How to draw a standard UML use case diagram

[Live broadcast preview] How far do we have to go to replace Oracle?

If you have some confusion during the design process, such as: not knowing how to find use cases, not being able to distinguish between the two use case diagrams, or not knowing whether the one you drew is correct. So I hope this article can help clarify the above issues, truly master the use case diagram, and be able to use it easily in subsequent designs.

Do you have any of the following confusions when designing?

1. Can’t find use cases: What are business use cases and system use cases? How should I write the use case correctly?

2. The two use case diagrams are not clearly distinguishable: the business use case diagram and the system use case diagram feel similar, and there seems to be no difference?

3. I don’t know if what I drew is correct: I drew a use case diagram just like a cat or a tiger, but I don’t know if it is correct. In case the reviewer doesn’t know how to do it, let’s just leave it like this.

If you have the above confusions during the design process, then I hope this article can help clarify the above issues, truly master the use case diagram, and use it with ease in subsequent designs.

1. How to identify the right use cases

First, let’s look at the concept of use cases. The encyclopedia defines “a use case as a description of how the system responds to external requests in software engineering or system engineering. It is a technology that obtains requirements through user usage scenarios.” What does it mean? Here I quote a passage from "Elephant: Thinking in UML" to explain this definition.

The functionality of this world is reflected in the fact that first there is someone's desire, which drives people to do things and obtain a certain result. Without desire, functionality is impossible. A system is composed of various desires. In other words, various people do various things for their own purposes to form a system. If we want to describe the functional requirements of a system, we must find people who have aspirations for the system and let them explain what they will do in the system and what results they want. If all the things that anyone who wants the system to do are found, then the functionality of the system is confirmed.

One of the most important characteristics of a use case is that it is relatively independent. This means that it does not need to interact with other use cases to complete the purpose of the participant alone, which means that the use case is "functionally" complete. The essence of use cases reflects the wishes of system participants. Those that cannot fully meet the wishes of participants cannot be called use cases. For example, withdrawing money is a valid use case, but filling in a withdrawal form is not, because the complete purpose is to withdraw money, and no one will make a special trip to the bank just to fill in the withdrawal form.

There are two types of use cases, business use cases and system use cases. So how do we accurately identify use cases? Next, we will analyze the business use cases and system use cases one by one.

1.1 Business use cases

A business use case is defined as the value that business actors hope to gain from interacting with the organization under study.

We can see a key word - value. This value does not refer to what you (the organization) can provide but to what I (the executor) want. At this time, we need to put the perspective outside the organization and switch to the executor. , to see what he hopes to gain from the organization, rather than looking inside the organization to see what the organization can provide. For example, take the restaurant organization as an example. Its business executors are mainly customers. Although the restaurant can provide services such as change exchange, football game broadcast, and power bank rental, customers come to the restaurant just to eat. Customer->dining is the restaurant's business. Use case, providing dining services is the greatest value of the restaurant organization.

Just imagine if a restaurant does not operate around the concept of "providing high-quality and low-priced dining services", but the quality of the food is very poor and a lot of power bank services are provided, then the results of this restaurant can be imagined.

1.2 System use cases

After talking about business use cases, let’s look at system use cases. The definition of system use cases is the value that the system can provide to the executors and is acceptable to the stakeholders . Some of these concepts:

1. System

Only something that encapsulates its own data and behavior and can independently provide external services can be called a system. It should be noted that the system is a whole, and the system may have many subsystems. For example, bank transfer transactions require risk control. If a merchant sells a trading system to a bank, then the risk control subsystem must be included in the entire trading system and packaged together and sold to the bank.

2. System executor

System actors are defined as other systems outside the system under study that functionally interact with the system. There are a few points to note here:

The system executor must be outside the system and can be a person or other system;
System executors must interact with the system;
System executors are not necessarily business executors;

3. Stakeholders

Stakeholders are all people and things related to the business system to be built, and system executors are also part of the stakeholders.

Let’s take a restaurant as an example. If the customer tells the waiter verbally (rather than scanning the QR code to place an order) what dish he wants, and the waiter places an order for the customer through the ordering system, then by studying this ordering system we can conclude:

1. System executor: Waiter. Although the customer is the business executor of the restaurant organization, it is the waiter who directly interacts with the ordering system, so the waiter is the system executor of the ordering system;

2. Stakeholders, there are many, customers, waiters, restaurant owners, chefs, etc. are all stakeholders because they are all stakeholders in the ordering system;

