Solving the TTC 2011 Reengineering Case with VIATRA2

Automated model transformations play an important role in modern model-driven system engineering in order to query, derive and manipulate large, industrial models. Since such transformations are frequently integrated to design environments, they need to provide short reaction time to support software engineers.

The objective of the VIATRA2 (VIsual Automated model TRAnsformations [9]) framework is to support the entire life-cycle of model transformations consisting of specification, design, execution, validation and maintenance.

Model representation. VIATRA2 uses the VPM metamodeling approach [8] for describing modeling languages and models. The main reason for selecting VPM instead of a MOF-based metamodeling approach is that VPM supports arbitrary metalevels in the model space. As a direct consequence, models taken from conceptually different domains (and/or technological spaces) can be easily integrated into the VPM model space. The flexibility of VPM is demonstrated by a large number of already existing model importers accepting the models of different BPM formalisms, UML models of various tools, XSD descriptions, and EMF models.

Graph transformation (GT) [3] based tools have been frequently used for specifying and executing complex model transformations. In GT tools, graph patterns capture structural conditions and type constraints in a compact visual way. At execution time, these conditions need to be evaluated by graph pattern matching, which aims to retrieve one or all matches of a given pattern to execute a transformation rule. A graph transformation rule declaratively specifies a model manipulation operation, that replaces a match of the LHS graph pattern with an image of the RHS pattern.

Transformation description. Specification of model transformations in VIATRA2 combines the visual, declarative rule and pattern based paradigm of graph transformation and the very general, high-level formal paradigm of abstract state machines (ASM) [2] into a single framework for capturing transformations within and between modeling languages [7]. A transformation is defined by an ASM machine that may contain ASM rules (executable command sequences), graph patterns, GT rules, as well as ASM functions for temporary storage. An optional main rule can serve as entry point. For model manipulation and pattern matching, the transformation may rely on the metamodels available in the VPM model space; such references are made easier by namespace imports.

Transformation Execution. Transformations are executed within the framework by using the VI-ATRA2 interpreter. For pattern matching both (i) local search based pattern matching (LS) and (ii) [6].

The rest of the paper is structured as follows. Sec. 2 gives an architectural overview of the transformation, while Sec. 3 highlights the interesting parts of our implementation and finally Sec. 4 concludes the paper.

We implemented our solution for the Program Understanding case study [5] using the VIATRA2 model transformation framework. Fig. 1 shows the complete architecture with both preexisting (depicted with darker rectangles) and newly created components (lighter rectangles). The optional Transformation Controller is an extension to the Eclipse framework that provides an easy-to-use graphical interface for executing the underlying transformation (i.e. it appears as a command in the pop-up menu of XMI files); it is, however, possible to execute the same steps manually on the user interface of VIATRA2. From the user perspective, the controller is invoked on an input XMI file and the result is an output Statemachine file.

Note that the transformation is performed on models inside the VPM modelspace of VIATRA2 rather than on in-memory EMF models. Although VIATRA2 does not manipulate EMF models directly, it includes a generic support for handling EMF metamodels and instance models.

In order to understand the transformation we briefly outline the metamodeling approach of our solution. The Ecore metametamodel is the base of this support, which was defined in accordance with the actual EMF metamodel of Ecore.

Both the Java syntax graph and Statemachine metamodels are defined as instances of this metametamodel, and are imported into VIATRA2 with the generic Ecore metamodel importer. Then the input file is used to import the Java syntax graph into VIATRA2 and create the Java syntax model which is the instance of the Java syntax metamodel.

By executing our implemented transformation, we can transform the Java syntax model to a Statemachine model which is an instance of the Statemachine metamodel. This Statemachine model is then exported to create the output Statemachine file.

3 Transforming Java syntax to statemachines (J2SM)

The J2SM transformation generates the Statemachine model from the Java syntax graph in the VIATRA2 framework and is implemented in the VIATRA2 Textual Command Language (VTCL) [1]. J2SM can be separated into four parts, (1) the construction of the Sta

This content is AI-processed based on open access ArXiv data.