Dynamic Relationships

All of the static relationships (except class hierarchy and collaboration) can be seen as setting the stage information. They determine the scenery and props, the marks that actors use to navigate the stage, the cast of characters , and an outline of the plot. A script actually determines what happens on the stage during the performance of the play. A script is simply a collection of messages sent from actor to actor, interpreted by receiving actors, and resulting in subsequent messaging. On occasion, actors respond to cues other than messages ”that is, signals, such as the ringing of a phone, which is the phone s way of notifying other objects of a change in its state.

Capturing and modeling the dynamics of an application (following the stage metaphor) consists of detailed modeling of scripts and event notification: the two sources of cues for our participating objects.

Scripts

During discovery, we told stories about object interactions. Some of those stories we wrote down on cards; others we modeled with interaction diagrams. Most of those stories exhibited a nested structure, analogous to the way a play is broken up into acts and acts into scenes. Design and implementation activities require that we turn those stories into specifications, program code, or both.

The same tool, an interaction diagram, is used to discover conversational requirements and specify a script. The only difference will be in the labels attached to objects, messages, events, and returned objects. During discovery we want to use, exclusively, domain language in describing our stories. For design purposes, our diagrams should have labels that correspond to actual classes and actual messages as they appear in message protocols recorded on the object cubes. (In the Behavior! tool mentioned earlier, interaction diagrams have color -coded labels: red meaning that the label has not been mapped to an implementation term and reflects user vocabulary, black for user vocabulary that has been mapped to an implementation term, and blue for the implementation term . The diagram itself does not change, only the labels, assuring consistency between our domain and the simulation of that domain we are creating in software.) Figure 9-15 depicts the discovery and script versions of a conversation from the mortgage trust example.

Figure 9-15: The diagram on the left has labels reflecting domain vocabulary. The one on the right is the identical conversation with labels reflecting implementation vocabulary.

Customers, working with developers, spend time factoring their stories into discrete cards with the goal of creating cards that can be estimated (effort required to realize the story in code) and that have a discrete focus. This may require refactoring an ambiguous or overly ambitious story. No intermediary design is required. An XP user story maps to a discrete bit of functionality of a larger program or system and should probably involve fewer than six objects exchanging ten or so messages. Purely as a thought-organizing aid, even XP developers often take the time to sketch a rough interaction diagram as a means of factoring stories and as a prelude to coding. Although not one of the official twelve practices of XP, a quick design session using a whiteboard clearly has a role in clarifying the intent of the story and outlining the participating objects and their interactions.

For example, consider the story card Application form is completed and validated , a story that almost certainly needs to be factored . Figure 9-16 (a “c) shows rough sketches of interaction diagrams that might have been sketched during a conversation ^[4] among developers and the on-site customer. Drawing the diagrams reveals ways to factor the original story. (The story might actually stay intact, and only the tests and tasks completed by the programmers are factored to reflect the design implications of the interaction diagram sketches.)

Figure 9-16a: The original story that, whenever it looks as though a lot is going to happen, is factored with a placeholder for a substory inserted.

Figure 9-16b: Substory: Entry field obtains and validates contents.

Figure 9-16c: Substory: Application form validates self.

Note that the interaction diagrams created as part of the conversation about the story expose a need for object interactions that detect and resolve problems ”error handling.

A final note on scripts: It s quite possible, and sometimes desirable, to implement scripts as first-class objects, as an ordered collection of messages. When told to execute, the script sends the messages it contains, in order; accumulates the results; and keeps track of its own status in terms of its successful execution. This approach adds discipline to a conversation, ensuring that it occurs as it was supposed to, without adding control. The script object encapsulates a conversational fragment, and it s the script object itself that succeeds or fails in its assigned task. As a first-class object, a script can be modified by adding and deleting message objects without the need to recompile the application containing those script objects.

Event Dispatching

