An Extensible Open Source AADL Tool Environment (OSATE)

Transcription

1 An Extensible Open Source AADL Tool Environment (OSATE) Release Oct 5, 2004 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 Installation Complete OSATE Install 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) Invocation of OSATE/Eclipse AADL Model Files How to Manage Your Eclipse/OSATE Workspaces Import and Export to the File System Synchronizing with the File System Using the Tools What s New in OSATE What s Coming Significant Changes Since OSATE Important Bug Fixes and Changes Changes to the Meta-Model and XML Representation Semantic Checking Significant Changes Since OSATE Alpha Release Features of the AADL Text Editor Syntax/Semantics Checking of AADL Text Code Completion Text Hover Code Folding Working With Textual AADL Models Semantic Checking and Translation to XML

3 5.3.1 What does the parser and semantic checker check? Error! Bookmark not defined The AADL XML Document The AADL Object Editor Operating the Library Hierarchy and System Instance Hierarchy Editing in the AADL Object Editor Generating Textual AADL Additional OSATE Plug-ins Required Connection Checking Stream Miss Rate Checking Security Level Checking Flow Latency Analysis Aadl Model Instantiation MetaH Generation Do It Yourself Problems and Errors OSATE Implementation Background

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 initial set of plug-ins provides a toolset for front-end processing of AADL models. The initial 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 of 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) Additional plug-ins to OSATE, including AADL to MetaH conversion, and several example analysis plug-ins performing various architecture consistency checks. A graphical AADL editor based on the Eclipse Graphical Editing Framework (GEF) is in development as an additional front-end plug-in. 4

5 2 Installation OSATE is available as a set of plug-ins to the Eclipse platform packaged ass an installable feature. OSATE release is supported under Eclipse Release 3.0 or and EMF Release The Eclipse-based AADL tool environment runs on a number of compute platforms including Windows, MacOS, Linux. The descriptions in this document are based on the Windows installation. Eclipse Release 3.0/3.0.1 requires Java JDK1.4 or higher. Eclipse can be installed in one of three ways: 1. Download Eclipse, EMF, and OSATE as a complete installation in a single zip file from the download page of 2. Download the OSATE plug-ins as a zip file from the download page of and install into your existing Eclipse 3.0/3.0.1 and EMF installation. 3. Update your existing Eclipse 3.0/3.0.1 and EMF installation with the OSATE plug-ins from the OSATE update site using the Eclipse installation and update manager. 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 Complete OSATE Install Download the complete installation for your platform from We have configured complete installations for Windows, Linux, and the Mac. Install Eclipse/EMF/OSATE by unzipping the downloaded installation zip file anywhere onto your disk. Eclipse/EMF/OSATE will be placed into a folder called eclipse, which we refer to as the installation root folder of your Eclipse installation. Go to the installation root folder and find the eclipse.exe executable. You can make a shortcut to it on your desktop and add it to your program menu or quickstart bar. You can rename the installation root folder, if you desire to do so. Note that you can have multiple Eclipse installations in the same machine. These can be installations of different releases of Eclipse. The Eclipse installation does not make any changes to an operating system registry. 2.2 Install into an existing Eclipse installation Download and install Eclipse Release from and EMF Release from if you do not already have an existing installation of Eclipse Release 3.0 or and EMF Release (or EMF Maintenance Build M used in the beta release of OSATE or newer). The runtime binaries are sufficient, but the SDK works as well. 5

6 Download the OSATE plug-ins release as zip file and unzip it into your Eclipse installation root folder, typically a folder called eclipse. 2.3 Use the Eclipse Installation/Update Manager Start your Eclipse and go to the menu entry Help/Software Updates/Find and Install. 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 by checking the box and click next. Continue through the dialog sequence until the OSATE plug-ins are installed. 2.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 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. 6

7 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 below). If all else fails send us a note to tools@aadl.info. 2.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 above) 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 above). Be sure to read the section on How to Manage Your Eclipse/OSATE Workspaces to facilitate reinstallation of Eclipse & OSATE without loosing your projects, allowing for backup of your Eclipse/OSATE workspaces, and to manage your projects in the workspaces through a version control system. 7

