14.3 INTERACTION DIAGRAM

14.3 INTERACTION DIAGRAM

An interaction diagram shows how objects collaborate in achieving a use case or a small set of related use cases. Interaction diagrams are drawn at an early stage in a design process as they shed further light on the role of each class and give a more concrete focus to the responsibilities of each class. Since in an interaction diagram you make explicit how a class interacts with other classes, you get a better sense of what methods to endow a class with. There are two types of interaction diagrams: sequence diagrams and collaboration diagrams. Modern OO design software can switch automatically between the two. So you need to explicitly draw only one of the two. In what follows in this section, we will first discuss sequence diagrams and then collaboration diagrams.

14.3.1 Sequence Diagram

A sequence diagram shows in a time-sequenced manner the collaboration carried out by a group of objects to achieve a use case or a small set of related use cases. Each object is assigned a lifeline that hangs below it in the diagram. The time sequencing of the activities related to an object is made evident by placing the activities at different points on the lifeline. Time increases downwards along a lifeline.

In a sequence diagram, an object interacts with other objects by either sending messages to them or by receiving messages from them, as depicted in Figure 14.10. A C++ or Java implementation of these interactions will most commonly consist of one object invoking a method on another object—the argument object—for either eliciting some behavior from the argument object, or for ascertaining the value or status of a data member of the argument object. The purpose of the labels "synchronous" and "asynchronous" on the message arrows shown in the figure will become clear later in this section.

Figure 14.10

The various components of a sequence diagram are:

1. Object icons

2. Lifelines

3. Arrowed lines for interaction messages between two different objects

4. Activation icons

5. Message to self lines

Our examples will make clear the function served by each of these components. But first we must present the rules of syntax to which the different kinds of interaction messages must conform. A message can be one of the following six different kinds:

1. Status message, like the value of a boolean variable, that an object transmits to another object.

2. Name of a method; this is the method that one object invokes on another object.

3. *[iteration basis] method, where ‘*’ is the iteration marker; the named method is invoked on multiple instances of the target object; as to which instances specifically is controlled by the expression inside the square brackets.

4. flag := method, where flag is set to TRUE or FALSE depending on the outcome of the specified method that is invoked on the receiver of the message.

5. [condition] method, where the specified method is executed on the receiver object only when the given condition is satisfied.

6. The special symbol new, which means to create a new instance of the receiver object.

To illustrate the various components of a sequence diagram and the different types of messages in such diagrams, consider the following closely related set of use cases for the internet auction example:

The buyer first examines the max bid posted so far on all the items of interest to him/her. The buyer selects one item and posts his/her bid on that item. If the newly posted bid equals or exceeds the seller' minimum acceptable bid, the seller is notified. If seller is satisfied with the bid, he/she so notifies the auction site and prepares a sales document for the buyer.

We can implement this set of use cases with the following objects:

    A Buyer object    An AuctionList object, this is simply a list      of all the items available for aution    An AuctionItem object (this object constantly    compares the latest highest posted bid with the     minimum highest bid acceptable to the seller)    A Seller object    A SalesDocument object 

Figure 14.3.1 presents a sequence diagram for the use cases described above. The first message shown in this diagram is of the form

    *[ iteration-basis ] method 

As mentioned earlier, the presence of the iteration marker symbol ‘*’ means that the method is to be applied to multiple instances of the target object; as to which target objects exactly, that is controlled by the expression inside the brackets. In this case, we wish to apply the method getCurrentMaxBid() to all the AuctionItem objects in the AuctionList object.

Figure 14.11

The second and the third messages from the top are straightforward invocations of the designated methods on the target objects.

In the fourth from the top message, of form

    flag := method 

we want to execute the method check() in order to set the boolean value of the flag minAcceptBidExceeded.

Going down the lifelines, the next message, of form

    [condition] method 

is executed only after the boolean variable minAcceptBidAccepted is set to TRUE. The next message seeks to set the value of the boolean variable bidAcceptable by running a method check () on self, in this case a Seller object. The next two messages are merely notification messages. Finally, for the last message, notice how when the bidAcceptable variable checks out to be TRUE, the Seller object creates a new object of type SalesDoc.

In the previous diagram, the time order in which the various interactions take place is strict, in the sense that a given interaction between any two objects takes place after some other known interaction and before some other interaction, also known. And even more importantly, each method invocation is synchronous, meaning that after an object invokes a method, it waits for the method to return. We can also say that the method call blocks until the method has finished execution.

But many OO programs are written today using multi-processing and/or multithreading. In such programs, when an object invokes a method in a separate process or a separate thread, it does not necessarily have to wait for the method to finish execution. Such method invocation is called asynchronous. We will now see how an interaction diagram can represent a use case that calls for asynchronous interactions.

Consider the following set of related use cases for a robot engaged in autonomous navigation using its cameras to identify directions to landmarks in its environment:

When desiring to navigate from its current location to a target location, the navigator module must first get a precise fix on its current location. This it must do by locating a certain minimum number of landmarks in its environment and then by triangulating its position from the directions to those landmarks.

As shown in the sequence diagram in Figure 14.12, the MobileRobot asks its Navigator module to get a fix on its current location, which in turn creates a number (in our figure, two, but it could be any number) of LandmarkLocator objects, each of which is responsible for a locating a particular landmark from a list of landmarks known to the robot. Since the computational difficulty associated with the extraction and identification of a particular landmark would vary widely from landmark to landmark, it would be best to spawn the landmark identification processes asynchronously. That would also make it easy to add additional landmark identification processes if necessary.

Figure 14.12

The concurrent processes here correspond to the different LandmarkSeeker threads. And by these threads running asynchronously is meant that they do not block the caller, in this case the method of the Navigator object that spawns the threads.

Regarding the new notation here:

1. The half-arrowhead messages are asynchronous. When such methods are invoked, the caller does not block. Ordinarily, as mentioned before, when a method A invokes method B, A waits for B to return. But when B is launched asynchronously, A does not wait and continues doing what comes next after having launched B.

2. The thin vertical rectangles below the object boxes are called activations or Focus of Control (FOC). To explain this notation, notice the three activations below the box for the Navigator object. The first activation says that the object stays in operation as it is spawning asynchronously the different LandmarkSeeker objects. The second activation takes effect when the return "have landmarks" is received from the first LandmarkSeeker object. During this activation, the Navigator object also checks whether a certain minimum number of the other LandmarkSeeker objects have returned "have landmark." The third activation does the same for the second LandmarkSeeker object.

3. The X below each activation for asynchronously created objects means that the thread is supposed to get destroyed after it has finished its task.

14.3.2 Collaboration Diagram

A collaboration diagram is another way of showing the interaction between objects. In this diagram, you do away with the lifelines of the sequence diagrams. Messages go directly from object icons to object icons. The temporal sequencing of the messages is displayed by assigning a sequence number to each message.

The collaboration diagram for the internet auction example looks like what is shown in Figure 14.13. Note the syntax used for objects:

   objectName : className 

Figure 14.13

where either the object name or the class name may be omitted. But if you omit the object name, you must retain the colon to make it clear that you are using a class name.

Interaction diagrams are not so good at delineating the overall behavior of an object across several use cases. If it is important to show that, you should use statechart diagrams.