Applying UML & Patterns 3rd Edition by Craig Larman

Rating: Too many words. Too little essence. Messy. Academic.

This 700 page book could be easily re-edited to fit 400 pages or less. There are very few original ideas here. There is a lot of repetition, obvious statements, outside of topic statements, defensive statements, and meta-content. There was one bit of wee humor in the first 240 pages, but I did not write it down immediately, and now I cannot find it. :-(

This book looks like an attempt at jumping on the agile development bandwagon, by someone who preached for ages a complex, UML and roles driven, approach to software development, and now is very apologetic about it.

Chapter 22 tells us that UML is used as a sketch, as a blueprint, and very rarely as a programming language.
Chapter 22 contains also this breaking piece of news: '''developers consistently report that UML tools seem to "get in the way" more than help''' - page 396.

The CUPPS standard defines "log in" and "log on" as 2 different operations. In the same fashion this book on page 594 defines "fault", "error", and "failure" as 3 different terms. Which normal person is going to remember what is what?

UML Distilled by Martin Fowler et all

Rating: Concise. Worth returning to.

Finally, there is a book about UML written by a practitioner for practitioners. It even has code samples that make sense. Nice.

The only complaint I have at the moment is the amount of forewords and prefaces: 10 pages for a book that has 159 pages of content.

All right, so what did I get out of this book?

1. Use '''UML as sketch''' to help communicate design ideas.
2. Everything in UML is optional, so when reading a diagram do no make assumptions based on something not being present.
3. It is ok to use non-standard notations, if they are better known, or simpler - be pragmatic - the goal is for your audience to understand your design.
4. There are also useful, non-UML diagrams, like the screen flow diagram, and the decision table.
5. It is very difficult to get UML right before coding, therefore using UML as blueprint in forward engineering may not be efficient.

This book should be read twice and should be kept around for reference.