10.3 Property Associations
A property association correlates a property value or list of property values with a property name resulting from evaluation of property expressions.  Property associations can be declared within component types, component implementations, subcomponents, features, connections, flows, modes, and subprogram calls, as well as their respective refinement declarations. Subcomponents can also declare contained property associations of subcomponents contained in them.  Contained property associations permit separate property values to be associated with every component in the system instance hierarchy (see Section 12.1).
Syntax
property_association ::=
  [ property_set_identifier :: ] property_name_identifier ( => | +=> )
      [ constant ] property_value
      [ in_binding ]
      [ in_modes ] ;

access_property_association ::=
  [ property_set_identifier :: ] property_name_identifier ( => | +=> )
      [ constant ] access property_value
      [ in_binding ]
      [ in_modes ] ;

contained_property_association ::=
  [ property_set_identifier :: ]
  property_name_identifier ( => | +=> )
     [ constant ] property_value
     applies to contained_unit_identifier { . contained_unit_identifier }*
     [ in_binding ]
     [ in_modes ] ;

property_value ::= single_property_value | property_list_value

single_property_value ::= property_expression

property_list_value ::=
  ( [ property_expression { , property_expression  }* ] )

in_binding ::=
      in binding ( platform_classifier_reference
                { , platform_classifier_reference }* )
platform_classifier_reference ::=
  processor_classifier_reference
  | memory_classifier_reference
  | bus_classifer_reference
