Revision as of 05:00, 14 April 2011

The primary goal of this section is to provide technical specification of the UML Comparison engine. This engine will provide support of UML specific concepts and operations.

Overview

There are two ways of implementing UML Compare engine:

• Use the provided extension mechanism and override the visit() method to implement UML specific difference semantic
• Implement our own Diff/Match Engine (or override Generic Diff/Mathc engine if suited) to implement specific diff detection.

The first one should be simpler as it uses a builtin mechanism of EMFcompare but with less ability to get out of the border of what it had been designed for while the second one would let us define whatever we want but with an increased implementation complexity.

We now detail the two options, their pros and cons, and finally conclude and propose a solution.

Builtin extension mechanism

The extension mechanism is not working in essence. The mechanism work as follow:

• In your extending Ecore, you define a subclass of the EClasses AbstractDiffExtension and DiffElement (or any of its subclasses).
• You generate the code of this Ecore, and implement the visit(DiffModel), getText(), getImage(), provideMerger() methods.
• When the DiffService.doDiff() is called, diff is realized by the best suited diff engine within the registered ones.
• Once the diff is over, for each registered AbstractDiffExtension, the visit() method is called.

There are two problems:

• AbstractDiffExtension are instantiated only once. How can we assume we will only get one difference of that kind in the model? That's dumb and not working.
• Even if AbstractDiffExtension is to instantied the correct number of time, the visit() method is taking the whole diff model as input. It has to be browse for each extension. It will not scale.

The good parts of this mechanism come from AbstractDiffExtension#hideElements reference and its opposite DiffElement#isHiddenBy. It provides a neat solution to hide differences created by generic engines as it taken into account by the GUI.

The AbstractDiffExtension#provideMerger() are also a good idea as it let us provide our own merger to the framework. But it is best to provide the mergers through the IMergerProvider extension point.

The AbstractDiffExtension#getText(), AbstractDiffExtension#getImage() are bad idea. Why dont EMF compare use edit framework and its providers to display label and image ? Even for extension, it can work!

Implements specific Diff/Match engine

• Suggestion*

Make the *AbstractDiffExtension#visit()* method deprecated in EMF Compare 1.2 and remove it from 2.0

The GenericXXXEngine (where XXX is Match or Diff) implementations provide useful base implementation of EMF model comparison. Then we will

UML Compare match engine

There is no need to subclass

UML Compare diff engine

Profile / Stereotype support

Testing support