Three relationships in use case diagrams

Commonality: All of the common use cases are extracted from the public part of the information, as a separate use case, and then through the different methods to reuse the common use case, to reduce the workload of model maintenance.

1. Include (include)

Include relationship: Use the include (inclusion) use case to encapsulate a set of similar actions (behavior fragments) that span multiple use cases so that multiple base (base) Use cases are reused. The relationship between the base use case control and the containing use case, and whether the event stream containing the use case will be inserted into the event stream of the base case. The base use case can depend on the results that contain the execution of the use case, but neither side has access to the other's properties.
A typical application of a containment relationship is reuse, which is what the definition says. But sometimes when the event of a use case flows through complexity, in order to simplify the description of the use case, we can also abstract an event stream into a contained use case, instead, when the use case is divided too thin, you can also abstract a base use case to contain the use cases of these fine particles. This situation is similar to the process design language in which a piece of the program's algorithm is encapsulated into a sub-procedure, and then called from the main program.

For example: In a business, there is always the ability to maintain such information, and if it is used as a use case, the new, edit, and modify are described in the use case details, too complex, if divided into new use cases, edit use cases and delete use cases, it is too thin. This includes relationships that can be used to clarify relationships.

2. Extension (Extend)

Extended relationships: A relatively independent and optional action in the base use case, encapsulated with an extension (Extension) use case, and then extended from the extension point (Extension points) declared in the base use case to make the base use case more concise and more focused. The extension use case adds new behavior to the base use case. An extension use case can access the properties of the base use case, so it can determine whether to execute itself based on the current state of the extension point in the base case. However, the extension use case is not visible to the base use case.

For an extension use case, you can have several extensibility points on the base use case.
For example, the system allows users to export and print the results of a query. For the query, you can export, print the query is the same, export, printing is not visible. Import, print, and query are relatively independent, and new behavior is added to the query. You can therefore use extended relationships to describe:

4. Generalization (generalization)

Generalized relationships: Child use cases are similar to parent use cases, but exhibit more specific behavior, and child use cases inherit all the structures, behaviors, and relationships of the parent use case. A child use case can use a section of the parent use case, or it can be overloaded. The parent use case is usually abstract. In practical applications, the generalization relationship is seldom used, and the special behavior in the sub-use case can exist as an alternative stream in the parent use case.

For example, there may be many things in the business that require the approval of the department leader, but the process of leading approval is very similar and can be expressed as a generalization relationship:

The above is my reference to an article, feel that the difference between the three kinds of relationship is clear, on this basis, combined with their own system, the project (online shopping system) use cases to do a whole description.
*****************************************************************
(1) System overall use case diagram

According to the overall use case, after the subsystem use cases to depict, welcome everyone to put forward good suggestions!

Go: The difference between extension and generalization in UML
The generalization representation is similar to the OO term "inheritance" or "polymorphic". The usage case generalization process in UML is to abstract the merged parts between different use cases into separate parent use cases, and to separate the non-consolidated parts into their own sub-uses, and the inclusion and extension processes are similar to the generalization process, but the three focus on the optimization of the relationship between them is different. As follows:
Generalization emphasizes the mutual exclusion between sub-cases;
Contains the indirection that emphasizes the inclusion of the use case to the actor service;
The extension focuses on the triggering uncertainty of the extension use case, as detailed below:

Since a use case is a UML representation of a system-provided service, the process of service is inevitable in all use-case scenarios, but occurs in the following two scenarios, according to the conditions of occurrence:
⒈ unconditional occurrence: sure to happen;
⒉ conditional occurrence: May not occur, the occurrence or not depends on the system state;

Therefore, the three kinds of relationship of use case are considered by the system state, the generalization and the inclusion use case belong to the unconditional occurrence use case, and the extension belongs to the conditional occurrence use case. Further, the existence of use cases is to provide services for actors, but the way in which the use cases provide services can be divided into indirect and direct, according to which, the sub-use cases in generalization provide direct services, while the included use cases provide indirect services. Similarly, extension use cases provide direct services, but the occurrence of extension cases is conditional.

Another point to mention is that the sub-use cases in generalization and extension cases in extensions can all exist as a prepared selection stream for basic use case events.

Three relationships in a use case diagram (GO)