Dedicated Model Transformation Languages vs. General-purpose

Languages: A Historical Perspective on ATL vs. Java

Stefan G

otz

1 a

, Matthias Tichy

1 b

and Timo Kehrer

2 c

Institute of Software Engineering and Programming languages, Ulm University, James-Franck Ring, Ulm, Germany

Department of Computer Science, Humboldt - University of Berlin, Berlin, Germany

Keywords:

Model Transformation Languages, ATL, Java, Complexity.

Abstract:

Model transformations are among the key concepts of model-driven engineering (MDE), and dedicated model

transformation languages (MTLs) emerged with the popularity of the MDE paradigm about 15 to 20 years

ago. MTLs claim to increase the ease of development of model transformations by abstracting from recur-

ring transformation aspects and hiding complex semantics behind a simple yet intuitive syntax. Nonetheless,

MTLs are rarely adopted in practice, there is still no empirical evidence for this claim, and the argument of

abstraction deserves a fresh look in the light of modern general-purpose languages (GPLs) which have un-

dergone a signiﬁcant evolution in the last two decades. In this paper, we report about a study in which we

compare the complexity of model transformations written in three different languages, namely (i) the Atlas

Transformation Language (ATL), (ii) Java SE5, and (iii) Java SE14; the Java transformations are derived from

an ATL speciﬁcation using a translation schema we developed in terms of our study. In a nutshell, we found

that some of the new features in Java SE14 compared to Java SE5 help to signiﬁcantly reduce the complexity

of transformations written in Java. At the same time, however, the relative amount of complexity that stems

from aspects that ATL can hide from the developer stays about the same. Based on these results, we indicate

potential avenues for future research on the comparison of MTLs and GPLs in a model transformation context.

1 INTRODUCTION

Model transformations are among the key con-

cepts of the model-driven engineering (MDE)

paradigm (Sendall and Kozaczynski, 2003). They

are a particular kind of software which needs to be

developed along with an MDE tool chain or de-

velopment environment. With the aim of support-

ing the development of model transformations, ded-

icated model transformation languages (MTLs) have

been proposed and implemented shortly after the

MDE paradigm gained a foothold in software engi-

neering. In the literature, many advantages are as-

cribed to model transformation languages, such as

better analysability, comprehensibility or expressive-

ness (G

otz et al., 2020). Moreover, model transfor-

mation languages aim at abstracting from certain re-

curring aspects of a model transformation, claiming

to hide complex semantics behind a simple yet in-

https://orcid.org/0000-0001-7028-131X

https://orcid.org/0000-0002-9067-3748

https://orcid.org/0000-0002-2582-5557

tuitive syntax (Jouault et al., 2008; Krikava et al.,

2014; Sendall and Kozaczynski, 2003; Gray and Kar-

sai, 2003).

Nowadays, however, such claims have two main

ﬂaws. First, as discussed by G

otz et al., there is a lack

of actual evidence to have conﬁdence in their gen-

uineness (G

otz et al., 2020). Second, we argue that

most of these claims emerged together with the ﬁrst

MTLs around 15 years ago. The Atlas Transforma-

tion Language (ATL) (Jouault et al., 2006), for exam-

ple, was ﬁrst introduced in 2006, at a time when third

generation general-purpose languages (GPLs) were

still in their infancy. Arguably, these ﬂaws are under-

pinned by the observation that MTLs have been rarely

adopted in practical MDE (Burgueno et al., 2019).

Within our research group as well as in conver-

sations with other researchers, the presumption that

transformations can just as well be written in a GPL

such as Java has been discussed frequently. In fact,

in our own research, we have implemented various

model transformations using a GPL; examples of this

include the meta-tooling facilities of established re-

search tools like SiLift (Kehrer et al., 2012) and

122

Götz, S., Tichy, M. and Kehrer, T.

Dedicated Model Transformation Languages vs. General-purpose Languages: A Historical Perspective on ATL vs. Java.

DOI: 10.5220/0010340801220135

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

ISBN: 978-989-758-487-9

SERGe (Kehrer et al., 2016; Rindt et al., 2014), or the

implementation of model refactorings and model mu-

tations in experimental setups of more recent empir-

ical evaluations (Schultheiß et al., 2020a; Schultheiß

et al., 2020b). The presumption that model transfor-

mations can just as well be written in a GPL has been

conﬁrmed by a community discussion on the future

of model transformation languages (Burgueno et al.,

2019), and, at least partially, by an empirical study

conducted by Hebig et al. (Hebig et al., 2018). Our

argumentation for specifying model transformations

using a modern GPL is mainly rooted in the idea that

new language features allow developers to heavily re-

duce the boilerplate code that MTLs claim to abstract

away from.

To validate and better understand this argumen-

tation, we elected to compare ATL, one of the most

widely known MTLs, with Java, a widespread GPL.

More speciﬁcally, we compare ATL with Java in its

current iteration (Java SE14) as well as at the level

of 2006 (Java SE5) when ATL was introduced

see how much transformation code written in Java

SE5 can be improved using newer language features

released in Java SE14, we also decided to compare

transformations written in these two versions. Based

on these goals, we devised three research questions to

focus our research on:

• RQ1: How much less complex can transforma-

tions be written in Java SE14 compared to Java

SE5?

• RQ2: How is the complexity of transformations

written in Java SE5 distributed over the different

aspects of the transformation process compared

to ATL?

• RQ3: How is the complexity of transformations

written in Java SE14 distributed over the different

aspects of the transformation process compared

to ATL?

To answer these research questions, we devised a

schema to translate 10 existing ATL transformations

taken from the ATL Zoo

into Java. For comparing

transformations speciﬁed in Java SE5 and SE 14, we

use a combination of two metrics for measuring size

and complexity, namely lines of code (LOC) and Mc-

Cabe’s cyclomatic complexity. Our comparison of

complexity distributions is based on these metrics,

and we incorporate the ﬁndings of G

otz et al. on

how complexity is distributed within ATL transforma-

tions (G

otz and Tichy, 2020). For better understand-

Interestingly, there was no signiﬁcant evolution of the

ATL language since its initial introduction in 2006 (Bur-

gueno et al., 2019).

https://www.eclipse.org/atl/atlTransformations

ing the differences revealed by our quantitative com-

parison, we conducted a qualitative analysis of corre-

sponding code fragments written in the three different

languages used in our study.

The remainder of this paper is structured as fol-

lows: First, Section 2 introduces the relevant aspects

of ATL as well as the relevant differences between

