Djamel Eddine Khelladi
email: djamel_eddine.khelladi@jku.at

Reda Bendraou

Regina Hebig
email: hebig@chalmers.se

Marie-Pierre Gervais
email: marie-pierre.gervais@lip6.fr

A Semi-Automatic Maintenance and Co-evolution of OCL Constraints with (Meta)model Evolution

Keywords: Metamodel, Evolution, OCL, Constraints, Co-evolution

Metamodels are core components of modeling languages to dene structural aspects of a business domain. As a complement, OCL constraints are used to specify detailed aspects of the business domain, e.g. more than 750 constraints come with the UML metamodel. As the metamodel evolves, its OCL constraints may need to be co-evolved too. Our systematic analysis shows that semantically dierent resolutions can be applied depending not only on the metamodel changes, but also on the user intent and on the structure of the impacted constraints. In this paper, we rst investigate the syntactical reasons that lead to apply dierent resolutions. We then propose a co-evolution approach that oers alternative resolutions while allowing the user to choose the best applicable one. We evaluated our approach on six case studies of metamodel evolution and their OCL constraints co-evolution. The results show the usefulness of alternative resolutions along with user decision to cope with real co-evolution scenarios. Within our six case studies our approach led to an average of 92% (syntactically) and 93% (semantically) matching co-evolution w.r.t. the user intent.

Introduction

In the past years, Model-Driven Engineering (MDE) has proven to be eective in the development and maintenance of large scale and embedded systems [START_REF] Hutchinson | Empirical assessment of mde in industry[END_REF][START_REF] Liebel | Assessing the state-of-practice of model-based engineering in the embedded systems domain[END_REF]. As a consequence, modeling languages have emerged in the industry [START_REF] Tolvanen | Metaedit+: dening and using integrated domain-specic modeling languages[END_REF] supporting all typical phases of development processes [START_REF] Shirtz | Adopting model driven development in a large nancial organization[END_REF].

At the heart of any modeling language ecosystem, there is a metamodel [START_REF] Boronat | An algebraic semantics for mof[END_REF]. Metamodels are core components to the well-functioning of a modeling language ecosystem [START_REF] Hutchinson | Empirical assessment of mde in industry[END_REF]. They dene the structural aspects of a business domain, i.e. the main concepts, their properties, and relationships between them [START_REF] Jordi | Object constraint language (OCL): A denitive guide[END_REF]. However, a metamodel alone is insucient to capture all the relevant aspects and information of a domain specication [START_REF] Mezei | An optimizing ocl compiler for metamodeling and model transformation environments[END_REF]. To overcome this limitation, the Object Constraint Language (OCL) [START_REF] Omg | Object management group. object constraints language (ocl)[END_REF] is used to dene constraints on top of the metamodel. For instance, the wide-spread Unied Modeling Language (UML) [START_REF] Omg | Object management group. unied modeling language[END_REF] in version 2.4.1 contains more than 750 OCL constraints expressing well-formedness rules to be enforced at the model instance level.

Evolution of modeling languages is inevitable and necessary. One of the main evolution dimensions in a modeling language is the metamodel evolution. A challenge hereby arises when the metamodel is evolved causing the invalidation of some OCL constraints that may need to be co-evolved as well (i.e. maintained to remain reusable [START_REF] Morisio | Success and failure factors in software reuse[END_REF]). For instance, the UML metamodel ocially evolved 10 times in the past 1 , and these evolutions led to manually adapting the impacted OCL constraints among the ones associated to the UML metamodel. This is not only the case of UML, but also for many modeling languages such as BPMN 2 and GMF 3 who respectively evolved 4 times and 24 times.

Manual co-evolution can be tedious, time-consuming, and an error-prone task [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF][START_REF] Andova | Mde basics with a dsl focus[END_REF], in particular when hundreds of OCL constraints are impacted by the changes. In such context, it is crucial to support software engineers with an automatic co-evolution for two reasons. The rst one relates to the need to maintain the legacy, i.e. OCL constraints. Indeed, already dened OCL constraints fulll part of the domain's specication that must naturally be maintained w.r.t. the new evolved version of the metamodel. The second one is the need to avoid introducing errors in source code and test cases that can be automatically generated from models and their OCL constraints (e.g. [START_REF] Hemel | Code generation by model transformation[END_REF][START_REF] Aichernig | Test case generation by ocl mutation and constraint solving[END_REF]). This automatic generation would not be trustworthy if it was based on non co-evolved OCL constraints.

Problems. Automatically co-evolving OCL constraints remains challenging, mainly because of two issues: 1) the existence of multiple and semantically dierent resolutions, and 2) a resolution can be applicable only to a subset of OCL constraints. In the following, we detail these issues.

1) The impact of a metamodel change on an OCL constraint can be resolvable using resolutions that are syntactically and/or semantically dierent. For instance, the metamodel change "multiplicity generalization of a property p from a single value to multiple values" requires the OCL constraints to work on a collection of values, e.g. by introducing an iterator. Figure 1 gives an example of this change for the property ref with a simple OCL constraint.

Multiple resolutions can be applied here as depicted in Figure 1, since multiple iterators with dierent semantics exist, e.g. forAll(), exists() etc. Proposing a unique resolution reduces the applicability of the co-evolution approach and limits its benet. Final decision can only be specied by the user herself, to avoid unintended co-evolution changes.

2) A given resolution strategy is not always applicable for all OCL constraints. The complex nature of OCL requires dierent resolution strategies, each one applicable for only a subset of OCL constraints based on: a) the location of the impacted part in an OCL constraint, and b) its context (i.e. the metamodel element on which an OCL constraint is dened). Figure 2 illustrates this issue. It depicts an evolution of a metamodel where the property depth is deleted from the superclass Component and added to the subclass Composite, which ts the denition of a "push property" [START_REF] Herrmannsdoerfer | An extensive catalog of operators for the coupled evolution of metamodels and models[END_REF]. The rst two constraints become invalid because depth is no more accessible in Component. The rst constraint that uses the pushed property depth through the refer- ence component, can be co-evolved by introducing an If expression that rst checks whether component references an instance of the subclass Composite so that depth is accessible. In contrast, the second OCL constraint whose context is dened on the pushed property depth, is co-evolved dierently by duplicating it for the subclass Composite. The original constraint is then removed as depicted in Figure 2d. Note that the third constraint dened on the context of the subclass Composite that uses depth is not impacted.

Clearly, a unique resolution strategy cannot be applied whatever the OCL constraint, for the three constraints in our example. Consequently, it is crucial to consider the two above issues when coevolving OCL constraints. However, existing approaches [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF][START_REF] Demuth | Automatically generating and adapting model constraints to support co-evolution of design models[END_REF][START_REF] Demuth | Supporting the coevolution of metamodels and constraints through incremental constraint management[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF][START_REF] Kusel | Systematic co-evolution of ocl expressions[END_REF][START_REF] Cabot | Automatic integrity constraint evolution due to model subtract operations[END_REF] neither consider the two above issues, nor interact with the user. We think that a co-evolution approach should nd a balance between manual intervention and full automation. On the one hand, nal decision regarding which resolution strategy to apply among a set of possible resolutions should be left to human. On the other hand, its application must be automated to reduce the eort of the co-evolution from the users.

Contributions. We addressed these challenges by four contributions: First, we systematically investigate what are the inuencing factors that lead to dene alternative resolution strategies and when to apply them. Thus, we establish that the metamodel changes alone are insufcient to propose the appropriate resolutions, and additional factors must be considered.

Second, we propose an approach that considers alternative resolutions per impacted part of an OCL constraint. Thus, for a metamodel change, we propose various resolutions for dierent subsets of OCL constraints. It allows us to cover dierent alternatives of co-evolution. A minimal set of resolutions is proposed so far in our approach.

Third, based on the inuencing factors and from our set of resolutions, we dene a process that aims at proposing only the appropriate resolutions that can be applied to an impacted OCL constraint. The process takes the inuencing factors for each impacted OCL constraint and excludes resolutions that cannot be applied on it. The user can then conrm which resolutions to be applied among the proposed alternative ones. Involving the user greatly contributes to avoid applying unintended resolution strategies.

Fourth, we investigate the possibility to co-evolve non-impacted OCL constraints. Indeed, non-impacted OCL constraints may as well be coevolved and/or refactored due in response to the metamodel evolution. Herein we propose to extend our co-evolution approach to also co-evolve non-impacted OCL constraints.

We validated the co-evolution approach on six case studies. The results show that we are able to co-evolve the impacted OCL constraints w.r.t. the user intent, which in 92% of the cases are syntactically (and in 93% of the cases are semantically) equivalent to the actual co-evolved constraints. Our approach is implemented as plugin for the Eclipse IDE a wide-spread software development environment.

In Model-Driven Engineering OCL constraints can be dened on objectoriented models, e.g., metamodels, UML models etc. While we focus in this paper on the co-evolution of OCL constraint dened on metamodels, the current approach theoretically applies on OCL constraints dened on objectoriented models in general.

This paper extends our previous work [START_REF] Khelladi | Metamodel and constraints co-evolution: A semi automatic maintenance of ocl constraints[END_REF]. Additional contributions include a more detailed description of all resolutions that we propose, considering the co-evolution of non-impacted constraints, ve additional case studies used to show the feasibility of the approach with various evolution and coevolution scenarios, a prototype that supports OCL co-evolution dened on both the Ecore modeling tool and the UML Class Diagram (CD) Papyrus modeling tool, and a more comprehensive and extensive discussion of our results and the related work.

For a better understanding of the current approach, this paper rst discusses in Section 2 the factors we identied that inuence the application of the resolution strategies. Section 3 then presents the overall approach introduces some of the proposed resolutions. Section 4 illustrates our implementation. The evaluation, results, discussion, and threats to validity are presented in Section 5. Finally, Section 6 and 7 present respectively the related work and the conclusion.

Factors Inuencing the Resolution Strategies

In this section, we identify the factors that inuence the choice of the resolution strategies. To illustrate the inuencing factors we reuse the example used in the introduction as depicted in Figure 2.

Factor 1

