jeudi 28 octobre 2010

Sequence Diagrams for your DSL's

We're working a lot on Obeo Designer 5.0 - release planned for Q1 2011 , on the traceability support and the next-gen model to text transformation language.

Concerning the editing and diagraming support changes are more subtles though powerful. Here is a quick glimpse on the latest milestone :

The most visible change is the work on the diagram ergonomy, the user interface has been cleanup, streamlined and features are more accessible. The global toolbar has been replaced with a dedicated toolbar embedded in the diagram editor providing access to the filters and the enablement of layers.
The contextual actions have been re-organized too.

If you're used to nice Eclipse editors you'll be happy to learn that the "Quick Outline" (summoned thanks to CTRL+O) is available in the diagrams now.

Just type in any word here, and the corresponding model element will be revealed in your diagram.

More interesting is the redesigned support for diagrams ! You can, for any kind of model being UML or your own DSL, specify and leverage a diagram editor keeping the model sequence order in sync with the diagram ordering.

you have the same level of customization that for the other kind of diagrams, you can change the shapes, colors and use the sequence diagram constructions like lifelines, messages and executions.

Here we're not using UML but our own "interactions" DSL which refers to another DSL describing domain entities.

As a sidenote, you can now have a color definition which is interpolated on a color palette depending on some model computation. Here we have a nice shade of green depending on the level of execution.

In a nutshell this new release will bring you more control, to the visual aspect and interactions on the tooling, the ability to define sequence diagrams, still keeping the complexity to a minimum : no deployement requirement, one file describes the whole design environment which you can test and try without even starting an Eclipse runtime.

It doesn't mean you can't deploy your environment as a set of plugins with proper dependency checking thanks to P2, it's just that you don't have too.

If you don't know about Obeo Designer and you want to setup a dedicated design + transformation toolchain for your domain, have a look here.

Here is a flash demo being a recap of these features :

mercredi 13 octobre 2010

Model Comparison : Patching with MPatch

The following message is posted on this blog on behalf of Patrick Könemann

Cédric already announced it two weeks ago: MPatch is integrated into EMF Compare!

Did you ever want to transfer changes from one model to another?

Or do you frequently perform the same changes on your models?

MPatch is a technology that stores model changes as self-contained artifacts, just like patches, that are also applicable to other models! Let me show an example of how MPatch works:

This is just a simple model, a base version on the left and a modified version on the right.
Modeled with the IBM Rational Software Architect, but any kind of EMF model is supported.
The changes are highlighted: 3 deleted attributes, 1 updated attribute, 1 new class, 3 new generalizations.

EMF Compare is a nice tool for calculating such changes. The result is shown below.
All changes are nicely highlighted in the treeviews and one can browse through them.
This is where MPatch comes into play: the export menu lists a new option!

An export wizard is started that guides the user through the MPatch creation task.
In the end, the changes are stored in a file, extract_id.mpatch for example.
This file can now be applied to other models, even if their contents differ!

The model below is a different one -- again we want to extract the id attribute into a common superclass.
However, the attributes, the classes, and even the number of attributes and classes differ!

Let's see how MPatch handles the situation.
Selecting Apply MPatch triggers a wizard with the same name.
The crucial part is the so-called resolution of symbolic references -- they are responsible for selecting the proper model elements of your target model.
Let's have a closer look:

  • The first change is not applicable because there is no attribute called Title -- ignore this!
  • The second change is applicable because a similarly named package (data vs. customerdata) is found -- ok.
  • The third change is applicable because I manually selected Contract and Invoice -- ok.
  • The fourth change is applicable because similar named attributes (id vs. inv_id / con_id) are found -- ok.

Following the wizard to its end updates the given model and this is the result:

To wrap up, an Mpatch is not only a self-contained patch for models, it is even able to make the changes applicable to different models!

Installation instructions and a lot more information on the project website:

vendredi 1 octobre 2010

Autumn is a second spring when every leaf is a flower

Maybe twitter gives a false impression that you're keeping the users informed of what is going on. False because 140 chars can't be enough !

Many things are keeping the Obeo guys busy, from the Eclipse and open-source involvement to the incubation of highly innovative products you'll love while still providing the best service to our customers looking for expertise :) .
Oh, and we provided the first Helios service release for Compare, Acceleo, EEF, ATL and much more, go get the modeling package !

Summer is an internship time in France, and for us every internship's ultimate goal is to hire another great person. I can say we did succeed this year ! Expect even more great contributions, user experience polishing and features for Indigo !!

Furthermore the newcomers completely understood the chocolate-commit spirit ...

No doubt you'll hear about those guys at some point, Stéphane already started to blog...