Java 5 and Java 14. In Section 3, we present our

methodology for translating, reviewing and analysing

the translated transformations. Afterwards, in Sec-

tion 4, we give an overview of how ATL transfor-

mations were translated into Java. The results of our

analysis and extensive comparison between the differ-

ent transformation approaches are then presented in

Section 5. Section 6 discusses potential threats to the

validity of our work, while related work is considered

in Section 7. Lastly, Section 8 concludes the paper

and presents potential avenues for future research.

2 BACKGROUND

In this section, we brieﬂy introduce the relevant back-

ground knowledge required for this paper. First, since

model transformations can only be speciﬁed precisely

based on some concrete model representation, we

introduce the structural representation of models in

MDE which is typically assumed by all mainstream

model transformation languages, including ATL. Af-

terwards, since our work builds on ATL as well as the

technological advancement of Java, it is necessary to

introduce the relevant background knowledge on ATL

and to present the important differences between Java

SE5 and Java SE14, respectively.

2.1 Models in MDE

In MDE, the conceptual model elements of a

modelling language are typically deﬁned by a

meta-model. The Eclipse Modeling Framework

(EMF) (Steinberg et al., 2008), a Java-based refer-

ence implementation of OMG’s Essential Meta Ob-

ject Facility (EMOF) (OMG, 2016), has evolved into

a de-facto standard technology to deﬁne meta-models

that prescribe the valid structures that instance mod-

els of the deﬁned modeling language may exhibit. It

follows an object-oriented approach in which model

elements and their structural relationships are repre-

sented by objects (EObjects) and references whose

types are deﬁned by classes (EClasses) and associa-

tions (EReferences), respectively. Local properties of

model elements are represented and deﬁned by object

attributes (EAttributes). A speciﬁc kind of references

are containments. In a valid EMF model, each ob-

Dedicated Model Transformation Languages vs. General-purpose Languages: A Historical Perspective on ATL vs. Java

123

 

1 module NAM E

2 create OUT 1 : Me t a M o delB , ...

3 [ from | re f i ning ] IN1 : M e t a M odelA , ...

5 [ uses LIBRARY ]*

6 [ R U L E D E F | HEL P E R D EF ]*

 

Listing 1: Structure of an ATL module.

ject must not have more than one container and cy-

cles of containments must not occur. Typically, an

EMF model has a dedicated root object that contains

all other objects of the model directly or transitively.

2.2 ATL

ATL distinguishes among three kinds of so-called

Units, being either a module, a library or a query.

Depending on the type of unit, they consist of rules,

helpers and attributes. For data types and expres-

sions, ATL uses the Object Constraint Language

(OCL) (OMG, 2014).

2.2.1 Units

As illustrated in Listing 1, transformations are deﬁned

in Modules, taking a set of input models (line 3) which

are transformed to a set of output models (line 2) by

rule and helper deﬁnitions which make up the trans-

formation (line 6).

Libraries: do not deﬁne transformations but only

consist of a set of helper deﬁnitions. Libraries can be

imported into modules to enhance their functionality

(line 5).

Queries: are special types of libraries, that are

used to deﬁne transformations from model elements

to simple OCL types. They are comprised of a query

element and a set of helper deﬁnitions.

2.2.2 Helpers and Attributes

Helpers allow outsourcing of expressions that can be

called from within rules, similar to simple functions

in general purpose languages. Helper deﬁnitions can

specify a so-called context which deﬁnes the data type

for which the helper is deﬁned as well as parameters

passed to the helper. ATL also allows the deﬁnition of

attribute helpers. Attribute helpers differ from helpers

in that they do not accept any parameter and always

require a context data type. They serve as constants

for the speciﬁed context. Listing 2 shows the syntax

to deﬁne helpers and attribute helpers.

 

1 helper [ context M O D E LTYP E ]? def :

NAME [( PARA M E T ERS ) ]? : TYPE =

EXPR ;

 

Listing 2: Syntax to deﬁne Helpers.

2.2.3 Rules

In ATL, transformations of input models into output

models are deﬁned using rules. There are two main

types of rules: matched rules and called rules.

Matched Rules: The declarative part of an ATL

transformation is comprised by matched rules which

are automatically executed on all matching input

model elements, thus allowing to deﬁne type-speciﬁc

transformations into output model elements. For this,

the ATL engine traverses the input model in an op-

timized order. Furthermore, matched rules generate

traceability links (trace links for short) between the

source and target elements. These links can be nav-

igated throughout the transformation speciﬁcation to

access references to elements created from a source

element. Matched rules are comprised of four sec-

tions (see Listing 3):

• The In-Pattern (lines 2 to 3) deﬁnes the type of

source model elements that are to be matched and

transformed. An optional ﬁlter expression allows

the deﬁnition of a condition that must be met for

the rule to be applied.

• An optional Using-Block (lines 4 to 6) allows to

deﬁne local variables based on the input element.

• The Out-Pattern (lines 7 to 10) then deﬁnes a

number of output model elements that are to be

created from the input element when the rule is

applied. Each output model element is deﬁned us-

ing a set of so-called bindings for assigning values

to attributes of the output model element.

• Lastly, an optional Action-Block (lines 11 to 13)

can be deﬁned which allows the speciﬁcation of

imperative code that is executed once the target

elements have been created.

Matched rules can also be deﬁned as lazy rules by

adding the keyword lazy to the rule deﬁnition (line

1). In contrast to regular matched rules, lazy rules

are only executed when explicitly called for a speciﬁc

model element that matches both the rule’s type and

its ﬁlter expression. They can be called multiple times

on the same model element to produce multiple dis-

tinct output elements. To change the behaviour of lazy

rules to always produce one and the same output el-

ement for the same source model element, lazy rules

can be declared as unique (line 1).

Called Rules: As opposed to matched rules,

called rules enable an explicit generation of target

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

124

 

1 [ lazy | u n i q u e lazy ]? r u le NAME {

2 from

3 INVAR : M ODEL A T YPE [( C O NDIT I O N ) ]*

4 [ u sing {

5 [ VAR : VARTY P E = EXP R ;]+

6 }]?

7 to

8 [ O U T V A R : MOD E L B TYP E {

9 [ ATR <- EXPR ,]+

10 } ,]+

11 [do {

12 [ S T A TEME N T ;]*

13 }]?

14 }

 

Listing 3: Syntax to deﬁne matched rules.

model elements in an imperative way. Called rules

can be called from within the imperative code deﬁned

in the Action-Block of rules. They are deﬁned sim-

