HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG
KHOA CƠNG NGHỆ THÔNG TIN 1

BÁO CÁO NHẬP MÔN CÔNG NGHỆ PHẦN MỀM
ĐỀ TÀI: HỆ THỐNG QUẢN LÝ CỬA HÀNG CHO
THUÊ TRUYỆN

Nhóm học phần: Nhóm 03
Nhóm bài tập:

Nhóm 04

Modul:

Khách hàng trả truyện và thanh tốn

Thành viên:

Phạm Ngọc Cường - B20DCCN105
Nguyễn Đức Hịa - B20DCCN264
Hoàng Xuân Lương - B20DCCN412
Đinh Hữu Nam - B20DCCN026

Hà Nội - 2023


I. Biểu đồ UC chi tiết + mô tả các UC của modul
1. Diễn giải và vẽ biểu đồ Usecase chi tiết của modul
1. Diễn giải
Bước 1: Nhân viên chọn menu "Tìm danh sách truyện mượn theo tên
KH".

Bước 2: Nhân viên nhập tên khách hàng và click tìm kiếm.
Bước 3: Hệ thống hiển thị danh sách các khách hàng có tên vừa nhập.
Bước 4: Nhân viên chọn tên khách hàng đúng với thông tin khách hàng
hiện tại.
Bước 5: Hệ thống hiện lên danh sách các đầu truyện mà khách hàng đó
đang mượn, mỗi đầu truyện trên một dịng với đầy đủ thông tin về đầu
truyện, ngày mượn, giá mượn, và số tiền thuê tính đến ngày đang trả, cột
cuối cùng là ơ tích chọn trả.
Bước 6: Nhân viên click vào nút chọn trả cho các đầu truyện mà
khách hàng đem trả (có thể khơng trả hết 1 lần).
Bước 7: Nhân viên nhập tình trạng sách (nếu có hỏng hóc thì tìm chọn
hoặc thêm lỗi + nhập tiền phạt).
Bước 8: Cuối cùng, nhân viên click nút thanh toán.
Bước 9: Hệ thống hiện hóa đơn đầy đủ thơng tin khách hàng và 1 bảng
danh sách các đầu truyện trả như mô tả ở trên, dòng cuối là tổng số tiền
trả.
Bước 10: Nhân viên click xác nhận để hệ thống cập nhật vào CSDL.

2. Biểu đồ Usecase


- Các usecase được mô tả như sau:
+ Trả truyện và thanh toán: usecase này cho phép khách hàng trả truyện
và nhân viên thanh toán.
+ NV thu ngân đăng nhập: usecase này cho phép nhân viên thu ngân
đăng nhập.
+ Tìm khách hàng: usecase này cho phép nhân viên thu ngân tìm khách
hàng.
+ Tìm truyện: usecase này cho phép nhân viên thu ngân tìm truyện
+ Thêm lỗi : usecase này cho phép nhân viên thu ngân thêm lỗi khi

truyện hỏng
+ Xác nhận : usecase này cho phép khách hàng và nhân viên xác nhận
với nhau

II. Kịch bản chuẩn
Scenario
Actor
Precondition

Khách hàng trả truyện và thanh toán
Nhân viên thu ngân, khách hàng
-Nhân viên đã đăng nhập vào hệ thống
-Khách hàng cần trả sách đã được đăng ký và có đầu truyện mượn tại cửa
hàng

Postcondition

Hệ thống cập nhật danh sách các đầu truyện được trả và thơng tin hóa đơn
vào CSDL


Main
event

1. Khách hàng đem truyện đến yêu cầu nhân viên thực hiện trả truyện và
thanh toán, nhân viên thu ngân A nhập username: cashier, password:
acb@123 và click đăng nhập.
2. Hệ thống giao diện chính của nhân viên thu ngân có các lựa chọn:
- Quản lí thơng tin khách hàng
- Quản lí thơng tin mượn truyện

