General (generalization), extended (extend), and included (include) Relationships of UML use case diagram-a series of UML stream series explanations

It is important to clarify the relationship between use cases when drawing a use case diagram. The relationships of use cases include generalization, extended, and include ). Include and extend are the most confusing. Next we will thoroughly clarify the relationship between the three Based on the instance.

Basic Concepts
Use case diagram: the use case diagram shows who is the relevant user, what services (Use Cases) The user wants the system to provide, and the Relationship Diagram between use cases. The use case diagram mainly serves to obtain requirements and guide testing.

Four basic components of the use case diagram: the actors, the use case, the relationship, and the system.

Generalization: A general relation is an inheritance relation. A subuse case inherits all behaviors, relationships, and communication relationships of the base use case, that is to say, subcases can be used to replace any use case. The general relationship is expressed by a hollow arrow in the use case diagram, and the arrow direction is directed to the base case from the subcase.

Extend: The extend relationship is an extension of the base use case. The base use case is a complete Use Case and can complete a complete function even if no sub-use case is involved. There will be an extension point in the base use case of extend. The child use case will be executed only when the extension point is activated. The extend relationship is represented by a dotted line with arrows in the use case diagram (online labeling <extend>), and the arrows direct from the child case to the base case.

Include: When two or more use cases use the same group of actions, you can extract the same group of actions as an independent sub-use case, shared by multiple base use cases. Because the child use cases are extracted, the base use cases are not a complete Use Case. Therefore, the base use cases in the include relationship must be used with the child use cases to be complete, and the child use cases must also be executed. The include relationship is represented by a dotted line with an arrow (<include> online) in the use case diagram, and the arrow points from the base case to the sub-case.

Instance requirements
Unicom customers respond to OSS. The system provides function modules such as fault tickets, Service Activation, resource verification, cutover, service re-protection, and network quality and performance. Now we will explain some of the requirements as an example.

Requirement 1: the customer can respond to user and international customer service for cutover notification query. The page contains tabs for backbone cutover query, provincial cutover query, and provincial cutover query.
Analysis: it is easy to see that cutover query and different cutover subquery tabs are inherited, so generalization is used here. User and customer response, and international customer service are also inherited actor relationships.

Requirement 2: the customer responds to the user and international customer service and can view the cutover notification information. You can export the cutover information in Excel format on the page and query the fault ticket information associated with the cutover.
Analysis: because the failure ticket information associated with the export cutover and view is optional, this means that you can not perform these operations when viewing the cutover, so the extend relationship is used here. That is, you can export the cutover and view the fault ticket information, and expand the information to view the cutover.

Requirement 3: the customer can create a cutover notification from the network management system, save the cutover notification as a draft, or directly publish a cutover notification.
Analysis: When a cutover notification is created, the release cutover notification can be executed at the same time or saved as a draft. Therefore, the release cutover is optional and it is more appropriate to use extend. That is, the create cutover notification is extended for publishing cutover.

Requirement 4: You need to distribute data when activating your business, releasing cutover notifications, re-insurance notifications, and related cross-province businesses.
Analysis: as data distribution cases are required for business activation, re-protection, cutover, and other cross-province businesses, we can extract data distribution cases separately for various businesses to use, it is more appropriate to use include here. In the actual system, data distribution is also an interface service that is independently extracted using JMS and WebService.

Other requirements: You can see the delete cutover notification and view cutover details. It can also be used as an extension of the cutover notification query case. When querying the list, you can choose to continue viewing details or delete operations. However, in the extended graph, the two extends can be left blank, just to help you understand the concept.

Example diagram: You can refer to the diagram for better understanding.

Deep understanding
We will use the use cases in another scenario to describe include and extend, because these two things are easy to mix up.
Cancel account: Because the cancel account must settle the account first, use include
Downtime reminder: there are two options: SMS reminder and email reminder, so extend is used.

After the above analysis, I believe you have a good understanding of the three relationships. Do you have any other ideas or good opinions.

PS: The above example is drawn using Enterprise effecect 7.5. We recommend that you use EA here, which is very good. It can replace Visio and Rose. Visio is not powerful enough, and Rose is too heavy. Only EA is suitable.