Bài tập lớn: Phân tích & thiết kế hệ thống quản lý thư viện (ĐH Bách Khoa)

Chuyên khảo phân tích Phân tích và thiết kế hướng đối tượng đối với hệ thống quản lý thư viện, đánh giá các khía cạnh quan trọng, đề xuất hướng nghiên cứu tiếp theo.

• Đề tài: Phân Tích và Thiết Kế Hệ Thống Quản Lý Thư Viện

Mục lục chi tiết

• PHÂN CÔNG THÀNH VIÊN TRONG NHÓM
• 1. CHƯƠNG 1: GIỚI THIỆU ĐỀ TÀI
• 1.1. Mục tiêu và phạm vi của đề tài
• 1.2. Các thuật ngữ và từ viết tắt
• 1.3. Tài liệu tham khảo
• 1.4. Tổng quan tài liệu
• 2. CHƯƠNG 2: PHÂN TÍCH YÊU CẦU PHẦN MỀM
• 2.1. Yêu cầu tổng quan về nghiệp vụ
• 2.1.1. Phân tích nghiệp vụ
• 2.1.2. Quy tắc nghiệp vụ
• 2.1.3. Các tác nhân của hệ thống
• 2.2. Phân tích yêu cầu chức năng
• 2.2.1. Biểu đồ use case tổng quan của hệ thống
• 2.2.2. Phân rã use case “Quản lý sách”
• 2.2.3. Phân rã use case “Quản lý mượn, trả sách”
• 2.2.4. Phân rã use case “Quản lý độc giả”
• 2.2.5. Phân rã use case “Thống kê”
• 2.2.6. Phân rã use case “Quản lý tài khoản thủ thư”
• 2.2.7. Đặc tả use case
• 2.2.7.1. Nhóm use case “Quản lý sách”
• 2.2.7.1.1. UC001 “Thêm sách”
• 2.2.7.1.2. UC002 “Tìm kiếm sách”
• 2.2.7.1.3. UC003 “Xem chi tiết sách”
• 2.2.7.1.4. UC005 “Sửa thông tin sách”
• 2.2.7.2. Nhóm use case “Quản lý mượn, trả sách”
• 2.2.7.2.1. UC006 “Lập phiếu mượn”
• 2.2.7.2.2. UC007 “Gia hạn phiếu mượn”
• 2.2.7.2.3. UC008 “Xử lý trả sách”
• 2.2.7.2.4. UC009 “Xử lý vi phạm”
• 2.2.7.3. Nhóm use case “Quản lý độc giả”
• 2.2.7.3.1. UC010 “Tìm kiếm độc giả”
• 2.2.7.3.2. UC011 “Xem thông tin độc giả”
• 2.2.7.3.3. UC012 “Thêm độc giả”
• 2.2.7.3.4. UC013 “Xóa độc giả”
• 2.2.7.3.5. UC014 “Sửa thông tin độc giả”
• 2.2.7.4. Nhóm use case “Thống kê”
• 2.2.7.4.1. UC015 “Thống kê độc giả vi phạm”
• 2.2.7.4.2. UC016 “Thống kê sách mượn quá hạn”
• 2.2.7.4.3. UC017 “Thống kê lượt mượn sách”
• 2.2.7.5. Nhóm use case “Quản lý tài khoản thủ thư”
• 2.2.7.5.1. UC019 “Xem danh sách thủ thư”
• 2.2.7.5.2. UC020 “Tìm kiếm tài khoản”
• 2.2.7.5.3. UC021 “Xem chi tiết”
• 2.2.7.5.4. UC022 “Khóa tài khoản”
• 2.2.7.5.5. UC023 “Mở khóa tài khoản”
• 2.2.7.5.6. UC024 “Tạo tài khoản mới”
• 2.2.7.6. Các use case khác
• 2.2.7.6.1. UC025 “Đăng nhập”
• 2.2.7.6.2. UC026 “Đăng xuất”
• 2.2.7.6.3. UC027 “Tìm kiếm sách”
• 2.2.7.6.4. UC028 “Xem chi tiết sách”
• 2.2.7.6.5. UC029 “Cập nhật thông tin cá nhân”
• 2.3. Phân tích yêu cầu phi chức năng
• 2.3.1. Yêu cầu bảo mật
• 2.3.2. Yêu cầu hiệu năng
• 2.3.3. Yêu cầu giao diện
• 3. CHƯƠNG 3: THIẾT KẾ HỆ THỐNG
• 3.1. Mô hình hóa cấu trúc hệ thống
• 3.1.1. Nhóm ca sử dụng “Quản lý mượn trả sách”
• 3.1.1.1. Ca sử dụng “Xử lý yêu cầu trả”
• 3.1.1.2. Ca sử dụng “Xử lý vi phạm”
• 3.1.1.3. Ca sử dụng “Gia hạn phiếu mượn”
• 3.1.1.4. Ca sử dụng “Lập phiếu mượn”
• 3.1.2. Nhóm ca sử dụng “Quản lý sách”
• 3.1.2.1. Ca sử dụng “Tìm kiếm sách”
• 3.1.2.2. Ca sử dụng “Xem chi tiết sách”
• 3.1.2.3. Ca sử dụng “Sửa thông tin sách”
• 3.1.2.4. Ca sử dụng “Xóa sách”
• 3.1.2.5. Ca sử dụng “Thêm sách”
• 3.1.3. Nhóm ca sử dụng “Quản lý tài khoản thủ thư”
• 3.1.3.1. Ca sử dụng “Xem danh sách thủ thư”
• 3.1.3.2. Ca sử dụng “Xem chi tiết”
• 3.1.3.3. Ca sử dụng “Tìm kiếm tài khoản”
• 3.1.3.4. Ca sử dụng “Tạo tài khoản mới”
• 3.1.3.5. Ca sử dụng “Khóa tài khoản”
• 3.1.3.6. Ca sử dụng “Mở khóa tài khoản”
• 3.1.4. Nhóm ca sử dụng “Quản lý độc giả”
• 3.1.4.1. Ca sử dụng “Tìm kiếm độc giả”
• 3.1.4.2. Ca sử dụng “Thêm độc giả”
• 3.1.4.3. Ca sử dụng “Xem thông tin độc giả”
• 3.1.4.4. Ca sử dụng “Xóa độc giả”
• 3.1.4.5. Ca sử dụng “Sửa thông tin độc giả”
• 3.1.5. Nhóm ca sử dụng “Thống kê”
• 3.1.5.1. Ca sử dụng “Thống kê độc giả vi phạm”
• 3.1.5.2. Ca sử dụng “Thống kê sách mượn quá hạn”
• 3.1.5.3. Ca sử dụng “Thống kê lượt mượn sách”
• 3.1.5.4. Ca sử dụng “Xuất báo cáo”
• 3.1.6. Các ca sử dụng khác
• 3.1.6.1. Ca sử dụng “Đăng nhập”
• 3.1.6.2. Ca sử dụng “Đăng xuất”
• 3.1.6.3. Ca sử dụng “Cập nhật thông tin cá nhân”
• 3.2. Mô hình hóa sự tương tác
• 3.2.1. Nhóm ca sử dụng “Quản lý mượn trả sách”
• 3.2.1.1. Ca sử dụng “Xử lý yêu cầu trả”
• 3.2.1.2. Ca sử dụng “Xử lý vi phạm”
• 3.2.1.3. Ca sử dụng “Gia hạn phiếu mượn”
• 3.2.1.4. Ca sử dụng “Lập phiếu mượn”
• 3.2.2. Nhóm ca sử dụng “Quản lý sách”
• 3.2.2.1. Ca sử dụng “Tìm kiếm sách”
• 3.2.2.2. Ca sử dụng “Xem chi tiết sách”
• 3.2.2.3. Ca sử dụng “Sửa thông tin sách”
• 3.2.2.4. Ca sử dụng “Xóa sách”
• 3.2.2.5. Ca sử dụng “Thêm sách”
• 3.2.3. Nhóm ca sử dụng “Quản lý tài khoản thủ thư”
• 3.2.3.1. Ca sử dụng “Xem danh sách thủ thư”
• 3.2.3.2. Ca sử dụng “Xem chi tiết”
• 3.2.3.3. Ca sử dụng “Tìm kiếm tài khoản”
• 3.2.3.4. Ca sử dụng “Tạo tài khoản mới”
• 3.2.3.5. Ca sử dụng “Khóa tài khoản”
• 3.2.3.6. Ca sử dụng “Mở khóa tài khoản”
• 3.2.4. Nhóm ca sử dụng “Quản lý độc giả”
• 3.2.4.1. Ca sử dụng “Tìm kiếm độc giả”
• 3.2.4.2. Ca sử dụng “Thêm độc giả”
• 3.2.4.3. Ca sử dụng “Xem thông tin độc giả”
• 3.2.4.4. Ca sử dụng “Xóa độc giả”
• 3.2.4.5. Ca sử dụng “Sửa thông tin độc giả”
• 3.2.5. Nhóm ca sử dụng “Thống kê”
• 3.2.5.1. Ca sử dụng “Thống kê độc giả vi phạm”
• 3.2.5.2. Ca sử dụng “Thống kê sách mượn quá hạn”
• 3.2.5.3. Ca sử dụng “Thống kê lượt mượn sách”
• 3.2.5.4. Ca sử dụng “Xuất báo cáo”
• 3.2.6. Các ca sử dụng khác
• 3.2.6.1. Ca sử dụng “Đăng nhập”
• 3.2.6.2. Ca sử dụng “Đăng xuất”
• 3.3. Kiến trúc tổng thể của hệ thống
• 3.4. Thiết kế chi tiết lớp
• 3.4.1. Sơ đồ lớp tổng quan của gói model
• 3.4.2. Sơ đồ gói lớp tổng quan của gói Control
• 3.4.3. Sơ đồ lớp tổng quan của gói View
• 3.5. Thiết kế cơ sở dữ liệu
• 3.5.1. Sơ đồ quan hệ bảng dữ liệu
• 3.5.2. Danh sách các bảng dữ liệu
• 3.5.3. Thiết kế chi tiết các bảng dữ liệu
• 3.5.3.1. Bảng doc_gia
• 3.5.3.2. Bảng phieu_muon
• 3.5.3.3. Bảng bien_ban_vi_pham
• 3.5.3.4. Bảng tai_khoan
• 3.5.3.5. Bảng thu_thu
• 3.5.3.6. Bảng muon_sach
• 3.6. Thiết kế nguyên mẫu giao diện
• 3.6.1. Giao diện khách
• 3.6.2. Giao diện đăng nhập hệ thống
• 3.6.3. Giao diện của thủ thư sau đăng nhập
• 3.6.4. Giao diện quản lý sách
• 3.6.5. Giao diện xem chi tiết sách
• 3.6.6. Giao diện sửa thông tin sách
• 3.6.7. Giao diện thống kê
• 3.6.8. Giao diện tải báo cáo
• 3.6.9. Giao diện tạo phiếu mượn
• 3.6.10. Giao diện xử lý độc giả trả sách
• 3.6.11. Giao diện của quản trị viên
• 3.6.12. Giao diện xem chi tiết tài khoản thủ thư

