Biểu đồ Use Case: Hướng dẫn thực tiễn

Một biểu đồ use case là một biểu đồ hành vi UML thể hiện cách người dùng hoặc hệ thống bên ngoài tương tác với một hệ thống. Nó tập trung vào hệ thống làm gì từ góc độ của một tác nhân, chứ không phải vào các chi tiết triển khai nội bộ.

Biểu đồ use case đặc biệt hữu ích trong giai đoạn phân tích yêu cầu vì chúng cung cấp cái nhìn tổng quan về chức năng và phạm vi của hệ thống.

1. Biểu đồ Use Case thể hiện điều gì

Một biểu đồ use case thường bao gồm:

• Biên giới hệ thống — xác định những gì nằm bên trong hệ thống đang được mô hình hóa.

• Tác nhân — người dùng, tổ chức, thiết bị hoặc hệ thống bên ngoài tương tác với nó.

• Use case — mục tiêu hoặc dịch vụ mà hệ thống cung cấp.

• Liên kết — các liên kết truyền thông giữa các tác nhân và use case.

• Mối quan hệ giữa các use case — chẳng hạn như <<include>> và <<extend>>.

• Tổng quát hóa — sự thừa kế giữa các tác nhân hoặc use case.

Một biểu đồ use case thường không hiển thị:

• Các bước của thuật toán

• Bảng cơ sở dữ liệu

• Lớp chương trình

• Quy trình nội bộ

• Bố cục giao diện người dùng chi tiết

• Chuỗi thông điệp theo thời gian

Những chi tiết đó được thể hiện tốt hơn bằng sơ đồ hoạt động, lớp, chuỗi hoặc trạng thái.

2. Khái niệm cốt lõi

Biên giới hệ thống

Biên giới hệ thống là hình chữ nhật bao quanh các kịch bản sử dụng thuộc về hệ thống.

Ví dụ, trong một hệ thống mua sắm trực tuyến:

+--------------------------------------+
|        Hệ thống mua sắm trực tuyến   |
|                                      |
|  (Duyệt sản phẩm)                    |
|  (Đặt hàng)                          |
|  (Thanh toán)                        |
+--------------------------------------+

Các tác nhân vẫn nằm ngoài biên giới vì chúng là yếu tố bên ngoài hệ thống.

Biên giới giúp làm rõ phạm vicủa hệ thống. Nếu một khả năng nằm ngoài biên giới, nó không được hệ thống đang được mô hình hóa thực hiện.

Các tác nhân

Một tác nhânlà bất kỳ yếu tố bên ngoài nào tương tác với hệ thống để đạt được mục tiêu.

Các tác nhân có thể bao gồm:

• Người dùng là con người

• Ứng dụng bên ngoài

• Thiết bị phần cứng

• Các tổ chức khác

• Thời gian hoặc sự kiện theo lịch trình, khi được mô hình hóa như các kích hoạt bên ngoài

Ví dụ:

• Khách hàng

• Thủ thư

• Cổng thanh toán

• Quản trị viên

• Dịch vụ email

Một tác nhân đại diện cho một vai trò, không nhất thiết là một người cụ thể. Ví dụ, “Khách hàng” thường tốt hơn “Alex.”

Các vai trò có thể là:

• Vai trò chính — khởi tạo các tương tác để đạt được mục tiêu.

• Vai trò hỗ trợ — cung cấp dịch vụ cho hệ thống.

Ví dụ, một khách hàng có thể khởi tạo “Đặt hàng,” trong khi một cổng thanh toán hỗ trợ “Xử lý thanh toán.”

Các trường hợp sử dụng

Một trường hợp sử dụng đại diện cho một mục tiêu hoặc dịch vụ có ý nghĩa do hệ thống cung cấp.

Tên trường hợp sử dụng tốt thường tuân theo dạng sau:

Động từ + tân ngữ

Ví dụ:

• Đăng ký tài khoản

• Tìm kiếm danh mục

• Gửi đơn xin

• Tạo báo cáo

• Hủy đặt chỗ

• Xử lý thanh toán

Một trường hợp sử dụng nên mô tả một kết quả có thể quan sát được, thay vì một bước thực hiện nội bộ.

Ưu tiên:

Đặt hàng

hơn:

Rà soát đối tượng đơn hàng

Cái thứ hai mô tả một hoạt động nội bộ thay vì một mục tiêu của người dùng.

Các liên kết

Một liên kết là một liên kết truyền thông giữa một vai trò và một trường hợp sử dụng.

Nó cho thấy vai trò tham gia hoặc khởi tạo trường hợp sử dụng.

Khách hàng ---- (Đặt hàng)

