Bối cảnh và vấn đề nghiên cứu

Trong bối cảnh hoạt động thể thao phong trào ngày càng phát triển, nhu cầu thuê và quản lý sân bóng mini gia tăng nhanh chóng, đòi hỏi các cơ sở kinh doanh phải áp dụng giải pháp tin học hóa nhằm thay thế các phương thức vận hành thủ công. Báo cáo bài tập lớn môn Phân tích và Thiết kế Hệ thống Thông tin với đề tài "Hệ thống Quản lý Sân bóng Mini" được thực hiện bởi nhóm sinh viên Khoa Công nghệ Thông tin – Học viện Công nghệ Bưu chính Viễn thông (dưới sự hướng dẫn của giảng viên Đào Ngọc Phong) nhằm giải quyết bài toán tự động hóa quy trình quản lý và nâng cao hiệu quả kinh doanh.

Mục tiêu nghiên cứu và xây dựng hệ thống được xác định cụ thể như sau:

  1. Xây dựng hệ thống quản lý toàn diện cho mô hình sân bóng mini, từ việc tự động hóa các quy trình vận hành đến tối ưu hóa nghiệp vụ quản lý.
  2. Nâng cao trải nghiệm của khách hàng thông qua việc cung cấp các dịch vụ tiện ích tương ứng (đặt sân đa kênh, dịch vụ đi kèm, tích lũy điểm thưởng).
  3. Đóng góp vào việc mở rộng quy mô kinh doanh và gia tăng khả năng cạnh tranh của doanh nghiệp trong lĩnh vực dịch vụ thể thao.

Đối tượng và phạm vi nghiên cứu của đề tài bao gồm:

  • Đối tượng sử dụng hệ thống:
    • Quản lý viên: Chủ sân bóng (Admin) và Nhân viên quản lý sân bóng (Manager).
    • Nhân viên: Nhân viên lễ tân kiêm thu ngân nhận thanh toán (Receptionist) và Nhân viên bán hàng (Seller).
    • Khách hàng: Khách hàng thường xuyên và Khách hàng mới (Client).
  • Phạm vi chức năng: Bao quát toàn bộ các hoạt động quản lý thông tin sân, đặt sân trực tiếp và trực tuyến, quản lý khách hàng, quản lý kho và dịch vụ cho thuê/bán kèm, quản lý thanh toán - xuất hóa đơn, thống kê báo cáo doanh thu và phân quyền người dùng.
  • Thời gian và đơn vị thực hiện: Báo cáo được hoàn thành vào ngày 25 tháng 11 năm 2024 tại Học viện Công nghệ Bưu chính Viễn thông.

Cơ sở lý thuyết và phương pháp

Đề tài áp dụng quy trình phân tích và thiết kế hệ thống hướng đối tượng (OOAD - Object-Oriented Analysis and Design) kết hợp với ngôn ngữ mô hình hóa thống nhất (UML).

Các khung lý thuyết và phương pháp kỹ thuật được triển khai bao gồm:

  • Phương pháp trích xuất thực thể: Phân tích mô tả hoạt động nghiệp vụ thực tế, áp dụng kỹ thuật trích lọc danh từ để xác định các lớp thực thể cốt lõi; loại bỏ các danh từ trừu tượng (như tiền sân, chi phí, hệ thống), đối tượng ngoài phạm vi (điện thoại) và xác định đúng vai trò của các đối tượng biên (báo cáo doanh thu).
  • Mô hình hóa ca sử dụng (Use Case Modeling): Xây dựng sơ đồ Use Case (UC) tổng quát và sơ đồ chi tiết cho từng tác nhân (Admin, Manager, Receptionist, Seller, Client) nhằm phân định rõ ranh giới trách nhiệm và luồng tương tác.
  • Mô hình hóa hoạt động (Activity Modeling): Xây dựng biểu đồ hoạt động để mô tả chi tiết các luồng nghiệp vụ phức tạp (luồng cơ bản, luồng rẽ nhánh, luồng ngoại lệ).
  • Phương pháp thiết kế và chuẩn hóa cơ sở dữ liệu quan hệ: Chuyển đổi các lớp thực thể trong biểu đồ lớp thành bảng dữ liệu quan hệ, xác lập các ràng buộc toàn vẹn (khóa chính, khóa ngoại, quan hệ 1-1, 1-n, n-1) và thực hiện kỹ thuật mịn hóa thuộc tính (loại bỏ các thuộc tính có thể tính toán suy diễn nhằm giảm dư thừa dữ liệu).
  • Nguồn dữ liệu nghiên cứu: Thu thập từ khảo sát thực tế quy trình đặt sân, vận hành, kiểm kê dịch vụ và thanh toán tại các cụm sân bóng mini.

Thiết kế và triển khai

Hệ thống được phân tích và lựa chọn kiến trúc dựa trên các góc nhìn kỹ thuật đa chiều, đáp ứng yêu cầu vận hành với độ trễ thấp và khả năng mở rộng cao.

Phân tích kiến trúc theo các góc nhìn

Góc nhìn kiến trúc Mô hình lựa chọn Ưu điểm và đặc tính đáp ứng
Quan điểm module (Module Viewpoint) Kiến trúc hướng dịch vụ (SOA) & Mô hình MVC Chia nhỏ hệ thống thành các dịch vụ độc lập; tách biệt giao diện người dùng, logic điều khiển và xử lý dữ liệu.
Góc nhìn quá trình (Process Viewpoint) Microservices & Xử lý đồng thời thời gian thực Phân tách chức năng độc lập giao tiếp qua API; đáp ứng khả năng mở rộng cao, không nghẽn hệ thống khi xử lý nhiều phiên đặt sân đồng thời.
Quan điểm dòng dữ liệu (Data Flow Viewpoint) Kiến trúc hướng sự kiện (Event-Driven Architecture) Sử dụng Event Bus để thông báo và cập nhật dữ liệu tự động giữa các dịch vụ (ví dụ: phát sự kiện "Đặt Sân Mới" sang Service Báo cáo).

Mô hình thiết kế tổng thể

Hệ thống kết hợp mô hình MVC ở tầng Frontend với Microservices và Event-Driven Architecture ở tầng Backend:

  • Frontend (MVC): Giao diện tương thích máy tính để bàn và máy tính cá nhân, chia theo vai trò người dùng (Model đại diện dữ liệu, View trực quan hóa, Controller tiếp nhận tương tác và gửi dữ liệu qua API).
  • Backend Services:
    • Service Quản lý sân: Xử lý thông tin và trạng thái sân bóng.
    • Service Đặt sân: Kiểm tra sân trống, tạo lịch đặt và giữ chỗ.
    • Service Thanh toán: Xử lý tiền cọc, giờ thuê, xuất hóa đơn.
    • Service Dịch vụ kèm theo: Quản lý cho thuê giày, bóng, áo đấu.
    • Service Quản lý nhập hàng: Quản lý đơn hàng từ nhà cung cấp.
    • Service Báo cáo và thống kê: Phân tích doanh thu và hiệu suất sân.
  • Event Bus: Trục truyền thông điệp liên dịch vụ theo thời gian thực.
  • Cơ sở dữ liệu phân tán: Tách biệt thành các cơ sở dữ liệu chuyên biệt gồm DB Quản lý sân, DB Đặt sân, DB Thanh toán, DB Dịch vụ, DB Báo cáo và thống kê.
  • Đặc tả môi trường: Triển khai trên máy chủ đám mây, đảm bảo thời gian phản hồi hệ thống dưới 3 giây và sẵn sàng vận hành 24/7.

Nội dung chính theo từng chương

Báo cáo được cấu trúc thành hai phần chính: Công việc chung và Công việc cá nhân.

Phần I: Công việc chung

1. Mô tả bài toán và Đặc tả yêu cầu phần mềm

Phần này làm rõ mục tiêu, mô hình vận hành và phân định các nhóm yêu cầu kỹ thuật:

  • Yêu cầu chức năng: Gồm 7 phân hệ chính (Quản lý sân bóng; Quản lý đặt sân; Quản lý khách hàng; Quản lý dịch vụ kèm theo; Quản lý thanh toán; Quản lý báo cáo thống kê; Quản lý hệ thống và phân quyền).
  • Yêu cầu phi chức năng: Đảm bảo tính bảo mật (mã hóa dữ liệu, phân quyền truy cập, sao lưu định kỳ); tính hiệu năng (phản hồi < 3 giây, phục vụ đồng thời nhiều người dùng); độ tin cậy (tự phục hồi khi gặp sự cố, dữ liệu nhất quán); giao diện thân thiện, tương thích máy tính để bàn và máy tính cá nhân.
  • Các ràng buộc hệ thống:
    • Ràng buộc thời gian: Thời gian thuê tối thiểu 1 giờ; đặt sân trước ít nhất 2 giờ; hủy sân trước 24 giờ.
    • Ràng buộc thanh toán: Đặt cọc trước 30% tổng giá trị thuê; hoàn tất thanh toán trước khi vào sử dụng sân.

