Metamodel co-evolution with related model-driven engineering artifacts : a multi-objective search framework

(1)

(2)

(3)

Université de Montréal

Metamodel Co-Evolution with Related Model-Driven

Engineering Artifacts: A Multi-Objective Search Framework

par

Wael Kessentini

Département d’informatique et de recherche opérationnelle Faculté des arts et des sciences

Thèse présentée à la Faculté des études supérieures et postdoctorales en vue de l’obtention du grade de

Philosophiæ Doctor (Ph.D.) en Informatique

Aôut, 2018

c

(4)

(5)

Sommaire

Les produits logiciels sont, en général, évolués en introduisant des changements continus. Les tâches d’évolution et de maintenance sont fastidieuses et longues. Évidemment, il y a un besoin pour trouver de meilleures façons de faire évoluer les systèmes de logiciels. De la même manière que le code source, la conception est amenée à évoluer au fil du temps, en raison des changements des exigences et des contraintes techniques.

Dans le développement dirigée par les modèles, l’évolution des métamodèles peut briser les relations avec les artefacts dépendants tels que les modèles, les règles de transformation et les contraintes OCL. Alors que plusieurs études de coévolution sont proposées, la plupart d’entre elles fournissent un support manuel ou semi-automatisé basé sur des modèles prédéfinis de scé-narios d’évolution. En plus d’être prédéfinis, ces modèles sont spécifiques à l’artefact à coévoluer avec le métamodèle. L’objectif principal de notre recherche est de proposer un cadre de recherche générique qui automatise la dérivation de stratégies de coévolution sans utiliser de modèles prédéfi-nis pour des changements de métamodèles ou des types d’artefacts spécifiques. Pour qu’un artefact co-évolue, le but est de produire une nouvelle version conforme à la nouvelle version du métamod-èle. À cette fin, nous considérons la coévolution comme un problème d’optimisation multi-objectif. La recherche des solutions est guidée par trois objectifs, qui visent à minimiser la violation de la structure du métamodèle révisé, le nombre de modifications appliquées à l’artefact initial et la perte d’informations. Ensuite, le cadre recommande un sous-ensemble approprié de solutions de coévo-lution, avec la possibilité d’intégrer l’utilisateur dans la boucle pour fournir des commentaires et mettre à jour les modifications recommandées.

Nous avons validé notre cadre générique en utilisant trois cas de coévolution de métamod-èles, des modmétamod-èles, des règles de transformation et des contraintes OCL, sur des ensembles de données réelles. Les résultats de l’évaluation montrent que notre approche est efficace en termes d’exactitude, et d’utilité par rapport aux approches de coévolution les plus récentes.

(6)

Mots clés: Méta-heuristiques, Evolution des logiciels, Ingénierie dirigée par les modèles, Optimisation multi-objectif.

(7)

Summary

Successful software products are evolved by introducing continuous changes at different levels. Thus, software industry is actively recruiting software engineers, not to create new software sys-tems, but to evolve and maintain existing ones. Such evolution and maintenance tasks are tedious and time consuming. Thus, there is an urgent need to find better ways to evolve software systems and consequently, improve developers’ productivity. Like the source code, the design is subject to evolution due to changing requirements and technological constraints. Model-Driven Software Evolution is concerned with the changes related to the design of software systems, from initial development to maintenance.

In model driven development, the evolution of metamodels may break the relationships to dependent artifacts like models, transformation rules and OCL constraints. While several co-evolution studies are proposed, most of them are providing either a manual or semi-automated support based on pre-defined templates of evolution scenarios. In addition to be pre-defined, these templates are specific to the artifact to co-evolve with the metamodel. The main objective of our research is to propose a generic search-based framework for the automated recommendation of co-evolution strategies without using pre-defined templates for specific metamodel changes or artifact types. For an artifact to co-evolve, the goal is to produce a new version that conforms to the new version of the metamodel. To this end, we view the co-evolution as a multi-objective optimiza-tion problem, and guide the search for soluoptimiza-tions by three objectives, which aims at minimizing the violation of the structure of the revised metamodel, the number of changes applied to the initial artifact, and the loss of information. Then, the framework is able to recommend an appropriate subset of co-evolution solutions, with the possibility of integrating the user in the loop to provide feedback and update the recommended changes.

We validated our generic framework using three metamodel co-evolution cases, models, trans-formation rules, and OCL constraints, on sets of real-world data. The evaluation results show that

(8)

our approach is effective in terms of correctness and usefulness as compared to the state-of-the-art co-evolution approaches.

Keywords: Search-based Software Engineering, Software evolution, Model Driven Engi-neering, Multi-Objective Optimization.

(9)

List of tables

2.1 Comparison of model co-evolution approaches. . . 20

2.2 Comparison of transformation co-evolution approaches. . . 23

2.3 Comparison of OCL constraints co-evolution approaches. . . 24

4.1 Model edit operations. . . 38

4.2 Statistics related to the collected data of the investigated cases. . . 47

6.1 Selected ATL Case Studies. . . 84

6.2 Statistical tests summary. A “+” symbol at the ith _{position means that the evaluation} metric value of algorithm A is statistically different from algorithm B on CSi. A “-” symbol at the ith_{position means the opposite. . . 89}

7.1 Statistical comparison of results between random search and our approach on three metamodel co-evolution scenarios. . . 104

(16)

(17)

List of figures

2.1 Metamodel excerpts of UML class diagrams and UML object diagrams. . . 8

2.2 Metamodel Evolution/Transformation Co-Evolution Context: (a) Model Transformation Pattern, (b) Source Metamodel Evolution/Transformation Co-Evolution, and (c) Target Metamodel Evolution/Transformation Co-Evolution; (b) and (c) may occur in combination. . . 9

2.3 Metamodel–OCL co-evolution. . . 10

2.4 NSGA-II selection mechanism for a two-objective problem. . . 14

3.1 MDE Artifacts Co-Evolution Overview. . . 28

3.2 Evolution and Co-Evolution Scenario in MDE Adapted from [1]. . . 28

3.3 MDE Artifacts Co-Evolution Overview. . . 29

3.4 Solution representation. . . 30

3.5 Variation operators. . . 31

4.1 Example metamodel evolution. . . 34

4.2 Example model co-evolutions. . . 35

4.3 Solution representation. . . 39

4.4 MOPSO adaptation. . . 42

4.5 Average precision results of NSGA-II, MOPSO, Kessentini et al. [2], GA, and Random Search on 30 runs. . . 51

4.6 Average recall results of NSGA-II, MOPSO, Kessentini et al. [2], GA, and Random Search on 30 runs. . . 52

(18)

4.7 Average MC results of NSGA-II, MOPSO, Kessentini et al. [2], GA, and Random

Search on 30 runs. . . 53

4.8 Average execution time of NSGA-II, Kessentini et al. [2], GA, and Random Search. . . 54

4.9 Impact of the size of models on the performance of NSGA-II. . . 55

