Cách Vẽ Use Case Diagram: Hướng Dẫn Chi Tiết Từ Cơ Bản Đến Nâng Cao

1. Giới thiệu tổng quan về Use Case Diagram

Use Case Diagram (biểu đồ trường hợp sử dụng) là một trong những công cụ quan trọng nhất trong UML (Unified Modeling Language) để mô tả chức năng của một hệ thống từ góc độ người dùng. Thay vì tập trung vào cấu trúc nội bộ hay thuật toán, Use Case Diagram giúp chúng ta hiểu rõ những gì hệ thống phải thực hiện, ai là người (hoặc hệ thống) tương tác với nó, và các mối quan hệ giữa các chức năng.

1.1. Lợi ích khi sử dụng Use Case Diagram

Lợi ích	Mô tả
Giao tiếp dễ hiểu	Biểu đồ được vẽ bằng các hình ảnh đơn giản (hình người, hình bầu dục) nên ngay cả những người không có kiến thức kỹ thuật cũng có thể đọc được.
Xác định yêu cầu	Giúp các nhà phân tích và khách hàng thống nhất về các chức năng cần có, tránh thiếu sót hoặc hiểu lầm.
Hỗ trợ thiết kế	Khi đã có Use Case Diagram, các giai đoạn tiếp theo như thiết kế lớp, thiết kế giao diện, và viết test case sẽ trở nên mạch lạc hơn.
Quản lý dự án	Dễ dàng phân chia công việc cho các nhóm phát triển dựa trên các use case riêng lẻ.
Kiểm tra và bảo trì	Khi thay đổi yêu cầu, chỉ cần cập nhật các use case liên quan mà không ảnh hưởng đến toàn bộ hệ thống.

1.2. Các thành phần cơ bản của Use Case Diagram

1. Actor (Diễn viên): Đối tượng (có thể là người, hệ thống, thiết bị) tương tác với hệ thống. Được biểu diễn bằng hình người (stick figure).
2. Use Case (Trường hợp sử dụng): Mô tả một hành động hoặc chức năng mà hệ thống thực hiện để đáp ứng nhu cầu của actor. Được vẽ dưới dạng hình bầu dục.
3. System Boundary (Ranh giới hệ thống): Một khung chữ nhật bao quanh các use case, cho biết phạm vi chức năng của hệ thống.
4. Relationships (Mối quan hệ):
5. Association (Liên kết): Đường thẳng nối actor với use case.
6. Include (Bao gồm): Mũi tên có ký hiệu «include», cho thấy một use case luôn thực hiện một use case khác.
7. Extend (Mở rộng): Mũi tên có ký hiệu «extend», cho thấy một use case có thể mở rộng hành vi của một use case khác trong một số điều kiện.
8. Generalization (Kế thừa): Đường thẳng có mũi tên rỗng, thể hiện quan hệ kế thừa giữa các actor hoặc các use case.

2. Các bước chuẩn bị trước khi vẽ Use Case Diagram

2.1. Thu thập và phân tích yêu cầu

Có thể bạn quan tâm: Cách Vẽ Tóc Thắt Bím Đẹp, Chi Tiết Từ Cơ Bản Đến Nâng Cao

• Phỏng vấn stakeholder: Gặp gỡ người dùng cuối, khách hàng, quản lý dự án để hiểu nhu cầu thực tế.
• Xem tài liệu: Đọc các tài liệu yêu cầu, hợp đồng, và các quy trình kinh doanh hiện có.
• Sử dụng kỹ thuật “User Stories”: Viết các câu chuyện người dùng dạng “As a …, I want …, so that …” để làm nền tảng cho các use case.

2.2. Xác định các Actor

• Actor chính: Người dùng cuối (Customer, Admin, Staff).
• Actor phụ: Hệ thống bên ngoài (Payment Gateway, Email Server, Mobile App).
• Actor hệ thống: Các thành phần nội bộ khác (Database, Scheduler).

Hãy nhớ rằng một actor không nhất thiết phải là con người; bất kỳ thực thể nào tương tác với hệ thống đều được xem là actor.

2.3. Định danh các Use Case

• Liệt kê: Ghi lại tất cả các chức năng mà hệ thống cần thực hiện.
• Phân nhóm: Sắp xếp các use case theo chức năng chính (Quản lý người dùng, Quản lý đơn hàng, Báo cáo).
• Kiểm tra tính bao phủ: Đảm bảo mỗi yêu cầu đã được ánh xạ tới ít nhất một use case.

2.4. Xác định mối quan hệ

• Include: Khi một hành động luôn luôn xuất hiện trong một use case khác (ví dụ: “Xác thực người dùng” luôn được thực hiện trong “Đăng nhập”, “Mua hàng”).
• Extend: Khi một hành động chỉ xảy ra trong một số trường hợp đặc biệt (ví dụ: “Áp dụng mã giảm giá” mở rộng “Thanh toán” khi người dùng nhập mã).
• Generalization: Khi các actor hoặc use case chia sẻ hành vi chung (ví dụ: “Người dùng” và “Quản trị viên” kế thừa từ “Người dùng hệ thống”).

