Bidirectional Transformations with QVT-R: A Case Study in Round-trip

Engineering UML Class Models and Java Source Code

Sandra Greiner, Thomas Buchmann and Bernhard Westfechtel

Chair of Applied Computer Science I, University of Bayreuth, Universit

atsstrasse 30, 95440, Bayreuth, Germany

Keywords:

Bidirectional Transformations, UML, QVT, Java, Round-trip Engineering, Model Transformation.

Abstract:

Model-driven software engineering has become more and more important during the last few years. Model

transformations constitute the core essence of model-driven development. Throughout the years, the con-

cept of unidirectional model transformations and corresponding tool support has become mature and usable.

Transformations of this kind are widely used in model-driven development, for forward or reverse engineering

or mainly for code generation. Bidirectional transformations, on the other hand, aim to provide support for

(incrementally) transforming one or more source models to one or more target models and vice versa from

only one transformation description. However, they seem to be rarely used in model-driven software develop-

ment although modelers need round-trip support between the different stages of development models. In this

paper we present a QVT implementation of a bidirectional model transformation. Our case study keeps UML

class diagrams consistent with a Java model during round-trip engineering and thereby shows a real world

application. The results and experiences gained in this case study are discussed in detail.

1 INTRODUCTION

Model-driven software engineering is a discipline

which puts strong emphasis on the development of

higher-level models rather than on source code. Over

the years, UML (OMG, 2011c) has been established

as the standard modeling language for model-driven

development.

The basic idea behind UML is providing a stan-

dardized modeling language for the Model-Driven Ar-

chitecture (MDA) (Mellor et al., 2004) approach prop-

agated by the Object Management Group (OMG).

MDA is the result of a standardization process for

core concepts in model-driven software engineering

focusing on interoperability and portability. Thus,

the MDA approach uses both platform independent

(PIM) and platform speciﬁc (PSM) models and it uses

UML to describe both of them. UML itself con-

sists of several parts: (1) The Infrastructure (OMG,

2011b) deﬁnes the core of the meta language which

serves as the base for the architecture while the (2)

Meta Object Facility (MOF) (OMG, 2011a) deﬁnes

a meta-modeling language which uses and extends

the abstract syntax deﬁned in the Infrastructure. (3)

The UML Superstructure (OMG, 2011c) deﬁnes all

kinds of UML diagrams and serves as the metamodel

speciﬁcation for all UML modeling tools. (4) XMI

(XML Metadata Interchange) is intended to serve as

an interchange mechanism between UML tools and

as an input format for code generators or interpreters.

(5) Finally, the Object Constraint Language (OCL)

(OMG, 2012) provides a formal textual syntax based

on concepts of set theory and predicate logic to reﬁne

models with queries and constraints.

Model-driven software engineering is supported

by model transformations. A wide range of lan-

guages and tools have been developed (Czarnecki and

Helsen, 2006), including e.g. QVT (QVT, 2015) and

ATL (Jouault et al., 2008). At present, the technology

for deﬁning and executing unidirectional batch trans-

formations seems to be fairly well developed. How-

ever, in many scenarios transformations of this kind

do not sufﬁce: After transforming a source model

into a target model, extensions and changes of the tar-

get 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. Change propagations call for incremen-

tal rather than batch transformations. Furthermore,

changes to the target model may have to be reﬂected

in the source model; then, transformations need to be

bidirectional. Altogether, this results in a round-trip

engineering process in which source and target mod-

els may be edited independently and changes need

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

Bidirectional Transformations with QVT-R: A Case Study in Round-trip Engineering UML Class Models and Java Source Code.

In Proceedings of the 4th International Conference on Model-Driven Engineer ing and Software Development (MODELSWARD 2016), pages 15-27

ISBN: 978-989-758-168-7

to be propagated in both directions. While several

languages and tools have been proposed for bidirec-

tional and incremental transformations, there are still

a number of unresolved issues concerning both the

languages for deﬁning transformations and the re-

spective supporting tools (Stevens, 2007).

In this paper, we provide a case study dealing with

incremental round-trip engineering of UML class

models and Java source code. We use the MoDisco

(Bruneliere et al., 2010) framework to parse the Java

source code into a model representation. QVT-R

is used to formalize a bidirectional model-to-model

transformation between the UML model and the Java

model. This aspect is an interesting feature of QVT-

R, as a transformation developer may provide a sin-

gle relational speciﬁcation which may be executed in

both directions, rather than writing two unidirectional

transformations separately. Moreover, QVT-R is cho-

sen because of its declarative nature where the devel-

oper is supposed to focus on relations and dependen-

cies between the metamodels rather than on single ex-

ecution steps. Triple graph grammars (Sch

urr, 1994)

also provide powerful means to specify bidirectional

transformations. While there exist several tools sup-

porting TGGs (Leblebici et al., 2014), the TGG ap-

proach is not standardized and therefore we decided

to use QVT instead.

The usage scenario serves as a real-world case

study to evaluate the beneﬁts and drawbacks of the

QVT-R standard in general and the provided tool sup-

port in particular.

The paper is structured as follows: In Section 2

we discuss related work. Section 3 presents the meta-

models used in our approach while excerpts of our

implementations and the results are shown in Section

4. The results are further discussed in Section 5 while

Section 6 draws a conclusion.

2 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

approach towards model and source code round-trip

engineering, which is based on reverse engineering

of M2T transformation templates. The idea behind

this approach is to use (customizable) code genera-

tion templates as a grammar to parse the generated

(and later modiﬁed) code. The beneﬁt of this ap-

proach compared 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

templates are automatically taken into account during

reverse 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 QVT-R rules that relate

two elements of the respective meta-models. Since

MoDisco is able to parse source code which even

contains syntax or compile errors into a correspond-

ing Java model, our approach is also independent 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 3. 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

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

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.

Recently, Macedo et al. proposed an idea on how

to circumvent some problems that are related with a

QVT-R script by using the language Alloy with their

tool Echo (Macedo and Cunha, 2014). In order to

ﬁnd a proper model in the backward direction, they

apply the ”principle of least-change”. However, they

present an erroneous transformation that might not

work with an arbitrary tool, like medini QVT. This

leads to their decision to use Alloy instead, which

offers more structural aspects and neglects the basic

declarative idea of QVT-R.

3 OVERVIEW

In this section, we provide an overview on our ap-

proach and how it could be integrated into existing

UML CASE tools. Figure 1 depicts the different

building blocks. The user of the tool may work on

the UML model level or on the Java source code

level and perform changes. These changes are then

automatically propagated to the other direction with

the help of QVT-R. In the following we only focus

UML

Model

(EMF-

based)

Java

Source

Code

User Interaction

Round-trip Support

QVT-R rules

MoDisco Java

Model (EMF-

based)

update update

MoDisco

(T2M)

Acceleo

(M2T)

edit edit

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

on the involved metamodels: The UML2 metamodel

and the MoDisco Java metamodel. Discovering the

Java model from Java source code and generating Java

source code from the Java model are out of scope of

this paper, since this is performed by the MoDisco

framework. Before we discuss the relevant parts of

the involved metamodels, we describe key concepts

of QVT-R and show which tools support its execu-

tion.

3.1 QVT-R

In order to keep this article self-contained, we shortly

mention important features of the QVT-R language.

For detailed information we refer to the ofﬁcial QVT-

R speciﬁcation (QVT, 2015).

In a transformation elements of the corre-

sponding metamodels are regarded in a relation. A

relation declares at least two domains which can

be marked as checkonly, enforce or primitive

where the ﬁrst keyword hints that a consistency check

must ﬁnd corresponding elements otherwise it reports

an error. Contrastingly, if the domain is marked as

enforce, it will create the missing element and delete

inconsistent ones whereas primitive domains might

be used as variables. A relation can also be dec-

orated with the keyword top, i.e., it is executed au-

tomatically. Otherwise, it must be called explicitly.

With when and where clauses, further pre- and post-

conditions for a relation may be speciﬁed. A key

can indicate values that uniquely identify an element.

In general, every script is executable in many ways.

In both transformation directions the developer can

choose between checkonly and enforce mode and

thereby determine the respective semantics.

3.2 QVT-R Tools

Different tools implement (parts of) the QVT-R speci-

ﬁcation. Unfortunately, mostly they are not developed

any longer or do not implement the full standard.

Medini QVT

, that was chosen for the implemen-

http://projects.ikv.de/qvt

Bidirectional Transformations with QVT-R: A Case Study in Round-trip Engineering UML Class Models and Java Source Code

tation, is only available for slightly outdated Eclipse

versions

and is restricted to basic concepts of QVT-

R. For instance, the check-before-enforce semantics

of QVT-R is not realized. ModelMorf

seems to re-

alize most of the standard’s concepts but needs a li-

cense that is unavailable. It was used, e.g., in (Brad-

ﬁeld and Stevens, 2013). The proposal of the Eclipse

Modeling Community, QVT-d

, is not yet able to ex-

ecute bidirectional relational transformations. A fur-

ther tool, QVT-XSLT (Li et al., 2011), allows to spec-

ify a transformation with the graphical notation of

QVT-R. Although this tool took part in a contest, it

is still prototypic and unavailable.

3.3 Used Metamodels

In the following subsection, we brieﬂy discuss the

metamodels involved in our transformation. Both

metamodels are based on Ecore (Steinberg et al.,

2009), i.e. they share the same meta-metamodel.

Since most UML diagrams lack a precise and formal

semantics, we restrict the case study on the structural

features of both models. Behavioral aspects, like the

body of method declarations, are not regarded in the

implementation.

3.3.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, 2011c).

Eclipse UML2 only constitutes the abstract syntax of

UML2. Tool integrators may contribute their own dia-

gram editors, code generators, and additional tooling,

as has been done, for example, in our Valkyrie (Buch-

mann, 2012) toolchain. Figure 2 depicts a simpliﬁed

overview of the most relevant metaclasses involved in

the transformation.

The root element, Model, which is a specializa-

tion of a Package, constitutes a hierarchy of pack-

ages. A Package may contain nestedPackages that

are derived from its packagedElements. The lat-

ter ones subsume – in our use case – classes, inter-

faces or enumerations besides the packages. Classes

and interfaces are container elements for Operations

that may have Parameters, where the direction at-

tribute speciﬁes if a parameter is used as a return type

or as an input or output parameter. Attributes be-

longing to a Class are expressed by the metaclass

We tested it with Eclipse Indigo.

http://www.tcs-trddc.com/trddc website/ModelMorf/