First of all, the type of a metamodel change is fundamental to choose which resolution to apply, similarly as in model co-evolution approaches (e.g. [START_REF] García | Model transformation co-evolution: A semi-automatic approach[END_REF][START_REF] Wachsmuth | Metamodel adaptation and model co-adaptation[END_REF][START_REF] Herrmannsdoerfer | Cope-automating coupled evolution of metamodels and models[END_REF][START_REF] Cicchetti | Automating co-evolution in model-driven engineering[END_REF]). The impacts of a rename property and a push property cannot be xed using the same resolution. Thus, the rst inuencing factor is: the metamodel change.

Factor 2

We further investigated which locations in an OCL constraint can inuence the choice of a resolution. We identied two locations that have an inuence: navigation path and context. For example, in Figure 2 the two rst OCL constraints need to be resolved dierently since the pushed property depth is used in dierent locations. In the rst constraint depth is located in the OCL expression (i.e. body) through a navigation path. Whereas, in the second constraint depth is located in the context. Thus, the second inuencing factor is: the location of the impacted metamodel element e in an OCL constraint.

Factor 3

Finally, we found a third factor that is the context of the constraint, which can inuence the choice of a resolution. In Figure 2, the rst constraint is coevolved by introducing an If expression and not by duplicating the constraint to the subclasses where depth is pushed, as we did with the second constraint. This is due to the fact that the context of the rst constraint is not the superclass Component. When changing the context, all accessible properties from the old context must remain accessible from the new context. If the context of the rst constraint is changed from Element to Composite, the property limit will not be accessed anymore. For the third constraint which has the sub class Composite as context no resolution strategy is applied, since depth is still accessible. Therefore, the third inuencing factor is: the context of the impacted constraint.

Our analysis of the state-of-the-art led us to identify only the factor 1 that is considered by all co-evolution approaches. To identify additional factors, we systematically studied the dierent uses of the metamodel elements in the OCL language (last version 2.4). Thus, we investigated: 1) the uses of each metamodel element in all possible structures that an OCL constraint can have (in the OCL grammar [START_REF] Omg | Object management group. object constraints language (ocl)[END_REF]) and further 2) the reasons why a resolution can be applied to some constraints and not to others. It allowed us to identify the additional factors 2 and 3. Our systematic analysis gives us condence that the above factors are the only ones w.r.t. the current version of OCL. However, we cannot prove it formally that there is no other factors. So far, we have not found a counter-example. Note that the above factors consider syntactic aspects of the OCL constraints and less the semantic of the OCL constraints.

In summary, to propose appropriate resolutions we must consider the three identied inuencing factors that are highlighted in the framebox here under.

1. The metamodel change of an element e.

Location of the impacted element e in an OCL constraint:

(a) e is used in the context of an OCL constraint (b) e is used in the OCL expression (i.e. body) through a navigation path. 3. The context of the impacted constraint, to know from which class the impacted element is accessed.

A Co-Evolution Approach of OCL Constraints

This section presents our approach to co-evolve OCL constraints. Figure 3 depicts an overview of our approach. We rst present the metamodel changes that we consider during an evolution and we present how they are identied 1 . After that, we discuss the identication of impacted OCL constraints, in particular the localization of the impacted parts in the constraints 2 . Then, we explain how we obtain the three inuencing factors for each impacted OCL constraint. Finally, we show how alternative resolutions are proposed to the user 3 and how they are automatically applied 4 .

Based on the discussion of challenges in the introduction of this work, we formulate three requirements that must be fullled in our approach: R1. All OCL constraints that must be co-evolved are identied. R2. Alternative resolutions are always proposed whenever it is possible. R3. Only the appropriate resolutions that can be applied to the impacted OCL constraint are proposed.

Metamodel Changes During Evolution

During a metamodel evolution two types of changes are distinguished: a) Atomic changes that are additions, removals, and updates of a metamodel element, and b) Complex changes that consist in a sequence of atomic changes combined together. For example, move property is a complex change where a property is moved from one class to another via a reference. This is composed of two atomic changes: delete property and add property [START_REF] Herrmannsdoerfer | An extensive catalog of operators for the coupled evolution of metamodels and models[END_REF].

We consider the following set of atomic changes: add, delete, and update of metamodel elements. An update, changes the value of a property of an element, such as 'type', 'name', 'upper/lower bounds'. The metametamodel elements that are considered in this work are: package, class, attribute, reference, operation, parameter, and generalization. Those elements represent the core features of a metamodel in the EMF/Ecore [START_REF] Steinberg | EMF: eclipse modeling framework[END_REF] and the MOF [START_REF] Omg | Object management group. meta object facility (mof)[END_REF] standards. In the literature, over sixty complex changes are proposed [START_REF] Herrmannsdoerfer | An extensive catalog of operators for the coupled evolution of metamodels and models[END_REF]. Among them, we focus on seven complex changes: move property, pull property, push property, extract super class, atten hierarchy, extract class, and inline class. A study of the evolution of GMF4 metamodel showed that these seven changes are the most used ones and constitute 72% of the applied complex changes [START_REF] Herrmannsdoerfer | Language evolution in practice: The history of GMF[END_REF][START_REF] Langer | A posteriori operation detection in evolving software models[END_REF]. In our case studies they constitute 100% of the applied complex changes in the evolutions.

In our co-evolution approach we must rst identify metamodel changes that led from version n to version n+1, as shown by the step 1 in Figure 3. This is a prerequisite for both impact analysis and automatic support of the co-evolution. We reuse our detection tool [START_REF] Khelladi | Detecting complex changes and refactorings during (meta) model evolution[END_REF][START_REF] Khelladi | Detecting complex changes during metamodel evolution[END_REF][START_REF] Khelladi | Ad-room: a tool for automatic detection of refactorings in object-oriented models[END_REF], an extension of the Praxis tool [START_REF] Blanc | Detecting model inconsistency through operation-based model construction[END_REF]. It rst records at run-time all atomic changes applied by users within a modeling tool. Note that the atomic changes can also be computed by the dierence between the original and evolved metamodels. However, this technique has two drawbacks [START_REF] Khelladi | Detecting complex changes and refactorings during (meta) model evolution[END_REF]: 1) The chronological order of the applied atomic changes is lost. 2) Some changes are hidden by other changes during evolution. For instance, when a move property p is followed by a rename p to p' during the evolution, computing the dierence do not detect these last two changes, but sees only two independent changes: delete p and add p'. The sequence of recorded atomic changes then serves as input for the detection of complex changes. Our tool [START_REF] Khelladi | Detecting complex changes and refactorings during (meta) model evolution[END_REF] has been designed to detect all applied changes. This is conrmed in the evaluation results by reaching a 100% recall (i.e. all complex changes are detected) and a precision (i.e. correct detection) of 91% and 100%. Our detection tool [START_REF] Khelladi | Detecting complex changes and refactorings during (meta) model evolution[END_REF] allows the user to conrm the list of complex changes that best reect her intention during the evolution. Therefore, a nal precise, complete, and ordered trace of both atomic and complex changes is computed. This trace is taken as input by our herein tool to co-evolve the OCL constraints when the user requires it.

Identication of Impacted OCL Constraints

The second step of our approach is to identify the OCL constraints impacted by metamodel changes during the evolution. In particular, we identify all the impacted parts of the OCL constraints that need to be co-evolved.

To run the impact analysis we need to access to all the elements used in an OCL constraint. Thus, we rst parse the OCL constraints to use the Abstract Syntax Tree (AST) representing a structured view of an OCL constraint. The identication of impacted OCL constraint is then performed on the generated AST. Before identifying where an AST is impacted, we rst compute a table that lists for each metamodel element e, all OCL constraints using e with references to the AST nodes using e. Those references will be further used in the resolution step. Table 1 illustrates an example of our computed table. To build Table 1, we apply a pre-order tree traversal algorithm on the AST while lling the table.

For each metamodel change on a metamodel element e i , we access the set of impacted OCL constraints and we access exactly the impacted AST nodes with the saved references. Note that a metamodel complex change can involve several elements e i ...e j . Thus, the set of impacted OCL constraints are accessed naturally for each element e k where i ≤ k ≤ j. During the co-evolution process Table 1 is also updated accordingly with the applied resolutions. For instance, when a rename element e occurs, it is also renamed in the table. Using the Table 1 answers the requirement R1 to detect all impacted constraints. By using Table 1, we might also have false positives by identifying nonimpacted OCL constraints. In particular, when a push property or atten hierarchy are applied, already dened constraints on the subclasses are identied as impacted. However, they are ltered with the third inuencing factor. No resolutions will be proposed since they are in fact non-impacted. Alternatively, one can use an OCL interpreter/evaluator to retrieve the OCL constraints that are invalid on which we run the impact analysis and we propose the appropriate resolutions for each impacted OCL constraint.

Obtaining the Inuencing Factors

As discussed in section 3.1 the metamodel changes are given as input from our detection tool. The two last factors, i.e. location and context, are obtained from the impacted AST and AST nodes from Table 1. Each AST node has a type and information that we can use to determine the impacted location in the constraints as well as the context of a constraint.

For the context, we further identify whether the impacted element is accessed from the level of its container, the sub classes, or the super class. At this point, once the three inuencing factors for an impacted part of an OCL constraint are determined, we can propose a set of possible resolutions, as we will describe it in Section 3.6.

Resolution Strategies

This section introduces our resolution strategies and the inuencing factors under which they are applied on impacted OCL constraints. Table 2 shows the changes we consider in this paper as well as their classication, i.e. whether they do impact OCL constraints. The changes are evaluated as impacting, if there exists at least one situation where the metamodel changes impacts the syntactic correctness of the OCL constraints. All metamodel changes that are non-impacting do not need to be handled (n/a), i.e. no resolutions are dened for them. Among all impacting metamodel changes we handle those whose impact can be automatically co-evolved. Two changes are not handled since they require user intervention. For instance, when a parameter p is added to an operation op(). In all calls of the operation op(), a variable v of the same type of the parameter p must be added (in the right position when several parameters are dened) resulting in the new operation calls op(v). This decision can only be manual, in particular when several parameters are dened with the same type. Although, the change modify property type in some cases does not impact OCL constraints, e.g., changing it from Integer to Double. However, it may also impact the OCL constraints in case the old and new types are incompatible, e.g., from Date type to Enumeration type, and hence requiring manual intervention. As mentioned previously, in the following strategies, there is always the empty resolution strategy that does nothing. For sake of readability, we do not duplicate it for all changes in the rest of this section.

