Tiểu luận môn Hướng đối tượng Thiết kế hệ thống quản lý thư viện

Tiểu luận môn Hướng đối tượng Thiết kế hệ thống quản lý thư viện 1. Khách hàng tạo một yêu cầu tìm sách (tìm theo tên, tìm theo thể loại, tìm theo tác giả) 2. Khách hàng gửi yêu cầu tìm sách của mình cho hệ thống 3. Hệ thống kiểm tra yêu cầu tìm kiếm của khách hàng để đảm bảo yêu cầu tìm kiếm đó có lỗi (không chứa ký tự đặc biệt, không quá dàingắn,…) 4. Nếu yêu cầu tìm kiếm có lỗi, yêu cầu bị từ chối và được trả lại cho khách hàng để chỉnh sửa hoặc hủy bỏ 5. Nếu yêu cầu tìm kiếm không có lỗi, yêu cầu được chấp nhận 6. Các kết quả tìm kiếm được gửi về cho khách hàng 7. Yêu cầu được đóng lại

Thiết kế hệ thống quản lý thư viện

Normal Flow of Events:

1 Khách hàng đưa ra yêu cầu tìm sách.

Nếu muốn tìm theo loại sách, thực hiện subflows S-1.

Nếu muốn tìm theo tên sách, thực hiện subflows S-2.

Nếu muốn tìm theo tác giả, thực hiện subflows S-3.

1 Khách hàng chọn sách theo tên có trong danh sách các phân loại sách của thư viện

2 Hệ thống trả về là danh sách các cuốn sách có tên giống hoặc gần giống với từ khóa

tìm kiếm của khách hàng.

S-3:

1 Khách hàng chọn sách theo tác giả mình mong muốn.

2 Hệ thống trả về danh sách các tác giả có tên giống hoặc gần giống với từ khóa của

khách hàng.

Như vậy, các lớp ứng tuyển là: khách hàng, sách, yêu cầu tìm sách, danh sáchtìm kiếm theo loại sách, danh sách tìm kiếm theo tên sách, danh sách tìm kiếmtheo tên tác giả

Khách hàng là người tạo ra việc tìm kiếm theo tên, phân loại hoặc theo tác giả

1.1.2 Ca sử dụng mượn sách.

Normal Flow of Events:

1 Khách hàng đưa ra yêu cầu mượn sách.

2 Khách hàng đưa ra danh sách muốn mượn.

3 Hệ thống sẽ chứng thực xem người dùng có quyền mượn (những) cuốn sách đó hay không.

Nếu được mượn thực hiện subflows S-1

Nếu không thực hiện subflows S-2

Hệ thống báo lỗi, khách hàng có thể quay lại để tiếp tục mượn các cuốn sách khác.

Ngoài các lớp ứng tuyển như ở mục 1.1.1, có thêm các lớp ứng tuyển sau: yêucầu mượn sách, danh sách muốn mượn sách, hóa đơn

Khách hàng là người tạo ra yêu cầu mượn sách Hóa đơn cần được in ra mỗikhi có sự thay đổi trong việc mượn trả sách

1.1.3 Ca sử dụng trả sách

Normal Flow of Events:

1 Khách hàng đem sách đến trả cho thư viện.

2 Nhân viên nhập mã khách hàng.

3 Hệ thống sẽ hiện ra danh sách các sách mà khách còn mượn.

4 Nhân viên căn cứ vào danh sách các sách trả để cập nhật lại thông tin mượn trả

sách.

5 Nhân viên hỏi khách hàng có tiếp tục mượn sách ngay hay không

Nếu khách hàng muốn mượn tiếp sách, thực hiện subflows S-1

Nếu khách hàng chỉ đến để trả sách, thực hiện subflows S-2.

Subflows:

S-1:

Khách hàng chuyển qua ca sử dụng mượn sách.

S-2:

Hệ thống yêu cầu in hóa đơn.

Ngoài các lớp ứng tuyển ở 2 trường hợp trên, còn có lớp danh sách sách đãmượn, nhân viên, danh sách các sách trả

Nhân viên làm nhiệm vụ xác nhận việc trả sách có hợp lý hay không Nếu việctrả sách là hợp lệ, thông tin mượn trả được cập nhật lại

1.2 Xây dựng thẻ CRC.

Class Name: khách

Description: mô tả thông tin khác hàng và các hoạt động

Đưa ra yêu cầu tìm kiếm.

Đưa ra yêu cầu mượn sách.

Đưa ra yêu cầu trả sách.

Số điện thoại (int).

Số tài khoản/mật khẩu (string).

Relationships:

