“I am your container”, Darth Sirius

Continuing the Sirius blog posts series, today we will see a small tip: how to create artificial containers in your diagram?

One of the main advantage of Sirius is that the graphical representations are independent from the metamodel’s structure. This means that you can choose to not respect the containment hierarchy of your model when you display it graphically. This is possible thanks to Sirius being based on queries.

In the following example, we define a metamodel of a family:

To begin with, we define a Flat diagram, which displays all the members of the family at the same level:

In the Person mapping, we use the Semantic Candidates Expression to provide which semantic elements must be represented. These expressions returning model elements are called queries. To write these queries, there are different languages provided by default in Sirius: specialized interpreters (var, feature, service), Acceleo, raw OCL or Java. Here, we use the feature interpreter to get for a family all the persons referenced by the members reference. You can easily identify interpreted expressions by their yellow background in the Properties tab of an element.

We create a first diagram which represents the flattened Skywalker family:

The next step is to add a level to model the Family as a container. We create a new Family diagram which contains a Family container mapping and a Person mapping as sub nodes:

The Family diagram is created and all the members are represented inside the Skywalker container.

Here we represent graphically the containment reference members. But what to do if we want to create an artificial container which does not exist in the metamodel as a containment reference?

Let’s see! Now imagine that we want to add a level to represent The Force and if the person is related to the dark side or the light side. To do this we create a new ForceSide diagram:

We add a new container to represent the DarkSide of the force :

The dark side must be represented once for each family, the semantic candidate returns var:self which means the current family. As it should contain persons, it is defined as a FreeForm container.

We need to represent, in the Dark Side container, the persons that are from the dark side of the force. So we define a new sub node Person with the Semantic expression set to: [self.members->select(p|p.oclAsType(Person).dark)/]
This query returns all the members of a family and selects only the Person which has the attribute dark set to true.

Then we reuse the Person mapping to represent the person in its force side container.

Finally, we do the same for the light side of the force and we create a LightSide container and the Person mapping to represent members of the family in this new container who are influenced by the light side: [not self.members->select(p|p.oclAsType(Person).dark)/]
A new ForceSide diagram is created in the Skywalker family and we discover that only Darth Vader is from the dark side of the force and that his children are driven by the light side of the force.

Thanks to the queries in Sirius, it is easy to create artificial containers which are not related to containment referencers in the metamodel.

“May the Sirius Force be with you” ;)

The sample code from this example is available on github: https://github.com/mbats/sirius-blog/tree/master/artificial-container

 

Refine diagrams with interpolated colors

This article is part 4 of a series covering cool features of Sirius and tips to create advanced modelers. See http://melb.enix.org/category/sirius/ for the complete series.

Today we will present how diagrams can be refined to display information using interpolated colors.

Diagrams with meaningful colors

In your Viewpoint Specification Model (VSM), the specifier is not limited to use the provided colors but can define a palette with custom colors. A color can be defined using a RGB code (Red/Green/Blue).

However, using this new color in a mapping will paint every mapping candidates to this color. As our goal is giving colors a meaning, it needs to be defined by an expression. Sirius provides two solutions: Computed Colors and Interpolated Colors.

Note that RGB codes are defined with three integer values between 0 and 255. If the value is over 255, Sirius will use it as a 255 value.

Diagrams with computed colors

Computed colors are alike RGB Colors but instead of choosing an int value for the Red/Green/Blue fields, an expression will be given.

On this sample the color is computed depending on the depth of the package to represent. As this information is far from a RGB value transposition, the expressions are unfortunately not really natural to write. The Interpolated Colors will offer a more natural conversion.

Diagrams with interpolated colors

An Interpolated Color is defined by an expression and several Color Steps. The expression should return an integer value. Here is an example where the expression calculate the depth of the current element using the ancestors() service.

A Color Step is the association of a color and an integer value. Note that the color selection is not limited by the provided color, but can also be a custom color. In this sample, the selected colors are RGB Colors.

Depending on the return value of the expression, a color will be created between the defined Color Steps. As close the return value is of a Color Step, as close the result color will be to this Color Step.

On the previous example, the interpolated was used in order to display EPackage element with a graduation of color depending on the depth because both steps where different tint of a similar color. Of course, the Color Steps can be of different colors and the number of steps is not limited.
On the next example, we want to present the EPackage again but this time the yellow color graduation will depend on the number of contained EClasses. Moreover, we decide that for future refactoring/cleaning purpose, the empty EPackage should be white. Furthermore, the recommended EPackage size is between one and eight EClasses and should be displayed yellow with a tint darker the more contained EClasses there are. Twelve or more EClasses is seen as too many and should be displayed as red. To represent this as an Interpolated Color we have:

  • An expression computing the contained Eclasses number: [eContents()->filter(EClass)->size()/];
  • A first color step defined as white for value 0;
  • A second color step defined as light yellow for value 1;
  • A third color step defined as dark yellow for value 8;
  • A fourth color step defined as red for value 12.

On this sample:

  • p1121 and p1123 are empty and displayed as white;
  • p112 has 1 EClass and is displayed as light yellow;
  • p1 has 3 EClasses and is displayed as a slightly darker yellow;
  • p111 has 8 EClasses and is displayed as dark yellow;
  • p1122 has 10 EClasses and is displayed some kind of orange/brown as a result of beeing a mix of dark yellow and red;
  • p12 has 16 EClasses and is displayed as red.

Interpolated colors are an easy way to display meaningful information and an alternative from text display. Furthermore it can produce beautiful diagrams using nice colors that can be created using simple tools like www.colourlovers.com or colourco.de.

The sample code from this example is available on github: https://github.com/mbats/sirius-blog/tree/master/interpolated-colors

Keyboard shortcuts

Usually when you are using a graphical modeler, you do most of the actions with the mouse. Sirius based modelers have several built-in shortcut keys that you can use to save time in your day to day workflow. Shortcut keys are commonly accessed by using the key, key, or key in conjunction with other keys.

  1. Keyboards shortcuts
    1. Common shortcuts
    2. Diagram shortcuts
      1. Navigate
      2. Select
      3. Edit
      4. Diagram editor
      5. Palette
    3. Table & Tree shortcuts

Common shortcuts

Some shortcuts are available for all the representations (diagram, table, tree…).

Action Shortcut Description
Go to open editors + To get a direct access to an editor, just press Ctrl + E, and either use the arrow buttons, or type the name of the representation you are editing.
Navigate between visited representations + or + To cycle between visited representations use Alt + Arrows. On Mac : + +
Select All +
Direct Edit
Open Help +
Undo + On Mac: +
Redo + On Linux : + + , On Mac: + +
Save +
Save all + +

Diagram shortcuts

Shortcut keys help providing an easier and usually quicker method of navigation.

Action Shortcut Description
Cycle between shapes on the diagram from left to right
Cycle between shapes on the diagram from right to left +
Navigate between shapes on the diagram +
Navigate into a container +
Navigate out of a container +
Navigate clockwise among the existing edges
Navigate counter-clockwise among the existing edges
Show quick outline + On Mac : +

Select

Below is a list of the shortcut keys that allow to select elements on the diagrams.

Action Shortcut Description
Select in sequence + Hold down Shift, use navigation keys to select additional components.
Select multiple + + Hold down Ctrl, use navigation keys to navigate to additional components, press Space to select additional components.
Deselect + Deselect the selected shape/edge by showing the shape/edge in an outline.
Select diagram Select the diagram and so deselect all other previous selections.

Edit

It is also possible to use shortcuts to edit a diagram.

Action Shortcut Description
Refresh Force an update of the diagram according to the latest version of the semantic model.
Copy semantic element + On Mac : +
Paste semantic element + On Mac : +
Copy layout + + + See Sirius copy/paste layout documentation.
Paste layout + + + See Sirius copy/paste layout documentation.
Hide element + See Sirius hide elements documentation.
Hide label + See Sirius hide labels documentation. On Mac : +
Show label + + On Mac : + +
Move shape
Cycle on element handles Cycle on Position Handle / 8 Side and Corner Size Handles / Position Handle. Clockwise rotation.
Cycle through edge points Cycle through the endpoints, bendpoints, and midpoints of a connection. Clockwise rotation.
Manage edge + + Remove all the bend-points to retrieve an original straight edge. See Sirius manage edge documentation. On Mac : + +
Move a component + Cycle once to the Move handle using the period key (.), use navigation keys to move, press Enter to accept new location or press Escape to cancel the move.
Constrained move + This action constrained the move by snaping the shape to the grid.
Move without snap + This action allows to ignore the snap while dragging a shape. On Mac : +
Resize a component + Resize Cycle to desired resize handle using the period key, use navigation keys to resize, press Enter to accept new size or press Escape to cancel the resize.
Centered resize + Expands the shape on both opposite sides. See Sirius resize elements documentation. On Mac : +
Resize that keeps the ratio + See Sirius resize elements documentation.
Resize without snap + Temporarily disables the snap during the resize if it is activated. See Sirius resize elements documentation. On Mac : +
Resize container keeping children relative + When the shape is resized using the left and/or top border, the children (contained nodes for container and border nodes for all shapes) are moved with the border. See Sirius resize elements documentation.
Reset diagram + The diagram can have a negative origin or can be shifted toward the bottom-right with a blank zone at the top-left. This action aims to move all diagram elements to retrieve its origin while keeping the element layout. See Sirius reset diagram documentation. On Mac : +

Diagram editor

The following shortcuts allow to zoom, scroll or invoke the context menu from the diagram.

Action Shortcut Description
Zoom in +
Zoom out +
Pan when zoomed in + Hold down spacebar and drag the mouse
Scroll in diagram + +
Invokes the context menu for the shape +

Palette

Keyboard shortcuts save you time by letting you explore the palette quickly.

Action Shortcut
Collapse or expand the selected group or
Select tool or
Stack popup list appears +
Navigate between group & tools or

Table & Tree shortcuts

Some specific key shortcuts are also available on tables and trees.

Action Shortcut
Expand direct children
Collapse or
Expand all children

Use keyboard shortcuts and increase your productivity!

This post is available on github : https://github.com/mbats/sirius-blog/tree/master/keyboard

 

 

Customize diagrams with images

Continuing from the example of our previous blog post on House of Cards, we’ll see today how one can customize the elements of diagrams by using pictures.

Per-diagram instance customization

In a Sirius based editor, the style of each diagram element can be customized. This customization can be applied from:

  • the tool bar:

  • the Appearance tab of the property view:

  • the Diagram menu:

  • the contextual menu Format:

The elements you can customize are:

  • container: background color, background style, border size, foreground color, label alignment, label size, label format and workspace image.
  • node: border size, color, label alignment, format, position, size and workspace image.
  • edge: the folding style, the color, the label alignment, format, position and size, the line and routing style, the size and the target and source arrow.

If we set a workspace image on the Influence diagram resulting from the tree layout blog post, we are able to see Frank Underwood’s face instead of a simple white square.

These customizations can be reset using:

  • the Reset style customization button available in the Appearance tab of the property view :

  • in the diagram editor tool bar :

Thanks to this feature each user can customize existing diagrams in any Sirius based modeler. The problem with this solution is that if you create another diagram, the default style will be applied, and we would no longer see Frank’s beautiful face. This method is only useful to customize a specific instance of a diagram.

Using workspace image style

If instead of having customization specific to a given instance, we would like all diagrams of a certain type, what we need to do is to provide the image during the diagram specification phase.

In order to get the image on every new diagram, we need to provide it at the diagram specification phase. To do so, after reopening the houseofcards.odesign, we need to update the Influence diagram description to use a workspace image in a conditional style to represent Frank.

From now on, everytime an Influence diagram is created, Frank’s and Linda’s faces will automatically be associated to the relevant diagram elements.

What is problematic with this solution is that we need to create a conditional style for each character. As there are around 50 different characters in the House of Cards series, it is not a very practical solution.

Specify style custom images

Fortunately, Sirius provides another way to achieve that. We want to provide all the images in a specific folder and have Sirius select the right one according to the picture’s name. This can easily be done by using the style customizations.
We modify our mapping to specify a workspace image style.

We provide a new style customization:

And a new property customization by expression:

All the pictures are stored in an images folder.

Then we specify that the style to customize is the workspace image previously defined.
This style customization must be applied on PersonWorkspaceImage and we want to customize the workspacePath property:

To retrieve the value of the workspacePath, we call a Java service getImage which returns the image path from the person name:

Finally, when we reopen our example, we get a shinier diagram this time with everybody associated to his picture.

And now if I update the name of a character, I get automatically the associated picture. John Doe is represented by the default image and we see Zoe’s lovely face.

With the next Sirius 3.0 version, if you use images with a transparent background, the edges will follow the image.

The sample code from this example is available on github: https://github.com/mbats/sirius-blog/tree/master/custo-diag

The Tree Layout Secret

A recurring problem when developing a graphical modeler is providing the right layout. The advantage with Sirius is it provides you with a default algorithm that performs an automatic layout of all the elements on a diagram.

To illustrate the Sirius’ layout capabilities imagine that we want to visualize the hierarchy of characters in the US TV series House Of Cards. To do this we define the following metamodel:

First, we used Sirius to create a diagram representing the Persons.

Each person is represented by a white square with his or her name on it.

By default Sirius lays out nodes from left to right and what we now have is a flat diagram, with each person on exactly the same level.

However what we want to see is the White House organizational hierarchy so we need to represent the subordination link. This link is modeled using the dependsOn reference in the metamodel.
Second we define a new relation based edge mapping. This edge will connect Persons, and to find the subordinate we just use the dependsOn reference.

The default layout will automatically present an ordered tree diagram of the White House hierarchy with president Garrett Walker at the top of the diagram and Congressman Peter Russo at the bottom. When you define a relation based edge, Sirius then automatically lays out the elements as an ordered tree diagram by using the dependsOn reference to find the children.

That looks all very well and good. However, supposing that now we want to retain and be able to view our subordination link but also order our nodes according to a different relation. In our metamodel we add another reference influences that represents the influence one person can exert over another. We need to create another kind of diagram with the most influencial person at the top and the most influenced person at the bottom whilst still retaining the former subordination links between the persons.

Great news! This is really easy to implement with Sirius!
If the Sirius default algorithm does not fit your particular needs, you can configure some of the parameters or request alternative algorithms directly within the Sirius specification editor.
You can define either of:

  • A Composite Layout : this must be used to show containment relations. It enables you to specify padding between the different elements and the direction for the default algorithm.
  • An Ordered Tree Layout : this must be used so as to lay nodes as an ordered tree.

These layout algorithms manage only nodes connected by edges, other nodes are lay out from left to right as usual.

The Ordered Tree Layout is what we need for our case.
We defined a new Influence diagram with a Person mapping and a DependsOn mapping. These mappings are exactly the same as with the Hierarchy diagram. The only difference being that we have produced an Ordered Tree Layout.

The Children Expression is used to specify how to retrieve children for each node. In our example we use the influences reference to progress through the model.

Your Node Mapping must specify the mapping that the tree order algorithm is to operate on. In our example we want the algorithm to operate on Person.

Note: the ordered tree layout only works if you have only defined a single kind of node mapping in your diagram specification.

And… Ta-daaah! By defining this new layout you can see the person influencing every other player in the White House is… Frank Underwood, but Shh! That’s a secret ;)

Finally, if you need to go further, you can also provide your own layout algorithm programmatically.

The sample code from this example is available on github : https://github.com/mbats/sirius-blog/tree/master/tree-layout

Sirius posts are coming!

Just to announce that we (I and some Sirius commiters from Obeo) will start a series of posts about some features available in Sirius. For the ones who don’t know, Sirius is an Eclipse project to quickly define multi view workbenches based on DSL with dedicated representations. Sirius is part of the release train since Luna and its version 3.0 will be available with Mars.
A modeling workbench created with Sirius is composed of a set of Eclipse editors which allow the users to create, edit and visualize EMF models.
In the next weeks, you will discover posts about diagram customization, tree layout, SVG images…

Stay tuned!

Release 1.0.0 of the Buildroot/Eclipse integration

We are proud to announce today the first release of the
Buildroot/Eclipse integration. This integration will make it easier
for Eclipse users to develop, build, and debug applications in the
context of embedded Linux systems generated with Buildroot.

This integration allows Eclipse to:

  • Automatically discover the toolchain made available by each of the
    Buildroot project on your machine.
  • Automatically build your application or library in Eclipse using
    the cross-compiler of a given Buildroot project. Eclipse also
    automatically recognizes all the cross-compiled libraries that are
    exposed through pkg-config, so that linking your application
    against one or several of those libraries is just a matter of
    selecting them in a list.
  • Automatically copy your compiled application to the target and
    execute it, directly from Eclipse, with just one click on the “Run”
    button.
  • Automatically start a remote debugging session, directly from
    Eclipse, with just one click on the “Debug” button.
  • Explore the target filesystem from Eclipse, get access to a shell
    on the target (using SSH).

More details on the project home page on github.

EclipseCon North America 2013 Submissions

I submitted two talks for EclipseCon North America 2013 :

This conference will take place this year in Boston on March 25-28 2013.

EclipseCon Europe 2012 Submissions

I proposed two talks for the EclipseCon Europe 2012.
The first one is dedicated to System Engeneering to demonstrate how to build a custom workbench based on Eclipse modeling software constellation:
http://www.eclipsecon.org/europe2012/sessions/build-your-own-system-engineering-workbench
I have also posted a talk on Buildroot Toolchain Eclipse Plugin for which I will give details soon :
http://www.eclipsecon.org/europe2012/sessions/buildroot-eclipse-bundle-powerful-ide-embedded-linux-developers

The EclipseCon Europe will take place from October 23rd to October 25th 2012 in Ludwigsburg, Germany.