Limitations of Automating Model Migration in ...

Limitations of Automating Model Migration in Response to Metamodel Adaptation Markus Herrmannsdoerfer and Daniel Ratiu Institut f¨ ur Informatik Technische Universit¨ at M¨ unchen Boltzmannstr. 3, 85748 Garching b. M¨ unchen, Germany {herrmama, ratiu}@in.tum.de

Abstract. In consequence of changing requirements and technological progress, modeling languages are subject to change. When their metamodels are adapted to reflect those changes, existing models might become invalid. Manually migrating the models to the adapted metamodel is tedious. To substantially reduce effort, a number of approaches have been proposed to fully automate model migration. However, the evolution of modeling languages occasionally leads to metamodel changes for which the migration of models inherently cannot be fully automated. In these cases, the migration of models requires information which is not available in the model. If such changes are ignored or circumvented, they may lead to language erosion. In this paper, we formally characterize metamodel adaptations in terms of the effort needed for model migration. We focus on the problem of metamodel changes that prevent the automatic migration of models. We outline different possibilities to systematically cope with these kinds of metamodel changes.

1

Introduction

Even though often neglected, a modeling language is subject to change like any other software artifact [1]. This holds for both general-purpose and domainspecific modeling languages. For instance, UML—a general purpose modeling language—already has a rich evolution history, although it is relatively young. Domain-specific modeling languages—like e. g. AUTOSAR for the specification of automotive software architectures—are even more prone to change, as they have to be adapted whenever their domain changes due to technological progress or evolving requirements. A modeling language is evolved by adapting its metamodel to satisfy new requirements. Due to metamodel adaptation, existing models may no longer conform to the adapted metamodel. These models have to be migrated so that they can be used with the new version of the modeling language. Throughout the paper, the combination of metamodel adaptation and reconciling model migration is referred to as coupled evolution. Manually migrating existing models to the adapted metamodel is tedious and error-prone. Adequate tool support is thus required to reduce the effort for model migration.

To determine requirements for adequate tool support, we reverse engineered the coupled evolution of a number of real-world modeling languages [2, 3]. More specifically, we classified the performed metamodel changes according to the automatability of the associated model migration. Metamodel-only changes do not require the migration of models, whereas coupled changes do. Metamodelindependent coupled changes do not depend on a specific metamodel. Metamodelspecific coupled changes are so specific to a certain metamodel that the migration cannot be reused across metamodels. Model-specific coupled changes require information from the modeler during migration, and thus the migration cannot be specified in a model-independent way. As no changes were classified as modelspecific, we decided to ignore them for the first version of our tool called COPE. With adequate tool support at our hands, we started using COPE to forward engineer the coupled evolution of a number of modeling languages. From our experience with adapting several metamodels, we learned that sometimes changes requested by the users of the modeling language require a metamodel adaptation that prevents the automation of the model migration. Using our terminology presented above, we would say that these cases require a model-specific coupled evolution. Implementing such a change would invalidate the existing models, which have to be migrated manually. However, manually migrating a potentially unknown number of models imposes a heavy burden on the language users. Consequently, the language developers are tempted to avoid model-specific coupled evolution by adapting the metamodel in a way that the model migration does not require information from the users. However, not being able to implement such changes limits modeling language evolution, and threatens the simplicity and quality of the metamodel. In this paper, we provide a formal framework to characterize metamodel adaptations in terms of the efforts needed for model migration. We focus on the problem of metamodel changes that prevent the automatic migration of models. We outline different possibilities to systematically cope with these kinds of metamodel changes. Outline. In Sec. 2, we provide a number of examples to distinguish modelspecific coupled changes from other kinds of changes. In Sec. 3, we try to specify these coupled changes using our current tool COPE. Subsequently, we present the formal framework to generally characterize model-specific coupled evolution: we show how to formalize the syntax and semantics of a modeling language in Sec. 4; we formally characterize the evolution of a modeling language in Sec. 5; and finally, we formally define model-specific migration in Sec. 6. In Sec. 7, we outline a number of possible solutions to cope with model-specific coupled evolution. In Sec. 8, we analyze related work with respect to the support for model-specific coupled evolution, and we conclude our paper in Sec. 9.

