Sirius 4.0 Gotta Catch ‘Em All: Stability and Performance

Release after release, feature after feature, the goal of the Sirius team is to provide a stable and efficient framework to our users. So as usual we worked with this goal in mind for the Sirius 4.0 release.

Edges labels stability

We worked on several improvements to the diagram editor to offer a better experience to the end user. For example, we improved the edge label stability. With Sirius 4.0 when you move an edge the label stays close to the edge.

Improve performance on session unload

The Sirius team works as well on improving performance. A significant improvement has been brought in the 4.0 release on session unload. Now Sirius will no longer spend time calling unload on the resources that will no longer be used. Thanks to this, the unload operation is now almost immediate. Note, that it is possible to customize this behavior if needed by specific resources implementations or usage contexts.

To catch all the new features coming with Sirius 4.0 have a look at the slides of our talk at EclipseCon France! Another chance for you to join the Sirius community, SiriusCon will occur in Paris the 15th November 2016. Be sure to save the date!

Sirius 4.0 Gotta Catch ‘Em All: Improve user experience

To continue with the Sirius 4.0 new features serie, today we will show how we improved the user experience.

Bi-directional link with editor

When exploring a complex model, users frequently need to switch from the tree representation (provided by the Model Explorer) to the current diagram and vice-versa. Before Sirius 3.1, the “link with editor” option was uni-directional: selecting a model element in the Model Browser was selecting the same element in the diagram, but not the opposite. Now, this option is bi-directional: selecting a diagram element automatically selects the corresponding model element in the Model browser.

Selection after tool execution

For users who need to rapidly create new models and efficient representations, reducing the number of clicks is very important to improve their productivity. With Sirius 3.1, we have added the possibility to specify which elements to automatically select after a tool execution. For each kind of tool (creation, edition, navigation, etc), we have added two new options “Element To Select” and “Inverse Selection Order” that can be used to specify which model elements to select after the execution of the tool.
To catch all the new features coming with Sirius 4.0 have a look at the slides of our talk at EclipseCon France! Another chance for you to join the Sirius community, SiriusCon will occur in Paris the 15th November 2016. Be sure to save the date!

Sirius 4.0 Gotta Catch ‘Em All: SVenGers: Infinity war

We continue our exploration of the Eclipse Sirius 4.0 new features. Do you remember our previous post about the Scalable Girl? We further improved the SVG rendering to make her even more powerful.

Better SVG rendering


This is a significant improvement. With Sirius 4.0, on a diagram when the user uses the zoom, the rendering of a SVG file has a much higher quality.


Contribute SVG shapes


Sirius provides a basic image style for node mappings, which offers a selection of five different shapes. The new bundledImageShape extension point allows specifiers to provide their own shapes defined in a SVG file like a stencil pack.

stencilpack.gifemotes - Gestionnaire de fichiers_101.png

To catch all the new features coming with Sirius 4.0 have a look at the slides of our talk at EclipseCon France! Another chance for you to join the Sirius community, SiriusCon will occur in Paris the 15th November 2016. Be sure to save the date!

Sirius 4.0 Gotta Catch ‘Em All: Border song

If you enjoyed our previous post on Eclipse Sirius 4.0 new features, read on to hear the Sirius border song.

Customizable border style

The border style of your diagram elements can have a semantic meaning defined by your graphical notation: you may want to express a different information whether the border shape is dashed or plain. Here and now, with Sirius 3.1, it is possible to define such styles for both the nodes and the containers (like it was already possible for edges).

Preferred side for border nodes


By default, border nodes can be located on any side of its parent. It is now possible to restrict border nodes to specific sides only. Thus the end user will not have the possibility to create or to move a border node on a forbidden side. Authorized sides can be specified in the advanced tab of the border node style.

To catch all the new features coming with Sirius 4.0 have a look at the slides of our talk at EclipseCon France! Another chance for you to join the Sirius community, SiriusCon will occur in Paris the 15th November 2016. Be sure to save the date!

Sirius 4.0 Gotta Catch ‘Em All : Be prepared for the future

Properties View
My previous post illustrates The Power of One framework to define graphical designers and property views: Eclipse Sirius 4.0. It shows how to get property views for your designer as fast as a thunderbolt!
During the last year, the Sirius team worked on two versions of Sirius the 3.1 and the 4.0. In the following days I will detail all the new features coming in Sirius, since the release of Eclipse Mars, that are included in Eclipse Neon.

The Sirius project is very active with 10 committers working full time during this past year. We did around 900 commits and fixed 84 bugs. Since the Mars release, more than 1100 posts were made in the Sirius forum: there is a vibrant community around Sirius.

In this new release we introduce a significant feature with the properties view description but we are also preparing the future with a small change.

 Metamodel warning

Starting with Sirius 4.0, a warning appears if the specifier does not define explicitly its metamodel on a representation description. This is a first step and in the future, specifying the metamodel will become mandatory which will allow us to give more precise feedback to specifiers resulting in more robust modelers.

To catch all the new features coming with Sirius 4.0 come to our talk at EclipseCon France! Another chance for you to join the Sirius community, SiriusCon will occur in Paris the 15th November 2016. Be sure to save the date!

Let me Sirius that for you: Properties view

It’s been a while since my last Eclipse Sirius post but this year we Get Busy at Obeo with the preparation of the new Sirius release. It is a really important release for me as I am contributing For the very first time as an Eclipse commiter :)

I am really proud to be part of the Eclipse community and excited to meet her again at EclipseCon France.  I hope you’ll join us to attend our talk Sirius 4.0: Let me Sirius that for you!

You already know that Sirius allows you to create So powerful graphical designers. With minimal efforts you can create a great modeler with a ready-to-use graphical editor providing a model explorer, a palette, a toolbar and contextual menus dedicated to your own DSL.

But when you create a dedicated designer after specifying the viewpoints, the mappings and the tools, the next step is most of the time to contribute dedicated properties views in order to ease data edition.

Thanks to the Eclipse modeling ecosystem, there are already several solutions to contribute form-based views to Eclipse applications: EEF, EMF Forms, EMF Parsley.

All these solutions can work with Sirius based modelers through an extension point and it will remain so. But what we have seen is that for many people the gap in between the “Sirius way” and the “Other frameworks” way is large and they are often groping for the constructions they are used to in Sirius. At that point you feel like, This is the way you left me… Very transversal things like colors or editing behavior are defined in a Viewpoint Specification Model and the users needs to refer to those things for their property views. A property views definition which is perceived as more complex than the graphical modeler defeats the whole approach.

At the end of last year, we decided to do something for you to improve the situation. You guys Get lucky!

I am very pleased to announce that from here on out Sirius provides an integrated way to define your properties views in the same way as you are used to define the other parts of your designer: no need for code, it is dynamic and query based.

With Sirius 4.0, you are able to specify exactly how your properties view should be represented. If you already know Sirius, it is fairly Easy.

As you are used to do with other kind of representation in Sirius, you can specify mappings between graphical properties view elements and semantic elements.

Once you installed the right plugins, in the VSM (the configuration file which defines your modelers in Sirius) you can create a new kind of extension under which you can specify Pages, Groups and Widgets. A page represents a tab of your properties view and a group represents a section. Several widgets are available to represent you semantic elements: text, text area, checkbox, select… and it is very easy to add your own if needed.

For each kind of widgets, you can define specific styles based on the semantic model. Exactly like it is already possible for diagrams, conditional styles can be applied based on evolving values of your semantic model.

It is also possible for each widget to define a specific behavior. You can specify the behaviour associated to: the text widget edition, the onclick event of an hyperlink/a table, a pushed button, etc. For example, to define the behavior of the text when a change occurs, you simply specify the behavior associated to the edition inside the Begin element using all the usual model operations.

One of the main advantage of Sirius is that the graphical representations are independent from the metamodel’s structure. The same principle was kept for developping the properties views feature. This means that you can choose not to respect the containment hierarchy of your model when you display it graphically. This is possible because Sirius is based on queries.

