While in a statechart diagram, the flow of control is visualized from state to state, in an activity diagram,
the flow of control is visualized from activity to activity.
An activity diagram shows a series of actions that have to be followed before the software component in question can meet its intended goal.
This means that often a path in the diagram will split into 2
or more paths, because an action might have more than one outcome. Tangible states are viewed more retroactively, while activites are grounded in the present.
Activity diagrams might use states as a way to differentiate between paths, as consequences to actions taken.
Actors are not as important in activity diagrams as in other diagrams, however there are ways to show which action belongs to whom using swimlanes, which will be further explained
in the symbols section.
You can use an activity diagram to show any task that a user might want to accomplish while using your software! All UML diagrams can be helpful in further explaining how you want your
software to function.
However, it might be especially helpful to use an activity diagram when there could be several outcomes to an action, or where something is likely to not go as intended.
The Dog Wash Example
When washing a dog, there aren't that many steps, however there is still a lot that can go wrong.
In this example, one must first turn on the water to warm up, and then look for the dog. (Who is probably hiding after hearing the water) This brings us to our first decision node,
where the dog is either found, or not found. If the dog is not found, our diagram states they must look again. However in another diagram, one might have that lead to the action "give up."
Once the dog is found, catching him is another story. When he is eventually found and caught, however, then multiple actions can be taken at the same time in order to wash the dog. Then, as a joint effort, the dog
can be dried and once again be set free.
