UML-use case diagram for team communication

In all UML diagrams, the most easy to understand is the use case diagram, which is also a UML diagram with the least elements, and also the most handy one for product managers.

 

I. Purpose

The use case diagram is often used to describe the requirements, so that users can first understand the functions of the system. Someone may ask, How can users understand the system in a few diagrams?

? In fact, the PRD of the product manager is displayed in the form of "image and text dependency". Here, the "text" is also the "case description ".

 

Ii. Basic Elements

All elements in the use case diagram are preliminary concepts, so all elements are commonly used. First, let's look at the elements in the toolbox.

1: participants, Generalization

<1> participants: we know that the use case diagram shows the functions of the system. Who will use the system and who will interact with the system in the future?

"Participant" is the "who". Note that "participant" not only refers to people, but also to all virtual participants.

<2> generalization: generalization is too simple, that is, inheritance in the object-oriented model. I believe it can be taken over.

2: Use Cases, Association

<1> Use Case: this is the core of the use case diagram, as the name suggests, that is, the function points to be presented.

<2> join: we must use the join relationship between "participant" and "use case.

3: Include, extend

<1> include: the meaning of include is better understood. For example, if I want to tell you what features should be provided by "User Information Management", then your first response must be

It is curd. Yes, curd is an inseparable basic unit for "User Information Management.

<2> expansion: Compared with "inclusion", expansion is the Edge Function of the basic function unit, that is, it is dispensable. The key is whether the "participant" needs this function.

4: Subsystem

Just like its name, if your system has many subsystems, or your system has many functional modules, you want to organize them in a namespace similar

These functions make the "subsystem" very suitable at this time. For example, "User Information Management" is a large function module. At this time, I can use the "subsystem" to represent

For this "Use Case".

5: Project, dependency

<1> Project: as we mentioned earlier, the use case chart uses the form of "image-text dependency" in actual application, so the project here plays the role of "text.

<2> dependency: the link between use cases and projects. We use the form of "dependency.

There is a hyperlink attribute in the "project". When we click the upper right corner, we can smoothly enter the link document we set.