A Use Case Diagram is a Diagram that shows a set of Use cases, actors, and the relationships between them. It describes how users want to use a system. The use case diagram shows who are the relevant users of the system, what services they want the system to provide, and what services they need to provide for the system.
What can use case diagrams give us?
- Used to describe the functional requirements and usage scenarios of the system to be developed.
- Facilitate progress at all stages of the development process.
- Used to validate and validate system requirements.
Use case modeling is a good way to implement system requirements analysis, through which system analysts and customers can better communicate system requirements.
The composition of a use case diagram
In the introduction we said that a use case diagram is a diagram that shows the relationships between a set of use cases and actors. What follows is a detailed explanation of what a use case is, what the actors are, and what the relationship between them is.
Actors (Actor)
Actors, also called roles, represent users of the system. It is important to note that the user is not a person. If we are developing a public API project, then the caller of the API is our user.
The actor refers not to the user itself, but to the role it plays in the system. For example, Zhang SAN is the owner of a Taobao store. When he participates in the interaction of Taobao, he can either play the role of the owner or buy things on Taobao as a buyer. At this time, Zhang SAN plays two roles in the system, which are two different participants, buyer and seller.
The role of the participants is:
- Establish the external user model of the system
- Describes objects outside the boundaries of the system
Let’s start with two cases:
Example: The salesman will send the sales information of the day to the sales manager by email before finishing work every day, and the sales manager will summarize the total sales records and input them into the system.
The person interacting with the system at this time is the sales manager, so the sales manager is a participant in the system.
Actors are in our code and are essentially classes, so there are inheritance relationships among actors (inheritance is generally represented by generalization relationships during the analysis phase). Generalization refers to the connection between a generic actor (the parent) and another special actor (the child). The generalized relationship between the actors is represented by a solid line with a hollow arrow, the end of which represents the parent actor.
In the figure above, we can see that both administrators and ordinary users are user particularities, so a parent actor can be abstracted. Administrators and ordinary users both have all the characteristics of users, but also have their own special characteristics.
Use Case (Use Case)
Requirements analysis is an essential part of the software development process. Its main purpose is to model the system to be developed, and use cases are the best way to do this.
A use case is a description of a set of actions that the system performs to produce visible results for the participants in the use case. A term used to describe a system service or function that can be perceived by participants.
In UML, use cases are usually represented by an elliptical symbol:
In e-commerce systems, “add to cart” is a use case, and in social software, “send someone a message” is a use case.
Characteristics of system requirement analysis using use cases:
- Use cases describe the information in the system from the perspective of the users of the system, that is, the functions of the system that can be seen outside the system, without considering the specific implementation of the functions inside the system
- A use case describes a visual requirement that corresponds to a specific user goal. Use cases can be used to delimit the system from external entities.
- A use case is usually executed by an actor.
- Use cases return the results of execution to the actors.
- Use cases are functionally complete. It takes input from the participants and outputs the results to them.
In general, how do we describe specific information about a function to others? We use text to explain the function. The use case diagram is simply a graphical representation of the system; the full description of the functionality needs to be written. Therefore, for use cases, we need to be detailed, so that others can understand the system more clearly. This is where we need to write the use case description.
Use-case descriptions are usually not hard and fast, but some complex or important use cases should be written. Use case description generally includes use case number, use case description, preconditions, basic event flow, other event flow, exception event flow, post-conditions, etc.
Here’s a detailed description of the “Add to cart” use case:
| The element | describe |
|---|---|
| Use case name | Add to cart |
| Use case identification | UC001 |
| Brief description | Adds an item to the user’s shopping cart |
| precondition | The user has logged in |
| Basic event flow | The user sends a request to the system to add to the shopping cart, and the system needs to verify the inventory of the goods and the number of the user’s shopping cart to determine whether it can be added to the shopping cart |
| Other stream of events | There is no |
| Abnormal event flow | If the inventory is insufficient, inform the user that the inventory is insufficient and cannot be added; If the user’s shopping cart has reached the upper limit, the user is informed that the cart is full and that some items need to be deleted before being added |
| postconditions | After the shopping cart is added successfully, you need to collect statistics on the number of shopping carts |
| annotation | There is no |
With the use cases out of the way, let’s talk about the relationships between use cases
Relationships between use cases
Contains the relationship
A containment relationship refers to a relationship between two use cases where the behavior of one (the basic use case) includes the behavior of the other (the containment use case).
In UML diagrams, inclusion relationships are represented by dashed lines marked <
> with arrows going in the direction from the basic use case to the inclusion use case.
Extension relationship
The extension relationship is an extension of the basic use case, which is a complete use case that can complete a complete function even without the participation of sub-use cases. There is an extension point in the extension’s base use case, and only when the extension point is activated can the sub-use case be executed. An extension relationship is a relationship from an extension use case to a base use case, which describes how the extension use case is inserted into the base use case.
Use scenarios for extended use cases:
- Indicates that some part of the use case is optional behavior
- Indicates a branch that is executed only under certain conditions
- Indicates that there may be a set of behaviors, one or more of which can be inserted at extension points in the base use case. The behavior and order of insertion depends on the interaction with the protagonist during the execution of the base use case.
In UML diagrams, use a dotted line with an arrow and the dotted line is marked <
>:
Generalization relationship
The generalization relationship refers to the relationship between the general (parent use case) and the special (child use case). When multiple use cases share a similar structure and behavior, their commonalities can be abstracted as parent use cases and other use cases as child cases in the generalization relationship.
Group relations
In some use case diagrams, the number of use cases may be large, and it is necessary to organize the use cases.
Use case diagram modeling and application
Creating a use case diagram model consists of three parts:
- Identify roles and use cases in the system
- Prioritize use cases
- Create a use case diagram model structure
Identify roles and use cases in the system
This is usually done by the systems analyst through communication with the customer.
To capture the use cases of the system, first identify the roles of the system.
To capture a system role, ask the user questions to identify the role when communicating with the customer. Please refer to the following questions:
- Who will use the main features of the system?
- Do you need systematic support to accomplish your daily tasks?
- Who is responsible for maintaining, managing and keeping the system running?
- What external systems does the system interact with?
- What hardware does the system need to handle?
- Who is interested in the results of the system?
Once we have a system role, we can list its use cases by the role. Use cases can be identified by answering the following questions:
- What actions does each role perform?
- What roles will create, store, change, delete, or read information from the system?
- What use case creates, stores, changes, deletes, or reads this information?
- Does the role need to notify the external system of sudden changes?
- Does the system need to notify the role of what is happening?
- What use cases will support and maintain the system?
Prioritize use cases
Some use cases must be completed before others, because they are interdependent. For example, before purchasing goods, users must first log in.
Build the use case diagram model
Place the identified and refined roles and use cases into the use case diagram. Then the structural model between use cases is given by means of the relationship between inclusion, extension and generalization.
In the system requirements analysis, it is necessary to consider which views are required for the system use case diagram model, what each view contains, and whether the members of the view need to form packages.
summary
Use case modeling is a good way to realize system requirements analysis, which enables system analysts and users to better communicate system requirements.