This book, however, is just a dump of UML information, fairly ecletic but not always in sufficient depth. It is good information, but the poor organization makes it useless after the initial reading.

If you are looking to learn UML, it IS possible to get a good feel for it from this book. However, something like "UML for Dummies" will also give you a good introduction, at a better price. If you will be modeling a lot, and want a deep understanding of UML, then it would be wiser to buy the Reference Manual instead.

To start with each chapter begins with an analogy on how building a house is like software design. When I started the book the analogy seemed appropriate, by chapter 31 I wanted to break someone's nose.

Outside of the horrible cover design and redundant analogies the book is poorly organized. The book constantly refers to terms that it doesn't expound upon or for that matter define anywhere. For example, the authors refer over and over again to CRC Cards, but they're not defined anywhere in the book. What's worse, however, are the partially defined lists. For example the authors go to the trouble of informing you that there are four kinds of events in UML, but only bother to discuss three of them. Maddening!

The chapters don't really follow a logical flow. The Three Amigos constantly skip backwards and forward throughout the book. In the side margins, almost as an afterthought they have included chapter references in blue type. If you follow the chapter references you're reading all over the place. Moreover, and perhaps most annoying of all is when they keep referring to concepts that they cover later in the book. I was paranoid that I day dreamed my way over the whole concept of the state machine until I discovered it nested away in chapter 21.

Last but not least, the book is poorly written. Seriously, if you have to read this piece of crap you better brew a big pot of coffee. Technical literature can be a bit dry at times, but this is an exceptionally horrid piece of work.

Death to the Three Amigos and a pox on Rational for hiring them!

Don't buy this book.

However, the book is a serious piece of work on the UML subject coming from the most authorized voices on the topic.

The book is rather for people with good experience in OOP and some experience in UML.

This is more of a reference book. It's well-cross referenced and I find it much more helpful for looking up individual terms, diagram types, etc. than when I read it front-to-back.

What I was hoping to gain from the book is a better sense of when, where, and why you would be creating the different diagrams and how it all fits into a development life-cycle. Evidently, this kind of information is left to other "Three Amigos" books.

I'm inclined to agree with other reviewers who feel that this book is "wordier" than it really needs to be. They repeatedly use an analogy to building a house that gets nearly as tiresome as it is obvious. But if you find UML to be useful, necessary, or just intersting, this would be a good book to have in your library.

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!

The method in which they design each chapter, as some reviewers have noted is in a very programmer style approach. Every chapter basically deals with a single topic that is introduced in a simple manner, the topic developed, and then concluded. However, this makes for a very inconsistent reading content, as many of the chapters hardly give any segue into the next chapter. Most of the chapters feature redundant material, and often fails to build on the previous chapters in a coherent way. Even as an object oriented programmer, while some of the topics are easy to follow, a lot of the text is still totally disorganized and not suitable for a making this a book to learn from. Most of the chapters have extremely simple examples that won't be of any help to experienced programmers. However on the other end, most of these simple examples are not explained at all for beginners. This book never builds upon a single example throughout the book, and that's a huge mistake keeping the reader from focusing on a personal reference point and ignoring the ability of the reader to build on the past chapters.

The chapters tend to give a rough description of a UML problem that must be solved, then discusses the components relevant to the chapter, and then a graphic example with little discussion of the example itself. If you can't thumb through this book, here's a VERY (EXTREMELY) typical example of the UML "Notes" on each page. Opening a random page of this book, right in the middle, I've hit chapter 15. The assumption should be that if I'm on Chapter 15, the book should really only discuss items from at LEAST chapters 1-4. But on a SINGLE page I have ELEVEN notes referencing me to different chapters of this book: Chapters 4, 9, 19, 27, 4, 9, 25, 26, 16, 27, and then 9 again. If you'll notice, on this single page, 6 of the chapters are further ahead then the reader has learned, 4 of them are a full TEN chapters ahead of the reader's current knowledge!

When reading these reviews, keep in mind to look for the opinions that talk about how the information is relayed to you as a reader, not just an outline of what's in the book. If everything was in the book, but you couldn't read it, what's the use? If you think this book is bad, you should see their so-called "Multimedia" learning package.

However, if you just pick whatever piece you are interested, and spend some time really digging into it, you will find many good insights. In this sense, it's much better than average user guide.

I personally find the "Common Modeling Techniques" section of each chapter very useful.

I read most of the UML Toolkit book that was published before the UML Users Guide, but it was rather dry reading and didn't cover UML comprehensively like the UML Users Guide does.

