I got my introduction to Object Oriented Modeling (OOM) by using Grady Booch\u2019s
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 \u201dTower of Babel\u201d situation in
UML borrowed ideas from the Booch notation, Rumbaugh notation, and Jacobson\u2019s 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, \u201dUnderstanding UML\u201d)
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:
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.
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
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.
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 \u201dround trip\u201d 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
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.
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:
I personally consider UML sequence diagrams as one of the \u201dbig wins\u201d for UML that does the most to justify the time required for UML modeling. We will see an example sequence diagram in Figure6.3.
Now bringing you back...
Does that email address look wrong? Try again with a different email.