Handcrafting a Triple Graph Transformation System to Realize

Round-trip Engineering Between UML Class Models and Java Source

Code

Thomas Buchmann and Sandra Greiner

Chair of Applied Computer Science I, University of Bayreuth, Universitätsstrasse 30, 95440, Bayreuth, Germany

Keywords:

Round-trip Engineering, Model-driven Development, Xtend, Triple Graph Transformation Systems.

Abstract:

Model transformations are a mandatory requirement for model-driven development, a software engineering

discipline, which has become more and more popular during the last decade. Over the years, the concept

of unidirectional model transformations and corresponding tool support reached maturity since these kind

of transformations are widely used in model-driven engineering, mainly for forward engineering and code

generation. In incremental and iterative software engineering processes, forward engineering may be too

restrictive since it resembles waterfall-like processes. Thus, bidirectional transformations are required, which

aim to provide support for (incrementally) transforming one or more source model to one or more target model

and vice versa from only one transformation description. However, they seem to be rarely used in model-

driven software development as adequate tool support is missing. On the other hand, programming languages

nowadays provide support for higher-level features like closures or lambda expressions which allow to describe

transformation patterns in a declarative way. In this paper, we present an approach for round-trip engineering

between UML class models and Java source code, which is realized with a triple graph transformation system

written in the Xtend programming language.

1 INTRODUCTION

During the last few years, model-driven software en-

gineering has become more and more popular. The

main focus of model-driven software engineering is

put on the development of higher-level models rather

than on source code. Throughout the years, the Uni-

ﬁed Modeling Language (UML) (OMG, 2015b) has

been established as the standard modeling language

for model-driven development.

The Object Management Group (OMG) proposes

Model-Driven Architecture (MDA) (Mellor et al.,

2004), a result of a standardization process for

core concepts in model-driven software engineering,

which put strong emphasis on interoperability and

portability. UML serves as the standardized modeling

language for MDA. To achieve interoperability and

portability, the MDA approach uses both platform in-

dependent (PIM) and platform speciﬁc (PSM) models

and it uses UML to describe both of them.

Model transformations constitute the core essence

of model-driven software engineering and especially

MDA, where they are used, e.g., to transform PIM to

PSM models. Throughout the years, many languages

and accompanying tools have emerged (Czarnecki

and Helsen, 2006). We observe tools, which sup-

port unidirectional batch transformations, e.g. ATL

(Jouault et al., 2008), as well as languages for (incre-

mental) bidirectional transformations, as described in

the QVT standard (OMG, 2015a).

Nowadays, tools for specifying and executing uni-

directional batch transformations are mature and used

frequently in model-driven development. However,

in many scenarios transformations of this kind do not

sufﬁce: After transforming a source model into a tar-

get model, extensions and changes to the target model

may still be required. As a consequence, changes

to the source model need to be propagated such that

manual modiﬁcations of the target model are retained.

These propagations call for incremental rather than

batch transformations. Furthermore, changes to the

target model may have to be propagated to the source

model; then, transformations need to be bidirectional.

Altogether, this results in a round-trip engineer-

ing process in which source and target models may

be edited independently and changes need to be prop-

agated in both directions. While several languages

and tools have been proposed for bidirectional and in-

Buchmann, T. and Greiner, S.

Handcrafting a Triple Graph Transformation System to Realize Round-trip Engineering Between UML Class Models and Java Source Code.

DOI: 10.5220/0005957100270038

In Proceedings of the 11th International Joint Conference on Software Technologies (ICSOFT 2016) - Volume 2: ICSOFT-PT, pages 27-38

ISBN: 978-989-758-194-6

cremental transformations, there are still a number of

unresolved issues concerning both the languages for

deﬁning transformations and the respective support

tools (Stevens, 2007; Westfechtel, 2016).

As stated above, many formalisms for deﬁning

model transformations have been proposed. Besides

the approaches mentioned earlier, graphs may be used

to represent models in a natural way. As a conse-

quence, graph transformation rules describe modiﬁ-

cations of graph structures in a declarative way. Fur-

thermore, there is a comprehensive body of theories,

languages, tools, and applications (Rozenberg, 1997;

Ehrig et al., 1999).

Maintaining consistency between independent

and evolving models requires a graph transformation

system, which comprises at least the source graph

and the target graph. In order to incrementally prop-

agate changes, a correspondence graph is necessary

in between for maintaining traceability links. As a

result, a triple graph transformation system (TGTS)

is required, containing rules deﬁning source-to-target

and target-to-source transformations, as well as ac-

tions for checking consistency and repairing incon-

sistencies (Buchmann et al., 2008).

In this paper, we provide a case study dealing with

incremental round-trip engineering of UML class

models and Java source code. Our solution has been

implemented using a handcrafted TGTS written with

the Xtend

programming language.

The paper is structured as follows: Section 2 pro-

vides an overview on the proposed approach. In Sec-

tion 3 our approach is motivated while key aspects of

the implementation are described in Section 4. The

experiences gained in the case study are discussed in

Section 5 and related work is presented in Section 6.

Section 7 concludes the paper.

2 OVERVIEW

This section provides an overview on our approach.

The round-trip engineering use case presented in

this paper would require a bidirectional incremental

model-to-text transformation since the UML model is

represented as an instance of its metamodel and the

Java source code is stored using a set of text ﬁles.

However, up to now there is no language or tool avail-

able supporting this kind of transformations. Thus,

a combination of multiple transformation languages

and tools is needed to solve this issue. Figure 1 de-

picts the chosen architecture. The TGTS operates on

a correspondence model, which is placed in between

http://eclipse.org/xtend/

the UML model and a MoDisco (Bruneliere et al.,

2010) Java model. The TGTS merely addresses struc-

tural transformations, including methods with empty

bodies for user-deﬁned operations in the UML model,

and ignores accessor methods. The rules may be ex-

ecuted both in forward and backward direction. In

the forward direction, an additional M2T transforma-

tion using Acceleo is executed, which supplies the ac-

