This document contains clarifications of material in the book: R.J.A. Buhr, R.S.Casselman, "Use Case Maps for Object-Oriented Systems", Prentice Hall, 1996. These follow from the use of this book as a textbook in a graduate course at Carleton University beginning Fall 95 and will be continually updated as new ones come to light. Clarifications try to shed light on parts that students found tricky or hard to understand. Corrections are in a separate document (in file ucmfoos1.txt). Chapter 2- p21, Fig2.9 - Experience has shown that this figure would be easier to understand if the left and right halves of (a) were positioned one above the other, with the boxes that represent the same subsystem joined bottom to top; the same goes for (b). This makes things clearer by showing in one place all the paths that touch one subystem. p26, Fig2.13 - Some arrows in this figure (e.g., send digits, ringing) should, in general, be double ended because interactions can go both ways. This omission is not recorded as an error because the figure, as is, serves the only purpose for which it was intended, namely to provide an example of a certain type of diagram; nothing later on depends on its details. Chapter 3- p43, Fig3.1(c) - This map must be interpreted as representing a single scenario that extends over more than one traversal of paths starting from the same start point. The preconditions and postconditions establish this interpretation, but unfortunately are only implied here, not explicitly stated. There are two alternative preconditions: (1) the system is in an initial state in readiness for new mouse clicks and (2) the system is in a state where it is has received one mouse click and is expecting a second one. The bottom fork from the start point follows the first precondition and the top fork follows the second one. A postcondition of the init segment is that the second precondition is established at the start point for continuing the scenario. p44 - "(OPERATION DOMAIN)" in the main heading and "(Operation Domain)" in the subheadings are not defined until Chapter 4 (this is an artifact of a last-minute change in the chapter order). pp48-49 - "(ASSEMBLY DOMAIN)" in the main heading and "(Assembly Domain)" in the subheadings are not defined until Chapter 4 (this is a similar artifact). pp48-50 - The difference between slots, pools, and data caused a lot of confusion and is perhaps worth restating in a different way. Pools and slots are places for schizoid components with two personalities, one as data and one as operational components (i.e., entities that can call and be called). In the pools they show their data personality. In the slots they show their operational personality. Anything that has only one personality has no use for pools or slots. For example, fixed objects have only one personality, as operational components, and files in a non-object-oriented data base have only one personality, as data. Anything that is only data has existence in use case maps only indirectly: either it is inside some component that manages it (and provides access to it through an interface) or it is flowing along a path. Data may flow along paths and into and out of objects or slots, but it never becomes a slot occupant, it only flows to or from an existing object or slot. Data itself, as opposed to objects that store it, has no explicit existence in our design diagrams. Data only has implicit existence as amorphous quantities hidden inside data objects. These amorphous quantities might represent large numbers of data constants, data variables, and data structures (and even data objects - see the comment on Section 4.6 of Chapter 4) that have been lumped together into a single abstraction. When the design model includes a number of data objects, data elements may move or be copied from one of these objects to another, but these appear in the design diagrams of this book only as parameters that flow from place to place, not as explicit elements of defined data structures. p50, 2nd para, lines 3 and 4 - The phrase "or the component is destroyed on the spot" has the assumed qualifier: "if a destroy arrow is shown". Similarly the phrase "or the component is created on the spot" has the assumed qualifier: "if a create arrow is shown". We assumed this would be obvious to all, but discovered otherwise. p52, Sec3.5.2 - This section does not distinguish between stub instances and stub types. It assumes all stubs are instances. See the comment on p168, Fig8.16 for a discussion of the difference between stub instances and stub types. p53, diagram at the top of the page - We have found that a clearer notation is to use a rectangular box for a stub with the circle-bar stub notation shown here superimposed on it and to identify, by labels, points where paths may enter and leave the stub box. In the simplest case (the only one illustrated in this section), there is only one entry and one exit point, but more general stubs are often useful and this labelling is needed for them. Chapter 4- p65, Section4.6 - Experience has shown that the intended use of the component notation to give a system view of programs, not literal pictures of programs, was not made sufficiently explicit in this and later chapters, with the result that students often mistakenly thought they needed to show all objects in an object-oriented program in design diagrams (or to show all possible slots for objects). Nothing could be further from the truth. In this notation, the term object means only a procedure or data abstraction that we wish to view as machine-like at a particular scale of interest, regardless of how it is implemented. To make the discussion clearer, let us, for the moment, refer to objects in design diagrams as design-objects and objects in object-oriented programming languages as programming-objects. The problem is the sheer number of programming-objects in typical object-oriented programs. Because programming-objects may be used for everything from small data structures to large subsystems, showing them all would populate our world of machines with so many design-objects at all scales that we could be overwhelmed. The philosophy that everything is an object is useful for programming, where it provides a fractal-like self-similarity at different scales that fosters uniform programming paradigms. However, it is not useful for system design, where we want to focus on particular scales, for example, the scale of a system as a whole. The bottom line is that we may have to perform some conceptual chunking of programming-objects (or potential programming-objects if the code has not been written yet) to come up with suitable design-objects at the scale of interest. Then we regard anything inside the design-objects as undefined detail from a diagramming perspective, even if it includes programming objects. This is no different from the conceptual chunking of plain ordinary data that we might perform to represent a non-object-oriented program as a system of machines. In our conceptual world of machines, whether data is implemented with programming-objects or some other way, we regard it as detail that is hidden in design-objects, and we make the design-objects as large scale as we need to understand the big picture. Obviously, there is some creative licence here, but we are talking about design, so this is only to be expected. Chapter 6- p115, Fig 6.13 - There is actually no need for the LoadDrawing path to touch the DrawingView at A8 on the way to the CurrentDrawing slot. It could bypass the DrawingView without any loss of information. To see this, imagine that we implement the LoadDrawing path with the following chain of registrations and notifications: (1) DrawingView registers itself as a dependent of DrawingModel; (2) DrawingModel notifies DrawingView of the existence of a new drawing object; (3) DrawingView registers itself as a dependent of the new drawing object; (4) the new drawing object notifies DrawingView that it must be displayed. At first glance, (1) implements a precondition of the path, (2) and (3) together implement A8, and (4) implements A10. However, what implements A9? In fact, (2) and (3) implement A9 and A8 is redundant. This is because the meaning of moving an object into a slot is exactly that all necessary visibility relationships that are needed in the local context are established. Here, (2) and (3) do this job. A path without A8 that bypasses DrawingView says all we need to know. This discussion emphasizes that there is no cookbook for building good models with use case maps (even the authors don't have one), and identifies a characteristic of a good model: it shows no more than it needs to. p117, Fig6.14 - We have observed that this figure, while not incorrect in itself, is difficult to explain and understand, for several reasons. (1) The reader starts out off balance because the figure unexpectedly shows, not the expansion of the stub in Fig6.13, but the entire path after the expansion. (2) The reader is pushed further off balance by the fact that the words describing the responsibilities are unintentionally different between Fig6.14 and Fig6.13 (although, once this is understood, the relationship between the figures is clear, because the different words in the two figures do not contradict each other). (3) The model of the handles-figures relationships is hard to understand in relation to the system as a whole. The model is a set of teams in the DrawingController, with slots in them for objects: teams because handles and associated figures act as teams while a figure is being resized or dragged by a user; in the DrawingController because we imagined the handles-figure interaction as analagous to ordinary user interactions with the DrawingController. This model requires a mental stretch because it is not obvious that these interactions are logically part of the MVC, or even at the same level of abstraction as the MVC. This model is complex because the treatment of handles and figures is not uniform between the DrawingController and the DrawingView: for the former they are modelled as slots, for the latter as objects that are updated transiently while moving along paths (see also discussion of Fig6.16 below). We decided to model them this way for what seemed like logical reasons, but the difficulty of explaining the model (including its relationship to Fig6.16) suggests it was not a good decision. An easier-to-explain model would have the handles-figures teams positioned outside the MVC, where they could be imagined to interact with both the DrawingController and the DrawingView in a uniform way. The problem arises because we tried to keep the existence of handles and figures as objects explicit. However, remembering that what we are trying to do here is get a system view at the MVC level, the best alternative may be to treat handles and figures as data at a lower level of detail. This discussion reemphasizes that there is no cookbook for building good models with use case maps, and identifies another characteristic of a good model: ease of explanation. p121, Fig6.16 - This figure carries the baggage of Fig6.14 with it. On the one hand, Fig6.16 provides slots for figures and handles in the DrawingController, following Fig6.14. On the other hand, it has no slots for figures or handles in the DrawingView, because it models figures and handles there as objects that have no persistent place, but only display themselves "in passing"; in other words, it treats these updates as details below the level of the MVC. p124, Fig6.18 - This figure can be confusing because it is more complete than the SelectFigure path, which it is said to illustrate, requires, but also less complete than is needed for all possible paths. For example, it includes a visibility relationship that is not required for the SelectFigure path, from the DrawingView to the DrawingController, but does not show that CurrentDrawing must see DrawingView in order to make updates. Chapter 7- pp142-146 - These pages do not seem to give enough warning not to introduce processes too soon. The examples in later chapters try to illustrate the issue, but perhaps it needs to be brought out more forcibly here. The theme of these pages might be stated as: "Let the paths tell you what the processes should be." However, students can easily take this too literally too soon. For example, some students, as soon as they have a major use case path defined through a distributed system, will immediately start positioning processes along the path in teams representing separate computers. They seem to have in mind that, because processes are for concurrency, they should be introduced as soon as there is any hint of concurrency. However, processes should be deferred until all of the important concurrent paths have been identified and composed into a unified map that lays bare the essence of the concurrency requirements (this does not mean that the map has to be complete in the sense that all couplings are defined). Chapter 8 gives an example where a very simple map that identifies all the major paths is used to discover processes. However, it would be a mistake in that example to start introducing processes on the basis of only one of these paths. Chapter 8- p164, Fig8.12 - M, P, and L are intended to refer back to Message, Packet, and Link from Fig8.5. p167, Fig8.14 - Stub boxes with labelled entry and exit points would make this diagram clearer (the labels would provide more explicit linkage between the different parts of the figure). p168, Fig8.16 - The two stubs labelled tx1 in this figure are intended to indicate the same instance appearing in two places (meaning all responsibilities and bound components are shared). More generally, one might imagine that such a notation could be used to indicate different instances of the same type of stub appearing in different places (meaning that the responsibilities and bound components are operationally identical, but distinct). To indicate the later case, we would use different names for the stubs and add textual annotation to indicate they are different instances of the same type (e.g., tx1:txStubType, tx2:txStubType). Chapter 9- p172, Fig9.1 - The call-return patterns on the left of the figure are not intended to be restrictive: processes and ISRs may also be initiators in relation to call-return connections. On the other hand, the remaining patterns are intended to be restrictive, as shown. These things are covered in the rest of the chapter, but not explicitly in this figure, leading to possible confusion. p173, Fig9.2, first row - To include the style of call-return interaction that occurs with monitors, there should be "(reentrant)" after Call-return and an additional row in the table with entries "Call-return (serial)", "Shared", "Round trip", and "Synchronized". (Monitors are indicated by the doubly outlining objects or teams.) Section 9.2.2 - The lack in this book of collaboration graph notations to indicate things like asserting a slot is to be filled or emptied or indicating a call is required to a factory layer to create a new component or destroy an old one has proved to be too restrictive in practice. We now use dashed arrows for the former and, for the latter, ordinary call return connections terminating in a wiggly line symbolizing that the call disappears into an invisible layer. Chapter 10- p192, first paragraph - This paragraph puts an unecessarily narrow interpretation on Fig10.2(a). If the objects in this map are interpreted as data-manager objects that may manage data for multiple internal data buffers, then the map is quite general. p193, Fig10.3 - The repositioning of the reception buffer object from inside the reception process in (a) to outside the process in (b) follows from combining delayering with collaboration graph design. We introduced an ISR in (b) that was assumed to be part of a lower layer in (a). This delayering means that both the ISR and the reception process must have access to the reception buffer, so the buffer can no longer be private to the process. Had we performed delayering in the map first, no change would have been required in the buffer position between (a) and (b). However, details like this are often deferred to collaboration graphs, so the transition from maps to collaboration graphs is not always completely straightforward. p198, Fig10.6(b) - Arrowheads along chained call-return paths are unintentionally inconsistent here. Logically, there should be an arrowhead touching every interface, but in a diagram like this we often leave out arrowheads along chained paths to avoid clutter. However, we unintentionally left some out and not others here, without intending that any meaning be attached to the difference. p202, Fig10.8 - The move arrow into the transmision path at e puts a different interpretation on this map relative to previous MTU maps, but the prose neglects to point this out. The map implies that physical I/O is layered under the txL slots and that a postcondition of the transmission path is that physical I/O is completed. The map could be easily changed to be consistent with previous maps by removing the move arrow at e, but for the structurally dynamic case the diagram as is seems clearer because it keeps all aspects of structural dynamics visible in one diagram.