From Research to Implementation: Activity Diagram – Usage and Benefits


As part of the Unified Modeling Language, Activity diagrams are often utilized for many software projects. However, a few questions about Activity diagrams linger in the minds of many Business Analysts, such as:

  • Who is really using them?

  • What kind of projects are they being used on?

  • Why are people not using them?

  • How are people using them?

  • Are they providing any benefit?

The three research studies presented below can help Business Analysts answer these questions and provide recommendations for implementation.

The Who, What, Why and How of Activity Diagrams [1]

Activity DiagramThe first research paper helps us answer the Who, What, Why, and How questions relating to the actual implementation of Use Case diagrams in the field. This study was conducted by the authors with full support of the Object Management Group (OMG). The authors created a web survey composed of 38 questions designed to inquire about UML usage, including Activity diagrams. A total of 284 meaningful responses to the survey were collected and analyzed. The first meaningful piece of data to come out of this study indicated that 182 respondents utilize UML while 102 provided reasons why they were not using UML.

Who is really using Activity diagrams?

The average practitioner has 15.1 years of IT experience, but they only have 4.7 years of UML experience. It is interesting to note that UML has been around for more that 12 years, but many experienced individuals still have a considerably low amount of time working on projects with UML. It is not really clear why there is such a low level of experience as the data showed no correlation between number of years of experience and UML diagram usage.

What kind of projects are Activity Diagrams being used on?

Figure 1 shows us that UML diagrams are being used on non-trivial projects. Note that the average number of Use Cases per project is 88. This is a lot of information to convey, and it would seem beneficial to provide a Use Case Model that contains Activity diagrams to help describe the behavior of a system this size. In addition, tools today provide the ability to map traceability between Activity diagrams, Use Cases and Classes to ensure the solution delivered is meeting the end goals of the user. Furthermore, all people, including developers, consume information in various forms with varying levels of comprehension. It can be important to model the flow of a Use Case as an Activity diagram, especially if the use case has a significant number of alternate flows and extensions.

Figure 1: Typical Project Size

Why are people not using Activity diagrams?

Figure 2 shows the reasons given by respondents for not using Activity diagrams (respondents were allowed to choose more than one answer, so total % is greater than 100). Looking at this data, there are a few areas that can be addressed easily and cheaply to provide the momentum for Activity diagram implementation.

  1. Not well understood by analyst – This is easily solved with training or mentoring. Note that nearly 50% of respondents identified this reason.

  2. Insufficient value to justify cost – There is very little cost to creating Activity diagrams when using commonly available corporate tools such as Microsoft Visio which usually adds no additional cost in tools. In addition, recent research has shown that Activity diagrams increase the quality of UML artifacts they are used with (see third study, below).

  3. Not useful with programmers – This, again, is easily solved with training or mentoring. Notice the relatively low respondent rate. In my experience, programmers would rather begin coding based off the Activity diagram due to it's logical structure, compared to the text of a use case scenario.

Figure 2: Reasons for not using Activity diagrams (% responses)

How are people using Activity Diagrams?

The study ask those respondents who reported using a particular diagram at least a third of the time, to rated them from “Moderately Useful” to “Essential” for four different purposes. The percentage of respondents who viewed Activity diagrams at least “Moderately Useful” for each purpose is presented in Figure 3.

The relatively high percentage noted for Client Validation is expected. As mentioned before, it is often easier to trace the path of a complex Use Case scenario or functional system behavior by looking at the Activity diagram compared to reading pages of text.

The highest percentage, 81, for Implement seems to support the assertion that programmers find it easier to follow the state-like logic of an Activity diagram compared to a Use Case narrative (UC narrative scored a 79). However, the lowest percentage, 73, for Documentation is a bit disheartening. Considering that changes involving maintenance and enhancements can touch other logic, it would seem that the impact of changes would be easier to visualize using good Activity diagrams. Given that the Clarify score is the second highest for Activity diagrams, it would follow that a diagram that is good at clarifying understanding among technical members of the team would be extremely useful as documentation for changes or enhancements.

Figure 3: Roles for Use Case Diagrams

Benefits of Activity Diagrams [2] [3]

The authors of the second study looked at software projects that utilized both Activity diagrams and Use Case descriptions to identify potential areas for improvement. They found that when closely related to Use Case descriptions, Activity diagrams can serve to increase the quality of both the Use Case description and the Activity diagram themselves by looking at overlapping quality areas.

