Just about any developer these days who works in an object oriented language would do well to have at least cursory knowledge of the seemingly ubiquitous Unified Modeling Language (UML). If this acronym is not on your resume, then that is a hole you might want to fill. I say the UML is "seemingly ubiquitous" because if you go by what you see in software development magazines, books, conferences, and advertising, you'd probably come to the conclusion that everyone is using the UML and that you should be too. However, I see two recent indications that the perception of UML ubiquity may be faulty.
First, SD Times magazine recently published a survey conducted by it's sister company, BZ Research, which found, among other things, that "fully 62 percent of respondents said that they didn't use UML." Second, I did an informal study of my own today: I went to ComputerJobs.com (in my opinion, the only U.S.-based employment web site worth your time), and did a search of their national database using the phrase "UML." Out of 6,532 job listings, only 165 came up in my search. That's only 2.5%. Even if you allow for a huge margin of error by increasing that to 10% or even 20%, that's still far from even half of the available jobs out there that are explicitly seeking UML skills.
So if the UML is not a central part of the majority of the projects out there, then why did I start this review off recommending that developers make sure they know something about it, and why am I recommending this book, UML Distilled? First, I think the numbers above are somewhat misleading. I think that the UML is being used informally on a lot more projects than these surveys indicate, with designers and developers drawing UML diagrams on white boards and note pads. My guess is that many people do not consider themselves "using UML" unless they are using a tool, such as Microsoft Visio or Rational Rose, that is formally designed for modeling in the UML, and then using that tool to generate, or even reverse engineer, code.
In addition, if projects are not using UML modeling as part of a formal process, such as the RUP, that includes explicit provisions for analysis and design modeling then they may not indicate in a survey that they "use UML." The vocabulary of the UML is near universal even if formal usage of the notation is not. Furthermore, I think a lot of software development managers look for "UML" when they read resumes because, like code reviews, risk lists, and other perceived "best practices," these managers intend to start using the UML "real soon."
My second reason for suggesting developers learn the basics of the UML is that, without at least some basic knowledge of the conventions of the UML, a developer is going to be left out of the vast majority of important analysis, design, and architecture ideas to be found in contemporary software development books and magazines. Go to the bookstore and flip through some object oriented software design books and magazine articles, and you will find that even if the UML is not quite yet universal in the real world, in the world of ideas, it is indeed the lingua franca. And if you're not exposing yourself to the world of software development ideas, then your growth will always at best be limited by what you can learn from your immediate circumstances and surroundings.
So the next logical question is, who in the hell has time to learn a beast like the UML? Dan, have you seen the OMG's monstrous UML specification? Yes I have, and I didn't look too long. Hence, the beauty of Martin Fowler's UML Distilled. To quote Gregory Wilson's review blurb from the back cover of the book, "UML Distilled proves that you can say a lot of useful things about computing in a small book." Indeed it does. If all the software development books I read weighed in at 150 pages, then I could read a lot more of them.
Fowler succeeds here by only focusing on the important stuff. As a practitioner who uses the UML himself every day, he recognizes that so much of the detail to be found on the specification is background noise. If you were designing a UML modeling tool or trying to ensure that the UML covered every possible contingency, then all that detail would certainly be important. However, for most things, you just need the basics. UML Distilled covers the basics with Fowler's usual wit, eloquence, and economy of words.
Most of the chapters focus on one kind of diagram, starting with the most frequently used diagrams. The book covers all of the following diagram notations in enough detail to allow you to read other peoples diagrams, hold an intelligent conversation about them, and construct diagrams of your own: Use Cases, Class Diagrams, Sequence Diagrams, Collaboration Diagrams, Package Diagrams, State Diagrams, Activity Diagrams, Deployment Diagrams, and Component Diagrams. In addition, Fowler starts off with a chapter that describes a basic development process and wraps up with a chapter that follows a simple example project from diagramming to code.
A few other facts that further strengthen the book: The inside front and back covers contain examples of each diagram for quick reference. Also, each chapter contains references to more detailed information in other books if you want to explore more. Finally, the book is organized equally well to be read straight through and used as a reference.
I have nothing bad to say about this book. Hopefully Martin will be able to maintain what is great about it as he works on future editions. With the Object Management Group (OMG) hard at work on UML 2.0 and Model Driven Architecture (MDA), things are sure to get more complicated. For now, though, if you are currently working in (or working towards) the object oriented paradigm, then UML Distilled is essential.