Exploring DSL Evolutionary Patterns in Practice

A Study of DSL Evolution in a Large-scale Industrial DSL Repository

Josh G. M. Mengerink

, Bram van der Sanden

, Bram C. M. Cappers

, Alexander Serebrenik

Ramon R. H. Schiffelers

1,2

and Mark G. J. van den Brand

Eindhoven University of Technology, The Netherlands

ASML, Veldhoven, The Netherlands

Keywords:

Model Driven Engineering, Evolution, Maintenance.

Abstract:

Model-driven engineering is used in the design of systems to (a.o.) enable analysis early in the design process.

For instance, by using domain-speciﬁc languages, enabling engineers to model systems in terms of their

domain, rather then encoding them into general purpose modeling languages. Domain-speciﬁc languages,

like classical software, evolve over time. When domain languages evolve, they may trigger co-evolution of

models, model-to-model transformations, editors (both graphical and textual), and other artifacts that depend

on the domain-speciﬁc language. This co-evolution can be tedious and very costly.

In literature, various approaches are proposed towards automated co-evolution. However, these approaches do

not reach full automation. Several other studies have shown that there are theoretical limitations to the level

of automation that can be achieved in certain scenarios. For several scenarios full automation can never be

achieved. We wish to gain insight to which extent practically occurring scenarios can be automated.

To gain this insight, in this paper, we investigate on a large-scale industrial repository, which (co-)evolutionary

scenarios occur in practice, and compare them with the various scenarios and their theoretical automatability.

We then assess whether practically occurring scenarios can be fully automated.

1 AN INTRODUCTION TO

MODEL CO-EVOLUTION

Model-driven software engineering (MDSE) has

many promises, such as improved productivity and

quality. Among those strengths is the ability to per-

form analysis early in the design process (Schiffelers

et al., 2012), (Karsai et al., 2003). For instance,

computing the expected throughput of a modeled

logistic system, giving feedback earlier in the design

process and increasing productivity.

One way to support such early analysis is to

design domain-speciﬁc languages (DSLs) enabling

engineers to model (parts of) systems in terms close to

their knowledge domain. Subsequently, those models

can be transformed into dedicated analysis formal-

isms (Lara and Vangheluwe, 2002) such as mCRL2

(Groote et al., 2007), UPPAAL (Bengtsson et al.,

1995), or SDF (SDF, 2015) using standard model-

to-model transformation techniques (e.g., QVT or

ATL (QVT, 2015; Jouault and Kurtev, 2006; Kolovos

et al., 2008)). Such a two-phase approach (transform-

ation from speciﬁcation models to analyses models)

has been successfully implemented in various studies

in industry (Schiffelers et al., 2012), (Mohagheghi

et al., 2013).

However, MDSE using DSLs also has challenges.

As metamodels (which underpin DSLs) have become

the central artifact in the design (Mengerink et al.,

2016), (Vissers et al., 2016), their evolution (Favre,

2005) can trigger forced co-evolution of other eco-

system artifacts such as editors (Di Ruscio et al.,

2011), constraints (Khelladi et al., 2016), transforma-

tions (Garc

ıa et al., 2013; Levendovszky et al., 2010),

and models (Gruschko et al., 2007; Narayanan et al.,

2009; Cicchetti et al., 2008; Wachsmuth, 2007). This

process is similar to changing source code in response

to API evolution in a traditional software engineering

context (Dig and Johnson, 2005), and results in a

tedious, error-prone, and thus costly process of co-

evolution.

Various approaches have been proposed aiming

to (partially) automate co-evolution of metamodel-

dependent artifacts (Khelladi et al., 2016; Garc

ıa

446

Mengerink, J., Sanden, B., Cappers, B., Serebrenik, A., Schiffelers, R. and Brand, M.

Exploring DSL Evolutionary Patterns in Practice - A Study of DSL Evolution in a Large-scale Industrial DSL Repository.

DOI: 10.5220/0006605804460453

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

ISBN: 978-989-758-283-7

et al., 2013; Levendovszky et al., 2010; Di Ruscio

et al., 2011). In particular, co-evolution of models

