UML use case diagram Overview

The use case diagram is mainly used to illustrate the main event process of the system. It is mainly used to describe the customer's needs, that is, the user wants the system to complete certain functional actions, the general understanding of use cases is the functional module of the software, so it is the starting point of the design system analysis phase. The designer creates and explains the use case diagram based on the customer's needs, it is used to describe the functional modules that the software should possess and the call relationship between these modules. The use case diagram contains the use cases and participants, use Cases are connected with each other to reflect the entire structure and functions of the system to non-technical personnel (usually software users). This corresponds to the software structure and functional decomposition.

A use case is a behavior visible outside the system and is a complete service provided by the system for one or more actors. In principle, use cases are independent and parallel, and there is no subordination between them. However, in order to reflect the business relationship between some use cases and improve maintainability and consistency, the use cases can abstract several relations, including, extend, and generalization.

Commonalities: the common information is extracted from the existing use cases. As a separate use case, different methods are used to reuse this public use case, to reduce the workload of model maintenance.

1. Include)

Inclusion relationship: Use inclusion cases to encapsulate a group of similar actions (behavior fragments) that span multiple use cases, so that multiple base use cases can be reused. The relationship between the basic case control and the contained case, and whether the event stream of the included case will be inserted into the event stream of the base case. The base use case can depend on the result of the execution of the use case, but neither party can access the attributes of the other party.

The inclusion relationship is reused for a typical application, that is, the scenario described in the definition. However, when an event in a use case flows through a complex process, we can abstract an event stream into an included use case to simplify the description of the use case. On the contrary, when the use cases are too detailed, a basic use case can be abstracted to include these fine-grained use cases. This is similar to encapsulating an algorithm of a program into a sub-process in a process design language, and then calling this sub-process from the main program.

For example, the service always has the function of maintaining XX information. If you use this function as a use case, it is too complicated to describe, edit, and modify the information in the use case details; if it is divided into new use cases, edit use cases, and delete use cases, the Division is too detailed. The contained relationship can be used to clarify the relationship.

2. Extended)

Extensioning: encapsulate a relatively independent and optional action in the base case with the extension case, and then let it claim the extension point from the base case) to make the basic use case behavior more concise and more concentrated. Add new behaviors for the extended use case. The extended use case can access the attributes of the base use case. Therefore, it can determine whether to execute itself based on the current status of the extension points in the base use case. However, the extended use case is invisible to the base use case.

For an extension case, there are several extension points on the base case.

For example, you can export and print the query results in the system. For queries, whether or not the query can be exported or printed is the same, and export and printing are invisible. Imports, prints, and queries are relatively independent, and new behaviors are added for queries. Therefore, you can use the extended relationship to describe:

4. Generalization)

General relationship: the child case is similar to the parent case, but shows more special behavior. The child case inherits all structures, behaviors, and relationships of the parent case. A child use case can use a behavior of the parent use case or reload it. The parent case is usually abstract. Generalization is rarely used in practical applications. Special behaviors in subcases can be used as alternative streams in the parent case.

For example, there may be many tasks that require approval from department leaders in the business, but the approval process is very similar. In this case, the general relationship can be expressed as follows:

The above is an article I have referenced. I think the difference between the three relations is very clear. Based on this, I will combine my own system to explain the project (Online Shopping System) as a whole.

**************************************** *************************

(1) overall system use case diagram

(Product use case diagram)

(Purchase information use case)

(User Data Use Cases)

Follow the overall use case first, and then the subsystem use case to describe it. You are welcome to make good suggestions!

Transformation: differences between extension and generalization in UML

Generalized representation is similar to the OO term "inheritance" or "polymorphism ". The Use Case generalization process in UML abstracts the merged parts of different use cases into independent parent use cases, and separately merges the unmerged parts into their respective subuse cases; the process of inclusion and extension is similar to that of generalization, but the optimization focus on the relationship between use cases is different. As follows:

• Generalization focuses on the mutual exclusion between subcases;
• Include focuses on the indirect nature of the included use cases to provide services to actor;
• The extension focuses on the trigger uncertainty of the extension case. The details are as follows:

Since the use case is a UML representation of the system to provide services, the process of service is inevitable in all use case scenarios. However, the occurrence conditions can be divided into the following two situations:

Condition occurs unconditionally: Yes;

Conditional occurrence of a token: It may not occur, and the occurrence or failure depends on the system status;

Therefore, for the three relationships of use cases, combined with system status considerations, generalization and inclusion of use cases are unconditional use cases, and extension is conditional use cases. Furthermore, the use cases provide services for actor, but the use cases provide services in two ways: indirect and direct. Based on this, the generalized sub-cases provide direct services, the included use cases provide indirect services. Similarly, extended use cases provide direct services, but the occurrence of extended use cases is conditional.

In addition, the subuse cases in generalization and the extended use cases in extension can be used as the backup selection stream of basic Use Case events.