With Eclipse Luna comes a complete re-implementation of EcoreTools, the diagram editor for Ecore. This is an important piece of news because EcoreTools is often the first step our adopters have to go through. Users are expecting to have a diagram editor to design a domain model. They are expecting this because they are used to this notation, they learnt it at school or university and even just this ubiquity makes it powerful in itself.




And that's why EcoreTools matter. And that's why EcoreTools matter even more for an organization like Obeo.

But then what happened ? Why did this project have been stale for years ?

How it all started

Let's come back to the creation of this project. The proposal has been submited in 2007, and in 2008 EcoreTools 0.8 was shipped with Ganymede.
At that time building such a graphical modeler was quite costly, even with the GMF runtime and Tools which were leveraged by the original team, going from a very basic diagram editor to a complete tool with a consistent user experience was a lot of work. And they tackled this work and had progress from version to version up to the end of 2009 when the company behind this effort got acquired and changed its focus. The project entered hibernation then.
Because it was a key component of the whole modeling eco-system, Ed Merks and I stepped up to take care of the project, leading it through the bare minimum so that it can be part of the release train and still exist. The plan at that time was to find other people interested in investing in it, unfortunately it did not happen and I can't blame them, as I said that was costly, an investment you could not do without clear gains to expect.

Then Thales and Obeo open-sourced Sirius within Eclipse : a complete tooling and framework designed to build rich modeling environment efficiently, also designed on our experience with the shortcomings of the GMF Tool project. Creating an Ecore modeling environment then became barely more work than maintaining its build. I already had a starting point as we built an Ecore modeler with Sirius before, but many things in this tool were not quite exactly as I wanted it. That lead me to rethink all the interactions to provide a tool which actually assist you in design a good Ecore model easily.

I started by inspecting the usages of "EcoreTools 1" or our own commercial modeler internally. At Obeo we are designing Ecore models all the time. We have customers which do need to design Ecore models often, we do consultancy projects in which the Ecore model is the backbone of all the tooling we are building, yet EcoreTools 1 was not used at all and our commercial modeler was almost exclusively used to produce diagrams for the documentation and deliverables. And when I digged deeper, I realized the tool was just barely helping compared to the tree editor provided by the EMF Project itself, and sometime was even "getting into the way".

I also wrote down scenarios of usage for the tool using personnas. Both these efforts have been enlightening : I could clearly identify usability problems and expectations regarding the tool. I came up with a few key points to focus on :

1 - making sure EcoreTools was providing more value to users knowing Ecore than the Ecore Tree Editor.
2 - making sure that EcoreTools will not make you "look bad" when using it with a customer

Ecore Support

EcoreTools 2 obviously allows you to design Classes, Datatypes, References and all the classical Ecore constructions, but Ecore is way more than that. There are different concerns involved in expressing your domain model: documenting, reviewing the referencing mechanism of elements, identifying business constraints, exploring the model... Specific tools have been implemented for these concerns and most of them are "opt-in" in a given diagram through the activation of a dedicated layer.

Documentation

Bi-directional references

Constraints

Domain constraints can be listed directly from the diagram once you activate the "Constraints" layer. EMF will then use this information to generate all the required plumbing so that you just have to fill a java method to implement the actual check.

Generics

Ecore has been supporting Generics for quite a few years already, EcoreTools allows you now to express Parameter types and use them in references or operations.

Packages Dependency Analysis

Often domains have relationships to other domains, and this is reflected in Ecore models through direct referencing. But keeping track of those dependencies between domain packages proves to be hard in practice, you have to digg through every Class to see if it refers to something which is external. EcoreTools provides a diagram which is dedicated to see and analyze those dependencies.


And also a dedicated decorator for classes which are from another package.

Productivity

To be productive the tool needs to be at your fingertips. EcoreTools provides many shorctuts to make your life easier, especially regarding references and attributes. Typing "1" will make the reference or the attribute mandatory. Typing "*" will make it a "many". Just typing a name will only change the name, but typing ": someTypeName" will set the type.

You can't really discover those shortcuts on your own, so feel free to have a look on the documentation, but once you'll know them you'll be quicker in designing your Ecore using the diagram editor compared to the classical tree editor.

Many more things have been done to make sure the tool doesn't get into the way. All the references can be reconnected graphically, the modeler can be used in "full screen" with no other Eclipse views around while keeping a good usability, EcoreTools will take care of your GenModel too by reloading it when necessary.

Design and Feedback

From a graphical point of view I tried to keep the original visuals, only make them slightly more appealing. Colors have been aligned to the Eclipse Standard palette. Classifiers now have rounded borders, icons and text style are used to convey the difference between Classes, Abstract Classes and Interfaces.
Boldness is used for anything which is mandatory, blue for anything which is derived.
These are the kind of things you can think of if you can quickly turn-around and try in your graphical modeler, and Eclipse Sirius enables that.



A tool is helpful when it is giving you the right information at the right time. This is all about feedback.
EcoreTools 2 is highlighting in red any construction which is not valid. You want to know that as soon as possible.

But feedback is not always immediate, only if you enable the "documentation" layer to annotate your model, then the red borders will be used so that you can quickly identify elements which have no documentation.

How much work was that ?

Of course it is slightly biased because I know Sirius really well. I was actually part of the team building it for years now so anything I want to do in EcoreTools I can quickly see how I'm going to do it leveraging Sirius.

Nevertheless here is a typical change introducing the constraints support in EcoreTools, this is mostly about expressing, in the Viewpoint Specification Model of Sirius, what you want to achieve.

















No code generation is involved, my plugin defining the modeler is just a standard Eclipse plugin, I can use JUnit, SWTbot, Tycho, nothing fancy here is imposed to me by Sirius. Here are a few stats :

The diagram and table editors of EcoreTools 2 are representing less than 2700 lines of code.

Now what ?

EcoreTools has been rebooted based on Sirius which means I can add new features in a fraction of the time I would have needed to just maintain the tooling before.I think the net gain compared to the 1.x stream is already huge but of course the paint is slightly fresh, you might find issues and if you do please report a bug. If you like it, please tell me through twitter, google plus or the Eclipse Forums, this will be appreciated.

You can install EcoreTools using the Eclipse Marketplace, you will also find it in the Modeling Package which is shipped with Luna.