3. Quy trình vẽ Use Case Diagram chi tiết

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

3.1. Chọn công cụ vẽ

• Công cụ miễn phí: Draw.io, Lucidchart (phiên bản miễn phí), Visual Paradigm Community.
• Công cụ trả phí: Microsoft Visio, Enterprise Architect, StarUML.

3.2. Tạo System Boundary

1. Vẽ một hình chữ nhật lớn, đặt tên hệ thống (ví dụ: “Hệ thống Quản lý Đặt phòng khách sạn”).
2. Đặt tiêu đề ở phía trên hoặc trong khung để rõ ràng.

3.3. Thêm các Actor

1. Đặt các actor bên ngoài khung, sắp xếp hợp lý để giảm đường nối giao nhau.
2. Ghi rõ tên actor (Customer, Receptionist, Payment Gateway).

3.4. Vẽ các Use Case

1. Bên trong System Boundary, vẽ các hình bầu dục cho từng use case.
2. Đặt tên ngắn gọn, mô tả hành động (ví dụ: “Đặt phòng”, “Thanh toán”, “Hủy đặt phòng”).

3.5. Kết nối Actor – Use Case (Association)

• Vẽ đường thẳng từ actor tới use case.
• Nếu một actor có nhiều use case, có thể nhóm lại bằng một “package” hoặc “package diagram” để tránh lộn xộn.

3.6. Thêm mối quan hệ Include / Extend

Có thể bạn quan tâm: Cách Vẽ Thỏ Đơn Giản: Hướng Dẫn Từng Bước Dành Cho Người Mới Bắt Đầu

• Include: Vẽ mũi tên có ký hiệu «include» từ use case phụ (được bao gồm) tới use case chính.
• Extend: Vẽ mũi tên có ký hiệu «extend» từ use case mở rộng tới use case gốc, kèm ghi chú điều kiện (ví dụ: nếu có mã giảm giá).

3.7. Áp dụng Generalization (Kế thừa)

• Đối với actor: Vẽ một đường thẳng có mũi tên rỗng từ actor con tới actor cha.
• Đối với use case: Tương tự, dùng để chỉ các use case con kế thừa hành vi chung.

3.8. Kiểm tra và tinh chỉnh

• Độ rõ ràng: Đảm bảo các tên không quá dài, không có lỗi chính tả.
• Số lượng đường nối: Tránh các đường cắt nhau quá nhiều, có thể dùng “routing” để chuyển hướng.
• Đánh giá tính đầy đủ: Kiểm tra lại danh sách yêu cầu, chắc chắn mọi yêu cầu đã được ánh xạ.

4. Ví dụ thực tế: Vẽ Use Case Diagram cho một ứng dụng đặt vé máy bay

4.1. Xác định Actor

Actor	Mô tả
Passenger	Người dùng cuối đặt và quản lý vé.
Admin	Quản trị hệ thống, quản lý chuyến bay, giá vé.
Payment Gateway	Hệ thống thanh toán bên ngoài.
Airline System	Hệ thống của hãng hàng không cung cấp dữ liệu chuyến bay.
Email Service	Dịch vụ gửi email xác nhận.

4.2. Xác định Use Case

Có thể bạn quan tâm: Cách Vẽ Tem Bưu Chính: Hướng Dẫn Chi Tiết Cho Người Mới Bắt Đầu

Use Case	Mô tả
Tìm chuyến bay	Passenger nhập điểm đi, điểm đến, ngày, tìm các chuyến bay phù hợp.
Đặt vé	Passenger chọn chuyến, nhập thông tin hành khách, tiến hành thanh toán.
Thanh toán	Gửi yêu cầu tới Payment Gateway, nhận kết quả.
Xác nhận đặt vé	Gửi email xác nhận, lưu thông tin vào hệ thống.
Hủy vé	Passenger yêu cầu hủy, hệ thống trả lại tiền (nếu đủ điều kiện).
Quản lý chuyến bay	Admin tạo, sửa, xóa chuyến bay.
Quản lý giá vé	Admin thiết lập giá, khuyến mãi.
Kiểm tra lịch sử đặt vé	Passenger xem danh sách các vé đã đặt.
Gửi thông báo	Hệ thống gửi email/sms khi có thay đổi.

4.3. Mối quan hệ

• Include: “Đặt vé” include “Thanh toán”.
• Include: “Đặt vé” include “Xác nhận đặt vé”.
• Extend: “Hủy vé” extend “Thanh toán” khi vé đã được thanh toán.
• Generalization: “Passenger” và “Admin” generalize từ “User”.

