I originally bought a book on UML back in 1998 after someone downloaded a demo version of the Select CASE tool. I thought UML was really going to take off as it seemed to provide a comprehensive language for describing software systems. Fast forward 10 years and my experience hasn't changed radically since those first doodles – most other developers still don't seem to use any sort of modelling, either as a documentation or design tool. Consequently I have always struggled when putting together various diagrams as I've never know whether I'm doing it right: - too much detail or too little, aggregation or association, stereotype or parameterised type ...
UML distilled, for me, answers many of those questions. As Fowler describes right from the start, some people do use UML as a blueprint to guide construction, but he, along with many others only use it mostly for sketching. This sets the tone for the rest book as he focuses on those aspects of the language that provide the most bang-for-buck when using UML in this way. However at each juncture, should you want to know more, he points you in the direction of the necessary resources; in this way the book would also act as a good introduction to the material.
Whereas my previous book walked through the UML in a waterfall-esque fashion covering requirements then static structure through to deployment; Fowler guides you based on his use cases [pun intended]. This means he covers Class Diagrams first; in fact he discusses object, package and deployment diagrams before getting to Use Cases. Admittedly Deployment Diagrams do only get 2 pages, but they aren't exactly the most complicated topic to digest. When he does finally tackle Use Cases I found it reassuring to find him pointing out that the real value is in the Use Case text - the diagrams often provide little additional benefit.
State Machine and Activity Diagrams then get 10 or so pages each, with the latter getting extensive coverage because of its new lease of life in UML 2.0, and it has certainly piqued my interest due to its ability to illustrate parallel workflows. He then goes on to briefly cover the various other diagram types, such as the renamed Communication Diagrams (previously known as Collaboration Diagrams), Component Diagrams, Timing Diagrams etc. I was a little disappointed he didn't spend more time on Communication and Component Diagrams (he suggests that people generally prefer Sequence Diagrams to the former) as they both looked promising.
Although the book tips the scales at less than 200 pages, he still manages to cover the history of UML, a section on development methodologies, and an appendix to summarise the key changes from 1.0 through to 2.0.
