MODGRAPH

A Transformation Engine for EMF Model Transformations

Thomas Buchmann, Bernhard Westfechtel and Sabine Winetzhammer

University of Bayreuth, Universitaetsstrasse 30, 95440, Bayreuth, Germany

Keywords:

Model-driven development, Graph transformations, Code generation, EMF, Pattern matching, OCL.

Abstract:

Model-driven software engineering aims at increasing productivity by replacing conventional programming

with the development of high-level executable models. However, current technology focuses on structural

models, while behavioral modeling is still neglected. The transformation engine ModGraph intends to ﬁll

this gap. ModGraph complements the Eclipse Modeling Framework with graphical transformation rules from

which executable code is generated. An operation deﬁned in an Ecore model is speciﬁed by a model transfor-

mation rule which is compiled into a Java method calling EMF operations. In this way, ModGraph comple-

ments the capabilities of EMF which would compile operations into empty Java methods. The net result is an

environment which provides comprehensive support for executable models.

1 INTRODUCTION

The Eclipse Modeling Framework (EMF) (Steinberg

et al., 2009) has been used successfully in a wide

range of applications in both research and industry. In

EMF, models are based on the object-oriented Ecore

metamodel, in which classes as well as their structural

and behavioral features are deﬁned. However, con-

cerning behavior, the modeling capabilities of EMF

are limited: Only the signatures of operations may be

deﬁned. Thus, Ecore may be used to deﬁne struc-

tural models only. The EMF code generator creates

code for the classes in an Ecore model. But this code

comprises only elementary operations for setting at-

tribute values, inserting and deleting links, etc. For

user-deﬁned operations, only a skeleton is generated

consisting of the signature and an empty body. The

user needs to supply an implementation for each user-

deﬁned operation. Usually, this is done by program-

ming in Java.

Thus, model-driven software engineering is sup-

ported only partially by EMF. In this paper, we intro-

duce ModGraph

, a transformation engine for EMF

model transformations, which adds behavioral mod-

eling and code generation to EMF. In ModGraph,

model transformations may be deﬁned for any model

deﬁned with Ecore. ModGraph is based on the theory

of graph transformation and views an EMF model

ModGraph is an acronym of “Model Transformation

with Graph Transformation”.

instance as a directed graph. A model transforma-

tion rule is used to realize an operation deﬁned in the

Ecore model and describes a model transformation in

a declarative way. The core of a transformation rule

consists of a graph pattern, which speciﬁes both a set

of objects and links to be searched and the changes to

be performed. In ModGraph, model transformations

are speciﬁed at a much higher level of abstraction than

Java code. A model transformation rule is validated

against the underlying Ecore model. Furthermore, a

valid rule is transformed into executable code which

is injected into the code generated by the EMF code

generator. Thus, ModGraph is tightly integrated with

the EMF framework.

ModGraph adds support for behavioral modeling

to EMF in an incremental way. This approach is in

line with the philosophy underlying EMF, namely to

offer an evolutionary path from Java programming to

modeling. Using the EMF core technology, an ap-

plication developer beneﬁts from structural modeling

and code generation for elementary operations. Us-

ing ModGraph, (s)he may use graph transformations

whenever they are helpful to describe complex oper-

ations on EMF model instances in a declarative and

graphical way. The ModGraph compiler will then

compile these rules into ordinary Java methods. For

the “rest”, the application developer may still resort

to plain Java programming. In particular, the control

structure of an application resides completely in Java

since Java — and other conventional textual program-

212

Winetzhammer S., Buchmann T. and Westfechtel B..

MODGRAPH - A Transformation Engine for EMF Model Transformations.

DOI: 10.5220/0003606702120219

In Proceedings of the 6th International Conference on Software and Database Technologies (ICSOFT-2011), pages 212-219

ISBN: 978-989-8425-77-5

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

ModGraph

Ecore

metamodel

Class diagram

instance of

