![]() ![]() |
||||
|
||||
Parsing and semantic checking of textual AADL files and generation of an AADL MXL file can
be done in two ways:
|
||||
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. |
||||
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:
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. |
||||
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.
![]() 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. |
||||