cessor methods. Please note that Acceleo allows to

protect user-deﬁned blocks within method bodies as-

suring that manually supplied code fragments remain

unchanged on subsequent transformations. The text-

to-model transformation takes Java source code and

transforms it into an instance of the Java metamodel

provided by MoDisco. We supply our own incre-

mental discoverer, as the standard discoverer works

in batch mode only. The focus in this paper is on the

TGTS which has been implemented using Xtend and

which provides bidirectional transformations between

the UML model and the MoDisco Java model. The

following subsections brieﬂy introduce Xtend and the

metamodels used in the transformation.

UML

Model

(EMF-

based)

Java

Source

Code

User Interaction

Round-trip Support

Corres-

pondence

Model

MoDisco Java

Model (EMF-

based)

TGTS

rules

TGTS

rules

MoDisco

(T2M)

edit edit

Figure 1: Round-trip support for UML CASE Tools.

2.1 Xtend

The general-purpose programming language Xtend

has its syntactical and semantical roots in the Java

programming language. However, it focuses on a

more concise syntax and extra functionality such as

type inference, extension methods and operator over-

loading. While Xtend primarily is an object-oriented

language, it also provides declarative features known

from functional programming, e.g., lambda expres-

sions. The Xtend language is statically typed and it

uses the type system of Java without modiﬁcations.

Xtend code is compiled into fully executable Java

code and thus, integrates seamlessly with all existing

Java libraries.

2.2 Used Metamodels

As explained above, we strive for round-trip engi-

neering support for UML class models and Java mod-

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

Figure 2: Some relevant parts of the Eclipse UML2 metamodel.

els representing the Java source code (by reusing the

MoDisco framework). Both metamodels are based

on Ecore (Steinberg et al., 2009), i.e. they share the

same meta-metamodel. Since most UML diagrams

lack precise and formal semantics, we restrict the case

study on the structural features of both models. Be-

havioral aspects, like the body of method declara-

tions, are not regarded in this implementation.

2.2.1 Eclipse UML2

Eclipse UML2 is part of the Eclipse Modeling

Project

. It provides an Ecore-based implementa-

tion of the OMG UML2 speciﬁcation (OMG, 2015b).

Eclipse UML2 only constitutes the abstract syntax of

UML2. Figure 2 depicts a simpliﬁed overview on rel-

evant metaclasses involved in the transformation.

Packages constitute the container elements of the

UML model tree, with a Model, which is a specializa-

tion of a Package, as the root element. Packages may

be nested and they contain PackageableElements, e.g.

Classes, Interfaces or Enumerations. Classes and in-

terfaces may contain Operations (which may have Pa-

rameters) and Propertys.

Properties and parameters have a multiplicity and

a type. Primitive types may be declared in the model

or they may be imported (importedElements). Please

note that in our case study we always import the

pre-deﬁned primitive types supplied with the Eclipse

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

UML2 implementation.

An Association is a relation between two or more

Classiﬁers

. The ends are contained as properties ei-

ther in the association or the opposite classiﬁer. De-

pending on whether both associations ends are navi-

gable, an association is said to be bidirectional or uni-

directional.

2.2.2 Java (MoDisco)

MoDisco is an extensible framework for developing

model-driven tools to support use cases of software

modernization. It provides an Ecore-compliant meta-

model for Java which resembles the AST of the Java

language. Furthermore, it provides a discovery mech-

anism, that allows to parse existing Java source code

into instances of the supplied Java metamodel. Rel-

evant cutouts of the MoDisco Java metamodel are

shown in Figure 3.

Similar to the UML2 metamodel, a Model element

constitutes the root element and contains a hierarchy

of Packages. However, in the Java metamodel, the

Model is no specialization of a Package. The model

contains primitive types (orphanTypes), as well as

ParameterizedTypes and ArrayTypes, which represent

multi-valued typed elements.

Packages may be nested (ownedPackages) and

may contain ownedElements, e.g. AbstractTypeDec-

Please note that in our approach we always assume that an

association has exactly two member ends.

Handcrafting a Triple Graph Transformation System to Realize Round-trip Engineering Between UML Class Models and Java Source Code

Figure 3: Some relevant aspects of the MoDisco Java metamodel.

laration, the metaclass of which is specialized among

others by ClassDeclaration, InterfaceDeclaration and

EnumerationDeclaration.

An AbstractTypeDeclaration contains Body-

Declarations, which can be either attributes

(FieldDeclaration) or operations (MethodDeclaration).

Both are typed elements where the type of the opera-

tion represents the returned type. Instead of accessing

this type directly, the metaclass TypeAccess provides

access to the respective type. With this layer of

indirection the interrelation of types is recorded.

The input parameters for a method are modeled as

ownedParameters with the metaclass SingleVari-

ableDeclaration. Moreover, the name of an attribute

is placed in the VariableDeclarationFragment.

The CompilationUnits referenced in the Model con-

stitute the abstraction of physical ﬁles which contain

type declarations, like classes, interfaces or enumera-

tions. They serve as anchor points for the M2T code

generation supplied by the MoDisco framework.

Both metamodels share great similarities but also

signiﬁcant differences, which led to rule explosion in

previous round-trip approaches. For instance, while

the UML metamodel has one class for all kinds of

primitive types, the Java metamodel subclasses the

base class PrimitiveType for each primitive type ex-

plicitly. Furthermore, there are elements in each

model which do not have a corresponding element

in the other one. For example, a corresponding con-

struct for an UML Association is missing in the Java

metamodel whereas a CompilationUnit is not regarded

by the UML metamodel. Furthermore, Propertys in

UML are multiplicity elements, i.e. they have a lower

and an upper bound whereas in Java arrays or collec-

tions have to be used to express this behavior.

3 MOTIVATION

Triple Graph Grammars (TGG) (Schürr, 1994) have

been proposed to make the task of specifying inter-

model consistency maintenance easier. They may

be used to formalize model transformations without