8 3 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 AADL Tool Environment 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. In this note we focus on describing functionality that is specific to the AADL plug-ins. 3.1 Invocation of OSATE/Eclipse OSATE is invoked by double clicking on the Eclipse.exe icon in the installation root folder (by default called eclipse ). You may have a shortcut to it on your desktop or your Programs/Applications menu. When OSATE comes up you want to be sure you have the following View panes open. They are opened via Window/Show view. Some of the views are found under Other. The Problems view: it is used to report the status of OSATE commands you perform and to report any errors that are encountered. Make sure that the AADL Text Marker and the AADL Object Model Marker are enabled in the Problem view filter. The AADL Properties Values view: it displays AADL property values for elements of your AADL object model when viewing in the AADL Object Model editor. The Properties view: it displays and allows you to edit attributes and references of the elements of your AADL object model. For more detail see AADL Object Editor. 3.2 AADL Model Files Note: In the Eclipse platform 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 models as XML documents: 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. In the future, there will also be a graphical AADL editor. 8

9 AADL files are kept in Eclipse projects. The project can be created as a simple project. Within a project you can organize files into folders. AADL files can be created within ATE or they can be imported from the file system. New files are created as follows: Textual AADL files are created by performing a New and File for a file with the extension aadl. The file is automatically opened in the AADL text editor. XML-based AADL files are created by parsing textual AADL files (see below) or by performing a New followed by Other and then selecting the Model Creation Wizards and Aadl Model. AADL models can also be imported from the file system. This is done through the import command in the File menu or in the popup menu opened through right clicking in the file system Navigator. See section How to Manage Your Eclipse/OSATE Workspaces for more detail. 3.3 How to Manage Your Eclipse/OSATE Workspaces 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. 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. NOTE: 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. You may want to call this workspace folder OSATE User Workspace. By keeping the workspace separate from the installation root folder area, you can delete the installation root folder for a clean reinstallation without loosing your project work. Keeping the workspace separate also allows you to have the workspace backed up without backing up the installation itself. While working within Eclipse dialogs to create/open/save files will show the folder/file hierarchy relative to the workspace root with the exception of the import/export 9

10 operations. If you want to find out the location of the current workspace, a project folder, folder, or file in the workspace as a full path in the in the file system, select the item in the Eclipse Navigator view and select the Properties command in the popup or File menu Import and Export to the File System We have provided a number of AADL model examples in textual form. You can download them at You can bring files from the file system into a workspace in several ways: Files can be imported into 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. You will have to have created a project in the workspace ( File/New/Project ) before importing files. 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 popup menu/ Refresh ) on the project 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. Files in the workspace can be accessed from the file system in several ways: Simply access the workspace and its content using the regular file system browser. Export the files into the file system by using the Export command. This will result in a copy of the file in the specified file system location. 10

