Rating: 
Summary: UML 2, but not as we know it!
Review: I disappointed by this, the third edition of UML Distilled. The first edition of this book was clearly rushed out to meet the release of the UML specification and so contained many inaccuracies. However, this is now the third edition and it still has many problems.
The biggest issue is that the author has too many non-standard diagrams. These are helpfully labelled "non-normative", and are an odd mix of UML 1, UML 2 and some other bits and pieces that the author likes. Now what is the point of this? These diagrams won't be supported by UML 1 tools, or by UML 2 tools, so how is one to draw them? Also, the non-normative diagrams do not have a metamodel or any well-defined semantics, so even if one were to build a tool to support their syntax, their semantics would still be open to debate.
The next issue is that many of the UML 2 diagrams are syntactically incorrect (e.g. the use of dependencies rather than connectors in composite structures). Perhaps this is because the author was writing the book while the UML 2 specification was still being developed. Personally, I would rather he had waited a bit rather than give us something only partially baked.
The discussion of UML syntax implies that UML as a visual language is much less powerful and complete than it actually is. For example the very brief discussion of sequence diagrams misses out most of their important new features. You don't learn about combined fragments, references, gates or parameters (although some of these are mentioned in passing). Yet these are the things that make UML 2 sequence diagrams so much more powerful and useable than they were in UML 1. In fact, the sequence diagrams in this book look like they have been translated directly from UML 1 sequence diagrams without applying any of the new features.
The discussion of UML semantics is generally disappointing. UML 2 has tied UML semantics down very tightly - it has had to do this because of MDA. However, in this book you get the impression that much of it is still quite vague and open to interpretation - hence the "non-normative" diagrams.
On the whole, the level of detail is, in many cases, too low to be useful even in a "distilled presentation". For example, you get 2 pages on interaction overview diagrams, and in this you lean that the author hasn't really worked out how to use them effectively and doesn't really care for them anyway. Yet these diagrams are important. They give us, for the first time, the ability to string together isolated interactions into workflows in a precise way.
On the whole, I can't recommend this book. Try "UML 2 for Dummies" instead.
Rating: 
Summary: Much Improved 3rd Edition
Review: Previous editions of this book were very useful but contained some obvious flaws. The 1st edition was hastily put together when UML was new and the 2nd edition was a relatively minor update to keep up with changes to the UML Standard. This 3rd edition is a major overhaul of the book and is a significant improvement. Lot's of new material has been added to bring the book up-to-date with UML 2.0. Most of the chapters have been rewritten and reorganized into a more useful sequence. The rewrite benefits from Martin Fowler's recent experience teaching classes on UML. I'm glad to see that chapter 11 "UML and Programming" in the 2nd edition has been removed. It was the least useful part of the book and the space has been better utilized in the 3rd edition by focusing on more specifically on UML and the added material for UML 2.0. This book is worth the price to "upgrade" from previous editions.
Rating:
Summary: an excellent handy reference
Review: There are hundrends if not thousands of articles and tutorials floating around on the net which are written on or around or about UML, some try to cover everything in a shallow manner, some try going deep into a very specialized aspect of one kind of diagrams. As a software architect, people like me need something concise and handy which we can constantly refer to which chalking out different diagrams which are required in software project following RUP methodology, this book serves this purpose in an excellent manner and I am certainly happy using it for the last couple of projects I handled.One thing I must say is that I found the coverage of 'Development Process' (Ch 2) very sketchy and superficial, and most probably it does not even belong in a book so focussed in being used as a reference for a software project. There is only one more thing which I expected from this book. Different UML diagrams are sketched and used in different stages of a project, if only these were overlapped with RUP project phases (inception, elaboration, construction and transition) along with a representative of other documents used in those phases the use of the UML diagrams could have been realized from a better perspective. I would highly recommend the book 'Building J2EE Applications with RUP' (Peter Eeles, Kelli Houston and Wojtek Kozaczynski) for the J2EE practitioners, these two books complement each other very well in the J2EE/RUP world.
Rating:
Summary: An excellent and classic book
Review: First of all, please let me confess that I happen to be a fan of Martin Fowler's writing style. I feel he has an uncanny ability to get things over to his readers. But this book is more than style. It follows an approach based on Pareto's 80/20 principle (which in the present instance translates into what would have been a statement like "there is 20% of UML syntax that you will need 80% of time and this is what I am going to teach you.") Following that tenet, this thin book (fewer than 200 pages) succeeds in its goal of being a very good distillation of the basics of UML, and thus an excellent introductory book to this graphical notational language. Since this is an introductory book, a good thing about it is that it provides ample references to other publications for those inclined or required to delve in more depth into specific aspects of UML and OO analysis and design. There is a tendency to prescribe books from Addison-Wesley's Object Technology Series (part of which this book is), but I guess that is something to be expected. Actually, the book, despite its small size, is not strictly constrained to UML per se. In its introductory chapter, it discusses the broader issue of OO analysis and design, where it succeeds in providing some background to the uninitiated, as well as providing the necessary context for UML, which without OO is like a fish out of the water. In the next chapter Fowler moves on to discuss process (RUP) - where RUP, of course, is not necessarily confined to the OO realm - stressing however that "the UML is independent of process" (p. 14). Within this discussion he offers some sidebar discussions of related issues such as Self-Testing Software, Refactoring (one of his favorite subjects), and Patterns. In Chapter 3, Fowler moves on to discuss Use Cases (again something not necessarily, albeit customarily, related to UML, or object orientation for that matter... - you may be wondering when he is going to discuss UML after all :-), pointing to Cockburn's work for a more comprehensive discussion of the issue. So, with Chapter 4, finally, starts the presentation of the UML. This is a short-'n-sweet (and to-the-point) discussion, covering the whole gamut: Class Diagrams (Essentials and Advanced Concepts), Interaction Diagrams, Packages and Collaborations, Statechart Diagrams, Activity Diagrams, and Physical Diagrams. The whole discussion of UML per se comprises 7 chapters and just 96 pages! However, I have never found myself in the need to use something in the "field" that is not contained in those 96 pages. It is all about distillation here, for the busy professional, who does not have the time to go through tomes of UML reference and specification documents. The ultimate chapter attempts to illustrate the process of mapping the UML artifacts into Java code, using an example from the Health Care business domain. I would not say that this is my favorite chapter of the book; however your mileage may vary. All in all, this is highly recommended book, if you are just embarking into this wonderful field... It will help you quickly get up and running. Also, if you have already been doing UML stuff without the assistance of some publication, based solely on free online material, the book will help consolidate and reinforce your present knowledge.
Rating: 
Summary: Really good, concise intro to UML
Review: This small book is a great introduction to UML, with real-world applications. It's concise and easy to understand for the novice (me). It probably shouldn't be a book for advanced UML architects. The tone of the book is nice, connecting the abstract concepts of UML modeling to practical situations. Unlike some other UML books, this one avoids the "religous" indocrination -- the idea that you MUST do UML a certain way, or adhere to 101% of the standard. Instead, the author shows examples of how you can be more productive by relaxing a little and applying only as much rigor as necessary. Highly recommended to anyone who wants to augment their skills as a system architect, and prepare sophisticated plans for implementing an object-oriented application.
Rating: 
Summary: another poor author
Review: To somebody who knows OOP, UML can be explained in under 30 minutes. It is simple, OOP is not. OOD starts in the head of an OOP programmer. Patterns help! I heavily recommend Sams "Teach Yourself UML in 24 hours"
ISBN 0672322382 Make up your own mind by looking at the books locally first. Whoever wrote the Schaum's Outline on UML also engages in doubletalk that is convoluted and based on something in the head of the author. Too bad Stephen Prata, Stephen Kochan, Ivor Horton or Bruce Eckel didn't write on patterns or UML! So many books by Booch, Fowler and Larman are heavily padded...full of repetitious sentences that tell me nothing! A professor at a local university said "I read Booch's 1992 book on OOA 3 times and asked myself what I learned...nothing" Those are my words exactly! When I was in Junior High, there was a teacher whose punishment for chewing gum was to write a 10 page essay on the benefits of chewing gum. I'll tell you I never chewed gum. Can you imagine how much you have to pad the writing to get 10 pages. Concerning a recent Booch book, I emailed Grady Booch to ask where the black diamond (in an early chapter) was defined. A month later, back came "chapter 16". Good thing I already knew about aggregation and composites. These people just can't write. Why are there so many fans of these books?
There is honor amongst thieves, elitists and groupies!
Rating:
Summary: Introduction to UML
Review: Best introduction in UML. Easy and complete (for almost 99% of UML you ever use). Buy it!
Rating:
Summary: A Good Distillation and Reference
Review: I read the 1st edition of the book several years ago and this 2nd edition just recently. This book is a very good summary of the most commonly used UML diagrams and notation. It's a handy refresher for those who have already studied UML in detail and need a quick, practical reference. It may also work for those who are unfamiliar with UML, but need a quick primer on how to read UML diagrams. It's much less effective as a tutorial for using UML. The writing is clear and concise. Chapter 2 is a good summary of the development process, touching the high points and offering some useful tips. (The author recommends Craig Larman's book "Applying UML and Patterns" for a more in-depth introduction to Unified Process. I agree with that recommendation.) Chapters 3 - 10 (which cover the diagrams and notation) are the most useful. Chapter 11 "UML and Programming", is not very effective in trying to bridge UML work to programming. It either needs more detail, or should have been omitted entirely. Its primary accomplishment seems to be the author's facetious intention to "get Java into this book somehow" (p. 148).
Rating:
Summary: less than inspiring
Review: This book was less than inspiring but had some useful ideas. The following paragraphs briefly document these ideas. A class diagram describes the various classes in the system and their static interrelationships. There are three perspectives in drawing class diagrams: 1) conceptual, 2) specification, and 3) implementation. A conceptual view looks only at the classes and their interactions with other classes (class responsibilities) with no regard to the underlying software. A specification does look at the underlying software but only at the interfaces of the classes and not their implementation. The implementation view looks not only at the interfaces of the classes but also at the underlying implementation. The two principle kinds of relationships are: 1) associations, and 2) sub-types. Class attributes describe the way data get stored in classes. Operations are the processes carried out by a class; there may be several ways (methods) of carrying out the same operation (through polymorphism). Interaction diagrams help describe the interaction of objects within a single use case. There are three different ways to describe the interaction between objects: 1) sequence diagram, 2) collaboration diagram, 3) CRC (class-responsibility-collaboration) cards. State diagrams help describe the behavior of a single object across several use cases. Activity diagrams (or flow charts) help understand the workflow of a business process. Packages are collections of classes with interdependencies. A package diagram is like a class diagram with packages instead of classes. A system's overall structure can be described by a package diagram. If this synopsis is insufficient but has aroused your interest in this book, buy it; otherwise buy some other UML book with more substance.
Rating:
Summary: For me, this was all I needed to get up to speed with UML
Review: As a developer trying to improve my coding skills I was looking for a quick overview of UML to get me up to speed with it so I could apply simple modelling to my software projects. This book was all I needed to do just that. Thus, it lives up to its name, as it says in the title it is a "brief" guide to UML. For most people, I think it is all they'll ever need to know about it. If you are a Software Architect on the other hand, you'll probably want to pick up some other titles as well. Either way, this is where everyone should start.
| 