specifying a direction. The TGG execution environ-

ment automatically derives the respective forward or

backward transformation rules. On the one hand,

TGGs are highly declarative but on the other hand,

some transformations are easier to describe in an im-

perative way. In (Buchmann and Westfechtel, 2013)

the authors present an implementation of round-trip

engineering UML class models and Java source code

using TGGs. This case study unveils that many rules

have to be copied and pasted since the used TGG ap-

proach lacks concepts, like rule inheritance and im-

perative language constructs.

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

Another implementation of round-trip engineer-

ing UML class models and Java source code us-

ing the bidirectional model transformation language

QVT-R was discussed in (Greiner et al., 2016). Since

there is no reference implementation for QVT-R, the

only available tool for the Eclipse environment is me-

dini QVT, which does not fully implement the QVT-

R standard. As a consequence, the check-before-

enforce semantics is not covered and it is not quite

clear how when- and where-clauses are applied during

transformation execution. Furthermore, it is observed

that the textual syntax of QVT-R allows a concise no-

tation of the transformation rules. Still, sometimes

the rules become quite complex due to the fact that

the language does not provide constructs for specify-

ing control ﬂow or a template mechanism.

As stated in Section 1, many languages support-

ing model transformations are available, e.g. ATL

or QVT, which provide a declarative approach to de-

scribe model transformations in a concise way. How-

ever, these languages come with certain limitations:

Our use case needs a bidirectional model transfor-

mation, which has to be performed in an incremen-

tal way, in order to update existing models after sub-

sequent changes. ATL only supports unidirectional

batch transformations and thus, can not be used here.

QVT-R on the other hand, addresses incremental and

bidirectional transformations. However, as discussed

in (Greiner et al., 2016), tool support for QVT-R is far

from being mature and there are also some ﬂaws in

the ofﬁcial standard. In (Buchmann and Westfechtel,

2013), it was shown that the chosen TGG approach

comes with better tool support than QVT-R but lack-

ing rule inheritance or template mechanisms lead to

an explosion of transformation rules.

All in all, our previous work showed using QVT-R

or TGGs might become quite tedious and also corre-

sponding tool support has several weaknesses. Hand-

crafting a TGTS on the other hand, requires to spec-

ify the generation of graphs, to consider modiﬁcations

and deletions for each direction as well as to specify

rules for checking consistency and establishing corre-

spondences. The contribution of this paper is to in-

vestigate whether the effort in handcrafting a TGTS

(i.e. program both transformation directions explic-

itly) outweighs the drawbacks of the aforementioned

approaches.

4 IMPLEMENTING THE TGTS

As stated in Section 1, model transformations play a

key role in model-driven engineering. In principle,

model transformations may be programmed in an or-

dinary programming language, such as Java. This ap-

proach is still followed frequently but clearly a more

high-level approach is desired. In the past, many for-

malisms have been proposed for deﬁning model trans-

formations in the context of object-oriented modeling,

e.g. QVT (OMG, 2015a). On the other hand, graphs

may represent models in a natural way. Graph trans-

formations describe modiﬁcations of graph structures

in a declarative way. For maintaining consistency be-

tween interdependent and evolving models, a graph

transformation system is required, which deals with

at least two graphs, namely a source graph s and a

target graph t. For incremental change propagation,

a correspondence graph c is placed in between s and

t for maintaining traceability links. This results in a

triple graph transformation system (TGTS), the rules

of which deﬁne source-to-target and target-to-source

transformations, as well as actions for checking con-

sistency and repairing inconsistencies.

Developing a TGTS by hand seems to be a tedious

and laborious task: First, in addition to the generation

of graphs, modiﬁcations and deletions have to be ad-

dressed. Second, each direction of the transformation

has to be speciﬁed – as well as rules for checking con-

sistency and establishing correspondences.

4.1 Correspondence Model

In our use case, source and target models are the

Eclipse UML2 model and the MoDisco Java model

(c.f., Section 2.2) respectively. As stated above, for

incremental operations, a correspondence model is

needed. Figure 4 shows the correspondence model

used in our implementation. A Transformation con-

tains an arbitrary number of correspondence elements

(Corr).

In order to establish traceability links, a corre-

spondence element always refers to one EObject from

the source model and one EObject from the target

model. The String desc describes the element. Since

Corr is abstract in order to allow different and com-

plex specializations, we added the concrete class Ba-

sicElem without additional features which is sufﬁcient

Figure 4: Correspondence model.

Handcrafting a Triple Graph Transformation System to Realize Round-trip Engineering Between UML Class Models and Java Source Code

for our use case. If there are 1:n mappings, no addi-

tional correspondence object is created but the addi-

tional elements (2-n) are manually maintained in the

rule that transforms the 1:1 mapping.

4.2 Transformation Rules

When specifying a model transformation, the soft-

ware engineer needs to decide whether the model el-

ements should be transformed bottom-up, i.e. start-

ing with the leaf nodes of the spanning containment

tree or at the root node. As declarative approaches

perform a topological sort of model elements, soft-

ware developers only have very limited inﬂuence on

the transformation order. Typically, the developer

must presume the execution behavior when declaring

the rules. When hand-crafting a TGTS on the other

hand, the transformation order is fully under the con-

trol of the user. We chose to strictly follow a top-

down approach on the highest level (i.e. on the el-

ement level). As a consequence, when transforming

child elements, e.g. attributes or methods of classes,

we can always be sure that the respective containers

and the referred types already exist. Therefore, our

transformation starts at the respective root elements

(i.e. the Model in both cases) and the primitive types.

Next, the Package hierarchy is established. Once this

is ﬁnished, type declarations (classes, interfaces, enu-

meration) and associations are transformed followed

by the respective inheritance relationships. We further

tackle properties and methods afterwards.

As we are hand-crafting our TGTS (unlike in pre-

vious approaches (Greiner et al., 2016; Buchmann

and Westfechtel, 2013), where bidirectional model

transformation formalisms were used), we need to ex-

