I never expected to write a methods book.
I was approached to write one late in 1992. By then, however, all the
really influential methods books had been published, and I didn't think I had anything
significant to add to the literature. As far as I was concerned, the ground was covered-there
were better things to do. I had decided not to create a new methodology that was "fowler" than
all the others, and there were already too many methodologies.
When Grady Booch, Jim Rumbaugh,
and Ivar Jacobson (the "three amigos") joined forces to form a single Unified Modeling Language
(UML), I was delighted. Arguments over which method to choose are some of the most tiresome
arguments I've had to deal with, particularly since they have little impact on the final result.
I was glad to see that argument go away. When I was approached to write this book, the amigos
were beginning to write their books; these books will be the authoritative works on the UML.
However, there is a need for a short book to both provide something while the three of them are
working on their larger works and act as a concise UML guide. I intended to make this volume the
shortest methods book ever written.
Although this is a noble aim for me, is this the right book
for you? I'll start by telling you what this book is not.
It is not a tutorial on OO analysis
and design with the UML. The user's guide, led by Grady Booch, will be that book.
It is not a
definitive reference guide to the notation and its semantics. The reference guide, led by Jim
Rumbaugh, will be that book.
It is not a detailed guide to the process of using the UML on
object-oriented projects. The process guide, led by Ivar Jacobson, will be that book.
is a short guide to the key parts of the notation, the semantics, and the process. I am aiming it
at those who already have used object technology, probably with one of the many currently
available OO analysis and design methods. This book tells you quickly what the key elements of
the notation are and what they mean, and it suggests an outline process for using them. I've also
taken the opportunity to add tips and suggestions from my use of object methods over the last
decade. Because it is a short book, it will be easier to digest the information and get used to
what the UML has to say. It also will provide a good first place to look for reference
Chapter 1 looks at what the UML is, the history of its development, and the reasons
why you might want to use it.
Chapter 2 discusses the object-oriented development process.
Al-though the UML exists independent of process, I find it hard to discuss modeling
without talking about where they fit in with object-oriented development.
Chapters 3 through 10
discuss the various modeling techniques of the UML, in turn. I have organized these chapters
around the kinds of diagrams I find useful. I describe the notation, including its semantics, and
tips about using the techniques. My philosophy is to make clear what the UML says and,
at the same time, give you my opinions on how best to use it.
Chapter 11 gives a small example to
show how the UML fits in with programming using (of course) Java.
The inside covers summarize
the UML notation. You may find it useful to refer to these as you are reading the chapters so
that you can check on the notation for the various modeling concepts. Scattered within the
"official UML" chapters are a number of sidebars on other techniques I have found valuable but
which are not emphasized in the UML. They certainly can and should be used with the UML. For
each UML and non-UML technique, I've provided summaries about when to use the technique and where
to find more information. As I write this, there are no UML books on the market, so I have
referenced only pre-UML books. Although the notation is different, many of the concepts are the
same, and it will be a while before these books should be relegated to the basement. Of course,
this book, like any book written within our industry, will be out of date as soon as it is
finished. To combat this, I'm making the inevitable use of the World Wide Web. To get my latest
thoughts on methods, take a look at the Web site for this book:
Putting out a
book this fast required a lot of help from people who went beyond the normal effort that goes
into producing a book to do everything that much more quickly. Kendall Scott played an important
role in pulling together all the material and working over the text and graphics. The three
amigos, Grady Booch, Ivar Jacobson, and Jim Rumbaugh, have been full of support and advice. We
have burned up many hours of transcontinental phone calls, and they have improved the book
greatly (as well as my understanding of the UML). A good slate of book reviewers is essential to
doing a good job on a book. Not only did these reviewers give me the feedback I needed, they also
turned around their comments in less than a week to keep to our tight deadlines. My thanks to:
Simmi Kochhar Bhargava of Netscape Communications Corporation, Eric Evans, Tom Hadfield of Evolve
Software, Inc., Ronald E. Jeffries, Joshua Kerievsky of Industrial Logic, Inc., Helen Klein of
University of Michigan, James Odell, and Vivek Salgar of Netscape Communications
Corporation. Double thanks to Tom Hadfield because he did it twice! I want to thank Jim Odell
for two things: first, for coordinating the Object Management Group (OMG) effort to get a single
standard UML, which will be a big step forward for our industry; and second, for encouraging me
to get into the object-oriented analysis and design field. Oh, and thanks for reviewing the book,
too! Thanks to Cindy for dealing with me being absent even when I was home. I can't even
imagine the difficulties that my editor, J. Carter Shanklin, and his assistant, Angela Buenning,
went through to get this book out as quickly as they did. Whatever these difficulties were, I'm
sure Carter and Angela deserve my thanks. Last, but not least, thanks to my parents for helping
me start off with a good education, from which all else springs.