[Reprint] use case diagram

Use case diagram is a diagram composed of the main character, use case, and the relationship between them. This figure shows the relationships in the use case model.

The use case diagram can be organized into the use case package, which is owned by the use case package, so that only the relevant content is displayed in the specific package.

A Use Case chart consists of actors, Use cases, system boundaries, and arrows.

A participant is not a specific person, but a role outside the system in the use of the system or in interaction with the system. Therefore, participants can be people, things, time, or other systems. Note that participants do not refer to people or things themselves, but to the roles played by people or things at the time. For example, James is the administrator of the library. He participates in the interaction of the library management system. At this time, he can take the role of the Administrator to participate in management, or as a borrower to borrow books from the library, here, James plays two roles, two different participants. The participants are illustrated with simple characters, and the names of the participants are attached to the figures.

A use case is a description of a group of action sequences, including variables. The system executes these actions and generates the observed results that pass the value of a specific participant. This is the formal definition of the use case in UML, which may be difficult for beginners. We can understand that use cases are what the participants want the system to do. For case naming, we can give the case a simple and descriptive name, generally a word with attention. The use case is represented by an ellipse in the drawing. The name of the use case is attached to the ellipse.

The system boundary is used to represent the boundary of the modeling system. Within the boundary, it indicates the components of the system, and outside the boundary, it indicates the system exterior. The system boundary is displayed in a box in the drawing, and the system name is attached. The participant is drawn outside the boundary, and the use case is drawn inside the boundary. Because the function of the system boundary is sometimes not very obvious, I personally understand that it can be omitted when drawing.

Arrows are used to indicate the associations between participants and the system by sending signals or messages to each other. The tail of the arrow is used to indicate the Start side of the interaction, and the head of the arrow is used to indicate the Start side. The use case is always started by the participants.

The use case diagram has three main functions: (1) Obtaining requirements; (2) Guiding test; (3) Guiding other workflows throughout the process.

□Relationship between elements

In addition to system boundaries, roles, and use cases, the elements contained in the use case diagram are links. The relationship includes the relationship between use cases, between roles, and between use cases and roles.

1. Relationship between roles:

Relationship between roles. Because a role is essentially a class, it has the same relationship description as the class, that is, there is a general relationship between the roles, the meaning of the generalized relationship is to extract the common behaviors of some roles and express them as common behaviors.

2. Relationship between use cases:

Include relationship: the behavior of a basic use case includes the behavior of another use case. Basic use cases describe common actions in multiple use cases. The inclusion relationship is essentially a special dependency. It has more semantics than general dependency. The direction of the arrow in the include link is from the basic case to the include case. In UML1.1, use cases use and expand these two relationships, both of which are the layout of the general relationship. In Versions later than UML1.3, there are two relationships: Inclusion and extension.

General Relationship: represents a special relationship. It means similar to the concept of inheritance in object-oriented programming. The difference is that inheritance is used in the implementation phase, while generalization is used in the analysis and design phases. In the generalization relationship, the subuse case inherits the behavior and meaning of the parent case. The subuse case can also add new behaviors and meanings or overwrite the behavior and meaning in the parent case.

The basic meaning of an extended link is similar to that of a generalized link. However, in an extended link, there are more rule restrictions on the extended use case. The basic use case must declare the extension point, extended use cases can only add new behaviors and meanings to the extended points. Like the inclusion relationship, the extension relationship is also the dependency type. In the extended relationship, arrows are directed from the extended case to the basic case, which is different from the contained relationship.

Comparison of generalization, inclusion, and extension relationships of use cases. Generally, you can use "is a" and "has a" to determine the relationship. The relationship between model and extension indicates that the use case is in the "is a" relationship, and the relationship between them indicates that the use case is in the "has a" relationship. Extended use cases can only be extended on the extended points of basic use cases. In an extended relationship, this use case exists independently. When you execute basic use cases in the inclusion relationship, the include use cases will be executed. If you need to repeat two or more use cases, you can consider using the inclusion relationship to reference one basic use case to another. When the deformation of normal behaviors is occasionally described, you can consider using only generalized relationships. When you want to use more control methods to describe the deformation of normal behaviors, you can set the extension points in the basic use cases and use the extension relationships. It is difficult to understand the extended relationship. It can be helpful to understand the extended relationship as a general relationship with more rule restrictions. Generally, the basic use case is obtained first. For each behavior in the use case, ask: what will happen in this step? Is the procedure different? How to perform this step in different ways and mark all changes as extensions. Generally, basic use cases are easy to construct, while extended use cases need to be analyzed and verified repeatedly. When we find that there is a similarity between the two use cases, we can extract the similarity from the two use cases as a separate use case. This use case is used by both use cases at the same time, this abstract use case forms an inclusive relationship with the other two use cases.

Use case diagram Use case diagram   Use case diagram   Use case diagram

(1) Use case model)
For a long time, in object-oriented development and traditional software development, people can understand their needs based on typical use cases. However, these scenarios are informal, and although often used, it is difficult to establish a formal document block. The Use Case model was first used by Ivar Jacobson in the Development of AXE systems and added to the OOSE and objectid methods proposed by him. The use case method has aroused great attention in the Object-Oriented field. Since the publication of Ivar Jacob son in 1994
The object field has widely accepted the use case concept and considered it a symbol of the second generation of object-oriented technology.
The Use Case Model describes the system functions that the external executor understands. The Use Case model is used in the demand analysis stage. It is the result of repeated discussions between system developers and users. It demonstrates the consensus between developers and users on the requirement specifications. First, it describes the functional requirements of the system to be developed. Second, it regards the system as a black box and understands the system from the perspective of external executors. Third, it drives the development work in various stages after requirement analysis, not only ensures the implementation of all functions of the system during the development process, but also is used to verify and detect the system developed, this affects all stages of development and various UML models. In UML, a use case model is described by several Use Case Diagrams. The main elements of a use case diagram are use cases and executors.

(2) use case)
Essentially, a use case is a typical interaction between a user and a computer. Taking the word processing software as an example, "putting some text in the black body" and "Creating an index" are two typical use cases. In UML, a use case is defined as a series of actions executed by the system, and the execution result of the action can be noticed by the specified executor.

Figure 1 use case diagram

In UML, the use case is represented as an elliptic. Figure 1 shows an example of a financial and trade system. Among them, "Risk Analysis", "transaction valuation", "conducting transactions", "setting borders", "transactions beyond borders", "evaluating trade ", "Updating accounts" are examples of use cases. In summary, use cases have the following features:
· Use cases capture the visible needs of some users to achieve a specific user goal.
· The use case is activated by the performer and the exact value is provided to the performer.
· Use cases can be big or small, but they must be a complete description of the implementation of a specific user goal.

(3) Performer)
Performer refers to the role played by the user in the system. Its graphical representation is a villain. Figure 1 contains four executors: trade manager, marketing staff, sales staff, and accounting system. In some organizations, there may be many marketers
But for the system, they all play the same role and play the same role, so they are represented by an executor. A user can also assume multiple roles (executors ). For example, a senior marketer can be either a trade manager or a common marketer, or a salesperson. It is important to consider the role of the operator rather than the name of a person or work.
In Figure 1, a line segment without arrows connects the performer with the use case, indicating that information is exchanged between the two, which is called communication. The executor triggers the use case and exchanges information with the use case. A single executor can be associated with multiple use cases. In turn, a single use case can be associated with multiple executors. Different executors have different roles for the same use case: they can take values from the use case or participate in the use case. It should be noted that although the performer is represented in a person-like figure in the use case diagram, the performer is not necessarily a person. For example, an executor can also be an external system, which may need to obtain information from the current system and interact with the current system. In Figure 1, we can see that the accounting system is an external system that needs to update accounts.
Through practice, we find that executors are very useful for providing use cases. In the face of a large system, it is often very difficult to list use cases. In this case, you can first list the executors and then list their use cases for each executor, which makes the problem much easier.

(4) Use and extended)
In addition to the connections between executors and use cases, Figure 1 provides two other types of connections to indicate the use and extension relationships between use cases. Use and extension are two different forms of inheritance relationships. When one use case is similar to another, but more actions are performed, you can use the extended relationship. In example 1, the basic use case is "transaction ". Transactions may go smoothly, but there may also be factors that disrupt transactions. One of them is beyond some boundary values. For example, the Trade Organization defines the maximum trade volume for a specific customer. In this case, it cannot perform the general actions provided by the given use case, but must make some changes. We can make changes in the "transaction" case. However, this will combine the use case with a lot of special judgments and logic to obscure the normal process. In Figure 1, conventional actions are placed in the "transaction" Use Case, and unconventional actions are placed in the "transactions that exceed boundaries" case. This is the essence of the extended relationship. When a large similar action exists in several use cases and you do not want to describe the Action repeatedly, you can use the relationship. For example, in reality, both risk analysis and transaction valuation need to evaluate trade. Therefore, a separate use case can be defined, that is, "evaluate trade ", the "Risk Analysis" and "transaction valuation" Use Cases. Note the similarities and differences between expansion and use. Both of them mean to extract public behaviors from several use cases and put them into a separate use case, which is used or extended by several other use cases. However, the purpose of use and extension is different.

(5) Use Case model acquisition
Use Cases are used in almost any situation. Use Cases are used to obtain requirements, plan and control projects. The acquisition of use cases is one of the main tasks in the demand analysis phase, and is the first task to be done. Most of the use cases will be generated in the requirement analysis phase of the project, and more use cases will be found as the work goes deeper, which should be added to the existing use cases in a timely manner. Each case in a case set is a potential requirement.
A. Get performer
To obtain a use case, you must first find the executor of the system. You can identify the performer by answering answers to some questions. You can refer to the following questions:
· Who uses the main functions of the system (main users ).
· Who needs the system to support their daily work.
· Who can maintain and manage the system (to assist users ).
· What hardware does the system need to manipulate.
· What other systems do the system need to interact with, including other computer systems and other applications.
· Persons or things interested in the results produced by the system.
B. Obtain Use Cases
Once an executor is obtained, a question can be raised to each executor to obtain the use case. You can refer to the following questions:
· What functions do executors require the system to provide (What do executors need to do )?
· Types of information that the performer needs to read, generate, delete, modify, or store.
· Which system events must be reminded to the performer? Or do executors have to remind the system of events? How can we express these events as functions in use cases?
· To fully describe the use case, do you need to know whether some typical functions of the performer can be automatically implemented by the system?
There are also some problems not specific to the executor (that is, the problems for the entire system ):
· What input and output does the system need? Where does the input come from? Where is the output?
· What are the main problems with the current operating system (maybe manual operations rather than computer systems?
Note that the last two questions do not mean that there are no executors or examples, but they do not know what the executors are. A use case must be associated with at least one executor. Note that different designers use different cases. For example, Ivar Jacob said that for a ten-year project, he needs 20 Use Cases. In a project of the same size, Martin Fowler uses more than one hundred use cases. We believe that any suitable use case can be used. The process of determining the use case is the process of refining and summarizing the obtained use cases. For a project of 10 years, there seems to be too few 20 Use Cases, and too many more than one hundred use cases, so we need to maintain a relatively balanced relationship between the two.