Modeling Symposium

In previous years, the Modeling Symposium at Eclipse meetings in Europe attracted a large panel of attendees interested in sharing their ideas and in learning about the projects of others in the community. At the last event, we had fifteen interesting presentations and the room was full.

This year, there is no session planned for the symposium, so it will take place during a BoF on

Thursday, November 3rd
at 19:00 

If you are interested to show a demo, exchange ideas, or gather feedback about a proposal, please contact us with a short description about what you would like to talk. We hope being able to announce an exciting agenda.

Collaborative modeling, the new deal

 I already blogged about collaborative modeling but I would like to stand back from the previous post, which was very technical, and introduce the talk I will present with Martin and Benjamin at EclipseCon Europe.

Since several years now the Eclipse modeling platform provides useful tools which have help to democratize the use of modeling technologies. However those tools have raised issues linked to collaboration we start to better address.

To visualize and edit models in a graphical manner diagrams are often used. However  usually diagramming technologies do not scale well and this is problematic as the more the models and their complexity grow the more one wants to work in group.

When you model with other people, one of the difficulty is to understand reasons behind their choices and design. Document them is of course necessary but the main difficulty is to keep documentation accurate across refactorings and changes.

In fact, often the more the time flies by, the more we lost the intention, documentation being seen as a post-design step.





Collaborate means dealing with concurrent accesses. To enable them you have two strategies. One is to prevent conflicts either through models splitting or with locks. But models splitting is not well supported by tools and coarse-grained locks are not pratical.

 

The other strategy is to allows conflict happens and deals with them when they occurs. It looks like a dice game, and depending on the frequency, it could become hard to deal with conflicts.

Interested by the subject ? Come to the talk to discover what are the available technologies to address those concerns, and understand why collaboration matters in modeling.

Acceleo 3.2

 To celebrate the historic victory of the french rugby team in the world cup quarter final, the Acceleo team is proud to announce its 3.2 release very soon.

Photo from NikRugby23

 

• We tackled performance problems in compilation. Acceleo is now as fast as Vincent Clerc, and even if you totally don't know who he is, you will appreciate the better reactivity of the tool.  

• We provide a new useful view to test Acceleo and OCL expressions on the fly, the Acceleo interpreter. You will find more details and example of usage of the interpreter in the Laurent's blog entry.

Screenshot of Acceleo Interpreter

Want to join the scrum  ? You could install a release candidate and give us feedback before the final release planned for October 24th.

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.

EclipseCon Europe submissions advice

EclipseCon Europe submissions deadline is approaching, and I received already several advice requests. So it's time to share some hints for increasing chance of being accepted. Just a reminder before the enumeration, we are several people in the program committee, and every one of us has his opinion and his sensibility, so do not blame me if your talk is finally not accepted.

• Read the submission FAQs 
• Submit before August 3, 2011, you talk may be accepted early ! Early bird winners will be advertised on the website, and speakers will receive a special gift. 

  Photo from Magnethy

• If you submit a talk about well known Eclipse Project, or a talk already presented several times, consider an original presentation format.
• Blog about your submission to give further details and provide us some screenshots if it's worthwile. You may also receive interesting feedback.
• Be reactive if the committee ask you details about your submission.

Hope to read you soon.

EclipseCon Europe needs you

  I have always appreciated Eclipse events, and see them as a great opportunity to meet the community. I think that from connections made over frosty beverages could emerge new ideas and durable collaborations. This year the convention in europe will celebrate 10 years of Eclipse, it's an unique chance for measuring the road we have traveled, but also to discuss about the future and new ways to explore :

Photo from FlyingSinger

But August 17 is approaching and if you dot have done it yet, it's time for a submission. To not miss accidentaly deadlines there is even a calendar you may import.

Last but not least there will be Java 7 summit organized by Oracle this year, another reason to come.

SWTBot @ Eclipse Party Toulouse

Eclipse Indigo is here !

If you come back from vacation, or dot not follow Eclipse community on a daily basis, you may have missed that once more, the eclipse annual release train has been shipped on time.

To celebrate the event, Toulibre organized last thursday an eclipse party with several talks and a great attendance. This was a great opportunity to give a presentation about a tool I am working on.

 SWTBot is a small open-source tool, dedicated to functional tests. It focuses on helping writing easily UI tests with a nice API.

  Developers are aware of unit tests, TDD is now a common practice and uncle bob converts each day developers to clean coders and craftsmen. But focusing on internal quality is not sufficient.

  Functional tests enables one to ensure that your application works as expected from an end user point of view. When you do not have a tooling to automate these tests, you should run them manually, which is time consuming. If you should release often, it will be costly, and if you have a limited budget, you will release less often. In others terms, due to budget restrictions or due to the necessity to meet deadlines, this is often the manual quality tests which will be dropped.

  SWTBot API wraps each SWT widget. It hides synchronization with the UI thread through a fluent interface, making tests very readable.

SWTBot provides matchers (thanks to hamcrest) to find easily controls and conditions to write robust tests, independent of the execution context.

  One great small unknown feature of SWTBot is that it will take a screenshot each time a test failed, this will give you clues to find what went wrong.

  You will find a lot of information on SWTBot on its wiki page. But if you hesistate to have a look to this technology, fear of losing time in configuration and information seeking, follow this tutorial and in 5 minutes you will have written your first test.