Rename Element

This strategy applies for a class, a property (i.e. attribute, reference, operation), a parameter, an enumeration, and an enumeration literal.

-Id : #S1 Context : n/a Location in the constraint : n/a Description : When an element e in the metamodel is renamed to e', a rename is also applied in the OCL constraints using e.

Delete Element

Similarly, this strategy applies for a class, a property (i.e. attribute, reference, operation), a parameter, an enumeration, and an enumeration literal.

-Id : #S2

Context : n/a Location in the constraint : n/a Description : When an element e in the metamodel is deleted, a delete of the constraints using e is also applied.

Note that for both rename and delete element, we do not need the information of the location of the element on the impacted OCL constraint and the context. These strategies applies to any constraint whatever the two last factors.

Generalize Property Multiplicity (GPM) from a Single Value to Mul-

tiple Values An example of this metamodel change is already shown in Figure 1. This metamodel change requires the OCL constraint to work on a collection of values of a property p and not a single value anymore. Multiple solutions can be proposed all with a slightly dierent semantic and are presented below. Note that the operation any(exp) is not used since is requires a boolean condition as a parameter that only the user can specify..

-Id : #S3.

Context : n/a. Location in the constraint : navigation path. Description : An iterator "forAll" is added to access the property p, and the subexpression (i.e., restExp) using the values of p is moved to the body of the "forAll" while replacing the access path with a temporary variable. The given semantic here is that the OCL constraint is satised if it is satised for all the values of p.

Exp.p.restExp => Exp.p->forAll(x|x.restExp)

-Id : #S4. Context : n/a. Location in the constraint : navigation path. Description : An iterator "exists" is added to access the property p, and the subexpression (i.e., restExp) using the values of p is moved to the body of the "exists" while replacing the access path with a temporary variable. The given semantic is that the OCL constraint is satised if at least it is satised for one value of p.

Exp The value at the i -th position (given by the user) of the collection of the property p is accessed.

Exp.p.restExp => Exp.p->asOrderedSet()->at(i).restExp

Move Property

This change consists of moving a property p from a class A to a class B through a reference r from A.

When the moved property is used in the context, we propose the following resolution.

-Id : #S8 Context : A (container) Location in the constraint : context Description : The context of the constraint is updated, by changing the source class to the target class where the property p is moved. Then, for each keyword self (equivalent to this in Java) referencing the old context, a navigation back to it is added through an existing reference r' given by the user as input. The navigation path to the property p is rst extended with the reference r. Then, one of the strategies among #S3, #S4, #S5, #S6, and #S7 is chosen by the user to be applied, since r is returning a collection. This resolution strategy is a combination of #S9 and one of #S3, #S4, #S5, #S6, #S7.

Exp -Id : #S11.

Context : A (container) Location in the constraint : context Description : The constraint is duplicated to the subclasses where the property p is pushed, while updating the context with the subclasses. The original constraint is deleted.

-Id : #S12 Context : A (container) Location in the constraint : navigation path Description : If the context is on the superclass A, then duplicate the constraint to the subclasses where the property p is pushed, while updating the context with the subclasses. The original constraint is then deleted.

-Id : #S13 Context : not via the subclasses Location in the constraint : navigation path Description : An If expression is introduced for each subclass where the property p is pushed. The condition tests whether the navigation path until p is a type of the subclass. The subexpression is copied in the then branch while casting to the subclass before accessing p. Note that all the If expressions are joined with the operator "or". This strategy is applied in Figure 5 in our example of Figure 2.

( Exp.p.restExp ) => ( if(Exp.oclIsKindOf(subclass 1 )) then Exp.oclAsType(subclass 1 ).p.restExp else false or ... if(Exp.oclIsKindOf(subclass n )) then Exp.oclAsType(subclass n ).p.restExp else false ) Note that the resolution #S13 (or in combination of other resolutions), in complex situations, may lead to a nal co-evolved constraint that might be hard to comprehend. Thus, as with any automatic activity the user might need to re-write and re-structure the constraint in seldom cases. We will further assess whether in our case studies such cases occurs.

Extract Class

An Extract Class is performed as follows: a new class B is added, and a single-valued reference r is added from a class A to class B. Then a set of properties p 1 , ..., p n are deleted from A and added to B. It can be seen as a group of move properties through a single-valued reference. Thus, the resolution strategies are the same as the #S8 and #S9 for each p i .

Inline Class

An Inline Class is the opposite of Extract class, a set of properties p 1 , ..., p n are deleted from a class B and added to a class A. Then the class B (nonreferenced by any other class) as well as the single-valued reference r are deleted.

- -Id : #S17 Context : A (container) Location in the constraint : n/a Description : If the context is on the superclass A, then duplicate the constraint to the subclasses. The original constraint is then deleted.

Table 3 presents the metamodel changes that have an impact on OCL constraints that can be automatically resolved, and their associated resolutions while specifying the two new inuencing factors. The changes are evaluated as impacting, if there exists at least one situation where the metamodel change impacts the syntactic correctness of the OCL constraints. The resolutions aim at restoring the syntactic correctness of the impacted OCL constraints while expressing the same OCL constraints. The idea of each resolution is to propagate the metamodel change knowledge on the OCL constraints. However, some alternative resolutions may express dierent semantics. In particular, for the change Generalize Property Multiplicity (GPM) from a Single Value to Multiple Values, the proposed resolutions (rst, last, etc.) to access a collection of values have dierent semantics. Thus, the resulted OCL constraint still veries the same original condition but either for the rst value, for the last value, etc.

Among the 7 complex changes we consider (section 3.1), we analyzed the impact they can have on OCL constraints. Except for pull property and extract super class, they all have an impact that can be automatically resolved.

Instead of proposing a unique resolution per metamodel change, we propose the minimal number of resolutions that consider the three inuencing factors. In particular, we propose the minimal set of resolutions so that: 1) the alternative operations that the OCL language oers are all considered, e.g. the alternative iterators forAll() and exists(), and 2) an arbitrary impacted OCL constraint (with an arbitrary impacted location) can always be co-evolved. Note that our resolutions are designed independently from the types of the OCL expressions but rather as a response to the eect of the impacting metamodel changes. However, for each of the resolutions we simulated (during the design phase of the resolutions) their application on dierent OCL expressions with the dierent available types to identify cases where thy are not applicable. Further in our evaluation we did not face a case where a resolution strategy could not be applied. Nonetheless, we cannot generalize it to all possible constraints as stated in the threats to validity.

However, we do not attempt to dene all possible resolutions. There will always be a situation in which the user might apply a manual resolution or a particular refactoring. This is handled in our approach by the ignore option since we allow the user to not apply a specic resolution when desired. Search-based techniques can be used to explore all possible solution space, i.e. all possible co-evolved OCL constraints as it is done for models' co-evolution [START_REF] Kessentini | Automated metamodel/model co-evolution using a multi-objective optimization approach[END_REF][START_REF] Demuth | Co-evolution of metamodels and models through consistent change propagation[END_REF][START_REF] Schoenboeck | Care: A constraint-based approach for re-establishing conformance-relationships[END_REF]. In particular, a search-based technique can be used when the user chooses to ignore the proposed resolutions. This is left as future work. As shown in Table 3, for 8 metamodel changes we propose 17 resolutions, thus answering the requirement R2. Note that in our case studies these 17 resolutions covered the co-evolution of all the impacted OCL constraints.

Co-evolving Non-impacted OCL Constraints

Up to now we focused on resolving OCL constraints that are impacted by metamodel changes. As shown in Table 2 several changes do not impact OCL constraints and thus no resolution is associated to those changes. Nonetheless, a co-evolution in the form of a refactoring can be proposed to be applied on OCL constraints. Indeed, non-impacted OCL constraints can always be improved or even deleted in case they become meaningless. However, it is very challenging to rst detect the non-impacted constraint that may need to be co-evolved since they are still valid constraints.

In the following we propose to co-evolve non-impacted OCL constraints with resolutions that are associated to Pull property and Extract super class. In fact, these two changes have the intention to make the properties more accessible to all subclasses. So while a constraint would stay valid, there could suddenly be instances of the property that are no more under the constraint that before did hold for all instances of the property. Thus, the additional knowledge of these two changes can be valuable to co-evolve OCL constraints that use a pulled property or a property extracted in the superclass.

Pull Property

This change consists in an add of a property p in a superclass A and its deletion in subclasses B 1 ,..., B n .

Id : #S18 Context : n/a
Location in the constraint : n/a Description : The context of the constraint is updated, by changing the subclass B i to the superclass A. This will make the constraint applicable to the superclass and all subclasses. context B i ::p j init: exp => context A::p j init: exp context B i inv: Exp.p j .restExp => context A inv: Exp.p j .restExp

The above resolution #S18 should be applied if the constraint uses only the pulled property p from the subclass and does not use other properties that are not pulled from B 1 ,..., B n . Otherwise, the constraint would become invalid since other non-pulled properties are missioning in the superclass.

Extract Super Class

This change consists of an addition of a set of properties p 1 , ..., p n in a superclass A, and their deletion in the subclasses B 1 ,... B n . The superclass A is a newly added class. This change can be seen a group of pull properties from B 1 ,... B n to A, after adding A. For this change, the resolution strategy is the same as #S18.

Table 4 presents the resolutions that are associated to non-impacting metamodel changes. In the evaluation section, we will further assess whether the resolution #S18 is used in our case studies. This resolution is proposed to the user in the same manner the resolutions of Table 3 are proposed to the user. The next section illustrates the process of proposing the appropriate resolutions for each impacted OCL constraint.

Proposing Resolution Strategies