plicitly specify both transformation directions. Fur-

thermore, we need to address creation, deletion or up-

date of existing elements. To reduce the speciﬁcation

effort, we made use of the fact that Xtend builds on

the Java VM and it provides mechanisms for inheri-

tance and method overloading. Listing 1 provides a

cutout of the abstract base class for all transformation

rules.

The base class consists of the three resources

sourceModel, targetModel and corrModel, which are

not shown in Listing 1 due to space restrictions and

which are created or kept consistent during the trans-

formations. The methods sourceToTarget() and tar-

getToSource() are overridden in each class inheriting

from Elem2Elem. The respective implementations

contain the transformation rule for the corresponding

elements for each transformation direction. The su-

per rule, which is executed in the overriding meth-

ods at last (e.g., Listing 2, line 9,18), ensures that

all unreferenced elements, where the umlElement or

the javaElement are empty, are deleted and saves the

transformation (Listing 1, line 6,11). The String given

to the deletion calls (Listing 1, line 4,9) can be used to

adapt the behavior for speciﬁc elements, e.g. deleting

elements without a correspondence object.

Listing 1: Abstract base class for our transformation rules.

1 ab st r act c las s E le m 2El e m {

2 .. .

3 de f vo id so urc e T oT a r get ( S tri ng s ) {

4 d el e t e U nre f e r enc e d T a rg e t E l eme n t s (s )

5 co r rMo d el . s av e ( nu ll )

6 ta r g et M o de l . sav e ( nul l )

7 }

8 de f vo id ta rge t T oS o u rce ( S tri ng s ) {

9 d el e t e U nre f e r enc e d S o ur c e E l eme n t s (s )

10 co r rMo d el . s av e ( nu ll )

11 so u r ce M o de l . sav e ( nul l )

12 }

13 de f Co rr ge tCo r r Mod e l El e m ( E Ob j ec t ob ) {

14 co r r Mo d el . co n te n ts . g et (0) . co r res p o nd e n c es

15 . f i ndF i rs t [ c | c. um l El e m en t == ob || c .

jav a Ele m ent == ob ]

16 }

17 de f g e tOr C r e ate C o r rMo d e l Ele m e n t ( EO b je c t ob ,

St r in g d e sc r i pt i o n ) {

18 v ar Co rr c = ob . g e tC o r rMo d e lEl e m

19 if (c == null ) {

20 c = c o rrF a cto r y . c re a t e Ba s i cEl e m => [

21 if ( o b . e C la s s . EP a ck a ge ins t an c e of

UML P ac k a ge )

22 u m lE l e me n t = ob

23 if ( o b . e C la s s . EP a ck a ge ins t an c e of

Jav a Pac k age )

24 j a va E l em e n t = ob

25 des c = de s c ri p t io n

26 ]

27 co r rMo d el . c o nte nts . ge t (0) . c o r re s p ond e n ce s

+= c

28 }

29 r e tu r n c

30 } }

The methods getOrCreateModelElement and get-

CorrModelElem maintain the traceability links in the

correspondence model. Within the transformation

rules sourceToTarget and targetToSource the method

getOrCreateModelElement is called (e.g., Listing 2,

line 5,14) to extract the element to be created. The

call parameters are:

EObject ob The context object on which the method

is called

String description The description identifying the

correspondence elements

This method calls getCorrModelElem which re-

trieves the requested object from the correspondence

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

model if it is already present. If a correspondence ob-

ject cannot be found for the given element, it will be

created (Listing 1, line 20) and stored in the respec-

tive EReference (umlElement or javaElement). Please

note that for each of the subsequent descriptions the

source represents the UML model and the target in-

dicates the Java model. Accordingly, if the method

sourceToTarget is called, a transformation from the

UML model to the Java model is performed and vice

versa in case of calling targetToSource. We further

denote the source to target as forward and the oppo-

site as backward direction.

The redeﬁnitions of the methods sourceToTarget

and targetToSource always consist of the following

basic steps: First, the resource of the speciﬁed direc-

tion is searched for the element transformed in the re-

spective rule. Next, the correspondence element is

extracted with the aforementioned method getOrCre-

ateCorrespondenceModelElement. From the returned

element the target object for the respective direction

is either extracted – if it already exists – or created

and added to the correspondence element as umlEle-

ment or javaElement by the methods getOrCreate-

SourceElem and getOrCreateTargetElem respectively

(Listing 2, line 5,14). This way an already existing

correspondence and target element can be altered in-

crementally

. Thereafter, the basic properties of the

target element for the respective direction are updated

or added.

Listing 2: Class to transform the root elements of both models.

1 cla s s M od e l2M o del ex te n ds El em 2 Ele m {

2 o v er r id e v oi d s our c e To T a rge t ( S tr i ng s ) {

3 sou r ceM o del . c o nt e nts . f il t er ( t ype of ( org .

ec l ip s e . um l2 . um l . Mode l ) )

4 . f o rE a ch [ m |

5 v ar targ = m . ge t O rC r e a t eC o r r M od e l E l em e n t (s

) . g e t O rC r e a teT a r g et E l e m ( J av a Pac k age .

eI N S TA N CE . mo de l )

6 t ar g . na me = m. na me

7 ta r g et M o de l . c o nt e nt s += ta rg

8 ]

9 s upe r . sou r c eT o T arg e t (" mo de l ")

10 }

11 o v er r id e v oi d t arg e t To S o urc e ( S tr i ng s ) {

12 tar g etM o del . c o nt e nts . f il t er ( t ype of ( M od e l ) )

13 . f o rE a ch [ m |

14 va r src = m. g e t O rC r e a teC o r r Mod e l E lem e n t (s

) . g e t O rC r e a teS o u r ce E l e m ( UML P ack a ge .

Li t era l s . MO DE L )

15 sr c . name = m . name

16 s o ur c e Mo d e l . co n ten t s += s rc

Incremental means that the target and correspondence ele-

ment will not be created anew if they already exist. Their

properties, on the other hand, are overwritten. Otherwise,

one would have to calculate or track the differences be-

tween the previous and the current version ﬁrst.

17 ]

18 s upe r . tar g e tT o S our c e (" mo de l ")

19 } }