ilarly to matched rules. The main difference is that

they do not contain an In-Pattern but instead allow the

deﬁnition of required parameters. These parameters

can then be used in the Out-Pattern and Action-Block

to produce output model elements.

2.2.4 Reﬁning Mode

The reﬁning mode is a special execution mode for

ATL modules which aims at supporting an easy def-

inition of in-place transformations (Czarnecki and

Helsen, 2006; Str

uber et al., 2017). Normally, the

ATL engine only creates new output model elements

from input model elements matched by the rules de-

ﬁned in a module. However, in the reﬁning mode, the

ATL engine instead executes all rules on matching in-

put elements and produces a copy of all unmatched

input elements automatically. This aims to allow de-

velopers to focus solely on local modiﬁcations such

as model refactorings rather than also having to man-

ually produce copies of all other model elements.

2.3 Technological Advancements in

Java14 Compared to Java5

Since the release of J2SE 5 in September of 2004,

there have been a lot of improvements made to the

Java language. In this section, however, we will only

cover the ones relevant in the context of this paper.

All the relevant features relate to a more functional

programming style as they allow developers to ex-

press some key aspects of a transformation speciﬁ-

cation more concisely.

 

1 F u nction < I nteger , Integ er >

doubl e I t = ( value ) - > v a l u e *

 

Listing 5: Lambda expression deﬁnition based on Function.

2.3.1 Functional Interfaces

With the introduction of the functional interfaces

in Java SE8, Java made an important step towards

embracing the functional programming paradigm,

paving the way to deﬁne lambda expressions in ar-

bitrary Java code. Lambda expressions, also called

anonymous functions, are functions that are deﬁned

without being bound to an identiﬁer. This allows de-

velopers to pass them as arguments.

In essence, a functional interface is an interface

containing only a single abstract method. This ab-

stract method can then be implemented by means of

a Java lambda expression (see Listing 5). One exam-

ple of this is the interface called Function<T,R> (see

Listing 4). It represents a function which takes a sin-

gle parameter and returns a value.

 

1 public inte r f a ce Func t ion <T ,R > {

2 public R ap p l y (T par ) ;

3 }

 

Listing 4: Deﬁnition of the Function interface.

Lambdas deﬁned with the interface Function<T,R>

as their type are then nothing more than objects with

their deﬁnition as the implementation of the apply

method wrapped in a more functional syntax (see

Listing 5).

Java provides a number of predeﬁned func-

tional interfaces, such as the aforementioned

Function<T,R>, or Consumer<T> which takes one

argument and has void as its return value.

2.3.2 Streams

Streams represent a sequence of elements and allow

a number of different operations to be performed on

the elements within the sequence. Stream operations

can either be intermediate or terminal. This means

that the operations can either produce another stream

as their result or a non-stream result which therefore

terminates the computation on the stream. This also

means that intermediate operations work with all ele-

ments within the stream without the developer having

to deﬁne a loop over it.

The example in Listing 6 shows how one can ﬁnd

and print all even numbers in a list using streams.

Dedicated Model Transformation Languages vs. General-purpose Languages: A Historical Perspective on ATL vs. Java

125

 

1 List < Stri ng > myList =

Arrays . asList (1 ,2 ,3 ,4 ,5 ,6) ;

2 myList . stream () . filter ( i -> i % 2

== 0) . forEach (

System . out :: prin t l n ) ;

 

Listing 6: Finding and printing all even numbers in a list.

Table 1: Meta-Data about the selected transformation mod-

ules.

Data minimum average maximum total

LOC 42 329 1125 13455

Rules 2 8 20 78

Helpers 0 9 74 82

3 METHODOLOGY

Our research methodology consists of three main sub-

sequent steps. First, we selected transformation mod-

ules to translate and analyse. Afterwards, we devel-

oped a translation schema for translating ATL trans-

formations into Java and translated the selected ones

into both Java SE5 and Java SE14. Lastly, we se-

lected and applied complexity measures on the Java

and ATL code. The results were then analysed and

compared in accordance with our research questions

from Section 1.

3.1 Module Selection

The selection of ATL modules was done with several

goals in mind. First we wanted to include transfor-

mations of different size and purpose. We also aimed

to include both transformations using ATLs reﬁning

mode and normal transformations. Lastly, due to the

fact that our translations would be done manually, we

decided to limit the total number of transformations

to 10 and the maximum size of a transformation to

around 1000 LOC.

Since our work is, in part, based on the work pre-

sented in (G

otz and Tichy, 2020) and their selection

criteria align with ours, we opted to make the selec-

tion of modules from the set of transformations anal-

ysed by them.

This selection process resulted in a total of 10 ATL

transformations

, each of which stems from the well-

known ATL Zoo. Basic meta-data about the transfor-

mations can be found in Table 1, while further details

can be found in the ATL Zoo.

A list with the names of the used transformations can

be found under https://spgit.informatik.uni-ulm.de/stefan.

goetz/javatransformationsv4/-/blob/master/resources/

toCompare

3.2 Translation Schema Development

and Application

To develop the translation schema, we followed

the design science research methodology (Wieringa,

2014). We used the ATL solution found in the

ATL Zoo for the families2persons case from the

TTC’17 (Anjorin et al., 2017) as our initial test input

for the translation scheme and focused on developing

the schema for Java SE14.

The development process followed a simple, itera-

tive pattern. A translation schema was developed and

applied to the families2persons case. The resulting

transformation was then reviewed, focusing on com-

pleteness and meaningfulness. Afterwards, the results

of the review were used as input for reiterating the

process.

In a ﬁnal evolution step, the preliminary transfor-

mation schema was applied to all 10 selected ATL

transformations. Afterwards, two researchers re-

viewed the resulting transformations separately based

on a predeﬁned code review protocol. In a joint meet-

ing, the results of the reviews were discussed and ﬁnal

adjustments to the transformation schema were de-

cided. These were then used to create a ﬁnal trans-

lation of all 10 ATL transformations.

Lastly we ported the developed transformations to

Java SE5 by forking the project, reducing the com-

piler compliance level and re-implementing the parts

that were not compatible with older compiler ver-

sions.

To validate the correctness of the translated trans-

formations, we used the input and output models

that were provided within the ATL transformation

projects. The input models were used as input for the

Java transformations and the output models were then

compared with the output of the transformations. If

no output models were provided in the projects, we

applied the ATL transformations to the input models

and compared the Java results with the results gener-

ated by ATL. If no input model and output model were

provided, we relied on the results of our code reviews.