In our approach we dene and implement a set of resolutions that can be applied during co-evolution. The resolutions and inuencing factors were co-jointly dened in section 3.4. Figure 4 depicts our process of selecting the appropriate resolutions. It starts with all implemented resolutions and excludes a subset of resolutions based on the inuencing factors. The nal subset of applicable resolutions is then proposed to the user. The rst factor we consider to exclude resolutions is the metamodel change that reduces the possible applicable resolutions (step 1). For example, if we encounter a rename change we exclude the resolutions dened for other metamodel changes. After that, the impacted location is considered to also reduce the subset of the possible applicable resolutions (step 2). Finally, the context of the impacted constraint allows us to further reduce the resolutions to a nal subset (step 3) that is proposed to the user who decides which one to apply. This answers the requirement R3. A constraint can be impacted in dierent parts, i.e. dierent AST nodes, by either the same or dierent metamodel changes. The process of Figure 4 is applied for each impacted part of an OCL constraint, i.e. for each tuple of {impacted OCL constraint × impacted AST node}.

Note that when a constraint is impacted by several metamodel changes, the resolutions are proposed and applied following the chronological order of the changes (detected in section 3.1). It ensures consistency in the coevolution. For instance, suppose the OCL expression "self.p ≥ 0" is impacted by a move property p through a reference ref, followed by a rename p to p'. If the resolutions associated to the metamodel changes (respectively #S9 and #S1) are applied following the order of the changes, the constraint is correctly co-evolved (I) by rst extending the navigation path of the property p before to be renamed. However, if the resolution #S1 is rst applied, then #S9 cannot be applied (II) since p is no longer present in the constraint.

self.p ≥ 0 ⇒ self.ref.p ≥ 0 ⇒ self.ref.p' ≥ 0 (I) self.p ≥ 0 ⇒ self.p' ≥ 0 (II)
To remain exible and to not introduce unintended solutions, our approach also proposes the possibility to ignore (in Figure 4) the proposed resolutions.

Automated Application of the Constraints' Resolutions

At this stage, we can propose, for each impacted part of an OCL constraint, a set of resolution strategies among which the user can choose. A resolution updates the AST by adding, removing, or updating nodes. Each resolution is implemented as a transformation function applied on the ASTs. Figure 5 depicts the co-evolution of the rst constraint in Figure 2c to the rst constraint in Figure 2d at the AST level. The identied impacted AST node by the push property depth is represented with an arrow labeled "impacts" in Figure 5.

Some resolutions can be applied directly on the impacted AST node such as for a rename. Other resolutions can be applied on a subtree composing the OCL subexpression that includes the impacted AST node. The resolution for the pushed property depth cannot be applied on the AST node AttributeCallExp of depth alone. To this end, the rst OCL subexpression in the AST containing the impacted AST node is identied on which the resolution strategy is applied locally.

In Figure 5, the subtree on which the resolution #S13 applies is surrounded by the dashed square. The resolution is represented by the gray nodes, and it consists in introducing an If expression that tests whether the current instance of the container is of type Composite. The Then branch contains the found subtree while introducing a conversion to Composite before to call the property depth.

As stated earlier, complex situations can occur when a single constraint is impacted several times requiring dierent resolutions. Although the resolutions are applied following the order of impacting changes, the user still controls which resolutions are applied among the alternative possible ones and hence controlling the possible complexity of the co-evolution process. Nonetheless, no complex co-evolution occurred in our evaluation although some constraints were impacted by several changes.

Improvement and Optimization of the Co-evolution

Throughout this section, except for the delete changes where we delete OCL constraints, we aim at resolving and maintaining the impacted OCL constraints. Nevertheless, the user may as well decide to delete an impacted constraint instead of maintaining it, for example by applying a rename strategy. Therefore, in the evaluation section, we will estimate whether proposing the delete strategy #S2 whenever an OCL constraint is impacted could increase the percentage of co-evolution w.r.t. the user intent.

Furthermore, in our co-evolution approach, after the user has chosen the resolution to be applied for each constraint, we rst apply the delete resolutions #S2 before we apply the rest of the resolutions while following the chronological order of the changes as explained in section 3.6. In case a constraint is impacted by a delete and another metamodel change, this optimization allows us to not apply the additional resolution on the already deleted constraint, and thus improving the performances.

Implementation

Our tool manipulates Ecore/EMF metamodels and OCL les for the constraints. After identifying the metamodel evolution trace with the detection tool, the impact analysis on the OCL constraints is performed and for each impacted part we propose alternative resolutions. The user can then choose the appropriate resolution among the proposed ones or can decide to apply none of them. Then, our co-evolution engine applies the chosen resolution for each impacted part of an OCL constraint at the AST level. The core functionalities of this component are implemented with Java (4568 LoC) and are packaged into an Eclipse plugin that is chained with the detection plugin [START_REF] Khelladi | Detecting complex changes and refactorings during (meta) model evolution[END_REF][START_REF] Khelladi | Ad-room: a tool for automatic detection of refactorings in object-oriented models[END_REF].

Figure 6 displays a screenshot of our tool. Window (1) shows the OCL constraints that are co-evolved. In window (2) we present the impacted constraints and the cause of the impact in a textual message (the metamodel change and the location of the used element). In Window (3) a set of resolutions is proposed in a dropdown menu to the user along with the ignore option. Then, each resolution is applied to each impacted part of an OCL constraint.

Evaluation of the OCL constraints' co-evolution

This section presents a qualitative evaluation of our co-evolution approach. We rst present our dataset and the evaluation process we follow. Then, we present the co-evolution of OCL constraints as it occurred in practice. After that, the co-evolution results when using our approach are illustrated. Finally, we compare our results against the ones in practice. Time performances of the co-evolution are measured as well.

Throughout this evaluation, we set three goals that are the following: #G1: Demonstrate that alternative resolutions are required in practice. #G2: Show that our 18 resolutions reach most of the user's needs. #G3: Show that the set of initial metamodel changes we support already allows handling a realistic co-evolution scenario.

Dataset

At this stage of our research, we aim at validating empirically on 6 real case studies namely: Unied Modeling Language Class Diagram (UML CD) [START_REF] Omg | Object management group. unied modeling language[END_REF], Structured Metrics metamodel (SMM) [START_REF] Omg | Structured metrics metamodel[END_REF], Unied Prole for DoDAF/MoDAF (UPDM) [START_REF] Omg | Unied prole for the department of defense architecture framework (dodaf) and the ministry of defence architecture framework (modaf)[END_REF], UML Prole for National Information Exchange Model (NIEM) [START_REF] Omg | Uml prole for national information exchange model[END_REF], the EXPRESS Information Modeling Language (EXPRESS) [START_REF] Omg | Reference metamodel for the express information modeling language[END_REF], and the Requirements Interchange Format (ReqIF) [START_REF]Requirements interchange format[END_REF].

In this evaluation, we have studied variety of metamodels of modeling languages from the OMG standards to metamodel proles that are proposed by the OMG [START_REF] Omg | Object management group[END_REF]. We were interested in nding in practice OCL constraints that are co-evolved manually in at least two versions so that we can compare them to our semi-automatic co-evolution of the same constraints. In so doing, we show the capability of our current approach of OCL co-evolution. We collected the OCL constraints from the dierent versions. We put the constraints into a canonical form, e.g. by adding the keyword "self" to remove any ambiguity. We also corrected errors in some constraints.

Since we rely on metamodel change for the co-evolution, we also manually studied the evolution of the dierent metamodels UML CD, SMM, UPDM, NIEM, EXPRESS, and ReqIF to determine the atomic and complex changes. Thus, in our evaluation we re-applied those changes on the original metamodel to detect them with our tool [START_REF] Khelladi | Detecting complex changes and refactorings during (meta) model evolution[END_REF]. This particular aspect will be discussed as a threat to validity. Alternatively, those changes can also be detected with a dierence-based technique (e.g., EMF Compare [START_REF] Toulmé | Presentation of emf compare utility[END_REF], UMLDi [START_REF] Xing | Umldi: an algorithm for object-oriented design dierencing[END_REF], or DSMDi [START_REF] Lin | Dsmdi: a dierentiation tool for domain-specic models[END_REF] etc.). Table 5 shows the selected case studies and the number of the OCL constraints in each of the studies version.

Process of the Evaluation

To run this experiment, we rst detect atomic and complex changes that occurred in the metamodels' evolution from version n until version n+1. After that, based on the evolution changes we identify the impacted OCL constraints and we co-evolve them from version n until version n+1 as well.

In this experiment, we measured the accuracy of our co-evolution tool by comparing for the same set of constraints how they are manually co-evolved in practice against how they are automatically co-evolved by our tool. This allows us to measure the precision of our co-evolution approach.

Furthermore, we will assess whether our resolution strategy #S18 can be helpful to co-evolve non-impacted OCL constraints. Finally, we also evaluate whether always proposing the delete strategy #S2 among the alternative ones would increase the co-evolution percentage (i.e., whether it is useful).

Co-Evolution Results as Occurred in Practice

As a rst step of our evaluation, we studied how the OCL constraints are manually co-evolved in practice in response to the metamodel evolution. In order to study how the OCL constraints are co-evolved accordingly in practice, we followed the next procedure: Identify non-impacted constraints in the original version that are present in the new version.

Identify non-impacted constraints in the original version that are deleted in the new version.

Identify impacted constraints in the original version that should be co-evolved.

For these impacted constraints, we systematically verify in the new version whether it exists a constraint that:

Has the same objective. We judge based on the comments describing the constraint's purpose (given in the specication). We also check returned type equality.

Has the same structure, using similar OCL operators, and/or using the same metamodel elements.

Final decision is made manually:

1. If no constraint is found, we consider the impacted constraint to be deleted. 2. If a constraint is found, we consider it to be the co-evolved version of the impacted constraint.

Identify new constraints added in the evolved version.

The results of our analysis are given in Table 7. It gives the number of non-impacted and impacted constraints fro each case study.

Co-Evolution' Results by our Approach