After reading the UML Users guide, and maybe the Unified Process by the same authors, you can apply this knowledge to manage the complexity and architecture of large systems, assuming that not only do you understand all of the UML notation, but know how to apply it through education, training and expertise.

The UML Users guide is well written and has very short granular chapters that cover one self-contained concept of the UML. It is a must read for any serious software engineer who wants to speak a common modeling language and get beyond a code and fix type approach to development.

I suspect that Grady Booch gets paid by the word (or page perhaps). Personally I like my technical information to be accurate, comprehensible and terse. I don't like being frustrated by a book that is hihgly repetitive (just see how often the OO and building construction analogy is flogged to death and then chased into the after life).

In terms of usefulness, I don't think this book has any value. It's not a reference and it's also incomplete (does not cover OCL)... and no I don't want to buy a seperate book by Jim Rumbaugh to get the information on that. Instead I'll be getting it for free at the omg web-site).

The book is not for developers with in-depth knowledge of UML. They will be bored with the terms and examples. I imagine they are looking for more of a theoretical approach to what makes a UML diagram efficient or inefficent, not how to read the diagram (thus the nature of some of the negative reviews).

Personally, I liked the fact the book was broken into 30 some chapters. I read a chapter an evening for a month and bang, I had a solid foundation on UML, just what I was looking for. The chapters were short, to the point though they did contain repetitve information (maybe it was intentional as repetition is how people learn.)

I thought the book rocked. I read plenty of CS related books but this is the only one I have ever considered writing a review for because I think it can truly benefit the novice to intermediate UML user.

That said, it is an important primer for the UML. It introduces the kinds of diagrams you can make and all their highlights. The writing itself is good, if repetitive.

The book authors forgot that you cannot learn the language learning only its grammar - no way! Book does not show how language constructions actually work and what is the relative importance of different elements of the language when you try to describe your system.

Every chapter finishes with bunch of general advises how to apply UML to describe your system, but never shows how actually to do it for a specific system.

I read OMT book written by Rumbaugh and it was similar to this one. Both of them assumed that readers love UML/OMT for the sake of UML/OMT.

It is pity that such an exciting subject was converted into boring text by the authors who don't know how to write useful books.

The book starts of with reasons for modeling with real world examples. For a novice, this will be the best introduction to modeling - why is it needed in the first place.

The book also describes the evolution of UML (best practises of OOSE,OMT and Booch) which will benefit people in all levels of software engineering.

Any modeling technique needs to address the following three components a) Structural b) Behavioral and c) Architecture.

This book contains explanations for all of the above three components in separate sections. Even advance behavioral/structural modeling is discussed.

The structural modeling is described with explanations on a) Objects & classes b) relationship between classes c) class diagrams

The behavioral modeling is described with explanations on a) use case diagrams b) interaction diagrams c) activity diagrams and importantly d) state charts to name a few.

The architecture modeling is described with explanations on deployment, collaborations and component diagrams to name a few.

I would recommend interested OO developers/managers to acquire this book as a reference material for OO development needs.

I purchased this text because the introduction to UML Distilled said that this book would be better if you wanted a really in depth understanding of the UML. Unfortunately, it does not fulfill this role. While it succeeds in catelogging nearly all the features of UML, it has no unified examples. Indeed, all the examples are next to trivial.

The book is not worthless. I read it and worked through some examples from my own experience, and I'm pretty comfortable with UML now. But good examples are something a text like this should provide. To really see the UML in action, I'm going to have to buy another book. I'll keep this one as a reference, but that isn't the purpose it was designed for.

If you are learning UML, good companions to this book are: "Applying Uml and Patterns: An Introduction to Object-Oriented Analysis and Design" and "UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language".

Some of the symbols are used before they are explained. But in general, most of the concepts are explained clearly.

None of the phone number and http address given together with this book work. So you won't get a free-CD through this way.

What bugs me the most is that the treatment of UML flows from structural to behavioral. The authors treat basic and advanced structural modeling before they even pick up use-cases and basic behavioral modeling. This is not how the real world works.

In projects, during the first iteration, a lot more of behavioral modelling is done to gather user requirements. It would be more helpful if the book aligned itself to this Unified Process.

Each chapter is written like a good lecture. It starts from the very beginning assuming no previous knowledge of OO. Then one aspect of UML is carefully explained. Every chapter ends with some concluding remarks and "hints and tips". This organization is mostly good, but it adds a lot of repetition to the book.

