Xây dựng hệ thống quản lý và đánh giá sách xuất bản tại việt nam

Mục tiêu đề tài

Xây dựng website đánh giá sách xuất bản tại Việt Nam nhằm cho người đọc thấy những đánh giá tổng quát để có thể dễ dàng lựa chọn những đầu sách phù hợp với bản thân Cụ thể cần đạt được những mục tiêu sau:

 Đối khách vãng lai chưa phải là thành viên: gồm các chức năng cơ bản

- Xem danh sách danh mục.

- Xem chi tiết sách xuất bản.

- Tìm kiếm (theo tên, theo tóm tắt, theo nhà xuất bản,…).

- Xem đánh giá và bình luận của thành viên.

 Đối với khách là thành viên: giống với khách vãng lai chưa phải là thành viên và có thêm một số chức năng

- Lựa chọn tủ sách cho cuốn sách.

- Xếp hạng và bình luận cho sách.

- Xoá sách khỏi tủ sách

- Chỉnh sửa hồ sơ cá nhân.

- Xem hồ sơ của người dùng khác.

- Chọn “đồng tình” hoặc “không đồng tình” đối với mỗi bình luận

 Đối với điều phối viên: bao gồm các chức năng quản lý

- Xem danh sách thành viên.

- Cấm thành viên truy cập.

- Quản lý sách xuất bản.

 Đối với quản trị viên: giống với điều phối viên và có thêm một số chức năng

- Xem thống kê (theo số lượng đầu sách xuất bản, theo số lượng thành viên, theo số lượng danh mục, theo số lượng điều phối viên, số lượng bình luận…).

- Quản lý điều phối viên.

Phương pháp nghiên cứu

Sinh viên thực hiện: Nguyễn Nhã Trúc Người hướng dẫn: ThS Nguyễn Nguyễn Thị Hà Quyên 1

Xây dựng hệ thống quản lý và đánh giá sách xuất bản tại Việt Nam

 Phương pháp nghiên cứu lý thuyết thu thập thông tin qua internet, tài liệu, sách để tìm được các cơ sở lý thuyết liên quan vấn đề mình nghiên cứu.

 Phương pháp triển khai thực nghiệm: xây dựng website.

Giải pháp công nghệ

 Hệ quản trị cơ sở dữ liệu: MongoDB

 Hỗ trợ mã nguồn: Visual Studio Code.

 Lưu trữ file: Google Cloud Storage

Cấu trúc đồ án

Cấu trúc đồ án tốt nghiệp gồm các phần như sau:

- Chương 1: Cơ sở lý thuyết.

- Chương 2: Phân tích thiết kế hệ thống

- Chương 3: Xây dựng chương trình.

- Kết luận và hướng phát triển

CƠ SỞ LÝ THUYẾT

Ngôn ngữ lập trình JavaScript

JavaScript là một trong ba ngôn ngữ chính của lập trình web, và nó được dùng phổ biến trong suốt 20 năm qua Từ thuở sơ khai, nó còn có tên là Mocha (năm 1995), sau đó được đổi thành Mona, Livescript, và cuối cùng là JavaScript như hiện nay.

Brendan Eich chính là người đã phát triển Javascript tại Netscape với tiền thân là Mocha Sau đó, Mocha được đổi thành LiveScript và cuối cùng mới đổi thành JavaScript.

 Năm 1998, JavaScript với phiên bản mới nhất là ECMAScript 2 phát hành và đến năm 1999 thì ECMAScript 3 được ra mắt

 Năm 2016, ứng dụng JavaScript đã đạt kỷ lục lên tới 92% website sử dụng,đồng thời cũng được đánh giá là một công cụ cực kỳ quan trọng đối với lập trình viên.

ReactJS Framework

ReactJS là một opensource được phát triển bởi Facebook, ra mắt vào năm

2013, bản thân nó là một thư viện Javascript được dùng để để xây dựng các tương tác với các thành phần trên website Hầu hết các tính năng hay sức mạnh của ReactJS thường bắt đầu từ việc tập trung vào các phần riêng lẻ Do đó thay vì làm việc trên toàn bộ ứng dụng của website thì ReactJS lại cho phép các Developer phá vỡ giao diện phức tạp của người dùng trở nên đơn giản hơn nhiều Điều này có nghĩa là các Render dữ liệu không chỉ được thực hiện ở vị trí server mà còn có thể thực hiện ở vị trí Client khi sử dụng ReactJS.

ReactJS tạo ra cho bản thân nó một Virtual Dom, nơi các Component được tồn tại trên đó và việc tạo ra Dom giúp cải thiện hiệu suất làm việc tốt hơn Khi bạn cần cập nhật các thông tin lên Dom hoặc thay đổi gì đó, ReactJS đều có thể tính toán trước và thực hiện chúng Nhờ đó mà ReactJS sẽ tránh được các thao tác cần có trên Dom và không tốn thêm bất cứ hành động nào khác

Việc viết code trở nên dễ dàng hơn bởi nó sử dụng một cú pháp đặc biệt là JSX, cho phép trộn được giữa code HTML và JavaScript Bên cạnh đó người dùng có thể sử dụng đoạn code này để thêm vào hàm Render mà không cần thực hiện việc nối chuỗi Điều này được đánh giá là một trong những đặc tính mới cực kỳ thú vị của ReactJS Đồng thời, việc chuyển đổi các đoạn HTML thành các hàm khởi động đều được thực hiện từ bộ biến đổi chính là JSX

ReactJS có nhiều công cụ phát triển nhờ cài đặt thêm ứng dụng mở rộng củaChrome chuyên sử dụng cho ReactJS Các lập trình viên có thể debug code một cách dễ dàng hơn, giúp bạn quan sát trực tiếp vào Virtual Dom.

Tổng quan về Express.js

Expressjs hay còn được viết là Express js, Express.js Đây là một framework mã nguồn mở miễn phí cho Node.js Express.js được sử dụng trong thiết kế và xây dựng các ứng dụng web một cách đơn giản và nhanh chóng.

