Jan. 27, 2011, 7:20 p.m.
posted by demx
The type of arrowhead that is on a message is also important when understanding what type of message is being passed. For example, the Message Caller may want to wait for a message to return before carrying on with its worka synchronous message. Or it may wish to just send the message to the Message Receiver without waiting for any return as a form of "fire and forget" messagean asynchronous message.
Sequence diagrams need to show these different types of message using various message arrows , as shown in Figure.
To explain how the different types of messages work, let's look at some simple examples where the participants are actually software objects implemented in Java.
There are five main types of message arrow for use on sequence diagram, and each has its own meaning
As mentioned before, a synchronous message is invoked when the Message Caller waits for the Message Receiver to return from the message invocation, as shown in Figure.
The messageCaller participant makes a single synchronous message invocation on the messageReceiver participant
The messageCaller object makes a regular Java method call to the foo( ) method on the messageReceiver object and then waits for the messageReceiver.foo( ) method to return before carrying on with any further steps in the interaction
It would be great if all the interactions in your system happened one after the other in a nice simple order. Each participant would pass a message to another participant and then calmly wait for the message to return before carrying on. Unfortunately, that's not how most systems work. Interactions can happen at the same point in time, and sometimes you will want to initiate a collection of interactions all at the same time and not wait for them to return at all.
For example, say you are designing a piece of software with a user interface that supports the editing and printing of a set of documents. Your application offers a button for the user to print a document. Printing could take some time, so you want to show that after the print button is pressed and the document is printing, the user can go ahead and work with other things in the application. The regular synchronous message arrow is not sufficient to show these types of interactions. You need a new type of message arrow: the asynchronous message arrow.
An asynchronous message is invoked by a Message Caller on a Message Receiver, but the Message Caller does not wait for the message invocation to return before carrying on with the rest of the interaction's steps. This means that the Message Caller will invoke a message on the Message Receiver and the Message Caller will be busy invoking further messages before the original message returns, as shown in Figure.
A common way of implementing asynchronous messaging in Java is to use threads, as shown in Figure.
While the foo( ) message is being worked on by the messageReceiver object, the messageCaller object has carried on with the interaction by executing further synchronous messages on another object
If you're not too familiar with how threads work in Java, check out Java in a Nutshell , Fifth Edition (O'Reilly) or Java Threads (O'Reilly). See "Applying Asynchronous Messages" later in this chapter for a practical example of asynchronous messages.
The operation1( ) asynchronous message invokes an internal thread on the message receiver that in turn spurs the message, immediately returning the flow of execution to the messageCaller
The Return Message
The return message is an optional piece of notation that you can use at the end of an activation bar to show that the control flow of the activation returns to the participant that passed the original message. In code, a return arrow is similar to reaching the end of a method or explicitly calling a return statement.
You don't have to use return messages sometimes they can really make your sequence diagram too busy and confusing. You don't have to clutter up your sequence diagrams with a return arrow for every activation bar since there is an implied return arrow on any activation bars that are invoked using a synchronous message.
Participant Creation and Destruction Messages
Participants do not necessarily live for the entire duration of a sequence diagram's interaction. Participants can be created and destroyed according to the messages that are being passed, as shown in Figure.
Both participant2 and participant3 are created throughout the course of this sequence diagram
To show that a participant is created, you can either simply pass a create(..) message to the participant's lifeline or use the dropped participant box notation where it is absolutely clear that the participant does not exist before the create call is invoked. Participant deletion is shown by the ending of the participant's lifeline with the deletion cross.
Software participant creation in Java and C# is implemented using the new keyword, as shown in Figure.
The MessageCaller creates a new MessageReceiver object simply by using the new keyword
With some implementation languages, such as Java, you will not have an explicit destroy method , so it doesn't make sense to show one on your sequence diagrams. Figure is one such case where the messageReceiver object will be flagged for destruction when the doSomething( ) method completes its execution. However, no additional messages have to be passed to the messageReceiver to make it destroy itself since this is all handled implicitly by the Java garbage collector.
In these cases, where another factor such as the garbage collector is involved, you can either leave the object as alive but unused or imply that it is no longer needed by using the destruction cross without an associated destroy method, as shown in Figure.
Using an explicit destroy message or implying that a participant has been discarded using just a destruction cross