 Two years ago, Addison-Wesley approached me to write a book about the then-new UML. At that time, there was a lot of interest in the UML, but only a standards document from which to learn about it. We broke many records to quickly produce a short introductory guide to the new UML, something that would provide some guidance until the more detailed and official books were to appear later that year.
We didn't expect this book to last after more detailed books
appeared. Most people believed that given the choice between a slim
overview and a detailed text, everyone would pick the detailed text.
Although that was the general view, I believed that even in the
presence of detailed books, there was still room for a concise summary.
Two
years later, my hopes have been realized more than I could have wished.
UML Distilled has been, in computer industry terms, a best-seller. Even
though good detailed books have appeared on the UML, the book still
sells well. Better than that, more slim books have appeared, confirming
my belief that in a world with so much information, there is value in
well-chosen brevity.
Now, that's all very well, but should you buy this book?
I'm
going to assume you've heard about the UML. It has become the standard
way to draw diagrams of object-oriented designs, and it has also spread
into non-OO fields. The major pre-UML methods have all died out. The
UML has arrived and is here to stay.
If you want to learn about
the UML, this book is one way to do it. The main reason for starting
with this book is that it's a small book. Buying a big book will give
you more information, but it will also take you longer to read. I've
selected the most important parts of the UML so that you don't have to.
With this book, you'll pick up the key elements of the notation and
what they mean. If you want to move further, you can move to a more
detailed book later.
If you want a longer tutorial to the UML, I
suggest the Unified Modeling Language User Guide (Booch, Rumbaugh, and
Jacobson 1999). The User Guide is able to cover a lot more ground. It's
well written and organized in a way that explains how to apply the UML
to various modeling problems.
Both this book and the User Guide
assume that you know something about OO development. Although many
people have told me that this book is a good introduction to objects, I
didn't write it with that in mind. If you're looking for an
introduction to objects with the UML, you should also consider Craig
Larman's book (Larman 1998).
Although the main point of this book
is the UML, I've also added material that complements the UML material.
The UML is a relatively small part of what you need to know to succeed
with objects, and I think that it's important to point out some of the
other things here.
The most important of these is software
process. The UML is designed to be independent of process. You can do
anything you like; all the UML does is say what your diagrams mean.
However, the diagrams don't make much sense without a process to give
them context. I also believe that process is important and that a good
process doesn't need to be complicated.
So, I've described a
lightweight outline process for OO software development. This provides
a context for the techniques and will help to get you going in using
objects.
The other topics include patterns, refactoring,
self-testing code, design by contract, and CRC cards. None of these are
part of the UML, yet they are valuable techniques that I use regularly.
 |
Subscribe to this comment's feed