Naming Rules
A property name consists of an optional property set identifier followed by a property identifier, separated by a double colon (“::”).
The property set identifier, if present, must appear in the global namespace and must be the defining identifier in a property set declaration. 
The property identifier must exist in the namespace of the property set, or if the optional property set identifier is absent, in the namespace of the predeclared property sets AADL_Properties or AADL_Project.
A property name may appear in the property association clause of a component type, component implementation, subcomponent, feature, flow, connection, mode, or subprogram call only if the respective AADL model element is listed in the applies to list of the property name declaration. 
The dot-separated identifier sequence following the reserved words applies to of a contained property association identifies a component, feature, flow, connection, or mode in the containment hierarchy, for which the property value holds.  The root of this path is the subcomponent or the component implementation with the contained property association declaration.  The path consists of a sequence of zero or more subcomponent identifiers followed by a subcomponent, feature, flow, connection, or mode identifier.  A port in a port group is identified by the port group identifier and the port identifier.
If a property association has an in binding statement, the property value is binding-specific. The property value applies if the binding is to one of the specified execution platform types of the categories processor, memory, or bus.  If a property association list contains both binding-specific associations and an association without an in binding statement, then the latter applies to all bindings not explicitly declared in in binding statements.
If a property association has an in modes statement, the property value is mode-specific. The property value applies if one of the specified modes is active.  If a property association list contains both mode-specific associations and an association without an in modes statement, then the latter applies to all associations not explicitly declared in in modes statements.
A property association list must have at most one property association for the same property name.  In case of mode-specific and binding-specific property associations, there must be at most one association for each mode and binding.
Legality Rules
The property named by a property association must list the category of the component type, component implementation, subcomponent, feature, connection, flow, or mode the property association is declared for in its Property_Owner_Category list (see Section 10.1.2). 
If a property association is declared within a package, the property value applies to all component classifier declarations contained in the package for which the property is valid.
If a property expression list consists of a list of two or more property expressions, all of those property expressions must be of the same property type. 
If the property declaration for the associated property name does not contain the reserved words list of, the property value must be a single property valueIf the property declaration for the associated property name contains the reserved words list of, the property value can be a single property value, which is interpreted to be a list of one value. 
The property association operator +=> must only be used if the property declaration for the associated property name contains the reserved words list of.  Furthermore, the property association may not have an in modes  or in binding statement.
The property association operator +=> may not be used in contained property associations.
In a property association, the type of the evaluated property expression must match the property type of the named property.
A property value declared by a property association with the reserved word constant cannot be changed.
The semantics rules below for determining the value of a property impose a precedence on the property associations for a property.  A property association with the reserved word constant must be the highest priority association. 
The reserved word access is only permitted and is required in property associations declared in required and provided access subcomponent declarations and refinements.
The unique component type identifiers in the in binding statement must refer to component types of the categories processor, memory, or bus.
Property associations declared as part of a component type declaration, port group type declaration, a feature or feature refinement declaration in a component type or port group type, or as part of a feature refinement in the refines type clause of a component implementation are not permitted to have an in modes statement as the scope of modes is limited to component implementations.  A feature refinement in the refines type clause of a component implementation must not inherit a modal property association from its component implementation.
Semantics
Property associations determine the property value of the component instances and their feature, connection, flow, and mode instances in the system instance hierarchy (see Section 12.1). The property association of a component type, component implementation, subcomponent, feature, flow, connection, mode, or subprogram call determines the property value of all instances derived from the respective declaration. 
If a property association is declared within a package, the property value applies to all component classifier declarations contained in the package for which the property is valid. 
The value of a property is determined through evaluation of the property expression.  Property associations are declared in the properties subclause of component types and component implementations.  They are also declared as part of feature declarations in component types, as part of subcomponent, connection, flow and mode declarations in component implementations. Contained property associations declared with subcomponents can represent separate property values for different instances of subcomponents, their features, connections, flows and modes that are contained in the subcomponent. Contained property associations can also be used to record system instance specific property values for all components, features, connections, flows, and modes in a system instance. This permits AADL analysis tools to record system instance specific information about a physical system separate from the declarative AADL specification.  For example, a resource allocation tool can record the actual bindings of threads to processors and source text to memory through a set of contained property associations, and can keep multiple such binding configurations for the same system.
The property value is determined according to the following rules, which impose a precedence on the property associations for a particular property.  The earlier a property association for the given property is encountered by the rules, the higher it’s precedence.
If a property value is not present after applying all of the rules below, it is determined by the default value of its property name declaration.  If not present in the property name declaration, the property value is undefined.
For component types and port group types, the property value of a property is determined by its property association in the properties subclause. If not present, the property value is determined by the first ancestor component type or port group type with its property association. If not present and the component type or port group type is declared in the private section of a package, then the property value is determined by its association in the property subclause of the private section.  If not present in the private section, it is determined by its association in the property subclause of the package’s public section.  If the component type or port group type is declared in the public section of a package, the property value is determined by its association in the public section of the package.  Otherwise, it is considered not present.
For component implementations and port groups, the property value of a property is determined by its property association in the properties subclause. If not present, the property value is determined by the first ancestor component implementation or port group with its property association. If not present, it is determined by the property value of the component implementation’s component type according to the component type rules. 
For subcomponents, the property value of a property is determined by its property association in the subcomponent declaration. If not present and the subcomponent is refined, then the property value is determined by a property association in the subcomponent declaration being refined; this is done recursively along the refinement sequence. If not present in the subcomponent, it is determined by the subcomponent’s component classifier reference according to the respective component implementation or component type rules described above.  If not present and the property name has been declared as inherit, it is determined by the property value of the component implementation that contains the subcomponent declaration according to the component implementation rules.  Otherwise, it is considered not present.
For modes, connections, or flow sequences the property value of a property is determined by its property association in the mode, connection, or flow sequence declaration. If not present and the mode, connection, or flow sequence is refined, then the property value is determined by a property association in the mode, connection, or flow sequence declaration being refined; this is done recursively along the refinement sequence. If not present and the property name has been declared as inherit, it is determined by the property value of the component implementation that contains the mode, connection, or flow sequence declaration according to the component implementation rules.  Otherwise, it is considered not present.
For subprogram calls in call sequences, the property value of a property is determined by its property association in the subprogram call.  If not present and the called subprogram name is a subprogram classifier reference, the property value is determined by the subprogram classifier according to the component implementation or component type rules described above.  If not present and the called subprogram name is a subprogram feature reference in a data component, the property value is determined by the subprogram feature according to the feature rules described below.  If not present and the property name has been declared as inherit, it is determined by the property value of the component implementation that contains the subprogram call according to the compoment implementation rules.  Otherwise, it is considered not present.
For features in a component type or port group type, or flow specifications in a component type, the property value of a property is determined by its property association in the feature or flow specification declaration. If not present and the feature or flow specification is refined, then the property value is determined by a property association in the feature or flow specification declaration being refined; this is done recursively along the refinement sequence.  For subprogram, server subprogram, and port group features, if not present and the feature references a subprogram classifier or port group type reference, the property value is determined by the subprogram component classifier reference or port group type according to the respective component implementation, component type, or port group type rules described above. If not present and the feature references a subprogram feature in a data component type, the property value is determined by the subprogram feature according to the feature rules.  If not present and the property name has been declared as inherit, then it is determined by the property value of the component type or port group type that contains the feature or flow specification declaration according to the respective component type or port group type rules.  Otherwise, it is considered not present.
For features in a refines type clause of a component implementation, the property value of a property is determined by its property association in the feature refinement declaration   If not present, then the property value is determined by a property association in the feature declaration being refined; this is done recursively along the refinement sequence.  If not present and the property value has been declared inherit, it is determined by the property value of the component implementation according to the component implementation rules.  Otherwise, it is considered not present.
For component, feature, connection, flow, or mode instances in the system instance hierarchy, the property value of a property is determined by the contained property association highest in the system instance hierarchy that references the component, feature, connection, flow, or mode.  If not present, then the property value is determined by the respective subcomponent, mode, connection, feature declaration that results in the instance according to the rules above.  If not present and the property name has been declared as inherit, then it is determined by the property value of the first containing component in the containment hierarchy of the system instance. Otherwise, it is undefined.
graphic
Figure 16 Property Value Determination
Figure 16 illustrates the order in which the value of a property is determined. Instance4 is an element in the system instance hierarchy.  The value of one of its properties is determined by first looking for a property associated with the instance itself – shown as step 1.  This is specified by a contained property association. The contained property association for this instance declared in a component implementation highest in the instance hierarchy determines that value.  If no instance value exists, the implementation (ImplA) of the instance is examined (step 2).  If it does not exist, ancestor implementations are examined (step 3).  If the property value still has not been determined, the component type is examined (step 4).  If not found there, its ancestor component types are examined (step 5).  If not found and the property is inherited, for subcomponents and features, the enclosing implementation is examined.  Otherwise, the containing component in the component instance hierarchy is examined (step 6).  Finally, the default value is considered.
Two property association operators are supported.  The operator => results in a new value for the property.  The operator +=> results in the addition of a value to a property value list.  More specifically, a property association via the operator => replaces any associations of lower precedence according to the above rules.  A property association via the operator +=> appends to the value determined by the association immediately preceding it according to the order imposed by the above rules.
A property value list is evaluated by evaluating each of the property expressions, and appending the values in order.  If the property expression evaluates to a list, all the list elements are appended.  If the property expression evaluates to undefined, it is treated as an empty list. 
If a property association is declared with the reserved word constant, then the following rules apply:
For subcomponents, connections, flow sequences, and modes, any refinements cannot contain a property association for this property.
For features or flow specifications, any refinements cannot contain a property association for this property.
For component implementations, any component implementation extension, or any subcomponents referencing the component implementation or any of its descendents as component classifier cannot contain a property association for this property.
For port groups, any port group refinement cannot contain a property association for this property.
For component types, any component type extension, any component implementation, any subcomponent, or any subprogram or server subprogram feature referencing the component type or any of its descendents cannot contain a property association for this property.
For port group types, any port group type extension or any port group feature referencing the port group type or any its descendents cannot contain a property association for this property.
A property association declared with the reserved word access applies to the access to an actual subcomponent represented by the provided or required subcomponent access rather than the actual subcomponent itself.  Two different components sharing access to a component may have different access property associations.
The optional in_modes subclause specifies what modes the property association is part of.  The detailed semantics of this subclause are defined in Section 11.1.
Component instance property associations with specified contained subcomponent identifier sequences allow separate property values to be associated with each component instance in the containment hierarchy. In particular, it permits separate property values such as actual processor binding property values or result values from an analysis method to be associated with each component in the system instance containment hierarchy.