(1) Access connections represent access to shared data components by concurrently executing threads or by subprograms executing within thread. They also denote communication between processors, memory, and devices by accessing a shared bus. Finally, they represent a subprogram call to a specific instance of a subprogram or subprogram group. If the subprogram or subprogram group resides in a different thread, then the call is treated as a remote call. Access connections for subprograms and buses are bidirectional. Data and bus access connections may be bidirectional or directional. If they are directional they indicate write or read access to the data component or bus component.
(2) A semantic access connection is defined by a sequence of one or more individual access connection declarations that follow the component containment hierarchy from an ultimate source to an ultimate destination.
(3) In the case of bidirectional connections either the subcomponent being accessed or the feature that requires access can be the ultimate source or destination. In the case of directional data access connections the ultimate source is the source of the data flow, i.e., the data component in the case of a read access and the ultimate destination in the case of a write access. In the case of partial AADL models, the ultimate source or destination may be a provides access feature of a component without subcomponents.
(4) Figure 19 illustrates a semantic data connection from the data component D to thread Q. The access connection is bidirectional, thus, the data component could be the ultimate destination as well.
Figure 19 Semantic Access Connection For Data Components
(5) The flow of data of a semantic data or bus access connection is determined by the Access_Right property on the shared component or the access feature. In the case of a directional access connection and the connection direction must be consistent with the access rights.
Syntax
access_connection ::=
[ bus | subprogram | subprogram group | data ] access
source_access_reference connection_symbol destination_access_reference
access_connection_refinement ::=
[ bus | subprogram | subprogram group | data ] access
access_reference ::=
-- requires or provides access feature in the component type
requires_access_identifier | provides_access_identifier
|
-- requires or provides access feature in a feature group of the component type
feature_group_identifier . requires_access_identifier
|
feature_group_identifier . provides_access_identifier
|
-- provides or requires access in a subcomponent
subcomponent_identifier . provides_access_identifier
|
subcomponent_identifier . requires_access_identifier
|
subprogram_call_identifier . requires_or_provides_access_identifier
-- data, subprogram, subprogram group or bus being accessed
data_subprogram_subprogram_group_or_bus_subcomponent_identifier
|
-- subprogram a processor being accessed
processor . provides_subprogram_access_identifier
Naming Rules
(N1) The connection identifier in an access connection refinement declaration must refer to a named access or feature connection declared in an ancestor component implementation.
(N2) An access reference in an access connection declaration must reference an access feature of a subcomponent, subprogram call, or processor, an access feature in the component type of the containing component, an access feature in a feature group of the containing component type, or a data, bus, subprogram, or subprogram group subcomponent.
Legality Rules
(L1) The category of the source and the destination of a access connection declaration must be the same, i.e., they must both be data, bus, subprogram, or subprogram group, or their respective access feature.
(L2) In the case of a bidirectional semantic access connection either connection end can be the source.
(L3) In the case of a directional data or bus access connection the connection end representing the component being accessed must be the source for read access, and the destination for write access, i.e., the direction declared for the access connection must be compatible with the direction of the data flow for reading or writing based on the access rights.
(L4) In a partial AADL model the ultimate source or destination may be a provides access feature of a component instead of the subcomponent.
The provides and requires indicators of source and destination access features must satisfy the following rules:
(L5) If the access connection declaration represents an access connection between access features of sibling components, then the source must be a provides access, and the destination must be a requires access, or vice versa.
(L6) If the access connection declaration represents a feature mapping up the containment hierarchy, then one connection end must be a provides access of a subcomponent, or a data, subprogram, or bus subcomponent; and the other connection end must be a provides access feature of the enclosing component or a provides feature of a feature group of the enclosing component.
(L7) If the access connection declaration represents a feature mapping down the containment hierarchy, then one connection end must be a requires access of the enclosing component, a requires access of a feature group of the enclosing component, or a data, subprogram, or bus subcomponent; and the other connection end must be a requires access of a subcomponent.
(L8) An access connection must not lead to more than one bus, data, or subprogram subcomponent unless the connection is mode specific. In this case, the restriction applies for each mode.
(L9) For access connections the classifier of the provider access must match to the classifier of the requires access according to the Classifier_Matching_Rules property. By default the classifiers must be the same (see Section 9.1).
(L10) If more than one access feature in a semantic access connection has an Access_Right property association, then the resulting property values must be compatible. This means that the provider must provide read-only or read-write access if the requirer specifies read-only. Similarly, the provider must provide write-only or read-write access if the requirer specifies write-only. The provider must provide read-write access if the requirer specifies read-write. Finally, the provider must provide by-method access if the requirer specifies by-method access.
(L11) The category of the access connection source and destination must be identical. If the component category is specified as part of the connection declaration, then it must be identical to that of the source and destination. Bus, data, subprogram, and subprogram group are acceptable categories.
Standard Properties
Connection_Pattern: list of list of Supported_Connection_Patterns
Connection_Set: list of Connection_Pair
Semantics
(6) A data access connection represents access to a shared data component by concurrently executing threads or by subprograms executing within thread. A subprogram access or subprogram group access connection represents access to subprogram code or a library that calls can be made to. The call may be a remote call. A bus access connection represents communication between processors, memory, and devices by accessing a shared bus.
(7) Access connections are restricted to 1-n connectivity, i.e., a data, subprogram, or bus component can have multiple outgoing access connections, but a requires access feature can only have one connection. The restriction of one connection applies to each mode, i.e., different incoming access connections may exist in different modes, but not in the same mode.
(8) The optional in_modes subclause specifies what modes the access connection is part of. The detailed semantics of this subclause are defined in Section 12.
(9) The actual data flow through data and bus access connections is determined by the value of the Access_Right property on the shared data or bus component and their provides and requires access declarations. Read means flow of data from the shared component to the component requiring access, and write means flow of data from the component requiring access to the shared component. The desired data flow can also be indicated by specifying the direction in the access connection declaration.
(10) The connection patterns for component arrays described in Section 9.2.3 apply to access connections as well.