Combining a Declarative Language and an Imperative Language for

Bidirectional Incremental Model Transformations

Matthias Bank, Thomas Buchmann and Bernhard Westfechtel

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

atsstrasse 30, 95440 Bayreuth, Germany

Keywords:

Model-Driven Software Development, Model Transformation, Bidirectional Transformation, Incremental

Transformation.

Abstract:

Bidirectional incremental model transformations are crucial for supporting round-trip engineering in model-

driven software development. A variety of domain-speciﬁc languages (DSLs) have been proposed for the

declarative speciﬁcation of bidirectional transformations. Unfortunately, previous proposals fail to provide

the expressiveness required for solving practically relevant bidirectional transformation problems. To address

this shortcoming, we propose a layered approach: On the declarative level, a bidirectional transformation

is speciﬁed concisely in a small and light-weight external DSL. From this speciﬁcation, code is generarated

into an object-oriented framework, on top of which the behavior of the transformation may be complemented

and adapted in an imperative internal DSL. An evaluation with the help of a well-known transformation case

demonstrates that this layered hybrid approach is both concise and expressive, and also scalable.

1 INTRODUCTION

A wide range of application domains demands for

bidirectional transformations (bx), which are mecha-

nisms for specifying and maintaining consistency be-

tween two or more models. Many areas, including

model-driven software development (MDSD) (V

olter

et al., 2006) have been subject for studies of bx.

Roundtrip engineering in model-driven architecture

(MDA)(Mellor et al., 2002) processes e.g. is a use

case for bx.

Unidirectional languages and tools may be used

to solve bx problems, resulting in increased effort of

maintaining separate implementations with mutually

consistent behavior. To cope with this fact, a wide

range of dedicated domain-speciﬁc languages (DSLs)

and accompanying tools for bx have been developed

in the past, promising to assist transformation devel-

opers in solving bx problems more efﬁciently and

reliably. A detailed and feature-based classiﬁcation

of numerous bx approaches and tools may be found

in (Czarnecki and Helsen, 2006) and (Hidaka et al.,

2016).

Typically, bx approaches reside on a high level of

abstraction. They provide declarative languages that

relieve the transformation developer from explicitly

specifying both transformation directions as well

as incremental behavior. This is achieved in differ-

ent ways: In grammar-based approaches, a gram-

mar is deﬁned to generate consistent pairs of models

(Sch

urr, 1994). In relational approaches (Cicchetti

et al., 2010), consistency relations between source

and target models are deﬁned. In functional ap-

proaches (Foster et al., 2007), one transformation di-

rection is speciﬁed explicitly, and the opposite trans-

formation is derived automatically.

Unfortunately, the declarative bx approaches that

have been proposed so far suffer from a problem

which is shared by all of them: While they guaran-

tee certain bx laws (regarding consistent behavior of

forward and backward transformations), they lack ex-

pressiveness: Certain bx problems cannot be solved

at all, or they can be solved only partially, or they can

be solved, but the speciﬁcation effort is much higher

than expected. In previous work, this claim was sub-

stantiated by a number of benchmarks and case stud-

ies, covering both artiﬁcial and real-world transfor-

mation scenarios (Anjorin et al., 2020; Westfechtel,

2019; Westfechtel and Buchmann, 2019; Buchmann

and Westfechtel, 2013; Greiner et al., 2016; Buch-

mann and Westfechtel, 2016).

These observations motivated us to setup BXtend

(Buchmann, 2018) – a framework for bidirectional in-

cremental model transformations based on the pro-

Bank, M., Buchmann, T. and Westfechtel, B.

Combining a Declarative Language and an Imperative Language for Bidirectional Incremental Model Transformations.

DOI: 10.5220/0010188200150027

In Proceedings of the 9th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2021), pages 15-27

ISBN: 978-989-758-487-9

Transformation

code (BXtendDSL)

Hand written code

(BXtend)

Generated code

(BXtend)

Framework code

(BXtend)

Transformation code

(BXtend)

Transformation

developer

Source model

Correspondence

model

Target model

Figure 1: Layered approach to bidirectional transforma-

tions.

gramming language Xtend

. The framework pro-

vides a set of reusable classes that are extended to

program bidirectional transformations. Thus, a bidi-

rectional transformation is speciﬁed in an imperative

language which provides for the required expressive-

ness to solve non-trivial bx problems. The BXtend

approach was evaluated successfully in several trans-

formation scenarios (Anjorin et al., 2020; Westfech-

tel and Buchmann, 2019; Bank et al., 2020; Greiner

et al., 2016). Although in BXtend both transformation

directions have to be programmed explicitly, the re-

sulting transformation deﬁnitions are still even more

concise than in some declarative approaches. This is

due to lacking ﬂexibility of the respective languages,

resulting in redundant rule sets.

This paper complements previous work on BX-

tend by providing a declarative language called BX-

tendDSL. While the BXtend framework provides

an imperative internal DSL (based on Xtend), BX-

tendDSL is a small and light-weight declarative ex-

ternal DSL. In BXtendDSL, the transformation de-

veloper essentially declares correspondences between

elements of source and target languages. Intention-

ally, BXtendDSL is incomplete, i.e., usually it is not

possible to solve the respective transformation case

completely in this external DSL (this would have re-

quired a considerably more expressive and compre-

hensive language). Rather, from a transformation def-

inition written in BXtendDSL code may be generated

on top of the BXtend framework. Subsequently, the

generated code is extended with manually written im-

perative code. Altogether, this results in a layered

approach (Figure 1): First, the external DSL is used

to specify correspondences declaratively. In a second

step, the internal DSL is employed to take care of all

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

the algorithmic details required to solve the respective

bx problem completely.

In this paper, we start by outlining our overall ap-

proach to specifying bidirectional incremental trans-

formations (Section 2). Subsequently, we present

BXtendDSL (Section 3). We illustrate our approach

by a well-known bx problem: the Families-to-Persons

case (Section 4). This example is used in Section 5

to perform a thorough evaluation comparing our new

layered approach to the plain BXtend solution, re-

garding the following research questions:

1. Is the size of the resulting transformation deﬁni-

tion smaller, indicating a reduced implementation

