The ByADL framework


The framework

Figure 1 shows the main constituting elements of byADL.

The main input of byADL is represented by the metamodel of the ADL to be extended. For this reason byADL contains a repository of metamodels as shown in the Figure. The metamodel is extended by means of Composition Mechanisms which rely on specific composition operators that have to be applied to metamodels extracted from the metamodel repository.





Figure 1: The high-level design of the byADL framework.



It is important to note that extending an ADL does not mean to compose and merge two different ADLs. Even though this could be technically possible this could lead to the creation of a "chaotic" and "vague" language. In this cases we believe that it is better to keep using the two different ADLs while referring to interoperability techniques in order to translate from one ADL to a different one (see DUALLy). The composition operators allow the software engineer to select which parts of the two metamodels will be considered in the composed metamodel. The selection of the parts to be considered is calculated by means of a "slicing" procedure performed before composing the metamodels. The composition operators are:

The composition engine performs various semantic checks to avoid incidental errors. The ADL obtained at the end of the process is a modeling language consisting of (i) an abstract syntax, i.e. the metamodel obtained by means of the composition mechanisms, (ii) a set of concrete syntaxes, i.e., textual and graphical notations to visualize and edit models conforming to the composed metamodel, and (iii) semantics describing the meaning of the language constructs. For each ADL, different concrete syntaxes can be specified by means of the "Visualization and editor creators" component. The semantics of the extended language is given by means of semantic relationships between the language's elements and elements of a core set of architectural concepts called A0 (see DUALLy). By means of relationships between elements of a metamodel and elements of A0 the elements of the ADL implicitly inherit the built-in semantics of A0.

Finally, suitable Migrators are defined in order to automatically generate model transformations able to reflect the architectural models defined within the newly created ADL, back to the original tools. More precisely, a migrator takes as input a model and produces three different models: a model for the two metamodels to be composed and a "trace" model that contains information required to store the elements which have to be considered together, when the separated models have to be recomposed. Migrators are automatically generated by means of Higher Order Transformations (HOTs), i.e. transformations that generate transformations, defined inside byADL.

The tool

The byADL framework has been implemented atop of the Eclipse platform, and consists of a set of Eclipse plugins which exploits the ATLAS Model Management Architecture (AMMA). In particular, metamodel compositions are specified as weaving models defined by using the ATLAS Model Weaver (AMW). AMW allows the definition of correspondences among (meta)models and links among model elements. An extensible weaving metamodel defines the types of such weaving links. All the involved model transformations (like Composition2Ecore or the model migrators) are based on the ATLAS Transformation Language (ATL), an hybrid model transformation language with declarative and imperative constructs. Models and metamodels are managed by means of EMF which is a modeling framework and code generation facility for building tools and other metamodel-based applications. EMF provides tools and runtime support to produce a basic editor, viewers, serializers and other auxiliary facilities.

The tool is integrated with other MDE technologies already available in the Eclipse community; in the following we will specify also the dependencies of the byADL plugins, i.e. extension or use of already existing plugins.

Metamodels import

Even though we consider this step an atomic one, importing a metamodel into the byADL framework (more specifically, into its Metamodel repository) is a three-steps process: retrieving the metamodel, tagging it and, finally, providing its semantics. Each step will be described in the remaining of the section.

Obtaining a metamodel

The byADL framework is able to manage Ecore metamodels and to operate on a specific notation, the software engineer must necessarily provide its metamodel specified in Ecore. Unfortunately, the Ecore metamodel of an architectural notation is not always available and typically its abstract syntax is defined as a textbased grammar. In particular, there are three main cases in which the Ecore metamodel of a given notation is not readily available:

Tagging a metamodel

Assuming that the Ecore metamodel of the considered notation to import is available, the software engineer has to "tag" it to specify additional information about the nature of the elements it contains. The rationale of tagging a metamodel is that of guiding the software engineer in correctly extending ADLs while keeping the involved metamodels organized and classified. Moreover, the tags will guide the software architect while importing and composing metamodels. In fact, the byADL metamodel composition operators are metamodel independent and this could lead to undesired scenarios if not properly supported. For instance, as previously said we do not promote the composition and merging of two different ADLs and by means of the tagging feature we prevent this kind of composition for each metamodel tagged as ADL. Additionally, byADL introduces other tags that reflect the various composition scenarios, namely:

  1. Domain & Viewpoint & Analysis. The metamodel defines either domainspecific concepts, viewpoint-specific concepts, or analysis-oriented constructs.
  2. Methodology&Process. The metamodel specifies methodologyor process-specific elements.
  3. Customization. The metamodel has been defined to customize an ADL with some peculiar elements.

The importing wizard allows the user to associate one or more tags to the current metamodel by simply selecting the desired tag during the importing phase. In fact in some cases a metamodel can be used for different composition scenarios.

Providing semantics to a metamodel

The third step of the importing process is that of providing semantics to the metamodel being imported. A kind of translational semantics is provided to the metamodel by linking its metaclasses to elements in A0. By doing this, the elements of the metamodel implicitly inherit the built-in semantics of A0. The links among the metamodel elements and A0 are stored in a weaving model whose metamodel is an extension of the base AMW weaving metamodel obtained by adding the type-of link.

