![]() ![]() |
||||
|
||||
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. |
||||