An Introduction to Activity Diagrams


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.

Author: Morgan Masters is Business Analyst and Staff Writer at, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at  

[1]Ericcson, Maria. "Activity Diagrams: What They Are and How to Use Them." Accessed October 14, 2010
[2] Accessed October 20, 2010.
[3]From Sourcemaking: Teaching IT Professionals. Accessed October 20, 2010.
[4]Podeswa, Howard. UML for the IT Business Analyst: A Practical Guide to Requirements Gathering Using the Unified Modeling Language. Second Edition. Boston, MA: Course Technology, 2010.
[5]Podeswa, Howard. UML for the IT Business Analyst: A Practical Guide to Requirements Gathering Using the Unified Modeling Language. Second Edition. Boston, MA: Course Technology, 2010.
[6]Ericcson, Maria. "Activity Diagrams: What They Are and How to Use Them." Accessed October 14, 2010.
[7]Ericcson, Maria. "Activity Diagrams: What They Are and How to Use Them." Accessed October 14, 2010.
[8] Accessed October 20, 2010.
[9] Accessed October 20, 2010.
[10] Accessed October 20, 2010.
[11]Podeswa, Howard. UML for the IT Business Analyst: A Practical Guide to Requirements Gathering Using the Unified Modeling Language. Second Edition. Boston, MA: Course Technology, 2010.
[12]Ericcson, Maria. "Activity Diagrams: What They Are and How to Use Them." Accessed October 14, 2010.
[13] Accessed October 20, 2010.
Poseidon for UML: User Guide - Activity Diagram Accessed October 20, 2010.

Like this article:
  20 members liked this article


JulieK posted on Wednesday, May 4, 2011 12:10 AM
Just wondering if there's a reason you chose to use the oval rather than the rounded rectangle that is the standard notation for activities? I've only ever seen the oval used for use cases.
DEStiles posted on Tuesday, May 10, 2011 12:28 PM
I was wondering the same thing.

According to OMG UML Superstructure Specfication V2.3, Section 12.3.2, the notation for an action is a round-cornered rectangle. In Section 16.3.6, the oval or ellipse is the notation for a use case.
Adrian M. posted on Tuesday, May 10, 2011 3:49 PM
Well - I think that you probably are both correct: the standard activity symbol is the round-corner rectangle. Having said that, some tools use different symbols.

What we probably need to focus on is understanding the usage of these types of tools (ex: activity diagramsa), what they show, when to use them, what problems they solve, etc.

JulieK posted on Tuesday, May 10, 2011 6:48 PM
Sure, agree that the focus should be on the use of the diagram and why you should use them, but if you're going to teach a technique, using the right symbols would be beneficial. The last thing the industry needs is yet more variation in the way we document things.

If we use UML properly, including using all the right symbols for the right diagrams, everyone who has been using UML for the past 15 years will know exactly what the diagram means and won't think that we're inventing something different.

If a tool is using a different symbol, then it shouldn't be calling the diagrams it produces Activity diagrams, and it's certainly not UML-compliant.
slowlearner posted on Thursday, May 12, 2011 2:23 PM
Thank you for the article. It's interesting it isn't also tagged with a category of 'process modeling'. Where i work there is an ongoing debate regarding the need for BPMN when (to paraphrase the UML camp's attitude) "UML activity diagrams already allow you to model everything that BPMN can, so why bother with another notation/standard".
I am not in that camp,believing that there is room for both. I would be very interested in hearing from Modern Analyst subscribers if they have opinions regarding the UML activity models vs BPMN.
Adrian M. posted on Monday, May 16, 2011 4:07 PM

Here's an interesting fact: the OMG (Object Management Group) was the steward of the UML specification, which includes the Activity Diagram, long before BPMN came into picture.

BPMN evolved as a standard notation outside the OMG. OMG decided to also adopt the BPMN notation despite the fact that the UML Activity Diagram had existed for a while.

Now, here comes my personal opinion and interpretation:
- I am reading this as OMG thought BPMN to be a superior way to model processes than the Activity Diagram,
- UML was initially created to model software activities/flow while BPMN was created specifically to model business processes,
- BPMN has a much richer set of constructs.

While BPMN has many overlaps with the UML Activity Diagram, in my opinion BPMN is a much superior way to model business processes. I think that BPMN is awesome!

Do I still use UML Activity Diagrams? Yes. :-)

Hope this helps!
Only registered users may post comments.


Upcoming Live Webinars


Copyright 2006-2024 by Modern Analyst Media LLC