11 3.3.2 Synchronizing with the File System 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. Eclipse will detect that changes have been made externally. You will have to perform a Refresh (in the File menu or Eclipse Navigator popup 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 do so in the Workbench dialog pane of the Help/Preferences dialog. 3.4 Using the Tools You use the AADL Text Editor by opening a file with the extension aadl. You can do so by double clicking on the file in the Eclipse Navigator or through the Open menu entry. The AADL Text Editor automatically performs syntax and semantic checking we you save the file and reports any errors or warnings in the Problem view. For more detail on this editor see the appropriate section below. You use the AADL Object Model Editor by opening a file with the extension aaxl, i.e., and AADL XML file. You can do so by double clicking on the file in the Eclipse Navigator or through the Open menu entry. The AADL Object Model Editor supports viewing of AADL Property Values and editing of the AADL object model. You can also apply various analysis and generation plug-ins to the AADL object model by selecting an appropriate object in the AADL Object Editor and invoking the plug-in from the menu bar or from a toolbar button. For details on the AADL Object Model Editor and the Plugins see the appropriate section later. You can also open an AADL XML file as XML text. You do so by first closing the AADL model in the AADL Object Model Editor and then opening the file using Open with in the popup menu of the Eclipse Navigator. Be sure to have the Problem view open in order to see any messages from the editors and analysis/generation plug-ins. In addition, 11

12 4 What s New in OSATE What s Coming Graphical AADL Editor. XML file per AADL package support. Modal processing of AADL model instances. Resource allocation and scheduling analysis plug-ins. Plug-in development workshop and guide. Support for sublanguage extensions to AADL. 4.2 Significant Changes Since OSATE Important Bug Fixes and Changes The parser did not check that port group definitions had matching names on the definition delimiters. That is, port group x features p: in data port; end y; was previously allowed. The Parser now automatically includes the predeclared property sets. This means you do not have to copy them into your textual AADL model. The parser recognizes whether you do have these property sets included in your model and will not load them automatically in that case. Please remove the predeclared property set text from your models in order for the parser to use the most recent definitions of those property sets. Note: There was a minor correction to the predeclared Deadline property to be consistent with the standard (the default value is that of the period). All OSATE plug-ins now log exceptions and internal errors in the Eclipse Error log. This log file is located as.log in the.metadata folder of the actively used Eclipse workspace. Analysis plug-ins that require additional properties now use a single property set called SEI. The MetaH generation plug-in now produces MetaH text in the correct declaration order and translates a larger set of properties. The model instantiation plug-in now creates semantic port connections Changes to the Meta-Model and XML Representation The ADL meta model and XML representation is consistent with Version 0.2 of the draft AADL Interchange Format Annex document, which is currently in review and available upon request. PropertyDefinition given a hasemptylist attribute to distinguish whether the default value of a list-valued attribute is the empty list or undefined. Changed how references to property constants via the value( ) expression are represented. Now all references are represented by PropertyReference objects. 12

13 The PropertyReference class now has a new attribute referencesign that may point to a leading sign when the reference is to a PropertyConstant. Added the new super class BooleanOrPropertyReference, which is used to replace the BooleanPropertyReference class. As the name implies, it is a superclass to BooleanValue and PropertyReference. The BooleanOR, BooleanAND, and BooleanNOT classes now point to BooleanOrPropertyReference objects. Added the new super class NumberOrPropertyReference, which is a super class to NumberValue and PropertyReference. The minimum, maximum, and delta attributes of RangeValue now refer to NumberOrPropertyReference objects. This change is related to the overall changes to how references to property constants are represented. References between different elements in the XML document, i.e., between objects in the AADL Object Model, are now maintained using the XML XPath representation. Previously, we had used an EMF specific reference representation. For more detail see the draft AADL Interchange Format Annex document Semantic Checking OSATE now checks all the semantic rules except for those noted as Remaining Unimplemented below Newly Implemented Checks Only one subprogram call sequence can apply to a given mode Checking subprogram call order on connections between subprogram ports Check for cycles in the type/implementation/port group type hierarchies Better handling of refined features Better checking of connections: directions of ports, port group compatibility, data compatibility, modes Enforcement of "inverse of" rules for port group types: no chaining of inverses, and no extension of inverse port groups Components and connections making up flow sequences and end-to-end flows are checked for correctness Checks that a property is only assigned to once in a given property association clause Better error messages when property type errors occur Property lookup on instance models Added property value equality methods Better checking of "completeness" of system, e.g., a complete process must contain a thread; e.g., a processor component must contain at least one memory component or require at least one bus access Checking semantic attributes of models: delayed port connections between periodic threads, consistency of property values along semantic connections, etc 13

14 Remaining Unimplemented Semantic Checks Checking that constant property associations really are constant. This won t be implemented. The in binding semantics of property associations are not yet implemented. Checking that any given package has at most one public and one private section. This will be checked once we have a better way of managing packages. Checks related to the modification of component classifiers and port direction when features are refined. This will be implemented in the future. Checking compatibility of Required_Access and Provided_Access property values on provided/required features. This will be implemented in future. Checking that two port groups complement each other. This will be implemented in the future. Checking that port groups whose Aggregate_Data_Port property value is true contain ports that all have the same direction. This will be implemented in the future. Checking that server subprograms map to subprograms that have compatible signatures. This will be implemented in the future. Semantic connections are not fully checked for correctness. This is because the instantiation process currently does not create all the semantic connections in the instantiated system. This will be corrected in the future. Checking that the mode transitions for a component implementation are deterministic. This will be implemented in the future. Checking that all threads are bindable to processors and all components representing source test are bindable to memory. This will be implemented in the future Checks Beyond the Scope of the Tool A number of semantic rules have been determined to be beyond the scope of the OSATE tool set. Such rules are unlikely to ever be enforced by the toolset. All the rules in Section 12.2 System Binding are beyond the scope of the tool, plus the following rules that have to do with source code issues: The complete source text associated with a process component must form a complete and legal program as defined in the applicable source language standard. This source text shall include the source text that corresponds to the complete set of subcomponents in the process s containment hierarchy along with the data and subprograms that are referenced by required subcomponent declarations. If several subprogram declarations refer to the same subprogram type or via the Source_Name property to the same subprogram in the source text, then their parameter signatures in the source text and the property associations must be consistent with each other. The source text associated with all contained components of the system instance must be compliant with the specified component type, component implementation, and property associations. 14

15 4.3 Significant Changes Since OSATE Alpha Release The following capabilities have been added since the Alpha release of May 2004: Support for AADL V0.994 as approved by the SAE AADL working group in July Works with the official release of Eclipse Release Build 3.0 and EMF Version 2.0 (incl. maintenance release 2.0.1). An online help plug-in for AADL OSATE. A new version of the AADL text editor with syntax-sensitive help. Full semantic checking: semantic checking on connections and flows such as port direction, matching data types, number of incoming connections on data ports; semantic checking on properties such as property type, applicability of property to component category. Automatic inclusion of the predeclared properties defined in the property sets AadlProperties and AadlProjects. Maintenance of declaration order in the Aadl Object model. The AADL Object Model Editor limits choices in the properties sheet to those that are legal with respect to AADL name scoping rules. Full property value retrieval support including mode dependent property values and property values inherited from component classifiers being extended. Generation of a system instance model from a system implementation as system instance root and persistent storage of this model instance as separate XML document. Methods to support creation of analysis plug-ins as extensions to OSATE. An example analysis plug-in that performs consistency analysis of security levels, a property newly introduced through a property set; the analysis plug-in checks for compatible security levels across connections and determines the security level of a component containing subcomponents from the security level of the subcomponents. A prototype plug-in to convert SAE AADL into MetaH; the converter can currently translate non-model AADL models. An architecture analysis plug-ins that demonstrate light-weight architecture consistency validation of properties whose inconsistency could result in system problems. OSATE has handled AADL models as large as lines and more. 15

16 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 open/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 Code folding: the capability to selectively hide or display portions of the specification being edited 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 When pressing '.': the editor determines the AADL model element preceding the period and computes proposals appropriate to the element 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. 16

17 Classifier elements: within a component type declaration, the editor can suggest the type's features, to be used within flow specifications. Within a component implementation, the editor can suggest the associated type's connections, to be used within flow implementations. As with reserved words, the proposals are restricted by a user-provided prefix, or are otherwise exhaustive if no prefix is detected Component implementations: within a component implementation, the editor can suggest the implementations of a type if code completion is triggered by typing a type name followed by a period ('.'). This is useful when declaring subcomponents of an implementation which have a specific implementation as their type. This feature is not triggered if the user is typing a new component implementation declaration, or ending it. Subcomponent elements: within a component implementation, the editor can suggest features of a subcomponent if code completion is triggered by typing a subcomponent name followed by a period ('.'). This is useful when declaring connections within an implementation. Similarly, the editor can propose the subcomponent's type flow specifications, to be used within flow implementations. Some of the above proposals may apply simultaneously in a given scenario. For instance, triggering code completion after typing a non-qualified fragment could match both reserved words and classifier elements. In that case, all proposals are returned to the user; each kind of proposal has a unique icon associated with it to assist the user in choosing semantically valid options. Reserved words, which tend to outnumber other kinds of proposals, are placed towards the end of the list. 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) 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 If the hovered element is a feature or a flow specification, an AADL-like fragment is displayed showing the declaration of the type where the feature of flow specification is declared, followed by the feature or flow specification declaration itself. This is useful when hovering over a feature or flow 17

18 specification used within a connection or flow implementation declared in a different element than the feature of flow specification's declaration point If the hovered element is a classifier, the classifier's declaration is displayed. Moreover, if the classifier is a component implementation, the information displayed will be different according to the portion of the identifier hovered; if the user hovers the mouse over the classifier's type, the type declaration will be shown, otherwise it will be the implementation declaration Finally, if the hovered element is a subcomponent, or an element of a subcomponent such as a feature or a flow specification, the declaration of the appropriate element will be shown. Again, the information includes the declaration of the element itself and that of its enclosing classifier. As with classifiers, hovering over a fully qualified subcomponent element reference will describe the subcomponent itself or the specific element, depending on whether the user hovers the mouse to the left or to the right of the period ('.') in the identifier Code Folding The AADL editor is based on Eclipse's own Java example editor. As such, it inherits a number of features from this editor. A particularly useful feature is the capability to produce an outline from an AADL specification. This outline contains all top-level declarations present in the AADL specification. A further feature present in the editor is that of synchronizing its display according to the outline. If this option is selected, instead of displaying the full AADL specification, the editor will only display a declaration highlighted in the outline page corresponding to the specification. This can be useful in understanding specific portions of an AADL specification. Version 3.0 of the Eclipse platform introduced support for code folding, the capability to selectively expand or collapse portions of an editor's contents independently of the content outline. The editor has been extended to provide support for code folding. When an AADL specification is opened, a number of small arrows are displayed next to each top-level declaration. Clicking those arrows hides all but the first line of the declaration. Hovering over the arrow next to a collapsed region shows the hidden contents in a popup. The advantage of this feature over the original content outline synchronization (which is still present) is that by selectively hiding portions of the specification, the user may compare two or more declarations with each other by visually laying them out together; the content outline synchronization feature, by contrast, allows the display of only one declaration at a time. 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 18

19 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 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. 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, package, and property set declarations. Selection in the outline view results in navigating the text editor to that construct. If the Outline view is not visible 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. 19

20 5.3 Semantic Checking and Translation to XML Parsing and semantic checking is performed in two ways on textual AADL files: The parser and semantic checker are invoked automatically every time a save is performed in the AADL Text Editor, or an AADL text file is loaded into the AADL Text Editor. In this case no XML file of the textual AADL model is created. The parser and semantic checker are invoked when the user selects the AADL text file in the Eclipse Navigator and invokes the Parse to XML command from the menu or via tool bar button. In this case the XML file containing the AADL model, i.e., a file with the extension aaxl is created 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. 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 Object Model Marker is enabled with a checkmark. 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 Predeclared Properties The semantic checker automatically includes the predeclared properties of the core AADL, i.e., properties that are defined in AADL_Properties or in AADL_Project, in the Aadl Object Model. These 20

21 declarations are included with the Aadl plugins. If you have already have manually included these property sets in your textual AADL model, those property sets will be processed instead. You can remove those two property set declarations from your aadl files to ensure that the most recent version of the property sets are used. The predeclared property sets are kept in the aadl folder in the edu.cmu.sei.aadl.parser/aadl 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. A list of semantic checks not currently performed can be found in section The AADL XML Document The parser generates an AADL object model, which is persistently saved as an AADL XML document. This document 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 document 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 document 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 documents. 21

22 We have implemented a system instance representation as an AADL object model and persistent XML representation. This representation is intended for analysis plug-ins that focus on back-end analysis and generation of the runtime architecture and is designed to be used as a more compact representation that does not require loading of the complete declarative AADL model. An prototype instantiation plug-in is included with this release of OSATE (see the plug-in section below). Note: Currently an AADL model is stored as a single XML document. We are in the process of completing a multi-file implementation of AADL XML documents. In that case each AADL package will be stored in a separate XML document. The multi-file support is 90% complete and will be available with the next release. 22

23 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 3.2). When opened the AADL Object Editor has the following views and edit panes: 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. 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. 23

