Step 3: Process in Detail
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.
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.
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.
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.
TIP: For more on swimlanes, architecture, and interface design, see Chapter 8.
Step 4: Design and Step 5: Repeat will appear next week.
blog comments powered by Disqus