UML Designer 7.0

UML Designer 7.0 is out. This new release is based on Eclipse Sirius 4.0 and Eclipse Neon.

It provides plenty of brand new features:

  • Bi-directional link with editor (#523)
    image
  • New dashboard based on the Activity Explorer from Amalgam (#827)
    image
    image
  • Class diagram:
    • represent abstract element in italic (#758)
      image
    • represent static element underlined (#363)
      image
    • view the qualified name of a class in the tooltip (#851)
      image
    • stabilize association class (#856#854#857),
    • support N-ary association (#850#855#853)
      image
    • support qualifiers on association ends (#434)
      image
  • State machine diagram: orthogonal regions re-implemented by using the Sirius compartment feature (#125)
    image
  • Activity diagram: optional body layer (#757#846) and some bug fixes (#865)
  • Sequence diagram: clean & reorder the palette (#858)
  • Use case diagram: handle non human actor (#46)

All closed issues are available on https://github.com/ObeoNetwork/UML-Designer/milestones/7.0.0.

Try it and download it on: http://www.umldesigner.org/download/

Sirius 4.0 Gotta Catch ‘Em All: Fully operational battle station!

Finally, with Sirius 4.0, some newly introduced components are declared fully operational.

Compartments

Sirius 3.1 came with the possibility to create compartments where you can group and stack your model elements. The way your data is represented is better structured and the information is easier to understand. With Sirius 3.0, it was already possible to create compartments, but we had introduced it as an “experimental” feature since some behaviors were not supported yet. Today compartments are fully operational.

I18N

We completed our work on the internationalization. Now the runtime strings are externalized and a dedicated mechanism exists for the odesign files.
 To catch all the new features coming with Sirius 4.0 have a look to 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: Super powered API

You already discovered with the previous posts that Sirius is more and more powerful.
Sirius 4.0 offers more and more possibilities to our advanced users thanks to super powered APIs.

API to control the tab-bar

The top area of all Sirius diagram editors is filled with the tab-bar, which provides access to many operations on diagrams and their elements.
From now on, Sirius provides an API to get complete control of how the tab-bar is filled: which elements to put (Sirius standard ones or custom ones) and in which order.

Better integration with EMF Edit


For the specifier, Sirius 4.0 comes with a better integration with EMF Edit. While it is only the beginning, Sirius is now contributing the EditingDomainServices service class, which can be referenced from any VSM. This class provides a large set of methods giving access to many useful features of the EMF Edit framework. It provides general editing domain related services and contributes all types of Item Providers, in a way that is directly accessible as service invocations from interpreted expressions. It also offers item property related services. A series of service methods can be used to invoke the standard EMF Commands available from and ItemProviderAdapter’s various createXXXCommand() methods. Note that contrary to the createXXXCommand() methods which simply returns a Command instance, the service methods exposed in this class will directly execute the command on the editing domains CommandStack.

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: 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.
post-execution_options.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: 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

starmie_by_weaponix-d88e6i3.png

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.

svg-zoom.gif

Contribute SVG shapes

mew_by_weaponix-d8bzqze.png

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

magneton_by_weaponix-d800elu.png

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
Pikachu
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!
properties_widgets.png
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.name 
[self.eContents()->select(name.startsWith('A'))/] is invalid and becomes self.eContents()->select(i | i.name.startsWith('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