Understanding of the inclusion, extension, and generalization relationships in UML use cases

There are three relationships in the case relationship: "include", "extended", and generalization. Of course, there is also the most basic relationship, "association ".

Including the link:

The inclusion relationship is used to separate some workflows. For these workflows, the basic use cases only depend on the results and are irrelevant to the methods used to obtain the results. If such separation can simplify understanding of basic use cases (hide detailed behaviors), or reuse the behavior of separation in other basic use cases, you can separate the workflow.

The basic use case is connected to the include use case through the inclusion relationship. Examples are always abstract. It describes the behavior segments inserted in the use case instance that executes the basic use case. The relationship between basic use cases and include use cases can be controlled and dependent on the results obtained by executing include use cases. However, neither the basic use case nor the include use case can access the attributes of the other party. In this sense, the inclusion case is encapsulated and represents the behavior that can be reused in different use cases.

The include relation is used to: (1) break down the behavior from the basic use case: it is not necessary to understand the main purpose of the basic use case, and only its results are important. (2) break down the behaviors shared by two or more use cases.

Extended relationship:

The extension relationship connects the extension case with the basic case. By referencing the extension point in the basic case, you can define where the extension case is inserted in the basic case. The extension case is usually abstract, but not abstract.

The purpose of expansion is to: (1) indicate that a part of the use case is optional (or possibly optional) system behavior. In this way, you can separate the optional and mandatory behaviors in the model. (2) indicates the branch stream that is executed only under certain conditions (sometimes exceptions), such as triggering an alarm. (3) It indicates that there may be a group of behavior segments, one or more of which can be inserted at the extension points in the basic use case. The inserted behavior segments (and the insertion sequence) depend on the interaction with the main character when executing the basic use case.

Extension is conditional, and whether it is executed depends on the events that occur when the basic use case is executed. Basic use cases do not control the conditions for executing extensions. These conditions are described in the extension relationship. Extended use cases allow you to access and modify attributes of basic use cases. However, the extended use cases cannot be accessed in basic use cases.

Extended use cases modify basic use cases implicitly. It can also be said that the basic Use Case defines a modular framework where you can add the extension use case, but the basic use case cannot see the specific extension use case.

The basic use cases should be complete, that is, the basic use cases should be understandable and meaningful without reference to any extended use cases. However, the basic use cases are not independent from the extension use cases, because if you cannot follow the extension use cases, you cannot execute the basic use cases.

Generalization relationship: the generalization relationship of a use case refers to the relationship from a sub-use case to a parent case. It specifies how the sub-Use Case features and behaviors of the parent case are exclusive.

The parent case can be specially formed into one or more child cases, which represent a special form of the parent case. Although the parent case is abstract in most cases, neither the parent case nor the child case must be abstract. Child Cases inherit all structures, behaviors, and relationships of the parent case. Child cases of the same parent case are special cases of this parent case. This is the general relationship applicable to use cases.

When you find that two or more examples have commonalities in behavior, structure, and purpose, you can use generalized relationships. When this happens, you can use a new, usually abstract use case to describe these common parts. This use case is then specially crafted by the quilt use case.

?