Would you like to understand the most important elements of Class diagrams? (See page 35.)
Do you want to see the new UML 2.0 interaction frame notation for adding control flow to sequence diagrams (see page 58) and the unofficial notation that many prefer? (See page 60.)
Do you want to know what changes have been made to all versions of the UML? (See page 151.)
Do you want a quick reference to the most useful parts of the UML notation? (See the inside covers.)
Do you want to find out what diagram types were added to the UML 2.0 without wading through the spec? (See page 11.)
More than 300,000 developers have benefited from past editions of UML Distilled. This third edition is the best resource for quick, no-nonsense insights into understanding and using UML 2.0 and prior versions of the UML.
Some readers will want to quickly get up to speed with the UML 2.0 and learn the essentials of the UML. Others will use this book as a handy, quick reference to the most common parts of the UML. The author delivers on both of these promises in a short, concise, and focused presentation.
This book describes all the major UML diagram types, what they're used for, and the basic notation involved in creating and deciphering them. These diagrams include class, sequence, object, package, deployment, use case, state machine, activity, communication, composite structure, component, interaction overview, and timing diagrams. The examples are clear and the explanations cut to the fundamental design logic.
If you are like most developers, you don't have time to keep up with all the new innovations in software engineering. This new edition of Fowler's classic work gets you acquainted with some of the best thinking about efficient object-oriented software design using the UML--in a convenient format that will be essential to anyone who designs software professionally.
About the Author
Martin Fowler is an independent consultant who has applied objects to pressing business problems for more than a decade. He has consulted on systems in fields such as health care, financial trading, and corporate finance. His clients include Chrysler, Citibank, UK National Health Service, Andersen Consulting, and Netscape Communications. In addition, Fowler is a regular speaker on objects, the Unified Modeling Language, and patterns.
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.
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.
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.
There is really a sore need of a book that can teach UML modelling with a NO-[nonsense] kind of approach. Alas, the tendency is not this one... This book does take a more concrete and sensible approach to UML but is mostly superficial and when it goes into details it does so in a very confusing and inelegant way. I suspect the true reason of its popularity is that compared with other books on the subject this is at least a SHORT pain in the b. ;)
If you need to learn UML this is a great book. It is well written in that everything is concise and descriptive. Examples of what diagrams should have and look like are given throughout so with the help of some diagramming software anyone can produce UML diagrams. You might be disapointed though when you receive this book and see how small it is. Usually, when I pay $$ for a book, it is at least 4 times this size of this baby.