2. Xây dựng Business Model và Use Case

Xây dựng lược đồ Use Case tổng quát và Use Case chi tiết cho 5 nhóm đối tượng người dùng:

  • Nhân viên nói chung: Login, Change password, Logout.
  • Nhân viên quản lý (Manager): Manage area (thêm, sửa, xóa khu vực sân), Manage service (quản lý dịch vụ bán/cho thuê), View report (xem doanh thu, tỷ lệ sân trống theo ngày/tháng/năm).
  • Chủ sân bóng (Admin): Admin login, Manage user (quản lý tài khoản và phân quyền nhân viên).
  • Nhân viên lễ tân (Receptionist): Manage booking on site, Manage Client on site, Manage used services, Checkin, Checkout, Manage payment on site.
  • Nhân viên bán hàng (Seller): Manage booking via phone, Manage payment via phone.
  • Khách hàng (Client): Client login, Client sign up, Booking online, View booking history, Promotion.

3. Phân tích và thiết kế cơ sở dữ liệu

Quá trình phân tích danh từ đã trích xuất các thực thể chính: Sân, Hệ thống sân, Tài khoản người dùng, Khách hàng, Hóa đơn, Dịch vụ, Nhà cung cấp, Đơn nhập hàng.

CSDL toàn hệ thống được thiết kế gồm 12 bảng dữ liệu quan hệ:

Tên bảng Khóa chính (PK) Khóa ngoại (FK) Các thuộc tính tiêu biểu
tblSystem ID Không name, address, description
tblField ID systemID name, displayPrice, description
tblClient ID Không name, phoneNumber, description
tblUser ID Không userName, password, fullName, bod, address, role, phoneNumber
tblService ID Không name, displayPrice, unit, quantity
tblUsedService ID serviceID, sessionID pricePerUnit, quantity
tblBooking ID rentalFieldID, clientID, userID beginDate, endDate, pricePerHour, description
tblOrder ID userID, serviceID, providerID orderTime, quantity, pricePerUnit, paymentType, description
tblProvider ID Không name, address, phoneNumber, description
tblBill ID userID, bookingID paymentTime, paymentAmount, paymentType, description
tblRentalField id fieldID, sessionID price, saleoff, subtotal
tblOneSessionOfRental id Không checkIn, checkOut

Mịn hóa thuộc tính: Nhóm nghiên cứu đã loại bỏ thuộc tính totalPrice tại các bảng tblBooking, tblUsedService và tblOrder do trường dữ liệu này hoàn toàn có thể tính toán gián tiếp từ đơn giá và số lượng/thời gian thuê, giúp tối ưu hóa không gian lưu trữ và đảm bảo tính nhất quán dữ liệu.


Phần II: Công việc cá nhân

Phần này phân chia trách nhiệm thiết kế chi tiết các ca sử dụng cho từng thành viên trong nhóm:

STT Thành viên Mã sinh viên Use Case đảm nhận
1 Trần Hữu Ngọc B21DCCN568 Đặt sân
2 Nguyễn Hoàng Nam B21DCCN550 Cập nhật các dịch vụ kèm theo
3 Trần Hương Giang B21DCCN308 Thanh toán
4 Nguyễn Thế Dũng B21DCCN275 Thống kê doanh thu
5 Đỗ Quang Huy B21DCCN432 Quản lý nhập hàng

Chi tiết thiết kế Use Case Đặt sân (Sinh viên Trần Hữu Ngọc)

  • Đặc tả Use Case UCBF_1 (Đặt sân qua nhân viên):
    • Actor: Nhân viên lễ tân, nhân viên bán hàng (chính); Khách hàng (phụ).
    • Luồng sự kiện: Tìm kiếm sân trống theo khung giờ, khoảng ngày, thứ cố định, loại sân -> Tìm kiếm/thêm mới thông tin khách hàng -> Lập phiếu đặt sân (tính tiền ước tính, tính tiền cọc 10%, cộng 5% xu tích lũy) -> Tùy chọn sử dụng xu tích lũy để trừ tiền -> Thanh toán tiền mặt hoặc chuyển khoản ngân hàng qua mã QR -> Xác nhận, in phiếu và gửi SMS.
  • Đặc tả Use Case UCBF_2 (Đặt sân qua Website):
    • Actor: Khách hàng.
    • Luồng sự kiện: Khách hàng đăng nhập/đăng ký tài khoản (xác thực OTP 6 số trong 2 phút) -> Tìm kiếm và chọn sân trống -> Xác nhận thông tin và áp dụng xu tích lũy -> Thanh toán tiền cọc qua mã QR động (thời hạn hiệu lực 30 phút) -> Hệ thống nhận phản hồi tự động từ ngân hàng, xuất phiếu điện tử và lưu CSDL.
  • Thiết kế giao diện và lớp tương ứng: Xây dựng chi tiết các biểu đồ hoạt động và đặc tả giao diện gồm HomeEmployeeFrm, BookingFrm, ListFieldFrm, SearchClient, AddInfoClientFrm, InfoClientFrm, DetailBookingFrm, PaymentFrm cùng các phương thức xử lý nghiệp vụ (searchFieldSession(), searchClient(), createPayment()).

Kết quả và đóng góp

  1. Kết quả kỹ thuật:
    • Xây dựng hoàn chỉnh tài liệu phân tích và thiết kế hệ thống thông tin quản lý sân bóng mini theo chuẩn mô hình hóa UML.
    • Thiết lập mô hình cơ sở dữ liệu quan hệ chuẩn hóa gồm 12 bảng thực thể, tối ưu hóa các thuộc tính suy diễn.
    • Hoàn thiện đặc tả kiến trúc kết hợp linh hoạt giữa Microservices, Event-Driven và MVC, đảm bảo thời gian đáp ứng dưới 3 giây.
  2. Giải pháp nghiệp vụ:
    • Chuẩn hóa quy trình đặt sân đa kênh (tại quầy, qua điện thoại và qua website trực tuyến).
    • Thiết kế cơ chế quản lý tài chính linh hoạt: quản lý cọc (10% - 30%), thanh toán tự động qua mã QR động liên kết ngân hàng, cơ chế tích lũy điểm thưởng (cộng 5% giá trị, cho phép khấu trừ vào các lần thuê tiếp theo).
  3. Đóng góp của đồ án:
    • Cung cấp tài liệu thiết kế hệ thống chi tiết, có tính ứng dụng thực tiễn cao cho các cơ sở kinh doanh dịch vụ sân thể thao mini quy mô vừa và nhỏ.

Hạn chế và hướng nghiên cứu tiếp

  • Hạn chế: Báo cáo tập trung chủ yếu vào giai đoạn Phân tích và Thiết kế hệ thống (Analysis and Design); phần chi tiết cá nhân trong tài liệu được công bố tập trung sâu vào ca sử dụng "Đặt sân", trong khi các ca sử dụng chuyên sâu khác (nhập hàng, thống kê nâng cao) mới dừng lại ở mức mô hình hóa tổng quan.
  • Hướng phát triển: Hiện thực hóa toàn bộ mã nguồn chương trình dựa trên các bản vẽ thiết kế; tích hợp cổng thanh toán trực tuyến thực tế (Payment Gateway); triển khai thử nghiệm trên hạ tầng máy chủ đám mây để đánh giá tải thực tế và độ ổn định 24/7.

Giá trị tham khảo

Tài liệu là nguồn tham khảo hữu ích cho:

  • Sinh viên ngành Công nghệ Thông tin, Hệ thống Thông tin, Kỹ thuật Phần mềm: Học tập phương pháp trích xuất thực thể, xây dựng sơ đồ Use Case, phân tích thiết kế CSDL quan hệ và cách tích hợp các kiến trúc phần mềm hiện đại (Microservices, Event-Driven, MVC).
  • Các nhóm phát triển dự án phần mềm dịch vụ: Tham khảo mô hình luồng nghiệp vụ đặt chỗ (booking), quản lý ca thuê, xử lý tích điểm thưởng và quy trình thanh toán bán lẻ kết hợp dịch vụ đi kèm.

Câu hỏi thường gặp

1. Hệ thống phân quyền cho những nhóm người dùng nào và vai trò của từng nhóm là gì?