Tóm tắt

I. Hướng dẫn phân tích thiết kế hướng đối tượng cho thư viện

Phương pháp phân tích và thiết kế hướng đối tượng (OOAD) là một cách tiếp cận hiện đại trong công nghệ phần mềm, giúp mô hình hóa các hệ thống phức tạp dựa trên các đối tượng (object) và lớp (class) trong thế giới thực. Đối với một hệ thống quản lý thư viện, việc áp dụng phương pháp này mang lại hiệu quả vượt trội so với các phương pháp truyền thống. Thay vì tập trung vào các hàm và logic riêng lẻ, hướng đối tượng tập trung vào việc định nghĩa các đối tượng như 'Sách', 'Độc giả', 'Phiếu mượn' và các mối quan hệ giữa chúng. Điều này giúp hệ thống trở nên dễ hiểu, dễ bảo trì và đặc biệt là dễ dàng mở rộng trong tương lai. Các khái niệm cốt lõi như đóng gói (encapsulation), kế thừa (inheritance), và đa hình (polymorphism) cho phép xây dựng một cấu trúc phần mềm linh hoạt và tái sử dụng cao. Một báo cáo phân tích thiết kế hệ thống theo hướng đối tượng sẽ sử dụng Ngôn ngữ Mô hình hóa Thống nhất (UML) để trực quan hóa kiến trúc, hành vi và các thành phần của hệ thống. Các biểu đồ UML không chỉ là công cụ cho lập trình viên mà còn là cầu nối giao tiếp hiệu quả giữa các bên liên quan, từ người quản lý dự án đến khách hàng, đảm bảo mọi yêu cầu đều được hiểu đúng và triển khai chính xác. Việc áp dụng thành công phương pháp này đòi hỏi một quy trình rõ ràng, bắt đầu từ việc thu thập và phân tích yêu cầu hệ thống một cách kỹ lưỡng.

1.1. Tổng quan về phương pháp hướng đối tượng OOAD

Phương pháp hướng đối tượng (Object-Oriented Analysis and Design - OOAD) là một quy trình kỹ thuật phần mềm tập trung vào việc mô hình hóa hệ thống như một tập hợp các đối tượng tương tác với nhau. Phân tích hướng đối tượng (OOA) tập trung vào việc xác định các đối tượng từ miền vấn đề và các mối quan hệ của chúng. Thiết kế hướng đối tượng (OOD) tập trung vào việc định nghĩa các đối tượng phần mềm và cách chúng phối hợp để thực hiện các yêu cầu. Bốn nguyên tắc trụ cột của OOAD bao gồm: Đóng gói (Encapsulation) - che giấu trạng thái bên trong của đối tượng và chỉ cho phép truy cập thông qua các phương thức công khai; Kế thừa (Inheritance) - cho phép một lớp mới (lớp con) thừa hưởng các thuộc tính và phương thức từ một lớp hiện có (lớp cha); Đa hình (Polymorphism) - cho phép các đối tượng có kiểu dữ liệu khác nhau phản hồi cùng một thông điệp theo cách riêng; và Trừu tượng hóa (Abstraction) - tập trung vào các đặc điểm thiết yếu của một đối tượng và bỏ qua các chi tiết không cần thiết. Việc áp dụng các nguyên tắc này giúp tạo ra mã nguồn có tính module, dễ tái sử dụng và dễ quản lý hơn.

1.2. Lợi ích khi áp dụng OOAD vào quản lý thư viện

Áp dụng OOAD vào hệ thống quản lý thư viện mang lại nhiều lợi ích thiết thực. Thứ nhất, nó giúp mô hình hóa hệ thống một cách tự nhiên và gần gũi với thực tế. Các thực thể như 'Độc giả', 'Sách', 'Thủ thư' có thể được ánh xạ trực tiếp thành các lớp (class), giúp việc phân tích trở nên trực quan. Thứ hai, tính tái sử dụng mã nguồn được đề cao. Ví dụ, một lớp 'NguoiDung' có thể được tạo ra, và các lớp 'DocGia' và 'ThuThu' có thể kế thừa từ đó, giúp giảm thiểu sự trùng lặp code. Thứ ba, hệ thống trở nên dễ bảo trì và mở rộng. Khi cần thêm một chức năng mới, chẳng hạn như quản lý tài liệu điện tử, các nhà phát triển chỉ cần tạo một lớp mới mà không làm ảnh hưởng lớn đến các thành phần hiện có. Cuối cùng, việc sử dụng các biểu đồ UML giúp tài liệu hóa hệ thống một cách rõ ràng, tạo điều kiện thuận lợi cho việc chuyển giao và phát triển đội ngũ sau này.

II. Thách thức trong quản lý thư viện vai trò của OOAD

Các hệ thống quản lý thư viện truyền thống thường gặp phải nhiều thách thức đáng kể. Việc quản lý thủ công hoặc bằng các phần mềm cũ kỹ dẫn đến sai sót trong việc theo dõi hàng ngàn đầu sách và hàng vạn lượt mượn trả. Các quy trình như quản lý mượn trả sách, quản lý độc giả, và thống kê báo cáo tốn nhiều thời gian và nguồn lực của thủ thư. Theo báo cáo của nhóm sinh viên Đại học Bách Khoa Hà Nội, "số lượng đầu sách, tài liệu cũng như số lượng độc giả... ngày một tăng cao, dẫn tới những phương pháp và cơ chế quản lý thư viện truyền thống đang gặp những vấn đề phức tạp". Các vấn đề thường gặp bao gồm: khó khăn trong việc tìm kiếm sách, quản lý tình trạng sách (đang được mượn, quá hạn, bị hỏng), xử lý vi phạm của độc giả và tạo báo cáo thống kê chính xác. Phân tích và thiết kế hướng đối tượng ra đời như một giải pháp toàn diện cho những thách thức này. Bằng cách mô hình hóa hệ thống thành các đối tượng có thuộc tính và hành vi rõ ràng, OOAD giúp tự động hóa và tối ưu hóa các quy trình nghiệp vụ phức tạp, giảm thiểu sai sót do con người và nâng cao hiệu suất hoạt động. Đây là nền tảng để xây dựng một đồ án công nghệ phần mềm vững chắc và hiệu quả.

2.1. Các vấn đề của hệ thống quản lý thủ công

Quản lý thư viện theo phương pháp thủ công hoặc các phần mềm thế hệ cũ tồn tại nhiều hạn chế. Việc ghi chép thông tin mượn trả trên sổ sách dễ gây thất lạc và sai sót dữ liệu. Quá trình tìm kiếm thông tin một cuốn sách hoặc một độc giả cụ thể tốn nhiều thời gian, làm giảm trải nghiệm của người dùng. Việc kiểm soát sách quá hạn và xử lý vi phạm không được thực hiện kịp thời, gây tổn thất cho thư viện. Ngoài ra, việc tổng hợp và lập báo cáo thống kê, ví dụ như thống kê sách được mượn nhiều nhất hay độc giả vi phạm, là một công việc nặng nhọc và không đảm bảo tính chính xác. Những vấn đề này trực tiếp ảnh hưởng đến hiệu quả hoạt động của thư viện và sự hài lòng của độc giả, đòi hỏi một giải pháp công nghệ hiện đại hơn.

2.2. Vai trò của OOAD trong việc giải quyết vấn đề

OOAD đóng vai trò then chốt trong việc khắc phục các nhược điểm của hệ thống quản lý truyền thống. Bằng cách phân tích yêu cầu hệ thống một cách bài bản, OOAD giúp xác định chính xác các chức năng cần có như quản lý sách, quản lý độc giả, và quản lý mượn trả sách. Thông qua việc mô hình hóa hệ thống bằng UML, các quy trình nghiệp vụ phức tạp được đơn giản hóa và chuẩn hóa. Ví dụ, một đối tượng 'PhieuMuon' có thể tự động kiểm tra ngày hết hạn và thay đổi trạng thái, giúp thủ thư dễ dàng theo dõi. Nguyên tắc đóng gói đảm bảo dữ liệu được toàn vẹn, tránh các thay đổi không mong muốn. Do đó, OOAD không chỉ là một phương pháp lập trình mà còn là một công cụ tư duy giúp tổ chức và cấu trúc lại toàn bộ hoạt động của thư viện một cách logic và hiệu quả.

III. Phương pháp phân tích yêu cầu hệ thống thư viện với UML

Giai đoạn phân tích yêu cầu hệ thống là nền tảng cho bất kỳ dự án phần mềm thành công nào. Trong phương pháp hướng đối tượng, giai đoạn này được hỗ trợ mạnh mẽ bởi Ngôn ngữ Mô hình hóa Thống nhất (UML). Mục tiêu chính là xác định rõ ràng hệ thống sẽ làm gì, các tác nhân là ai và họ tương tác với hệ thống như thế nào. Biểu đồ use case là công cụ trung tâm trong giai đoạn này. Dựa trên tài liệu nghiên cứu, hệ thống quản lý thư viện có ba tác nhân chính: Khách (chưa đăng nhập), Thủ thư, và Quản trị viên. Biểu đồ use case tổng quan sẽ mô tả các chức năng chính mà mỗi tác nhân có thể thực hiện, chẳng hạn như "Quản lý sách", "Quản lý mượn, trả sách", "Quản lý độc giả", và "Thống kê". Từ đó, mỗi use case lớn sẽ được phân rã thành các use case nhỏ hơn, chi tiết hơn. Ví dụ, use case "Quản lý sách" được phân rã thành "Thêm sách", "Tìm kiếm sách", "Xóa sách", và "Sửa thông tin sách". Việc đặc tả chi tiết từng use case (bao gồm tác nhân, mục đích, luồng sự kiện chính, luồng thay thế) đảm bảo rằng tất cả các yêu cầu chức năng và phi chức năng đều được ghi nhận và thấu hiểu trước khi chuyển sang giai đoạn thiết kế, tạo nên một báo cáo phân tích thiết kế hệ thống hoàn chỉnh.

3.1. Kỹ thuật xác định tác nhân và biểu đồ use case

Bước đầu tiên trong phân tích yêu cầu hệ thống là xác định các tác nhân (Actors) - những người hoặc hệ thống bên ngoài tương tác với hệ thống đang xây dựng. Trong hệ thống thư viện, các tác nhân bao gồm 'Độc giả', 'Thủ thư', và 'Quản trị viên'. Sau khi xác định tác nhân, biểu đồ use case được sử dụng để mô hình hóa các chức năng mà hệ thống cung cấp cho mỗi tác nhân. Mỗi use case đại diện cho một hành động cụ thể có giá trị, ví dụ UC006 “Lập phiếu mượn” hay UC015 “Thống kê độc giả vi phạm”. Biểu đồ này cung cấp một cái nhìn tổng quan, cấp cao về các yêu cầu chức năng của hệ thống, giúp đội ngũ phát triển và các bên liên quan có chung một cách hiểu về phạm vi và mục tiêu của dự án.

3.2. Phân tích yêu cầu chức năng và phi chức năng

Yêu cầu chức năng mô tả những gì hệ thống phải làm. Đây là các chức năng cụ thể được thể hiện qua các use case như quản lý sách, tìm kiếm, đăng nhập, lập phiếu mượn. Mỗi chức năng này cần được đặc tả chi tiết về luồng sự kiện, điều kiện tiên quyết và hậu điều kiện. Ngược lại, yêu cầu phi chức năng định nghĩa cách hệ thống thực hiện các chức năng đó, liên quan đến các tiêu chí về chất lượng như hiệu năng, bảo mật, và giao diện người dùng. Ví dụ, tài liệu đề tài yêu cầu "Thời gian phản hồi của hệ thống tối đa 6s" (yêu cầu hiệu năng) và "người dùng chỉ có thể truy cập được các chức năng và các thông tin phù hợp với vai trò" (yêu cầu bảo mật). Cả hai loại yêu cầu này đều quan trọng như nhau để xây dựng một phần mềm hoàn chỉnh và đáp ứng đúng nhu cầu người dùng.

IV. Bí quyết thiết kế hướng đối tượng Sơ đồ lớp và CSDL

Sau khi hoàn tất giai đoạn phân tích, giai đoạn thiết kế hướng đối tượng bắt đầu, chuyển các yêu cầu đã xác định thành một bản thiết kế chi tiết sẵn sàng cho việc lập trình. Trọng tâm của giai đoạn này là xây dựng các mô hình cấu trúc và hành vi của hệ thống. Sơ đồ lớp (class diagram) là biểu đồ quan trọng nhất, mô tả cấu trúc tĩnh của hệ thống bằng cách hiển thị các lớp (class), thuộc tính, phương thức và mối quan hệ giữa chúng (association, aggregation, inheritance). Ví dụ, lớp 'Sach' sẽ có các thuộc tính như 'maSach', 'tenSach', 'tacGia' và các phương thức như 'kiemTraTrangThai()'. Lớp 'DocGia' và 'ThuThu' có thể kế thừa từ một lớp cha 'NguoiDung'. Bên cạnh đó, các biểu đồ tương tác như biểu đồ tuần tự (sequence diagram) và biểu đồ hoạt động (activity diagram) được sử dụng để mô hình hóa hành vi động của hệ thống. Biểu đồ tuần tự cho thấy trình tự các thông điệp được trao đổi giữa các đối tượng để thực hiện một use case cụ thể, trong khi biểu đồ hoạt động mô tả luồng công việc của một quy trình nghiệp vụ. Cuối cùng, từ sơ đồ lớp, việc thiết kế cơ sở dữ liệu (CSDL) được tiến hành, trong đó mỗi lớp thường được ánh xạ thành một bảng trong CSDL quan hệ.

4.1. Xây dựng sơ đồ lớp class diagram cho hệ thống

Sơ đồ lớp (class diagram) là xương sống của mô hình thiết kế hướng đối tượng. Nó không chỉ xác định các lớp cần thiết cho hệ thống như DocGia, Sach, PhieuMuon, ThuThu, mà còn định nghĩa rõ các thuộc tính (dữ liệu) và phương thức (hành vi) của chúng. Quan trọng hơn, sơ đồ lớp thể hiện các mối quan hệ logic giữa các lớp: quan hệ một-nhiều (ví dụ: một độc giả có thể mượn nhiều sách), quan hệ kế thừa (ví dụ: ThuThu là một loại NguoiDung), và quan hệ kết hợp. Một sơ đồ lớp được thiết kế tốt sẽ đảm bảo tính đóng gói, che giấu dữ liệu không cần thiết và chỉ cung cấp các giao diện cần thiết để tương tác, tạo ra một cấu trúc hệ thống rõ ràng và logic.

4.2. Thiết kế cơ sở dữ liệu từ mô hình đối tượng

Việc thiết kế cơ sở dữ liệu là bước chuyển đổi từ mô hình logic (sơ đồ lớp) sang mô hình vật lý (các bảng dữ liệu). Quy tắc phổ biến là mỗi lớp bền vững (persistent class) trong sơ đồ lớp sẽ được ánh xạ thành một bảng trong cơ sở dữ liệu quan hệ. Các thuộc tính của lớp trở thành các cột của bảng, và mỗi đối tượng của lớp tương ứng với một hàng trong bảng. Các mối quan hệ giữa các lớp (ví dụ: một-một, một-nhiều) được thể hiện thông qua các khóa ngoại (foreign keys). Ví dụ, bảng phieu_muon sẽ chứa một khóa ngoại ma_doc_gia để tham chiếu đến bảng doc_gia. Quá trình này đòi hỏi phải chuẩn hóa dữ liệu để đảm bảo tính nhất quán, toàn vẹn và giảm thiểu sự dư thừa, tạo ra một CSDL hiệu quả cho việc lưu trữ và truy xuất thông tin.

4.3. Mô hình hóa hành vi với biểu đồ tuần tự và hoạt động

Nếu sơ đồ lớp mô tả cấu trúc tĩnh, thì biểu đồ tuần tự (sequence diagram) và biểu đồ hoạt động (activity diagram) mô tả hành vi động. Biểu đồ tuần tự trực quan hóa sự tương tác giữa các đối tượng theo thời gian. Nó cho thấy chính xác đối tượng nào gọi phương thức của đối tượng nào và theo thứ tự nào để hoàn thành một chức năng, ví dụ như quy trình "Lập phiếu mượn". Trong khi đó, biểu đồ hoạt động tập trung vào luồng công việc, mô tả các bước và các quyết định trong một quy trình từ đầu đến cuối. Ví dụ, nó có thể mô tả luồng xử lý trả sách, bao gồm các bước kiểm tra sách, kiểm tra vi phạm, và cập nhật trạng thái. Cả hai biểu đồ này đều là công cụ hữu ích để làm rõ logic nghiệp vụ và đảm bảo hệ thống hoạt động đúng như mong đợi.

V. Case study Ứng dụng OOAD trong đồ án quản lý thư viện

Để minh họa tính thực tiễn của phương pháp phân tích và thiết kế hướng đối tượng, chúng ta có thể xem xét đồ án công nghệ phần mềm về Hệ thống quản lý thư viện do nhóm sinh viên Đại học Bách Khoa Hà Nội thực hiện. Đồ án này là một ví dụ điển hình về việc áp dụng lý thuyết OOAD vào giải quyết một bài toán thực tế. Nhóm đã bắt đầu bằng việc phân tích yêu cầu hệ thống một cách chi tiết, định nghĩa rõ ràng các tác nhân và xây dựng hệ thống biểu đồ use case phân cấp, từ tổng quan đến chi tiết cho từng nghiệp vụ như quản lý mượn trả sách và quản lý độc giả. Trong giai đoạn thiết kế, sơ đồ lớp (class diagram) được xây dựng để thể hiện cấu trúc của các đối tượng chính như TaiKhoan, ThuThu, DocGia, Sach, PhieuMuon. Các mối quan hệ phức tạp như kế thừa và liên kết được mô hình hóa cẩn thận. Bên cạnh đó, các biểu đồ tuần tự và biểu đồ hoạt động được sử dụng để làm rõ luồng xử lý cho các chức năng quan trọng như "Xử lý trả sách" và "Lập phiếu mượn". Kết quả của dự án không chỉ là một phần mềm hoạt động mà còn là một bộ báo cáo phân tích thiết kế hệ thống chi tiết, thể hiện rõ ràng quá trình áp dụng các nguyên lý hướng đối tượng để tạo ra một sản phẩm chất lượng cao.

5.1. Phân tích các use case chính Quản lý sách độc giả

