EMF DiffMerge/Co-Evolution/Programmatic Usage

Principles

Co-Evolution supports implementing incremental model/data transformations of arbitrary complexity. Its primary goal is to enable engineers of different disciplines, working on the same system in a Model-Based Systems Engineering approach, to discuss and synchronize their (heterogeneous) models during co-engineering sessions within iterative processes.

Assumptions

Co-Evolution assumes the existence of two data sets that need to be synchronized. These are arbitrary sets of data elements, for example: an EMF model, a model in some other arbitrary but known format, a subset of a model, or a subset of the union of models. One data set is given the role of source and the other one the role of target. Deviations or inconsistencies between them are expressed as differences on the target side between: 1. the target data set as it is now, and 2. the target data set as it should be according to the source.

The data sets must comply to the following assumptions.

• Their data elements can be identified uniquely and consistently through their life cycle. In other words, even though the data set evolved, the element that was previously identified as E is still identified as E whatever happened in the meantime. Besides, it is always the only one to be identified as such.
• They can be read in Java, and for the target side written in Java, from the same Java Virtual Machine.
• They are disjoint: no data element belongs to both data sets.

In the case where a data set is only made of EMF model elements, it naturally maps to an EMF Diff/Merge model scope.

Concepts

Co-Evolution distinguishes three concerns.

• Transformation:
• Trace:
• Update:

Define a trace-aware model transformation

The