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]
The 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.
-
Not well understood by analyst – This is easily solved with training or mentoring. Note that nearly 50% of respondents identified this reason.
-
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).
-
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 Modernanalyst.com), 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.
References:
-
Dimensions of UML Diagram Use:A Survey of Practitioners, Journal of Database Management, 19(1), 1-18, January-March 2008
-
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.
-
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 http://businessanalystmastery.com He can be reached at [email protected].
Top photo © Kirill Roslyakov - Fotolia.com