Early in the analysis, some objects seem to relate to others even though it is not always clear exactly how. The first step is to identify the existence of such associations. We discuss the characterization of associations later in this chapter. There are a few strategies for the identification of object relationships. Each relies on the fact that objects send messages to other objects and every message implies an association. Table 6-7 shows the most common strategies used to identify associations. Table 6-7. Object Association StrategiesStrategy | Description |
---|
Identify messages | Each message implies an association between the participating objects. | Identify message sources | The sensors that detect information or events and the creators of information or events are all message sources. They pass information on to other objects for handling and storage. | Identify message storage depots | Message storage depots store information for archival purposes or provide a central repository of information for other objects. The depots have associations with the message sources as well as the users of that information. | Identify message handlers | Some objects centralize message dispatching and handling. They form connections to either or both message sources and message storage depots. | Identify whole/part structures | Whole/part relations will become aggregation or composition relationships among objects. Wholes often send messages to their parts. | Identify more/less abstract structures | Some objects are related to each other by differences in levels of abstraction. It is not uncommon for a single higher-level abstraction to be implemented by a tightly knit set of objects at a more concrete level of abstraction. The larger object in this case will become a composite object and the smaller objects, its component parts. The relationship among them will become a composition relation. | Apply scenarios | Walk through scenarios using the identified objects. The scenarios explicitly show how the messages are sent between objects. | In our elevator example, there are a number of associations, shown in Table 6-8. Table 6-8. Elevator Object AssociationsMessage Source | Message Target | Message |
---|
Elevator request button | Elevator gnome | Requests an elevator | Elevator gnome | Elevator | Request status | Elevator gnome | Elevator | Add destination for elevator | Elevator | Elevator gnome | Accept destination | Elevator | Floor speaker | Arrival event beep | Elevator floor sensor | Elevator | Location | Cable tension sensor | Locking clamps | Engage | Central station | Locking clamps | Release | Cable tension sensor | Central station | Alarm condition | Elevator | Central station | Status | Floor request button | Elevator | Add destination | Run-stop switch | Elevator | Stop/run | Run-stop switch | Central station | Stop/run | Alarm button | Central station | Alarm condition | Elevator | Door | Open/close | Class and object diagrams capture these associations. A line drawn between two objects represents a link (instance of an association) between those objects, supporting the transmission of a message from one to the other. The object diagram in Figure 6-11 shows the general structure of the identified objects and their neighbors. The system consists of 38 high-level objects: 8 shafts, 8 elevators, 20 floors, and one central station and one elevator gnome. The numbers at the upper lefthand corner of the object represents the instance count, that is, the number of instances of the object in the enclosing context. The shaft, elevator, and floor are all composites that strongly aggregate their components. The instance counts of their components as per instance of their context. That is, each Elevator has 20 instances of Floor Request Button. Figure 6-11. First-Cut Elevator Object Diagram |