has received signiﬁcant attention (Rose et al., 2009;

Wachsmuth, 2007; Gruschko et al., 2007; Di Rocco

et al., 2012), as models are most numerous artifacts

depending on the metamodel (Vissers et al., 2016).

Furthermore, several studies have also approached the

co-evolution problem from a theoretical stance (Her-

rmannsd

orfer and Ratiu, 2009; Sprinkle et al., 2009),

determining the limits of automation. These papers

argue that when the constituting parts (e.g., syntax

and semantics) of DSLs evolve, full automation can

only be achieved in certain cases

In our research, we are working towards improved

automation of model co-evolution, but wonder to

what extent this is feasible. To ascertain the impact of

the fundamental limitations (Sprinkle et al., 2009) in

practice, we wish to understand which of these cases

occur in practice.

The remainder of this paper is structured as fol-

lows: we describe our case study and experiments in

Section 2 and discuss the results in Section 3. We

discuss threats to validity and conclusions in Sections

4 and 5 respectively.

2 STUDY

2.1 Evolutionary Patterns

To understand what evolutionary patterns exist in

terms of a DSL, we ﬁrst identify the various compon-

ents of a DSL. Sprinkle et al. (Sprinkle et al., 2009)

have provided a formal deﬁnition of a DSL as a tuple

of:

1. Abstract Syntax (i.e., the metamodel), denoted A;

2. Constraints (e.g., OCL constraints on the

metamodel), denoted C ;

3. A semantic domain, denoted S D;

4. Semantics that map syntax to the semantic do-

main, denoted S .

We then deﬁne an evolutionary pattern as a change

of any combination of (1), (2), (3), and/or (4). For

example: syntax only, or syntax and semantics co-

evolution.

Throughout this paper, the terms cases and patterns

both refer to a particular co-evolution of constituent parts

of a DSL

2.2 Industrial Context

Our research takes place at ASML, provider of litho-

graphy equipment for the semiconductor industry. At

ASML, MDE is used to enable virtual prototyping

to provide feedback early in the design process. In

particular, we perform our case study (cf. (Runeson

and H

ost, 2008)) on the CARM ecosystem of DSLs

(Schiffelers et al., 2012). The CARM ecosystem con-

sists of more than 20 DSLS with over 100 model-to-

model transformations, with a revision history of up

to six years. Note that we only study ﬁles committed

to the main branch of this repository, as subsequent

states of this branch represent ﬁnished products.

In CARM (Schiffelers et al., 2012), we observe

that the deﬁnition of a DSL as described by Sprinkle

et al. (Sprinkle et al., 2009) is not present in prac-

tice. Rather than the decomposition described in

Section 2.1, we see that the abstract syntax (A)

and constraints (C ) are often combined into a single

