Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EMF Compare/GMF Notation model Comparison"

(Implementation)
(Implementation)
Line 126: Line 126:
 
| Added node inside a node
 
| Added node inside a node
 
! style="color:green" | ok
 
! style="color:green" | ok
| [[Image:TC4.png|thumb]]
+
| [[Image:TC04.png|thumb]]
 
|-
 
|-
 
| Removed node inside a node
 
| Removed node inside a node
 
! style="color:green" | ok
 
! style="color:green" | ok
| [[Image:TC5.png|thumb]]
+
| [[Image:TC05.png|thumb]]
 
|-
 
|-
 
| Moved node
 
| Moved node

Revision as of 05:51, 27 July 2011

The GMF diagram comparison task can be splitted into 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

Notation model comparison need its own MatchEngine and DiffEngine. The whole notation metamodel will not be taken into account. The difference computation will only occur on a subpart as depicted below:

Gmf notation compare.png

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 super class 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
  • 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 , we have to get the text of the label and 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 triggered only if the label is editable (=> ask to the editpart of the view isEditModeEnabled())

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 (View.isVisible())

GMF editor integration within Comparison editor

The integration of GMF editor within the comparison editor has to be done through specific contentMergeViewer (org.eclipse.compare.contentMergeViewers extension point) and maybe a specific structureMergerViewer (org.eclipse.compare.structureMergeViewers extension point) to provide the separation between graphical differences and semantic differences.

The content merge viewer has to instantiate DiagramGraphicalViewer inside its createControls() method:

viewer = new DiagramGraphicalViewer();
viewer.createControl(composite);
viewer.getControl().setBackground(ColorConstants.listBackground);

The resize of the left/right/ancestor panes has to be handled gracefully like this:

viewer_left.getControl().setBounds(x, y, leftWidth, height);
viewer_right.getControl().setBounds(x + leftWidth + centerWidth, y, rightWidth, height);

Initialization

The left/right/ancestor viewers has to be initialized with a proper editing domain. This creation takes the resourceSet as input:

DiagramEditingDomainFactory.getInstance().createEditingDomain(resourceset);

Then, the viewers has to be configured like this:

viewer.setEditDomain(new DefaultEditDomain(null)); // GEF editDomain
viewer.setEditPartFactory(EditPartService.getInstance());
viewer.setRootEditPart(new DiagramRootEditPart(diag.getMeasurementUnit()));
viewer.setContents(diag); // the diagram from the notation model

It is also possible to make the viewer uneditable by browsing all children of the rootEditPart of each viewer, but then, we will not be able to ask for the editability of views. It should be better to add a top layer that forbid the editing.

Markers for GMF diagrams

Difference marker on notation model are provided by using the org.eclipse.gmf.runtime.diagram.ui.decoratorProviders extension point.

The provided IDecoratorProvider will create a decorator based on the proposed IDecoratorTarget. This IDecoratorTarget can be adapted to a Notation View like this :

View view = (View) decoratorTarget.getAdapter(View.class);

The decorator should be created if, and only if, there is a graphical difference associated with the given View. The graphical difference model will be retrieved from the owning EditPart.

Provided decorators has to implement IDecorator interface.

The issue with specific decorator is to define the locator. Each Figure has its own bounds and we will start from the assumption that:

  • Marker of decorated figure will be rectangle following their bounds (smallest rectangle completely enclosing the IFigure)
  • Marker of decorated edges will be handled for polylines only and bounds of the decoration will be the bounds of the decorated
  • Marker of move will be an icon (picture not yet defined) located:
    • in the middle of the edge if the edge has moved
    • in the top right of the bounds of the figure if it is a node.

See samples of first annotation prototypes (on Ecore diagram):

Class added: MarkedAdded.png

Class removed: MarkedRemoved.png

Label of class changed: MarkedLabel.png

Edge marked (added) MarkedEdge.png

Edge marked (moved) MarkedMovedEdge.png

Implementation

Here are some screenshots of the current development under the master branch of the following repository https://github.com/sbouchet/emfcompare

Description State Screenshot
Added nodes ok
TC1.png
Deleted nodes ok
TC2.png
Mix of added and deleted nodes ok
TC3.png
Added node inside a node ok
TC04.png
Removed node inside a node ok
TC05.png
Moved node ok
TC6.png
Modified bounds of a node ko
File:TC7.png
not implemented
Hidden node ok
TC09.png
Revealed node ok
TC08.png
Modified label ok
TC10.png
Added label ok
TC11.png
Removed label ok
TC12.png
Mix of added and removed label ok
TC13.png
Hidden label ok
TC15.png
Revealed label ok
TC14.png
Modified label ok
TC16.png
Modified label ok
TC17.png
Added edge ko
no highlight on labels
Removed edge ko
no highlight on labels
Mix of added and removed edges ko
no highlight on labels
Moved edge ok
TC21.png
Modified edge label ok
TC23.png
Modified edge label ok
TC24.png
Revealed edge ok
TC25.png
Hidden edge ok
TC26.png
Revealed edge label ok
TC27.png
Hidden edge label ok
TC28.png
Removed node with edge ko
no highlight on labels
Removed node with edge ( delete from diagram ) ko
no highlight on labels
Removed edge ( delete from diagram ) ko
no highlight on labels
3 WAY added node ok
TC32.png
3 WAY removed node ok
TC33.png
3 WAY moved node (remote) ko
both nodes are marked
3 WAY moved node (local) ko
both nodes are marked
3 WAY modified label ko
no detection

Back to the top