24 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.1 Operating the Library Hierarchy and System Instance Hierarchy The library hierarchy view of the edit pane is shown in the figure above. It shows component declarations contained directly in an AADL specification, package, annex library, and property set declarations, and their content. Component types and implementations, property types and property name declarations expand hierarchically. Component types contain features, flow specifications, and property associations (as defined in the AADL syntax). Component implementations contain subcomponent, mode, flow implementation, connection, call sequence, and property declarations. Subcomponents do not expand out into their classifier and those classifiers content. The system instance hierarchy view the edit pane shows the instance hierarchy of the selected element in the Outline view. 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. The system instance hierarchy is shown in the figure below. OSATE includes an initial prototype plug-in that an AADL instance model (see Section 7.6). This model is also navigable and can be manipulated by the AADL Object Editor. Its system hierarchy corresponds to that shown in the system instance hierarchy view of the same root system implementation. 24

25 6.2 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 Create child and Create 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 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. 25

26 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.3 Generating Textual AADL The AADL Tool Environment includes an unparser, i.e., a generator of textual AADL from and AADL object model. In other words, this is an AADL XML to textual AADL converter. The unparser can be invoked on a file with the aaxl extension by opening the file in the AADL Object Editor, selecting the AadlSpec object (root of the model), selecting Aadl Menu / Unparse Aadl or by clicking on the Produce Aadl Text button in the toolbar. This button has an icon with a curly bracket and the letter A. 26

