Draw a clean UML diagram

Whether you like it or not, Software Diagrams such as the Unified Modeling Language (UML) model and use case model often determine their quality based on their appearance. Neat charts are more favored by readers-often your users or senior managers-than messy ones.

I would like to describe several important empirical rules that will make you better than other modeling colleagues. These simple but key suggestions mainly focus on the boxes and lines that make up Software Diagrams (including UML class models, use case models, and even persistent models, therefore, it applies to all types of graphs.

To create a clean-looking chart, avoid:

• Boxes of different sizes
• Diagonal Line
• Crossover line
• Curve
• Chaotic Graph
• Unnecessary details

Let's start with an example. In figures 1 and 2, you can see two graphs drawn in two different styles. The first one is complex and has no rules, while the second one is simple and well organized (although tedious ). Which one do you think is better? Most people will agree that the second one looks better, because although the two designs are functionally equal, the second arrangement is more neat.

Figure 1. "messy" Diagram

Figure 2. "clean"

Avoid boxes of different sizes
How can we improve Figure 1? First, make sure all the boxes are of the same size. A large box seems to be more important than a small box. If this is what you try to express, that's right-but if I select it, I 'd rather keep all the boxes in the same size. This method is most suitable for the "UML use case" diagram, because all the use case boxes and the participant symbols can be easily unified into the same, it also applies to "UML collaboration diagram", "UML Sequence Diagram", and "UML User Interface flowchart ". For charts with different information contained in the box, such as "UML class diagram" (some of them have attributes and operations of varying quantities ), or the "UML status chart" and "persistent" (data) models are difficult.

Avoid diagonal lines
Another difference between figure 2 and Figure 1 is that it does not have any diagonal lines. I try to rearrange boxes to remove diagonal lines, as if they are on a grid, so that the interconnected boxes can be separated vertically or horizontally. Visually, most people are more interested in straight lines.

Avoid crossover
In Figure 1, there are two lines that cross each other. One of my common empirical rules is to minimize the number of cross lines in the figure. By moving some boxes to the side, I can avoid cross of the two lines in a short time. Unfortunately, it is not always so lucky-you cannot always avoid crossover. In Figure 3, I want to connect all the five boxes, but this cannot be done without having at least two lines intersection. As you can see, I have no other method to connect Box 3 and 5. When I have to cross the line, I will mark it with the standard for the circuit diagram: One Line "skips" and the other line, as shown in 4. The advantage of skipping is that it is clear that the explicit line only crosses the graph and does not connect in any way.

Figure 3. How to Connect 3 and 5 without crossover lines?

Figure 4. One line jumps over the other

Avoid Curves
As you can see in figure 5, I made further improvements to Figure 4: removing the curve. People like to see vertical or horizontal straight lines. This time I pretended to be drawing on a grid (in fact, this is the built-in feature of many Computer-Aided System Engineering (CASE) tools ), then, you only need to draw boxes and lines like on the grid.

Figure 5. clean version of Figure 4

Avoid chaotic or complex Graphs
An image that shows too many details or looks messy does not look very good. It is best to have several pictures that show details of various degrees, rather than a complex diagram that shows all things. This is one of the reasons why UML has several diagrams: A software is so complex that we cannot model all aspects of a single graph. In addition, UML allows you to add packages to the diagram (tips for next week ).

Another important note is the use of the screen or page area. In my opinion, a picture with several pages is much better than a picture that wraps all the content together so that it can print on one page. You should leave enough space for the graph to make it easy to understand.

Avoid wasting too much time on image beautification.
Although these empirical rules are very effective, changing the appearance of an image will always increase the modeling time. One way to solve this problem is to try to make the image look at a very good level-you don't need it to be perfect when using it. Once you are sure that the graph is modeled on the application as needed, you can start to move the box to avoid crossover and improve comprehensibility.

Your primary goal is to model the system, rather than creating beautiful images. It is necessary to point out that these important empirical rules can also be used to beautify poor designs. For example, from figure 2, I can rearrange it into 1, to make the design look more complex than actually-it may make senior managers believe that I need more time or resources to complete the work, or guide them away from alternative designs that I don't particularly like. Assuming that your motivation changes with the situation, I hope that your situation is healthy. The most important question you consider is to make the amazing design look more fascinating, instead of survival in Office authority.