Trong đồ án, nhóm nghiên cứu đã phân rã các chức năng lớn thành các use case cụ thể. Nhóm use case “Quản lý sách” bao gồm các chức năng cơ bản như Thêm, Sửa, Xóa, và Tìm kiếm sách (UC001-UC005). Tương tự, nhóm use case “Quản lý độc giả” (UC010-UC014) cho phép thủ thư quản lý thông tin người mượn. Việc đặc tả chi tiết từng use case, bao gồm cả luồng sự kiện thành công và các luồng thay thế (ví dụ: thông báo lỗi khi mã sách đã tồn tại), đã đảm bảo các yêu cầu nghiệp vụ được nắm bắt đầy đủ. Cách tiếp cận này giúp việc phát triển trở nên có hệ thống và giảm thiểu rủi ro bỏ sót yêu cầu.

5.2. Thiết kế chi tiết cho nghiệp vụ quản lý mượn trả sách

Nghiệp vụ quản lý mượn trả sách là một trong những nghiệp vụ phức tạp nhất. Đồ án đã sử dụng biểu đồ hoạt động để mô tả quy trình từ lúc độc giả yêu cầu mượn đến khi trả sách và xử lý vi phạm. Đồng thời, biểu đồ tuần tự được dùng để minh họa sự tương tác giữa các đối tượng ThuThu, PhieuMuon, và Sach trong quá trình lập phiếu mượn. Bản thiết kế đã xác định rõ các lớp liên quan như PhieuMuon, BienBanViPham, MuonSach, và thiết kế các bảng cơ sở dữ liệu tương ứng. Cách tiếp cận này đảm bảo logic nghiệp vụ được cài đặt chính xác và dữ liệu được quản lý một cách nhất quán.

VI. Kết luận và định hướng phát triển cho hệ thống thư viện

Qua phân tích, có thể khẳng định rằng phân tích và thiết kế hướng đối tượng là một phương pháp luận mạnh mẽ và phù hợp để xây dựng các hệ thống quản lý thư viện hiện đại. Cách tiếp cận này không chỉ giải quyết hiệu quả các thách thức của mô hình quản lý truyền thống mà còn tạo ra một nền tảng phần mềm vững chắc, linh hoạt và dễ bảo trì. Việc sử dụng UML để mô hình hóa hệ thống từ giai đoạn phân tích đến thiết kế giúp đảm bảo sự nhất quán và rõ ràng trong toàn bộ quá trình phát triển. Các khái niệm cốt lõi như lớp, đối tượng, kế thừa, và đóng gói giúp cấu trúc hóa hệ thống một cách logic, phản ánh đúng bản chất của các thực thể trong thế giới thực. Trong tương lai, hệ thống có thể được phát triển thêm nhiều tính năng nâng cao như tích hợp với các nguồn tài liệu số, ứng dụng di động cho độc giả, hoặc sử dụng trí tuệ nhân tạo để gợi ý sách. Nhờ vào kiến trúc hướng đối tượng, việc tích hợp các chức năng mới này sẽ trở nên thuận lợi hơn rất nhiều. Tóm lại, việc đầu tư vào một quy trình phân tích thiết kế hệ thống bài bản theo hướng đối tượng là yếu tố then chốt cho sự thành công của bất kỳ đồ án công nghệ phần mềm quản lý thư viện nào.

6.1. Tóm tắt ưu điểm của phương pháp hướng đối tượng

Tóm lại, phương pháp hướng đối tượng mang lại ba ưu điểm chính cho việc phát triển hệ thống quản lý thư viện. Một là, tính tự nhiên và dễ hiểu, giúp mô hình hóa các thực thể và quy trình phức tạp một cách trực quan. Hai là, khả năng tái sử dụng cao thông qua kế thừa và composition, giúp tiết kiệm thời gian và công sức phát triển. Ba là, tính linh hoạt và dễ bảo trì, cho phép hệ thống dễ dàng thích ứng với các thay đổi và mở rộng chức năng trong tương lai mà không phá vỡ cấu trúc hiện có. Những ưu điểm này làm cho OOAD trở thành lựa chọn hàng đầu cho các dự án phần mềm quy mô lớn và có vòng đời dài.

6.2. Hướng phát triển trong tương lai cho hệ thống

Một hệ thống quản lý thư viện được xây dựng trên nền tảng hướng đối tượng vững chắc mở ra nhiều tiềm năng phát triển. Trong tương lai, hệ thống có thể được mở rộng để quản lý tài nguyên số (e-books, audiobooks), tích hợp cổng thanh toán trực tuyến cho các khoản phạt, và phát triển một ứng dụng di động cho phép độc giả tìm kiếm, đặt trước sách và nhận thông báo. Ngoài ra, việc áp dụng các công nghệ mới như phân tích dữ liệu lớn để hiểu rõ hơn về thói quen đọc của độc giả, hay xây dựng hệ thống gợi ý sách cá nhân hóa cũng là những hướng đi đầy hứa hẹn. Kiến trúc module hóa của OOAD sẽ là một lợi thế lớn khi tích hợp các công nghệ tiên tiến này.

Trích đoạn nội dung tài liệu

Chương 1: Giới thiệu đề tài nhằm mục đích cung cấp cho người đọc cái nhìn tổng quát về hệ thống Quản li thư viện, cũng như về các tài liệu phân tích chi tiết hơn ở phần sau - Chương 2: Phân tích yêu cầu phần mềm trình bày sơ đồ hoạt động, use case tổng quan và các use case cụ thể của hệ thống, đặc tả chức năng và các ràng buộc với chức năng đó của hệ thống. - Chương 3: Thiết kế hệ thống trình bày cấu trúc, kiến trúc tổng thể của hệ thống qua thao tác mô hình hóa, sau đó đi vào các thiết kế chi tiết lớp cũng như giao diện 8 CHƯƠNG 2. PHÂN TÍCH YÊU CẦU PHẦN MỀM 2. Yêu cầu tổng quan về nghiệp vụ 2.

