Pha phân tích quản lý sân bóng
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (268 KB, 9 trang )
1.
Vẽ lại sơ đồ chi tiết các UC của modul cá nhân.
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.
2.
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
12.
khiển. Vẽ sơ đồ lớp từ các lớp đã trích được.
3.1 Trí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
+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ể
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
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:
3.2
•
4.
4.2
Thẻ CRC cho lớp điều khiển
4.3
Sơ đồ lớp cho modul
5.
Xây dựng sơ đồ hoạt động (statechart) cho modul
lic
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
6.
•
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)