For the Model2Model rule seen in Listing 2 this only

comprises the name attribute. Afterwards, the cre-

ated or updated model is added to the targetModel or

sourceModel respectively. The metaclass Model is the

root for the respective metamodel, i.e. there should

only exist one Model element. Other references of the

Models, e.g. the orphanTypes of the Java Model, are

maintained in the transformation of the referenced el-

ements.

The transformation of models (and, e.g. pack-

ages and classes) are declared fairly straightforward

because the metamodels share many features and are

almost 1:1 mappings. Treating UML associations,

which have no corresponding concept in the Java

model, is more complex, for instance. We decided

to add a ClassDeclaration in the Java model for every

association. This class contains both memberEnds of

the association as ﬁelds and corresponding accessor

methods with proper visibilities that reﬂect the navi-

gability as speciﬁed in the UML model

. The corre-

spondence element with the description "association"

always points to an Association as umlElement and a

ClassDeclaration as javaElement.

Listing 3 presents a simpliﬁcation of how a class

is created for an association and vice versa. The cre-

ated class is added to the package of the association

(Listing 3, line 7), receives the name of the asso-

ciation and stores all memberEnds as bodyDeclara-

tions. As each classiﬁer needs a CompilationUnit in

the Java model, it is created or updated by reusing the

method getOrCreateCompU in line 8 that supports all

kinds of AbstractTypeDeclarations. The Compilatio-

nUnit is added to the Java model without creating a

separate correspondence element because the UML

association is already mapped to the corresponding

Java class. Thus, it is necessary to manually update

or delete the CompilationUnit in case the correspond-

ing association is modiﬁed or removed. The update

is performed in the method getOrCreateCompU, the

deletion in the method deleteUnreferencedTargetEle-

ments (Listing 1, line 4).

Listing 3: Class to transform the UML associations to Java classes.

1 cla s s A sso c i at i o n 2C l a s s e xt e nd s E l em 2 Ele m {

2 o v er r id e s o u rce T o Ta r g et ( St rin g s ) {

3 sou r ceM o del . a l l Co n t en t s . fi l te r ( typ eo f (

Ass o cia t ion ) )

This class serves as 1:1 mapping for the association (but

not for its ends) and can be extended for more general

UML concepts like, e.g. n-ary associations.

Handcrafting a Triple Graph Transformation System to Realize Round-trip Engineering Between UML Class Models and Java Source Code

4 . f o rE a ch [ a |

5 va r c l = a. g e t O rC r e a t eC o r r M od e l E l em e n t (s

) . g e t O rC r e a teT a r g et E l e m ( J av a Pac k age

. e I NST A NC E . c l a ss D e cla r a tio n )

6 cl . nam e = a . name . t oF i r stU p per ()

7 a. pa c ka g e . co r r M od e l E le m e nt . ja v a El e m en t .

own e d El e m en t s += cl

8 cl . or i g i nal C o m pil a t i on U n i t =

get O r Cre a t eC o m p U ( cl )

9 if ( c l . c o mm e nts . s iz e = = 0)

10 cl . co m me n ts + = jF ac t . c re a t eJ a v ado c

11 cl . co m me n ts . get (0) . c o nt e nt = "/

@associationClass" + cl.name + "

13 . ..

14 ]

15 s upe r . sou r c eT o T arg e t (s )

16 }

17 o v er r id e t a r get T o So u r ce ( St rin g s ) {

18 tar g etM o del . a l l Co n t en t s . fi l te r ( typ eof (

Cla s s Dec l a ra t i o n ) ) . fi lt e r [ c d |

19 cd . c om m en t s . si ze > 0 && cd . co mm e nts . ge t (0) .

co n te n t . co n tai n s ( ’ @a s so c iat i on C la s s ’ ) ]

20 . f o rE a ch [ cd |

21 v ar a ss oc = cd . g e tOr C r e ate C o r rMo d e l Ele m e n t

( s). g e tO r C r eat e S our c e E le m ( U M L Pa c kag e .

eI N S TA N CE . as s oci a tio n )

22 a sso c . name = cd . nam e . t oF i r st L o wer

23 a sso c . pa c ka g e = c d . pa ck a ge .

cor r M ode l E le m e n t . uml E le m e nt

24 ]

25 s upe r . tar g e tT o S our c e (s )

26 } }

To distinguish between association classes and

“regular” classes, we annotate them with a Javadoc

comment (Listing 3, line 11f.). Thus, we can identify

annotated classes in the backward direction and build

up the Association correspondingly. The name is ex-

tracted from the ClassDeclaration (Listing 3, line 22)

and the right package (Listing 3, line 23) is set. The

memberEnds are treated like other properties with the

next rules.

Listing 4 shows the forward transformation of

properties of all kinds. If they are of primitive type,

they will be added to the containing classiﬁer. If they

belong to an association, the method setOwnerJava

(Listing 4, line 5) will add both memberEnds as body-

Declarations to the corresponding introduced associ-

ation class. Furthermore, this method applies com-

ments whether the end is owned by the association or

the class and whether it is navigable.

Listing 4: Transformation for UML properties.

1 ov er r ide d ef s o urc e T oT a r get ( S t ri ng s ) {

2 s o urc e Mod e l . a ll C o nt e n ts . f i lt er ( ty pe o f (

Pr o per t y ) )

3 . for Eac h [ p |

4 v ar fd = p . ge t O r Cre a t e Cor r M o del E l e men t ( s).

get O r C re a t e Tar g e t El e m ( J a va P a ck a g e .

eI N S TA N CE . fi e l dDe c l ara t i on )

5 se t O wn e r Jav a (p , f d )

6 fd . o r igi n a l Com p i l at i o n Uni t = fd .

abs t r a ctT y p e De c l a rat i o n .

ori g i n alC o m p il a t i onU n i t

7 se t N am e J av a (p , fd )

8 se t T yp e J av a (p , fd )

9 se t V isi b i li t y (p , f d )

10 ]

11 sup e r . so u r ceT o T ar g e t ( s ) }