For example, we can represent the same attribute with different widgets. Below, you can see that the Location can be represented thanks to a Select or a Radio widget.

We just specify two different widgets in the properties view description, one for the Select :

And one for the Radio:

In each case, the Candidate Expression and Value Expression are used to query the model and get the expected semantic elements.

One last thing, with the Sirius 4.0 version, when you create a modeler, by default you can get for free beautiful default properties views without defining anything special in your VSM.

How does it work? It’s a kind of magic…

We do the work for you by providing default rules based on the type of the elements defined in your metamodel. For example, if you have defined a string attribute in your metamodel, it will be automatically represented with a text widget, a boolean will be represented  with a checkbox, etc.

If the default properties view does not fit what you need, no problem specify your own properties view as explained above.

There are plenty of other awesome features, such as context based properties views, dynamic mappings, validation, quick-fixes and more. If you want to learn more, join us at EclipseCon France:

What you think is Give it to me baby! This feature will be delivered as experimental with Sirius 4.0 which comes with Neon, and be available officially in Sirius 4.1 expected after Neon.1. Even if it is tagged as experimental, it is ready to use. And do not be afraid, try it, we will take care of the migration for you as we usually do for other parts of Sirius, it will be completely transparent for you to upgrade from 4.0 to 4.1 when it becomes available.

Come on and try it on your own!

Sirius 3.0 “Harder, Better, Faster, Stronger”

Today is a great day: with the announcement of Eclipse Mars, many great projects are released, and Sirius 3.0 is part of this release train.

When I have a look at the status of the Sirius project today, one soundtrack immediately comes to mind: Harder, Better, Faster, Stronger

Work on it harder

One first fact, looking at the project’s statistics, is that the Sirius team worked hard on this release to deliver some new cool features and improve the existing ones:

Version Date Total Closed Feature Requests
1.0.0(Luna) June 14 100 2
1.0.1 Aug 14 20 -
2.0.0 Oct 14 113 27
2.0.1 Nov 14 2 -
2.0.2 Dec 14 15 -
2.0.3 Jan 15 16 -
2.0.4 Feb 15 8 -
2.0.5 Apr 15 8 -
3.0.0(Mars) Jun 15 213 35
426 64

This release is the first one on which the team worked at full speed, so for the future you can expect the same amount of work done.

Make it better

Their goal was to provide a better tooling for the end users by improving the diagram user experience. This work started with Sirius 2.0 and some of the following features are there since then.

Resizing a container

Positioning elements

Snap To Shape enabled by default for new diagrams
Snap To Grid now used when an element is created
Resize no longer change ports or children’s location
Actions to distribute shapes
Action to reset the diagram origin

Edges layouting

Beautiful editor

The editor was also improved to provide:

  • Anchor on borders: Now the edges are linked closely to the images, you just need to define images with an transparent background.

  • Underlined and strike through style for labels

  • Compartments: There are two new values available for a container mapping Vertical Stack and Horizontal Stack. This means that the defined container will show its children as a vertical/horizontal stack of compartments. Thanks to this new feature, you are able to define a dynamic number of compartments.

Compartments are just a specific setting of a full blown container mapping making it easy to create any artificial level of compartments independently from the metamodel structure.

Have a look at the Sirius compartments documentation for more details.

Do it faster

The goal was to get a runtime which react well with 1 million elements. Why one million? Because it is a beautiful number… but also because we noted that the modeling projects are fastly growing to 200K elements and 500K in case of in-depth analysis. Usually when you are over 500K, it means it’s time to re-think the process as you will likely need to decouple models with a clear and defined life-cycle. That is why we aim Sirius to work with 1 millions, then it will be really smoothly with the more usual 500K use case.

Sirius performances are in constant improvements, and this version comes with significant enhancements on heap consumption and time execution.

