BXtend - A Framework for (Bidirectional) Incremental Model

Transformations

Thomas Buchmann

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

atsstrasse 30, 95440 Bayreuth, Germany

Keywords:

Model Transformations, Bidirectional, Incremental, Imperative, Model-driven Development.

Abstract:

Model transformations constitute the core essence of model-driven software development (MDSD) – a soft-

ware engineering discipline, which gained more and more attention during the last decade. While technology

for unidirectional batch transformations seems to be fairly well developed, tool support for bidirectional and

incremental transformations is still restricted. Results obtained with case studies carried out with popular bidi-

rectional approaches motivated us to set up our own light-weight framework for bidirectional and incremental

model transformations based on the Xtend programming language. Our approach provides several advan-

tages, as it reduces the cognitive complexity for transformation developers, and allows for a greater ﬂexibility

in transformation speciﬁcations by providing procedural language constructs. In addition, it provides a higher

expressive power and allows for compact speciﬁcations at the same time.

1 INTRODUCTION

The motivation behind Model-driven software de-

velopment (MDSD) (V

olter et al., 2006) is to re-

place low-level programming with the development

of high-level models. Starting from an initial model

capturing the requirements, a set of models over mul-

tiple levels of abstraction is derived until ﬁnally code

is generated. Modeling languages are usually de-

ﬁned with the help of meta models in the context

of object-oriented modeling. In the academic world,

the de-facto standard for research dedicated to model-

driven engineering is the Eclipse Modeling Frame-

work (EMF) (Steinberg et al., 2009). It strictly fo-

cuses on principles from object-oriented modeling

and only provides core concepts for deﬁning classes,

attributes and relationships between classes. EMF is

based on its meta model Ecore, which basically re-

sembles Essential MOF (EMOF), a subset of MOF

(OMG, 2015b).

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

2004) is the standard process for model-driven soft-

ware engineering. In the MDA context, model trans-

formations are typically chained. A platform inde-

pendent model (PIM) is reﬁned to a platform spe-

ciﬁc model (PSM) using a series of subsequent model

transformations. Consequently, MDSD highly de-

pends on model transformations. A model transfor-

mation describes how a source model s, represented

as an instance of an input meta model is transformed

into a target model t conforming to the output meta

model. Typically, we distinguish between model-

to-text (M2T) and model-to-model (M2M) transfor-

mations, depending on the representation of the tar-

get models. A wide range of formalisms have been

proposed in the past for deﬁning model transfor-

mations (Czarnecki and Helsen, 2006). They vary

with respect to computational paradigms (procedural,

functional, rule-based, object-oriented), directional-

ity (unidirectional vs. bidirectional), support for in-

place, out-place, incremental or batch transforma-

tions, etc. Numerous model transformation languages

emerged accordingly, ranging from general ones, like

ATL (Jouault et al., 2008) or QVT (OMG, 2015a),

graph based languages like Henshin (Arendt et al.,

2010) or eMoﬂon (Anjorin et al., 2012) to domain-

speciﬁc languages such as, e.g., the Epsilon family of

transformation languages (Rose et al., 2014) or EMG

(Popoola et al., 2016). Our observations have shown

that tool support for (unidirectional) batch transfor-

mations is fairly well developed. However, in many

scenarios different kinds of transformations are re-

quired: After transforming a source model into a tar-

get model, additions or modiﬁcations to the target

model may be necessary. Consequently, changes to

the source model need to be propagated in a way

which allows to retain the manual modiﬁcations of

the target model. These change propagations de-

336

Buchmann, T.

BXtend - A Framework for (Bidirectional) Incremental Model Transformations.

DOI: 10.5220/0006563503360345

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 336-345

ISBN: 978-989-758-283-7

mand for incremental rather than batch transforma-

tions. Additionally, changes to the target model may

have to be propagated back to the source model, re-

sulting in bidirectional transformations. While sev-

eral languages and tools for bidirectional and incre-

mental transformations have been proposed in the

past (OMG, 2015a; Sch

urr, 1994), there are still a

number of unresolved issues concerning both the lan-

guages for deﬁning transformations and the respective

supporting tools (Stevens, 2007; Westfechtel, 2016).

In this paper, we present BXtend, a light-weight

framework for bidirectional and incremental model

transformations based on the Xtend programming

language. The framework helps transformation de-

velopers to easily create a hand-crafted Triple Graph

Transformation System (TGTS) which will be used

for a bidirectional and incremental model-to-model

transformation. Moreover, it is an object-oriented and

imperative language with some functional parts al-

lowing for concise transformation speciﬁcations with

a high degree of expressive power. Our results ob-

tained from several case studies have shown that BX-

tend allows to reduce the cognitive complexity for

the transformation developer, by explicitly specify-

ing both transformation directions. Furthermore, the

procedural character of the language allows for a

greater ﬂexibility in the transformation rules. How-

ever, the overall size of the transformation speciﬁ-

cation is outperforms purely declarative and bidirec-

tional approaches, as QVT-R for example. The re-

sulting transformation seamlessly integrates into Java

code, which makes it easy for tool integrators to em-

power their tools with powerful model transforma-

tions.

2 RELATED WORK

Over the years, many approaches for model transfor-

mations have been proposed. In the following, we

will focus our discussion only on the ones providing

support for bidirectional and incremental model-to-

model transformations. Please note that rather than

comparing our framework against single tools, we

tried to categorize the existing formalisms and dis-

cuss the beneﬁts and drawbacks of the chosen ap-

proach instead. Of course we will give examples of

tools belonging to the respective categories. However,

our own observations and case studies have revealed,

that all of the approaches listed below have limitations

when conditional creations of target elements are re-

quired. In this case, procedural approaches like BX-

tend are more powerful.

2.1 Rule-based Approaches

Approaches belonging to this category usually are

grammar-based and provide a high-level language al-

lowing for generating all consistent pairs of source

and target models. While this technique can be ap-

plied to strings, lists, or trees, the most prominent

representative are Triple Graph Grammars (TGG)

(Sch

urr, 1994). TGGs have been implemented by

various tools, such as, e.g. eMoﬂon (Anjorin et al.,

2012), TGG Interpreter (Kindler and Wagner, 2007),

MoTE (Giese et al., 2014) or EMorF (Klassen and

Wagner, 2012), just to name a few. The basic idea

behind TGGs is to interpret both source and tar-

get models as graphs and additionally have a corre-

spondence graph, whose nodes reference correspond-

ing elements from both source and target graphs, re-

spectively. The resulting model transformation lan-

guage is highly declarative, as the construction of

triple graphs is described with a set of production

rules, which are used to describe the simultaneous ex-

tension of the involved domains of the triple graph.

Please note that within the rules, no information about

a transformation direction is contained. The corre-

sponding rules for forward and backward transfor-

mation may be derived automatically by the TGG

engine. Trace information is stored in the corre-

spondence graph, which is exploited for incremental

change propagation. From the viewpoint of the trans-

formation designer, incrementality and bidirectional-

ity come for free and need not be speciﬁed explicitly

in the transformation deﬁnition, as well as modiﬁca-

tions and deletions, which are also handled automati-

cally by the TGG engine.

2.2 Constraint-based Approaches

Constraint-based approaches are usually even more

high-level than grammar-based approaches, as they

only require a speciﬁcation of the consistency relation

but all details how to restore this consistency relation

are left open. QVT-R (OMG, 2015a) is a language

following this principle. Unfortunately, there are only

very few tools which are based on this standard. QVT-

R allows of a declarative speciﬁcation of bidirectional

transformations. The transformation developer may

provide a single relational speciﬁcation which deﬁnes

relations between elements of source and target mod-

els respectively. This speciﬁcation may be executed

in different directions (forward and backward) and in

different modes (checkonly and enforcement). Fur-

thermore, QVT-R allows to propagate updates from

the source model to the target model in subsequent

transformation executions (incremental behavior).

BXtend - A Framework for (Bidirectional) Incremental Model Transformations

337

2.3 Functional Programming-based

Approaches

In functional programming-based approaches, the ba-

sic idea is to program a single function (forward

or backward), which is used to infer the opposite

function (backward or forward) and providing a pair

which adheres to round tripping laws. These ap-

proaches origin from the BX community and are

based on lenses, which are used to specify view/up-

date problems. A different terminology is used for

forward and backward directions: the forward direc-

tion is referred to as get, while the backward direction

is called put. The round trip idea can be realised ei-

ther by using get to infer put, or vice versa. In all

cases, the underlying consistency relation is not spec-

iﬁed explicitly. One representative of this approach is

BiGUL

2.4 Our Approach

The main differences of our approach compared to

the approaches discussed above, is that BXtend is a

procedural and object-oriented framework, which is

implemented in the programming language Xtend

Besides its procedural and object-oriented charac-

ter, Xtend also provides powerful functional parts, as

lambda expressions. The procedural constructs al-

low for a greater ﬂexibility in transformation speci-

ﬁcations. Our BXtend framework is a light-weight

framework helping transformation developers to eas-

ily create a TGTS as an internal DSL. It is easy to

use for Java developers, as Xtend directly builds upon

Java and just makes it less verbose. Thus, the trans-

formation developer does not need to learn a new

programming language. Furthermore, the resulting

M2M transformation may be integrated seamlessly

with any other Java application without requiring ad-

ditional dependencies, which makes it particularly in-

teresting for tool integrators. Transformation direc-

tions are speciﬁed independently in an unidirectional

language, which provides a greater ﬂexibility for the

transformation developer, but provides not support to

check if the backward transformation matches the for-

ward direction. Nevertheless, our case studies un-

vieled, that although both transformation directions

need to be speciﬁed separately, the overall transfor-

mation script is still dense an compact and does not

require more LOC than approaches optimized for

bidirectional transformations.

www.prg.nii.ac.jp/project/bigul/

http://www.eclipse.org/xtend/

3 BACKGROUND

3.1 Model Transformations

As stated above, model transformations constitute the

core essence of model-driven software development.

Given a source model s and a target model t, both

conforming to their respective meta models, a model

transformation describes how s is converted to t. De-

pending on the representation of the models s and

t, we distinguish between model-to-model (M2M),

model-to-text (M2T), text-to-model (T2M), and text-