In the backward direction depicted in Listing 5 these

comments are used to construct the memberEnds.

The method setOwnerUML (Listing 5, line 7) deter-

mines from the annotation whether the end is navi-

gable or not and whether it is owned by the associa-

tion. As a consequence, it will add the created prop-

erty to either one of the classes participating in the

association or to the association as one of the owne-

dEnd or the navigableOwnedEnd references. The type

is determined with the method setTypeUML. In case

the type of the property is primitive, the property is

simply added to the UML classiﬁer corresponding

with the abstractTypeDeclaration of the Java ﬁeld. If

the type is a ParameterizedType or an ArrayType, the

value upper of the UML Property will be set to inﬁn-

ity. Moreover, in the latter case the UML type can-

not be retrieved from the correspondence element in a

straightforward way but the typeArguments and types

respectively must be used to obtain the corresponding

umlElement.

Listing 5: Transformation of Java FieldDeclarations.

1 ov er r ide ta rge t T oS o u rce ( S t ri ng s ) {

2 t a rge t Mod e l . a ll C o nt e n ts . f i lt er ( ty pe o f (

Fie l d Dec l a ra t i o n ) )

3 . for Eac h [ fd |

4 v ar p = fd . ge t O r Cre a t e Cor r M o del E l e men t ( s).

get O r C re a t e Sou r c e El e m ( U M LP a c ka g e .

Li t era l s . PR O PE R TY )

5 p . n am e = f d . f r a gm e nt s . ge t (0) . na me

6 se t Typ e UML ( f d , p )

7 se t O wn e r UM L (fd , p )

8 . ..

9 ]

10 s up er . ta r g et T o Sou r c e ( s ) }

4.3 Round-trip Example

This section provides a brief example to illustrate a

simple round-trip scenario in our use case.

Figure 5 depicts the single transformation steps. It

provides cutouts of the UML abstract syntax as well

as of the resulting Java model in the Ecore tree rep-

resentation. The transformation starts with a given

UML model and an empty Java model. Subsequent

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

Figure 5: Example round-trip scenario.

changes are added incrementally. In the initial model

many persons may live at one Address where the ends

of the association lives at are contained in the re-

spective opposite class. This indicates an association

which is navigable in both directions. Transform-

ing in the forward direction results in three classes

where the ends are added as ﬁelds in the associa-

tion class. However, the comment of the ﬁelds reg-

isters the classes participating in the association as

owner of the ﬁelds (1) by noting a "type" instead of

an "association". Transforming backward correctly

results in the original model. Next, the association be-

comes owner of the person end in the UML instance

(2). Transforming forward again adapts the comment

of the corresponding ﬁeld and notes that the owner

is now the association (3). Thereafter, it is decided

that a person might live at different addresses so the

class Address is replaced by an ParameterizedType

that serves as a collection for many Address instances

(4). These changes are propagated back to the UML

model when applying an incremental backward trans-

formation: the property address is now multi-valued

(5) and the person end is still contained in the associ-

ation (6).

5 DISCUSSION

This section discusses the lessons learned from im-

plementing a bidirectional model transformation with

a hand-crafted TGTS written in Xtend. The integra-

tion of the system, on the other hand, is yet to come

and the evaluation will be published separately.

Basically, we can categorize the relations between

source and target model elements into 1:1 mappings

(e.g., a UML package and a Java package) and 1:n (a

UML class and a Java ClassDeclaration, a Java Com-

pilatonUnit and a ParameterizedType) mappings. We

found out that 1:1 mappings are straightforward and

easy to implement and that additional elements in the

involved models may be added without restrictions:

For instance, a UML class needs a corresponding Java

ClassDeclaration and the ClassDeclaration always be-

longs to a CompilationUnit which must be included ad-

ditionally in the Java model.

In contrast to purely declarative approaches, lan-

guage features, like inheritance or generics, can be

used seamlessly in the Xtend language. While the

lack of these features in the QVT-R or the TGG ap-

proach leads to a combinatorial explosion in the num-

ber of rules which have to be copied and pasted, e.g.

in case that a rule needs to be invoked for subclasses

of an (abstract) super type, we were able to express

Handcrafting a Triple Graph Transformation System to Realize Round-trip Engineering Between UML Class Models and Java Source Code

the same behavior within a single rule in the TGTS.

Listings 4 and 5 show that complex assignments

can easily be moved to operations, which may be

reused from various places – a feature which is com-

mon in object-oriented programming languages but

which is lacking in (declarative) model transforma-

tion languages. Please note, that QVT-R allows to

specify queries which could also be reused in arbi-

trary places but only without side-effects, while non-

top level relations can also be called from other rules

and may contain side-effects.

The downside of the presented approach is that

both transformation directions have to be speciﬁed

explicitly. Hence, whenever the metamodels are

changed in a way that requires adapting the transfor-

mation rules, these changes have to be performed at

different places inside the transformation script. It

is up to the software engineer to ensure a consistent

modiﬁcation throughout the script. Moreover, allow-

ing only 1:1 correspondences affords to keep the 2-

n other elements manually consistent in incremental

transformations which results in an imminent danger

of introducing inconsistencies by mistake.

The alternative of using 1:n correspondences in

the trace model would require to keep track which

additional elements are mapped and stored at which

position. This complicates the rules signiﬁcantly and

requires users to know the mapping assumptions. If,

for instance, a class was mapped to a class, a Compi-

lationUnit, and a ParameterizedType, this would result

in a collection of three different Java elements that

must be treated separately. Thus, the user must be

sure which of the mapped elements is of which type.

Another problem of the current approach are ele-

ments that have no corresponding partner in the op-

posite model, i.e. "0:1" mappings. In general, these

elements cannot be created in advance or at the end