Speaking about Indigo, we wrote down a "long term roadmap" for EMF Compare on the wiki, feel free to have a look ! Coming soon : more information about the MPatch contribution recently integrated in EMF Compare.

Ok, enough teasing, back to code generation. In case you did not noticed Acceleo 3 provides one of the most compelling editing tooling you can get with the Eclipse platform. Using the JDT I often find myself thinking "oh, they did though about this ! great !" : you'll often get the same feeling with Acceleo 3...
Let's try with an example: it's often useful to be able to call Java logic directly from a template. If you want to do so, start by writting down this java logic.

Then call it from your template, obviously it's not going to work as is. Here we're calling the "getJavaCompatibleName" method on an EClass, but this method is not existing on this type. Acceleo provides a mechanism to call Java logic associated with a given meta-class: the first parameter of the method have to be of the type of the extended meta-class and Acceleo will automatically transform a myInstance.myMethod() call to a SomeClass.myMethod(myInstance).

If you want to try that, call the quickfix menu on the compilation error with CTRL+1 :

Choosing the "Create Java Service Wrapper" quick fix will add a new query to your template :

And your done !

mardi 27 juillet 2010

Eclipse Helios - a whole year of goodness

Eclipse Helios is a release, but it's also a complete development cycle in a global and distributed team of commiters. Since I choose 3 features I especially liked in Helios this kept bugging me : what is Helios to me ?

Helios will have its place in my memory, not the bits themselves but good things we had as a community.

1 - The Acceleo Community joins and starts by using black magic to build bits

It's just the begining of this move but so far it went pretty well :)

2 - Eclipse Summit Europe is the best Eclipse conference to meet friends

3- The dreaded diamonds of the Simultaneous Release are still haunting my dreams...

4- Our friend Hudson is now serving way more projects, but not always happily.

5 - The Foundation keeps moving things forward

Last but not least, this Helios cycle was filled with more interactions with end-users and adopters leading to nice enhancements in Eclipse as a whole, thanks for your help !

lundi 28 juin 2010

3 Good Reasons to use the Helios Modeling Package

Now that the entire world noticed that I don't know even one thing about soccer and I'm even trying to cheat, I should get back in sharing what I understand instead of those silly forecasts.

Helios has been out for a little while now, the mediatic storm is pretty much gone and it's a good time for me to have a look back.

This year one of my goal was : "I want to transform the Modeling Package in a product which I would use myself". I've been using it quite extensively lately and I'm pretty happy with the results, the Galileo package is far from being usable but the Helios version is just great :)

Why ? a few reasons...

1. because it's including hidden EMF goodness !

EMF generates code... which is good as any code you don't need to write means less bugs. But sometimes you don't even want to see that code !

If so, you're lucky, there is a specific filter for your workspace !

And the integration goes even further, code you manually changed is highlighted with different colors !

Oh, and you can compare and merge any kind of emf model, starting from the Ecore ones.

2. It provides Class diagram support

As a developper you always ends up needing some kind of graphical support for your communication, a class like diagram is well known by others, the modeling package includes support for Ecore thanks to the EcoreTools project.

And you even have specific views to browse your design hierarchy or usages.

While I'm at it, if you're interested in contributing to this project which is highly popular, you should really get in touch with Ed ! We're looking for fresh people to reboot this project, it's not as active as it deserves to be !

3. It's an SDK

As the modeling project provides a lot of high quality frameworks, you often need to have access to their source and as such it's one of the few packages providing SDK's.

All those reasons are making the modeling package the best one to get started with any modeling task but also any RCP development planning to leverage those great frameworks.

Oh yes, that should make this package a nice starter for e4 too :

post scriptum : 4. It's easily extensible

Of course the modeling community is way more active than that, I would strongly encourage you to have a small click on this button and have a try on the latest hot contributions which were not part of the Helios release the Agent Modeling Platform :

And the Papyrus UML modeler

And now it's time for you to download this package !

Forecasts Comparison For The World !

I have to admit I know nothing about soccer. Yes I'm a french guy, but I know nothing about soccer. That said I'm not against having a few beers in front of this broadcasted green field and I'm always in when its about having fun with a small game leveraging Eclipse technologies.

Obviously I played with the EEF based rich client for the forecasts, and from the moment the source code has been made available I started hacking the code.

The forecasts, matchs and results are all kept in a model accessible through an http uri, and as EMF rule them all, find them, bring them all and in the darkness bind them, you can leverage any Eclipse Modeling component to hack something quite easily.

That's what I did with Compare.

I extended the EMF editor adding a specific action, "Compare with / Player with Best Rank"

