Thao luan Bai tap 5
Thuy Nga
Nga đã post 2 file sơ đồ UML ( Adv 1 và Use Case Adv 1 ) cơ bản đồng ý
với ý kiến anh Xuân, Nga có một số thay đổi so với anh Xuân đã làm,
nhóm xem và trao đổi để thống nhất, phần diễn giải chức năng rất dài.
1> Actor "Nguoi_su_dung" thêm use case "Đăng_xuất"
2> Actor "Người_quản_lý":
- đề nghị chuyển use case "Nguon_thu_quang_cao" vào use case
"Theo_doi_cong_no" của Actor "ke_toan"
- use case "Quan_ly_nguoi_dung": đề nghị bỏ use case "Cap_quyen_nd" vì
quyền người dùng đã là 1 thuộc tính khi tạo một người dùng.
- Tương tự các use case "giá","giảm_gia","hoa_hong" là thuộc tính của
Bảng giá, không phải chức năng phụ của Bang_gia ( Anh Xuan gọi la
Don_giá ) khi dùng quan hệ extend.
và khi cập nhật về Bảng giá có thể cập nhật cả
"giá","giam_gia","hoa_hong".
3> Actor "Nhan_vien_in":
- đề nghị bỏ use case "Đon_gia" vì chỉ có "Nguoi_quan_ly" mới quy định
giá, nhân vien in chỉ sử dụng bảng giá khi nhận lịch thôi.
- Trong thực tế thì nhân viên in chỉ thực hiện 2 công việc chính là
nhập mẫu và nhập lịch book thôi, chức năng phụ là nhập lịch phim để có
thể thống kê doanh thu khi phát sóng một phim.
+ Bỏ chức năng "nhận_lich_book": đây là công việc không thao tác trên
phần mềm. Nó chỉ là việc kiểm tra giá trên tờ lịch book và ký xác
nhận, fax lại cho khách hàng.
+ Bỏ use case "Nhap_lich_book_bu" vì nó cũng là nhập một lịch book
bình thường chỉ khác là không tính tiền thôi. Khi thiết kế chi tiết
mình sẽ chọn chức năng tính tiền hay không tính tiền lịch này. Thực tế
có nhiều trường hợp phát sóng không tính tiền: các thông báo mang tính
chất nhân đạo hoặc từ thiện,...
- thêm quan hệ extend giữa 2 use case "Danh_sach_mau" và
"Nhap_lich_book" vì thực tế khách hàng có thể book lịch trước rất
nhiều ngày so với ngày gửi mẫu băng quảng cáo. Khi nhận lịch book và
nhập lịch book vào phần mềm, Nhan_vien_in không thể nhớ mẫu băng này
đã nhận và nhập vào phần mềm hay chưa, nếu chưa họ vẫn có thể nhập mẫu
để tiếp tục việc nhập lịch book đang thực hiện.
- Đổi tên 'Lich_phat_song" thành "Lich_phim" tránh hiểu nhầm là Lịch
phát quảng cáo ( mà Nhan_vien_out thực hiện mỗi ngày.
4> Actor Nhan_vien_out: Nga có đề nghị sau:
+ thêm use case "Thong_ke_thoi_luong" : thống kê thời lượng phát quảng
cáo theo giờ, theo bộ phim,...
+ sửa tên "Danh_sach_cut" thành "In_lich_phat"
+ sửa tên "Cung_cap_giay_CNPS" thành "In_CNPS"
+ sửa tên "Cong_no_khach_hang" thành "Tong_hop_doanh_so"
* Nga 0 rõ lắm ý của anh Xuân thực hiện 2 chức năng
"cung_cap_cho_bo_phan_ke_toan" và "phát sóng các cut" :
+Quy trình thực tế thì Nhan_vien_out in lịch phát quảng cáo (là các
cut) chuyển danh sách này cho kỹ thuật dựng để họ dựng cut quảng cáo
chuyển thành file phim cho phòng kỹ thuật phát lên sóng.
+ use case "cung_cap_cho_bo_phan_ke_toan" đây là chức năng cung cấp
các chứng từ được in ra bao gồm CNPS và tổng hợp doanh số theo từng
khách hàng để kế toán kiểm tra, chức năng này kế toán thực hiện bằng
use case "Theo_doi_cong_no"
5> Actor Ke_toan: cong việc chính là Theo_dõi_công_nợ
các use case phụ: Hop_dong , Thong_tin_khach_hang , Thanh toan
Câu hỏi: Có nhiều use case đều cần 3 thao tác "thêm" "xoá" "cap_nhat"
có cần vẽ vào sơ đồ không, nếu biểu diễn thì vẽ thế nào để khỏi rối.
Nga đề nghị : Nhóm upload sơ đồ tiếp theo thì đặt tên Adv 2, Adv
3,...để nhóm tiện trao đổi.