The authors applied a conceptual model quality framework to discover quality problems when Activity diagrams are closely tied to Use Case descriptions. The authors studied 26 semester-long projects performed by undergraduate students at the City University of Hong Kong. The authors identified several common, overlapping quality problems that led them to specific recommendations to improve the quality of both Activity diagrams and Use Case descriptions.

(quoted from the reasearch paper, highlighting and italics were added)

a) Ensure labeling consistency across artifacts: Since the use case models and activity diagrams represent the system requirements from different perspectives, several elements from use case models such as use case names, actor names, and action part of step descriptions are also used in activity diagrams as name of the diagram, swimlane label, and activity names.

b) Enhance structural alignment: In addition to ensuring consistency in naming across various artifacts, structural alignment between use case descriptions and corresponding activity diagrams must be verified. In this regard, relationships among use cases, sequence of steps, step extensions and iterations must be matched against decision points, alternate paths, activity sequence and loops in activity diagrams.

c) Focus on specification quality of step descriptions and activities: Focus on removing ambiguity from step descriptions by enhancing the details presented in step descriptions, removing implementation details (especially when modeling logical requirements), and achieving uniform granularity in steps or activities.

d) Adhere to notational conventions: Adhere to a given set of notational conventions, as true in many types of specifications, plays an important part in enhancing the communication. The tools used for creating these artifacts assist only to a certain extent, and additional guidelines based on our findings can be defined and followed.

In the third research study (which you may be familiar with from my Use Case Diagrams: Usage and Benefits article here at, individual Retention and Problem solving measures increased by 22% and 20%, respectively, for the test that included a Use Case Diagram. According to the authors, additional improvement is likely by adding additional UML diagrams such as the Activity diagram.

Recommendations for Implementation

The first recommendation comes directly out of Figure 2 above. Companies need to provide adequate training and mentoring to both Business Analysts and Programmers to understand Activity diagrams and UML in general.

As the second study points out, Activity diagrams, especially those closely tied to Use Case models, can help improve overall quality if the proposed recommendations are followed. If you have Activity diagrams that are tied closely to Use Case descriptions, the four quality improvement suggestions are recommended.

Finally, as the third study indicates, inclusion of an Activity diagram can aid in the understanding of those trying to understand the system being developed.


  1. Dimensions of UML Diagram Use:A Survey of Practitioners, Journal of Database Management, 19(1), 1-18, January-March 2008

  2. Exploiting the Complementary Relationship between Use Case Models and Activity Diagrams for Developing Quality Requirements Specifications, I.-Y. Song et al. (Eds.): ER Workshops 2008, LNCS 5232, pp. 144–153, 2008.

  3. Use Case Diagrams in Support of Use Case Modeling: Deriving Understanding from the Picture, Journal of Database Management, 20(1), 1-24, January-March 2009

Author: Mr. Botz is a working Business Analyst and the host of the Business Analyst Mastery podcast. His research and writing focuses on turning recent, relevant research into implementable actions. You hear his podcast at He can be reached at [email protected].

Top photo © Kirill Roslyakov -

Like this article:
  19 members liked this article


edward posted on Monday, September 27, 2010 3:31 PM
very good summary article w/ hard facts as to why Activity Diagrams (A.D.s) can be [not always will be] very useful when describing/confirming requirements.

what's amazing to me is that 1/2 of the respondents of the first survey did not understand what A.D.s are all about and where they are of most value. they are so similar to flowcharts and state models that i am amazed that analysts werent able to make the small jump from those models to activity models!! this is NOT rocket science, just plain old flow/state modeling!!

in my current project, we've used A.D.s to describe/specify consistent behavioral for many processes and alternative/exception flows. they complement our use cases. many of our "use cases" are really descriptions of system behavior for processes that are initiated by events [receipt of data, transition of an item from one state to another, etc.] and have very little actor involvement [that's why i quoted "use cases"]. the processes are rather complex but do have lots of similar patterns in them [for example, interacting w/ an external system - sending information, waiting for a response (and raising an alert if it doesnt arrive after a certain time), and processing the response].