to-text (T2T) transformations.

Throughout the years, a wide range of languages

and tools for model transformations has been de-

veloped (Czarnecki and Helsen, 2006). These ap-

proaches differ from each other in several aspects:

Computational Paradigms: Computational

paradigms of model transformation languages

comprise procedural, functional, object-oriented,

or rule-based languages.

Transformation Direction: While some languages

only provide support for unidirectional (i.e., from

the source to the target model), other languages

allow to formalize and execute bidirectional trans-

formations (i.e., from source to target models and

vice versa).

Execution Modes: While batch transformations cre-

ate the complete target model in each transfor-

mation run from scratch, incremental transforma-

tions may be used to retain changes made to the

target model.

Source/Target Model Relationships: If source and

target model refer to the same model instance, the

transformation is called in-place transformation.

Out-place transformations operate on different in-

stances of source and target models.

Source/Target Language Relationships: If both

source and target model are instances of the

same meta model, the transformation is called

endogenous. In an exogenous transformation,

the meta models or source and target models are

different.

Different model transformation languages exist,

ranging from general ones, like ATL (Jouault et al.,

2008) or QVT (OMG, 2015a), graph based languages

(e.g., Henshin (Arendt et al., 2010) or eMoﬂon (An-

jorin et al., 2012)) to domain-speciﬁc transformation

languages such as the Epsilon family of transforma-

tion languages (Rose et al., 2014) or EMG (Popoola

et al., 2016).

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

338

3.2 Graph Transformations

Model instances may be interpreted as graphs, as a

model typically constitutes a spanning containment-

tree whose elements are interconnected with cross-

tree edges. As a consequence, a model transfor-

mation is regarded as a problem in the domain of

graph transformations (Ehrig et al., 2005). In general,

graph-based systems may be classiﬁed into two dif-

ferent categories: Graph-rewrite systems and graph

grammars. For the application scenario of bidirec-

tional model-to-model transformations, a special kind

of graph grammars – triple graph grammars (Sch

urr,

1994) – are used typically. Graph rewriting implies

that the graphs are transformed by applying rewrite

rules, which specify the replacement of a graph pat-

tern (left-hand side) by a subgraph to be embedded

into the overall host graph. Triple Graph Grammars

(TGG) (Sch

urr, 1994) interpret both source and target

models as graphs and additionally a correspondence

graph whose nodes reference corresponding elements

from both source and target graphs, respectively, is

used. TGGs allow to describe model transformations

in a highly declarative way by means of production

rules, which are used to describe the simultaneous ex-

tension of the involved graphs.

3.3 Triple Graph Transformation

System

As stated above, graphs may be used to represent

models in a natural way and graph transformations

declaratively describe modiﬁcations of graph struc-

tures. In order to maintain consistency between in-

terdependent and evolving models, a graph transfor-

mation system is necessary dealing with at least two

graphs: a source graph s, and a target graph t. When

incremental change propagation is required, an addi-

tional correspondence graph c is placed in between

s and t, in order to maintain traceability links. Al-

together, this results in a triple graph transformation

system (TGTS) comprising rules for deﬁning source-

to-target and target-to-source transformations and ac-

tions for checking consistency and repairing inconsis-

tencies. TGGs are able to automatically derive a cor-

responding TGTS from a TGG speciﬁcation but, as

described in (Buchmann et al., 2009) and (Buchmann

and Westfechtel, 2016), the TGG approach suffers

from certain limitations which have been unveiled

in our case study. As a consequence, we decided

to provide an alternative implementation by hand-

crafting the TGTS which deals with the models in-

volved in this use case. Please note that we intention-

ally decided to implement the TGTS manually rather

than using graph transformation tools, like Henshin

(Arendt et al., 2010), to specify the corresponding

forward and backward rules since we wanted to com-

pare the bidirectional approaches with manual imple-

mentations of model transformations in a current pro-

gramming language.

4 BXtend FRAMEWORK

Developing a Triple Graph Transformation System

by hand seems to be a laborious task at ﬁrst glance:

Each alteration of the involved graphs needs to be

addressed, including generations, modiﬁcations and

deletions. Furthermore, each transformation direction

needs to be speciﬁed separately. In addition, rules

for checking consistency and establishing correspon-

dences are required. In the following, we present our

framework BXtend, which helps transformation de-

velopers to easily create a TGTS for bidirectional and

incremental model transformations. The framework

takes care of the correspondence model and detecting

modiﬁcations and deletions. Thus, the user can focus

on specifying the forward and backward rules for the

transformation.

4.1 Correspondence Model

In order to implement a TGTS, besides source and

target graph, a correspondence graph is needed. It

turned out, that a simple correspondence model, as

depicted in Figure 1 is sufﬁcient for all transformation

problems that we encountered so far.

Figure 1: Correspondence metamodel.

A Transformation contains an arbitrary number

of correspondence elements (Corr). In order to es-

tablish traceability links, such elements always refer

to at least one EObject from the source model and

one EObject from the target model. In general, the

easiest kind of mapping are 1:1 mappings. Thus, for

the Corr class at maximum one source and one tar-

get element are allowed. In case of 1:n mappings,

