Mình chào mọi người ạ. Mình đang cần vẽ 1 use case tổng quát về quản lí sinh viên, mình có vẽ được như ảnh dưới đây, mong mọi người góp ý ạ!
Sơ đồ use case tổng quát về quản lý sinh viên
-
Bạn có thể giải thích tại sao bạn chọn mối quan hệ “extend” cho use-case Điểm, Lịch thi, Học phí, DS môn học đăng ký,… đối với use-case Cập nhật không? Mình có kể ra một vài mối quan hệ trong biểu đồ UML Use-case phía bên dưới, bạn cân nhắc thử xem mối quan hệ nào sẽ phù hợp để đưa vào diagram của bạn.
-
Bên cạnh đó, quản trị viên có sử dụng được các use-case như xem tiến trình đóng học phí của sinh viên, xem điểm, xem thông tin cá nhân… của Sinh viên không?
-
Trong những trường hợp như hệ thống đăng kí tín chỉ bị lỗi, hoặc sinh viên không đăng kí môn học đúng hạn, quản trị viên có quyền sử dụng use-case đăng kí môn học để bổ sung sinh viên vào lớp học được không?
-
Nếu bạn có ý định mở rộng hơn cho hệ thống quản lý sinh viên này, bạn có thể cân nhắc thêm một vài chức năng như là:
- In bản điểm lúc Xem điểm,
- Tạo thống kê hoặc vẽ biểu đồ theo dõi sự tiến bộ qua các năm học của sinh viên,
- Sinh viên xem thông tin cá nhân và có thể tự cập nhật thông tin cá nhân (sđt, email,… trừ ra các phần mà quản trị viên mới được cập nhật),
- Thanh toán học phí khi xem tra cứu học phí,
- Sinh viên tạo và gửi thư góp ý, …
- Ngoài ra, bạn có thể cân nhắc đưa thêm một vài Actor khác vào, như giảng viên với các use case như tạo/cập nhật/huỷ lớp học, quản lý danh sách sinh viên lớp, upload tài liệu dạy học, …
Dưới đây là danh sách các mối quan hệ có thể xuất hiện trong biểu đồ UML use case:
- Hiệp hội (Association): Một mối quan hệ giữa một actor và một use case, thể hiện việc actor tương tác với use case.
- Tổng quát hóa (Generalization): Một mối quan hệ giữa hai use case, thể hiện rằng một use case là một phiên bản cụ thể hơn của một use case khác.
- Bao gồm (Include): Một mối quan hệ giữa hai use case, thể hiện rằng một use case bao gồm hành vi của một use case khác như một phần bắt buộc của hành vi của nó.
- Mở rộng (Extend): Một mối quan hệ giữa hai use case, thể hiện rằng một use case tùy chọn thêm hoặc sửa đổi hành vi của một use case khác dưới các điều kiện nhất định.
- Phụ thuộc (Dependency): Một mối quan hệ giữa hai phần tử trong biểu đồ UML, thể hiện rằng một thay đổi trong một phần tử có thể ảnh hưởng đến phần tử khác.
2 Likes
Một số use case trong sơ đồ không bắt đầu với động từ (verb), ví dụ “học phí”, “lịch thi”,… Đây là lỗi khá quan trọng, cần chú ý trước tiên.
3 Likes
-
Lúc đầu, mình chọn mối quan hệ “extend” cho use-case Điểm, Lịch thi, Học phí, DS môn học đăng ký,… đối với use-case Cập nhật vì mình nghĩ các use-case Điểm, Lịch thi, Học phí, DS môn học đăng ký,… là những chức năng mở rộng đối với use-case Cập nhật, xảy ra khi quản trị viên muốn cập nhật 1 danh mục cụ thể nào đó như điểm, lịch thi,…
Nhưng mình xem lại các quan hệ bạn liệt kê ở dưới, mình nghĩ là dùng quan hệ generalization sẽ phù hợp hơn. -
Quản trị viên có thể sử dụng được các use-case như xem tiến trình đóng học phí của sinh viên, xem điểm, xem thông tin cá nhân… của Sinh viên.
-
Trong trường hợp như hệ thống đăng kí tín chỉ bị lỗi, quản trị viên có quyền sử dụng use-case đăng kí môn học để bổ sung sinh viên vào lớp học.
-
Mình sẽ cân nhắc.
Mình cảm ơn vì những góp ý của bạn!
Mình có sửa lại như này
Trong một hệ thống quản lý sinh viên, những chức năng cập nhật thường được thực hiện cách chủ động bởi quản trị viên. Tuy nhiên, trong một số trường hợp đặc biệt, sinh viên sẽ viết đơn gửi lên phòng đào tạo để xin chỉnh sửa thông tin. Ví dụ: chấm sai điểm, bị giảng viên đánh vắng nhầm người, xin chuyển lớp, xin bảo lưu kết quả học tập,…
=> Bạn có thể làm thêm chức năng sinh viên tạo form, gửi form lên hệ thống để yêu cầu cập nhật, chỉnh sửa thông tin, có thể có thêm Actor giảng viên bộ môn vào để xác nhận thông tin…
Nếu bạn muốn đi lâu dài với dự án này thì có thể bổ sung thêm, trong trường hợp đây chỉ là đề tài cho môn học hiện tại thì mình nghĩ bạn vẽ như thế cũng khá là ok rồi.
Các use cases của bạn nên được để trong một khung, sau này trong quá trình phát triển, hệ thống của bạn được chia ra làm nhiều components, nhiều layers, thì sẽ dễ hiểu hơn. Ví dụ:
3 Likes
Một vài điểm bạn cần lưu ý:
Actor Sinh viên có thể xem điểm, nhưng chỉ có thể xem điểm của bản thân mình.
Actor Sinh viên có thể xem lịch thi, nhưng chỉ là lịch thi của bản thân mình.
…
Tuy nhiên, Admin có thể xem điểm, xem lịch thi, … của bất kỳ sinh viên nào.
=> Vậy thì Sinh viên và Admin không thể nào sử dụng chung một use case Xem điểm, Xem lịch thi được phải không?
Mình nghĩ bạn nên thêm vào một Use case Tìm kiếm cho Admin, và các use case Xem điểm, xem lịch thi, … là những use-case có thể được dùng sau khi tìm kiếm ra kết quả ( quan hệ của chúng là include nhỉ? )
Phía sinh viên, khi sử dụng use case Xem điểm, input mặc định sẽ là mã sinh viên của bản thân sinh viên. Trong khi sử dụng use case Xem điểm including trong use case Tìm kiếm, input của Xem điểm sẽ là mã sinh viên đã search được. Bạn hiểu ý mình nói chứ? 
2 Likes
Mình hiểu ý bạn ạ, cảm ơn bạn nha
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?