UML: use case diagram

From http://www.umlonline.org/school/thread-34-1-1.html

Let's take a look at the sample image?

 

The use case diagram looks pretty good. There is a little person in the diagram, And the use case diagram is a little bit of a feeling of reading the doll book.
The use case map looks nice and looks nice. What is it?
The use case diagram is a diagram of what roles can do through a certain system. The use case diagram focuses on the external performance of the system, the interaction between the system and people, and the interaction between the system and other systems.

The meanings of various symbols in the use case diagram are described as follows:

Villain:
After classifying users using a system, we can summarize the roles used in the system. Different roles have different responsibilities, the system functions they need will be different.
A villain is a role, which provides us with an inspiration. we can think about the needs of a system from the perspective of different roles.
For example, how do you think about an attendance system? Will a lot of functions be listed at once? A better way is to first think about who will use this system. We can probably estimate that the system will be used by general employees, senior leaders, front-end personnel, and finance personnel, what do employees pay attention to in addition to punching in? Does she make attendance statistics for the front-end? Does finance need to adjust employee salaries based on attendance? This way of thinking makes it easier for us to fully explore the needs of the system.
Note that the role may be a person or a person, but another system. If the system interacts with another system, you can create another system as a role.

Circle:
There will be a text with a dynamic object structure in the circle, that is, the form of "Verb + noun". The text in this circle + circle is the use case, which shows what the system can do.
Take the attendance system as an example: two use cases are called "logging" and "checking your attendance". The two circles are connected to the "general employee" role with one line, respectively, we can read this graph in this order: Read the role name first, and then read the text in the use case. According to this reading method, we can get two complete sentences:
"General employees punch in"
"General Employees view their attendance information"
You can use this method to check whether your use case diagram is properly drawn.
A use case does not necessarily belong to a specific role. Many use cases are shared by multiple roles.

Box:
There is a box outside all the use cases. This box only contains the use case and does not contain the role. This is called the system boundary. The upper part of the box will indicate the name of the system.
The system we do cannot include roles. To play a variety of roles, the system must use the use cases of the system by "traversing" the system boundary.
The system boundary can clearly express the range of the system. Not all use case diagrams need to draw the system boundary. Generally, you only need to draw the system boundary in the global use case diagram. When the use case is refined, you do not need to draw system boundaries.

Line:
A line refers to a line between a role and a use case. There are three types of lines: An arrow without an arrow, an arrow pointing to a use case, and an arrow pointing to a role. No matter whether there are arrows or not, these lines are used to connect roles (villains) and use cases (circles), indicating what use cases a role can "do.
A line with arrows indicates the flow of data during the interaction between the role and the system. If the arrow points to a use case, the role needs to input data to the system. If the arrow points to the role, the system outputs data to the role.
The line without arrows does not clearly indicate the data flow direction. In general, you do not need to explicitly indicate the data flow direction. You only need to draw a line without arrows.

UML: use case diagram