metamodel speciﬁcation (denoted M

Furthermore, the semantic domain (S D) is im-

plemented as a second metamodel. Often, this is

the metamodel of an analysis DSL, rather than some

abstract domain with a notion of equivalence (as the

description of Sprinkle et al. (Sprinkle et al., 2009)

suggests). Lastly, the model-to-model transformation

between the speciﬁcation DSL metamodel (i.e., M

)

and analysis DSL metamodel (S D) takes on the

role of S . These relations (and their evolution) are

illustrated in Figure 1.

Figure 1: The relationship between the formal deﬁnition of

a language, and various artifacts in a repository.

Observing this practical organisation of DSLs at

ASML, we limit ourselves to combinations of evolu-

tions of:

1. Syntax-deﬁning metamodel, M

;

2. The semantics-deﬁning transformation, S ;

Exploring DSL Evolutionary Patterns in Practice - A Study of DSL Evolution in a Large-scale Industrial DSL Repository

447

name : String

Ecosystem

TransformationRevision

name : String

abstract File abstract Revision

namespace : String

MetaModelRevision

MetaModel

Transformation

revisionOf

timestamp : int

Snapshot

revisions

1..1

1..*

0..*

modiﬁedFiles

parent

1..*

snapshots

ﬁles

1..*

allFiles

1..*

prev, next

0..1

inputs

outputs

0..*

prev, next

0..1

Figure 2: A graphical representation of the metamodel we

use to specify the evolution history of our ecosystem.

3. The metamodel deﬁning the semantic domain,

S D.

This results in a total of seven cases (= 2

− 1),

which excludes the pattern where nothing evolves.

2.3 Experimental Setup

In the spirit of MDE, we reconstruct the evolution

history of DSLs as a model. For this purpose we have

designed the metamodel illustrated in Figure 2. On

this metamodel, we subsequently deﬁne patterns of

interest.

The all-encompassing concept in the metamodel

is the Ecosystem. An ecosystem consists of various

Files such as MetaModels and Transformations.

As the ﬁles evolve over time, Snapshots represent

the state of the ecosystem at a particular point in

time, as indicated in the timestamp attribute. In a

snapshot, various ﬁles are modiﬁed, as encoded in

the modifiedFiles reference. A snapshot also has a

reference to ﬁles that were “carried over” from earlier

revisions, by means of the allFiles reference.

Revision is a version of a ﬁle at a particular

point in time. Similar to the distinction between two

types of Files: Metamodels and transformations,

we distinguish between MetaModelRevisions and

TransformationRevisions. Since the namespace

of a DSL, as well as the input and the output of

the transformations, can evolve in time, we repres-

ent them as attributes of MetaModelRevisions and

TransformationRevisions rather than Metamodel

and Transformation.

timestamp = 1

:Snapshot

timestamp = 2

:Snapshot

namespace = “Av1”

:MetaModelRevision

:TransformationRevision

namespace = “Bv1”

:MetaModelRevision

allFiles

modiﬁedFiles

output

input

output

name = “Example”

:Ecosystem

revisions

Figure 3: An object diagram (also known as instance dia-

gram) of a model conforming to the metamodel in Figure 2.

Speciﬁcally, an instance of Ecosystem is presented. For

clarity, several edges have been omitted but do recall that

Snapshot.modiﬁedFiles ⊆ Snapshot.allFiles.

This model shows two subsequent snapshots of the repos-

itory (at times t = 1 and t = 2). In snapshot 1, DSL B is

modiﬁed, in snapshot 2, DSL A and a transformation from

A to B are modiﬁed.

Subsequently, we can reconstruct the revision

history as a model in our metamodel. In Figure 3,

we present an example fragment of such a model.

As stated in Section 2.2, the constituting parts of

our DSL are in practice present as two DSLs A and

B (representing M

and S D) and a transformation

between them (representing S). Such a pattern is also

illustrated in Figure 3, where we see the pattern of an

evolving syntax and semantics, but the semantic do-

main does not evolve. From the reconstructed model

of our repository, we wish to extract for evolutionary

pattern, how many Revisions evolve according to

that pattern.

To encode the various combinations in which syn-

tax, semantics, and semantic domain can change, we

create configurations, which are boolean triples

encoding the particular combination of interest. For

every combination we create one such triple:

Configuration : B × B × B

For example, the pattern in which syntax changes,

semantic changes, but the semantic domain does not,

is encoded as

true,true, f alse

. We also refer to this

conﬁguration as Q110. The only conﬁguration which

we are not interested in is

f alse, f alse, f alse

, as

there is no (co-)evolution.

Note that the common ground between every

conﬁguration of interest is that each one has at least

one artifact that evolves. In terms of our model this

means that we can iterate over every Snapshot, and

at least one artifact relevant for the pattern is in the

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

448

Data: An ecosystem e, and a conﬁguration

Con f

Result: A collection of all revisions that play a

part in Con f

1 results ←

2 foreach snapshot : Snapshot ∈ e.snapshots do

3 foreach revision : Revision ∈

snapshot.modiﬁedFiles do

4 if evolvesAsPattern(revision, Conf)

then

5 results ← results ∪

Con f , revision

6 end

7 end

8 end

9 return results

Algorithm 1: Iterate over every Revision to see if it

plays a part in a particular pattern. We can iterate over

modifiedFiles only, because every Revision is uniquely

contained in the modifiedFiles relation of a Snapshot.

modifiedFiles of that snapshot. This knowledge is

used in Algorithm 1.

This leaves the problem of identifying whether a

revision plays a part in a pattern as described by a

conﬁguration. This identiﬁcation is given by means

of the evolvesAsPattern function:

evolvesAsPattern(r : Revision,c : Con f iguration) =

evolvesAsSyntax(r,c) ∨

evolvesAsSemantics(r,c) ∨

evolvesAsSemanticDomain(r,c)

It is important to note that we consider all input

metamodels of a transformation together to specify

syntax, and all output metamodels of a transformation

together to specify the semantic domain. This means

that:

• The syntax, or semantic domain is considered

to change, if any of its composing

MetaModelRevisions change.

• The syntax, or semantic domain is considered

to stay the same if none of its composing

MetaModelRevisions change.

For more informations about the constituent func-

tions, we refer to the algorithms in the appendix.

Algorithm 2 for evolvesAsSyntax, 2 for evolvesAsSe-

mantics, and 4 for evolvesAsSemanticDomain.

The result from Algorithm 1 then contains, per

conﬁguration, all the revisions of ﬁles that evolve

according to that conﬁguration. The results of this

analysis are presented in Section 3.

2.4 Mining Git

In order to perform our analyses, we extract relevant

ﬁles the git version-control system at ASML. At

ASML, the GIT repository makes use of a master

branch that represents ﬁnished states. Features are de-

veloped in separate branched and merged into master

once completed. In this work, we limit ourselves to

the main branch of the repository as commits to this

branch should represent the full intended change to

the ecosystem.

On the main branch, starting with the earliest com-

mit, we look at subsequent commits to the ecosystem

and determine which ﬁles were added, changed, or

deleted. This earliest-ﬁrst approach allows us to deal

with merges as regular commits.

2.5 Instance Model Creation

To create an instance of the metamodel in Figure 2,

we take the following steps. Starting with the earliest

commit to the main branch, we create a snapshot S

for this commit. All ﬁles in that commit are added to

both the “modiﬁedFiles” and ‘allFiles‘ of S

For every subsequent commit (including merges)

to the main branch ,we create a snapshot S

with

a timestamp corresponding to the commit. Sub-

sequently:

• Every ﬁle added or modiﬁed in that commit is

added to both the “modiﬁedFiles” and ‘allFiles‘

of S

• Files from the “allFiles” of the previous version

i−1

) that were not added/modiﬁed/deleted in this

