UML Weekend Crash Course™ - To Parent Directory

Session 16—Modeling the Dynamic View: The Sequence Diagram 173
Reference #4 points to an asynchronous event. Typically, you see events that require some
type of response like addItem (did it work or not) or productAvailable (is there any product
in stock). But there are times when the event is simply a signal to another object to do
something. For example, just a moment ago my wife told me that dinner was ready. Knowing
my work habits, she knows better than to expect a response. In Figure 16-3, message 7, you
send a message to inventory to reduce the count on the product by the quantity supplied. It
is up to inventory to queue the request and take care of it. The place order process is not
going to wait. (This makes a good illustration but it is probably not very good design.)
Note the difference in the arrows. An asynchronous message uses a stick arrowhead
instead of the solid arrowhead used for simple or synchronous messages.
Now, take a look at messages 4 and 8. Message 4 starts the operation “addProduct” but
the return doesn’t come until message 8. All the messages between 4 and 8 are the messages
sent by the Order object while performing the operation “addProduct.” This is another good
reason to show the returns. Without the returns explicitly shown in Figure 16-3, it would be
possible to interpret the diagram to say that the system first adds the product before it
even checks to see if the product is available.
Finally, to model object creation, you have a few options. In Figure 16-3, message 1, you
see the message Order() pointing to the object lifeline. This is a common coding convention
for a constructor (an operation with the same name as the Class), an operation that creates
an object. But the Sequence diagram uses an object lifeline that should allow us to represent
object creation visually. Figure 16-4 shows two variations using the object lifeline.
Bill : Customer
Standard form
Bill : Customer
Also used in
modeling tools
1: Order()
2: return order
Bill's Order : Order
1: Order()
2: return order
Bill's Order : Order
Figure 16-4 Two ways of modeling object creation
The example on the left is the form explicitly defined by the UML. The creation message
(constructor) points directly at the Object. This means that the object icon has to be placed
somewhere down the page where the creation actually happens instead of at the top. Using
this technique implies that objects at the top of the page already existed when the scenario
started.
The example on the right is a minor variation where the constructor points to the object
lifeline just below the object. But the object is still placed on the diagram at the point in
time when it is created, rather than at the top.
The goal is to represent the fact that the object did not exist prior to the creation message.
The object lifeline literally comes into existence when the creation message is sent, so
there is no object lifeline before (above) the creation message.
Note
Not all tools support either of these techniques, so you may have to use the
approach in Figure 16-3.