Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
UML in a Nutshell Paperback – September 27, 1998
Customers Who Viewed This Item Also Viewed
Top Customer Reviews
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.
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 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.
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 :-)
Most Recent Customer Reviews
The Desktop Quick Reference is packed with very detailed definitions of UML concepts and the language's meta...Read more