Generalization (a kind of):

Aggregation (has parts):

Other Associations: sách, yêu cầu tìm sách, yêu cầu mượn sách.

Class Name: sách ID: 02 Type: Medium.

Description: mô tả thông tin về sách.

Associated Use Case:

Generalization (a kind of):

Aggregation (has parts):

Other Associations: Danh sách tìm sách, danh sách mượn sách, danh sách trả sách.

Class Name: Yêu cầu mượn sách ID: 03 Type: Medium

Description: Mô tả một yêu cầu của khách hàng Associated Use Case: Mượn sách.

 Hóa đơn:

Astributes:

Relationships:

Generalization (a kind of):

Aggregation (has parts): ………

Other Associations: Khách hàng, danh sách mượn, Hóa đơn.

Class Name: Yêu cầu tìm kiếm ID: 04 Type: …

Description: Mô tả một yêu cầu của khách hàng.

Associated Use Case: Tìm kiếm.

 Danh sách kết quả tìm kiếm:

o Thực hiện tìm kiếm trong danh mục sách trong thư viện.

o Trả lại kết quả là một danh sách các cuốn sách phù hợp

vs kết quả, và trả lại danh sách rỗng nếu không tìm thấy.

Astributes:

 Kiểu tìm kiếm (int).

 Từ khóa tìm kiếm (string).

Relationships:

Generalization (a kind of):

Aggregation (has parts): ………

Other Associations: Khách hàng, danh sách kết quả tìm kiếm

Class Name: Hóa đơn ID: 05 Type: Low

Description: Cung cấp thông tin về các giao dịch giữa

1 Danh mục sách đang mượn (danh sách)

2 Thời điểm mượn trả (string)

Relationships:

Generalization (a kind of):

Aggregation (has parts):

Other Associations: Yêu cầu mượn sách, Yêu cầu trả sách.

Class Name: Nhân viên ID: 06 Type: High.

Description:

Associated Use Case:

Trả sách

Chứng thực nhân viên.Thay đổi tiền cọc.Cập nhật phí hàng tháng

2 Mã nhân viên (string)

3 Số điện thoại (string)

4 Tài khoản/mật khẩu (string)

Relationships:

Generalization (a kind of):

Aggregation (has parts):

Other Associations: Yêu cầu trả sách.

Class Name: Yêu cầu trả sách ID: 07 Type: Medium

Description: Mô tả yêu cầu trả sách của khách hàng Associated Use Case:

Trả sách.

Danh sách sách Nhân viên Hóa đơn.

Astributes:

Danh sách sách cần trả (danh sách sách)

Relationships:

Generalization (a kind of):

Aggregation (has parts): ………

Other Associations: Danh sách sách mang trả, nhân viên, hóa đơn.

Class Name: Danh sách sách ID: 08 Type: Medium

Description: Tập hợp các cuốn sách Associated Use Case:

Yêu cầu tìm kiếm Yêu cầu mượn hóa đơn.

Generalization (a kind of):

Aggregation (has parts): ………

Other Associations: Yêu cầu tìm kiếm, Yêu cầu mượn, hóa đơn, sách, yêu cầu trả.

2 Xây dựng biểu đồ lớp.

Biểu đồ tuần tự

1 Xác định ngữ cảnh

Nhóm vẽ biểu đồ lớp cho 3 ca sử dụng chính: Tim sách, mượn sách và trả sách

2 Xác định các đối tượng tham gia

2.1 Tìm sách

Normal Flow of Events:

1 Khách hàng đưa ra yêu cầu tìm sách.

Nếu muốn tìm theo loại sách, thực hiện subflows S-1.

Nếu muốn tìm theo tên sách, thực hiện subflows S-2.

Nếu muốn tìm theo tác giả, thực hiện subflows S-3.

1 Khách hàng chọn sách theo tên có trong danh sách các phân loại sách của thư viện

2 Hệ thống trả về là danh sách các cuốn sách có tên giống hoặc gần giống với từ khóa tìm kiếm của khách hàng.

S-3:

1 Khách hàng chọn sách theo tác giả mình mong muốn.

2 Hệ thống trả về danh sách các tác giả có tên giống hoặc gần giống với từ khóa của khách hàng.

Nhóm sẽ vẽ biểu đồ tuần tự cho một kịch bản đó là tìm kiếm theo loại sách

Dựa vào Normal of flow events của ca sử dụng tìm sách ta nhận diện được các đối tượng sau:

 Đối tượng khách hàng (User)

 Đối tượng sách (Book)

 Danh sách các cuốn sách có trong thư viện (BookList)

 Yêu cầu tìm kiếm (SearchRequest)

 Đối tượng kết quả tìm kiếm (ResultList)

 Thông tin tác giả (Author)

 Tổng quan về sách (Review)

