What is an activity diagram?

An activity diagram is basically an extension of the workflow diagram. It describes the dynamic aspects of the system and is considered one the most important features of UML. Activity diagrams represent the flow of one activity from another. What is an activity? Well, an activity is described as the operational process of the system. Therefore, an activity diagram is a flowchart of activities.

Features of an activity diagram

Let’s look at a few common features of an activity diagram:

1. Start state. This represents the start of the activity diagram.
2. Activity. It is described as the operational process of the system. Activities start at the start node and terminate at some final node.
3. Decision node. A diamond-shaped box used to encounter a decision within any activity node. It has two outcomes, a Yes or a No.
4. Final State. It is used to illustrate the end of a process/when the process is to be terminated.
5. Fork and Merge. Fork is used to split a process into sub-processes. Merge is used to combine sub-processes into a single process.

Example activity diagram

Let’s look at the activity diagram for selecting a comedy movie. It starts with two processes. In the first process, we decide we have to watch a comedy movie. Then, we decide to look at movie options. This is where our process forks into two sub-processes. Next, we look at the movie options available. Since we decided that we want to watch a comedy movie, and “Mission Impossible” is not a comedy movie, we will discard it by ending the process with the final state symbol. Once we chose “The three stooges,” we then check if cinemas are open or not. If not, the process is ended with the final state symbol. If Yes, then we’ll have a few hours of laughter ahead of us.

Applications of activity diagrams

The purpose of an activity diagram can be described as:

1. Drawing the activity flow of an entire system.

2. Correlating and describing the sequence from one activity to another.

3. Describing the parallel, branched, and concurrent flow of the system.

4. Modeling workflow and business requirements.

5. For high-level​ understanding of any system’s functionalities.

6. Investigating business requirements to be used at a later stage.