Generalization, extension, and inclusion relationships in UML use case diagrams

When drawing a use case diagram, it is important to clarify the relationship between use cases. The relationships of Use cases have generalizations (generalization), extensions (extend), and inclusions (include). Include and extend are most easily confused. Here we combine the examples to completely clarify the relationship between the three.

Basic concepts

Use case diagram (Diagram): A use case diagram shows who is the relevant user, what services the user wants the system to provide, and the diagram of the relationship between the use cases. The main function of a use case diagram is to obtain requirements and guide testing.

4 basic components of a use-case diagram: Participants (Actor), use cases (uses case), relationships (relationship), and systems.

Generalization (generalization): A generalization relationship is an inheritance relationship in which the child use case inherits all the behavior, relationship, and communication relationships of the base use case, which means that a child case can be substituted for any use of the base use case. Generalization relationships use a hollow arrow in a use case diagram to indicate that the arrow direction points from the child case to the base use case.

Extension (Extend): The extend relationship is an extension of the base use case, a complete use case that completes a complete function even without the involvement of the child use case. There is an extension point in the base use case of extend, and the child case is executed only if the extension point is activated. The extend relationship uses a dashed line representation with an arrowhead in a use case diagram (callout <<extend>> on line), and the arrow points from the child case to the base use case.

Include: include includes, when two or more use cases have the same set of actions, you can extract the same set of actions as a separate child case to be shared by multiple base use cases. Because a child case is drawn out and the base use case is not a complete use case, the base use case in the include relationship must be used in conjunction with the child case to be complete, and the child use case is bound to be executed. An include relationship uses a dashed line representation with an arrowhead in a use case diagram (callout <<include>> on line) and the arrow points from the base use case to a child case.

Instance Requirements Scenario

Unicom customers respond to OSS. The system has the function module of fault single, business opening, resource checking, cutting, business re-protection, network quality performance, etc. Now let's take some of the requirements as examples.

Demand 1: Customer response users and international customer service can be cut to inform the query, on the page has the backbone of the cut query, the provinces cut the query, the provincial Cut Query tab.

Analysis: It's easy to see that the cut-and-Go Query tab is an inherited relationship between the different cut-and-pick tabs, so use generalization here. User and customer response, international customer service is also an inherited actor relationship.

Demand 2: Customer response users and international customer service can view a cut notification information, you can export cut information on the page Excel format, you can query and the link to cut the fault order information.

Analysis: Because it is optional to export the cut and view the associated fault order information, which means that when I look at the cut, I can not do the operation, so I use the extend relationship. That is, export cut and view the fault order information extended to view the cut information.

Demand 3: Customer response users can be a network management system for the source of the creation of cut notification, in the creation of cutting notice can be saved as a draft, you can also directly issue a cut notice.

Analysis: As a result of the creation of cutting notice, the release of the cutting notice can be carried out at the same time, can also be saved as a draft, so the release of cut is optional, with extend is more appropriate. That is, the release cut extension is created to create a cut-and-receive notification.

Demand 4: Users in the opening of the business, the issue of cutting notice, the issuance of prudential notice and the relevant trans-provincial business needs to carry out data distribution.

Analysis: Because of business opening, maintenance, cutting and other trans-province business needs to use the data distribution use cases, we can separate the data distribution cases for each business use, here is more appropriate with include. Data distribution in the actual system is also a separate extraction of the interface services implemented using JMS and webservice.

Other requirements: You can see delete cut and see the cut details can also be used as a cutting notification the extension of the query case, as a result of the query list, you can generally choose to continue to view the details or delete operations. But in the actual diagram, these two extend can not be painted, here just to let everyone understand the concept.