effort for the transformation developer?

2. Does the resulting transformation fulﬁll the qual-

ity criteria? I.e., it must pass all tests that the BX-

tend solution also passes.

3. Is the overall performance affected by introducing

the additional layer of abstraction?

Finally, related work is discussed in Section 6,

while Section 7 concludes the paper.

2 APPROACH

As stated above, BXtend (Buchmann, 2018) is a

pragmatic approach to programming bx, with a spe-

cial emphasis to address problems encountered in

the practical application of existing bx languages and

tools. Built upon the programming language Xtend,

BXtend provides the full-ﬂedged potential of imper-

ative programming, combined with powerful declara-

tive parts used for describing transformation patterns.

Technically, the transformation developer pro-

grams a Triple Graph Transformation System (TGTS)

(Buchmann et al., 2009) using the BXtend frame-

work, employing a correspondence model which may

be manipulated using an internal DSL. The project

presented in this paper – BXtendDSL – extends

the framework and furthermore provides an exter-

nal DSL, which allows for a concise speciﬁcation of

(bidirectional) transformation rules in a declarative

textual syntax.

When working with the stand-alone BXtend

framework, certain classes have to be adapted for

speciﬁc transformations in several places, e.g. when

model elements are created or deleted, when user sup-

plied rules are called and for rule orchestration. Fur-

thermore, the standard generic correspondence model

only supports 1:1 correspondences. If 1:n or m:n cor-

respondences are required, manual adaptions are pos-

sible – resulting in additional adaptations of the in-

ternal DSL for accessing and manipulating the cor-

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

BaseBase

GeneratedGenerated

ManualManual

src-gen

framework

src-once

Elem2ElemElem2Elem

RuleARuleA

RuleAImplRuleAImpl

RuleBRuleB

Figure 2: Architecture, based on the generation gap pattern.

respondence model. The transformation developer

needs to specify both transformation directions sep-

arately, resulting in BXtend transformation rules with

a signiﬁcant portion of repetitive standard code.

BXtendDSL aims at minimizing the effort for

the transformation developer signiﬁcantly, by auto-

matically generating the transformation-speciﬁc code

from the DSL containing the transformation def-

inition into the corresponding BXtend framework

classes by keeping the ﬂexibility of BXtend at the

same time, since all generated classes may still be

adapted freely. Furthermore, BXtendDSL supports

m:n correspondences and provides a new internal

DSL, which allows for an even more efﬁcient ac-

cess to the correspondence model. The concise and

declarative notation of transformation rules allows to

specify patterns between attributes and references of

classes of both source and target model which are

subject to transformation. The rule body provides a

less-verbose syntax for model access and allows for

a consistent speciﬁcation of both transformation di-

rections. BXtend transformation classes are automati-

cally derived from the DSL avoiding the need of man-

ually supplying repetitive standard code. All aspects

of the transformation which can not be expressed ad-

equately in a declarative way may be supplied imper-

atively using predeﬁned hooks in the generated code.

Figure 2 depicts the architecture with the DSL and all

derived artifacts on the different levels, designed as a

generation gap pattern (Fowler, 2011).

The framework comprises generic code for ac-

cessing the correspondence model and for transfor-

mation rules (depicted in the row framework). Based

on code speciﬁed in the DSL ﬁle, generated classes

inherit from those base classes adding speciﬁc behav-

ior (src-gen). If parts of the transformation can not be

expressed adequately in a declarative way in the DSL,

extension points are generated (src-once), where im-

perative code may be added by the transformation de-

veloper on the level of the Xtend programming lan-

guage.

TransformationTransformation

ruleId: EString

Corr

ruleId: EString

Corr

CorrElemCorrElem

elements: EObject[0..*]

MultiElem

elements: EObject[0..*]

MultiElem

element: EObject

SingleElem

element: EObject

SingleElem

0..*correspondences 0..*correspondences

source

0..*

source

0..*

target 0..*target 0..*

Figure 3: Correspondence metamodel (Ecore).

Incremental change propagation relies on a persis-

tently stored correspondence model which has been

generalized signiﬁcantly compared to its predecessor

version (Buchmann, 2018). Figure 3 depicts the un-

derlying metamodel. A Transformation maintains a set

of correspondences of class Corr, each of which stores

the respective applied rule (attribute ruleId) and refer-

ences to source and target elements of class CorrElem.

In this way, m:n correspondences may be represented.

Correspondence elements refer to the actual objects of

the source and the target model by attributes of type

EObject. A correspondence element may in turn rep-

resent a single object (SingleElem) or a set of objects

(MultiElem). Sets of objects may be used for example

when dealing with transformation problems which re-

quire folding/unfolding operations of source and tar-

get elements respectively and go beyond the scope of

this paper. However, the interested reader is referred

to (Bank, 2019) for further details.

3 LANGUAGE

In this section, we describe the syntax and semantics

of BXtendDSL in general terms; an application fol-

lows in the next section.

3.1 Syntax

BXtendDSL is a small and light-weight textual lan-

guage for the declarative speciﬁcation of bidirectional

incremental model transformations. Transformations

deﬁned in BXtendDSL deﬁne relations between lan-

guage elements and are located at a high level of

abstraction. However, the expressiveness of BX-

tendDSL is limited. Several language constructs pro-

vide hooks for the implementation of imperative as-

pects of the transformation at the BXtend layer. Be-

low, we will explain the language constructs of BX-

tendDSL, referring to Listing 1, which will be ex-

plained in detail in Section 4.

BXtendDSL is designed for the bidirectional

transformation between two models, called source

model and target model, respectively. The keywords

sourcemodel and targetmodel are followed by refer-

ences (URLs) to the respective metamodels. Actual

Combining a Declarative Language and an Imperative Language for Bidirectional Incremental Model Transformations

instances of these metamodels are supplied when the

transformation is executed.

A transformation may be conﬁgured with the help

of options. Each option will be bound to a Boolean

value at runtime when the transformation is executed.

Options are only deﬁned, but not used at the BX-

tendDSL layer; they will be queried in BXtend code

to be written by the transformation developer. In this

way, the behavior of the transformation may be con-

trolled.