ModelMorf.htm

https://wiki.eclipse.org/MMT/QVT Declarative (QVTd)

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

Property.

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 im-

port the pre-deﬁned primitive types supplied with the

Eclipse UML2 metamodel. An Association links

two classes and might be unidirectional or bidirec-

tional depending on whether both ends are naviga-

ble or only one end. A class may also extend an-

other class or implement an interface whereas inter-

faces can inherit other interfaces. The modeling de-

tails for the latter relationships are omitted in Figure

2 for simpliﬁcation reasons.

3.3.2 Java (MoDisco)

MoDisco (Bruneliere et al., 2010) is an extensible

framework for developing model-driven tools to sup-

port use cases of software modernization. It provides

an Ecore-compliant metamodel for Java which resem-

bles the AST of the Java language. Furthermore, it

provides a discovery mechanism, that allows to parse

existing Java source code into instances of the Java

metamodel. The relevant cutouts of the MoDisco Java

metamodel are shown in Figure 3.

The Model contains a hierarchy of Packages but

is – in contrast to the UML metamodel – no spe-

cialization of a Package. It stores primitive types

as orphanTypes together with ParameterizedTypes

and ArrayTypes that represent multi-valued types.

Besides ownedPackages, a Package con-

tains further ownedElements that summa-

rize classes, interfaces and enumerations.

Attributes (FieldDeclaration) and oper-

ations (MethodDeclaration) are added as

bodyDeclarations. Both are typed elements

where the type of the operation represents the re-

turned type. Instead of accessing this type directly,

the metaclass TypeAccess provides access to the

respective type. This common pattern of the Java

metamodel records which two types are related

and provides indirect access to the actual type. For

example, the superClass and superInterfaces

are modeled in this way, too.

Input parameters for a method are modeled

differently as ownedParameters with the meta-

class SingleVariableDeclaration. More-

over, the name of an attribute is placed in the

VariableDeclarationFragment. To generate

source code, the Java model regards every classiﬁer

as separate unit and records which elements belong

to it. CompilationUnits constitute the abstraction

of the Java ﬁles which contain type declarations

like classes, interfaces or enumerations. In order to

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

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

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

generate Java source code from the Java model, it is

neccessary, that the Java model contains the appro-

priate compilations units, as the M2T transformation

supplied by the MoDisco framework needs these

elements as anchor points for the code generation

templates.

4 BIDIRECTIONAL

TRANSFORMATION WITH

QVT-R

This section introduces the implementation of the

transformation. Beforehand, we show conceptual ap-

Bidirectional Transformations with QVT-R: A Case Study in Round-trip Engineering UML Class Models and Java Source Code

proaches towards implementing QVT-R rules. At the

end of the section, we present the results that are ob-

tained from testing the transformation script.

4.1 Transformation Approach

In the following, we focus on different possibilities to

declare a transformation with their beneﬁts and draw-

backs. A transformation may traverse the contain-

ment hierarchy top-down or bottom-up by strictly or-

dering the relation calls. Eventually, it turns out that a

hybrid approach is the most declarative form to spec-

ify the transformation.

4.1.1 Top-down

In a top-down approach we only need to specify one

top relation that transforms the root element, the

Model. Every other element will be considered in

called rules. They are included as postconditions in

the where clauses. This process traverses the span-

ning containment tree from its root element to the

leaves. Although it is a straightforward way to de-

clare the transformation, some drawbacks exist: The

treatment of cross-referencing elements is not obvi-

ous when they are declared in different rule patterns.

A mechanism must ensure that a single element is cre-

ated only once and otherwise only referenced. Ad-

ditionally, applying a step-wise transformation with

a given order contradicts the declarative nature, be-

cause the developer is more concerned about ordering

the calls instead of focusing on the relationships be-

tween the metamodel elements.

4.1.2 Bottom-up

The opposite conceptual approach inverts the idea of

the top-down process and starts at the bottom, the

leaves of the spanning-tree. Accordingly, this in-

cludes several different top relations. For example,

the creation of the parameters could initiate the trans-

formation of its containing operation and the latter, on

the other hand, the creation of the owning class. Ob-

viously, in this approach it is as well necessary to take

care that the same elements are only created once.

Another problem of this approach are circular depen-

dencies. For instance, a class might be the type of a

parameter. At the creation time of the parameter the

class might, however, not exist yet. Therefore, its cre-

ation must either be anticipated as precondition in the

when clause of the relation or a template for the class

must be used. Moreover, this approach relies heavily

on the fact that single elements are linked the right

way. Sometimes an element might not be located at

the lowest level and might not contain an element of

the lowest level. In this approach, it might not be

transformed at all as no element is there to commence

its creation. While the domain patterns might be writ-

ten more intuitively at ﬁrst glance, we found these

drawbacks: Backward links must be modeled and

contain proper values. Secondly, there might be circu-

lar dependencies and unresolvable cross-referencing

elements.

4.1.3 Hybrid

As we have seen from the previous descriptions, the

strict ordering of relation calls in when and where

clauses contradicts the declarative nature of QVT-R

and is an unsatisfying solution. Consequently, we fo-

cus on a hybrid strategy: We try to declare as many

top relations as possible. Relations are only called in

where clauses when they are directly linked with the

calling concept, e.g. the addition of parameters to an

operation, or when they simplify the transformation

signiﬁcantly. The latter reason holds, for instance,

when anticipating the creation of primitive types in

the Model, which is the ﬁrst rule we present in the

next section. Other dependencies should be resolved

by the execution engine. Thereby, we may write rules

more intuitively but are dependent on the execution

engine to properly resolve dependencies.

4.2 Implementation

In this section, we present some example rules of our

implementation which demonstrate, on the one hand,

simple rules and, on the other hand, pitfalls that might

occur when declaring a QVT-R script.

We start with transforming the root element as a

fairly straightforward example for a relation. A rule

to transform the Model metaclass, as shown in Listing

1, can be designed fairly easy. Both metaclasses de-

ﬁne a name attribute that must match.

Listing 1: Simpliﬁed transformation rule for the root, the Model.

1 top relation M ode l 2 M ode l {

2 nam e : Str ing ;

3 enforce domain uml uR oot : u ml :: Mod el {

4 na me = nam e

5 };

6 enforce domain j ava jR oot : j ava :: M o del {

7 na me = nam e

8 };

9 where {

10 E l ementI m p o r t 2Prim i t i v e T ( uRoot , j Roo t );

11 C reat e V o idTyp e ( u Ro ot , j R oot ) ;

12 C r eate S t r i ngCla s s ( u Root , j Roo t );

13 P a ckag e 2 P a ckage T o p ( uRoot , j Roo t );

14 }

15 }

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

However, every Model stores different kinds of types

and is composed of packages. Since primitive types

are needed in many relations, their creation is antic-

ipated in the where clause of the Model2Model rela-

tion (Listing 1, line 10). In the listing, we have sim-

pliﬁed this rule call due to space restrictions. In the

actual transformation, we have written eight differ-

ent rules where the letter T is replaced by one of the

actual primitive types that both metamodels share

The problem of this increasing amount of rules is dis-

cussed in the following paragraphs. As a consequence

of the rule calls, it can be assumed that primitive types

are created completely and accessible in other rela-

tions afterwards. Other types, like Strings, that are

treated differently in the metamodels need extra con-

sideration in the rule (Listing 1, lines 11-12). In a

last step, Listing 1 initiates the creation of packages

in line 13 as they are basic parts of the Model

Taking a closer look at the integration of primitive

types into Models (Listing 2), reveals one drawback

of QVT-R and the medini QVT implementation.

Listing 2: Simpliﬁed transformation rule for primitive types.

1 relation E l e m e n t Impor t 2 P r i mitive T {

2 t y peN a me : S t rin g ;

3 enforce domain uml uR oot : u ml :: Mo del {

4 e leme n t I mpor t = uI m port : u ml ::

Elem e n tImp o r t {

5 impo r t e dElem e n t = uI m port e d : u ml ::

Prim i t iveT y p e {

6 na me = t y peN a me

7 }

8 }

9 };

10 enforce domain j ava jR oot : j ava :: M o del {

11 o rpha n T ypes = jOr p han : j ava ::

Prim i t i veTy p e T {

12 n ame = ty p eNa m e

13 }

14 };

15 when { ty p eNam e = ’ T ’ ; }

16 }

Depending on the name of the primitive type, a differ-

ent metaclass must be picked in the Java domain (List-

ing 2, line 11). In total, this results in eight different

rules in our transformation that only differ in the name

of the type (Listing 2, line 15) and the corresponding

metaclass. As the parameter T hints, a template mech-

anism or rule inheritance would be beneﬁcial. Thus,

one relation would sufﬁce and simplify the transfor-

The shared primitive types are: Bool, Byte, Char, Dou-

ble, Float, Int, Long and Short.

Two different rules for packages are required because

they are added to the Model with a different reference than

to other packages in the Java metamodel.

mation signiﬁcantly. Although the standard at least

deﬁnes rule inheritance in the QVT-R textual syntax

this functionality is missing in medini QVT. Accord-

ingly, we need to specify the same number of rules as

existing corresponding model elements when there is

a trivial difference in the metamodels.

The increase of rules becomes especially evident,

for instance, when treating parameters of an opera-

tion. The Java metamodel makes a difference be-

tween return and input parameters whereas the UML

metamodel only adapts the direction property of

the Parameter metaclass. In the Java model a re-

turned parameter is always present and might be – in

case it is empty – the type Void. It is modeled as

an instance of the metaclass TypeAccess. The list

of input parameters might really be empty. In con-

trast to the returned type, these elements are instances

of the SingleVariableDeclaration metaclass of

the Java metamodel. Additionally, there is a differ-

ence between single- and multi-valued types since in

the source code the multiplicity cannot be simply ex-

pressed by numbers, as is the case in the UML class

model. To this end, this results in separate rules for

single- and multi-valued, returned and input parame-

ters that must be further distinguished by their types.

Only when every possible combination is declared as

relation, the script is generally applicable.

Despite the combinatorial explosion of rules be-

cause of minor differences in the metamodels, in other

situations, we have found a way to circumvent the

missing capability of medini QVT to deﬁne relation

inheritance. For example, it is possible to deﬁne the

general components of a class in a ”super” relation, as

shown in Listing 3, and add speciﬁc details in ”sub”

relations, like the fact that the class inherits from an-

other class or realizes an interface.

Listing 3: Base transformation rule for classes.

1 top relation C las s 2 C las s {

2 /* v a riab l e dec l a rati o n s */

3 enforce domain uml uP ack : u ml :: Pa c kage {

4 p ackag e d E leme n t = u C las s : uml :: C las s {

5 /* set ba sic p rope r t ies :

6 name , v isi bil ity , ab str act , pa ckag e */

7 }

8 };

9 enforce domain j ava jP ack : j ava :: Pa c kag e {

10 o wned E l e ment s = jC l ass : ja va ::

Clas s D e c lara t i o n {

11 /* set ba sic p rope r t ies :

12 nam e , visi bil i ty , abs tract , pac k age

13 an d Co m p ilat i o n U nit */

14 }

15 };

There are no details given on the semantics of inheri-

tance.

Bidirectional Transformations with QVT-R: A Case Study in Round-trip Engineering UML Class Models and Java Source Code

16 when{

17 A uxPa c k 2Pac k ( u Pa ck , jPac k );

18 /* r etr i eve vi s ibil i t ies a nd a b str a ct

pro p erty */

19 }

20 where{ Au x C l ass2C l a ss ( uClass , jCla ss ) ; }

21 }

This is possible by employing an auxiliary relation

that links both instances in the where clause (Listing

3, line 20) after their basic properties have been trans-

formed. The auxiliary relation is kept quite simple

and solely deﬁnes two empty classes as domains. To

add special properties, this auxiliary relation is called

as precondition in the when clause of relations that

extend the basic values, like in Listing 4. This rule

adds an optional super class to the basic properties of

the class. The call in line 15 ensures that the super

classes (Listing 4, lines 5 and 11) are added to the

proper class instances.

Listing 4: Transformation rule to add a ’super’ class.

1 top relation C l ass2C l a s s _ gener a l i z e d {

2 enforce domain uml uP ack : u ml :: Pa c kage {

3 p ackag e d E leme n t = u C las s : uml :: C las s {

4 gene r a l izat i o n = uGen : uml ::

Gene r a l izat i o n {

5 gen e ral = u Sup er : uml :: C l ass {} }

6 }

7 };

8 enforce domain j ava jP ack : j ava :: Pa c kage {

9 o wned E l e ment s = jC l ass : ja va ::

Clas s D e c lara t i o n {

10 sup e r Clas s = j A cce s s : j ava ::

Typ e A cces s {

11 ty pe = j Sup e r : ja va : :

Clas s D e c lara t i o n {} }

12 }

13 };

14 when{ Au x P a ck2P a c k ( uPack , jPa c k ) ;

15 A uxCl a s s 2Clas s ( u Class , j C las s ) ;

16 A uxCl a s s 2Clas s ( u Super , j S upe r ) ; }

17 }

This pattern is applicable to all elements which

are referenced in different relations and should be

extended by additional properties. A similar result

might be achieved by using key declarations for the

component that should be extended. However, with

keys, their features must always be mentioned in ev-

ery domain pattern. Thus, it is necessary that all

unique properties are available in the respective re-

lation. In general, this is not always the case.

So far, we have only discussed situations in which

both metamodels possess matching elements, even so

they might not be 1:1 mappings. This is not the case

for UML associations. An Association is a concept

that is part of UML but unknown in Java. When gen-

erating Java source code, the ends of an association

are normally represented as attributes of the class of

the opposite end and receive corresponding accessor

methods. This, however, is only true when the asso-

ciation is bidirectional and the ends are owned by the

class

. Still, the non-navigable end of a unidirectional

association has to be stored in the Association. Fig-

ure 4 depicts the abstract syntax for a simple example

of a unidirectional association.

Figure 4: Representation of a unidirectional association in

abstract syntax.

As a comparable concept is missing in the Java

metamodel, the information about a non-navigable

end is a priori lost and not recoverable from source

code. Generally, the same is true for the name at-

tribute used for the Association. In order to de-

clare a proper bidirectional rule, we either have to use

special naming conventions or extract the information

from different sources. Since we do not want to re-

strict the user, we chose to attach Javadoc comments

to the source code. Accordingly, the user is free to

model and name the association ends as desired. The

comment style distinguishes between uni- and bidi-

rectional comments and regards the multiplicity of the

ends. A bidirectional comment, as shown in Listing

5, stores the name of the association in the ﬁrst line

(Listing 5, line 2) and the name of the end and the

name of the end’s type in the following line.

Listing 5: Pattern for a bidirectional comment.

1 ’ /* *

2 @ b i d i recti o n a l A s socia t i o n : < a sso cNa me >

3 @ own E nd < mem berE ndNa me > : < m embe r End T y peN a m e

4 @ a ggre g a t ion : < a ggre g ati o nKin d >

5 */ ’

In our implementation we assume that navigable asso-

ciation ends always belong to classes and not to the associ-

ation itself.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

Furthermore, it includes the information of the aggre-

gation kind (Listing 5, line 4), which would also be

lost in the source code in case no conventions are ap-

plied. For the unidirectional comment this style is ex-

tended by one line. After the second comment line

(Listing 5, line 3) with the ’@ownEnd’ tag, the non-

navigable end that is part of the Association itself,

is recorded in the same way as the ’ownEnd’.

Listing 6 shows a simpliﬁed version of how to re-

late a unidirectional association with the correspond-

ing FieldDeclaration. This rule reveals that as

soon as the mapping cannot be accomplished 1:1,

the rules might become really complicated. In the

UML domain, it declares the owned- (Listing 6,

lines 5-12) and the opposite memberEnd (Listing 6,

lines 13-22) of the Association, which should not

be the same (Listing 6, line 51). In the forward

direction, the Association is mapped to a single

FieldDeclaration of the non-navigable class and

receives, most importantly, a comment (Listing 6,

lines 42-45) that summarizes the necessary informa-

tion to build the Association in the backward di-

rection. Note that the types are not mandatory in the

comment because in the forward direction they are

known from the given types of the member ends (List-

ing 6, lines 9-11 and 17-19). In the backward direc-

tion, the types are accessible with the help of auxiliary

relations that link the class instances that are already

created and thus, retrieve the proper class types for

the navigable and non-navigable end. In this way, the

Association is built as well as the Property that is

added to the non-navigable class (uOwnedType). The

naming (Listing 6, lines 54-56) and the aggregation

kind (Listing 6, line 53) are extracted from the given

comment with queries.

Listing 6: Simpliﬁed transformation for unidirectional associa-

tions.

1 top relation U n iAsso c i a t i on2Pr o p e r t y {

2 /* va r i abl e decl a r a tion s . .. */

3 enforce domain uml u Pac k : u ml :: Pa c kag e {

4 p ackag e d E leme n t = u A sso c : uml ::

Ass o c i ati o n {

5 n ame = a Na me ,

6 o w n edE n d = uO w ned E n d : u ml :: Pr o pert y {

7 na me = n otN avN ame ,

8 low er = 0 , uppe r = 1 ,

9 ty pe = u O wned T y pe : uml :: C las s {

10 na me = n o tNav T y pe

11 },

12 a ssoc i a tion = uA s soc

13 }

14 mem b erEn d = u M emE n d : u ml :: Pr o pert y {

15 na me = sec Na me ,

16 low er = 0 , uppe r = 1 ,

17 ty pe = u M emT y pe : uml :: C las s {

18 na me = m e mTyp e N ame

19 },

20 a ssoc i a tion = u Assoc ,

21 cla ss = u Own edT ype ,

22 a ggre g a tion = uA ggr

23 },

24 _ p a cka g e = uPac k

25 }

26 };

27 enforce domain j ava jP ack : j ava :: Pa c kag e {

28 o wned E l e ment s = jC l ass : j ava ::

Clas s D e c lara t i o n {

29 body D e c l arat i o n s = jFi e ld : jav a ::

Fiel d D e c lara t i o n {

30 ty pe = j Acce ss : j ava :: T y p eAcc e s s {

31 ty pe = j Typ e : j ava ::

Clas s D e c lara t i o n {

32 na me = m e mTyp e N ame

33 }

34 },

35 /* fragm ent , modi fie r ,

comp i l a tionU n i t fea t ure s . .. */

36 comm e nts = jCo m ment : j ava :: Ja v adoc {

37 con t ent = ann ,

38 o r iginal C o m p i latio n U n i t = jC las s .

origi n a l C o mpila t i o n U nit

39 }

40 }

41 }

42 };

43 when{

44 not( uMe m Typ e = uO w n edTy p e );

45 not( a nn . in d exOf ( ’ @bid i r e ctio n a l ’ ) > 0) ;

46 -- b ind typ es :

47 A uxCl a s s 2Clas s ( uO w ned Typ e , jCla s s ) ;

48 A uxCl a s s 2Clas s ( uM emT ype , jTyp e );

50 an n = g e t U niDi r C o m ment ( aName , secNam e ,

mem Typ e Nam e , notN avN ame , not Nav Typ e

, agg r ) ;

51 ag gr = g e t S tring F r o mAggr ( uAg gr ) ; - - FW

52 ag gr = g e t A g grFro m C o m m entUn i ( ann ) ; - - BW

53 uAg gr = g e t A ggrF r o m S tring ( ag gr ) ;

54 n otN a v Name = getN o t N avNa m e ( a nn ) ;

55 n otN a v Type = getN o t N avTy p e ( a nn ) ;

56 aNa me = g e tAsso c N ame ( an n ) ;

57 }

58 }

The relation for bidirectional associations can be de-

clared with less effort and is only mentioned for com-

pleteness. It is sufﬁcient to regard only one Property

as UML domain and to deﬁne the Association as

nested template with unique values. The Property

is related with a FieldDeclaration in the Java do-

main quite like it is declared for the memberEnd of a

unidirectional association. In contrast to the unidirec-

tional rule, these two instances sufﬁce because pattern

matching will match both ends as a Property and the

Association is created only once because of a key

declaration.

Bidirectional Transformations with QVT-R: A Case Study in Round-trip Engineering UML Class Models and Java Source Code

The concept of keys embraces another problem.

Conceptually, a key should declare unique proper-

ties of an element, like a primary key in Relational

Databases. However, sometimes key properties are

mutually exclusive or not always available. For in-

stance, a Property may belong exclusively to a

class or to an association but sometimes may be

found in one of both. If we declare both references

as keys of the Property, the medini QVT engine will

search both values in every pattern of a Property. If

only one key attribute is set in the domain pattern, it

will lead to misbehavior, e.g. the Property is not

unique anymore when it only declares a class in its

pattern.