4.10 Average number of edit operation results of NSGA-II, MOPSO, Kessentini et al. [2], GA, and Random Search on 30 runs. . . 56

4.11 Average precision, recall and manual correctness of NSGA-II and Wimmer et al. [3] on UML State Machine metamodel evolution.. . . 59

5.1 High-level overview of the proposed interactive co-evolution approach. . . 64

5.2 A simplified example of a Pareto front of co-evolution solutions generated by our tool. 67 5.3 An illustration of the interaction features (add, modify, remove and evaluate) with the user for a generated co-evolution solution. . . 68

5.4 An example of an interaction feature to modify a Move Slot operation. . . 69

5.5 Median correctness results of the interactive and the automated multi-objective [2] approaches on the different subjects. . . 72

5.6 Median number of interactions by the participants to find the best co-evolution solution on the different models. . . 73

5.7 Median correctness results of the interactive and the automated deterministic [3] approaches on the different UML class diagrams. . . 74

5.8 Qualitative example: Initial metamodel (above) and revised metamodel (below). . . 75

5.9 Qualitative example: Initial model (above) and revised model (below). . . 76

5.10 Median time in minutes spent by the participants to find the best co-evolution solution on the GMF subjects. . . 77

6.1 Motivating Example: Metamodel Evolution . . . 80

6.2 Solution encoding. . . 82

(19)

6.4 Mean number of fixed rules (FR) based on 30 runs for NSGA-II, RS and GA. . . 87

6.5 Mean execution time (T) based on 30 runs for NSGA-II, RS and GA. . . 88

6.6 Number of edit operations (Nop) mean values of NSGA-II, GA, and RS over 30 independent runs. . . 89

7.1 Version 1 . . . 94

7.2 Version 2 . . . 94

7.3 Evolution of the State Machine metamodel. . . 94

7.4 Abstract syntax tree of the constraint C1in Section 7.2 . . . 96

7.5 Example application of the “Indirection Insertion” mutation operator . . . 99

7.6 Clustering of solutions: Solutions in the Pareto front are grouped by relative syntactic distance between each other’s . . . 101

7.7 Family . . . 105

7.8 State Machine . . . 105

7.9 Project Management . . . 105

7.10 Distribution of the accuracy of solutions: number of constraints found in each execution. X-axis shows the number of solutions, Y-axis the number of valid constraints for each solution . . . 105

7.11 Family . . . 107

7.12 State Machine . . . 107

7.13 Project Management . . . 107

7.14 Comparison of the effectiveness of the two recommendation strategies. The X-axis shows the number of recommendations presented to the user. The Y-axis shows the number of correct solutions in the recommendation. . . 107

(20)

(21)

Acronyms and Abbreviations

ATL ATLAS Transformation Language

DSML Domain-Specific Modeling Language

EMF Eclipse Modeling Framework

HOT Higher-Order Transformation

GA Genetic Algorithm

GMF Graphical Modeling Framework

MCL Model Change Language

MDE Model-Driven Engineering

MOF Meta-Object Facility

MOP Multi-Objective Optimization Problem

MOPSO Multi-Objective Particle Swarm Optimization

NSGA-II Non Sorting Genetic Algorithm II

OCL Object Constraint Language

QVT Query/View/Transformation Language

RS Random Search

SBSE Search-Based Software Engineering

(22)

(23)

Acknowledgments

I express my greatest thanks to the Tunisian Ministry of Higher Education and Scientific Re-search, and the University of Montreal for co-funding this research work through many excellence scholarships.

I express my greatest thanks to my supervisor Prof. Houari Sahraoui for his guidance during my Ph.D. within the GEODES Software Engineering Laboratory. I appreciate all his contributions of time, ideas and feedback that encouraged me to succeed. I am proud to be one of his students.

I express my greatest thanks to my co-supervisor Prof. Manuel Wimmer for his unending support. His explanations were easy to grasp and his feedback was highly appreciated.

I express my deep gratitude and thanks to my family who never stopped believing in me. A spe-cial thank, in the language they read, to my parents Lassâad and Monia, Merci Pour l’incontestable soutien, le respect et toute l’affection qu’ils ont témoignés à mon égard. Qu’ils puissent trouver dans ce modeste travail la récompense de leurs énormes sacrifices.

(24)

(25)

Chapter 1 Introduction

1.1. Research Context

In software engineering, the evolution of software artifacts is multifaceted. Diverse artifacts such as programs, data, requirements, and documentation may evolve due to several reasons such as changes in the requirements, new hardware, fixing bugs, etc. Thus, the complexity of software development is facing a continuous growth [4]. To tackle the increasing of the complexity, a recent approach has been adopted called Model-Driven Engineering (MDE). MDE raises the abstraction level of software development from code to models, so the developer concerns on the problem domain rather than on the underlying technologies by creating, maintaining, and manipulating models, i.e., abstractions of a real phenomenon [5]. As the model is an abstraction of the system in the reality, rules and constraints for building the model have to be properly stated through a corresponding language definition: a metamodel is a key artifact that describes the structure and semantics constraints of models [6].

Evolution occurs also at metamodel level and it might have an impact on the whole modelling system thus it can break the conformance relationships between artifacts created in the initial ver-sion of the language and the evolved metamodel. In order to bring the modelling system in con-sistent state, i.e, a system with valid dependency relationships between metamodels and related artifacts, these conformance relations have to be repaired, i.e migrated to their new version. This is called the co-evolution of artifacts and metamodels.

Unfortunately, few techniques are available to support the evolution of models and design in general. Our research work addresses the automation of the adaptation of these models, model transformations and constraints during the software evolution as described in the next section.

(26)

1.2. Problem Statement

In MDE, evolution is inevitable during the whole life cycle of complex software-intensive systems and more importantly of entire product families. Not only instance models, but also entire modelling languages are subject to change [7]. When manually performed, the adaptation is error-prone and can give place to inconsistencies between the metamodel and the related artifacts. Hence inconsistencies can possibly lead to irremediable information erosion [8].

There is a substantial amount of research work focusing on the automation of artifact migration to make them conform to the evolved metamodel. There are many open issues that need to be addressed when defining a migration strategy.

Problem 1. Most of the automated co-evolution studies focus on the detection of the differ-ences between the metamodel versions. Then they use predefined rules for each type of change to update the initial artifact to revised ones which conform to the new metamodel. However, the migration rules have to be defined manually for the change types which are detectable on the meta-model level and they are difficult to generalize for all potential changes of metameta-models. The defi-nition of these rules may require a high level of expertise/knowledge regarding both the previous and new versions of the metamodel. In addition, the detection of changes at the metamodel level is complex and time consuming especially when the metamodels were extensively modified [9]. For example, when one attribute is removed and another is added, this can be interpreted as a rename, or a deletion and addition of independent attributes. The combinatory of the possibilities increases dramatically when multiple changes are performed at the same time.

