Use Case (trường hợp sử dụng) là một trong những công cụ quan trọng nhất trong việc phân tích và thiết kế hệ thống phần mềm. Nó mô tả cách mà người dùng (hoặc các hệ thống khác) tương tác với hệ thống để đạt được một mục tiêu cụ thể. Khi kết hợp với UML (Unified Modeling Language), Use Case trở thành một phần của bộ ngôn ngữ tiêu chuẩn quốc tế, giúp các nhà phân tích, kiến trúc sư và lập trình viên giao tiếp một cách rõ ràng, nhất quán.
1.1. Tầm quan trọng của Use Case trong dự án phần mềm
Giao tiếp: Use Case là “ngôn ngữ chung” giữa các bên liên quan (business, khách hàng, developer).
Xác định yêu cầu: Thông qua việc mô tả các kịch bản thực tế, chúng ta có thể khám phá và ghi lại các yêu cầu chức năng một cách chi tiết.
Kiểm thử: Các kịch bản Use Case dễ dàng chuyển đổi thành test case, giúp kiểm tra tính đúng đắn của hệ thống.
Quản lý thay đổi: Khi yêu cầu thay đổi, ta chỉ cần cập nhật các Use Case liên quan mà không cần thay đổi toàn bộ mô hình.
1.2. UML là gì?
UML là một ngôn ngữ mô hình hóa đồ họa được tiêu chuẩn hoá bởi Object Management Group (OMG). UML bao gồm nhiều loại diagram, trong đó Use Case Diagram là loại dùng để mô tả các Use Case và mối quan hệ giữa chúng, cũng như các actor (đối tượng bên ngoài) tương tác với hệ thống.
Trước khi bắt đầu vẽ, chúng ta cần nắm rõ các ký hiệu và thành phần chính:
Thành phần
Ký hiệu
Mô tả
Actor
Stick figure (hình người)
Đối tượng bên ngoài (người dùng, hệ thống khác) tương tác với hệ thống.
Use Case
Oval (hình bầu dục)
Mô tả một chức năng hoặc dịch vụ mà hệ thống cung cấp.
System Boundary
Hình chữ nhật
Bao quanh các Use Case, xác định phạm vi hệ thống.
Association
Đường thẳng
Kết nối Actor và Use Case, biểu thị mối quan hệ “giao tiếp”.
Include
Đường mũi tên có nhãn <>
Một Use Case luôn được thực hiện như một phần của Use Case khác.
Extend
Đường mũi tên có nhãn <>
Một Use Case có thể được thực hiện trong một số tình huống đặc biệt, mở rộng Use Case gốc.
Generalization
Đường mũi tên rỗng
Thể hiện quan hệ kế thừa giữa các Actor hoặc Use Case.
3. Quy trình chuẩn để vẽ Use Case UML
3.1. Bước 1: Thu thập và phân loại yêu cầu
Phỏng vấn stakeholders: Gặp gỡ khách hàng, người dùng cuối, quản lý dự án để hiểu nhu cầu thực tế.
Phân tích tài liệu: Đọc các tài liệu yêu cầu, hợp đồng, quy trình kinh doanh hiện tại.
Xác định các actor: Liệt kê tất cả các đối tượng bên ngoài sẽ tương tác với hệ thống (người dùng, thiết bị, hệ thống khác).
Xác định các mục tiêu: Mỗi actor thường có một hoặc nhiều mục tiêu (đăng nhập, đặt hàng, tạo báo cáo).
Mẹo: Sử dụng kỹ thuật “5 Whys” để đi sâu vào nguyên nhân và xác định chính xác chức năng cần thiết.
3.2. Bước 2: Viết mô tả Use Case chi tiết
Mỗi Use Case nên có một Use Case Specification gồm các phần sau:
Phần
Nội dung
Tên Use Case
Đặt tên ngắn gọn, mô tả hành động (VD: “Đăng nhập hệ thống”).
Mô tả ngắn
Một đoạn văn ngắn tóm tắt mục tiêu.
Actor chính
Ai là người thực hiện?
Precondition
Điều kiện phải thỏa mãn trước khi bắt đầu.
Basic Flow (Main Success Scenario)
Các bước thực hiện thành công.
Alternative Flow
Các kịch bản thay thế hoặc lỗi.
Postcondition
Trạng thái hệ thống sau khi Use Case kết thúc.
Extension Points
Các điểm có thể mở rộng (để dùng với <>).
Related Use Cases
Liên kết include/extend.
3.3. Bước 3: Xây dựng sơ đồ sơ khai (Draft)
Vẽ System Boundary: Đặt tên hệ thống (VD: “Hệ thống Quản lý Đặt vé”).
Thêm Actor: Đặt các stick figure bên ngoài, gán tên (VD: “Khách hàng”, “Nhân viên bán vé”).
Thêm Use Case: Vẽ các oval bên trong boundary, gán tên tương ứng.
Kết nối Association: Vẽ đường thẳng từ Actor tới Use Case.
Lưu ý: Ở giai đoạn này không cần quan tâm tới include/extend; tập trung vào việc thể hiện toàn bộ chức năng chính.
Cách Vẽ Use Case Uml
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
3.4. Bước 4: Phân tích mối quan hệ Include và Extend
Include: Dùng khi một phần chức năng luôn xuất hiện trong một hoặc nhiều Use Case. Ví dụ, “Xác thực người dùng” thường được include trong “Đăng nhập”, “Thay đổi mật khẩu”.
Extend: Dùng khi một chức năng chỉ xuất hiện trong một số trường hợp đặc biệt, thường là lỗi hoặc tùy chọn mở rộng. Ví dụ, “Gửi mã OTP” có thể extend “Đăng nhập” nếu hệ thống yêu cầu xác thực hai yếu tố.
Cách xác định:
1. Đánh dấu các bước lặp lại trong các Use Case khác nhau → có khả năng là Include.
2. Xác định các hành động phụ trợ, không bắt buộc → có khả năng là Extend.
Sau khi xác định, vẽ các mũi tên <> hoặc <> từ Use Case phụ tới Use Case chính, kèm theo label và đặt “extension point” nếu cần.
3.5. Bước 5: Kiểm tra tính nhất quán và hoàn thiện
Kiểm tra tính bao phủ: Mỗi yêu cầu chức năng đã được mô tả trong ít nhất một Use Case chưa?
Kiểm tra mối quan hệ: Không có vòng lặp vô hạn giữa các Use Case (ví dụ A include B và B include A).
Đánh giá độ rõ ràng: Các tên Use Case và Actor có ngắn gọn, dễ hiểu không?
Xác nhận với stakeholder: Trình bày sơ đồ cho người dùng cuối hoặc khách hàng để xác nhận.
Giao diện hiện đại, hỗ trợ nhiều loại diagram, export SVG/PDF
99 USD (một lần)
Windows, macOS, Linux
Visual Paradigm
Tích hợp đầy đủ UML, BPMN, hỗ trợ teamwork
Free (Community) / 12 USD/tháng (Professional)
Windows, macOS, Linux
Draw.io (diagrams.net)
Miễn phí, web-based, tích hợp Google Drive
Free
Web
Enterprise Architect
Công cụ mạnh cho kiến trúc doanh nghiệp, hỗ trợ yêu cầu traceability
229 USD
Windows
PlantUML
Viết mã text để sinh diagram, tích hợp CI/CD
Free
Cross-platform
Lưu ý: Khi làm việc nhóm, nên chọn công cụ có tính năng version control và collaborative editing (VD: Visual Paradigm, Draw.io).
5. Thực hành: Ví dụ chi tiết vẽ Use Case cho “Hệ thống Đặt vé máy bay”
5.1. Bước 1: Xác định Actor
Actor
Vai trò
Khách hàng
Đặt vé, thanh toán, hủy vé.
Nhân viên hỗ trợ
Xử lý yêu cầu hủy, thay đổi.
Hệ thống thanh toán
Xác nhận giao dịch.
Hệ thống hãng hàng không
Cung cấp lịch chuyến bay, xác nhận đặt chỗ.
5.2. Bước 2: Viết Use Case Specification (một ví dụ)
Tên Use Case: Đặt vé máy bay Mô tả ngắn: Khách hàng tìm kiếm chuyến bay, chọn ghế và thanh toán để hoàn tất đặt vé. Actor chính: Khách hàng Precondition: Khách hàng đã đăng nhập vào hệ thống. Basic Flow:
1. Khách hàng nhập điểm xuất phát, điểm đến, ngày bay.
2. Hệ thống hiển thị danh sách chuyến bay khả dụng.
3. Khách hàng chọn chuyến bay và loại vé.
4. Hệ thống hiển thị bản đồ chỗ ngồi, khách hàng chọn ghế.
5. Hệ thống tính tổng tiền và chuyển sang trang thanh toán.
6. Khách hàng nhập thông tin thẻ, hệ thống thanh toán xác nhận.
7. Hệ thống tạo mã đặt vé và gửi email xác nhận.
Alternative Flow:
– 4a. Nếu ghế đã được người khác đặt, hệ thống đề xuất ghế khác.
– 6a. Nếu thanh toán thất bại, hiển thị lỗi và cho phép khách hàng thử lại hoặc chọn phương thức khác.
Postcondition: Vé được tạo và lưu trữ, khách hàng nhận email xác nhận.
Extension Points:
– EP1: “Xác thực OTP” (có thể extend nếu giao dịch > $500).
5.3. Bước 3: Vẽ sơ đồ (mô tả bằng text)
+---------------------------------------------------+
| Hệ thống Đặt vé máy bay |
| |
| (Use Cases) |
| +--------------------+ +--------------------+ |
| | Đăng nhập | | Đặt vé máy bay | |
| +--------------------+ +--------------------+ |
| | Xem lịch chuyến | | Thanh toán | |
| +--------------------+ +--------------------+ |
| | Hủy vé | | Gửi email xác nhận | |
| +--------------------+ +--------------------+ |
+---------------------------------------------------+ Khách hàng --------------(association)------------> Đăng nhập
Khách hàng --------------(association)------------> Đặt vé máy bay
Khách hàng --------------(association)------------> Hủy vé
Nhân viên hỗ trợ --------(association)------------> Hủy vé
Hệ thống thanh toán -----(include)---------------> Thanh toán
Đặt vé máy bay -----(extend <<extend>> at EP1)----> Xác thực OTP
5.4. Bước 4: Kiểm tra mối quan hệ
Include: “Thanh toán” được include trong “Đặt vé máy bay” vì mọi lần đặt vé đều cần thanh toán.
Extend: “Xác thực OTP” được extend vào “Đặt vé máy bay” tại Extension Point EP1, chỉ khi giao dịch lớn.
5.5. Bước 5: Hoàn thiện và chia sẻ
Sử dụng StarUML để tạo diagram chuyên nghiệp, export PDF.
Đưa file vào Git để quản lý phiên bản, tạo nhánh cho mỗi thay đổi.
Gửi link cho stakeholder qua Confluence để thu thập phản hồi.
6. Các lỗi thường gặp khi vẽ Use Case và cách khắc phục
Lỗi
Nguyên nhân
Cách khắc phục
Quá nhiều actor
Không phân tách rõ ràng vai trò, tạo ra actor ảo.
Tập trung vào các actor thực sự có hành động trực tiếp với hệ thống.
Use Case quá rộng
Gộp nhiều chức năng vào một Use Case (VD: “Quản lý hệ thống”).
Chia thành các Use Case nhỏ, cụ thể (VD: “Quản lý người dùng”, “Quản lý báo cáo”).
Nhầm lẫn Include/Extend
Không hiểu rõ sự khác biệt, dùng sai.
Nhớ: Include = luôn có, Extend = chỉ có trong trường hợp đặc biệt.
Thiếu pre/postcondition
Không mô tả trạng thái hệ thống, gây khó kiểm thử.
Luôn viết pre/postcondition trong Use Case Specification.
Không đồng bộ với tài liệu yêu cầu
Bản diagram không phản ánh các yêu cầu đã được phê duyệt.
Định kỳ so sánh diagram với Requirement Traceability Matrix (RTM).
Đồ họa lộn xộn
Vẽ quá nhiều đường nối, không sắp xếp hợp lý.
Sử dụng layout tự động của công cụ, nhóm các Use Case liên quan gần nhau.
7. Kỹ thuật nâng cao: Use Case và các loại diagram khác trong UML
Cách Vẽ Use Case Uml
Activity Diagram: Dùng để chi tiết hoá Basic Flow và Alternative Flow của một Use Case.
Sequence Diagram: Mô tả tương tác thời gian giữa Actor và các object trong hệ thống cho một Use Case cụ thể.
Class Diagram: Khi đã có Use Case, ta có thể xác định các lớp (class) cần thiết để thực hiện các chức năng.
State Machine Diagram: Đối với các Use Case có trạng thái phức tạp (VD: “Quản lý đơn hàng” với trạng thái Đặt, Thanh toán, Giao, Hoàn trả).
Chiến lược: Bắt đầu với Use Case Diagram để “có cái nhìn tổng quan”, sau đó mở rộng sang Activity/Sequence để “chi tiết hoá” và cuối cùng tới Class/Component để “thiết kế kỹ thuật”.
8. Thực tiễn áp dụng Use Case trong môi trường Agile
User Story vs Use Case: Trong Scrum, thường dùng User Story (định dạng “As a … I want … so that …”). Tuy nhiên, Use Case vẫn hữu ích để phân tách các story phức tạp thành các kịch bản chi tiết.
Definition of Ready (DoR): Một User Story được coi là Ready khi đã có Use Case Specification kèm theo các pre/postcondition.
Definition of Done (DoD): Khi story được hoàn thành, các test case phải dựa trên Basic Flow và Alternative Flow của Use Case.
9. Tổng kết
Việc vẽ Use Case UML không chỉ là một công việc “đồ họa” mà là một quá trình phân tích, xác định yêu cầu, và thiết kế kiến trúc hệ thống một cách có hệ thống. Bằng cách tuân thủ các bước: thu thập yêu cầu, viết Use Case Specification, vẽ sơ đồ, xác định include/extend và kiểm tra tính nhất quán, chúng ta có thể:
Đảm bảo giao tiếp rõ ràng giữa các bên liên quan.
Tạo nền tảng vững chắc cho kiểm thử và phát triển.
Giảm thiểu rủi ro thiếu sót yêu cầu và lỗi thiết kế.
Hãy áp dụng các nguyên tắc và kỹ thuật đã trình bày trong bài viết này vào dự án thực tế của bạn. Khi thực hành thường xuyên, bạn sẽ trở thành một chuyên gia trong việc mô hình hoá Use Case, từ đó nâng cao chất lượng và tốc độ triển khai phần mềm. Chúc bạn thành công!
