This is a good book to have as a reference and to get an introductory understanding into UML. Many engineers at the company that I work at have this book and also at previous companies that I've worked at.

I do well appreciate how those who believe the earth is flat must feel. I believe the people have lost their senses in their enduring alacrity over the aptly-acronymned OOPS. I have read a number of books on OOPS and worked with OOPS languages, and I continue to believe it is nonsense. The gullibility of my fellow humans has most surprised me.

1/3 of OOPS is logically without foundation: "Everything is an object", the notion that object-oriented procedural systems suffice for reuse, and the notion that object-oriented procedural systems are necessary for reuse, for example. The remaining 2/3 is just old ideas, such as various diagrams, modularity, and control over others, parading in new lingo.

For all their talk of reuse, the champions of OOPS are the ones who sought to discard previously existing software and to rewrite the entire corpus in the style of OOPS. OOPS developers have brought error messages to new levels of incomprehensibility. OOPS is an obstructionist vanity that continues to impede more than it helps systems development and maintenance.

This book contains almost everything you have to know about UML. It's best quality is that it's a very short book and very easy to read.

This book is what i call, lets get Down and dirty. Its a quick and dirty way of learning UML. for practical purposes this book is highly useful, I would recommend it to anyone who wants to learn UML and start out his way...


Anirudh vyas

This book was so disappointing and all over the place. It is clearly written for those that are strictly into programming and coding and have prior knowledge and understanding of object modeling. Even the diagramming was not for the beginner analyst. It's written more in theory than practical information even to get you started in defining UML and what it really is.

It would have been much more informative if author would have stated up front that you have to have basic knowledge of Object Modeling and all the terminology that is defined. Next, define UML as a set of DIAGRAMS. Nothing more and nothing less! Spend the time on the details of the diagrams and how to read them versus jumping all over the place talking in theory about sketching versus blueprinting, etc. Every area seems to be lacking details in terms of what it means in layman's terms. For example, with sequence diagrams, what does it mean to look at the behavior of several objects within a single use case? Don't go off talking about the next diagram and never addressing the sequence diagrams and objects in a Use case. Provide a Use Case and a Sequence Diagram and then explain it in terms of behavior and objects. A good analyst, whether system and/or business, thinks in terms of user functions, actions and what is expected of the system.

The books also defined terms using the term which really made it confusing. I never did figure out how to define a meta-model or how it even looks.

Is UML really a programming language starting with the diagramming approach? Should the developer be able to develop activity diagrams from use cases written by the analyst? Should be analyst be looking to develop all the diagrams and have the knowledge of Object Modeling which is really UML? A lot of questions that couldn't be addressed with this book.


Definitely not worth the price!

This book provides some brief but good background to set the context then proceeds to succinctly communicate those aspects of UML one really needs to know.

I have had the second edition of this book, but obtained the third edition also. The most important differences I found in the third edition were the fancier cover and the compliance with version 2.0 of the OMG UML standard. Really suitable for the working professional this book is very useful as a first encounter with the UML standard. It is also a very useful reference later when one wants to return to a particular topic. The examples are really basic and for really deep coverage of the topics other texts may be more suitable, but that is also an advantage since the book is striving to be a concise introductory text. I believe that is why the book is so popular. Programmers are busy with so many other things and many have no time to spend with a very comrehensive text. Highly recommended for any new UML user.

The subject of Object-Oriented Analysis and Design is vast. This book can be thought of as a distilled dispenser of Unified Modeling Language (UML). I interviewed Martin Fowler for an article in CoDe Magazine. Mr. Fowler's credentials are impressive: A regular speaker at object technology conferences including OOPSLA, Software Development, and ECOOP. Fowler is also the author of the Analysis Patterns, Refactoring, and Planning Extreme Programming. In this book, Fowler presents a brief overview of UML and does it quite well.

As an introductory guide this book is not intended to cover the expansive subject of OOD, but rather is a map of the territory ahead. The author presents an overview of UML in seven separate categories. The categories are then divided by chapter: Use Cases, Interaction Diagrams, Class Diagrams, Packages and Collaborations, State Diagrams, Activity Diagrams, and Physical Diagrams. As a bonus at the end of each chapter the author provides a list of recommended readings to further explore the subject.

The characteristic of UML Distilled that stood out most clearly is the author's ability to translate real-world experience into clear concepts. A good example is Chapter 9, "Activity Diagrams", probably the least understood areas of UML. The activity diagram "describes the sequencing of activities for both conditional and parallel behavior." The activity diagram is considered by some to be not object-oriented. However, Fowler shows the advantages of using this type of diagram and provides guidelines for when to use and when not to use it.

