When this book came out, it was an excellent reference in an area relatively devoid of literature. Documents explaining UML (and OCL) were sparse, UML modeling tools were sparse (and proprietary), and the technology to "use" UML hadn't acheived the wide(r) acceptance and sophistication found today. However, even within this context, one might have complained about the format.



This book contains a fair bit of explanation and theory - one understands the difference between sequence and class diagrams. Moreover, one cannot really complain about the books usefulness as a reference, though the low-level "nuts-and-bolts" information falls a bit short of other O'Reilly "Nutshell" books. Yet, there is something missing in the middle. One doesn't get how to move from A (introductory this-is-this and that-is-that) to B (how do I depict relationships between classes and interfaces). In other words, one cannot read this book and begin jotting down ideas in UML - at least not easily. My largest complaint is this lack of intermediate instruction - how to move past the basics so that one can take advantage of the reference nature of the book.



However, that being said, I believe that this is a useful book to have in one's "zoo". Further, it is interesting enough to read cover to cover - I did.

When this book came out, it was an excellent reference in an area relatively devoid of literature. Documents explaining UML (and OCL) were sparse, UML modeling tools were sparse (and proprietary), and the technology to "use" UML hadn't acheived the wide(r) acceptance and sophistication found today. However, even within this context, one might have complained about the format.

This book contains a fair bit of explanation and theory - one understands the difference between sequence and class diagrams. Moreover, one cannot really complain about the books usefulness as a reference, though the low-level "nuts-and-bolts" information falls a bit short of other O'Reilly "Nutshell" books. Yet, there is something missing in the middle. One doesn't get how to move from A (introductory this-is-this and that-is-that) to B (how do I depict relationships between classes and interfaces). In other words, one cannot read this book and begin jotting down ideas in UML - at least not easily. My largest complaint is this lack of intermediate instruction - how to move past the basics so that one can take advantage of the reference nature of the book.

However, that being said, I believe that this is a useful book to have in one's "zoo". Further, it is interesting enough to read cover to cover - I did.

I pity anyone who spent money on this book and thought they would get a decent reference manual to the topic. O'Reilly will lose its reputation for publishing clear, concise, readable books on technology if they keep this up. WHERE were the editors for this book? And WHO CARES whether the author "knows his stuff"? The point is for the author to communicate concepts to the reader. This abstruse work has to be the one of the greatest obfuscations of a subject I've ever seen.

After slogging through the useless preface and introduction, you get to Chapter 2: The Big Picture. You sigh with relief thinking that maybe now the author will provide some insight. This hope will evaporate quickly, sad to say. First, the author wants to enlighten you by providing an in-depth analysis of "Problems, Solutions and Problem Solving".

Let me share a couple of mangled sentences from this section:

"To deliver valued solutions (maximum quality and minimum cost within the minimum time), organizations must capture (acquire), communicate (share), and leverage (utilize) knowledge."

And later in the same section:

"In addressing this problem, an overall approach must address how we will understand or conceptualize the problem, derive a solution to the problem, and implement or realize the solution. This approach will determine how we view the problem (paradigm) for the purpose of realizing it. We will apply our knowledge of the situation and other rules of thumb (heuristics) gained from other experiences to derive the solution (artifacts). Our effort will be organized (life cycle) as a series of (possibly concurrent) steps (activities) so that it may be managed to develop the resulting information system."

Uuuhhh, and when do we get to start talking about UML? Spare us the attempts at philosophy. We know what problems and solutions are. We have a problem here -- we need to understand UML.

Oh, I can't resist adding a bit more:

"'Methods' specify how to conduct problem-solving efforts. They specify an overall problem-solving approach and its components. They specify how problems and solutions are viewed in relation to a problem-solving approach; this is known as a method's 'descriptive' aspect since it describes how knowledge is captured and communicated regarding a problem and solution. Methods also specify a problem-solving approach to be used to solve the problem and derive a solution; this is known as a methods 'prescriptive' aspect since it prescribes how knowledge is leveraged to solve a problem. Methods specify descriptively how problems and solutions are viewed, and prescriptively how the problem-solving effort may be actualized."

Do you feel edified from reading this passage? If so, run out and get this book because there's a lot more of the same throughout.

I pity anyone who spent money on this book and thought they would get a decent reference manual to the topic. O'Reilly will lose its reputation for publishing clear, concise, readable books on technology if they keep this up. WHERE were the editors for this book? And WHO CARES whether the author "knows his stuff"? The point is for the author to communicate concepts to the reader. This abstruse work has to be the one of the greatest obfuscations of a subject I've ever seen.

After slogging through the useless preface and introduction, you get to Chapter 2: The Big Picture. You sigh with relief thinking that maybe now the author will provide some insight. This hope will evaporate quickly, sad to say. First, the author wants to enlighten you by providing an in-depth analysis of "Problems, Solutions and Problem Solving".

Let me share a couple of mangled sentences from this section:

"To deliver valued solutions (maximum quality and minimum cost within the minimum time), organizations must capture (acquire), communicate (share), and leverage (utilize) knowledge."

And later in the same section:

"In addressing this problem, an overall approach must address how we will understand or conceptualize the problem, derive a solution to the problem, and implement or realize the solution. This approach will determine how we view the problem (paradigm) for the purpose of realizing it. We will apply our knowledge of the situation and other rules of thumb (heuristics) gained from other experiences to derive the solution (artifacts). Our effort will be organized (life cycle) as a series of (possibly concurrent) steps (activities) so that it may be managed to develop the resulting information system."

Uuuhhh, and when do we get to start talking about UML? Spare us the attempts at philosophy. We know what problems and solutions are. We have a problem here -- we need to understand UML.

Oh, I can't resist adding a bit more:

"'Methods' specify how to conduct problem-solving efforts. They specify an overall problem-solving approach and its components. They specify how problems and solutions are viewed in relation to a problem-solving approach; this is known as a method's 'descriptive' aspect since it describes how knowledge is captured and communicated regarding a problem and solution. Methods also specify a problem-solving approach to be used to solve the problem and derive a solution; this is known as a methods 'prescriptive' aspect since it prescribes how knowledge is leveraged to solve a problem. Methods specify descriptively how problems and solutions are viewed, and prescriptively how the problem-solving effort may be actualized."

Do you feel edified from reading this passage? If so, run out and get this book because there's a lot more of the same throughout.

When I write a review this bad, I feel that my objections must be as specific and concrete as possible. The good news is that the book gives me plenty to work with.

First is the writing style. Nearly all of the text is bulleted lists or hierarchies of bulleted lists. At best, it's an un-natural reading style. This isn't the best, though. Some of the lists go on for pages. Most annoying is that most bullet items start with incomplete sentences. At times, I felt desperate for a whole sentence with subject and verb.

Second is the style of illustration. I don't insist that every author be a trained graphic designer. A few basics should be obvious, though. Here's one: at least within any one picture, use different line styles to encode different information or to create contrast. Figure 2-8 uses lots of different styles to say the same thing, fig. 3-7 uses one style to say lots of different things, and fig 5-7 appears to use one line drawn in styles (weights) that change when it turns a corner. These are just examples, by the way, not a complete catalog of problem illustrations or even of kinds of problems.

The worst, though, is the technical content. The first half of the book isn't UML at all, it's an introduction to OO design (compared to two different earlier styles) and development process. I generally found the discussions so brief as to border on meaningless. If I wasn't already familiar with the topics, I doubt that I could have figured out what the machine-gun bulleted lists were trying to express. I feel sorry for the beginner trying to learn from these chapters.

Even the UML, the second half of the book, suffered from the same brevity and opaque style. The section on state charts, in particular, managed to show only the pieces but never how they fit into a whole state machine. It was as if I showed you a box full of nuts, bolts, wheels, and handles, and expected you to understand what a tricycle is. The section on activity diagrams, however, was short enough to qualify as negligent. I can't even criticize the content, because there's almost nothing there to criticize.

I can not recommend this book.

The author of this In a Nutshell title clearly knows his stuff.

The Desktop Quick Reference is packed with very detailed definitions of UML concepts and the language's meta model. The author's style is very succinct and focused.

This very detailed, granular approach probably makes it a great Desktop Quick Reference for anyone who already knows UML reasonably well.

However, if you are new to UML and trying to learn it (like me), I'd say this Nutshell is pretty tough to crack. On balance, there is not a lot of narrative in the book. What is there, is very dense:

"The object-oriented paradigm is reducible to the function-driven paradigm or the data-driven paradigm. That is, while using the object-oriented paradigm, activities can be skewed to independently leverage function-driven concepts or data-driven concepts in a given problem-solving approach." (p 66)

So after several reads, the language still feels out of reach. I've gotten another book to help me teach myself: UML and the Unified Process (ASIN 0201770601).

Using the two books together, I'm making much greater strides.

And when I have learned UML, I am sure In a Nutshell will be a very useful reference.

Every time I ... buy a technical book without checking Amazon.com for the reviews I end up kicking myself, and this time is no exception. This book is almost completely impossible to read - it is a tangle of repetitive bullet points torn from some cursed corner of academia. When the author does take the time to write a complete sentence it is riddled with odd parenthetical notes that are less than helpful. And the diagrams, at least in the initial chapters, are arcane, in my opinion rather silly, but mostly just needlessly confusing.

I found myself skipping larger and larger sections of the text at a time looking for some island of clarity from which I could learn something valuable without too much squinting and ended up skipping all the way through the book.

Of all the topics that should be treated in a clear, straightforward manner, coverage of a modeling language designed to facilitate communication pretty much tops the list - so if you are a collector of irony, this book would make a nice addition to your collection. Otherwise, I'd select another title.

Every time I ... buy a technical book without checking Amazon.com for the reviews I end up kicking myself, and this time is no exception. This book is almost completely impossible to read - it is a tangle of repetitive bullet points torn from some cursed corner of academia. When the author does take the time to write a complete sentence it is riddled with odd parenthetical notes that are less than helpful. And the diagrams, at least in the initial chapters, are arcane, in my opinion rather silly, but mostly just needlessly confusing.

I found myself skipping larger and larger sections of the text at a time looking for some island of clarity from which I could learn something valuable without too much squinting and ended up skipping all the way through the book.

Of all the topics that should be treated in a clear, straightforward manner, coverage of a modeling language designed to facilitate communication pretty much tops the list - so if you are a collector of irony, this book would make a nice addition to your collection. Otherwise, I'd select another title.

This book is horrible. It tries to be a tutorial, and a reference but succeeds at neither. Instead we get a dense book consisting mostly of bullet points, complicated diagrams and a rambling format which never gets to the point or tells you concisely what you want to know. It is like someone has just cut and pasted the bullet points of their UML training course (extra complicated edition) into book format.

I don't suppose UML is *that* hard to understand assuming an author takes you through it in reasonable learning steps, but unfortunately this book doesn't.

This is a very poor O'Reilly title.

O'Reilly in many ways defines a technology. If there is a O'Reilly book that means it is something you probably want to know. Most of the "In A Nutshell books" have become invaluable and essential for me, but unfortunately this book misses the mark. In many ways this book does more to hurt UML than increase its use. When confronted with this confusing mess, more often than not, people will walk away thinking, UML is too confusing and not a helpful tool.

The author babbels on for two chapters without giving any concrete examples, showing the concepts, or demonstrating how it helps you. The diagrams are confusing, for example, the software life cycle diagram. I think the objective of the was author to prove he was smarter than the rest of us rather than trying to help us understand.

I want the second edition (assuming it comes out and fixes the major problems) of this book for free because it was a waste of money and is not up to O'Reilly standards. I have certainly bought enough O'Reilly books to make them quite wealthy.

This book is more analogous to O'Reilly's *nix in a Nutshell series than to their Java in a Nutshell series. It is a very quick ready reference to the notation with some minimal explanatory material. It is only useful to practitioners. Beginners should read Fowler first, but this will then flesh out the detail Fowler misses. Alternatively get the OMG guide in PDF, it covers the same ground but in less usable electronic form.

I bought this book, without reading any reviews, on the basis it would demonstrate the usual lucidity of the "In a Nutshell" series. Alas no. It is a fine example of a pedantic, overly qualified academic book; almost comical in its lack of clarity. Vague diagrams followed by long lists of overly precise bullet points are the preferred mechanism of imparting knowledge (one can imagine the author sweating to impart maximum exactitude in the minimum word count). I'm sure the author knows the subject, however, I would defy any generalist to make head or tail of it. The last book I read as staggeringly incomprehensible as this was Wittgenstein's Tractatus Logico-Philosophicus - and at least you know with Wittgenstein it's going to be incomprehensible before you part with your cash. So in a nutshell, no.

As a devotee of O'reilly titles (it's the first publisher I usually look to on computer subjects), this one was disappointing. Regardless of whether it covers the subject matter well, the book fails simply because of the writing. It is, at least in the beginning, weighed down by comma series that go on forever, parenthetic notes that are redundant, and points that are lost in a volume of unrelated stuff.

The author lacks focus, and the writing style is academic. This is not a practitioner's guide. I ended up purchasing a second UML book within a week.

I don't normally write reviews but this book was just too much to pass up. I swear I have seen this skit on SNL where some guy just explains something an absurd degree and confuses everyone. This is that skit in book form.

For example (I was laughing when I read this) on page 52 where the author is describing objects, the 4th bullet says, "Objects - May be of a simple or complex data type (should have stopped here) Simple data types are not reducible to any subordinate parts. Complex data types are conglomerates reducible to subordinate parts."

I think someone published his dissertation at O'Reilly.

Let me say to the folks who gave this book five stars and think that these other people just don't know enough to be in the ballgame, I respectable disagree with you. I have worked with OOA&D and the UML for several years now and I just found this book to be a mediocre reference at best. You are correct, it is not for beginners but a book still needs to be interesting, provide concrete examples and in-depth analysis into the most important aspects of good object-oriented analysis and design. In my opinion, this book really offers none of that.

If you really want a great book that will keep you reading like a Tom Clancy novel (okay that is stretching it a bit) you should get Fundamentals of Object-Oriented Design in UML by Meilir Page-Jones. Now I have seen some reviews that say it is for beginners but I do not agree. The first section on fundamentals of OO yes, however the subsequent parts of the book get into some very well written detailed analysis about not only best practices with the UML, but also object-oriented software design principles in general.

O'Reilly, I am disappointed. I have several titles (Java Network Programming, Java and XML, EJB, Servlets etc.) and this is by far the worse. I think O'Reilly should leave OOA&D and the UML to the Addison-Wesley Booch-Rumbaugh-Jacabson series. Just my two cents :-)

The tutorial section was ok, but other than that I found the book to be of little use. The author's attempt at describing the basic O-O paradigm is possibly the most convoluted explanation I've ever seen. Eg, object operations (aka methods) "Are representational constructs of behaviorial characteristics of entities". IMO, this is just one example of many failed attempts at describing simple concepts. I started to wonder if the author was paid by the syllable.

I found no use for this book, except as ... The text is boring. There is no explanation, just a set of phrases that most of the time seams to be lost in the context. From chapter one to three there is nothing useful. Some diagrams and descriptions after Chapter 3 but everything is to much vague. For me this is more a review or collection of white papers than a book.

I agree with some other reviewers about the unnecessary history of UML: that doesn't fit the prupose.
I found the contents pretty useful (not everything is for novices), but the editing is really bad: almost every reference to a figure is 1 or 2 pages away.
I paid 24 dollars for this and I don't regret.

This is NOT the book you want if you are just starting to learn about UML. I bought it for that purpose, and found it useless.
I'm selling it now, and will use the proceeds toward Martin Fowler's book, UML Distilled.

I agree with one reviewer who said this book may be reaching the wrong audience. This is not for beginners, it's a reference for those who have pre-existing knowledge but who need to review from time to time, when we come across something new or complex. This book belongs at work with everyone designing in UML.

If your just beginning with UML, you may still benefit from this, but don't expect this to be an intro course to UML.

if you start learning UML, this is absolutely not a good pick. The orgnization of this book is poor. Some parts are reiterated more than 3 times, some are seldomly mentioned.
Too many messy diagrams makes readers like me confused.

My first reaction to this book after I started to read it was accckkk. The first two chapters are absolutely horrid, they read like someone's class notes from a seminar that were only meant to make sense to them. The intro is the usual waste (I really wonder why nutshell books have them... Who cares about the whole history of UML...If I care I'm sure I can find it on the net somewhere).

If I had it to do all over again, I'd still buy this book, if only for the tutorial. I've been using UML for a little while to illustrate points, but decyphering the writing of people who work for Rational is always a challange. They tend to use the long wordy circular sentences that may be useful for achedemic discussions, but really aren't good for doing actual work. The writing style is easier than those for sure but its somewhat strained. I can't quite put my finger on it. I could care less if its correct grammar or not as long as I get the point. The problem is a lot of the writing gives me pause. I understand in the end, but its unnatural.

My next major gripe is with the editor. If you have a reference to a diagram it should be on the same page or opposite page as the text. I can understand if you introduce it the page before but if I have to turn two pages to look at the diagram you're referencing, its pretty darn annoying.

You'll definately need more than this book to learn UML and more than this book to practice it, but it has its place. Its just a pity that there isn't much of an alternative.

Personally, as someone who knows UML already and does a great deal with Tech Writing, this book is a wonderful reference guide. It presents UML cleanly without the fluff I have seen in many other books of its type (hence its low cost and small size).

I would hate to try and learn UML from this book, but it isn't meant to be a teaching guide: it is meant to be a reference book. It is not meant to be a book about software design, or about software engineering, or about project management: it is meant to be a reference book in UML and in that task it succeeds wonderfully.

I bought this book on impulse in a walk-in bookshop, something I normally never do (sorry, Amazon, I couldn't wait).

My instinct proved right : for a working developer, this book has much to recommend it: careful argumentation, extrememly useful examples and rigorously disciplined language.

Each chapter is a first-class reference on the modelling technique concerned, and because all examples relate to the same system, you quickly get to see how the various views relate.

If the book appears wordy, take a careful look at it's size. :-)

The only difficulty I had was in relating the author's analysis of software development phases to those defined in project execution processes we use in our work, but the latter lie well outwith the author's control.

I suspect that had other reviewers read this book right through, they might have been a little more generous with their praise.

A useless compendium of high-sounding abstractions, by and for complete ivory-tower computer scientists. Nowhere are any concrete examples given. The defense that "this is not a book for beginners" is nonsense. Even highly experienced practitioners need clear explanations and specific examples. The GOF patterns book and the Fowler refactoring book are also computer science texts, but they always give actual examples of what they are talking about. I get angrier every time I pick up this book and try to make practical application.

If the purpose of communication is to promote understanding, this book widely misses the mark.

I own plenty of programming-related books, and I think I can recognize a good book when I read one. This is not one of those books, which is surprising in an O'Reilley Nutshell book. Certainly it covers the basics and essentials of UML, but most of the substantive information is in bulleted lists, surrounded mounds of useless prose. Here's a typical example:

"To deliver valued solutions (maximum quality and minimum cost within the minimum time), organizations must capture (acquire), communicate (share), and leverage (utilize) knowledge. The value of a solution is determined by the quality of the product or service, the cost of the product of service, and the time needed to produce the product or deliver the service."

This paragraph may seem rather innocent by itself, but after about ten pages of this I began to feel physically ill. Nothing life-threatening, mind you -- just a little nausea. Closing the book for several minutes made the feeling go away, and reading the book again cause my symptoms to return. Reading a different programming book did not cause my illness to return. So I placed "UML in a Nutshell" on the shelf and have felt fine ever since.

I then purchased a different book to lean UML.

This book looks like the author just copied the text from a series of PowerPoint slides. The vast majority of the text comes in the form of bulleted lists, and any text outside that is repetitive, echoing either itself or the lists. The lists themselves are poorly organized: information that is hierarchical in nature, is not presented hierarchically. (Instead, it's just presented as a sequence of lists.) So as a result, this text is useful neither as a reference, nor as a tutorial.

I'd give this book only a half star if that were possible. The half star would be for the following useful information from the book: (1) the table of contents provides a quick overview of UML, (2) there's an appendix with "web resources". This amounts to about 5 pages of useful content.

If you want an introduction to UML, I highly recommend Martin Fowler's "UML Distilled". If you want a reference, there's the User's Guide and Reference from Addison-Wesley, plus the web site...

Save your money. Do NOT buy this book!

This book focuses on how to create effective and correct UML diagrams, not on software design, not on software design. I use this book as a reference when I want a concise explanation or clarification on how to depict an idea in a UML diagram.

Most of the information is presented as an outline of key points--there is little fluff or detail. I attend many lectures and seminars and actually enjoyed that format, but it can be disconcerting to readers.

Part I of the book provides a short overview of UML and OO that I often refer to people just becoming familiar with the concepts. While the information can be found in many texts, its conciseness seemed to give me new insights.

Part II provides a brief tutorial in UML. Inasmuch as one cannot effectively learn how to model by just reading a book, if you are new to software design you will probably want a book with more examples and diagrams. However, if you're familiar with modeling techniques and have been exposed to UML, this section offers a very condensed summation of the purposes and construction of UML diagramsm.

Part III is the "quick reference" section. Each diagram type is covered by a chapter along with a chapter on overall diagram organization, UML extension mechanisms, and even the Object Constraint Language. As mentioned before, each chapter is brief, concise, and highlights key points. I find it helps me focus on the key points of the diagram which I find valuable when I'm in the middle of diagramming and am not sure how exactly to express something.

If you are looking to learn UML, this is not the book to buy. However, if you are looking for a reference to help you use UML appropriately and consistently, this is an excellent reference to keep within arms reach.

I started UML with this book and immediately switched over to Martin Fowlers book, but later when I got a good overview of what UML says then this book was a real reference (quick reference). Thanks for Alhir for avoiding me to read what UML Specification says.. But it would be better if the chapters regarding Object Oriented Concepts avoided for a true UML quick reference in a nutshell

Err, I blasted this book in a previous review a year or so ago. Its not all that expensive and you should buy it. I find myself constantly refering to this book rather than other books. I didnt learn UML from this book :-) but I sure do use the bulleted lists alot now.

I own most of the O'Reilly books, so I'm a bit biased: I think they are great. Except for this one. I keep checking to see if the publisher really is O'Reilly.

Here are the major problems with the book:

1) The title says "In A Nutshell", yet the book is 273 pages long. Which would be fine if all of that space was needed to cover the material in nutshell fashion. It isn't, by a long shot. To fill that much space, the text resorts to repeating the same thing sentence after sentence. Here's an example: "Problems and solutions occur within a context. The solution to a problem must be understood in order to be constructed and utilized. The solution must be organized in order to facilitate its realization and adhere to the various constraints of the context (available computer systems, development time, etc.) in which it will be realized. To solve the problem, appropriate knowledge about the problem and solution must be captured, organized around decisions regarding the problem and solution, and...." Shall I go on? It could be summarized with "You need to understand the problem and proposed solution". Which is better, but for that matter why is *any* of this found in a book called UML In A Nutshell?

2) The writing betrays a lack of knowledge on the part of the author of what is important and what is not. As a result, everything is included and nothing seems important. Here's the author's biography from the back of the book: "Sinan Si Alhir has breadth and depth in all phases of the systems development life cycle. With experience in high-level and low-level project work, and his broad and deep knowledge of technology and methodology, he focuses on delivering quality solution-oriented results within various application domains using a multitude of technologies and methods." This is absurd, and could be reduced to "Knows everything about everything." Is that what they really were trying to say? I'm sure the author is skilled in some specific areas. But you'll never discover what those are from this bio.

3) Perhaps you are thinking that criticing the bio is unfair. It would be, but the text is even worse. Here's an example: "Our effort will be organized (life cycle) as a series of (possibly concurrent) steps (activities) so that it may be managed to develop the resulting information system." Huh? This takes obtuse to such a level that I can't even think of a simple sentence to summarize what they are trying to say.

4) Now when I tell you that about 80% of the text is in the form of bulleted lists you may be thinking "Good, who cares if the text is bad when most of the book is bulleted lists". OK try this example, which gives just a few of the dozens of bullet points that follow the heading Models:

* Are blueprints of systems used for system construction and renovation

* Are used to understand and manage complexity within systems

* Are used for communication and assurance of architectural soundness

* Capture knowledge regarding a system or context

* Represent knowledge of problems, solutions, and the contexts in which they exist and are addressed ....

You can't assimilate that many bulleted items without supporting text, and if you could you just download the spec and save the $30.00.

My suggestion is either save the $30.00 or spend it elsewhere.

This book is miserable, but I will probably keep it, simply because of its size and shape (useful like one of those little pocket dictionaries.) The diagrams are nice and the final 1/3 is organized well. The rest is horrid.

I am comfortable with UML and, most importantly, it's application in a process environment to substantial development projects. I seriously doubt the author has ever broken out of the campus viewpoint.

The writing is repetitive and annoying. It is annoying to read this book. Each sentence repeats the prior sentence is a slightly different way that becomes annoying. The book repeats the same information in an annoying manner...sorry, apparently it is contagious. Dont laugh, this paragraph could very EASILY be in the book somewhere.

With writing like this there is no wonder as to why bulleted lists where used. I am willing to bet the book will soon be replaced or overhauled because it does not live up to the O'reilly legacy. Wait for the coherent, excuse me, second edition. For a true idea or reflection of the book's content please read the "about the author" section at the end of the book.

If you are new to UML, look somewhere else. If you know most of the buzzwords, look for an applying book (like Larman's Applying UML and patterns.) If you are tired of lugging around 700+pg spec., the user's guide, and UML distilled then pick up this book for the quick reference value.

This book is a very difficult read and not for novices. I bought it when I needed to understand UML for the first time and I am afraid that it failed my expectations. In the end I forced myself to speed read through the whole thing just to get some kind of overview. I suspect some of it penetrated my subconscious, but not a great deal, since a large portion of the book is bulleted with incomplete sentences. I now use it as it was intended to be used, as a reference guide, for which the book partially succeeds. Even so, I have not found a single UML book that is both informative and exciting. They are usually one or the other.

While the opinion of others seems to be that this book was a waste of their money, I thought it was well worth it. I've read quite a number of UML books and just about gave up and started reading the spec itself. Then I found this book and thought it was great!

There are clear examples in the front and the reference sections were great in getting my feet wet. If I need more information then I'll read the spec.

This is a great book if you are just trying to get your head around the UML.

UML is yours for free in a 700+ page specification available as a pdf download from the OMG management group. I was attracted by the fact that what I expected would be a torturous journey could be reduced to the 260 pages by O'Reilly in an inexpensive handbook,"UML in a Nutshell" . I was also curious if the book was being 'thumbs downed' by Amazon customers reviewing the book because of the difficult nature of UML or because of how the topic was being presented in the book. I haved concluded it has been a bit of both.

I took a careful look at the comments of reviewers who have all extensive experience with UML.Most conclude that the text is comprehensive, not a small feat in 260 pages. Of these pros, not one stated the diagrams were inaccurate. (Of the 140 pages I read I found the presentation of the diagrams very instructive). I conclude that the experienced user is so happy to have a comprehensive 'pocket handbook' for UML and is so confortable with the UML syntax that they find the weakness in the writing style of minor consequence.

On the other hand, the mass of technophiles that have various intermediate levels, who always expect a book to present information in a clear fashion hits headlong into what they perceive as serious weaknesses in the writing style. Mix this with a dastardly hard subject matter and you have a recipe for a closed book and bad review.

On reading further into the text I found that the writing style problems occured with varying frequently but were not pervasive throughout the text. Some of the most annoying aspects of the presentation were unfortunately placed right where first impressions would turn many readers off.

The book gets off to a bad start in the Intro using the patronizing approach popular in some training camps, colleges and modular courses where the first paragraph is dedicated to telling you what you'll understand after reading the module. I never liked being told what I will know after reading something. I'll know what I'll know!" This approach to the chapter header is only used in the first three chapters.

Then there's the big criticism of the text being bulleted to death. This is most evident in the Intro which probably should be bulleted to the appendix or beyond. Better though, would be to rewrite the Intro chapter in carefully worded prose. When the author uses this bullet style, he does so with way too many points attached. As c_barron put it "After reading a dozen bullet points, all incomplete sentences that don't even sound right unless you make a mental note to repeat "The UML" before it, you tend to lose track of what the author's point was to begin with".

// c_barron is a customer/reviewer of the book at the Amazon site

The UML Big Picture is the second chapter, is bulleted less and is easier to read. This would probably have been better as the first chapter. Here the author uses another technique that is distracting. As _rread put it, "I completely (totally) concur (agree) with the other reviewer's assessment (review) of the book in listed on this page. If you find this style of writing annoying (aggravating) then you will not enjoy (like or appreciate) this book."

// _rread is also a customer/reviewer of the book at the Amazon site

What _rread is describing is the provision of another term meaning the same as the first in brackets. I think we know where the author is coming from. In this highly defined verbal environment he is giving in brackets a formally accepted alternative word to describe the same thing. This can be good or annoying depending on your perspective. I found on reading sections a second time I was able to ignore these brackets. Let me find you a real quote so you can judge for yourself. I'll use a bullet from what I think was a not too popular Intro chapter.

"The UML - Is a language. It is not simply a notation for drawing diagrams, but a complete language for capturing knowledge (semantics) about a subject and expressing knowledge (syntax)regarding the subject for the purpose of communication. "

When a subject is so 'languagey', it might be better to pick a word, go with it leave the alternatives out.

In some chapters the author sounds like he is studying for admission to the bar using a form of repetition. This is a long but good quote to show this. [page 112]

"The Class concept is an instance of the metamodel Thing concept. Classes are a description of a set of objects with common structural features, behavioral features, relationships and semantics. They are used to model a set of entities with common characteristics. The Object concept is an instance of the meta-metamodel Thing concept. Objects are instances of classes. They are used to model particular entities. The Association concept is an instance of the meta-metamodel Thing concept. Associations are descriptions of a set of links with comon structural features, behavioral features, relationships and semantics. They are used to model a set of relationships that relate two or more other entities where the relationships have common characteristics. The Link concept is an instance of the metametamodel Thing concept. Links are instances of associations. They are used to model instances of relationships that relate two or more objects. Associations relate classes and Links relate objects. "

Although there is some merit in this technique would it not be better to collect similarities where convenient and get the relationship between the concepts out front. For instance,

In UML, the concepts of the Class, the Object, the Association and the Link are all instances of the meta-metamodel Thing concept. Associations are used to relate classes and Links to relate objects.

Classes are a description of a set of objects (with common structural features, behavioral features, relationships and semantics). They are used to model a set of entities with common characteristics. Objects are instances of classes. They are used to model particular class entities.

These are the author own words, just less of them and focused differently..

Another chapter that was good was the Tutorial. The chapter on Object Orientation was a little weak. I teach object-oriented programming, but still had a hard time relating what I knew to the what being conceptualized in this chapter. In fairness to the author, I believe this is due to the terminology the 'three amigoes' have selected to package generic object-oriented programming in the UML.

But there my criticism ends. I'm glad I have the book. The one chapter I read from the Quick reference section was just right. I know if I was trying to design something in UML the Quick Reference chapters 6 to 16 would be a quick, concise and handy summary of the rules and details of the given topic area which would assist in getting the diagrams and symbols of UML right.

Conclusion

In conclusion I think 'UML in a Nutshell' is an excellent effort to provide a synopsis of a very large and difficult subject area. I think the book was ready for prime time in terms of content. Perhaps out of haste or exhaustion or who knows, the book went out the door in a somewhat beta condition from a language point of view, another small irony.

I had an amusing afterthought. The manuscript was submitted to proof reader's at O'Reilly to review but none of them could stand UML enough to get through to discover the grammarical weaknesses! I, for one, would not blame them for failing in such a quest!

This is a great book, still in the rough, and I would encourage the author (or one of the O'Reilly editors) to refine it into a classic for the next edition.

I think the people who reviewed this book, tried to learn UML from it. Bad idea. This book as it says on the cover is a "desktop quick reference". Its good at that. Buy this book as a reference not as a tutorial.

This book is aptly named. Like most nutshells, it is all but indigestible. A much better overview of UML is Martin Fowler's "UML Distilled".

As some readers already mentioned, it is not a book for someone who wants to learn UML. The introduction example is quite helpful but afterwards it is just full of "PowerPoint"-slide-style (PPSS) description.

Like other books in the "Nutshell" series, this is not a suitable vehicle for learning UML, nor is it a comprehensive reference. As other reviewers have noted, Alhir's material is like the handout from a presentation: mostly bullet points but fairly well structured. I recommend it as a first place to look before consulting your primary sources.

Reviewing books about the UML is challenging, because it's often hard to separate flaws in the presentation from shortcomings in the UML itself.

It is disappointing to see all the bad reviews this book received. I wonder if this book is reaching the right audience. I believe that most of the bad reviews come from people with little to no experience in UML. Also, don't forget that UML is a concept, a way of thinking. You can learn UML, but that doesn't mean that you understand the full concept. People who are confused, and are lost when they read the bulleted points in this book may write some of the bad reviews.

This book is not for those who are planning on starting to explore UML, or for those who are not comfortable with using the concept. Don't expect to get up and running quickly in UML-based design by reading this book. You have to understand object-oriented analysis and design and the modeling techniques in the UML.

Although the book has editing errors and needs improvement, it is definitely a good reference for anyone with a firm foundation in UML. It is punctual, quick and easy to handle, with coverage of all the concepts.

After UML Distilled (ISBN 0-201-65783-X), this is a good guide to have.

I have bought the book a few months back and I am not fully through. As a software professional and teacher, I think this is a different kind of effort. I have got an Indian edition of the book and low-priced editions of both the UML user's guide and reference guide by the Three Amigoes are also available in India. I do not think this book can pose any competition to the Three Amigoes' books. But as a short and quick reference it should serve some purpose.

The numerous errors however should not be ignored. O'Reilly or no O'Reilly, I really do not think that any good book should contain so many errors. The errata, which I found in O'Reilly's site however, is a good compensatory effort.

Regrettably this is one of my books in UML (just because it is from Oreilly). A piece of advice to the author: take some time to strengthen your UML background -- playing around with words is the not the way to write a book.

Are you looking for a book on UML, go somewhere else...

Using bullets are good for making points clear, but not as default font for a book. And content should be refined if this book is to deserve the nutshell title from Oreilly. This is probably the worst book on computing that I have ever read, and hopefully it will be for some time. It was very disappointing compared to the usual Oreilly standard.

Found it unreadable, gave up. Two problems:

1. Excessive use of bulleted points, where prose should be used. Everything is lists, which can't build up an idea like a paragraph does. They seem to repeat points, and you can't retain this info.

2. Extremely vacous business buzzwords used throughout.

I thought this book would be up to the usual O'Reilly standards. I was wrong. Don't bother.

UML In a Nutshell should be about half its current size. It's full of verbiage that doesn't really add anything. The book should "cut to the chase" and get stuff accomplished up-front, rather than wax philosophical in bureaucratese for the first three chapters.

Bits like "The problem occurs within a business context (domain or space). The solution must be realized to fit within the organization's information technology infrastructure (domain or space)." [p16] should be taken out and shot with the bullets from the neighboring pages. I mean really, who cares (domain or space)?

You can open this book at random and find pretty much the same kind of writing.

Sorry. At least it wasn't that expensive (domain or space).

`UML in a nutshell' is a book I do not like. The terminology used deviates from what is commonly used in all other books on the subject. I disagree with the sequence in which the author presents the material and find his introduction to OO one of the worst ones I have ever come across. Trying to capture all of the UML in such a small book resulted in the book containing information that is only mentioned and not explored, leaving the reader confused rather than enthused. Finally, what does not help at all is the heavy use of bullet points throughout the book, which is a characteristic of the bad style this book is written in. I apologise to the author, maybe he is brilliant at what he does for a living (one never knows), but a technical writer he is not. END

Densely written to the point of being unreadable. I've been working with UML for a while and was looking for a more complete reference, but this isn't it. It doesn't even adequately or reasonably explain what I already knew, and is sometimes downright contradictory in its use of terminology. O'Reilly must have really been asleep to put their name on this worthless exercise. My other O'Reilly books are the best and most useful references I've ever had, but this does not deserve to be in the same company.

What can I add to the remarks made by all the other one-star reviewers? Not a lot. I could bullet-point all their comments. This would give prospective purchasers a glimpse of what they are letting themselves in for. Like some of the other reviewers, I have come to regard O'Reilly's Nutshell series as a quality source of information. This book provides a sharp lesson in taking things for granted. NEVER AGAIN. I can only console myself with the thought that the bookwas not too expensive a mistake.

This book was extremely significant to me, and reading it was a very positive experience. However, I cannot take issue with a lot of the comments posted thus far for this book.

I have read Grady Booch's UML User's Guide, the UML Specifications, James Rumbaugh's OMT Book (from 91), and Desmond D'Souza's Catalysis work. Though I have plunged through each work at least twice, there were still some significant missing links, and this book was a great help in filling many of these in (how Use Cases relate to Sequence & Coll. Diagrams; how Use Cases can use signals (Statechart events); and the real difference in Statechart and Activity diagrams).

For those who wanted a quick course in UML, with some well thought-out examples... I can understand their disappointment. It is unfortunate that the online purchasers could not read the author's preface, which states that the reader should have UML experience before diving in. It is a quick reference, not a tutorial, and that difference is huge. I own the Java in a Nutshell book, and I _could not_ learn Java from it... it was useful only after I discovered the basics somewhere else. So I believe O'Reilly stuck to their original Nutshell philosophy, and should not be attacked for not handholding every beginner.

I quite enjoyed the first few chapters, which were a metamodel of terms that underly the entire structure of problem solving... an interesting philisophical discussion worthy of three or four reads (and worthy of its own book)! The UML introduction chapters were far too short to be of use (as anyone who has tried to read or write a comprehensive example in UML will notice). However, the reference chapters on the individual UML elements are written well... the bulleted lists and removal of examples make for a quick, uncomplicated, unclouded read. You can always hope for more (any UML book under 500 pages that claims to be comprehensive is suspect... UML is sooo powerful, its applications are illimitable), but for a light 250 page, $20 book, I was quite satisfied. Find a bookstore, flip through chapter 2 and the reference chapters, and see for yourself.

When in the field using UML, I have my notes from Booch's User Guide, and a copy of this book.

I was gonna buy this book until I got hold of my co-employee's copy. This book is so BORING that I gave up reading it after 2 chapters! I would usually have a quick glance at all the pages of a book to get rough idea on what the book is all about. But this time, I came up with nothing. The presentation style is so AWFUL it doesn't matter anymore what's inside the book!

I bought this book mainly going by the O'Reilly name which usually has excellent books (Java, Motif), but this book is like listening to a theoretical computer science prof. drone on and on... It literally took me three months to get through just chapter two. I kept falling asleep every time I tried to read it! Most of chapter two consists of cut-and-pasted bulleted lists each one defining a zillion terms w/o justification. So, we don't say 'acquired', we say 'captured'. Great! Can you say 'pedantic', boys and girls?

Bottom line is that when an author keeps using big obfuscated words for no good reason where simpler ones would do (e.g. 'facilitate' v/s 'ease') you know you are in trouble. He is obviously writing to impress his colleagues, not to educate his readers...