This article uses a restaurant customer service system to illustrate how business use-case diagrams can effectively model business processes, including interactions between actors and use cases. It demonstrates how Unified Modeling Language (UML) use-case diagrams capture software requirements and discusses their advantages and limitations in Software Development (SD).
Alexander S. Ricciardi
December 15, 2024
Business use-case diagrams are used to model and illustrate interactions between business actors and processes within businesses. Their primary purpose is to describe how a business is used by its customers and partners (Helm n.d.). In Software Development (SD), use case diagrams are used to capture a system's requirements which is essential in the early stage of SD. This article explores the business use case of a generic restaurant, more specifically the restaurant customer service system by providing a Unify Modeling Language (UML) business use-case diagram and, based on the diagram, offers a critical analysis of the business actors and business interactions. Additionally, it provides a list of advantages and limitations of UML use-cases diagrams in SD.
Definition of Use-Case Diagrams
A use-case diagram illustrates the behavior of systems helping to capture the working requirements of those systems (IBM, 2023). In other words, the diagram describes the high-level functionality and the main scope of systems. Use-case diagrams also identify the interactions between systems use cases and their actors. Actors and use cases can be defined as follows:
Actors can be people, organizations, or external or internal systems that interact with the business. Use cases can be specific functionalities or services that the business provides to the actors and other use cases.
Furthermore, use cases can be divided into base use cases, which represent the core functionalities of the systems (can be modified by other use cases), and additional use cases are supplemental functionalities that can modify other use cases. Additional use cases can also be defined as supplemental functionalities that can modify other use cases.
In UML use-case diagrams, the interactions between use cases are defined as relationships that can be divided into four categories:
Association relationships are illustrations of direct interactions between actors and use cases or between use cases.
Include relationships are illustrations of interactions where use cases include the functionalities of other use cases.
Extend relationships are illustrations of interactions where use cases are extended by other use cases under certain conditions.
Generalization relationships are illustrations of interactions where use cases are generalized versions of other use cases or actors are generalized versions of other actors. It is a parent-child relationship where the parent is the generalized version of a child.
(Helm, n.d)
Figure 1
Restaurant Customer Service System Diagram
Critical Analysis of the Business Actors and Business Interactions
The restaurant customer service system is one of several systems that are part of a restaurant; other systems are, for example, inventory management, accounting, and kitchen. Thus the restaurant customer service system represents one functionality of a restaurant organization. It is a process that involves external actors such as dine-in customers and takeaway customers, and internal actors such as servers, bussers, hosts, service managers, and cooks. Use cases include placing an order, making a payment, and preparing food. Relationships within the system include associations, includes, and extends. Additionally, the use case customer service system model showcased in this essay is based on a model that can be built upon.
Use Cases
Business use cases can be divided into base cases and additional cases; however, they can also be further categorized into three categories which are:
Business processes the commercially important activities (Helm n.d.).
Supporting activities that are not commercially important, but have to be performed.
Management activities are a type of work that affects how the other business use cases are managed.
The table below, Table 1, summarizes the use cases within the restaurant customer service system, categorizing them into business processes, supporting activities, and management activities
Table 1
Use Cases Table
As shown in the table above core business processes like customer service, fulfilling orders, and payment highlight the core functionalities of the business. Supporting activities such as order handling, credit card or cash payment processing, and handling special requests are important functions for the smooth operation of the restaurant and for customer satisfaction.
Actors
Business actors can represent individuals, organizations, and other businesses that interact with the business. Furthermore, actors who interact with the business but are not part of the business use case system are categorized as external actors, and actors who are an integral part of the use case system are categorized as internal actors. The table below, Table 2, summarizes the internal and external actors that interact with the restaurant customer service system.
Table 2
Actors Table
As shown in the table above, the interactions between external actors, customers, and internal actors like servers, bussers, and cooks are essential for the successful operation of the restaurant.
Relationships
Several relationships between actors and use cases, as well as user cases with other use cases and actors with other actors, are involved in the overall functionality of the restaurant customer service system. The relationships have been defined earlier in this essay. However, the generalization relationship can be defined further. It is a relationship that can be described as parent-child inheritance relationship and it can be divided into two categories:
Use case generalization a relationship is where the properties of a parent use case or generalized use case, usually a base use case, are inherited by a specialized child use case.
Actor generalization is a relationship where the properties of a parent actor or generalized actor are inherited by a specialized child a actors
The table below, Table 3, summarizes the different relationships involved in the overall functionality of the restaurant customer service system.
Table 3
Relationships Table
As shown in the table above, relationships between actors and use cases, as well as user cases with other use cases and actors with other actors, demonstrate how complex interactions within the restaurant customer service system are. Additionally, these relationships showcase how the different components contribute to the overall functionality of the system.
Use Cases Advantages and Limitations in Software Development
The use case model, as illustrated in the restaurant customer service system example, is a powerful tool that can be used to model and visually represent interactions between business actors and processes within businesses or systems. In SD, more specifically at the early stage of development, UML use-case diagrams are used to capture system requirements (actors, use cases, and relationships) defining the “What” a system should do. However, they struggle to capture and illustrate “How” these requirements should be implemented. The “what” and the “How” distinctions illustrate the advantages and limitations of the use-case model in SD. The following sections list the main advantages and limitations of the model in SD.
Advantages
Actors and use case components of a UML use-case diagram provide a user-centric approach when modeling a system's requirements. This helps ensure that the correct system is developed by capturing the requirements from a user perspective (Firesmith, n.d). In addition to providing a user-centric approach they also provide the following advantages:
Use cases and actors are easy to recognize and their descriptions are written in natural language making it easy to understand and providing an excellent way to communicate with customers and users (Firesmith, n.d.).
The following list is from “Chapter 5 – Use Case Models-1: Actors and Use Cases. Software engineering with UML” (Unhelkar, 2018 b, p. 92):
Use cases help the business analyst to document requirements in a commonly accepted format in the problem space of the project.
The actor, through the use cases, specifies the suite of interactions with the system.
Use cases capture the functional aspects of the system. More specifically, they capture the business processes carried out in the system. They are usually developed by domain experts and business analysts, resulting in the effective documentation of functionalities.
Since use cases document the complete functionality of a system, no separate functional requirements document is needed (although additional operational and interface requirements or additional details such as the referenced material may be available or placed in a separate document).
Use cases facilitate tracing of requirements. By providing well-organized documentation on the requirements, a use case provides a trace for a particular requirement throughout the system. This is especially helpful in creating and executing acceptance tests by users.
Use cases can help in the creation of prototypes. Developers can select a use case and produce a proof-of-concept prototype of the system that will validate system requirements.
Documentation of a use case provides a means for creating activity diagrams. The documentation of the flow within the use case can also be influenced and improved by the activity diagram(s) drawn for a use case.
Specifications and documentation of use cases also provide a rich source of information for the identification of business entities. These business entities can be put together in a suite of class diagrams—providing vital information in the model of the problem space.
Use cases can also provide a starting point for sequence diagrams—based on the scenarios (or instances of behavior) documented within a use case.
Use cases are the basis for test case development.
Use cases aid in requirement mapping: matching a requirement to a software feature to the approved test case.
Limitations
However, UML use cases also have some limitations. By primarily focusing on a system’s requirements, they may not capture non-functional requirements. In other words, while they capture well what the system should do, they do not demonstrate well how the system should do it. Non-functional requirements, such as performance, security, and usability are often not documented in use cases.
In addition to not capturing non-functional requirements properly, UML use cases experience the following limitations.
The following list is from “Chapter 5 – Use Case Models-1: Actors and Use Cases. Software engineering with UML” (Unhelkar, 2018 b, p. 92):
Use case documentation is not standardized. This leads to confusion and debates on what makes up a good use case. Most projects proceed on the basis of a template (see previous discussion).
Use cases are not object-oriented in nature. Therefore, they are not an ideal mechanism to model design-level constructs in the solution space (where object orientation plays an important role).
Use cases do not have a granularity standard. Therefore, sometimes use cases are written as huge descriptive documents, resulting in the inability of modelers to capitalize on the reusable and organizational aspect of use case modeling. Alternatively, too brief a description will result in a large number of miniscule use cases—making them less comprehensible and manageable.
Use cases do not provide a good basis for coding. Their documentation provides a foundation for subsequent modeling, but not for code generation.
Summary
Business use case diagrams are used to model and visually represent interactions between business actors and processes within businesses or systems. As shown by the critical analysis of the restaurant customer service system the use cases, actors, and their relationships give a deep insight into the processes, interactions, and dependencies within the restaurant customer service operations. Thus, business use case diagrams are a great tool for stakeholders to gain a deep understanding of the business or a system, identify potential issues, and make informed decisions about system design and development. Additionaly, UML use-case diagrams, with their actors, use cases, and relationships, provide a user-centric approach to capturing a system's requirements which is essential in the early stage of Software Development. They excel at illustrating and capturing the “what” a system should do. However, they are not efficient at capturing and illustrating the “How” these requirements should be implemented. More specifically, they struggle to capture non-functional requirements, and they do not provide a good basis for coding generation.
References:
Firesmith D., G. (n.d.). Use Cases: the pros and cons. Knowledge Systems Corporation. https://www.cs.hmc.edu/~mike/courses/mike121/readings/reqsModeling/firesmith.htm
Helm, J. (n.d.). Business use-case model. Rational unified process. Fall 2023 SWEN 5135 Configuration Management course. University of Houston at Clear Lake. https://sceweb.uhcl.edu/helm/RUP_Folder/RationalUnifiedProcess/process/modguide/md_bucm.htm
IBM documentation (2023, September 21). Use-case diagrams. IBM Rational Software Architect documentation. IBM. https://www.ibm.com/docs/en/rational-soft-arch/9.7.0?topic=diagrams-use-case
Unhelkar, B. (2018 a). Chapter 6 – Use case models-2: Use case diagrams and requirements modeling. Software engineering with UML. CRC Press. ISBN 9781138297432
Unhelkar, B. (2018 b). Chapter 5 – Use case models-1: Actors and use cases. Software engineering with UML. CRC Press. ISBN 9781138297432