commit are added to the “allFiles” of S

For subsequent snapshots, the “next” and “prev”

relations are set.

Once the above relations have all been initialized,

we can begin creating the “input” and “output” rela-

tions of the various transformations as described in

Section 2. For instance, in the example illustated

in Figure 3, we parse a TransformationRevision, and

ﬁnd that it has “Av1” and “Bv1” as input and output

respectively. As the TransformationRevision resides

at timestamp t = 2, we have to search backwards

(starting at t = 2) through all snapshots for MetaMod-

elRevisions with the appropriate names. In Figure 3,

this means that we use the “Av1” at time t = 2, and

“Bv1” at time t = 1.

After the “input” and “output” relations have been

properly created, we can begin our pattern-analysis.

Exploring DSL Evolutionary Patterns in Practice - A Study of DSL Evolution in a Large-scale Industrial DSL Repository

449

Table 1: Number of revisions evolving according to a

particular conﬁguration.

Reference M

evolves

S D

evolves

Q010 no yes no 865

Q100 yes no no 368

Q001 no no yes 344

Q111 yes yes yes 296

Q110 yes yes no 86

Q011 no yes yes 84

Q101 yes no yes 0

Time

Transformations

Figure 4: Illustration showing the modiﬁcation of model-

to-model transformations over time (Q010). Each row

represents a transformation, and each column represents a

moment in time. Columns are sorted chronologically, and

rows are sorted by initial creation of the transformation. A

cell is colored red if the given transformation changed at

that moment in time. Names of transformations have been

omitted for reasons of conﬁdentiality.

Observe that various transformations are often created