Time (sec) Heap (Mb) Time Variation Heap Variation
Open Huge Project 80 276 -31,00% -20,00%
Open Big Class Diagram 11 24 -54,00% +20,00%
Refresh Big Class Diagram 0,731 0 -18,00% 0,00%
Save After Diagram Change 26 0 -23,00% 0,00%
Close Diagram 0,1 -6 0,00% 0,00%
Close Project 55 294 0,00% 0,00%

On big operations, the model footprint is reduced by 20%. To do so, major work was done on:

  • using MinimalEObject
  • Transforming Colors from full-blown EObject into Immutable DataType
  • Detecting and fixing leaks
  • Reducing the usage of adapters.

Then the save strategy was reviewed as well as the diagram refresh and the image cache.

Another big task was to reduce the latency. First, on the UI runtime:

  • model element selection dialogs must be used for big models.
  • the right-click in the explorer was optimized.
  • and the property views made with EEF are better integrated.

And then to reduce the latency on tables, SWT refreshes are now done in batch and the team also improved the table model refresh.

Performance is also your matter! It really depends on your .odesign specification. You should focus on queries which will have a complexity depending on the size of the model: measure, improve and repeat! Think about using the Sirius embedded profiler:

Make us stronger

Definition tooling

The Sirius team also worked to polish the specifier editor. They improved many different small things which will really enhance the specifier work as it will guarantee a better odesign validation and an efficient navigation.

  • Workspace class loading is BACK: With Sirius 3 you can define Java services and then try them directly in your current development environment, you do not need anymore to launch another runtime just to test your services!
  • Image path validation and selection wizard: Now, there is a selection wizard to choose an image and then validation exists on image path. You will never get a not found image.

  • Quick Outline: An awesome improvement: it allows to quickly find any element in a odesign! Just call Ctrl+O and a wizard shows up to help you searching through the viewpoint specification.

  • Prioritized sub menus: Another great thing, the menus have been reordered and now the most used elements are available at the top.

Query languages

If you are used to work with Sirius, you already know that writing queries can turn to a severe headache due to the lack of detailed type information.

Actually, there are in Sirius 5 different interpreters to write your queries:

  • Feature: feature:
  • Service: service:
  • Var: var:
  • MTL: [/]
  • and the legacy one: <%%>

The .odesign specification is as flexible as possible, tools can be reused among mappings, mappings can be reused by other mappings, but that means one variable definition can actually have several types depending on the .odesign structure. If we have a look at the following query: What is the type of var:source?

Regarding our example, source can be a Man or a Woman but it could be Woman or Package. Then the source variable can be of multiple types and those types may have no common ancestor other than EObject.

Type analysis within the action language requires a stronger type information from interpreters. It is implemented in feature:, var:. We made some improvements in [/] and there is simply no support in legacy <%%> and ocl:. What we want is a good reference support.

The Acceleo Query Language also known as AQL comes to our rescue. The implementation of AQL is specifically tailored for the Sirius use case. We have many variables for a given expression and null values are common. The usage is really interactive and so the context is constantly changing. I can hear you “Hoooo no, not yet another language…”. Don’t be afraid! You know OCL ? Then you know AQL.

The most important things to know is that:

  • You will find the classic operations like filter, collect,
  • And some convenient ones as: eInverse(), eResource()
  • There is no implicit variable:
[name/] is invalid becomes 
[self.eContents()->select(name.startsWith('A'))/] is invalid and becomes self.eContents()->select(i |'A') 
self.referenceWithNoValue.someOtherAttribute has no evaluation error, returns "Nothing" 

AQL is not strictly compatible with MTL but a subset of MTL works for both.

We did some benchmarks with the different queries engines available in Sirius:

There is no good reason not to use it considering the overhead vs the flexibility and strong validation. In Sirius 3.0, it is delivered as an experimental feature but it will be available officially for the next 3.1 release.

So consider using it from now on if you are still using Acceleo 2 expressions (<%%>). Otherwise, if you are using MTL ([/]), you can prepare your queries to make the migration easier.

To get more details about what is arriving in Sirius 3.0, have a look at the release notes and to the slides or the video of Cédric Brun EclipseCon France talk.