Vì Express js chỉ yêu cầu ngôn ngữ lập trình Javascript nên việc xây dựng các ứng dụng web và API trở nên đơn giản hơn với các lập trình viên và nhà phát triển.Expressjs cũng là một khuôn khổ của Node.js do đó hầu hết các mã code đã được viết sẵn cho các lập trình viên có thể làm việc.

Nhờ có Expressjs mà các nhà lập trình có thể dễ dàng tạo các ứng dụng 1 web, nhiều web hoặc kết hợp Do có dung lượng khá nhẹ, Expressjs giúp cho việc tổ chức các ứng dụng web thành một kiến trúc MVC có tổ chức hơn.Để có thể sử dụng được mã nguồn này, chúng ta cần phải biết về Javascript và HTML.

Expressjs cũng là một phần của công nghệ giúp quản lý các ứng dụng web một cách dễ dàng hơn hay còn được gọi là ngăn xếp phần mềm MEAN.Nhờ có thư viện Javascript của Express js đã giúp cho các nhà lập trình xây dựng nên các ứng dụng web hiệu quả và nhanh chóng hơn Expressjs cũng được sử dụng để nâng cao các chức năng của Node.js.

Tổng quan hề hệ cơ sở dữ liệu MongoDB

MongoDB là một trong những NoSQL database nổi trội nhất hiện tại.

Cơ sở dữ liệu NoSQL sử dụng nhiều mô hình dữ liệu để truy cập và quản lý dữ liệu Các loại cơ sở dữ liệu này được tối ưu hóa dành riêng cho các ứng dụng yêu cầu mô hình dữ liệu linh hoạt có lượng dữ liệu lớn và độ trễ thấp, có thể đạt được bằng cách giảm bớt một số hạn chế về tính nhất quán của dữ liệu của các cơ sở dữ liệu khác NoSQL ra đời như là một mảnh vá cho những khuyết điểm và thiếu xót cũng như hạn chế của mô hình dữ liệu quan hệ RDBMS (Relational Database Management System - Hệ quản trị cơ sở dữ liệu quan hệ) về tốc độ, tính năng,… Ngoài ra, Với NoSQL bạn có thể mở rộng dữ liệu mà không lo tới những việc như tạo khóa ngoại, khóa chính, kiểm tra ràng buộc v.v

Dữ liệu trong MongoDB không có sự ràng buộc lẫn nhau, không có join như trong RDBMS nên khi insert, xóa hay update nó không cần phải mất thời gian kiểm tra xem có thỏa mãn các ràng buộc dữ liệu như trong RDBMS.

Restful API

Restful API là một trong những tiêu chuẩn được sử dụng để thiết kế API cho các ứng dụng web, để tiện hơn cho việc quản lý các resource Rest API thường chú trọng vào các tài nguyên của hệ thống bao gồm: ảnh, văn bản, âm thanh, video hoặc các dữ liệu di động, Nó thường bao gồm các trạng thái tài nguyên đã được định dạng sẵn và được truyền tải thông qua HTTP.

Một chức năng quan trọng nhất của REST là: quy định các cách sử dụng HTTP method chẳng hạn như: Post, Get, Delete, Put, và cách có thể định dạng các URL cho ứng dụng web để có thể quản lý được các resource Restful không quy định logic code ứng dụng và không được giới hạn bởi những ngôn ngữ lập trình ứng dụng Bất kỳ framework hoặc ngôn ngữ nào cũng có thể được dùng để thiết kế được một Restful API Mà cụ thể ý nghĩa từng phần của cụm từ Rest API sẽ được diễn giải như sau:

 API là từ viết tắt của cụm từ Application Programming Interface, đây là tập hợp những quy tắc và cơ chế mà theo đó thì: Một ứng dụng hoặc một thành phần nào đó sẽ tương tác với một ứng dụng hoặc một số thành phần khác API có thể sẽ được trả về dữ liệu mà người dùng cần cho chính ứng dụng của bạn với những kiểu dữ liệu được dùng phổ biến như JSON hoặc XML

 Rest là từ viết tắt của Representational State Transfer: Nó là một trong những dạng chuyển đổi cấu trúc, với kiểu kiến trúc thường được viết API Rest thường sử dụng dụng phương thức HTTP đơn giản để có thể tạo ra giao tiếp giữa các máy Bởi vì thế, thay vì phải sử dụng một URL cho việc xử lý một

Xây dựng hệ thống quản lý và đánh giá sách xuất bản tại Việt Nam số thông tin của người dùng thì Rest sẽ yêu cầu HTTP như: GET, POST,DELETE, đến với bất kỳ một URL để được xử lý dữ liệu.

PHÂN TÍCH THIẾT KẾ HỆ THỐNG

Khảo sát hệ thống

Hiện nay, nhu cầu mua sách tăng cao, nên các nhà xuất bản gia nhập thị trường sách Việt Nam cũng tăng cao Những đầu sách ngày càng được xuất bản nhiều khiến cho việc chọn lựa cuốn sách phù hợp với yêu cần người dùng trở nên không dễ dàng khi đứng trước quá nhiều lựa chọn Vậy nên website “BookRV” đã ra đời nhằm đáp ứng nhu cầu thiết thực đó.

Việc lựa chọn những cuốn sách phù hợp với bản thân ngày một khó hơn trong khi kinh phí có hạn Vậy nên người dùng muốn được nghe đánh giá khác quan của những người dùng khác để chọn lựa được cuốn sách phù hợp nhất với mình.

Đặc tả yêu cầu phần mềm

2.2.1 Xác định các tác nhân

 Đề tài gồm bốn tác nhân chính

2.2.2 Các yêu cầu chức năng

 Xem danh sách danh mục.

 Xem chi tiết thông tin sách.

 Xem đánh giá về sách.

 Tìm kiếm Sách (lọc theo tên, nội dung, nhà xuất bản,…).

 Xem danh sách danh mục.

 Xem chi tiết thông tin sách.

 Xem đánh giá về sách.

 Tìm kiếm Sách (lọc theo tên, nội dung, nhà xuất bản,…).

 Lựa chọn tủ sách cho cuốn sách

 Xoá sách khỏi tủ sách.

 Xếp hạng và bình luận về sách.

 Sửa xếp hạng và bình luận đã đăng.

 Chọn “Đồng tình” hoặc “Không đồng tình” cho mỗi bình luận

 Chỉnh sửa hồ sơ cá nhân

 Xem hồ sơ của người dùng khác

 Đăng nhập, đăng xuất, đổi mật khẩu.

 Điều phối viên (gồm các chức năng của người dùng )

 Quản lý sách xuất bản

 Quản trị viên (gồm các chức năng của điều phối viên)

 Quản lý điều phối viên.