2

Motivating Example

We choose a simple modeling language to specify I/O automata as our running example. To show different levels of automating a model migration, we present a

Automaton

Automaton

1..* state

1..* state * outgoing 1 target

State name: String effect: Action*

Transition trigger: Event

(a) Original Metamodel Automaton

1..* state State name: String effect: Action*

* outgoing 1 target

State name: String effect: Action*

Transition trigger: Event

(b) Introducing Hierarchical States Automaton

1 initial * outgoing 1 target

1..* state Transition trigger: Event

(c) Introducing Initial States

1 initial

State name: String

* outgoing 1 target

Transition trigger: Event effect: Action*

(d) Moore to Mealy Automata

Fig. 1. Metamodel Adaptation

number of adaptations to the language’s metamodel. We first present the different metamodel adaptation steps, and then discuss reconciling model migrations. Metamodel Adaptation. Fig. 2 depicts the different versions of the metamodel as UML class diagrams. For better overview, metamodel adaptations are highlighted by dashed boxes. Original Metamodel. Fig. 1(a) depicts the original version of the metamodel. An Automaton defines a number of named states. A State has a number of outgoing transitions each of which is activated by a trigger Event. When a Transition is activated, the control transitions to a target state. When the target state is entered, a sequence of Actions is performed as effect. Introducing Hierarchical States. As is depicted in Fig. 1(b), we introduce hierarchical states to our modeling language to be able to structure complex automata. In the metamodel, we thus make Automaton a subclass of State. Now, a State can also be an Automaton which can again be decomposed into a number of states, and so on. Introducing Initial States. As is depicted in Fig. 1(c), we introduce initial states to refine the modeling language. In the metamodel, the mandatory reference initial is introduced to denote the initial state within an automaton. Moore to Mealy Automata. As is depicted in Fig. 1(d), we change the modeling language from a Moore to a Mealy automaton to ease the specification

of effects. In Moore machines, the effect of the automaton only depends on the current state. In contrast, the effect of the automaton depends also on the trigger in Mealy machines. In the metamodel, we thus move the attribute effect from State to Transition. Model Migration. We discuss the model migration for each metamodel adaptation step presented above in the order of decreasing automatibility. Note that this order is slightly different from the temporal order in which the metamodel adaptations were performed. Introducing Hierarchical States. Existing models without hierarchy are not affected by this metamodel adaptation, as they are still valid and have the same meaning. As a consequence, they do not have to be migrated, and the adaptation basically is a conservative extension. Moore to Mealy Automata. As effects are no longer allowed for states, models no longer conform to the adapted metamodel. To migrate these models, the effect of each transition has to be determined based on the states it enters. Note that this model migration can be fully automated by the well-known algorithm to transform Moore to Mealy automata. Introducing Initial States. As the introduced reference initial is mandatory, the model needs to be migrated to add the missing information. However, the initial states cannot be unambiguously inferred from the information already available in the model, and default values cannot be provided either. As a consequence, this model migration cannot be automated, as information is required from the developer of the model during migration. One solution would be to avoid the model-specific change. For example, we could make the new reference initial optional instead of mandatory in order not to invalidate existing models. However, our metamodel would not be as robust as we want it to be, and our tools would have to cope with missing initial states in an ad-hoc manner (each tool can interpret the initial states differently) and this would lead to ambiguities. As a result, this reduces the overall quality and simplicity of the modeling language and makes models fragile. To prevent such language erosion, we need to be able to support model-specific coupled evolution.

3

COPE – Coupled Evolution of Metamodels and Models