4.4. Vẽ biểu đồ (Mô tả bằng lời)

1. Vẽ System Boundary: “Hệ thống Đặt vé Máy bay”.
2. Bên ngoài khung, đặt các actor: Passenger (trái), Admin (trái trên), Payment Gateway (phải), Airline System (phải dưới), Email Service (điểm dưới).
3. Bên trong khung, vẽ các use case: “Tìm chuyến bay”, “Đặt vé”, “Thanh toán”, “Xác nhận đặt vé”, “Hủy vé”, “Quản lý chuyến bay”, “Quản lý giá vé”, “Kiểm tra lịch sử đặt vé”, “Gửi thông báo”.
4. Kết nối:
5. Passenger ↔ “Tìm chuyến bay”, “Đặt vé”, “Hủy vé”, “Kiểm tra lịch sử đặt vé”.
6. Admin ↔ “Quản lý chuyến bay”, “Quản lý giá vé”.
7. Payment Gateway ↔ “Thanh toán”.
8. Email Service ↔ “Xác nhận đặt vé”, “Gửi thông báo”.
9. Airline System ↔ “Tìm chuyến bay”, “Quản lý chuyến bay”.
10. Thêm mũi tên include và extend như đã mô tả.

5. Các lỗi thường gặp khi vẽ Use Case Diagram và cách khắc phục

Lỗi	Mô tả	Cách khắc phục
Quá nhiều chi tiết	Đưa quá nhiều thông tin vào use case (ví dụ: mô tả chi tiết giao diện).	Giữ use case ở mức chức năng, chi tiết hơn sẽ nằm ở Use Case Specification hoặc Sequence Diagram.
Nhầm lẫn actor và system	Vẽ hệ thống như một actor hoặc ngược lại.	Actor luôn nằm ngoài System Boundary; hệ thống luôn được bọc trong khung.
Thiếu mối quan hệ include/extend	Không sử dụng include/extend khi cần, dẫn tới lặp lại.	Xác định các hành động chung (include) và các hành động tùy chọn (extend).
Tên use case không rõ ràng	Dùng từ ngữ mơ hồ hoặc quá dài.	Sử dụng động từ ở dạng nguyên mẫu, ngắn gọn: “Đặt vé”, “Xác nhận thanh toán”.
Đường nối rối rắm	Nhiều đường thẳng cắt nhau, làm biểu đồ khó đọc.	Sắp xếp lại vị trí actor và use case, dùng routing (điểm gập) để tránh giao cắt.
Không phản ánh yêu cầu	Một số yêu cầu quan trọng không có trong diagram.	Kiểm tra lại tài liệu yêu cầu, thực hiện walkthrough với stakeholder.

6. Kỹ thuật mở rộng: Từ Use Case Diagram tới tài liệu chi tiết

Sau khi hoàn thành Use Case Diagram, các nhà phân tích thường tạo Use Case Specification cho mỗi use case. Nội dung thường bao gồm:

1. Tên use case
2. Mô tả ngắn
3. Actor chính
4. Preconditions (điều kiện tiên quyết)
5. Postconditions (kết quả)
6. Basic Flow (luồng chính)
7. Alternative Flows (luồng thay thế)
8. Exception Flows (luồng ngoại lệ)
9. Business Rules
10. Related Requirements

Việc này giúp các nhà phát triển, tester, và QA có một tài liệu chuẩn để thực hiện thiết kế và kiểm thử.

7. Thực hành: Bước tiếp theo sau khi vẽ Use Case Diagram

1. Review với stakeholder: Trình bày diagram, nhận phản hồi, chỉnh sửa.
2. Xây dựng Sequence Diagram cho các use case quan trọng (ví dụ: “Đặt vé”).
3. Tạo Class Diagram dựa trên các đối tượng xuất hiện trong các flow.
4. Viết test case dựa trên Basic Flow và Alternative Flows.
5. Cập nhật backlog: Mỗi use case có thể tương ứng với một user story trong Scrum.

8. Tổng kết

Use Case Diagram không chỉ là một hình ảnh đẹp trong tài liệu thiết kế mà còn là một công cụ giao tiếp mạnh mẽ, giúp mọi người cùng hiểu và thống nhất về chức năng của hệ thống. Việc làm đúng quy trình chuẩn – từ thu thập yêu cầu, xác định actor, xác định use case, vẽ diagram, kiểm tra lỗi, tới mở rộng thành tài liệu chi tiết – sẽ giảm thiểu rủi ro dự án, tăng tốc độ phát triển và đảm bảo chất lượng phần mềm.

Hãy áp dụng các bước và mẹo trên vào dự án thực tế của bạn, và bạn sẽ thấy việc tạo ra một Use Case Diagram chuẩn, rõ ràng và hữu ích là một việc không còn quá khó khăn nữa. Chúc bạn thành công!