we've also used them to describe/specify "managing item" and "configure system" use cases (* see below). although these processes are somewhat simpler, they've helped the business stakeholders see how the different user interfaces are all variations of a single theme [find an item, view/edit it, perform one of the many actions when viewing/editing it].

finally, A.D.s also help show the business stakeholders and the developement and test teams the scope and/or complexity of a process so they can review, estimate, and plan for it. showing a rich activity diagram goes a long way in showing the "size" of something that showing a 10-20 page use case can ever do.

(* for one way to structure Use Cases, see "Inside The Oval : Use-Case Content Patterns" by Martin Langlands. very insightful paper for patterns in requirements.
posting -
the paper - )
Leslie posted on Monday, September 27, 2010 10:14 PM
This is a great overview justification for using diagrams with use case modeling.

Thanks for the link to Use Case patterns, erperez.

I do not want to complicate this article by adding references to my own, but since I received this article from linkedin, I hope it is ok to refer back to linkedin discussions on the same subject.

I started a group on linkedin named 'Analysis Through Pictures'. The intent is to gain feedback on a book of guidelines for UML modeling (and other things). Subscription is open to the public, and if you open the discussions named
Chapter 5 and Chapter 8,
there are links to articles explaining how to do exactly what is being proposed in the article.

Nope this is useful.

Tony Markos posted on Wednesday, September 29, 2010 5:39 PM
When are Activity Diagrams not appropriate? Answer: At the bigger-picture level, especially on larger scale efforts. Here system processes can typically occur in any order - there is no sequence. Activity Diagrams are sequence based. An analyst cannot use a sequence based modeling technique when there is no sequence.

In theory, Use Cases, as they are nonsequence based, could be used for higher-level modeling on large scale projects. But larger scale modeling efforts require the use of effective partitioning/decomposition. As Use Cases have no mechanism to actually guide the BA through a logical partitioning, they result in a rather arbitrary partitioning. An arbitrary partitioning can only be decomposed downward about one level. After that, the ability to see the interrelationships between processes/activities becomes very poor and therefore the model is of little use.

Brad posted on Wednesday, September 29, 2010 8:39 PM

I can understand not using ADs at the very highest level of abstraction. Like any tool, there are times to use it and times not to use it. Thanks for point that out.

Although Use Cases on their own do not provide a deep level of logical partitioning, the book "Use Cases: Patterns and Blueprints" identifies some ways to build models that incorporate the kind of partitioning you are talking about. Granted, I wouldn't want to navigate a complex model through paper documentation, but today's tool sets allow quite a lot of functionality for navigating complex/partitioned models.

edward posted on Wednesday, September 29, 2010 10:47 PM
to tony.

you wrote...
When are Activity Diagrams not appropriate? Answer: At the bigger-picture level, especially on larger scale efforts. Here system processes can typically occur in any order - there is no sequence. Activity Diagrams are sequence based. An analyst cannot use a sequence based modeling technique when there is no sequence.

i beg to differ, esp when you go on to state that "Use Cases, as they are nonsequence based, could be used for higher-level modeling on large scale projects."

they are BOTH descriptions of behavior [a process]. so whatever can be represented in a use case diagram can always be represented in an activity diagram and vice versa [although the translation might not look so good, it can be done]. each step in a use case's primary and in each alternative/exception flow and each transition from one action state to another is the result of someone or something initiating an action, responding to an event, or performing an operation.

they are NOT that much different from flowcharts of days gone by [and i still have my IBM HIPO chart template (Hierarchical Input Process Output, circa 1974).]

either of these can be used to describe any level of behavior. at a higher level, the steps/flow would generally [but not always] describe a process that is completed in a very long time frame [think of the process from car rental reservation to car check in]. at a lower level, the steps/flow might be shorter.

i've worked on many projects where i've used both and in all cases, the business stakeholders have had a easier time working thru the process when dealing w/ activity diagrams than with use cases = a diagram is worth a thousand words. They have been able to revise it, improve it, and confirm it much quicker than reading textual descriptions. there are several modeling/requirements tools that present activitiy diagrams and can simulate them, then convert to textual use cases.

but, to your question, "When are Activity Diagrams not appropriate?" when the behavior/process is way too complex or way too simple. Or when the audience/consumers of the information are not able to understand the process [which means it should be re-thought/re-worked]. Or when they just dont want to deal with diagrams.
Tony Markos posted on Thursday, September 30, 2010 6:34 PM

