An Extensible Open Source AADL Tool Environment (OSATE)

Transcription

1 An Extensible Open Source AADL Tool Environment (OSATE) Release 1.0 May 23, 2005 The SEI AADL Team Software Engineering Institute 1

2 Table of Content An Extensible Open Source AADL Tool Environment (OSATE)... 1 Table of Content Introduction What s New in OSATE V Download and Installation Installation of OSATE Bundled with Eclipse Install into an existing Eclipse installation Use the Eclipse Installation/Update Manager Problems with the Installation Updating Your Installation Use of the AADL Tool Environment (OSATE) Starting Up OSATE for the First Time How to Manage Your AADL Models Overview of OSATE Projects AADL Models as Files Multi-file Support and AADL Namespaces Eclipse Projects and OSATE Team Support Creating and Editing AADL Models Predeclared AADL Properties Automatic Build with the AADL Builder Importing AADL Models into OSATE Synchronizing Eclipse/OSATE with the File System The AADL Text Editor Syntax/Semantics Checking of AADL Text Code Completion Text Hover Working With Textual AADL Models Semantic Checking and Translation to XML Reporting of Errors and Warnings What does the parser and semantic checker check? The AADL Model as XML File

3 6 The AADL Object Editor Viewing AADL Object Models Navigating AADL Object Models Editing in the AADL Object Editor Viewing the System Instance Hierarchy in the Declarative Model Creating and Working with AADL Instance Models Generating Textual AADL Analysis of Declarative AADL Models and AADL Instance Models Model Statistics Required Connection Checking Stream Miss Rate Checking Security Level Checking Safety Criticality Level Checking Flow Latency Analysis MetaH Generation Do It Yourself Problems and Errors OSATE Implementation Background Appendix A: Flow Latency Analysis Fully and Partially Specified Instance Models End-To-End Flow Latency Analysis on Instance Models End-To-End Flow Latency Analysis on Declarative Models Flow Implementation Latency Analysis on Declarative Models Example Models for Flow Analysis Appendix B Example Models

4 1 Introduction The Software Engineering Institute has developed an Open Source AADL Tool Environment (OSATE) as a set of plug-ins on top of the open source Eclipse platform ( The set of plug-ins provides a toolset for front-end processing of AADL models. AADL models can be maintained as textual AADL files or as XMLbased AADL model files. The set of plug-ins consists of: A syntax-sensitive text editor with syntax highlighting, popup help A parser and semantic checker for textual AADL with conversion into AADL XML and error reporting integrated with the text editor An AADL XML viewer and editor A syntax-sensitive AADL object model editor with drag-and-drop as well as undo capabilities, and an AADL properties viewer An AADL XML to textual AADL converter (AADL unparser) Multi-file support for both textual and XML-based AADL model files Auto-build support through an AADL nature to automatically update XML-based AADL model files after changes to textual AADL files and vice versa Team support through a version control system interface The OSATE front-end has been augmented with a set of additional plug-ins, including an AADL to MetaH converter, several analysis plug-ins for performing various architecture consistency checks, and a distributed resource allocation and scheduling analysis plug-in. A graphical AADL editing front-end based on the Eclipse Graphical Editing Framework (GEF) for graphically viewing and editing XML-based AADL models is in development by a student as USC. A second Eclipse-based graphical front-end for AADL is being developed by Airbus Industries. An analysis plug-in for fault modeling and reliability analysis for the draft Error Model Annex of AADL is being developed by Embry-Riddle University. The University of Pennsylvania has interfaced a process algebra with AADL and is completing an extension to AADL to support translation of AADL models into CHARON, and hybrid control system modeling language. 4

5 2 What s New in OSATE V 1.0 The following are updated and new capabilities in OSATE V1.0. Multi-file support for AADL models: AADL models can be split into separate files by storing each AADL package and property set into a separate file. For details see section Team support: AADL model files can be organized into projects. Projects can be managed by version control systems through the team support services of Eclipse. For details see section Auto-build: OSATE now manages updating of AADL XML files (with extension aaxl ) when AADL text files (with extension aadl ) are modified in the AADL Text Editor. Similarly, OSATE updates AADL text files when AADL XML files are modified in the AADL Object Editor (and in the future in the Graphical AADL Editor). Finally, OSATE automatically updates instance model files when the corresponding AADL text file or AADL XML file has changed. For details see section AADL Object Editor Navigation: This editor now has the ability to follow references in the object model. This allows you to navigate from subcomponents to their classifiers, from connections and flows to their source and destination, and from instance model objects to the declarative model counterparts they were derived from. Through navigation history the user can return to previously visited locations. For details see section 6.2. AADL Instance Models: AADL instance models are now created with a complete set of semantic connections for port connections, access connections, and for mode transition triggering by event ports, with end-to-end flow instances and flow specification instances, and modal information. Instance model-based property lookup is now fully supported, including modal property values. In particular, property values for semantic connections are retrieved from the appropriate connection declaration. Instantiation of high-level AADL models: OSATE now supports creation of instance models with connection instances and flow instances for models, whose component structure has not been elaborated down to the level of individual threads. This allows for early integration analysis of high-level model specifications for flow related analysis such as partition latency analysis, or specification based network load analysis. AADL Meta Model Implementation: OSATE V1.0 implements the AADL Meta Model as defined in the AADL Meta Model & XML/XMI Interchange Format Annex V0.9. This document has been included in the OSATE help system. Changes to the meta model include a new abstract class Classifier to be compatible with the UML profile, and the addition of a connectioncontext association for connection instances. For further details on Meta Model changes please see the Annex document. 5

6 Port groups and Semantic Connections: When port groups are involved in semantic connections those port groups are now unpacked into semantic connections for individual ports for each ultimate source and destination of a semantic connection. Updated Flow Latency Analysis plug-in: The flow latency analysis plug-in has been updated to handle delayed and immediate connections between periodic thread and to operate in instance models as well as declarative models. For details see section 10 (Appendix A). New Resource Management plug-in: We have added a ResourceManagement plug-in that supports priority inversion checking. This plug-in also interfaces with a Java-based implementation of Rate-Monotonic Analysis (RMA) algorithm to provide scheduling analysis of independently executing periodic threads. We have also developed an interface to a Java-based implementation of a constraintbased resource that allocates processor, memory, and bus resources to application systems utilizing a binpacking approach. This resource management implementation is part of the TimeWeaver embedded systems engineering framework developed at Carnegie Mellon University ( 2.cs.cmu.edu/~rtml/timeweaverweb/). If you are interested in further resource scheduling analyses, U. Penn has interfaced their Process Algebra toolset to perform analysis of AADL models and will make their work available to others (see AADL User Presentations at for details). OSATE Plug-in Development: The OSATE infrastructure for analysis plug-in development has been updated to support the multi-file capability of OSATE. A four part presentation series on OSATE Plug-in Development was given in January 2005 and is available on CD. A OSATE Plug-in Development Guide document is in development and a first draft is available as part of the OSATE help system or can be requested as printable document. Online Help: Now includes the JavaDoc of major OSATE functionality, the OSATE Plug-in Development Guide in its current draft form, and a description of the AADL meta model and XML/XMI interchange format. Several semantic checks have been added, in particular checks relating to modal systems. Bug fixes: A number of bugs have been fixed. A thank you to all who have reported problems to us. For a detailed list of bug fixes please see the OSATE pages at 6

7 3 Download and Installation OSATE is available as two Eclipse features. The first installable feature is a set of plugins representing the OSATE front-end. The second installable feature is a collection of analysis plug-ins that demonstrates the extensibility of OSATE and AADL. OSATE release 1.0 is supported under Eclipse Release 3.0.1/3.0.2 and the Eclipse Modeling Framework (EMF) Release 2.0.1/ Eclipse and OSATE run on a number of compute platforms including several versions of Windows, MacOS, and Linux for 32- bit and 64-bit hardware platforms (see for details). Eclipse Release 3.0.1/3.0.2 requires Java 2 Platform, Standard Edition (J2SE) Version 1.4 or higher. OSATE has been developed and tested with Version If OSATE is used as an AADL modeling tool the Java Runtime Environment (JRE) is sufficient. If OSATE is also used to develop new OSATE plug-ins the Java Software Development Kit (SDK) is necessary. The Java JRE or SDK can be found at the website java.sun.com under J2SE SDK. OSATE can be installed in one of three ways: 1. Download and install OSATE (the front-end and the analysis plug-ins) bundled with Eclipse and EMF as a complete installation in a single zip file from the download area of 2. Download and install Eclipse and EMF from the Eclipse website. Extend is new or an existing Eclipse installation with the installable feature containing the plug-ins of the OSATE front-end and an installable feature containing a set of architecture analysis plug-ins as two zip files from the download area of 3. Update your existing Eclipse/OSATE installation with the OSATE installable features from the OSATE update site using the Eclipse installation and update manager. The URL for the update site is We will describe each of the installation approaches in turn and then discuss setting up your workspaces in Eclipse/OSATE. Example AADL models are available at Installation of OSATE Bundled with Eclipse Download the OSATE bundled with Eclipse and EMF for your platform from This installation is available both as a Runtime environment for AADL modeling & analysis, and as an SDK for OSATE plug-in development. The zip file is called osate-1.0-rt-eclipse emf <os>- <date>.zip for the runtime version, where <os> is windows, macos, and linux. The OSATE SDK is named osate-1.0-sdk-eclipse emf <os>-<date>.zip. Install OSATE bundled with Eclipse by extracting the content of the downloaded zip file to a location of your choice on your hard disk. OSATE/Eclipse will be placed into a 7

8 folder called eclipse at the specified location. We refer to this folder as the installation root folder of your installation. This folder can be renamed. The installation of Eclipse and OSATE does not make any changes to an operating system registry. To add a shortcut to the executable, go to the installation root folder and find the eclipse.exe executable. You can create a shortcut to it and give it a name of your choice, e.g., osate-1.0. You can place this shortcut on your desktop, add it to your program menu, or add it to the quickstart toolbar. Note that you can have multiple Eclipse installations in the same machine. These can be installations of different releases of Eclipse, of different releases of OSATE, or the same release of OSATE with different experimental plug-ins. 3.2 Install into an existing Eclipse installation As stated previously, OSATE is implemented as a set of plug-ins to the Eclipse platform. Therefore, it can be added to a new or an existing Eclipse installation. You can download Eclipse Release 3.0.1/3.0.2 from the download area of The Platform Runtime Binary of Eclipse is sufficient for AADL modeling and analysis. The Eclipse SDK is necessary if you want to develop additional OSATE plug-ins. To install Eclipse, extract it from the downloaded zip file by specifying a location of your choice. It will be installed at the location into the installation root folder called eclipse. This folder can be renamed (after you also install EMF). EMF Release 2.0.1/2.0.2 is available from the Eclipse Tools Project area at The EMF&SDO runtime binaries are sufficient for AADL modeling and analysis. The SDK for EMF&SDO is necessary for OSATE plug-in development. The XSD component (included in the EMF All SDK) is necessary if an EMF meta model has to be developed for an AADL annex sublanguage. To install EMF, extract it from the downloaded zip file to the same location as Eclipse. Its content will also be placed in the installation root folder named eclipse. The OSATE front-end and the OSATE architecture analysis plug-ins are available as two installable features in form of two zip files from the download area of The OSATE front-end is called osate-frontend-1.0- <date>.zip. The analysis plug-in collection is called osate-plugins-1.0-<date>.zip. To install the two OSATE features, extract them from the respective zip file by specifying the installation root folder as location to extract to. This is the folder created through the installation of Eclipse, by default called eclipse. Add a shortcut to the executable, go to the installation root folder and find the eclipse.exe executable. You can create a shortcut to it and give it a name of your choice, e.g., osate You can place this shortcut on your desktop, add it to your program menu, or add it to the quickstart toolbar. 3.3 Use the Eclipse Installation/Update Manager Start your Eclipse and go to the menu entry Help/Software Updates/Find and Install. 8

9 Select Search for new features to install and click next. Select New remote site and add OSATE Update Site as name and as URL. Click Ok. Select OSATE-Frontend 1.0 by checking the box and click next. Continue through the dialog sequence until the OSATE front-end plug-ins are installed. Next, select OSATE-Plugins 1.0 by checking the box and click next. Continue through the dialog sequence until the OSATE analysis plug-ins are installed. 3.4 Problems with the Installation You can check to see the set of installed plug-ins as follows: 1. Go to the Help menu, About Eclipse Platform. 2. The dialog box should show the Eclipse icon and the OSATE icon. 3. You can find OSATE listed as a feature under feature details. You can also find all OSATE plug-ins listed under plug-in details. The EMF plug-ins and the OSATE plug-ins are recognized by Eclipse as features, i.e., a collection of plug-ins that make up an Eclipse application. You can disable and enable installed features using the Manage Configurations service found under Help / Software Updates. If you have an existing installation of Eclipse with your own or your company s plug-ins, try the OSATE plug-ins in a separate Eclipse installation or disable your company plugins to determine whether there are conflicts between the two sets of plug-ins. You may also try a clean reinstallation, but be sure you have kept your workspace outside the installation root folder (see How to Manage Your Eclipse/OSATE Workspaces in section 4.2). If you runt OSATE and you get out-of-memory errors, the default virtual memory allocation for your Java Virtual Machine (JVM) may be too small. You can change this 9

10 allocation by opening the Properties of the shortcut to the executable through its context menu. The context menu can be brought up by selecting the shortcut and then right clicking on it. In the Properties dialog box, select the shortcut panel. In the Target field add the following after eclipse.exe: -vmargs -Xms128M -Xmx512M. If all else fails, send us a note to tools@aadl.info. 3.5 Updating Your Installation You can update your installation of Eclipse, EMF, and OSATE by utilizing the Eclipse update manager. You can invoke it with the menu entry Help/Software Updates and then Find and install. Be sure you have included the OSATE update site for OSATE updates (see section 3.3) and the Eclipse update site for Eclipse and EMF updates. You can also update your installation by downloading the appropriate zip files and unzipping them into your installation (See Installing into an existing Eclipse Installation in section 3.2). Be sure to read section 4.2 on How to Manage Your Eclipse/OSATE Workspaces to facilitate reinstallation of Eclipse & OSATE without losing your projects, allowing for backup of your Eclipse/OSATE workspaces, and to manage your projects in the workspaces through a version control system. 10

11 4 Use of the AADL Tool Environment (OSATE) OSATE is implemented as an extension of the Eclipse platform. As a result, some of the basic functionality of the OSATE is that of Eclipse itself. This includes browsing, editing, management of files, team support through an interface with CVS or other version control systems, error/problem reporting, etc. The Eclipse online help facility provides a good introduction to the basics of Eclipse. It also contains this OSATE user manual and the AADL standard as reference manual in a browsable and searchable form. The Eclipse, OSATE, and AADL help is found under the Help menu as Help Content. In this guide we focus on describing functionality that is specific to the AADL plug-ins. 4.1 Starting Up OSATE for the First Time OSATE is invoked by double clicking on the shortcut for the executable, or on the Eclipse.exe icon in the installation root folder. When you start up Eclipse/OSATE for the first time you will be prompted to select a folder as your workspace. By default this will be a folder called workspace in the installation root folder of Eclipse/OSATE. You will want to change that to a folder you have created that is separate from the installation root folder or any of its subfolders. This workspace folder can be created anywhere on your hard disk with a name of your choice, e.g., AadlProject1WS. You can use the convention of placing the workspace folders in a folder called OSATE Workspaces. By keeping the workspace separate from the installation root folder area, you can delete the installation root folder for a clean re-installation without loosing your project work. Keeping the workspace separate also allows you to have the workspace backed up without backing up the installation itself. For more on OSATE workspaces see section 4.2. After OSATE comes up you may see a welcome panel. If you close this panel you will see the OSATE window divided into four areas. The top left is used by the Navigator. The Navigator allows you the browse the OSATE workspace and open files (called resources in Eclipse) by double clicking on them or by opening them through their context menu. The top right area is used by editors when files in the Navigator are opened. If multiple files are opened, their windows are shown in tabbed panels. An editor window can be placed next to another editor window by dragging it on its tab. The bottom left is used by the Outline view, a panel that shows an outline of the editor content. The bottom right is used to show a number of views in tabbed window panels. 11

12 Figure 1 OSATE Window Layout The following list of views is useful and can be activated if not already visible by going to the menu Window->Show view. Some of the views are found under Other. The Problems view: This view is opened by selecting Window-> Show View- >Problems. This view is used to report any errors, warnings, and status information that are attached to files through the Eclipse marker mechanism. OSATE uses these markers to report syntax and semantic problems in AADL models as well as results of executing analysis plug-ins. We have defined two AADL specific marker types as subclasses of Eclipse problem markers: AADL Text Marker to report problems on textual AADL files, and the AADL Object Model Marker to report problems on AADL model files in XML. Make sure these marker types are enabled in the Problem view Filter dialog, which can be invoked as shown. In the Filter dialog box make sure the two marker types are checked. You may also want to select On selected resource and its children. This will only show problem markers for the selected file, folder, or project and its children. 12

13 The AADL Property Values view: This view is opened by selecting Window- > Show View->Other and then selecting Other->AADL Property values. This view displays AADL property values for elements of your AADL object model when viewing in the AADL Object Model editor. The Properties view: This view is opened by selecting Window-> Show View- >Properties, or by selecting Window-> Show View->Other and then selecting Basic->Properties. This view displays and allows you to edit attributes and references of the elements of your AADL object model. For more detail see AADL Object Editor. The Tasks view: This view is opened by selecting Window-> Show View- >Tasks, or by selecting Window-> Show View->Other and then selecting Basic->Tasks. This view maintains a list of tasks to be done. The context menu of this view allows you to add and manage the status of tasks. When developing OSATE plug-ins this view also displays a list of to-do tasks that are recorded in the plug-in Java code as comments starting with the word TODO. The Progress view: This view is opened by selecting Window-> Show View-> Progress, or by selecting Window-> Show View->Other and then selecting Basic-> Progress. This view shows the progress during an automatic build (see also section 4.2.7). 13

14 4.2 How to Manage Your AADL Models When you work in Eclipse/OSATE you will access files in your file system through workspaces. You can set up multiple workspaces, but you can only work in one workspace at a time. A command to switch between workspaces is available under the File menu. A workspace can be any folder in your file system. The workspace is organized into projects. Each project can be separately version controlled. Projects can be substructured through folders. In previous versions of OSATE, each file contained a complete AADL specification. Multiple AADL specification files could be kept in the same workspace, project, or folder. One AADL specification file could not reference declarations in another AADL specification file. This capability is still available in OSATE V1.0. OSATE V1.0 also provides support for modeling of large system through separately developed AADL models and for teams of people developing such models. OSATE makes use of projects the Eclipse workspace and projects to allow large AADL models to be split into multiple files and to support the team support services of Eclipse that interface with version control systems. OSATE V1.0 also provides an automatic build capability that maintains consistency between AADL text files and AADL XML files by regenerating one when the other is changed by the modeler. It does so by propagating changes to AADL packages and property sets to other AADL files that potentially are affected. Furthermore, it automatically regenerates any AADL instance model that is potentially affected by changes to AADL models Overview of OSATE Projects This section summarizes the most relevant points about how OSATE handles model files that are described in more detail in the following sections. AADL models, in both textual and object model form, are stored in Eclipse projects. The preferred modeling style in OSATE 1.0 is to store each AADL package and property set in a separate file. An AADL specification, however, can be split across multiple files for ease of organization and team management. Because Eclipse uses the project as the unit of version control, OSATE searches all open AADL projects in the same workspace when looking for named classifiers, packages, property sets, etc. This allows particularly complex models to be split across projects, or standard property sets and packages to be stored in their own projects, facilitating separate versioning of components, packages, and property sets AADL Projects An AADL project can be created through the AADL Project wizard by invoking New- >Project in the File menu or the context menu of the Navigator, and then selecting Aadl Wizards->Aadl Project. The standard organization of an AADL project is for it to have two top-level directories aadl and aaxl, which store textual and object models, respectively; see Figure 2. In general, there is a one-to-one correspondence 14

15 between the contents of the two directories, and they have a parallel structure. AADL instance models, however, are only stored as object models in the aaxl directory. There are two special directories packages and propertysets in the aadl and aaxl directories. It is expected that files containing package declarations be kept in the packages folder, and that files containing property set declarations be kept in the propertysets folder. A file that contains a package must have the same name as the package except that the :: is replaced by either _, -, or.. The same replacement character must be used within a file name, but different files may use different replacements. A file that contains a property set must have the same name as the property set. AADL specification files can be organized in arbitrary subfolders Support for Pre-OSATE1.0 Specification Files Prior to OSATE 1.0, a single file was expected to contain a complete AADL specification. That is all classifiers, packages, and property sets relevant to the specification needed to be declared in a single monolithic file. This is no longer the preferred way of managing specifications, but to ease the transition to OSATE 1.0, this format is still supported, although it may not be supported in future versions of OSATE. When a specification contains a package or a property set, they are said to be locally declared. A package or property set declared in its own file in the packages or propertysets folder is said to globally declared. Members of a globally declared package or property set may be referenced by any other specification in the workspace. Members of a locally declared package or property set may only be referenced from within the same file, thus the local appellation. In addition, a local package or property set shadows any global package or property set with the same name AADL Models as Files Note: In Eclipse files are referred to as resources. OSATE understands two file extensions as AADL file types: 1. aadl: textual AADL models; Files with this extension can be edited by a generic text editor or by the AADL text editor 2. aaxl: AADL object models in XML; these AADL object models represent the AADL models corresponding to the textual AADL model (declarative AADL models) or AADL instance models (instantiations of systems see section 6.2). Files with this extension can be edited as XML files by a generic text editor, or as an AADL object model by the AADL Object Editor. The graphical AADL editor will also manipulate AADL object models in XML and store layout information in a separate XML-based layout file. The following naming conventions are expected by OSATE: A file that contains an AADL specification can be given any legal AADL name with the appropriate file extension. This name will be used as the name of the AadlSpec object and in the XPATH cross references in AADL XML files. 15

16 A file that contains a single property set is expected to have the same name as the property set with the appropriate file extension. The Aadl builder uses the property set name to find the file containing the property set. A file that contains a single AADL package is expected to have the same name as the package with the appropriate file extension. The :: in the Aadl package name are expected to be replaced by all _ or by all - or by all.. The Aadl builder uses the AADL package name to find the file containing the AADL package. When an AADL XML file generated by the AADL builder it will use _ as the replacement character in the file name. A file that contains an AADL instance model will only be stored as an AADL XML file. Its name is automatically generated by OSATE when an AADL model is instantiated (see section 6.4). The file name consists of the AADL specification name or package name containing the system implementation being instantiated, the system type name and the word Instance, separated by the character _. There is a one-to-one correspondence between AADL text files and AADL model XML files. In other words, each AADL text file is converted into a single AADL XML file Multi-file Support and AADL Namespaces In AADL packages and property sets reside in a global namespace. This means that components and properties declared in them can be referenced by other packages and property sets. In addition, each AADL specification has an anonymous namespace. Items declared in an AADL specification are accessible only within that AADL specification. OSATE implements the multi-file support with global and anonymous namespaces as follows. An Eclipse workspace represents the global namespace. AADL packages and property sets that are stored as one package or property set per file are known in the global namespace. AADL packages and property sets that are stored together with other packages, property sets, or component declarations in a file are considered an AADL specification and are accessible only within that file. If a component classifier in a package or a property in a property set is referenced by another item in an AADL specification the package or property set is first searched for in the anonymous workspace of the AADL specification, then searched for in the global namespace. This provides backward compatibility to previous releases of OSATE. Complete AADL models in a single file such as those from versions of OSATE previous to Version 1.0 can still be maintained in the same Eclipse workspace as separate AADL models. At the same time, individual AADL packages and property sets can be moved into separate files for reuse across multiple AADL models (AADL specifications) with packages and property sets in an AADL specification overriding the globally accessible packages and property sets Eclipse Projects and OSATE Team Support Eclipse team support is provided through Eclipse projects. Eclipse projects are checked into and out of version control repositories such as CVS. Once checked out projects can 16

17 be synchronized with the repository. A CVS Repository Exploring perspective allows you to specify a connection to version control repositories and to navigate the repository content. This perspective can be opened through Window->Open perspective->cvs Repository Exploring. Team synchronization is supported through a set of commands available in the context menu of the Navigator view panel and through a Team Synchronizing perspective. For more details on how to set up team support see the Eclipse online help. OSATE uses the Eclipse project concept to allow large scale AADL models to be divided into different collections of AADL packages, e.g., one per major subsystem, and maintained in separate projects in the same workspace. These projects can then be managed by the team support services of Eclipse as outlined above. The global AADL namespace spans all projects in a workspace. An AADL project can be created through the AADL Project wizard by invoking New->Project in the File menu or the context menu of the Navigator, and then selecting Aadl Wizards->Aadl Project. After the project name is supplied, the wizard will automatically create the project and folders to organize the files within the project, and will associate an automatic AADL builder with the project (for more details on the automatic builder see section 4.2.7). An AADL project is organized as follows. AADL text files are kept in a text folder and AADL XML files are kept in a model folder. (This is similar to the Eclipse Java IDE keeping Java text files in a folder called src and the generated code in a folder called bin.) By default these folders are called aadl and aaxl. The name/location of these folders is recorded as a project property in a file called.aadlsettings in the project folder. These properties can be changed by selecting the project in the Navigator and invoking Properties in the context menu and selecting Aadl Build Path. If the names of these folders are changed the Aadl Build Path properties of the project must be updated. In addition, two folders named packages and propertysets are created in the AADL text file folder and the AADL XML file folder. These folders should not be renamed. The folder structure populated with some files is shown in Figure 2. 17

18 Figure 2 AADL Project Structure Files containing AADL specifications as text of XML should be placed in the AADL text file folder or AADL XML file folder respectively. (Note that the two folder locations may point to the same folder see backward compatibility below in this section). An AADL package stored as a separate file should be placed in the packages subfolder, while an AADL property set stored as separate file should be placed in the propertysets sub-folder. Individual package and property set files may also be placed in the AADL text file folder or AADL XML file folder directly, but the automatic builder will be less efficient in updating files (see section for details on automatic build). Files in the propertysets and in the packages folder may not be organized into subfolders. OSATE 1.0 provides backward compatibility to AADL models maintained in projects created under previous versions of OSATE, or created without the AADL project wizard. This is achieved by allowing the AADL text file folder and the AADL XML file folder to be the same folder, i.e., the project folder. If OSATE 1.0 encounters a project without the Aadl Build Path property settings, it will automatically create those settings. It does so by looking for folders called aadl and aaxl, or src and bin, or src and output in the project folder and set the Aadl Build Path property settings appropriately. If no such folders are encountered the project folder is set for both the AADL text file folder and the AADL XML file folder. This capability, together with the ability to keep multiple AADL specifications as separate files in the same workspace or project, allows OSATE 1.0 to operate in existing AADL model workspaces. 18

19 4.2.5 Creating and Editing AADL Models AADL models can be maintained as AADL text files or as AADL XML files. These AADL files can be created within OSATE projects in the AADL text file folder or AADL XML file folder. You will have to have created a project in the workspace ( File- >New->Project ) before creating files. The files are created as follows: Textual AADL files are created by selecting the folder in which to create the file and by selecting New->File in the File menu or in the context menu. Specify a filename with the extension aadl. The file is created and automatically opened in the AADL text editor. You can then type in the model or copy and paste it from an existing file and save the content. For details on using the AADL Text Editor see section 5. XML-based AADL files are created with the AADL Model Creation wizard. This wizard is invoked by selecting New->Other in the File menu or in the context menu. In the dialog box for selecting a wizard, select Aadl Wizards- >Aadl Model. The file is created and automatically opened in the AADL Object Editor. You can now use the AADL Object Editor to create elements of the model and save the content. For details on using the AADL Object Editor see section 6. Existing AADL text files or AADL XML files can be opened in the respective editor by double clicking on the file in the Navigator. This is the editor the file was opened in last. By default AADL text files are opened in the AADL Text Editor, and ADL XML file in the AADL Object Editor. The files can also be opened with a specific editor through the context menu on the file by selecting Open with-> and the select the desired editor. For example, this allows AADL XML files to be opened as text files, if you want to examine the XML representation. Note that Eclipse allows you to open a file on only one editor at a time. This means, you have to close the AADL Object Editor in an AADL XML file before you can open that file in a text editor to examine the XML as text. AADL XML files can also be created by converting an AADL text file. This is done by invoking AADL Menu->Convert to XML on a selected file in the main menu bar, by clicking on the toolbar button labeled Produce XML AADL, or by selecting AADL- >Convert to XML in the context menu. 19

20 AADL text files can also be created by converting an AADL XML file into textual AADL. This is done by invoking AADL Menu->Convert to Text on a selected file in the main menu bar, by clicking on the toolbar button labeled Produce textual AADL. When an AADL text file is saved and the automatic builder is enabled, the file is automatically checked for syntax and semantics and converted into XML. Additional analyses can be invoked explicitly on AADL XML files (see section 7). Be sure to have the Problem view open in order to see any messages from the editors and analysis/generation plug-ins Predeclared AADL Properties The AADL standard defines a number of predeclared properties in two property sets called Aadl_Properties and Aadl_Project. Those property sets are automatically provided as part of the OSATE installation, i.e., they do not have to be included explicitly in the workspace. These property sets are kept in the edu.cmu.sei.osate.workspace plugin in the properties folder both as AADL text files and as AADL XML files. The location of the file to be used is specified in the Window->Preferences dialog under OSATE preferences. These preferences can be set separately for each workspace. If the AADL XML files are specified, then the XML file is loaded and references are resolved. If the AADL text files are specified, then the AADL text files are converted into XML before references are resolved, but the XML representation is not saved into the file system. In other words, the AADL XML file in the installation is is not overwritten. The user can place a copy of the Aadl_Project property set with project-specific changes as allowed by the standard in a separate file and place the file in the installation area or the workspace. By changing the preferences to point to this file location, this version of the property set will be processed instead of the installation version Automatic Build with the AADL Builder OSATE has an AADL builder that maintains consistency between AADL text files and AADL XML files, including AADL instance files. This builder is implemented through the Eclipse builder API. The AADL builder can be enabled for a project by enabling the AADL Nature. This is done by selecting a project, bringing up the context menu, and selecting Enable AADL Nature. If the AADL nature is enabled the nature can be removed instead with Remove AADL Nature. When the AADL nature is enabled the project icon has a decorator in the form of the letter A. When a project is created with New AADL Project wizard, the AADL Nature is enabled by default. 20

21 Figure 3 Enabling and Disabling the AADL Builder When the builder is enabled the build command under the Project menu of Eclipse invoke the AADL builder (see Figure 4). Figure 4 Build Commands Automatic build can be enabled and disabled by selecting the Build Automatically command. Automatic build is invoked any time files have changed. The builder then regenerated all derived files that are potentially affected by the change. The Clean command results in a complete rebuild of the workspace or project as specified in a subsequent dialog window. The clean command causes all derived files to be regenerated and any derived files for which the source does not exist to be deleted. If automatic build is not enabled (no check mark next to the menu command), then changes to the files are tracked by Eclipse but the builder is not automatically invoked. In that case the Build All and Build Project commands are enabled in the context menu and can be invoked to process all changes that occurred since the last invocation of a build. 21

22 The AADL builder considers a file that has been changed in an editor as the original file when it is saved from within that editor. If the AADL text file has been edited and saved, it is the original file. If the AADL XML file as been edited (by the AADL Object editor or in the future by the Graphical Editor) it is considered to be the original file. If the AADL text is the original file, then the AADL XML file is regenerated from the modified AADL text file. If the AADL XML file is the original file, then the AADL text file is regenerated from the modified AADL XML file. AADL instance model files are always considered derived from AADL XML files. This means they are regenerated anytime the AADL XML files they are derived from have been updated due to edits or regeneration. Currently analysis plug-ins invoked on instance models or declarative models are not tracked, thus, not automatically applied to the regenerated XML files. If an AADL file that contains an AADL specification has been modified, then only that file is processed by the builder, since other AADL files cannot refer to items in this file. This is due to the fact that the declared component classifiers are part of the anonymous namespace of an AADL specification, and that AADL packages and property sets not stored in individually in separate files are not treated as residing in the global namespace. If an AADL package or property set in the global namespace is modified, then all AADL files in the workspace can potentially be affected and all are rebuilt Importing AADL Models into OSATE AADL models may have been created outside OSATE. For example, we have provided a number of AADL model examples in textual form that can be downloaded from Such files may be made available as a collection of files, as an OSATE or Eclipse project in a zip file. First, we describe how AADL models can be imported as files, then we describe how an Eclipse or OSATE project can be imported. AADL models can be brought into an OSATE workspace as files in one of several ways: You can create an empty AADL text file in the workspace as described in section 4.2.5, open the existing file in a text editor outside OSATE, and copy/paste the content into the AADL text file in OSATE. Files can be imported into a project in the workspace. This is done by selecting Import in the File menu and then selecting from File System in the dialog box. The files being imported are copied from the file system location into the workspace location. 22

23 If you already have a project in the workspace, you can copy the file into the project folder in the workspace (or one of its sub-folders) from outside Eclipse, i.e., with your regular file system navigator. Then, you invoke File->Refresh (or Refresh in the context menu) on the project or folder in the Eclipse Navigator, and the file will become visible in Eclipse. You can create a new file in a project in the workspace ( File/New/File ) and create a link to an existing file anywhere in the file system by clicking on Advanced in the dialog and selecting Link to file in file system. In this case the file is kept in its original location and updated from within Eclipse when editing the file in Eclipse. AADL model files may have been made available to you as an OSATE project in a zip file. In this case, unzip the file into an OSATE workspace from outside Eclipse, then from within Eclipse/OSATE invoke Import->Existing Project into Workspace and point to the folder in the OSATE workspace folder that represents the project you just unzipped Synchronizing Eclipse/OSATE with the File System This capability is part of the Eclipse functionality. You may have edited a file that is in an Eclipse workspace from outside Eclipse either with an editor or by (re-)generating the file with a tool outside Eclipse. Eclipse will detect that changes have been made externally. You will have to perform a Refresh (in the File menu or Eclipse Navigator context menu) in the Eclipse Navigator in order for Eclipse to update its state information of the file system. You can also set an option to automatically perform a refresh if changes happen to the file system. You can do so in the Workbench dialog pane of the Help/Preferences dialog. 23

24 5 The AADL Text Editor We would like to thank Ramón Jiménez of University of York for making these enhancements to the AADL Text Editor of OSATE. The AADL Text Editor is based on the example Java Text Editor that is made available as part of Eclipse. The contributions to the AADL Text Editor comprise four main new features, namely: Syntax and semantic checking on save: Checking the syntax and semantics of the AADL text in the editor by parsing it and reporting errors Code completion: assistive support in writing AADL specifications by providing choices to complete declarations Text hover: assistive support in writing or reading AADL specifications by providing additional information over declaration elements These features are now explained in greater detail Syntax/Semantics Checking of AADL Text Making use of the AADL parser, an in-memory AADL model is kept for each textual AADL specification being edited. The maintenance of this model is tied to the editor's lifecycle methods, i.e. opening, saving, saving as, and reverting to the saved version of an AADL specification. Any detected errors and warnings are reported in the Eclipse Problem view. The model is used by the rest of the assistive features of the text editor Code Completion Making use of Eclipse's code completion mechanism, the AADL editor provides completion proposals under the following contexts: When pressing 'Ctrl'+'Space': the editor computes possible completions according to the text fragment immediately before the position where code completion has been triggered Proposals are intended to help the user in writing AADL specifications. Currently, the editor provides the following proposals for the indicated contexts: Reserved words: the editor can suggest categories, keywords, constants and types which match the prefix typed by the user. A comprehensive list of reserved words is proposed; a subset of the reserved words is automatically calculated as the user types initial letters. At this time the text editor does not take into account the reserved word syntax rule in order to subset the proposal. If the user navigates between proposals using the ' up' and 'down' arrow keys, an additional description is provided for each proposal. This usually takes the form of an AADL-like fragment detailing the model element the proposal suggests, or an arbitrary fragment of the AADL specification in the case of reserved words proposals (see below). 24

25 5.1.3 Text Hover By resting the mouse for a few seconds over a portion of the specification's text, the editor's text hovering feature is activated. This feature, also provided by Eclipse, can yield the following information depending on the hovered element: If the hovered element is a keyword, it is looked up in a dictionary-like structure. This structure, based on an extensible XML file, is initially loaded with descriptions for all 70 AADL reserved words, taken from the AADL draft standard version The XML file includes a reference to the standard section and line number(s) the description is taken from, to ease incremental updating of the file 5.2 Working With Textual AADL Models AADL text files have the aadl extension and an icon containing a curly bracket and the letter A. AADL text files can be edited by double clicking on the file name in the Navigator view of Eclipse. This opens the file in the editor window, by default, with the AADL text editor. You can also open the file through the popup menu by right clicking on the selected file and selecting one of the editors under Open with... This can be a regular text editor or the AADL text editor. The selected editor becomes the default the editor next time the file is opened by double clicking. If the file is already open and the Open with command is invoked, the file remains open with the original editor. Eclipse ensures that only one editor at a time has a file open for modification. As you edit textual AADL the editor will process the AADL model, report any syntactic errors and provide basic editing capabilities as well as the new features described above. 25

26 The AADL text editor has an Outline view (shown on the bottom left in the figure above). This view shows the top-level component type, component implementation, the component type and implementation declarations in packages, and the property set declarations. Selection in the outline view results in navigating the text editor to that construct. If the Outline view is not visible, you can open it through Windows, Show view and select Outline in the displayed menu or find it in Others -> Basic. The illustration also shows code completion in the example offering reserved words and hovering presenting context help on the selected reserved word. The Problems view shows syntax errors that are detected by the text editor through automatic parsing. When one of the error messages is double clicked the text editor navigates to the line that is in error. 5.3 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, if the AADL Nature the AADL builder is enabled and automatic build is activated (see section 4.2.7). 26

27 The parser and semantic checker are invoked when the user selects the AADL text file in the Eclipse Navigator and invokes the Convert to XML command from the menu or via tool bar button Reporting of Errors and Warnings Any errors, warnings, and information will be reported in the Problems view. This view can be opened by going to Window and Show View and select Problems. If Problems is not visible in the set, select Others and find it under Basic. Double clicking on one of the errors 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. The reported errors shown in the Problems view can be filtered in a number of ways to limit the set shown at any time. One useful filter constraint is to show only the errors of the selected file ( On selected resource only ). Make sure the Aadl Model Object Marker and the Aadl Text Marker are enabled with a checkmark What does 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 endto-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 27

28 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 AADLD 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 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. The example below shows a system type declaration with flow specification and feature declarations. The XML XPath notation is used to represent references within and across XML files. 28

29 AADL models can be stored in multiple files as discussed in section 0. The way AADL models are split into separate text files determines how they are stored as XML files. In other words, each AADL text file is translated into an equivalent AADL XML file. If an AADL text file contains 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 contains a single AADL package, it is stored as an AADL object model with an AadlPackage as root object. If an AADL text file contains a single property set, it is stored as an AADL object model with an PropertySet as root object. 29

30 6 The AADL Object Editor The AADL Object Editor can be invoked in one of two ways: Double click on an existing resource with the aaxl extension. These resources (aka. Files) are also represented by the Aqua colored Aadl icon as shown below. Invoke the Model Creation Wizard for a Aadl Model by invoking New and Other.. (see section 4.2.5). 6.1 Viewing AADL Object Models Figure 5 The AADL Object Editor Views When opened the AADL Object Editor has the following views and edit panes as shown in Figure 5: An Outline view that shows the set of component classifier, port group type, package, annex library, and property sets declarations in a declarative library view. Selection of an element in this view results in change of the current selection in the edit pane. This view is shown at the bottom left in the figure below. 30

31 The edit window with two tabbed edit panes. The first edit pane (labeled Library ) shows the AADL object model in the declarative library view structure. The second edit pane (labeled Instance ) shows the AADL object model in a system instance view. The edit window allows you to navigate and edit the structure of the AADL object model. The edit window is shown on the top right. A Properties view that shows attributes of a selected AADL model object. This view allows the user to model object properties such as port direction, as well as references to other AADL model objects, such as a reference from a subcomponent to its classifier. The Properties view allows you to change attributes and references of the object model. The properties view is shown at the bottom right. An AADL property values view that shows the values of AADL properties associated with a selected AADL model object. This view can be opened by selecting Window, Show view, Other.., Other->Aadl Property View. Note: Tabbed views can be opened into separate windows by pulling the tab of the view to an appropriate location. If the icon shows stacked pages when the mouse is released the window is turned into a tabbed view. If the icon shows an arrow the window is opened in a separate window pane. This is Eclipse platform functionality. 6.2 Navigating AADL Object Models The AADL Object Editor is used to view and edit both declarative AADL models and AADL instance models. The declarative AADL models are collections of component type and implementation declarations, AADL package declarations containing type and implementation declarations, and property set declarations. These declarative models can be expressed in textual AADL, stored as AADL text files (see section 5.2), and converted to AADL XML files (see section 5.3). They can also be created in the AADL Object Editor, stored as AADL XML files (see section 6), and converted into textual AADL (see section 6.6). AADL instance models are instantiations of a system implementation to represent a system instance, whose application software is to be bound to the execution platform. AADL instance models are maintained as AADL XML files (see section 6.5). The user can browse and navigate an AADL object model in several ways: 31

32 The user can select a component classifier in the Outline view. The focus of the Edit pane is moved to the selected item. The user can navigate the hierarchical structure in the Edit pane itself. The hierarchy view can be opened and collapsed by clicking on the + and - symbols on the left hand side. The user can navigate to the location in an AADL object model, for which an error, warning, or information marker is displayed in the Problem view. Double-clicking on the message in the Problem view will change the focus of the editor to that location (and open the editor if necessary). The user can navigate by following references associated with a selected object in the AADL object model. This is done through the context menu or Aadl Editor menu. These navigation commands are useful when tracking down the source of error and warning messages. The command Goto Source/Classifier moves the editor focus to the source point of a connection or a flow specification, or to the classifier of a subcomponent or feature. The command Goto Destination/Declaration moves the editor focus to the destination point of a connection or a flow specification, or to the declaration in the declarative model that an instance model object was derived from. The user can navigate by making use of the edit history by moving back and forth with the Back and Forward commands in the Navigate menu or the corresponding toolbar buttons with the yellow arrow point to the left and to the right. 6.3 Editing in the AADL Object Editor The AADL Object Editor supports syntax-sensitive editing of the AADL object model. You can create new AADL model objects by selecting an element in the Outline view or in the edit pane and right-clicking for a context menu. This menu will contain submenus for New child and New sibling. The same menu entries are available in the menu bar under Aadl Editor. These submenus are syntax-sensitive in that only syntactically legal objects can be added to the AADL model. An example context menu is shown in the figure to the right. The AADL Object Editor supports cut/copy and paste, drag and drop, as well as an edit history with undo capability. Drag and drop can be used when organizing component classifier declarations into packages. You create the package with appropriate public and private sections. You then select one or more component types and component implementations and drag then onto the public or private section of the 32

33 package, i.e., a place for which these AADL model objects are syntactically legal. The figure below shows the selected component implementations before the drag-and-drop on the left and after the drop onto the Aadl Public object on the right. AADL models can be further edited through the Properties view. This view provides access to attributes and relations (reference associations) of AADL model objects. These attributes include the name of the model object, direction of port. Relations include references to component classifiers for subcomponents and ports, references to ports in connections, etc. Those references can be filled in by popup menu, with the menu selection limiting the choices that adhere to the syntax and name scoping rules of AADL in the case of the figure below Data classifiers. 6.4 Viewing the System Instance Hierarchy in the Declarative Model Note, a more effective way of navigating a system instance is to create an AADL instance model by instantiating a system implementation and opening it in the AADL Object Editor. Creation and editing of AADL instance models is described in section 6.5. The AADL Object Editor allows you to view the system instance hierarchy through the declarative AADL model. When you have a declarative AADL model open, select a system implementation in the Outline view as the root of your system instance of interest. Then switch to the view tab of the Edit pane from Library to Instance as 33

34 shown in Figure 6. Typically you will want to select a component implementation that represents the top-level element of a system modeled in AADL. The content of the selected element is shown in the edit pane. In case of subcomponents can be expanded into the subcomponents contained in the component implementation referenced by the subcomponent. These subcomponent nestings can be expanded recursively. Figure 6 A System Instance View of the Declarative AADL Model 6.5 Creating and Working with AADL Instance Models An AADL instance model represents a system instance as described in the AADL standard document. An AADL instance model can be generated from a declarative AADL model by specifying a system implementation as the root of the system instance. This is done by selecting a system implementation in the AADL Object Editor and by invoking the Instantiate a system implementation command in the Aadl Menu or through the toolbar button as shown in Figure 7. This results in an AADL instance model XML file being created. The file name of this file will consist of the name of the original file, the name of the root system type, and Instance separated by _ (see highlighted file name in the Navigator in Figure 7). 34

35 Figure 7 Creating an AADL Instance Model The AADL instance model consists of a hierarchy of component instance objects that represent the system hierarchy and saves this instance model as a separate XML file. The instance objects refer to the appropriate model objects in the declarative model they are derived from. This instance model includes the component instances, feature instances, mode and mode transition instances, semantic connections in form of port connection instances, access connection instances, mode transition connection instances, as well as flow specification and end-to-end flow instances, and locally cached property values for all properties retrieved from the corresponding object model of the Aadl specification. Finally, for modal system instances all possible System Operation Modes, i.e., possible mode combinations of modal components, are generated and included in the AADL instance model. Figure 8 Viewing an Instance Model & Its Properties 35

36 The instance model can be opened and examined with the Aadl Object Model Editor. In Figure 8 the Edit pane shows a system component with its port and flow spec instances, as well as an end-to-end flow instance and port connection instances of the enclosing component instance. The AADL properties can be viewed in the AADL Property Values view as shown on the bottom right of Figure Generating Textual AADL The AADL Tool Environment includes a generator of textual AADL from AADL object models. In other words, this is an AADL XML to textual AADL converter for declarative AADL models. AADL text files can be produced automatically or manually. The AADL builder can be used to automatically update a textual AADL file when an AADL object model is modified in the AADL Object Editor and saved as an XML file (see section 4.2.7). AADL text files can also be generated by explicitly invoking a command in three ways when an AADL XML file is selected in the Navigator or opened in the AADL Object Editor: Select Aadl Menu-> Convert to AADL Text. Select the Convert from XML to Aadl Text button in the toolbar. This button has an icon with a curly bracket and the letter A. Select AADL-> Convert to AADL Text in the Navigator context menu. The user is prompted for a file name and a folder to place the file in. The file name should have the extension aadl. The user can select any location within the current Eclipse workspace. 36

37 7 Analysis of Declarative AADL Models and AADL Instance Models OSATE includes several plug-ins beyond those that check the basic semantics of AADL models. These plug-ins are available for execution in the tool bar and in the Analysis Menu. They are only enabled if the appropriate resource or Aadl Model Object is selected. Errors from these plug-ins are reported through AadlObjectMarkers that are shown in the Problem view and/or reported through a dialog box. The markers are hyperlinked to the relevant objects in the Aadl object model. Thus, by double clicking on a message the Aadl object editor makes that object its current selection. The plug-ins which are included in this release are described below. Several AADL models which demonstrate the plug-ins functionality are available for download from A description of the models and the application of analyses to them is included in Appendix B. The detailed algorithm used in the flow latency analysis plug-in is described in Appendix A. 7.1 Model Statistics Figure 9 Reporting Model Statistics on an Instance Model 37