Package diagram

metamodel

instance of

Package diagram

instance of

Graph transformation

metamodel

instance of

Graph trans-

formation rule

instance of

Java Methods

written in

implements

EMF

Code generator

GraTra

Code generator

calls

consistent with

Executable

model

GMF

based upon

Graphical

definition

GMF

Graphical

tool

Modeler End user

Figure 1: Overview about the different meta-models and models used in ModGraph.

ming languages — has proved to offer a concise and

expressive notation for control ﬂow.

2 OVERVIEW

In this section we provide an overview about Mod-

Graph and its context. Figure 1 depicts a diagram

showing the different modeling components and the

interaction with the modeler and the end user. When

specifying a software system, the modeler usually

starts on a coarse-grained level, by deﬁning an ar-

chitecture. In our approach, package diagrams are

used for this task. A package diagram describes

the coarse structure of the software system by pack-

ages and their dependencies (public/private package

and element imports are used for this purpose). We

developed a package diagram editor which provides

the modeler with modeling-in-the-large capabilities

(Buchmann et al., 2009). This editor was developed

in a model-driven way using the Eclipse Modeling

Framework (EMF) (Steinberg et al., 2009) and the

Graphical Modeling Framework (GMF) (Gronback,

2009). Thus, its metamodel is an instance of the Ecore

metamodel.

In a subsequent step, the modeler can reﬁne this

package diagram with an Ecore class diagram. To

create Ecore class diagrams, any Ecore compliant ed-

itor can be used, e.g., the tree editor which is part of

Eclipse’s EMF distribution or graphical editors like

the Ecore Tools editor or even commercial tools like

eUML2 (Soyatec, 2011). The package diagram editor

provides several methods of use to maintain consis-

tency with the corresponding class diagrams, includ-

ing forward, reverse, incremental round-tripengineer-

ing and an additional validation.

In the following step, the modeler can reﬁne an

operation declared in the class diagram by a graph

transformation rule. This graph transformation rule

is an instance of the graph transformation metamodel

which is also an instance of the Ecore metamodel.

The graphical editor which allows the modeler to

graphically specify the graph transformation rule was

also developed in a model-drivenway using EMF and

GMF.

In addition, hand-written method implementations

in plain Java code are used to call the graph transfor-

mation rules.

To generate code from the speciﬁcation created

by the modeler, two different code generation steps

are used. First, the EMF code generator is used to

generate EMF compliant code according to the Ecore

class diagram. In a subsequent step, the method bod-

ies which are speciﬁed by graph transformation rules

are generated and merged with the code generated in

the previous step. The different code fragments - the

generated ones and the hand written ones - result in

an executable model. An additional advantage of our

MODGRAPH - A Transformation Engine for EMF Model Transformations

213

approach is that GMF can be used to build graphi-

cal tools on top of the executable model, since Ecore

class diagrams are used to model the static structure.

3 GRAPH TRANSFORMATION

RULES

This section goes into detail concerning the graph

transformation rules, which may be used to model be-

havior on a ﬁne grained level.

3.1 General Description

Implementing an EMF operation can lead to large

method bodies coded on a low level of abstraction.

Our graph transformation rules provide a compact and

declarative way to model complex operations. Each

graph transformation rule represents the method body

for an operation declared in the Ecore model. The

parameters of this operation represented EMF objects

and data values. Object parameters are used to bind

nodes of the graph pattern. Data values are used e.g.

in attribute conditions and attribute assignments.

EMF model instances are considered as graphs —

called model graphs — whose nodes and edges rep-

resent objects and links, respectively. A graph trans-

formation rule declaratively describes a transforma-

tion of the model, consisting of structural changes (in-

sertion/creation of objects and links), changes of at-

tribute values, and nested method calls. The core part

of a graph transformation rule is a graph pattern, in

which objects and links are represented by nodes and

edges, respectively. The graph pattern speciﬁes both

the subgraph to be searched and the operations to be

performed. The graph pattern may be constrained us-

ing pre- and postconditions as well as a negative ap-

plication condition (NAC).

A graph pattern resembles a UML communica-

tion diagram, which is composed of a static part —

the underlying object diagram — and a dynamic part

(specifying change operations). The nodes of a graph

pattern are classiﬁed into the current object (denoted

by this), parameter objects, single objects and multi-

objects (representing sets of objects). The current

object and the parameter objects are bound via the

method call. All other objects are unbound and need

to be searched in the model graph. Unbound objects

may be marked with <<out>> to designate them as

return objects of the graph transformation rule.

Nodes are connected by two kinds of edges: paths

and links. Paths stand for derived references and are

marked with expressions. A path expression is written

in OCL or Java. It is evaluated on the source node,

resulting in all target nodes belonging to the model

graph and fulﬁlling the expression. Links represent

instances of references declared in the Ecore model

on which the graph transformation rule is based.

All unbound nodes of the graph pattern need to be

typed with classes from the underlying Ecore model.

Bound nodes are not typed because the types are de-

rived from the owning class (in the case of the cur-

rent object) and the operation signature (in the case of

parameter objects). Links are typed with references

from the Ecore model.

Nodes in a graph pattern contain compartments

for specifying constraints and changes. In the con-

straints compartment, OCL constraints and conditions

on values of single attributes (in Java syntax) may be

deﬁned. The changes compartment may contain at-

tribute assignments as well as other Java statements

(e.g., method calls).

To model structural changes, the elements of a

graph pattern may be decorated with a state. ++ and

- - indicate the states “created” and “deleted”, respec-

tively. An element without decoration owns the de-

fault state “preserved”. Bound nodes may not be cre-

ated, and the current object may not be deleted. If

the graph pattern does not contain any changes either

in its structural part or in the nodes’ change compart-

ments, it describes a graph test which does not have

any effect on the model graph.

Preconditions are checked before the graph pat-

tern is searched; they provide additional application

conditions. Postconditions are checked immediately

before the end of the execution of the graph trans-

formation rule to ensure that the model graph is in a

valid state. Both pre- and postconditions are written

as OCL constraints.

A negative application condition (NAC) is

checked after a match of the graph pattern has been

located and before the transformation is executed. If

the pattern speciﬁed in the NAC occurs in the model

graph, the rule cannot be applied to the current match.

If no other match may be found, the rule fails alto-

gether. An NAC is composed of nodes of the graph

pattern, all of which are bound at this stage of execu-

tion, and (optionally) further nodes, all of which are

unbound. In contrast to the graph pattern, an NAC

may describe only a graph test rather than a graph

transformation.

3.2 Example

To show the functionality, a widely known example

from an EMF tutorial

, the library model, is adapted

http://help.eclipse.org/ganymede/index.jsp?topic=/

org.eclipse.emf.doc/references/overview/EMF.html

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

214

Figure 2: Ecore model of a simple library management system.

(Figure 2). The model deﬁnes a library with a name,

that owns books and lends them to its clients. Each

book has a title, is available or not, and is associated

to exactly one writer. This writer has a name and is

known to the library. Clients also have a name and

an address. In addition, they have to pay a fee if they

borrow a book longer than allowed.

The classes Library and Client deﬁne some opera-

tions. In the following we show the implementation

of three operations with the help of ModGraph trans-

formation rules. The rules have been designed for the

purpose of demonstration. They are simple to under-

stand, yet they cover most of the elements of graph

transformation rules described in the previous subsec-

tion.

The rule acquireBook shown in Figure 3 acquires

a book for the library provided that the author is not

known yet. It receives two parameters title and au-

thorsName of type String. The OCL precondition

given on the top requires that both strings must not

be null. If the precondition does not hold, the rule

fails. The graph pattern below the precondition spec-

iﬁes that a new writer is added to the known writers