Even if Sirius 3.0 is major version, don’t be afraid! The models are automatically migrated by Sirius, the API changes are well documented in the release notes and some projects such as EcoreTools or UML Designer could upgrade just by changing the version range in the plugin, no impact on the code.

The 3.1 version is planned for November and the next topics of work will be: more flexibility for diagram UX, compartments feature complete, bullet-proof AQL and again more performance and scalability improvements… and your priority is our priority for the future. So don’t be shy, report what you need and want on the bugzilla and remember you can sponsor us to get it done quickly!

Let’s have Daft Punk conclude this post:

More than ever
Hour after
Our work is
Never over

Fix it Sirius!

This week the Sirius blog post series presents «How to integrate validation rules on a diagram ?».

EMF provides a powerful validation system which helps you detect errors in your model. But sometimes you would like to add more rules not already implemented in your metamodel. Sirius is there again!

Imagine that we would like to represent the well known Arcade game from the Wreck it Ralph! movie.

We define a metamodel to represent the Building present in the game.

We also define an isFixed attribute that indicates whether the building is broken or not and so if it needs to be fixed.

Semantic validation

Then we create a new Sirius specification project and we define a viewpoint with a new diagram named SemanticValidation. A Building mapping is added and provides two different styles according to whether the building is broken or not.

We create a model example defining a Game element and a Building, we activate our new viewpoint and create a new SemanticValidation diagram.

We create also a Wreck it tool which can be applied on a Building and set the isFixed attribute to false. After applying the tool on the building the diagram looks as below:

Next a rule is defined to detect when the isFixed attribute is set to false. We improve our diagram specification by adding a new Validation rule. To do so on the diagram specification element, select New Validation > Validation and create a Semantic Validation Rule.

Then, we set :

  • the Level: severity of issues reported when the validation rule is broken. It could be Information, Warning or Error.
  • the target class: type of semantic element checked by the rule.
  • the Message: message shown to the user in the Problems view when the validation failed.

An Audit element must be also defined to provide the expression that must be checked to validate the rule. When the expression evaluates to true, no validation issues are reported. Otherwise, issues will be listed in the Problems view. It is possible to define several audits for one rule, in this case the rule is considered as violated if at least one audit applies.

The user can call the validation thanks to a right click on the diagram background and by selecting the Validate diagram menu:

If we activate the validation on our wrecked building, we get one error:

On the diagram, the validation issue is also visible thanks to an error decorator added on the figure:

View validation

Another possibility is to define validation rules based on graphical elements instead of the semantic ones.
We create another representation named ViewValidation which provides a view validation rule:

In this case, the validation rule will be applied on a mapping.

This time an error will be thrown when the border color RGB red component of the building will be different than 239.
We define also a quick fix which also modified the semantic model to fix the building again.

Quick fix

Eclipse users love their IDE because it is very often capable of proposing a Quick fix functionality for typical problems. Sirius allows to easily implement such a Quick fix feature, let’s call it “Felix quick fix it”:

On the validation rule element, we define the Fix.

We set the fix message and define how the fix will update the model. Finally if we launch the quick fix on our example, it just changes the value of the isFixed attribute to true.

Thanks to Sirius and Felix our building is all fixed.

You can wreck it again… thanks Ralph…

The sample code from this example is available on github:

The SVenGers : Age of Sirius

Today we swing the Sirius posts series onto another topic : using SVG images in your designers.

Maybe you do not know yet but we will have to fight Pixels monsters this summer :

Our mission: save the world.
Our superpowered team: the SVenGers.


The story begins as any superhero blockbuster movie : a bad experiment generates a monster.
So our first step in this post is to introduce a pixel monster in the world. We define as usual a metamodel. This time, it represents our SVenGers team :

Then we provide a Sirius specification project with a new kind of representation named PixelatedDiagram and a ScalableGirl mapping.

As we already saw in a previous post we use the Workspace Image style to modelize our team member.

We create a new instance of our metamodel which defines the team with the SVenGers superheroes:

And finally, a new diagram is created :

