Nhân viên lễ tân A click vào chức năng thanh toán trong menu quản lý khách hàng nhận sân.. Hệ thống hiển thị giao diện yêu cầu tên hoặc số id của khách hàng: 1 ô nhập id, 1 ô nhập tên và
Trang 11. Vẽ lại sơ đồ chi tiết các UC của modul cá nhân.
2. Với mỗi UC, trích các scenario chuẩn và các ngoại lệ tương ứng
2.1. Viết Scanario chuẩn:
1. Nhân viên lễ tân A click vào chức năng thanh toán trong menu quản lý khách hàng nhận sân Nhân viên lễ tân A muốn làm thủ tục thanh toán đặt cọc cho khách hàng B
2. Hệ thống hiển thị giao diện yêu cầu tên hoặc số id của khách hàng: 1 ô nhập id, 1 ô nhập tên và một nút tìm kiếm lịch sử đặt sân của khách hàng
3. Nhân viên A hỏi lại khách hàng B id và tên
4. Khách hàng B trả lời tên và số id của mình cho nhân viên A
5. Nhân viên A nhập id của khách hàng B vào ô tìm kiếm và click vào nút tìm kiếm
6. Hệ thống tìm kiếm từ CSDL và hiển thị lên thông tin hợp đồng các lần đặt sân của khách hàng B Mỗi hàng một lần đặt với đầy đủ thông tin:tên(mã)sân, kiểu sân, giá đặt, mô tả, giờ vào sân và giờ ra sân
7. Nhân viên A yêu cầu khách hàng B và xác nhận thông tin sân đặt: giờ vào và giờ ra
8. Khách hàng B xác nhận giờ vào và giờ ra cho nhân viên A
9. Nhân viên A click vào lần lượt sân tương ứng trên giao diện và chọn thanh toán
10. Hệ thống hiển thị thông tin hóa đơn cần thanh toán bao gồm các thông tin: mã hóa đơn, ngày tạo,tên, địa chỉ khách hàng, số hiệu sân, kiểu sân, đơn giá, gía thêm giờ, tiền đồ ăn, nước uống,…Dòng tiếp theo ghi tổng số tiền của hóa đơn, một dòng ghi tổng số tiền đã thanh toán trước đó Dòng cuối cùng yêu cầu nhập vào số tiền khách hàng muốn thanh toán
11. Nhân viên A nhập vào số tiền đã nhận của khách hàng B
Trang 212. Hệ thống hiển thị lại thông tin hóa đơn một lần nữa: trong đó cập nhật lại số tiền
đã thanh toán và số tiền còn lại cần thanh toán
13. Nhân viên A thông báo lại cho khách hàng số tiền còn lại cần trả và in hóa đơn cho lần thanh toán này cho khách hàng B
2.2. Scenario ngoại lệ:
1. Hệ thống kiểm tra được đã tồn tại khách hàng có số id 12345 trong CSDL, hệ thống hiển thị thông báo:”Đã tồn tại khách hàng này”
2. B nhấn nút hủy, hệ thống hiển thị giao diện chương trình
3. Trích các lớp thực thể, trích các lớp biên, các lớp điều
khiển Vẽ sơ đồ lớp từ các lớp đã trích được.
3.1Trích các lớp thực thể.
• Mô tả bài toán đặt sân bóng:
Hệ thống phục vụ hoạt động quản lí đặt sân (sân bóng) của một cửa hàng Trong đó, nhân viên quản lí có thể quản lí thông tin sân, quản lí thông tin lịch sân
và xem các báo cáo Nhân viên quản trị có thể quản lí các tài khoản người dùng hệ thống Nhân viên bán hàng có thể đặt sân, thay đổi và hủy đặt sân cho khách hàng thông qua điện thoại Nhân viên tiếp tân có thể đặt sân, thay đổi đặt sân, hủy đặt sân, làm thủ tục checkin, checkout, cho khách hàng ký hợp đồng, hủy hợp đồng và thanh toán trực tiếp tại chỗ cho khách hàng Khi thanh toán có thể xuất hóa đơn theo yêu cầu của khách hàng, bao gồm tiền sân và chi phí các dịch vụ gia tăng của cửa hàng mà khách hàng đã dùng
• Các danh từ: Hệ thống, sân bóng, cửa hàng, nhân viên quản lí, báo cáo, nhân viên
quản trị, tài khoản người dùng, nhân viên bán hàng, khách hàng, điện thoại, nhân viên tiếp tân, hóa đơn, yêu cầu, tiền sân, chi phí, dịch vụ gia tăng
• Đánh giá:
+ Điện thoại nằm ngoài phạm vi của phần mềm → loại
+Hệ thống, yêu cầu, tiền sân, chi phí là các danh từ trừu tượng → loại
+Báo cáo nên là một lớp biên hơn là lớp thực thể
+Nhân viên quản lí, nhân viên quản trị, nhân viên bán hàng, nhân viên tiếp tân đều có thể là các danh từ cụ thể của tài khỏan người dùng
• Như vậy chỉ còn các lớp thực thể:
+Sân bóng: FootballPitch
Trang 3+Cửa hàng: ShopForRent
+Tài khoản người dùng: User
+Hóa đơn: Bill
+Khách hàng: Client
+Dịch vụ gia tăng: Service
• Quan hệ giữa các lớp thực thể:
+Một ShopForRent có nhiều FootballPitch, một FootballPitch phải thuộc vào một ShopForRent nhất định
+Một FootballPitch có thể đặt bởi nhiều Client, một Client lại có thể đặt nhiều FootballPitch tại nhiều thời điểm khác nhau → Đề xuất thêm một lớp Booking +Một Booking có thể dùng nhiều Service khác nhau, một Service lại có thể được
sử dụng bởi nhiều Booking khác nhau → Đề xuất thêm lớp UsedService
+Một Booking có thể được thanh toán nhiều lần khác nhau nên có thể có nhiều Bill
+Mỗi Bill có tối đa một User lập và nhận thanh toán
• Sơ đồ thực thể
Trang 43.2 Trích các lớp biên, lớp điều khiển.
• Trích các lớp biên
Đề xuất các lớp biên cho modul quản lí sân bóng của Manager:
Giao diện chính: FootballGroundManagerFrm
Chức năng thêm: form thêm (AddFootballGroundFrm)
Chức năng sửa: form tìm kiếm (SearchEditFootballGroundFrm), form kết quả (chung với SearchEditFootballGroundFrm), form sửa
(EditFootballGroundFrm)
Chức năng xóa: form tìm kiếm (SearchDeleteFootballGroundFrm), form kết quả dùng chung với SearchDeletefootballGroundFrm
Các dialog và cửa sổ con đều là thành phần của các form chính
• Trích lớp điều khiển
Đề xuất mỗi modul dùng riêng lớp điều khiển:
Lớp điều khiển cho modul Manager: ManagerCtr
Lớp điều khiển cho modul Admin: AdminCtr
Lớp điều khiển cho modul Seller: SellerCtr
Lớp điều khiển cho modul Receptionist: ReceptCtr
4 Xây dựng thẻ CRC cho các lớp điều khiển
4.1 Thẻ CRC cho lớp điều khiển modul Manager:
Trang 54.2 Thẻ CRC cho lớp điều khiển
Trang 64.3 Sơ đồ lớp cho modul
Trang 85. Xây dựng sơ đồ hoạt động (statechart) cho modul
lic
6. Viết lại các scenario với các lớp đã trích được
• Manage footballground: scenario chuẩn cho thêm sân
1 Nhân viên quản lí A chọn chức năng quản lí sân sau khi login A muốn thêm thông tin một sân mới
2 Lớp FootballGroundManagerFrm hiện ra với 3 nút: thêm, sửa, xóa sân
3 Nhân viên A click vào nút thêm sân
4 Lớp FootballGroundManagerFrm gọi lớp AddFootballgroundFrm yêu cầu hiển thị
5 Lớp AddFootballGroundFrm hiện ra với các ô nhập: id sân, tên sân, kiểu sân, giá hiển thị, mô tả, và 2 nút: nút thêm sân, và nút hủy bỏ
6 Nhân viên A nhập các thông tin sân mới vào các ô và click nút thêm sân
7 Lớp AddFootballGroundFrm gọi lớp FootballGround để đóng gói thông tin trên form thành một đối tượng kiểu FootballGround
7 Thực tế hóa mỗi scenario của mỗi UC thành sơ đồ tuần tự (hoặc cộng tác)