- Quản lí thơng tin khách hàng trả truyện và thanh toán
3. Nhân viên click chọn chức năng quản lí thơng tin mượn truyện.
4. Hệ thống hiện giao diện của chức năng quản lí thơng tin mượn truyện.
5. Nhân viên click vào chức năng tìm danh sách truyện mượn theo tên khách
hàng.
6. Hệ thống hiện giao diện nhập tên khách hàng để tìm kiếm hiện ra.
7. Nhân viên hỏi khách hàng tên, khách hàng trả lời, nhân viên nhập
đúng tên mà khách hàng nói và click vào nút “Tìm kiếm”.
8. Hệ thống hiện giao diện ra danh sách các khách hàng có tên vừa nhập.
9. Nhân viên xác nhận lại với khách hàng để chọn dòng chứa khách
hàng có thơng tin trùng khớp với khách hàng hiện tại, click vào
dịng đó.
10. Hệ thống hiện giao diện các đầu truyện mà khách hàng đó đang mượn:
Id Name
Title
Date
Price
Total
Choose
rent
rent
rent
pay
1 Pham
Conan
7/3/2023 5000
20000
Chọn
Van A
trả

2
Pham
Doremon 7/3/2023 4000
15000
Chọn
Van A
trả
11. Nhân viên click vào ô chọn trả các đầu sách mà khách hàng đem trả
(có thể khơng trả hết ), nhập thơng tin tình trạng sách và số tiền phạt
(nếu có)
12. Hệ thống hiện giao diện trả truyện:
Id Title
Date
Date pay
Book
Penalty Pay
rent
condition fee
1 Conan 7/3/2023 14/3/2023 Tốt
0
Thanh
toán
13. Nhân viên click vào nút thanh toán
14. Hệ thống hiện giao diện thanh tốn đầy đủ thơng tin khách hàng + bảng
danh sách các đầu truyện trả
Id
1

Name
Pham

Van A

Tel
Email
0312313176

Address
Hà
Nội


Exception

Id Title

Date pay

1

14/3/2023

Date
rent
Conan 7/3/2023

Book
Penalty Amount Choose
condition fee
Tốt
0

20000
Xác
nhận

15. Nhân viên thông báo số tiền tổng phải trả cho khách
hàng.
16. Khách hàng thanh toán cho nhân viên số tiền được yêu
cầu.
17. Nhân viên click chọn nút “Xác nhận” để xác nhận trả
truyện
18. Hệ thống cập nhật vào cơ sở dữ liệu, thông báo “Thành công”.
19. Nhân viên thông báo lại cho khách hàng kết thúc thành
công giao dịch.
1. Hệ thống báo sai username/password
1.1Nhân viên click ok của thông báo
1.2Hệ thống quay về giao diện đăng nhập
1.3 Nhân viên nhập lại username/password
1.4 Hệ thống hiện giao diện của nhân viên ( bước 2)
8. Hệ thống khơng tìm thấy tên khách hàng
8.1Nhân viên nhập tên khách hàng tìm kiếm
8.2Hệ thống khơng tìm thấy khách hàng trong hệ thống
8.3Nhân viên click ok của thông báo
8.4 Hệ thống quay về bước 7
8.5 Nhân viên nhập lại tên khách hàng
8.6 Hệ thống hiện lại danh sách khách hàng vừa nhập


III. Biểu đồ thực thể pha phân tích của modul
1. Diễn giải
- Cửa hàng: là đối tượng xử lí của hệ thống → là một lớp thực thể: Store

