Cách Vẽ Biểu Đồ Use-case: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao

1. Giới thiệu chung về Use-Case và Vai trò của Biểu Đồ Use-Case

1.1. Use-Case là gì?

Use-case (trường hợp sử dụng) là một khái niệm quan trọng trong phân tích và thiết kế phần mềm, được giới thiệu lần đầu trong cuốn sách Object-Oriented Software Engineering của Ivar Jacobson. Use-case mô tả cách một hệ thống tương tác với các tác nhân (actor) bên ngoài để đạt được một mục tiêu cụ thể. Mỗi use-case thường bao gồm:

• Tên: Định danh duy nhất, mô tả ngắn gọn mục tiêu.
• Mô tả: Giải thích chi tiết hành vi của hệ thống.
• Các tác nhân: Người dùng, hệ thống khác hoặc thiết bị tương tác.
• Các luồng: Luồng chính (happy path) và các luồng phụ (exception, alternate).
• Preconditions và Postconditions: Điều kiện trước và sau khi thực hiện.

1.2. Tại sao cần biểu đồ use-case?

Biểu đồ use-case (Use-Case Diagram) là một công cụ trực quan giúp:

• Giao tiếp: Trình bày nhanh chóng yêu cầu chức năng cho khách hàng, nhà quản lý và các bên liên quan.
• Phân tích: Xác định phạm vi hệ thống, các tác nhân và các mối quan hệ.
• Kiểm tra: Dễ dàng xây dựng các test case dựa trên các luồng của use-case.
• Thiết kế: Hỗ trợ việc chia nhỏ công việc, phân công và lập kế hoạch phát triển.

2. Chuẩn bị trước khi vẽ biểu đồ use-case

2.1. Thu thập yêu cầu

• Phỏng vấn: Gặp gỡ người dùng cuối, khách hàng, nhà quản lý để hiểu nhu cầu.
• Tài liệu: Đọc các tài liệu yêu cầu, hợp đồng, tiêu chuẩn nghiệp vụ.
• Workshop: Tổ chức buổi brainstorming để xác định các chức năng chính.

2.2. Xác định các tác nhân (actors)

• Actor là ai?: Mọi người, hệ thống, thiết bị hoặc phần mềm khác tương tác với hệ thống.
• Phân loại:
• Primary actor: Bắt đầu một use-case để đạt mục tiêu.
• Secondary actor: Hỗ trợ primary actor trong quá trình thực hiện.
• Kỹ thuật: Vẽ sơ đồ “actor diagram” đơn giản để liệt kê tất cả các actor.

2.3. Xác định các use-case chính

Có thể bạn quan tâm: Cách Vẽ Biểu Đồ Uml: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao

• Phương pháp “User Stories”: “As a actor, I want to goal so that benefit”.
• Phân nhóm: Gom các use-case có liên quan thành packages (gói) để quản lý dễ dàng.
• Kiểm tra tính đầy đủ: Đảm bảo mỗi mục tiêu nghiệp vụ đều có ít nhất một use-case mô tả.

3. Các ký hiệu và quy tắc chuẩn trong UML Use-Case Diagram

Ký hiệu	Tên	Mô tả
Hình elip	Use-Case	Đại diện cho một chức năng hệ thống.
Stick figure	Actor	Người dùng hoặc hệ thống bên ngoài.
Đường thẳng	Association	Mối quan hệ giao tiếp giữa actor và use-case.
Đường mũi tên trống (<>)	Include	Một use-case luôn được thực hiện trong use-case khác.
Đường mũi tên trống (<>)	Extend	Use-case phụ được thực hiện tùy thuộc vào điều kiện.
Hình chữ nhật bao quanh	Package	Nhóm các use-case liên quan.
Đường nét đứt	Dependency	Mối quan hệ phụ thuộc, thường dùng cho <> hoặc <>.

3.1. Các mối quan hệ quan trọng

• Association (giao tiếp): Kết nối actor và use-case, biểu thị actor có thể thực hiện use-case.
• Include: Khi một use-case luôn chứa một phần chức năng chung, ta tách phần chung thành một use-case riêng và dùng <>.
• Extend: Khi một use-case chỉ thực hiện trong một số điều kiện, ta dùng <> để mô tả sự mở rộng.
• Generalization (kế thừa): Cả actor và use-case đều có thể kế thừa, ví dụ: “Quản trị viên” kế thừa “Người dùng”.

4. Quy trình vẽ biểu đồ use-case chi tiết

4.1. Bước 1: Vẽ các actor

1. Đặt tên: Tên ngắn gọn, mô tả vai trò (ví dụ: “Khách hàng”, “Nhân viên bán hàng”).
2. Vị trí: Đặt actor ở phía ngoài biên của biểu đồ, thường ở phía trái hoặc phía trên.
3. Sắp xếp: Giữ khoảng cách hợp lý để tránh giao nhau các đường kết nối.

4.2. Bước 2: Vẽ các use-case

1. Đặt tên: Sử dụng động từ + danh từ (ví dụ: “Đặt hàng”, “Xem lịch sử mua hàng”).
2. Kích thước: Đảm bảo mỗi elip đủ lớn để chứa tên.
3. Nhóm: Nếu có nhiều use-case liên quan, đặt chúng gần nhau và bao quanh bằng một package nếu cần.

4.3. Bước 3: Tạo các kết nối Association

• Kéo đường thẳng từ actor tới use-case mà actor tham gia.
• Tránh giao nhau: Nếu có đường cắt nhau, dùng “routing” (đi qua các điểm trung gian) hoặc “bridge” để biểu thị.

4.4. Bước 4: Xác định và vẽ các mối quan hệ Include / Extend

Có thể bạn quan tâm: Cách Vẽ Biểu Đồ U‑chart: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao

• Include:
• Xác định các chức năng chung (ví dụ: “Xác thực người dùng”).
• Đánh dấu <> trên đường nối từ use-case chính tới use-case chung.
• Extend:
• Xác định các trường hợp mở rộng (ví dụ: “Áp dụng mã giảm giá” chỉ khi có mã).
• Đánh dấu <> và chỉ định điểm mở rộng (extension point) trong use-case gốc.

4.5. Bước 5: Đánh dấu các package (nếu có)

• Vòng bao quanh các use-case có liên quan.
• Đặt tên package (ví dụ: “Quản lý đơn hàng”, “Báo cáo”).

4.6. Bước 6: Kiểm tra lại tính đầy đủ và logic

• Mỗi actor có ít nhất một use-case?
• Mỗi use-case có ít nhất một actor?
• Không có mối quan hệ vòng lặp không cần thiết.
• Tên các thành phần rõ ràng, không trùng lặp.

5. Công cụ hỗ trợ vẽ biểu đồ use-case

Công cụ	Loại	Ưu điểm	Nhược điểm
Microsoft Visio	Desktop	Đa dạng mẫu, tích hợp Office	Giá thành cao
Lucidchart	Web	Hợp tác thời gian thực, tích hợp Google Drive	Giới hạn bản miễn phí
draw.io (diagrams.net)	Web/Desktop	Miễn phí, mở rộng plugin	Giao diện hơi phức tạp cho người mới
StarUML	Desktop	Hỗ trợ UML đầy đủ, export code	Cần mua giấy phép
PlantUML	Text-based	Tạo diagram bằng code, dễ tích hợp CI	Cần học ngôn ngữ mô tả

5.1. Hướng dẫn nhanh với PlantUML

PlantUML cho phép viết mô tả bằng văn bản và tự động tạo diagram:

@startuml
left to right direction
actor KhachHang
actor NhanVien package "Quản lý đơn hàng" { usecase "Đặt hàng" as UC1 usecase "Thanh toán" as UC2 usecase "Xác thực người dùng" as UC3 <<include>> usecase "Áp dụng mã giảm giá" as UC4 <<extend>>
} KhachHang --> UC1
KhachHang --> UC2
UC1 --> UC3 : <<include>>
UC2 --> UC4 : <<extend>>
@enduml

Kết quả sẽ là một biểu đồ sạch sẽ, dễ chỉnh sửa và version control.

