I found this book overall unclear and misleading. I won't comment on the typing errors, as a few have already been pointed out by the other reviewers.
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.