- Đầu truyện: là đối tượng xử lí của hệ thống → là một lớp thực thể: Story
- Khách hàng: là đối tượng xử lí của hệ thống → là một lớp thực thể:
Customer
- Phiếu mượn : là đối tượng xử lí của hệ thống → là một lớp thực thể:
Borrowing
- Phiếu trả: là đối tượng xử lí của hệ thống → là một lớp thực thể:
RecieptSlip
- Nhân viên: không phải đối tượng xử lí trực tiếp của hệ thống, nhưng cũng
bị quản lý cùng với quản lý theo kiểu người dùng trực tiếp của phần mềm
→ đề xuất một lớp thực thể chung: User
- Tài sản đảm bảo: là đối tượng xử lí của hệ thống → là một lớp thực thể:
Collateral
- Lỗi hỏng: là đối tượng xử lí của hệ thống → là một lớp thực thể:
BrokenError
- Truyện trả: là đối tượng xử lí của hệ thống → là một lớp thực thể:
ReturnedStory
Như vậy, các lớp thực thể ban đầu là Store, Story, Customer, Borrowing,
ReiceptSlip, User, Collateral, BrokenError, ReturnedStory
Quan hệ giữa các lớp thực thể được xác định như sau:
- Một Store có nhiều Story, một Story chỉ thuộc vào một Store. Vậy quan hệ
giữa Store và Story là 1 – n.
- Mỗi Story có thể có nhiều phiếu mượn khác nhau Borrowing, mỗi phiếu
mượn Borrowing mượn được nhiều Story khác nhau. Quan hệ giữa
Borrowing và Story là n – n. Vậy nên ta có BorrowingDetail là thực thể
liên kết giữa Story và Borrowing.
- Một Customer có thể có nhiều phiếu mượn Borowing, mỗi phiếu mượn
Borrowing chỉ được sở hữu bởi một khách hàng duy nhất. Quan hệ giữa
Customer và Borrowing là 1 – n.
- Một User cũng có thể lập nhiều RecieptSlip khác nhau cho các lần mượn
do đó, quan hệ giữa User và RecieptSlip là quan hệ 1 – n.



- Mỗi sách trả ReturnedStory có thể có nhiều lỗi BrokenError, và mỗi lỗi
BrokenError có thể xuất hiện ở nhiều truyện trả ReturnedStory. Quan hệ
giữa BrokenError và ReturnedStory là n – n. Vậy nên ta có ErrorAfterDetail
là thực thể liên kết giữa BrokenError và ReturnedStory.
- Mỗi phiếu mượn chi tiết BorrowingDetail có thể có nhiều lỗi
BrokenError, và mỗi lỗi BrokenError có thể có ở nhiều phiếu mượn chi
tiết BorrowingDetail. Quan hệ giữa BrokenError và BorrowingDetail là n
– n . Vậy nên có ErrorBeforeDetail là thực thể liên kết giữa
BorrowingDetail và BrokenError.
- Mỗi phiếu mượn có thể có nhiều tài sản đặt cọc, mỗi tài sản đặt cọc có thể
có nhiều phiếu mượn. Quan hệ giữa Borrowing và Collateral là n – n. Vậy
nên CollateralDetail là thực thể liên kết giữa Borrowing và Collateral.

2. Biểu đồ


IV. Biểu đồ lớp đầy đủ pha phân tích của modul
1. Diễn giải
1. Vào hệ thống -> Xuất hiện giao diện đăng nhập -> cần lớp: LoginView
• Đầu vào cho tên người dùng -> inUsername
• Nhập mật khẩu -> inPassword
• Gửi để đăng nhập -> subLogin
2. Nhập tên người dùng/mật khẩu -> hệ thống phải kiểm tra xem đăng nhập
có đúng khơng -> cần phương pháp:
• Tên: checkLogin()
• Đầu vào: username, password ( của lớp User)
• Đầu ra: Boolean
• Gán cho lớp thực thể: User

3. Sau khi đăng nhập thành cơng -> xuất hiện giao diện chính của nhân viên
thu ngân -> cần có lớp: UserHomeView có ít nhất:
• Một tùy chọn để chọn quản lí khách hàng -> subCustomer
• Một nút hủy -> subCancel
4. Chọn quản lí khách hàng -> xuất hiện giao diện tìm kiếm khách hàng ->
cần có lớp: SearchCustomerView:
• Nhập tên khách hàng -> inName
• Một nút tìm kiếm -> subSearch
• Một nút ok -> subOK
• Một nút hủy -> subCancel
• Một bảng để hiển thị kết quả (có thể nhấp) -> outListCustomer
5. Nhập tên khách hàng và click vào nút tìm kiếm -> hệ thống phải tìm tất
cả các khách hàng có tên với khách hàng vừa nhập -> cần có phương
pháp:
• Tên: searchCustomerByName()
• Đầu vào: inName
• Đầu ra: danh sách khách hàng theo tên
• Gán cho lớp thực thể: Customer
6. Kết quả sau đó được trả về (và hiển thị trên) SearchCustomerView


7. Nhân viên thu ngân chọn đúng khách hàng -> xuất hiện giao diện danh
sách truyện mà khách hàng đang mượn -> cần có lớp: StoryView
• Hiển thị tồn bộ thơng tin về đầu truyện -> outListStory
• Một nút thêm lỗi khi truyện hỏng -> subAddFault
• Một nút thanh tốn -> subPayment
• Một nút hủy -> subCancel
8. Nhân viên click chọn trả cho các đầu truyện mà khách hàng đem trả ->
xuất hiện giao diện tình thêm trạng sách addFault() -> cần có class:
AddFaultView

• Nhập lỗi -> inDescription
• Một nút reset -> subReset
• Một nút save -> subSave
• Gán cho lớp thực thể: ErrorAfterDetail
9. Xuất hiện giao diện xác nhận -> cần có lớp ComfirmView
• Hiển thị tồn bộ thơng tin về RecieptSlip -> out RecieptSlip
• Một nút xác nhận -> subComfirm
• Một nút hủy -> subCancel
• Một nút ok -> subOK
10. Nhân viên chọn xác nhận sau khi có tổng hợp từ khách hàng -> hệ thống
phải lưu RecieptSlip vào Database -> cần có phương thức:
• Tên: getRecieptSlip()
• Đầu vào: một đối tượng của RecieptSlip
• Đầu ra: none hoặc boolean
• Gán cho lớp thực thể: RecieptSlip
11. Sau khi lưu vào Database, hệ thống quay trở lại UserHomeView

2. Biểu đồ



V. Biểu đồ tuần tự pha phân tích của modul
1. Scenario V2
1. Khách hàng đến cửa hàng yêu cầu trả truyện
2. Nhân viên nhập username/password vào loginView, click login
3. Lớp LoginView gọi lớp User để kiểm tra đăng nhập
4. Lớp User gọi hàm checkLogin()
5. Lớp User trả kết quả cho lớp loginView
6. Lớp LoginView gọi lớp UserHomeView hiển thị cho nhân viên thu ngân
7. Lớp UserHomeView hiển thị cho nhân viên

8. Nhân viên chọn chức năng tìm danh sách truyện mượn theo tên khách
hàng
9. Lớp UserHomeView gọi lớp SearchCustomerView để hiển thị cho nhân
viên thu ngân
10.Lớp SearchCustomerView hiển thị cho nhân viên thu ngân
11.Nhân viên thu ngân hỏi tên khách hàng
12.Khách hàng trả lời nhân viên ngân
13.Nhân viên nhập tên khách hàng tại lớp SearchCustomerView và click nút
tìm
14.Lớp SearchCustomerView gọi lớp Customer để tìm khách hàng
15.Lớp Customer gọi hàm SearchCustomerByName()
16.Lớp Customer trả kết quả tìm được về lớp SearchCustomerView
17.Lớp SearchCustomerView hiển thị kết quả cho nhân viên thu ngân
18.Nhân viên thu ngân hỏi khách hàng để xác nhận thông tin
19.Khách hàng xác nhận thông tin
20.Nhân viên thu ngân click vào khách hàng đang hiển thị tại lớp
SearchCustomerView
21.Lớp SearchCustomerView gọi lớp StoryView
22.Lớp StoryView hiển thị danh sách các đầu truyện mà khách hàng đang
mượn cho nhân viên thu ngân
23.Nhân viên thu ngân lặp lại những thông tin này cho khách hàng và yêu cầu
khách hàng xác nhận
24.Khách hàng xác nhận
25.Nhân viên thu ngân click nút thanh toán


26.Lớp StoryView gọi lớp ComfirmView
27.Lớp ComfirmView hiển thị hóa đơn đầy đủ thông tin khách hàng và bảng
danh sách các đầu truyện cho nhân viên thu ngân
28.Nhân viên thu ngân thông báo cho khách hàng số tiền cần trả

29.Khách hàng đồng ý và trả tiền cho nhân viên thu ngân
30.Nhân viên thu ngân click xác nhận
31.Lớp ComfirmView gọi lớp RecieptSlip
32.Lớp RecieptSlip gọi hàm getRecieptSlip()
33.Lớp RecieptSlip trả kết quả cho lớp ComfirmView
34.Lớp ComfirmView thơng báo cho nhân viên thanh tốn thành công
35.Nhân viên click OK
36.Lớp ComfirmView gọi lớp UserHomeView
37.Lớp UserHomeView hiển thị cho nhân viên thu ngân
38.Nhân viên thu ngân báo với khách hàng thanh tốn thành cơng.

2. Sequence diagram


VI. Biểu đồ thiết kế lớp thực thể của modul
1. Diễn giải
• Bước 1: Thêm thuộc tính id cho các lớp Không kế thừa từ lớp khách:
Store, Story, Customer, RecieptSlip, BorrowingDetail, Borrowing,
User, BorkenError, Collateral, ErrorBeforeDetail, ErrorAfterDetail,
ReturnedStory, CollateralDetail.
• Bước 2: Thêm loại của từng thuộc tính trong tất cả các lớp
• Bước 3: Chuyển đổi tất cả mối quan hệ liên kết thành mỗi quan hệ tổng
hợp/ thành phần tương ứng:
o Story + Borrowing -> BorrowingDetail được chuyển thành:
Story là thành phần của BorrowingDetail, BorrowingDetail là
thành phần của Borrowing
o Borrowing + Collateral -> CollateralDetail được chuyển thành:
Collateral là thành phần của CollateralDetail, CollateralDetail là
thành phần của Borrowing
o BorrowingDetail + BrokenError -> ErrorBeforeDetail được

chuyển thành: BrokenError là thành phần của ErrorBeforeDetail,
ErrorBeforeDetail là thành phần của BorrowingDetail.
o ReturnedStory + BrokenError -> ErrorAfterDetail được chuyển
thành: BrokenError là thành phần của ErrorAfterDetail,
ErrorAfterDetail là thành phần của ReturnedStory.
• Bước 4: Thêm các thuộc tính đối tượng tương ứng với mối quan hệ tập
hợp/thành phần:
• Story là thành phần của cửa hàng, loại n-1 -> Cửa hàng có danh sách
truyện.
• Story là thành phần của Borrowing, loại 1-n -> BorrowingDetail có
truyện.
• BorrowingDetail là thành phần của Borrowing, loại n-1 -> Borrowing
có danh sách các BorrowingDetail.
• Customer là thành phần của Borrowing, kiểu 1-n -> Borrowing có
Customer.
• User là thành phần của Borrowing, kiểu 1-n -> Borrowing có User.
• User là thành phần của RecieptSlip, loại 1-n -> RecieptSlip có User.
• Customer là thành phần của RecieptSlip, loại 1-n -> RecieptSlip có
Customer.
• ReturnedStory kế thừa BorrowingDetail.


• ReturnedStory là thành phần của RecieptSlip, loại n-1 -> RecieptSlip
có danh sách các ReturnedStory.
• Collateral là thành phần của CollateralDetail, kiểu 1-n ->
CollateralDetail có Collateral.
• CollateralDetail là thành phần của Borrowing, loại n-1 -> Borrowing
có danh sách các CollateralDetail.
• BrokenError là thành phần của ErrorBeforeDetail, kiểu 1-n ->
CollateralDetail có BrokenError.

• ErrorBeforeDetail là thành phần của BorrowingDetail, loại n-1 ->
BorrowingDetail có danh sách các ErrorBeforeDetail.
• BrokenError là thành phần của ErrorAfterDetail, kiểu 1-n ->
CollateralDetail có BrokenError.
• ErrorAfterDetail là thành phần của ReturnedStory, loại n-1 ->
• ReturnedStory có danh sách các ErrorAfterDetail.

2. Diễn giải


VII. Biểu đồ thiết kế CSDL của modul
1. Diễn giải
Dựa vào sơ đồ lớp thực thể đã trích được trong pha phân tích,
ta có thể đề xuất các bảng dữ liệu như sau:
• tblStore: Id, name, address, ratingStar, description
• tblCustomer: Id, name, address, email, tell, note
• tblUser: Id, fullname, username, password, position
• tblStory: Id, type, storyName, author, priceRent
• tblBorrowingDetail: Id, priceRent, dateRent, saleOff, note
• tblBorrowing: Id, dateRent, saleOff
• tblRecieptSlip: Id, datePay, total, note
• tblBrokenError: Id, description, saleOff
• tblErrorBeforeDetail: Id, description, saleOff, note
• tblErrorAfterDetail: Id, description, fine, note
• tblCollateralDetail: Id, quantity, status, description
• tblCollateral: Id, name, value, note
• tblReturnedStory: Id, datePay, note

Quan hệ giữa các bảng:
• 1 tblStore – n tblStory

• 1 tblStory – n tblBorrowingDetail
• 1 tblCustomer – n tlbBorrowing
• 1 tblCustomer – n RecieptSlip
• 1 tblUser – n tblRecieptSlip
• 1 tbl User – n tblBorrowing
• 1 tblBorrowing – n tblBorrowingDetail
• 1 tblBorrowing – n tblCollateral
• 1 tbl Collateral – n tblCollateralDetail
• 1 tblBorrowingDetail – n tblErrorBeforeDetail
• 1 tblBrokenError – n tbltblErrorBeforeDetail
• 1 tblBrokenError – n tbl ErrorAfterDetail


• 1 tbl ReturnedStory – n tbl ErrorAfterDetail
• 1 tbl RecieptSlip – n tbl ReturnedStory

2. Diễn giải

VIII. Biểu đồ thiết kế giao diện và biểu đồ lớp thiết kế chi tiết
đầy đủ của modul
1. Biểu đồ thiết kế giao diện


2. Biểu đồ lớp thiết kế chi tiết đầy đủ
a. Diễn giải
Chúng ta cần có các lớp theo mơ hình MVC cho modul này như sau:
- Các lớp tầng giao diện:
+ LoginFrm là giao diện đăng nhập. Nó cần một trường văn bản để nhập
tên người dùng, một trường văn bản để nhập mật khẩu và một nút để
đăng nhập.

+ UserHomeFrm là giao diện chính của nhân viên thu ngân. Nó cần ít
nhất một nút để chuyển đến chức năng tìm kiếm khách hàng.
+ SearchCustomerFrm là giao diện tìm khách hàng. Nó cần một trường
văn bản để nhập từ khóa để tìm kiếm khách hàng theo tên, một nút để
tìm kiếm và một bảng để hiển thị khách hàng đã tìm được.
+ StoryFrm là giao diện hiển thị tồn bộ truyện mà khách hàng đang
mượn. Nó cần một nút thêm lỗi khi truyện bị hỏng và một nút thanh
toán.
+ AddFault là giao diện để thêm lỗi. Nó cần một trường văn bản để nhập


lỗi, một nút để lưu lỗi.
+ ComfirmFrm là là giao diện xác nhận thơng tin thanh tốn.
- Các lớp điều khiến (DAO)
+ DAO là một lớp chung của DAO. Nó chỉ có cấu trúc để kết nối với
DB và cung cấp kết nối chung cho tất cả các lớp DAO kế thừa trong hệ
thống.
+ UserDAO là lớp để thao tác với DB liên quan đến đối tượng User, có
phương thức checkLogin() để kiểm tra đăng nhập có chính xác khơng.
+ CustomerDAO có phương thức searchCustomer() để tìm kiếm khách
hàng có tên chứa khóa đã nhập.
+ BrokenErrorDAO là có phương thức addFault() để thêm lỗi khi khách
hàng đem trả truyện.
+ RecieptslipDAO là có phương thức getRecieptSlip() để lấy hóa đơn
của khách hàng khi thanh toán.