of the transformation since they may reference other

elements that are created during the transformation or

they may be referenced by other elements. For in-

stance, the collection container in the Java model has

no partner element in the opposite model. Thus, the

user needs to manually add and update such an ele-

ment by calling a respective operation when required

during the transformation.

Nevertheless, in a generic base rule the current ap-

proach is able to describe the parts dealing with the

trace links between the model elements and locating

changes. Consequently, the concrete rules only de-

scribe the changes using Xtend’s lambda expressions.

In total, it took 1121 lines of Xtend code to specify

the transformation rules, compared to 2947 lines of

QVT-R code. Hence, for the transformation problem

in this case study, the usage of a declarative language

(which should provide a more concise and compact

solution) required almost three times the number of

lines of code than using a modern imperative lan-

guage with lambda expressions.

One note on testing our implementation: Another

beneﬁt of the approach presented in this paper is

the fact that each Xtend speciﬁcation can easily be

tested automatically with the help of JUnit test cases.

Moreover, even those test cases may be written us-

ing Xtend. We supplied an extensive set of test cases

for each rule and tested model modiﬁcations for both

transformation directions (creation, update and dele-

tion of respective model elements). Being able to

run automated tests is a considerable improvement

over our previous TGG (Buchmann and Westfechtel,

2013) and QVT-R (Greiner et al., 2016) implemen-

tations, where all of those tests had to be carried out

manually in a tedious and time consuming procedure.

Apart from this use case, our correspondence

model is generic enough to be reused with other bidi-

rectional model transformations. Having correspon-

dence elements that map one element of a source to

one element of a target model is the most natural map-

ping present in transformations. Non-bijective map-

pings always need further consideration and are more

likely to be established manually since these trans-

formations are hard to automate. For traceability and

managing the transformation incrementally the result-

ing correspondence graph serves as persisted trace in-

formation. As a consequence, one could think about

writing a DSL on top of Xtend allowing to specify

transformation patterns.

6 RELATED WORK

Common approaches that are used to transform text

(e.g. source code) to models are based on parsers for

the speciﬁc text languages. Usually, these approaches

work on the resulting parse trees and map the tree

items to corresponding model elements. Typical lim-

itations are maintenance problems when the underly-

ing M2T templates are changed.

In (Bork et al., 2008), Bork et al. describe an ap-

proach towards model and source code round-trip en-

gineering, which is based on reverse engineering of

M2T transformation templates. The idea of this ap-

proach is to use (customizable) code generation tem-

plates as a grammar to parse the generated (and later

modiﬁed) code. The beneﬁt of this approach com-

pared to other approaches using plain Java parsers

and the resulting parse tree as a source for the code

to model transformation is that changes to the tem-

plates are automatically taken into account during re-

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

verse engineering. While the approach described in

(Bork et al., 2008) requires considerable implemen-

tation effort since a template parser, reasoner and to-

ken creator have to be implemented, our approach just

required the speciﬁcation of respective Xtend rules

that relate two elements of the respective metamod-

els. Since MoDisco is able to parse source code which

even contains syntax or compile errors into a corre-

sponding Java model, our approach is also indepen-

dent of the style of the generated code and it also does

not depend on a (usually) ﬁne grained parse tree. Fur-

thermore, Javadoc tags can be used to add additional

meta-information to the code. While the approach

presented in (Bork et al., 2008) is able to round-trip

engineer only code that has been generated with the

corresponding templates, our approach is able to han-

dle any code which complies to Java language speci-

ﬁcation version 5. In addition, the approach by Bork

et al. requires bijective reversible templates. E.g. the

approach will fail if an attribute name in a class con-

tains the class name.

Angyal et al. present in (Angyal et al., 2008) an

approach for model and code round-trip engineering

based on differencing and merging of abstract syntax

trees (AST). In this approach, the AST is regarded

to be the platform-speciﬁc model (PSM) according to

the taxonomy of models in MDA (Mellor et al., 2004).

Nevertheless, in this approach the AST model has a

very low level of abstraction because it exactly rep-

resents the code. Contrastingly, the discovered Java

model which is used in our approach is on a higher

level of abstraction. The round-trip engineering ap-

proach comprises two different round-trip tasks: one

between PIM and PSM and one between PSM and

code. The approach tries to prevent information loss

during round-trip engineering by using a so called

trace model which is used to synchronize the PIM and

the PSM (the AST). Furthermore, the AST and the

source code are updated using a ﬁne grained bidirec-

tional incremental merge based on three-way differ-

encing. In our approach, information loss is prevented

by using Javadoc tags as annotations. In case model

and code are changed simultaneously and the changes

are contradicting, one transformation direction has to

be chosen, which causes that some changes might get

lost.

There are also approaches that are dedicated

to model-to-model round-trip engineering. This

task involves synchronizing models and keeping

them consistent. Antkiewicz and Czarnecki pro-

pose an approach towards round-trip engineering

for framework-speciﬁc modeling languages (FSML)

(Antkiewicz and Czarnecki, 2006). FSMLs are a

special category of DSLs which are deﬁned on top

of object-oriented application frameworks. In con-

trast to general round-trip engineering approaches,

the approach presented in (Antkiewicz and Czarnecki,

2006) does not have to deal with non-isomorphic

mappings between the artifacts, as the problem do-

main is much smaller and only code for a speciﬁc

framework is generated by the code generators of the

FSML. The synchronization of the involved imple-

mentation model is based on a comparison inspired

by CVS and reconciliation. In a last step, conﬂict res-

olution has to be carried out interactively by the user.

Hettel et al. (Hettel et al., 2009) propose an ap-

proach towards model round-trip engineering based

on abductive logic programming. In particular, this

approach does not place restrictions such as injective

behavior on the underlying transformations. A ref-

erence implementation is given which can be used

to reverse unidirectional transformations based on the

Tefkat language. It is a general approach, which could

also be applied to other model transformation lan-

guages, like QVT. However, since the source transfor-

mation does not necessarily need to be injective, am-