2.2 Mượn sách

Normal Flow of Events:

1 Khách hàng đưa ra yêu cầu mượn sách.

2 Khách hàng đưa ra danh sách muốn mượn.

3 Hệ thống sẽ chứng thực xem người dùng có quyền mượn (những) cuốn sách đó hay không.

Nếu được mượn thực hiện subflows S-1

Nếu không thực hiện subflows S-2

Các đối tượng được nhận diện như sau:

 User

 BookList

 Danh sách sách mà khách hàng muốn mượn: BorrowList

 Danh sách sách mà khách hàng đang giữ: BorowedList

 Yêu cầu mượn sách: BorrowRequest

 Hóa đơn: Bill

2.3 Trả sách

Normal Flow of Events:

1 Khách hàng đem sách đến trả cho thư viện.

2 Nhân viên nhập mã khách hàng.

3 Hệ thống sẽ hiện ra danh sách các sách mà khách còn mượn.

4 Nhân viên căn cứ vào danh sách các sách trả để cập nhật lại thông tin mượn trả sách.

5 Nhân viên hỏi khách hàng có tiếp tục mượn sách ngay hay không

Nếu khách hàng muốn mượn tiếp sách, thực hiện subflows S-1

Nếu khách hàng chỉ đến để trả sách, thực hiện subflows S-2.

Subflows:

S-1:

Khách hàng chuyển qua ca sử dụng mượn sách.

S-2:

Hệ thống yêu cầu in hóa đơn.

Các đối tượng được nhận diện như sau:

 Nhân viên thư viện: Manager

 BookList

 Danh sách sách mà khách hàng muốn trả: ReturnList

 Danh sách sách mà khách hàng đang giữ: BorowedList

 Yêu cầu trả sách: ReturnRequest

 Bill

3 Xác định đường sống cho mỗi đối tượng.

3.1 Tìm sách

Đối tượng SearchRequest và ResultList sẽ đực tạo ra theo yêu cầu của khách hàng

và hủy đi ngay sau đó

Các đối tượng còn lại được khởi tạo ngay khi bắt đầu sử dụng hệ thống và tồn tại đến hết nên không bị hủy đi

3.2 Mượn sách

Các đối tượng BorrowRequest, BorrowList, Bill đặc trưng cho 1 lần giao dịch nên

sẽ được hủy đi ngay khi kết thúc giao dịch

3.3 Trả sách

Các đối tượng ReturnRequest, ReturnList, Bill đặc trưng cho 1 lần giao dịch nên

sẽ được hủy đi ngay khi kết thúc giao dịch

4 Biểu diễn thông điệp.

4.1 Tìm sách

 Người dùng tạo yêu cầu tìm kiếm theo loại sách: make_catSR

 Hệ thống sẽ tìm kiếm trong cơ sở dữ liệu những sách thỏa mãn: findbooks

 Kết quả được trả về trong ResultList: result_in

 Đọc thông tin chi tiết về quyển sách mong muốn: getBasicInfor,

getAuthorInfor, getReviewInfor

4.2 Mượn sách

 Người dùng tạo yêu cầu mượn sách: makeBR

 Người dùng tạo danh sách sách muốn mượn: create_borrList

 Hệ thống cập nhật sách đã mượn trong cơ sở dữ liệu và trong danh sách mượn của khách: update

 Hệ thống in hóa đơn: makeBill

4.3 Trả sách

 Nhân viên tạo yêu cầu trả sách: makeRR

 Nhân viên tạo danh sách sách muốn trả: create_returnList

 Hệ thống cập nhật sách đã trả trong cơ sở dữ liệu và trong danh sách mượncủa khách: update

 Hệ thống in hóa đơn: printBill

5 Biểu diễn các điểm bắt đầu hoạt động trên mỗi đường sống.

6 Kiểm tra lại biểu đồ.

Bước 5 và 6 sẽ trình bày trên biểu đồ tuần tự tương ứng

Biểu đồ tuần tự mẫu cho ca sử dụng tìm kiếm

Biểu đồ tuần tự cho ca sử dụng mượn sách

Biểu đồ tuần tự cho ca sử dụng trả sách

Biểu đồ giao tiếp

Khi đã có được biểu đồ tuần tự ta có biểu đồ giao tiếp như sau:

Biểu đồ giao tiếp cho ca sử dụng tìm sách

Biểu đồ giao tiếp cho ca sử dụng mượn sách

