(1) Feature groups represent groups of component features or feature groups. Within a component, the features of a feature group can be connected to individually. Outside a component, feature groups can be connected as a single unit. This grouping concept allows the number of connection declarations to be reduced, especially at higher levels of a system when a number of features from one subcomponent and its contained subcomponents must be connected to features in another subcomponent and its contained subcomponents. The content of a feature group is declared through a feature group type declaration. This declaration is then referenced when feature groups are declared as component features. Feature groups can be declared for any kind of feature, for ports, and for access features.
Syntax
-- Defining the content structure of a feature group
feature_group_type ::=
feature group defining_identifier
[ prototypes ( { prototype }+ | none_statement ) ]
[ features { feature }+ ]
[ inverse of unique_feature_group_type_reference ]
[ properties ( { feature_group_contained_property_association }+ | none_statement ) ]
{ annex_subclause }*
end defining_identifier ;
feature_group_type_extension ::=
feature group defining_identifier
extends unique_feature_group_type_reference [ prototype_bindings ]
[ prototypes ( { prototype | prototype_refinement }+ | none_statement ) ]
[ features { feature | feature_refinement }+ ]
[ inverse of unique_feature_group_type_reference ]
[ properties ( { feature_group_contained_property_association }+ | none_statement ) ]
{ annex_subclause }*
end defining_identifier ;
-- declaring a feature group as component feature
feature_group_spec ::=
defining_feature_group_identifier : [ in | out ] feature group
[ [ inverse of ]
( unique_feature_group_type_reference | feature_group_prototype_identifier ) ]
feature_group_refinement ::=
defining_feature_group_identifier : refined to [ in | out ] feature group
[ [ inverse of ]
( unique_feature_group_type_reference | feature_group_prototype_identifier ) ]
unique_feature_group_type_reference ::=
[ package_name :: ] feature_group_type_identifier
Naming Rules
(N1) The defining identifier of a feature group type must be unique within the package namespace of the package where the feature group type is declared.
(N2) Each feature group type provides a local namespace. The defining identifiers of prototype, feature, and feature group declarations in a feature group type must be unique within the namespace of the feature group type.
(N3) The local namespace of a feature group type extension includes the defining identifiers in the local namespace of the feature group type being extended. This means, the defining identifiers of prototype, feature, or feature group declarations in a feature group type extension must not exist in the local namespace of the feature group type being extended. The defining identifiers of prototype, feature, or feature group refinements in a feature group type extension must refer to a prototype, feature, or feature group in the local namespace of an ancestor feature group type.
(N4) The defining feature identifiers of feature group declarations must be unique in the local name space of the component type containing the feature group declaration.
(N5) The defining feature group identifier of feature_refinement declarations in component types must exist in the local namespace of the component type being extended and must refer to a feature or feature group.
(N6) The package name of the unique feature group type reference must refer to a package name in the global namespace. The feature group type identifier of the unique feature group type reference must refer to a feature group type identifier in the named package.
(N7) The prototype reference in a feature group declaration must refer to a prototype of the component type or feature group type that contains the feature group declaration.
Legality Rules
(L1) A feature group type may contain zero or more elements, i.e., feature or feature groups. If it contains zero elements, then the feature group type may be declared to be the inverse of another feature group type.
(L2) A feature group type can be declared to be the inverse of another feature group type, as indicated by the reserved words inverse of and the name of a feature group type. Any feature group type named in an inverse of statement cannot itself contain an inverse of statement. This means that several feature groups can be declared to be the inverse of one feature group, e.g., B inverse of A and C inverse of A is acceptable. However, chaining of inverses is not permitted, e.g., B inverse of A and C inverse of B is not acceptable.
(L3) Only feature group types without inverse of or feature group types with features and inverse of can be extended.
(L4) A feature group type that is an extension of another feature group type without an inverse of cannot contain an inverse of statement.
(L5) The feature group type that is an extension of another feature group type with features and inverse of that adds features must have an inverse of to identify the feature group type whose inverse it is.
(L6) A feature group declaration with an inverse of statement must only reference feature group types without an inverse of statement.
(L7) A feature group refinement may be refined to only add property associations. In this case inclusion of the feature group type reference is optional.
Two feature group types are considered to complement each other if the following holds:
(L8) The number of feature or feature groups contained in the feature group and its complement must be identical;
(L9) Each of the declared features or feature groups in a feature group must be a pair-wise complement with that in the feature group complement, with pairs determined by declaration order. In the case of feature group type extensions, the feature and feature group declarations in the extension are considered to be declared after the declarations in the feature group type being extended;
(L10) If both feature group types have zero features, then they are considered to complement each other;
(L11) Ports are pair-wise complementary if they satisfy the port connection rules specified in Section 9.2.1. This includes appropriate port direction and matching of data component classifier references according to classifier matching rules (see Section 9.5 legality rules (L3) and (L4);
(L12) Access features are pair-wise complementary if they satisfy the access connection rules in Section 9.4.
(L13) If an in or out direction is specified as part of a feature group declaration, then all features inside the feature group must satisfy this direction.
NOTES:
Aggregate data ports can be modeled in AADL V2 by a data port with a data component classifier that has data subcomponents for each of the element ports. This replaces the Aggregate_Data_Port on port groups in the original AADL standard.
Standard Properties
-- Port properties defined to be inherit, thus can be associated with a
-- feature group to apply to all contained ports.
Source_Text: inherit list of aadlstring
Allowed_Memory_Binding_Class:
inherit list of classifier (memory, system, processor)
Allowed_Memory_Binding: inherit list of reference (memory, system, processor)
Actual_Memory_Binding: inherit list of reference (memory)
Semantics
(2) A feature group declaration represents groups of component features. As such each feature group of a component type can represent a separate interface to the component.
(3) A feature group of a component can be connected to another component through a single connection declaration. It represents a connection for each of the feature inside the feature group. Feature groups can contain feature groups. This supports nested grouping of features for different levels of the modeled system.
(4) Within a component, the features of a feature group can be connected to individually to subcomponents. The members of the feature group are declared in a feature group type declaration that is referenced by the feature group declaration. The referenced feature group type determines the feature group compatibility for a feature group connection.
(5) The inverse of reserved words of a feature group type declaration indicate that the feature group type represents the complement to the referenced feature group type. The legality of feature group connections is affected by the complementary nature of feature groups (see Section 9.5).
(6) Features can be declared without feature group types or with feature group types without features. They are considered to be incomplete feature group specifications. Feature group types can later be added in a feature group refinement. Features can later be inserted directly into the feature group type or the feature group type can later be refined into feature group types with one or more features.
Examples
package GPS_Interface
public
with GPSLib;
feature group GPSbasic_socket
features
Wakeup: in event port;
Observation: out data port GPSLib::position;
end GPSbasic_socket;
feature group GPSbasic_plug
features
WakeupEvent: out event port;
ObservationData: in data port GPSLib::position;
-- the features must match in same order with opposite direction
inverse of GPSbasic_socket
end GPSbasic_plug;
feature group MyGPS_plug
-- second feature group as inverse of the original
-- no chaining in inverse and
-- no pairwise inverse references are allowed
inverse of GPSbasic_socket
end MyGPS_plug;
feature group GPSextended_socket extends GPSbasic_socket
features
Signal: out event port;
Cmd: in data port GPSLib::commands;
end GPSextended_socket;
process Satellite_position
features
position: feature group GPSBasic_socket;
end Satellite_position;
process GPS_System
features
position: feature group inverse of GPSbasic_socket;
end GPS_System;
system Satellite
end Satellite;
system implementation Satellite.others
subcomponents
SatPos: process Satellite_position;
MyGPS: process GPS_System;
connections
satconn: feature group Satpos.position <-> MyGPS.position;
end Satellite.others;
end GPS_Interface;