Problem 2. Existing approaches require that metamodel changes should be an input for the co-evolution algorithms. It is difficult to generalize the co-evolution scenarios for each metamodel change based on a pre-defined template. Thus, existing work provide exactly one solution for a metamodel/artifact co-evolution scenario, while other solutions might be possible and may be more suitable in a particular context and the sequence of introduced metamodel changes.

Problem 3. Very few studies in model-driven engineering addressed the problem of co-evolution and there is a lack of tools to support the automation of this process. Due to these challenges, modelers are, sometimes, reluctant to migrate their artifacts to a new metamodel ver-sion, considering the high effort required to adapt these artifacts.

(27)

Problem 4. Existing approaches require the user to explicitly encode his co-evolution prefer-ences up front and produce a single solution. However, specifying a set of explicit preferprefer-ences in advance might not be possible without an idea about the shape of expected results.

1.3. Proposed Research Contributions

To address the above mentioned problems, we propose the following solutions which are orga-nized into three principal contributions.

Contribution 1: Model Co-evolution

We proposed an approach that tackles the co-evolution of models without the need of com-puting differences between metamodel versions. In particular, we view the metamodel/model co-evolution as a multi-objective optimization process that searches for a good combination of edit operations, at the model level, by minimizing (i) the number of constraints the revised model vio-lates with respect to the new metamodel version, (ii) the number of changes applied on the initial model to produce the revised model, and (iii) the structural and semantics deviation (dissimilar-ities) between the initial and revised models. These three objectives are the heuristics that allow us to approximate the evolution of models without an explicit knowledge on the differences be-tween the two metamodel versions and the rules to apply to migrate the models. The first objective ensures that the modified model conforms to the new metamodel. As changes in the metamodel are generally limited to a small subset of its elements, the second objective is used to reflect this property at the model level and to prevent from deviating a lot from the initial design. Finally, the third objective allows us to limit the loss of information when migrating a model.

We have also provided an interactive support for the metamode/model co-evolution where the user can provide feedback for the recommended changes and modify some of them especially for co-evolution scenarios that are hard to automate.

Contribution 2: Transformation Co-evolution

To revise transformation rules when metamodels evolve, we leverage the use of search-based software engineering algorithms [10] to deal with the large search space of possible co-evolution solutions to repair the rules based on three main criteria: maximizing the coverage of metamodel changes and minimizing the number of static errors in the transformation and the number of ap-plied changes to the transformation. In particular, we focus on the automated co-evolution of transformations expressed in ATL [11].

(28)

Contribution 3: OCL Constraints Co-evolutionIn this work, we propose a novel two-step approach to the co-evolution of metamodels and OCL constraints. First, we use a multi-objective genetic algorithm to explore the space of possible OCL modifications to identify solutions that (a) do not violate the structure of the new version of the metamodel, (b) minimize changes to exist-ing constraints, and (c) minimize loss of information. Then, we recommend an appropriate subset of solutions to the user. We developed two recommendation strategies: using a clustering algo-rithm based on the similarities between the identified solutions, and a ranking based on solutions’ objective values.

All these above contributions are published in several venues :

(1) Wael Kessentini, Houari A. Sahraoui, Manuel Wimmer: Automated metamodel/model co-evolution using a multi-objective optimization approach, in: Modelling Foundations and Applications- European Conference, ECMFA 2016.

(2) Wael Kessentini, Houari A. Sahraoui, Manuel Wimmer: Automated Metamodel/Model Co-Evolution: A Search-Based Approach, in: Information & Software Technology, IST 2018. Accept, in press.

(3) Wael Kessentini, Manuel Wimmer, Houari A. Sahraoui: Integrating the Designer in-the-loop for Metamodel/Model Co-Evolution via Interactive Computational Search, in: In-ternational Conference on Model Driven Engineering Languages and Systems, MODELS 2018.

(4) Wael Kessentini, Houari A. Sahraoui, Manuel Wimmer: Automated Co-Evolution of Meta-models and Transformation Rules: A Based Approach in: Symposium on Search-Based Software Engineering, SSBSE 2018.

(5) Edouard Batot, Wael Kessentini, Houari A. Sahraoui, Michalis Famelis: Heuristic-Based Recommendation for Metamodel - OCL Coevolution, in: International Conference on Model Driven Engineering Languages and Systems, MODELS 2017.

1.4. Road-map

This thesis is organized as follows. Chapter 2 introduces the concepts and terms that will be used along the thesis and provides a review of the literature on previous research related to artifacts coevolution and search-based software engineering. Chapter 3 describes our research objectives and gives an overview of our methodology and how the proposed contributions are

(29)

interconnected. Chapter 4 presents our approach to automate the co-evolution of models after metamodel evolution. Chapter 5 describes our proposal that interactively co-evolve models after metamodel evolution by integrating the user in the loop to adjust the recommendations. Chapter 6 gives an overview about our approach to automate the co-evolution of transformation rules after metamodel evolution. Chapter 7 proposes our contribution to automate the co-evolution of OCL constraints after metamodel evolution. Chapter 8 summarizes the contributions presented in this thesis, underlines its main limitations, its impact on the community and suggests possible future research directions.

(30)

(31)

Chapter 2 State of the Art

2.1. Introduction

In this chapter, we first provide the necessary background related the co-evolution problems in Model-Driven Engineering and search based software engineering. Then, we provide a survey of existing studies.

2.2. Background

2.2.1. Co-evolution of Model-driven Engineering Artifacts

2.2.1.1. Metamodels and models

In MDE, metamodels are the means to specify the abstract syntax of modeling languages [12]. For defining metamodels, there are metamodeling standards (such as MOF, Ecore) available which are mostly based on a core subset of the UML class diagrams, i.e., classes, attributes, and refer-ences.

Theoretically speaking, metamodels give the intentional description of all possible models of a given language. In practice, metamodels are instantiated to produce models which are, in essence, object graphs, i.e., consisting of objects (instances of classes) representing the modeling elements, object slots for storing values (instances of attributes), and links between objects (instances of ref-erences). The object graphs are often represented as UML object diagrams. They have to conform to the respective UML class diagrams. This means, for a model to conform to its metamodel, a set of constraints have to be fulfilled. This set of constraints is normally referred to as conformsTo relationship [13, 14].

(32)

(a) Excerpt of Class Diagram Metamodel 1..1 type 0..* features StructuralFeature lower: Integer upper: Integer Attribute type : {String, Integer, Boolean, …} Reference Object id: String Link Slot value: String NamedElement name: String Class isAbstract: Boolean TypedElement type: String

(b) Excerpt of Object Diagram Metamodel

0..* links 0..* slots 1..1 target 0..* superClasses

Fig. 2.1. Metamodel excerpts of UML class diagrams and UML object diagrams.