COPE is a tool to reduce the effort associated with model migration by incrementally composing the coupled evolution of metamodels and models. COPE is implemented based on the Eclipse Modeling Framework (EMF). Overview of COPE. As is depicted in Figure 2, COPE allows the language developer to record the history of a metamodel. The history basically is a sequence of operations which adapt the metamodel. These operations can be enriched with instructions on how to migrate models in response to metamodel adaptation. As they thus couple metamodel adaptation with model migration, these operations are termed coupled operations. COPE provides two kinds of coupled operations: reusable and custom coupled operations.

Rename

SpecializeSuperType

NewReference

ExtractClass

Instantiation of Reusable Coupled Operations

Metamodel level

Metamodel History

Release 0

Metamodel Adaptation

SpecializeSuperType

NewRefere...

Custom Coupled Operation

Introducing Hierarchical States

Introducing Initial States

Moore To Mealy

Model Migration Old Metamodel

Generation

Model level

conforms To

Old Model

Input

Migrator

Release 1

COPE

Meta-metamodel level

Library of Reusable Coupled Operations

New Metamodel conforms To

Output

New Model

Fig. 2. Overview of COPE.

Metamodel-only and metamodel-independent coupled changes can be reused across metamodels—reducing the effort associated with model migration. Therefore, COPE provides reusable coupled operations which encapsulate metamodel adaptation and model migration in a metamodel-independent way. Reusable coupled operations are organized in a library which can be extended by declarations of new operations. The declaration is made independent of a specific metamodel through parameters, and may provide constraints to restrict the applicability of the operation. The operation SpecializeSuperType—which replaces a super type by one of its subclasses—e. g. can be used to introduce hierarchical states. Metamodel-specific coupled changes are so specific to a certain metamodel that reuse makes no sense. To be able to cover these model migrations, a custom coupled operation can be manually defined by the language developer. In order to do so, the developer has to manually implement a model migration for a recorded metamodel adaptation. The model migration is implemented in a language provided by COPE which is expressive enough to cater for complex model migrations [4]. A custom coupled operation is e. g. necessary to transition from Moore to Mealy automata. Model-specific coupled changes are currently not supported, and hence we use the operation NewReference to introduce the reference initial as a placeholder.

metamodel editor

operation browser

Custom Coupled Operation

migration editor

history

Reusable Coupled Operations

Fig. 3. User Interface of COPE.

A migrator can be generated from the history that allows for the batch migration of models. The migrator simply packages the sequence of coupled operations which can be invoked to automatically migrate existing models. User Interface of COPE. Fig. 3 shows COPE’s user interface which has been integrated into the existing structural metamodel editor provided by EMF. This metamodel editor has been extended so that it also provides access to the metamodel history. All reusable coupled operations in the library are made available to the language developer through a special view called operation browser. A migration editor with syntax highlighting is provided for the specification of custom coupled operations. The developer can adapt the metamodel by invoking reusable coupled operations through the operation browser. The operation browser allows to set the parameters of a reusable coupled operation based on their type and gives feedback on its applicability based on the constraints. When a reusable coupled operation is executed, its invocation is automatically recorded in the metamodel history. Fig. 3 shows the SpecializeSuperType operation being available in the browser and some reusable coupled operations stored in the history.

In case no reusable coupled operation is available for the change at hand, the language developer can perform a custom coupled operation. First, the metamodel is directly adapted in the metamodel editor, in response to which the changes are automatically recorded in the history. A migration can later be attached to the sequence of metamodel changes. Fig. 3 shows the model migration—implemented in COPE’s language—for the transition from Moore to Mealy automata in the migration editor. The operation browser provides a release button to create a major version of the metamodel. After release, the language developer can initiate the automatic generation of a migrator.

4

Defining Modeling Languages

