In Model-Driven Engineering (MDE), metamodels and domain-speci c languages are key artifacts as they are used to de ne syntax and semantics of domain models. However, metamodels are evolving over time, requiring existing domain models to be co-evolved. Though approaches have been proposed for performing such co-evolution automatically, those approaches typically support only speci c metamodel changes. In this paper, we present a vision of co-evolution between metamodels and models through consistent change propagation. The approach addressed co-evolution issues without being limited to speci c metamodels or evolution scenarios. It relies on incremental management of metamodel-based constraints that are used to detect co-evolution failures (i.e., inconsistencies between metamodel and model). After failure detection, the approach automatically generates suggestions for correction (i.e., repairs for inconsistencies). Preliminary validation results are promising as they indicate that the approach computes correct suggestions for model adaptations, and that it scales and can be applied live without interrupting tool users.
In Model-Driven Development (MDD) [
Co-evolution of models denotes the process of adapting models as a
consequence of metamodel evolution [
In this paper, we outline a generic approach that does not try to automate coevolution in general, but that detects co-evolution failures and suggests model adaptations to co-evolve a model correctly. In particular, the approach relies on incremental constraint management that allows for e cient detection of coevolution failures (including the absence of co-evolution). If such failures are detected, the resulting inconsistencies between metamodel and model { along with other design constraints imposed on the model { are used for nding suitable model adaptations (repairs) that establish compliance of the model with the updated metamodel and thus lead to correct co-evolution. 2
To illustrate our work, we use a simple metamodel for component-oriented systems with high availability requirements, as shown in Fig. 1(a). Note that, for now, we only consider elements drawn solid { dotted elements indicate evolution which we will discuss later. The metamodel de nes three classes: Component, Domain, and Communication. Components can have an arbitrary number of subcomponents and must belong to a Domain. Domains include components that are responsible for ful lling a common task in the system. Communications occur between a sender and a receiver (rec) component. To increase the chance of a successful communication, di erent components can be speci ed as primary (prim) and as alternative (alt) target of a communication. All possible targets of a communication are aggregated by the derived reference possibleReceivers. Note that the de ned reference cardinalities (e.g., 1 for prim) implicitly de ne model constraints. For example, an instance of Communication must reference exactly one Component via prim. However, to ensure that only intended models can be built, the metamodel has been extended with the following three explicit constraints: R1 All possible receivers of a Communication must be located within a single
Domain (i.e., a set of components with a common purpose).
R2 A communication may only occur between components of di erent component domains.
R3 It is not permitted that a single component is used as primary and alternative target.
Note that we omit other possible domain-speci c constraints as well as implicit syntactical constraints for simplicity reasons.
In Fig. 1(b), a model that complies with the metamodel is depicted. Again, ignore dotted elements for now as they indicate possible evolution which we will discuss later. The derived reference possibleReceivers is omitted for readability reasons. The model contains three domains: X, Y , and Z. Domain X consists of only two components (X1 and X2), Y consists of four components in total (Y 1 { Y 4), and Z consists of two components (Z1 and Z2). The model also contains two communications (C1 and C2), drawn as circles.
Let us now consider a simple metamodel evolution. To increase the availability of systems and reduce the chance of communication failures, a second alternative communication target (called alt2) is added to the metamodel, as indicated by the dotted arrow in Fig. 1(a). Intuitively, this metamodel evolution requires the model in Fig 1(b) to be co-evolved as a new mandatory reference was added to the class Communication that is instantiated twice in the model. While existing approaches can typically nd model adaptations that produce a syntactically correct model { for example, by adding a new reference alt2, which points to an arbitrary Component, to every Communication { such adaptations may easily lead to a semantically incorrect model. In the next section, we will show how our approach handles this scenario and automatically provides user guidance that helps designers to easily nd valid adaptions. 3
To address the issues discussed above, we propose to perform co-evolution through consistent change propagation. The approach consists of two phases: 1. Detect co-evolution failures. 2. Derive options for correction of failures.
In Phase 1, the approach detects locations where co-evolution is not performed correctly. This, of course, includes the situation of plainly missing co-evolution. In Phase 2, options for a correct propagation of the metamodel change to the a ected model are derived. We will now discuss those phases in more detail and also show how the approach is applied to the evolution scenario presented above. 3.1
Although metamodel evolution is likely to require model adaptations, this is not a necessity { a metamodel may also change in ways that do not a ect the validity of existing models. For example, when an optional reference is added. Additionally, models may be changed manually by designers or automatically by tools after a metamodel evolution occurred, trying to co-evolve the model. Therefore, it is necessary after a metamodel change { and subsequent model adaptations { to determine whether an a ected model is consistent with the updated metamodel. If it is, co-evolution was performed correctly and no further intervention is required. If, however, the model is inconsistent with the updated metamodel, co-evolution failed and additional model adaptations are necessary. Constraint Management As we have shown in the running example, constraints can be used for ensuring both syntax and semantics. Therefore, when the metamodel evolves, constraints of both kinds may be a ected. By using an incremental constraint management approach, it is possible to update constraints after metamodel changes { ensuring that models are always validated with constraints that are up-to-date.
In our example, the addition of alt2 in Fig. 1(a) requires a new syntactical
constraint to be enforced on models:
R4 Each Communication must reference a Component via alt2.
Consistency Checking After updating the set of constraints imposed by the
metamodel, standard consistency checkings mechanisms (e.g., [
After adding the new syntactical constraint de ned above, any standard consistency checker will nd that the model in Fig. 1(b) contains two inconsistencies: neither C1 nor C2 provide a second alternative target. Thus, our intuitive assumption that additional model adaptations are necessary for correct co-evolution has been con rmed. 3.2
Once co-evolution failures have been detected, our approach reaches Phase 2 in which those failures are corrected.
Repair Options To correct co-evolution failures and propagate the metamodel
change correctly, it is necessary to nd model adaptations (i.e., repair options)
that transform the inconsistent model into a consistent one. Unfortunately,
nding suitable adaptations is non trivial as every change to a model may not only
eliminate the violation of a constraint, but it may also cause other constraints
to be violated. However, single changes can of course also remove several
inconsistencies at once. Due to those side e ects, nding suitable corrections is a
complex task that should not be performed in an ad-hoc manner. Our approach
employs a reasoning mechanism that takes into consideration all design
constraints present in a model to nd suitable adaptations [
Let us come back to our example. During Phase 1, two inconsistencies caused by the elements C1 and C2 were detected in the model. First, we consider the inconsistency involving C1. To correct the syntax and remove the violation of constraint R4, a reference alt2 to any component is su cient. Moreover, in each domain a new component could be created and used as second alternative target for C1. Of course, it would also be possible to create a new component in an entirely new domain. Therefore, there are 12 options available in total: one for each of the eight existing (i.e., solid drawn) components in Fig. 1(b), one for each of the three domains, and one for a new domain with a new component. However, by also taking into account the domain-speci c constraints R1 { R3 from Section 2, our approach computes side e ects for each of those options. Due to constraint R2, adding either X1 or X2 as second alternative target to C1 is not a valid adaptation as this would violate R2. Additionally, the existing references prim and alt from C1 to components of domain Y disallow the use of any components that belong to a domain other than Y , according to constraint R1. This rules out any remaining options that involve a second alternative receiver in domain Z or in a newly created domain. Finally, constraint R3 disallows Y 1 and Y 2 as options because they are already possible receivers. Note that this means a reduction from 12 options { from which 9 are actually semantically incorrect { to only 3 options that co-evolve C1 correctly. Those are drawn dotted in Fig. 1(b).
For the communication C2, the constraints R1 { R4 can only be satis ed by adding a new component to domain X that is used as second alternative receiver, as indicated by the dotted drawn component X3 in Fig. 1(b). Change Execution Although each derived repair option xes a model, some of them may seem more intuitive and more logical to stakeholders than others. Therefore, stakeholders should choose manually which of the available repair options should be executed. However, repair options could of course be selected and executed automatically if model characteristics such as readability are of low importance.
In our example, the co-evolution of C2 can be done automatically as there is only one repair option. To repair the inconsistency of C1, a user has to decide between only three options that propagate the metamodel change correctly to the model. 4
Let us now brie y discuss the planned implementation of our approach and preliminary validation results. 4.1
The individual parts of the approach have been implemented in previous work.
For the constraint management part, we have implemented a template-based
transformation engine that generates and updates metamodel-based model
constraints [
We have demonstrated in [
We have illustrated how our approach updates constraints and derives options for correcting co-evolution failures. Although we have used the proposed solution in isolation to keep the example simple and focused, it is compatible with existing automatic co-evolution techniques. When used in isolation, our approach detects the absence of necessary model adaptations as co-evolution failures. When combined with other approaches, it also detects co-evolution failures that are based on incorrect model adaptations. Therefore, our solution is not a substitute but a complement to existing technologies.
Let us now discuss how the presented approach relates to other work that has
been done in the eld of co-evolving metamodels and models. The necessity
of support for e cient and automatic co-evolution of metamodel and models
was identi ed as a major challenge in software evolution by Mens et al. [
Wimmer et al. [
In this vision paper, we have presented the outline of a novel approach for supporting the co-evolution of metamodels and models. Our approach is generic and relies on the detection of inconsistencies that occur after metamodel evolution. Those inconsistencies serve as input for a reasoning mechanism that provides as output a set of possible model adaptations for repairing { that is, co-evolving { an a ected model.
The preliminary validation results are promising and suggest that the presented approach is feasible and that it can be implemented e ciently. However, these were observed in tests that were performed with prototype implementations for the individual components involved in the approach. For a complete validation, we have yet to conduct case studies with industrial models and a complete implementation that fully integrates the prototypes of individual components.