This action allows you to compare your own forecasts with the best ones, and then merge your own forcast with the best player one (Noooo, that's not cheating ! )

And here is the user interface you get for free*, with a pure semantic comparison :

* you have to depend on EMF Compare though...

Here is the logic needed to launch the comparison :

I had to use a few tricks, I had to provide a specific match engine enforcing the match of two players, otherwise the Compare component stop matching the forecasts from the beginning as the players are differents.

That's all for today, If I can free more time for this hack I'll provide a diff extension to change the score delta representation to a more meaningfull one, so far it's left as an exercise for the reader ;)

vendredi 18 juin 2010

Eclipse Modeling Survey results

The survey has been going on for more than one week now and the trends are only enforcing themselves. Let's summarize it:

First, the audience represents many non-commiters (2/3) though the commiters are still quite represented. That's quite consistent with what I was expecting, the survey was published on the planet, some newsgroups and through twitter and as such targeting commiter or adopters following quite closely what's happening in Eclipse Modeling.

Concerning the package size, we're right now at 250MB, it looks like it's mostly ok but being a bit smaller would still be nice.

As the package is an SDK we could probably drop most of the dupplicated javadoc in the plugins.

This one is interesting, it's something we're hearing and hearing again at each Eclipse conference, users do want more documentation, moreover best practices are hard to reveal through the wiki, newsgroup and online help jungle.

There is probably something to do here but, hey, there is an EMF Book already, an Eclipse Modeling one and everybody can contribute on the wiki, so why isn't this urgent need covered yet ?

It might be because:
  • People are not even aware of these books or books are old fashioned now : all content should be on the web !
  • It's so hard to understand what each project is providing that one really needs some Modeling Guide.
  • As a user you always want doc even if you won't ever read it, it just gives you the confidence that the technology is not going to vanish in a glimpse.
  • [ ] <----- any opinion expressed through the comments
It's even more disturbing when ...

yes, most people would be willing to give time to make this happen. We might need to do something here, maybe crowdsourcing the doc would do the trick... What is pretty sure is I wouldn't like it if Eclipse Modeling commiters spent half of their time documenting : we should make it easier for the adopters to contribute back.

And yes, writting doc and books takes a huge amount of time !

I asked another related question in the survey about "examples". In fact examples are way easier to provide and in my opinion are more valuable in most cases. And when you look at it, each project is already building its own examples, but these examples cannot be composed in some way. Just like Toast is a best practices application for OSGi, we would need a modeling one.

At its beginning the Amalgam project was providing some; yet since these examples were not part of their target Eclipse project (EMF examples in EMF, ATL examples in ATL) they were not maintained correctly. As a result they are not reflecting the "state of the art" of Eclipse Modeling anymore... Maybe for the next release !

I'm done for the strong trendes, others questions like "Having on the shelf design and generation tools" or "Domain focused UI instead of component focused one" were quite uncertain.

A few more ideas or questions have been given through this survey,
It will take another blog post to describe those.

Thanks again for your feedback !

mercredi 9 juin 2010

Eclipse Modeling Package Survey

I've been quiet in the planet lately, it doesn't mean I've been inactive, quite the contrary in fact, just like all the other commiters I've spent the last few weeks polishing the Eclipse Modeling Helios release. (As a sidenote, I'm giving more update from here --> )

And now the final bits are almost here ! More info about what's new in the Modeling Package soon, but you might have already seen that we have a pretty good feedback :) .

Helios is almost public now, we're already wondering what shape Eclipse Indigo will have, and to do so I'd like to have your opinion. I compiled a tiny survey, 6 questions you can fill in seconds.

I'f you're interested in Modeling in General, and Eclipse Modeling in particular, please spend the next seconds filling this survey.

the survey is embedded in the post or accessible here

mercredi 28 avril 2010

Compare/Helios - Every Second Counts

I tend to break a lot of keyboards. Not because I release all the aggression that I hold deep within me on them, but because I drool testing the product Obeo is going to launch really soon now.

During EclipseCon 2010 It struck me that some keyboards might have died because of EMF Compare. Ok, no more drooling here, the colors are nice, but when you are using compare with pretty decent models (like thousands of elements) you end up thinking it could be faster.

Hold your breath, order your very last keyboard which you'll use for a long time now, Compare's scalability has been improved a lot both in terms of performances and memory.

This work was pretty focused on the matching pipeline, there is room for improvements in the other parts of compare (especially the UI) but the matching was just so obviously slow and is even called 2 times for the 3 way match. That wa just making sense to fix things there.

The performance test case is using UML models containing 1,000 to 256,000 elements organized in a decent way and is matching them several times, here are the results before the scalability sprint:

Yes we have quite a strange value for the 1000 elements model, after investigation it looks like it's just some kind of corner case.

The last models have no time result for the simple reason they use all my memory and I end up with this dreaded OOM error.

Here are the figures after the sprint:

Now I can feel from here that you've been thrilled by all these figures and you only want one thing : to get your hands on this release. The Helios M7 release will be a good time to do so, wait for a few more days and go ahead: give us feedback !

Not only will the Helios release provide these major performances enhancements but the future looks even better: Stefan will work on a new match engine implementation focused on scalability for his google summer of code.

Waking up as every morning, getting up but being a bit happier than usual as I know I made progress on something important for adopters :)

Please, keep in mind that your feedback made me work on this, thanks again.

vendredi 26 mars 2010

I'm a poor, lonesome cowboy ..

I'm a long long way from home.
And this poor lonesome cowboy.
Has got a long long way to roam ...

That's right, EclipseCon 2010 is over, each year it gets better and better and leaving it is always a bit sad.
I'll use this blog post as a memento of my feelings and the things I noticed during this week:

  • Many people are using EMF Compare. That should not be a surprise as it provides a key feature for anybody working with models, but still it gives me a warm feeling :) The ECon attendees provided me a lot of very relevant feedback, among others it looks like scability is not so nice when one is using a big model. Don't worry, I'll work on that (In fact I already started) and you can expect a performance boost, even for the generic engine. More of that in a future blog post with figures.
  • People are now used to the idea of e4 is going to exist, it will provide new means for writting application, I also have the feeling that people understood that e4 is going to be what WE as a community, wants it to be.
  • ATL is definitely THE model to model transformation language, it's mature, and now thanks to William's work the tooling is a bit closer to the perfection.
  • CDO is one of the most amazing framework I had the change to use, it's quite unbelivable that such a small and slim framework can provides you such a power. You need years of engineering and professionalism to achieve this. congrats to the whole CDO Team !
  • I have a lot of hope for the Mylyn Review project, the approach is simple but perfect for people like me, it will just be "yet another key feature" of the IDE. In fact the whole Mylyn project is providing, as usual, innovations.
  • The Sharks Rocks ! They blasted the Dallas Stars ! And I guess I'll be more interested about hockey now :)
  • Pascal has not been abducted by aliens, he is still the same although being transformed in a Maven guy now.
  • Modeling is everywhere. It's just pervading on everything : from your IP Log to the next generation platform you'll rely on.
  • End users really appreciated the work I did on the modeling package, Here again, thanks for your feedback.
  • Xtext was everywhere, and will be a key asset for the upcoming IDE generation.
  • The Eclipse Foundation did a tremendous work for this event, and it' s been perfect ! Thanks again !
  • Acceleo is so powerful that many people expressed their wish to use it for their code generation needs : step one on the "taking over the world" plan is validated.
  • Nasa, Rockets and Robots are cool.
  • The Architecture Council is taking more and more initiative and Martin is doing a great job driving it.
  • Now that EMF is everywhere everybody wants to use EEF
  • Huge companies like SAP or Thales are building their tooling strategy around Eclipse - not only as a platform but also as a community.
  • I already said "No" to my manager at least two times !
  • Such a conference in an hotel can work, and it's actually even better than in a Convention Center, we have nice couch, a bar, it makes discussion way easier.
  • Having tutorials in the morning during the whole week is great, then you start smoothly, learn things and code : I can fill my addiction.
  • It's possible to create a conference program of high quality (the best I had in the previous four years to my opinion), with such a diverse community. Kuddos to Oisin !
