4     Components, Packages, and Annexes

(1)   The AADL defines the following categories of components: data, subprogram, subprogram group, thread, thread group, process, memory, bus, virtual bus, processor, virtual processor, device, system, and abstract.  The category abstract can be refined into any of the other categories.  This section describes those aspects of components that are common to all AADL component categories.  This section also describes packages as an organizing mechanism for component types and implementations.  This section closes with the definition of annex subclauses and annex libraries.

(2)   A component represents some hardware or software entity that is part of a system being modeled in AADL.  A component has a component type, which defines a functional interface.  The component type acts as the specification of a component that other components can operate against. It consists of features, flows, and property associations. 

(3)   A feature models a characteristic of a component that is visible to other components.  Features are named, externally visible parts of the component type, and are used to exchange control and data via connections with other components.  Features include ports to support directional flow of data and control, and subprograms including support for remote procedure call interactions.  Features define parameters that represent the data values that can be passed into and out of subprograms.  Features specify component access requirements for external data and bus components. Component access requirements for external subprograms support remote procedure call interactions.

(4)   A component has zero or more component implementations.  Component implementations represent variants of a component that adhere to the same interface, but may have different property values.  A component implementation specifies the realization of a component variant, i.e., an internal structure for a component as an assembly of subcomponents.  Subcomponents are instantiations of component classifiers, i.e., component types and implementations.

(5)   Components are named and have properties.  These properties have associated values that represent attributes and characteristics of a component.  

(6)   Components can be declared in terms of other components by refining and extending existing component types and component implementations.  This permits partially complete component type and implementation declarations to act as templates that may have explicit parameter (prototype) specifications.  Such templates can represent a common basis for the evolution of a family of related component types and implementations.

(7)   This standard defines basic concepts and requirements for determining compliance between a component specification and a physical component.  Within this framework, annexes to this standard will specify detailed compliance requirements for specific software programming, application modeling, and hardware description languages.  This standard does not restrict the lower-level representation(s) used for software components, e.g., binary images, conventional programming languages, application modeling languages, nor does it restrict the lower-level representation(s) used for physical hardware component designs, e.g., circuit diagrams, hardware behavioral descriptions.