OSATE V2 Plugin Development

From AadlWiki

Jump to: navigation, search

We have migrated to the use of Xtext as the AADL V2 front-end framework. Xtext allows you to develop a domain specific language (DSL) where they provide a large portion of the desired platform. It maintains AADL declarative model in memory based on the EMF Ecore Meta model for AADL V2, while storing it in the file system as AADL text file. It uses Xtext resources as subclass of EMF resources, which makes the interaction between declarative models in multiple files, and with instance models transparent.

AADL V2 instance models are based on the AADL instance Meta model expressed in Ecore. This Meta model has not changed much over the OSATE V1.5 Meta model for instances.

OSATE makes available a number of utility methods for model traversal and property retrieval. Some of these methods have moved due to the use of Xtext and its use of EMF indices to manage resolving references across files.

Contents

OSATE V2 Uses Xtext for Declarative Models

Through Xtext we have

  • A syntax-sensitive text editor with syntax highlighting, hyperlinked references, popup help. It includes an ANTLR-based parser and semantic checker for textual AADL that produces the Meta model based in memory representation. The outline view shows the in memory model structure.
  • An AADL XML to textual AADL converter (AADL unparser)
  • Multi-file support for AADL models across projects.
    • AADL V2 has with clauses that make the content of packages and property sets available to other packages and property sets. We utilize the project references (dependency) mechanism in Eclipse in support of this global scoping, i.e., packages in one project can only be referenced by packages in another project if that project has been identified as a referenced project in the project references section of the Properties of a project.
    • Xtext utilizes lazy loading, i.e., it only brings into memory those declarative models that are actually being accessed.
    • Xtext also utilizes the EMF index mechanism to identify classifiers and property definitions/types/constants across packages and property sets without requiring them to be loaded.
  • Auto-build support through Xtext that automatically recompiles declarative AADL model files after changes.
  • Model validation via the EMF Validation framework with incremental validation triggered by incremental parsing, validation on model save, and validation by explicit command invocation. See XTtext Validation for details.

You may also want to check out Xtext documentation on their support for generation via Xtend. They have a very active forum at Xtext Forum.

Changes in Available Methods

Accessing Properties

The methods for accessing properties have moved to org.osate.xtext.aadl2.properties.util. You will find

  • classes that contain static variables with the names of all prredeclared properties, organized by property sets.
  • The class GetProperties contains methods to get various properties for a specified model element, e.g., getActualLatencyinMS. It also contains methods for looking up property definitions, types, and constants by name. It uses EMFIndexRetrieval and PropertiesLinkingService as appropriate. In OSATE 1.5 it was found in edu.cmu.sei.aadl.mdoel.util.
  • The class Utils contains utility methods to create or get property values.

Finding Model Elements

The methods for resolving references and looking up model elements relative to other model elements have moved as they take advantage of EMF indexing and Xtext global scoping support.

  • The class EMFIndexRetrieval in org.osate.xtext.aadl2.properties.util has methods for looking up packages, property sets, classifiers, property definitions, property types, and property constants directly in the EMF index ignoring any scoping constraints. The EMF index works with EObject description objects, which among other things contain a URL to the model object. Methods such as getPropertyDefinitionInWorkspace in EMFIndexRetrieval as well as commented out sample code in DoModelStatistics in the Architecture analysis plug-in show how to use these description objects. Usage of EMFIndexRetrieval requires that the org.osate.xtext.aadl2.properties.ui plugin be activated in order to be initialized properly. This is usually done automatically, but in cases where the class is accessed before initialization occurs, org.osate.xtext.aadl2.properties.ui.MyPropertiesActivator.getInstance() can be called to ensure the plugin is activated.
  • The class PropertiesLinkingService in org.osate.xtext.aadl2.properties.linking provides methods for finding globally accessible entities, such as packages, property sets, and items within them, such as property definitions, property types, property constants, and classifiers. The methods use a context parameter (the model element that references the desired item) as context for the name resolution. In this case visibility rules based on project dependencies are considered. For global lookup ignoring any visibility rules (other than closed projects) see EMFIndexRetrieval.

Other utility methods are now available in the class AadlUtil in org.osate.aadl2.modelsupport.util

  • getContaining(Classifier/PackageSection/Package/PropertySet/TopLevelNameSpace
  • findImportedPackage/PropertySet from string to model object in import list of context.
  • getClassifierName methods that know whether in a given context the name has to be qualified.
  • getFlowxxxName
  • For properties:
    • getPredeclaredPropertySetNames, isPredeclaredPropertySet, isImportedPropertySet,
    • getBaseProperty Type walks down nested list types to get to the base type.

In the class Aadl2Util in org.osate.aadl2.util you find

  • the method isNull which tests a references as to whether it is null or an unresolved proxy.

Finally, in org.osate.aadl2.modelsupport.resources you find

  • a class ModelLoadingAdapter that provides an adapter for getting a model element from an ISelection or IFile.
  • the class OsateResoruceUtil with methods for getting the shared resourceset, getting/creating resources, instancemodel URI from the system implementation.
  • the class PredeclaredProperties with methods for creating the PluginResources project, which contains the predeclared property sets, and contributor property sets.

Working with Files

As in Osate 1.5, we provide a number of methods for traversal of declarative models and instance models, using the EMF generated switch mechanism to invoke user defined methods on each declarative and instance model element type (see org.osate.aadl2.modelsupport.modeltraversal). They are used in various analysis plug-ins.

We have updated a set of methods that traverse the whole workspace (visitWorkspace, visitWorkspaceDeclarativeModels, visitWorkspaceInstanceModels). They make use of methods defined in the class TraverseWorkspace that examine the project and folder hierarchy in an Eclipse workspace to identify IFiles that are declarative models (extension "aadl" or "aadl2") or instance models (extension "aaxl2" and ending with "_instance" in the name).

Personal tools