We rst detected with our tool the evolution traces of the UML CD, SMM, UPDM, NIEM, EXPRESS, and ReqIF metamodels that are given as input to our co-evolution tool. In the experiment, the authors play the user role by selecting the resolutions to apply. We aimed at co-evolving the OCL constraints as close as possible to the co-evolution in practice while also avoiding the use of the ignore solution (for an objective comparison in the next section). The goal is to assess to what extent our approach can get near to the user intent when co-evolving OCL constraints. Hence, after that we could compare to what extent our approach cover the manual co-evolution of our case studies. Note that we did not apply randomly the resolutions. The results of our applied co-evolution are presented in Table 8 that will be compared to the results of Table 7 in the next section. Table 6 displays the applied resolution strategies for each case study during our co-evolution. In most of the case studies, several constraints are impacted by more than one metamodel change. Thus, more than one resolution is applied for several constraints, in particular in the UML CD, SMM, and EXPRESS case studies. For instance, the rename #S1 (see Table 3) is applied several times along with #S1, #S3, #S9 #S12, #S13, #S15, or #S16 on the same constraint. As mentioned previously in section 3.6, the resolutions are applied following the chronological order of the detected metamodel changes in the evolution trace. Since the authors evolved themselves the metamodels, the applied order of changes may have an inuence on the co-evolved constraints. For the constraints that were impacted by multiple changes, we investigated whether changing the order of changes can lead to dierent versions of co-evolved constraints (e.g., comparing the eect of a rename + move and move + rename changes). This was not the case in our case studies, where changing the order of changes (and applying the resolutions in accordance to each of the dierent orders) resulted in the same constraints. This means that using a dierence-based technique to detect the changes would not aect the co-evolution result in our case studies. Nonetheless, we cannot generalize it to other case studies. Note that apart from the above cases we did not face complex situations where an impacted constraint was not co-evolved properly.

Performances.

Similarly as for the detection, we ran our experiment on a PC VAIO with an i7 1.80 GHz Processor and 8GB of RAM on Windows 7. The evaluation experiment using our approach for OCL co-evolution returned instant runs. In particular, after selecting the resolutions to be applied among the proposed ones, all impacted OCL constraints were co-evolved in less than 1 second in each of the case studies.

Comparison of the observed and obtained Results: "in Practice" VS "our

Approach" This section discusses the evaluation's results and compares the observed co-evolution in practice with the obtained OCL co-evolved constraints by our tool.

UML CD case study

Following the procedure described in section 3.2 we were able to identify all the 54 impacted constraints. Deleted constraints. Among those 54 constraints, 28 constraints are co-evolved by deletion. Indeed, some properties and/or classes used in those 28 constraints were deleted during the metamodel evolution. Those 28 deleted constraints were also deleted in the real case study, i.e. they are included in the 35 deleted constraints in practice.

constraints. Using our approach we co-evolved 26 constraints with various resolutions as displayed in Table 6. Among those 26 constraints, 19 constraints are co-evolved in our approach that correspond to the 19 co-evolved constraints in practice. Moreover, 7 constraints are coevolved in our approach and correspond to the 7 impacted constraints that were deleted in practice.

Regarding the 19 constraints that are co-evolved with our tool, 11 coevolved constraints are syntactically equal to 11 of the the 19 constraints that resulted from the co-evolution in practice. Additional 4 constraints are not syntactically but are semantically equal to 4 of the 19 constraints that are co-evolved in practice. Thus, 15 constraints have been correctly co-evolved using our tool. E.g. one denition "def: allConnections: ..." is changed to "def: allConnections(): ..." by adding the "()" in practice.

However, the last 4 constraints are non-syntactically and non-semantically matching. They are refactored in practice with a dierent semantic. For example, one original constraint that checks absence of circular inheritance is impacted by the renaming of GeneralizableElement to PackageableElement. It is co-evolved by our approach as follows from (1) to (2) by applying the rename strategy #S1. context GeneralizableElement inv: not self.allParents()-> includes(self) (1) context PackageableElement inv: not self.allParents()-> includes(self) [START_REF] Andova | Mde basics with a dsl focus[END_REF] In practice the context of constraint (2) was changed to the subclass Classifier instead of applying a rename. Therefore, the semantic is slightly changed by the manual co-evolution since the applicability scope of the new constraint is reduced to elements of type Classifier. The rates of both syntactically and semantically correct co-evolution are respectively 72% and 80% 5 .

Maintained constraints. In our approach, 7 impacted constraints (referred to them later as A ) are co-evolved whereas they were deleted in practice . We applied 8 times the rename strategy #S1 for six of the constraints and 1 time the strategy #S16 of an inline class for one constraint. Thus, only 35% (19/54) of the impacted constraints are maintained in practice, while 48% (26/54) of the impacted constraints are maintained in our approach. For example, constraint ( 3) is an operation dened on a ModelElement returning a set of all direct suppliers of the ModelElement; it is impacted by the rename of ModelElement to NamedElement. We co-evolved it to (4) simply by applying the rename strategy #S1. Set(NamedElement) = self.clientDependency.supplier Furthermore, we noticed the deletion of 12 non-impacted constraints (referred to them as B ). For example, constraint [START_REF] Büttner | Towards transformation of integrity constraints and database states[END_REF] expressing that an interface can only contain operations is deleted although it is not impacted.

context Interface inv: [START_REF] Büttner | Towards transformation of integrity constraints and database states[END_REF] self.allFeatures()->forAll(f | f.oclIsKindOf(Operation))

SMM case study

Following the procedure described in section 3.2 all the 12 impacted constraints were identied and successfully co-evolved. Deleted constraints. Only 1 constraint is co-evolved by deletion due to the delete class RecursiveMeasureRelationship.

Undeleted constraints. Our tool also co-evolved 11 constraints that are impacted by several renames of properties and/or classes, and by one extract class. Those 11 constraints correspond to the 11 manually co-evolved constraints in practice. 9 co-evolved constraints are syntactically equal to 9 of the the 11 constraints that resulted from the co-evolution in practice.

However, 2 constraints are non-syntactically and non-semantically matching. Those 2 constraints are modied and further refactored in practice. For example, the following constraint ( 6) is impacted by an extract class of the property measurand from class Measurement to ObservedMeasure through the reference observedMeasure, and by the rename of measurand to measure. It is co-evolved by our tool as follows from ( 6) to ( 7) by extending the navigation path of measurand to observedMeasure.measurand (i.e. #S9) before renaming the property (i.e. #S1). Note that this constraint is impacted in three locations by the same above changes, and thus each of #S9 and is applied three times. context RescaledMeasurement inv: [START_REF] Cabot | Automatic integrity constraint evolution due to model subtract operations[END_REF] self.measurand.oclIsTypeOf(RescaledMeasure) and self.isBaseSupplied implies not self.baseMeasurement->isEmpty() and (self.baseMeasurement.measurand = self.measurand.baseMeasure) context RescaledMeasurement inv: [START_REF] Cabot | Transformation techniques for ocl constraints[END_REF] self.observedMeasure.measure.oclIsTypeOf(RescaledMeasure) and self.isBaseSupplied implies not self.baseMeasurement->isEmpty() and (self.baseMeasurement.observedMeasure.measure = self.observedMeasure.measure.baseMeasure) In practice the property baseMeasurement in the constraint ( 7) is replaced by the property rescaleFrom, resulting in a semantically dierent constraint. Thus, both the rates of syntactically and semantically correct co-evolution are 83%.

UPDM case study

We identied all the 12 impacted constraints in the UPDM case study following the procedure of section 3.2.

Deleted constraints. Among the 12 impacted constraints, 9 constraints are co-evolved by deletion, mainly due to a delete of several classes (e.g. PhysicalLocation, OrganizationalExchange, OperationalNode, ArtifactResourceArtifact).

Undeleted constraints. Our approach also co-evolved 3 constraints by applying three times the rename resolution #S1. For instance, the constraint (8) is co-evolved to [START_REF] Demuth | Automatically generating and adapting model constraints to support co-evolution of design models[END_REF] The impacted OCL constraints are co-evolved similarly in our tool as in practice. Thus, both the rates of syntactically and semantically correct co-evolution are 100%.

NIEM case study

Following the procedure described in section 3.2 all the 15 impacted constraints were identied and successfully co-evolved.

Deleted constraints.

In the NIEM case study, all 15 impacted constraints are co-evolved by deletion due to a delete of sev- Undeleted constraints. Only 1 constraint is co-evolved with a rename resolution #S1 due to a rename of the property maxlength to maxLength. The impacted OCL constraints are co-evolved similarly in our tool as in practice. Thus, both the rates of syntactically and semantically correct co-evolution are 100%.

Discussion

This section presents a comparison with the existing works and discusses the evaluation results and observations.

Comparison with existing co-evolution approaches

In this work, we proposed an approach for OCL constraints' co-evolution when the metamodel evolves. Table 9 highlights the results of the measured co-evolution percentages. For four case studies, we reached 100% coevolution percentage, whereas in UML CD and SMM, we had respectively 72%, 80% and 83% of co-evolution percentage. An average of 92% (syntactically) and 93% (semantically) co-evolution equivalent to the actual co-evolved constraints. These results show that our approach can support the user with a co-evolution near to her intent and needs.

Furthermore, we wanted to compare our work with existing approaches. In particular, to compare the co-evolution percentage of the dierent approaches on our case studies. We simulated the co-evolution of each approach on our case studies based on the clear content of the paper and the following procedure:

1. We identied the considered changes and proposed resolutions for each existing approaches.

2. For all impacted constraints in our case studies, we assessed whether they can be co-evolved by the existing approaches, i.e., whether they are detected and most importantly whether they can be resolved. 3. If no, the impacted constraints are considered as non co-evolved.

4. If yes, we co-evolve manually the impacted constraints as it is described in the exiting approaches (i.e., their respective papers).

5. We nally computed the co-evolution percentage for all existing works.

Following the above procedure we simulated the automatic co-evolution of the existing works and computed their co-evolution percentages. Table 10 shows the comparative results. Note that if a change C is not addressed by an existing approach, we classify the impacted OCL constraint by the change C as not co-evolved. For example, Hassam et al. [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF] did not consider the changes delete and rename elements and did not proposed resolutions for them, although mentioned in [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF]. Thus, impacted constraints by delete and rename elements are counted as non-co-evolved in this case, which is why Hassam et al. [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF] reached 0% in some of our case studies where OCL constraints were only impacted by delete and rename changes. Table 10 shows that our reached co-evolution percentage exceeds the one simulated for the existing approaches if they were used on the same case study. Overall results shows the benet of our approach, although we cannot generalize the comparative observations. Further comparison of the existing approaches will be discussed in the related work section 6. 5.6.2. Alternative resolutions, maintained and non-necessary deleted constraints In the following we discuss the observed results in our evaluation. First of all, as shown in Table 6, multiple resolutions are used for the metamodel changes push property (#S12, #S13) and inline class (#S15, #S16), in particular for UML CD. These results emphasize and conrm the usefulness to propose alternative resolutions in order to cope with realistic scenarios of OCL constraints' co-evolution. Otherwise, not considering them would reduce the co-evolution percentage with a risk of introducing inappropriate solutions.

Moreover, we observed interesting 7 cases of maintained constraints A by our tool in the UML CD. From our point of view, it is surprising to delete a constraint, whereas it would have been possible to rename the impacted element or to apply another resolution. One possible explanation is that the constraints became meaningless in the new version of the metamodel. Another arguable explanation is that the lack of a (semi) automated support for co-evolution was the cause of the loss of those constraints. Otherwise, they would have been easily maintained in the new version. Those rst 7 cases of maintained constraints A in the UML CD underline the need to also propose the delete strategy #S2 whenever a constraint is impacted, and not always try to maintain the constraint.

We also observed cases of unnecessary removals of constraints that were not impacted. The second 12 cases of deleted constraints B in UML CD and 23 deleted constraints C in NIEM are examples of unnecessary removals. Similarly, a possible explanation is that those constraints are no more necessary. As a further investigation, we had a look at later versions of UML CD specications (versions 2.1, 2.2, and 2.3), and the constraints are indeed missing 6 . Those cases B and C emphasize the fact that even if all impacted constraints are correctly co-evolved, user intervention would still be needed to decide whether to keep or to remove some of the non-impacted constraints.

As mentioned in section 3.8, we also are interested to assess whether always proposing the delete resolution would increase the co-evolution percentage. In our case studies, apart from the UML CD, the co-evolution percentage in the rest of the case studies remain unchanged. However, in the UML CD by deleting the 7 maintained constraints A instead of co-evolving them, the co-evolution percentage signicantly improves from 72% to 85% of syntactically correct co-evolution 7 , and from 80% to 93% of semantically correct co-evolution 8 . This conrms our hypothesis that always proposing the resolution #S2 among the existing alternatives can be benecial for the user in some cases when used appropriately.

Semantically not matching constraints

It is worth noting that the cases of the semantically not matching constraints obtained in UML CD (e.g. constraint [START_REF] Aichernig | Test case generation by ocl mutation and constraint solving[END_REF]) and in SMM (e.g. constraint ( 6)) underline the need to let the user ignore a proposed co-evolution. By not applying a particular resolution, the user can manually co-evolve it and further refactors it w.r.t. her intent. We further analyzed these cases of semantically not matching constraints to understand the reasons. We observed two reasons 1) either the context was changed or 2) new OCL subexpression with new elements are added to the constraints. The former could be handled by changing the context. However, navigation paths must be carefully updated to still access the properties in the old context, as we do in resolution #S8 (see section 3.4). This issue is detailed and addressed by Cabot et al. [START_REF] Cabot | Transformation techniques for ocl constraints[END_REF]. The latter, on the contrary is hard to be handled automatically by a co-evolution approach. The new added parts are the result of the engineering knowledge that cannot be grasped only with the metamodel changes during evolution. Manual intervention remains necessary in this case.