6. Các lưu ý thực tiễn khi vẽ biểu đồ use-case trong dự án thực tế

6.1. Đừng quá chi tiết

Biểu đồ use-case không phải là nơi mô tả chi tiết thuật toán. Nếu một use-case quá phức tạp, hãy tách thành các use-case con hoặc sử dụng activity diagram để mô tả chi tiết hơn.

6.2. Tránh lặp lại actor và use-case

Có thể bạn quan tâm: Cách Vẽ Biểu Đồ U: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao

Nếu một actor tương tác với nhiều use-case, chỉ cần vẽ một lần và nối tới mọi use-case. Điều này giảm sự lộn xộn và tăng tính đọc hiểu.

6.3. Sử dụng naming convention đồng nhất

• Actor: Đặt tên danh từ (ví dụ: “Khách hàng”, “Quản trị viên”).
• Use-case: Đặt tên động từ + danh từ (ví dụ: “Xem báo cáo”, “Cập nhật thông tin”).

6.4. Quản lý phiên bản

Khi dự án phát triển, yêu cầu có thể thay đổi. Sử dụng hệ thống quản lý phiên bản (Git) để lưu trữ các file diagram (đặc biệt là dạng text như PlantUML) giúp theo dõi lịch sử và so sánh.

6.5. Đối chiếu với tài liệu yêu cầu

Sau khi hoàn thành diagram, hãy so sánh lại với tài liệu yêu cầu (SRS). Mỗi yêu cầu chức năng (functional requirement) nên có ít nhất một use-case tương ứng.

7. Ví dụ thực tế: Vẽ biểu đồ use-case cho một hệ thống thương mại điện tử

Có thể bạn quan tâm: Cách Vẽ Biểu Đồ Tròn: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao

7.1. Các actor chính

• Khách hàng: Người mua hàng.
• Quản trị viên: Quản lý sản phẩm, đơn hàng.
• Hệ thống thanh toán: Đối tác thanh toán bên ngoài.
• Nhân viên giao hàng: Thực hiện giao hàng.

7.2. Các use-case quan trọng

1. Đăng ký tài khoản
2. Đăng nhập
3. Duyệt danh mục sản phẩm
4. Thêm sản phẩm vào giỏ
5. Xem giỏ hàng
6. Thanh toán (include: “Xác thực người dùng”, “Gửi yêu cầu thanh toán”)
7. Áp dụng mã giảm giá (extend: “Thanh toán”)
8. Quản lý sản phẩm (include: “Thêm sản phẩm”, “Cập nhật sản phẩm”, “Xóa sản phẩm”)
9. Xem báo cáo bán hàng
10. Xử lý đơn hàng (include: “Xác nhận đơn hàng”, “Giao hàng”)

7.3. Mô tả sơ đồ (text PlantUML)

@startuml
actor "Khách hàng" as KH
actor "Quản trị viên" as QTV
actor "Hệ thống thanh toán" as HTTT
actor "Nhân viên giao hàng" as NVGH package "Mua sắm" { usecase "Đăng ký tài khoản" as UC_DK usecase "Đăng nhập" as UC_DN usecase "Duyệt danh mục sản phẩm" as UC_DSM usecase "Thêm sản phẩm vào giỏ" as UC_ThemGio usecase "Xem giỏ hàng" as UC_XemGio usecase "Thanh toán" as UC_ThanhToan usecase "Xác thực người dùng" as UC_XacThuc <<include>> usecase "Gửi yêu cầu thanh toán" as UC_GuiTT <<include>> usecase "Áp dụng mã giảm giá" as UC_MaGiam <<extend>>
} package "Quản lý" { usecase "Quản lý sản phẩm" as UC_QLSP usecase "Thêm sản phẩm" as UC_ThemSP usecase "Cập nhật sản phẩm" as UC_CapNhatSP usecase "Xóa sản phẩm" as UC_XoaSP usecase "Xem báo cáo bán hàng" as UC_BaoCao usecase "Xử lý đơn hàng" as UC_XLDH usecase "Xác nhận đơn hàng" as UC_XacNhan <<include>> usecase "Giao hàng" as UC_GiaoHang <<include>>
} KH --> UC_DK
KH --> UC_DN
KH --> UC_DSM
KH --> UC_ThemGio
KH --> UC_XemGio
KH --> UC_ThanhToan
UC_ThanhToan --> UC_XacThuc : <<include>>
UC_ThanhToan --> UC_GuiTT : <<include>>
UC_ThanhToan --> UC_MaGiam : <<extend>> QTV --> UC_QLSP
UC_QLSP --> UC_ThemSP : <<include>>
UC_QLSP --> UC_CapNhatSP : <<include>>
UC_QLSP --> UC_XoaSP : <<include>>
QTV --> UC_BaoCao
QTV --> UC_XLDH
UC_XLDH --> UC_XacNhan : <<include>>
UC_XLDH --> UC_GiaoHang : <<include>> HTTT --> UC_GuiTT
NVGH --> UC_GiaoHang
@enduml

