Some people use them. Some people don't use them. Some people create them using sophisticated tools. Some use basic drawing programs. As part of the Unified Modeling Language, Use Case diagrams are often the starting point for many software projects. However, questions about Use Case diagrams still 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?
Recent research can help Business Analysts answer these questions and provide recommendations for implementation.
The Who, What, Why and How of Use Case 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 Use Case 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 Use Case 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 Use Case 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 Use Case diagrams to help describe the behavior of a system this size. In addition, tools today provide the ability to map traceability between Use Cases and Classes to ensure the solution delivered is meeting the end goals of the user. Furthermore, as requirements change (as they often do), being able to know how many classes are affected by a change to a Use Case can provide invaluable information that relates directly to cost, scope and project planning.
Figure 1: Typical Project Size
Why are people not using Use Case diagrams?
Figure 2 shows the reasons given by respondents for not using Use Case 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 alleviate the roadblock to Use Case diagram implementation.
-
Not well understood by analyst – This is easily solved with training or mentoring.
-
Insufficient value to justify cost – There is very little cost to creating Use Case diagrams when using commonly available corporate tools such as Microsoft Visio which adds no additional cost in tools. In addition, recent research has shown that Use Case diagrams do provide cognitive benefits (see next study, below).
-
Not useful with programmers – This, again, is easily solved with training or mentoring. In addition, Use Case diagrams provide the abstract view of system behavior which is the end goal of the programmers efforts.
Figure 2: Reasons for not using Use Case diagrams (% responses)
How are people using Use Case Diagrams?
The researchers asked the respondents to provide a rank (on a scale from 1-5) showing how they were using Use Case diagrams (and other UML diagrams) on projects. A review of Figure 3 shows some interesting numbers.
As would be expected, Client Validation has the highest score. However, it seems that the 2.90 score for Document for future maintenance and other enhancements is low. It appears that practitioners are not taking into account that enhancements, in particular, are not always performed by the personnel that originally created the system. Use Case diagrams are extremely useful in providing personnel, not familiar with the original system, a business context to understand. This may be a consequence of the diagram not being well understood by analysts.
The measures for Implement and Clarify, as defined, are expected as Use Case diagrams are not designed to provide detailed implementation detail for technical members of the project team.
Figure 3: Roles for Use Case Diagrams
Benefits of Use Case Diagrams [2]
Measuring the actual benefits of Use Case diagrams has only recently attracted the attention of researchers. As indicated above in Figure 2, 42% of respondents in the previous study indicated that there was “Insufficient value to justify cost, and a further 29% indicated that Use Case diagrams were “Not useful with clients”. Research published this year, however, shows that Use Case diagrams actually aid in the understanding of the use case narrative.
In this study, the researchers identify a process, Conceptual Modeling, that involves the analyst working with stakeholders to identify the initial ideas of the system, model those ideas, and use that Conceptual Model to have the stakeholders validate the requirements. Since Conceptual Modeling techniques often combine words with graphical symbols, the researchers applied the Cognitive Theory of Multimedia Learning (CTML). The CTML “suggests the most effective communication occurs when verbal and visual pathways are utilized simultaneously.”
49 upper-level business students, with no particular knowledge of object-oriented principles or UML, were randomly assigned to two groups. Each group was presented with a pre-test, five use cases (only one group included a Use Case diagram), tasks (measuring comprehension, retention and problem solving), and a post-test.
Retention and Problem solving measures increased by 22% and 20%, respectively, for the group that included a Use Case Diagram. The overall comprehension measure was unaffected. According to the authors: “These results suggest that diagrams, even simple diagrams such as the use case diagram provided in this experiment, can have measurable effects on viewer understanding.” Utilizing the CTML, he authors proposed, and subsequently showed, that by utilizing both visual and textual information, the reader is able to increase understanding of the system domain being designed.
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 Use Case diagrams and UML in general. As the second study points out, Use Case diagrams increase learning performance when trying to understand Use Cases.
The second recommendation is to include Use Case Diagrams with every Use Case narrative or scenario. Regardless of the simplicity of the diagram, including a Use Case diagram can certainly not hurt the project and will, most likely, increase everyone's understanding of the system domain.
References:
-
Dimensions of UML Diagram Use:A Survey of Practitioners, Journal of Database Management, 19(1), 1-18, January-March 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 operates Prime Proficiency, a company specializing in Business Analyst training.
His research and writing focuses on turning recent, relevant research into implementable actions. You can see more of his Business Analyst writings at www.primeproficiency.com. He can be reached at [email protected]