4.3 Results

The transformation described in the previous subsec-

tion was tested with a set of examples. The obtained

results show the expected behavior. The transforma-

tion may be executed without restrictions in both di-

rections. On the one hand, a forward transformation,

from UML to Java, followed by a backward trans-

formation preserves the original state of the source

model.

Figure 5 depicts one of the example scenarios.

The example contains a unidirectional association be-

Figure 5: Resulting models from transforming the given

UML classdiagram to Java source code and vice versa.

tween a class Person and a class Address where

many persons may live at one address. The

persons association end, however, is not navigable.

The ﬁgure presents cutouts of the UML abstract syn-

tax in the Ecore tree representation as well as the tree

representation of the MoDisco Java model which re-

sult from applying the transformation. As shown in

the ﬁgure, the non-navigable end persons and the

Association itself are not available in the Java rep-

resentation anymore except for the artiﬁcially added

comment of the navigable end address. Neverthe-

less, by using this comment and the auxiliary rela-

tions the association can be restored completely in

the backward transformation as the second arrow in-

dicates. Thus, a non-bijective element can be trans-

formed by exploiting additional information that is

stored in the models.

On the other hand, the result of the forward trans-

formation corresponds to the discovered Java source

code model except for the elements that are not con-

sidered by our transformation, e.g. the method bodies.

Moreover, we have examined the incremental be-

havior. A sample round-trip process is depicted in

Figure 6. We start with a UML model from which

we have already generated Java source code. In a ﬁrst

step, we change the UML model (blue color) the fol-

lowing way: We delete a class (1) and a method (2)

and add a class (3) and an input parameter to a method

(4). Afterwards, we perform an incremental forward

transformation that integrates the changes in the Java

model in the expected way.

In a second step, we adapt the Java model with

the subsequent changes (red color) in the source code:

We delete a method (5) and a class (6) which are not

referenced from other elements. Additionally, we add

a new class (7) and further change the signature of the

method (8). After we execute our script incremen-

tally in the backward direction, these adaptations are

reﬂected in the UML model. Here we can observe

that, for example, the return type of the Operation

run() which was previously empty has changed to

type boolean and that this parameter was added to

the corresponding method in the UML model.

These modiﬁcations are picked as exemplary use

cases. Due to space restrictions, we cannot provide

the whole set of the tests which can be obtained from

the website provided in the Resources section. They

show that the same well-deﬁned behavior can be ob-

served for the rest of the implemented features.

Yet, we have not examined simultaneous updates.

They might lead to lost updates or unwanted elements

that remain from unconsidered modiﬁcations of the

opposite model. For instance, if the user changes the

name of a class in both models in a different way, only

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

Figure 6: Sample round-trip process.

the name of the source model for the transformation

is kept. The other one cannot be regenerated. Still, in

general the round-trip process, is realizable with the

QVT-R script.

5 DISCUSSION

This section brieﬂy describes the lessons learned from

implementing the use case.

First of all, 1:1 mappings do not pose many dif-

ﬁculties and can be implemented quite straightfor-

ward. Secondly, we additional elements may be

added without restrictions in the involved models: For

instance, a UML class needs a corresponding Java

ClassDeclaration and the ClassDeclaration al-

ways belongs to a CompilationUnit which must be

included additionally in the Java model. Since the

CompilationUnit can be extracted from the same

information as the ClassDeclaration, two bidirec-

tional rules match both Java elements to the same

UML Class as domain. This works well due to gen-

erating the Class ﬁrst and referencing it later with

the auxiliary relation combined with the declaration

of key properties for the CompilationUnit.

Furthermore, we saw that due to the declarative

nature and limitations of medini QVT, minor differ-

ences in the metamodels may result in a large num-

ber of relations. Though the differences are minimal,

e.g. for the integration of primitive types, a differ-

ent rule to mention every metaclass separately is re-

quired. This is also true for packages, attributes of dif-

ferent types and becomes worse when regarding the

two kinds of parameters an operation might possess

where, moreover, the types can vary. A mechanism of

rule inheritance or the deﬁnition of template relations

would be a beneﬁcial help. In this way the integration

of primitive types could be written as in Listing 2 and

T could be replaced automatically by the execution

engine.

To avoid copying and pasting a relation solely be-

cause of different type instances, it would be help-

ful to allow the declaration of abstract types as do-

mains or inside the domain patterns. The execution

engine could pick the respective instances. If spe-

cial behavior has to be implemented dependent on the

type, it could also be accomplished in the when or

where clauses. In these scenarios, queries with side-

Bidirectional Transformations with QVT-R: A Case Study in Round-trip Engineering UML Class Models and Java Source Code

effects, that are part of the operational QVT speciﬁ-

cation (QVT-o) (QVT, 2015), might be an appropri-

ate construct to extract a proper type or to build up a

special part of the domain.

Moreover, there is a conceptual problem inherent

to key properties. They introduce unexpected behav-

ior when different, possibly mutually exclusive prop-

erties make up the key. If they cannot be declared in

every domain pattern, the regarded element might not

be built only once.

While sometimes the rules get really complicated,

we also found a workaround to simplify some rela-

tions without having the possibility to inherit from a

relation. By using auxiliary relations to keep track

of corresponding elements on both metamodels, it is

possible to add speciﬁc values to the general proper-

ties. This needs, however, the proper placement of the