BXtendDSL is a rule-based language. A BX-

tendDSL program consists of a set of rules that spec-

ify correspondences between elements of the source

and the target model. The keywords src and trg are

followed by lists of typed elements. In this way, it is

possible to deﬁne m:n correspondences.

Each element may be decorated by a list of mod-

iﬁers, each of which is indicated by a respective key-

word. Each modiﬁer requires an implementation in

BXtend; the code generator provides for the respec-

tive method hook. Modiﬁers are used for different

purposes. A ﬁlter indicates an application condition.

A creation modiﬁer stands for code that needs to be

executed when the respective element is created; like-

wise, a deletion modiﬁer is available for clean-up ac-

tions required in the course of the deletion of an ele-

ment. BXtendDSL provides a few more modiﬁers for

other purposes which are not relevant for our running

example; see (Bank, 2019).

Each rule may deﬁne a list of mappings, which de-

ﬁne correspondences between structural features (at-

tributes or references) of source and target elements.

At the BXtendDSL layer, mappings are only deﬁned;

calculation rules for the values of structural features

may have to be provided at the BXtend layer.

A mapping is deﬁned by a list of source features,

a mapping operator, and a list of target features. The

mapping operator < −− > indicates a bidirectional

mapping that is executed in both transformation direc-

tions. Likewise, the operators −− > and < −− rep-

resent unidirectional mappings (in forward and back-

ward direction, respectively).

In simple cases, a mapping may be translated into

executable code. For example, in the case of a birec-

tional 1:1 mapping between attributes of the same

type, code is generated to copy attribute values back

and forth. Similarly, in the case of a bidirectional

1:1 mapping between references to corresponding ob-

jects, code is generated for “copying” links: When an

object s is referenced in the source model, the corre-

sponding object t is referenced in the target model. In

this case, the mapping deﬁnes correspondence by re-

ferring to another rule that connects the corresponding

objects. If a mapping is not 1:1, method hooks will be

generated, where the mapping deﬁnes the signature of

the respective generated method.

3.2 Semantics

There is no declarative speciﬁcation of the seman-

tics of BXtendDSL. From a program written in BX-

tendDSL, code is generated on top of the BXtend

framework code according to the generation gap ar-

chitecture of Figure 2. In the src-gen layer, either

abstract or concrete classes are generated, depend-

ing on whether the BXtendDSL code deﬁnes the se-

mantics partially or completely. In the src-once layer,

the transformation developer has to provide all miss-

ing method implementations, but (s)he is also free to

override default behavior as required. Altogether, the

semantics of BXtendDSL programs may be adapted

in a ﬂexible way.

The framework contains an abstract class Transfor-

mation which deﬁnes the default behavior of transfor-

mations. This class provides two methods sourceTo-

Target and targetToSource for executing transforma-

tions in forward and backward direction, respectively.

Execution is structured into the following phases (as-

suming forward direction in the following):

1. Rules are executed in their textual order in the

BXtendDSL program. For each rule, its sourceTo-

Target method is called. All matches for the cur-

rent rule are retrieved (taking ﬁlters into account),

and consistency of the target elements with the

source elements is established (including the ex-

ecution of mappings). Furthermore, the method

sourceToTarget collects all created elements and

all elements to be deleted (in the target model) for

further processing.

2. For all rules, their creation hooks are executed

in turn. In this phase, the target elements to be

deleted are still available.

3. For all rules, their deletion hooks are executed in

turn. This allows for the execution of additional

operations on the model which require the ele-

ments to be deleted.

4. In a ﬁnal clean-up phase, target elements sched-

uled for deletion are actually deleted.

4 EXAMPLE

In this section we present the transformation problem

which is used as a running example in this paper, be-

fore we discuss details of our solution.

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

FamilyRegister

Family

name :String

FamilyMember

name :String

father

0..1

father

Inverse

0..1

mother

0..1

mother

Inverse

0..1

sons

0..*

sons

Inverse

0..1

daughters

0..*

daughters

Inverse

0..1

families

0..*

families

Inverse

PersonRegister

Person

name :String

birthday :Date

persons

0..*

persons

Inverse

Male

Female

Figure 4: Metamodels.

4.1 Transformation Problem

As a running example in this paper, we chose to use

the well-known Families-to-Persons benchmark (An-

jorin et al., 2017), since it allows for a quantitative and

qualitative evaluation of our DSL compared to other

bx approaches (Anjorin et al., 2020). In the trans-

formation case, two related, but differently structured

models have to be kept in synch: A families model,

with family members taking different roles within a

family, and a ﬂat set of males and females in a persons

model (c.f., Figure 4). A unique root in each model is

assumed. A family register stores an unordered col-

lection of families, where each family has members

who are distinguished by their roles. The metamodel

permits at most one mother and at most one father as

well as an arbitrary number of daughters and sons. In

contrast, a person register maintains a ﬂat unordered

collection of persons who have a birthday and are ei-

ther male or female. Please note that there may be

multiple families with the same name, family mem-

bers with the same name even within a single family,

and multiple persons with the same name and even

the same birthday.

A families model is consistent with a persons

model if a bijective mapping between family mem-

bers and persons can be established such that:

1. Mothers and daughters (fathers and sons) are

paired with females (males).

2. The name of every person p is “ f.name, m.name”,

where m is the member (in family f ) paired with

Any transformation should result in a pair of mu-

tually consistent models. However, this requirement

does not determine the behavior of the transforma-

tion in a unique way. For example, when a per-

son is inserted into the persons model, it is not clear

whether the corresponding new member should be in-

serted into an existing or a new family, and whether

the member should occupy the role of a parent or a

child. Therefore, the deﬁnition of the Families-to-

Persons benchmark includes behavioral descriptions

for all types of model changes both for forward and

backward transformations; see (Anjorin et al., 2020)

for further details.

4.2 Solution

The solution for the Families-to-Persons benchmark

is structured into a declarative and an imperative

layer, which are explained in turn below.

4.2.1 Declarative Layer (BXtendDSL)

Listing 1 shows the BXtendDSL code for the

Families-to-Persons transformation. On this declar-

ative level, the overall transformation is deﬁned only