Các mối liên kết thông thường không chỉ ra trình tự, luồng điều khiển hoặc hướng. Nếu thứ tự của các tương tác là quan trọng, hãy sử dụng biểu đồ trình tự hoặc biểu đồ hoạt động.

3. Mối quan hệ giữa các kịch bản sử dụng

<<include>>

Sử dụng <<include>> khi một kịch bản sử dụng luôn sử dụng một kịch bản sử dụng khác.

Ví dụ, việc đặt hàng có thể luôn yêu cầu xác thực:

(Đặt hàng) ..> (Xác thực khách hàng) : <<include>>

Kịch bản sử dụng cơ sở phụ thuộc vào kịch bản sử dụng được bao gồm.

Sử dụng include khi:

• Hành vi là bắt buộc.

• Hành vi được nhiều kịch bản sử dụng tái sử dụng.

• Việc tách hành vi ra giúp cải thiện tính rõ ràng.

Ví dụ:

(Rút tiền) ..> (Xác thực thẻ) : <<include>>
(Kiểm tra số dư) ..> (Xác thực thẻ) : <<include>>

Cả hai kịch bản sử dụng đều luôn yêu cầu xác thực thẻ.

<<extend>>

Sử dụng <<extend>> khi hành vi bổ sung là tùy chọn hoặc được chèn vào kịch bản sử dụng cơ sở theo điều kiện.

(Áp dụng giảm giá) ..> (Đặt hàng) : <<extend>>

Hành vi giảm giá chỉ xảy ra khi các điều kiện đủ điều kiện được đáp ứng.

Sử dụng extend khi:

• Hành vi là tùy chọn.

• Nó chỉ xảy ra trong một điều kiện nhất định.

• Use case cơ bản đã hoàn tất mà không cần nó.

Ví dụ:

• “Thêm gói quà” mở rộng “Đặt hàng.”

• “Yêu cầu hoàn tiền” mở rộng “Hủy đăng ký.”

• “Gửi email quảng cáo” mở rộng “Hoàn tất đăng ký.”

Mũi tên chỉ từ use case mở rộng đến use case cơ bản.

Tổng quát hóa

Tổng quát hóa biểu thị mối quan hệ “là một” giữa các vai trò hoặc use case.

Ví dụ:

Khách hàng cao cấp --|> Khách hàng

Khách hàng cao cấp là một loại khách hàng và thừa kế các tương tác của khách hàng.

Tổng quát hóa vai trò có thể hữu ích khi nhiều vai trò chia sẻ hành vi chung:

Quản trị viên --|> Nhân viên
Thủ thư --|> Nhân viên

Hãy sử dụng tổng quát hóa một cách tiết kiệm. Nếu mối quan hệ chỉ đơn thuần là “sử dụng” hoặc “tham gia vào,” thì một liên kết thường phù hợp hơn.

4. Vai trò chính và vai trò hỗ trợ

Hãy xem xét một kịch bản thanh toán trực tuyến:

• Cổng thanh toán khách hàng là vai trò chính vì họ khởi tạo việc mua hàng.

• Cổng thanh toán là một vai trò hỗ trợ vì nó xử lý thanh toán theo yêu cầu của hệ thống.

Một mô hình đơn giản có thể trông như thế này:

Khách hàng ---- (Đặt hàng)
(Đặt hàng) ---- Cổng thanh toán

Sự phân biệt này hữu ích vì nó làm rõ ai được hưởng lợi từ use case và hệ thống bên ngoài nào tham gia.

5. Cách xác định use case

Một cách thực tế để phát hiện use case là đặt câu hỏi:

1. Ai sử dụng hệ thống?

2. Mỗi vai trò muốn đạt được mục tiêu gì?

3. Hệ thống cung cấp những dịch vụ nào?

4. Sự kiện nào kích hoạt hành vi của hệ thống?

5. Hệ thống phải tương tác với những hệ thống bên ngoài nào?

6. Hành vi nào luôn được yêu cầu?

7. Hành vi nào là tùy chọn hoặc có điều kiện?

Đối với mỗi vai trò, hãy liệt kê mục tiêu của họ:

Mục tiêu phải có ý nghĩa đối với vai trò. Tránh biến mọi thao tác nhỏ của hệ thống thành một trường hợp sử dụng.

6. Hướng dẫn đặt tên

Sử dụng tên rõ ràng, định hướng theo mục tiêu.

Ví dụ tốt:

• Tạo tài khoản

• Cập nhật hồ sơ

• Gửi yêu cầu bồi thường

• Theo dõi vận chuyển

• Duyệt yêu cầu