of the library. Furthermore, a new book associated to

the library and the writer is created. This new book

is marked with <<out>> as the return object of the

rule. In the changes compartment, the parameter title

is assigned to the attribute of the same name. Fur-

thermore, the books’ availability is set to true, hence

it can be lent to a client. The NAC to the right of

the graph pattern is checked before the transforma-

tion is applied. The NAC succeeds if there already ex-

ists a writer with the name authorsName. If the NAC

succeeds, the rule fails without having performed any

changes.

The rule lendBook (Figure 4) lends a book owned

by the library to one of its clients if the book is avail-

able and there are no unpaid fees charged to the client.

A precondition forcing the library to be open and the

client to be registered is set as the application condi-

tion to be checked before applying the rule. Alter-

natively, this precondition could have been speciﬁed

in the constraints compartment of the current object.

In addition to the current object, the graph pattern

consists of two objects bound by the input parame-

ters client and author (rounded rectangles), and an un-

bound object of class Book (since only the title was

supplied as an input parameter, the book object needs

to be searched in the model graph). The constraints

compartment of the book object checks that the book

has the title supplied as input parameter and that it is

available. The constraints compartment of the client

object ensures that there are no unpaid fees. If the

pattern match succeeds, a link from the book object

to the client object is created, and the book is marked

as not available in its changes compartment.

Finally, returnAllBooks returns all books borrowed

by some client in a single step (Figure 5). This rule is

executed on an object of class Client. The rule demon-

strates the use of a multi-object books representing

a set of books. This set is determined by intersect-

ing the target sets of the references borrows and owns

emanating from the current object and the parame-

ter object lib, respectively. This means that the set

will contain all books which have been borrowed by

the client and are owned by the library (please notice

that the client may have borrowed books from other li-

braries, which are not considered in this operation). If

the pattern match succeeds, all borrows links between

the current object and books objects are deleted, and

all books objects are marked as available.

4 IMPLEMENTATION

ModGraph provides a graphical editor, different

mechanisms for validation, and a code generator. For

their realization, several Eclipse based tools have

been used.

MODGRAPH - A Transformation Engine for EMF Model Transformations

215

Figure 3: ModGraph rule for Library::acquireBook(title : String, authorsName : String) : Book.

Figure 4: ModGraph rule for Library::lendBook(author : Writer, title: String, client : Client).

Figure 5: ModGraph rule for Client::returnAllBooks(lib : Library).

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

216

4.1 Graphical Editor and Validation

The ModGraph graphical editor has been developed

in a model-driven way using the Eclipse Model-

ing Framework (EMF) and the Graphical Modeling

Framework (GMF). The graph transformation rules

shown in Figures 3–5 were produced as snapshots of

the graphical view provided by the editor. In addition,

the editor displays a property view and a tool palette.

Correctness of a ModGraph graph transformation

rule is achieved using several mechanisms:

1. A graph transformation rule must conform to the

metamodel underlying ModGraph. For example,

nodes in NACs may not be marked as created or

deleted. The Ecore model for ModGraph is built

in such a way that errors of this kind cannot occur.

2. The graphical editor performs live validation dur-

ing editing. Commands which would violate the

rules of live validation are rejected. Live valida-

tion is realized by GMF constraints. For example,

a link to be preserved must not be connected to a

node to be deleted. Furthermore, we implemented

restrictions in the source code. For example, the

properties view allows only to select valid refer-

ences for typing a link between two objects (a ref-

erence is valid if it is owned by the class of the

source and the class of the target conforms to the

target class of the reference).

3. All remaining errors are caught by batch valida-

tion. After a batch validation, the user will be in-

formed about the rule’s validity. In case of fail-

ures, error markers are shown in the diagram, and

the Eclipse problems view shows error messages.

For the implementation of the batch validation we

used the EMF-Validation and the Check language

(oAW

). Check is a validation language of the

former openArchitectureWare, which is now part

