Rating: 
Summary: A good intro, decent reference, rip out the first 2 chapters
Review: 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.
Rating: 
Summary: Wonderful Reference Manual
Review: 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.
Rating: 
Summary: Concise, useful and tightly integrated reference.
Review: 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.
Rating: 
Summary: Not a single concrete example
Review: 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.
Rating:
Summary: Find a Different UML Book
Review: 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.
Rating:
Summary: Poorly organized list of lists
Review: 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!
Rating:
Summary: Very good reference for drawing diagrams correctly
Review: This book focuses on how to create effective and correct UML diagrams, not on software design, <em>not</em> 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.
Rating:
Summary: Not for Novices as it is a reference
Review: 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
Rating:
Summary: For a book I hated I sure do refer to it alot!
Review: 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.
Rating: 
Summary: A Mess
Review: 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.
| 
