Monthly Archives: September 2010

Modeling Tool Usability Checklist – Element Deletion

Posted on by
Reply

Working with modeling tools that provide different views on the same model (like UML with diagrams) can be an interesting experience. The relationship between model and views introduces some challenges for usability, which is addressed differently by tools. These aspects can easily confuse those that do their first steps in modeling and annoy those that work with several tools. I suggest that you might want to have some checklist for your tool for quick reference to navigate these quirks. In a number of blog posts, I will propose and explain this checklist.

For illustration, I am working with Papyrus/MDT. Papyrus at the time of writing is available in version 0.7.0. Usability might change, but Papyrus is only used to illustrate the checklist, not to comment on the tool itself.

Checklist: In your tool, what commands are used for local deletion (in diagram) and from model.

Assume we have a small UML model with three classes, RainSensor, RainSensor Variant and SunRoof in two diagrams A and B.

Diagram A

Diagram A

Diagram B

Diagram B

It is important to remember, that diagrams are only views on the model. The actual model can be seen in the tree view. Obviously we should only find one RainSensor in the model.

Model Viewer

Diagrams are views on the model.  This has a view implications on usability. If we have a look on the context menu of Papyrus, we see two commands for deletion:

Deletion Commands

These two kinds of deletion commands can be found with all kinds of different naming conventions in graphical modeling tools. 2) will remove the symbol from the diagram without modifying the model. 1) will actually remove the model element. If you try 2), the model will not be changed. However, this is how the screenshots change after you choose 1): Since the model element has been deleted, its symbol is removed from Diagram B.

Don’t confuse the two, you might accidentally remove elements. It would be great if your tool had functionality to show you the impact of a deletion (the impact of any change would even be better).

Model elements can also be deleted by using the pop-up from the tree view:

Checklist: Check the semantics of Undo

If you try the above in any of your tools, try the undo function as well and see what your tool does. If you try the steps above and use undo after deleting from within the diagram, you will get the following results:

and, unexpectedly:

This tool does not undo any side effect a change has on other diagrams! Be sure to check the semantics of undo, to make sure you do not loose any data.

Checklist: Changes on closed diagrams

If you close the diagram (i.e. it is not open for editing), changes can have a different semantics. Again, deleting the model element RainSensor from within Diagram A, but having closed Diagram B results in the expected deletion of the model element. This is how B looks after opening it again:

Suddenly, there is an element “model” in there? What happened? Tools that do not actively update closed diagrams when the model changes, have to check the consistency of diagram and model upon opening. This specific tool seems to follow the strategy to replace references to non existing model elements with references to others. Check what your tool does!

Checklist: Collaboration

Several people working on one model at the same time opens another can of worms. Without going into detail: Check how deletions by one person are propagated throughout the system.

Checklist: Find unreferenced elements

You can easily imagine, that you might delete an element from the diagram, actually forgetting about it. But it is still there in the model. Does your tool have functionality to find unreferenced elements? You wouldn’t want to browse through all the diagrams just to find the unused items.

The next post on the topic will be on element renaming.

Modeling AUTOSAR with UML / Papyrus

Posted on by
2

In the early days of AUTOSAR (Release 2.0) there was the idea of using UML tools for AUTOSAR modeling by applying profiles. At this time, an actual profile had been defined as part of the documents provided by AUTOSAR (http://www.autosar.org/download/R2.0/AUTOSAR_UML_Profile.pdf).  This document has not been updated further, partly because the main contributor (an UML tool provider) left AUTOSAR at that time. I was never convinced that the UML profile approach was feasible. Grafting AUTOSAR on top of UML requires mapping a complex meta-model to another. In terms of AUTOSAR ECU configuration, there is no real correspondence in UML and the UI of the UML tool would have to go major changes. Today, with the availability of an AUTOSAR meta-model tooling in the form of Artop, domain specific languages and graphical editing frameworks (GMF/Graphiti), the approach is even less feasible IMHO.

You can easily create AUTOSAR software-component models with textual modeling by using ARText. There is, however, no low-cost tooling available right now for showing graphical models. So if you want to avoid license costs and still be able to graphically software components, for this case, an UML profile could be one approach. Both AUTOSAR and UML provide a component model, so the meta-model structures have more similarities than in other areas of AUTOSAR.

The nice thing is, that you can use open source UML tools for modeling. If you use Papyrus, you can easily define stereotypes for AUTOSAR:

The basic component types of AUTOSAR are easily added. But the great thing is that Papyrus allows you to change the graphical representation of elements depending on the stereotype. AUTOSAR defines a certain notation for sender/receiver ports, so we can bring this notation to Papyrus by first defining a stereotype for sender and receiver ports:

Note the “<Image>” elements in the property sheet. You can set these to any image. To do this, you have to locate them in the model browser and load an image by pressing the “+” button. After that, the “+” button will be replaced by a preview of your icon:

Now go ahead to model in “AUTOSAR”-style (change the appearance of the ports in the corresponding tab to “icon”):

Of course, you now have an UML model. But with Eclipse M2T/M2M technologies you can transform that to an AUTOSAR model.

Relocation

Posted on by
Reply

The itemis south branch has been operating out of Pforzheim (which is 50 kms west of Stuttgart) for several years and we are really having nice offices in a good environment here. However, for a number of reasons, we feel that there are a number of factors that made us re-evaluate the Pforzheim location:

  • itemis is providing services to companies for MDSD in several domains. One domain is “complex technical systems”, which includes automotive / embedded. Several of our customers here in the south of Germany are obviously based in Stuttgart.
  • itemis is growing. We find it easier to find new talent for our Stuttgart office.
  • itemis is member of several consortia (AUTOSAR, Genivi) and research projects (VERDE, Q-Impress,etc.). Hosting meetings in Stuttgart will be more convenient for our project partners, that come from all over Europe.
  • itemis has its main office in Lünen near Dortmund. There is a great train connection from Stuttgart to Dortmund (3,5 hours).

All of this factors brought us to the decision to fuse our small Stuttgart office with the Pforzheim office in a new location in Stuttgart. Further factors where:

  • the location should be easily accessible from both the main station and the airport for guests, colleagues and commuters (basically no changing trains from those stops, more than one public transports stopping near the office)
  • the location should be easily accessible for our commuters from Pforzheim (i.e. a highway exit in the south west of Stuttgart)
  • the location should allow for growth
  • the location should have a bright atmosphere
  • food, good food. Good lunch is a prerequisite for a good afternoon.

We found all that in the Stuttgart Engineering Park STEP and I am looking forward to us opening the new office and growing further in January.