The best technical books are interspersed with sprinklings of the author's experience among the formal industry documentation. When an author has lived the topic, the book increases in worth. This book scores high on that account. Fowler delivers all the essentials from the ground up in very clear and concise language. Reading this book is both a pleasurable and valuable learning experience.

[A review of the 3rd Edition.]

Fowler explains the latest UML 2.0 with his usual eloquence. One virtue of the book is its brevity. An important point made by this is that UML 2 can be quickly and easily grasped. No need, at least for most users, to know all the ins and outs of it.

You might think of this book as analogous to RISC computing. Where there is a minimal instruction set in hardware. Likewise, Fowler attempts to dispel any mystique about the UML notation and usage.

After Grady Booch, James Rumbaugh, Stephen Mellor and GOF, Martin Fowler is pretty much one of the fore-fathers of Object Oriented design and analysis. He is one of the initial torch bearers of the discipline we know as refactoring. Martin Fowler is the author of several renowned books on analysis and design namely "Patterns of Enterprise Application Architecture", "Refactoring: Improving the Design of Existing Code", "Planning Extreme Programming" and "Analysis Patterns: Reusable Object Models"

I have been using "UML Distilled: A Brief Guide to the Standard Object Modeling Language" for some time now and the best thing I like about this 170 page guide is its simplicity. This books well written, practical and goes straight to the point. This does not mean that it lacks in theoretical aspect of UML but it's not intended towards "fluff" when all you need is a bare minimum to get the job done. UML, as we know is standard for modeling software artifacts. Using UML software developers and architects can make a blueprint of a project like entity relationship diagrams for relational design and server queue diagrams for discrete event simulation.

Martin does an excellent job in explaining how to specify, visualize, construct, and document the artifacts of software systems by using UML. The practical guidelines help simplifying the complex process of software design by using pseudo codes and their corresponding UML designs. The back cover has some interesting prospect to look at book for instance

Would you like to understand the most important elements of class diagrams (see page 35)

Do you want to find out what diagram types were added to the UML 2.0 without wading through the spec? (see page 11)

I usually say that if you can read only one book on OO modeling and design from a developer's prospect, go with David Parsons. If you can only read one book on how to think OO, "Object Thinking" is the way to go. Now I'll add to it that if you can read only one book on how to do OO design with UML modeling, make "UML Distilled: A Brief Guide to the Standard Object Modeling Language" your first choice.

The author does an excellent job in his purpose: teach software engineers how to effectively communicate ideas about software structure and behavior via UML diagrams.

This book is intended for software professionals who already have some exposure to object-oriented programming and software development. It's also for practical software engineers and not academic oriented computer scientists.

