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/2012EMFCompareEnhancements"

(DiffElement selection)
 
(21 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This work is developed by [http://www.obeo.fr Obeo] and sponsored by [http://www.ericsson.com Ericsson] in the context of the [[Polarsys | Polarsys]]
+
{{Template:EMF Compare Archive Notice}}
 +
 
 +
This work is developed by [http://www.obeo.fr Obeo] and sponsored by [http://www.ericsson.com Ericsson] in the context of the [[Polarsys | Polarsys]]. <br>
 +
It provides improvements for UML compare and merge with EGit and Papyrus both in term of features and in term of performances. <br>
 +
These features will be integrated in Juno, and the performance tests will be done before Juno SR1.
  
 
==EMF Compare integration==
 
==EMF Compare integration==
Line 28: Line 32:
 
===DiffElement selection===
 
===DiffElement selection===
  
From a stored/serialized DiffElement, to enable to select the related DiffElement in the current comparison editor. If no DiffElement matches, open a new comparison editor which contains the DiffElement to select.
+
From a stored/serialized DiffElement, this feature enables the selection of the related DiffElement in the current comparison editor. If no DiffElement matches, open a new comparison editor which contains the DiffElement to select.
  
 
===Contextual menu contribution===
 
===Contextual menu contribution===
  
To enable to contribute your own right click menu on the comparison editor, through extension point.
+
This feature enables to contribute your own right-click menu on the comparison editor, through extension point.
  
 
===Undo/Redo support for the comparison editor===
 
===Undo/Redo support for the comparison editor===
  
There is currently no way to undo merge operations done through EMF Compare. Support for undo/redo actions on these operations will be handled directly from the UI, with an accessible API for standalone merging.
+
There is currently no way to undo merge operations done through EMF Compare. Support for undo/redo actions on these operations will be handled directly from the UI, with an accessible API for standalone use.
  
===Conflict resolving wizard===
+
===Conflict resolution wizard===
  
Currently, conflicts detected by EMF Compare are resolved by overriding : users either select the "local" version or the "remote" version, but cannot resolve the conflict by merging some parts of the change. This will be resolved through the addition of a new wizard accessible from the UI for conflict resolution.
+
Currently, conflicts detected by EMF Compare are resolved by overriding : users either select the "local" version or the "remote" version. A new wizard, accessible from the UI, will be added to help conflict resolution by merging some parts of the change.
  
 
===Standalone comparison editor===
 
===Standalone comparison editor===
  
Implementation  of  a  standalone  comparison  editor  that  can  be  reused  by  third-party  plugins  to  display comparison results.
+
Implementation  of  a  standalone  comparison  editor  that  can  be  reused  by  third-party  plugins  to  display comparison results.<br/>
The current comparison editor relies on the comparison editor framework provided by the Eclipse platform. It provides the advantage of a good integration in the Eclipse platform, but can be not enough customizable in some cases.
+
The current comparison editor relies on the comparison editor framework provided by the Eclipse platform. It provides the advantage of a good integration in the Eclipse platform, but can be not enough customizable in some cases.<br/>
 
This  feature  includes  both  an  editor  mimicking  the  looks  and  behavior  of  the  "standard" comparison editor, and the API to use and customize it out of the context of the team API.
 
This  feature  includes  both  an  editor  mimicking  the  looks  and  behavior  of  the  "standard" comparison editor, and the API to use and customize it out of the context of the team API.
  
 
==UML Compare / Merge Performance Enhancements==
 
==UML Compare / Merge Performance Enhancements==
 
===Handling very large models===
 
  
 
After the work done in 2011, there are still some needs for enhancements to be able to support large model comparisons and to fully support logical models. These enhancements focus on restricting the scope of a comparison, and on getting faster and using less memory when we compare and merge large models.
 
After the work done in 2011, there are still some needs for enhancements to be able to support large model comparisons and to fully support logical models. These enhancements focus on restricting the scope of a comparison, and on getting faster and using less memory when we compare and merge large models.
Line 56: Line 58:
 
===Scoped models comparison===
 
===Scoped models comparison===
  
EMF Compare has the concept of a “scoped” comparison to ignore changes which are not in scope, but in term of implementation the complete UML model gets loaded (two or three versions of it depending on whether we need to detect conflicts or not). Thanks to the Logical Model implementation we now have the ability to create the complete graph of files composing a model and their SCM status. From this information we will be able to implement a comparison scope which will only load the changed fragments, avoiding to load the complete UML model. It will lead to considerable cpu time and memory usage gains and will enable to handle the minimal set of model fragment during a comparison.
+
EMF Compare has the concept of a “scoped” comparison to ignore changes which are not in scope, but in term of implementation the complete UML model gets loaded (two or three versions of it depending on whether we need to detect conflicts or not). <br/>
To do so we need to implement a first analysis pass to build the minimal scope of the comparison, and then leverage this scope during the whole comparison process.
+
Thanks to the Logical Model implementation we now have the ability to create the complete graph of files composing a model and their SCM status. From this information we will be able to implement a comparison scope which will only load the changed fragments, avoiding to load the complete UML model. It will lead to considerable cpu time and memory usage gains and will enable to handle the minimal set of model fragment during a comparison.<br/>
In order to illustrate the expected gains, we can consider that a model is composed of F fragments (diagrams or semantic models' fragments alike) and that the size of all fragments is the same X MB. We also consider that all three versions (local, remote, ancestor) of the model have the same number F of fragments, and that all three versions' fragments share the same size X MB when loaded in memory.
+
To do so we need to implement a first analysis pass to build the minimal scope of the comparison, and then leverage this scope during the whole comparison process.<br/>
Currently, a comparison through EMF Compare will need to load the whole model for all three versions. It thus takes (3 * F * X) megabytes in memory for a single comparison; both for the comparison and the UI display of the comparison result.
+
In terms of memory gains, we expect to move from a memory scaling according to the number of fragments in the models to a memory scaling according to the number of changed fragments.<br/>
The described enhancement will allow us to determine beforehand which model fragments have changed, allowing us to only load and compare this minimal number n of fragments in memory. Such comparisons will thus be limited to (3 * n * X) megabytes in memory for the comparison process. However, displaying the result of these comparisons in the UI is dependent of the framework. Displaying these comparison results in EMF Compare's tree viewers will only show the changed fragments, thus limiting the UI occupation to (3 * n * X) megabytes; but displaying these results in graphical editors such as papyrus might necessitate loading the whole models, whatever the changed fragments are. It depends on the graphical framework: to display diagram D, papyrus might need to load more semantic model fragments that the "changed" set. In the worst case scenario, displaying graphical comparison results will take (3 * F * X) megabytes.
+
In terms of performance, the improvement will be of a comparable level of magnitude than for memory as the use of Logical Models will result in a drastic reduction of processing from the current situation (we compare the whole model) to the comparison of the minimal set of consistent UML fragments.<br/>
In terms of performance, the improvement will be of a comparable level of magnitude than for memory as the use of Logical Models will result in a drastic reduction of processing from the current situation (we compare the whole model) to the comparison of the minimal set of consistent UML fragments.
+
A new API will be provided to resolve the minimum set of fragments for a two way compare of two different versions of a UML model / Diagram e.g. left and right related diagram and model fragments in order to enable a compare session independently of the projects loaded in the work space.<br/>
A performance evaluation report and a profiling report will be provided to illustrate these enhancements.
+
A new API will be provided to resolve the minimum set of fragments for a two way compare of two different versions of a UML model / Diagram e.g. left and right related diagram and model fragments in order to enable a compare session independently of the projects loaded in the work space.
+
Additionally to the implementation of Scoped comparisons, the two following tasks correspond to the full support and test of these scoped implementation in the Generic and UML engines.
+
 
+
===Update the engine and UI to avoid any un-necessary proxy resolution===
+
  
Once the scope is defined the comparison engine (responsible for the match and diff process) and the user interface presenting the result should never ever resolve proxies which are out of this scope. We need to update the implementation and the corresponding non regression tests in this regard.
+
===Update the generic engine, UML engine and UI to avoid any un-necessary proxy resolution===
  
===Update the UML engine to avoid any un-necessary proxy resolution===
+
Once the scope is defined the comparison engine (responsible for the match and diff process) and the user interface presenting the result should never ever resolve proxies which are out of this scope.
  
The UML engine extends the generic engine to create higher level diffs and to manage UML specific diff dependencies. Through this extension the implementation might lead to un-necessary proxy resolutions, we would need to update the implementation to make sure that would not happen.
+
=== Performance tests ===
 +
A performance evaluation and a profiling campaign will be done to illustrate these enhancements. This tests will cover models with characteristics similar to:
 +
{|
 +
|-  
 +
!
 +
!Small
 +
!Nominal
 +
!Large
 +
|-
 +
|Fragments
 +
|99
 +
|399
 +
|947
 +
|-
 +
|Packages
 +
|97
 +
|389
 +
|880
 +
|-
 +
|Classes
 +
|140
 +
|578
 +
|2169
 +
|-
 +
|Primitive Types
 +
|581
 +
|5370
 +
|17152
 +
|-
 +
|Data Types
 +
|599
 +
|5781
 +
|18637
 +
|-
 +
|State Machines
 +
|55
 +
|209
 +
|1311
 +
|-
 +
|States
 +
|202
 +
|765
 +
|10156
 +
|-
 +
|Dependencies
 +
|235
 +
|2522
 +
|8681
 +
|-
 +
|Transitions
 +
|798
 +
|3106
 +
|49805
 +
|-
 +
|Operations
 +
|1183
 +
|5903
 +
|46029
 +
|}

Latest revision as of 12:00, 5 March 2014

THIS PAGE IS ARCHIVED. IT IS PROBABLY OUTDATED AND WILL NOT BE UPDATED

This work is developed by Obeo and sponsored by Ericsson in the context of the Polarsys.
It provides improvements for UML compare and merge with EGit and Papyrus both in term of features and in term of performances.
These features will be integrated in Juno, and the performance tests will be done before Juno SR1.

EMF Compare integration

Diff model restructuring to ease exploitation

The diff model provided as a result by EMF Compare can be quite complex to leverage for several reasons :

  • The model is missing an “origin” information (remote, local, ancestor, hierarchy, with user name when possible), leading to excessive abstract types of changes in the diff model.
  • “DiffGroup” have to be created/deleted on demand by the adopter modifying a diff model, this concept should be either deleted or have utility methods to make sure the diff model is valid.
  • Lack of browsing and cross-referencing APIs
  • DiffElements should be easily serializable for storage of DiffElement selections and reuse of these selections in order to open the comparison editors at the right place.

We are working on a new API to directly retrieve the following serializable information from each Diff:

    • Description as provided by Structural differences in the Eclipse compare
    • Modification type
    • Element Details e.g. class name, package name, diagram, etc.
    • Meta-Meta model details e.g. Eclass, EPackage
    • Model Location e.g. xmi-id
    • Diagram Details e.g. element name, type, etc..
    • Stereotype
    • Any other data needed to re-create a Model / Diagram diff

These API will specifically focus on making easier to reuse and integrate the diff model results in other tools like R4E.
It will be possible to re-create a Diff instance from the serialized information above.
UML and SysML comparison features will be updated accordingly.

EMF Compare usability

DiffElement selection

From a stored/serialized DiffElement, this feature enables the selection of the related DiffElement in the current comparison editor. If no DiffElement matches, open a new comparison editor which contains the DiffElement to select.

Contextual menu contribution

This feature enables to contribute your own right-click menu on the comparison editor, through extension point.

Undo/Redo support for the comparison editor

There is currently no way to undo merge operations done through EMF Compare. Support for undo/redo actions on these operations will be handled directly from the UI, with an accessible API for standalone use.

Conflict resolution wizard

Currently, conflicts detected by EMF Compare are resolved by overriding : users either select the "local" version or the "remote" version. A new wizard, accessible from the UI, will be added to help conflict resolution by merging some parts of the change.

Standalone comparison editor

Implementation of a standalone comparison editor that can be reused by third-party plugins to display comparison results.
The current comparison editor relies on the comparison editor framework provided by the Eclipse platform. It provides the advantage of a good integration in the Eclipse platform, but can be not enough customizable in some cases.
This feature includes both an editor mimicking the looks and behavior of the "standard" comparison editor, and the API to use and customize it out of the context of the team API.

UML Compare / Merge Performance Enhancements

After the work done in 2011, there are still some needs for enhancements to be able to support large model comparisons and to fully support logical models. These enhancements focus on restricting the scope of a comparison, and on getting faster and using less memory when we compare and merge large models.

Scoped models comparison

EMF Compare has the concept of a “scoped” comparison to ignore changes which are not in scope, but in term of implementation the complete UML model gets loaded (two or three versions of it depending on whether we need to detect conflicts or not).
Thanks to the Logical Model implementation we now have the ability to create the complete graph of files composing a model and their SCM status. From this information we will be able to implement a comparison scope which will only load the changed fragments, avoiding to load the complete UML model. It will lead to considerable cpu time and memory usage gains and will enable to handle the minimal set of model fragment during a comparison.
To do so we need to implement a first analysis pass to build the minimal scope of the comparison, and then leverage this scope during the whole comparison process.
In terms of memory gains, we expect to move from a memory scaling according to the number of fragments in the models to a memory scaling according to the number of changed fragments.
In terms of performance, the improvement will be of a comparable level of magnitude than for memory as the use of Logical Models will result in a drastic reduction of processing from the current situation (we compare the whole model) to the comparison of the minimal set of consistent UML fragments.
A new API will be provided to resolve the minimum set of fragments for a two way compare of two different versions of a UML model / Diagram e.g. left and right related diagram and model fragments in order to enable a compare session independently of the projects loaded in the work space.

Update the generic engine, UML engine and UI to avoid any un-necessary proxy resolution

Once the scope is defined the comparison engine (responsible for the match and diff process) and the user interface presenting the result should never ever resolve proxies which are out of this scope.

Performance tests

A performance evaluation and a profiling campaign will be done to illustrate these enhancements. This tests will cover models with characteristics similar to:

Small Nominal Large
Fragments 99 399 947
Packages 97 389 880
Classes 140 578 2169
Primitive Types 581 5370 17152
Data Types 599 5781 18637
State Machines 55 209 1311
States 202 765 10156
Dependencies 235 2522 8681
Transitions 798 3106 49805
Operations 1183 5903 46029

Copyright © Eclipse Foundation, Inc. All Rights Reserved.