2.2 Mapping to XML Documents
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:
  • Concrete classes result in object instances in the AADL model.
  • Labels of containment associations result in element tags. 
  • Class attributes result in XML attributes. Multi-valued attributes result in collections of XML elements.
  • Reference associations within and across XML documents are represented by using the XML XPath construct as the reference notation [XPath 1999]. 
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.
graphic

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