You may have noticed that the BandSpy application has a hierarchy of classes. Bands contain Musicians that have Instruments that may be composites of other Instruments. During the use of the application, messages get relayed through the object relationships. You can think of method calls as a kind of message that one object might call on another. For example, if an instance of Band needed to know what Instruments its Musicians were playing, it would send a message to called getInstruments() to all its Musicians. Another way of saying that is Band is calling the getInstruments() method on all its Musicians.
It's useful to visualize how messages move between different objects, and the UML provides another diagram that's designed to represent that movement. This diagram is called the sequence diagram.
Sequence diagrams can usually be tied to an individual use case. The previous section on use cases contained a general "browse band info'' use case. To illustrate the sequence diagram, we can break the "browse band info'' use case down into more specific cases. Figure 2-11 shows some more specific use cases for the "user'' actor.
Figure 2-11
Taking the "lookup instruments by band'' use case, the sequence diagram should show all the objects involved and the messages passed between them to complete the task. The sequence diagram is shown in Figure 2-12.
Figure 2-12
The boxes at the top show the instances of objects involved in the sequence. In general, a box with an underlined name denotes an instance as opposed to a class. The dashed line descending from the object is the object's lifeline. In this case, the lifeline doesn't indicate the creation or deletion of any of your objects before this use case was acted upon, all the objects were already there. However, it is possible to indicate the instantiation of an object by using a "create'' message and a large X at the bottom of the object's lifeline to show its deletion.
The vertical rectangle shows the object's activation, that is, the time during which the object is involved in the execution of a particular operation. Time in this case is represented vertically, so the longer an object's activation (denoted by the length of the rectangle that represents it), the longer it is involved in the operation.
Another object in the application, the System object, is introduced in this diagram. In the BandSpy application, the System object will receive all messages from the Web GUI, rather than allow it to interact directly with your other objects. This way, the application has a single point of entry.
Arrows indicate messages. They're named with the corresponding method names of the objects, but it's okay to be less formal about it and just use a non method-like name for the message. Taking the messages step by step, the sequence is as follows:
A user requests to see all instruments of a particular band by typing in its name.
The system object looks up the band reference by performing a self-call on its own utility method.
The system object uses the found band reference and calls the getBandMembers method on it.
The band object calls the getInstruments method of its assigned musicians.
The musician object calls the getName method on each of its assigned instruments.
The instrument names are returned to the system object for display to the user.