Mixed-Mode Compare/Merge, Part I

As not all models that EMF Compare operates on will be described in terms of a façade, it is equally to be expected that some models will only partially comprise domain-specific content that can be described by a façade. So, models will often present a mix of content in various languages, some of which have façades and some which don't: imagine a UML design model that mixes "pure UML" content that describes the structure and behaviour of a system in very abstract terms, linked to refinements of various components in their own DSLs.

This second demonstration of experimental work on façade-based compare/merge in EMF Compare explores working with models that comprise a mix of languages, some with and some without façades to customize the comparison experience.

The video above demonstrates the first step towards support for mixed-mode comparison and merge, in which a model merge is performed in UML terms for abstract design content and a domain-specific façade for more lower-level design content pertaining to a particular technology. As before, check out the prototype on GitHub.

---

Update

Updated 10.25, 27 July 2017

A brief update on the problem of spurious pseudo-conflicts that popped up in the first demonstration of mixed-mode compare/merge with façades.

In the first demonstration video, a problem cropped up in which pseudo-conflicts were detected on erroneous matching of new elements added on the left and the right sides. The consequence was that a correct and complete merge would not be possible. The brief update video, above, shows how this problem can be resolved in the façade model simply by providing unique identifiers for every object to help the matching process.

Welcome to Compare-Land

Yes, it has been a while since I last blogged, and that was before a long run of work on the Papyrus-RT project which just this month reached the all-important 1.0 release. Now I have changed tack slightly, still working on Eclipse open-source projects, but with a focus on the EMF Compare. At least, for now.

I am diving head-first into this project with some prototyping/experimentation in the use of Façade Models for customization and stream-lining of the user experience of compare/merge in complex modeling languages such as UML, especially when profiled for DSMLs (domain-specific modeling languages).

An introduction to a prototype of façade-based comparisons in EMF Compare, aimed at simplifying the customization of the compare/merge experience for complex models, especially UML Profile-based DSLs.

The embedded video is a demonstration, longer than is usual for these videos of mine, of the first prototype of pluggable Façade Providers in the EMF Compare framework. The framework consults the available façade providers to obtain instances of a façade model representing the input models to be compared. The idea is that the façade can more concisely and, in some ways, usefully encode the semantics of the domain-specific language that are significant to the efficient and correct comparison and merging of those models. Indeed, even the very simple example presented in the video shows how domain-specific constraints are easily represented in the façade that enable detection of merge conflicts that are much more cumbersome to implement "by hand" in the EMF Compare framework.

Basically, what happens is that instead of comparing the underlying model content (in this case, profiled UML), the system compares the façades and presents that comparison to the user in its terms. And changes performed by the user on the merge result are propagated by the façade to the underlying model, to be written out when the user saves the merge result.

Check out the video above and get the code in my GitHub fork of the EMF Compare project, on the uml-compare branch. Look particularly at the new plug-in and test projects:

• oeec.facade — some core façade framework bits
• oeec.facade.ui — the user interface for façade provider preferences
• oeec.uml2.facade — extensions to support façades for UML profiles
• oeec.uml2.facade.tests — some JUnit tests for basic façade mechanics and simple façade-based compare/merge scenarios

Where, of course, oeec is just a compact substitute for the org.eclipse.emf.compare namespace.

New and Noteworthy in Papyrus Mars

The Mars release of the Eclipse Papyrus project is upon us. In this release, I went pretty deep on new features in the diagrams, a part of the GMF technology stack with which I have historically been least familiar.

Modeling Assistants

The first major feature in this release was the introduction of Modeling Assistants to Papyrus UML diagrams. The underpinnings of this functionality have been in the GMF Run-time since Callisto but were heretofore suppressed in Papyrus. Now, several of the diagrams provide connection handles and pop-up assistants for creation of objects related to what's already on the diagram. It is still a work in press: some diagrams do not implement them, yet.

The Modeling Assistants implemented in Papyrus are, of course, described by models, based on the modeled element types that are also new in Mars. In fact, these models are hot-deployable from the workspace at run-time and can be generated from GMFGen models of a diagram or from UML Profiles. The latter case is particularly useful for users to complement custom palettes for graphical DSLs.

See bug 451230 for more details.

Canonical Diagrams

The next major feature is an extensible canonical edit-policy (in the GMF terminology) that is manifest to users as diagram views that are automatically synchronized with the semantic model. A new appearance property is added to the property sheet for diagram views that makes them synchronized with the model. A corresponding CSS attribute canonical is also supported for stylesheets. Canonical views automatically present child views and connected edges where possible in the diagram and keep them synchronized with changes in the model.

See bug 433206 for more details.

Diagram Synchronization

This last feature completes work started by Laurent Wouters to implement a general-purpose synchronization framework capable of handling peer-to-peer and master-slave synchronization of model content and diagram notation. On this framework is implemented a proof-of-concept in the UML Real-Time domain: synchronization of the semantics and diagram of a state machine in a Capsule that redefines an inherited state machine.

See bug 465416 for more details.

Enjoy your trip to Mars! We'll see you under the Neon lights next year.