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 1 | delete the parenthesised "(even here at Edinburgh...question)" | Now we have, we do Java! | ||||
xviii | l4 of last para | C++ 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. | ||||
86 | l6-7 | in 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. | ||||
89 | l-6 to -7 | in each of the 4 places where it happens, replace '' (two single inverted commas) with " (double inverted comma) | typo | ||||
92 | section 6.6 Visibility, protection |
| UML1.4 adds package visibility | ||||
125 | Delete 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). | |||||
135 | Figure 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:
| UML1.4 deprecates the half-arrow because the old distinction between flat and asyncronous messages was "subtle and confusing" (3-116). | ||||
135 | para 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 | ||||
136 | Figure 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). | ||||
136 | second Q ("Could we have used...") | delete | The original Q doesn't make sense now that the distinction has disappeared | ||||
136 | DQ77 |
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! | ||||
139 | 3rd paragraph, last line | add ")" at the end of the line | typo | ||||
162 | para 2 | has 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 | |||||
188 | DQ 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. | ||||
202 | last line | "do" should be "include" | A UML1.3 change that slipped through the net | ||||
251 | references 49 and 50 |
The same three changes in both cases:
| now reference the new version |