biguities have to be solved when reversing the trans-

formation. At the end, the “best” solution has to be

picked by the user or it has to be determined using

some kind of heuristics.

7 CONCLUSION AND FUTURE

WORK

In this paper, we presented a solution for incremen-

tal round-trip engineering between UML class mod-

els and Java source code, using a hand-crafted triple

graph transformation system (TGTS) written with the

Xtend programming language.

While nowadays tool support for model trans-

formation mostly covers unidirectional batch trans-

formation, this use case demands for a bidirectional

transformation, which works in an incremental man-

ner. However, our previous research revealed that

there is no adequate tool support to solve this prob-

lem.

To this end, we chose to code both transformation

directions explicitly using the Xtend language. We

exploited lambda expressions to describe the graph

patterns of our TGTS in a declarative way and made

use of the traditional imperative programming style

whenever it was appropriate.

Future work comprises a quantitative and qualita-

tive evaluation of our three implemented solutions for

incremental round-trip engineering.

Handcrafting a Triple Graph Transformation System to Realize Round-trip Engineering Between UML Class Models and Java Source Code

REFERENCES

Angyal, L., Lengyel, L., and Charaf, H. (2008). A synchro-

nizing technique for syntactic model-code round-trip

engineering. In Proceedings of the 15th International

Conference on the Engineering of Computer Based

Systems (ECBS 2008), pages 463–472.

Antkiewicz, M. and Czarnecki, K. (2006). Framework-

speciﬁc modeling languages with round-trip engineer-

ing. In Proceedings of the 9th International Confer-

ence on Model Driven Engineering Languages and

Systems (MoDELS 2006), LNCS 4199, pages 692–

706, Genova, Italy.

Bork, M., Geiger, L., Schneider, C., and Zündorf, A. (2008).

Towards roundtrip engineering - a template-based re-

verse engineering approach. In Schieferdecker, I.

and Hartman, A., editors, ECMDA-FA, volume 5095

of Lecture Notes in Computer Science, pages 33–47.

Springer.

Bruneliere, H., Cabot, J., Jouault, F., and Madiot, F. (2010).

MoDisco: a generic and extensible framework for

model driven reverse engineering. In Proceedings

of the IEEE/ACM international conference on Auto-

mated software engineering, ASE ’10, pages 173–

174, New York, NY, USA. ACM.

Buchmann, T., Dotor, A., and Westfechtel, B. (2008). Triple

graph grammars or triple graph transformation sys-

tems? In Chaudron, M. R. V., editor, Models in Soft-

ware Engineering, Workshops and Symposia at MOD-

ELS 2008, Toulouse, France, September 28 - October

3, 2008. Reports and Revised Selected Papers, volume

5421 of Lecture Notes in Computer Science, pages

138–150. Springer.

Buchmann, T. and Westfechtel, B. (2013). Towards in-

cremental round-trip engineering using model trans-

formations. In Demirors, O. and Turetken, O., edi-

tors, Proceedings of the 39th Euromicro Conference

on Software Engineering and Advanced Applications

(SEAA 2013), pages 130–133. IEEE Conference Pub-

lishing Service.

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

vey of model transformation approaches. IBM Sys-

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

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

editors (1999). Handbook on Graph Grammars and

Computing by Graph Transformation, volume 2: Ap-

plications, Languages, and Tools. Singapore.

Greiner, S., Buchmann, T., and Westfechtel, B. (2016).

Bidirectional Transformations with QVT-R: A Case

Study in Round-trip Engineering UML Class Models

and Java Source Code. In Proceedings of the 4th In-

ternational Conference on Model-Driven Engineering

and Software Development (MODELSWARD 2016).

accepted for publication.

Hettel, T., Lawley, M., and Raymond, K. (2009). To-

wards model round-trip engineering: An abductive

approach. In Proceedings of the 2nd International

Conference on Theory and Practice of Model Trans-

formations (ICMT 2009), LNCS 5563, pages 100–

115, Zurich, Switzerland.

Jouault, F., Allilaire, F., Bézivin, J., and Kurtev, I. (2008).

Atl: A model transformation tool. Science of Com-

puter Programming, 72:31 – 39. Special Issue on Sec-

ond issue of experimental software and toolkits (EST).

Mellor, S. J., Kendall, S., Uhl, A., and Weise, D. (2004).

MDA Distilled. Addison Wesley Longman Publishing

Co., Inc., Redwood City, CA, USA.

OMG (2015a). Meta Object Facility (MOF) 2.0

Query/View/Transformation Speciﬁcation. Needham,

MA, formal/2015-02-01 edition.

OMG (2015b). Uniﬁed Modeling Language (UML). Object

Management Group, Needham, MA, formal/15-03-01

edition.

Rozenberg, G., editor (1997). Handbook on Graph Gram-

mars and Computing by Graph Transformations, vol-

ume 1: Foundations. Singapore.

Schürr, A. (1994). Speciﬁcation of Graph Translators with

Triple Graph Grammars. In Proceedings of the 20th

International Workshop on Graph-Theoretic Concepts

in Computer Science (WG 1994), volume 903 of

LNCS 903, pages 151–163, Herrsching, Germany.

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

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

Eclipse Series. Boston, MA, 2nd edition.

Stevens, P. (2007). Bidirectional Model Transformations

in QVT: Semantic Issues and Open Questions. In

Proceedings of the 10th International Conference on

Model Driven Engineering Languages and Systems

(MoDELS 2007), LNCS 4735, pages 1–15, Nashville,

USA.

Westfechtel, B. (2016). A Case Study for a Bidirectional

Transformation Between Heterogeneous Metamodels

in QVT Relations. In Maciaszek, L. A. and Filipe,

J., editors, Evaluation of Novel Approaches to Soft-

ware Engineering, volume 599 of Communications

in Computer and Information Science (CCIS), chap-

ter 8, pages 141–161. Springer International Publish-

ing. Revised Selected Papers from ENASE 2015.

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends