OOPortal OOPortal


Sequence Diagram   «Prev  Next»
Lesson 5 Mapping events to objects
Objective Assign events to objects.

Mapping Events to Objects

Assigning Responsibility for Events

Once you have arranged all the events from one scenario onto a sequence diagram, go back over the diagram and verify that the purpose of the object corresponds to the events that it participates in. Apply the measure of cohesion to the object. Ask:
  1. Does every event initiated by the object support the object's (single) purpose?
  2. Does every event that the object responds to fit with object's (single) purpose, or is the object being asked to do something that does not directly relate to its primary purpose?
Apply the measure of coupling to the objects. Interactions implicitly identify dependencies. The questions to ask are:
  1. Does the dependency reinforce an appropriate division a labor among the objects, or does it simply complicate communication?
  2. Does the dependency reflect the way the real world functions?

Evaluate object purpose

When you assign a new task to an object, you are in effect adding a new responsibility to the object's "job description." New responsibilities affect objects the same way that adding responsibilities to your job will affect you.
Including some responsibilities can actually help you get work done more effectively by eliminating dependency on others. Adding other duties can unnecessarily complicate your job. For example, mentoring a new employee requires that you use your routine tasks as training opportunities, in effect doubling the work for each task.

Three Object Example

Figure Figure 3-5 below models three objects: a 1) customer actor, a 2) theater system, and 3) venue, and three messages. The theater system asks the venue for a set of events taking place in a specified date range. The venue returns the set of events. The theater system then sends the events to the customer actor (user interface) to be displayed. The types of arrows describe the type of interaction. The messages become operation signatures. The returns help validate the interaction.
Figure 3-5: Sequence diagram of a portion of the "Select a Performance" use case.

Another benefit of the Sequence diagram is that it has a very narrow scope, typically, one scenario for one use case. A scenario describes one possible sequence of interactions when a use case executes. For example, when you attempt to pay for your order at the theater, your credit card is approved and you get your tickets, or your card is rejected and you don't get your tickets. These are two scenarios; each scenario is represented by one Sequence diagram.
Sequence diagrams are valuable because they
  1. Have a narrow focus that helps you see the specific questions, commands, and data being communicated during the execution of a specific task. It is not very easy to gloss over the details when the express design of the diagram reveals those details.
  2. Explicitly identify the communication required to fulfill an interaction. This helps validate or discover the interfaces required by a class.
  3. Explicitly identify the objects that participate in an interaction. This helps validate or even discover the features of a class.
  4. Explicitly identify the data that are passed as part of the interactions. The data have to belong to a class somewhere in the design. Tracking down the source of the data often reveals new interactions.