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-
fied 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 specific (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
suffice: 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 modifications 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
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
27
cremental transformations, there are still a number of
unresolved issues concerning both the languages for
defining transformations and the respective support
tools (Stevens, 2007; Westfechtel, 2016).
As stated above, many formalisms for defining
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 modifi-
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 defining 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
1
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 files.
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
1
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-defined 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-defined 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 briefly 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 modifications.
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
28
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
2
. It provides an Ecore-based implementa-
tion of the OMG UML2 specification (OMG, 2015b).
Eclipse UML2 only constitutes the abstract syntax of
UML2. Figure 2 depicts a simplified 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-defined primitive types supplied with the Eclipse
2
http://www.eclipse.org/modeling/
UML2 implementation.
An Association is a relation between two or more
Classifiers
3
. The ends are contained as properties ei-
ther in the association or the opposite classifier. 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-
3
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
29
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 files 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
significant 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
30
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 flow 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 flaws in
the official 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 modifications
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 defining 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 modifications 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 define 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, modifications and deletions have to be ad-
dressed. Second, each direction of the transformation
has to be specified 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 sufficient
Figure 4: Correspondence model.
Handcrafting a Triple Graph Transformation System to Realize Round-trip Engineering Between UML Class Models and Java Source Code
31
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 influence 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 finished, 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 specification
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 specific 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
32
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 redefinitions of the methods sourceToTarget
and targetToSource always consist of the following
basic steps: First, the resource of the specified 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
4
. 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
4
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 first.
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 fields and corresponding accessor
methods with proper visibilities that reflect the navi-
gability as specified in the UML model
5
. The corre-
spondence element with the description "association"
always points to an Association as umlElement and a
ClassDeclaration as javaElement.
Listing 3 presents a simplification 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 classifier 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 modified 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 ) )
5
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
33
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 = "/
**
12
*
@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 classifier. 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 classifier corresponding
with the abstractTypeDeclaration of the Java field. If
the type is a ParameterizedType or an ArrayType, the
value upper of the UML Property will be set to infin-
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
34
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 fields in the associa-
tion class. However, the comment of the fields reg-
isters the classes participating in the association as
owner of the fields (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 field 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
35
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 specified
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
modification 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 significantly 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
benefit of the approach presented in this paper is
the fact that each Xtend specification 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 modifications 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 specific 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
modified) code. The benefit 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
36
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 specification 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) fine 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-
fication 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-specific 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 fine 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-specific modeling languages (FSML)
(Antkiewicz and Czarnecki, 2006). FSMLs are a
special category of DSLs which are defined 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 specific
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, conflict 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
37
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-
specific 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 Specification. Needham,
MA, formal/2015-02-01 edition.
OMG (2015b). Unified 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). Specification 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
38