6.4 Sequence Diagrams
A sequence diagram shows elements as they interact over time, showing an interaction or interaction instance. Sequence diagrams are organized along two axes: the horizontal axis shows the elements that are involved in the interaction, and the vertical axis represents time proceeding down the page. The elements on the horizontal axis may appear in any order.
Sequence diagrams are made up of a number of elements, including class roles, specific objects, lifelines, and activations. All of these are described in the following subsections.
184.108.40.206 Class roles
In a sequence diagram, a class role is shown using the notation for a class as defined in Chapter 3, but the class name is preceded by a forward slash followed by the name of the role that objects must conform to in order to participate within the role, followed by a colon. Other classes may also be shown as necessary, using the notation for classes as defined in Chapter 3.
Class roles and other classes are used for specification-level collaborations communicated using sequence diagrams. Figure 6-8 shows the projectOrganization class role as well as the Project and Report classes.
220.127.116.11 Specific objects
In a sequence diagram, a specific object of a class conforming to a class role is shown using the notation for objects as defined in Chapter 3, but the object name is followed by a forward slash followed by the name of the role followed by a colon followed by the class name, all fully underlined. Other objects may also be shown as necessary using the notation for objects, as defined in Chapter 3.
Specific objects conforming to class roles and other objects are used for instance-level collaborations communicated using sequence diagrams. Figure 6-9 shows that Andy's organization plays the role of an organization that contains a project that is the subject of the report. Figure 6-9 also shows anonymous Project and Report objects.
A lifeline, shown as a vertical dashed line from an element, represents the existence of the element over time. Figure 6-10 shows lifelines for the class role (projectOrganization) and classes (Project and Report) in Figure 6-8. Lifelines may also be shown for the objects in Figure 6-9.
An optional activation, shown as a tall, thin rectangle on a lifeline, represents the period during which an element is performing an operation. The top of the rectangle is aligned with the initiation time, and the bottom is aligned with the completion time. Figure 6-11 shows activations for the class roles in Figure 6-8, where all the elements are simultaneously performing operations. Activations may also be shown for the objects in Figure 6-9.
In a sequence diagram, a communication, message, or stimulus is shown as a horizontal solid arrow from the lifeline or activation of a sender to the lifeline or activation of a receiver. In the UML, communication is described using the following UML syntax:
[guard] *[iteration] sequence_number : return_variable := operation_name (argument_list)
Figure 6-12 shows the communication occurring between the GenerateProject-StatusReportHandler class (which is responsible for managing the overall generation of the project status report) and the projectOrganization class role.
Let's take a step-wise look at how the communication notation used in Figure 6-12 is built. To begin with, the communication invokes a FormatWorkerInfo operation that formats a worker's information:
This operation requires a worker's units of work and work products, so we can update the communication to the following:
FormatWorkerInfo (UnitsOfWork, WorkProducts)
The operation also returns some output data as a string of formatted text, so we update the communication to reflect this:
OutputData := FormatWorkerInfo (UnitsOfWork, WorkProducts)
In our earlier description of this interaction and collaboration, this operation occurs as the sixth communication in an overall sequence of communications:
6 : OutputData := FormatWorkerInfo (UnitsOfWork, WorkProducts)
A project may involve more than one worker, thus the operation is to occur once for each worker: We indicate this using the notation for repetition:
*[For each worker] 6 : OutputData := FormatWorkerInfo (UnitsOfWork, WorkProducts)
Finally, this operation is to occur only if a project is active, and we indicate this using guard notation:
[Project is active] *[For each worker] 6 : OutputData := FormatWorkerInfo (UnitsOfWork, WorkProducts)
18.104.22.168 Reflexive communication
Similar to a reflexive association or link, as discussed in Chapter 3, an element may communicate with itself where a communication is sent from the element to itself. In the UML, a reflexive communication is shown as a horizontal solid arrow from the lifeline or activation of an element that loops back to the same lifeline or activation of the element.
Figure 6-13 shows a reflexive communication for step 6 of the Generate Project-Status Report interaction and collaboration description where the GenerateProject-StatusReportHandler class formats the organization and project information.
22.214.171.124 Element creation and destruction
When an element is created during an interaction, the communication that creates the element is shown with its arrowhead to the element. When an element is destroyed during an interaction, the communication that destroys the element is shown with its arrowhead to the element's lifeline where the destruction is marked with a large "X" symbol.
Figure 6-14 shows a communication for step 3 of the Generate Project-Status Report interaction and collaboration description in which the GenerateProject-StatusReportHandler class creates a report. This figure also shows a communication for step 8 of the Generate Project-Status Report interaction and collaboration description where the GenerateProject-StatusReportHandler class destroys the report.
An iteration expression may be used at the top-inside or bottom-inside of the rectangle to indicate the number of times the communications inside the rectangle occur. Figure 6-15 shows step 6b of the Generate Project-Status Report interaction and collaboration description using an iteration expression in which the GenerateProject-StatusReportHandler class retrieves the worker's units of work and work products, formats this information, and outputs the formatted information to the report element. Note the use of *[For each worker] in the upper left, which indicates that the communications shown occur once for each worker involved in the project.
Alternatively, a guard expression may be used at the top-inside or bottom-inside of the rectangle to indicate the condition that must be satisfied in order to terminate the repetition. Figure 6-16 shows Figure 6-15 using a guard expression to express the same iteration as in Figure 6-15. Rather than specify explicitly that the set of communications is repeated for each worker, the guard expression specifies that the communications are to be repeated until no more workers remain to be processed.
Repetition within an instance-form interaction involves showing the actual set of messages or stimuli that are repeated. Figure 6-17 shows step 6b of the Generate Project-Status Report interaction and collaboration description (Figure 6-15 and Figure 6-16) for a project that contains exactly three workers, each with two units of work and one work product. Notice that I have also described the interaction in the left margin to make the diagram more readable.
In a sequence diagram, conditionality (which involves communicating one set of messages or stimuli rather than another set of messages or stimuli) within a generic-form interaction is shown as multiple communications leaving a single point on a lifeline or activation, with the communications having mutually exclusive guard expressions. A lifeline may also split into two or more lifelines to show how a single element would handle multiple incoming communications, and the lifelines would subsequently merge together again.
Figure 6-18 shows steps 5 and 6 of the Generate Project-Status Report interaction and collaboration description where the GenerateProject-StatusReportHandler class requests that the projectOrganization class role indicate that the project is empty if the project is a newly created or unpopulated project, and the GenerateProject-StatusReportHandler class requests that the projectOrganization class role continue generating information for the report element if the project is not a newly created or populated project. In this figure, only the first communication is shown for actually generating the report. If there are no other communications for actually generating the report, the GenerateReport communication may go to the same lifeline as the OutputEmptyProject communication. I use different lifelines in the figure because each lifeline represents a different path of execution.
Conditionality within an instance-form interaction involves the set of messages or stimuli that are communicated for a specific condition. Figure 6-19 shows Figure 6-18 for a project that is populated.