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

1. Giới thiệu chung về Use Case Model

Use case model (mô hình trường hợp sử dụng) là một trong những công cụ quan trọng nhất trong phân tích và thiết kế phần mềm, đặc biệt trong môi trường phát triển hướng đối tượng. Nó giúp các nhà phân tích, kiến trúc sư và lập trình viên hiểu rõ các yêu cầu chức năng của hệ thống, mô tả cách mà người dùng (hoặc các hệ thống khác) tương tác với phần mềm để đạt được mục tiêu cụ thể.

Use case model không chỉ là một biểu đồ đơn thuần; nó còn bao gồm một tập hợp các tài liệu mô tả chi tiết, bao gồm:

• Use case diagram (biểu đồ trường hợp sử dụng): hình ảnh trực quan mô tả các tác nhân (actors) và các use case (trường hợp sử dụng) liên quan.
• Use case description (mô tả chi tiết): văn bản mô tả luồng sự kiện, điều kiện tiền đề, điều kiện hậu quả, các luồng phụ, và các ràng buộc.

Khi được vẽ đúng cách, use case model giúp:

1. Xác định phạm vi dự án – Biết rõ những gì hệ thống phải làm và không phải làm.
2. Giao tiếp hiệu quả giữa các bên liên quan – Người dùng, nhà quản lý, và đội phát triển có một ngôn ngữ chung.
3. Hỗ trợ thiết kế kiến trúc – Các use case thường là nguồn gốc cho việc xác định các lớp, dịch vụ và giao diện.
4. Lập kế hoạch kiểm thử – Mỗi use case có thể trở thành một test case.

Trong bài viết này, chúng ta sẽ đi sâu vào quy trình vẽ use case model, từ việc chuẩn bị, xác định các thành phần, lựa chọn công cụ, tới các kỹ thuật nâng cao để tối ưu hoá mô hình.

2. Bước chuẩn bị: Thu thập và phân tích yêu cầu

2.1. Hiểu rõ mục tiêu kinh doanh

Trước khi bắt tay vào vẽ, bạn cần nắm bắt mục tiêu kinh doanh của dự án. Hãy trả lời các câu hỏi:

• Hệ thống này giải quyết vấn đề gì?
• Khách hàng/ người dùng cuối mong muốn đạt được gì?
• Các chỉ tiêu thành công (KPIs) là gì?

Việc có một bức tranh tổng thể giúp bạn tránh việc “vẽ quá” hoặc “vẽ thiếu” các chức năng quan trọng.

2.2. Thu thập yêu cầu từ các stakeholder

Sử dụng các kỹ thuật như:

• Interview (phỏng vấn): Đối thoại trực tiếp với người dùng, quản lý, chuyên gia domain.
• Questionnaire (bảng hỏi): Thu thập thông tin nhanh từ nhóm lớn.
• Observation (quan sát): Theo dõi quy trình hiện tại để phát hiện nhu cầu tiềm ẩn.
• Document analysis (phân tích tài liệu): Xem các tài liệu hiện có như quy trình SOP, báo cáo.

Kết quả là một danh sách các yêu cầu chức năng, phi chức năng và các ràng buộc.

2.3. Xác định các actor (tác nhân)

Actor là bất kỳ thực thể nào (người, hệ thống, thiết bị) tương tác với hệ thống. Để xác định actor:

1. Liệt kê tất cả các thực thể tương tác.
2. Phân loại: Human actor (người), External system (hệ thống bên ngoài), Hardware device (thiết bị).
3. Kiểm tra tính độc lập: Nếu hai thực thể có cùng hành vi và vai trò, chúng có thể hợp nhất thành một actor chung.

Ví dụ trong một hệ thống bán hàng trực tuyến:
– Customer (Khách hàng) – người mua hàng.
– Admin (Quản trị viên) – người quản lý nội dung, đơn hàng.
– Payment Gateway (Cổng thanh toán) – hệ thống bên ngoài xử lý giao dịch.

Có thể bạn quan tâm: Cách Vẽ Unicorn Dễ Thương: Hướng Dẫn Từng Bước Để Tạo Nên Những Bức Tranh Lung Linh Và Đầy Sắc Màu

2.4. Xác định các use case (trường hợp sử dụng)

Use case mô tả một mục tiêu hoàn chỉnh mà actor muốn đạt được. Các tiêu chí để xác định một use case:

