Models and Metamodels Co-Evolution
When ad-hoc metamodels are used, it is common to have issues related to their evolution. Managing metamodel versions and keeping the models conforming to specific (and likely old) metamodel versions is an useful alternative in some cases. However, in other situations models must always conform to the latest metamodel versions. In these cases, there is a necessity for co-evolving the models and metamodels. Moreover, in the context of Enterprise Architecture there are special characteristics that make unsuitable the application of existing Co-Evolution solutions.
To target this issue, we have developed a platform for Co-Evolution called Asimov, which is based around 3 key points:
- The evolution of a metamodel can be described in terms of a sequence of discrete steps, which give origin to intermediate metamodels.
- The co-evolution of models can be described in terms of a sequence of steps that make the model conform successively to each intermediate metamodel.
- The metamodeler knows why the metamodel evolves and has a general idea of how the model should be modied, but it is the modeler (the owner of the model) that knows exactly how the model must be modied, must approve every change, and must provide any missing information.
To support these points, Asimov offers a language to describe metamodel evolution steps, complemented by assistance steps. These assistance steps are suggestions, made by a metamodeler, about the co-evolution of the models given the corresponding evolution of the metamodels. When a model has to be evolved, the modeler loads the steps denition into the Asimov platform. This platform executes the steps one by one and presents questions about decisions that the modeler should made or about additional information that he should provide. Asimov is based on EnAr-Fusion and the issues that we encountered when we were building it led us into the Co-Creation line.