Before we can characterize language evolution, we have to formally define our understanding of a modeling language. According to [5], a modeling language is specified through its abstract syntax and semantics. Definition 1 (Modeling language). A modeling language L = (M, SD, S) is a triple of abstract syntax M, semantic domain SD and semantic mapping S. The abstract syntax defines the (possibly infinite) set of all models M = {m1 , m2 , . . .} that are syntactically correct. The semantic domain SD specifies the concepts that exist in the universe of discourse, and the semantic mapping S : M → SD interprets a model from M w.r.t. to the semantic domain SD. A model is syntactically valid if it is built from the constructs and fulfills the constraints defined by the metamodel. For the sake of simplicity, we omit the formalization of the relationship between model and metamodel here. Two models m1 , m2 ∈ M are syntactically equivalent if and only if m1 = m2 . Note that, in practice, usually only a small subset Mbuilt ⊂ M of the possible models are actually built. Since the semantics S is a total function, each well-formed model has associated a semantics. Furthermore, we require the notions of semantic equivalence ≡ and refinement 5 on the semantic domain. Two models m1 , m2 ∈ M are semantically equivalent, if the interpretation returns equivalent objects from the semantic domain, i. e. S(m1 ) ≡ S(m2 ). A model m1 ∈ M is a refinement of m2 ∈ M, if the interpretation of model m1 refines the interpretation of model m2 , i. e. S(m1 ) 5 S(m2 ). Example. The abstract syntax of the example modeling language presented in Sec. 2 defines a dialect of I/O automata. The instances of a class in the metamodel can be accessed through a set with its name: e. g. Automaton to access all instances {a1 , a2 , . . .} of the class Automaton. The associations in the metamodel can be followed by functions applied to instances: e. g. state : Automaton → P(State) to access the states of an automaton. Notationally, a.state is the same as state(a).

