Use Case chart new solution

When I first came into contact with a UML diagram, I felt pretty good about it and it was not very difficult. However, in practice, I always feel like I am painting myself.

The following is a brief introduction to my new understanding of the use case recently.

The Use Case chart is a set of abstract functions of the system. It classifies the functions of the system reasonably. It is the most functional and direct visual interpretation of the system.

Some people say that the use case diagram is a form of communication and understanding between the customer and the developer. It is a visual contract between the developer and the customer. I feel very good about it.

I personally think that the use cases and interfaces are almost one-to-one. Just like the ing between an object class and a database table, although it corresponds to a whole, there are also special circumstances that make them irrelevant. So I used almost the same words just now.

Here, I think the use case is the corresponding interface, so that we will not be wrong from a generous perspective.

Of course, in the use case diagram, if there are several similar use cases, we can abstract them into a parent use case. For example, in the data room charging system, user operations include adding users, deleting users, and querying users. We can abstract a usermanager use case as a parent use case.

In this case, another part of the use case diagram is more important, that is, the relationship between the use case diagram. There are two common relationships: one is the relationship between the role and the use case, and the other is the relationship between the use case and the effort. The relationship between roles and use cases is simple, that is, the relationship between roles and use cases. A simple understanding is that a role uses a specific use case. There are two main relationships between use cases: Include and expand.

These two relationships are well recognized: Include refers to the parent case containing the child case, so the arrow points from the parent case to the child case to form the inclusive relationship. The extended relationship should be understood as "extended from", which is the extended use case, and the arrow should point to the extended party.

The meanings of these two relationships are also well differentiated: the parent cases in the inclusion relationship are generally abstracted, so there is almost no interface corresponding to them, and the interfaces correspond to their subinterfaces; in the extended relationship, we use the following figure for demonstration.

In this relationship, the queryitem (query project) use case must be executed, while the deleteitem (delete project) can be executed or not, so we say that the deleteitem use case is extended from the queryitem use case.

We can understand it as follows: if we want to get the project information, we must use queryitem to query the project information. After finding the information, we can delete or not delete the project.

After talking about the latest knowledge of the use case, let's talk about its role.

There is no doubt about the role of the map in demand and modeling.

First of all, because the use case diagram looks very direct and the visualization effect is very good, you can view the use case diagram and the system analyst's explanation to fully understand the system, let's see if they want the system to be built in the future and whether it can meet their needs. Therefore, the use case diagram can be seen as a bridge between the user and the demand analyst.

Second, the use case chart plays an important role in the modeling process. What functions need to be completed on an interface? The best reason is to model based on the Use Case. Then, as to whether the page is beautiful, this can be implemented using Div + CSS, some good effects can be implemented using JS, and Ajax is required for some part of local updates. I am also a newbie in these aspects, learning. You are welcome to study, discuss, and make progress together with me.

Finally, after determining the architecture, we need to determine the class diagram and method based on the Use Case.

Therefore, the importance of the use case diagram is self-evident. This article describes the main components and relationships of the use case diagram and its usage. In my opinion, the use case diagram is the second step of a system. After the feasibility analysis, the most important thing is to determine the use case. Because a good use case diagram determines its good needs. At the same time, it makes great convenience for subsequent modeling.

This article is intended for my personal understanding of the use case diagram since I learned the UML diagram. I hope you can leave valuable comments and make progress together.