Jump to: navigation, search

Difference between revisions of "EMF Compare/CompareUMLPapyrusAPI"

(Others generic APIs)
(20 intermediate revisions by 4 users not shown)
Line 1: Line 1:
This work is sponsored by [http://www.ericsson.com Ericsson] in the context of the [http://wiki.eclipse.org/ModelingPlatform Modeling Platform Industrial Working Group]
+
This work is developed by [http://www.obeo.fr Obeo] and sponsored by [http://www.ericsson.com Ericsson] in the context of the [[ModelingPlatform | Modeling Platform Industrial Working Group]]
 
+
* <span style="color:#cc0000">'''[PFI]'''</span> means "'''Planned for Indigo'''"
+
* <span style="color:#cc6600">'''[PFS]'''</span> means "'''Planned for September'''"
+
  
 
== Enhance the existing tree editor ==
 
== Enhance the existing tree editor ==
  
* <span style="color:#cc0000">'''[PFI]'''</span> [[EMF Compare/EGit support | Specific team handler for model resources managed through Git with eGit]]. This handler enables the comparison and merge of files managed with Git.
+
* [[EMF Compare/Textual diff in model diff | Capability to switch between the tree and textual editor by using a popup menu, without losing the selection.]]
* <span style="color:#cc0000">'''[PFI]'''</span> [[EMF Compare/Textual diff in model diff | Capability to switch between the tree and textual editor by using a popup menu, without losing the selection.]]
+
 
* [[EMF Compare/Restrict comparison on selection | Capability to restrict the comparison on the current selection]]
 
* [[EMF Compare/Restrict comparison on selection | Capability to restrict the comparison on the current selection]]
* <span style="color:#cc0000">'''[PFI]'''</span> [[EMF Compare/Grouping facility | Capability to group differences]] by:
+
* [[EMF Compare/Grouping facility | Capability to group differences]] by:
 
** File
 
** File
 
** Modification type
 
** Modification type
Line 15: Line 11:
 
** Flat text elements
 
** Flat text elements
  
* <span style="color:#cc0000">'''[PFI]'''</span> [[EMF Compare/Filtering facility | Capability to dynamically hide/show the displayed elements with filters]]:
+
* [[EMF Compare/Filtering facility | Capability to dynamically hide/show the displayed elements with filters]]:
 
** Filter add changes
 
** Filter add changes
 
** Filter delete changes
 
** Filter delete changes
Line 21: Line 17:
 
** Filter element order changes
 
** Filter element order changes
 
   
 
   
* <span style="color:#cc6600">'''[PFS]'''</span> [[EMF Compare/Filtering facility#Preference_page_for_filter_setting_configuration | Propose a Preference page to define default settings for EMF compare filter]]
+
* [[EMF Compare/Filtering facility#Preference_page_for_filter_setting_configuration | Propose a Preference page to define default settings for EMF compare filter]]
* <span style="color:#cc0000">'''[PFI]'''</span> [[EMF Compare/Filtering facility#Provide_an_API_enabling_the_contribution_of_new_filters | Provide an API enabling the contribution of new filters.]]
+
* [[EMF Compare/Filtering facility#Provide_an_API_enabling_the_contribution_of_new_filters | Provide an API enabling the contribution of new filters.]]
  
== <span style="color:#cc6600">'''[PFS]'''</span> Specific support of UML Model ==
+
== EMFCompare support for Logical Model Integration ==
 +
 
 +
The need for a more logical view on resources has been discussed and implemented in Eclipse and the work on this started prior to Eclipse 3.2. It was there identified that also the Team API needs to be more logical context aware so that not all operations were performed file-by-file. This includes fetching logical context for different versions and also the ability to commit changes in several physical files in one merge commit which logical model merging does.
 +
 +
Information spawn from the bugzilla bug 37723 that was filed 2005 https://bugs.eclipse.org/bugs/show_bug.cgi?id=37723 and
 +
http://www.eclipse.org/eclipse/platform-team/team3.0/logical-physical.html
 +
 +
Logical model API aware SCM (only CVS currently) should have the ability to resolve related artifacts that are participating in a merge. When merging in one commit/change-set you are comparing files that are part and not part of the change set. The rest of the files are identical for the two versions of the model to be merged. 
 +
 
 +
'''[[EMF Compare/Logical model support | Detailed specifications]]'''
 +
 
 +
== Specific support of UML Model ==
  
 
In order to provide the best possible accuracy and precision when comparing and merging UML models, it is necessary to implement a specific comparison engine which handles the UML meta-model directly (according to the UML metamodel defined with EMF in Eclipse / Modeling Tools / UML).  
 
In order to provide the best possible accuracy and precision when comparing and merging UML models, it is necessary to implement a specific comparison engine which handles the UML meta-model directly (according to the UML metamodel defined with EMF in Eclipse / Modeling Tools / UML).  
Line 30: Line 37:
 
For example, for the addition (or deletion or modification) of an association at the UML level, there is 3 additions (or deletions, or potential modifications) in the EMF representation : one "association", and two "property ends". We will define specific UML extensions for EMF Compare using the DiffExtension API to create the UML level operations (AddAssociation, DeleteAssociation, ModifyAssociation) and write the recognition code to identify these UML level change operations from the EMF level change operations. So, the end-user who diffs and merges a UML model will only see UML level change operations, and the changes will be applied atomically on the model to avoid model inconsistency.  
 
For example, for the addition (or deletion or modification) of an association at the UML level, there is 3 additions (or deletions, or potential modifications) in the EMF representation : one "association", and two "property ends". We will define specific UML extensions for EMF Compare using the DiffExtension API to create the UML level operations (AddAssociation, DeleteAssociation, ModifyAssociation) and write the recognition code to identify these UML level change operations from the EMF level change operations. So, the end-user who diffs and merges a UML model will only see UML level change operations, and the changes will be applied atomically on the model to avoid model inconsistency.  
  
Additionally, EMF Compare will support diff and merge of fragmented UML models, that is UML models stored in several physical resources, and of sets of UML model fragments. The fact that UML level operations are atomically applied will be specifically addressed in the case of merging of model fragments to forbid partial merges in one fragment that would corrupt the whole model.  
+
Additionally, EMF Compare will support diff and merge of fragmented UML models, that is UML models stored in several physical resources, and of sets of UML model fragments. The fact that UML level operations are atomically applied will be specifically addressed in the case of merging of model fragments to forbid partial merges in one fragment that would corrupt the whole model. See previous section for more information [[#Support of Eclipse logical model Team API]].
  
 
Another transversal UML issue to be addressed is the support of UML profiles.
 
Another transversal UML issue to be addressed is the support of UML profiles.
Line 46: Line 53:
 
* Support second set of behavioral metamodels : State, Communication
 
* Support second set of behavioral metamodels : State, Communication
  
== <span style="color:#cc0000">'''[PFI]'''</span> GMF Diagram Comparison ==
+
'''[[EMF Compare/UML Compare | Detailed specifications]]'''
 +
 
 +
== GMF Diagram Comparison ==
  
 
With diagram comparison, a user must be able to graphically visualize the changes between two or three diagrams. Diagram comparison will contribute a new comparison editor, in addition to the tree and textual comparison editors. This new editor will be available when the compared resources are GMF diagrams. Typically, the diagram comparison editor will display one version of the diagram without decoration (the original diagram) alongside another version of the diagram with graphical decorations to show the differences.
 
With diagram comparison, a user must be able to graphically visualize the changes between two or three diagrams. Diagram comparison will contribute a new comparison editor, in addition to the tree and textual comparison editors. This new editor will be available when the compared resources are GMF diagrams. Typically, the diagram comparison editor will display one version of the diagram without decoration (the original diagram) alongside another version of the diagram with graphical decorations to show the differences.
Line 57: Line 66:
 
</gallery>
 
</gallery>
  
* Modifications of nodes and edges must be highlighted with a specific decoration.
+
* Suppression of nodes and edges must be highlighted with a specific decoration.
  
 
<gallery widths="150px" heights="200px">
 
<gallery widths="150px" heights="200px">
Line 64: Line 73:
 
</gallery>
 
</gallery>
  
* Layout changes must be displayable, but must also be filtered with a configurable threshold.This threshold must be configurable either through an API, or an Eclipse preference.
+
* Labels changes must be highlighted with a specific decoration.
  
 
<gallery widths="450px" heights="200px">
 
<gallery widths="450px" heights="200px">
Image:Diag_comp_label_1.png‎|'''Example''' of graphical decoration for node modification
+
Image:Diag_comp_label_1.png‎|'''Example''' of graphical decoration for node label modification
Image:Diag_comp_label_2.png‎|'''Example''' of graphical decoration for edge modification
+
Image:Diag_comp_label_2.png‎|'''Example''' of graphical decoration for edge label modification
 
</gallery>
 
</gallery>
  
Line 85: Line 94:
 
</gallery>
 
</gallery>
  
== <span style="color:#cc6600">'''[PFS]'''</span> Support fo various UML diagrams comparison in Papyrus ==
+
'''[[EMF Compare/GMF Compare Markers | Detailed specifications]]'''
 +
 
 +
== Support fo various UML diagrams comparison in Papyrus ==
  
 
Beyond the generic implementation of GMF graphical diagrams comparison, we will integrate diagram comparison in the Eclipse foundation open source tool Papyrus. We will incrementally implement the different diagrams supported in Papyrus:
 
Beyond the generic implementation of GMF graphical diagrams comparison, we will integrate diagram comparison in the Eclipse foundation open source tool Papyrus. We will incrementally implement the different diagrams supported in Papyrus:
Line 95: Line 106:
  
 
A specific communication and contribution channel will be established to ensure that the UML model comparison is integrated with the mainstream Papyrus releases.
 
A specific communication and contribution channel will be established to ensure that the UML model comparison is integrated with the mainstream Papyrus releases.
 +
 +
'''[[EMF Compare/UML Compare Papyrus integration | Detailed specifications]]'''
  
 
== Others generic APIs ==
 
== Others generic APIs ==
Line 100: Line 113:
 
The following APIs will be implemented to work both with the Tree and diagram comparison editors:
 
The following APIs will be implemented to work both with the Tree and diagram comparison editors:
  
* <span style="color:#cc0000">'''[PFI]'''</span> API to create a viewer listing all structural changes resulting from a model comparison which includes the filtering and grouping options as mentioned previously. This API will offer the capability to programmatically retrieve the Meta model class (type) e.g. Documentation, stereotype)
+
* [[EMF_Compare/API_Viewer_FilteringGrouping | API to create a viewer listing all structural changes resulting from a model comparison which includes the filtering and grouping options as mentioned previously. This API will offer the capability to programmatically retrieve the Meta model class (type) e.g. Documentation, stereotype)]]
* <span style="color:#cc0000">'''[PFI]'''</span> API to query the viewer for the list of visible changes (e.g. not filtered out) The type of elements returned in the list of structural differences should offer an API to retrieve the location information of the affected elements, in order to trigger the selection of the affected elements in both the Project Explorer and Editor.
+
* [[EMF_Compare/API_GetVisibleDiffElements | API to query the viewer for the list of visible changes (e.g. not filtered out) The type of elements returned in the list of structural differences should offer an API to retrieve the location information of the affected elements, in order to trigger the selection of the affected elements in both the Project Explorer and Editor.]]
* <span style="color:#cc6600">'''[PFS]'''</span> API to handle and serialize a set of graphical elements under comparison so that it is possible to pass them on to another tool.
+
* [[EMF_Compare/API_LayerDifferences | API to handle and serialize a set of graphical elements under comparison so that it is possible to pass them on to another tool.]]
* <span style="color:#cc6600">'''[PFS]'''</span> API to launch an Eclipse Model Compare editor with two specified versions of model files and be able to programmatically request the selection of a structural change based on a previously obtained location.
+
* [[EMF_Compare/API_OpenEditorWithSelection | API to launch an Eclipse Model Compare editor with two specified versions of model files and be able to programmatically request the selection of a structural change based on a previously obtained location.]]
 +
 
 +
* [[EMF_Compare/API_MetamodelRequiresLink | Meta-model API to define dependencies between difference elements]]
 +
 
 +
[[Category:Modeling]] [[Category:EMF Compare]]

Revision as of 03:49, 18 October 2012

This work is developed by Obeo and sponsored by Ericsson in the context of the Modeling Platform Industrial Working Group

Enhance the existing tree editor

EMFCompare support for Logical Model Integration

The need for a more logical view on resources has been discussed and implemented in Eclipse and the work on this started prior to Eclipse 3.2. It was there identified that also the Team API needs to be more logical context aware so that not all operations were performed file-by-file. This includes fetching logical context for different versions and also the ability to commit changes in several physical files in one merge commit which logical model merging does.

Information spawn from the bugzilla bug 37723 that was filed 2005 https://bugs.eclipse.org/bugs/show_bug.cgi?id=37723 and http://www.eclipse.org/eclipse/platform-team/team3.0/logical-physical.html

Logical model API aware SCM (only CVS currently) should have the ability to resolve related artifacts that are participating in a merge. When merging in one commit/change-set you are comparing files that are part and not part of the change set. The rest of the files are identical for the two versions of the model to be merged.

Detailed specifications

Specific support of UML Model

In order to provide the best possible accuracy and precision when comparing and merging UML models, it is necessary to implement a specific comparison engine which handles the UML meta-model directly (according to the UML metamodel defined with EMF in Eclipse / Modeling Tools / UML).

For example, for the addition (or deletion or modification) of an association at the UML level, there is 3 additions (or deletions, or potential modifications) in the EMF representation : one "association", and two "property ends". We will define specific UML extensions for EMF Compare using the DiffExtension API to create the UML level operations (AddAssociation, DeleteAssociation, ModifyAssociation) and write the recognition code to identify these UML level change operations from the EMF level change operations. So, the end-user who diffs and merges a UML model will only see UML level change operations, and the changes will be applied atomically on the model to avoid model inconsistency.

Additionally, EMF Compare will support diff and merge of fragmented UML models, that is UML models stored in several physical resources, and of sets of UML model fragments. The fact that UML level operations are atomically applied will be specifically addressed in the case of merging of model fragments to forbid partial merges in one fragment that would corrupt the whole model. See previous section for more information #Support of Eclipse logical model Team API.

Another transversal UML issue to be addressed is the support of UML profiles.

We will also ensure that generic APIs are adapted to work at the UML level. More specifically, we will provide UML level APIs for:

  • API to request a UML diff between two models providing the result as a list of structural differences or serialized to a file
  • API to retrieve the UML modification types (e.g. add, delete, change, move, separation/fragment, join/fragment)

Then, we identify separate sets of UML diagram meta-models which will be supported incrementally:

  • Support first set of Structural metamodels : Package, Class
  • Support second set of structural metamodels : Composite
  • Support first set of behavioral metamodels : Use Case , Sequence, Activity
  • Support second set of behavioral metamodels : State, Communication

Detailed specifications

GMF Diagram Comparison

With diagram comparison, a user must be able to graphically visualize the changes between two or three diagrams. Diagram comparison will contribute a new comparison editor, in addition to the tree and textual comparison editors. This new editor will be available when the compared resources are GMF diagrams. Typically, the diagram comparison editor will display one version of the diagram without decoration (the original diagram) alongside another version of the diagram with graphical decorations to show the differences.

  • Additions of nodes or edges must be highlighted with a specific graphical decoration.
  • Suppression of nodes and edges must be highlighted with a specific decoration.
  • Labels changes must be highlighted with a specific decoration.
  • Layout changes must be displayable, but must also be filtered with a configurable threshold. This threshold must be configurable either through an API, or an Eclipse preference.

Example of integration of the different graphical decorations for a diagram:

Detailed specifications

Support fo various UML diagrams comparison in Papyrus

Beyond the generic implementation of GMF graphical diagrams comparison, we will integrate diagram comparison in the Eclipse foundation open source tool Papyrus. We will incrementally implement the different diagrams supported in Papyrus:

  • Support first set of Structural diagram metamodels : Package, Class
  • Support second set of structural diagram metamodels : Composite
  • Support first set of behavioral diagram metamodels : Use Case , Sequence, Activity
  • Support second set of behavioral diagram metamodels : State, Communication

A specific communication and contribution channel will be established to ensure that the UML model comparison is integrated with the mainstream Papyrus releases.

Detailed specifications

Others generic APIs

The following APIs will be implemented to work both with the Tree and diagram comparison editors: