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

Thiết kế hệ thống quản lý thư viện
Nhóm 5 lớp KSTN – ĐTVT – K54
Đỗ Trung Đức
Trần Xuân Bách
Nguyễn Tiến Đạt
Hoàng Văn Pháp
Biểu đồ lớp
1. Xây dựng thẻ CRC.
1.1. Nhận diện lớp.
1.1.1. Ca sử dụng tìm sách.
Normal Flow of Events:
1. Khách hàng đưa ra yêu cầu m sách.
Nếu muốn m theo loại sách, thực hiện subows S-1.
Nếu muốn m theo tên sách, thực hiện subows S-2.
Nếu muốn m theo tác giả, thực hiện subows S-3.
Sub"ows:
S-1:
1. Khách hàng chọn sách theo chuyên ngành có trong danh sách các phân loại sách của
thư viện.
2. Hệ thống trả về các danh sách sách theo phân loại sách đó.
S-2:
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
6m 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ách
tì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ếm
theo 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 subows S-1
Nếu không thực hiện subows S-2
Sub"ows:
S-1:
1. Hệ thống cập nhật 6nh trạng mượn trả sách của khách hàng.
2. Hệ thống yêu cầu in hóa đơn.
S2:
Hệ thống báo lỗi, khách hàng có thể quay lại để Eế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êu
cầ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ỗi
khi 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 2n mượn trả
sách.
5. Nhân viên hỏi khách hàng có Eếp tục mượn sách ngay hay không
Nếu khách hàng muốn mượn Eếp sách, thực hiện subows S-1
Nếu khách hàng chỉ đến để trả sách, thực hiện subows S-2.
Sub"ows:

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ệc
trả 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
hàng
ID: 01 Type: High
Descrip2on: mô tả thông En khác hàng và các hoạt động
cùa khách hàng.
Associated Use Case:
Tìm sách.
Mượn sách.
Trả sách.
Chứng thực khách hàng.
Responsibili2es
Đưa ra yêu cầu 6m kiếm.
Đưa ra yêu cầu mượn sách.
Đưa ra yêu cầu trả sách.
Đăng nhập vào hệ thống.
Đưa ra yêu cầu xem thông En cơ bản.
Collaborators
Danh sách sách đã trả.
Yêu cầu 6m sách.
Yêu cầu mượn sách.
Astributes:

Tên (string).
Số nhận dạng ID (int).
Số điện thoại (int).
Số tài khoản/mật khẩu (string).
Rela2onships:
Generaliza2on (a kind of):
Aggrega2on (has parts):
Other Associa2ons: sách, yêu cầu 6m sách, yêu cầu mượn sách.
Class Name: sách ID: 02 Type: Medium.
Descrip2on: mô tả thông En về sách.
Associated Use Case:
Tìm sách.
Mượn sách.
Trả sách.
Responsibili2es
Cung cấp thông En về sách.
Collaborators
Danh sách 6m sách.
Danh sách mượn sách.
Danh sách trả sách.
Astributes:
Tên sách (string).
Tác giả (string).
Loại sách (string).
Mã số sách (string).
Giá sách (int).
Vị trí của sách (string).
Rela2onships:
Generaliza2on (a kind of):
Aggrega2on (has parts):

Other Associa2ons: Danh sách 6m 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
Descrip2on: Mô tả một yêu cầu của khách hàng. Associated Use Case: Mượn sách.
Responsibili2es
• Khởi tạo yêu cầu mượn sách
(boolean).
• Cập nhật vào danh sách các sách
đang có trong thư viện.
• Cập nhật vào danh sách các sách đã
mượn của khách hàng.
Collaborators
• Khách hàng: Khách hàng đưa ra yêu
cầu mượn sách.
• Danh sách sách mượn:
o Tạo một danh sách các cuốn
sách cần mượn.
o Thực hiện cập nhật lại danh
mục sách có trong thư viện và
danh mục sách đang mượn
của người dùng.
• Hóa đơn:
Astributes:
Rela2onships:
Generaliza2on (a kind of):
Aggrega2on (has parts): ………………………………………………………………
Other Associa2ons: Khách hàng, danh sách mượn, Hóa đơn.
Class Name: Yêu cầu 6m kiếm. ID: 04 Type: …
Descrip2on: Mô tả một yêu cầu của khách hàng.
Associated Use Case: Tìm kiếm.
Responsibili2es

• Thực hiện yêu cầu 6m kiếm (danh
sách).
Collaborators
• Khách hàng: Khách hàng đưa ra yêu
cầu 6m sách.
• Danh sách kết quả m kiếm:
o Thực hiện 6m 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 6m thấy.
Astributes:
• Kiểu 6m kiếm (int).
• Từ khóa 6m kiếm (string).
Rela2onships:
Generaliza2on (a kind of):
Aggrega2on (has parts): ………………………………………………………………
Other Associa2ons: Khách hàng, danh sách kết quả 6m 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
khách hàng và hệ thống.
Associated Use Case:
Mượn sách.
Trả sách.
Thay đổi tiền cọc.
Cập nhật phí hàng tháng.
Responsibilities
• In hóa đơn (Boolean)

Collaborators
1. Yêu cầu mượn sách.
2. Yêu cầu trả sách.
Astributes:
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.
Responsibilities
1. Xác nhật việc mượn trả sách.
Collaborators
1. Yêu cầu trả sách.
Astributes:
1. Tên (string).
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
Descrip2on: Mô tả yêu cầu trả sách của khách hàng
Associated Use Case:
Trả sách.
Responsibili2es Collaborators
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)
Rela2onships:
Generaliza2on (a kind of):
Aggrega2on (has parts): ………………………………………………………………
Other Associa2ons: 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
Descrip2on: Tập hợp các cuốn sách Associated Use Case:
Responsibili2es Collaborators
Yêu cầu 6m kiếm
Yêu cầu mượn
hóa đơn.
Sách.
yêu cầu trả.
Astributes:
Danh mục sách (array).
Rela2onships:
Generaliza2on (a kind of):
Aggrega2on (has parts): ………………………………………………………………
Other Associa2ons: Yêu cầu 6m 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 6m sách.
Nếu muốn 6m theo loại sách, thực hiện subows S-1.
Nếu muốn 6m theo tên sách, thực hiện subows S-2.
Nếu muốn 6m theo tác giả, thực hiện subows S-3.
Sub"ows:
S-1:
1. Khách hàng chọn sách theo chuyên ngành có trong danh sách các phân loại sách của
thư viện.
2. Hệ thống trả về các danh sách sách theo phân loại sách đó.
S-2:
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
6m 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 subows S-1
Nếu không thực hiện subows S-2
Sub"ows:
S-1:
1. Hệ thống cập nhật 6nh trạng mượn trả sách của khách hàng.
2. Hệ thống yêu cầu in hóa đơn.
S2:
Hệ thống báo lỗi, khách hàng có thể quay lại để Eếp tục mượn các cuốn sách khác.
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 En mượn trả sách.
5. Nhân viên hỏi khách hàng có Eếp tục mượn sách ngay hay không

Nếu khách hàng muốn mượn Eếp sách, thực hiện subows S-1
Nếu khách hàng chỉ đến để trả sách, thực hiện subows S-2.
Sub"ows:
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ượn
củ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ác
cuố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ới
nhau 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ển
sách mà khách hàng đang mượn. Do đó 2 lớp này được nhóm chung với
nhau 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ác
thô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