27 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, but not another location in the file system outside the Eclipse workspace. 27

28 7 Additional OSATE Plug-ins OSATE includes several plug-ins beyond those that check the basic semantics of AADL models. They are several analysis plug-ins and a plug-in that generates textual MetaH from an AADL Object model. These plug-ins are available for execution in the tool bar and in the Aadl Menu or 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. Those 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 following plug-ins have been included with this release. 7.1 Required Connection Checking The Required_Connection property is a predeclared aadlboolean property for ports. It is true if a port must always be connected. This means that a component implementation must have a connection from/to this port and a subcomponent port for every mode. Similarly, a subcomponent with a component classifier, whose port has this property set to true must have that port connected within the enclosing component implementation for every mode. The check can be invoked on the aaxl resource, or on any of the AADL model objects. In both cases the check is applied to all ports of component implementations and subcomponents that have a value for this property. Note: The default setting for this property is currently true. This means unless the value is set to false the check will be performed and violations reported. We may want to consider having no default value, i.e., let the modeler explicitly decide whether they care to have this property checked for a port. You can apply this analysis to any model. Any subcomponent port that requires a connection but does not have an incoming or outgoing connection is reported. Any component implementation port that requires a connection but does not have an incoming or outgoing connection is reported if the implementation contains subcomponents. 7.2 Stream Miss Rate Checking This plug-in checks whether the miss rates in streams communicated through ports are consistent, i.e., the miss rate of an out port does not exceed the miss rate of an in port. The miss rate of an out port represents the maximum miss rate of the generated stream through this port. The miss rate in an in port represents the maximum miss rate that is component expects and is willing to handle. Miss rates are specified on ports through SEI::StreamMissRate, a aadlreal valued property defined in an Architecture property set, i.e., 28