a. The customer is worried that his order was not successful and he waited for a long time without being served; b. The waiter is worried that the failure to place the order will lead to customer complaints and his bonus will be deducted; c. The boss is worried that the system failure will cause many customer complaints and the business will be affected;

d. The chef is worried that the allocation of the ordering system is unreasonable, and all the dishes are allocated to himself;

Generally, this ordering system allows you to log in, place orders, and view order records. These are some of the functions of the ordering system. Let's review the concept of system use cases: System use cases refer to the value that the system can provide to the executor and is acceptable to the stakeholders. Then we will analyze the need for these functions from the perspective of each stakeholder.

	Log in	Place an order	View order records
waiter	I need it, otherwise what should I do if someone places the wrong order and blames me?	I need it！	I need it so I can check if the customer's dishes are ready.
customer	I don't care！	Whether I can place an order directly affects whether I can eat.	I need it too. I have to print out my menu so I can check it when I check out.
boss	I need it too. I can see how the waiter is doing.	The ordering system cannot place orders. Why should I buy it?	I need it to facilitate order management and see which dish is ordered by the most customers.
chef	I don't care！	Can't place an order? Who can tell me what to cook?	I need it, otherwise there’s no way to explain why I’ve cooked one less dish.

Therefore, from the above, we can conclude that placing an order and viewing order records satisfy the concept of system use cases. The system use case diagram is as follows

It can be seen that different from business use cases, when studying system use cases, we need to switch our perspective to the system, and start from the system to see what kind of value can be provided to the executors and can be accepted by the stakeholders.

Tips:
1. The name of the use case is generally a verb-object structure, that is, "verb + noun", but this is not strictly required. For example, there is no need to reverse the industry term "results analysis" and change it to "analysis results".

2. Study the business process honestly, do business modeling well, and try to map the system use cases from the business sequence diagram. The system obtained in this way Use cases are the most real.

3. A use case can have a main executor and an auxiliary executor: the main executor points from the executor to the use case, and the auxiliary executor points from the use case to the executor. The main executor initiates the interaction of the use case, and the auxiliary executor is passive during the interaction process. Get involved. Generally speaking, it is rare for the auxiliary executor to be a human system, and more often it is another non-human intelligent system.

4. The main executor and the auxiliary executor are relative to the use case. "xx is the main/auxiliary executor of the xx use case" is correct, but the statement "xx is the main/auxiliary executor of the xx system" is wrong.

2. How to distinguish business use case diagrams and system use case diagrams

I believe that after the above analysis, you have discovered the similarities and differences between the two use case diagrams. If not, I will post two more diagrams (to facilitate comparison, the ordering system is simplified into one use case of ordering) for a more intuitive comparison:

That's right, the biggest difference between the two diagrams is whether there is a "/". The business use case diagram has "/" on the business executor and business use case, while the system use case diagram does not have "/" on the system executor and system use case diagram. ”, it’s that simple. So now when you look at the following pictures, you can see the problems at a glance.

3. How to use PlantUML to draw standardized use case diagrams

PlantUML is a component or language that can quickly create UML graphics, defining graphics through a simple and intuitive language. It has great advantages in learning cost, efficiency, team collaboration and maintenance cost, so it is recommended to use PlantUML to draw pictures.

The use case diagram is actually very simple. It mainly consists of four elements. Here we take the system use case as an example. The four elements are system, executor, use case and relationship.

3.1 System

The system is represented by a rectangular block, which is rectangle in UML syntax. as follows:

@startuml

rectangle "xx 系统" {

}

@enduml

3.2 Executor

The executor is represented by a fire material person, which is actor in UML syntax. There are two main ways of writing it, as follows:

@startuml

'系统执行者的两种写法'
actor Actor1
:Actor2:

'业务执行者的两种写法'
actor/ Actor3
:Actor4:/

@enduml

3.3 Use cases

The use case is represented by an ellipse. In UML syntax, it is usecase. The two ways of writing business use cases and system use cases are as follows:

@startuml

usecase/ " 业务用例 1" as UC1
'业务用例的第二种写法：() + 用例名称 + /'
(业务用例 2)/ as UC3

usecase "系统用例 1" as UC2
'系统用例的第二种写法：() + 用例名称 '
(系统用例 2)
@enduml

3.4 Relationship

There are four main types of relationships in the system use case diagram, namely association, inclusion, extension, and generalization.

3.4.1 Association

