How to draw a UML use case diagram

UML
The use case diagram is a very useful graph. In demand analysis, it can free people from the heavy documentation, in addition, it prompts people to express their meaning more accurately and intuitively when making demands. Common languages
The word is often unable to express a thing clearly. At this time, it needs to be expressed in other ways. The example graph is a good method, of course, the use case diagram is not only dedicated for demand analysis, but also powerful
Large applicability can also be used in many other places, which is not described in detail here. There are many UML-based tools. I recommend that you use this tool to draw an example. If you have time, I
I will write a preliminary tutorial. Next we will introduce the use case diagram.

1. First, we will briefly introduce UML.

UML (Unified Modeling Language, Unified Modeling
Language) is a well-defined, easy-to-Express, powerful, and universally applicable visual modeling language. It integrates new ideas, new methods, and new technologies in the software engineering field. Its scope is not limited
With object-oriented analysis and design, it also supports the entire process of software development starting from requirement analysis. In the system analysis stage, we generally use UML to draw a lot of diagrams, including the use case diagram, status diagram, class diagram, and activity diagram.
Diagram, sequence diagram, collaboration diagram, build diagram, and configuration diagram. In fact, a simple understanding is also a personal understanding. The role of UML is to use a lot of diagrams in both static and dynamic aspects.
A comprehensive description of the system we will develop.

2. Use Case Modeling

Is a part of UML modeling, it is also the most basic part of UML. The main function of case modeling is to express the functional requirements or behaviors of the system.

Use Case modeling can be divided into use case diagrams and use case descriptions. A Use Case chart consists of actors, use cases, system boundaries, and arrows. The use case description is used to describe each use case in the use case diagram in detail and is completed in a text document.

3. Description of the use case diagram

Here we need to explain the participants. Participants are not specific to people, but roles outside of the system in the use of the system or in the interaction with the system. Therefore, participants can be people, things, time, or other
System. 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 a library administrator who participates in the interaction of the library management system,
At this time, he can take the role of administrator to participate in management, or as a borrower to borrow books from the library. Here, James plays two roles, two different participants. Participants draw with simple characters
The name of the participant. For example

 

 

Connect
It is the use case. The Use Case describes a group of action sequences, including variables. The system executes these actions and generates the observed results that pass the values of specific participants. This is
The formal definition of Use Cases in UML may be difficult for beginners. We can understand that use cases are what the participants want the system to do. For the name Of the use case, we can give the use case a simple, descriptive
Is 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. For example

 

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 system boundaries is sometimes not very obvious. (This 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.

4. Next, let's talk about the case description. A good case description directly determines the quality of the project. The use case diagram simply describes the system with a diagram, but we also need to have a detailed description of each use case so that others can have a more detailed understanding of the system, in this case, we need to write the case description.

There is generally no hard format for the content of the case description, but some of the necessary or important content must be written into the case description. Use case description generally includes: Brief description (description), prerequisite conditions, basic event stream, other event streams, abnormal event streams, and post (post) conditions. The following describes the meaning of each part:

Brief description: a brief description of the role and purpose of the use case;

Prerequisites: conditions that must be met or in the system before the execution of the use case;

Basic event stream: describes the basic process of this case. It refers to what happens when every process is "normal" and there is no alternative stream or abnormal stream, and only the most likely event stream;

Other event streams: indicates that this action or process is optional or optional, and does not always need to be executed;

Abnormal event stream: indicates the process to be executed when an abnormal event occurs;

Post condition: the status of the system after the use case is executed;