Chapter 5: Object Interaction

Using Interaction Diagrams

From the diagrams, designers and developers can determine the classes they will need to develop, the relationships between the classes, and the operations or responsibilities of each class. The Interaction diagrams become the cornerstones upon which the rest of the design is built.

Sequence diagrams are ordered by time. They are useful if someone wants to review the flow of logic through a scenario. Although Collaboration diagrams include sequencing information, it is easier to see on a Sequence diagram.

Collaboration diagrams are useful if you want to assess the impact of a change. It's very easy to see on a Collaboration diagram which objects communicate with which other objects. If you need to change an object, you can easily see which other objects might be affected.

Interaction diagrams contain:

Objects An Interaction diagram can use object names, class names, or both.

Messages Through a message, one object or class can request that another carry out some specific function. For example, a form may ask a report object to print itself.

One thing to remember as you create the Interaction diagrams is that you are assigning responsibility to objects. When you add a message to an Interaction diagram, you are assigning a responsibility to the object receiving the message. Be sure to assign the appropriate responsibilities to the appropriate objects. In most applications, screens and forms shouldn't do any business processing. They should only allow the user to enter and view information. By separating the front−end from the business logic, you've created an architecture that reduces the ripple effect of changes. If the business logic needs to change, the interface shouldn't be affected. If you change the format of a screen or two, the business logic won't need to be changed. Other objects should be assigned appropriate responsibilities as well. For example, if you need to print a list of all flights in an airline's schedule, flight #1020 shouldn't be responsible for that. The responsibilities of the flight #1020 object should focus on just that flight. Another object can be responsible for looking at all of the flights in order to generate a report.

Another way to look at responsibilities is to consider the entity, boundary, and control categories we discussed earlier in the "Finding Objects" section. Entity objects should hold information and conduct business functionality. Boundary classes (forms and windows) should display and receive information, but should also do minimal business processing. Boundary classes (interfaces) should send information to another system or receive information from another system, but again do minimal business processing. Control classes should take care of the sequencing.

Sequence Diagrams

Let's begin by taking a look at Sequence diagrams. Sequence diagrams are Interaction diagrams that are ordered by time; you read the diagram from the top to the bottom. As we mentioned above, each use case will have a number of alternate flows. Each Sequence diagram represents one of the flows through a use case. For example, Figure 5.3 is the Sequence diagram that shows John Doe purchasing a ticket for flight #1020.

164

Chapter 5: Object Interaction

We can read this diagram by looking at the objects and messages. The objects that participate in the flow are shown in rectangles across the top of the diagram. In this example, there are a number of objects: the flight search form, flight list form, fare information form, credit form, and confirmation form are all client pages that are displayed to the end user. The remaining objects constitute the server−side logic and include server pages, interfaces, and other server−side objects. Notice that some of the objects have the same name as their classes. It is not necessary to name the objects differently from the classes.

Figure 5.3: Sequence diagram for purchasing a ticket

The process begins when John Doe selects his departure and destination cities and departure and return dates. The FlightFinder server−side object looks for flights that match the criteria and builds the FlightListForm, which displays all matching flights. John selects his flight, and the FlightDetails server−side object looks for fare information for that flight. Once fare information has been retrieved, it is displayed using the FareInfoForm. John confirms the rate, and the CreditForm is displayed. John enters his credit information, and the CreditProcessor object interfaces to the external credit system to confirm John's credit. Once the credit has been confirmed, a seat is reserved, the confirmation number is generated, and the confirmation is displayed to John.

Each object has a lifeline, drawn as a vertical dashed line below the object. The lifeline begins when the object is instantiated and ends when the object is destroyed. A message is drawn between the lifelines of two objects to show that the objects communicate. Each message represents one object making a function call of another.

Later in the process, as we define operations for the classes, each message will become an operation. Messages can also be reflexive, showing that an object is calling one of its own operations.

The Sequence Diagram Toolbar

When a Sequence diagram is opened, the Diagram toolbar changes to let you add objects, messages, and other items to the diagram. Table 5.1 lists the buttons available in the Sequence Diagram toolbar and explains the purpose of each. In the following sections, we'll discuss adding each of these items.

Table 5.1: Icons in the Sequence Diagram Toolbar

165