Biểu đồ giao tiếp cho ca sử dụng trả sách

Biểu đồ máy trạng thái

Lựa chọn 2 đối tượng là “BorrowRequest” và “SearchRequest” để vẽ sơ đồ trạng thái.The life of an “BorrowRequest” object:

1 Khách hàng tạo một yêu cầu mượn sách là một danh sách các cuốn sách cần mượn

2 Khách hàng gửi yêu cầu mượn sách của mình sau khi đã chọn xong

3 Hệ thống tự động kiểm tra yêu cầu của khách hàng để đảm bảo tổng giá trị cáccuốn sách nhỏ hơn hoặc bằng số tiền đặt cọc còn lại của khách hàng

4 Nếu tổng giá các cuốn sách lớn hơn số tiền đặt cọc còn lại của khách hàng, yêu cầu bị từ chối và được gửi lại cho khách hàng để sửa hoặc hủy

5 Nếu điều kiện về tiền đặt cọc đã được thỏa mãn, yêu cầu được gửi tới cho nhân viên

6 Nhân viên đối chiếu yêu cầu mượn sách với sách mà khách hàng đã lấy ra để đảm bảo khách hàng lấy đúng và đủ sách

7 Nếu có sai sót, nhân viên thông báo cho khách hàng biết đồng thời, yêu cầu được gửi lại để khách hàng sửa hoặc hủy

8 Khi nhân viên đã xác nhận không còn sai sót, yêu cầu được chấp nhận

9 Nhân viên in hóa đơn

10 Khách hàng nhận sách và hóa đơn

11 Yêu cầu được đóng lại

The life of an “SearchRequest” object:

1 Khách hàng tạo một yêu cầu tìm sách (tìm theo tên, tìm theo thể loại, tìm theo tác giả)

2 Khách hàng gửi yêu cầu tìm sách của mình cho hệ thống

3 Hệ thống kiểm tra yêu cầu tìm kiếm của khách hàng để đảm bảo yêu cầu tìm kiếm đó có lỗi (không chứa ký tự đặc biệt, không quá dài/ngắn,…)

4 Nếu yêu cầu tìm kiếm có lỗi, yêu cầu bị từ chối và được trả lại cho khách hàng

để chỉnh sửa hoặc hủy bỏ

5 Nếu yêu cầu tìm kiếm không có lỗi, yêu cầu được chấp nhận

6 Các kết quả tìm kiếm được gửi về cho khách hàng

7 Yêu cầu được đóng lại

Biểu đồ gói

Biểu đồ lớp với 3 ca sử dụng: Tìm sách, mượn sách, trả sách

1 Xác định ngữ cảnh

Xây dựng biểu đồ gói cho tầng miền bài toán

2 Nhóm các lớp lại với nhau thành các gói

 Các lớp SearchRequest, TitleSearch, AuthorSearch, CategorySearch vàResultList có quan hệ tổng quát hóa với nhau (4 lớp đầu) và có quan hệchặt chẽ với nhau khi cùng thực hiện chức năng tìm kiếm được nhóm vớinhau thành gói search_pkg

 Lớp BorrowedList chỉ liên kết với lớp User_class, đặc trưng cho các quyểnsách mà khách hàng đang mượn Do đó 2 lớp này được nhóm chung vớinhau thành gói user_pkg

 Lớp Book, Author và Review có quan hệ tổng thể bộ phận và cùng cho cácthông tin cơ bản về sách nên được nhóm với nhau thành gói book_pkg

 Lớp BorrowRequest và BorrowList đặc trưng cho giao dịch mượn sách,cùng chung 1 mục đích với nhau được nhóm với nhau thành gói

borrow_pkg.

 Tương tự với 2 lớp ReturnList và ReturnRequest thành gói return_pkg

 2 lớp Manager_class và Bill sẽ không được nhóm và trở thành gói riêng:

manager_pkg và bill_pkg.

3 Xác định mối quan hệ phụ thuộc giữa các gói

 Cả 3 gói search_pkg, borrow_pkg, return_pkg đều phụ thuộc vào gói book_pkg

 Người dùng (user_pkg) phải phụ thuộc vào các phương pháp tìm kiếm (search_pkg) phần mềm cung cấp

 Borrow_pkg phụ thuộc vào user_pkg bởi mỗi người dùng sẽ có số tiền giới hạn mượn khác nhau

 Return_pkg sẽ phụ thuộc vào manager_pkg

 Bill_pkg phụ thuộc vào cả 3 gói user_pkg, return_pkg và borrow_pkg

4 Vẽ biểu đồ gói