Non-impacted constraints and refactorings

Furthermore, in our case studies we also studied the non-impacted OCL constraints to evaluate whether they were refactored and changed. Table 11 shows the number of refactored non-impacted OCL constraints that we encountered in our case studies.

Among the non-impacted OCL constraints one constraint in the SMM case study was refactored with the resolution #S18 that we proposed in Section 3.5. Indeed, a complex change Extract super class occurred from the class RankingInterval to Interval. The constraint [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF] was refactored to [START_REF] Hemel | Code generation by model transformation[END_REF] Moreover, in UML CD, UPDM, NIEM, EXPRESS case studies, several cases of non-impacted constraints' refactoring were observed. For instance, in the EXPRESS case study the constraint [START_REF] Herrmannsdoerfer | Cope-automating coupled evolution of metamodels and models[END_REF] expressing that there should be a unique instance of Indeterminate, was refactored to [START_REF] Herrmannsdoerfer | Language evolution in practice: The history of GMF[END_REF].

context Indeterminate derive: [START_REF] Herrmannsdoerfer | Cope-automating coupled evolution of metamodels and models[END_REF] self = Indeterminate.allInstances()->asOrderedSet()->at [START_REF] Aichernig | Test case generation by ocl mutation and constraint solving[END_REF] context Indeterminate derive: [START_REF] Herrmannsdoerfer | Language evolution in practice: The history of GMF[END_REF] Indeterminate.allInstances()->size() = 1 Another type of refactoring was observed in the NIEM case study where several constraints were merged into a single one. For example, the constraint (17) and ( 18) were refactored to [START_REF] Jordi | Object constraint language (OCL): A denitive guide[END_REF] by merging them with the logical operator "and". context Union derive: [START_REF] Herrmannsdoerfer | An extensive catalog of operators for the coupled evolution of metamodels and models[END_REF] self = self.base_DataType.generalization->isEmpty() context Union derive: [START_REF] Hutchinson | Empirical assessment of mde in industry[END_REF] self.base_DataType.ownedAttribute->isEmpty() context Union derive: [START_REF] Jordi | Object constraint language (OCL): A denitive guide[END_REF] self.base_DataType.attribute->isEmpty() and self.base_DataType.generalization->isEmpty() At this stage of our research, we only observed those refactorings, but we still lack enough case studies to better understand the reasons of those refactorings and their benets. Nevertheless, we can observe that some refactorings changed the semantic of the constraint whereas others did not. For example, the constraint (15) in the specication document aimed at express-ing the uniqueness of the Indeterminate's instance. However, the original constraint checks only that the current instance is equal to the rst instance in the set of all instances of Indeterminate class. This constraints does not verify the uniqueness characteristic. Therefore, the constraints was refactored to [START_REF] Herrmannsdoerfer | Language evolution in practice: The history of GMF[END_REF] to clearly express that there is only one instance of Indeterminate class. As a future work, this refactoring can be captured as a pattern to be reused in other case studies, but there is no guarantee of its usefulness in practice. As for the constraints ( 17) and [START_REF] Hutchinson | Empirical assessment of mde in industry[END_REF], this refactoring could be applied to all constraints that share the same context. Yet this refactoring may be explained by the dierent writing styles of the software engineers, since both constraints ( 17) and ( 18) are equivalent to [START_REF] Jordi | Object constraint language (OCL): A denitive guide[END_REF].

In this paper we mainly focused on co-evolving impacted OCL constraints so they can be reused in the evolved metamodel version. These cases of non-impacted constraints' co-evolution emphasize the need to examine the challenging topic of co-evolving non-impacted OCL constraints.

Threats to Validity

We now discuss internal, external, and conclusion threats to validity after Wohlin et al. [START_REF] Wohlin | Experimentation in software engineering[END_REF] w.r.t. our three evaluation goals #G1, #G2, and #G3.

Internal Validity.

During the analysis of the co-evolution of the OCL constraints in practice, it is possible that we could have missed a correspondence between an original constraint and a co-evolved constraint when the latter is subject to a strong refactoring. To reduce this risk, in the procedure of our analysis for each impacted constraint, we investigated the constraints of the new versions one by one to avoid missing any correspondence. Moreover, other complex changes than the 7 ones we considered may occur in the evolution requiring additional resolutions that are not in our 18 resolutions. However, in our evaluation the 7 complex changes we considered as well as the 18 resolutions were sucient in our case studies.

Furthermore, in our evaluation the authors played the user role by selecting the resolutions to be applied during the co-evolution of the OCL constraints. This would deliver better results since the authors are familiar with the case studies. However, as our goal was to assess to what extent our approach can get near to user intent when co-evolving OCL constraints, we aimed at reproducing the user intention with our resolutions as closely as possible. Hence, after that we could compare to what extent our approach covers the user manual co-evolution in our case studies. Therefore, this threat is acceptable here.

External Validity.

We evaluated our tool on six case studies of metamodels and their OCL constraints. However, it is dicult to generalize our obtained results for other metamodels and OCL constraints. Nonetheless, the UML CD, SMM, UPDM, NIEM, EXPRESS, and ReqIF case studies provided a representative and a complex evolution trace that had a signicant impact on the OCL constraints. In future work, we plan to evaluate our approach on an industrial case study that will be provided by our industrial partners.

Conclusion Validity.

Our evaluation gives promising results demonstrating that alternative resolutions are used in real life cases. The results also indicate that our 18 resolutions are semantically close to the user needs during the co-evolution. Thus, our evaluation's results meet our goals #G1 and #G2. However, we cannot estimate the quality of the resolutions only based on our six case studies. Third goal #G3 is also met since our co-evolution tool covers all metamodel changes that occurred in the evolutions of our case studies. Yet, more experiments are necessary to retrieve a more precise measure of the resolutions' quality, their occurrence frequency, and the benet of the ignore option in practice.

Related Work

In this section, we present the main approaches that co-evolve OCL constraints and we discuss them w.r.t. our current work.

Demuth et al. [START_REF] Demuth | Automatically generating and adapting model constraints to support co-evolution of design models[END_REF][START_REF] Demuth | Supporting the coevolution of metamodels and constraints through incremental constraint management[END_REF] proposed an approach for OCL co-evolution based on templates. They provided 11 templates that dene a xed structure for OCL constraints. The templates are then re-instantiated to generate the co-evolved OCL constraints. However, their approach is not applicable for arbitrary OCL constraints, and is limited to 11 templates only. They do not handle metamodel changes that impact the structure of the constraints. The impact analysis and the co-evolution of the 11 templates (i.e. constraints) is performed during the metamodel evolution after each change.

Hassam et al. [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF] proposed a tool METAEVOL to co-evolve OCL constraints using Query/View/Transformation (QVT) [START_REF] Omg | Object management group. query / views / transformations (qvt)[END_REF], a transformation language. The impact analysis is performed during the metamodel evolution, however, the OCL co-evolution is done at the end. To manage the constraints states, i.e. whether they are impacted and whether they are coevolved, an intermediate table is used for this purpose. However, it is unclear whether the metamodel changes are recorded at run-time, or are manually specied by the user.

