am 30. Januar 2001
This book is not a reference manual. It does not teach modeling. It does not describe a development process. It provides only trivial examples.
In the words of the preface: "This is similar to a user guide for a programming language that teaches you how to use the language but does not teach you how to program".
Taken alone, this work isn't enough. You'll need a real reference. Consider getting The Unified Modeling Language Reference Manual instead.
For the specific purpose of being a user guide, this book might be very good.
am 27. Juni 2000
If this were the only UML book in existence, it would deserve 5 stars. It contains a lot of information and a nearly comprehensive list of language features without the dry tone of a reference. But there are better books on the market and this is not the one to spend your $45 on. If you want a comprehensive reference, get the UML reference. If you want an introduction, get UML Distilled.
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.
am 20. Dezember 2005
When I started reading this book I had no real idea of
what the UML is, so I thought a "tutorial" is a good way
of getting a feeling for it. I read this book from beginning
to end, and I guess now I have a "feeling" for it. Not more
and not less. In that sense the book can be a suggested
reading. But some knowledge of a 00P-language is definitely
I am surprised by the fact, that many people seem to use this
book mainly as a reference. This is definitely no good reference
because the real content is much too sparse (but verbosely expressed)
and introductory to serve as a reference. If one wants to know something
specific of a given UML feature, he most of the time wont find sufficient
information in this book.
But even the few things it covers are not always comprehensible
for a novice to the UML, e.g. the chapter on "Common Mechanisms"
gives absolutely no idea on what these things really are and
how to use them (like stereotypes). And sometimes one just finds
sentences like "you may also draw this kind or that kind of
relation between these kinds of things" without any further
explanation, what kind of semantics this could have. This seems
to be the main dilemma of this book, and the UML in general,
that they try to explain their models without giving
semantics. Also this book "smuggles" semantics in by
referring to OOP-languages, but in an inconsequent manner.
Sometimes they do, sometimes they don't. So many things stay
completely unclear to the reader.
A whole lot of the text is written in an maddening verbose, complicated
way, like "A message is a specification of a communication between
objects that conveys information with the expectation that activity will
ensue.". I have sometimes the impression, the UML people try to
hide the triviality of their models behind an almost pseudo-philosophical
blurry language. Why? To ease the sale of lots of seminars?
One can read David Harel's original paper on Statecharts, and after
just a few pages one knows everything in great detail. With this
book you read hundreds of pages, and still you just have a
a blurry, minimal idea of the "things" of the UML (they really
call it "things").
After reading the 450 pages I had the impression that all that
could have been said also on 40 pages. In that sense this book
is a great waste of time. On the other hand it gave me an
introduction into it, and at least now I have a (misty-eyed)
big picture of what all this is about. So, if you have the
time, it might be a useful introduction. But there must be
much better ways of explaining these (trivial) things.
am 26. Januar 2000
Unfortunately, this is one of the poorest books I have ever read. To begin with, the langauge is stilted and difficult to follow. It is as if the authors wrote the book in a different language and then translated the work into English. If the purpose is to communicate concepts, the work falls short for this reason.
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.
am 28. April 1999
"The Unified Modeling Language User Guide" is a comprehensive study of the Object Management Group's (OMG) and Rational Corporation's Unified Modeling Language (UML). It is written by the three Amigo's; Grady Booch, James Rumbaugh and Ivar Jacobson (order appears to be important, just look at the other books in this series) and carries a date stamp of September, 1998. The discussion as presented by Booch et al. covers what appears to be a similar range of topics to the UML 1.3 version as specified by the OMG. This text is written in a clear concise fashion including a generous introduction to the object paradigm. The book goes on to present a fairly complete picture of the UML's basic notation and concepts. Further, a description of many of the object paradigm's advanced mechanisms including distribution, persistence, and real-time issues as modeled in UML is presented. A comprehensive glossary is accompanied by three fairly complete appendicies, a quick reference to UML notation and diagrams, a list of UML standard elements Stereotypes, Constraints and Tagged Values and an abridged guide to the Rational Unified Process (RUP). As a profesional object modeler I have exteremely dog eared copies of a few tried and true basic object paradigm texts. The first couple that come to mind are Booch's Object Oriented Analysis and Design with Applications and Rumbaug's Object Modeling Technique. The tattered state of these tombs is due to using both as reference on more times than I would care to mention. These books have proven to be the basic guide, the corner stone, to the object paradigm for most CS and IT professionals. "The Unified Modeling Language User Guide" should prove to be able to shoulder this tradition and become the newest OO Bible, a formidable weapon in any object modeling warrior's arsenal. All in all this book is a good read (one cup of caffine needed) and provides great object paradigm basics and UML references. Of course there are other books that discuss the same topics such as, UML in a Nutshell from O'REILLY, (two thumbs up), Instant UML from Wrox (translated from French), UML Distilled from Addison Wesley, (outdated and incomplete) amongst others. Overall, "The Unified Modeling Language User Guide" is a must for any object modelers library. Four and one half stars. P.S. The 1.4 version of the UML is supposed to be accepted by the OMG in an April, 1999 time frame, these additions to the UML are not fully describe in the "The Unified Modeling Language User Guide". For the most part the UML 1.4 version concerns the addition of some of Object-Time's Real-Time Object Oreinted Modeling (ROOM) concepts.
am 26. Februar 2000
"The Unified Modeling Language User Guide" really starts from the beginning. Apparently the reader is assumed to be totally unfamiliar with object oriented design. The book starts with the very basics, and explains a reasonably complete set of UML. The really advanced and esoteric features are not explained.
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.
am 16. September 1999
My feelings on this book are mixed. It is a large book for what it offers (almost 500 pages that take a lot of time to read) but it does provide a thorough introduction to UML. It also discusses some advanced modeling concepts and constructs (sections 3 & 5) but it leaves the reader wanting to look elsewhere for how to apply these. There is an irritating duplication of material in different parts of the book, but I liked the appendices that included some of the standard elements of UML and a very brief summary of the Rational Unified Process. If you have the (a lot of) time to read the book or you are one of the many fans of Booch's writings, then this book will be of value.
am 2. November 1999
When you read a book, you must understand the type of book it is. If you approach a satire as a serious treatise, a fantasy as a history, or a telephone directory as a novel, your expectations will not be met and your review of the book will be flawed.
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.
am 26. September 1999
This is not "The Ultimate Tutorial" written on the subject, and certainly does not help as a "USER GUIDE". An ironical downswing, more so after one expects standards set by Booch's earlier "Object Oriented Analysis and Design".
Yes, every chapter in this book is structured in the same way, but wow! What a structured redundancy! There are several repetitions, some word-by-word and very, very irritating! It seems less of a tutorial, and more of a reference book. And the preface mentions that "each (chapter) builds upon the content of the previous one, thus lending itself to a linear progression".
Let us investigate what kinds of readers can this book help.
If you are already knowledgeable in Object Oriented Concepts and Development, then you already use some kind of notation in your work and are looking for an introduction to the UML notation. The only chapters useful for you in this book are the appendices and you can always refer to them in a library. This book will add nothing to your knowledge of OO-concepts and it's 500-page introduction to UML notation is most likely not worth the time required. I strictly advise you against buying this book.
If you are not knowledgeable in Object Oriented Concepts, then reading this book is not going to add anything to your knowledge. A better book would be something like "Object Oriented Analysis and Design" by Booch, and supplemented with some small book on UML (I am also searching for a small book, by the way). In this case also, I strictly advise you against buying this book.
Most of what the book contains could be compressed and presented in a 100-page book, written with some respect to readability and professional quality.
At the end of it all, one sighs- What a waste!- and the authors are the very people who developed the UML standard. (I can't end without mentioning this- there are some places in the book where there are abrupt changes in font sizes. Bravo! But don't keep it up!)
am 7. Mai 1999
I wish the technical content of this book were half as good as the quality of the type-setting. I found the presentation style nice, specially nice use of heading styles and 2 colors. But I was very disappointed with the technical depth.
I would expect such a book to give really tight rules about consistency between models, and to provide an objective basis for a modeler to follow (in addition to all the "good advice"). A consistent example would not hurt either.
Some specific points I was turned off by:
(1) As a person with some experience with precise modeling approaches, I think Booch has really missed the mark by treating "refinement" as a little syntactic detail, instead of something central. This smacks somewhat more of "kitchen sink" than an elegant solution based on a simple core, that will scale well with time. "Refinement" sounds cool -- let's throw in a notation or stereotype.
(2) The description of patterns will probably attract someone who was looking for a notation for basic "Gang-Of-Four" stuff; but there is a scary lack of depth behind that notation!
(3) Activity diagrams -- again, scary lack of depth behind an initially appealing notation. "It's just a state diagram..." -- jeez! If the bubbles represent states, then why are the state annotations of Object Flows (e.g. Fig 19.8) always shown AFTER the bubbles? That screams out that bubbles are used more like state changes than as states!
Oh well ... I will try Rumbaugh's book next.