Skip to main content
Jump to: navigation, search

EMF Compare/Specifications/IntermediateProxiesResolution

Containment changes in fragments

Summary

When a model is split into fragments, and only some of them have changes, the structure merge viewer (SMV) and the content merge viewers (CMV) display the models involved in the comparison but don’t display the fragments that have no changes.

If a change (x) is detected in a fragment (B), and this fragment is a child of another fragment (A) that has no changes, then (A) won't appear in the SMV and the CMV's. As a result, users will think (B) is the root of the global model.

To avoid this, the idea is to display intermediate node(s) (represented as [...]) in order to show to users that it exists something (fragments, i.e. a parts of models) between/above the changes.

The following cases represent such models, the way they are currently displaying and the way we want them to be displayed.

Case 0

A model divided in 2 fragments, with one change in the second fragment.

EMFCompare IPR Case0 0.png

2-way comparison (of Resource1.uml) results

Currently

We don’t know that <Package> A is under <Package> Root.

EMFCompare IPR Case0 1.png

What we want

We want to know that <Package> A is under <Package> Root. Display the fact that <Package> A is contained under <Package> Root is a valuable information. We want to show this in the structure merge viewer (a.k.a. SMV, top part of the editor) and in the content merge viewers (a.k.a. CMVs, bottom left part & bottom right part of the editor).

EMFCompare IPR Case0 2.png

Proposal of a degraded solution that seems technically more viable (for performance reasons)

Display the fact that <Package> A is contained under something is already a valuable information.

EMFCompare IPR Case0 3.png

Case 1

A model divided in 3 fragments, with one change in the first fragment and one change in the last fragment.

EMFCompare IPR Case1 0.png

2-way comparison (of Resource1.uml) results

Currently

Since the Resource2.uml is not loaded (because it contains no changes), we don’t know that <Package> D is under <Package> A. Thus, in the SMV & the CMVs, <Package> D is considering as root element. Moreover, since Resource1.uml is not loaded, we can’t display <Package> A under <Package> Root, only the fact that it exists something (represented by its proxy) under <Package> Root.

EMFCompare IPR Case1 1.png

What we want

We want to know that <Package> D is under <Package> A. Display the fact that <Package> D is contained under <Package> A is a valuable information. In the structure merge, <Package> D must be under <Package> A. <Package> A must be under <Package> Root.

When <Package> C is selected in the SMV, the CMVs must display the children of <Package> Root, including <Package> A. <Package> D doesn't need to be display, because it must be contained under <Package> A. However, if <Package> A is expanded, <Package> D must appear.

EMFCompare IPR Case1 2.png

When <Package> F is selected in the SMV, the CMVs must look like below. We don’t need to display <Package> E from Resource2.uml, as it is not concerned with the <Package> F difference.

EMFCompare IPR Case1 3.png

Proposal of a degraded solution that seems technically more viable (for performance reasons)

Display the fact that <Package> D is contained under something is already a valuable information.

EMFCompare IPR Case1 4.png

EMFCompare IPR Case1 5.png

Case 2

A model divides in 3 fragments, with one containment change in the second fragment and one containment change in the last fragment.

EMFCompare IPR Case2 0.png

2-way comparison (of Resource1.uml) results

Currently

Since the Resource1.uml is not loaded (because it contains no changes), we don’t know that <Package> A is under <Package> Root. Thus, in the SMV & the CMVs, <Package> A is considering as root element.

EMFCompare IPR Case2 1.png

What we want

We want to know that <Package> A is under <Package> Root. Display the fact that <Package> A is contained under <Package> Root is a valuable information. In the structure merge, <Package> A must be under <Package> Root.

When <Package> F is selected:

EMFCompare IPR Case2 2.png

When <Package> E is selected:

EMFCompare IPR Case2 3.png

Proposal of a degraded solution that seems technically more viable (for performance reasons)

When <Package> F is selected:

EMFCompare IPR Case2 4.png

When <Package> E is selected:

EMFCompare IPR Case2 5.png

Case 3

A model divides in 4 fragments, with one containment change in the second fragment and one containment change in the last fragment.

EMFCompare IPR Case3 0.png

2-way comparison (of Resource1.uml) results

Currently

Since the Resource1.uml is not loaded (because it contains no changes), we don’t know that <Package> A is under another resource. Thus, in the SMV & the CMVs, <Package> A is considering as root element. Moreover, since Resource3.uml is not loaded, we can’t display <Package> E under <Package> C, only the fact that it exists something (represented by its proxy) under <Package> C.

Since the Resource3.uml is not loaded (because it contains no changes), we don’t know that <Package> H is under another resource. Thus, in the SMV & the CMVs, <Package> H is considering as root element.

EMFCompare IPR Case3 1.png

What we want

We want to know that <Package> A is under <Package> Root. Display the fact that <Package> A is contained under something is a valuable information. In the structure merge, <Package> A must be under <Package> Root. We want to know that <Package> H is under <Package> F (itself under <Package> E). Display the fact that <Package> H is contained under something is a valuable information. In the structure merge, <Package> H must be under <Package> F. <Package> F must be under <Package> E.

When <Package> D is selected in the SMV, the CMVs must display the <Package> Root element, containing <Package> A and <Package> D.

EMFCompare IPR Case3 2.png

When <Package> I is selected in the SMV, the CMVs must look like below. We don’t need to display <Package> G from Resource3.uml, as it is not concerned with the <Package> I difference. We also don’t need to display <Package> B from Resource3.uml, as it is not concerned with the <Package> I difference.

EMFCompare IPR Case3 3.png

Proposal of a degraded solution that seems technically more viable (for performance reasons)

When <Package> D is selected in the SMV:

EMFCompare IPR Case3 4.png

When <Package> I is selected in the SMV:

EMFCompare IPR Case3 5.png

Resource with non-containment references to other resources

A comparison detects changes on a resource. This resource (X) have non-containment references to other resources (Y, Z). Y & Z won’t be loaded during the display step, because there are no changes on them detected during the comparison step.

During the display step (after the comparison step), EMF Compare should allow to load every resources needed to properly display comparison results.

Work to handle these cases has been integrated to EMF Compare via https://git.eclipse.org/r/#/c/39187/

Case 0

A model with changes, and with non-containment reference to another resource. This non-containment reference is not involved in changes.

EMFCompare IPR CrossRef Case0 0.png

2-way comparison (of Resource1.uml) results

Currently

The type of <Property> p2 (C3) is not displayed because there are no changes detected on Resource2.uml (the resource containing C3).

EMFCompare IPR CrossRef Case0 1.png

What we want

Display the type of <Property> p2 (C3) even if there are no changes detected on Resource2.uml (the resource containing C3). Note: C3 should also be displayed in the structure merge viewer when the Identical elements filter is deactivated.

EMFCompare IPR CrossRef Case0 2.png

Graphic changes but no semantic changes

A comparison with only graphic changes but no semantic changes is currently displayed as the following Currently section. The semantic resources (*.uml models) associated with the diagram resources (*.di models) are not loaded during the display step, because there are no changes detected during the comparison step. This leads to display diagrams without semantic data. During the display step (after the comparison step), EMF Compare should allow to load every resources needed to properly display comparison results, as in the following What we want section.

Work to handle this case has been integrated to EMF Compare via https://git.eclipse.org/r/#/c/39187/

Currently

The diagrams are displaying without semantic data.

EMFCompare IPR GraphicChange 0.png

What we want

Semantic data displayed with their graphic representations.

EMFCompare IPR GraphicChange 1.png

Back to the top