• Mục tiêu rõ ràng: Ví dụ “Mua hàng”, “Đăng ký tài khoản”.
• Có giá trị cho actor: Nếu actor không quan tâm tới kết quả, thì không cần một use case.
• Có tính độc lập: Mỗi use case nên có thể thực hiện riêng rẽ, không phụ thuộc vào các use case khác (trừ khi có mối quan hệ extend/include).

Kỹ thuật brainstorming thường được dùng: viết ra mọi hành động mà actor thực hiện, sau đó nhóm lại thành các use case hợp lý.

3. Cấu trúc một use case description

Mỗi use case nên có một mô tả chi tiết, thường bao gồm các phần sau:

Thành phần	Mô tả
Tên use case	Đặt tên ngắn gọn, mô tả hành động (verb + object), ví dụ “Đặt hàng”.
Mô tả ngắn	Một đoạn văn tóm tắt mục tiêu và giá trị.
Actor chính	Actor thực hiện chính.
Actor phụ	Các actor khác tham gia (nếu có).
Preconditions (điều kiện tiền đề)	Các điều kiện phải thỏa mãn trước khi bắt đầu.
Postconditions (điều kiện hậu quả)	Trạng thái hệ thống sau khi use case hoàn thành (có thể thành công hoặc thất bại).
Luồng sự kiện chính (Basic flow)	Các bước thực hiện tuần tự khi mọi thứ diễn ra bình thường.
Luồng phụ (Alternative/Exception flows)	Các trường hợp ngoại lệ, lỗi, hoặc tùy chọn.
Ràng buộc	Các quy tắc nghiệp vụ, bảo mật, hiệu năng liên quan.
Tần suất sử dụng	Đánh giá mức độ thường xuyên (high, medium, low).
Mức độ ưu tiên	Critical, High, Medium, Low.
Ghi chú	Thông tin bổ sung, liên kết tới tài liệu khác.

Việc chuẩn bị mô tả chi tiết này trước khi vẽ biểu đồ giúp bạn có một nền tảng vững chắc, tránh việc vẽ biểu đồ mơ hồ.

4. Vẽ Use Case Diagram – Các bước thực hiện

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

Có rất nhiều công cụ hỗ trợ, từ miễn phí tới trả phí:

• Microsoft Visio – mạnh mẽ, tích hợp Office.
• Lucidchart – trực tuyến, cộng tác nhóm.
• draw.io (diagrams.net) – miễn phí, dễ dùng.
• StarUML, Visual Paradigm – chuyên cho UML, hỗ trợ nhiều loại diagram.

Chọn công cụ phù hợp với quy mô dự án và thói quen làm việc của đội ngũ.

4.2. Xác định phạm vi biểu đồ

Không nên vẽ một biểu đồ quá lớn, khó đọc. Thông thường, một hệ thống lớn sẽ có các package (gói) con, mỗi package chứa một nhóm use case liên quan. Ví dụ:

• Package “Quản lý người dùng” – bao gồm Register, Login, Forgot Password.
• Package “Quản lý đơn hàng” – bao gồm Create Order, Cancel Order, Track Order.

4.3. Đặt các thành phần cơ bản

1. Actor: Vẽ hình người (stick figure) hoặc biểu tượng tương tự, đặt tên bên cạnh.
2. Use case: Vẽ hình elip, đặt tên ở giữa.
3. Mối quan hệ:
4. Association (liên kết): Đường thẳng đơn, nối actor với use case.
5. Include: Đường thẳng có mũi tên nhọn, gạch đứt, ghi “<>”. Dùng khi một use case luôn bao gồm một hành động chung (ví dụ “Xác thực người dùng” được include trong “Login” và “Register”).
6. Extend: Đường thẳng có mũi tên nhọn, gạch đứt, ghi “<>”. Dùng cho luồng phụ (ví dụ “Áp dụng mã giảm giá” mở rộng “Thanh toán”).
7. Generalization (kế thừa): Đường thẳng có tam giác rỗng, thể hiện quan hệ cha-con (ví dụ “Quản trị viên” kế thừa “Người dùng”).

4.4. Sắp xếp bố cục

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

• Đặt các actor ở phía bên trái hoặc bên phải, tùy thuộc vào hướng luồng.
• Use case nằm ở trung tâm, nhóm theo chức năng.
• Tránh giao nhau các đường liên kết; nếu cần, sử dụng routing (điểm gập) để làm sạch biểu đồ.

4.5. Kiểm tra tính toàn vẹn