• Tạo hóa đơn

Tránh đặt tên mơ hồ:

• Xử lý hệ thống

• Xử lý dữ liệu

• Chức năng người dùng

• Thực thi tác vụ

Tránh chi tiết kỹ thuật quá mức:

• Thực thi truy vấn SQL

• Gọi điểm cuối REST

• Khởi tạo PaymentService

Những bước này có thể là các bước triển khai hợp lệ, nhưng chúng thường không hữu ích dưới dạng các kịch bản sử dụng cấp cao.

7. Ví dụ: Hệ thống quản lý thư viện

Giả sử một hệ thống thư viện hỗ trợ:

• Thành viên tìm kiếm sách

• Thành viên mượn sách

• Thành viên trả sách

• Thủ thư quản lý danh mục

• Thông báo quá hạn

• Xử lý thanh toán tiền phạt

Các vai trò có thể có:

• Thành viên

• Thủ thư

• Dịch vụ thông báo

• Dịch vụ thanh toán

Các kịch bản sử dụng có thể có:

• Tìm kiếm danh mục

• Mượn sách

• Trả sách

• Tính tiền phạt

• Thanh toán tiền phạt

• Quản lý danh mục

• Gửi thông báo quá hạn

Mối quan hệ:

• Mượn sách bao gồm Kiểm tra tư cách thành viên.

• Mượn sách bao gồm Kiểm tra tình trạng sẵn có của sách.

• Trả sách bao gồm Tính tiền phạt.

• Thanh toán tiền phạt tương tác với Dịch vụ Thanh toán.

• Gửi thông báo quá hạn tương tác với Dịch vụ Thông báo.

8. Ví dụ PlantUML

Mã PlantUML sau đây tạo biểu đồ trường hợp sử dụng cho hệ thống thư viện:

@startuml
left to right direction

title Hệ thống Quản lý Thư viện - Biểu đồ Trường hợp Sử dụng

actor Thành viên
actor Thủ thư
actor "Dịch vụ Thông báo" as Notification
actor "Dịch vụ Thanh toán" as Payment

rectangle "Hệ thống Quản lý Thư viện" {

  usecase "Tìm kiếm Danh mục" as UC_Search
  usecase "Mượn sách" as UC_Borrow
  usecase "Trả sách" as UC_Return
  usecase "Kiểm tra tư cách thành viên" as UC_CheckMember
  usecase "Kiểm tra tình trạng sẵn có của sách" as UC_CheckAvailability
  usecase "Tính tiền phạt" as UC_CalculateFine
  usecase "Thanh toán tiền phạt" as UC_PayFine
  usecase "Quản lý danh mục" as UC_ManageCatalog
  usecase "Gửi thông báo quá hạn" as UC_Notify
}

Thành viên --> UC_Search
Thành viên --> UC_Borrow
Thành viên --> UC_Return
Thành viên --> UC_PayFine

Thủ thư --> UC_ManageCatalog
Thủ thư --> UC_Borrow
Thủ thư --> UC_Return

Payment --> UC_PayFine
Notification --> UC_Notify

UC_Borrow ..> UC_CheckMember : <<include>>
UC_Borrow ..> UC_CheckAvailability : <<include>>
UC_Return ..> UC_CalculateFine : <<include>>

UC_Notify ..> UC_Return : <<extend>>

@enduml

9. Giải thích ví dụ

Các vai trò

actor Thành viên
actor Thủ thư
actor "Dịch vụ Thông báo" as Notification
actor "Dịch vụ Thanh toán" as Payment

Biểu đồ mô hình hóa hai vai trò con người và hai dịch vụ bên ngoài.

Các biệt danh như as Notification giúp việc tham chiếu các tên dài trở nên dễ dàng hơn sau này.

Biên giới hệ thống

hình chữ nhật "Hệ thống Quản lý Thư viện" {
    ...
}

Hình chữ nhật xác định phạm vi của hệ thống. Các kịch bản sử dụng bên trong hình chữ nhật được cung cấp bởi hệ thống thư viện.

Liên kết Tác nhân

Thành viên --> UC_Tìm kiếm
Thành viên --> UC_Mượn

Các liên kết này cho thấy một thành viên có thể tìm kiếm trong danh mục và mượn sách.

Hướng mũi tên thường không mang ý nghĩa ngữ nghĩa quan trọng trong một sơ đồ kịch bản sử dụng cơ bản. Nó chủ yếu được sử dụng để làm cho sơ đồ dễ đọc.

Mối quan hệ Bao gồm

UC_Mượn ..> UC_Kiểm tra Thành viên : <<bao gồm>>
UC_Mượn ..> UC_Kiểm tra Tính khả dụng : <<bao gồm>>

