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[1]. 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."[2] Another site puts it even more simply: "Activity
diagrams are used to illustrate activities."[3] 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."[4] 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."[5] 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."[6]
• 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."[7] 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."[8] 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."[9]

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."[10] (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]."[11] 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.'"[12] 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."[13] 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."[14] 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.