Biểu đồ trên cho thấy mối quan hệ rõ ràng giữa các actor và use-case, đồng thời sử dụng <> và <> một cách hợp lý để giảm trùng lặp.

8. Từ biểu đồ use-case tới các artefact khác

8.1. Tạo mô tả chi tiết (Use-Case Specification)

Sau khi có biểu đồ, mỗi use-case cần một tài liệu chi tiết bao gồm:

Phần	Nội dung
Tên	Tên duy nhất, giống tên trong diagram
Mô tả ngắn	1-2 câu tóm tắt
Actor chính	Ai là người khởi tạo?
Preconditions	Điều kiện trước khi bắt đầu
Postconditions	Kết quả sau khi hoàn thành
Luồng chính (Basic Flow)	Các bước thực hiện thành công
Luồng phụ (Alternative Flows)	Các trường hợp ngoại lệ, lỗi
Yêu cầu phi chức năng	Hiệu suất, bảo mật, …
Ghi chú	Thông tin bổ sung

8.2. Chuyển sang Activity Diagram

Đối với các use-case phức tạp, vẽ Activity Diagram để mô tả luồng công việc chi tiết, bao gồm quyết định (decision), vòng lặp (loop) và đồng thời (parallel).

8.3. Tạo Test Cases

Mỗi luồng (basic và alternative) có thể được chuyển thành một hoặc nhiều test case, giúp kiểm thử chức năng (functional testing) và kiểm thử tích hợp (integration testing).

9. Thực hành: Bài tập tự luyện

1. Bài tập 1: Lấy một hệ thống ngân hàng online, xác định ít nhất 5 actor và 8 use-case, vẽ diagram bằng draw.io.
2. Bài tập 2: Đối với use-case “Rút tiền”, viết mô tả chi tiết, bao gồm preconditions, postconditions và 2 luồng phụ.
3. Bài tập 3: Sử dụng PlantUML, tạo một diagram có package “Quản lý tài khoản” và “Giao dịch”, sau đó export thành PNG.

10. Kết luận

Việc vẽ biểu đồ use-case không chỉ là một bước trong quá trình phân tích hệ thống mà còn là công cụ giao tiếp mạnh mẽ, giúp các bên liên quan hiểu rõ chức năng, phạm vi và mối quan hệ của hệ thống. Khi thực hiện đúng quy trình:

• Bắt đầu bằng thu thập yêu cầu và xác định actor.
• Sử dụng các ký hiệu UML chuẩn, chú ý tới các mối quan hệ <> và <>.
• Kiểm tra tính đầy đủ, logic và đảm bảo tính nhất quán với tài liệu yêu cầu.
• Lựa chọn công cụ phù hợp (Visio, Lucidchart, draw.io, PlantUML…) để tối ưu thời gian và hiệu quả.
• Mở rộng từ diagram sang tài liệu chi tiết, activity diagram và test case.

Hy vọng bài viết này đã cung cấp cho bạn một hướng dẫn toàn diện, chi tiết và thực tiễn để cách vẽ biểu đồ use-case một cách chuyên nghiệp, đáp ứng nhu cầu phân tích và thiết kế phần mềm hiện đại. Chúc bạn thành công trong việc áp dụng kiến thức này vào dự án thực tế!