A use case diagram (UCD) is a graphical depiction of a software system, use cases within this system, and the actors of the use cases. UCDs are used to model the behaviour of a system and to help capture the requirements of the system, without going into detail about technical aspects like data structures or algorithms. The diagram is part of the Unified Modeling Language, or UML for short. Within UML, it is a subclass of behavioural diagrams.[1][2][3]
A use case diagram consists of different elements, the most prominent elements being the Actor, Use Case, and System. A use case diagram can contain a box representing the system and its boundaries. Within the system, ellipses represent use cases. Outside of the system, actors are represented as stick figures. Actors can have a relation to one or more use cases that belong to the actor using simple lines. A use case can have a relation with one or more actors. Relations can also exist between actors themselves, or between use cases themselves, see Elements:Relations.[4][5][6]
Use case diagrams can be used to answer the following questions:[3]
What is being described? (the system)
Who interacts with the system? (the actors)
What actions can these actors perform? (the use cases)
Use case diagrams can be used throughout the entire software development process, and can provide value to anyone involved with the project, including the developers, testers, management, and stakeholders. IBM describes four situations in which use case diagrams can be helpful:[7]
Before or while starting a project, UCDs can be used to model a process or system to make sure all participants have the same global understanding of the process or system.
While gathering requirements, UCDs can be created to show the system requirements to both the stakeholders, as well as the developers.
During analysis and design phases, the components of the UCD, mainly the actors and use cases, can be used to identify the classes that the system requires.
During the test phase, UCDs can be used to identify tests for the system.
The term use case diagram was first used in 1986 by the inventor of the use case Ivar Jacobson.[5] The usage of use case diagrams in research however, be it in papers or in articles in journals, started at around 1996 according to Google Scholar.[8] Until 2000, UCDs appeared sporadically in such publishments.
From 2001-2005, three publications express interesting aspects of UCDs.
First, a paper published by Siau, K. and Lee, L. (2001) states that use case diagrams were “undoubtedly the most controversial diagramming technique in UML”.[9] The study laid out an experiment to “better understand the informational value of UCDs in communicating and verifying requirements analysis”. The results of this study sadly have not been found anywhere online by the authors of this Wikipedia page.
A second paper highlights a different branch of research that would gain support in later years, being the automatic generation of UCDs, and generation of elements from UCDs. A bachelor’s thesis by Cayaba, C. and Rodil, J. (2005, though formally published in 2006) put the focus on a system that automatically generated UCDs from English requirements specification documents by a system they named “CAUse”.[10][11]
A third publication shows research in the direction of formalization of UCDs, another branch of research that would continue to develop in years to come. This publication did research with the aim of formalizing, testing and executing a use case diagram in order to find errors in a requirements model during the early phase of software development.[6]
Between 2006 and 2010, research on UCDs increased. Until 2005, research was mostly done on understanding UCDs and allowing generation of UCDs, with both branches of research consisting of a small number of published articles. From 2006 onwards however, two categories became more widely researched.
The generation of UCDs and generation of items (other diagrams, test cases, and more) from UCDs, a branch of research which was seen in the first half of the decade, continued to grow with several new publications. In this timeframe, multiple publications came out on using UCDs to generate test cases.[12][13]
Second, the formalization of UCDs became a branch of research concerning UCDs. Multiple papers formalized UCDs using the Z notation, a formal specification language used for describing and modelling computing systems, making the UCDs structured and easier to employ automation-techniques on.[14][15] A different publication focussed on developing well-formedness rules (WFR) for UCDs, where WFRs describe consistency rules between diagrams.[16] A third paper proposed a formal model of use cases and presented methods of formal analysis and verification.[17]
At the end of the previous decade, Ibrahim, N., Ibrahim, R. et al. (2010) stated that UCDs were “one of the most used diagram[s] among UML practitioners”.[16] Looking at publications in the timespan of 2011 – 2015, this popularity of UCDs is well-visible.
Several new pieces of research were published in the period from 2011 to 2015. A paper was published concerning automized-UCD generation, this time from use case descriptions written in the Portuguese language[18], keeping the topic of automatization alive. A different paper was published concerning the role of the UCD in software development[19], concluding that “the significance of [the] use case diagram is increasing as the size of the project increases”. Lastly, a book was published in a book series “Undergraduate Topics in Computer Science” called “UML @ Classroom” explaining the history of UML, as well as several diagrams within UML including the UCD.[3] Publications like these prove the significance of the UCD within software development.
From 2016 onwards, research on UCDs has been more popular than ever, with research on UCD in this period being present in several research branches.
As per usual, automation was one of the biggest branches within UCD-related research. Within this branch, research has been done on automated UCD semantic assessment[20], support for automating transformations from SBVR to UCDs[21], automated UCD generation from textual user requirement documents[22], and plenty more.
The research branch of formalisation also sees multiple publications. Some publications focus on formalizing UCDs with Z notation[23], as well as other research on using Event-B (a method related to Z notation).[24]
Actors are roles that can be played by persons, groups of people, organizations, or external systems that interact with the system.[25][26][2] They are outside the system and are depicted as human figure icons.[26][27][2] An object may have one or more roles in interacting with the system, but an object can play only one role at a time.[28]
Actors interact with use cases which are represented by horizontal ellipse.[2] Use cases are things that the system performs for its actors.[26] They are functionalities of the system[25] which provide measurable value to the users.[2]
Uses cases are placed within the system boundary, which is shaped as a rectangle.[2] Anything inside this boundary is a functionality in the scope of the system.[25][2] If a system is large and complex, each module could be a separate system boundary.[29]
Example of an association relationship in a use case diagram
Actors and use cases are connected with lines that symbolize the relationship between them.[25][2] An association can have an optional arrowhead.[26][2] This represents which element indicated the action. The actor or use case which started the interaction will in that case be at the blunt end of the line. There are three special types of relations:[25][28]
Example of an include relationship in a use case diagramInclude (or Use): This adds functionality to a main use case with another use case.[25] It indicates that the main use case will include the behaviour of another use case. This type of relationship is shown by a directed arrow having a dotted line with “<<include>>” written next to it.[29] It points from the main use case to the child use case.
Example of an extend relationship in a use case diagramExtend: This relationship represents optional functionality.[25] It is also shown by a directed arrow having a dotted line, but with “<<extend>>” written next to it.[29] It points from the optional use case to the main use case.[30]
Example of a generalization relationship between actors in a use case diagramExample of a generalization relationship in a use case diagramGeneralization: A generalization can be used between different actors or between different use cases.[25][31] The child actor or use case inherits the behaviour of the parent actor or use case. This relationship is shown with a directed arrow with a triangle arrowhead. The child needs to be at the base of the arrow, and the tip is connected to the parent.
While technical specifications can contain a lot of in-depth information about the workings of a system, a use case diagram can help provide a higher-level overview of the system. This is caused by the use case diagram providing a black-box view of the system [5]. This higher-level overview has several benefits, the first being that this high-level overview takes a lot of (technical) detail away. This abstraction makes it easier for all users to understand the diagram better. For instance, it allows users to see if their needs are satisfied at the very beginning of the development process [6]. A second reason the black-box high-level overview benefits the use case diagram is the function of a use case diagram as a blueprint for the software development process [6].
Due to their simplistic nature explained above, use case diagrams can be a good communication tool for stakeholders. The drawings attempt to mimic the real world and provide a view for the stakeholder to understand how the system is going to be designed. Siau, K., Lee, L. (2004) conducted research to determine if there was a valid situation for use case diagrams at all or if they were unnecessary. What was found was that the use case diagrams conveyed the intent of the system in a more simplified manner to stakeholders and that they were "interpreted more completely than class diagrams".[32][33]
It is not possible to model everything in a use case diagram. A few important limitations to consider are:
It is not possible to show or specify execution constrains between use cases.[34]
A use case diagram does not show in which order, how often and at what time interval use cases occur.[2]
You can only model the system and its immediate environment. If, for example, two actors share information related to the system, outside of the system, this communication can not be shown in the use case diagram.[34]
Likewise, it is also not possible to show how multiple systems relate to eachother.[34]
One of the goal of a use case diagram is to also be able reach a wide nontechnical audience. When qualifying elements are added and the complexity increases, this could overwhelm some of the intended stakeholders.[35]
^“ABOUT THE UNIFIED MODELING LANGUAGE SPECIFICATION VERSION 2.5.1.” About the Unified Modeling Language Specification Version 2.5.1, Dec. 2017, https://www.omg.org/spec/UML/About-UML/.
^ abcdefghijAleryani, Arwa. ‘Comparative Study between Data Flow Diagram and Use Case Diagram’. International Journal of Scientific and Research Publications, vol. 6, 2016, pp. 124–2250.
^ abcSeidl, M., Scholz, M. et al.: ‘The Use Case Diagram. In: UML @ Classroom’. Undergraduate Topics in Computer Science. Springer, Cham.
^Rizzo Aquino, Erika and Saqui-Sannes, Pierre de and Vingerhoeds, Rob A. "[https://hal.science/hal-02882415/document A Methodological Assistant for Use Case
Diagrams]". (2020) In: 8th MODELSWARD : International Conference on Model-Driven Engineering and Software
Development, 25 February 2020 - 27 February 2020 (La Valette, Malta).
^ abcdDong, Jin Song, et al. “Formalization, Testing and Execution of a Use Case Diagram.” Formal Methods and Software Engineering: 5th International Conference on Formal Engineering Methods, ICFEM 2003, Singapore, November 5-7, 2003 ; Proceedings, Springer, Berlin, 2003, pp. 68–85.
^Swain, S., Mohapatra, D. and Mall, R.: ‘Test Case Generation Based on Use case and Sequence Diagram’. International Journal of Software Engineering, vol. 3, 2010.
^Ismail, N., Ibrahim, R. and Ibrahim, N.: ‘Automatic Generation of Test Cases from Use-Case Diagram’. Proceedings of the International Conference on Electrical Engineering and Informatics, 2007.
^Sengupta, S., Bhattacharya, S. et al.: ‘Formalization of UML use case diagram-a Z notation based approach’. 2006 International Conference on Computing & Informatics, pp 1--6, 2006.
^Mostafa, A., Ismail, M., et al.: ‘TOWARD A FORMALIZATION OF USE CASE DIAGRAM USING Z SPECIFICATIONS’. Journal of Engineering Sciences, Assiut University, vol. 34, pp 173--188, 2006.
^ abIbrahim, N., Ibrahim, R., et al.: ‘On Well-Formedness Rules for UML Use Case Diagram’. Lecture Notes in Computer Science, vol. 6318, 2010.
^ Klimek, Radosław, and Piotr Szwed. “Formal Analysis of Use Case Diagrams.” Computer Science, vol. 11, 2010, pp. 115–131.
^Anchiêta, R., Sousa, R. and Moura, R.: ‘Using NLP techniques for identifying GUI prototypes and UML diagrams from use cases’. Proceedings of the International Conference on Software Engineering and Knowledge Engineering, pp 48--53, 2013.
^Fauzan, R., Siahaan, D. et al.: ‘A Different Approach on Automated Use Case Diagram Semantic Assessment’. International Journal of Intelligent Engineering & Systems, vol. 14, 2021.
^Essebaa, I., Chantit, S.: ‘Tool Support to Automate Transformations from SBVR to UML Use Case Diagram’. Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering, pp 525-532, 2018.
^Ahmed, I., Daleel, M.: ‘Automated Use Case Diagram Generation with Non-functional Requirements using Neural Network’. International Journal of Applied Information Systems, vol. 12, 2020.
^Muhamad, Z., Abdulmonim, D. and Alathari, B.: ‘An integration of uml use case diagram and activity diagram with Z language for formalization of library management system’. Institute of Advanced Engineering and Science, vol. 9, 2019.
^Sousa, T., Kelvin, L., et al.: ‘A Formal Semantics for Use Case Diagram Via Event-B’. Journal of Software, vol. 12, 2017.
^ abcdefghJebril, Eyad M., et al. “An Algorithmic Approach to Extract Actions and Actors (AAEAA).” Proceedings of the International Conference on Geoinformatics and Data Analysis, Apr. 2018, https://doi.org/10.1145/3220228.3220247.
^ abcdBittner, Kurt, and Ian Spence. Use Case Modeling. Addison-Wesley, 2008.
^Grechanik, Mark, et al. “Recovering and Using Use-Case-Diagram-to-Source-Code Traceability Links.” Proceedings of the the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on The Foundations of Software Engineering, Sept. 2007, https://doi.org/10.1145/1287624.1287640.
^ abArifin, Mohammad Nazir, and Daniel Siahaan. “Structural and Semantic Similarity Measurement of UML Use Case Diagram.” Lontar Komputer : Jurnal Ilmiah Teknologi Informasi, vol. 11, no. 2, Aug. 2020, p. 88., https://doi.org/10.24843/lkjiti.2020.v11.i02.p03.
^Dolques, Xavier, et al. “Fixing Generalization Defects in UML Use Case Diagrams.” Fundamenta Informaticae, vol. 115, no. 4, 2012, pp. 327–356., https://doi.org/10.3233/fi-2012-658.
^Siau, K., Lee, L.: ‘Are use case and class diagrams complementary in requirements analysis? An experimental study on use case and class diagrams in UML’. Requirements Eng, vol. 9, pp 2009--237, 2004.
^ abcWegmann, Alain, and Guy Genilloud. "The role of “Roles” in use case diagrams." International Conference on the Unified Modeling Language. Springer, Berlin, Heidelberg, 2000.
^Dedeke, Adenekan, and Benjamin Lieberman. "Qualifying use case diagram associations." Computer 39.6 (2006): 23-29.