b. Biểu đồ




IX. Biểu đồ tuần tự pha thiết kế của modul
1. Kịch bản chuẩn V3
1. Khách hàng đến trả truyện
2. Nhân viên thu ngân nhập tên người dùng, mật khẩu của mình và nhấp
nút đăng nhập trên LoginFrm
3. Hàm actionperformed() của LoginFrm được gọi
4. Hàm actionperformed() gọi User để tạo một đối tượng User
5. Lớp User đóng gói thơng tin vào một đối tượng User
6. Lớp User trả về đối tượng User cho hàm actionperformed()
7. Hàm actionperform() gọi hàm checkLogin() của lớp UserDAO
8. Hàm checkLogin() kiểm tra thông tin đăng nhập
9. Hàm checkLogin() gọi lớp User thiết lập thêm hai thuộc tính tên và vị
trí
10.Lớp User gọi hàm setName(), setPosition() của nó
11.Hàm checkLogin() trả kết quả cho actionperformed()
12.Hàm actionperformed() gọi lớp UserHomeFrm
13.Hàm tạo UserHomeFrm() được gọi
14.Giao diện UserHomeFrm được hiển thị cho nhân viên thu ngân
15.Nhân viên thu ngân nhấn vào chức năng tìm khách hàng trên giao diện
16.Hàm actionperformed() của lớp UserHomeFrm được gọi
17.Hàm actionperformed() gọi lớp SearchCustomerFrm
18.Hàm tạo SearchCustomerFrm() được gọi
19.Giao diện SearchCustomerFrm được hiển thị cho nhân viên thu ngân
20.Nhân viên thu ngân hỏi khách hàng tên
21.Khách hàng trả lời
22.Nhân viên thu ngân nhập tên khách hàng và nhấn vào tìm kiếm
23.Hàm actionperformed() của lớp SearchCustomerFrm được gọi
24.Hàm actionperformed() gọi hàm SearchCustomer() của lớp
CustomerDAO
25.Hàm SearchCustomer() thực hiện tìm kiếm khách hàng

26.Hàm SearchCustomer() gọi lớp Customer để đóng gói kết quả.
27.Lớp Customer trả về đối tượng cho hàm SearchCustomer()


28.Hàm SearchCustomer() trả kết quả về cho hàm actionperformed()
29.Hàm actionperformed() hiển thị kết quả trên giao diện
SearchCustomerFrm cho
nhân viên thu ngân
30.Nhân viên click vào tên khách hàng
31.Lớp SearchCustomerFrm gọi hàm actionperformed()
32.Hàm actionperformed() gọi lớp StoryFrm
33.Hàm tạo StoryFrm() được gọi
34.Giao diện StoryFrm được hiển thị cho nhân viên thu ngân
35.Nhân viên click thanh toán
36.Hàm actionperformed() của lớp StoryFrm được gọi
37.Hàm actionperformed() gọi lớp ComfirmFrm
38.Hàm tạo ComfirmFrm() được gọi
39.Giao diện ComfirmFrm được hiển thị cho nhân viên thu ngân
40.Nhân viên click xác nhận
41.Hàm actionperformed() của lớp ComfirmFrm được gọi
42.Hàm actionperformed() gọi hàm getRecieptSlip() của lớp
RecieptSlipDAO
43.Lớp RecieptSlipDAO thực hiện hàm getRecieptSlip()
44.Hàm getRecieptSlip() gọi lớp RecieptSlip để đóng gói kết quả
45.Lớp RecieptSlip trả về đối tượng cho hàm getRecieptSlip()
46.Hàm getRecieptSlip() trả kết quả về cho hàm actionperformed()
47.Hàm actionperformed() hiển thị kết quả trên giao diện ComfirmFrm
cho nhân viên
thu ngân thông báo thành công
48.Nhân viên thu ngân click OK của thống báo

49.Hàm actionperformed() gọi lại giao diện UserHomeFrm
50.Giao diện UserHomeFrm được hiển thị cho nhân viên thu ngân
51.Nhân viên thu ngân xác nhận thanh toán thành công với khách hàng.

