Rating: 
Summary: A superb job of distillation
Review: If you start your study of the Unified Modeling Language(UML) by going to the definitive references by the three creators, it is quite likely that you will be intimidated. The three books, _The Unified Modeling Language User Guide_, _The Unified Modeling Language Reference Manual_ and _The Unified Software Development Process_, all written by the designers and published by Addison-Wesley, are nearly 1500 pages of rather intense material. Like a veteran horseman, Martin Fowler charges to the rescue.
In a "mere" 174 pages, he takes each of the essential main areas of the UML and presents a brief, yet surprisingly thorough description of what it is and how it is used. While targeted at the UML novice, it is necessary to have a fairly solid background in object-oriented programming in order to understand it. Since the UML is a modeling language based heavily on diagrams, they are used throughout the book and are very effective.
This book will not teach you the UML, that task is left to weightier works. However, it will provide the proper foundation so that you can learn it, a task that is just as important. I listed the first edition as one of the best books of the year in my "On Books" column that appeared in the September, 1998 issue of _Journal of Object-Oriented Programming_ . There is nothing in the second edition that will change that opinion.
Rating:
Summary: All the UML the average person needs
Review: More books should be like "UML Distilled:" concise and readable. Martin Fowler and Kendall Scott select the parts of UML that you need, and present them in an easy to read style. More valuable than a mere description of the modeling language, however, is the author's insight and experience in how to use this technique to communicate and document design. Quite simply, UML is the technique that developers use to communicate their object-oriented software design and planning. A picture is worth a thousand words, and UML makes sure that everybody can read your paintings. If you're not familiar with object-oriented programming, then you may want to start here. Chapters 1 and 2 give a brief history of UML, and a quick overview of a generic software process, touching on techniques such as agile methodologies, refactoring, patterns, and test. Chapters 3 through 5 get started on UML with use cases, class diagrams, and interaction diagrams. Throughout, Fowler gives details on how and when he uses these -- and more importantly, when he doesn't. Despite the conversational tone, this book is designed as a reference. The authors go so far as to tell you to skip chapter six until you need it. Such helpful pointers are a godsend to mere mortals trying to accomplish something. This chapter focuses on more advanced elements within object diagrams, probably the most heavily used diagram type. Chapter 7 focuses on packages, which are used to describe high level relationships within the system. Again, Fowler's advice is welcome on how to best use these diagrams in the real world. Chapter 8 examines the state diagrams, providing a standard way to use and document these designs. Chapter 9 centers on activity diagrams, which standardize and update traditional flow charts. He touches on deployment and component diagrams, but wisely leaves the details to others. There are lots of books on UML. Unfortunately, most are unapproachable due to their didactic tone, detail, and sheer volume. "UML Distilled," on the other hand, focuses on key knowledge, conversational tone, and brevity to emphasize the day to day use of UML. Many people simply will never need another book on UML.
Rating: 
Summary: A Terrible Guide - Even if a "Brief Guide"
Review: This book is a terrible guide to UML. The authors constantly give their opinions on components of UML and fail to define or illustrate the components clearly or accurately. Irrelevant metaphors and "jibber-jabber" are constantly used throughout every chapter. The further the book goes into UML and the more complex the subject becomes - the more vague and misleading the book becomes. I would not recommend this book to anyone attempting to learn or use UML. Whether this book is assuming that the reader knows UML or not, it would be incomplete for both types of readers.
Rating:
Summary: Excellent introduction to UML
Review: I highly recommend this book to anyone who is interested in learning the UML. It is by no means a complete coverage, and should not be the only book on your reading list, but should be the first. Fowler does an excellent job of presenting the big picture of the UML and how it is applied in the real world. I found his use of his own experiences applying the UML to customer problems very helpful. The book itself is very well written, with clear examples of the topics being described. The strongest trait of this book is its ability to quickly (the book is less that 200 pages) give the reader a basic working knowledge of the UML. If you are an engineer looking to learn the UML, start with this book to get a high level view of the UML, then move on to a more in-depth book. If you are a project manager, this is a great tool for you to have a working understanding of what your design team is doing with the UML.
Rating:
Summary: An Informative and Satisfying Guide to UML in OO Design
Review: This is an informative and satisfying guide to using UML in object oriented development. In relatively few pages the most commonly used aspects of the standard modeling language are presented, explained, and illustrated. A developer already familiar with an object oriented language could make good use of this book as their first introduction to UML. For those without any grounding in object orientation I think Sams Teach Yourself UML in 24 Hours or Fundamentals of Object-Oriented Design in UML are better places to start. The thing I liked the most about this book was the practical advice for moving an object oriented project through to completion. As asides to the explanations of UML syntax and form, the authors dropped in tidbits of advice... "Don't try to do software that exactly maps the conceptual perspective. Try, instead, to be faithful to the spirit of conceptual perspective but still realistic considering the tools you are using" (p. 150). This was said in the context of one of the longer chapters in the book, UML and Programming, where the reader is walked through a demonstration of using UML to conceptualize a patient information system for a hospital and then walked through the choices that might be made to implement it in Java. The authors work with a sample where an ideal solution is out of reach and illustrate instead a pragmatic choice that works. This kind of thing is done over and over again in the book. Martin Fowler also refers the reader to his website where he extends this demonstration into greater complexities than the book covered. Since this book is so brief it would be a great choice for an entire team to read together to get everyone on the same page for a project.
Rating: 
Summary: Good introduction
Review: Fowler has done a very good job of introducing UML - this is the book I recommend to beginners. He goes over all the main categories of UML diagrams showing what they mean and usually how they relate to actual code. This is, by intent, a very brief book about a very large topic. Part of its value is in giving the quick tour without dragging the reader through the thousands of pages of OMG specifications. That means a lack of rigor, reinforced by the informal writing style - all very approriate to an introduction. The UML can be intimidating in its mass and in the level of detail it prescribes. Fowler cuts through all that very well. Best of all, he keeps a slightly skeptical tone. The UML is a tool, meant to serve the developer. It is not intended to take over the development process, so don't let it. There are just two things I wish this book decribed better. First is the unification problem. The UML offers dozen or so different representations of different aspects of a program's structure and behavior. The question is, how do I get all those representations to relate to each other so it's clear that they describe the same thing? The complete answer may be too long for this book, but this isn't a book about complete answers. A few more clues would have strengthened the discussion. Second is the discussion of state diagrams. It's a concept that beginners seem to stumble over: what do states really model? The best answer I know is that it describes situations where one input elicits different responses at different times, in different operating modes. The number keys on an ATM keypad are an example: first they represent the PIN, then they choose the banking operation to perform, then they may represent the numeric dollar amount of a transaction. Fowler just says to use state diagrams for "interesting behavior." It's a good intro to UML with a good (though aging) bibliography. It should not be your only book on UML, but never meant to be. Beginners get a gentle start to a tough topic. Seasoned users can jog their memories on fine points of notations they haven't used in a while. This book really is for everyone.
Rating:
Summary: : Good introductory book that covers the basics well
Review: A good mixture of UML, new additions to UML and how UML integrates into software processes. The topics are at a high level and only get skin deep, so this book is good for practically anyone interested in UML: developers needing to know the new additions to UML, managers with little time that want to learn UML to be able to talk to their developers, and even marketing staff wanting to communicate the needs of their customers with the engineers and product managers. Martin Fowler has done it again with the third edition of the UML Distilled book. Informative, well organized, quick read and more importantly an easy read. He starts with a background on UML and where it came from, and where it is currently heading. He continues with the introduction with going over what a software process is and why it's needed. The importance and the benefits of how UML can assist the software process during all the phases of the process sets the stage for UML throughout the rest of the book. If you are unfamiliar with software processes such as the Rational Unified Process, Fowler's introduction goes a long way and clear things up. "... the creators of the UML see the [UML] diagrams as a secondary; the essence of the UML is the meta model. Diagrams are simply a presentation of the meta-model." Probably the best explanation of UML you can find anywhere. Folwer, from the get go tries to set the stage straight and clear up some of the misconceptions that UML. At the beginning, he focuses on the fact that UML is not the solution to everything a development team faces during a project, but rather a starting point, and "you shouldn't hesitate to use a non-UML diagram if no UML diagram suits your purpose." Starting with the basics of UML, such as class diagrams and sequence diagrams, Fowler delves into the basics of UML and mainly the critical components on UML 1.0. A very controversial topic in UML and mainly the class diagrams are the notion of Aggregation and Composition. Aggregation being the part-of relationship and composition being an object with only one owner are depicted well thru a number of examples. For simplicity, Fowler suggests the aggregation be entirely dropped from diagrams.
Associations versus class Properties are another unclear point that is covered well. If you have been working with UML for a while, you have certainly realized that anything that can be presented via Associations can also be presented via the use of Properties. This point of ambiguity could mean the difference between a clean and clear class diagram and a clotted diagram that looks like a web of coupled classes. The author clears the point between the two notions up by specifying a rule of thumb: use attributes for small things such as dates and Boolean types, and use associations between large object types with clear dependencies between the objects. This rule can certainly help when you are trying to do round-trip-engineering, and your reversed engineered class diagram is totally not what you were expecting! Has that ever happened to you?
Object Diagrams, Use Cases, State Machines and Activity diagrams mark some of the UML tools that have been around since the earlier versions of UML.
Composite Structures, Interaction Overview and Timing Diagrams are new to the UML 2.0. Composite Structures enable the internal structure of a class to be decomposed. It clearly defines and marks what the interfaces are, and what the required external interfaces are for each of the interfaces shown. Interaction Overview diagrams graft together activity diagrams and sequence diagrams. The author does however mention that he has no interest in using the Interaction Overview diagram due to the fact that they are too busy. I agree!
Overall, Martin Fowler's UML Distilled book provides a clear, concise and brief but sweet introduction to UML. Each topic is short and gets to the point. Main pitfall of UML are explained well, and the reader upon reading this book can "speak" the UML language.
Rating:
Summary: exactly what I wanted
Review: Now this is what I am talking about. It really follows the 20-80 rule. I am sick and tired of reading books which start from the basics as if I am a complete idiot and then form the story in a roundabout manner. You can always get the basics of anything from the internet for free, and as engineers, as most of us are, I presume, we can pick up any new technology fast. So what we need is this kind of books. The author has done a great job. He shows us the 20 percent of what we will use for 80 percent of the time. Only suggestion: give and illustrate more examples.
Rating:
Summary: drive-by publishing is full of errors and misinformation
Review: As one other reviewed noted, it's understandable that the first edition was rushed, but it's not acceptable that the 3rd edition is still so full of errors. The only reason I bought the 3rd edition was because I thought that it would be better than the 2nd, but it is not much better. The author's informal style glosses over the numerous errors in the book. This is not standard UML (1 or 2). Often the most important concepts of UML are shown in only a single diagram and discussed very briefly, while the author's pet peeves and non-standard adaptations of UML are elaborated for pages. There are several outright errors. E.g., just try to find figure 5.1, it is not there! This book seems to be part of an effort to cast UML as being defined by celebraties, specifically Fowler, Booch, Jacobson, Rumbaugh, and some of the XP advocates. Repeatedly, individual preferences are shown to superceed the standard. UML is not a cult of personality, it *is* a standard notation. The whole point of UML is to have one notation that students, professionals, and tool vendors can agree on.
Rating:
Summary: A Terrible Guide - Even if a "Brief Guide"
Review: This book is a terrible guide to UML. The authors constantly give their opinions on components of UML and fail to define or illustrate the components clearly or accurately. Irrelevant metaphors and "jibber-jabber" are constantly used throughout every chapter. The further the book goes into UML and the more complex the subject becomes - the more vague and misleading the book becomes. I would not recommend this book to anyone attempting to learn or use UML. Whether this book is assuming that the reader knows UML or not, it would be incomplete for both types of readers.
| 