• Mỗi actor phải có ít nhất một liên kết – tránh actor “lẻ”.
• Mỗi use case phải có ít nhất một actor – nếu không, có thể là một hệ thống nội bộ, nên xem xét tạo actor “System”.
• Không có vòng lặp vô nghĩa – các mối quan hệ include/extend phải có hướng rõ ràng, không tạo ra vòng lặp.

5. Kỹ thuật nâng cao trong vẽ Use Case Model

5.1. Sử dụng Packages để quản lý độ phức tạp

Khi hệ thống có hơn 20 use case, việc chia thành các package là cần thiết. Các package có thể được đặt tên theo module, domain, hoặc layer (presentation, business, data). Việc này giúp:

• Độc lập các nhóm làm việc trên các phần riêng biệt.
• Dễ dàng mở rộng hoặc thay đổi một phần mà không ảnh hưởng đến toàn bộ mô hình.

5.2. Áp dụng “System Boundary”

Vẽ một hình chữ nhật bao quanh tất cả các use case, đặt tên hệ thống (ví dụ “Online Shopping System”). Điều này giúp người xem nhanh chóng nhận biết đâu là phạm vi hệ thống và đâu là môi trường bên ngoài.

5.3. Mô tả các luồng phụ bằng “extend” chi tiết

Khi một luồng phụ có nhiều điều kiện, bạn có thể tạo multiple extend relationships từ cùng một use case tới các use case phụ. Ví dụ:

• “Thanh toán” <> “Kiểm tra hạn mức” (nếu vượt mức).
• “Thanh toán” <> “Xác nhận OTP” (nếu bật xác thực 2FA).

Mỗi extend nên có guard condition (điều kiện) được ghi trong dấu ngoặc vuông trên mũi tên, ví dụ: hạn mức > 10.000.

5.4. Sử dụng “actor system” cho các hệ thống tự động

Nếu hệ thống tương tác với các API, dịch vụ web, hoặc các thiết bị IoT, bạn có thể tạo actor đặc biệt gọi là System Actor hoặc External System. Điều này giúp phân biệt rõ ràng giữa người dùng và các thành phần tự động.

5.5. Mối quan hệ “Generalization” giữa các use case

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

Trong một số trường hợp, một use case có thể là phiên bản tổng quát của các use case con. Ví dụ:

• Manage Account (quản lý tài khoản) có các con: “Create Account”, “Update Account”, “Delete Account”.

Sử dụng mũi tên tam giác để biểu thị quan hệ này giúp giảm số lượng elip trên diagram, đồng thời minh bạch cấu trúc nghiệp vụ.

6. Kiểm tra và xác nhận Use Case Model

6.1. Review nội bộ

• Team Review: Các nhà phân tích, developer, tester cùng xem lại. Kiểm tra tính đầy đủ, nhất quán, và khả năng thực thi.
• Walkthrough: Mỗi thành viên mô tả lại một use case, kiểm tra xem có hiểu đúng không.

6.2. Review với stakeholder

• Presentation: Trình bày diagram và mô tả chi tiết cho khách hàng hoặc người dùng cuối.
• Feedback Loop: Ghi nhận các yêu cầu thay đổi, bổ sung hoặc loại bỏ.

6.3. Kiểm tra tính khả thi kỹ thuật

• Đối chiếu các use case với kiến trúc hiện có (các lớp, API).
• Xác định các rủi ro: ví dụ, một use case yêu cầu giao dịch đồng thời trên nhiều dịch vụ có thể gây vấn đề về đồng bộ.

7. Từ Use Case Model tới các artefact khác

7.1. Chuyển đổi thành User Stories

Trong môi trường Agile, mỗi use case thường được chia thành một hoặc nhiều user story. Ví dụ:

• Use case “Đăng ký tài khoản” →
• “Là người dùng, tôi muốn nhập email và mật khẩu để tạo tài khoản.”
• “Là người dùng, tôi muốn nhận email xác nhận để kích hoạt tài khoản.”

7.2. Tạo Test Cases

Mỗi luồng chính và luồng phụ của use case trở thành một test case. Điều này giúp đảm bảo rằng mọi kịch bản được kiểm thử đầy đủ.

7.3. Hỗ trợ Class Diagram

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

Các actor và các hành động trong use case thường gợi ý các lớp và phương thức cần thiết. Ví dụ, use case “Thanh toán” sẽ yêu cầu lớp PaymentProcessor, Invoice, v.v.

