Diagram Centric Model Versioning

By Stefan Schefberger and Matthias Winkelhofer

Introduction

Model driven engineering becomes more and more important in the area of software development. As with any engineering project, you need to collaborate as a team sharing the source code, as well as models, through a version control system. EMF Compare and EGit provide a sufficient mechanism to support model versioning. However, the model comparison viewer always strictly separates between changes applied to the model and the diagram. Many users however do not consider these two worlds, the model and the diagram, as separate artifacts, but rather as a unified concept. They prefer to interact mainly with the diagrams since the graphical representations are closer their way of thinking. For such diagram-centric user scenarios, the separation as in EMF compare is counter-intuitive. Therefore, we present in this post a new diagram-centric plug-in that supports the combination the model and diagram changes in a common view.

Diagram Example:

Before

After

Requirements

But before we were able to work on our approach to satisfy the diagram-centric users, we had to think about their requirements and demands. After some extensive discussions we gathered the following main points:

• no strict separation in model and diagram differences
• keep control over the management of model changes
• full functionality of the versioning mechanism
• implementation compatible to the already existing groups

Approach

To be able to tell EMF Compare how we want to change the way it displays the tree of changes, we first of all initialized a new Eclipse plug-in and, of course. Within the plugin.xml configuration file we had to register an additional org.eclipse.emf.compare.rcp.ui.group by adding it with assistance of the so called Extension Point Selection Wizard. After doing that we were able to add our new EMF Compare group extension and finally add the corresponding class and a proper label.

But of course this was only the basic prerequisite. We still needed a way to logically implement our desired solution. Therefore we had to link the already described model and diagram representation. To have a specific use case for this project, we chose the modelling framework Papyrus and its implementation of UML. Looking at the corresponding XML files in EMF, you can see a link which points from the diagram to the model side. This is the case, because for one logical element, there are several graphical ones.

EMF Compare already provides a hierarchical data structure that inherits this property. The root level for one versioning process is called Comparison and contains several Matches which are created for identical elements that reside on the different versioning sides (Left, Origin, Right). Since within this context everything is built up as a tree, each Match can contain a list of Sub-Matches (containments) and of course because we are talking about versioning, on each level there is the possibility to have multiple differences, that shall be displayed within the Diagram-Centric group later on.

To be able to work with this already given data structure we decided to reuse some logical components of the BasicDifferenceGroupImpl.java. Finally we were able to fulfill our purpose via using a HashMap to store the Diagram Matches that corresponds to the desired Model elements.

Solution

For better understanding we provide two different representation of the comparison tree. In the first image you can see the default representation without any additional grouping. As we already mentioned during several sections of our paper, again there is the strict separation of the tree representation in the Diagram and Model perspective.

In contrast to this, the second one shows our final implementation, which unifies these two worlds and provides the user with a diagram-centric versioning tree.

Default representation without grouping

Diagram-Centric representation

Outlook

Now, after the hard work, we are able to show them in the desired way. But there are several areas with improvement potential. First of all this group was initially designed to work with UML and can be understood as a prototype. So to make this group applicable for end users, a lot more modelling languages have to be taken into account and tested against a huge amount of special cases. Another point of improvement is the compatibility of our implementation to get along with the pre-implemented filtering functions of EMF Compare. And finally during our examinations we were focused on the logical correctness of our solution.

But as a closing statement, once more we would like to note, that the Diagram Centric group implementation is the first step in a specialized model oriented perspective of representing the changes of graphical and logical models.