Purpose

Steps

Heuristics

Artifacts

   The activity diagram maps the functional aspects of each use case workflow into discrete activities for each of the participants. There is at least one sequence or activity diagram for each “leaf” use case in the use case model. A use case may have additional diagrams to represent variants or exceptions to the workflow. Activity diagrams are best suited to a workflow with many decisions or loops. If the workflow is linear, a sequence diagram may be more appropriate. An activity diagram is well suited for illustrating various branches in a workflow for exceptions or variants, leading to their use for diagramming test cases.

1. 1. Begin with a blank UML activity diagram for a selected use case.
   

2. 2. Add the title and date / version to the diagram. The title is an exact match to the name of the use case to ensure traceability.
   

3. 3. Referring to the use case workflow, map each activity onto the activity diagram:
   

1. a. Identify the “does what” in the workflow and add it as an activity to the diagram. Link the activity to the next or previous activity with workflow arrows.
   

2. b.Identify the “who” and the “whom” in each activity, and create partitions (swim-lanes) for each participant. Ensure the activities reside in the correct partition for the participant, or extend the activity to cross partitions if desired.
   

3. c. Identify the flow of information in the activity (if any) and add it as a label to the flow arrows between activities.
   

4. d. Where multiple flows exit from one activity, use guard conditions to distinguish between them (a guard condition is a boolean expression in square brackets.)
   

5. e. If a branch in the workflow is associated with an important decision, add a decision diamond to the diagram and annotate with the associated question. Label the various outflows of the diamond with the answers to the question.
   

6. 6. If necessary, return to the use case descriptions to update the text.

1. • The activity diagram must be consistent with the workflow description of the use case it represents.  If the use case description is not clear about “who does what to whom”, it must be explored and updated in conjunction with developing the sequence diagram.
   

2. • Activity diagram participants at this level of abstraction are always entities found within the problem domain.
   

3. • Each activity diagram should have a starting point. Each diagram may also have a clear ending point, or may result in a pre-mature ending.
   

4. • If the flow forks into multiple, parallel flows, use a join to bring them back together.
   

5. • If non-active participants are involved in the activities, they can be added as passive participants using the instance notation as seen for participants on the sequence diagram. Link them to associated activities with a dependency arrow.

An Activity Diagram (Example 1)