Phân tích nghiệp vụ Để có thể thiết kế được một hệ thống quản lý thư viện, trước tiên chúng ta cần hiểu được các luồng sự kiện có thể diễn ra trên hệ thống Sau đây là quy trình nghiệp vụ của thủ thư: Khi có người mượn sách: Khi có người trả sách: 9 Khi có người làm thẻ độc giả: 10 2. Quy tắc nghiệp vụ Đối với việc mượn, trả sách: - Độc giả chỉ được mượn tối đa 3 cuốn sách hoặc tài liệu mỗi lần mượn - Đối với cùng 1 cuốn sách mượn, độc giả chỉ được gia hạn trả sách tối đa 2 lần, mỗi lần được phép gia hạn tối đa 1 tuần Đối với các lỗi vi phạm: Độc giả vi phạm các lỗi sau sẽ được ghi nhận vào hệ thống độc giả vi phạm của hệ thống - Làm hư, hỏng, không giữ được tính toàn vẹn của sách mượn - Không trả sách theo đúng kỳ hạn - Khai báo gian dối các thông tin khi làm thẻ độc giả 11 2. Các tác nhân của hệ thống Hệ thống gồm 3 tác nhân: Khách, Thủ thư và Quản trị viên - Khách: là người dùng thường, chưa đăng nhập vào hệ thống. Họ chỉ có thể sử dụng chức năng tìm kiếm, xem chi tiết sách và tài liệu của hệ thống.

Sau khi đăng nhập mới có thể sử dụng các chức năng khác tương ứng với loại tài khoản của họ. - Quản trị viên: là quản trị viên của thư viện. Sau khi đã đăng nhập tài khoản vai trò Quản trị viên, họ có thể sử dụng chức năng quản lí các tài khoản có vai trò thủ thư - Thủ thư: là thủ thư của thư viện. Sau khi đăng nhập tài khoản với vai trò thủ thư, họ có thể sử dụng các chức năng quản lí như quản lí sách, quản lí việc mượn, trả sách, quản lí độc giả, thống kê số liệu, cập nhật thông tin cá nhân để quản lí hoạt động của thư viện.

Phân tích yêu cầu chức năng 2. Biểu đồ use case tổng quan của hệ thống 2. Phân rã use case “Quản lý sách” 13 2. Phân rã use case “Quản lý mượn, trả sách” 2.

Phân rã use case “Quản lý độc giả” 14 2. Phân rã use case “Thống kê” 2. Phân rã use case “Quản lý tài khoản thủ thư” 2. Đặc tả use case 2.

Nhóm use case “Quản lý sách” UC001 “Thêm sách” Mã Use case UC001 Tên Use case Thêm sách Tác nhân Thủ thư Mục đích ca sử Thủ thư sử dụng use case thêm sách vào hệ thống dụng 15 Sự kiện kích Thủ thư chọn chức năng thêm sách hoạt Tiền điều kiện không có Luồng sự kiện chính ST Thực hiện Hành động (Thành công) T bởi 1. Thủ thư Chọn chức năng thêm sách 2. Hệ thống HIển thị form điền thông tin sách 3. Thủ thư Nhập thông tin về sách 4.

Hệ thống Kiểm tra các trường thông tin đã được nhập đầy đủ chưa 5. Hệ thống Kiểm tra mã sách có bị trùng lặp 6. Hệ thống Lưu thông tin sách, thông báo lưu thành công Luồng sự kiện thay thế STT Thực hiện Hành động bởi 5a. Hệ thống Thông báo “Cần nhập hết các trường bắt buộc” 6b.

Hệ thống Thông báo “Mã sách đã tồn tại” Hậu điều kiện Hệ thống thông báo thêm thành công * Dữ liệu đầu vào gồm các trường dữ liệu sau: Trường dữ STT Bắt buộc? Điều kiện hợp lệ Ví dụ liệu 1 Mã sách Có TT.TH201 2 Tên sách Có Dế mèn phiêu lưu kí 3 Tên tác giả Có Tô Hoài 4 Nhà xuất bản Có Kim Đồng 5 Năm xuất bản Có 2018 UC002 “Tìm kiếm sách” 16 Mã Use case UC002 Tên Use case Tìm kiếm sách Tác nhân Khách Mục đích ca sử dụng Tìm kiếm thông tin về sách dựa vào tên sách, tên tác giả, lĩnh vực Sự kiện kích hoạt Người dùng chọn vào chức năng tìm kiếm sách Tiền điều kiện không Luồng sự kiện chính STT Thực hiện bởi Hành động (Thành công) 1. Người dùng Chọn chức năng tìm kiếm sách 2. Hệ thống Hiển thị thanh tìm kiếm gồm các trường: Tên tác giả, Tên sách và ô lựa chọn Lĩnh vực 3. Người dùng Nhập/chọn thông tin vào các trường.

Hệ thống Tìm kiếm, hiển thị danh sách các kết quả trùng khớp • Nếu muốn xem chi tiết thông tin sách thì chọn nghiệp vụ “xem chi tiết sách” Luồng sự kiện thay STT Thực hiện bởi Hành động thế 5a. Hệ thống Thông báo “Không có kết quả trùng khớp” Hậu điều kiện Hiển thị danh sách kết quả tìm kiếm UC003 “Xem chi tiết sách” Mã Use case UC003 Tên Use case Xem chi tiết sách Tác nhân Thủ thư Mục đích ca sử dụng Xem thông tin chi tiết sách Sự kiện kích hoạt Thủ thư chọn chức năng xem chi tiết Tiền điều kiện không có 17 Luồng sự kiện chính (Thành công) Thực hiện bởi Hành động STT 1 Thủ thư Chọn sách từ danh sách 2. Thủ thư Chọn xem chi tiết Hệ thống Hiển thị các thông tin về sách • Nếu muốn chỉnh sửa thông tin, thủ thư thực hiện nghiệp vụ “Sửa thông 3. tin sách” • Nếu muốn xóa sách, thủ thư thực hiện nghiệp vụ “Xóa sách” Luồng sự kiện thay Không có thế Hậu điều kiện Hệ thống thông báo xóa sách thành công UC004 “Xóa sách” Mã Use case UC004 Tên Use case Xóa sách Tác nhân Thủ thư Mục đích ca sử dụng Thủ thư sử dụng use case để xóa sách trong hệ thống Sự kiện kích hoạt Thủ thư chọn chức năng xóa sách Tiền điều kiện không có Luồng sự kiện chính (Thành công) Thực hiện bởi Hành động STT 1.

Thủ thư Chọn sách muốn xóa 2. Thủ thư Chọn xóa sách 3. Hệ thống Hiển thị pop up Xác nhận xóa 4. Thủ thư Chọn Xác nhận 5.

Hệ thống Xóa sách khỏi hệ thống, thông báo xóa thành công 18 Luồng sự kiện thay thế STT Thực hiện bởi Hành động 5a Thông báo “Sách hiện đang được mượn, không Hệ thống thể xóa” 4b Thủ thư Chọn Hủy 5b Hệ thống Không thực hiện nghiệp vụ nào Hậu điều kiện Hệ thống thông báo xóa sách thành công UC005 “Sửa thông tin sách” Mã Use case UC005 Tên Use case Sửa thông tin sách Tác nhân Thủ thư Mục đích ca sử dụng Thủ thư sửa thông tin sách Sự kiện kích hoạt Thủ thư chọn chức năng Sửa thông tin sách Tiền điều kiện không Luồng sự kiện chính STT Thực hiện bởi Hành động (Thành công) 1. Thủ thư Chọn sửa thông tin 2. Hệ thống Hiển thị form sửa thông tin 3. Thủ thư Chỉnh sửa các trường cần thiết 4.

Thủ thư Chọn Lưu lại 5. Hệ thống Hiển thị pop-up xác nhận 6. Thủ thư Chọn Xác nhận 7. Hệ thống Kiểm tra các trường thông tin đã đầy đủ 8.

Hệ thống Lưu lại thay đổi, thông báo chỉnh sửa thành công Luồng sự kiện thay STT Thực hiện bởi Hành động thế 6a. Thủ thư Chọn hủy 7a. Hệ thống Quay về màn hình form chỉnh sửa 8b. Hệ thống Báo lỗi “Cần điền đầy đủ thông tin” Hậu điều kiện Hiển thị thông báo chỉnh sửa thành công 19 2.

Nhóm use case “Quản lý mượn, trả sách” UC006 “Lập phiếu mượn” Mã Use case UC006 Tên Use case Lập phiếu mượn Tác nhân Thủ thư Mục đích ca sử dụng Thủ thư sử dụng use case để lưu lại thông tin mượn sách của độc giả Sự kiện kích hoạt Thủ thư chọn chức năng lập phiếu mượn Tiền điều kiện không có Luồng sự kiện chính STT Thực hiện bởi Hành động (Thành công) 1. Thủ thư Chọn chức năng Lập phiếu mượn 2. Hệ thống HIển thị form phiếu mượn 3. Thủ thư Nhập mã độc giả 4.

Thủ thư Nhập/chọn sách mà độc giả mượn 5. Thủ thư Chọn nút Tạo phiếu mượn 6. Hệ thống Kiểm tra các trường thông tin đã đầy đủ chưa 7. Hệ thống Kiểm tra thông tin độc giả 8.

Hệ thống Hiển thị phiếu mượn hoàn chỉnh 9. Thủ thư Chọn Hoàn tất 10. Hệ thống Lưu thông tin phiếu mượn, thông báo tạo phiếu mượn thành công Luồng sự kiện thay STT Thực hiện bởi Hành động thế 6a. Hệ thống Thông báo “chưa có thông tin sách hoặc độc giả” 7a.

Hệ thống Thông báo “độc giả không đủ điều kiện mượn sách” STT Thực hiện bởi Hành động 8b. Thủ thư Chọn hủy 9b. Hệ thống Quay về màn hình form phiếu mượn Hậu điều kiện Hệ thống thông báo tạo phiếu mượn thành công * Dữ liệu đầu vào gồm các trường dữ liệu sau: 20 Trường dữ STT Bắt buộc? Điều kiện hợp lệ Ví dụ liệu 1 Mã độc giả Có DG102 UC007 “Gia hạn phiếu mượn” Mã Use case UC007 Tên Use case Gia hạn phiếu mượn Tác nhân Thủ thư Mục đích ca sử dụng Thủ thư sử dụng khi có yêu cầu gia hạn từ độc giả Sự kiện kích hoạt Thủ thư chọn chức năng Gia hạn Tiền điều kiện Không Luồng sự kiện chính STT Thực hiện bởi Hành động (Thành công) 1. Hệ thống Hiển thị danh sách phiếu mượn 2.

Thủ thư Chọn phiếu mượn cần gia hạn 3. Hệ thống Hiển thị chi tiết phiếu mượn và các lựa chọn mức gia hạn 4. Thủ thư Chọn mức gia hạn, nhấn Xác nhận 5. Hệ thống Kiểm tra thông tin phiếu mượn và độc giả 6.

Hệ thống Thông báo “Gia hạn thành công”, cập nhật thông tin phiếu mượn Luồng sự kiện thay STT Thực hiện bởi Hành động thế 7a. Hệ thống Thông báo “Không đủ điều kiện gia hạn” Hậu điều kiện Hệ thống thông báo gia hạn thành công UC008 “Xử lý trả sách” Mã Use case UC008 Tên Use case Xử lý trả sách Tác nhân Thủ thư Mục đích ca sử dụng Thủ thư sử dụng use case khi có yêu cầu trả sách từ độc giả Sự kiện kích hoạt Thủ thư chọn chức năng Xử lý trả sách Tiền điều kiện không 21 Luồng sự kiện chính STT Thực hiện bởi Hành động (Thành công) 1. Hệ thống Hiển thị danh sách phiếu mượn 2. Thủ thư Chọn phiếu mượn 3.

Hệ thống Hiển thị chi tiết phiếu mượn • Nếu phát hiện vi phạm, thủ thư chọn thực hiện nghiệp vụ “Xử lý vi phạm” 4. Thủ thư Chọn Xác nhận 5.