One of the main benefits of diagrams is that they can make it very easy to quickly grasp the overall structure of a model. As the saying goes “a picture is worth a thousand words”. However this is only true if the layout of the diagram is actually good. Laying out large diagrams manually can be very cumbersome, so Eclipse Sirius has always supported automatic diagram layout (through the “Arrange All” action), but this relies on a generic algorithm which is not adapted to all kinds of diagrams.
Sirius 6.0, which was released last June as part of Eclipse Photon, includes a new experimental feature that has the potential to produce much better results by leveraging the high-quality layout algorithms provided by the ELK project.
The gist of the new feature is that people who create Sirius-based modeling tools can now:
- choose among the many algorithms offered by ELK (including the ones from GraphViz if the library is installed on a user’s system),
- tweak the algorithm’s parameters to best fit their specific diagram,
- and ship the resulting modeler.
The result is transparent to end-users of the modeler, who can continue to use the standard “Arrange All” action, but will now get better results for free.
For example here is how the fixed, legacy algorithm lays out a particular Capella diagram:
It is not very readable, with lots of edges crossing, labels on top of each other, and no discernable structure. Just changing the modeler to use the ELK Layered algorithm and tweaking a few parameters gives this:
This is much more readable! The flow structure of the underlying model becomes obvious, edges are no longer crossing and all labels are visible. There are still some things to improve, notably with the edges routing. These are most probably integration issues with the “glue” code between the two systems and not limitations of the ELK algorithms themselves. We've currently focused on making it really easy for Sirius users to experiment with ELK, but more work is still needed to integrate the two and leverage the full power of ELK.
Read on for more details about this new feature, and instructions on how to test this on your own modelers. As mentioned above, this is still experimental at the moment, but the more testers and feedback we get, the faster we will be able to offer a more complete and stable version!
Automatic Diagram Layout
One important aspect to take into consideration when it comes to graphical modeling is the layout of diagrams. Indeed, why bother making nice boxes with shiny edges to represent information in a Sirius diagram when you cannot lay it out properly?
A bad layout will make your diagram unreadable whereas graphical representations are meant to make it easy to quickly grasp the important concepts and their relations. This is especially important as diagrams are often used for communication.
Let’s have a look at the following Sirius ecore diagram layouted with default Sirius algorithm:
Not so sexy, is it? It is difficult to extract useful information as it stands. You have two choices to make it readable:
- Either you layout the diagram manually node by node, edge by edge until you have a good enough result to understand what you are seeing. But the more items you have on your diagram, the more time you will need to achieve this task. What’s more, it’s not exactly the most interesting thing to do.
- Or you can rely on an automatic layout algorithm that will do the job for you quickly and with efficiency even with a high number of items present in the diagram.
Many layout algorithms exist like the tree-based, layered-based or radial algorithms, and each will be adapted to different kinds of diagrams:
So you want to have as many of these as possible to produce the most readable result. You also want these to be as customizable as they can be. For example, whether the layout should be done from the left to the right or vice versa is something you want to be able to specify.
Prior to version 6.0, Sirius provided only two algorithms: one (the default) for layered diagrams, and one for hierarchical tree-like diagrams. These generic algorithms give acceptable results in a lot of cases, but in some others it could be improved. The only way to improve Sirius capacities in that matter was to provide layouting algorithms yourself, or to develop your own integration of a layouting technology.
But that was before Sirius met ELK (Eclipse Layout Kernel) starting from version 6.0. ELK is a Java framework providing many more standard layout algorithms than Sirius and that can be rather easily connected to diagram editors like Sirius. ELK algorithm implementations are based on academic research from Kiel University in Germany.
Being based on GMF, ELK already integrated with Sirius on a basic level, but needed to be adapted to its peculiarities to work well. For example it is not aware of Sirius-specific constraints which are defined in the modeler definition files like forcing some kinds of ports to only appear on the left side of their parent or that some elements are “pinned” and should not be moved at all.
How to Test it Yourself
The easiest way to test the Sirius/ELK integration yourself is to grab the just released Obeo Designer CE 11.0 which integrates Sirius 6.0.1. Because this new feature is still considered experimental, it is not directly available in Obeo Designer, but can easily be installed from the Sirius 6.0.1 update site at http://download.eclipse.org/sirius/updates/releases/6.0.1/photon
Once the feature is installed, if you open an existing Sirius modeler definition (.odesign file), on each diagram definition you will get access to all the layout algorithms provided by ELK in the New Layout sub-menu:
The ELK project provides reference documentation for all layout algorithms they support, including all the configuration options of each algorithm. Note that ELK can also use the well-known and battle-tested algorithms from GraphViz, but you will need to make sure GraphViz is installed (including on end-user systems) for this to work.
Once you’ve selected the algorithm, the properties view allows you to customize any of the many options it supports:
Thanks to the dynamic nature of Sirius, it is very easy to experiment with different variants. Once you, as the specifier, are satisfied with a particular configuration for each of your types of diagrams, the resulting modeler can be shipped to end-users as usual. The only additional step is to make sure our modeler definition plug-in correctly declares that it depends on the org.eclipse.sirius.diagram.elk plug-in to make sure the runtime support is installed along with your modeler on end-users’ systems. If this is not the case it will not cause an error, but the “Arrange All” action will fall back to the legacy generic algorithm and ignore your ELK-specific configurations.
Then users of your modeler will only have to use the “Arrange All” button to magically see his diagram layouted automatically by the chosen layout algorithm.
The following example is using FDP algorithm and the result is pretty good for the comprehension:
You can see the whole process in action See it in action in this short video:
A benefit of ELK in addition to all layout algorithms it already provides, is that any new implementation of a layout algorithm contributed to the framework will be usable in Sirius only by installing the feature containing it.
The State and Future of ELK Sirius Integration
The ELK integration in Sirius is fresh and experimental. It means that you can encounter some bugs (some we’re already aware of). As already mentioned, we've currently focused on making it really easy for Sirius users to experiment with ELK, but more work is still needed to fully integrate the two and leverage the full power of the ELK algorithms. You may also have some needs or want some features regarding this new functionality that we do not provide with current integration. The more testers and feedback we get, the faster we will be able to offer a stable version, so do not hesitate to test on your own diagrams and to report any issues or enhancement ideas on the forum, in the Sirius bugzilla,or by contacting us directly to sponsor the development of this exciting new feature.
Post-Scriptum: Thanks to the ELK team for their feedback and remarks on early versions of this message.