together (A), and maintained together (B). Also, once a

transformation is modiﬁed, various revisions ensue in rapid

succession (C).

3 DISCUSSION OF RESULTS

Using the analysis from Section 2, we have obtain the

results which are presented in Table 1. In Sections 3.1

through 3.4 we discuss the most frequently occuring

cases in more detail.

3.1 Redeﬁnition of Semantics (Q010)

As the semantics-only DSL evolution case (Q010) has

the most occurences, we can say that the semantic

deﬁnitions of DSLs are the most volatile part. Plotting

the changes over time as illustrated in Figure 4, we

can see that the evolution frequency of the various

transformations seems to decrease over time. This

enforces our intuition that DSL semantics stabilize

over time.

Interesting in Figure 4 is the large vertical column

(encircled in blue), in which a majority of trans-

formation seems to have been updated. Upon closer

(manual) inspection, a new website for document-

ation was introduced, and all error messages were

refactored to include appropriate links to this site.

This, in essence, was not an update to the semantics.

These log-related updates appear to be the only non-

semantical updates performed.

To ensure that these non-semantical updates do

now invalidate our ﬁndings, we further analyzed to

what extent they are present in our data. An analysis

of these non-semantical updates shows that of the

17187 differences that were observed 57 are cre-

ations of new log-statements, 201 are modiﬁcations

of existing log-expressions, and 1 removal of a log

statement. The total of 259 non-semantical changes

thus constitutes approximately 1.5% (259/17187) of

the observed data, which leads us to conclude that

our results are not invalidated by presence of non-

semantical changes.

The observed volatility (the fact that most DSL

evolutions are semantics-based), creates the necessity

to incorporate semantics into the co-evolution process

of models. Interestingly, the work of Sprinkle et al.

(Sprinkle et al., 2009) does not discuss the funda-

mental limitations of model co-evolution in response

to evolution of only DSL semantics.

The question we remain with is: given a model m

for M

, does a model m

exists that has equivalent

semantics using the new semantical deﬁnition S

∃

∈M

) ≡ S

)]

In practice, we observe that identity = is frequently

used as a notion of equivalence (≡). In this case,

existence of such an m

basically boils down to the

question if the image (I) of the original semantic

function is a subset of the image of the updated

semantic function:

I(S

) ⊆ I(S

)

In general, this problem is undecidable. Take for

instance I(S

) to be

true, f alse

, and let S

map pro-

grams to true, if and only if that program terminates

(the Halting problem). As the Halting problem is

undecidable, as a result I(S

) is undecidable. Hence,

