Participants on a sequence diagram can be named in number of different ways, picking elements from the standard format:

name [selector] : class_name ref decomposition

The elements of the format that you pick to use for a particular participant will depend on the information known about a participant at a given time, as explained in Table 7-1.

The format used when creating names for your participants is totally up to you—or maybe your company’s style guide. In this book, we lowercase the first word in the participant name to make sure that there is as little confusion as possible with the name of a class. However, this is just our convention—similar to the conventions used when naming objects and classes in Java—and is not something specified by UML.

A message arrow comes with a description, or signature. The format for a message signature is:

attribute = signal_or_message_name (arguments) : return_type

You can specify any number of different arguments on a message, each separated using a comma. The format of an argument is:

<name>:<class>

The elements of the format that you use for a particular message will depend on the information known about a particular message at any given time, as explained in Table 7-2.

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.

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
   }
}

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.

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
   }
}

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.

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.

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

Before you can specify what types of interaction are going to occur when a use case executes, you need a more detailed description of what the use case does. If you’ve already completed a use case description, you already have a good reference for this detailed information.

Table 7-3 shows the steps that occur in the Create a new Regular Blog Account use case according to its detailed description.

Table 7-3 actually shows all of the steps involved in the Create a new Regular Blog Account use case, including any steps that it has inherited from Create a new Blog Account or reused from Check Identity. This has been done just so you can easily see all of the Main Flow steps in one place.

In practice, you would probably just look up all three use case descriptions separately without actually going to the bother of actually merging them.

Table 7-3 only shows the Main Flow—that is the steps that would occur without worrying about any extensions—but this is a good enough starting point for creating a top-level sequence diagram, as shown in Figure 7-14.

Figure 7-14. This sequence diagram shows the actors that interact with your system and your system is shown simply as a single part in the sequence

At this point, Figure 7-14 shows only the interactions that must happen between the external actors and your system because that is the level at which the use case description’s steps were written. On the sequence diagram, your system is represented as a single participant, the ContentManagementSystem; however, unless you intend on implementing your content management system as a single monolithic piece of code (generally not a good idea!), it’s time to break apart ContentManagementSystem to expose the pieces that go inside, as shown in Figure 7-15.

Figure 7-15. Adding more detail about the internals of your system

Sequence diagrams can get much more complicated by simply adding a couple of extra participants and some more detailed interactions. In Figure 7-15, the original sequence diagram has been refined so that the single ContentManagementSystem participant has been removed and in its place, more detail has been added showing the actual participants that will be involved.

Work on sequence diagrams invariably goes on throughout the life of your system’s model, and even getting the right participants and interactions in a detailed sequence diagram at the beginning can be hard work. Keeping your sequence diagrams up to date is also a challenge (see "Managing Complex Interactions with Sequence Fragments" later in this chapter); therefore, expect to spend some time working with your sequence diagrams until you get things right.

Something critical is missing from the sequence diagram shown in Figure 7-15. The title of the use case in which the sequence diagram is operating is Create a new Regular Blog Account, but where is the actual creation of the blog account? Figure 7-16 adds the missing pieces to the model to show the actual creation of a regular blog account.

Figure 7-16. Showing the lifelines of your sequence diagram’s participants

Participant lifelines are particularly useful when showing that a participant has been created. In Figure 7-16, the AuthorDetails and RegularBlogAccount participants are not in existence when the sequence diagram begins but they are created during its execution.

The AuthorDetails and newAccount:RegularBlogAccount participants are created by corresponding create messages. Each create message connects directly into the title box for the participant being created, passing any information needed when creating the new participant. By dropping the participant’s title box to the point where the create message is actually invoked, the diagram can clearly show the point where the participant’s lifeline begins.

Let’s say that the authorDetails:AuthorDetails participant is no longer required once the newAccount:RegularBlogAccount has been created. To show that the authorDetails:AuthorDetails participant is discarded at this point, you can use an explicit destroy message connected to the destruction cross, as shown in Figure 7-17.

So far, all of the messages on our example sequence diagram have been synchronous; they are executed one after the other in order, and nothing happens concurrently. However, there is at least one message in the example sequence that is a great candidate for being an asynchronous message, as shown in Figure 7-18.

Figure 7-17. Showing that a participant is discarded using the destruction cross

Figure 7-18. The clickSubmit( ) message will currently produce some irregular behavior when the admin creates a new account

In Figure 7-18, when the Administrator clicks on the submit button the system freezes, until the new blog account has been created. It would be useful to show that the user interface allows the Administrator to carry on with other tasks while the content management system creates the new account. What we need is for the clickSubmit( ) message to be asynchronous.

Converting the clickSubmit( ) from a synchronous to an asynchronous message means that the sequence diagram now shows that when the new regular blog account information is submitted, the user interface will not lock and wait for the new account to be created. Instead, the user interface allows the Administrator actor to continue working with the system.

For the Administrator to receive feedback as to whether the new blog account has been created, the simple return arrow has to be replaced with a new accountCreationNotification( ) asynchronous message since asynchronous messages do not have return values.

The ref type of sequence fragment finally alleviates some of the maintenance nightmare presented by the huge sequence diagrams that are often created for complex systems. In Figure 7-20, the ref fragment represents a piece of a larger sequence diagram.

The interactions by which the Administrator actor selects a blog account type for creation are now contained within the referenced sequence fragment. Figure 7-21 shows how the referenced fragment can be expressed on a separate sequence diagram.

Figure 7-20. Capturing the interactions used to select an account type within a ref sequence fragment

Figure 7-21. A referenced sequence diagram that contains the new account selection interactions

Along with managing the sheer size of large sequence diagrams, the ref fragment also presents an opportunity to reuse a set of common interactions. Several ref fragment boxes can reference the same set of interactions, thereby reusing the interactions in multiple places.

UML 2.0 contains a broad set of different fragment types that you can apply to your sequence diagrams to make them more expressive, as shown in Table 7-4.

Sequence fragments make it easier to create and maintain accurate sequence diagrams. However, it’s worth remembering that no fragment is an island; you can mix and match any number of fragments to accurately model the interactions on a sequence diagram. Be wary if your diagrams become huge and unwieldy even when you are using fragments, since you might simply be trying to model too much in one sequence.

We’ve given you a brief overview of sequence diagram fragments here. All the different sequence diagram fragment types are a big subject in their own right and are a little beyond the scope of this book. For a more in-depth look at the different types of sequence diagram fragments, see UML 2.0 in a Nutshell (O’Reilly).