2. Sequence diagram



X. Test plan và test case chuẩn cho hộp đen của modul
Black-box test plan:
TT
1

Modul
Trường hợp thử nghiệm
Khách hàng trả truyện và thanh tốn Khơng tính tiền phạt

2

Tính tiền phạt khi có sách bị hỏng

1. Trường hợp kiểm thử số 1
a. Cơ sở dữ liệu trước khi thử nghiệm:
• tblUser
Id
1
2
3

Fullname

Manager

Username

Password

position

manager

Administrator
Receptionist

admin
recept

manager
admin

manager
administrator
receptionist

recept

• tblStore
Id
1

Name

Address
StoryHappy 42 Thanh Binh, Ha Noi

Star Des
5

• tblCustomer
Id
1
2
3
4
•

Name
Le Van An
Pham Ngoc Cuong
Pham Ngoc Son
Nguyen Thi Tuyet

Address
Ha Noi
Hai Duong
Thanh Hoa
Ha Noi

Email






Tell
12345
23445
34456
25122

tblStory
Id
1
2
3

IdStore
1
1
1

Story name
Tam cam
Conan
Onepiece

Type
Co tich
Trinh tham
Phieu luu

Author

Khong co
Aoyama Gōshō
Oda Eiichiro

Price
4000
5000
5000


•

tblBorrowing
Id
1
2
3

•

Date rent
2023-03-15
2023-03-25
2023-03-30

Sale off
0
0
0


IdStory
1
2
3

IdBorrowing
1
2
3

Price rent
4000
5000
5000

Date rent
2023-03-15
2023-03-25
2023-03-30

Sale off
0
0
0

Note

tblRecieptSlip
Id
1

2
3

•

IdUser
1
1
1

tblBorrowingDetail
Id
1
2
3

•

IdCustomer
1
2
3

IdCustomer
1
2
3

IdUser
1

1
1

Date pay
2023-03-20
2023-04-01
2023-04-10

Total
24000
40000
60000

Note

tblReturnedStory
Id IdReceiptSlip Price rent
1
2
3

1
2
3

4000
5000
5000

Date rent Date pay


Sale off note

2023-03-15 2023-03-20 0
2023-03-25 2023-04-01 0
2023-03-30 2023-04-10 0

b. Kịch bản và kết quả mong đợi của trường hợp số 1


Scenario

Expected result

1.Khởi động ứng dụng

Giao diện đăng nhập xuất hiện với: trường văn bản để nhập tên người
dùng, mật khẩu, nút đăng nhập

2.Nhập username = recept Giao diện trang chủ của trình nhân viên thu ngân xuất hiện:
password = recept và click đăng - Customer
nhập
- Cancel
3.Bấm vào nút Customer

Giao diện quản lí khách hàng xuất hiện:
-Trường văn bản nhập tên khách hàng và nút tìm kiếm

4.Nhập tên khách hàng:
name = Nguyen Thi Tuyet,

click tìm

Giao diện tìm khách hàng:
Id Name
4 Nguyen
Thi Tuyet

Address
Hai
Duong

Email
Tell
25122

Note Select
✓

5.Click dòng tên Nguyen Thi Giao diện truyện xuất hiện các đầu truyện khách hàng đang mượn:
Tuyet
Id
Name
Date rent
Price rent Total
Choose pay
1
Connan
2023-04-26 5000
25000
✓

2

Onepiece

2023-04-26

5000

20000

✓

+ Nút thêm lỗi, thanh toán, hủy
6.Click vào chọn trả đầu
truyện conan , click nút
thanh toán

Giao diện thanh tốn xuất hiện với thơng tin khách hàng và thông tin
đầu truyện trả:
-id:4
-name: Nguyen Thi Tuyet
-address: Hai Duong
-email:
-tell: 25122
-name story: conan
-date rent : 2023-04-26
-date pay : 2023-04-30
-price rent : 5000
-total: 25000


7.Nhân viên click xác nhận

Hiện thông báo thành công