I'm pretty sure I'm forgotting things, but anyway, I really need to sleep now...

In a nutshell : the best conference ever :)

mardi 23 mars 2010

Diff, Merge and Patch your Models with Helios

Ok, you're stuck at home, you are one of the numerous budget shortcuts victims ? You did not had the chance to come at EclipseCon ? Here is some kind of transcript of the talk I just gave:

This talk will tackle team-working with models. Once you use models in your development proces, they matters as much as the source code. Don't you want to be able to diff, merge or even patch your models just like with text files ?

The good news is that unlike text files models have a semantic structure defined thanks to their ecore model, as such we're able to semantically compare the models, comparing the serialization (XMI or other..) is often meaningless.

By the way I'm the project lead of EMF compare, the project has been contributed in Eclipse in early 2007, at that time many EMF adopters realized that this piece was missing in the Modeling ecosystem and this lack was often a blocker !

So here we are, three years later. EMF Compare - in the EMF Technology project at first- graduated and is now part of the EMF project itself !

Just like Transaction, Validation or CDO, Compare is one of the many pieces you can reuse as a framework, or just as a tool. Its focus is quite narrow : comparing, merging and patching any kind of EMF model, the later being an UML model or a domain specific one.

As we graduated we've been focusing on keeping stable API you can rely on. We really think that EMF popularity is highly due to the fact that depending on it is easy as it is completely forward compatible. Working nicely as a pure Java jar library is another key asset of EMF, we tried to stick to that for the Compare project: our framework can be used as a Java jar, not depending on Equinox or any extension point.

We could phrase the Eclipse IDE spirit in : be extensible, be customizable, be integrated. We are sticking to this motto too, you can extend or customize any part of the comparison process.

The compare and merge features are completely integrated with the Eclipse Team API. When you launch a comparison from the workspace or from an history, if the file is in fact a model, EMF Compare will be opened and will show you the differences, allowing you to merge, or switch back to the serialization diff.

Let's have a look on the tool through a demo. This demo goes higher and higher in coolness, as such it's starting by comparing an old fashioned UML model on a dying CVS Repository.

A bit more cool : comparing a domain specific model on a SVN repository.

Total coolness : comparing an XText DSLsemantically, merging it, on top of a GIT repository !

That's just the tip of the iceberg, EMF Compare has a few more features and is especially useful in a lot of contexts, rather than listing all these details I'll focus now on the inside, revealing you which kind of magic make this clock ticking.

As I said at the beginning, the good news comparing models is that we've got semantic information we're not comparing plain text. There is a drawback though: models are graph and as such being able to match similar graphs is a complex and tricky problem.

The first thing we have to do for a comparison is to match the elements from both versions of the model.

If you've got ID's that part is trivial, EMF Compare will use your ID's (either business one or technical ones). On the other hand if you don't, we are providing what we call the "generic match engine", this engine uses a few statistical metrics to match the elements.

For a given element this engine will extract it's type information, the content values, its relations with other elements and its name if we can detect one. Each piece of this extraction will be compared with other elements to compute a similarity coefficient, from this one we can try to get closer and closer to the perfect match.

Once this engine has done it's job, it provides a Match Model grouping all this information and weaving the other models.

It gets more complicated, (and then more interesting) when using source control management systems. Then you have to match three versions of a model: yours, the remote one, and the common ancestor between those versions.

To do so we builds two match models, between your local version and the common ancestor, then between the remote version and the common ancestor, and we combine those two match models into one, weaving the three models altogether.

At this stage it should be obvious that the faster the match engine is, the faster you'll get a result.

To be honest the generic match engine is not so fast, having little clue about the models it's matching it spends a lot of time browsing the structure, trying to match things which probably have no possibilities of being the same..

Being aware of that we eased the definition of your own match engine specific to your Ecore model. In doing so no doubt you'll get better results and way faster.

Let's take a step back. What are we trying to do ?

We are trying to change two versions of a graph into a set of events, in reality we are trying to re-construct "a posteriori" the history of the graph: what changes have been made to transform the original one to the new one.

Match computation is done by the Match Engine, the Diff one by the Diff Engine. This processor has to provide a Diff Model from a Match Model.

In fact, when you have the MatchModel, deducing the DiffModel is not a huge task, you basically have to browse the matched elements, checking for changed attributes and reference, and then create for each "unmatched element" the corresponding deletion or addition event.

Here again, you can plug in your own diff engine, and you can even define your own diffs specific to your formalism. Instead of having a "stock value changed from 12 to 34" event you can define yours as being "stock value has been increased from 12 to 34" and even aggregate several atomic diffs in a single top-level one.

Being a first class model itself, the diff model can be leveraged through model to model or model to text transformation to publish the changes to another format.

Now you should have a basic understanding of what EMF compare is trying to solve and in which way. We've seen that stability both in term of API and code was our primary goal right now but does that means nothing new is being done in Compare ?

For Helios we fixed many issues thanks to the community feedback, support for fragmented models and matching of referenced resources has been greatly improved.

The primary feedback is bug reports, but we also had quite a few contributions among those a new API to scope the matching process and a whole new set of plugins to create model independent diffs resilent to transformations in the model you want to apply the diff on.

So many things to discuss in such a short time frame.
Give it a try, EMF Compare is part of the Eclipse Modeling Platform SDK, download the package and you're done.

I would be happy to discuss with you, either IRL or through electronic means. Please uses the EMF newsgroup, the bugzilla or the #eclipse-modeling IRC channel on freenode. We're also available and new trendy channels like Twitter : @bruncedric.

Want's more ? Have a try downloading the Eclipse Modeling Package !