This is a systems analysis task, that may be omitted since it duplicates much of the analysis activities involved with modeling the use cases with class states and the activity of cross-checking the software requirements against the use case steps (addressed in Chapter 16 }.

The purpose of this activity is to cross-check the steps of the use case against the logical class model, to ensure that every step is captured by an analysis class. To this extent, it is not as rigorous as modeling the classes with states and then detailing the software requirements.

In fact, I find that with the available tools, maintenance of sequence diagrams extremely painful and tedious. As such I recommend that if performing this step, it is simply used to cross-check the class operations against the use case steps and the realizations are then discarded. That is with one exception. The use case analysis activities, described in previous chapters do not take into consideration the 'create' and 'delete' events (since these are considered design operations). A by-product of this activity is a sequence diagram showing the sequence of creation and deletion of objects in the logical model. This may prove worth maintaining if one is considering execution of the analysis model.

15.1 Overview

A use case realization is modeled using the UML sequence diagram. The sequence diagram contains the classes that realize the use case, the actors that interface with the use case and the events that cause the use case to execute. It basically describes a mapping of use case steps to analysis classes (or design – not covered in this work). The idea being to demonstrate that every use case step has been captured by an event that is operated on by a class.

Each class or actor is captured by one or more instances of that class with a lifeline attached to the instance. Messages flow between object lifelines in sequence, from top to bottom in the diagram.

Sequence diagrams do not capture decisions made during execution of the use case (that information is already captured within the use case), hence we model each workflow with its own diagram.

Figure 1: contains a simple sequence diagram showing a customer requesting assistance. Analysis classes are represented by instances of the class (objects), and use case steps are represented as messages between those objects. Each step is processed by the class instance receiving the message. Note that the label on the message corresponds to an operation performed by that class. When an instance of that class receives a message indicating that the event causing the step has occurred, the object responds to the event by sending out a response that is recognized by another object or by an actor. Use case events generally originate from an actor of the use case, although a single step may be processed by several objects acting together to produce the desired result.

In the above example, use case steps are initiated by the Customer actor, recognized by the table associated with the customer and an appropriate action is requested of the Restaurant. The Restaurant displays the table as requesting or not requesting assistance, as appropriate.

15.2 Process

Sequence diagrams do not display decision or looping operations very well (nor should they[1]). Therefore each sequence diagram describes a single workflow within a use case, and not the decisions made for branching to alternate workflows.

3. For each step in the workflow that originates from an actor, add a message to the sequence diagram, originating from the actor instance to represent that step. Label the message appropriately (by 'appropriately, I mean that someone reading the use case realization can trace the event back to the use case step[2]).

4. Now add an object to the diagram to represent an instance of the class that will recognize that event. Objects generally take an explicit name that represents an instance of the class. Unless there is benefit to identifying the class instance name, I recommend leaving this blank, or simply giving it the name of the class.

5. Create a message exiting this object that either triggers another object (this would be an internal event not recognized by the requirements), or sends a message to an external actor. Each incoming event must be shown as triggering at least 1 external response. The external response may be a direct response by the class receiving the event, or it may pass on a message to other objects that will cause the external response to be generated.

a. If the class handling the event generates the response, then simply show it as a message from the object lifeline, to the receiving actor.

b. If the class that receives the event passes on a message to objects that perform subsequent operations as a result of the event occurring, then a message is shown leaving the receiving object and entering another object, which in turn sends messages to other objects or external actors. Model the complete path of the responses to this event until all external responses have been generated.

c. Some events may cause instances of classes to be created or deleted. These messages are shown on the Class Hierarchy sequence diagram. For the purposes of the use case realization, we assume that all necessary objects already exist.

15.3 Example

Taking the Serve Customer AUC as our example, Figure 2: shows the steps of the use case.

2. The use case initiating event is added to the diagram. This is shown as a message originating from the primary actor and entering an instance of the class that processes the event.

Note that the message is assigned the an operation of the Menu class. I have assigned the message with the name 'Start Menu', but this is not displayed in Figure 4:.[3]

3. Next the return message from the system is added to the sequence diagram. In step 2 of the use case, the system returns the system instructions, as shown in Figure 5:

4. Continue modeling events and responses as sequences of messages from top to bottom of the object lifelines. Where an input event causes several messages to occur, model them as a sequence of messages until all external responses have been output.

Note in Figure 6:, that the confirmOrder event triggers both a response to the Customer actor, and event to the Kitchen. Although the use case describes these 2 responses as arbitrary, it is not always possible to show arbitrary responses on a sequence diagram (another reason for not maintaining them as deliverable artifacts). Where possible, I show both responses occurring at the same point in the object lifeline, as shown in Figure 6: where 2 responses occur as a result of a confirmOrder event being received. One to display the confirmed order to the customer; the other to display the order to the kitchen.

5. When all use case steps have been captured, the sequence diagram looks like that in Figure 7:

[Note: I use Visio 'messages' to indicate events entering classes, 'responses' to indicate messages to actors. This is so that I do not add unnecessary information to the actors in the model.]

Modeling realizations of the alternative and exception flows Figure 8:, we get the diagrams shown in Figure 9:.

15.4 Modeling Hierarchy

As mentioned, if you wish to execute the model a useful diagram to maintain is a hierarchical view of the sequence in which class instances are created. (Objects delete themselves when no longer needed). This ensures that needed objects exist when they are used, and that unwanted objects are not taking up system resources when they are no longer being used.

We can use a collaboration diagram to demonstrate the hierarchy of object creation, as shown in Figure 10:.

Although not shown in the Serve Customer use case realization, the System is the initiating class. (This diagram is a collaboration of all application use cases.) This class instance is created when the system is operational. It creates an instance of the Restaurant class which allows the administrator to manage tables in the restaurant. The Restaurant object creates Table instances, as necessary. The table recognizes when a customer is associated with the table and creates a Customer instance to handle customer requests. The Customer instance creates the customer Order and Bill as necessary. The Order instance create a Menu for the customer to order from. The Menu controls creation of Category instances and Categories create associated Menu Items. Finally, the Bill recognizes when a Receipt is required.

As mentioned, this diagram does not provide much in the way of additional information to the analysis model, but I like to create it as a sort of safety blanket, to show that I have tied up any loose ends in the use case realization model.

15.5 Summary

Sequence and swimlane diagrams, in my experience, are two of the most difficult UML diagrams types to maintain. I am not normally a proponent of modeling with whiteboards, but in the case of these diagrams, I make an exception. The use case realization is a fine method for checking that the steps of the use case have been captured by the logical model. Apart from this check, I do not see a great deal of benefit to building a use case realization of the analysis model. I find that modeling the use cases in a logical model with states is much more effective and often sufficient without bothering with the use case realizations. On the plus side, sequence diagrams are simple to read and perhaps, work better than state diagrams when using a whiteboard.

Their other purpose is as a tool for checking traceability between use case steps and software requirements.

Whether using sequence diagrams for modeling use case realizations or establishing traceability between use cases and software requirements, I do not recommend maintaining them. Unless you have a tool (that I do not know about), which makes the effort of sequence diagram maintenance cost effective when compared to alternative methods described here.

[1] An example of the rule ‘use the diagram to model what it was intended to show’.

[2] Your tool may insist that you label the message with the name of an operation performed by that class. In which case ensure that the operation can be traced back to the step that initiates the operation.

[3] Yes, even though I have informed Visio that I wish to display message names on my sequence diagrams, Visio appears to have decided that I do not need to see these.