UML use case diagram-Getting Started

What is a use case chart?

The UML use case diagram is mainly used to describe the customer's needs, that is, the user wants the system to complete certain functional actions. The common understanding of use cases is the functional module of the software, this 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 to describe the functional modules that the software should possess and the call relationships between these modules, the UML use case diagram contains use cases and participants. The use cases are connected by associations to reflect the entire structure and functions of the system to non-technical personnel (usually software users ), it corresponds to the software structure and functional decomposition.

What is the use case chart?

This article focuses on the basic operations of using processon to draw UML diagrams. There are many tools for drawing UML diagrams. processon is only one of them. processon is very brisk and online drawing tool. many people are using it.

 

The first step is to register processon and create a new UML use case diagram template.

Now let's take a look at the basic knowledge.

Three elements of the use case diagram

1. Participants-system users 2, use cases-system functions 3, relationships-connections between participants and participants, and connections between use cases and use cases.

     

 

The important and understandable content is the relationship. Let's first look at the relationship between participants and participants (mainly generalization)

Generalized relationship between participants

For example, an online ordering system can include online customers, telephone customers, and direct customers. We can see that they share common behavioral characteristics. This means they can use object-oriented abstraction to abstract more general participants-customers. It uses generalization to describe the common behavior of multiple participants. Different participants use the system in a unique way.

Generalization is similar to the inheritance relationship in Java. Sub-classes have all the actions of the parent class and add their own actions based on them.

 

Relationship between use cases and use cases

1. Generalized relationship

There is also a general relationship between use cases and use cases, which is usually used to represent different technical implementations of the same business purpose (parent case) (each sub-use case ).

For example, if a shopping system provides users with different payment methods, the complex use case of "payment" can be expressed by generalized relationships.

TIPS: subclass name = XX (for specific description) + parent class name.

                

2. Inclusion relationship

In the inclusion relationship, the basic use case absorbs the behavior of the included use case. Without the latter, the basic use case is incomplete.

There are two advantages to the division of the inclusion relationship: first, the inclusion cases are extracted and the basic cases are simplified; second, public event streams can be abstracted to achieve code reuse.

                                        

Sometimes, 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.

3. Extended relationships

Under certain conditions, the event stream of the extended use case is inserted into the event stream of the basic use case according to the extension point, that is, whether to insert the event stream to the basic use case is determined based on certain conditions, and multiple extension points can be used.

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:

Include relationship and extension relationship ()

Commonalities: both the extended and included use cases are part of the base use cases.

The basic use cases are not executed, but the extended and included use cases are not executed.

Extended use cases can be extended to multiple basic use cases, including use cases that can be included by multiple basic use cases

Differences:

When the basic stream of the basic use case in the extension relationship is executed, the extension use case is not necessarily executed, that is, the extension use case is executed only when the basic use case meets certain conditions.

When the basic stream execution of a basic use case in a link is included, the included use case will certainly be executed.

Summary

The main difficulty of a use case diagram is the use of the three relationships between use cases and use cases.

Use cases are functional modules used to reflect services. We divide services into two categories:

1. Direct/indirect services and 2. Conditional services/unconditional services

Therefore, expansion is a conditional service. Only when the expanded parent class has certain conditions will it provide services.

Generalization and inclusion are unconditional services. Generalization is a direct service, and inclusion is an indirect service.

Let's try again. For example:

By function name: Generalized ---------- subclass name = XX (for specific description) + parent class name. For example, mobile payment = Mobile + payment. PC payment = PC + payment.

Include ---------- include (X1/X2/X3) = include (XX) example: password maintenance/account maintenance/profile maintenance = maintenance.

 

UML use case diagram-Getting Started