of Eclipse (MDT

). The ModGraph Check vali-

dation is called by an MWE-workﬂow (MWE

which loads the user’s model and performs all

given Check ﬁles, containing various constraints.

Batch validation catches errors which cannot be

checked conveniently by live validation. For ex-

ample, batch validation veriﬁes the reachability

of nodes, which is important for pattern match-

ing (see below), and performs a syntactic check

on OCL constraints.

http://openarchitectureware.org/

http://www.eclipse.org/modeling/

http://wiki.eclipse.org/Modeling Workﬂow Engine

(MWE)

4.2 Code Generation

When the user invokes the code generator on a graph

transformation rule, the rule is automatically vali-

dated. If validation succeeds, code will be gener-

ated. Since each rule implements an operation de-

ﬁned in the underlying Ecore model, code is gen-

erated directly into the EMF generated code. After

parsing the EMF generated code, the code generator

for graph transformation rules uses Xpand templates

which were formerly provided by openArchitecture-

Ware and were recently included into the Eclipse

Modeling Project. These templates are, like the vali-

dation, called by an mwe-workﬂow.

The generated code will execute a graph transfor-

mation rule in the following steps:

1. The preconditions of the rule are checked. If one

of the preconditions is violated, execution fails.

2. An instance of the graph pattern is searched in the

model graph. If no match is found, executionfails.

3. If a match is found and an NAC is present, it is at-

tempted to ﬁnd a match for the NAC. If the match-

ing succeeds, a forbidden pattern was located. Ac-

cordingly, rule execution returns to the previous

step, trying to ﬁnd the next match for the graph

pattern.

4. Now, the changes speciﬁed in the graph pattern

are applied to the located match.

5. Finally, the postconditions are checked. If one

of the postconditions is violated, execution fails

Otherwise, execution terminates successfully.

Pattern matching constitutes a crucial step in the

execution of a graph transformation rule. Pattern

matching starts at the bound nodes and needs to locate

instances of the unbound nodes of the model graph.

We require that all unbound nodes are reachable from

the bound nodes via a directed path. In the case of

bidirectional references, opposite links are automati-

cally considered in the search, as well. Thus, pattern

matching is performed exclusively by navigation and

does not assume other mechanism for locating objects

such as key attributes and indices.

The performance of pattern matching is severely

affected by the order in which unbound nodes are

searched. In the case of multi-valued references, all

targets of outgoing links need to be considered in the

matching process. Since these targets may have out-

going multi-valued references, as well, the set of can-

didates may grow combinatorially. To bound the can-

In this case, an exception is raised which has to be han-

dled by the caller, e.g., by running a compensating graph

transformation rule.

MODGRAPH - A Transformation Engine for EMF Model Transformations

217

didate set, we implemented a heuristic greedy algo-

rithm which assigns costs to references according to

the upper bounds deﬁned in the Ecore model. In or-

der to extend the current partial match, all edges from

already matched to unmatched nodes are considered

in parallel. From this set of edges, an edge with min-

imal costs is selected. In this way, a spanning for-

est of the graph pattern is constructed. In particu-

lar, the pattern matching algorithm considers single-

valued references before multi-valued references. If

only single-valued references are used to locate the

unbound nodes, there is at most one candidate for

each of them.

5 RELATED WORK

Research on model-driven software engineering has

produced a wide spectrum of model transformation

approaches (Czarnecki and Helsen, 2006). The term

model-to-model transformation indicates that some

target model is created from some source model.

For example, ATL (Jouault and Kurtev, 2005) and

QVT (OMG, 2011) address model-to-model trans-

formations. In contrast, ModGraph supports updat-

ing model transformations, which modify an existing

model.

In contrast to textual model transformation lan-

guages such as ATL and QVT, ModGraph provides

a graphical notation (with embedded textual frag-

ments). The graphical notation makes it easier to un-

derstand the effects of a complex model transforma-

tion. Furthermore, ModGraph is based on the theory

of graph transformations. Many languages, tools, and

environmentshave been developed for graph transfor-

mations (Ehrig et al., 1999). However, in most cases

there is no connection to the EMF framework. There

is only a small number of graph transformation ap-

proaches which are based on EMF. In the following,

we will focus on these approaches because they are

related most closely to ModGraph.

VIATRA2 (Varr´o and Balogh, 2007) provides a

textual rather than graphical language for graph trans-

formations. VIATRA2 has been built with EMF; it

deﬁnes its own metamodel with the help of Ecore. In

contrast, ModGraph has been built for EMF. In par-

ticular, Ecore is reused for structural modeling. As

we have demonstrated, ModGraph is integrated seam-

lessly into the EMF framework and extends it with

graph transformations.

Like ModGraph, TIGER (Biermann et al., 2006)

exploits Ecore for structural modeling. However,

TIGER supports only graph transformation rules

which lack many of the advanced constructs imple-

mented in ModGraph (multi-objects, pre- and post-

conditions, paths, method calls, and OCL integra-

tion). Its successor Henshin (Arendt et al., 2010) ex-

tends TIGER’s graph transformation rules with multi-

objects and control structures, but the other features

mentioned above are still missing.

In TIGER, rules are compiled into classes rather

than methods. When an application developer wants

to implement a user-deﬁned operation introduced in

an Ecore model with the help of a graph transforma-

tion rule, (s)he must write code to instantiate the rule’s

class, to provide the rule instance with parameters,

and to execute the rule. Thus, calling a rule involves

multiple steps which are awkward to implement and

cause considerable overhead at run time. In contrast,

in ModGraph a graph transformation rule is associ-

ated to a user-deﬁned operation, and the ModGraph

compiler generates an ordinary Java method. From

an application developer’s point of view, ModGraph

provides both seamless and efﬁcient integration of the

Java code generated from graph transformation rules.

This is not the case for TIGER. So far, Henshin pro-

vides only an interpreter, which is of limited use for

conventional application development.

Fujaba (Z¨undorf, 2001) is an object-oriented mod-

eling environment which offers class diagrams for

structural modeling and story diagrams for behavioral

modeling. A story diagram is a control ﬂow dia-

gram containing statement activities (plain Java code

fragments) and story patterns (graph transformation

rules). Fujaba was developed outside EMF, but was

re-implemented partially in EMF (Giese et al., 2009).

The re-implementation — called MDELab — uses

Ecore for structural modeling and provides a graphi-

cal editor and an interpreter for story diagrams. Thus,

the end user is limited to the interpreter when work-

ing with model instances. In our approach, the gener-

ated EMF compliant code can be used in all possible

ways, including the generation of a graphical editor

using GMF.

Fujaba’s story patterns are less expressive than

ModGraph’s graph transformation rules because only

the latter offer pre- and postconditions, OCL integra-

tion

, and negative application conditions deﬁned as

separate forbidden graph patterns. Furthermore, the

control ﬂow of story diagrams is limited in its expres-

sive power since it lacks explicit high-level control

structures. For these reasons, ModGraph resorts to

Java for expressing the control ﬂow.

A prototypical integration, which did not make its way

into the Fujaba release, was reported in (St¨olzel et al.,

2006).

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

218

6 CONCLUSIONS

We have presented ModGraph, an environment for

modeling with graph transformations. ModGraph in-

crementally adds behavioral modeling to EMF. Thus,

it provides an evolution path from programming to

modeling. An application developer may take advan-

tage of model transformations where they provide an

added value, and program in Java otherwise. The

examples given in Section 3 clearly demonstrate the

beneﬁts of modeling behavior graphically and declar-

atively with the help of graph transformation rules.

Implementation of ModGraph currently is under

way. Most parts have already been completed. The

package diagram editor and its integration with Ecore

have been implemented completely. The metamodel

for graph transformation rules, the graphical editor,

and rule validations have been completed recently.

The code generator is currently being implemented

and is expected to be complete in the near future.

Since the graphical editor is already available, we are

performing case studies in parallel in order to obtain

feedback from applications. The experiences gained

from these case studies are promising, and we expect

at most minor future changes of the transformation

metamodel.

REFERENCES

Arendt, T., Biermann, E., Jurack, S., Krause, C., and

Taentzer, G. (2010). Henshin: Advanced concepts

and tools for in-place EMF model transformations. In

Petriu, D. C., Rouquette, N., and Haugen, Ø., editors,

Proceedings 13th International Conference on Model

Driven Engineering Languages and Systems (MOD-

ELS 2010), Part I, volume 6394, pages 121–135, Oslo,

Norway.

Biermann, E., Ehrig, K., K¨ohler, C., Kuhns, G., Taentzer,

G., and Weiss, E. (2006). Graphical deﬁnition of in-

place transformations in the eclipse modeling frame-

work. In Nierstrasz, O., Whittle, J., Harel, D., and

Reggio, G., editors, Proceedings 9th International

Conference on Model Driven Engineering Languages

and Systems (MoDELS 2006), volume 4199, pages

425–439, Genova, Italy.

Buchmann, T., Dotor, A., and Klinke, M. (2009). Sup-

porting modeling in the large in fujaba. In van Gorp,

P., editor, Proceedings of the 7th International Fujaba

Days, pages 59–63, Eindhoven, The Netherlands.

Czarnecki, K. and Helsen, S. (2006). Feature-based sur-

vey of model transformation approaches. IBM Sys-

tems Journal, 45(3):621–646.

Ehrig, H., Engels, G., Kreowski, H.-J., and Rozenberg, G.,

editors (1999). Handbook on Graph Grammars and

Computing by Graph Transformation: Applications,

Languages, and Tools, volume 2. World Scientiﬁc,

Singapore.

Giese, H., Hildebrandt, S., and Seibel, A. (2009). Im-

proved ﬂexibility and scalability by interpreting story

diagrams. In Boronat, A. and Heckel, R., editors, Pro-

ceedings of the 8th International Workshop on Graph

Transformation and Visual Modeling Techniques (GT-

VMT 2009), volume 18 of Electronic Communications

of the EASST, York, UK. 12 p.

Gronback, R. C. (2009). Eclipse Modeling Project:

A Domain-Speciﬁc Language (DSL) Toolkit. The

Eclipse Series. Boston, MA, 1st edition.

Jouault, F. and Kurtev, I. (2005). Transforming models

with ATL. In Bruel, J.-M., editor, MoDELS Satellite

Events, volume 3844, pages 128–138.

OMG (2011). Meta Object Facility (MOF) 2.0

Query/View/Transformation, v1.1. OMG.

Soyatec (2011). euml2 studio edition 3.6.0.20110120.

Steinberg, D., Budinsky, F., Paternostro, M., and Merks,

E. (2009). EMF Eclipse Modeling Framework. The

Eclipse Series. Boston, MA, 2nd edition.

St¨olzel, M., Zschaler, S., and Geiger, L. (2006). Integrat-

ing OCL and model transformations in Fujaba. In

Chiorean, D., Demuth, B., Gogolla, M., and Warmer,

J., editors, Proceedings of the 6th OCL Workshop OCL

for (Meta-)Models in Multiple Application Domains

(OCLApps 2006), volume 5 of Electronic Communi-

cations of the EASST, Genova, Italy. 16 p.

Varr´o, D. and Balogh, A. (2007). The model transforma-

tion language of the VIATRA2 framework. Science of

Computer Programming, 68(3):214–234.

Z¨undorf, A. (2001). Rigorous object oriented software de-

velopment. Technical report, University of Paderborn,

Germany.

MODGRAPH - A Transformation Engine for EMF Model Transformations

219