Diagram of the relationship between use cases in UML

Http://www.cnblogs.com/gisdev/archive/2007/11/15/959843.html

The use case diagram is used to analyze a system. The relationship between use cases must be considered during this period. Find the following information.
Body:
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 perform 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 they are not included in the subordination. 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, this public use case is reused through different methods, 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 similarProgramOfAlgorithmEncapsulate the sub-process and then call it 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:

3. Generalization)

 

Generalization relationship: child cases are similar to parent cases, but show more special behaviors;Child Cases inherit 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:

At last, I will attach a preliminary use case diagram.