2.2.3 Yêu cầu phi chức năng

 Giao diện, đẹp mắt, đơn giản, dễ sử dụng.

 Đảm bảo tính bảo mật, an toàn.

 Tốc độ xử lý nhanh chóng.

Sơ đồ Use Case

Hình 2.3.1 Use case khách vãng lai

Hình 2.3.2 Use case Người dùng

Hình 2.3.3 Use case Điều phối viên

Hình 2.3.4 Use case Quản trị viên

Scenario cho Use Case

2.4.1 Scenario Use-case “Đăng ký”

Bảng 2.4.1 Scenario Use-case “Đăng ký”

Use case name Đăng ký

1 Description Khách vãng lai chưa có tài khoản muốn đăng ký vào hệ thống

3 Input Thông tin tài khoản

4 Output Hệ thống thông báo đăng ký thành công thành công

5 Basic flow 1 Khách vãng lai vào website  Bắt đầu use case.

2 Khách vãng lai nhấn vào nút đăng nhập.

3 Khách vãng lai nhấn vào nút đăng ký.

4 Khách vãng lai nhập thông tin tài khoản (tên tài khoản, email, mật khẩu).

5 Khách vãng lai nhấn nút đăng đăng ký.

6 Hệ thống kiểm tra và trả về trang Đăng nhập  Kết thúc use case.

2.1.Khách vãng lai thoát khỏi hệ thống  Use case kết thúc mà chưa được đăng ký

3.1 Khách vãng lai thoát khỏi hệ thống  Use case kết thúc mà chưa được đăng ký

4.1 Nhập sai tài khoản hoặc mật khẩu  Thông báo không tìm thấy tài khoản hoặc sai mật khẩu Quay lại bước 3

2.4.2 Scenario Use-case “Đăng nhập”

Bảng 2.4.1 Scenario Use-case “Đăng nhập”

Use case name Đăng nhập

1 Description Người dùng/Điều phối viên/Quản trị viên đã có tài khoản muón đăng nhập vào hệ thống.

2 Actors Người dùng, Điều phối viên, Quản trị viên đã

3 Input Thông tin tài khoản

4 Output Hệ thống thông báo đăng nhập thành công thành công

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viênvào website  Bắt đầu use case.

2 Người dùng/Điều phối viên/Quản trị viên nhấn vào nút đăng nhập.

3 Người dùng/Điều phối viên/Quản trị viên nhập thông tin tài khoản (email, mật khẩu).

4 Người dùng/Điều phối viên/Quản trị viên nhấn nút đăng đăng nhập.

5 Hệ thống kiểm tra và trả về trang chủ  Kết thúc use case.

2.1 Người dùng/Điều phối viên/Quản trị viên thoát khỏi hệ thống  Use case kết thúc mà chưa được đăng nhập

3.1 Nhập sai tài khoản hoặc mật khẩu  Thông báo không tìm thấy tài khoản hoặc sai mật khẩu Quay lại bước 2

2.4.3 Scenario Use-case “Đổi mật khẩu”

Bảng 2.4.2 Scenario Use-case “Đổi mật khẩu”

Use case name Đổi mật khẩu

1 Description Người dùng/Điều phối viên/Quản trị viên muốn thay đổi mật khẩu

2 Actors Người dùng, Điều phối viên, Quản trị viên

3 Input Người dùng/Điều phối viên/Quản trị viên đã đăng nhập thành công

4 Output Thông báo đổi mật khẩu thành công.

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viên nhấn vào

“Tên người dùng” ở thanh header của hệ thống sau đó nhấn “Đổi mật khẩu”  Use case bắt đầu.

2 Thực hiện các thao tác đổi mật khẩu.

3 Người dùng/Điều phối viên/Quản trị viên nhấn nút

4 Hệ thống lưu lại thông tin mới của người dùng sau khi thay đổi  Kết thúc Use case.

2.1 Nếu người dùng nhập mật khẩu cũ hoặc nhập lại mật khẩu mới không không khớp  Nút “lưu” bị vô hiệu.

2.4.4 Scenario Use-case “Chỉnh sửa hồ sơ”

Bảng 2.4.2 Scenario Use-case “Chỉnh sửa hồ sơ”

1 Description Người dùng/Điều phối viên/Quản trị viên muốn chỉnh sửa hồ sơ cá nhân.

2 Actors Người dùng, Điều phối viên, Quản trị viên.

3 Input Người dùng/Điều phối viên/Quản trị viên đã đăng nhập

Xây dựng hệ thống quản lý và đánh giá sách xuất bản tại Việt Nam thành công.

4 Output Thông báo cập nhật thành công.

“Tên người dùng” ở thanh header của hệ thống sau đó nhấn “Chỉnh sửa hồ sơ”  Use case bắt đầu.

2 Thực hiện các thao tác cập nhật hồ sơ.

3 Người dùng/Điều phối viên/Quản trị viên nhấn nút

4 Hệ thống lưu lại thông tin mới của người dùng sau khi thay đổi  Kết thúc Use case.

2.1 Nếu người dùng xoá tên hiển thị  Nhấn nút “Lưu” sẽ bị báo lỗi

2.4.5 Scenario Use-case “Đăng xuất”

Bảng 2.4.2 Scenario Use-case “Đăng xuất”

Use case name Đăng xuất

1 Description Người dùng/Điều phối viên/Quản trị viên muốn đăng xuất.

2 Actors Người dùng, Điều phối viên, Quản trị viên.

3 Input Người dùng/Điều phối viên/Quản trị viên đã đăng nhập thành công.

4 Output Thông báo đăng xuất thành công.