To make the conformsTo relationship more concrete, we give an excerpt of the constraints con-cerning objects in models and their relationship to classes in metamodels. Figure 2.1 illustrates the used elements of both languages. Objects are instantiated from classes. Thus, for each re-ferred type of an object in a given model, a corresponding class must exist in the metamodel (name equivalence), and the corresponding class must not be abstract. Such constraints may be formu-lated in the following way, for instance, using the Object Constraint Language (OCL) as shown in Listing 2.1.

Listing 2.1. Type/Object Relationship formalized as OCL Constraint 1 context M!Object

2 inv typeExists: MM!Class.allInstances() ->

3 exists(c|c.name = self.type and not c.isAbstract)

When metamodels evolve, the instantiated models need to be updated to make them conform with the new metamodel version. Thus, a set of change operations has to be applied on the intial model versions to fix the inconsistencies with new metamodel version. This process is called metamodel/model co-evolution.

2.2.1.2. Metamodels and transformation rules

Model transformations are considered as the heart and soul of MDE [15]. Model transforma-tions are not only used for deriving implementatransforma-tions out of models, but also to analyze, compare,

(33)

merge, and improve models [16]. In this context, metamodels contribute important information for model transformations. In particular, they introduce the type systems which can be used in model transformation programs [17]. The elements contained in a metamodel are accessible through model transformation languages and represent essential information needed to formulate trans-formations. Figure 2.2(a) shows the model transformation pattern which illustrates that on the metamodel level the transformation is defined and executed on the model level. Of course, when metamodels change, this has a direct impact on the existing transformations as the referred types and features have to exist in the metamodels. Figures 2.2(b-c) show the cases of source metamodel evolution and target metamodel evolution and the required transformation co-evolutions, respec-tively. Please note that both cases may occur simultaneously. The quest is to find the corresponding delta (i.e., changes) to patch the transformation for a given metamodel delta.

MM_src MM_trg MM’_src MM_src MM_trg MM’_trg T T’ T’ T MM MM MM_src T MM_trg M_src TE M_trg (a) (b) (c)

Fig. 2.2. Metamodel Evolution/Transformation Co-Evolution Context: (a) Model Transformation Pattern, (b) Source Metamodel Evolution/Transformation Co-Evolution, and (c) Target Metamodel Evolution/Transformation Co-Evolution; (b) and (c) may occur in combination.

ATL [11] is a model transformation language which follows the mentioned model transfor-mation pattern. In particular, ATL transfortransfor-mations are rule-based programs which are executed on fixed input models to produce output models. For this process, matches in the input model are computed based on the input patterns of the transformation rules which trigger the creation of output elements based on the output patterns of the transformation rules. Please note that ATL transformations are typed by the source and target metamodels, i.e., the input and output pattern

(34)

a

b

d

Constraints S

Models conforming to M

a'

b'

c'

de'

S ’

rej(M)

Models conforming to

M’

(a)

(b)

acc(M)

e

Possible

constraint

coevolutions

Fig. 2.3. Metamodel–OCL co-evolution.

elements have to refer to existing elements in the involved metamodels. In addition, OCL expres-sions may be employed for filtering definitions to restrict the matches in the input model as well as for computing values with so-called bindings for setting features of the produced output elements.

2.2.1.3. Metamodels and OCL constraints

The metamodel/OCL constraints co-evolution problem can be posed as follows: given a meta-model M and a set S of OCL constraints over M, if M evolves to a new version M′_{, how should} S be evolved to a new version S′_{? Below, we use primes to refer to concepts relevant to the new} version.

Let ins(M) be the –potentially infinite– set of all models that can be instantiated from M. In the following, we call such models “instance models”. Then the set of constraints S partitions ins(M ) into two disjoint subsets: ins(M ) = acc(M ) ⊔ rej(M ), where acc(M ) contains the instance models of M that satisfy the constraints in S (“accepted”) and rej(M) those that do not (“rejected”). We show this schematically in Fig. 2.3(a), where acc(M) = {b,e} and rej(M) = {a,d}.

The set of instance models of the new metamodel version M′ _{can be co-evolved [18] from} ins(M ) to the new set ins(M′_{), shown in Fig. 2.3(b). The problem of co-evolving S can thus be}

(35)

naïvely posed as identifying set of OCL constraints S′ _{that partition ins(M}′_{) such that acc(M}′_{) =} (acc(M ))′ _{and rej(M}′_{) = (rej(M ))}′_{. However, the co-evolution of instance models does not} necessarily produce a one-to-one correspondence between ins(M) and ins(M′_).

Assume for example a toy metamodel M1 containing a single metaclass K1. A developer evolves it to M′

1 by adding a new metaclass, such that M1′ contains the metaclasses K1′,K2′. A model c that only contains instances of the metaclass K′

2conforms to M1′, and is thus in ins(M1′). Should it be placed in acc(M′

1) or rej(M1′)? There is no obvious model in ins(M1) from which to make this decision. Consider also the reverse scenario: the metamodel M1 contains the meta-classes K1,K2 and is evolved by deleting the metaclass K2 such that M1′ only contains the meta-class K′

1. Assume two instance models d and e in ins(M1), where d contains just the elements {k1 : K1,k2d : K2} and e contains just the elements {k1 : K1,k2e: K2}. Assume also that for whatever reason, the OCL constraints S of M1 partition ins(M1) such that d ∈ acc(M1) and e ∈ rej(M1). Since in M1′ the metaclass K2 is deleted, their co-evolved versions coincide to a model de′ _{that simply contains the element k}

1 : K1. Should we co-evolve the constraints to a new set S′_{that place this model in acc(M}′

1) (because d ∈ acc(M1)) or in rej(M1′) (since e ∈ rej(M1))? We illustrate this ambiguity in Fig. 2.3(b), where we show that there exist multiple possible partitions of ins(M′_{). The choice of appropriate partition depends on the intent of the developer} responsible for the evolution of the metamodel. This intent is the developer’s intuition about which of the models that can be instantiated from M′_{should be accepted by the set S}′_{of co-evolved OCL} constraints and which should be rejected (put in acc(M′_{) and rej(M}′_{) respectfully). Unless this} intent is made explicit, the co-evolution of OCL constraints cannot be fully automated. However, making it explicit may not be possible without rewriting the set of OCL constraints S′_{from scratch,} or doing the co-evolution manually. We thus consider the automated co-evolution problem as providing support to the developer in order to identify the set S′ _{of OCL constraints that best} reflects her intent.

2.2.2. Search Based Software Engineering

Most software engineering problems can be formulated as search problems, where the goal is to find optimal or near-optimal solutions [19]. This search is often complex with many com-peting constraints and objectives. The situation can be worse since nowadays successful software is more complex, more critical, and more dynamic leading to an increasing need to automate or

(36)

semi-automate the search process of acceptable solutions for software engineers. As a result, an emerging software engineering area, called Search-Based Software Engineering (SBSE) [20], is rapidly growing. SBSE is a software development practice that focuses on couching software en-gineering problems as optimization problems and utilizing meta-heuristic techniques to discover and automate the search for near optimal solutions to those problems.

