![]() ![]() |
||||
|
||||
The focus of the AADL meta model is to represent the
declarative structure of AADL models as an
object model, with relevant cross-references directly expressed in the object model, and to map
this object model into an XML document.
An AADL model described by such a class diagram of the
AADL meta model maps into an XML
document as follows:
The XPath reference notation results in unnamed model
objects in the reference path being
recorded by their containment label, while named model objects are recorded by their containment
label followed by the name as attribute, e.g., threadType[@name=GPS]. In case of a containment
multiplicity of unnamed model objects the object is identified by the containment label and the
index starting with zero as attribute, e.g., modeTransition[@index=0]. We always record these
references as absolute references, i.e., references relative to the XML document root. For
example, the following XPath references a thread type named GPS within the public section of a
package specification named edu::cmu::sei::XMIExample.
compType="//aadlPackage[@name=edu::cmu::sei::XMIExample]/aadlPublic/threadType[@name=GPS]".
References to model objects in the same XML document
use the current AadlSpec object as root,
as indicated by //. References to model objects in other XML documents explicitly
name the
AadlSpec object. Its name is used to identify the name of the XML document that contains the
referenced model. For example, the following XPath references the property definition
SafetyCriticality
that is declared in the property set SEI in the XML document SEI.
propertyDefinition="/aadlSpec[@name=SEI]/propertySet[@name=SEI]/propertyDefinition[@name=SafetyCriticality]".
References encoded in the XPath reference
notation are interpreted as URIs. The first element of
the Xpath, if present, is interpreted like the URL portion of a URI, i.e., the AadlSpec name is
mapped to a name in the file system to identify the file containing the XML document of the
package. This allows the XML documents to be independent of the particular location of the file that
contains the XML document.
Figure 5 shows an example AADL model that consists of
a system type and a system
implementation.
package edu::cmu::sei::XMIExample
public
system GPS
features
init: in event port;
signal: out data port
GPS_Signal;
end GPS;
system implementation
GPS.basic
end GPS.Basic;
data GPS_Signal
end GPS_Signal;
end edu::cmu::sei::XMIExample;
Figure 5 An Example AADL Model
Figure 6 shows the XML document based for that AADL model.
The highlighted attribute of a
system implementation XML element shows the reference of the system implementation to its
system type.
<?xml version="1.0" encoding="ASCII"?>
<core:AadlSpec xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:core="http://core" xmlns:property="http://property">
<aadlPackage name="edu::cmu::sei::XMIExample">
<aadlPublic>
<systemType
name="GPS">
<features>
<eventPort name="init"/>
<dataPort name="signal" direction="out"
dataClassifier="//aadlPackage[@name=edu::cmu::sei::XMIExample]/aadlPublic/dataType[@name=GPS_Signal]"/>
</features>
</systemType>
<systemImpl
name="GPS.basic"
compType="//aadlPackage[@name=edu::cmu::sei::XMIExample]/aadlPublic/systemType[@name=GPS]"/>
<dataType
name="GPS_Signal"/>
</aadlPublic>
</aadlPackage>
</core:AadlSpec>
Figure 6 XML Document of AADL Model
Figure 7 shows the class description for system types
and system implementations in the AADL
meta model. The association between the system type and system implementation is shown as bi-
directional; the reference from the system type to the system implementation is defined as
transient, i.e., it is not stored in the XML document. This reduces the size of XML documents,
while at the same time provides for efficient access to objects in the AADL model when operated
on by tools.
![]() Figure 7 System Component Meta Model
Figure 8 shows the XMI specification of the system type
and system implementation as it is
generated by EMF from the Ecore meta model. Only the compType portion of the bi-directional
reference association between the system type and the system implementation is specified for
persistent storage. The compType reference association (shown as xsd:element
name=compType) is shown as being restricted to SystemType (shown as
type=component:SystemType). In other words, system implementations can only
refer to system
types. The reference value is recorded as string valued attribute in the example of Figure
6
shown in XPath format.
<xsd:complexType name="SystemType">
<xsd:complexContent>
<xsd:extension base="core:ComponentType">
<xsd:choice minOccurs="0"
maxOccurs="unbounded">
<xsd:element
name="extend" nillable="true"
type="component:SystemType"/>
<xsd:element
name="features" type="feature:SystemFeatures"/>
</xsd:choice>
<xsd:attribute name="extend"
type="xsd:string"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="SystemType" type="component:SystemType"/>
<xsd:complexType name="SystemImpl">
<xsd:complexContent>
<xsd:extension base="core:ComponentImpl">
<xsd:choice minOccurs="0"
maxOccurs="unbounded">
<xsd:element
name="subcomponents"
type="component:SystemSubcomponents"/>
<xsd:element
name="compType" type="component:SystemType"/>
<xsd:element
name="extend" nillable="true"
type="component:SystemImpl"/>
</xsd:choice>
<xsd:attribute
name="compType" type="xsd:string"/>
<xsd:attribute name="extend"
type="xsd:string"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="SystemImpl" type="component:SystemImpl"/>
Figure 8 XMI Meta Model of System Type & Implementation
Figure 9 shows the generated XML
schema for the system implementation as it is generated by
EMF from the Ecore meta model. The highlighted section shows that the reference association
compType is recorded as a string. The restriction of the reference to system types is not
explicitly
recorded in the XML schema. This illustrates the richer expressive power of the XMI meta model
specification over the XML schema specification.
<xsd:complexType name="SystemType">
<xsd:complexContent>
<xsd:extension base="core:ComponentType">
<xsd:sequence>
<xsd:element
minOccurs="0" maxOccurs="1" name="features"
type="feature:SystemFeatures"/>
</xsd:sequence>
<xsd:attribute name="extend"
type="xsd:string"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="SystemType" type="component:SystemType"/>
<xsd:complexType name="SystemImpl">
<xsd:complexContent>
<xsd:extension base="core:ComponentImpl">
<xsd:sequence>
<xsd:element
minOccurs="0" maxOccurs="1" name="subcomponents"
type="component:SystemSubcomponents"/>
</xsd:sequence>
<xsd:attribute
name="compType" type="xsd:string"/>
<xsd:attribute name="extend"
type="xsd:string"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="SystemImpl" type="component:SystemImpl"/>
Figure 9 XML Schema for System Type & Implementation |
||||