4. Components, Packages, and Annexes
The AADL defines the following categories of components: data, subprogram, thread, thread group, process, memory, bus, processor, device, and system.  This section describes those aspects of components that are common to all AADL component categories.  This section also describes packages as an organizing mechanism.  This section closes with the definition of annex subclauses and annex libraries.
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. 
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 (server subprograms).  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.
A component has zero or more component implementations.  A component implementation specifies an internal structure for a component as an assembly of subcomponents. Subcomponents are instantiations of component classifiers, i.e., component types and implementations.
Components are named and have properties.  These properties have associated expressions and values that represent attributes and behaviors of a component.  
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 a common basis for the evolution of a family of related component types and implementations.
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.