Modeling 2.0 : Let's collaborate!

A bit of history

4 years ago, when I joined Obeo, I started to work on a new modeling tool dedicated to system engineering. The main focus of this tool was to enable system engineers to model graphically complex systems with different representations, for each speciality, depending on their viewpoint. The tool was associated to a methodology and integrated in a modeling workbench.

Separation of concerns by representations was a first step to scalability of graphical representations, another was to add several mechanisms (layers, filters, hide/reveal) to allow end users to hide some elements. The approach is somehow similar on what Miles is working on.

We took the decision to create a generic runtime with the possibility to specify graphical representations and to drive the tooling by the viewpoints. The approach has similarities with Jan current's work, and I think our work inspired him a little bit.

Since the runtime has been used for safety analysis (diagram screenshot) and several other use cases.

However, although our tool primary concerns was collaborate modeling since its inception, we did not offer directly a solution to the concurrent access problem. In fact, we left it to the Revision Control System (RCS) used by end users. As Alex wrote concurrent access management by RCS have several drawbacks, so we decided to offer the possibility for end users to collaborate more seamlessly.

On the technical side, we decided to use CDO, a technology we had experienced successfully in others projects, and which seems to match the most to our requirements. As our graphical modeling technology is based on GMF Runtime, our global technical task was to integrate GMF and CDO.

GMF and CDO, integration challenges

If you are used to component architecture like the Eclipse platform one, you may think that these two components will plug together quite easily. Unfortunately, this is not the case for various reasons :

• EMF Transactions and CDO Transactions
  GMF Runtime relies on EMF Transaction to manage read and write accesses to models. To simplify this means that one is not allowed to do a modification without encapsulating its change in a recording command. On its side CDO provides its own transaction mechanism, which relies on the database store one. So it is necessary to integrate the two mechanisms. This is one of the features Dawn provides (see those bugzilla entries for further information).

• Transactional model break in GMF Runtime
  GMF Runtime is a bridge between EMF models and GEF. Among others things, it provides a notation model, to store graphical information. The synchronization between the graphical model and the semantic model, is one of the responsibility of edit parts. The choice to split the synchronization responsibility in each edit part enables one to easily override the default behavior for a given edit part. This choice is consistent with the high extensible approach of the framework. However, it has one major drawback, edit parts should be instantiated to update the notation model ! As GMF Runtime edit parts creation is done in an post commit listener, when no models changes are allowed, the runtime have to force the transaction using a special option.
  This behavior prevents one to have triggers for those modifications. If you need to avoid conflicts (see below), you will not be able to acquire lock before commit. In this case it means that one have to extract the synchronization from edit parts and to call it at the right time.
• Avoiding conflicts
  If CDO provides live updates of shared models, it does not prevents conflicts. There is two ways to handle them. The first one is to write your own conflict resolver, which will take a decision when a conflict occurs. The second one is to avoid conflicts through locks. Easier to said than to implement, but that the way we choose.
• Lock integration
  To avoid conflicts, the simplest way is to lock automatically elements before their edition. In practice, one could use the EMF Transaction trigger mechanism to do this. Edit parts need to listen to locks events to deactivate accordingly their edition capabilities and provide visual indicators of the lock. Lastly, to provide logical lock for end-users, one may provide a lock strategy.
• Consistency maintenance on client side
  EMF Transaction enables one to rollback a transaction, before its commit. This is generally done for validation or lock acquisitions purposes. The recording command manages this rollback and will abort properly the transaction if it occurs. However with the abort, the CDO state of the object will change (see bug 312534 for more details). To avoid conflicts a solution is to use CDO save points to restore the object to a clean state if a transaction aborts.
   
