Closed reteprelief closed 8 years ago
For feature connections, the 2.2 draft standard explicitly mentions only
as the ends of a feature connection.
Feature groups, internal features, processor features, and subcomponents are not mentioned in the text, and the grammar rules use the term feature_identifier
, so currently they are not allowed.
According to the standard, abstract features are not allowed as ends of port and access connections, and abstract components are not allowed as access connection ends.
I marked a comment for the ballot review. Abstract features can be refined into feature groups. So it makes sense to allow feature connections between feature groups. There is a statement in (2) and in (N2) that need to be fixed. For subcomponent as endpoint it is ugly - shows that people should use access features to connect.
The implementation seems to allow feature connection between feature groups. I have some examples.
The AADL 2.2 draft actually contradicts itself. We will continue to require one abstract feature for a feature connection (as specified in the semantics section 9.1 (4)). AADL 3 will get rid the various kinds of connections. Currently we allow feature connections between feature groups. These are then treated like feature group connections. We should remove this.
The standard indicates that a feature connection declaration can be used for any connection endpoints. Currently it is limited to abstract features and internal features. Proposal: change FeatureConnectionEnd to accept any feature or subcomponent.
There is a similar issue with abstract features not being acceptable as PortConnectionEnd, AccessConnectionEnd. Finally, AbstractSubcomponent should be allowed as endpoint for access connections.