partially. The BXtendDSL code is supplemented with

Xtend code which will be explained in the next sub-

section.

In lines 1–2, the source and target metamodels

are deﬁned on which the transformation is based.

Lines 4–6 introduce Boolean options which are used

to control the backward transformation. These op-

tions, which will be used only on the imperative layer,

deﬁne whether a member should be inserted as a par-

ent or a child and whether (s)he should be inserted

into a new or into an existing family.

The rule Register2Register maps the root contain-

ers of both models (lines 8–10). The correspond-

ing references families and persons cannot be mapped

onto each other since there is no corresponding class

for a Family in the persons model. These references

are managed via the rules Member2Female and Mem-

ber2Male, respectively.

Member2Female is used to specify the transfor-

mation of a FamilyMember to a Female person and

vice versa (lines 12–17). The rule deﬁnes two mod-

iﬁers, resulting in the creation of methods stubs at

the imperative layer. The transformation developer

needs to implement the respective bodies in order to

realizes the desired behavior. Both modiﬁers are rel-

evant only in forward direction. The ﬁlter modiﬁer

on the source element member (line 13) has to ensure

that only mothers and daughters are considered by the

rule. The creation modiﬁer (line 14) has to handle a

special case that may occur due to a move operation

in the families model: A father or son may be reas-

signed to one of the references daugthers or mother

within a family. As a consequence, a male person has

to be deleted, and a female person has to be created.

To avoid loss of information, the birthday has to be

Combining a Declarative Language and an Imperative Language for Bidirectional Incremental Model Transformations

1 sourcemodel " platf o rm :/ pl ugi n / F amil i es / mo d el / Fa m ilie s . eco r e "

2 targetmodel " platf o rm :/ pl ugi n / P ers o n s / mo d el / Pe r son s . eco r e "

4 options

5 PREFER_ C R E A T I N G _ P ARENT_T O _ C H I L D

6 PREFER _ E X I S T I N G _ FAMILY_ T O _ N E W

8 rule Re g i s t e r2Reg i s t e r

9 src F a m i l yReg i s t e r s ;

10 trg P e r s o nReg i s t e r t ;

12 rule Me m b e r2Fe m a l e

13 src F a m i lyMe m b e r me mber | filter;

14 trg F emal e fe male | creation;

15 me m ber . nam e me mber . m o t h erIn v e r se me mbe r . d a u g hters I n v e rse -- > f ema le . na me ;

16 me m ber . d a u g h tersI n v e r s e me mbe r . m o t herIn v e r se -- > f ema l e . p erso n s I n verse ;

17 me m ber . nam e <- - f ema l e .na me memb e r ;

19 rule Me m b er2M a l e

20 src F a m i lyMe m b e r me mber | filter;

21 trg M al e male | creation;

22 me m ber . nam e me mber . f a t h erIn v e r se me mbe r . s o nsIn v e r se -- > mal e . na me ;

23 me m ber . s o n sInv e r s e me mber . f a t h erIn v e r se -- > mal e . p erso n s I n vers e ;

24 me m ber . nam e <- - mal e .na me memb e r ;

Listing 1: Transformation of Families to Persons.

copied from the male person to be deleted to the fe-

male person to be created (the gender has changed,

but the person still is the same).

Furthermore, the rule Member2Female includes

three mappings (lines 15–17). All of these mappings

are directed, either in forward direction (−− >) or in

backward direction (< −−). Mappings are handled in

a similar way as ﬁlters: A mapping deﬁnes the inputs

and outputs of some calculation; the actual calcula-

tion is programmed at the imperative layer.

The mapping in line 15 is required in forward di-

rection for the calculation of the name of the female

person, based on the name of the member and the

name of the family to which the member belongs.

The family name is not supplied directly as a sec-

ond parameter (this would require a more general ex-

pression syntax in BXtendDSL). Rather, the family

is determined by navigating along an inverse refer-

ence (motherInverse or daughtersInverse). In a simi-

lar way, the mapping in line 16 is used to connect the

female person to the person register.

Finally, the mapping in line 17 is required in back-

ward direction to calculate the member’s name. In

addition, this mapping is used for the management of

families. The implementation of the mapping at the

imperative layer has to provide a policy for inserting

the member into a new or existing family as a parent

or a child. For this purpose, member is required as a

second argument.

The rule Member2Male works analogously to

Member2Female.

4.2.2 Imperative Layer(BXtend)

At the imperative layer, we have to provide imple-

mentations of ﬁlters and modiﬁers deﬁned at the

declarative layer. These implementations are located

at the bottom layer of the generation gap architecture

displayed in Figure 2. The transformation developer

implements bodies of hook methods which are called

by the framework code. At the imperative layer, we

exploit the expressiveness of imperative languages to

exactly implement the required behavior of the bidi-

rectional transformations.

Listing 2 displays the code for implementing the

modiﬁers deﬁned in lines 13–14 of Listing 1. The

ﬁlter modiﬁer is implemented in lines 2–7. The rule

Member2Female may be applied only if the mem-

ber is a daughter or a mother (line 6). In addition,

the method ﬁlterMember contains management code

which is required for handling the special case of

switching the member’s gender from male to female

in response to a move operation. In this case, the rule

Member2Female has to be applied to generate a new

Female object; afterwards, the old Male object will be

deleted. To save the male’s birthday, a map from fam-

ily members to dates is maintained which is declared

in line 1. In lines 3–5, the map is extended with the

birthday of the still existing male person.

The creation modiﬁer (line 14 of Listing 1) is im-

plemented by the method onFemaleCreation (lines 8–

12 of Listing 2). If the member corresponding to the

new female object has an entry in the birthdays map,

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

1 Map < Fa mil y Mem b er , D ate > b i rth d a ys = ne wHas h M ap ()

2 override protected filt e r M embe r ( F a m i lyMem b e r me m ber ) {

3 if ( m embe r . hasC o rr ) {

4 bir t h days . put ( me mber , ( u n wra p ( m emb er . co rr . ta rge t . ge t (0) ) as P e rso n ). bir t h day )

5 }

6 return m embe r . d a ughte r s I n v erse ! == null || me m ber . m o t h erInv e r s e !== null

7 }

