![]() ![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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.
![]() 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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: DataImpls subcomponents attribute
refers
to a DataSubcomponents object, ThreadImpls 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 classesin our example to ComponentImplJava 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.
![]() Figure 19: Portion of meta model
showing the abstract subcomponent attribute between ComponentImpl and
Subcomponents.
![]() 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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(). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||