Markovic et al. [START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF] proposed to refactor, based on QVT, OCL constraints annotated on UML class diagrams when these last evolve. Although their approach focuses on the model level with UML class diagrams, the theoretical basis also apply for OCL constraints dened on metamodels. This approach, proposes to apply a refactoring of the UML CD and immediately after it a co-evolution of the impacted OCL constraints.

Kusel et al. [START_REF] Kusel | A systematic taxonomy of metamodel evolution impacts on ocl expressions[END_REF] rst analyzed the impact of metamodel evolution on OCL expressions, and then proposed to resolve the impacted OCL expressions in [START_REF] Kusel | Systematic co-evolution of ocl expressions[END_REF]. However, they do not consider an OCL constraint as a whole but only its body. In particular, the context is ignored whereas it can be the impacted part (by a rename class for example) that requires a resolution.

Cabot et al. [START_REF] Cabot | Automatic integrity constraint evolution due to model subtract operations[END_REF] focused on a single metamodel change, the delete element. In particular, they aimed at preserving the impacted constraints instead of deleting them, by removing only a sub part of the OCL constraint that is using the deleted element. However, the approach is applicable only to OCL constraints written in the form of Conjunctive Normal Form (CNF). In addition, Cabot et al. [START_REF] Cabot | Transformation techniques for ocl constraints[END_REF] studied the dierent possibilities of changing the constraint's context while maintaining the constraints.

Buttner et al. [START_REF] Büttner | Towards transformation of integrity constraints and database states[END_REF] discussed the impact of changing the multiplicity of a property in the metamodel on OCL constraints, which is addressed in our resolutions (see section 3.4). In addition, transformation languages like ATL share many similarities with OCL, and hence co-evolution approaches such as Garcia et al. [START_REF] García | Model transformation co-evolution: A semi-automatic approach[END_REF] can be to a certain extent similar to OCL co-evolution.

Three OCL co-evolution approaches are oine9 [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF][START_REF] Kusel | Systematic co-evolution of ocl expressions[END_REF][START_REF] Cabot | Automatic integrity constraint evolution due to model subtract operations[END_REF] including ours, and two are online10 approaches [START_REF] Demuth | Automatically generating and adapting model constraints to support co-evolution of design models[END_REF][START_REF] Demuth | Supporting the coevolution of metamodels and constraints through incremental constraint management[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF]. Note that oine coevolutions, including ours, do apply an oine impact analysis 11 . Similarly with online co-evolutions that apply an online impact analysis 12 . Hassam et al. [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF] is the unique oine co-evolution approach that applies an online impact analysis.

As shown in Table 12 among the existing approaches only [START_REF] Demuth | Automatically generating and adapting model constraints to support co-evolution of design models[END_REF][START_REF] Demuth | Supporting the coevolution of metamodels and constraints through incremental constraint management[END_REF][START_REF] Kusel | Systematic co-evolution of ocl expressions[END_REF]] consider all atomic changes, whereas [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF][START_REF] Cabot | Automatic integrity constraint evolution due to model subtract operations[END_REF] consider a subset of atomic changes only. In this work, we also consider all set of atomic changes.

Moreover, only [START_REF] Demuth | Automatically generating and adapting model constraints to support co-evolution of design models[END_REF][START_REF] Demuth | Supporting the coevolution of metamodels and constraints through incremental constraint management[END_REF][START_REF] Cabot | Automatic integrity constraint evolution due to model subtract operations[END_REF] do not consider complex changes. The complex changes that are considered by the rest of the approaches diers for each of them [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF][START_REF] Kusel | Systematic co-evolution of ocl expressions[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF], as highlighted in the fth column of Table 12. In our work we initially consider seven well-known and most used complex changes (see section 3.1).

Regarding the degree of automation, Demuth et al. [START_REF] Demuth | Automatically generating and adapting model constraints to support co-evolution of design models[END_REF][START_REF] Demuth | Supporting the coevolution of metamodels and constraints through incremental constraint management[END_REF], Markovic et al. [START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF], and Cabot et al. [START_REF] Cabot | Automatic integrity constraint evolution due to model subtract operations[END_REF] all apply a fully automatic co-evolution. Hassam et al. [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF], Kusel et al. [START_REF] Kusel | Systematic co-evolution of ocl expressions[END_REF], and our current approach are all semiautomatic requiring user decision to conrm which resolutions to apply and whether to apply a resolution.

All existing approaches [START_REF] Demuth | Automatically generating and adapting model constraints to support co-evolution of design models[END_REF][START_REF] Demuth | Supporting the coevolution of metamodels and constraints through incremental constraint management[END_REF][START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF][START_REF] Cabot | Automatic integrity constraint evolution due to model subtract operations[END_REF][START_REF] Büttner | Towards transformation of integrity constraints and database states[END_REF][START_REF] Kusel | Systematic co-evolution of ocl expressions[END_REF] consider only the metamodel change as a factor to propose a resolution. Thus, they dene for each metamodel change only a unique resolution that will be applied to any arbitrary impacted OCL constraint. Only Cabot et al. [START_REF] Cabot | Automatic integrity constraint evolution due to model subtract operations[END_REF] partially addresses the issue of multiple resolutions by either deleting the constraints or just deleting part of them, i.e. the parts using the deleted element. In contrast, we identied two additional factors (see section 2) that lead to propose multiple resolutions. For the application order of resolutions, Demuth et al. [START_REF] Demuth | Automatically generating and adapting model constraints to support co-evolution of design models[END_REF][START_REF] Demuth | Supporting the coevolution of metamodels and constraints through incremental constraint management[END_REF], Hassam et al. [START_REF] Hassam | Assistance system for ocl constraints adaptation during metamodel evolution[END_REF], Markovic et al. [START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF][START_REF] Markovi¢ | Refactoring ocl annotated uml class diagrams[END_REF], and our current approach all rely on the chronological order of the metamodel changes. Kusel et al. [START_REF] Kusel | Systematic co-evolution of ocl expressions[END_REF] and Cabot et al. [START_REF] Cabot | Automatic integrity constraint evolution due to model subtract operations[END_REF] apply the resolution on a random order in comparison to the metamodel changes' order. We further apply a partial optimization by rst applying the deletes before the rest of resolutions. This allows to not apply resolutions to a constraint if it is going to be deleted anyway at the end.

Finally, in contrast to our work, none of the existing approaches addressed the issues of semantically alternative resolutions and the application scope of a resolution on OCL constraints.

To the best of our knowledge, we are the rst to propose alternative resolution strategies while coping with the application scope of the resolutions based on the structure of the impacted OCL constraint and the impacted location.

Conclusion and Future Works

In this paper, we addressed the topic of metamodel and OCL constraints co-evolutions. We proposed a semi-automatic approach to co-evolve OCL constraints with alternative and appropriate resolution strategies. We identied two new factors that lead us to propose alternative resolutions to the user to chose from. We support the user in the application of the appropriate resolutions based on the metamodel changes, the location of the impact in the OCL constraints, and the context. This has the advantage to co-evolve OCL constraints w.r.t. the user intent and to avoid applying unintended resolutions. Our evaluation on six sized case studies of metamodels with their OCL constraints resulted in an average of 92% (syntactically) and 93% (semantically) correct co-evolution is reached in our evaluation.

Although we focused on the co-evolution of OCL constraints dened on top of metamodels, our approach can also handle the co-evolution of OCL constraints dened on top of object-oriented models in general. Thus in future work, we rst aim to evaluate our approach on other applications of OCL constraints such as OCL queries, or OCL scripts that express model transformations and to run a user experiment. We further plan to investigate how the dierent OCL expression types can help in co-evolving the OCL constraints Furthermore, as we proposed to co-evolve non-impacted constraints for the two complex changes Pull property and Extract super class. We thus plan to further investigate the co-evolution of non-impacted OCL constraints and also the topic of OCL constraints refactoring. Finally, as we have proposed a xed set of resolutions, it would be interesting to apply search-based techniques for the OCL co-evolution in order to explore all possible space of solutions.

Figure 1 :

 1 Figure 1: Existence of multiple solutions : An Example.

Figure 2 :

 2 Figure 2: An evolution of a composite pattern and a co-evolution of OCL constraints: An example.

Figure 3 :

 3 Figure 3: Overall Approach.

  context A::p init: self.a*2 => context B::p init: self.r'.a*2 When the moved property p is used in a navigation path, we distinguish two cases of move property : 1) through a single-valued reference and 2) through a multi-valued reference. A) Through a single-valued reference -Id : #S9 Context : n/a Location in the constraint : navigation path Description : The navigation path to the property p is extended with the reference r. Exp.p.restExp => Exp.r.p.restExp B)Through a multi-valued reference -Id : #S10 Context : n/a Location in the constraint : navigation path Description :

Figure 4 :

 4 Figure 4: Process of selecting the appropriate resolution strategies per impacted part of a constraint and per metamodel change.

Figure 5 :

 5 Figure 5: ASTs of the original and co-evolved OCL constraint

Figure 6 :

 6 Figure 6: Screenshot of the Eclipse plugin Tool.

Table 8 :

 8 Co-evolution of OCL constraints by our approachCo-evolution of OCL constraints by our approach

context

  ModelElement def: supplier : (3) Set(ModelElement) = self.clientDependency.supplier context NamedElement def: supplier : (4)

  by renaming the class Location to LocationType. context uml::DataType inv: (8) UPDM::UPDML1::UPDML0::Core::AllElements::Environment:: Location.allInstances()->exists(n|n.base_DataType=self) implies SysML::ValueType.allInstances()->exists(b|b.base_DataType = self) context uml::DataType inv: (9) UPDM::UPDML1::UPDML0::Core::AllElements::Environment:: LocationType.allInstances()->exists(n|n.base_DataType=self) implies SysML::ValueType.allInstances()->exists(b|b.base_DataType = self)

Table 1 :

 1 Impact Identication on OCL constraints.

	Metamodel Elements	OCL Constraints	References to AST Nodes
	e 1	OCL 1 , ...	ref 1 , ref 2 , ...
	e i	OCL j , ...	ref k , ref l , ...
	...	...	...

Table 2 :

 2 Metamodel change impact on OCL constraints.

		Metamodel	Impact on Handled
		changes	OCL	in our
			constraints approach
		Add optional/mandatory class	no	n/a
		Add optional/mandatory property	no	n/a
		Add enumeration/enumeration literal	no	n/a
		Generalize property multiplicity from a set to a larger set	no	n/a
		Restrict property multiplicity	no	n/a
		Add parameter	yes	no
	Atomic	Rename class	yes	yes
	changes	Rename property	yes	yes
		Rename enumeration/enumeration literal	yes	yes
		Rename parameter	yes	yes
		Delete class	yes	yes
		Generalize property multiplicity from zero or one occurrence to a set	yes	yes
		Delete property	yes	yes
		Delete enumeration/enumeration literal	yes	yes
		Delete parameter	yes	yes
		Modify property type	yes	no
		Move property	yes	yes
		Pull property	no	yes
		Push property	yes	yes
	Complex	Extract class	yes	yes
	changes	Inline class	yes	yes
		Extract super class	no	yes
		Flatten hierarchy	yes	yes

  .p.restExp => Exp.p->exists(x|x.restExp)

-Id : #S5 Context : n/a Location in the constraint : navigation path Description : The rst value of the collection of the property p is accessed. Exp.p.restExp => Exp.p->asOrderedSet()->rst().restExp -Id : #S6 Context : n/a Location in the constraint : navigation path Description : The last value of the collection of the property p is accessed. Exp.p.restExp => Exp.p->asOrderedSet()->last().restExp -Id : #S7 Context : n/a Location in the constraint : navigation path Description :

  .p.restExp => Exp.r->forAll(x|x.p.restExp) or Exp.p.restExp => Exp.r->exists(x|x.p.restExp) or Exp.p.restExp => Exp.r->rst().p.restExp or Exp.p.restExp => Exp.r->last().p.restExp or Exp.p.restExp => Exp.r->at(i).p.restExp 3.4.5. Push Property This change consists in a delete of a property p from a superclass A and its addition in subclasses B 1 ,... B n .

  Flatten HierarchyThis change consists of a deletion of a set of properties p 1 , ..., p n from a superclass A, and their addition in the subclasses B 1 ,... B n . Then the superclass A (non-referenced by any other class) is deleted. This change can be seen as a group of push properties from A to B 1 ,... B n , before to delete A.

	-Id : #S16
	Context : n/a
	Location in the constraint : n/a
	Description : When the inlined class B is used as a type, it is
	changed to the target class A where B is inlined.
	3.4.8.
	Id : #S14
	Context : B (container)
	Location in the constraint : -Id : #S15
	Context : n/a
	Location in the constraint : navigation path
	Description : The navigation path to the property p i is reduced
	with the reference r.
	Exp.r.p i .restExp => Exp.p i .restExp

context Description : The context of the constraint is updated, by changing the source class B to the target class A where B is inlined. References from B to A are deleted in exp (if used in exp). context B::p i init: exp => context A::p i init: exp

Table 3 :

 3 Resolutions proposed to co-evolve impacted OCL constraints.

	Metamodel change (Factor 1)	Location in the OCL constraint (Factor 2)	Context (Factor 3)	Resolution strategies	Total N o of proposed resolutions
	Rename element	n/a	n/a	#S1	1
	Delete element	n/a	n/a	#S2	1
	GPM from a single value to multiple values	navigation path	n/a	#S3 #S4 #S5 #S6 #S7	5
	Move property	context navigation path	container n/a	#S8 #S9 #S10	3
		context	container	#S11
	Push property	navigation path	container	#S12	3
		navigation path	not via the subclasses	#S13
	Extract class	context navigation path	container n/a	#S8 #S9	2
	Inline class	context navigation path	container n/a	#S14 #S15 #S16	3
	Flatten hierarchy	n/a	container	#S17	1

Table 4 :

 4 Resolutions proposed to co-evolve non-impacted OCL constraints.

	Metamodel change (Factor 1)	Location in the OCL constraint (Factor 2)	Context (Factor 3)	Resolution strategies	Total N o of proposed resolutions
	Pull property	n/a	n/a	#S18	1
	Extract super class n/a	n/a	#S18	1

Table 5 :

 5 Co-evolution case studies.

		UML CD SMM		UPDM NIEM	EXPRESS ReqIF
		1.5 2.0	3.2.2 3.4.4 1.0 2.1 1.0 3.0 1.0 1.1	1.0 1.1
	Number of OCL constraints	73 110 59	87	29 39 49 135 60 58	26 25

Table 6 :

 6 Number of applied resolutions in our co-evolution for each case study.

	Case studies Applied resolutions	N o of application
		Delete #S2	28
		Rename #S1	34
		Add iterator #S3	2
	UML CD	Push property #S12	1
		Push property #S13	3
		Inline class #S15	3
		Inline class #S16	4
		Delete #S2	1
	SMM	Rename #S1	29
		Extract class #S9	17
	UPDM	Delete #S2 Rename #S1	9 3
	NIEM	Delete #S2	15
	EXPRESS	Delete #S2 Rename #S1	4 3
	ReqIF	Delete #S2 Rename #S1	1 1

Table 7 :

 7 Co-Evolution of the OCL constraints as they occurred in practice.

Table 9 :

 9 Correct Co-evolution Percentage (%).

		UML CD SMM UPDM NIEM EXPRESS ReqIF
	Syntactically correct co-evolution %	72%	83%	100%	100%	100%	100%
	Semantically correct co-evolution %	80%	83%	100%	100%	100%	100%
	Deleted constraints. Only 1 OCL constraints is co-evolved by deletion
	due a delete of the property defaultValue.

Table 10 :

 10 Comparison with existing OCL co-evolution approaches

	Approaches	UML CD 1.5 to 2.0	SMM 1.0 to 1.1	UPDM 1.0 to 2.1	NIEM 1.0 to 3.0	EXPRESS 1.0 to 1.1	ReqIF 1.0 to 1.1
	Demuth et al. [9, 10]	59%	25%	100%	100%	100%	100%
	Hassam et al. [13]	6%	0%	0%	0%	0%	0%
	Kusel et al. [25]	7%-17%	17%	25%	0%	20%	50%
	Markovic et al. [30, 31] 7%-17%	17%	25%	0%	20%	50%
	Cabot et al. [6]	52%	9%	75%	100%	80%	50%
	Current approach	72%-80%	83%	100%	100%	100%	100%

Table 11 :

 11 Number of refactorings on non-impacted OCL constraints.

		UML CD SMM UPDM NIEM EXPRESS ReqIF
	N o or refactorings
	of non-impacted	1	1	2	9	1	0
	constraints

  by changing the context to the superclass. Although the above example shows the usefulness of the resolution #S18, more case studies are required to assess the occurrence frequency of #S18 and it real benet.

	context RankingInterval derive: (13)
	(self.maximumEndpoint >= self.minimumEndpoint) and
	((self.maximumOpen or self.minimumOpen) implies)
	self.maximumEndpoint > self.minimumEndpoint)
	context Interval derive: (14)
	(self.maximumEndpoint >= self.minimumEndpoint) and
	((self.maximumOpen or self.minimumOpen) implies
	self.maximumEndpoint > self.minimumEndpoint)

Table 12 :

 12 Comparison of the dierent approaches that aim at OCL co-evolution. Legend [ : handled, ×:

http://www.omg.org/spec/UML/

http://www.omg.org/spec/BPMN/

http://www.eclipse.org/modeling/gmp/downloads/?project=gmf-tooling

Graphical Modeling Framework http://www.eclipse.org/modeling/gmf.

% = ((deleted constraints + syntactically (respectively semantically) correct coevolved constraints) / impacted constraints)

For NIEM case study no new version is currently available after version 3.0.

85% = ((28 + 7 deleted constraints + 11 syntactically correct co-evolved constraints) / 54 impacted constraints)

93% = ((28 + 7 deleted constraints + 15 semantically correct co-evolved constraints) / 54 impacted constraints)

Oine: The co-evolution is performed after nishing the metamodel evolution.

Online: The co-evolution is performed while evolving the metamodel.

Oine ia: impacted OCL constraints are identied after the metamodel evolution.

Online ia: impacted OCL constraints are identied while evolving the metamodel.

Acknowledgments.

The research leading to these results has received funding from the ANR French Project MoNoGe under grant FUI -AAP no. 15.

eral classes and properties (e.g. ModelPackageDescriptionFile, ModelPackageDescriptionFileSet). Thus, both the rates of syntactically and semantically correct co-evolution are 100%.

Maintained constraints. Furthermore, similarly as in UML CD case study, it is surprising to nd deletion of 23 non-impacted OCL constraints (referred to them as C ). For example, constraint [START_REF] Demuth | Supporting the coevolution of metamodels and constraints through incremental constraint management[END_REF] expressing that the ownedAttributes must have a multiplicity of "0..1" is deleted.

context Choice inv: [START_REF] Demuth | Supporting the coevolution of metamodels and constraints through incremental constraint management[END_REF] self.base_Class.ownedAttribute->forAll(a|(a.lower=0) and(a.upper=1))

EXPRESS case study

In the EXPRESS case study we were able to identify all the 5 impacted constraints by following the procedure of section 3.2.

Deleted constraints. Among the 5 impacted OCL constraints, 4 constraints are co-evolved by deletion, mainly due to the removal of the two properties ofentity and playsdomainrole.

Undeleted constraints. Only 1 constraint is co-evolved from [START_REF] Demuth | Co-evolution of metamodels and models through consistent change propagation[END_REF] to [START_REF] García | Model transformation co-evolution: A semi-automatic approach[END_REF] with a rename resolution #S1 due to a rename of the property formalparameter to forparameter. This constraint is impacted three times by the same change, and hence the resolution #S1 is applied three times on the same constraint. .forparameter endif The impacted OCL constraints are co-evolved similarly in our tool as in practice. Thus, both the rates of syntactically and semantically correct co-evolution are 100%.

ReqIF case study

Following the procedure described in section 3.2 the 2 impacted constraints were identied and successfully co-evolved.