Customer Reviews

UML Explained

5 star:		(5)
4 star:		(1)
3 star:		(2)
2 star:		(1)
1 star:		(3)

 

 

It is now reasonable to say that knowledge of the Unified Modeling Language or UML is an occupational requirement for software designers at all levels. While there are seemingly countless books that describe how it is used, the number that really explain it are few. This is one of them. With no assumptions regarding prior knowledge in object-oriented principles or the UML, you start with the definition of what a software system is. The next step is the description of the life-cycle of software development, where generalized diagrams are used. Objects and the UML notation to describe them do not appear until chapter three. Brevity in the description is a benefit here. It is reminiscent of the old television cliché, "Just the facts." In only a few short pages, you are brought up to speed on what a software system is as well as the fundamentals of an object and the UML notation to represent them. My experiences in teaching object-oriented programming (OOP) is that students have no trouble with the concepts at all. The difficulty always arises when they attempt to convert it into code, not the initial obvious examples, but the nontrivial real-world ones where design decisions must be made. Therefore, the decision to be brief about objects is the correct one. Use cases are described as the actions carried out by the actors in the system. As no pre-existing knowledge of use cases is assumed, the level here is that of introduction. Once again, the author is right on the mark. The basics of use cases are given, without the unnecessary overhead of a complex system. In my experience with students, the concept of the actions of actors is easily understood, provided it is presented by itself. To use them, it is necessary to have a complex system to model, however explaining them requires only the simplest of examples. After the background of the structures has been covered, the next step is to describe the changes in their state over time. The standard diagrams of flows and state transition are presented using the basic model of a customer login to a web site. Nothing fancy, just the basics needed to get the point across. The final chapters deal with how the parts are put together to make a viable entity. No object is an island unto itself, so the basics of collaboration diagrams show you how to combine your pieces so that they will work and play well together. Learning the UML is like all other complex structures. First it must be explained and then you can learn to use it. The point of this book is to do the explanation part and leave the use to others. In that area it is a complete success and I consider it as one of the top six technical books of the year.

Consider other books if you want to seriously learn UML or OO Analysis/design. A good design notation like UML should be intuitive and is better explained with examples. By reducing or avoiding examples as suggested by the author, the book is left with almost nothing.

Unless you're intimately familiar with the software development process, look elsewhere for an explanation of UML. The author's writing style is much too abstract, leaving the reader wondering what he is talking about much of the time - a major waste of time. Time and again he introduces unfamiliar terms, then "explains" them in yet more unfamiliar terms which are meaningless to those of us "outside" UML.

A very poor book on UML. Many of the descriptions are either lacking in important information, poorly executed, or simply wrong.

One example: pp. 94-95. The activity diagram is supposed to describe flows for a given object, except that object is never given. The text states: "Figure 7-7 shows part of an activity diagram relevant to our bookstore." Gee, couldn't the author have stated which object? Perhaps put a title on the diagram indicating which object? Instead, it is left to the reader to decipher what the author means.

Similarly, the flow of the book is extremely poor. Classes and associations before before use cases? In that, only one page on objects?

Yeah, sure, the book is simple to read but why would one want to read something this simple when it will only set you off in the wrong direction?

I only gave this thing 1 star because I can't give it 0.

This book starts pretty well, but then you realize that it won't really take you anywhere. He abuses the use of "references to previous and future chapters" over and over, many of them are absurd, it almost seems that he had no material and wanted to "fill" the page.
He does use a language that is "readable" to people with no computer background, but that is exactly were is going to leave you: with no real UML background.
If you are looking for quicker and solid results check out "Sams: Teach yourself UML in 24 hours", I normally don't by any "short cut" book meaning "24 hours!", but the way this book was written is an excellent way to provide a good background, foundation, hands-on, technical and practical use of the UML. If you don't have an Object Oriented Design background, this books gives you a good start on it as well.

The title of this book, UML Explained, is rather misleading. I should have known better. The book attempts to introduce the use of UML in the context of the Rational's Unified Process and does it well for *non-technical* readers who are *new* to UML and RUP. In my opinion, the book attempts to define most of the core UML concepts in a more "readable" manner, which leaves people who expect a high level of accuracy rather annoyed. For example, on page 7 K.S. speaks of the five views "UML defines". First, UML does not define these "five" views. Kruchten wrote a paper, "The 4+1 View Model of Architecture" [1995, IEEE Software, v.12] Second, there is a reason why Kruchten speaks of 4+1 Views as opposed to five (the fifth view is redundant but serves to validate the other four) Third, the "design" view K.S. speaks of is really the "Logical" view Kruchten wrote about. And the "Implementation" view is called "Development" view by Kruchten, which expresses its purpose much more clearly. Moreover, there "Deployment" view, K.S. speaks of is the "Physical" view, Kruchten wrote about. These differences are important, because there may be many more views used to describe an architecture, and sometimes *hybrid* views are used. "Deployment View" is on of these, hybrid views- it combines elements that are normally expressed as part of the Logical and the Physical views. From the context, it is obvious that K.S. meant these same views, yet described them inaccurately. The reason I finished the book was that I was stuck in an air plane for five hours, and I felt compelled to find out just what the rest of the book offered. With no bibliography and annotated references it is impossible to nail down all the errors precisely. The list of such "minor" inaccuracies went on.

Yes, the level of accuracy and the level of precision are often inversely related, but the author seems unaware of this phenomenon. Instead, he attempts to offer an "introductory" description at a seemingly high level of precision (why else bother spelling out definitions of commonly used terms). Failing at it, the level of accuracy of the description suffers significantly.

Please, take the time to flip through the book and read some chapters before you buy. If you like what you read, then this book is probably all you need. And I shall be donating it to the local public library becase my shelf space is rather precious. Pity, the book was not titled "UML for Project Managers". Then, the book would have reached its proper audience.

1) Book does a good job regarding with it promises
- Introduction to UML
- UML diagrams

2) Sequence diagrams are step-by-step well explained

3) The lack of code examples make the book somewhat weak

I bought this book on the spur of the moment. I was impressed with Kendall Scott's clear writing style and the good examples. I also liked the introduction. It explains UML in the context of the unified process, with reference to architectural views.

This book is probably not all you want to know about UML. But it is a good, light-weight reference to the portions of UML you'll use most. It explains the what, when, and how.

Mr Scott will like me as well - I own 3 other books he has co-authored. The Fowler book (UML Distilled) covers the same ground, but it is more dense, with fewer examples. What is nice is that the examples in this book builds upon the examples of the second Rosenberg book. See my reviews on the Rosenberg books elsewhere. (Use case driven object modeling with UML).

It's one thing to not like my book. It's another thing to refer to it in terms of "frontal lobotomy."

Mr. Moutray, I'd really like to know what you were thinking when you went off on such an angry tangent. And I'd also really like to know why you think that is so unreadable--specifics, please. Or perhaps you'd rather just stick with a review that verges on personal attack.

Amazon, how did you let this garbage go through, exactly?

I m a beginning of UML and found UML Explained clear, concise, and easy to understand.

This is not heavy into UML, around 100 pages, but it can give readers a good introduction to UML.

Instead of boring you of the syntax, Kendal provides an overview of UML and then reinforce your understanding by walking you through the process with examples.