Section 7.6. Message Arrows


7.6. Message Arrows

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 7-8.

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.

Figure 7-8. There are five main types of message arrow for use on sequence diagram, and each has its own meaning


7.6.1. Synchronous Messages

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 7-9.

Figure 7-9. The messageCaller participant makes a single synchronous message invocation on the messageReceiver participant


The interaction shown in Figure 7-9 is implemented in Java using nothing more than a simple method invocation, as shown in Example 7-1.

Example 7-1. 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

 public class MessageReceiver {    public void foo(  )    {       // Do something inside foo.    } }   public class MessageCaller {    private MessageReceiver messageReceiver;      // Other Methods and Attributes of the class are declared here      // The messageRecevier attribute is initialized elsewhere in    // the class.      public doSomething(String[] args)    {       // The MessageCaller invokes the foo(  ) method         this.messageReceiver.foo(  ); // then waits for the method to return         // before carrying on here with the rest of its work    } } 

7.6.2. Asynchronous Messages

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 7-10.

A common way of implementing asynchronous messaging in Java is to use threads, as shown in Example 7-2.

Figure 7-10. 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.

Example 7-2. 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

 public class MessageReceiver implements Runable {      public void operation1(  ) {       // Receive the message and trigger off the thread         Thread fooWorker = new Thread(this);       fooWorker.start(); // This call starts a new thread, calling the run(  )                       // method below         // As soon as the thread has been started, the call to foo(  ) returns.    }      public void run(  ) {       // This is where the work for the foo(  ) message invocation will       // be executed.    } }   public class MessageCaller {    private MessageReceiver messageReceiver;      // Other Methods and Attributes of the class are declared here      // The messageRecevier attribute is initialized elsewhere in    // the class.      public void doSomething(String[] args) {       // The MessageCaller invokes the operation1(  ) operation         this.messageReceiver.operation1(  );         // then immediately carries on with the rest of its work    } } 

7.6.3. 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.

Although a message will often be passed between two different participants, it is totally normal for a participant to pass a message to itself. Messages from an object to itself are a good way of splitting up a large activation into smaller and more manageable pieces and, in terms of software, can be thought of as being very similar to making a method call to the this reference in Java and C#.


7.6.4. 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 7-11.

Figure 7-11. 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 Example 7-3.

Example 7-3. The MessageCaller creates a new MessageReceiver object simply by using the new keyword

 public class MessageReceiver {    // Attributes and Methods of the MessageReceiver class }   public class MessageCaller {      // Other Methods and Attributes of the class are declared here      public void doSomething(  ) {       // The MessageReceiver object is created       MessageReceiver messageReceiver = new MessageReceiver(  );    } } 

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. Example 7-3 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 7-12.

Figure 7-12. Using an explicit destroy message or implying that a participant has been discarded using just a destruction cross





Learning UML 2.0
Learning UML 2.0
ISBN: 0596009828
EAN: 2147483647
Year: 2007
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net