The aim of SBSE research is to move software engineering problems from human-based search to machine-based search, using a variety of techniques from the fields of meta-heuristic search, operations research and evolutionary computation paradigms. SBSE has proved to be a widely applicable and successful approach, with many applications right across the full spectrum of ac-tivities in software engineering, from initial requirements, project planning, and cost estimation to regression testing and onward evolution [19].

2.2.2.1. Definitions of search algorithms

Search algorithms work in iterations that are called generations in a search space. The search space is a set of points. The algorithms operates on a collection of points called a population, and for each point of the population is a solution (called individuals), some quality is assigned via a function. It is called fitness function (or objective function in the context of optimization) [21].

*Random Search

Random search is a direct search method as it does not require derivatives to search a continu-ous domain [22]. It randomly individual solutions in any point of the search space, simply calcu-lating and comparing the value of the objective function of each solution in the hope of achieving good performance over all possible choices of random values. If an intelligent algorithm is not even able to clearly outperform pure random search, it is definitely not doing much good for the objective function under consideration [22].

*Mono-objective Genetic Algorithm

Genetic Algorithm (GA) is a powerful search method inspired by natural selection. The basic idea is to make a population of candidates evolve toward the solution of a specific problem.

Each individual of the population is evaluated by a fitness function that determines its ability to solve the target problem. Then, it is subjected to the action of genetic operators such as mutation and crossover. Once applied according to given probabilities, the newly created generation of individuals is evaluated by the fitness function. This process is repeated iteratively, usually for a

(37)

fixed number of generations. The result of the algorithm (the best solution found) is the fittest individual produced along all generations.

*Multi-objective Algorithms

We present some background definitions related to multi-objective optimization then we de-scribe the multi-objective algorithms used in this thesis.

Definition 1 (MOP). A multi-objective optimization problem (MOP) consists in minimizing or maximizing an objective function vector f(x) = [f1(x),f2(x), ...,fM(x)] of M objectives under some constraints. The set of feasible solutions, i.e., those that satisfy the problem constraints, defines the search space Ω. The resolution of a MOP consists in approximating the whole Pareto front.

Definition 2 (Pareto optimality). In the case of a minimization problem, a solution x∗ _{∈ Ω} is Pareto optimal if ∀x ∈ Ω and ∀m ∈ I = {1,...,M} either fm(x) = fm(x∗) or there is at least one m ∈ I such that fm(x) > fm(x∗). In other words, x∗ is Pareto optimal if no feasible solution exists, which would improve some objective without causing a simultaneous worsening in at least another one.

Definition 3 (Pareto dominance). A solution u is said to dominate another solution v (denoted by f(u) f(v)) if and only if f(u) is partially less than f(v), i.e., ∀m ∈ {1,...M} we have fm(u) ≤ fm(v) and ∃m ∈ {1,...,M } where fm(u) < fm(v).

Definition 4 (Pareto optimal set). For a MOP f(x), the Pareto optimal set is P∗ = {x ∈ Ω|¬∃x′ _{∈ Ω,f (x}′_{) f (x)}.}

Definition 5 (Pareto optimal front). For a given MOP f(x) and its Pareto optimal set P∗_the Pareto front is P F∗ _{= {f (x),x ∈ P}∗_}.

Now we present the two multi-objective algorithms used in this thesis.

2.2.2.2. Non Sorting Genetic Algorithm II (NSGA-II)

NSGA-II is among the widely-used algorithms to address real-world problems involving con-flicting objectives [23]. For example, a recent survey on search-based software engineering shows that NSGA-II was successfully applied to problems from different domains such as the next release problem [24], software product lines [25], refactoring [26], etc. It has also been applied to solve other co-evolution problems in recent work [27].

(38)

Fig. 2.4. NSGA-II selection mechanism for a two-objective problem. Algorithm 1Pseudocode for NSGA-II

1: Create an initial population P0 2: Create an offspring population Q0 3: t= 0

4: whilestopping criteria not reached do 5: Rt= Pt∪ Qt 6: F = fast-non-dominated-sort(Rt) 7: Pt+1= ∅ and i = 1 8: while| Pt+1| + | Fi |6 N do 9: Apply crowding-distance-assignment(Fi) 10: Pt+1 = Pt+1∪ Fi 11: i= i + 1 12: end while 13: Sort(Fi,≺ n) 14: Pt+1= Pt+1∪ Fi[N − | Pt+1 |] 15: Qt+1= create-new-pop(Pt+1) 16: t = t+1 17: end while

NSGA-II begins with a generation of an offspring population from an initial set of parent indi-viduals using two change operators of crossover and mutation. Both populations of the offspring and parent have the same size (lines 1-2 of Algorithm 1). Then, the merged population (parents and children) is ranked into several non-dominance layers, called fronts.

As described in Figure 2.4, the non-dominated solutions receive the rank of 1 that represents the first layer, called the Pareto front. After removing solutions of the first layer, the non-dominated solutions form the second layer until no non-dominated solutions remain (lines 5-6 of Algorithm 1).

(39)

After assigning solutions to fronts, each solution is assigned a diversity score, called crowding distance [6], which ranks the solutions inside each front (lines 7-12 of Algorithm 1). This distance aims, later, to favor diverse solutions in terms of objective values. A solution is then characterized by its front and its crowding distance inside the front. To finish an iteration of the evolution, NSGA-II performs the environmental selection to form the parent population for the next generation by picking half of the solutions (lines 13-16 of Algorithm 1). The solutions are included iteratively from the Pareto front to the lowest layers. If half of the population is reached inside a front then the crowding distance is used to discriminate between the solutions. In the example of Figure 2.4, the solutions of the three first layers are included but not all those of the 4th one. Some solutions of the 4th layer are selected based on their crowding distance values. The remaining solutions and those of the subsequent layers (not displayed in the figure) are not considered for the next iteration. In this way, most crowded solutions are the least likely to be selected; thereby emphasizing population diversification. The Pareto ranking encourages convergence towards the near-optimal solution while the crowding ranking emphasizes diversity.

2.2.2.3. Multi-Objective Particle Swarm Optimization

MOPSO is also a well-known multi-objective optimization algorithm, which generalizes the mono-objective particle swarm optimization algorithm. MOPSO generates, first, a population of random solutions, called particles. Each particle in MOPSO flies in the search space with a specific velocity value. The velocity is dynamically updated by the particle own flying experience and those of the other solutions. Each individual is treated as a point in the n-dimensional search space. A particle t has then a position Xt(Xt1, . . . .,Xtn). Its velocity is denoted by Vt(Vt1, . . . .,Vtn). In the single objective PSO, the goal is to find a global best solution. However, when tackling multi-objective problems, the goal is to find a set of solutions that constitute the Pareto Front. So a repository of non-dominated solutions is kept, where all non-dominated solutions found at each iteration are stored. The latter is used by the particles to identify a leader that will guide the search. At each iteration, the position and velocity of each particle are updated according to two best values, pbest and gbest. pbest is the individual best solution that the particle has achieved so far. As we are dealing with many objectives, pbest is randomly selected from the set of particle best non-dominated solution (local Pareto set). gbest is one of the global best solutions chosen randomly from the repository of non-dominated solutions obtained in the swarm until the current