This validation approach is similar to how (Sanchez

Cuadrado et al., 2020) validate their generated code.

3.3 Measure Selection and Analysis

Our analysis of the transformation speciﬁcations is

guided by the research questions introduced in Sec-

tion 1.

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

126

3.3.1 RQ1: How Much Less Complex Can

Transformations be Written in Java SE14

Compared to Java SE5?

To compare the transformations written in Java SE14

and Java SE5, we decided to use code metrics fo-

cused on code complexity and size. For this reason,

we chose McCabe’s cyclomatic complexity as well as

LOC which are shown to correlate with the complex-

ity and size of software (Jabangwe et al., 2015). To

keep the LOC count as fair as possible, we used the

same standard code formatter for all Java code.

We applied the Java code metrics calculator

(CK) (Aniche, 2015) on all 20 transformations to cal-

culate both metrics. CK calculates metrics on the

level of classes, methods, ﬁelds and variables. We

opted to use the values calculated on the level of

methods, i.e., the LOC and McCabe complexity of

the method bodies because neither the ﬁelds level nor

the variables level contained values for them and the

class level would be too coarse-grained for our analy-

sis. The metric values calculated by CK were then

analysed and compared based on maximum, mini-

mum, mean and average values.

3.3.2 RQ2,3: How Is the Complexity of

Transformations Written in Java SE5/14

Distributed over the Different Aspects of

the Transformation Process Compared to

ATL?

The approach for these research questions is twofold

and follows a top down methodology. First we com-

pare the distribution of complexity within the Java

code with regards to the different steps within the

transformation process. In particular, we want to see

how much effort needs to be put into writing those as-

pects that ATL can abstract away from. Afterwards,

we focus on the actual code. Here we compare how

code written in ATL compares to the Java code that

represents the same aspect within a transformation.

To be able to analyse the complexity distribution

in Java transformations, it is necessary to differentiate

the different steps within the Java code. We therefore

labelled each method in all transformations based on

which aspects within the transformation process they

represent. The relevant transformation aspects that

were explicitly present in our Java implementations

were:

• Model Traversal:, i.e., code that is associated

with traversing the input model and selecting

which ‘rules‘ to apply to which element.

• Element Creation and Tracing:, i.e., code in-

volved in creating output elements and trace links

 

1 r u le S i m ple B i nd i n g {

2 from s : M e m b e r

3 to t : Female (

4 n a me <- s . f irst N a m e

5 )

6 }

 

Listing 7: A rule with a simple binding.

 

1 r u le Trace {

2 from s : M e m b e r

3 to t : Ma le (

4 father <- s . f ami l y Fat h e r

5 )

6 }

 

Listing 8: A rule with a binding using traces.

between source and target model elements.

• Transformation:, i.e., code that uses given data

to populate the attributes of the output model ele-

ments.

• Helper:, i.e., code representing outsourced helper

facilities.

• Setup:, i.e., code required to read/write models

and to execute transformations on them.

We then used the metrics that were calculated for

RQ1 to create plots of the complexity distribution.

The resulting plots were then compared with the re-

sults presented in (G

otz and Tichy, 2020).

As for the code level comparison, we take a qual-

itative approach. We use a selection of three ATL

fragments representing code which is often written in

ATL transformations. The ﬁrst fragment (see List-

ing 7) represents code that copies the value of an

input attribute to an attribute of the resulting out-

put model element, an action which constitutes 56%

of all bindings in the set analysed by (G

otz and

Tichy, 2020). The second fragment (see Listing 8)

represents code that requires ATL to use traceability

links, which (G

otz and Tichy, 2020) found to con-

stitute 15% of all bindings. Because the attribute

s.familyFather does not contain a primitive data

type but a reference to another element within the

source model, the contained value can not simply be

copied to the output element. Instead ATL needs to

follow the traceability link created for the referenced

input element to ﬁnd its corresponding output element

which can then be referenced in the model element

created from s. The last code fragment (see Listing 9)

is a helper deﬁnition of typical size and complexity.

We use those code fragments and compare them

with the Java code that they are translated to in order

to highlight differences between the languages.

Dedicated Model Transformation Languages vs. General-purpose Languages: A Historical Perspective on ATL vs. Java

127

 

1 helper context Class def :

ass o c iat i o ns :

Seque n c e ( Ass o c i ati o n ) =

Ass o c iat i o n . al l I nst a n ces () - >

select ( a s so | a s so . value = 1) ;

 

Listing 9: A typical helper in ATL.

4 TRANSLATION SCHEMA

Our translation schema allows us to translate any ATL

module into corresponding Java code. The only as-

sumption we make is that all the meta-models of in-

put and output models are explicitly available. The

reason for this is that we work with EMF models in

so-called static mode, which means that all model el-

ement types deﬁned by a meta-model are translated

into corresponding Java classes using the EMF built-

in code generator.

As for the actual transformation, an ATL module

is represented by a Java class which contains a single

point of entry method that takes the root element of

the input model as its input and returns an object of

the root element of the output model. Additionally,

some setup code is needed for extracting a model and

its root element from a given source ﬁle, calling the

entry point of the actual transformation class, and se-

rializing the resulting output model.

Because traceability links need to be created be-

fore they can be used, we split the transformation

process into two separate runs. The ﬁrst run creates

all target elements as well as all traceability links be-

tween them and their source elements, while the sec-

ond run can safely traverse over model references and

populate the created elements by utilizing the trace-

ability links when needed. Consequently, the cor-

responding Java transformation class comprises two

separate methods, dedicated to each run and being

called by the entry point method. Listings 10 and 11

show an example of this translation.

For both model traversal as well as trace genera-

tion and resolving, we were able to develop generic

libraries which can be reused across all transforma-

tion classes. The remainder of this section will ﬁrst

describe these two libraries in more detail, before we

explain how the different types of rules and helpers of

an ATL module are translated into the corresponding

Java transformation class.

4.1 Traversal Library

The traversal library allows us to outsource the traver-

sal of the source model and thus reduce the amount of

boilerplate code written for each translated transfor-

 

1 module Example

2 create OUT : MetaMo d e l B from IN :

Met a M o delA

3 ...

 

Listing 10: Example ATL transformation.

 

1 public class MM A2MMB {

2 public B transfo r m ( A ro ot ) {

3 pr e T ran s f orm ( root ) ;

4 return ac t u al T r an s f or m ( r oot ) ;

5 }

6 priv a t e void preT r a nsf o r m ( A

root ) {.. . }

7 priv a t e void act u a lT r a ns f o rm (A

root ) {.. . }

8 }

 