Events are cues that can be used by the developer to script object interactions. Side 6 of the object cube lists the events (cues) available for use. Our stories and the interaction diagrams that might have been created as part of the conversation about those stories provide us the information needed to link an event (cue) with resulting messages sent to the objects being cued. The object cube tells us of the state changes an object deems of potential interest to others, and the interaction diagrams note occasions when state changes affect the flow of a conversation among objects.

The interaction diagrams also confirm an important aspect of object thinking: the only object directly aware of a state change is the object in which the change occurs. The double-headed arrow used in an interaction diagram to denote a state change signal must always be directed to the object in which that state change occurs, never to other objects in the diagram. Figure 9-17 illustrates this important caveat.

Figure 9-17: State change notification is always a message to oneself, never to other objects. A state change can trigger multiple messages to other objects, reflecting the contents of the event dispatcher, as shown in the diagram on the left.

All event notification is performed via an event dispatcher located in each object. Event dispatchers must be populated for an application to execute ”that is, each must contain a list of events and must have registrations ^[5] for those events consistent with the needs of the application as expressed stories (interaction diagrams). Because most objects will have little if any interesting state behavior, populating an event dispatcher will be relatively straightforward.

However simple an object s state behavior may be, it would be nice to have some corroboration of the information on side 6 of the object cube and in our stories. Taking the time to sketch a state model can provide this verification. State diagrams are also useful for modeling ( revealing ) constraints on object behavior (see the following major section, Constraints ) and for modeling event-driven (stimulus-response) scripts. A state chart, as devised by David Harel, has become the modeling tool of choice in the object community.

State Modeling

Figure 9-18 shows a state diagram for a mouse and part of a diagram for a mouseManager object. ( mouseManager is a name reflective of a popular operating system environment ”not of object thinking.) The dotted line in the diagram reveals that a mouse really consists of two concurrently operating objects, a movement detector and a button. (Although most mice have more than one button, it isn t necessary for the state chart to model them separately. Scroll wheels and other mouse embellishments are not modeled here but would be additional concurrent state machines within the mouse.) Both objects have very simple state, but the diagram confirms the events that need to be listed on the object cube for each object ” click and out of order for the button; newXYZ and out of order for the movement detector.

Figure 9-18: This Harel state chart depicts a mouse and its composite parts plus a fragment of a mouse manager.

Inclusion of the mouseManager diagram fragment illustrates how object thinking affects distribution of work. Instead of making a complicated mouse capable of generating events for all possible state change combinations, we keep the mouse simple and have other objects assume responsibility for transforming simple events into composite events ”in this case, for generating a double-click event. This example use of a state chart also reflects the XP commitment to simplicity. By separating the generation and interpretation of mouse events, we create objects that are simpler and more composable .

The partial state chart shown in Figure 9-19 shows partial state charts for a mortgage application and an entryField . Assuming that the entry field in question is one of those contained on the form, the diagram represents event registration information that needs to be accounted for and a constraint on the behavior of the application itself:

• Any change in the contents of an entryField object forces the containing application into the nonvalidated state. This means that the entryField object cube must contain a changed event and that the application must register for notification of that event with all of its contained entryField objects.

• The application cannot be funded if it s in the nonvalidated state, reflected in the fact that the funded trigger operates only while the application is in the validated state.

  
  Figure 9-19: Partial charts for application and entry field, from the mortgage trust example.

Unless the developer and customer are discussing an attempt to model a complex event-driven composite object ”a graphical user interface perhaps ”most state modeling is used only for the purpose of helping us think about possible constraints on an object s behavior, to confirm that we have listed all necessary events on each object s cube, or to confirm/reveal the need for one object to register for events (state changes) with other objects.

^[4] An XP story has three parts, card , conversation , and confirmation . The card is the tangible evidence of the story and a place to record information about the story (estimate and priority, for example). The conversation may be verbal or may involve the use of diagrams such as those depicted here. The conversation is intended to expand understanding and to reveal the design behind the story. Confirmation is the acceptance test, written by the user and implemented by the developers, that proves the code accomplishes the desired task.

^[5] Some of these registrations will be made as part of the application initialization process ”getting the cast (objects) ready to perform ”and others will come and go during the running of the application.