Use case diagram (UML learning notes)

The use case diagram mainly includes use cases, activists, and relationships.

Use Cases: A description of the sequence of actions that the system, subsystem, or class interacts with external participants, including various normal sequences and error sequences. Case analysis can be considered as a decomposition of system functions.

How to determine the granularity of use cases:
Generally, there are no mandatory requirements for a system. You only need to clarify the functional requirements. Generally, it is best to control a system in about 20 Use Cases; in addition, it should be noted that use cases are system-level and abstract descriptions, rather than details (not specific to how a function is implemented). for complex systems, they can be divided into several subsystems for processing.

How to obtain use cases:
What task does the activist want the system to execute?
What information does an activist access in the system?
What external information needs to be provided to the system?
Which system event needs to be told to the activator?
How to maintain the system?

Active users (roles): Participants outside the system, including users, external hardware, and other systems. Note that the active users are not necessarily human users, in addition, if a role is operated by another role proxy, create a dependency for this role to another role.

How to identify activists:
WHO provides information to the system?
Who gets information from the system?
Who's operating system?
Who maintains the system?
What external resources are used by the system?
Does the system interact with an existing system?

Link: the link includes Association, inclusion, extension, and generalization (including and extension are dependency details)

Association: a single arrow is used to indicate only who starts the use case, regardless of the two-way flow of information. Each use case has a role to start, unless it includes and extends the use case; no matter whether there is two-way data exchange between the use case and the role, the Association is always started by the role;

Include: the Basic use case points to the included use case. Two or more use cases have the same function. When executing a base use case, the included use case must be executed each time. For example, a system has two use cases: cancelling an order and querying an order. When executing the cancelling use case, you must first query the order, find the order to be deleted, and perform the delete action, therefore, the Order Cancellation case contains the query order case.

In addition, the inclusion can also be used when too many functions of a use case need to be broken down into small use cases.
For example, the use cases of the student information management system include adding student record cases, deleting student record cases, and modifying student record cases. However, such cases do not have a relationship with roles, it only has a inclusion relationship with the base use case.

Extension: one use case extends the functions of another use case to form a new use case. It should be noted that the extended use case may not necessarily be executed and no activity points to it. The extension example is composed of only partial fragments. It is not a complete and independent use case and cannot be executed independently.
For example, if we develop an order system and have a Goods Order use case, we can expand one more VIP discount use case.

Generalization: generalization is formed between a use case and other cases. For example, a transfer case contains interbank transfer and bank transfer.

These are my notes on studying UML. You may have a messy idea. You can join us and exchange your comments. I wish you a happy New Year.