View source for EMF DiffMerge/Co-Evolution

== Introduction  ==

The need being addressed is the synchronization of models that are technically disjoint, evolve in parallel, but are conceptually related. This conceptual relation implies that the models must be consistent with each other, at least at certain points in their life cycle, which requires synchronizations. By model we mean an arbitrary set or subset of consistently structured data, where consistency is defined by the compliance of the data to a known, unambiguous data format or metamodel.


It is assumed that
*the conceptual relation can be formalized as an explicit '''mapping''' or transformation between the models;
*the synchronization consists in an update of one of the models (the target) according to the other (the source) and the mapping in a so-called '''reconciliation''' phase;
*'''consistency preservation''' of the target model must be guaranteed during the reconciliation phase.


No assumption is made a priori on
*the respective life cycles of the models between two synchronizations: restrictions on evolutions, availability of a model when the other one changes;
*the complexity of the reconciliation phase, which can range from the simple replacement of a well-isolated subset of the model to a fine-grained, property-per-property update of an arbitrarily-defined subset;
*the degree to which human intervention is necessary in the reconciliation phase (reconciliation decisions) vs. the highest possible degree of automation;
*the technological nature of the models, which can therefore be heterogeneous - although EMF remains the primary reference.


We call a piece of software that carries out such a synchronization a '''bridge'''. The need for bridges, albeit well-known, is becoming more and more recurring in MBSE as a means to carry out model (or viewpoint) exploitation by analysis or simulation, co-engineering, or multi-model design in general as required by scalability issues, organizational issues, or tool heterogeneity. However, the design and development of effective bridges is currently hampered by a number of significant challenges and a lack of reusability between ad-hoc solutions. Consequently, Co-Evolution is a technology that is fully dedicated to the '''design and execution of bridges'''.


It has been and is being developed in the context of collaborative projects Sys2Soft, [http://www.crystal-artemis.eu/ Crystal] and [http://www.esterel-technologies.com/S3P-en.html S3P].


== Principles  ==

The technology enforces a strict separation between the mapping/transformation logics and the update logics, both being automatically connected by a trace conforming to minimal assumptions.

[[File:CoEv-SynchroDef.png|center]]


At execution time, the update logics may require an interaction with the end-user, in which case a dedicated GUI is involved.

[[File:CoEv-SynchroExec.png|center]]


== Architecture  ==

[[File:CoEv-Archi.jpg|center]]

== Usage  ==

*[http://wiki.eclipse.org/EMF_DiffMerge/Co-Evolution/Programmatic_Usage Programmatic usage and concepts] 
*[https://hudson.eclipse.org/diffmerge/job/emf-diffmerge-coevolution-master/javadoc/ Javadoc]: technical documentation

== Links  ==

*[https://wiki.eclipse.org/EMF_DiffMerge/Download/Co-Evolution Download]

*[https://github.com/eclipse/org.eclipse.emf.diffmerge.coevolution GitHub project]: the source code on GitHub

*[https://ci.eclipse.org/diffmerge/ Build]: the location where the project is built

*[https://wiki.eclipse.org/EMF_DiffMerge EMF Diff/Merge]: the host project that also provides the technological foundations upon which the Co-Evolution technology is based