EMF Compare/GMF Notation model Comparison

The GMF diagram comparison tasks can be splitted in four parts. First, we must be able to compare GMF Notation models, then we have to know how we handle the link with the comparison of the semantic model (i.e. the elements represented by the diagram). Third, we have to know how to integrate existing GMF editor within the EMF Compare editor. Finally, we have to know how to create generic markers on the diagram to give a feedback of the computed differences to the user.

Notation model comparison

The whole notation model will not be taken into account. The difference computation will only occur on a subpart as depicted below:

The nodes and edges will be matched by their XMI IDs. Containment between nodes will be handled in a generic way (i.e. by the GenericMatchEngine).

Only following differences will be computed:

• Addition / Removal of a node
• Addition / Removal of an edge
• Change of a Label on an edge or on a node (type id = 40xx)
• Move of a node within the diagram (with a configurable translation threshold for the move its location x/y).
• Move of an edge within the diagram (total number of bendpoints, change of bendpoints - sourceX, sourceY, targetX, targetY - and positions of the anchors).

Link with the semantic comparison

For many cases, we need the semantic comparison to be done before the graphical one. The work on logical model integration should give us this facility by computing the differences of a whole resource set instead of just the current resource containing the notation model.

The link with the semantic comparison had to be provided for the labels. For each element of type.startsWith("40"), we have to get the text of the label et compare them. They are not stored directly into the notation model.

Move operations of Edge and Node never correspond to semantic change.

For addition and removal of nodes and edges, graphical differences may or may not corresponds to a semantic change. For instance, a graphical element may be removed because it has been hidden or deleted from the diagram. It does not correspond to a change in the semantic model. This graphical change does not have to be linked to a semantic change. In the other case, the addition or the removal of a node or an edge must match an addition or a deletion in the semantic model.

Merge

As a we don't know from the notation model how labels are build and from which feature(s) of the semantic model, the merge operation of labels modification must be applied on the notation model to trigger the appropriate underlying commands on the semantic model. This merger operation can be triggerred only if the label is editable (ask to the editpart of the view isEditable())

The merge of a move a node or an edge never triggers a merge on the semantic model, only on the graphical notation. The merge is a simple copy of values of bendpoints/layout constraints.

Addition/Removal of node or edge trigger the merge of the semantic difference if it is associated to one, and the merge operation of the graphical difference otherwise. This merge operation consist of re-create the element if it has been deleted from the diagram, or to restor the hidden status of this view ()