Sirius – The easiest way to get your own modeling tool

I started using Sirius around two years ago when we built an open source editor for IFML (Interaction Flow Modeling Language) with it.  

Sirius is an (Eclipse-based) open Source technology that you can use to easily create a customized modeling workbench. In fact, Sirius’ motto is “the easiest way to get your own modeling tool” and my own experience confirms it. As I was saying then, “I don’t think right now there’s a better alternative inside the Eclipse ecosystem to quickly create graphical modeling editors for your DSL.”. This more recent comparison of tools to build graphical modeling editors seems to confirm this as well, by giving to Sirius and Obeo Designer, its professional packaged version,  the highest marks on a number of criteria.  

Sirius has also been taking good care of its community, even going to the extreme of organizing a conference fully focused on Sirius: SiriusCon where people can attend Sirius tutorials (both beginner & expert levels), listen other companies explaining their Sirius experience and advice or ask Sirius developers to give you a hand on your own projects. All this for free. Are you really going to miss SiriusCon 2016? (November 15th, Paris, France, register now, places are limited and last year they run out of space!).

For all these reasons, I think you will enjoy my talk with Cédric Brun,CTO at Obeo to know more about the past, present and future of Sirius and the SiriusCon. Enjoy!

 

JC: Obeo is the company behind Sirus but it has been building modeling tools for a long time now, maybe you can start by saying some words about  Obeo itself?

CB: Obeo is a French company that we started 10 years ago. We’ve been focusing our activity on model-driven engineering and specially around the Eclipse ecosystem. We started on the code-generation field but have been growing our toolset to cover many other aspects of MDE and increasing also our involvement in the Eclipse community where we have now around 10 projects such as Acceleo (code-generation), Ecore Tools (metamodel definition), EMF Compare (model comparison) or Sirius itself plus other core Eclipse Modeling technologies.

 

All of them are open source projects

Yes, All of them open source projects. The company has now around 60 employees so I’d say we have been quite successful in building a business model around open source. It’s always a difficult balance (to decide how much to open source)  but I think we have found the sweet spot.

We have never raised any capital so we always managed to raise the company by making money from our customers.

 

So, how does Obeo make money ?

We have different sources: maintenance contracts, providing services, offering training and expertise, implementing new features on-demand (sponsored by a large company that needs it and pays for getting it developed) and providing commercial extensions to open source projects.

 

Despite all this intense activity, it looks Sirius is now the main focus Obeo. What motivated you to create Sirius?

It all started from a customer need. Thales came to us to develop the tooling around its Arcadia method for systems design that would require plenty of graphical editors. We already had plenty of experience with GMF at the time and it was obvious to us that building something that would require dozens of diagram editors on top of GMF would be too costly, even for Thales and maintaining them would be a nightmare.

So we started prototyping a technology that would allow us (and any other company) to create graphical modeling editors very quickly. From this, it grew a lot inside Thales to the point that it covered many of their modeling engineering needs, including Capella, a MBSE Open Source workbench which is also being adopted by other industrials.

 

 

Thales was really willing to let us open source  the technology. We first started selling it as a commercial product but then we agreed that going the open source way would be better and would help tons of users that were struggling with GMF.

 

Is Sirius itself built on top of GMF?

Sirius is using the GMF runtime internally. It’s using the API that GMF provides on top of EMF (the core modeling framework infrastructure in Eclipse) and GEF (core graphical editor framework) but not the GMF tooling for the definition of the editors themselves.

Most of the problems we had when building modeling editors for customers was related to this GMF specification part. It generates huge quantity of code, very complex and every time you changed the ecore code (for the abstract syntax of the language) you need to basically start from scratch.

At first, we built Sirus around these pain points. We wanted Sirius to be able to deal with large metamodels and still very fast.

 

What are the other key features of Sirius?

We also focus on provide pre-built features that help the final user to manage complex models, such as layers (as in Photoshop, you can define several layers to hide/show model elements according to a specific viewpoint), filters, dynamic graphical styles, validation rules, tools to move things around easily,…

Sirius has also a very fast turn-around. The model is interpreted not compiled. Therefore, any change on the concrete syntax specification has an immediate effect on the diagram editor. Defining a graphical modeler is a matter of hours, not days.

 

The graphical language specification also supports predicates / queries to control when and how some features should be shown which gives lots of flexibility to the graphical view. So you  could  create partial views on top of the same domain model targeting different user profiles and they are all kept synchronized.   

Still, the graphical editor itself is one part but not the whole experience of the modeling tool. We try to cover the whole experience.

See some examples of languages created with Sirius (taken from the Sirius modeling gallery):

 

 

You mentioned before that Sirius included support for modeling collaboration

Yes. The open source version includes collaboration management in an optimistic way, i.e. assuming that the number of conflicts will be relatively low. With EMF compare, you can visualize the differences between versions of the same model and then take care of the merge process.

In the commercial version, this is taken care of you since the tool will actually use a short-lived fine-grained lock mechanism to make sure no two users modify the same element. Every time you click save the locks are released. This allows users to collaborate as they do in google docs for instance, they don’t even realize about the locks. A central model repository keeps the data and pushes notifications to the clients.

 

