Building Tools by Model Transformations in Eclipse Oskars Vilitis, Audris Kalnins, Edgars Celms, Elina Kalnina, Agris Sostaks, Janis Barzdins Institute of Mathematics and Computer Science, University of Latvia October 21, 2007

Metamodel-Based Graphical Tool Building Platforms Main applicability area of the metamodel-based tool building platforms is the support of the domain specific modeling (DSM). Such platforms provide a convenient set of tools for the implementation of DSL editors. Our focus is on the graphical domain-specific languages and the platform for creation of graphical DSL editors. General characteristics, common to most of the graphical tool building platforms include: Metamodels that are used for the definition of the tools consist of two parts. Domain part (abstract syntax) contains DSL domain classes. Presentation part (concrete syntax) contains classes representing the user interface elements; Some kind of a mechanism is introduced to define the relation between the domain and presentation metamodels. Typical solutions include: Static mapping approach; Transformation-driven approach.

Static Mapping Approach General characteristics: Correspondence between domain and presentation metamodels is expressed through static mappings. In some cases extra constraints are introduced (possibly OCL); If domain and presentation metamodels are isomorphic (have a similar structure), relatively simple editors can be built with a small effort; Mostly tools defined by the static mapping approach are compiled (generation step is used) with some rare exceptions, which are interpreted; Functionality that cannot be achieved through the static mappings can be implemented by using traditional programming languages. Some tools that use the static mapping approach: Graphical Modeling Framework GMF; MetaEdit+; Microsoft DSL Tools;  GME;  UL IMCS GMT.

Transformation-Driven Approach General characteristics: Correspondence between domain and presentation models is defined through model transformations; Most appropriate for complicated DSLs, where the mapping between domain and presentation metamodels is not obvious; Allows advanced integrity, syntax and semantics checking, as well as model validation on user actions; Permits execution of complex model-oriented tasks (generation, transformation, simulation, etc.) by the use of transformations. Prerequisite – appropriate, convenient and efficient transformation language. Some tools that use the transformation-driven approach: Tiger GMF Transformation Project; ViatraDSM Framework; METAclipse.

Transformation-Driven Tool Platform METAclipse Being developed within the project "New Generation Modeling Tool Framework" within Latvian state research program in IT - Sept Based on Eclipse open-source technologies: Eclipse core platform EMF – eclipse modeling framework, extended with the possibility to synchronize with an external repository, however keeping the strict implementation of original EMF interfaces; Tabbed properties framework (latest release with dynamic properties support); Common navigator framework; Graphical editing framework (GEF); Parts of Graphical Modeling Framework (GMF) runtime. Uses model transformation language MOLA and efficient external repository MIIREP (both developed at UL IMCS). Allows switching to any other implementations of repository and transformations (even clean EMF implementation).

Basic Principles of the METAclipse Framework Data flow between the repository and presentation engines (data flow 1, 4) is defined through the presentation metamodel, which forms the engine interface exposed to the transformations. Presentation metamodel instances are the only information understood by engines. Transformation library, on the other hand, works not only with (potentially augmented) presentation metamodel, but also with domain metamodel (data flow 3).

Presentation Engines Main presentation engines are: Project Explorer Engine; Property Engine; Graph Diagram Engine; Context Menu Engine. All engines are responsible only for managing the user interface and handle only purely presentation tasks (element position, size, graphical window, zoom, etc.); visually display the graphical elements that correspond to the presentation metamodel instances created by transformations; intercept all user activities that influence the model and pass corresponding commands to the transformation engine to execute the corresponding transformations.

METAclipse In Action – MOLA editor

Fragment of Presentation Metamodel (1) Presentation classes (together with some constraints) serve as a semantic contract between Presentation engines and transformations. Presentation metamodel is the fixed part that is not changing from tool to tool. Graph diagram engine’s presentation metamodel fragment: main classes

Fragment of Presentation Metamodel (2) Commands are written to the repository after each semantic user action. After the execution of the transformation, the result of the execution is read from the repository by the engines. Graph diagram engine’s presentation metamodel fragment: command classes

Transformations Manage the domain model (it is completely in the competence of transformations). Build or modify presentation model elements (tree and diagram) upon request by commands. Always keep the presentation model in synch with the domain. Build property dialogs and process related commands which represent the modifications done by the user. Transformation example in MOLA: build new class in a diagram (with a default name set).

Conclusions MOLA editor itself is implemented with the METAclipse platform using bootstrapping. It is being successfully used in the European IST 6 th framework project ReDSeeDS. The developed technology has reached maturity to be used practically. MOLA editor incorporates a compiler built by the facilities provided by METAclipse. It proves the ability to use METAclipse for definition of complete DSL solutions. It is relatively easy to implement logically complicated DSL editors. Even the developed MOLA editor contains non- trivial mappings and checks. It has been proven experimentally that the effort for building a typical DSL editor is relatively small. Currently there is a work going on to incorporate the static mapping ideas in METAclipse in order to ease the definition of simple DSL fragments and gain the productivity that is offered in simple cases by static mapping based platforms.

Building Tools by Model Transformations in Eclipse Paper is prepared with a support of the European Social Fund Thank You! Questions?