BXtend - A Framework for (Bidirectional) Incremental Model Transformations

339

which are also possible, no additional elements are

created in the correspondence model nor is the upper

bound for source or target elements extended. Rather

the additional elements (2-n) are maintained manu-

ally in the rule that covers the basic (1:1) mapping.

Please note that the user may also extend the corre-

spondence model by subclassing from the Corr class

and add m:n relationships between source and target

model elements if necessary.

The main purpose of the correspondence model is

to establish traceability links between source and tar-

get elements. The framework checks the correspon-

dence model before modifying source or target mod-

els in order to detect updates or deletions of model

elements.

4.2 Transformation Rules

As stated in Section 3.3, a triple graph transformation

system may be used for bidirectional and incremental

model transformations. Our BXtend framework im-

plements such a TGTS by using the correspondence

model as correspondence graph c. Maintaining the

correspondence graph is done by the framework, the

transformation engineer can focus on the respective

rule speciﬁcations for forward and backward transfor-

mations.

When specifying a model transformation, the soft-

ware engineer needs to decide in which direction the

spanning containment tree should be processed, i.e.

in a bottom-up way by starting at the leaves, or top-

down when the root element is considered ﬁrst. As

declarative approaches, like QVT-R or TGGs perform

a topological sort of model elements, transformation

developers have very limited inﬂuence on the trans-

formation order. Thus, the developer must typically

assume the resulting ordering of the rules (and the ex-

ecution semantics), when the model transformation is

speciﬁed.

Contrastingly, in our approach, the transformation

order is fully under the control of the software en-

gineer. I.e., when strictly following a top-down order

the user can assume that container elements in the tar-

get model already exist, when their child elements are

created.

The common behavior (including management of

the correspondence model) is implemented in an ab-

stract base class, which all user-implemented trans-

formation rules need to inherit from. Listing 1 shows

a cutout of this class with the most important meth-

ods, which handle the correspondence model getOr-

CreateCorrModelElement and the on-demand cre-

ation of source and target model elements getOrCre-

ateSourceElem, getOrCreateTargetElem.

Listing 1: Cutout of the abstract base class Elem2Elem.

1 abstract class Elem2Elem {

2 ...

3 def getCorrModelElem(EObject obj) {

4 (corrModel.contents?.get(0) as Transformation).

correspondences.

5 findFirst[corr |

6 corr.sourceElement == obj || corr.

targetElement == obj]

7 }

9 def getOrCreateCorrModelElement(EObject obj) {

10 var Corr corr = obj.getCorrModelElem

11 if (corr == null) {

12 corr = corrFactory.createBasicElem => [

13 if (obj.eClass.EPackage instanceof

sourcePackage)

14 sourceElement = obj

15 if (obj.eClass.EPackage instanceof

targetPackage)

16 targetElement = obj ]

17 (corrModel.contents.get(0) as Transformation).

correspondences += corr

18 }

19 }

21 def getOrCreateSourceElem(Corr corr, EClass clazz) {

22 var EObject source = corr.sourceElement

23 if (corr.sourceElement == null) {

24 source = sourceFactory.create(clazz)

25 corr.sourceElement = source

26 } return source

27 }

29 def getOrCreateTargetElem(Corr corr, EClass clazz) {

30 var EObject target = corr.targetElement

31 if (corr.targeteElement == null) {

32 target = targetFactory.create(clazz)

33 corr.targetElement = target

34 } return target

35 }

36 }

Listing 2 depicts a cutout of the class which

serves as an entry point for the transformation. The

class provides methods sourceToTarget() and tar-

getToSource(), which call the corresponding meth-

ods from the rule classes in the order speciﬁed by the

user (please note, these methods are omitted from the

listing due to space restrictions). Furthermore, this

class contains methods dealing with the deletion of

elements, as shown in the cutout in Listing 2.

Listing 2: Cutout of the entry class for the transformation.

