Use Case Diagram
Sơ đồ UML cho thấy hệ thống cho ai làm được những việc gì và ranh giới hệ thống nằm ở đâu. Công cụ chốt phạm vi gọn nhất mà BA có, vẽ được cùng khách trong nửa giờ.
Định nghĩa
Một hình que, một hình oval, một đường kẻ nối. Use case diagram đơn giản tới mức nhiều người coi thường nó, rồi tới lúc ngồi chốt phạm vi với khách lại chẳng có gì để chỉ tay vào. Đây là sơ đồ UML hiếm hoi mà người không làm CNTT vẫn đọc được.
Nó không mô tả luồng xử lý. Nó trả lời đúng một câu: hệ thống cho ai làm được những việc gì, và cái gì nằm ngoài phạm vi.
Gồm những gì
Bốn thành phần, và cái thứ tư mới là cái hay bị bỏ.
Actor là hình que: người hoặc hệ thống bên ngoài có tương tác với hệ thống. Có actor chính, tức người khởi động use case, và actor phụ, tức bên được gọi tới — cổng thanh toán chẳng hạn. Use case là hình oval, mỗi oval một việc mang lại kết quả có giá trị cho actor; tên đặt dạng động từ cộng tân ngữ, "Tạo phiếu nhập kho", đừng đặt "Quản lý kho". Quan hệ thì có association vẽ bằng đường thẳng, <<include>> cho bước con luôn xảy ra, <<extend>> cho phần chỉ chạy khi có điều kiện, và generalization khi actor hoặc use case kế thừa nhau.
Còn cái thứ tư là system boundary, đúng một khung chữ nhật bao quanh. Trong khung là làm, ngoài khung là không làm. Chẳng có gì để vẽ, mà lại là phần đắt nhất cả sơ đồ.
BA có cần tự vẽ không
Có, và đây là một trong số ít sơ đồ UML mà BA nên chủ động vẽ thay vì đợi dev. Lý do đơn giản: nó là công cụ đàm phán phạm vi chứ không phải bản thiết kế kỹ thuật. Vẽ ngay trong buổi workshop, trên draw.io hoặc trên bảng trắng, thường lòi ra hai ba chức năng chưa ai nhắc tới.
Ví dụ thực tế
Buổi trình bày phạm vi, chị kế toán trưởng nhìn sơ đồ đúng hai phút rồi hỏi: kiểm kê định kỳ đâu.
Đúng là thiếu thật. Sơ đồ hôm đó vẽ cho hệ thống quản lý kho của một chuỗi bán lẻ, bốn actor — Nhân viên kho, Quản lý cửa hàng, Kế toán, và hệ thống POS đẩy dữ liệu bán ra sang — với 14 use case trong khung. Thiếu một cái, nhưng thiếu ở giai đoạn còn sửa được: bắt trước lúc estimate, đỡ một CR cỡ 15 man-day.
Ba thứ hay bị gộp làm một
| Use case diagram | Use case specification | User story | |
|---|---|---|---|
| Trả lời câu hỏi | Ai làm được gì | Từng bước diễn ra thế nào | Ai cần gì, để làm gì |
| Độ dài | Một trang sơ đồ | 1–3 trang mỗi use case | 1–2 dòng kèm AC |
| Dùng ở giai đoạn | Chốt phạm vi | Viết FS, bàn giao dev | Lập backlog, chạy sprint |
| Ai đọc chính | Khách, sếp, cả team | Dev, QC | Team scrum |
Lỗi hay gặp
- Vẽ use case ở mức nút bấm: "Nhấn nút Lưu", "Mở màn hình danh sách". Use case phải trọn vẹn một việc.
- Biến nó thành flowchart bằng cách nối mũi tên thứ tự giữa các oval. Sơ đồ này không có trục thời gian.
- Quên actor là hệ thống ngoài. Cổng thanh toán, ERP, dịch vụ SMS đều là actor.
- Rắc
<<extend>>khắp nơi cho có vẻ chuyên nghiệp, trong khi bản chất là include. Vẽ ngược hướng mũi tên cũng hay gặp không kém: include đi từ use case gốc sang use case con, extend đi từ use case phụ ngược về gốc.
Nếu cả dự án chỉ được vẽ một sơ đồ, mình vẫn chọn cái này. Nửa giờ ngồi vẽ, đổi lại là mấy tháng đỡ phải cãi nhau xem cái đó có nằm trong phạm vi hay không.