Hệ thống phân định 3 nhóm người dùng chính gồm:

  • Quản lý viên: Gồm Chủ sân bóng (Admin - quản lý tài khoản người dùng, phân quyền) và Nhân viên quản lý (Manager - quản lý khu vực sân, quản lý danh mục dịch vụ, xem báo cáo doanh thu và tỷ lệ lấp đầy sân).
  • Nhân viên: Gồm Nhân viên lễ tân (tiếp nhận đặt sân tại chỗ, check-in, check-out, thanh toán, ghi nhận dịch vụ) và Nhân viên bán hàng (tiếp nhận đặt sân và thanh toán qua điện thoại).
  • Khách hàng: Khách hàng mới và khách hàng thân thiết (đăng ký, đăng nhập, tìm kiếm sân trống, đặt sân online, xem lịch sử và nhận khuyến mãi).

2. Các quy định và ràng buộc về thời gian, đặt cọc khi thuê sân được thiết kế như thế nào?

Theo đặc tả hệ thống:

  • Thời gian thuê sân tối thiểu là 1 giờ.
  • Khách hàng phải đặt sân trước thời điểm sử dụng ít nhất 2 giờ và nếu có nhu cầu hủy sân phải thực hiện trước ít nhất 24 giờ.
  • Về tài chính, khách hàng phải đặt cọc trước (từ 10% đến 30% tùy theo hình thức đặt) và hoàn tất thanh toán 100% chi phí trước khi vào sân thi đấu.

3. Tại sao hệ thống lại kết hợp giữa kiến trúc Microservices, Event-Driven và MVC?

Kiến trúc được chia tầng để tối ưu hóa từng khía cạnh:

  • Frontend sử dụng MVC: Giúp tách biệt rõ ràng giữa giao diện hiển thị theo quyền hạn (View), logic điều hướng (Controller) và dữ liệu (Model).
  • Backend sử dụng Microservices: Tách các chức năng (Quản lý sân, Đặt sân, Thanh toán, Dịch vụ, Báo cáo) thành các dịch vụ độc lập, giúp dễ dàng mở rộng và bảo trì mà không làm gián đoạn toàn bộ hệ thống khi một dịch vụ gặp sự cố.
  • Event-Driven (với Event Bus): Hỗ trợ cập nhật trạng thái theo thời gian thực giữa các dịch vụ (ví dụ: khi có giao dịch đặt sân mới, hệ thống tự động bắn sự kiện để cập nhật lịch sân và báo cáo thống kê).

4. Cơ sở dữ liệu của hệ thống gồm những bảng nào và kỹ thuật mịn hóa thuộc tính được thực hiện ra sao?

Cơ sở dữ liệu gồm 12 bảng: tblSystem, tblField, tblClient, tblUser, tblService, tblUsedService, tblBooking, tblOrder, tblProvider, tblBill, tblRentalField, tblOneSessionOfRental. Trong quá trình thiết kế, các tác giả đã mịn hóa bằng cách lược bỏ trường totalPrice ở các bảng tblBooking, tblUsedService, tblOrder nhằm tránh dư thừa dữ liệu, do giá trị này hoàn toàn có thể tính toán từ đơn giá và thời gian/số lượng.

5. Quy trình đặt sân trực tuyến qua Website (UCBF_2) xử lý bảo mật và thanh toán như thế nào?

Khi khách hàng mới đăng ký tài khoản, hệ thống gửi mã OTP 6 chữ số qua số điện thoại với thời gian hiệu lực trong 2 phút để xác thực. Khi thực hiện đặt sân, hệ thống tạo mã QR thanh toán độc nhất có hiệu lực trong 30 phút. Khách hàng thực hiện chuyển khoản, ngân hàng sẽ phản hồi trạng thái giao dịch thành công về hệ thống để tự động xuất phiếu đặt sân điện tử và gửi xác nhận qua tin nhắn SMS.


Kết luận

Báo cáo bài tập lớn "Hệ Thống Quản Lý Sân Bóng Mini: Phân Tích và Thiết Kế" của nhóm sinh viên Học viện Công nghệ Bưu chính Viễn thông đã xây dựng một tài liệu phân tích thiết kế hệ thống thông tin hoàn chỉnh, khoa học và bám sát nghiệp vụ thực tế. Đề tài thể hiện sự kết hợp chặt chẽ giữa các phương pháp mô hình hóa UML, thiết kế cơ sở dữ liệu quan hệ chuẩn hóa và các mô hình kiến trúc phần mềm hiện đại như Microservices, Event-Driven và MVC. Đây là tài liệu tham khảo có giá trị cao cho sinh viên công nghệ thông tin và các nhà phát triển hệ thống quản lý dịch vụ thể thao.