The Activity Diagrams that you created in Step 2 serve as your starting point. In Step 3 of Five-Step UML, you need to work through these diagrams, adding swimlanes to each of them. The best place to start is with the actor that initiates the use case, and then you can look at every activity in turn and think about what part of your system should be responsible for it.

Let’s have a look at this process in more detail.

Pick an Activity Diagram

You need to start somewhere, so pick an Activity Diagram. Go for a simple one first off, particularly if you’re trying to get some practice. You can work on more complicated diagrams later.

Look at the Initial State

Add a swimlane for the actor that requested the corresponding use case. Drag the initial and terminal states into that swimlane. (Here is where you’ll really appreciate a modeling tool or Post-it notes.) Or perhaps you’ll want to preserve the original diagram and re-create it with swimlanes.

Look at the First Activity

Look at the first activity and try to figure out which existing actor or interface should be responsible for that activity. If it’s an activity performed by an actor, the actor is responsible. If it’s an activity performed directly in response to an actor (such as processing user input or responding to a timer or receiving a message), an interface for the corresponding actor is responsible. If it’s a query to a database, a database interface is responsible. If it’s a call to an existing interface, that interface is responsible. And if the activity doesn’t seem to “belong” to any existing actor or interface, add a new interface that is responsible for it, as described in the next part of this exercise.

When adding interfaces, think in terms of high-level groups of services that together form a useful set of services.

For a New Actor or Interface or User Interface, Add a Swimlane

If the actor or interface has not been used in the current Activity Diagram before, add a swimlane for it. If the new element is a heretofore-undiscovered actor, add it to the Actor List. If the new element is a heretofore-undiscovered interface, add it to an Interface List. (You may find it convenient to maintain this Interface List as an evolving Component Diagram. We’ll see more about Component Diagrams later on in this chapter.) Brainstorm about the purpose of the new interface and what sort of other operations it might support.

Drag the Activity into the Swimlane

Now that you have identified the correct swimlane, drag the activity into it. If the swimlane represents an interface, add the activity to the interface (in the Interface List) as a required operation. If the swimlane represents a user interface, add the activity to the user interface (in the User Interface List) as a required operation.

Update All Transitions to Keep the Activity Diagram Intact

If you’re drawing the diagrams by hand, you’ll have to correct the transitions to and from the activity that you moved. Consider adding new activities and using the «invoke» and «interrupt» transitions where appropriate.

Repeat for All Branches, Merges, Activities, Forks, and Joins in the Diagram

Continue revising and adding swimlanes until each element of the diagram has been assigned to a swimlane. Rearrange the swimlanes and activities until you’re comfortable with the assignment of responsibilities. Make sure you keep all interface icons, class icons, and node icons up to date with these changes.

Search for Implicit Requirements and Back-End Activities

Look at your architectural assignments, and see what’s missing. Have implicit requirements been revealed? Have you found back-end activities that are needed? Add the new activities, along with swimlanes for interfaces to support them.

Consider Subactivity States and Additional Diagrams

As in Step 2, consider adding subactivity states and contained diagrams where they simplify the message.

Repeat for Each Activity Diagram

Add swimlanes to each of the remaining Activity Diagrams. Reuse interfaces where appropriate, but try to keep each interface cohesive. Don’t assign an activity to a given interface unless it fits the overall purpose of the interface.

If you’re working through this process as an exercise, then I recommend that you add swimlanes to at least two Activity Diagrams for practice, and more if you wish.

Example

As an example, Figure 2-15 is the Activity Diagram for the Locate Pet use case (shown in Figure 2-9), with an initial swimlane for the actor added.

Figure 2-15.  Activity Diagram for Locate Pet use case (with Swimlanes)

To add further structure to this, we can add activities that reflect the Pet Owner controlling the process, and we can add support interfaces to carry out back-end services. This is shown in Figure 2-16.

There are a few interesting things to note on this diagram:

I rearranged some of the flow, so that if the pet name is wrong, we simply display an error message. It’s up to the pet owner to reenter the name. Nothing in the application forces the pet owner to do so.

Note that the Call for Pet activity uses the Fetch Pet activity of the Care Giver swimlane (corresponding to the Care Giver actor). It does so via an «invoke» transition to the Call for Pet activity of the Care Giver UI, which then instructs the Care Giver to fetch the pet. This diagram doesn’t indicate the mechanism behind this asynchronous UI request. It might be a pager, it might be a pop-up message, it might be electrodes implanted in the care giver’s brain, but you can’t tell from this diagram. That is an implementation issue for the Care Giver UI.

Figure 2-16.  Activity Diagram for Locate Pet use case (interfaces added)

Next, let’s turn the preceding diagram into an architectural diagram by wrapping the business rules in subactivity states, as shown in Figure 2-17.

Figure 2-17.  Activity Diagram for Locate Pet use case (architectural view)

Step 4: Design and Step 5: Repeat will appear next week.