(40)

iteration (global Pareto set). The size of this repository is restricted to a predefined number. If the number of non-dominated solutions is higher that this number, then, the crowding distance is used to eliminate the exceeding solutions. The position and velocity updating equations are as follows. Velocity update:

vi(t + 1) = wvi(t) + r1c1(P_li(t) − xi) + r2c2(Pg(t) − xi) (2.2.1) Position update:

xi(t + 1) = xi(t) + vi(t + 1) (2.2.2)

Where w is the inertia weight, xi the position of a particle i, vi the velocity of i, c1 and c2 are the cognitive and social parameters of the MOPSO, r1 and r2 are random numbers between 0 and 1, Pi

l is the local best position that the particle i has had, which is selected from the local Pareto set and Pg is the global leader of particle i that is taken from the global Pareto set, i.e., the repository for our problem.

Algorithm 2 summarizes the different steps of the MOPSO algorithm. We start by generating a population of particles, where vi=0 for each particle (lines 1-4) and by initializing the memory of each particle (lines 5-7). After that, we evaluate each of the particles in the population (line 10). Then, we store in the memory of each particle PBESTS the best local position achieved so far and we store the positions of the particles that represent non-dominated vectors in the repository of global solutions (lines 11-12). After that, we compute the velocity of each particle (Equation 2.2.1) and we update the position (Equation 2.2.2) (lines 13-14). Once we have the new positions, we evaluate each of the particles in the population and we update the repository. This update consists of inserting all the currently non-dominated locations into the repository. Any dominated loca-tions from the repository are eliminated in the process. Since the size of the repository is limited, whenever it gets full, we apply a secondary criterion for retention: those particles located in less populated areas of objective space are given priority over those lying in highly populated regions (line 16). When the current position of the particle is better than the position contained in its memory, the particle’s position is updated. The criterion to decide what position from memory should be retained is simply to apply Pareto dominance (i.e., if the current position is dominated by the position in memory, then the position in memory is kept; otherwise, the current position replaces the one in memory; if neither of them is dominated by the other, then we select one of them randomly). The algorithms stops when reaching a stopping criteria.

(41)

Algorithm 2Pseudocode for MOPSO

1: fori=0 to Max do ⊲ Initialize the population pop. Max=number of particles 2: Initialize pop[i]

3: v[i]=0

4: end for

5: fori=0 to Max do ⊲ Initialize the memory of each particle

6: PBEST[i]=pop[i]

7: end for

8: whiletermination condition not reached do ⊲ Store the positions of particles that represent non-dominated solutions in the repository REP.

9: for eachparticle in the swarm do 10: Evaluate the particle

11: ifcurrent position of particle is better than position in its memory then Current position is set as the new PBEST

12: end if

13: Update the velocity of the particle according to equation (1) 14: Update the position of the particle according to equation (2)

15: end for

16: Update the contents of repository 17: end while

2.3. Related Work

2.3.1. Model Co-evolution

We discuss in this section approaches explicitly developed to target the metamodel/model co-evolution problem.

Co-evolution has been subject for research since several decades in the database commu-nity [28], and especially, the introduction of object-oriented database systems [29] gave rise to the investigation of this topic. However, metamodel/model co-evolution introduces several additional challenges mostly based on the rich modeling constructs for defining metamodels, and conse-quently, it has to be dealt with the specific conformsTo relationship between models and metamod-els. Thus, in the last decade, several approaches emerged which aim to tackle metamodel/model

(42)

co-evolution from different angles using different techniques (cf. e.g., [7, 30, 9, 31, 32, 33] for an overview). They can be classified in three categories [9]:

• Manual specification approaches in which the migration strategy is encoded manually by the modeler using general purpose programming languages (e.g., Java), or model transfor-mation languages (e.g., ATL, QVT) [34, 35, 36].

• Metamodel matching techniques used to infer a migration strategy from the difference between the original metamodel and the evolved metamodel [37, 7, 4, 38, 39, 40, 3]. • Operator based approaches that record the metamodel changes as a sequence of

co-evolutionary operations used later to infer a complete migration strategy [41, 42, 8, 33, 43]. We give an overview in the following about existing work in these three categories.

2.3.1.1. Manual specification approaches

In one of the early work [44], Sprinkle and Karsai present a domain-specific visual language. The co-evolution of models is tackled by defining patterns which describe the migration steps based on metamodel change types. Rose et al. [35] proposed a textual migration language, using transformation rules. Flock copies model elements of the old version and that are still conform to the new version of the metamodel. Then the user defines migration specification to co-evolve the remaining non-conforming model elements. Narayanan et al. [34] present a Model Change Language (MCL) which represents the differences between the source metamodel and the target metamodel in terms of rules, that helps the user to specify model migrations Another manual specification approach is presented in [36] where a specific transformation language is derived to describe the evolution on the metamodel level and derive a transformation for the model level.

2.3.1.2. Metamodel matching approaches

Matching approaches are based on the matching between the initial and evolved metamodel versions. In [40], the authors proposed an approach compromises five steps for model co-evolution: change detection, changes is detected either by comparing between metamodels or by tracing and recording the changes applied to the old version of the metamodel. The second step is a classifica-tion of the changes in metamodel and their impact in its instances in three categories: non-breaking changes: changes that do not break the models, breaking and resolvable changes that break mod-els, but can be resolved automatically and breaking and non-resolvable: changes that break model

(43)

instances but cannot be resolved automatically. Finally, an appropriate migration algorithm for model migration is determined. For initial model elements for which no transformation rule is found, a default copy transformation rule is applied. This algorithm has been realized in the model migration framework Epsilon Flock [35] and in the framework described in [34].

In [39, 38, 37], the authors compute differences between two metamodel versions to adapt mod-els automatically. This is achieved by transforming the differences into a migration transformation with a so-called higher-order transformation (HOT), i.e., a transformation which takes/produces another transformation as input/output.

In order to avoid copy rules at all, co-evolution approaches which base their solution on in-place transformations (i.e. transformations which are updating an input model to produce the output model) have been proposed. In such approaches (cf. e.g., [42, 3, 37, 45, 46, 47]), the co-evolution rules are specified as in-place transformation rules by using a kind of unified metamodel representing both metamodel versions, and then, to eliminate model elements that are not the part of evolved meta-model anymore, a check out transformation is performed. Thus, the models can be migrated to the new metamodel version without generating completely new models, instead the models are simply rewritten as long as needed.

Additionally, in [48], weaving models are employed to connect the changes of the metamodels with the model elements to provide a basis for reasoning how to perform the migration of the models to the new metamodel versions.

Table 2.1 illustrates a comparison of the different approaches of model co-evolution.