As semantic domain, we choose the behavior of automata. One possibility to define the behavior of I/O automata is through a function that maps a stream of events onto a stream of actions [6], i. e. SD : Event∗ → P(Action∗ ). Note that this semantic domain allows to specify non-deterministic behavior, as an event stream can lead to a set of action streams. The semantic mapping S : Automaton → SD maps an automaton a ∈ Automaton to its behavior S(a) ∈ SD. We use S(a, es) as a notation for (S(a))(es). Two automata a1 , a2 ∈ Automaton are semantically equivalent if S(a1 , es) = S(a2 , es)—meaning that for all possible event streams es ∈ Event∗ we have the same actions. A possible definition of refinement is the subset relationship on sets of streams: An automaton a1 ∈ Automaton refines another automaton a2 ∈ Automaton if S(a1 , es) ⊆ S(a2 , es) for all possible event streams es ∈ Event∗ —i.e. exhibits less non-determinism. In the following, we use the version number as index to distinguish the classes from different language versions, i. e. Automaton1 to denote the automata conforming to language version 1. Original Metamodel. The behavior of an automaton a ∈ Automaton1 for an event stream es = he1 , e2 , . . .i ∈ Event∗ is defined as the union of the behavior of its states: [

S1 (a, es) =

s.effect ◦ S1 (s, es)

(1)

s∈a.state

The operator ◦ concatenates streams and is automatically lifted to sets of streams. The behavior of a state s ∈ State1 is defined as the union of the behavior of the states to which the control can transition: S1 (s, hei ◦ es) =

[

t.target.effect ◦ S1 (t.target, es)

(2)

t∈activated1 (s,e)

in case there is at least one transition activated by event e ∈ Event, i. e. activated1 (s, e) 6= ∅. Otherwise—in case there is no transition activated—the automaton remains in the same state: S1 (s, hei ◦ es) = S1 (s, es) When there are no more events left to be processed, then of course S1 (s, hi) = {hi}. The set of transitions activated by an event e ∈ Event in a state s ∈ State is the set of outgoing transitions having the event as trigger: activated1 (s, e) = {t ∈ s.outgoing | t.trigger = e}

(3)

Introducing Hierarchical States. To introduce hierarchical states, we have to adapt formula (3) to also take into account the transitions inherited from parent states: activated2 (s, e) =

[ p∈s.parent∗

activated1 (p, e)

where parent : State2 → Automaton2 is the opposite of the association state, and ∗ is the transitive closure. The other formulas do not need to be adapted and thus stay the same. Note that the formulas are polymorphic, i. e. S2 (s, es) in formula (2) is automatically redirected to formula (1), in case s ∈ Automaton2 . Introducing Initial States. To introduce initial states, we only have to adapt formula (1) to take the initial state of an automaton into account: S3 (a, es) = a.initial.effect ◦ S3 (a.initial, es) In this change, we have refined the behavior of an automaton by removing possible executions. In other words, we removed non-determinism generated by the choice between more initial states. The developer of the model has to decide which executions to remove by choosing an initial state for each automaton. Moore to Mealy Automata. To transition from Moore to Mealy automata, we only have to adapt formulas (1) and (2) to consider the effect of the transition instead of the effect of its target state: S4 (a, es) = S4 (a.initial, es) [ S4 (s, hei ◦ es) = t.effect ◦ S4 (t.target, es) t∈activated4 (s,e)

5

Characterizing Language Evolution

A language evolution is usually reflected by the adaptation of the metamodel and/or by the adaptation of the semantics. In the following, we talk about two language versions L1 = (M1 , SD1 , S1 ) and L2 = (M2 , SD2 , S2 ), where L1 evolved to L2 . For simplicity’s sake, we assume that the semantic domain remains the same during language evolution, i. e. SD1 = SD2 . Consequently, only the abstract syntax and the semantic mapping change from one language version L1 = (M1 , SD, S1 ) to the next language version L2 = (M2 , SD, S2 ). Definition 2 (Conservative extension). L2 is a conservative extension of L1 if and only if M1 ⊂ M2 and S1 (m) ≡ S2 (m) for all m ∈ M1 . A conservative extension thus does not syntactically invalidate existing models and preserves their meaning. An extension can occur when new constructs are added to the metamodel, when existing constructs are extended, or when constraints are removed or weakened. Definition 3 (Restriction). L2 is a restriction of L1 if and only if M2 ⊂ M1 . A restriction syntactically invalidates a number of models, namely M1 \M2 , which have to be migrated. A restriction can occur when constructs are removed from the metamodel, when existing constructs are restricted, or when constraints are added or strengthened. In general, a new version of the language exhibits both restrictions and extensions which we call variations.

Definition 4 (Variation). L2 is a variation of L1 if and if only M2 \ M1 6= ∅ ∧ M1 \ M2 6= ∅. A variation invalidates outdated models, namely Mo = M1 \M2 , which have to be migrated. In practice, only those outdated models need to be migrated that are actually built, i. e. Mbuilt ∩ Mo . Example. Introducing Hierarchical States. The introduction of hierarchical states to the modeling language as depicted in Fig. 1(b) is an example of a conservative extension. Existing flat automata are still valid with respect to the adapted metamodel and have the same meaning. The meaning of all models is preserved, since for flat automata, the adapted semantics does not change the transitions activated in a state. The inverse evolution—from Fig. 1(b) back to Fig. 1(a)—is a restriction, as automata with hierarchy are no longer valid and thus have to be flattened. Moore to Mealy Automata. The transition from Moore to Mealy automata is a variation. All models that define effects for their states are no longer valid, but we now allow new models that define effects for their transitions. We have to find a mapping that migrates the outdated models to the new language version and preserves the semantics of the models. Introducing Initial States. The introduction of initial states is a variation, since it allows to build new automata with initial states and at the same time requires old automata to define initial states.

6

Characterizing Model-specific Migration

As we have seen before, models may have to be migrated to preserve their meaning in response to language evolution. A model migration is defined by a migration function which maps the models from the old language L1 to models of the new language L2 . Definition 5 (Migration function). A migration function is a function µ : M1 → M2 which maps each model m ∈ M1 to a model µ(m) ∈ M2 . Typically, we require that the migration function preserves the semantics of all models. Otherwise, information is lost during migration which needs to be avoided. Definition 6 (Language refactoring). A language refactoring is a change to the language which allows to build a migration function µ that preserves the semantics of the models, i. e. S2 (µ(m)) ≡ S1 (m) for all m ∈ M1 . However, there are cases in which the language is changed in a way that we cannot build a semantics-preserving migration. Definition 7 (Language refinement). A language refinement is a change to the language which allows to build a migration function µ that refines the semantics of the models, i. e. S2 (µ(m)) 5 S1 (m) for all m ∈ M1 .

When a language is refined, often the migration cannot be performed without information which is not available in the original model as shown below. Definition 8 (Model-specific migration). Let E : M1 → P(M2 ) with E(m1 ) = {m2 ∈ M2 | S2 (m2 ) 5 S1 (m1 )} be the models from M2 that refine a model from M1 after language refinement. A migration µ is model-specific if and only if a model m1 ∈ M1 exists for which |E(m1 )| > 1. A migration has to be model-specific, if several models in M2 exist which semantically refine a model in M1 . In this case, additional information is necessary during migration to choose one of these semantically equivalent models. The set for which the migration has to be model-specific is Mms = {m1 ∈ M1 | |E(m1 )| > 1}. Again, only those models are problematic which are built and require model-specific migration, i. e. Mbuilt ∩ Mms . A migration is thus model-independent if |E(m1 )| = 1 for all m1 ∈ M1 . Example. Moore to Mealy Automata. The transition from Moore to Mealy automata as depicted in Fig. 1(d) is a language refactoring. The transition requires a migration function that maps all models with effects in states to models with effects in transitions. To preserve the meaning of all models, the migration function has to determine the effect of a transition based on the state it enters. For a transition t ∈ T ransition3 which is mapped to t0 ∈ T ransition4 by the function µ34 to migrate models from language version 3 to 4 (i.e. t0 = µ34 (t)), t0 .effect = effect(t.target) is fulfilled with: ( s.effect ◦ effect(s.initial), if s ∈ Automaton3 effect(s) = s.effect, if s ∈ State3 Again, the indices denote the language version of the class. When a transition enters an automaton, we do not only have to take its effect into account but also the effect of its initial state. Note that this may have to be applied recursively, as the initial state may again be an automaton, and so on. Using the definition of the semantics, we can easily prove that this migration function preserves the meaning of all models. No additional information is required during migration, and we can thus specify an algorithm that automatically performs the migration. The implemented algorithm is displayed in the migration editor in Fig. 3. Introducing Initial States. The introduction of mandatory initial states as is depicted in Fig. 1(c) is a language refinement. A model migration µ23 from language version 2 to 3 cannot always preserve the semantics, but has to refine it (a0 = µ23 (a)): [ S3 (a0 , es) = S3 (a0 .initial, es) ⊆ S2 (s, es) = S2 (a, es) s∈a.state

As a consequence, a number of models with different choices for initial states are possible refinements for each model without initial states. Model-specific information is required to choose the one that is intended by the developer of the model.

7

Coping with Model-specific Migration

We outline a number of possible solutions to cope with model-specific coupled evolution. The solutions take advantage of particular situations which are however encountered very often in practice. Effort analysis. In practice, only a small subset of all possible models M are actually built. Only the existing models need to be migrated. In many practical situations (e. g. for languages developed only for use inside an organization), the language developers and users are quite close to each other. In these situations, it is often the case that the entire set of the existing models is known to the language developers. For instance, whenever the language is used only in-house, all models are contained in a central repository. In case when all models are known, language developers can make informed language improvements also with respect to the effort needed for model migration. Based on the existing models, they can assess the manual migration effort required after metamodel adaptation. For instance, the effort needed to introduce initial states is proportional to the number of automata in the existing models, as an initial state has to be chosen for each automaton. They can decide whether a language improvement is worth making given the amount of manual work necessary to migrate the existent models. However, in a lot of cases, language developers and users are decoupled which makes this approach infeasible. Interactive migration. One possibility to support model-specific coupled evolution is to provide user interaction during migration. The migration algorithm automatically migrates the model as far as possible, and whenever it needs supplementary information, it asks the language user to provide the missing information. It can also suggest a number of alternatives from which the language user has to choose. We have extended COPE’s language to implement a model migration with a primitive to trigger such an interaction during migration. The following snippet shows the use of this primitive in an interactive coupled operation that introduces initial states in the language: // metamodel adaptation newReference(Automaton, "initial", State, 1, 1, !CONTAINMENT) // model migration for(a in Automaton.allInstances) { a.initial = choose(a, a.state, "Choose initial state") }

The metamodel adaptation creates the new reference initial which is mandatory (lower bound 1), single-valued (upper bound 1) and not a composition (not containment). During model migration, the developer of the model has to choose an initial state for each automaton. The primitive choose takes three parameters as input—namely the context element, the values to choose from and a message, and returns the chosen value.

Fig. 4. COPE’s User interface for interactive coupled operations

Figure 4 shows the dialog that is opened during model migration to let the language user make a choice. The dialog shows the current state of the model (selecting the context element), the list of values to choose from, as well as the message. The developer of the model is required to choose a value from the list to determine the initial state within an automaton. Implicit information. Many times, the language users employ different conventions (e. g. naming conventions) to capture more information than is made explicit through the metamodel. In these cases, the language user can incorporate implicit information to help automate the migration. For example, language users might have already named all initial states with a prefix ”I”, before the initial states were explicitly introduced in the metamodel. They can then refine the migration in a way that for each automaton, it automatically chooses the marked sub state. We thus plan to introduce a means to allow the language user to upfront establish certain choices introduced by the language developer.

8

Related Work

Current approaches to reduce the effort for model migration focus on fully automating the model migration. They thus do not address model-specific coupled evolution which can inherently not be fully automated. We believe that the current language evolution approaches do not support model-specific migration, because the problem is not completely understood yet. With this paper, we thus aimed to characterize the problem and outlined possible solutions. Related work on model migration can be subdivided into two kinds of approaches: differencebased and operation-based.

Difference-based approaches allow language developers to synthesize a model migration based on the difference between two metamodel versions. Sprinkle et al. introduce a visual graph-transformation-based language which requires to specify the model migration only for the metamodel difference [7]. However, this language does not provide constructs to cater for model-specific migrations. The following approaches further automate model migration by automatically deriving it from the difference between two metamodel versions. Gruschko et al. classify primitive metamodel changes into non-breaking, breaking resolvable and unresolvable changes [8, 9]. Based on this classification, they propose to automatically derive a migration for non-breaking and resolvable changes. Cichetti et al. go even one step further and try to detect composite changes like e. g. extract class in the difference between metamodel versions [10, 11]. Garces et al. refine this approach, present a prototype and demonstrate its applicability in two case studies [12]. However, the derivation approaches currently are not able to detect model-specific migrations in the metamodel difference. Operation-based approaches allow language developers to incrementally transform the metamodel by means of coupled operations which also encapsulate the corresponding model migration. Although they are not as automated as difference-based approaches, they allow to capture the intended model migration already when adapting the metamodel. H¨oßler and Soden present a number of reusable coupled operations which automate metamodel adaptation as well as model migration [13]. Wachsmuth adopts ideas from grammar adaptation and proposes a classification of metamodel changes based on instance preservation properties [14]. Based on these preservation properties, the author defines a library of reusable coupled operations. In [3, 4] we generalize these approaches by a language which allows to specify arbitrary new reusable coupled operations. Moreover, this language can be used to attach a custom migration to a metamodel adaptation, which cannot be covered by reusable coupled operations. We demonstrate the usefulness of this approach by presenting the coupled evolution of two real-life metamodels. However, all of these approaches do not provide coupled operations which support model-specific migrations. In this paper, we thus extended our language for expressing coupled operations with a choice construct that allows the user to guide the migration.

9

Conclusion

Modeling languages evolve over time, and thereby their metamodels need to be adapted. To reduce the effort for language evolution, the resulting migration of models needs to be automated. However, some metamodel changes require information during migration which is not available in the model. Consequently, these metamodel changes inherently prevent the automatic migration of models. In this paper, we presented an example of such model-specific changes and formally characterized them. Moreover, we presented a number of techniques to cope with model-specific migrations. With these techniques, language developers

can make informed decisions about the effort needed for manual migration, and partially automate the manual migration by means of adequate tool support. As a consequence, language erosion can be prevented which can result from avoiding model-specific changes. It remains to be investigated how much a language suffers from systematically avoiding model-specific changes. Moreover, we are interested in how often model-specific changes are actually required in practice. Acknowledgments. This work was partially funded by the German Federal Ministry of Education and Research (BMBF), grant “SPES2020, 01IS08045A”.

References 1. Favre, J.M.: Languages evolve too! changing the software time scale. In: 8th International Workshop on Principles of Software Evolution (IWPSE), IEEE Computer Society (2005) 33–44 2. Herrmannsdoerfer, M., Benz, S., Juergens, E.: Automatability of Coupled Evolution of Metamodels and Models in Practice. In: MODELS 2008. Volume 5301 of LNCS., Springer (2008) 645–659 3. Herrmannsdoerfer, M., Benz, S., Juergens, E.: COPE - Automating Coupled Evolution of Metamodels and Models. In: ECOOP ’09. Volume 5653 of LNCS., Springer (2009) 52–76 4. Herrmannsdoerfer, M., Benz, S., Juergens, E.: COPE: A Language for the Coupled Evolution of Metamodels and Models. In: 1st International Workshop on Model Co-Evolution and Consistency Management (MCCM). (2008) 5. Harel, D., Rumpe, B.: Meaningful modeling: what’s the semantics of ”semantics”? Computer 37(10) (Oct. 2004) 64–72 6. Rumpe, B.: A note on semantics (with an emphasis on UML). In: 2nd ECOOP Workshop on Precise Behavioral Semantics. (1998) 7. Sprinkle, J., Karsai, G.: A domain-specific visual language for domain model evolution. Journal of Visual Languages and Computing 15 (2004) 291–307 8. Becker, S., Gruschko, B., Goldschmidt, T., Koziolek, H.: A Process Model and Classification Scheme for Semi-Automatic Meta-Model Evolution. In: 1st Workshop MDD, SOA und IT-Management (MSI), GI, GiTO-Verlag (2007) 35–46 9. Gruschko, B., Kolovos, D., Paige, R.: Towards synchronizing models with evolving metamodels. In: International Workshop on Model-Driven Software Evolution (MoDSE). (2007) 10. Cicchetti, A., Ruscio, D.D., Eramo, R., Pierantonio, A.: Automating co-evolution in model-driven engineering. In Ceballos, S., ed.: 12th International Enterprise Distributed Object Computing Conference (EDOC), IEEE Computer Society (2008) 11. Cicchetti, A., Ruscio, D.D., Pierantonio, A.: Managing dependent changes in coupled evolution. In: ICMT. Volume 5563 of LNCS., Springer (2009) 35–51 12. Garc´es, K., Jouault, F., Cointe, P., B´ezivin, J.: Managing model adaptation by precise detection of metamodel changes. In: ECMDA-FA. Volume 5562 of LNCS., Springer (2009) 34–49 13. H¨ oßler, J., Soden, M., Eichler, H.: Coevolution of Models, Metamodels and Transformations. In: Models and Human Reasoning. Wissenschaft und Technik Verlag, Berlin (2005) 129–154 14. Wachsmuth, G.: Metamodel adaptation and model co-adaptation. In: ECOOP. Volume 4609 of LNCS., Springer (2007) 600–624