Working through Workflow Diagrams

Your specific needs for modeling workflow can come in many shapes and sizes. The example in Figure 13-2 illustrates the use of an activity diagram at the level of a complex operation on a class. You can also use UML for more than developing software. We use it to model business processes, document flow, and employee responsibilities. The activity diagram is very useful when you want to illustrate work flowing through a business process. You can also document complex use cases with what is known as an interaction overview diagram.

Warning Be careful not to use the activity diagram at too low (that is, detailed) a level. Activity diagrams can potentially specify the line-by-line code for a method—but (alas) today’s UML tools don’t generate code from activity diagrams. So if you find yourself thinking, “I could have already written the code in the time it took me to draw this activity diagram,” then you’re definitely modeling at too low a level.

Diagramming use case steps

UML2 Some of your use cases are likely to be complex enough to have a main success scenario, many alternative flows, and error flows. UML 2 has come to the rescue by making possible a special kind of activity diagram: the interaction-overview diagram.

In an interaction-overview diagram, you show interaction occurrence nodes connected by control flows instead of showing action and activity nodes. An interaction occurrence is some notation for referencing a full-fledged sequence diagram. You draw an interaction-occurrence node as a rectangle with a small thumbnail in the upper left-hand corner. The thumbnail contains the keyword ref. The rest of the box contains the name of the interaction. See Chapter 12 for more details about interaction occurrences.

You can help others to understand complex use cases by giving them an overview of how the interaction sequences flow. For example, Figure 13-3 shows a simple use-case diagram for the process of making a room reservation in a hotel reservation system.

Figure 13-3: A use-case diagram for Make Room Reservation.

Figure 13-4 shows an interaction overview diagram, looking suspiciously similar to an activity diagram. Instead of enclosing the diagram with a symbol for complex activity (a rounded rectangle), you use a sequence-diagram frame in a regular rectangle.

Figure 13-4: Interaction Overview diagram for making a room reservation.

Tip Use interaction occurrences instead of activities when you need to show alternative flows. Use decision/merge nodes and fork/join nodes to indicate the flow of control through the use case.

To construct an interaction overview diagram for your complex use cases, follow these steps:

Place the name of the use case in the upper-left corner just after the sd keyword.

In the example in Figure 13-4, the name is Make Room Reservation.
Start your interaction with an initial node, a large dot.
Draw a control flow that starts at the initial node and goes to the first interaction occurrence.
Break up your main success scenario into groups of interactions.

Draw your main success scenario, breaking it up into groups of interactions. To make a reservation our actor, Potential Guest, must pick a room type and day span for the reservation, select an available room type, supply billing information, and confirm the reservation.
Each group of interactions becomes an interaction occurrence.

You show each interaction occurrence as a box with the ref keyword in the upper-left corner and the name of the occurrence in the middle of the box. For example, Identify room type and day span is a small interaction between the Potential Guest actor and the system. You show this referenced interaction in another sequence diagram. If the interaction is simple, you can show a mini-sequence diagram instead of an interaction occurrence.
Connect the main success scenario interactions with control-flow lines to show the correct sequence.

The Select available room type follows the Identify room type and day span interaction occurrence.
When you have an alternative flow, break the control flow between interaction occurrences and insert a decision node or a fork node.

If the alternative flow or flows are concurrent to the main success scenario, then use a fork to indicate it; otherwise use a decision.

In the reservation example in Figure 13-4, a decision must be made between the Identify room type and day span and the Select available room type interactions. If invalid day span is true, then control flows to the Day span error interaction occurrence. If cancel is true than control flows to the Cancel reservation interaction occurrence. Otherwise, control flows normally to the next part of the main success scenario.

Repeat this step as needed to encompass all the alternative flows for your use case.
Use merge or join nodes to bring any alternative paths that pass through the interaction diagram back together (if necessary).

This is the same technique used in an activity diagram. The example illustrated in Figure 13-4 doesn’t require any merge or join nodes.
You must use the activity final node in your interaction overview, because all use cases must come to an end.

In the reservation example, the interaction ends after the Confirm reservation interaction or the Cancel reservation interaction. To indicate this situation, you place a bull’s-eye at the bottom of the diagram with control flow lines coming from those two interaction occurrences.

Indicating the responsible parties

UML 2 lets you show who is responsible for an activity or an action in two ways:

Swim lanes: You can divide up your activity diagram into rows or columns, called swim lanes. To understand the concept of swim lanes, think of placing your activity diagram in a large pool. At the head of the pool you place each person involved in the business process, each in his or her own swim lane. Each person who dives into the pool then swims over the various activities for which they are responsible.

You show swim lanes as parallel lines across or down the page. At the top or side of the lane put the name of the person, job role, or organizational unit that is responsible for performing the activities in that lane. Place the activities or actions for that party inside the lane.
Partition names: When you can’t use swim lanes, you can just place the name of the responsible party in parentheses inside the rounded rectangle above the name of the activity or action.

When you model a business process, it’s necessary to show each part of the process and each individual responsible. With UML, you show business processes as an activity diagram with swim lanes. Figure 13-5 shows the process of getting through an airport to board a plane. This business process involves four participants: Passenger, Ticket Agent, Airport Security, and Boarding Agent.

Figure 13-5: Activity diagram showing a business process.

We chose to place the swim lanes in vertical swim lanes because they fit the page better, but we could have used horizontal swim lanes. Each lane has the name of one participant. Each participant is responsible for performing the activities in his or her lane.

You notice the Ticket object changes state as it moves through this activity diagram. When the Ticket Agent performs the Generate Pass activity, the Ticket object has the valid state. After the Boarding Agent performs the Stamp Pass activity the Ticket changes to the used state.

Tip Use a connector when you run out of space in an activity diagram. For example, we ran out of room at the Receive Pass activity that the passenger performs. So, we placed a connector with the label A. Then we drew a control-flow line from Receive Pass to the A connector. Using the same technique, you can pick up the control-flow path at the connector with the same label A at the top of the Passenger’s swim lane, and then proceed to the Wait in line activity.

Figure 13-6 shows two examples of partition names placed inside the activity’s rounded rectangle. Instead of using swim lanes, you can show that the Passenger is performing the Wait in line activity and Airport Security performs the Observe Passenger activity.

Figure 13-6: Showing who's responsible with names placed inside an activity.