“Tên người dùng” ở thanh header của hệ thống sau đó nhấn “Đăng xuất”  Use case bắt đầu.

2 Người dùng đăng xuất khỏi hệ thống Kết thúc Use case.

1.1 Nếu người dùng không chọn “Đăng xuất”  Use case kết thúc mà chưa được đăng xuất.

2.4.6 Scenario Use-case “Xem danh mục sách xuất bản”

Bảng 2.4.3 Scenario Use-case “Xem danh mục sách xuất bản”

Xem danh mục sách xuất bản

1 Description Người truy cập website muốn xem tất cả danh mục của hệ thống

2 Actors Tất cả các tác nhân của hệ thống: Khách vãng lai, Người dùng, Điều phối viên, Quản Trị Viên

3 Input Khách vãng lai/Người dùng/Điều phối viên/Quản Trị

Viên truy cập vào tranh danh mục của hệ thống

4 Output Hệ thống hiển thị danh sách các danh mục.

5 Basic flow 1 Khách vãng lai/Người dùng/Điều phối viên/Quản trị viên nhấn vào “Danh mục thể loại” ở thanh header của hệ thống  Bắt đầu use case.

2 Hệ thống hiển thị ra danh sách tất cả các danh mục

1.1 Khách vãng lai/Người dùng/Điều phối viên/Quản trị viên không nhấn vào “Danh mục thể loại” ở thanh header của hệ thống  Usecase kết thúc.

2.4.7 Scenario Use-case “Xem sách trong từng danh mục”

Bảng 2.4.1 Scenario Use-case “Xem sách trong từng danh mục”

Xem sách trong từng danh mục

1 Description Người truy cập website muốn xem tất cả các sách trong một danh mục cụ thể của hệ thống.

2 Actors Tất cả các tác nhân của hệ thống: Khách vãng lai, Người dùng, Điều phối viên, Quản Trị Viên.

3 Input Khách vãng lai/Người dùng/Điều phối viên/Quản Trị Viên truy cập vào một trang danh mục cụ thể của hệ thống.

4 Output Hệ thống hiển thị các đầu sách của danh mục đó.

5 Basic flow 1 Khách vãng lai/Người dùng/Điều phối viên/Quản trị viên vào trang “Danh mục thể loại” của hệ thống  Bắt đầu use case.

2 Khách vãng lai/Người dùng/Điều phối viên/Quản trị viên chọn danh mục cần tìm hoặc chọn “Xem thêm” tương ứng với thể loại đó.

3 Hệ thống hiển thị ra tất cả các đầu sách thuộc thể loại đó  Kết thúc use case.

2.1 Khách vãng lai/Người dùng/Điều phối viên/Quản trị viên không nhấn vào thể loại hoặc “Xem thêm” tương ứng với thể loại đó  Use case kết thúc mà chưa vào được trang xem sách của danh mục thể loại cụ thể.

2.4.8 Scenario Use-case “Tìm kiếm sách”

Bảng 2.4.1 Scenario Use-case “Tìm kiếm sách”

1 Description Người truy cập website muốn tìm kiếm sách.

2 Actors Tất cả các tác nhân của hệ thống: Khách vãng lai, Người dùng, Điều phối viên, Quản Trị Viên.