Association is a relationship between the executor and the use case, generally represented by a solid line + a solid arrow:

@startuml

actor Actor
rectangle "xx系统" {
  usecase "系统用例 1" as UC1
}

Actor -> UC1
@enduml

One thing to note here is that although the association relationship can be directly represented by a solid line such as AB, in the use case diagram we try to use a solid line + arrow to represent it, otherwise it is as follows:

You can't distinguish between Actor1 and Actor2, who is the main executor and who is the auxiliary executor, or are both main executors? It is very easy to distinguish after adding arrows, as follows

3.4.2 Contains

Inclusion is a relationship between use cases, in which the behavior of one use case (called a base use case) includes the behavior of another use case (called an included use case), represented by a dotted arrow + <<include>>, with the arrow pointing to the included use case .

The inclusion relationship means that the inclusion use case is an indispensable execution step in the basic use case. If the inclusion case is missing, the basic use case will become incomplete, which can be compared to the combination relationship between objects in a class diagram. Two scenarios for using include relationships:

When the basic use cases are complex, some inclusive use cases can be decomposed;
When two or more basic use cases have some repetitive behaviors, a containing use case can be extracted;

@startuml
'加入下面代码指定方向，使 UML 从左往右更直观'
left to right direction

actor Actor
rectangle "xx系统" {
  usecase "基本用例" as UC1
  usecase "包含用例 1" as UC2
  usecase "包含用例 2" as UC3
}

Actor --> UC1
UC1 ..> UC2 : <<include>>
UC1 ..> UC3 : <<include>>

@enduml

I used Actor --> UC1, UC1 ..> UC2 above. If you are interested, you can change it to ->, .> to see the effect.

3.4.3 Extended relationships

Extension is a relationship between use cases in which the behavior of one use case (called the extended use case) enhances the behavior of another use case (called the base use case), represented by a dotted arrow + <<extend>>, with the arrow pointing to the base use case .

The extended use case is a supplement or enhancement to the basic use case. Even without the extended use case, it will not have a direct impact on the basic use case. The basic use case itself is still complete. In other words, the extended use case is a possible supplement to the basic use case. For example, purchasing freight insurance is an extension of the use case of placing an order. Whether you buy freight insurance or not does not affect the order placement.

@startuml
left to right direction

actor Actor
rectangle "xx系统" {
  usecase "基本用例" as UC1
  usecase "扩展用例" as UC2
}

Actor --> UC1
UC1 <.. UC2 : <<extend>>

@enduml

3.4.4 Generalization

The generalization relationship can also be called an inheritance relationship (analogous to the generalization in a class diagram), represented by a solid line + hollow arrow, which can represent the relationship between executors or the relationship between use cases.

@startuml
left to right direction
actor Actor

rectangle "xx系统" {
  usecase "支付" as UC1
  usecase "微信支付" as UC2
  usecase "支付宝支付" as UC3
}

Actor --> UC1
UC1 <|-- UC2 
UC1 <|-- UC3

@enduml

4. A case

Here we take a bank's App as an example. As a system of the bank, we analyze it:

1. System: Of course it is this App

2. System executor

a. Main executor: Generally, customers who come to the bank to do business are main executors, including individual users and corporate users;

b. Auxiliary executor: Bank, all the business handled by the user in the App requires the bank to cooperate and execute;

3. System use cases: As a bank’s online business, it includes transfers, balance inquiries, financial management, and loans.

4. Relationship: What needs to be noted here is that too many transfers may exceed the limit. At this time, an over limit message will be displayed; before applying for a loan, the bank will definitely evaluate the user's assets to determine the loan amount.

@startuml
left to right direction
actor 客户 as Actor
actor 银行 as Actor2

rectangle "某银行App" {
  usecase "转账" as UC1
  usecase "查询余额" as UC2
  usecase "理财" as UC3
  usecase "贷款" as UC4
  usecase "评估资产" as UC5
  usecase "提示限额" as UC6
}

Actor <|-up- 个人用户
Actor <|-up- 企业用户
Actor --> UC1

Actor --> UC2
Actor --> UC3
Actor --> UC4
UC1 ----> Actor2
UC2 ----> Actor2
UC3 ----> Actor2
UC4 ----> Actor2

UC4 .left.> UC5 :<<include>>
UC1 <.down. UC6 :<<extend>>

@enduml

The overall use case diagram is as follows:

Author | Yehe

Original link

This article is original content from Alibaba Cloud and may not be reproduced without permission.