UML Best Practice: 5 rules for better UML diagrams

Following these 5 rules will make your UML diagrams easier to understand, cleaner, and more consistent.

Although that has no effect on the actual model, it will improve the communication with the stakeholders.

Rule 1: Less is more

Large diagrams containing heaps of elements actually convey less information then small focussed diagrams.
When reading such a large diagram your audience will not know what to focus on, and since there’s too much on there to actually pay attention to all elements, they will quickly give up trying altogether.

Show up with a diagram like this at your stakeholder, and you will have already lost his/her attention even before you start talking.

The diagram above is a good indication of how much, or how little, you should put on a diagram. My rule of thumb is that you need to be able to print the diagram on a single A4 sheet while keeping things readable.

Rule 2: No Crossings

This is a fairly common and well known rule. Try to avoid any two lines in your diagram to cross each other.

Uncrossing lines in your diagram sure make it more readable and understandable, but there’s more to it then that.  If you are unable to uncross the lines on your diagram then that is a sign that

  • a) there’s too much on the diagram (see rule 1 Less is more)
    It might be that you are showing two different aspects of the model in one diagram. In that case it might be better to create two different diagrams, each focused on one aspect.
  • b) there is some kind of design flaw in your model
    For some reason well designed models don’t have the crossing lines problem. I have no idea why or what it is exactly, I just noticed that a lot of the times, when I’m unable to “uncross” all the lines in a diagram, I discover a design flaw that, when fixed results in a diagram without crossing lines.
The following diagram contains exactly the same information, but has just been ordered differently as to make sure there are no crossing lines.

Rule 3: Orthogonality

It seems like a small thing, but making the lines in a diagram go only horizontal or vertical, and having all only right angles makes a diagram look better instantly.

The diagram below is uses a direct style for its connectors. they all go directly from one element to the other with a straight line.

The mere fact that the lines have all kinds of angles makes the diagram look a lot messier, and less understandable.

Below here again the same diagram, but now with all connectors styles set to orthogonal.

Exceptions to this rule are (for me) note links and all relations with use cases. For some reason they look better with a direct style.

Rule 4: Parents Up

When drawing generalization or realization hierarchies on a diagram always make sure the parent elements are higher then the child elements so the arrows always point upwards.

This rule is pretty intuitive for most UML modelers. Only now and then I encounter diagrams that don’t follow this rule and have their hierarchies upside down.

Diagrams like this, where the generalization arrows point downwards are harder to read. For some reason it takes a greater mental effort to understand this then when the arrows all point upwards.

In case you have multiple elements all descending from the same parent, it is recommendable to show the hierarchy in a vertical tree style.

Rule 5: Tidy Up

I realize this sound like a nagging mom, but for crying out loud: Tidy Up!

If you want to convey the message that your analysis is a well thought trough construction that will solve your stakeholders problems then you better show up with a nice and clean diagram.

When tidying up think about

  • Aligning elements, either by one of their sides (e.g Top) or by their centers. The latter works best when aligning vertically
  • Make elements the same size where possible

After tidying up the diagram looks a loot better

Now remember, following these diagramming rules will not make you a better analyst, nor will it result in better UML models.

But it will allow you to make a better impression when trying explain the fruits of your hard labor to your stakeholders. You will need less time explaining diagrams, and you will be able to spend more time focusing on the actual content.

More UML best practices

Published by

Geert Bellekens

Freelance UML and Enterprise Architect consultant

30 thoughts on “UML Best Practice: 5 rules for better UML diagrams”

  1. Hi if i have a class diagram for a check-in system for automatic check-in, express lane check-in and normal check-in with 17 classes(assuming database has already been created) is it consider too much?

    1. 17 classes is probably pushing the upper limit.
      Can you still print it on a A4 and still read all the info? If not you might consider creating a diagram per type of check-in.

  2. These guidlines are very useful for me to model SysML/UML diagrams which can be understood with less effort by other non-technical collegues. But there are some exceptions depends on the complexity of the diagram.

    In some diagrams it is so difficult to avoid the crossing lines.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s