8 override protected onFem a l e C reati o n ( F e mal e fe m ale ) {

9 if ( b i r thd a y s . c onta i n s Key ( fe m ale . c or r . sou r ce () . m emb er ) ) {

10 fem ale . bi r thda y = bi r thda y s . ge t ( fe m ale . c orr . s our ce () . me mbe r )

11 }

12 }

Listing 2: Code for implementing modiﬁers.

its value is retrieved from the map and used to assign

the birthday attribute of the object female.

Mappings are translated into methods which cal-

culate the requested outputs. Listing 3 shows the

methods implementing the mappings deﬁned in lines

16–17 of Listing 1. The method femNameFrom com-

poses the name of the female person from the family’s

name and the member’s name, as described at the end

of Section 4.1. The respective string is not returned

directly; rather, it is wrapped into an instance of some

generated type which in general may aggregate mul-

tiple outputs (which are allowed in the deﬁnition of

mappings).

Similarly, the method personsInverseFrom (lines

5–8) returns the target of the reference personsInverse

connecting the Female object to the PersonRegister

object. The target is retrieved by navigating from the

family to the family register and then using the corre-

spondence for the rule Register2Register to navigate

from the source to the target.

Finally, the mapping deﬁned in line 19 of Listing

1 is implemented by the method shown in Listing 4.

The name of the female person is split into the fam-

ily name and the member name (lines 2–3), the latter

of which is returned as the result of the method (line

25). The remaining code manages families, according

to the policy determined by the options introduced in

lines 5–6 of Listing 1. Any further action is required

only if the member has not been inserted yet into a

family or the family name of the person differs from

the current family name in the families model (line

5). If an existing family is preferred, it is attempted to

retrieve a family with the given family name, giving

priority to families without a mother (lines 6–11). If

the attempt is successful, the retrieved family is used

throughout the rest of the method; otherwise, a new

family is created and inserted into the family register

(lines 12–15). If a child is preferred or the selected

family has a mother who is different from the member

to be inserted, the member is inserted as a daughter;

otherwise, the member is inserted as a mother (lines

17–22).

An analogous implementation is supplied for the

corresponding ﬁlters and mappings for male persons,

which are not shown here due to space restrictions.

5 EMPIRICAL RESULTS

The declarative language presented in this paper was

evaluated with several transformation scenarios, e.g.

the transformation problems discussed in (Westfech-

tel, 2019). Due to space restrictions we decided

to give detailed insight into the Families-to-Persons

transformation problem (Anjorin et al., 2017), which

was evaluated with several bx approaches in (Anjorin

et al., 2020). In (Anjorin et al., 2020), the BXtend so-

lution for the Families to Persons case is discussed, al-

lowing for an easy comparison with the BXtendDSL

solution presented in this paper. However, the results

of this case apply also to the other transformation sce-

narios studied in (Bank, 2019).

5.1 Quantitative Analysis

While BXtend already allows for concise transfor-

mation deﬁnitions (Anjorin et al., 2020; Bank et al.,

2020), one of the goals of the work presented in this

paper was to further minimize the speciﬁcation effort.

As our solution supports a textual concrete syntax, a

quantitative impression of the size of the transforma-

tion deﬁnitions can be obtained by counting the num-

ber of lines of code (excluding empty lines and com-

ments), the number of words (character strings sepa-

rated by whitespace) in these lines, and the number of

characters in these words. Empty lines, comments as

well as generated code lines are omitted. Table 1 de-

picts the values obtained for those metrics for BXtend

and BXtendDSL. For both solutions, only those lines

were counted which had to be written manually. In the

case of BXtendDSL, both the code in the DSL itself

and the supplementary BXtend code was counted.

Combining a Declarative Language and an Imperative Language for Bidirectional Incremental Model Transformations

1 override protected fem N a m eFro m ( S t rin g memN am e , Fam i ly moth e rIn v ers e , F amil y dau g h t e r sInve r s e ) {

2 new T y p e 4fem N a m e (( mot h e r I nver s e ?: da u g hters I n v e r se ). name + " , " mem N ame )

3 }

5 override protected perso n s I n v e rseFr o m ( F a mil y da u g hte r s Inv e r se , Fam ily mo t herI n v e rse ) {

6 new T y p e 4 p e rsons I n v e r s e

7 ( Re g i ster2 R e g i s ter . ta r get (( d a u g hters I n v e rse ? : mo therI n v e rse ) . famil i e s I nvers e . c orr ). t )

8 }

Listing 3: Code for determining properties of females.

1 override protected mem N a m eFro m ( F a m i lyMe m b e r member , Str i ng femN a me ) {

2 val f a m ilyN a m e = fe mNa m e . spl it (" , ") . g et ( 0)

3 val m e m berN a m e = fe mNa m e . spl it (" , ") . g et ( 1)

5 if ( m embe r . e Cont a i ner = == null || ( me m ber . e C o n tain e r as Fami ly ) . na me != fam i l yNam e ) {

6 val p r e f e rExi s t i n g = traf o . g etO p t ion ( Fami l i e s 2Pers o n s . O P T _ P R E F E R _ E XISTING _ F A M I L Y _ T O _ NEW )

7 val f a mili e s = sr cRo o t . fami l ies

8 var f amil y = if ( pr e f e rExis t i n g == tr ue ) {

9 fam i lies .findFirst[ nam e == fam i l yNam e && moth e r === null] ? :

10 fam i lies .findFirst[ nam e == fam i l yNam e ]

11 }

12 fam ily = f ami l y ? : Fa m i lies F a c t ory . eIN S T ANCE . cr e ateF a m i ly () = > [

13 na me = f a mily N a me

14 famil i e s I nvers e = sr c R oot

15 ]

17 val p r e f erPa r e n t = traf o . g etO p t ion ( Fami l i e s 2Pers o n s . O P T _ P R E F E R _ C R EATING_P A R E N T _ T O _ C H ILD )

18 if ( p r e f erPa r e n t == fa lse || ( fami l y . mot h er ! == null && fa m ily . m oth e r !== mem ber ) ) {

19 f a mil y . d a ugh t e rs + = m e mbe r

20 } else {

21 f a mil y . m oth e r = m e mbe r

22 }

23 }

25 new T y p e 4mem N a m e ( m embe r N ame )

26 }