I will check out "Use Cases: Patterns and Blueprints"


Tony Markatos
Brad posted on Thursday, September 30, 2010 7:41 PM

Specifically, check out the Component Hierarchy, Layered System and Use Case Sequence Patterns. I would be interested in your thoughts concerning large systems and these patterns. Feel free to email me directly.
Gil posted on Thursday, October 14, 2010 10:59 AM
I want tor cry!!!! Something is going wrong here.

Either OMG have done a Tony Blair, and said lets forget our principles and let UML be what ever the clowns (voters) out there think it is
The survey has used pre-conceptions throughout its analysis
the author has added a lot of bias into this article.

UML defines Use Case Diagrams, Class Diagrams (both for domain and programming use), Sequence Diagrams, State Diagrams, Object/Communication Diagrams and a couple of sets of diagrams for documenting implementation. It also includes Activity Diagrams as a general purpose tool for enhancing detail where (exceptionally) the formal tools become confused.

In this capacity, it is ideal for expanding algorithms which are required by the business and need to be defined in the operations section of a class: the 'Block and Scholls' method for evaluation stocks in the futures mareket, the 'legislated loading rules', for loading and moving oil tankers (road), the Rete Algorithm for AI processing are some more extreme examples.

Activity diagrams, which are flow charts with a pseudo-parallel capability are useful for business process ('asis' and 'tobe') although BPMN seems to be more often used these days. They have their pluses and minuses.

Activity diagrams used to draw out the flows in use case descriptions in a complete NO! NO!. Martin Fowler first pointed out the reasons for this, and they are so true.

Use cases identyfy the things that users (actors) want to do on the system. In my opinion, they are best described by the paraphrased exression use by agile developers for user stories.
"As an 'actor' I wish to 'do blah' in order to achieve 'goal'."
It describes what they want to achieve by 'doing blah'. Either the 'do' or 'blah' can be conditioned by a gramatical clause, but only rarely; always query it!
When described this way, you get a complete description (Happy Day Scenario) of WHAT the use case does and achieves but NOT HOW it does it. The detailed scenario descriptions should NOT exceed about 9 pairs of statements; one starting 'Actor does ....' and the single response 'System does ....'.
You may also have (1) occasionally an Aternative Success path, (2) 2 or 3 Failure paths
(3) 1 or 2 Exception Paths. Each of these should NOT be much more that 2 or 3 statements.
Why do you want to draw something like that in a diagram. It should cover NO more than 2 or 3 pages of text. (NOT the 30 to 40 pages that I all too commonly see).

If you need an activity diagram to describe the scenarios of a use case then the use cases is too detailed. It will certainly contains considerable HOW description.

My view, that rather than having surveys, that show the obvious biases described in this blog, dictate to OMG how their very well analysed product should work, the education should be on using UML for the purpose it was designed.

If 60-70% of the users are using UML (particularly use cases wrongly) should we NOT conclude that the education you talk about should be telling them about the solid theoretical values that underly UML and persuading them to follow the 20-30% who are doing it correctly. This is what surveys like this should be telling us. Then those of us who understand and see the benefits of UML should respond to them and try to get every one back on track.

I'm fed up with huge use case scenarios covering tens of pages and telling it all. They are difficult to read, but because they are too big. I call them mini-specs, which is what we used to do around 1990, when they were at the front of technology.

Let us look at your blog:-

Who is really using Activity diagrams?
The majority are NOT experienced and dont seem to know what they are doing! Let us NOT base any advice on this survey, other than to note that.

What kind of projects are Activity Diagrams being used on?
88 use cases is NOT a case for drawing activity diagrams to clarify this detail. The activity diagrams you refer to describe apply inside their respective use cases and so add nothing to the complexity of having a large number of use cases. Use Case Diagrams are provided for this purpose. Someones logic is incorrect here.

If use cases have significant numbers of alternate paths etc, then the use case is too complex. Rember the ' 7 plus or minus 2' rule for good presentations. Divide it into a number of 'included' use cases. Such use cases are all too often said to be only for shared logic, but officially they are defined as being used where a sub goal can be distinguished and that sub goal can be 'included' in the primary use case. Hence the name 'included'. Again draw packages of use case diagrams, NOT Activity Diagrams.