We extended the AMW interface so that the semantic links to the A0 metamodel guide the application of the composition operators. More precisely, once applying an operator, byADL highlights as target the metaclasses that are semantically compatible with the source metaclass. In this respect, semantic compatibility of metaclasses depends on the type of operator being applied; for example, the Inherit operator may be applied only between two metaclasses (e.g. A and B) that are linked to the same metaclass in A0, or if A is linked to a sub-class of the A0 metaclass to which B is linked. This kind of mechanisms help the definition of semantically sound metamodel compositions.

Furthermore, if the metamodel being imported is tagged as ADL and such a metamodel is already integrated with the DUALLy network, then a weaving model linking the metamodel to A0 already exists. In this case, byADL reuses such a weaving model and analyzes it in order to provide semantics to the metamodel. byADL analyzes each weaving link between the ADL metamodel and A0 and applies the following strategy:

Metamodels composition

Software engineers create a next generation ADL by composing two metamodels already imported into the Metamodel Repository. Metamodels are composed by specifying weaving models which represent the application of the composition operators. Figure 2 depicts the AMW graphical interface we extended for metamodel composition. The woven metamodels are rendered into two lateral panels (points a and c in the figure) using the standard EMF treebased interface. The central panel (point b in the figure) represents the composition weaving model.





Figure 2: Metamodels composition user interface.



Our extension consists of a specific weaving metamodel defining the four kinds of composition operators and a dedicated weaving toolbar (see Figure 2.d) allowing the software engineer to easily compose the metamodels. We extended also the AMW weaving internal engine so that it considers also the tags that each woven metamodel may have. For example, while creating the weaving model the tool permits to select only one metamodel tagged as ADL. Moreover, as previously stated linking the woven metamodels to A0 guides the software engineering in designing meaningful weaving models. Other secondary policies exploit both the tagging mechanism and the semantic links to A0.

The composed metamodel is generated by clicking on a button of the byADL weaving toolbar; the result is an Ecore metamodel which is automatically loaded into the byADL metamodels repository and tagged as ADL.

Editors generation

In byADL there are three different possibilities to produce an editor for the ADL being developed: tree-based, textual, and graphical. Each editor is characterized by different levels of usability and requires different effort for the customization (if needed).

The tree-based editor is provided without any effort by the EMF Eclipse plugin. It displays model elements through a collapsible and hierarchically structured tree with content outline and properties sheet. If needed, the editor can be customized by assigning icons to specific model elements, by extending the forms to set properties, and so on. The customization of the EMF tree-based editor can be done either by hand-coding in Java the specificities of the editor, or by enriching the metamodel with suitable annotations which guide the EMF engine while generating the tree-based editor.

The textual editor is automatically generated starting from the metamodel of the new ADL. The editor conforms to the HumanUsable Textual Notation (HUTN) specification. The produced textual editor supports syntax highlighting and automatic conformance check with respect to the metamodel of the new ADL. Ad-hoc concrete syntaxes may be used for the new ADL, but in this case the software engineer needs to specify what is the textual representation of each element of the ADL metamodel. For example, this can be done by defining how each meta-element will be textually rendered (e.g. using TCS), or by developing specific bridging models serving as starting point for generating the grammar that will underly a generic textual editor (e.g. EMFText).

The graphical editor makes use of the EuGENia tool that automatically generates the models needed to implement an editor from a single annotated Ecore metamodel. EuGENia is based on the Eclipse Graphical Modeling Framework (GMF) that provides a generative component and runtime infrastructure for developing graphical editors. Suitable annotations allow the specification of different roles of the elements (such as the root object of the metamodel) and of graphical properties (such as border.color, label.icon, etc.).

In case of both the ADL being extended (ADL1) and the metamodel (MM) which is considered for extending ADL1 contain EuGENia annotations, then a fully functioning graphical editor can be automatically generated by inheriting all the graphical information available for each metamodel. If the graphical information related to a given element of the new ADL (ADLnew) exists both in the source ADL1 and MM, the preferred field of the operator we are using for composing can help to disambiguate. Another situation is when the ADL1 metamodel is already geared up with an Eclipse GMF graphical editor; in this case the software engineer may choose to adapt the GMF generative models and files so that they work also with the ADLnew metamodel. Moreover, also the A0 metamodel (i.e. the one used to give semantics to a metamodel while importing it into byADL) contains EuGENia-specific annotations. Thus, if neither ADL1 norMM is annotated then the byADL engine is able to navigate the links from ADL1 or MM to A0 and deduce a suitable EuGENia annotation for the resulting ADLnew metamodel. In conclusion, since byADL is developed in the context of the Eclipse platform, currently there are many model-driven solutions to create graphical editors for metamodels at different levels of granularity, usability and automation. So, in case the above mentioned byADL solutions cannot be applied, the software engineer can still provide a graphical editor for ADLnew in an efficient and time-saving manner, avoiding to develop it by hand through a programming language like Java.

Model Migrators generation

The logic of the migrators is encoded in the operators applied in the weaving model during the composition phase. The byADL weaving toolbar contains functionalities (see Figure 2.d) to automatically generate the migrators starting from the current composition weaving model. Technically, model migrators are specific ATL transformations and may be used also outside the byADL framework; the only requirements are that models and metamodels are based on EMF, and that the current Eclipse platform contains the ATL transformation engine.