2.3.1.3. Operator based approaches

Other contributions are based on using coupled operations [42, 8, 49, 41]. In [8] Wachsmuth provides a library of co-evolutionary operators for MOF metamodels, each of these operators provides a model migration strategy. In [41], Herrmannsdoerfer provides a tool support for the evolution of Ecore-based metamodels, that records the metamodel changes as a sequence of co-evolutionary operations that are structured in a library and used later to generate a complete migra-tion strategy. But, when no appropriate operator is available, model developer does the migramigra-tion manually, so those approaches depend on the library of reusable coupled operators they provide. To this end, the authors in [42] extended the tool by providing two kinds of coupled operators:

(44)

Approach Detection Strategy Automation Degree Granularity of change

Rose et al. [35] Manual Automatic

-Narayanan et al. [34] Manual Automatic

-Vermolen et al. [36] Manual Automatic

-Gruschko et al. [40] Metamodel matching Automatic Atomic Cicchetti et al. [39] Metamodel matching Automatic Atomic/Composite

Garces et al. [38] Metamodel matching Automatic Atomic/Composite Meyers et al. [37] Metamodel matching Semi-automatic Atomic/Composite Wimmer et al. [3] Metamodel matching Semi-automatic Atomic/Composite Herrmansdoerfer et al. [42] Operator-based Automatic Atomic/Composite Wachsmuth et al. [8] Operator-based Automatic Atomic/Composite

Anguel et al. [43] Metamodel matching/operator-based Semi-automatic Atomic Schoenboeck et al. [14] - Semi-automatic Atomic/Composite

Tab. 2.1. Comparison of model co-evolution approaches.

reusable and custom coupled operators. The reusable operators allow the reuse of migration strat-egy independently of the specific metamodel. The custom coupled operators allow to attach a custom migration to a recorded metamodel change. In [43], an approach is presented that uses in a first phase metamodel matching to derive the changes between two metamodel versions and in a second phase, operations are applied based on the detected changes to migrate the corresponding models.

Schoenboeck et al. [14] propose an approach that does not rely on metamodel changes. Au-thors apply a constrained-based search to detect the conformance violations and provide repair operations to re-establish this conformance relationship.

The next section discusses the approaches proposed to tackle the transformations co-evolution problem.

2.3.2. Transformation co-evolution

The evolution of models and transformations can be treated separately, but when their meta-models are updated or adapted, those artifacts might be impacted. However, the co-evolution of metamodels and transformations is different from the co-evolution of metamodels and models. The former depends only on the type of change performed during metamodel evolution, and the latter depends not only on the type of change but also on how the updated elements may affect

(45)

the transformation rules [50]. Surprisingly, transformation co-evolution problem has received less attention in MDE compared to model co-evolution. Thus, this area is largely unexplored and may require further investigation.

Like the term conformTo that specifies the relation between metamodel and model, Mendez et al. [51] introduce the term DomainConformTo as the relation between transformations and their metamodels. For instance, the source elements of every transformation rule must correspond to a metaclass in the source and/or the target metamodel elements. Even though the authors have studied how a metamodel evolution may affect that relationship and have given first pointers to an operator based approach for transformation co-evolution [51].

Similarly, Kusel [50] proposed an initial set of atomic operators and some complex ones (that are made up of simple operators) that can be applied on a given metamodel to perform changes and allow automatic or semi-automatic co-evolution of transformation and analyze the influence of the changes in the original ATL rules.

Di Ruscio et al. [52] proposed an approach to the coupled evolution of metamodels and ATL transformation rules. This approach contains various activities that start with defining the depen-dencies between the transformation language and the metamodeling language (e.g. establishing the correspondence between ATL and ECore metamodels) which are used later to derive them between an evolving metamodel and the existing transformations. The second step is analyzing the impact of changes by detecting all the elements of the transformation that are affected after the evolution of the metamodel. Then, the designer evaluates the cost of adapting the affected transformation; if the adaptation is too expensive the designer can decide to refine the metamodel changes to reduce the cost. After that, the affected transformation can be adapted.

Levendovszky et al. [53] proposed a Higher Order Transformation to adapt existing transfor-mations developed in the GME/GReAT toolset. They classify metamodels, with respect to the affected transformation, to three categories:

• Fully automated : changes that affect existing transformations which can be automatically migrated without user intervention.

• Partially automated: changes or modifications that affect existing transformations which can be adapted automatically, even though some manual fine-tuning is required to complete the adaptation.

(46)

• Fully semantic: changes are those modifications which affect transformations and cannot be automatically migrated, and the user has to completely define the adaptation.

The proposed algorithm automatically alerts the user about missing information when the au-tomation is not possible. However, the approach is limited to graph-based languages, considering simple changes and considering subtracting changes only as coarse-grained removals (i.e., rule level deletions). And this, due to the use of the Model Change Language (MCL), which represents the differences between the source metamodel and the target metamodel in terms of rules that have been designed for model co-evolution in order to migrate transformation rules. Thus the solution is only limited to a few evolution cases.

Garcia et al. [54] have proposed an approach compromise two steps for transformation co-evolution : detection and co-co-evolution. The detection step compromises the detection of simple changes (e.g class renaming) and the detection of complex changes that are considered as pred-icates over simple changes. The former are detected by the difference between the original and the evolved metamodel using EMF Compare tool. The latter is realized as a transformation that takes a Difference model as input and obtains a DiffExtended model that includes both simple and complex changes. At the co-evolution step, authors adapt the classification of changes of model co-evolution [39] to the transformation co-evolution problem. They define higher order transformations as a set of ATL rules, that takes transformations as input and returns a modified transformations by taking as parameters the changes obtained during the detection step to define a correspondence that map the original transformation into an evolved one.

Similarly, in [55], [56] and [57], authors have proposed a matching strategy that computes the equivalences and differences between a pair of metamodels and persists the results in a mapping model. Then a manual user intervention is needed to refine the generated mapping model. Finally, a HOT generates the adaptation transformation from the (refined) mapping model.

Table 2.2 illustrates a comparison of the different approaches of transformation co-evolution.

2.3.3. OCL co-evolution

In this section, we discuss approaches for the problem of co-evolving metamodels and OCL constraints. Existing approaches can be classified as online or offline approaches. Online ap-proaches perform instant co-evolution for each change during the metamodel evolution, whereas

(47)

Approach Detection Strategy Automation Degree Evolving Metamodel(s) Impact Analysis Garcia et al. [54] Metamodel matching Semi-automatic Source and target OCL, binding, rule,module Di Ruscio et al. [52] Manual Automatic Sourse and target No evaluation is made

Kruse [50] Operation-based Semi-automatic Source Binding, rule,module

Levendovszky et al. [53] Metamodel matching Semi-automatic Source Graph based Garcès et al. [57] Metamodel matching Semi-automatic Source and target Binding, rule,module

Kusel et al. [55] Operation-based Automatic Source OCL, binding, rule,module Tab. 2.2. Comparison of transformation co-evolution approaches.

offline approaches wait after the metamodel has been evolved to perform co-evolution of the OCL constraints.

For online approaches, Demuth et al. [58, 59] provide templates that define a fixed structure for OCL constraints that are then instantiated to update the constraints. However, they are limited to 11 templates that cannot cover all changes at metamodel level. Hassam et al. [60, 61] propose a semi-automatic approach that highlights the constraints that should disappear after evolution and by formalizing the adaptation to be applied on impacted constraint after each operation on a metamodel using the QVT transformation language [62]. Similarly, Markovic et al. [63, 64] proposed an approach using QVT, in which they formalize the most important refactoring rules for class diagrams and classify them with respect to their impact on annotated OCL constraints. The advantage of online approaches is that the order of changes is preserved and no hidden changes are missed. However, the cancelling actions during evolution are apart of the detected changes.

For offline approaches, Kusel et al. [65] analyze the impact of metamodel evolution on OCL, then propose resolution actions in model transformation by means of ATL helpers. Cabot and Conesa [66] focused on the metamodel changes that entail deleting elements. In particular, they aimed to remove the parts of OCL constraints that use the deleted elements. Khelladi et al. [67] pro-pose a semi-automatic approach that records in chronological order the changes to the metamodel. Then, they detect high-level changes and apply resolution strategies to adapt OCL constraints based on the structure of the impacted OCL constraint and the impacted location.

With respect to automation, Markovic et al. [63, 64], Cabot and Conesa [66], Demuth et al. [58, 59] are fully automated approaches. Hassam et al. [60, 61], Khelladi et al. [67] and Kusel et al. [65] are semi-automated approaches.

(48)

Approach Detection Strategy Automation Degree OCL Co-evolution Strategy Demuth et al. [58] [59] Recording changes Automatic Online

Hassam et al. [60] [61] Recording changes Semi-automatic Offline Kusel et al. [65] Metamodel differencing Semi-automatic Offline Markovic et al. [63] [64] Recording changes Automatic Online Cabot et al. [66] Metamodel differencing Automatic Offline Khelladi et al. [67] Recording changes Semi-automatic Offline

Tab. 2.3. Comparison of OCL constraints co-evolution approaches.

The above-mentioned approaches focus on identifying conceptually high-level changes to the metamodel in order to co-evolve OCL constraints. They detect such changes either by manually comparing the two metamodel versions or by recording, matching or calculating their differences. Subsequently, they apply various change-specific strategies aimed to mirror the high-level concep-tual changes.

Table 2.3 illustrates a comparison of the different approaches of OCL constraints co-evolution.

2.4. Synopsis

Although the main goal of all discussed approaches is similar to ours, there are several major differences. They focus on identifying conceptually high-level changes to the metamodel in order to co-evolve artifacts. They detect such changes either by manually comparing the two metamodel versions or by recording, matching or calculating their differences. Subsequently, they apply var-ious change-specific strategies aimed at mirroring the high-level conceptual changes. We tackle co-evolution of artifacts without the need of computing differences on the metamodel level. In-stead, we search for solutions, which fulfill multiple goals expressed as our fitness functions. By this, the critical and challenging task of finding proper co-evolution solutions is automated which allows exploring a much larger space of possible solutions which is possible when manually de-veloping co-evolution transformations.

To sum up, none of the existing approaches allows the exploration of different possible co-evolution strategies. On the contrary, only one specific strategy is either automatically derived from the calculated set of metamodel changes. So the resolution result is not guaranteed to be the one desired to co-evolve an artifacts.

(49)

Our contributions, described in the next chapters, give the user a better control over the rec-ommendations, since we propose a set of alternative resolution strategies to the user to select appropriate ones and interactively update them.

2.5. Conclusion

Among this chapter, we introduced the necessary background related to model-driven engi-neering, and its evolution and search-based software engineering techniques. Furthermore, we presented different existing approaches that have recently focused on the co-evolution of artifacts during metamodel evolution. In the next chapter, we will give an overview of our methodology and we will introduce our proposed co-evolution framework.

(50)

(51)

Chapter 3 Generic Model-Driven Engineering Co-Evolution Framework

3.1. Introduction

In this chapter, we describe our proposal to circumvent the problems identified in the previous chapters. Hence, we start by describing our research objectives. We next give an overview of our methodology to achieve these goals related to the metamodels co-evolution problem.

3.2. Research Objectives

The main objective of our research lies mainly on the evolution of model-based software sys-tems such as evolving meta-models, which are used to build domain-specific languages and trans-formation in model driven architecture. The evolution of metamodels and related artifactsc(e.g. models, model transformations, OCL constraints, etc.) are interdependent. A change in one arti-fact (metamodel) must be reflected in all other related artiarti-facts (models, rules, constraints, etc.).

Figure 3.1 gives an overview of the metamodel evolution and how it breaks the relationships to dependent artifacts. The evolution of a metamodel and related constraints may lead to several updates:

(1) Several model instances need to be migrated in order to conform to the new metamodel definition.

(2) Several model transformation rules need to be adapted. (3) Several OCL constraints need to be adapted

An abstract case of evolution of a metamodel and a co-evolution of artifacts is shown in fig-ure 3.2. A list of changes have been applied on the metamodel, and a migration strategy have been

(52)

Fig. 3.1. MDE Artifacts Co-Evolution Overview.

Fig. 3.2. Evolution and Co-Evolution Scenario in MDE Adapted from [1].

applied to make an artifact conforming to the evolved metamodel version. The goal of this work is to support the evolution of artifacts as described in the next section.

(53)

Fig. 3.3. MDE Artifacts Co-Evolution Overview.

3.3. Methodology

To achieve the artifact migration, we propose a generic automated search-based framework pre-sented in figure 3.3. The goal of our framework is to generate, for each of the considered artifacts, a minimum number of changes to generate a new version that conforms to the new metamodel as much as possible. Thus for each input artifact, the search space is the set of possible artifacts that can be generated by applying on the input artifact combinations of the edit operations. The explo-ration of this search space is guided by three objectives, which aims to minimize (i) the violation of the structure of the revised metamodel (ii) the number of changes applied to the initial artifact, and (iii) minimize the loss of information. Based on these three objectives, the revised artifact has to be similar, as much as possible, to the initial artifact while conforming to the new metamodel version.

The framework is based on a multi-objective NSGA-II algorithm to handle the three conflicting objectives. In the next subsections we will describe the generic adaptation of the algorithm, and in the next chapters we will provide specific details of the adaptation related to each artifact.

3.4. Metamodel/Artifact Co-evolution : a Multi-Objective Problem

We describe in this section our proposal and, in particular, how we adapt the metamodel/artifact co-evolution as a multi-objective optimization problem.

Solution representation (i.e., an individual). In our framework, a solution is the artifact. It can be represented either as a sequence of operations or by the artifact itself in a vector, since