Changes made in the UML1.4 printing

Many thanks to those who have reported bugs and suggested improvements: please continue to do so.
Page Where Change Comment
Front cover Top 1.3 -> 1.4
Back cover just below the John Salt "UML1.3, released in June 1999" -> "UML1.4, released in February 2001"
Back cover Top line of Features UML 1.3 -> UML 1.4
Back inside cover Top left Chapters 7 and 8 -> Chapter 9 Sorry: collaboration diagrams are in Chap. 9 (not 7 and 8)!
xvii l3 Replace "http://www.awl-he.com/computing" by "http://www.booksites.net" More durable URL
xviii half way down Replace "http://www.awl-he.com/computing" by "http://www.booksites.net" More durable URL
xviii point 1delete the parenthesised "(even here at Edinburgh...question)" Now we have, we do Java!
xviii l4 of last paraC++ or Java -> Java We settled on Java
xix section About the revised edition Replace the text under this heading with:

This printing of the revised edition describes UML1.4, which was released in February 2001. Earlier printings of the revised edition described UML1.3, which was released in June 1999 and formally adopted by the OMG in March 2000. UML1.3 was significantly different from UML1.1, but the changes between UML1.3 and UML1.4 are very minor. For details of all the changes, see the book's Web page.

xx the July 1999 date and the sentence above it Replace the sentence "Most of all... Open University" with "Most of all we thank all our students everywhere, and all the other people who have sent suggestions."; and replace the date July 1999 with March 2001. We both have students elsewhere now, and also want to thank the other people who've send suggestions.
86l6-7in both of the two places where it occurs, replace << implementation class>> with << implementationClass>> Actually this very minor change came in between UML1.1 and UML1.3 but I didn't notice, sorry.
89l-6 to -7 in each of the 4 places where it happens, replace '' (two single inverted commas) with " (double inverted comma) typo
92section 6.6 Visibility, protection
  • add index entries from here to "visibility", "private", "public", "protected", and "package"
  • "+, # and - to distinguish between public, protected and private" -> "+, #, ~ and - to distinguish between public, protected, package and private"
  • "The exact meaning of protected and private" -> "The exact meaning of protected, package and private"
  • "Protected members normally" -> "Protected and package members normally"
  • at end, replace the full stop by:

    : typically, protected members can be accessed from code in the same class or a subclass, package members can be accessed from code in any class contained in the same package.

UML1.4 adds package visibility
125Delete footnote UML1.4 is somewhat clearer than UML1.3, and I no longer think there's any serious ambiguity (remaining problems relate to what it is that's shown in the diagram: technically this is probably not the name of the stimulus, although that's what can be used in constraints. Hence our comment about the selector if it's unambiguous).
135Figure 10.5 Leave the headings and the first two rows alone, but replace the last two rows (Flat... and Asynchronous...) by the following one row, in which the symbol in column 2 is the same as that in the third row of the current table:
Asynchronous -> The sender does not lose control; it sends the message and may continue immediately. The recipient of the message may also become active, if it wasn't already.
 UML1.4 deprecates the half-arrow because the old distinction between flat and asyncronous messages was "subtle and confusing" (3-116).
135para 2 Replace the whole paragraph "UML has defined..." by the following:

If you are modelling a complex real-time system, or a system in which concurrency is important, you may wish to consider using a special variant (or \emph{profile}) of UML designed for such systems. For example, such a profile might define stereotypes for relevant kinds of messages. Describing such a profile is beyond the scope of this book, though there are some links to more information from the book's home page. Even standard UML, though, provides notation for asynchronous messages as described above; see Figure~\ref{chap10diag1}.

another effect of the deprecation of the flat/asynchronous distinction
136Figure 10.6 The two half-arrowheads (labelled chooseModules and email) should be replaced by full arrowheads -> (like the arrowhead on the dotted arrow, but without making the shafts dotted!) UML1.4 deprecates the half-arrow because the old distinction between flat and asyncronous messages was "subtle and confusing" (3-116).
136second Q ("Could we have used...")delete The original Q doesn't make sense now that the distinction has disappeared
136DQ77 Replace by this longer version:

\DQ{ \begin{enumerate} \item Would it ever be useful to use asynchronous messages in interaction diagrams even if the final system was to be single threaded? \item As we mentioned, UML has reduced the number of message variants available in standard UML, on the understanding that more variants can be added when needed, for example in a variant of UML that focuses on supporting the design of real-time systems. What message types do you think might be needed in such contexts, and why? \end{enumerate}}

I would have liked to make the new second part a separate DQ replacing the deleted Q above, but that would have changed the numbering of the DQs throughout the book, which I thought would be too confusing -- we should have numbered them within chapters!
1393rd paragraph, last lineadd ")" at the end of the line typo
162para 2has changed -> changed Reflects the fact that 1.3 is no longer the latest version; there were no significant changes to this area in 1.4
166 Replace the Technical UML Note with the following revised version (also, please fix the spacing: at present the first character I doesn't line up with the left hand edge of the text):

\begin{uml} In fact there are two more designations: protected and package. As for C++ classes, a protected element is available only within the package and to any specializations of the package. However, UML's concept of specializing packages has been much criticized: we are not going to discuss, or recommend using, generalization between ordinary packages. A element of a package which has package visibility is available within the same \emph{immediately enclosing} package, but not more widely. \end{uml}

UML1.4 adds package visibility
188DQ 112 Replace with:

\DQ{Although we show a one-way association between the framework classes \code{CurrentPosition} and \code{Game}, we had a two-way association between \code{Board} and \code{OXOGame}, the corresponding classes in the Noughts and Crosses application. These classes are therefore tightly coupled; it would not be possible to reuse one without the other. Why does this difference in navigabilities exist? Consider alternative designs, and see whether you think this situation is improvable.}

The original version, as pointed out by a reader (thanks!) was not what I meant to ask.
202last line "do" should be "include" A UML1.3 change that slipped through the net
251references 49 and 50 The same three changes in both cases:
  • 1.3 -> 1.4
  • ad/99-06-08 -> ad/01-02-14
  • 1999 -> 2001
now reference the new version