Chapter 5: Object Interaction

be captured in the flow of events and on a Sequence or Collaboration diagram.

Most use cases will have a number of Sequence and Collaboration diagrams, one for each scenario through the flow of events. These diagrams can be built at a high level of abstraction, to show how systems communicate, or at a very detailed level, showing exactly what classes need to participate in a particular scenario.

As you look at the nouns in your scenarios, some of the nouns will be actors, some will be objects, and some will be attributes of an object. When you're building your Interaction diagrams, the nouns will tell you what the objects will be. If you're looking at a noun and wondering whether it's an object or an attribute, ask whether it has any behavior. If it's information only, it's probably an attribute. If it has some behaviors also, it may be an object. Another check is whether it has attributes of its own. Is a passenger an attribute of a flight or an object of its own? The answer to that question really depends on the application you are building. If all you need to store is the name of the passenger, then it can be modeled as an attribute of a flight. If, however, you also want to store the passenger's address, credit card information, and phone number, then it would be better modeled as a separate object.

Not all of the objects will be in the flow of events. Forms, for example, may not appear in the flow of events, but will have to appear on the diagram in order to allow the actor to enter or view information. Other objects that probably won't appear in the flow of events are control objects.

You should consider each of these categories as you identify objects:

Entity objects These are objects that hold information. They may eventually map to some of the tables and fields in the database. Many of the nouns in the flow of events will give you entity objects. Entity objects in our airline example might be flight #1020, passenger John Doe, or ticket #1347A. These are business entities that have meaning to the end user.

Boundary objects These are objects that lie on the boundary between the system and the outside world. In other words, these are the forms and windows of the application and the interfaces to other applications. Forms may appear in the flow of events, but interfaces probably won't. As you go through the logic in the flow of events, ask whether any other system will need to be involved to carry out the logic in the flow. If so, you may need one or more interface objects.

Control objects These are optional objects that control the flow through the use case. They don't carry out any business functionality in and of themselves. Instead, they coordinate the other objects and control the overall logic flow. For example, a control object would know that the user's security level should be checked before a particular report is run. The control object wouldn't check the security level or run the report, it simply holds the sequencing logic and the business rules for the scenario. It would first tell another object to check the security, and then tell the report to run. Control objects won't appear in the flow of events. Using them is, instead, a design decision; if you decide to use control objects, add one to your Sequence or Collaboration diagram.

Finding the Actor

Once you have identified the objects for your Interaction diagram, the next step is to identify the necessary actor. An actor on an Interaction diagram is the external stimulus that starts the workflow for a flow of events. You can identify the actor by looking at the flow of events and determining who or what starts the process.

There may be more than one actor for a given Interaction diagram. Each actor that receives a message from or sends a message to the system in a particular scenario should be shown on the diagram for that scenario.

163