This book is not intended to teach you programming, object-oriented methodologies, or software development. It is not intended for software engineers who want to use UML as source code (due to the book's brevity).

All code examples are in Java or C#.

This book would be fine if it were the only UML book on the planet. But there are several much, much better UML books out there. This was a poor effort that appears as if it were hastily prepared. There is as much information about Fowler's favorite ways to write incorrect UML as there is about how to write correct UML. At least the difference is fairly well labeled.

Beginners may find it hard to distinguish between what is normative and what is Fowler's way. Experts should know well enough to buy a more comprehensive book.

This book is harder to digest than the Silmarillion. I received it in school along with some fellow students and we unanimously agreed that it was tripe. Perhaps a very experienced software engineer would be able to benefit from it but at the junior level we were at when we received it we found it magnificently boring. I think I tried reading it about three times and never got past page four. It's both boring beyond comprehension and confusing beyond comprehension. The only thing I comprehended about it was that it was the worst book I've ever attempted to read. Ever. If you are not particularly versed in modeling software systems and are looking for an introduction to it, such as UML, do not buy this book. Consider this a warning.

Fowler is one of my favorite writers. This book is a great book that is a must on the bookshelf of any serious developers. However, in spite of its power, which you can read in other reviews, it has some minor problems/mistakes.
Fowler, in this book, reminds me of a good instructor who starts a course very well, but at the end of the semester he just wants to finish all the topics carelessly.
The first eleven chapters are great and very well done, but the problem starts at chapter twelve, specifically when he tries to explain the "Composite Structure Diagram" and the usage of Ball-and-Socket notation in Component Diagram. He fails to do the job, however later on in his blog he tries to justify some of his mistakes. you can find the discussion under Ball-And-Socket post.

Another minor mistake is on page 89, when he confuses the concept of the namespace in .Net. I have seen that most of the people with Java background are confusing the "namespace" concept in .Net with "package" in java. Namespaces in .Net have nothing to do with access modifiers. I believe the more equivalent of packages in java are assemblies in .Net and for the Package diagram in UML one should consider an assembly as an equivalent to a package in the diagram.

The first two editions of the book were very successful, and after releasing the UML 2.0 a new edition, which covers the new elements in UML 2.0, was needed, but it seems Fowler was very busy at the time and he just wanted to upgrade the book in two or three days.

A quick, pragmatic and fun introduction into UML 2.0, the content book fully delivers on the title. Thanks to his extensive experience Fowler manages to cut some corners and turns UML into a manageable set of 'standards'.

A book that is a must-have for anybody new to UML and object oriented modeling.

I have both 2nd and 3rd edition of UML Distilled. Compared to 2nd edition, 3rd edition has lots of Martin's experience sharing. This is not a bad thing. But for a beginner of UML, what he wants is to quickly understand UML instead of Martin's experience.

For example, Martin tells readers that you should focus more on text description other than UML use case. Also, for the other example, in Chapter 14 Component Diagrams, it is full of Martin's opinion about how to use Component Diagrams without telling readers what is the definion of Component Diagrams.

If you are a new beginner of UML, go back to buy 2nd edition. If you are the readers of 2nd edition and would like to know Martin's experience, then 3rd edition can be a better choice.

First thing first, the third edition of this book is still not available in India. This review of mine's is based on its second edition. Let me first state the expectations I had from this book. It is the certification thing again which prompted me to go for this book. In the OOAD+J2EE+UML space, I feel the best certification to give,in terms of objectives, is the "IBM 486: Object-Oriented Analysis and Design with UML test" exam. Given IBM prescribes this one and the Craig Larman's book 'Applying UML and Patterns' towards preparing for the exam, one doesn't really have any other option but to read this book.

I have been working in the OOAD+J2EE+UML space for the last 3 years in the capacity of an Architect. Before this, though I have read few books on OOAD and Patterns, I hadn't read any book written exclusively on UML. In the large project I was part of, we used Use case diagrams, Sequence diagrams, Class diagrams and on certain rare occasions Activity diagrams.

You repeatedly come across comments such as concise, a very brief introduction, quick reference, compressed, direct in the reviews of this book. Frankly, it is all that. Let me give you chapter-wise impressions book before presenting my summary.

Chapter1: This chapter gives a decent introduction to UML, a reasonable tracing of its history and places UML in right perspective.

Chapter2: My favorite. Gives a classic snapshot of RUP. I infact used some of the lines for a presentation I had to do on RUP to my managers!!

Chapter 3: You get a very brief overview on Use Cases. It was nice to know certain esoteric features related to Use Case relationships. Watch out for the short 'n sweet synopsis on the differences between BUCs and SUCs.

Chapter 4: The author introduces you to the three perspectives while drawing class diagrams: Conceptual, Specification and Implementation. I seriously doubt whether we can engage our users into drawing conceptual diagrams!! Specification Modeling is what we do during the design phase. The sub-sections on Associations, Attributes, Operations, Generalization and Constraint rules are extremely well written. Though the side-bar on Design by Contract comes out a little sketchy.

Chapter 5: I doubt whether I'll ever use collaboration diagrams given the bias I have for sequence diagrams. The wealth of information that comes out of analyzing the sequence diagrams produced by designers is simply amazing.

Chapter 6: I found the sub-sections on Stereotypes, Object diagram, derived association and attribute, interface and abstract class, qualified association, association class, parameterized class, visibility to be too brief. But I found the sub-sections on reference and value object, Multiple and Dynamic Classification, aggregation and composition to be immensely useful and it brought out the wealth of experience the author possesses in no uncertain terms. I might have to re-read these sub-sections many times to get the essence.

Chapter 7: This chapter totally disappointed me. My personal opinion is, Robert C. Martin's papers on packaging are far more superior to what Martin Fowler has dished out on packaging in this chapter.

Chapter 8: The usage of state diagrams is very limited given that it traces the behavior of a single object across multiple use cases and should be used only with objects showing very interesting behavior. The author's treatment of State diagrams is competent.

Chapter 9: This chapter on Activity diagram is brilliantly handled by the author. Though the author confines the usage of activity diagrams to the construction phase, I find them increasingly getting used during the elaboration phase as well.

Chapter 10: I have a very low estimate of Physical diagrams and wouldn't want to comment upon this chapter.

Chapter 11: This chapter left me with mixed feelings. I found it to be good in that it takes you through different class diagram perspectives using the patient observation system. It is bad in that the solution is way too twisted that it leaves in you splits.

Let me summarize in parts:

What I liked: It delivers what it proclaims and I don't have any qualms against it being short, concise and compressed. I liked the informal+ direct + to-the-point style of the author and his 'me-myself' tone.

What I didn't like: It can easily give one a false notion of having mastered the subject when the reality might be far from that. It is not a book reading upon which you can set about your UML related tasks with ease. At best, it is a good reference book. It glosses over too many important subjects. At places, I find him not making a definitive statement when one is actually expecting one from him. Discussion on topics such as Design by Contract, CRC, Refactoring on which exclusive books are written come out thin and a trifle out of place.

If are an UML expert who needs a quick reference guide, then this is your book. If you are new to UML don't waist you money. Rather download this free tutorial: http://uml.tutorials.trireme.com/uml_tutorial.zip

This is a great book for this topic. I like the topic too.
Very trim and to the point. Well written with good examples
and even code samples towards the end (in Java).

If you are familiar with the principles of object oriented programming but you are not familiar with UML standards of OMG, and if your time is short and a condensed reader's digest is what you need, then this is the book for you... and even then, only as a starting point. If you want to do anything serious with UML you shall need more. I have given this 4 stars for what the book is; for many readers' requirements it is worth less.

This is an agile book! You don't have to read 1000 Pages to learn all this unnecessary details about exotic UML diagram types. Martin Fowler teaches the most important diagram types and much more like when to use which and how to use it including an essence of his experience as a software architect and consultant. (3rd Edition available)

I think that to fully understand the existence of this book we have to refer the foreword (in the 1st edition) by the three amigos. There, it is said: "We believe that the availability of a standard modeling language will encourage more developers to model their software systems before building them", and "The creation of the UML was itself an iterative and incremental process very similar to the modeling of a large software system", and last "Creating and agreeing on a standard modeling language is a significant challenge by itself". So in that period, early 1997, the focus was on the unification of the many languages used to visually express designs. On the other side there was another important aim to achieve: "educating the development community, and presenting the UML in a manner that is both accessible and in the context of a software development process". So Booch, Jacobson, and Rumbaugh had to introduce the software community to their achievement, the UML (the Unified Process had to come a bit later), in an iterative and incremental way (a first step before they gave birth to their books) and they had to choose someone with "insight and wisdom" for this job. Their choice fell on Martin Fowler.
I read the first edition of this book one year after its publication (may 1997) when I had already been teaching OOAD methods (mainly Yourdon-Coad and Booch) in my country for a few years. I immediately felt at home with the UML (1.0, and soon after with 1.1), because Mr. Fowler expressed in a simple and effective way in his short guide, first book on the language, the key concepts of the notation along with its semantics, keeping the promises he made at the beginning of the book. The first iteration of the language was successfully delivered to me `in time and budget', and I could introduce the notation in my courses with a great effect. Interesting parts of the book are the overview of the process (chapter 2) and the presentation of either refactoring and patterns.
Few months ago, the company I'm working for needed, for one of its departments, a revision to the process and a widespread use of a visual language. The choice fell on a light iterative process based on UML and I was chosen as trainer/mentor. The starting point to UML was this book (the italian translation), in its 2nd (on UML 1.3) and 3rd edition (on UML 2.0).
The book proved useful particularly for the quick introduction to the basic concepts of the language.
UML 2 was not exploited because of the lack of tools that use it, so it was not a priority in the training.
Today, with so many books on UML in the arena, this is still one of the main to and through the language, so thank you Martin (Grady, Ivar, and Jim) for your job (not forgetting the giants whose shoulders they're standing on).

Excellent guide for software engineers that need to come up to speed quickly. UML is huge and many may not want to be drowning in the details. This book gives you the basics, and then some. Many areas are covered and it could almost be a concise summary to many aspects of software development in the real world. Definitely will stay on my bookshelf.

Martin Fowler does it again. This is a very good introduction to UML 2. But, I wish Fowler had included more details on Class diagrams and Sequence diagrams in particular ,with real world examples.
Still, a great introductory book.

Readable! Excellent intro. On the inside covers, nice quick reference. As a web developer with no UML experience looking for a clearer way to pre-visualize my projects, this book got me going fast and offered perspective on best usage of the UML. The author's experience-driven opinions helped me learn faster. The book is honest about itself in that it admits it doesn't try to offer rare details of the UML that you'll rarely use. It keeps to what you'll use MOST of the time. It delivered 100% of what I was looking for. If you're already using the UML, I still think this is a great read for you.

I've read a review here, which says that "UML Distilled" 3rd edition has a lot of errors and mention missing figure 5.1 as an example. So I bought "UML Weekend Crash Course" instead, and was very disappointed with it. Then I finally bought this book, and I love it. It describes everything in a clear and simple way. And, by the way, the figure 5.1 is there on page 67, exactly where it should be.

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.

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.

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.

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 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.

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.

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.

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.

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.