Why are people not using Activity diagrams?
1. It is NOT just the analysts who dont undetstand UML and use cases, but it seems to be the survey analysts or the writer of this review who dont understand it.
2.The is a huge cost in drawing activity diagrams. The diagram, if drawn properly takes nearly as much time as the description; probably more if the description is as simple as it should be. Then you have to check that the two are consistant. My experience is the every reviewer also does this. Further every amendment has to be done twice and then checked by all and sundry again. Remember, you probably have 5 amendments to every written feature. Now the cost is several times the cost of writing the use cases.
3. Programmers, when trained and given the choice much prefer sequence diagrams; they are not call'pictorial coding' for nothing. Why train them to use the tool that is NOT defined for that purpose. Why NOT teach them about sequence diarams. It is my experience that analysts should be trained to write sequence diagrams.

I will NOT continue down the rest of the blog. It does NOT get better. It get worse.

One comment on an early comment. They say -----many of our "use cases" are really descriptions of system behavior for processes that are initiated by events [receipt of data, transition of an item from one state to another, etc.] and have very little actor involvement [that's why i quoted "use cases"]. the processes are rather complex but do have lots of similar patterns in them [for example, interacting w/ an external system - sending information, waiting for a response (and raising an alert if it doesnt arrive after a certain time), and processing the response].----- These are NOT use cases, they are mini specs. But it just goes to show how people doing the wrong thing reinforce one anothers errors.

I will also make a point of checking out "Use Cases: Patterns and Blueprints". It may make more sense.


Brad posted on Thursday, October 14, 2010 1:43 PM

I appreciate a spirited discussion because it forces people to look at their stance and evaluate their understanding of things.

The first thing that we should be clear about is that the OMG specification of UML is concerned with the syntax and semantics of modeling. It most certainly does not specify what or how to represent a particular implementation of a process, business rule, etc....

Additionally, I think it's good for everyone to remember that documents, whether use cases, mini-specs, or whatever, are written for an audience to "understand" them. Does it really matter whether I follow your methodologies or Martin Fowler's advice, as long as the reader of the document understands it?

I can tell that you are passionate about this topic, but I absolutely do not subscribe to a single way of doing things.

Although you may disagree with my interpretation of the data presented as well as my recommendations, I will submit that my projects tend to be described well enough that they come in on time, on budget and meeting customer requirements.

Also, given the length of your response, I think you might enjoy writing an article for this community, and I'm sure the community would enjoy a opposing view with the appropriate supporting research as well.
Leslie posted on Thursday, October 14, 2010 7:37 PM

You bring up some valid concerns about using activity diagrams.

"best described by the paraphrased exression use by agile developers for user stories" - for some of us user stories are not adequate. Personally, I want a graphical check that I have caught all of the exception, alternative and parallel flows in my use case. Activity diagrams are the best UML tool for doing this. Text alone is too inconsistent.

"f drawn properly takes nearly as much time as the description; probably more" - my preference is to draw the diagram and derive the steps from that. The text is purely an explanation/clarification of the diagram. Given a choice, I prefer activity diagrams over text.

"Then you have to check that the two are consistent." - this is a genuine concern. There are tools that will automatically generate the activity diagram from the text, but IME do not do a good job of round-trip engineering, especially when it comes to parallel flows. Ideally, I want to draw the diagram and have the text automatically generated.

Talking of parallel flows, I have not yet found a textual notation that adequately allows me to specify when steps may occur in parallel.

"Why NOT teach them about sequence diagrams" - sequence diagrams just don't work when describing alternative and parallel flows. They may be useful for simple basic flows, but are not able to show parallelism without spreading the activity over several diagrams. That said, I do use sequence diagrams to represent use case realizations.

"WHAT the use case does and achieves but NOT HOW it does" - if you are seeing this in use case activity diagrams, I blame the analysts, not the notation. Education and training can encourage analysts to present the 'right' level of detail for a use case activity diagram.

I would be interested in Fowler's concerns about activity diagrams. But for many of us, they are great tools for confirming the correctness of our use cases.

If you are interested in learning more about how they may be used consistently and with the right amount of detail you may reference my work on the subject:

Only registered users may post comments.


Upcoming Live Webinars


Copyright 2006-2023 by Modern Analyst Media LLC