I got my introduction to Object Oriented Modeling (OOM) by using Grady Booch’s

methodology. I was writing a series of C++ books for McGraw-Hill at the time, and
Grady sent me a (hand marked up) copy of his manuscript for a book on OOM. At the
time, there were over ten different methodologies a literal ”Tower of Babel” situation in
design notations.

UML borrowed ideas from the Booch notation, Rumbaugh notation, and Jacobson’s
notation. UML is now widely accepted as the standard notation for performing OOM
activities.

Most books on UML (e.g., the book Paul Harmon and I wrote, ”Understanding UML”)
go into some great detail on all UML diagram types. My approach here is a little
different: in my own work, I find myself usually only using three types of diagrams and
we will only discuss these three types of diagrams here:

• Use Case describes how users of a system interact with it

• Class documents the public and (optionally) private APIs for a class
• Sequence shows how objects of different classes interact as a function of time

A word of warning: be aware that we are just looking at the most commonly used aspects
of UML in this book; if you will be using UML with other team members, they are likely
to want to use additional types of diagrams. That said, this chapter exposes you to the
basics and provide a good starting point.

5.1 Use Case Diagrams

Even programmers who do not like to perform a lot of up front design work will find use
case diagrams a very effective method to both understand customer requirements and as a
type of contract between you and your customers. Like all aspects of good design, use
case diagrams not only will help you to reduce the costs of writing all but the most trivial
programs, they will also serve as insurance that you are developing what your customers
really want. In the next chapter, we will see an example use case diagram (Figure Figure
6.1).

As a developer, you will base the use cases that you write on conversations with your
customer. A set of use cases can be refined until both you and your customer agree on the
way that a system will be used and, in keeping with the philosophy of Extreme
Programming, can be used to define test cases early in the development cycle.

A good alternative to using UML modeling tool to create use case diagrams is to use 3x5
cards. Write a (very) brief description of each use case on a separate 3x5 card.

In either case, the idea is to develop a set of independent example uses of the system
under development.

5.2 Class Diagrams

Class diagrams are used to show both the APIs for a class and internal data and also to
show the relationships between classes. I find class diagrams to be most useful when used
to get a top-level overview of the major classes in a system and how they inter relate. For
a complex system implemented with hundreds of classes, I do not think that it makes
sense to produce class diagrams for all classes.

Most UML modeling tools (e.g., Poseidon) offer ”round trip” capabilities: if you already
have source code, then they can import the source code and automatically produce
diagrams. If you modify a diagram in the modeling tool, for example: adding a few
methods and extra class data, then the modeling tool can automatically update your
source code.

If I need to quickly produce high-level UML class diagrams for a new project, I find it
fastest to use a text editor to write skeleton code (i.e., just method signatures and data
definitions) for the top level classes and import this source code into my UML modeling
tool. I use the tool to clean up the layout of the diagrams, and tweak the initial class
design before allowing the modeling tool to update the original source code.

While I find modeling the high level classes for a new project useful, I also have a word
of warning: design is far from a perfect science. You will be modifying your design as
you get experience implementing the system. For this reason, I prefer for my own work
to cycle between design and implementation work. Too much up front design time can be
wasted if during early implementation you discover errors in requirements analysis
(which I consider part of design, not a separate step) or design that requires large
modifications. I consider best practices to be a cyclical development style.

Figure 6.2 in the next chapter I an example of a top-level class diagram for an automated
help desk system.

5.3 Sequence Diagrams

Sequence diagrams are a great way to understand and to explain to other people how the
objects in a system inter relate as a function of time. The utility of sequence diagrams is
incredible for at least three reasons:

• Allows developers to really understand the time-sequenced interaction between

system objects.
• Allows technically oriented customers to get a better understanding of how the
system will function.
• Allows developers to identify ”failure points” and facilitates setting up test cases.

I personally consider UML sequence diagrams as one of the ”big wins” for UML that
does the most to justify the time required for UML modeling. We will see an example
sequence diagram in Figure 6.3.