Listing 11: Example translated Class.

mation. The traversal library builds upon a HashMap

that maps a Class<T> to a Consumer<EObject>. The

Consumer<EObject> interface represents a function

that takes an input of type EObject and has a return

type of void. During traversal, which is encapsulated

within the library, each EObject can be matched with

the key classes in the HashMap and the corresponding

Consumer function can be executed.

This way, we only have to write code adding the

required key-value-pairs to the traverser, while the

code for traversing the input model as well as resolv-

ing the correct method which is to be called can be

completely outsourced. Note that this is only neces-

sary for matched rules since lazy and called rules are

called within the transformation code and not auto-

matically executed based on element type matching.

Since this setup relies on functional interfaces to

work, it is only applicable in Java SE8 and greater.

Therefore, in our transformations written in Java SE5,

this whole process has to be reimplemented manually

for each transformation module.

4.2 Trace Library

The trace library emulates the management of trace-

ability links. Similar to the traversal library, the trace

library is built based on a HashMap. In this case, how-

ever, the HashMap maps source EObjects to target

EObjects and thus can be used both in Java SE5 and

Java SE14.

In essence, the trace library exposes two methods.

One for adding a trace, thus requiring the source and

target objects to be passed as parameters. And one for

resolving a trace based on a source object.

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

128

 

1 r u le A2 B {

2 from

3 a : A

4 to

5 b : B ( b i nding s ...)

6 }

 

Listing 12: Example ATL matched rule.

 

1 public class Example {

2 // ...

3 private void preTr a n sfo r m ( A

root ) {

4 // ...

5 p reT r a ver s e r . a dd ( A . class , a

-> A2BPre ( a) ) ;

6 }

7 private void actu a l Tr a n sf o r m ( A

root ) {

8 // ...

9 t r aver s e r . add ( A . class , a - >

A2B (a ) ) ;

10 }

12 private void A2 B P r e ( A a ) {

13 T R A C E R . a d d Trace (a , new B () ) ;

14 }

15 private void A2B ( A a ) {

16 B b = T R A C E R . r e s o lve ( a ) ;

17 // ... bin d i n g s cod e

18 }

19 }

 

Listing 13: Example translated Class.

4.3 Matched Rule Translation

Matched rules are translated into two methods within

the transformation class. One method is responsi-

ble for creating a target object and its corresponding

trace link, and one method is responsible for popu-

lating the created target object in accordance with the

bindings in its corresponding ATL rule. The second

method will also incorporate all code corresponding

to the imperative code written in the Action-Block of

the translated rule. As already indicated in the be-

ginning of this section when introducing our two-step

transformation process, the main idea behind this sep-

aration is that all traces and referenced objects can

be safely resolved within the second method (called

during the second traversal) because they are created

within the ﬁrst method (called during the ﬁrst traver-

sal). That is, calls for the object and trace creation are

then put into the body of the preTransform method,

while calls for the second method are put into the

body of the actualTransform method. This is illus-

trated by Listings 12 and 13. In Listing 13 the rule

A2B from Listing 12 is translated into the methods

A2BPre and A2B. A2BPre creates an empty B object

as well as a trace between the input A and method A2B

ﬁlls the corresponding B object with data as deﬁned

through the bindings from the A2B rule. To actually

perform the transformation on all A objects the meth-

ods preTransform and actualTransform deﬁne for

which type of object which method should be exe-

cuted.

Lazy rules and unique lazy rules do not require

this much overhead since they are called directly from

within other rules/methods and thus do not need to

be integrated into the traversal order. However, they

do require traces to be crated and added to the global

tracer. Additionally, methods translated from these

types of rules have the target object as their return

value rather than the return type being void.

4.4 Called Rule Translation

Called rules, much like lazy rules, can be translated

into a single method that creates the output object

and populates it in accordance with the bindings of

the rule. Other than the methods created for matched

rules, the methods for called rules can take more than

one parameter as input since called rules in ATL can

deﬁne an arbitrary amount of parameters of varying

types.

4.5 Helper and OCL Expression

Translation

Helpers can be translated into methods much like

called rules. The contained OCL expressions can

easily be translated into semantically equivalent Java

code. One distinction that can be made here is again

between the different Java versions used in terms of

our study. Streams can be used to simulate the syntax

of OCL, in particular the arrow symbol for implicitly

navigating over collections), while older Java versions

need to use loops instead. Table 2 shows a number

of typical OCL expressions and their Java counterpart

using streams.

Table 2: OCL expressions translated to Java streams.

OCL Java

collection→select(e) collection.stream().ﬁlter(e)

collection→collect(e) collection.stream().map(e)

collection→includes(x) collection.stream().anyMatch(

a → x == a)

element.attribute element.getAttribute()

i | i > 5 i → i > 5

Dedicated Model Transformation Languages vs. General-purpose Languages: A Historical Perspective on ATL vs. Java

129

5 RESULTS SUMMARY AND

ANALYSIS

In this section, we present the results of our analysis

in accordance with the research questions from Sec-

tion 1.

5.1 RQ1: How Much Less Complex

Can Transformations be Written in

Java SE14 Compared to Java SE5?

Tables 3 and 4 summarise the calculated size (LOC)

and complexity (McCabe) measurements on the

method level for both the Java SE5 and Java SE14

transformation code.

Table 3: Size of the Java transformations in LOC.

Java minimum average median maximum

SE 5 3 10.4 7 135

SE 14 3 7.5 5 105

Table 4: McCabe’s cyclomatic complexity of the Java trans-

formations.

Java minimum average median maximum

SE 5 1 2.7 2 44

SE 14 1 1.5 1 11

As expected, the LOC required to write transforma-

tions in a newer Java version is less than in an older

version. However, a reduction of about 30% on aver-

age is more than expected. This is conﬁrmed by the

median LOC which also shows about 30% reduction

of Java SE14 compared to Java SE5.

The reduction in complexity is even more appar-

ent for the cyclomatic complexity. On average, trans-

formations written in Java SE14 are 45% less com-

plex. The median again reﬂects this result. Further-

more, the maximum McCabe complexity is reduced

from 44 to 11, which is a signiﬁcant decrease.

Overall, the results reﬂect what was expected. Com-

pared to Java SE5, new language features in Java

SE14 help to reduce both the size and complexity of

transformation speciﬁcations written in Java. How-

ever, the fact that the maximum cyclomatic complex-

ity could be reduced by 75% is a surprising result.

5.2 RQ2: How Is the Complexity of

Transformations Written in Java

SE5 Distributed over the Different

Aspects of the Transformation

Process Compared to ATL?

Figure 1 shows a plot over the distribution of McCabe

complexity split up into the different transformation

aspects involved in a transformation written in Java

SE5. It shows that about 73% of the complexity in-

volved in writing a transformation in Java stems from

the actual code representing the transformations and

helpers. The other 27% are distributed among the

model traversal, tracing and setup code. In ATL, it

is these three aspects which do not have to be written

explicitly but which are hidden behind ATL’s syntax.

In other words, this means that 27% of what is writ-

ten in the Java transformation can be considered as

overhead.

Moreover, a signiﬁcant portion of the complexity

of the transformation-related code stems from the im-

plementation of helpers. About 44% of the transfor-

mation and helper complexity comes from the helper

implementations. While this does not pose a prob-

lem directly, when comparing this with the results

of (G

otz and Tichy, 2020) where helpers only con-

stitute about 16% of the complexity of an ATL mod-

ule, it does raise some concern. The focus shifts away

from the actual transformation code towards the out-

sourced helpers.

Figure 1: Distribution of McCabe complexity over transfor-

mation aspects in Java SE5.

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

130

Overall, the results support the consensus from back

when ATL was introduced that a signiﬁcant portion

of complexity can be avoided when using a dedicated

MTL for writing model transformations.

When comparing a simple binding (see Listing 7)

written in ATL with its translation in Java SE5 (see

Listing 14), there is not much difference. Both re-

quire nothing more than their language constructs for

accessing attribute values and assigning them to a dif-

ferent attribute.

 

1 private void simp l e B in d i ng ( Member

s) {

2 ...

3 t. setName (s . g e t Fi r s tNa m e () ) ;

4 }

 

Listing 14: A rule with a simple binding in Java SE5.

This is not the case when traces are involved. While

ATL allows developers to treat source elements as if

they were their translated target element (see List-

ing 8), some explicit code needs to be written in Java

(see Listing 15). As a result, the transformation spec-

iﬁcation gets more complex since it is not only re-

quired to call the trace resolution functionality, but it

is also necessary to put some additional type informa-

tion in so the Java compiler can handle the resulting

object correctly. The type information is necessary

since, as described in Section 4.2, the trace library

holds EObjects which have to be converted to the

correct type after they have been retrieved based on

the source object.

 

1 private void simp l e B in d i ng ( Member

s) {

2 ...

3 t. setName ( T R A C E R . r e s o l v e (

s. familyFather , Male . c l ass ) ) ;

4 }

 

Listing 15: A rule with a binding using traces in Java SE5.

The increase in complexity is even more prevalent

when looking at the translation of a typical helper.

The helper in Listing 9 requires OCL code that works

with collections which, thanks to OCL’s “→ syntax”,

can be expressed in a concise manner. In Java SE5,

however, as seen in Listing 16, the code gets a lot

more complex and bloated. This is due to the fact that

the only way to implement the selection is to iterate

over the collection through an explicit loop (lines 3 to

9) and to use an if-condition within the loop (lines 4

to 6).

 

1 private List < A s s o c i a t i o n >

ass o c iat i o ns ( Class sel f ) {

2 List < Association > li s t = new

LinkedLis t < A s s o c i a t i o n >( ) ;

3 for ( A s s oci a t i on asso :

AL L A SS O C IA T I ONS ) {

4 if ( asso . g e t V alue () == 1) {

5 list . add ( asso ) ;

6 }

7 }

8 return list ;

9 }

 

Listing 16: A typical helper in Java SE5.

Overall, the examples show that simple bindings

can be expressed easily in both ATL and Java SE5.

Bindings involving trace resolution require some

additional effort in Java SE5 while ATL can han-

dle those like any other binding. The most signif-

icant difference, however, comes from expressions

involving collections. Due to the required usage of

explicit loops, the Java SE5 code blows up in size

and complexity compared to the more compact ATL

notation.

5.3 RQ3: How Is the Complexity of

Transformations Written in Java

SE14 Distributed over the Different

Aspects of the Transformation

Process Compared to ATL?

Given the observations from RQ1 combined with the

the general improvements that Java SE14 brings to

the translation scheme, one would expect better re-

sults for the complexity distribution of transforma-

tions written in that Java version. However, when

looking at Figure 2 which again shows a plot over the

distribution of McCabe complexity split up into the

different transformation aspects involved in a trans-

formation written in Java, there is still a signiﬁ-

cant portion of complexity associated with the model

traversal, tracing and setup code.

While the complexity associated with model

traversal is greatly reduced by the use of the traver-

sal library, the overall distribution between the actual

code representing the transformations and helpers and

the model traversal, tracing and setup code does not

change much. About 24% of the overall transforma-

tion speciﬁcation can still be considered as overhead

code. Moreover, not only did this ratio stay similar

compared to Java SE5, also the ratio between helper

code complexity and transformation code complex-

ity stayed about the same. Helper code makes up

about 45% of the transformation and helper complex-

Dedicated Model Transformation Languages vs. General-purpose Languages: A Historical Perspective on ATL vs. Java

131

Figure 2: Distribution of McCabe complexity over transfor-

mation aspects in Java SE14.

ity. One potential reason for this is that while newer

Java features help to reduce complexity, they do so for

all aspects of the transformation, thus the distribution

stays about the same.

The reason that the code related to trace manage-

ment experiences an increase in its complexity ratio

compared to other parts of the transformation can be

explained by the fact that this code stayed the same

between the different Java versions. Thus, while the

complexity of all other components shrank, the com-

plexity of trace management stayed the same, leading

to higher relative complexity.

Overall, the results point towards even newer ver-

sions of Java still having to deal with the complex-

ity overhead that ATL is able to hide. Speciﬁcally,

while the traversal complexity could be greatly re-

duced through the use of newer language features,

handling traces still entails a large overhead.

When comparing the code snippets for writing simple

bindings and bindings involving traces in Java SE14

with ATL, there is no difference to the ﬁndings from

comparing Java SE5 to ATL. This is due to the fact

that no Java features introduced since SE5 help in re-

ducing the complexity of code that needs to be written

here.

Comparing the helper code snippets, however,

does show some improvements of Java SE14 over

Java SE5. Because of the introduction of the streams

 

1 private List < A s s o c i a t i o n >

ass o c iat i o ns ( Class sel f ) {

2 return A L L AS S O CI A T IO N S . stream ()

3 . f i l t e r ( asso ->

asso . g e t V a l ue () ==1)

4 . c o l l e ct ( Co l l e cto r s . t o L i s t () ) ;

5 }

 