calls of the auxiliary relation.

A further aspect includes the missing of seman-

tic rules. Generally, there is no possibility to ensure

that semantic constraints are fulﬁlled. For example,

it should not be possible that an association has two

aggregated ends or is composed of more than two

ends

. However, the only chance to exclude misbe-

havior is to deﬁne a domain pattern that restricts the

input elements in the desired way. The resulting pat-

tern might either be very complicated or not deﬁnable

at all. A solution to this problem might be to attach

an OCL script to the QVT transformation and to eval-

uate the resulting models according to the speciﬁed

constraints afterwards. However, this would need fur-

ther actions, like roll-backs or ﬁxing rules, when the

result of the test is negative and hence is not easy re-

alizable.

Last but not least, the ﬁndings show that the pure

declarative semantics of QVT-R and missing medini

QVT support sometimes leads to a real overhead on

relations. Moreover, when implementing the relation,

the declarative nature is contradicted by considering

exactly where to put statements: in the when or in

the where clause. Because of the bidirectionality, the

developer must always consider the right ordering of

the statements and take care that they are executable

in both directions. This is, on the one hand, opposed

to the declarative idea of QVT-R. On the other hand,

a clearer execution order could rather facilitate the

QVT-R speciﬁcation at many places and make the

script more expressive.

Finally, it must be mentioned that many problems

are speciﬁc to the capabilities of the medini QVT en-

gine. For instance, rule inheritance and extending

transformation scripts is conceptually foreseen in the

We only considered bidirectional associations in our

implementation.

standard but not semantically deﬁned yet. However,

these concepts would be a valuable help to deﬁne

the transformation in a more declarative and compact

way. Hence, we have to claim the weak tool support

for complicating the speciﬁcation of the transforma-

tion. Missing functionality and a faulty implementa-

tion of the check-before-semantics, syntax highlight-

ing, error checking and many other details might con-

fuse users of the tool and rather hinders learning and

deﬁning QVT-R transformation.

6 CONCLUSION

In this paper we presented our bidirectional model

transformation between UML2 class models and a

Java model, which is obtained from Java source code.

The transformation serves as a case study and is in-

tended to be used in round-trip engineering scenarios

of our CASE tool Valkyrie (Buchmann, 2012).

It turned out that the transformation can be writ-

ten quite simple for matching elements but might be-

come very complex as soon as small differences exist

in the metamodels. Moreover, the weak tool support

hardens the process of specifying proper and simple

transformations. Nonetheless. it is possible to keep

two complex, non-injective models mutual consistent.

The transformation behaves well for batch transfor-

mations and determined incremental update opera-

tions.

To conclude, despite the fact that QVT-R offers a

high potential to declaratively keep two models (in-

crementally) in a synchronous state, weak tool sup-

port and ambiguities in the standard still hinder a

wide-spread usage of QVT-R in productive software

projects.

RESOURCES

The QVT-R script and the corresponding model in-

stances may be obtained via http://btn1x4.inf.uni-

bayreuth.de/umljava/UML-Java.zip. The speciﬁca-

tion was tested with medini QVT, version 1.7.0 on

Eclipse Indigo.

REFERENCES

(2015). Meta Object Facility (MOF) 2.0 Query/View/Trans-

formation Speciﬁcation. Needham, MA, formal/2015-

02-01 edition.

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

nizing technique for syntactic model-code round-trip

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

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

undorf, 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.

Bradﬁeld, J. and Stevens, P. (2013). Enforcing QVT-R with

mu-Calculus and Games. In Cortellessa, Vittorio and

Varr, Dniel, editor, Fundamental Approaches to Soft-

ware Engineering, volume 7793 of Lecture Notes in

Computer Science, pages 282–296. Springer Berlin

Heidelberg.

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. (2012). Valkyrie: A UML-Based Model-

Driven Environment for Model-Driven Software En-

gineering. In Proceedings of the 7th International

Conference on Software Paradigm Trends (ICSOFT

2012). INSTICC.

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

vey of model transformation approaches. IBM Sys-

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

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

ezivin, 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).

Leblebici, E., Anjorin, A., Sch

urr, A., Hildebrandt, S.,

Rieke, J., and Greenyer, J. (2014). A comparison of

incremental triple graph grammar tools. ECEASST,

67.

Li, D., Li, X., and Stolz, V. (2011). QVT-based Model

Transformation Using XSLT. SIGSOFT Softw. Eng.

Notes, 36(1):1–8.

Macedo, N. and Cunha, A. (2014). Least-change bidirec-

tional model transformation with QVT-R and ATL.

Software Systems Modeling, pages 1–28.

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

MDA Distilled. Addison Wesley Longman Publishing

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

OMG (2011a). Meta Object Facility (MOF) Core. Object

Management Group, Needham, MA, formal/2011-08-

07 edition.

OMG (2011b). UML Infrastructure. Object Management

Group, Needham, MA, formal/2011-08-05 edition.

OMG (2011c). UML Superstructure. Object Management

Group, Needham, MA, formal/2011-08-06 edition.

OMG (2012). Object Constraint Language. Object Man-

agement Group, Needham, MA, formal/2012-01-01

edition.

Sch

urr, 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.

Bidirectional Transformations with QVT-R: A Case Study in Round-trip Engineering UML Class Models and Java Source Code