UML Diagram Style Guides

The UML-Taiwan Blog has several posts containing a style guide for UML diagrams. It turns out hat the posts are a chinese summary of “The Elements of UML 2.0 Style” by Scott Ambler. You can find excerpts of the book on Google’s book search. It has been on the market for several years – and it still is a book that I would recommend for modellers / tool designers. It contains a lot of good points on modelling / diagramming. But some points are arguable.

  • (#1) Depict crossing lines as a jump
    Good idea. But usually the user is stuck with the lacking support of the design tools. Tool designers, consider this!
  • (#3) Avoid Diagonal or Curved Lines
    In state machines curved lines actually can increase readability. This basically related to the tool capabilities. Layout with curved lines can look pretty good (have a look at the graphs done by Graphviz e.g.).
  • (#8) Don’t Indicate Exploding Bubbles
    The author argues that the “rake” symbol for indicating additional information is not necessary because the user is smart enough to double click for information. However, in my experience, it is nice to have such indicators in the design phase to be able to know which elements actually have additional information. It interrupts the workflow when you click on elements only to find empty information.
  • (#9) Minimize number of Bubble Types
    This should probably read “Minimize the number of bubbles / symbols”.
  • (#60) Imply timing considerations by stacking use cases
    I have actually done that with several tools and it as a valid approach. But it needs a big caveat: Beware that your vertical ordering might be of no relevance to your tool. The order of model elements e.g. in a report probably will not be influenced by the graphical layout and you might not be able to access it by any other means. This might cost some tool customizaion in your project.
  • (#25) Prefer Naming Conventions over Stereotypes:
    An effective alternative to applying a stereotype is to apply a naming convention. For example, instgead of applying the stereotype <<getter>> on an operation, you could simply start all getters with the text get, as you can see in Figure 5 with the getSeminarsTaken() operation. This simplifies your diagrams and increases the consistency of your source ocde.

This suggestion conflicts with the basic approach of MDSD:

  • Create abstract models
  • Create semantically rich models

The example given is not very good. You should not model infrastructure aspects in your domain model. The getter/setter-stuff is to be kept out of the model and should be added by M2M or M2T-Transformation later on.  Usually, these operations do not add any information to the model. You don’t want that, unless your code generator generates 1:1 from the model – but in that case you are not modeling, you are programming in UML diagrams (actually the book has guideline (#99) Do not model scaffolding code, which says just that. But having such an example early in the book is misleading.

In addition, expressing semantics by naming conventions is error-prone. Using modelling techniques just like stereotypes are semantically better and can be processed by transformation steps much easier.

  • (#25) Consider Using Color in your Diagrams

Color is a difficult topic in User interface design. It’s best to use it extremely sparingly for visual indications. In fact, Scott Ambler writes in one of his other books: “Color should be used sparingly in your applications and, if you do use it, you must also use a secondary indicator. The problem is that some of your users may be color blind and if you are using color to highlight something on a screen, then you need to do something else to make it stand out if you want these people to notice it.

Leave a Reply

Your email address will not be published. Required fields are marked *