I would like to describe several important rules of thumb that will help you to distinguish yourself from your modeling peers. This simple, yet critical, advice focuses on how to arrange the bubbles and lines that make up your software diagrams -- including UML class models, use case models, and even persistence models -- and is therefore applicable to all kinds of diagrams.

To draw clean-looking diagrams you should avoid:

• Different-sized bubbles
• Diagonal lines
• Crossed lines
• Curved lines
• Cluttered diagrams
• Unnecessary detail

Let's begin by considering an example. In Figures 1 and 2, you see two diagrams drawn using two different styles. The first one is complex and disorganized while the second is simple and well organized (albeit a little boring). Which one looks like a better design to you? Most people would agree that the second one looks better because it is laid out in a cleaner way, although the fact is that both designs are functionally identical.

Avoid bubbles of different sizes

How did I improve Figure 1? First, I made sure that all the bubbles were of the same size. Larger bubbles appear more important than smaller ones, which is good if that is what you are trying to communicate -- but given the option, I prefer to make my bubbles the same size. This approach is best suited for UML Use Case diagrams where all the use-case bubbles and actor symbols can easily be the same, as well as UML Collaboration Diagrams, UML Sequence Diagrams, UML Collaboration Diagrams, and User-Interface Flow Diagrams. It becomes a little more difficult for diagrams where the bubbles contain varying amount of information, such as UML Class Diagrams where individual classes have different numbers of attributes and operations, or UML State Chart Diagrams and Persistence (data) models.

Back to top

Avoid diagonal lines

Additionally, Figure 2 does not have any diagonal lines, unlike Figure 1. I did this by reorganizing the bubbles as if they were on a grid, keeping connected bubbles either vertically apart or horizontally apart. Straight lines are more visually appealing to most people.

Back to top

Avoid crossed lines

In Figure 1 there are two lines that cross each other, and my general rule of thumb is that you should strive to minimize the number of crossed lines in your diagrams. By moving a few bubbles around, I could quickly avoid having the two lines cross. Unfortunately, you don't always get this lucky -- you can't always avoid crossing lines. In Figure 3, I would like to fully connect five bubbles but cannot do so without having at least two lines cross each other. As you can see, there is no other way for me to connect bubbles 3 and 5. When I am forced to have crossed lines, I will notate it using the standard applied on electrical-wiring diagrams: one line is drawn "hopping over" another one, as in Figure 4. The advantage of hopping is that it is clear that the lines are only crossing on your diagram, and that they don't connect in any way.

Back to top

Avoid curved lines

I improved Figure 4 even further by removing the curved lines, as you can see in Figure 5. People like straight lines that are either vertical or horizontal. Once again I pretended I was drawing my diagram on a grid (this is actually a built-in feature of many computer-aided system engineering (CASE) tools), then I simply drew my bubbles and lines as if there were on that grid.

Back to top

Avoid cluttered or complex diagrams

Diagrams that show too many details or that appear cluttered don't look good. It is better to have several diagrams showing various degrees of detail than to have one complex diagram that shows everything. This is one of the reasons why the UML has several diagrams: software is so complex you cannot hope to model all of its aspects on a single diagram. Furthermore, the UML allows packages to be added to diagrams (the topic of next week's tip).

A related consideration is the use of your screen or page real estate. In my opinion, one diagram spread out over several pages is better than a diagram with everything smushed together so it will print onto one page. You should take as much space as you need to make your diagrams easy to understand.

Back to top

Avoid wasting too much time making your diagrams look pretty

Although these rules of thumb work very well, there is always the danger of adding hours to your modeling efforts by endlessly tweaking the way your diagrams look. One way to solve this is to try to get your diagrams looking good in a rough sort of way -- a diagram doesn't have to be perfect while you're working on it. Once you're satisfied that your diagram models the application the way that you want it to, then begin moving bubbles around to avoid crossing lines and improve its understandability.

Your main goal is to model the system, not to produce a pretty diagram. It is important to point out that you can use also these rules of thumb to make a bad design look good. For example, I could have started with Figure 2 and rearranged it into Figure 1 to make my design look more complicated than it actually is -- perhaps to convince senior management that I need more time or resources to do the work, or to steer them away from a design alternative that I don't particularly like. Given that your motivations change from situation to situation, I hope that your situation is happy enough that your greatest concern is to make a great design look spectacular, rather than to survive office politics.

Resources

• Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology by Scott W. Ambler. New York: Cambridge University Press, 1998.
  
  
• Process Patterns -- Building Large-Scale Systems Using Object Technology by Scott Ambler. New York: Cambridge University Press, 1998.
  
  
• The Object Primer 2nd Edition by Scott W. Ambler. New York: Cambridge University Press, 2000.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Avoid bubbles of different sizes
• Avoid diagonal lines
• Avoid crossed lines
• Avoid curved lines
• Avoid cluttered or complex diagrams
• Avoid wasting too much time making your diagrams look pretty
• Resources
• About the author
• Comments

Next steps from IBM

With Rational Software Modeler you can increase productivity by dragging and dropping your way to a visual interpretation of your UML design.

---

• Try: Download a free trial version of Rational Software Modeler, a UML 2.0-based visual modeling and design tool for architects, systems analysts, and designers.
• Article: Learn what UML limitations are and how you can overcome them with Rational Software Modeler.
• Tutorial: This tutoral provides a tour of Rational Software Modeler's Visual UML modeling tools.
• Demo: This demo guides you through the creation of a UML modeling with Rational Software Modeler.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers