First thing first, the third edition of this book is still not available in India. This review of mine's is based on its second edition. Let me first state the expectations I had from this book. It is the certification thing again which prompted me to go for this book. In the OOAD+J2EE+UML space, I feel the best certification to give,in terms of objectives, is the "IBM 486: Object-Oriented Analysis and Design with UML test" exam. Given IBM prescribes this one and the Craig Larman's book 'Applying UML and Patterns' towards preparing for the exam, one doesn't really have any other option but to read this book.
I have been working in the OOAD+J2EE+UML space for the last 3 years in the capacity of an Architect. Before this, though I have read few books on OOAD and Patterns, I hadn't read any book written exclusively on UML. In the large project I was part of, we used Use case diagrams, Sequence diagrams, Class diagrams and on certain rare occasions Activity diagrams.
You repeatedly come across comments such as concise, a very brief introduction, quick reference, compressed, direct in the reviews of this book. Frankly, it is all that. Let me give you chapter-wise impressions book before presenting my summary.
Chapter1: This chapter gives a decent introduction to UML, a reasonable tracing of its history and places UML in right perspective.
Chapter2: My favorite. Gives a classic snapshot of RUP. I infact used some of the lines for a presentation I had to do on RUP to my managers!!
Chapter 3: You get a very brief overview on Use Cases. It was nice to know certain esoteric features related to Use Case relationships. Watch out for the short 'n sweet synopsis on the differences between BUCs and SUCs.
Chapter 4: The author introduces you to the three perspectives while drawing class diagrams: Conceptual, Specification and Implementation. I seriously doubt whether we can engage our users into drawing conceptual diagrams!! Specification Modeling is what we do during the design phase. The sub-sections on Associations, Attributes, Operations, Generalization and Constraint rules are extremely well written. Though the side-bar on Design by Contract comes out a little sketchy.
Chapter 5: I doubt whether I'll ever use collaboration diagrams given the bias I have for sequence diagrams. The wealth of information that comes out of analyzing the sequence diagrams produced by designers is simply amazing.
Chapter 6: I found the sub-sections on Stereotypes, Object diagram, derived association and attribute, interface and abstract class, qualified association, association class, parameterized class, visibility to be too brief. But I found the sub-sections on reference and value object, Multiple and Dynamic Classification, aggregation and composition to be immensely useful and it brought out the wealth of experience the author possesses in no uncertain terms. I might have to re-read these sub-sections many times to get the essence.
Chapter 7: This chapter totally disappointed me. My personal opinion is, Robert C. Martin's papers on packaging are far more superior to what Martin Fowler has dished out on packaging in this chapter.
Chapter 8: The usage of state diagrams is very limited given that it traces the behavior of a single object across multiple use cases and should be used only with objects showing very interesting behavior. The author's treatment of State diagrams is competent.
Chapter 9: This chapter on Activity diagram is brilliantly handled by the author. Though the author confines the usage of activity diagrams to the construction phase, I find them increasingly getting used during the elaboration phase as well.
Chapter 10: I have a very low estimate of Physical diagrams and wouldn't want to comment upon this chapter.
Chapter 11: This chapter left me with mixed feelings. I found it to be good in that it takes you through different class diagram perspectives using the patient observation system. It is bad in that the solution is way too twisted that it leaves in you splits.
Let me summarize in parts:
What I liked: It delivers what it proclaims and I don't have any qualms against it being short, concise and compressed. I liked the informal+ direct + to-the-point style of the author and his 'me-myself' tone.
What I didn't like: It can easily give one a false notion of having mastered the subject when the reality might be far from that. It is not a book reading upon which you can set about your UML related tasks with ease. At best, it is a good reference book. It glosses over too many important subjects. At places, I find him not making a definitive statement when one is actually expecting one from him. Discussion on topics such as Design by Contract, CRC, Refactoring on which exclusive books are written come out thin and a trifle out of place.