29 Property set SEI is StreamMissRate: aadlreal applies to (port); End SEI; The analysis plug-in performs this check for all connections if either or both the source or destination ports have a value for this property. The check can be invoked on the aaxl resource, or on any of the AADL model objects. In both cases it is applied to all connections in the AADL model. A connection is reported if the miss rate of the destination port is lower than the miss rate of the source port of any connection. You can use this plug-in on any AADL model that has property values for this property associated with some of its ports. A code snippet from the SunseekerDemo eexample: process Sunseekerplant_Type features Controllerinput : in data port Beacon_Standard::Single_Float; Outputfeedback : out data port Beacon_Standard::Single_Float { SEI::StreamMissRate => 0.06;}; 7.3 Security Level Checking This plug-in checks whether the security level of a component with an outgoing connection does not exceed the security level of the component this connection leads to. At this time this is checked for every connection declaration in the future this check should also be performed on semantic connections. The security level is specified on components, i.e., on component type, component implementation, or subcomponent declarations. SEI::SecurityLevel, an aadlinteger valued property defined in the SEI property set, i.e., Property set SEI is SecurityLevel: aadlinteger applies to (system, process, thread group, thread); End SEI; The analysis plug-in performs this check for all connections if either or both ports have a value for this property. The check can be invoked on the aaxl resource, or on any of the AADL model objects. This analysis can be performed on both the declarative AADL model, i.e., the collection of component classifier declarations in an AadlSpec, and on an Aadl model instance. For creation of model instances see the Instance plug-in description. This plug-in performs two functions. First, it ensures that a component has a security level that is the maximum of the security levels of its subcomponents. Second, it checks for all connections whether the source component of a connection declaration has a security level that is the same or lower than that of the destination component. If a 29

30 component does not have a SecurityLevel property declared its value is assumed to be zero, i.e., the lowest security level. The first check is performed for every component implementation. If the component implementation does not have this property, but at least one of its subcomponents does, then the property value will be set to the maximum value for the component implementation. If the enclosing component implementation already has a SecurityLevel value and it is less than the maximum of the subcomponent security levels, its value will be updated to the maximum. The analysis propagates the security level value up the system hierarchy in one of two ways. If the analysis is invoked on an Aadl model instance (either the corresponding aaxl resource or any model object of the model instance), then the component hierarchy of the system instance is traversed in postfix order (bottom up) to evaluate each component implementation that is a classifier for the subcomponent that is represented by a component instance object in the instance model. If the analysis is invoked on an AadlSpec (either the corresponding aaxl resource or any model object of an AadlSpec), then the analysis works bottom up through the component classifier library. This means it starts with component implementations with out subcomponents, and then recursively processes component implementations, whose subcomponents have the already processed component implementations as classifiers. The second check is performed after the security level values have been propagated up the system hierarchy. This check compares the security levels of the source and destination components in connection declarations. This means the security levels of subcomponents and in case of connection up or down the hierarchy between subcomponents and enclosing component implementations. In the future this check will be performed on semantic connections. Note: This plug-in is intended to demonstrate how to build analysis plug-ins. It operates on both AadlSpecs, i.e., collections of component classifier declarations possibly in packages, and on Aadl model instances. It makes use of traversal methods provided by AadlSwitch in order to propagate information up the system hierarchy, both in component classifier declaration collections, and in model instances. 7.4 Safety Criticality Level Checking This plug-in checks whether the safety criticality level of a component with an outgoing connection is higher or equal to the safety criticality level of the component at the destination end of the connection. The idea is that a component with lower safety criticality should not drive the operation of a component with a higher safety criticality. At this time this is checked for every connection declaration in the future this check should also be performed on semantic connections. The safety level is specified on components, i.e., on component type, component implementation, or subcomponent declarations. SEI::SafetyLevel, an aadlinteger valued property defined in the SEI property set, i.e., 30

31 Property set SEI is SafetyLevel: aadlinteger; End SEI; The implementation of this plug-in is similar to that of the security level checker. 7.5 Flow Latency Analysis This plug-in determines the latency of flow implementations declared for components and compares it to the latency specified by the corresponding flow specification of the component. The plug-in operates on the predeclared Latency property. The analysis plug-in performs this check for all flow implementations and their corresponding flow specifications for all component classifier declarations. The check can be invoked on the aaxl resource, or on any of the AADL model objects. In both cases it is applied to all component implementations. The latency of a flow implementation is determined as the sum of all: The connection latencies in the flow implementation; the connection latency is determined by the Latency property value if not declared it is assumed to be zero. The flowspec latencies of all subcomponent flowspecs in the flow implementation; the subcomponent flowspec latency is determined by its Latency property value if no value was declared and the component is a thread then the period is used for periodic threads, and the deadline for all other threads. Otherwise, zero latency is assumed. The resulting latency value is then stored as a Latency property association of the flow implementation. Finally, the latency value is compared to the latency value of the flow specification with the same name in the component type corresponding to the component implementation. If the flow implementation latency value exceeds that of the flow specification an error is reported. Note: This plug-in is still in development. The analysis is currently specification-based, i.e., the flow latency is analyzed against flow specification latency one component layer at a time in the component hierarchy. In the future it will include communication latencies due to connections over buses, end-to-end latency analysis, and latency analysis based on actuals. 7.6 Aadl Model Instantiation This plug-in creates an Aadl instance object model from a root system implementation in the declarative AADL object model, i.e., the AADL object model that is produced from parsing textual AADL. It creates 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 AadlSpec. This instance model includes the component instances, feature instances, mode instances, and locally cached 31

32 property values for all properties retrieved from the corresponding object model of the Aadl specification. The instance model can be opened and examined with the Aadl Object Model Editor. The AADL properties can be viewed in the AADL Property Values view. Instance models can also be processed by analysis plug-ins (see the security level analysis plug-in as an example). This plug-in can only be invoked on system implementations. NOTE: This plug-in is still under development. The instance model now includes semantic connections for port connections. Support for processing each combination of component modes, called System Operation Mode (SOM) in the standard, of a modal instance model is almost complete and will become available with the next release of OSATE. The instance model support is being tested by building a scheduling analysis plug-in that interfaces to a Java implementation of an RMA analysis and to a Java implementation of a distributes resource allocation tool. You can invoke this plug-in on a system implementation. The result is an instance XML file with the aaxl extension. The instance model shown at the bottom of the AADL Object Model Editor below. 7.7 MetaH Generation This plug-in generates a textual MetaH model from an Aadl object model. This is a prototype under development. It is currently limited to non-modal AADL models. The AADL to MetaH translator can be invoked on any object. However, if the generation of an application statement is desired, it should be invoked on a system implementation that contains two subcomponents, the first representing the application 32