(1) A connection is a linkage between features of two components that represents communication of data and control between components. This can be the transmission of control and data between ports of different threads or between threads and processor or device components. A connection may denote an event that triggers a mode transition. The timing of data and control transmission depends on the connection category and on the dispatch protocol of the connected threads. The flow of data between parameters of subprogram calls within a thread may be specified using connections. Finally, connections designate access to shared components.
(1) The AADL supports connections between abstract features, feature groups connections, port connections, parameter connections, and access connections. Port connections represent directional flow of data and control between two concurrently executing components, i.e., between two threads or between a thread and a processor or device. Parameter connections denote the flow of data through the parameters of a sequence of subprogram calls within a thread. Data access connections designate access to shared data components by concurrently executing threads or by subprograms executing within a thread. Bus access connections represent communication between processors, memory, and devices by accessing a shared bus. Subprogram access connections represent the binding of a subprogram call to a subprogram instance being called.
(2) When an AADL model with a thread architecture is instantiated, a connection instance is created from the ultimate source to the ultimate destination component by following a sequence of connection declarations. The ultimate source and ultimate destination typically are the active components in the instance model or components whose access is shared. This connection instance is referred to as semantic connection and its semantic details are defined for each of the different types of connections. If the AADL model is not fully detailed to the thread level, connection instances are created between the leaf components in the system hierarchy.
Syntax
connection ::=
defining_connection_identifier :
( feature_connection
| port_connection
| parameter_connection
| access_connection
| feature_group_connection )
[ { { property_association }+ } ]
[ in_modes_and_transitions ] ;
connection_refinement ::=
defining_connection_identifier : refined to
( feature_connection_refinement
| port_connection_refinement
| parameter_connection_refinement
| access_connection_refinement
| feature_group_connection_refinement )
[ { { property_association }+ } ]
[ in_modes_and_transitions ] ;
Naming Rules
(N1) The defining identifier of a defined connection declaration must be unique in the local namespace of the component implementation with the connection subclause. This is also the case for mode-specific connection declarations, i.e., declarations with an in_modes_and_transition subclause.
(N2) The connection identifier in a connection refinement declaration must refer to a named connection declared in an ancestor component implementation.
Legality Rules
(L1) A connection refinement must contain at least one of the following: a connection source and destination subclause, a property association, an in modes subclause.
(L2) If a semantic connection may be active in a particular mode, then the ultimate source and ultimate destination components must be part of that mode.
(L3) If a semantic connection may be active in a particular mode transition, then the ultimate source component must be part of a system mode that includes the old mode identifier and the ultimate destination component must be part of a system mode that includes the new mode identifier.
Semantics
(3) Connections define directional and bidirectional connectivity between abstract features, ports, access features, parameters, and between feature groups.
(4) Connections can have properties. Connections can be defined to be active in certain modes or in mode transitions, as indicated by the in_modes_and_transition subclause.