Up to there everything is fine.

But in our mapping definition we set that the node is resizable:

Consequently, the diagram can be updated

And we are able to make the Scalable girl bigger:

And here is the point where the pixels attack.
Thankfully, Sirius came to our rescue.


To fix this problem, Sirius supports SVG images. A Scalable girl SVG image is created thanks to an appropriate vector graphics editor like Inkscape.

As mentioned in the Sirius best practices, we need to clean the SVG file. On the <svg> container node, we must add the following attributes: viewBox="0 0 width height" and preserveAspectRatio="none".

Then when you define the mapping workspace image style instead of giving a bitmap image, you need to provide an SVG file.

To continue with our example, we create a new representation named SVGDiagram and this time, we select an SVG image for the Workspace Image style and we create two other mappings to represent the other SVenGers team members:

After creating a new SVGDiagram on our example model, we resize the Scalable girl again:

This time, she looks perfect after the resize, there is no more pixel artifact.

Caution, the current Sirius 2.0 version has a reported bug (442268) about SVG images. When you use the zoom, the SVG images quality gets as bad as if it was bitmap images. This is a known issue that should be fixed for the next 3.1 version. Do not hesitate when you find a bug to report it on the Sirius bugzilla!

By using SVG images, you are able to create designers which still look great after resize. So join us and use SVGs to fight against pixels!


Unravelling the container within the container within the container…

Last time in the Sirius blog post series, you learned how to create an artificial container, today we will see how to create an infinite hierarchy of containers.

As an example we will represent the different dream levels featured in Inception :

We need to model dream levels and that levels can refer to other sub levels :

We develop a first Flat representation to show all the levels at the same stage :

A Flat diagram is created and a Level container is defined to represent all the levels defined in the model :

Thanks to this representation we see all the different dreams but it is not possible to understand how they are interlinked.

Next step we create a SubLevel diagram to represent the first three dream levels :

A first container Level represents the reality, then we represent the second dream level thanks to the SubLevel container and finally the third level with another container named SubSubLevel.

For each container we retrieve the child level thanks to the levels feature defined in the metamodel. For each level container we define a new style.

The following SubLevel diagram results:

Defining for each level a new mapping and a new style is really painful and it determines the number of levels you can create. Fortunately, Sirius can help us to define an infinite hierarchy of elements.

Reuse mappings

We create a new Inception diagram as we did before, we define again a Level container to represent the initial level and then a SubLevel mapping models the second level.

At this point we are able to represent only the first two levels. To get an infinite hierarchy of levels, we need to set in the Import tab, the Reused Container Mappings field and select the SubLevel mapping. This means that the SubLevel mapping could define as descendant other SubLevel mappings. Here we reuse a mapping defined elsewhere in the VSM using the Reused Mappings property in the Import category. The effect at runtime is the same as if you had created an equivalent mapping inside the parent mapping.

We create a new Inception diagram and…It’s working like a dream! We see all the levels hierarchy.

Pay attention, as this method uses recursion, if you set the semantic candidates expression to eAllContents a stack overflow exception will occur.

Last point, using this method we need to define the style for the first level and then we set the same style values to the sublevel mapping in order that all the levels appears with the same look.

With Sirius you can define the level style just once.

Import mappings

A last Inception2 diagram is defined, with a Level2 mapping which is an exact copy of the previous Level mapping. We define also a style for this mapping.
Then instead of creating a New Diagram Element as we did in the previous diagram definition, this time we create a New Import Element.

The Semantic Candidates Expression is set to feature:levels

And in the Import tab, we set the Imported Mapping to Level2. This means that this new mapping reuses the style defined by the imported mapping.

The mapping imports are used to specialize an already defined mapping. In our example we override the Semantic Candidates Expression.
To get an infinite hierarchy of levels, we set again the Reused Container Mapping field to SubLevel2.

Then in this diagram definition the level style is defined just once:

If we create an Inception2 diagram we obtain exactly the same result as before :

With Sirius, make your dreaming designer come true!

The sample code from this example is available on github: