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.
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.
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
)
in which:
guard
Is optional and indicates a condition that must be satisfied for the communication to be sent or occur. The square brackets are removed when no guard is specified.
iteration
Is optional and indicates the number of times the communication is sent or occurs. The asterisk and square brackets are removed when no iteration is specified.
sequence_number
Is an optional integer that indicates the order of the communication. The succeeding colon is removed when no sequence number is specified. Because the vertical axis represents time proceeding down the page on a sequence diagram, a sequence number is optional.
return_variable
Is optional and indicates a name for the value returned by the operation. If you choose not to show a return variable, or the operation does not return a value, you should also omit the succeeding colon and equal sign.
operation_name
Is the name of the operation to be invoked.
argument_list
Is optional and is a comma-separated list that indicates the arguments passed to the operation. Each parameter may be an explicit value or a return variable from a preceding communication. If an operation does not require any arguments, the parentheses are left empty.
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:
FormatWorkerInfo
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)
The UML also allows you to show communication using pseudocode or another language. For example, you can use the syntax of Java, C++, C#, or some other programming language. A communication may also be described in the left margin of the sequence diagram.
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.
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.
In a sequence diagram, repetition (which involves repeating a set of messages or stimuli) within a generic-form interaction is shown as a set of communications enclosed in a rectangle.
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.
Figure 6-15. Sequence diagram repetition using an iteration expression within a generic-form interaction
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.
3.22.119.251