Listing 4: Code for calculating member names and managing families.

Table 1: Size of the transformation deﬁnitions of both solu-

tions.

BXtendDSL BXtend

Lines of code 89 211

Number of words 276 565

Number of characters 3030 7571

The transformation deﬁnition was written by the

same developer in both tools which are subject to this

comparison. The same layout conventions and pro-

gramming practices have been applied. Consequently,

those numbers give a good indication that the goal of

reducing the size of the transformation deﬁnition was

reached. In fact, they yield a signiﬁcant reduction in

terms of this LOC metrics.

5.2 Qualitative Analysis

In order to perform a qualitative analysis, test cases

for the different transformation directions have been

speciﬁed and executed for both batch and incremen-

tal mode of operation. We assume a test case to be

passed, if the resulting model matches a predeﬁned

expected model state. The BXtend solution is able

to pass all tests speciﬁed in (Anjorin et al., 2020).

The same holds for the BXtendDSL solution. Ta-

ble 2 gives an overview of the tests and the obtained

results following the criteria used in (Anjorin et al.,

2020). Please note that two unexpected passes are due

to cases that test for order-dependent update behavior

(which state-based tools cannot provide).

The qualitative analysis shows that the correct-

ness of the transformation is not affected by intro-

ducing the additional DSL layer. Moreover, with

respect to functional requirements both BXtend and

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

Table 2: Aggregate test results, grouped into categories and

classiﬁed as expected/unexpected passes/fails.

Category Result BXtendDSL BXtend

expected pass 7 7

Batch expected fail 0 0

FWD unexpected pass 0 0

unexpected fail 0 0

expected pass 11 11

Batch expected fail 0 0

BWD unexpected pass 0 0

unexpected fail 0 0

expected pass 8 8

Incr. expected fail 0 0

FWD unexpected pass 0 0

unexpected fail 0 0

expected pass 7 7

Incr. expected fail 0 0

BWD unexpected pass 1 1

unexpected fail 0 0

Total

expected pass 33 33

expected fail 0 0

unexpected pass 1 1

unexpected fail 0 0

BXtendDSL achieve a perfect result: Both solutions

pass all test cases. None of the other solutions com-

pared in (Anjorin et al., 2020) exhibit a pass rate of

100 %.

5.3 Performance Analysis

In order to evaluate the efﬁciency and scalability of

the resulting transformation with respect to increasing

model size, two experiments were conducted in both

forward and backward directions for each of the trans-

formation problems resulting in four sets of measure-

ments: (1) batch transformations in forward and back-

ward directions, and (2) incremental transformations

in forward and backward directions. The batch trans-

formations test how the solutions scale when creat-

ing corresponding opposite models of increasing size

(model size up to 1.000.000 elements). For incre-

mental transformations, the time required to locate

and propagate corresponding changes to the depen-

dent model is measured.

The tests were performed on the same machine

and in isolation for each solution and each transfor-

mation problem. A desktop PC with an AMD Ryzen

7 3700x CPU was used, running at a standard clock of

3.60 GHz, with 32 GB of DDR4 RAM and with Mi-

crosoft Windows 10 64-bit as operating system. We

used Java 13.0.2, Eclipse 4.11.0, and EMF version

2.17.0 to compile and execute the Java code for the

scalability test suite. Each test was repeated 5 times

and the median measured time was computed.

The four measurement results are depicted in Fig.

5, 6, 7, and 8. The ﬁgure for the batch backward

measurement is composed of two plots – a plot with

linear/linear scale to the left, and a plot with log/log

scale to the right. While the linear plot provides a re-

alistic impression for the actual complexity of each

solution, the logarithmic one zooms into ﬁner details

for smaller models and zooms out for larger models,

allowing to qualitatively present large differences in

runtime. Since we observed a signiﬁcant difference in

runtime for the batch backward solution, we decided

to supply those two plots.

In three out of four measurements, the BX-

tendDSL solution is slower than the stand-alone BX-

tend solution (as expected, due to the additional layer

of abstraction). However, in all measurements the

BXtendDSL solution roughly exhibits linear perfor-

mance, proving its scalability. Thus, the gap between

BXtend and BXtendDSL is still in a reasonable range,

and even the BXtendDSL solution outperforms many

of the bx approaches compared in (Anjorin et al.,

2020).

The reason why the BXtendDSL solution is so

much faster in the batch backward case is that in the

BXtend solution, retrieving matching families is ex-

pensive and results in a sharp increase of runtime. In

our original implementation we used an Xtend switch

statement to switch over the family size, which re-

sults in Java code which iterates over the same col-

lection several times using non-standard Java collec-

tion classes. Increasing model sizes lead to a signiﬁ-

cant decrease in performance in this case. In the BX-

tendDSL solution we did not use Xtend switch state-

ments, and only a single iteration over the families

collection was neccessary, resulting in an almost lin-

ear runtime. For the sake of comparability and trace-

ability, we did not modify the original BXtend solu-

tion, since it was the solution submitted for the TTC

2017 (Anjorin et al., 2017) and also the one that was

discussed in (Anjorin et al., 2020).

5.4 Summary

As expected, the use of BXtendDSL reduces the over-

all size of the transformation deﬁnition considerably.

This is due to the fact that parts of the transformation

may be speciﬁed in a declarative way, without being

forced to write separate forward and backward trans-

formations. Functional correctness is not affected

negatively; the full expressiveness of plain BXtend

is retained due to the combination of declarative and

imperative code. Finally, the BXtendDSL solution

proves scalable since it roughly exhibits linear per-

formance. Compared to plain BXtend, it degrades

performance to an acceptable degree, due to the ad-

ditional layer of abstraction.

Combining a Declarative Language and an Imperative Language for Bidirectional Incremental Model Transformations

# model elements

time in s

0.0

0.5

1.0

1.5

2.0

200000 400000 600000 800000 1000000

BXtend BXtendDSL

BXtend and BXtendDSL

Figure 5: Forward batch transformation: Linear/linear scale.

