Fast Track UML 2.0 (英語) ペーパーバック – 2004/3/11
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
* Examples are easy to understand; diagrams aren’t overly busy.
* Written in user-friendly style author is known for.
* Condensed, distilled presentation of the UML Superstructure document will get you up to speed with UML 2.0.
From the reviews:
"This is a book that focuses pretty much on the core elements of UML 2.0. … if you are looking for a fast introduction to the different UML 2.0 constructs then this is a good place to start. The book makes good use of diagrams … . pictures are supplemented with concise text detailing what the diagram is modelling and how it is used. … This kind of material adds value … ." (techbookreport.com, May, 2004)
"This really is a fast track to UML 2.0. It explains the logic of each component of the design method, how to draw diagrams, and what each entity is all about. … this is a fast, efficient and clear way of finding out the details of UML 2.0" (Ian Elliot, Visual Systems Journal, June, 2004)
Below, a few samples of what I mean:
1) Page 9, on attribute property: "... readOnly, which indicates that you can add possible values for the attribute, but you can't change existing values". I am not sure I understand this and I am not sure it's correct. Correct definition, according to the UML Reference Manual Second Edition, page 555, is "A keyword of changeability indicating a property whose value may not be modified after initialization". Period.
2) Page 10, on parameter direction: "out (The operation sets or changes the value of the parameter and returns it to the caller.)". Then, "inout (The operation uses the value of the parameter and may change the value; the caller expects to see an inout parameter again.)". If in both cases the operation changes and returns the parameter to the caller, then what's the difference between the two types of parameters? Here are the definitions provided by the UML Reference Manual, respectively at pages 503 and 397: "Out parameter: A parameter that communicates values to the caller using side effects on the parameter calling mechanism". Then, on "Inout parameter: A parameter used to supply arguments to the called procedure and also return values to the caller using side effects on the parameter itself". The latter set of definitions is crystal clear to me, whereas the former is not.
3) Page 10, on default value of a parameter: "A default value of a parameter for an operation means that each call to that operation includes that value for the given parameter." I don't think so. Again, UML Reference Manual, page 307, gives the proper definition: "A value supplied automatically for a parameter if no argument value is provided".
4) Pages 29-30, Fig. 2-10, Aggregations: Here we have an aggregation example where "... an instance of the Order class that aggregates one each of instances of the ShippingInfo and BillingInfo classes and one or more instances of the Book class. An important property of aggregation is that the aggregated classes are still basically independent of the aggregating class. In other words, when a particular Order goes away (because it's been archived, for example), the ShippingInfo and BillingInfo instances that were aggregated to that Order are still present in the system. (The Book instance, of course, is gone.)". Why is the Book instance "of course" gone? Taking into account that the Book class is shown having the attribute Title only, is this some weird bookstore that sells each book of a kind only once? Or, more possibly, is that another Book class attribute that is not shown and that truly makes a particular book unique in bookstore's inventory, such an inventory number? It's guesswork for the reader that ought not to be.
5) Page 102, on Submachines: "... A submachine state is a state that references a submachine such that a copy of that submachine is implicitly part of the enclosing state machine where the reference occurs". This one seems to be an extract from the UML Reference Manual, page 627, but without the two full pages that follow and that provide clarification and an example to the somewhat obscure definition above.
6) Page 128, on Node: "A node represents a computational resource that generally has memory and often has processing capability." The terms "generally" and "often" implying that they may not, is a computational resource that has no memory and no processing capability still one? Well, apparently yes, because "... Nodes include computing devices but also human resources or mechanical processing resources", as mentioned at page 479 of the UML Reference Manual, but nowhere in this book.
7) Page 129, on Execution environment: "An execution environment offers an environment for the execution of specific types of components that are deployed on the environment, in the form of executable artifacts". I found a more comprehensible definition at page 343 of the UML Reference Manual.
This is a 160-page plus "Fast Track" book supposed to let the reader get acquainted with UML 2.0 quicker than going through the Superstructure Specification. Instead, I spent as much time as if it were a 1000-page book, doing guesswork all the way long on what the author meant to say and kept doing continuous cross-checks with the UML User's Guide and the UML Reference Manual.
Therefore, my unique recommendation to the potential reader: If you need an UML book, better get another one.
I'm just on Chapter 1, and have found so many glaring errors so far that I suspect everything in the book has to be carefully read and re-read to identify the errors.
Examples: page 12 - the definitions for "precondition: and "postcondition" are EXACTLY the same. Page 17 - the graphic does not support the text that the notation for aggregation and composition are different. I suspect that the book was rushed to publication without adequate proofreading, which is too bad because, other than the errors, it's very consice and read-able.
Normally, when a book's title tries to convey that it's going to teach me something "really fast" or "in just XX hours", I won't even pick it up. In this case, from reading a few of his previous books, I trusted that the author, Kendall Scott, had probably put together another good book worth reading, and he did.
I'm a mildly experienced developer with a bit of object-oriented analysis and design (OOAD) understanding. In this book, I was looking for something that would quickly bring me up to date with UML 2.0, while still serving as a good reference manual into the future, as I sit down for some fancy picture drawing, also known as visual modeling. This is that book.
I would definitely recommend this book to anyone looking for a well-written, easy to follow and understand, concise UML 2.0 reference manual. If you're a career designer, note that this book does not describe in full detail, the complete syntax of UML 2.0. That said, if you're drawing fancy pictures using syntax not described in Fast Track UML 2.0, then perhaps that's a sign that you're models are too detailed. If you're brand new to the study of OOAD looking to develop these skills, this book alone probably isn't what you're after, though it would still serve well as a supplement to another material geared towards teaching OOAD. As a bonus, the book is priced well.
Mr. Ng, on the other hand, makes an assertion that is clearly false. The differences between the notations in Figure 1-13 are explained on the previous page; if he wishes to see an expression of which notation is 'better,' he'll have to find a different book. In the meantime, remarks such as 'sometimes you read it with lots of ambiguities come into your mind' is less than useful. With regard to the comment about how 'bad' it was written, I'll just say that at least I know proper grammar.
Same as M. J. Graham, I stopped proceeding beyond half of the Chapter 1. Figure 1.13 shows two examples of provided interfaces, using both notations. The usage differences between the two notations are never addressed.