1 class Source2TargetTransformation {

2 ...

3 def private deleteUnreferencedSourceElements() {

4 val List<EObject> deletionList = newArrayList

5 (corrModel.contents?.get(0) as Transformation).

correspondences.

6 filter[c | c.sourceElement == null].

7 forEach[c |

8 if (c.targetElement != null) {

9 deletionList += c.targetElement

10 }

11 deletionList += c

12 ]

13 deletionList.forEach[e | EcoreUtil.delete(e,

true)]

14 }

15 ...

In order to determine elements which need to

be deleted, the correspondence model is checked at

the end of the transformation. In case of Listing 2,

the method deleteUnreferencesSourceElements

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

340

is called at the end of the sourceToTarget() trans-

formation. If correspondence model elements exist,

in which the reference sourceElement is empty, the

corresponding target element is deleted. Afterwards

the correspondence element is deleted, too. An anal-

ogous method is used to determine deletions in the

target model.

5 EXAMPLE

To demonstrate the ﬂexibility and feasibility of our

approach, we chose the example “Families to Per-

sons” which is well-known in the model transforma-

tion community. Furthermore, the example is part of

the ATL (Jouault et al., 2008) transformation zoo. The

example was selected as a use case for the 2017 Trans-

formation Tool Contest (TTC)

and we contributed a

solution written with the help of the BXtend frame-

work presented in this paper and integrated it into the

Benchmarx framework (Anjorin et al., 2017), which

is intended to compare BX approaches. Please note

that our solution was provided as part of the reference

solutions and therefore it was not published yet.

5.1 Problem

Figure 2: Families meta model.

Figures 2 and 3 depict the two meta models which

are involved in the transformation scenario. In the

following we refer to the families model as “source

model” and the persons model as the “target model”.

The root element of the source model is a Fami-

lyRegister which may contain an arbitrary number

http://transformation-tool-contest.eu/

of families (Family). Each family has members who

are distinguished by their roles. The meta model al-

lows for at most one father and mother and an arbi-

trary number of sons and daughters. The Person-

tion of persons (Person) who are either male (Male)

or female (Female). It is important to note that we

can not assume any key properties in neither model.

Consequently, there may be multiple families with the

same name and name clashes may also occur within

the same family. In the person register there may be

multiple persons with the same name and even the

same birth date. No speciﬁc ordering of the collec-

tion is assumed.

Figure 3: Persons meta model.

Consistency between a families and a persons

model is established, if a bijective mapping exists

which pairs mothers and daughters (fathers and sons)

with females (males) and the name of every person p

is “f.name, m.name”, where m is the member in the

family f paired with p.

Please note that in this example, the forward trans-

formation is straightforward by mapping each fam-

ily member to a person of the same gender and com-

posing the person’s name from the surname and ﬁrst

name while leaving the birthday unset. The back-

ward transformation however is non-deterministic, as

a person may be mapped either to a parent or a child,

and persons may be grouped into families in differ-

ent ways. As a consequence, two boolean parame-

ters are introduced which control the behavior of the

backward transformation and allow for user-deﬁned

conﬁgurations. One parameter controls whether a

new person is added to an existing family (if avail-

able), or a new family is created with the person as a

single family member. The other parameter controls

whether a person is mapped to the parent or child role

BXtend - A Framework for (Bidirectional) Incremental Model Transformations

341

within the family. In case both parameters are set to

true, the ﬁrst one takes precedence, which means in

case there is a family with a matching surname but the

parent role is already occupied, the person is added as

a child.

This transformation scenario comes with informa-

tion loss in both directions, as in the forward direction

the distinction between parents and children as well as

the aggregation into families is lost. Birthdays are lost

in the backward direction. As a result, this case is an

example for a round-trip scenario, where both mod-

els may be edited and changes have to be propagated

back and forth.

5.2 Solution

We solved this transformation scenario with our

BXtend framework. Our solution comprises three

classes, implementing rules for transforming:

• a FamilyRegister to a PersonRegister and vice

versa

• fathers and sons (identiﬁed by the respective con-

tainment relation ships between Family and Fam-

ilyMember) to Male persons and vice versa

• mothers and daughters to Female persons and

vice versa

We did not need a separate rule dealing with Fam-

ilys as there is no counterpart for a family in the per-

son model.

Listing 3: Forward transformation of mothers and daughters

to female persons.

1 override sourceToTarget() {

2 sourceModel.allContents.filter(typeof(Family))

3 .forEach[

4 family |

5 val corrRegister = family.eContainer.

getCorrModelElement

6 val females = newArrayList

7 females.addAll(family.daughters)

8 if (family.mother != null)

9 females.add(family.mother)

10 females.forEach[

11 member |

12 val corrFemale = member.

getOrCreateCorrModelElement()

13 val female = corrFemale.

getOrCreatePersonElement(family.name + ",

" + member.name,

14 PersonsPackage.eINSTANCE.female)

15 ]

16 ]

17 }

As stated earlier, our BXtend framework works in-

crementally. To this end, we need to check the corre-

spondence model prior to each modiﬁcation of source

and target models. This check is done in line 8 of

Listing 4.

As stated above, the backward transformation is

non-deterministic for the following reasons:

• it is not clear to which family a person belongs,

especially if there are duplicate names

• a person may be added as a parent or a child

To this end, we developed a conﬁgurable back-

ward transformation which can be executed in three

different modes:

• using default values for the decision parameters

• a runtime-conﬁgurable version, where the param-

eters may be supplied via the API

• by providing a GUI where the user may edit corre-

spondences between family members and persons

Listing 4: Backward transformation of male persons.

1 override targetToSource() {

2 targetModel.allContents.filter(typeof(Male)).forEach

[ p |

3 val corr = p.getOrCreateCorrModelElement

4 val source = corr.getOrCreateSourceElem(

FamiliesPackage.eINSTANCE.familyMember) as

FamilyMember

5 val firstName = p.name.split(", ").get(1)

6 val familyName = p.name.split(", ").get(0)

7 val sourceFamily = source.eContainer() as Family

8 val famRegister = p.eContainer().getCorrModelElem

().source as FamilyRegister

10 source.name = firstname

12 if (sourceFamily == null || sourceFamily.name !=

familyName) {

13 val family = sourceFamily.getOrCreateFamily(p,

famRegister)

14 p.addToFamily(family, source, [family.father], [

family.father = it], [family.sons += it])

16 if (sourceFamily != null && sourceFamily.father

== null && sourceFamily.mother == null &&

17 sourceFamily.sons.empty && sourceFamily.

daughters.empty && decision.

deleteEmptyFamily(sourceFamily, source))

18 EcoreUtil.delete(sourceFamily, true)

19 }

20 ]

21 }

Listing 5: Helper method for backward transformation.

1 def protected getOrCreateFamily(Family sourceFamily,

Person p, FamilyRegister fregister) {

2 val familyname = p.name.split(", ").get(0)

3 val families = fregister.getFamilies(familyname)

4 var family = decision.getFamily(families, p,

sourceFamily)

5 if (family == null) {

6 family = createFamilyElement(FamiliesPackage.

eINSTANCE.family) as Family => [name =

familyname]

7 fregister.families += family

8 decision.linkPersonToFamily(p, family)

9 }

10 family

11 }

Listing 4 depicts the backward transformation of

male persons. The transformation is invoked for any

male person in the target model. For each matching

model element, the correspondence model element is

retrieved (or created if there is no such element) as

shown in line 3 of Listing 4. Afterwards, the Family-

Member element of the source model is retrieved or

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

342

created in line 4. As explained earlier, in the person

model only one attribute is used to store both ﬁrst and

last names, separated by a comma. The value of this

attribute needs to be split in the backward direction

in order to obtain the corresponding attribute values

for Family and FamilyMember. FamilyMembers

are connected to their respective Family by a contain-

ment relationship. In order to get the family for a fam-

ily member, the generic eContainer method of the

EMF framework is used. In case no such family exists

(the family member has been newly created), or the

family name does not match the expected value (per-

son name has been changed), a helper method getOr-

CreateFamily (c.f., Listing 5) is called. The helper

method getOrCreateFamily retrieves all matching

families from the family register. Depending on the

value of the boolean parameters controlling the as-

sociation of family members to families a family or

null is returned. If no family was returned, it is cre-

ated in lines 6-8 of Listing 5. Afterwards the person

is added to the retrieved family in line 14 of Listing

4 by calling the helper method addToFamily, where

the family member is added to the family using the

proper containment relation and taking into account

the conﬁguration parameters. E.g., a male person may

be added as a father (in case the boolean variable is set

accordingly), or as a son otherwise. Please note, that

in case the parent role of the family is taken already,

the family member will be added as a son, regardless

the value of the conﬁguration parameter.

6 EVALUATION

In order to demonstrate the feasibility of our frame-

work, we tested it in several bidirectional transfor-

mation scenarios. For the transformation tool con-

test, we implemented the Families 2 Persons example

as discussed in Section 5. Our solution was able to

pass all provided test cases, while the TGG and QVT-

R based solutions implemented with eMoﬂon(Anjorin

et al., 2012) and medini QVT

failed in some of them.

Surprisingly, when applying LOC metrics on the re-

spective transformation descriptions it turned out that

our solution did not require signiﬁcantly more imple-

mentation effort. Even if the other formalisms are de-

signed explicitly for bidirectional transformations and

they provide a highly-declarative syntax,

Table 1 summarizes the result of a comparison of

our solution to the Families 2 Persons test case of

the transformation tool contest 2017 with other tools.

The provided transformation case contains 34 differ-

http://projects.ikv.de/qvt

ent JUnit test cases, classiﬁed into forward and back-

ward tests with both batch and incremental behavior.

Our solution written with the BXtend framework pre-

sented in this paper was able to pass all supplied test

cases. We compared the BXtend solution with the

other provided reference solutions for this transfor-

mation case, which are all based on bidirectional lan-

guages. Please note that BX languages have a pre-

deﬁned semantics for consistency analysis and repair,

which can be adopted to the speciﬁc use case only to a

very limited extent and thus the provided transforma-

tion tool does not always ﬁt the speciﬁc requirements

of the transformation case.

We also evaluated our BXtend solution in a

real-world scenario: Round-trip engineering between

UML class diagrams and Java source code. The

transformation problem was solved using three differ-

ent formalisms: TGGs and the tool TGG Interpreter

(Buchmann and Westfechtel, 2016), QVT-R (Greiner

et al., 2016) and a hand-crafted triple graph transfor-

mation system (Buchmann and Greiner, 2016). The

following lessons have been learned and motivated us

to provide the BXtend framework:

Implementation Effort. The most surprising result

was that the BXtend solution outperforms the

QVT-R solution in terms of LOC metrics. Even

if TGGs and QVT-R provide support for bidirec-

tional and incremental model-to-model transfor-

mations, both approaches required signiﬁcant ef-

fort to specify bidirectional rules for the round-

trip engineering use case. 1032 lines of BXtend

code were required compared to 1905 lines of

QVT-R code (in the round-trip engineering use

case).

Redundancy of the Rule Set. The TGG approach

suffers from the redundancy of the rule set, caused

by inherent properties of triple rules: As each

rule describes a synchronous extension of source,

correspondence and target graph respectively, the

subgraph to be added is ﬁxed in the rule. Con-

sequently, it has to be deﬁned statically, which

nodes and edges of which types have to be cre-

ated and how the attribute values have to be cal-

culated. As a result, variability in right hand sides

of rules leads to several similar rules. We ob-

served a similar effect in the QVT-R speciﬁcation,

as it does not support variability either and thus,

slight differences have to be addressed in differ-

ent rules where large parts of the rule body needs

to be copied & pasted. The BXtend solution does

not suffer from this problem, since language fea-

tures like inheritance, genericity or control struc-

tures are available and extensively exploited in our

solution.

BXtend - A Framework for (Bidirectional) Incremental Model Transformations

343

Table 1: Results of running the test cases for the transformation tool contest.

Total test cases BXtend eMoﬂon BiGUL QVT-R

Batch forward 7 7 7 7 7

Batch backward 11 11 11 11 11

Incremental forward 8 8 5 3 4

Incremental backward 8 8 5 4 0

Total 34 34 28 25 22

Cognitive Complexity. From the three solutions,

QVT-R imposes the highest cognitive complex-

ity to the transformation developer for several rea-

sons: The rules are quite complex, even if there is

a declarative way of specifying them using a tex-

tual syntax. Often, it is not clear in which order

statements in when and where clauses are actu-

ally executed. Equations play a dual role, as de-

pending on the binding state of its left and right-

hand side, an equation may serve as an additional

constraint or as a simple assignment. Neverthe-

less, the transformation developer needs to spec-

ify rules which can be executed in both directions,

which means that operational semantics of QVT-

R needs to be taken into account carefully. In the

TGG approach, the transformation engineer has

to specify the rules in a way which allows for a

correct interplay, without explicitly specifying de-

pendencies between rules. Again, the execution

in both transformation directions has to be con-

sidered. In the BXtend approach, the cognitive

complexity for the developer is reduced, as there

are separate rules for each transformation direc-

tion. On the other hand, the developer needs to

make sure that both transformation directions ac-

tually match.

Level of Abstraction. The TGG speciﬁcation is

highly declarative, allowing for transformations in

both directions from only a single rule set. Fur-

thermore, the TGG engine deals with changes in

the participating models. Triple rules may be

speciﬁed in an intuitive graphical syntax and a

large number of rules in the considered transfor-

mation scenario have modest size and complexity.

QVT-R rules are also highly declarative and they

also only require one single rule set for execut-

ing transformations in both directions. Further-

more, QVT-R employs OCL statements in both

queries and when/where clauses allowing for a

compact and concise speciﬁcation of dependen-

cies between relations. The BXtend solution re-

sides on the lowest level of abstraction, as Xtend

(the programming language on which our solution

is based) primarily is a procedural object-oriented

language augmented with some declarative lan-

guage constructs like lambda expressions. How-

ever, in the use cases considered so far this fact

did not cause negative effects on the required im-

plementation effort or on the complexity of the re-

sulting forward and backward rules.

7 CONCLUSION AND FUTURE

WORK

In this paper, we presented a light-weight frame work

for specifying bidirectional and incremental model-

to-model transformations based on the Xtend pro-

gramming language. We showed the feasibility of

our approach by comparing it to standard M2M ap-

proaches in the popular Families 2 Persons trans-

formation scenario. Furthermore, we also applied

our approach in a real-world case study dealing with

round-trip engineering between UML class diagrams

and Java source code, which was also solved using

TGGs and QVT-R. This case study unveiled several

drawbacks of the TGG and QVT-R approach which

are not present in our BXtend solution.

Current work addresses the implementation of fur-

ther model-to-model transformation scenarios, as de-

scribed in (Westfechtel, 2016). Once the solutions are

implemented, we plan to add respective test cases to

the Benchmarx framework (Anjorin et al., 2017) to

obtain further results comparing our BXtend frame-

work with other solutions based on TGGs or QVT-R.

REFERENCES

Anjorin, A., Diskin, Z., Jouault, F., Ko, H.-S., Leblebici, E.,

and Westfechtel, B. (2017). Benchmarx reloaded: A

practical framework for bidirectional transformations.

In Eramo, R. and Johnson, M., editors, Sixth Inter-

national Workshop on Bidirectional Transformations

(BX 2017), CEUR Workshop Proceedings.

Anjorin, A., Lauder, M., and Sch

urr, A. (2012). eMoﬂon:

A Metamodelling and Model Transformation Tool. In

orrle, H., Botterweck, G., Bourdell

es, M., Kolovos,

D., Paige, R., Roubtsova, E., Rubin, J., and Tolvanen,

J., editors, Joint Proceedings of the Co-located Events

at the 8th European Conference on Modelling Foun-

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

344

dations and Applications (ECMFA 2012), page 348,

Copenhagen, Denmark. Technical University of Den-

mark (DTU). ISBN: 978-87-643-1014-6.

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

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

and Tools for In-Place EMF Model Transformations.

In Petriu, D. C., Rouquette, N., and Haugen, Ø., ed-

itors, Proceedings 13th International Conference on

Model Driven Engineering Languages and Systems

(MODELS 2010), Part I, volume 6394 of Lecture

Notes in Computer Science, pages 121–135, Oslo,

Norway. Springer-Verlag.

Buchmann, T., Dotor, A., and Westfechtel, B. (2009).

Triple Graph Grammars or Triple Graph Transforma-

tion Systems? In Chaudron, M. R., editor, Models

in Software Engineering, Workshops and Symposia

at MODELS 2008, volume 5421 of Lecture Notes

in Computer Science, pages 138–150. Springer Ver-

lag. best paper of Workshop MCCM 2008, Toulouse,

France, September/October 2008.

Buchmann, T. and Greiner, S. (2016). Handcrafting a Triple

Graph Transformation System to Realize Round-trip

Engineering Between UML Class Models and Java

Source Code. In Maciaszek, L. A., Cardoso, J. S.,

Ludwig, A., van Sinderen, M., and Cabello, E., edi-

tors, Proceedings of the 11th International Joint Con-

ference on Software Technologies (ICSOFT 2016) -

Volume 2: ICSOFT-PT, Lisbon, Portugal, July 24 -

26, 2016., pages 27–38. SciTePress.

Buchmann, T. and Westfechtel, B. (2016). Using Triple

Graph Grammars to Realize Incremental Round-Trip

Engineering. IET Software. Online ﬁrst, http://digital-

library.theiet.org/content/journals/10.1049/iet-

sen.2015.0125.

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

vey of model transformation approaches. IBM Sys-

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

Ehrig, K., Guerra, E., Lara, J. D., Lengyel, L., Leven-

dovszky, T., Prange, U., Taentzer, G., Varro, D.,

and Varro-Gyapay, S. (2005). Model transformation

by graph transformation: A comparative study. In

Proceedings of the International workshop on model

transformations in practice (MTiP 2005), Satellite

Event of MoDELS 2005, volume 3844 of Lecture

Notes in Computer Science, pages 71–80, Montego

Bay, Jamaica. Springer-Verlag.

Giese, H., Hildebrandt, S., and Lambers, L. (2014). Bridg-

ing the gap between formal semantics and implemen-

tation of triple graph grammars - Ensuring confor-

mance of relational model transformation speciﬁca-

tions and implementations. Software and System Mod-

eling, 13(1):273–299.

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

Bidirectional Transformations with QVT-R: A Case

Study in Round-trip Engineering UML Class Mod-

els and Java Source Code. In MODELSWARD 2016

- Proceedings of the 4rd International Conference

on Model-Driven Engineering and Software Develop-

ment, Rome, Italy, 19-21 February, 2016., pages 15–

27.

Jouault, F., Allilaire, F., B

ezivin, J., and Kurtev, I. (2008).

ATL: A model transformation tool. Sci. Comput. Pro-

gram., 72(1-2):31–39.

Kindler, E. and Wagner, R. (2007). Triple graph grammars:

Concepts, extensions, implementations, and applica-

tion scenarios. Technical Report tr-ri-07-284, Soft-

ware Engineering Group, Department of Computer

Science, University of Paderborn.

Klassen, L. and Wagner, R. (2012). EMorF - a tool for

model transformations. In Krause, C. and Westfechtel,

B., editors, Proceedings of the 7th International Work-

shop on Graph Based Tools (GraBaTs 2012), ECE-

ASST 54, page 6 p., Bremen, Germany.

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

MDA Distilled. Addison Wesley Longman Publishing

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

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

Query/View/Transformation Speciﬁcation. Needham,

MA, formal/2015-02-01 edition.

OMG (2015b). Meta Object Facility (MOF) Version 2.5.

OMG, Needham, MA, formal/2015-06-05 edition.

Popoola, S., Kolovos, D. S., and Rodriguez, H. H. (2016).

EMG: A domain-speciﬁc transformation language for

synthetic model generation. In Theory and Practice

of Model Transformations - 9th International Confer-

ence, ICMT 2016, Held as Part of STAF 2016, Vienna,

Austria, July 4-5, 2016, Proceedings, pages 36–51.

Rose, L. M., Kolovos, D. S., Paige, R. F., Polack, F. A. C.,

and Poulding, S. M. (2014). Epsilon ﬂock: a model

migration language. Software and System Modeling,

13(2):735–755.

Sch

urr, A. (1994). Speciﬁcation of Graph Translators

with Triple Graph Grammars. In Tinhofer, G., edi-

tor, Proceedings of the 20th International Workshop

on Graph-Theoretic Concepts in Computer Science

(WG 1994), volume 903 of LNCS, pages 151–163,

Herrsching, Germany. Springer-Verlag.

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

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

Eclipse Series. Addison-Wesley, Boston, MA, 2nd

edition.

Stevens, P. (2007). Bidirectional model transformations in

QVT: semantic issues and open questions. In Model

Driven Engineering Languages and Systems, 10th In-

ternational Conference, MoDELS 2007, Nashville,

USA, September 30 - October 5, 2007, Proceedings,

pages 1–15.

olter, M., Stahl, T., Bettin, J., Haase, A., and Helsen, S.

(2006). Model-Driven Software Development: Tech-

nology, Engineering, Management. John Wiley &

Sons.

Westfechtel, B. (Online ﬁrst, 2016). Case-Based

Exploration of Bidirectional Transformations in

QVT Relations. Software and Systems Modeling.

doi:10.1007/s10270-016-0527-z.

BXtend - A Framework for (Bidirectional) Incremental Model Transformations

345