EMF DiffMerge/Co-Evolution/Programmatic Usage/Mapping

Overview

The Mapping module of Co-Evolution allows specifying trace-aware model transformations that can be made incremental as described here. It is based on a classical two-pass, simple transformation engine. Other model transformation technologies can be used as long as they are wrapped to implement the Co-Evolution APIs (see org.eclipse.emf.diffmerge.bridge.api.IBridge and org.eclipse.emf.diffmerge.bridge.api.IBridgeTrace).

A Mapping bridge contains a set of queries and a set of rules (see org.eclipse.emf.diffmerge.bridge.mapping.impl.Query and org.eclipse.emf.diffmerge.bridge.mapping.impl.Rule).

• Queries take an object as input and return a set of objects that are typically made of pre-existing elements from the source data set.
• Rules take an object as input, that typically contains one or several elements of the source data set, and return a set of newly created elements that are expected to belong to the target data set.

Queries are essentially triggers for rules. A rule is plugged onto a query so that for every object returned by the query, the rule is executed on it.

Programmatic usage

A Mapping transformation implements interface org.eclipse.emf.diffmerge.bridge.mapping.api.IMappingBridge. In the case where the target is an EMF model, class org.eclipse.emf.diffmerge.bridge.mapping.impl.emf.EMFMappingBridge<SourceObjectType, IEditableModelScope> can be used directly. It is then filled with queries and rules using query/rule constructors.