4.2 Notes on Accessing Models
The AADL meta model defines attributes for classes in the meta model as well as containment and reference associations between classes. Attributes are pieces of information stored in an object of an AADL model itself. An example attribute is the timing attribute of the DataConnection class in Figure 18. The association eventConnection is a containment association between the Connections and EventConnection class in Figure 18. The association refines is a reference association between two AADL model objects of the class EventConnection in Figure 18. Attributes, containments, and references can be single valued (shown by an indicator of 0..1 or 1), or they can be multi-valued (shown by an indicator whose upper bound is greater than 1 with * indicating an arbitrary number).
4.2.1 An API for Accessing AADL Models
EMF generates a collection of methods for accessing and changing AADL models. The API for accessing AADL models consists of a collection of getter methods. These methods have the name get and the name of the attribute, containment, or reference to be accessed. For example, the method getRefines() provides access from an EventConnection object to the EventConnection object it refines. Reference associations automatically handle references between objects stored in different XML documents. If an attribute, containment, or reference is multi-valued, then the multi-value list is returned in form of an EList class.
The API for changing the model consists of setter methods. For single values these methods have the name set and the name of the attribute, containment, or reference to be changed. For multi-valued attributes, containment, and references these methods have the name add and the name of the attribute, containment, or reference to be added to the multiplicity list. The multi- value list can also be retrieved with the getter method and cleared.
Some classes have a set of containment associations to concrete classes that represent different categories of an abstract class. In the meta model shown in Figure 18, the class Connections contains EventConnection objects, DataConnection objects, etc. under separate containment associations. As a result, the contained XML elements have tag names that correspond to the containment label. Although they have separate containment associations, they represent a collection of connections. An EMF provided method eContents() returns the objects of all containment associations of an AADL model object. An EMF feature map has been specified in the meta model (see [AADL Meta Model Annex]). This feature map maintains an ordering of all contained objects across the containment associations. This assures that the order in which connection objects are added to a model is the same order in which they are returned by eContents(). In the case of a parsed AADL model, this order is the declaration order encountered in the textual AADL model.
These methods are straightforward implementations and strictly follow the structure of the model. While in many cases these methods are perfectly adequate, we have introduced additional convenience methods into the API.
4.2.2 Eliding Model Structure
The meta model includes structural information that is sometimes not interesting to clients of the model. For example, ComponentImpl has a connections containment that refers to a Connections object, which in turn, has the containments labeled dataAccessConnection, busAccessConnection, parameterConnection, eventConnection, etc. That is, there is an additional layer of abstraction between a component implementation and its connections that represents the connections subclause of the component implementation; see Figure 18. This applies to all subclauses of classifiers.
graphic
Figure 18: Portion of meta model hierarchy showing extra level of indirection in the representation of connections. Note that the classes referenced by Connections are all subclasses of Connection.
Some processing of AADL models can be performed for all classifiers, component types, or component implementations and the same processing is done for all elements of each subclause. In this case the processing methods want to retrieve all elements of a component type or component implementation subclause, i.e., all connections of a component implementation in our example, directly.
For this reason we have provided convenience methods for the classes Classifier, ComponentClassifier, ComponentType, and ComponentImpl. For example, in addition to the method ComponentImpl.getConnections() that returns the Connections object, ComponentImpl has the method getConnection() that returns an EList of Connection objects representing the connection declarations and refinements specified in the component implementation.
4.2.3 AADL Inheritance Semantics
The meta model generated getter methods do not understand the inheritance semantics of AADL. For example, when retrieving the connections in a component implementation, analysis is often interested in the connections declared in that component implementation together with the connections defined in any ancestor component implementations. In addition, if an ancestor connection is refined, only the declaration of the refinement is interesting. However, the meta model only captures the syntactic structure of the AADL model. The connections referenced by the Connections model object are thus only those connections declared within the associated component implementation. We thus have the convention that a normal meta model get method returns only those elements that are locally declared within a component, and that an additional getAll method returns all elements that are visible in the component due to inheritance, taking refinement into account. Be aware that not all getAll methods return lists: some attributes are inheritable via feature refinement, but they instead fill in previously unspecified information, for example, the component classifier of a subprogram feature.
This naming convention combines with the previous convention: continuing with the connections example, ComponentImpl also has the method getAllConnection() that returns an EList of Connection objects representing all the connections visible in the component implementation, including those inherited from ancestor component implementations.
4.2.4 Specialized Reference Associations
In some cases the meta model has containment or reference associations defined for abstract classes that are specialized as containment or reference associations with the same label for concrete subclasses. For example, all the subclasses of ComponentImpl declare a subcomponents containment. This abstract containment association is denoted in the meta model via a dashed line; see Figure 19. Example specializations of this subcomponents containment association are shown in Figure 20: DataImpl’s subcomponents attribute refers to a DataSubcomponents object, ThreadImpl’s subcomponents attribute refers to a ThreadSubcomponents object, etc.
Because EMF does not support abstract associations and their specializations, no access methods are automatically generated. Even if the appropriate access methods are added to the abstract classes—in our example to ComponentImpl—Java 1.4 would complain about incompatible return types because subclasses cannot refine the return value of a method. In our case, the return value of the access method getSubcomponents() of the subclass DataImpl would return DataSubcomponents, but the access method would have to be declared in ComponentImpl to return an instance of Subcomponents.
graphic
Figure 19: Portion of meta model showing the abstract subcomponent attribute between ComponentImpl and Subcomponents.
graphic
Figure 20: Portion of meta model showing DataImpl and ThreadImpl's specific subcomponents attributes. This excerpt does not show the fact that DataSubcomponents and ThreadSubcomponents are subclasses of Subcomponents.
To get around this problem, we have a third naming convention: we use getX methods to name generic getter methods in super classes. Again, this convention combines with the two previously described conventions. Thus ComponentImpl has the method getXSubcomponents() that returns a Subcomponents object (the super class of DataSubcomponents, ThreadSubcomponents, etc.), as well as the methods getXSubcomponent() and getXAllSubcomponent() that each return an EList of Subcomponent objects.
Note: Java 1.5 fixes this problem by allowing covariant return types on overridden methods.
4.2.5 Unifying “Either-Or” Associations
In a few cases a class in the meta model has a reference and containment association where only one of the two is expected to be set. For example, NumberType has a reference association unitsTypeReference and a containment association unitsType. These two associations come about because the AADL syntax allows the declaration of a number type to either reference a declared units type or specify the unit type in-place within the number type declaration. Thus to get the unit type from a NumberType, you have to check both associations and use which ever is non-null. This is verbose and error prone, so the naming pattern getThe is used to name a single method that returns which ever association is non-null. For example, NumberType has the method getTheUnitsType().
4.2.6 Specific Instances of the Getter Method Patterns
Package edu.cmu.sei.aadl.model.core
Class
Attribute
Additional Methods
ComponentClassifier
Abstract features
getXAllFeature
Abstract extends
getXExtend
ComponentImpl
Abstract callSequences
getXAllCallSequence
getXCallSequence
getXCallSequences
connections
getAllConnection
getAllConnection(Mode)
getConnection
getConnection(Mode)
Abstract features
getXAllFeature
getXAllAbstractPort
flows
getAllFlowSequence
getAllFlowSequence(Mode)
getFlowSequence
getFlowSequence(Mode)
modes
getAllMode
getAllModeAndModeTransition
getAllModeTransition
getMode
getModeAndModeTransition
getModeTransition
refinesType
getAllRefinedFeature
Abstract subcomponents
getXAllSubcomponent
getXAllSubcomponent(Mode)
getXSubcomponent
getXSubcomponent(Mode)
getXSubcomponents
ComponentType
Abstract feature
getXAllFeature
getXFeature
getXFeatures
flowSpecs
getAllFlowSpec
getFlowSpec
Connection
Abstract dst
getXAllDst
getXDst
dstContext
getDstContext
getAllDstContext
Abstract refines
getXRefines
Abstract src
getXAllSrc
getXSrc
srcContext
getSrcContext
getAllSrcContext
Feature
Abstract dataClassifier
getXAllDataClassifier
getXDataClassifier
Abstract refines
getXRefines
PropertyHolder
properties
getPropertyAssociation
Subcomponent
Abstract classifier
getXClassifier
Abstract feature
getXAllAbstractPort
getXAllFeature
Abstract refines
getXRefines
Package edu.cmu.sei.aadl.model.feature
Class
Attribute
Additional Methods
BusAccess
busClassifier
getAllBusClassifier
DataAccess
dataClassifier
getAllDataClassifier
Parameter
direction
getAllDirection
Port
direction
getAllDirection
PortGroupType
feature
getAllFeature
getFeature
ServerSubprogram
subprogramClassifier
getAllSubprogramClassifier
Subprogram
subprogramClassifier
getAllSubprogramClassifier
Package edu.cmu.sei.aadl.model.flow
Class
Attribute
Additional Methods
FlowImpl
Abstract implement
getXAllImplement
getXImplement
FlowSpec
Abstract dst
getXAllDst
getXDst
Abstract dstContext
getXAllDstContext
getXDstContext
Abstract src
getXAllSrc
getXSrc
Abstract srcContext
getXAllSrcContext
getXSrcContext
Package edu.cmu.sei.aadl.model.instance
Class
Attribute
Additional Methods
ComponentInstance
Abstract componentImpl
getXComponentImpl
Package edu.cmu.sei.aadl.model.property
Class
Attribute
Additional Methods
NumberType
unitsType
getTheUnitsType
unitsTypeReference
NumberValue
Abstract value
getXValue
PropertyConstant
propertyType
getThePropertyType
propertyTypeReference
PropertyDefinition
propertyType
getThePropertyType
propertyTypeReference
RangeType
numberType
getTheNumberType
numberTypeReference