The Sphinx project is one of the most interesting new projects on eclipse.org and provides important infrastructure for modeling projects. However, it might not be immediately visible from the project description what it does. Here is an example on how it can help you when writing graphical editors (in our case with Graphiti).

We face two questions:

• How to deal with models, that consist not only of one model file, but is actually split up between several models
• How to synchronize different views etc in Eclipse.

The first question immediately comes up for models that can be split per definition (as in AUTOSAR, where a model can be defined in several .arxml files). But even if you think that your domain model is only stored in one single file – by introducing one or more Graphiti diagrams (which are stored as EMF models), you have to combine these with the domain model.

Multiple copies of the domain model

The second question might not be immediately obvious, but you will notice it soon. The different views in Eclipse are not guaranteed to use the same in-memory representation of a model file, making synchronization difficult:

The Navigator in the Explorer View and the Diagram Editor might both load the domain model with standard EMF mechanism. But that results in each of the view having their own specific copy of the model independent of the other view. That means that an object “Wiper” is available in memory for the navigator and a different object “Wiper” at another memory location for the graphical editor.

That has several consequences:

• Changes in one editor are not reflected in the other editor immediately, since these are obviously different objects in different resources
• Synchronizing is done on resource save – the other editor detects that the resource has changed. This is annoying, because for the explorer this will result in the contents of the model being collapsed and you have to open everything again. And in the Graphiti editor, you will be notified that the underlying resource has changed and asked if you would like to discard your changes – even if your diagram does not have any of the affected domain model elements in it.
• Drag and Drop needs extra effort. If you drag one object from one view to another, you cannot just rely on the “==” operator, because even if it is the same domain model object, it will just be another copy. So you have to work with URIs or other approaches to find the domain model object you are being passed in your resource.

Sphinx to the rescue

Sphinx helps you with that. Sphinx provides extension points and an API to define which model files should be considered together as one model and then you just ask Sphinx for the model – everything else is taken care of.

Code details

There is an example integration of Graphiti editor in the Sphinx experimental directories – but we had to add additional things, since we derive from the plain Graphiti way at several places. The standard experimental Graphiti / Sphinx integration works on the Graphiti EMF namespace. However, since we derived from that, we need to tell Sphinx which models should be loaded to Autosar:

By providing the TargetMetaModelDescriptorProvider we tell Sphinx that our models should be loaded into the models defined by a target meta model descriptor. The default Sphinx/Graphiti integration is quite elaborate, but for us, we always want to be loaded into AUTOSAR model. So the implementation of the class is quite simple – by returning the Autosar40 model descriptor:

The target meta model is related to the model that should be added through the contentType attribute of targetDescriptorProvider(see screenshot above). Obviously, we need a Descriptor for our own GraphitiAutosar Metamodel (which is derived from Graphiti Diagram ecore):

Finally, we define a content-type for our diagram extensions:

In addition, we register a specific editor through org.eclipse.ui.editors:

Note the line “class” is

which is a modification done to actually invoke Graphiti editors with Guice.

After this implementation, changes done in the diagram are immediately reflected in the Graphiti editor (and vice-versa) and the drag-and drop code can be much simplified by checking with the “==” operator.

When working with AUTOSAR specifications, it is easy to see from the models on a high level which software components are communicating with each other. However, it is often interesting to see how that maps to the communication between ECUs. To do that, you have to take the software mapping into account that specifies, which SWC are mapped to which ECU. That adds quite some new levels of indirection and the information is not easily to be retrieved from the AUTOSAR model.

In the IMES project, we are easily showing that information in a diagram that shows the ECU mapping and then automatically calculates the necessary connections so that the architect can easily see the resulting data flow between ECUs.

Starting point is the ECU diagram, that can show buses (not shown in the screenshot, ECU instances and the mappings of software components to ECU instances). The left red square marks some mappings in the Artop explorer which are reflected by the marked rectangles in the diagrams (mappings are automatically added to the ECU instances in the diagram on user request). Now it would be interesting to see, if that mapping actually results in inter ECU-communication.On user request, the communication between mapped SWCs is added to the diagram and then the diagram is completely layouted. Of course, it is not only of interest, if two ECUs communicate, but also what data is transmitted. This can be seen by selecting a connection: The documentation view is updated with information on the involved ports, interfaces and data elements.

Inter-ECU communication