5.5 Semantic Checking and Translation to XML
Parsing and semantic checking of textual AADL files and generation of an AADL MXL file can be done in two ways:
    • The parser and semantic checker are invoked automatically every time a save is performed in the AADL Text Editor.
    • The parser and semantic checker are invoked when the user selects the AADL text file in the Eclipse Navigator and invokes the “Generate Aaxl file” command from the “OSATE” menu or via tool bar button (graphic). 
5.5.1 Reporting of Errors and Warnings
Errors, warnings, and information from semantic checking or from analyses are reported in the “Problems” view.  This view is opened by going to “Window > Show View > Problems.”  Or it can be found under the “Basic” views in the “Show View” dialog box.
Double clicking on one of the items in the “Problem” view will result in the AADL text editor or the regular text editor to place its cursor at the appropriate location in the text file.
As described in Section 4.1, the contents of the view can be filtered based on severity and marker type.  In particular, make sure that the OSATE markers (subclasses of “Aadl Model Object Marker” and “Aadl Text Marker”) are active for the view.
Eclipse does not provide the ability to export the contents of this view so OSATE contains a “Generate Marker Report” command in the “OSATE” menu.  This command is described in Section 6.
5.5.2 What do the Parser and Semantic Checker Check?
The parser checks the syntax of AADL models including the syntactic constraints for the different component categories shown in the SAE AADL standard document in tabular form. In addition, name resolution is performed in that all references by name in the AADL text are resolved to object references in the AADL object model.  This includes classifier references in component implementation and subcomponent, port, parameter, access, and port group declarations, use of predeclared properties or properties defined in property sets in property associations, use of defined property types, consistent references to connections and subcomponent flow specifications in flow implementations and end-to-end flows, visibility of declarations in public and private parts of packages. Other checking includes consistent use of port direction in connections, consistent use of properties in property associations.  Semantic checking also includes type checking of property expressions and range checking of property values. Finally, semantic constraints specified in the AADL standard document, such as that data ports can only have one incoming connection and that constraint must be checked for each mode in a modal system, are being checked. 
In summary, all semantic checks specified in the AADL standard document with the following exceptions are checked:
    • Checking that constant property associations really are constant. 
    • The “in binding” semantics of property associations are not yet implemented.
    • Checking compatibility of Required_Access and Provided_Access property values on provided/required features
    • Checking that port groups whose Aggregate_Data_Port property value is true contain ports that all have the same direction. 
Two checks, required connections and checking for circular references among property values are provided as stand-alone analyses that can be separately invoked.  They are described in Section 9.1.
5.5.3 The AADL Model as XML File
The parser generates an AADL object model, which is persistently saved as an AADL XML file.  This file conforms to the XML schema for AADL and to the XMI meta model for AADL.  These two definitions of the content of an AADL XML file are being standardized as an Annex of the SAE AADL standard.  They have been developed using the Eclipse EMF meta modeling capability.  For more information about the AADL meta model see the draft XML/XMI specification of the AADL.
The XML file representation of AADL models has been designed to reflect the language closely and to be quite readable.  It also has been designed such that textual AADL can be reproduced—including comments.  As a result this AADL object model and XML representation reflects the declarative nature of AADL as a collection of packages and property sets that contain component classifier and port group type declarations, as well as property type and property name declarations.
The XML-based AADL object model can be examined and edited structurally with the AADL Object Model Editor. The XML representation can also be examined textually by opening the file with the “aaxl” extension in a text editor using the “Open with” command. Be sure to close the AADL Object Editor window on the XML file before attempting to open it in a text editor, otherwise Eclipse will not open the file a second time.
The example in Figure 14 shows a processor type declaration and a process type declaration with comments and property associations.  The XML XPath notation is used to represent references within and across XML files.
graphic
Figure 14: XML of an AADL specification.
Each AADL text file is translated into an equivalent AADL XML file. If an AADL text file is an AADL specification, with multiple component classifiers, packages, or property sets, the whole collection is stored as an AADL object model with an AadlSpec root object.  If an AADL text file is an AADL package, it is stored as an AADL object model with an AadlSpec root object with a single AadlPackage child. If an AADL text file is an AADL property set single property set, it is stored as an AADL object model with an AadlSpec root object with a single PropertySet child.