# model elements

time in s

0.0

0.5

1.0

1.5

200000 400000 600000 800000 1000000

BXtend BXtendDSL

BXtend and BXtendDSL

Figure 6: Forward incremental transformation: Linear/linear scale.

# model elements

time in s

100

200

300

400

500

200000 400000 600000 800000 1000000

BXtend BXtendDSL

BXtend and BXtendDSL

# model elements

time in s

0.1

100

5000 10000 50000 100000 500000

BXtend BXtendDSL

BXtend and BXtendDSL

Figure 7: Backward batch transformation: Linear/linear scale (left) and log/log scale (right).

# model elements

time in s

0.00

0.25

0.50

0.75

1.00

1.25

200000 400000 600000 800000 1000000

BXtend BXtendDSL

BXtend and BXtendDSL

Figure 8: Backward incremental transformation: Linear/linear scale.

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

6 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, imperative approaches like BX-

tend are more powerful.

6.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 var-

ious tools, such as, e.g. eMoﬂon (Anjorin et al., 2012)

or TGG Interpreter (Kindler and Wagner, 2007), just

to name a few. The basic idea behind TGGs is to inter-

pret both source and target models as graphs and ad-

ditionally have a correspondence graph, whose nodes

reference corresponding elements from both source

and target graphs, respectively. The resulting model

transformation language is highly declarative, as the

construction of triple graphs is described with a set

of production rules, which are used to describe the

simultaneous extension of the involved domains of

the triple graph. Please note that within the rules, no

information about a transformation direction is con-

tained. The corresponding rules for forward and back-

ward transformation may be derived automatically by

the TGG engine. Trace information is stored in the

correspondence graph, which is exploited for incre-

mental change propagation. From the viewpoint of

the transformation designer, incrementality and bidi-

rectionality come for free and need not be speciﬁed

explicitly in the transformation deﬁnition, as well as

modiﬁcations and deletions, which are also handled

automatically by the TGG engine.

6.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 rela-

tion but all details how to restore this consistency re-

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

guage following this principle. Unfortunately, there

are only very few tools which are based on this stan-

dard. QVT-R allows for 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 models respectively. This speciﬁ-

cation may be executed in different directions (for-

ward and backward) and in different modes (check-

only and enforcement). Furthermore, QVT-R allows

to propagate updates from the source model to the

target model in subsequent transformation executions

(incremental behavior). JTL (Cicchetti et al., 2010)

is also a constraint-based approach, which provides

guarantees of round-trip laws when executing a trans-

formation speciﬁcation. It is speciﬁcally tailored to

support bidirectionality and non-determinism. When

using JTL, the transformation developer supplies a

set of constraints specifying a consistency relation.

Those constraints are transformed together with the

involved metamodels to an Answer Set Programming

(ASP) (Gelfond and Lifschitz, 1988) problem, which

an ASP solver can use to enable consistency restora-

tion. However, since constraint solving is an NP-hard

problem, JTL may only be applied to very small mod-

els and it does not scale with increasing model sizes.

6.3 FP-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 func-

tion (backward or forward). In this way, a pair of

functions is provided which adheres to round tripping

laws. These approaches origin from the BX com-

munity and are based on lenses (Foster et al., 2007),

which are used to specify view/update problems. A

different terminology is used for forward and back-

ward directions: the forward direction is referred to

as get, while the backward direction is called put. The

round trip idea can be realised either by using get to

infer put, or vice versa. In all cases, the underlying

consistency relation is not speciﬁed explicitly. One

representative of this approach is BiGUL (Ko et al.,

2016).

Combining a Declarative Language and an Imperative Language for Bidirectional Incremental Model Transformations

6.4 Our Approach

The main differences of our approach compared to

the approaches discussed above, is that BXtendDSL

builds upon BXtend – a framework which is im-

plemented in the imperative programming language

Xtend. A switch of paradigms is possible whenever

needed. The transformation developer may work on

the declarative layer as long as possible and then

switch to imperative constructs on demand. The gen-

eration gap pattern allows for a seamless integration

of BXtend code generated from the BXtendDSL spec-

iﬁcation and hand-written imperative extensions to

certain parts of the transformation rules. This ap-

proach allows for much greater ﬂexibility in transfor-

mation deﬁnitions compared with traditional bx ap-

proaches. Furthermore, our BXtend environment is

easy to use for Java developers, as the Xtend pro-

gramming language directly builds upon Java and just

makes it less verbose. Thus, the transformation de-

veloper does not need to learn a new programming

language. Finally, the resulting M2M transformation

may be integrated seamlessly with any other Java ap-

plication without requiring additional dependencies,

which makes it particularly interesting for tool inte-

grators.

7 CONCLUSION

In this paper we presented BXtendDSL – a program-

ming language, speciﬁcally designed for bidirectional

and incremental model transformation – which adds

a declarative layer for specifying relations between

model elements on top of the BXtend framework. We

were able to signiﬁcantly reduce the coding effort for

the transformation developer, preserving all beneﬁts

from the BXtend framework at the same time by ap-

plying the generation gap pattern to our solution. A

thorough evaluation proved the feasibility of our ap-

proach. Due to space restrictions, we limit ourselves

to results from a popular benchmark – Families-to-

Persons – in this paper. A detailed comparison with

BXtend is performed in terms of quality (passed test

cases), quantity (coding effort measured in LOC met-

rics) and performance (scalability tests). Following

the Benchmarx approach, the results obtained are

comparable with dedicated bx languages discussed in

(Anjorin et al., 2020).

What makes our work unique is the layered ap-

proach to the speciﬁcation of bidirectional incremen-

tal transformations. Quite a number of DSLs for bx

have been developed. While they allow to specify bx

on a high level of abstraction, they trade guarantees

of bx laws for expressiveness. This is a severe prob-

lem in practice: If you cannot provide a solution in a

DSL for bx which passes all test cases, you have to

go for another language. In contrast, BXtendDSL is

a small and lightweight DSL which allows to spec-

ify parts of the transformation declaratively. To ob-

tain a complete solution, code is generated on top of

the BXtend framework, and those problems not ad-