8. Những lỗi thường gặp khi vẽ Use Case Model và cách tránh

Lỗi	Mô tả	Cách khắc phục
Quá chi tiết	Vẽ quá nhiều các bước trong use case, biến elip thành flowchart.	Giữ use case ở mức mục tiêu, chi tiết trong mô tả văn bản.
Rối rắm các mối quan hệ	Nhiều include/extend lẫn lộn, gây khó hiểu.	Sử dụng guard condition, chỉ dùng extend cho luồng phụ thực sự.
Thiếu actor	Không xác định đầy đủ các tác nhân, dẫn đến thiếu yêu cầu.	Thực hiện checklist actor: người, hệ thống, thiết bị.
Không có System Boundary	Người xem không biết đâu là hệ thống.	Luôn vẽ một khung bao quanh các use case, đặt tên hệ thống.
Không cập nhật	Khi yêu cầu thay đổi, diagram không được sửa.	Thiết lập quy trình review định kỳ, lưu phiên bản.

9. Thực hành: Ví dụ thực tế – Hệ thống Quản lý Thư viện

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

• Người dùng muốn tìm kiếm sách, đặt mượn, đăng ký thẻ.
• Thủ thư muốn quản lý danh mục, xác nhận trả sách, tạo báo cáo.
• Hệ thống bên ngoài (ISBN API) cung cấp thông tin sách.

9.2. Xác định actor

Actor	Mô tả
Member	Thành viên thư viện (người dùng).
Librarian	Thủ thư, quản trị nội bộ.
ISBN Service	Hệ thống cung cấp dữ liệu sách.
System	Hệ thống thư viện (được dùng làm actor cho các tác vụ nội bộ).

9.3. Xác định use case

Use case	Actor chính	Mô tả ngắn
Search Book	Member	Tìm kiếm sách theo tiêu đề, tác giả, ISBN.
Borrow Book	Member	Đặt mượn sách, nhận thông báo.
Return Book	Member	Trả sách, cập nhật trạng thái.
Register Member	Member	Đăng ký thẻ thành viên mới.
Manage Catalog	Librarian	Thêm, sửa, xóa thông tin sách.
Validate ISBN	System	Gọi ISBN Service để xác thực thông tin.
Generate Report	Librarian	Tạo báo cáo thống kê mượn trả.

9.4. Vẽ diagram

1. System Boundary: “Library Management System”.
2. Actors đặt ở hai bên: Member (trái), Librarian (phải), ISBN Service (điểm ngoài).
3. Use case nhóm thành hai package: “Member Services” và “Administrative Services”.
4. Include: “Borrow Book” <> “Validate Membership”.
5. Extend: “Borrow Book” <> “Apply Discount” member có thẻ ưu đãi.
6. Generalization: “Member” và “Librarian” kế thừa “User”.

Kết quả là một biểu đồ sạch sẽ, dễ đọc, phản ánh đầy đủ các chức năng chính.

10. Kết luận

Việc vẽ Use Case Model không chỉ là một bước trong quy trình phát triển phần mềm; nó là nền tảng để xây dựng một hệ thống bền vững, đáp ứng đúng nhu cầu người dùng và dễ dàng bảo trì, mở rộng. Bằng cách tuân thủ quy trình chuẩn – từ thu thập yêu cầu, xác định actor và use case, chuẩn bị mô tả chi tiết, tới vẽ diagram hợp lý và kiểm tra lại – bạn sẽ tạo ra một mô hình chất lượng, hỗ trợ hiệu quả cho các giai đoạn tiếp theo như thiết kế, lập trình và kiểm thử.

Những điểm cần nhớ

1. Luôn bắt đầu từ mục tiêu kinh doanh, không để kỹ thuật chi phối.
2. Actor và use case phải độc lập, có giá trị rõ ràng.
3. Biểu đồ phải đơn giản, dùng packages và system boundary để kiểm soát độ phức tạp.
4. Mô tả chi tiết là không thể thiếu; nó là cầu nối giữa diagram và các artefact khác.
5. Kiểm tra, review và cập nhật liên tục để mô hình luôn đồng nhất với thực tế dự án.

Hy vọng rằng qua bài viết này, bạn đã nắm vững cách vẽ use case model một cách toàn diện, từ cơ bản đến nâng cao, và sẵn sàng áp dụng vào dự án thực tế của mình. Chúc bạn thành công!