UML Weekend Crash Course™ - To Parent Directory

Session 16—Modeling the Dynamic View: The Sequence Diagram 171
5. Return
6. Anonymous object
7. Object name
8. Sequence number
9. Condition
10. Basic comment
The sequence numbers are optional but are very helpful when you need to discuss the
diagram and make changes. Each message arrow describes an interface/operation on the
object it is pointing to. Consequently, the message contains the operation signature, that is,
the name, arguments, and optionally the return, such as addItem(product):boolean.
The dashed return arrows pointed to by references #2 and #5 each contain only the
answer to a message. Some folks leave these off. But the purpose of modeling is to reveal
information, not make assumptions. Showing the returns can help ensure that what you’re
getting back is consistent with what you asked for in the message.
Figure 16-2, reference #3, shows how you can indicate that an operation should be performed
repeatedly. Use the square condition brackets to enclose either the number of times
or the condition that controls the repetitions, for example [for each product].
The same condition brackets may be used to control whether a message is even sent.
Reference #9 points to step 6, which uses the test [product available = yes] to make certain
that the previous step succeeded before performing the operation in step 6.
Reference #10 shows how you may use a UML comment to add information that is not
explicitly part of the notation.
Defining the extended notation for the Sequence diagram
Sequence diagrams can be enhanced to illustrate object activation and object termination
and to customize messages.
Figure 16-3 includes some changes to the original Sequence diagram in order to illustrate
these new features. To show that an object is active, the notation is to widen the vertical
object lifeline to a narrow rectangle, as shown in Figure 16-3. The narrow rectangle is called
an “activation bar” or “focus of control.” Reference #1 shows when the object becomes
active at the top of the rectangle. Note that the object becomes active when it begins to do
work. Reference #2 shows when the object is deactivated or finishes its work and waits for
the next request. Using this notation, we can see that the Inventory object is only active
while it is responding to the “productAvailable” inquiry, and the Order is activated more
than once: once to create the Order object and once each time it is asked by Bill to perform
“addItem.”
To show that an object is terminated, place an X at the point in the object lifeline when
the termination occurs. This is usually in response to a message such as delete or cancel.
See message 10: cancel() followed by the X at reference #5. The absence of the X on an
object lifeline means that the object lives on after this sequence of events is ended.