it is undecidable whether I(S

) ⊆ I(S

An interesting piece of future work would be to

further investigate the nature of the S

to S

evolution.

3.2 Syntax-only DSL Evolution (Q100)

The second most frequent occurring change are syn-

tactic only in nature (Q100). In total, 368 revisions

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

450

evolved according to this pattern. We have already

studies the different kinds of syntactic changes that

typically occur in practice (Mengerink et al., 2016),

(Vissers et al., 2016). Furthermore, various ap-

proaches exist that perform syntactic model co-

evolution in response to syntax-only DSL evolution

(Eda, 2015; Rose et al., 2010; Di Rocco et al., 2012).

Upon more detailed study of the automation of

this case, Sprinkle et al. (Sprinkle et al., 2009) argue

that semantic model co-evolution is possible in a

large number of cases. More speciﬁcally, for additive

evolutions, it is always possible, and for subtractive

changes it depends on the speciﬁc context.

In our previous work (Mengerink et al., 2016)

we have observed that additive change make up

approximately 37% of syntactic DSL evolution, and

that 22% of syntax evolutions is subtractive in nature.

Moreover, we have looked into changes (i.e., a

change to a value in the metamodel is neither additive

nor subtractive). This category makes up the remain-

ing 41% of DSL evolutions. Additional research

is required to ascertain the automatability of these

syntax changes.

3.3 Evolution of the Semantic Domain

(Q001)

The third most frequent case is evolution of the

semantic domain. We expected the semantic domains

(i.e., our analysis DSLs) to be fairly stable over

time. The number of occurences (344) were nearly

as numerous as the syntactic evolutions (368), which

surprised us. This led us to investigate the evolution

of semantic domain DSLs further.

When intersecting all revisions that evolve as

syntax (Q100) and the revisions that evolve as a

semantic domain (Q001), we observe 309 revisions

are in both sets. Upon further inspection, it turns out

that transformations are often multi-step. That is, a

DSL A is transformed into a DSL B, which in turn

is transformed into a DSL C. In this case, when B

evolves, it acts both as semantic domain, and as a

syntax deﬁnition. Please note that this is distinct from

pattern Q101.

3.4 Everything Evolves (Q111)

The last major case (with over 200 occurrences),

is Q111. Here, we have to acknowledge a threat

to validity, as distinct evolutions may be obscured,

e.g., by our interpretation of git merges, skewing the

observations we make. The number of occurrences in

Q111 may thus be attributed to various other cases,

meaning that the various other cases become more

signiﬁcant. However, to conﬁrm this, more in-depth

research is needed, which we mark as future work.

4 THREATS TO VALIDITY

As with any repository mining work, there are some

inherent threats (Bird et al., 2009). In particular, our

assumption that a commit corresponds to a piece of

work may lead to skewing of our results. However, as

the set of ﬁles were consistent after every commit, we

have conﬁdence that this is not the case. Nonetheless,

we envision future work to further analyze whether

our results are indeed skewed.

Furthermore, we have inspected the change of a

ﬁle, but not how that ﬁle was changed. This leads

to some additional false positives, as described in

Section 3.1. Further research is needed to perform

a more in-depth analysis of the various changes.

5 CONCLUSION

In this work, we have investigated the evolution of

DSLs in a large-scale industrial MDSE ecosystem.

We conclude that, in our case study, of the various

constituent parts of a DSL that can evolve:

The most common type of DSL evolution is

redeﬁnition of its semantics.

Also, by mapping the automatability of semantic-

preserving co-evolution to the Halting problem, we

have argued that

Automatability of semantic-preserving

model co-evolution in response to DSL semantic

evolution is undecidable in general.

Further analysis of the semantic redeﬁnition of

languages over time (Figure 4 showed that, in our

case-study, the frequency of changes per transforma-

tion seems to decrease over time (barring exceptions).

Leading us to conjecture:

DSL semantics stabilize over time.

Lastly, we feel that this work shows that the

evolution of DSL semantics plays a more dominant

role in DSL evolution, where in literature, syntax is

often assumed to be the more dominant.

Exploring DSL Evolutionary Patterns in Practice - A Study of DSL Evolution in a Large-scale Industrial DSL Repository

451

More research into the role of DSL semantics

(co-)evolution is needed

As future work, we envision investigating whether

certain types always precede/succeed each other. For

instance, is syntax evolution normally followed by

semantic redeﬁnition, rather than changing the syntax

and semantics together in one go. Additionally, as

stated in Section 3.1, there is a need to investigate the

nature of DSL semantic change, in order to ascertain

if for some of these changes automation of model of

co-evolution is possible. Furthermore, additional case

studies are necessary to determine if the results in this

study can be generalized.

REFERENCES

(2015). Edapt. https://www.eclipse.org/edapt/. Accessed:

2015-04-07.

(2015). QVTo. http://www.eclipse.org/mmt/?project=qvto.

Accessed: 2015-04-07.

(2015). SDF. http://www.es.ele.tue.nl/sdf3/. Accessed:

2015-04-07.

Bengtsson, J., Larsen, K. G., Larsson, F., Pettersson, P.,

and Yi, W. (1995). UPPAAL - a tool suite for

automatic veriﬁcation of real-time systems. In Hybrid

Systems III: Veriﬁcation and Control, Proceedings of

the DIMACS/SYCON Workshop, pages 232–243.

Bird, C., Rigby, P. C., Barr, E. T., Hamilton, D. J., Germ

an,

D. M., and Devanbu, P. T. (2009). The promises and

perils of mining git. In MSR, pages 1–10.

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

A. (2008). Automating co-evolution in model-driven

engineering. In IEEE Enterprise Distributed Object

Computing Conference, pages 222–231.

Di Rocco, J., Iovino, L., and Pierantonio, A. (2012).

Bridging state-based differencing and co-evolution. In

Models and Evolution, pages 15–20. ACM.

Di Ruscio, D., L

ammel, R., and Pierantonio, A. (2011).

Automated co-evolution of GMF editor models. In

SLE, volume 6563 of LNCS, pages 143–162. Springer.

Dig, D. and Johnson, R. (2005). The role of refactorings in

api evolution. In 21st IEEE International Conference

on Software Maintenance (ICSM’05), pages 389–398.

Favre, J.-M. (2005). Languages evolve too! changing

the software time scale. In Principles of Software

Evolution, pages 33–42.

Garc

ıa, J., Diaz, O., and Azanza, M. (2013). Model

transformation co-evolution: A semi-automatic ap-

proach. In SLE, volume 7745 of LNCS, pages 144–

163. Springer.

Groote, J. F., Mathijssen, A., Reniers, M., Usenko, Y., and

van Weerdenburg, M. (2007). The formal speciﬁca-

tion language mcrl2. In Methods for Modelling Soft-

ware Systems (MMOSS), number 06351 in Dagstuhl

Seminar Proceedings. Dagstuhl.

Gruschko, B., Kolovos, D., and Paige, R. (2007). Towards

synchronizing models with evolving metamodels. In

Workshop on Model-Driven Software Evolution.

Herrmannsd

orfer, M. and Ratiu, D. (2009). Limita-

tions of automating model migration in response to

metamodel adaptation. In MSE, Workshops and

Symposia at MODELS, volume 6002 of LNCS, pages

205–219. Springer.

Jouault, F. and Kurtev, I. (2006). Transforming models with

atl. In Bruel, J.-M., editor, Satellite Events at the

MoDELS 2005 Conference, volume 3844 of LNCS,

pages 128–138. Springer.

Karsai, G., Sztipanovits, J., Ledeczi, A., and Bapty, T.

(2003). Model-integrated development of embedded

software. Proceedings of the IEEE, 91(1):145–164.

Khelladi, D. E., Hebig, R., Bendraou, R., Robin, J., and

Gervais, M.-P. (2016). Metamodel and constraints

co-evolution: A semi automatic maintenance of OCL

constraints. In ICSR, pages 333–349. Springer.

Kolovos, D. S., Paige, R. F., and Polack, F. A. C. (2008).

The Epsilon Transformation Language, pages 46–60.

Springer Berlin Heidelberg, Berlin, Heidelberg.

Lara, J. d. and Vangheluwe, H. (2002). Atom3: A tool

for multi-formalism and meta-modelling. In Kutsche,

R.-D. and Weber, H., editors, FASE, pages 174–188,

Berlin, Heidelberg. Springer Berlin Heidelberg.

Levendovszky, T., Balasubramanian, D., Narayanan, A.,

and Karsai, G. (2010). A novel approach to semi-

automated evolution of dsml model transformation. In

SLE, volume 5969 of LNCS, pages 23–41. Springer.

Mengerink, J. G. M., Serebrenik, A., Schiffelers, R. R. H.,

and van den Brand, M. G. J. (2016). A complete

operator library for DSL evolution speciﬁcation. In

ICSME 2016, Raleigh, NC, USA, pages 144–154.

Mohagheghi, P., Gilani, W., Stefanescu, A., Fernandez,

M. A., Nordmoen, B., and Fritzsche, M. (2013).

Where does model-driven engineering help? experi-

ences from three industrial cases. Software & Systems

Modeling, 12(3):619–639.

Narayanan, A., Levendovszky, T., Balasubramanian, D.,

and Karsai, G. (2009). Automatic domain model mi-

gration to manage metamodel evolution. In MoDELS,

volume 5795 of LNCS, pages 706–711. Springer.

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

F. A. (2010). Model migration with Epsilon Flock.

In ICMT, volume 6142 of LNCS, pages 184–198.

Springer.

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

A. C. (2009). An analysis of approaches to model

migration. In MoDSE-MCCM, pages 6–15.

Runeson, P. and H

ost, M. (2008). Guidelines for conducting

and reporting case study research in software engin-

eering. Empirical Software Engineering, 14(2):131.

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

452

Schiffelers, R. R. H., Alberts, W., and Voeten, J. P. M.

(2012). Model-based speciﬁcation, analysis and syn-

thesis of servo controllers for lithoscanners. In 6th

International Workshop on Multi-Paradigm Modeling,

pages 55–60. ACM.

Sprinkle, J., Gray, J., and Mernik, M. (2009). Funda-

mental limitations in domain-speciﬁc modeling lan-

guage evolution. Technical report, Technical Report#

Tr-0908311, University of Arizona.

Vissers, Y., Mengerink, J. G. M., Schiffelers, R. R. H.,

Serebrenik, A., and Reniers, M. A. (2016). Mainten-

ance of speciﬁcation models in industry using edapt.

In FDL, pages 1–6.

Wachsmuth, G. (2007). Metamodel adaptation and model

co-adaptation. In ECOOP, volume 4609 of LNCS,

pages 600–624. Springer.

APPENDIX

Data: A revision r, and a conﬁguration

Con f =

Result: true iff r fulﬁlls the role of syntactic

deﬁnition and adheres to Con f

1 if ¬(r instanceof MetaModelRevision)

then

2 return false

3 end

4 S

curr

← r.parent

5 if C

then

6 Q ← S

curr

.modi f iedFiles

7 else

8 Q ← S

curr

.prev.allFiles

9 end

10 if C

then

result

← result ∧ ∃

y:TransformationRevision

[

x ∈ input(y) ∧ y ∈ Q ∧

out put(y) ∩ S

curr

.modi f ied f iles 6=

11 else

result

← result ∧ ∃

y:TransformationRevision

[

x ∈ input(y) ∧ y ∈ Q ∧ out put(y) 6=

0∧

out put(y) ∩ S

curr

.modi f ied f iles =

12 end

13 return result

Algorithm 2: Checks if a given Revision is a syntactic

deﬁnition that adheres to a provided conﬁguration.

Data: A revision r, and a conﬁguration

Con f =

Result: true iff r fulﬁlls the role of semantic

mapping

1 if ¬(r instanceof TransformRevision)

then

2 return false

/* Avoid empty domain rule */

3 result ← (inputs(y) 6=

0) ∧ (out puts(y) 6=

4 S

mod

← r.parent.modi f iedFiles

5 if C

then

6 result ← result ∧ (inputs(y) ∩ S

mod

7 else

8 result ← result ∧ (inputs(y) ∩ S

mod

9 end

10 if C

then

11 result ← result ∧ (out puts(y) ∩ S

mod

12 else

13 result ← result ∧ (out puts(y) ∩ S

mod

14 end

15 return result

Algorithm 3: Checks if a given Revision is a semantic

transformation that adheres to a provided conﬁguration.

Data: A revision r, and a conﬁguration

Con f =

Result: true iff r fulﬁlls the role of syntactic

deﬁnition and adheres to Con f

1 if ¬(r instanceof MetaModelRevision)

then

2 return false

3 end

4 S

curr

← r.parent if C

then

5 Q ← S

curr

.modi f iedFiles

6 else

7 Q ← S

curr

.prev.allFiles

8 end

9 if C

then

result ← result ∧ ∃

y:TransformationRevision

[

z ∈ out put(y) ∧ y ∈ Q ∧

input(y) ∩ S

curr

.modi f ied f iles 6=

10 else

result

← result ∧∃

y:TransformationRevision

[

z ∈ input(y) ∧ y ∈ Q ∧ input(y) 6=

0∧

input(y) ∩ S

curr

.modi f ied f iles =

11 end

12 return result

Algorithm 4: Checks if a given Revision is a semantic

domain deﬁnition that adheres to a provided conﬁguration.

Exploring DSL Evolutionary Patterns in Practice - A Study of DSL Evolution in a Large-scale Industrial DSL Repository

453