Let’s clarify. What’s the name of this commercial version?

On the one hand, we have Sirius a single product available for download from the Eclipse site. Then, we have Obeo Designer which is our own packaging of Sirius. There are two versions of Obeo Designer: the Community edition, a free package which includes Sirius and all the other Eclipse tools you may need when using Sirius already packaged and tested, and the Team edition, a commercial package which includes additional features like the collaborative support we discussed above.

 

We’re now seeing plenty of modeling tools (or better said, drawing tools) moving to a web environment. What’s Sirius position on this?

This is something we’re looking at and that we envision in the mid-term. Right now, we offer SmartEA, a web-based product built with Sirius, to model enterprise architectures versions and perform impact and gap analyses.

A possibility would be to build other “vertical” editors for other domains if we find clients or companies interested in building an editor for a specific field.

 

Obeo tools are heavily depending on Eclipse. How do you mitigate this risk for the company

First of all, we try to be involved in Eclipse itself. For instance, I’m a member of the Architecture Council in Eclipse where we are actively trying to get more people on board to keep the platform evolving as quick as possible. We also try to integrate Sirius with plenty of other technologies which gives more strength to the tool, like the recent Sirius-Xtext integration

Also the last few years have seen the rise of a new dynamic regarding the platform projects with new contributors and a full time employee of the Foundation working on those critical projects. It takes time for all those initiative to get up to speed but results are visible in the latest releases and it’s only the start.

 

What about the dependence with EMF?

It’s true that everything depends on EMF but it’s also true that EMF in itself is small and very stable. We work closely with Ed Merks to fix any bugs we find so we are also quite invested in EMF ourselves.

We also work a lot with CDO that could be seen somehow as an alternative solution or a complement that tries to solve some of the limitations itself.

 

Another important point is how to help people define high-quality modeling languages?

I completely agree this is a very relevant problem. That is the reason why we are investing on the Ecore Tools project to facilitate the definition of modeling languages by providing a very intuitive and powerful Ecore graphical editor.

 

We also share our best practices on how to create a high-quality metamodel (see: http://cedric.brun.io/eclipse/ecore-design-checklist/).

On the graphical concern, I’d like Sirius to be better at providing more context-sensitive default values, i.e. Sirius itself could help you build a better language by offering predefined options that make sense in the context of the language  you’re building, e.g. offering a color for the new element that combines well with the color you used in the latest one (instead of always starting with a black colour option as it happens right now).

I can imagine some rules to be implemented for this, kind of encoding some of the knowledge of a graphic designer. So far we try to teach people about these rules (we even have sessions for this as part of the SiriusCon) but it’s difficult.

 

What can we expect in the future of Sirius?

We are in a continuous evolution always moving to this goal of providing a great user experience for the complete process of building a modeling editor and make sure we streamline as much as possible the whole process.

For instance, we have recently improved a lot the properties view. It turned out that with all the improvements Sirius brings to the specification of the modeling view, the bottleneck now was in the definition of the properties view to be linked to each graphical element. Once we realized this, we attacked the problem since it may not be a core graphical issue but it does impact the building of the graphical modeling tool.

 

A final curiosity. Why did you choose Sirius as a name?

Sirius is a star system and the brightest luminary in the Earth’s night sky, after the moon. This name was in line with the astronomy theme that rules the naming of Eclipse versions (Kepler, Luna, Mars, …). We chose it based on input and votes from both the Thales and Obeo teams. Picking names is never easy, but I would say it turned out very well as we can use “Sirius” in all sort of catchy titles 😉

 

Let’s move now to SiriusCon. There are not many conferences devoted to specific Eclipse products. Why putting the effort in organizing a SiriusCon?

For the community. When we started talking to users and customers we quickly realize that this event could help the community to build itself. SiriusCon focuses on graphical modeling not just Sirius so it can be interesting for people that are not even using Sirius.

We organized the first edition last year and it was a huge success so it was a no-brainer to do it again.

We have a very solid program with several big companies (like EDF or the European Space Agency) talking on how they use modeling in their environment. There are also some deep technical sessions and talks on the integration between textual and graphical editors.

Another aspect is helping users that have any question / problem related to Sirius. They can come with their laptop and show it to us. Typically, what for them it would take hours of work we can fix it in a few minutes. 

There is something for everybody!

 

And as a side benefit, you can get direct input on what users would like to see in future versions of Sirius

Exactly. And this is important because as soon as you open source a tool you risk losing this information. When you’re selling the tool, you know your clients and can contact them easily. With an open source tool, it is much more difficult to reach them and get feedback.

We have even mined GitHub to find examples of projects using Sirius to learn about how they use it, what they have built with it,… Obviously, this is quite incomplete but everything helps. We have found some good interesting use cases for Sirius doing this.

 

Thanks Cédric for your time. Remember, register right now for SiriusCon 2016 on November 15th in Paris (but don’t  worry, conference is in English). They only have 150 seats available and can fill pretty quickly!!!