Việc mượn sách luôn yêu cầu kiểm tra tư cách thành viên và tính khả dụng, do đó chúng được mô hình hóa dưới dạng các kịch bản sử dụng được bao gồm.

Mối quan hệ Mở rộng

UC_Báo động ..> UC_Trả : <<mở rộng>>

Điều này cho thấy hành vi thông báo quá hạn là hành vi bổ sung liên quan đến việc trả sách.

Tuy nhiên, trong một mô hình yêu cầu thực tế, một thiết kế tự nhiên hơn có thể là liên kết “Gửi thông báo quá hạn” với một quy trình được lên lịch hoặc một tác nhân như “Người lên lịch Thư viện”. Mối quan hệ tốt nhất phụ thuộc vào các quy tắc kinh doanh thực tế.

10. Một bản mô tả kịch bản sử dụng chi tiết hơn

Một sơ đồ cung cấp cái nhìn tổng quan, nhưng mỗi kịch bản sử dụng quan trọng thường nên có một bản mô tả bằng văn bản.

Kịch bản sử dụng: Mượn sách

Biểu đồ trường hợp sử dụng không nên cố gắng chứa tất cả chi tiết này. Biểu đồ cung cấp bản đồ; tài liệu đặc tả cung cấp hành vi.

11. Tham chiếu cú pháp PlantUML

Khai báo diễn viên

actor Customer
actor "Payment Gateway" as Gateway

Khai báo trường hợp sử dụng

usecase "Place Order" as PlaceOrder
usecase "Process Payment" as ProcessPayment

Tạo ranh giới hệ thống

rectangle "Cửa hàng trực tuyến" {
    usecase "Duyệt sản phẩm" as Browse
    usecase "Đặt hàng" as Order
}

Kết nối các vai trò và các trường hợp sử dụng

Khách hàng --> Duyệt
Khách hàng --> Đặt hàng

Bao gồm

Đặt hàng ..> Xử lý thanh toán : <<bao gồm>>

Mở rộng

Áp dụng mã giảm giá ..> Đặt hàng : <<mở rộng>>

Tổng quát hóa vai trò

Khách hàng cao cấp --|> Khách hàng

Nhóm gói

Các gói có thể nhóm trực quan các trường hợp sử dụng liên quan:

rectangle "Hệ thống ngân hàng" {
  package "Quản lý tài khoản" {
    usecase "Mở tài khoản" as OpenAccount
    usecase "Đóng tài khoản" as CloseAccount
  }

  package "Thanh toán" {
    usecase "Chuyển tiền" as TransferFunds
    usecase "Thanh toán hóa đơn" as PayBill
  }
}

Ghi chú

ghi chú bên phải của PlaceOrder
  Khách hàng phải được xác thực
  trước khi đặt hàng.
kết thúc ghi chú

12. Cải thiện bố cục sơ đồ

PlantUML tự động bố trí sơ đồ, nhưng một số kỹ thuật giúp cải thiện khả năng đọc.

Kiểm soát hướng

hướng từ trái sang phải

Điều này thường hữu ích khi các vai trò nên xuất hiện ở hai bên và các trường hợp sử dụng ở trung tâm.

Các hướng phổ biến khác bao gồm:

hướng từ trên xuống dưới

Sử dụng biệt danh

Thay vì lặp lại các tên dài:

usecase "Xác thực danh tính khách hàng" làm VerifyIdentity

Sau đó tham chiếu:

RegisterAccount ..> VerifyIdentity : <<include>>

Nhóm các trường hợp sử dụng liên quan

Sử dụng gói hoặc hình chữ nhật lồng nhau để tách biệt các khu vực chức năng:

package "Quản lý Đơn hàng" {
    usecase "Tạo Đơn hàng" as CreateOrder
    usecase "Hủy Đơn hàng" as CancelOrder
}

Tránh các giao cắt quá mức

Biểu đồ trở nên khó đọc khi có quá nhiều đường cắt nhau. Bạn có thể cải thiện nó bằng cách:

• Đặt các tác nhân liên quan gần các trường hợp sử dụng của chúng

• Nhóm các trường hợp sử dụng vào các gói

• Chia một biểu đồ lớn thành nhiều biểu đồ nhỏ hơn

• Sử dụng biệt danh để tham chiếu rõ ràng

• Tránh các mối quan hệ không cần thiết

13. Những lỗi phổ biến

Mô hình hóa các chức năng nội bộ dưới dạng trường hợp sử dụng

Điều này thường quá kỹ thuật:

Xác thực kết nối cơ sở dữ liệu
Chuẩn hóa yêu cầu
Gọi API thanh toán

Ưu tiên các mục tiêu có ý nghĩa bên ngoài:

Thanh toán
Gửi đơn xin
Tạo báo cáo

Xem mọi tác nhân như một con người

Các hệ thống và thiết bị bên ngoài cũng có thể là tác nhân:

• Cổng thanh toán

• Nhà cung cấp danh tính

• Hệ thống kho

• Máy quét mã vạch

• Dịch vụ thông báo

Sử dụng include cho hành vi tùy chọn

Nếu hành vi là tùy chọn, hãy sử dụng mở rộng thay vì bao gồm.

Sai:

Đặt hàng ..> Áp dụng mã giảm giá : <<bao gồm>>

Nếu việc áp dụng mã giảm giá là tùy chọn, hãy sử dụng:

Áp dụng mã giảm giá ..> Đặt hàng : <<mở rộng>>

Sử dụng mở rộng cho hành vi bắt buộc

Nếu một hành vi luôn xảy ra, nó thường nên được mô hình hóa bằng bao gồm.

Đặt hàng ..> Xác thực khách hàng : <<bao gồm>>

Kết nối các kịch bản sử dụng trực tiếp mà không có ý nghĩa

Một đường nối giữa hai kịch bản sử dụng phải biểu thị một mối quan hệ UML hợp lệ. Tránh các kết nối tùy tiện chỉ đơn thuần ngụ ý rằng các kịch bản sử dụng có liên quan theo cách nào đó.

Tạo một sơ đồ khổng lồ duy nhất

Sơ đồ kịch bản sử dụng nên truyền đạt rõ ràng ở cấp độ cao. Nếu nó chứa hàng chục người dùng và kịch bản sử dụng, hãy tạo nhiều sơ đồ được tổ chức theo phân hệ hoặc lĩnh vực kinh doanh.

Hiển thị trình tự

Sơ đồ kịch bản sử dụng không hiển thị việc một kịch bản sử dụng xảy ra trước kịch bản khác. Đối với trình tự, hãy sử dụng sơ đồ trình tự hoặc sơ đồ hoạt động.

14. Khi nào sử dụng các sơ đồ UML khác

Sơ đồ kịch bản sử dụng là tốt nhất cho phạm vi hệ thống và mục tiêu người dùng. Kết hợp chúng với các sơ đồ khác khi cần thêm chi tiết:

15. Quy trình mô hình hóa được khuyến nghị

1. Xác định ranh giới hệ thống.

2. Xác định tất cả các tác nhân bên ngoài.

3. Xác định mục tiêu của từng tác nhân.

4. Chuyển đổi các mục tiêu đó thành các trường hợp sử dụng.

5. Kết nối các tác nhân với các trường hợp sử dụng mà họ tham gia.

6. Xác định hành vi tái sử dụng bắt buộc và mô hình hóa nó bằng <<include>>.

7. Xác định hành vi tùy chọn hoặc có điều kiện và mô hình hóa nó bằng <<extend>>.

8. Chỉ thêm quan hệ tổng quát hóa ở những nơi có mối quan hệ “là một” thực sự.

9. Xem lại biểu đồ với các bên liên quan.

10. Thêm các đặc tả văn bản cho các trường hợp sử dụng quan trọng.

11. Chia nhỏ biểu đồ nếu nó trở nên quá tải.

16. Mẫu PlantUML gọn nhẹ

Bạn có thể sử dụng điều này làm điểm khởi đầu:

@startuml
left to right direction

title Biểu đồ Trường hợp Sử dụng Hệ thống

actor Người dùng
actor "Hệ thống bên ngoài" as ExternalSystem

rectangle "Tên hệ thống" {
  usecase "Mục tiêu chính của người dùng" as MainGoal
  usecase "Hành vi chia sẻ bắt buộc" as RequiredBehavior
  usecase "Hành vi tùy chọn" as OptionalBehavior
}

Người dùng --> MainGoal
ExternalSystem --> MainGoal

MainGoal ..> RequiredBehavior : <<include>>
OptionalBehavior ..> MainGoal : <<extend>>

@enduml

Nguyên tắc cốt lõi là mô hình hóa các mục tiêu có thể nhìn thấy từ bên ngoài, chứ không phải các chi tiết triển khai nội bộ. Một sơ đồ trường hợp sử dụng mạnh mẽ giúp làm cho ranh giới hệ thống, các vai trò, khả năng và các phụ thuộc quan trọng trở nên dễ hiểu ngay lập tức.

Tài liệu tham khảo

This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese and 简体中文.