The language is smooth and easy to read. It might still be a struggle to get read the book simply because of the amount of text (and repetition).

I would recommend this book to the interested novice. However, if you are reasonably familiar with UML, or if you have a solid foundation in object oriented programming, then I would recommend you the combination of "UML Distilled" by Martin Fowler and "The Unified Modeling Language Reference Manual" by James Rumbaugh et.al.

The primary difficultly with the work lies in some of the assumptions of the unified process. First, analysis and the upper lifecycle of systems development are treated very cavalierly. The attitude is that analysis is okay and may yield some valuable information, but you should be able to go right into design without wasting all that time in analysis. My 11 years of professional experience indicates otherwise.

The next difficultly is communication between various audiences. UML is touted as the most effective diagramming technique for communicating both business and software concepts. Yet the modeling techniques are severely lacking in techniques for capturing fundemental business information. In addition, many of the concepts presented are very esoteric and peculiar to object modeling and are not easily applied to the business world or even to transaction-based software applications.

There is also a concerted effort to ignore many valuable techniques developed in such disciplines as Information Engineering, Structured Analysis and Design, etc. The UML will be a mature enough modeling language only after these missing pieces have been incorporated.

If you want to familiarize yourself with the buzz words of the object community, buy the book. Otherwise, I wouldn't recommend wasting your money.

It would have been nice to see something that lived up to the great promise of Object-Oriented Analysis and Design. Unfortunately, it seems like we always loose 'em when they cross too far over into "pundit" and "promoter" land.

Maybe for a subsequent book, Mr. Booch could take something like his temperature control system from OOA&D and go through each model type using the same classes, objects, states, packages, etcetera - seeing an entire system, incrementally realized by the use of UML. Instead, we have a bunch of unfinished, disconnected, bits and pieces.

Throughout the book, the authors draw parallels to building architecture for corresponding UML elements for software architecture. There's effective use of two-color printing to distinguish metadiscourse and metadiagrams from actual UML diagrams.

And it's deep: VERY deep. The authors explore nearly every use of every UML element, covering things that most users of UML will never use. In that regard, this book makes a better reference manual than a user's guide. I'd recommend getting this book to sit on the shelf when you have questions or want to solve an ambiguity, but stick with Martin Fowler's "UML Distilled" for the core UML that you'll use day-to-day.

Another plus to this book is the many mini-tutorials on how to apply the UML to real world problems.

I would definitely recommend this book to anyone who is serious about becoming a better software developer.

You determine the type of book--the genre--by combining the book's own clues (statements by the author) with your experience in literature of all types (what "patterns" does this book share with other things I've read?). You may have to read the book once, reflect on the distance between what you expect and what the book provides, and then--well, then you have to choose. You can condemn the book as unfruitful and disappointing, or revise your expectations according to the book's genre.

The UML User Guide has forced me to do this revision. On first reading--a close and careful reading--I expected a different book, and was disappointed by the book. Yet the authors are not incompetent: their other works are classics (don't look for tight logic here--anyone can produce a clunker). What sort of book is this? The text is repetitive, both in chapter structure and in content. The material is simple, and barely touches the complexities of real-life modeling. The book is long, covering lots of ground, without digging more than a few centimeters deep at any one point. Where have I seen this before?

In my introductory Hebrew class, I learned that there were two tenses in Hebrew, past and future. I dealt with shallow topics like, "This is the [male] horse of the king," "The king hit the horse of the city," "The [female] horse will kill the king," until I could scream. Every chapter had a topic, examples, review, exercises. The book itself covered about all topics of Hebrew grammar, without going very much into depth, and without discussing how to compose (or just read) a historical book, a Psalm, or a prophesy about a neighboring country.

Later, in other courses and other texts, that "past and future" expanded into several pages of subtle shades of meaning; "the king's horse" was swallowed up in the majesty of, "In the year of the death of King Uzziah, I saw the LORD high and lifted up"; whole courses were devoted to certain Psalms, whole books to a single prophet. And it all became possible because of the irritating repetition of that first Hebrew textbook.

Like my Hebrew text, the User Guide is a "prescriptive" introductory grammar. It introduces you to the whole framework of the UML, adds some hints and details, and gives you enough training to compose diagrams about object-oriented kings with an aggregated [male] horses. It does this with the (potentially irritating) repetition appropriate to a book that is laying a foundation, brick by brick. The experienced developer may find that it is simple where she has encountered complexity and it gives answers where she has found questions; yet it may give her a footing she doesn't yet have, but will appreciate in a future project.