• Native mode for GMF Runtime notation models ?
  One of the coolest thing of CDO is its EObject implementation, but to benefit from the scalability it provides, you need to regenerate your metamodel with a CDO dependency. When one works with such CDO model instances, the mode in which one is, is called native. As GMF Runtime notation metamodel depends on the EMF one (don't do this at home), using notation models in native mode is far from being easy. So we worked on a solution which keeps source and binary compatibility with legacy code (see bug 336707 for technical details) and provides notation cdo native models, the code is available here (no builds yet).
     
• Content and cross reference adapters
  These two utilities should not be used as they will break the lazy loading mechanism of CDO. By default GMF runtime initializes one cross reference adapter when configuring the editing domain. You could quite easily override the default behavior. EMF Transaction uses an adapter that walk through its content, but removing it is much harder. 

On our product, the work is still in progress, but we he have implemented solutions for most challenges presented above. During this work we opened several issues :   

• fixed : bug 345719, bug 352191, bug 355915, bug 337870, bug 353167, bug 329753, bug 315570, bug 329869, bug 329752, bug 353076, bug 351393, bug 351921, bug 325436, bug 346378
• not yet fixed : bug 339908, bug 352189, bug 352977, bug 352204, bug 357400, bug 329786

As you may seen, the CDO team has been very responsive, and already provided fixes for most of them. I would like to thank them for their availability and help.

This blog entry present results coming from a work collaboration between Thales and Obeo.
Ce message de blog est issu d'un travail en commun entre Thales et Obeo.

About modeling workbenches

I was last week at Cambridge for Code Generation 2011.

That's the first time I attend to this conference, and I feel I have missed for several years, agreat opportunity to discuss and share ideas about modeling beyond Eclipse community.

One hot topic of the conference was language workbenches with a competition dedicated to them one day before the official start. You will find several summaries on this first journey with the several presentations, including the Obeo Designer one. I really enjoyed this workshop and discovered interesting new workbenches such as Essential or Whole platform.

The day after I presented how you could create easily your own modeling workbench mixing several kind of editors. If you did not attend, following is a summary of my presentation.

I started by explaining why particularly graphical DSL are more interesting than UML if you want to raise your level of abstraction rather than level of complexity.

UML graphical notation, along being not specific, is ambiguous and not intuitive.

Building a graphical or textual DSL should be driven by end user way of work and data you model.

Neither expect from an emacs user to program by drawing some kind of diagram sequence, nor expect from a powerpoint user to create a flowchart by literally typing it.

One of a key point for a modeling workbench is its ability to support collaborative work, which means enable people with different concerns to work on the same models.

A modeling workbench should adapt to the workflow of users and set process with conflicts handling.

Modeling is valuable in itself, however you can reach another level of productivity gain when you use models to produce deliverables : code, documentation or settings file.

A modeling workbench should manage de- synchronization between models and the deliverables.

Obeo Designer is a modeling workbench platform which focus on adaptability, flexibility and tooling. It is based on eclipse modeling projects.

For instance for text generation it includes Acceleo, a template based approach generator with featured editor, debugger and profiler.

It includes also Viewpoint, a graphical runtime to specify graphical representations such as diagrams and table editors. You don't need to generate any line of code to specify representations.

Viewpoint provides several mechanisms to display only relevant informations such as layers and filters.

Live demo showed how to create such editors to edit graphically models and then did a model transformation from UML and a code generation to Java.

This platform has been used for several Obeo customers and partners with different kind of editors and with various generation use cases.

For instance for safety analysis with FTA diagrams.

Viewpoint technology is also capable of drawing advanced diagrams for your domain specific models such as sequences diagrams (including interaction uses and combined fragments).

Even if you should often avoid UML you may have to deal with such legacy models.

So we provide open-source UML editors you could easily extend or integrate in a descriptive manner.

If you want to know more, presentation slides are available online.

I attended to a lot of interesting talks, but if I should to retain only two, it would definitely be the keynotes from Terrence Parr and Ed Merks. Strong opinions, good sense of humor, and a understandable speech to explain what they have realized.

Obeo Designer @ Code generation 2011

I will be speaking at Code Generation 2011 about Obeo Designer, our DSL Studio based on top of Eclipse modeling technologies.

I will notably present several customer use cases of graphical workbench dedicated to end-users and how the platform flexibility and extensibility allowed us to overcome challenge we faced.

Process modeling

Temporal specifications modeling

Speaking about obeo designer, we are currently working on the next version, which will include following eclipse project versions :

• Acceleo 3.1, with ant and maven better support, generators documentation, and syntax coloring configuration
• EMF Compare 1.2.0, with Filtering capabilities and UML dedicated comparison engine
• EEF 1.0, with one click generation and EMF/Edit alternative

On the Viewpoint side, we will use these technologies :

• The viewpoint specification editor properties will be based on EEF
• Acceleo 3 queries will be possible with completion and live validation

Acceleo 3 queries with live validation in EEF properties

Obeo new modeling box is coming

At Obeo we are currently working hard for the finishing of the next version of our eclipse based modeling studio named Obeo Designer.


Obeo Designer 5.0 embeds our latest modeling technologies.

• Acceleo 3.0.2
  

Acceleo is a text generation tool. If you think that code generation sucks due to its lack of tooling, then you should probably try Acceleo. Its offers much more than a complete eclipse editor with syntactic coloration, code completion and quick fixes. For instance it provides an integrated debugger :

Acceleo debugger

Acceleo is a technology that has been recognized as innovative and effective.

• Obeo Traceability 2.0
  

Obeo Traceability is a tool to manage the synchronization between your models and the generated text. For each model element, you are able to know which text section have been generated and navigate between text and model. If you decide to modify the generated text, Obeo Traceability will automatically indicates it, and offers you the choice mark the section as not generated or to update model and generator.

Before modification on the left and after on the right

Obeo Traceability provide these features with a user interface completely integrated to Eclipse.

• Viewpoint 5.2
  

Viewpoint allows one to create easily graphical editors. Easily ? For each editor you simply define mappings between model elements and graphical styles along with tools which describe modifications to make on model in response to user actions. Graphical editors ? you could specify diagrams, tables and trees and the API allows you to define your own kind of editors.
See example editors below made with Viewpoint.

Diagram editor

Table editor