dressed at the declarative layer may be solved at the

imperative layer. Thus, BXtendDSL in combination

with BXtend provides for a pragmatic bx approach

which is optimized towards conciseness, expressive-

ness, and scalability. Therefore, we consider this a

practical contribution which facilitates the develop-

ment of bidirectional incremental model transforma-

tions.

REFERENCES

Anjorin, A., Buchmann, T., and Westfechtel, B. (2017). The

Families to Persons Case. In Garc

ıa-Dom

ınguez, A.,

Hinkel, G., and Krikava, F., editors, Proceedings of

the 10th Transformation Tool Contest (TTC 2017), co-

located with the 2017 Software Technologies: Appli-

cations and Foundations (STAF 2017), Marburg, Ger-

many, July 21, 2017, volume 2026 of CEUR Workshop

Proceedings, pages 27–34. CEUR-WS.org.

Anjorin, A., Buchmann, T., Westfechtel, B., Diskin, Z.,

Ko, H., Eramo, R., Hinkel, G., Samimi-Dehkordi,

L., and Z

undorf, A. (2020). Benchmarking bidirec-

tional transformations: theory, implementation, appli-

cation, and assessment. Software and Systems Model-

ing, 19(3):647–691.

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-

dations and Applications (ECMFA 2012), page 348,

Copenhagen, Denmark. Technical University of Den-

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

Bank, M. (2019). Entwicklung einer deklarativen Sprache fr

bidirektionale Modell-zu-Modell Transformationen.

Master thesis (in German), University of Bayreuth,

Germany.

Bank, M., Kaske, S., Buchmann, T., and Westfechtel, B.

(2020). Incremental bidirectional transformations:

Evaluating declarative and imperative approaches us-

ing the ast2dag benchmark. In Ali, R., Kaindl, H.,

and Maciaszek, L. A., editors, Proceedings of the

15th International Conference on Evaluation of Novel

Approaches to Software Engineering, ENASE 2020,

Prague, Czech Republic, May 5-6, 2020, pages 249–

260. SCITEPRESS.

Buchmann, T. (2018). Bxtend - A framework for (bidi-

rectional) incremental model transformations. In

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

Hammoudi, S., Pires, L. F., and Selic, B., edi-

tors, Proceedings of the 6th International Confer-

ence on Model-Driven Engineering and Software De-

velopment, MODELSWARD 2018, Funchal, Madeira

- Portugal, January 22-24, 2018., pages 336–345.

SciTePress.

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 Verlag.

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

mental Round-Trip Engineering Using Model Trans-

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

tors, Proceedings of the 39th Euromicro Conference

on Software Engineering and Advanced Applications

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

lishing Service.

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

graph grammars to realize incremental round-trip en-

gineering. IET Software, 10(6):173–181.

Cicchetti, A., Di Ruscio, D., Eramo, R., and Pierantonio, A.

(2010). JTL: A bidirectional and change propagating

transformation language. In Malloy, B., Staab, S., and

van den Brand, M., editors, Proceedings of the Third

International Conference on Software Language En-

gineering (SLE 2010), volume 6563 of Lecture Notes

in Computer Science, pages 183–202, Eindhoven, The

Netherlands. Springer-Verlag.

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

vey of model transformation approaches. IBM Sys-

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

Foster, J. N., Greenwald, M. B., Moore, J. T., Pierce, B. C.,

and Schmitt, A. (2007). Combinators for bidirec-

tional tree transformations: A linguistic approach to

the view-update problem. ACM Transactions on Pro-

gramming Languages and Systems, 29(3):17:1–17:65.

Fowler, M. (2011). Domain-Speciﬁc Languages. The

Addison-Wesley signature series. Addison-Wesley.

Gelfond, M. and Lifschitz, V. (1988). The stable model se-

mantics for logic programming. In Kowalski, R. A.

and Bowen, K. A., editors, Logic Programming, Pro-

ceedings of the Fifth International Conference and

Symposium, Seattle, Washington, USA, August 15-19,

1988 (2 Volumes), pages 1070–1080. MIT Press.

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

Bidirectional transformations with QVT-R: A case

study in round-trip engineering UML class models

and java source code. In Hammoudi, S., Pires, L. F.,

Selic, B., and Desfray, P., editors, MODELSWARD

2016 - Proceedings of the 4rd International Confer-

ence on Model-Driven Engineering and Software De-

velopment, Rome, Italy, 19-21 February, 2016, pages

15–27. SciTePress.

Hidaka, S., Tisi, M., Cabot, J., and Hu, Z. (2016).

Feature-based classiﬁcation of bidirectional transfor-

mation approaches. Software and Systems Modeling,

15(3):907–928.

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.

Ko, H., Zan, T., and Hu, Z. (2016). BiGUL: a formally

veriﬁed core language for putback-based bidirectional

programming. In Proceedings of the 2016 ACM SIG-

PLAN Workshop on Partial Evaluation and Program

Manipulation, PEPM 2016, St. Petersburg, FL, USA,

January 20 - 22, 2016, pages 61–72.

Mellor, S. J., Scott, K., Uhl, A., and Weise, D. (2002).

Model-driven architecture. In Bruel, J. and Bellah-

sene, Z., editors, Advances in Object-Oriented In-

formation Systems, OOIS 2002 Workshops, Montpel-

lier, France, September 2, 2002, Proceedings, volume

2426 of Lecture Notes in Computer Science, pages

290–297. Springer.

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

Query/View/Transformation Speciﬁcation. Needham,

MA, formal/2015-02-01 edition.

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.

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. (2019). Case-based exploration of bidirec-

tional transformations in QVT relations. Software and

Systems Modeling, 17(3):989–1019.

Westfechtel, B. and Buchmann, T. (2019). Incremental

bidirectional transformations: Comparing declarative

and procedural approaches using the families to per-

sons benchmark. In Damiani, E., Spanoudakis, G.,

and Maciaszek, L. A., editors, Evaluation of Novel

Approaches to Software Engineering. ENASE 2018.,

Communications in Computer and Information Sci-

ence, pages 98–118. Springer.

Combining a Declarative Language and an Imperative Language for Bidirectional Incremental Model Transformations