Listing 17: A typical helper in Java SE14.

API, Java SE14 (see Listing 17) can now handle ex-

pressions involving collections nearly as seamless as

ATL (see Listing 9). Only one key difference re-

mains. Since collections in Java have to ﬁrst be

converted into streams and later reverted back into

the collection type, some overhead still exists. In

our example, these are the calls to stream() and

.collect(Collectors.toList()). In principle,

however, this difference could be eliminated by us-

ing an alternative GPL. The Scala programming lan-

guage, for example, does not require a conversion be-

tween streams and collections.

Overall, the examples show that code for both sim-

ple bindings and bindings involving traces in Java

SE14 stays just as complex in comparison to ATL as

in Java SE5. Code involving collections, however,

can now be expressed nearly as seamless as in ATL

due to the introduction of the streams API in Java

which offers a notation that is close to OCL nota-

tion.

6 THREATS TO VALIDITY

This section addresses potential threats to the validity

of the presented work.

The transformations chosen for evaluation in our

work were subject to a number of constraints. While

we aimed to select a variety of transformation mod-

ules w.r.t. scope and size, the limitation of LOC and

the source from which we selected the transforma-

tions may introduce a threat to the external valid-

ity of our work. The range of the domains involved

in the transformations is diverse and should thus not

threaten the external validity.

The next threat concerns the appropriateness and

correctness of our translation schema and the result-

ing transformations. We tried to mitigate this threat by

following the design science research method and us-

ing two separate reviewers for the proposed transfor-

mation schema. We also tested the correctness of the

resulting transformations to the extent that was possi-

ble based on available resources.

Another threat related to the translation schema

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

132

is that more than one way of translating ATL con-

structs into Java constructs and thus multiple trans-

lation schemas are possible. This impacts the con-

clusion validity of our study because different design

decisions for the translation schema may impact the

reproducibility of our results.

Lastly, the used metrics for measuring complexity

should also be discussed. To prevent a bias due to

the usage of a wrong measure, we opted to using two

metrics for measuring complexity. Their suitability is

supported by numerous publications in the literature

as shown in (Jabangwe et al., 2015).

7 RELATED WORK

To the best of our knowledge, there exists no research

that relates the complexity of transformations writ-

ten in a MTL with that of transformations written in

a GPL. However, there do exist several publications

that provide relevant context for our work.

Hebig et al. investigate the beneﬁt of using spe-

cialized model transformation languages compared to

general purpose languages by means of a controlled

experiment where participants had to complete a com-

prehension task, a change task, and they had to write

one transformation from scratch (Hebig et al., 2018).

They compare ATL, QVT-O and the GPL Xtend, and

they found no clear evidence for an advantage when

using MTLs. In comparison to their setup, we focus

on a larger number of transformations. Furthermore,

examples shown in the publication also suggest that

they did not consider ATLs reﬁning mode for their

refactoring task nor did their examples focus on ad-

vanced transformation aspects such as tracing.

The authors of (Sanchez Cuadrado et al., 2020)

propose A2L, a compiler for parallel execution of

ATL model transformations. A2L takes ATL trans-

formations as input and generates Java code that

can be run from within their self-developed engine.

Their data-oriented ATL algorithm describes how

ATL transformations are executed in their code and

closely resembles the structure that our translation

schema follows.

The Simple Transformation Library in Java

(SiTra) introduced in (Akehurst et al., 2006) provides

a simple set of interfaces for deﬁning transformations

in Java. Their interfaces abstract rules and traversal in

which they follow an approach similar to ours. How-

ever, they do not provide ways for trace management.

As previously described, parts of our research

build upon the work presented in (G

otz and Tichy,

2020). Here, the authors use a complexity measure

for ATL proposed in literature to investigate how the

complexity of ATL transformations is distributed over

different ATL constructs such as matched rules and

helpers. Their results provide a relevant data set to

compare our complexity distributions in Java trans-

formations to.

The authors of (van Amstel and van den Brand,

2011) use McCabe complexity to measure the com-

plexity of ATL helpers. Among others, this is also

done in (Vignaga, 2009). Similar to this, we use Mc-

Cabe complexity on transformations written in Java,

which includes translated helpers, to measure the

complexity of the code.

The Model Transformation Tool Contest (TTC)

aims to evaluate and compare various quality at-

tributes of model transformation tools. While some of

these quality attributes (e.g., readability of a transfor-

mation speciﬁcation) are related to the MTL used by

the tool, most of the attributes are related to tooling

issues (such as usability or performance) which are

out of the scope of our study. Moreover, the contest

is about comparing different MTLs with each other

rather than comparing them with a GPL. Nonethe-

less, some cases have been presented along with a

reference implementation in Java (Getir et al., 2017;

Beurer-Kellner et al., 2020), which could serve as an-

other source for comparing MTLs and GPLs more

widely, including tooling- and execution-related as-

pects.

8 CONCLUSION

In this work, we presented how we developed and

applied a translation schema to translate ATL trans-

formations into Java. We also described our results

of analysing the complexity and complexity distri-

bution of these transformations. For this purpose,

we used McCabe complexity as well as LOC met-

rics to measure the complexity of 10 transformations

translated into Java SE5 and Java SE14, respectively.

We analysed how the complexity between transfor-

mations written in those two Java versions differs as

well as how the distribution of complexity compares

to that in transformations written in ATL.

We found that new features introduced into Java

since 2006 help to signiﬁcantly reduce the complexity

of transformations written in Java. However, we also

showed that while the overall complexity of trans-

formations is reduced, the distribution of how much

of that complexity stems from code that implements

functionality that ATL and other model transforma-

tion languages can hide from the developer stays

https://www.transformation-tool-contest.eu

Dedicated Model Transformation Languages vs. General-purpose Languages: A Historical Perspective on ATL vs. Java

133

about the same. Thus, while the overall complexity

is reduced with newer Java versions, the overhead en-

tailed by using a general purpose language for writing

model transformations still seems to be present.

For future work, we propose to also look at the

transformation development process as a whole, in-

stead of only at the resulting transformations. In

particular, we are interested in investigating how the

maintenance effort differs between transformations

written in a GPL and those written in a MTL. For this

purpose, the presented artefacts can be reused. Sim-

ple modiﬁcations to the ATL transformations can be

compared to what needs to be adjusted in the corre-

sponding Java code. Furthermore, because develop-

