What is an activity diagram?
An activity diagram is a type of flowchart that is part of the UML (Unified Modeling Language) standard. Its purpose is to enable analysts to present a concrete, easy-to-follow visual of the workflow of a business use case. As one site notes, "In the Unified Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control." Another site puts it even more simply: "Activity diagrams are used to illustrate activities." To that end, activity diagrams may be used to describe an entire system, a use case, or an activity within the use case. They also enable the simple presentation of multiple conditions and choices within a workflow. A basic example of an activity diagram is below:
Among the most common workflow diagrams employed by the business analysis profession, activity diagrams are useful for describing "the interaction between the players and the business as the use case is played out." Because they do enable the display of both players and the business processes, and because they employ simple diagramming techniques, activity diagrams are easy for even junior analysts to pick up quickly. They also help analysts to think through the process of the workflow by their very creation. As the Sourcemaking website notes, "Activity diagrams allow you to think functionally." Not only do they enable analysts to think about a workflow functionally, they enable the practical presentation of a workflow.
Elements in Activity Diagrams
The more commonly used elements of an activity diagram are:
§ Initial nodes, which indicate the start of the workflow (also known as initial state). This is represented by a blackened circle.
§ Control flows, which indicate the direction of the workflow. This is represented by an arrow.
§ Activities, which indicate steps or stages in the workflow. These are represented by ovals.
§ Decisions, which indicate a choice between multiple conditions. These are represented by diamond shapes. Useful for presenting workflows that have one or more possible outcomes, "decisions . . . allow you to show alternative threads in the workflow of a business use case."
§ Guard conditions, which indicate a condition required for the workflow to proceed, and which normally (but not always) follows a decision. "Guard conditions control which transition of a set of alternative transitions follows once the activity has been completed." These are represented by brackets.
§ A fork and join, which indicates two or more possible conditions that may occur in the same process. "All branches [or forks] at some point are followed by a merge to indicate the end of the conditional behavior started by that branch. After the merge all of the parallel activities must be combined by a join before transitioning into the final activity state." Both the initial split (or fork) and the latter join are represented by the same symbol, a horizontal bar.
§ End nodes, which indicate the end of the workflow (also known as the final state). These are represented by a blackened circle within a circle.
Elements such as guard conditions, fork and join, and decisions are among the distinct advantages of activity diagrams because they make it possible for analysts to easily display parallel events and multiple conditions—which many real-life workflows have. As one writer notes, "The activity diagram is well suited for the illustration of business processes, since business processes rarely occur in a linear manner and often exhibit parallelisms."
Here again is our example of an activity diagram representing the process of a print publisher acquiring a book deal. Note that each of the elements listed above are included.
Other possible (but not always necessary) elements of an activity diagram include nested activities(basically a small activity diagram within an activity diagram). An example of this is below.
Another variation of an activity diagram is a diagram with swimlanes, which are partitions that indicate who does what—displaying an actor or entity in each lane. An example of this is below.
Constructing the Activity Diagram
An activity diagram’s construction lends itself to practical thinking, while enabling the depiction of workflows with multiple choices, conditions, and actors. A few hints to keep in mind when constructing an activity diagram are:
§ An analyst should start his or her diagram with the initial action in the workflow process. It may be helpful for many analysts to attempt to sketch the diagram on paper before moving to a program.
§ As the diagram moves forward, it will be easier for the analyst to identify which (if any) actors must be added.
§ Arrows should run from the start (initial node) toward the end (end node). "Diagrams are read from top to bottom . . . branches and forks describe conditions and parallel activities." (Note that an activity diagram is basically a UML standard version of a process flow diagram. The UML standard indeed dictates that an activity diagrams be read from top to bottom, but a process flow diagram may also be read from left to right.)
§ Activities are presented in more or less chronological order.
§ If a diagram appears to be becoming too complex, it likely is showing more than one workflow and should be broken into multiple diagrams.
§ Several software programs have activity diagram elements preloaded in their graphics, including Gliffy and SmartDraw.
As with any diagramming technique or tool in the business analyst’s arsenal, activity diagram get easier and smoother with practice.
What are the advantages and disadvantages of using activity diagrams?
Activity diagrams’ advantages include that they are typically easily comprehensible for both analysts and stakeholders. According to Podeswa in UML for the IT Business Analyst, "The activity diagram is the one most useful to the IT BA for depicting workflow [because] it is simple to understand—both for BAs and end-users [emphasis added]." Because they are among the most user-friendly diagrams available, they are generally regarded as an essential tool in an analyst’s repertoire.
Additionally, as stated above, activity diagrams allow an analyst to display multiple conditions and actors within a workflow through the use of swimlanes. Swimlanes, however, are optional as a single condition or actor is normally displayed without them.
Their disadvantages include that they have the potential to become overly complex because their user-friendly nature may lend itself to an all-inclusive description. In other words, since it is so simple to display the information related to the project, why not include all of it? When an analyst has a large project, creating a single, overly complex diagram can be a temptation. But as one author notes, "if you are using activity diagrams to define the structure of a workflow, you should not attempt to explore several levels of activity graphs down to their most ‘atomic’ level.’" Instead, an analyst should try to present a new diagram for each workflow, or if more applicable, to use swimlanes to present different actors within the same workflow. (More information about swimlanes is below.)
Another aspect of activity diagrams is that they may not be used in lieu of a state diagram or sequence diagram because "activity diagrams do not give detail about how objects behave or how objects collaborate." This is not a disadvantage per se, but it is important for an analyst to keep in mind when applying diagrams to their work.
In conclusion, activity diagrams are fairly easy to get the hang of, and will be useful for most projects because they "simply and quite plainly show how things work." Unlike many diagramming techniques, activity diagrams also enable the depiction of multiple choices and actors within a workflow, and they are easy for even non-technical users to follow.