Vẽ use case trong trường hợp này sao cho đúng?

[tonghoangvu (Vu Tong)]

Mình có vẽ thử use case diagram cho app Pomodoro như sau, và mình đang bị vướng chỗ quản lý timer (tô màu đỏ).

Yêu cầu là cho phép user tạo ra các timer (giống như từng mục báo thức), mỗi timer có thể bật tắt được. Và khi tới một khoảng thời gian đặt sẵn, thì các timer bật sẽ gửi 1 notification cho user.

Ở đây mình bị vướng chỗ có use case G4 là gửi notification. Mình không biết nên thể hiện nó ra như thế nào (vẽ như hình mình thấy không ổn lắm).

Ngoài ra mình cũng muốn nhận thêm các ý kiến đóng góp về những chỗ khác chưa ổn nữa. Mình cảm ơn.

[library (La biblioteca)]

“Trigger notification” có cảm giác như là tính năng tự hệ thống kích hoạt. Về lý thuyết, tính năng kiểu này không nhất thiết phải vẽ vào UCD.
Cơ mà cậu có thể đổi tên nó thành “Request for notification sending”, vì thực tế cậu gửi request này tới notification push service và để nó gửi, hơn là cậu tự gửi. Tên này chủ động hơn, và cậu có thể include use case này vào các usecase liên quan.

---

Có một số điểm nhỏ ở UCD này tớ muốn góp ý:

• Tớ có thấy cậu dùng mũi tên “kế thừa” khi kết nối các use cases. Tớ đoán cậu không có ý đó, nhưng sẽ tốt hơn nếu cậu không dùng mũi tên đó.
• Một vài usecase có lẽ nên là package hơn. Ví dụ: manage pomo, manage timer…

Hope it helps!

[tonghoangvu (Vu Tong)]

Mình đã dùng package để gom nhóm các use case quản lý pomo & timer.

Use case “Trigger notification” mình đã quyết định bỏ nó đi. Nếu đổi tên và để trong package “manage timer” thì không đúng lắm, do user không trực tiếp kích hoạt use case này được.

@library

Tớ có thấy cậu dùng mũi tên “kế thừa” khi kết nối các use cases. Tớ đoán cậu không có ý đó, nhưng sẽ tốt hơn nếu cậu không dùng mũi tên đó.

Điểm này mình chưa rõ, tại sao lại không nên sử dụng mũi tên kế thừa? Cậu có thể làm rõ điểm này không?

[library (La biblioteca)]

Điểm này mình chưa rõ, tại sao lại không nên sử dụng mũi tên kế thừa?

Uhm, ở UCD đầu tiên của cậu, cậu có dùng mũi tên kế thừa ở nhóm H, G, E. Tớ đã nghĩ nó không hợp lý, vì mấy chức năng ở các nhóm đó không có quan hệ kế thừa lẫn nhau (usecase có quan hệ kế thừa).
Cậu có thể đọc thêm về use case generalization ở đây:

Generalization and Use Case Models, Part 2 - Business Analyst Articles,...

Ở UCD mới của cậu, nhóm E vẫn còn mũi tên kế thừa cho dù về mặt ngữ nghĩa thì không. Có nhóm A là hợp lý về mặt ngữ nghĩa, khi 2 use case gửi 2 loại email khác nhau kế thừa từ use case A1.

Hope it helps!

[tonghoangvu (Vu Tong)]

À mình hiểu rồi, cảm ơn bạn nhiều nhé.