ers are the ﬁrst to be impacted by the languages, it is

also important to include users into such studies. For

this reason, we propose to focus on user-centric study

setups to be able to better study the impact of the lan-

guage choice on developers.

Another potential avenue to explore is the compar-

ison with a general purpose language that has a more

complete support for functional programming such as

e.g. Scala. Additional features such as pattern match-

ing and easier use of functional syntax for translating

OCL expressions into could potentially help to further

reduce the complexity of the resulting transformation

code.

REFERENCES

Akehurst, D. H., Bordbar, B., Evans, M. J., Howells, W.

G. J., and McDonald-Maier, K. D. (2006). SiTra:

Simple Transformations in Java. In Model Driven

Engineering Languages and Systems, pages 351–364.

Springer.

Aniche, M. (2015). Java code metrics calculator (CK).

https://github.com/mauricioaniche/ck.

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

Families to Persons Case.

Beurer-Kellner, L., von Pilgrim, J., and Kehrer, T. (2020).

Round-trip migration of object-oriented data model

instances. In Transformation Tool Contest at the Con-

ference on Software Technologies: Applications and

Foundations (TTC@STAF).

Burgueno, L., Cabot, J., and Gerard, S. (2019). The Fu-

ture of Model Transformation Languages: An Open

Community Discussion. Journal of Object Technol-

ogy, 18(3):7:1–11. The 12th International Conference

on Model Transformations.

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

vey of model transformation approaches. IBM systems

journal, 45(3):621–645.

Getir, S., Vu, D. A., Peverali, F., Str

uber, D., and Kehrer,

T. (2017). State Elimination as Model Transformation

Problem. In Transformation Tool Contest at the Con-

ference on Software Technologies: Applications and

Foundations (TTC@STAF), pages 65–73.

otz, S. and Tichy, M. (2020). Investigating the Origins of

Complexity and Expressiveness in ATL Transforma-

tions. Journal of Object Technology, 19(2):12:1–21.

The 16th European Conference on Modelling Foun-

dations and Applications (ECMFA 2020).

otz, S., Tichy, M., and Groner, R. (2020). Claimed advan-

tages and disadvantages of (dedicated) model trans-

formation languages: a systematic literature review.

Software and Systems Modeling.

Gray, J. and Karsai, G. (2003). An examination of DSLs for

concisely representing model traversals and transfor-

mations. In 36th Annual Hawaii International Con-

ference on System Sciences, 2003. Proceedings of the.

Hebig, R., Seidl, C., Berger, T., Pedersen, J. K., and Wa-

sowski, A. (2018). Model Transformation Languages

Under a Magnifying Glass: A Controlled Experi-

ment with Xtend, ATL, and QVT. In Proceedings of

the 2018 26th ACM Joint Meeting on European Soft-

ware Engineering Conference and Symposium on the

Foundations of Software Engineering, New York, NY,

USA.

Jabangwe, R., B

orstler, J.,

Smite, D., and Wohlin, C.

(2015). Empirical evidence on the link between

object-oriented measures and external quality at-

tributes: a systematic literature review. Empirical

Software Engineering, 20(3):640–693.

Jouault, F., Allilaire, F., B

ezivin, J., Kurtev, I., and Val-

duriez, P. (2006). ATL: A QVT-like Transforma-

tion Language. In Companion to the 21st ACM SIG-

PLAN Symposium on Object-oriented Programming

Systems, Languages, and Applications.

Jouault, F., Allilaire, F., B

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

ATL: A model transformation tool. Science of Com-

puter Programming.

Kehrer, T., Kelter, U., Ohrndorf, M., and Sollbach, T.

(2012). Understanding model evolution through se-

mantically lifting model differences with silift. In 28th

IEEE International Conference on Software Mainte-

nance (ICSM), pages 638–641. IEEE.

Kehrer, T., Taentzer, G., Rindt, M., and Kelter, U. (2016).

Automatically deriving the speciﬁcation of model

editing operations from meta-models. In International

Conference on Theory and Practice of Model Trans-

formations, pages 173–188. Springer.

Krikava, F., Collet, P., and France, R. (2014). Manipulating

Models Using Internal Domain-Speciﬁc Languages.

In Symposium On Applied Computing, Gyeongju,

South Korea.

OMG (2014). Object Constraint Language (OCL).

https://www.omg.org/spec/OCL/2.4/PDF.

OMG (2016). Meta Object Facility (MOF).

https://www.omg.org/spec/MOF.

Rindt, M., Kehrer, T., and Kelter, U. (2014). Auto-

matic Generation of Consistency-Preserving Edit Op-

erations for MDE Tools. Demos@ MoDELS, 14.

Sanchez Cuadrado, J., Burgueno, L., Wimmer, M., and Val-

lecillo, A. (2020). Efﬁcient execution of ATL model

transformations using static analysis and parallelism.

IEEE Transactions on Software Engineering.

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

134

Schultheiß, A., Bittner, P. M., Kehrer, T., and Th

um, T.

(2020a). On the use of product-line variants as exper-

imental subjects for clone-and-own research: a case

study. In SPLC ’20: 24th ACM International Sys-

tems and Software Product Line Conference, Mon-

treal, Quebec, Canada, October 19-23, 2020, Volume

A, pages 27:1–27:6. ACM.

Schultheiß, A., Boll, A., and Kehrer, T. (2020b). Com-

parison of Graph-based Model Transformation Rules.

Journal of Object Technology, 19(2):3:1–21.

Sendall, S. and Kozaczynski, W. (2003). Model transfor-

mation: the heart and soul of model-driven software

development. IEEE Software.

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

(2008). EMF: eclipse modeling framework. Pearson

Education.

Str

uber, D., Born, K., Gill, K. D., Groner, R., Kehrer, T.,

Ohrndorf, M., and Tichy, M. (2017). Henshin: A

usability-focused framework for emf model transfor-

mation development. In International Conference on

Graph Transformation, pages 196–208. Springer.

van Amstel, M. F. and van den Brand, M. (2011). Us-

ing Metrics for Assessing the Quality of ATL Model

Transformations. In MtATL@ TOOLS.

Vignaga, A. (2009). Metrics for measuring ATL model

transformations. MaTE, Department of Computer Sci-

ence, Universidad de Chile, Tech. Rep.

Wieringa, R. J. (2014). Design science methodology

for information systems and software engineering.

Springer. 10.1007/978-3-662-43839-8.

Dedicated Model Transformation Languages vs. General-purpose Languages: A Historical Perspective on ATL vs. Java

135