3 Input Thông tin về sách (Tên sách, tên nhà xuất bản, nội dung,

4 Output Hệ thống sẽ hiển thị ra các đầu sách tương ứng với điều kiện tìm kiếm đó.

5 Basic flow 1 Khách vãng lai/Người dùng/Điều phối viên/Quản trị viên vào website  Bắt đầu use case.

2 Khách vãng lai/Người dùng/Điều phối viên/Quản trị viên nhấn nhập điều kiện vào ô tìm kiếm trên thanh header.

3 Hệ thống kiểm tra và trả về kết quả ở trang tìm kiếm  Kết thúc use case.

2.1 Khách vãng lai/Người dùng/Điều phối viên/Quản trị viên nhấn không nhập điều kiện vào ô tìm kiếm trên thanh header  Use case kết thúc.

2.4.9 Scenario Use-case “Thêm sách vào tủ sách”

Bảng 2.4.1 Scenario Use-case “Thêm sách vào tủ sách”

Thêm sách vào tủ sách

1 Description Người dùng muốn thêm sách vào tủ sách cá nhân.

2 Actors Người dùng, Điều phối viên, Quản Trị Viên.

3 Input Sách cần thêm vào tủ sách.

4 Output Sách đã được thêm vào tủ sách.

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viên truy cập

Xây dựng hệ thống quản lý và đánh giá sách xuất bản tại Việt Nam vào trang hiển thị chi tiết thông tin sách  Bắt đầu use case.

2 Người dùng/Điều phối viên/Quản trị viên nhấn vào nút “Thêm vào tủ sách” hoặc nhấn chọn dấu mũi tên để lựa chọn thêm các tủ sách khác  Kết thúc use case.

2.1 Người dùng/Điều phối viên/Quản trị viên không nhấn “Thêm vào tủ sách”  Use case kết thúc mà sách chưa được thêm.

2.4.10.Scenario Use-case “Thêm sách vào tủ sách từ trang viết đánh giá”

Bảng 2.4.1 Scenario Use-case “Thêm sách vào tủ sách từ trang viết đánh giá”

Thêm sách vào tủ sách từ trang viết đánh giá

1 Description Người dùng muốn thêm sách vào tủ sách cá nhân.

3 Input Sách cần thêm vào tủ sách.

4 Output Sách đã được thêm vào tủ sách.

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viên truy cập vào trang hiển thị chi tiết thông tin sách  Bắt đầu use case.

2 Người dùng/Điều phối viên/Quản trị viên chọn

“Viết đánh giá” để chuyển sang trang viết đánh giá.

3 Người dùng/Điều phối viên/Quản trị viên lựa chọn tủ sách thích hợp và nhấn “lưu”  Kết thúc use case.

2.2 Người dùng/Điều phối viên/Quản trị viên không chọn tủ sách hoặc không nhấn “lưu” Use case kết thúc mà sách chưa được thêm.

2.4.11.Scenario Use-case “Thay đổi tủ sách của sách”

Bảng 2.4.1 Scenario Use-case “Thay đổi tủ sách của sách”

Thay đổi tủ sách của sách

1 Description Người dùng muốn thay đổi tủ sách cho cuốn sách.

3 Input Sách đã được thêm vào tủ sách.

4 Output Sách đã được đổi sang tủ khác.

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viên truy cập vào trang hiển thị chi tiết thông tin sách  Bắt đầu use case.

2 Người dùng/Điều phối viên/Quản trị viên nhấn vào nút “Thêm vào tủ sách”.

3 Người dùng/Điều phối viên/Quản trị viên nhấn chọn dấu mũi tên để lựa chọn thêm các tủ sách khác  Kết thúc use case.

2.1 Người dùng/Điều phối viên/Quản trị viên không chọn dấu mũi tên để sửa tủ sách  Use case kết thúc tủ sách chưa được đổi.

2.4.12.Scenario Use-case “Thay đổi tủ sách của sách từ trang tủ sách của tôi”

Bảng 2.4.1 Scenario Use-case “Thay đổi tủ sách của sách từ trang tủ sách của tôi”

Thay đổi tủ sách của sách từ trang tủ sách của tôi

1 Description Người dùng muốn thay đổi tủ sách cho cuốn sách.

3 Input Sách đã nằm trong “Tủ sách của tôi”.

4 Output Sách đã được đổi sang tủ khác.

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viên truy cập vào trang “Tủ sách của tôi”  Bắt đầu use case.

2 Người dùng/Điều phối viên/Quản trị viên thay đổi tủ sách (Dự định đọc/Đang đọc/Đã đọc/Ngừng đọc)  Kết thúc use case.

2.1 Người dùng/Điều phối viên/Quản trị viên không thay đổi tủ sách  Use case kết thúc tủ sách chưa được đổi.

2.4.13.Scenario Use-case “Xoá sách khỏi tủ sách từ trang tủ sách của tôi”

Bảng 2.4.1 Scenario Use-case “Xoá sách khỏi tủ sách từ trang tủ sách của tôi”

Xoá sách khỏi sách từ trang tủ sách của tôi

1 Description Người dùng muốn xoá sách khỏi tủ sách.

3 Input Sách đã nằm trong “Tủ sách của tôi”.

4 Output Sách đã bị xoá khỏi tủ sách.

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viên truy cập vào trang “Tủ sách của tôi”  Bắt đầu use case.

2 Người dùng/Điều phối viên/Quản trị nhấn biểu tượng thùng rác  Kết thúc use case.

2.1 Người dùng/Điều phối viên/Quản trị viên không nhấn biểu tượng thùng rác  Use case kết thúc sách chưa bị xoá khỏi tủ sách.

2.4.14.Scenario Use-case “Xoá sách khỏi tủ sách từ trang thông tin chi tiết sách”

Bảng 2.4.1 Scenario Use-case “Xoá sách khỏi tủ sách từ trang thông tin chi tiết sách”

Xoá sách khỏi sách từ trang thông tin chi tiết sách

1 Description Người dùng muốn xoá sách khỏi tủ sách.

3 Input Sách đã được thêm vào tủ sách.

4 Output Sách đã bị xoá khỏi tủ sách.

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viên truy cập vào trang “Thông tin chi tiết sách”  Bắt đầu use case.

2 Người dùng/Điều phối viên/Quản trị nhấn vào biểu tượng mũi tên đi xuống và nhấn bỏ vào thùng rác

7 Exception 2.1 Người dùng/Điều phối viên/Quản trị viên không

Xây dựng hệ thống quản lý và đánh giá sách xuất bản tại Việt Nam flow nhấn “Bỏ vào thùng rác”  Use case kết thúc sách chưa bị xoá khỏi tủ sách.

2.4.15.Scenario Use-case “Viết đánh giá”

Bảng 2.4.1 Scenario Use-case “Viết đánh giá”

1 Description Người dùng muốn viết đánh giá cho sách.

3 Input Sách cần viết đánh giá

4 Output Đã viết đánh giá thành công.

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viên truy cập vào trang “Thông tin chi tiết sách”  Bắt đầu use case.

3 Người dùng/Điều phối viên/Quản trị viên thực hiện các thao tác đánh giá (Xếp hạng sao, chọn tủ sách) và nhấn nút “Đăng”  Kết thúc use case.

3.1 Người dùng/Điều phối viên/Quản trị viên không xếp hạng sao mà bình luận  Hệ thống báo lỗi.

3.2 Người dùng/Điều phối viên/Quản trị viên không nhấn nút “Đăng”  Use case kết thúc mà đánh giá chưa được đăng.

2.4.16.Scenario Use-case “Sửa đánh giá”

Bảng 2.4.1 Scenario Use-case “Sửa đánh giá”

1 Description Người dùng muốn sửa lại đánh giá đã viết cho sách.

3 Input Đánh giá đã được đăng và cần được sửa.

4 Output Cập nhật đánh giá thành công.

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viên truy cập vào trang “Thông tin chi tiết sách”  Bắt đầu use

Xây dựng hệ thống quản lý và đánh giá sách xuất bản tại Việt Nam case.

3 Người dùng/Điều phối viên/Quản trị viên thực hiện các thao tác sửa đổi (Xếp hạng sao, chọn tủ sách) và nhấn nút “Đăng”  Kết thúc use case.

3.1 Người dùng/Điều phối viên/Quản trị viên không xoá bỏ xếp hạng sao mà giữ bình luận  Hệ thống báo lỗi.

3.2 Người dùng/Điều phối viên/Quản trị viên không nhấn nút “Đăng”  Use case kết thúc mà đánh giá đã sửa chưa được cập nhật.

2.4.17.Scenario Use-case “Chỉnh sửa hồ sơ cá nhân”

Bảng 2.4.1 Scenario Use-case “Chỉnh sửa hồ sơ cá nhân”

Chỉnh sửa hồ sơ cá nhân

1 Description Người dùng muốn chỉnh sửa hồ sơ cá nhân.

3 Input Thông tin cần thay đổi.

4 Output Hồ sơ cá nhân đã cập nhật thành công.

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viên truy cập vào website chọn “Tên User” trên thanh header và chọn “Chỉnh sửa hồ sơ”  Bắt đầu use case.

2 Người dùng/Điều phối viên/Quản trị viên thay đổi thông tin cá nhân và nhấn nút “Lưu”  Kết thúc Use case.

2.1 Người dùng/Điều phối viên/Quản trị viên không nhấn nút “Lưu”  Use case kết thúc mà hồ sơ cá nhân đã sửa chưa được cập nhật.

2.4.18.Scenario Use-case “Xem thông tin của người dùng khác”

Bảng 2.4.1 Scenario Use-case “Xem thông tin cá nhân của người dùng khác”

Xem thông tin cá nhân của người dùng khác

1 Description Người dùng muốn xem thông tin của người dùng khác.

3 Input Người dùng khác đã có đánh giá trên website.

4 Output Hồ sơ cá nhân của người dùng khác.

5 Basic flow 1 Người dùng/Điều phối viên/Quản trị viên truy cập vào website nhấn vào ảnh đại diện hoặc tên của người dùng khác đã có đánh giá trên website  Bắt đầu use case.

2 Người dùng/Điều phối viên/Quản trị viên xem được thông tin cá nhân của người dùng khác  Kết thúc Use case.

2.1 Người dùng/Điều phối viên/Quản trị viên không nhấn vào ảnh đại diện hoặc tên của người dùng khác đã có đánh giá trên website  Use case kết thúc mà không xem được hồ sơ cá nhân của người dùng khác.

2.4.19.Scenario Use-case “Tìm kiếm người dùng”

Bảng 2.4.1 Scenario Use-case “Tìm kiếm người dùng”

1 Description Điều phối viên/Quản trị viên muốn tìm kiếm thông tin của người dùng.

2 Actors Điều phối viên, Quản Trị Viên.

3 Input Thông tin người dùng

4 Output Kết quả tìm kiếm theo thông tin đã nhập

5 Basic flow 1 Điều phối viên/Quản trị viên truy cập vào website nhấn vào “tên user” trên thành header và chọn

“Quản lý”  Bắt đầu use case.

2 Điều phối viên/Quản trị viên nhấn vào mục “Người dùng”.

3 Điều phối viên/Quản trị viên nhập thông tin vào ô tìm kiếm  Kết thúc Use case.

3.1 Điều phối viên/Quản trị viên không nhập tên thông tin dùng  Use case kết thúc.

2.4.20.Scenario Use-case “Cấm người dùng”

Bảng 2.4.1 Scenario Use-case “Cấm người dùng”

1 Description Điều phối viên/Quản trị viên muốn cấm người dùng truy cập vào website.

3 Input Thông tin người dùng

4 Output Người dùng đã bị khoá quyền hạn.

3 Điều phối viên/Quản trị nhấn biếu tượng cấm và xác nhận  Kết thúc Use case.

3.1 Điều phối viên/Quản trị viên huỷ cấm  Use case kết thúc mà người dùng không bị cấm.

2.4.21.Scenario Use-case “Gỡ lệnh cấm người dùng”

Bảng 2.4.1 Scenario Use-case “Gỡ lệnh cấm người dùng”

Gỡ lệnh cấm người dùng

1 Description Điều phối viên/Quản trị viên muốn gỡ lệnh cấm người dùng đã thi hành.

3 Input Người dùng đã bị cấm

4 Output Người dùng đã được gỡ lệnh cấm.

3 Điều phối viên/Quản trị nhấn biếu tượng Khôi phục và xác nhận  Kết thúc Use case.

3.1 Điều phối viên/Quản trị viên huỷ xác nhận gỡ lệnh cấm  Use case kết thúc mà người dùng vẫn bị cấm.

2.4.22.Scenario Use-case “Gắn quyền điều phối viên cho người dùng”

Bảng 2.4.1 Scenario Use-case “Gắn quyền điều phối viên cho người dùng”

Gắn quyền điều phối viên cho người dùng

1 Description Quản trị viên muốn thêm người dùng làm Điều phối viên.

3 Input Người dùng không bị cấm.

4 Output Người dùng đã có quyền hạn của Điều phối viên.

5 Basic flow 1 Quản trị viên truy cập vào website nhấn vào “tên user” trên thành header và chọn “Quản lý”  Bắt đầu use case.

2 Quản trị viên nhấn vào mục “Người dùng”.

3 Quản trị nhấn biếu tượng Chỉnh sửa và xác nhận  Kết thúc Use case.

3.1 Quản trị viên huỷ xác nhận gắn quyền người dùng  Use case kết thúc mà người dùng vẫn chưa trở thành Điều phối viên.

2.4.23.Scenario Use-case “Xoá quyền điều phối viên của điều phối viên”

Bảng 2.4.1 Scenario Use-case “Xoá quyền điều phối viên của điều phối viên”

Xoá quyền điều phối viên của điều phối viên

1 Description Quản trị viên muốn xoá quyền điều phối viên của điều phối viên.

3 Input Đã là Điều phối viên.

4 Output Điều phối viên bị xoá mất quyền và trở lại thành người dùng.

2 Quản trị viên nhấn vào mục “Điều phối viên”.

3 Quản trị viên nhấn biếu tượng Xoá và xác nhận  Kết thúc Use case.

3.1 Quản trị viên huỷ xác nhận xoá quyền điều phối viên

 Use case kết thúc mà điều phối viên vẫn chưa trở về lại Người dùng.

2.4.24.Scenario Use-case “Thêm danh mục thể loại”

Bảng 2.4.1 Scenario Use-case “Thêm danh mục thể loại”

Thêm danh mục thể loại

1 Description Quản trị viên muốn tạo thêm danh mục thể loại mới cho sách.

3 Input Thông tin danh mục

4 Output Danh mục mới đã được thêm thành công.

2 Quản trị viên nhấn vào mục “Danh mục”.

3 Quản trị viên nhập thông tin danh mục mới và nhấn

“Tạo mới”  Kết thúc Use case.

3.1 Quản trị viên không nhấn “Tạo mới” Use case kết thúc mà danh mục mới chưa được thêm.

2.4.25.Scenario Use-case “Ẩn danh mục thể loại”

Bảng 2.4.1 Scenario Use-case “Ẩn danh mục thể loại”

Use case name Ẩn danh mục thể loại

1 Description Quản trị viên muốn ẩn danh mục thể loại đã tạo.

3 Input Thông tin danh mục đã tạo.

4 Output Danh mục đã được ẩn thành công.

5 Basic flow 1 Quản trị viên truy cập vào website nhấn vào “tên

Xây dựng hệ thống quản lý và đánh giá sách xuất bản tại Việt Nam user” trên thành header và chọn “Quản lý”  Bắt đầu use case.

2 Quản trị viên nhấn vào mục “Danh mục” và chọn

3 Quản trị viên chọn nút ẩn và xác nhận  Kết thúc Use case.

3.1 Quản trị viên không nhấn huỷ khi xác nhận  Use case kết thúc mà danh mục chưa bị ẩn.

2.4.26.Scenario Use-case “Khôi phục danh mục thể loại đã bị ẩn”

Bảng 2.4.1 Scenario Use-case “Khôi phục danh mục thể loại đã bị ẩn”

Khôi phục danh mục thể loại đã bị ẩn

1 Description Quản trị viên muốn khôi phục lại danh mục thể loại đã bị ẩn.

3 Input Thông tin danh mục đã bị ẩn.

4 Output Danh mục đã được khôi phục thành công.

2 Quản trị viên nhấn vào mục “Danh mục” và chọn

3 Quản trị viên chọn nút khôi và xác nhận  Kết thúc Use case.

3.1 Quản trị viên không nhấn huỷ khi xác nhận  Use case kết thúc mà danh mục bị ẩn vẫn chưa khối phục.

2.4.27.Scenario Use-case “Thêm sách mới”

Bảng 2.4.1 Scenario Use-case “Thêm sách mới”

1 Description Điều phối viên/Quản trị viên muốn thêm sách xuất bản mới.

3 Input Thông tin sách xuất bản mới chưa có trong hệ thống.

4 Output Sách đã được tạo thành công.

2 Điều phối viên/Quản trị viên nhấn vào mục “Quản lý sách”.

3 Điều phối viên/Quản trị viên nhập thông tin sách và nhấn nút “Tạo mới”  Kết thúc Use case.

3.1 Điều phối viên/Quản trị viên không nhấn nút “Tạo mới” Use case kết thúc mà sách mới chưa được thêm vào hệ thống.

2.4.28.Scenario Use-case “Chỉnh sửa thông tin sách”

Bảng 2.4.1 Scenario Use-case “Chỉnh sửa thông tin sách”

Chỉnh sửa thông tin sách

1 Description Điều phối viên/Quản trị viên muốn chỉnh sửa thông tin sách xuất bản.

3 Input Thông tin sách xuất bản cần được chỉnh sửa.

4 Output Thông tin sách đã được cập nhật thành công.

2 Điều phối viên/Quản trị viên nhấn vào mục “Quản lý sách” và chọn “Quản lý sách”.

3 Điều phối viên/Quản trị viên nhập chỉnh sửa thông tin sách và nhấn nút “Lưu”  Kết thúc Use case.

3.1 Điều phối viên/Quản trị viên không nhấn nút

“Lưu” Use case kết thúc mà sách vẫn chưa được chỉnh sửa.

2.4.29.Scenario Use-case “Ẩn sách”

Bảng 2.4.1 Scenario Use-case “Ẩn sách”

Use case name Ẩn sách

1 Description Điều phối viên/Quản trị viên muốn ẩn sách xuất bản.

3 Input Thông tin sách xuất bản cần được ẩn.

4 Output Sách đã bị ẩn.

3 Điều phối viên/Quản trị viên chọn nút ẩn sách và xác nhận  Kết thúc Use case.

3.1 Điều phối viên/Quản trị viên không nhấn nút xác nhận  Use case kết thúc mà sách vẫn chưa bị ẩn.

2.4.30.Scenario Use-case “Khôi phục sách đã bị ẩn”

Bảng 2.4.1 Scenario Use-case “Khôi phục sách đã bị ẩn”

Khôi phục sách đã bị ẩn

1 Description Điều phối viên/Quản trị viên muốn khôi phục sách đã bị ẩn.

3 Input Sách xuất bản đã bị ẩn.

4 Output Sách bị ẩn đã được khôi phục.

3 Điều phối viên/Quản trị viên chọn nút khôi phục sách và xác nhận  Kết thúc Use case.

3.1 Điều phối viên/Quản trị viên không nhấn nút xác nhận  Use case kết thúc mà sách vẫn bị ẩn.

2.4.31.Scenario Use-case “Quản lý bình luận”

Bảng 2.4.1 Scenario Use-case “Quản lý bình luận”

1 Description Điều phối viên/Quản trị viên muốn xoá hoặc khôi phục các binh luận trên website

3 Input Bình luận trên website

4 Output Bình luận đã bị ẩn/khôi phục.

2 Điều phối viên/Quản trị viên nhấn vào mục “Quản lý bình luận”.

3 Điều phối viên/Quản trị viên chọn các thao tác ẩn/khôi phục đối với bình luận và xác nhận  Kết thúc Use case.

3.1 Điều phối viên/Quản trị viên không nhấn nút xác nhận  Use case kết thúc.

2.4.32.Scenario Use-case “Xem thống kê”

Bảng 2.4.1 Scenario Use-case “Xem thống kê”

1 Description Quản trị viên muốn xem thống kê

2 Quản trị viên nhấn vào mục “Thống kê” Kết thúc

3.1 Quản trị viên không nhấn vào mục “Thống kê”  Use case kết thúc.

Thiết kế bảng cơ sở dữ liệu

Thuộc tính Giải thích Kiểu dữ liệu Ghi chú

_id Mã tự động gán string id Mã tài khoản string name Tên tài khoản người dùng string avatar Ảnh đại diện người dùng string email Email người dùng string phoneNumber Số điện thoại người dùng string gender Giới tính người dùng string dateOfBirth Ngày sinh người dùng date bio Tiểu sử người dùng string password Mật khẩu người dùng string accountStatus Trạng thái tài khoản người dùng object role Vai trò của người dùng string inChargeOf Quản lý những phần nào array token Token xác thực string collections Tủ sách người dùng object createdAt Ngày tạo tài khoản date updatedAt Ngày cập nhật tài date

Xây dựng hệ thống quản lý và đánh giá sách xuất bản tại Việt Nam khoản

Thuộc tính Giải thích Kiểu dữ liệu Ghi chú status Trạng thái hoạt động của tài khoản string “Đang hoặc động” và “Vô hiệu hoá” reason Lý do bị khoá tài khoản string disableAt Thời gian bị khoá tài khoản date

Thuộc tính Giải thích Kiểu dữ liệu Ghi chú wishList Dự định đọc array[objectId] readingList Đang đọc array[objectId] readList Đã đọc array[objectId] droppedList Ngừng đọc array[objectId]

Thuộc tính Giải thích Kiểu dữ liệu Ghi chú book objectID của bảng “books” objectId addedAt Ngày thêm date

_id Mã tự động gán object id Mã đánh giá string user Tên người dùng string book Mã sách string rating Xếp hạng sao int content Nội dung string deletedAt Ngày xoá date createdAt Ngày bình luận date updatedAt Ngày chỉnh sửa date downvotes Phản ứng

“Không đồng tình” array upvotes Phản ứng “Đồng tình”

_id Mã tự động gán objectid id Mã sách string title Tiêu đề sách string author Tác giả array[string] translator Dịch giả array[string] description Tóm tắt string cover Bìa sách string tags Thể loại array publisher Nhà phát hành string publishDate Ngày phát hành date pageCount Số trang int reviews Đánh giá array[objectid] rating Xếp hạng sao objectid deletedAt Ngày xoá sách date createdAt Ngày tạo sách date updatedAt Ngày cập nhật sách date buyLink Liên kết mua sách array[string]

Thuộc tính Giải thích Kiểu dữ liệu Ghi chú oneStar Một sao array oneStar Hai sao array

Xây dựng hệ thống quản lý và đánh giá sách xuất bản tại Việt Nam oneStar Ba sao array oneStar Bốn sao array fiveStar Năm sao array

_id Mã tự động gán objectid id Mã danh mục string code Mã tên danh mục string name Tên danh mục string deletedAt Ngày xoá danh mục date createdAt Ngày tạo danh mục date updatedAt Ngày cập nhật danh mục date type Loại danh mục string

_id Mã tự động gán objectId lastUserId Thứ tự người dùng cuối int lastTagId Thứ tự mã tag cuối int lastBookId Thứ tự mã sách cuối int lastReviewId Thứ tự lượt đánh giá cuối int

Database Schema

Hình 2.10 Sơ đồ Database Schema

XÂY DỰNG CHƯƠNG TRÌNH

Công cụ xây dựng

 Hệ quản trị cơ sở dữ liệu: MongoDB

 Hỗ trợ mã nguồn: Visual Studio Code.

 Lưu trữ file: Google Cloud Storage

Giao diện chương trình

Hình 3.2.1 Giao diện “Trang chủ”

3.6.2 Giao diện danh mục thể loại

Hình 3.2.2 Giao diện “Danh mục thể loại”

3.6.3 Giao diện sách trong một danh mục thể loại

Hình 3.2.3 Giao diện “Sách trong một danh mục thể loại”

3.6.4 Giao diện trang tìm kiếm

Hình 3.2.3 Giao diện “Tìm kiếm”

3.6.5 Giao diện chi tiết thông tin sách

Hình 3.2.4 Giao diện “Chi tiết thông tin sách”

3.6.6 Giao diện viết đánh giá

Hình 3.2.5 Giao diện “Viết đánh giá”

3.6.7 Giao diện tài khoản người dùng

Hình 3.2.6 Giao diện “Tài khoản người dùng”

3.6.8 Giao diện Chỉnh sửa thông tin tài khoản

Hình 3.2.7 Giao diện “Chỉnh sửa thông tin tài khoản”

3.6.9 Giao diện quản lý người dùng

Hình 3.2.8 Giao diện “Quản lý tài khoản người dùng”

3.6.10.Giao diện quản lý điều phối viên

Hình 3.2.9 Giao diện “Quản lý điều phối viên”

3.6.11.Giao diện quản lý sách

Hình 3.2.10 Giao diện “Quản lý sách”

3.6.12.Giao diện quản lý danh mục

Hình 3.2.11 Giao diện “Quản lý danh mục”

3.6.13.Giao diện quản lý bình luận

Hình 3.2.11 Giao diện “Quản lý bình luận”

Hình 3.2.11 Giao diện “Thống kê”

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN

 Tìm hiểu và nắm bắt được các công cụ thiết kế web.

 Biết được các thiết kế web động, trang web một trang cũng như cách tổ chức cơ sở dữ liệu.

 Nắm vững lý thuyết và hiểu sâu hơn về JavaScript

 Nắm vững lý thuyết và vận dụng được HTML, SCSS, MongoDB, Javascript,

 Xây dựng thành công “Xây dựng hệ thống quản lý và đánh giá sách xuất bản tại Việt Nam” với các chức năng đáp ứng các yêu cầu cơ bản của người sử dụng.

 Hoàn thành các chức năng còn thiếu và phát triển thêm một số chức năng mới.

Sinh viên thực hiện: Nguyễn Nhã Trúc Người hướng dẫn: ThS Nguyễn Thị Hà Quyên 46

Tiêu đề	Xây Dựng Hệ Thống Quản Lý Và Đánh Giá Sách Xuất Bản Tại Việt Nam
Tác giả	Nguyễn Nhã Trúc
Người hướng dẫn	ThS. Nguyễn Thị Hà Quyên
Trường học	Đại học Đà Nẵng
Chuyên ngành	Công nghệ thông tin
Thể loại	đồ án tốt nghiệp
Năm xuất bản	2023
Thành phố	Đà Nẵng

Định dạng
Số trang	65
Dung lượng	6,68 MB