User case)

ArticleDirectory

• Extend, include, and inheritance in the use case diagram

The use case diagram is a diagram of what roles can do through a certain system. The use case diagram relates to 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.

Extend, include, and inheritance in the use case diagram

The "print report" use case contains a dotted line pointing to the "view General Report" use case with the words "<extend>" on the dotted line, this indicates that the "print report" extension "view General Reports" allows you to print reports based on "print reports". This is what extend means. If the "print report" use case does not exist, the "view General Report" use case will not be affected. If the "view General Report" use case does not exist, you cannot print a report based on "view General Reports.
"Manage data" has three dotted lines, with arrows pointing to "View data", "add data", and "modify data". The dotted line has the word "<include>, this indicates that "manage data" contains three subcases: "View data", "add data", and "modify data", which means include. Include is used in the following cases:
1) Some steps of some use cases can be extracted separately to become a subuse case.
2) organize various use cases in the form of "Tree" and use include to organize Parent and Child use cases. The sub-use cases can include their own sub-use cases again.
There is no need to further break down "manage data" into subcases. It is common to view, add, modify, and delete data in a project, when describing use cases, we generally only need to describe these four operations as "manage xx.
Careful friends may find that there is an "inheritance" symbol in the class chart between the role and the role? From the perspective, what does the hacker mean by inheriting the average user and the leader inheriting the hacker?
Whether it is a recorder or a leader, you must first log on to the system to use various features. Do we need to draw a line between "Login User", "recorder", and "lead?
Generally, users can view general reports and print reports. Is it possible for entry personnel and leaders?
The role of the recorder inherits from normal users. In fact, the role represents what the average user can do. The recorder can also do, agree with the truth, and what the recorder can do. The leader can also do, this "inheritance" symbol means this. In practice, we often need to use this "inheritance" symbol to abstract the role properly.

When does a Use Case chart need to be decomposed or not?
That is, what is the granularity of decomposition usually?

The granularity of use cases is controlled by yourself. The following suggestions are provided for reference:
1. Based on the accurate and comprehensive understanding of the customer, the case can be simplified as much as possible.
2. Key and difficult cases should be described in detail.
3. Use cases must be implemented by developers so that developers can understand them.
4. the use case diagram is not omnipotent, nor is it the only way to express the demand. I often use the use case diagram as the main expression and add other expressions to express it. In some special projects, I don't even need to use the case diagram to describe the demand.