BAN CƠ YẾU CHÍNH PHỦ

HỌC VIỆN KỸ THUẬT MẬT MÃ

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

BÁO CÁO BÀI TẬP LỚN

MÔN: Phân tích thiết kế hệ thống thông tin
ĐỀ TÀI: Phân tích thiết kế website tìm kiếm phòng trọ

Khoa: An toàn thông tin

Giáo viên hướng dẫn: Thầy Nguyễn Đức Hiếu

Sinh viên thực hiện:

Hà Nội, Năm 2022

Mục Lục
1. GIỚI THIỆU 5
1.1. Mục đích tài liệu 5
1.2. Phạm vi tài liệu 5
1.3. Từ điển thuật ngữ 5

2. TỔNG QUAN VỀ HỆ THỐNG 6

2.1. Phát biểu bài toán 6
2.2. Mục tiêu hệ thống 6
2.3. Phạm vi hệ thống 7

3. NẮM BẮT YÊU CẦU 8

3.1. Quy trình nghiệp vụ 8
3.1.1. Quy trình đặt phòng 8
3.1.2. Quy trình đăng phòng 9
3.1.3. Quy trình duyệt phòng 10
3.1.4. Quy trình sửa phòng 11
3.1.5. Quy trình cập nhật thông tin cá nhân 12
3.1.6. Quy trình đăng nhập 13
3.1.7. Quy trình xóa người dùng 14
3.1.8. Quy trình báo cáo bài viết 15
3.1.9. Quy trình xử lý báo cáo 16
3.1.10. Quy trình đăng ký tài khoản 17
3.1.11. Mô hình phân cấp chức năng 18
3.2. Mô hình ca sử dụng 19
3.2.1. Biểu đồ ca sử dụng mức tổng thể của hệ thống 19
3.2.2. Biểu đồ ca sử dụng mức chi tiết 20
3.2.2.1. Đăng nhập 20
3.2.2.2. Đặt phòng 20
3.2.2.3. Xử lý báo cáo từ người dùng 20
3.2.2.4. Tạo tài khoản 21
3.2.2.5. Cập nhật thông tin cá nhân 21
3.2.2.6. Duyệt phòng 21
3.2.2.7. Xóa phòng 21
3.2.2.8. Sửa phòng 22
3.2.2.9. Đăng phòng 22
3.2.2.10. Báo cáo phòng 22
3.2.2.11. Tìm phòng 22
3.2.2.12. Xem phòng 23
3.2.2.13. Xóa User 23

2
 3.2.3. Đặc tả các ca sử dụng 23
3.2.4. Đặc tả bổ sung 39

4. PHÂN TÍCH 40
4.1. Phân tích kiến trúc 40
4.2. Phân tích các ca sử dụng 41
4.2.1. Đăng nhập 41
4.2.2. Tạo tài khoản 42
4.2.3. Cập nhật thông tin cá nhân 43
4.2.4. Duyệt phòng 43
4.2.5. Xóa phòng 45
4.2.6. Sửa phòng 46
4.2.7. Đăng phòng 47
4.2.8. Báo cáo phòng 48
4.2.9. Tìm phòng 49
4.2.10. Xem phòng 50
4.2.11. Đặt phòng 51
4.2.12. Xóa User 52
4.2.13. Xử lý báo cáo từ người dùng 53

5. THIẾT KẾ 53
5.1. Kiến trúc vật lý 54
5.2. Xác định các phần tử thiết kế 54
5.2.1. Các gói thiết kế 54
5.2.2. Các lớp thiết kế 54
5.3. Thiết kế các giao diện 56
5.3.1. Trang chủ 56
5.3.2. Đăng nhập 57
5.3.3. Trang cá nhân 57
5.3.4. Chỉnh sửa trang cá nhân 58
5.3.5. Đăng phòng 58
5.3.6. Danh sách phòng 60
5.3.7. Chi tiết phòng 61
5.4. Thiết kế các lớp 61
5.4.1. Đăng nhập 61
5.4.2. Tạo tài khoản 62
5.4.3. Cập nhật thông tin cá nhân 62
5.4.4. Duyệt phòng 62
5.4.5. Xóa phòng 64
5.4.6. Sửa phòng 65
5.4.7. Đăng phòng 66
5.4.8. Báo cáo phòng 66

3
 5.4.9. Tìm phòng 67
5.4.10. Xem phòng 68
5.4.11. Đặt phòng 69
5.4.12. Xóa User 69
5.4.13. Xử lý báo cáo từ người dùng 70
5.5. Thiết kế Database 70

4
1. GIỚI THIỆU
1.1. Mục đích tài liệu
Tài liệu này là để xác định các yêu cầu phi chức năng của hệ thống như độ tin cậy,
khả năng sử dụng, hiệu suất và khả năng hỗ trợ, cũng như các yêu cầu chức năng phổ
biến trong một số trường hợp sử dụng. Từ đó xây dựng các mô hình tạo điều kiện cho
việc nắm bắt hệ thống cũng như trao đổi giữa các bên liên quan

1.2. Phạm vi tài liệu

Các đặc tả trong tài liệu này áp dụng cho hệ thống YouRoom, là một trang web hỗ
trợ tìm kiếm phòng trọ tại Việt Nam.

1.3. Từ điển thuật ngữ

Administrator

Người có nhiệm vụ phê duyệt các bài viết trước khi chúng được đăng, xóa các bài bị
báo cáo và xóa những người dùng có hành vi lạm dụng nhằm đảm bảo rằng trang web
không có quảng cáo spam hoặc các hành vi lạm dụng.

Account

Một bản ghi về người dùng hoặc quản trị viên chứa những thông tin như họ và tên, e-
mail, địa chỉ, mật khẩu, số điện thoại ... Mỗi tài khoản có một ID người dùng và mật khẩu
riêng, được sử dụng để xác định người dùng hoặc quản trị viên và cấp cho họ truy cập
vào các phần an toàn của hệ thống.

Report

Một thông báo được gửi từ người dùng đã đăng ký đến quản trị viên về việc một bài
đăng đã vi phạm chính sách của trang web.

Room

Một phòng được đăng bởi một người dùng đã đăng ký nhằm mục đích cho thuê
phòng trọ do người dùng đó sở hữu. Một phòng chứa các thông tin về hình ảnh, địa điểm,
giá cả và mô tả của người đăng về những dịch vụ mà căn phòng đó sở hữu.

5
User

Bất kỳ người nào có tài khoản đã đăng ký trên trang web nhưng không phải là quản
trị viên. Người dùng có thể thực hiện nhiều tác vụ với tài khoản và phòng của họ.

Visitor

Một người quan tâm đến việc xem các phòng trên trang web nhưng không có tài
khoản.

Payment System

Một hệ thống cung cấp các dịch vụ thanh toán và xử lý các giao dịch.

2. TỔNG QUAN VỀ HỆ THỐNG

2.1. Phát biểu bài toán
Xây dựng 1 website giúp cho việc kết nối các đối tượng có nhu cầu thuê trọ/ cho thuê
trọ dễ dàng và thuận tiện hơn. Các phòng được kiểm duyệt nghiêm ngặt, giúp cung cấp
những phòng trọ chất lượng cao, đúng với mô tả, … Những đối tượng có nhu cầu thuê trọ
có thể lên website để tìm kiếm và chọn lựa các căn phòng đã được đăng tải lên website
bởi các đối tượng có nhu cầu cho thuê.

2.2. Mục tiêu hệ thống

YouRoom được xây dựng ra là một hệ thống giao dịch trực tuyến như một phương
tiện để kết nối các đối tượng có nhu cầu thuê trọ/cho thuê trọ, giải quyết các vấn đề khó
khăn trong qua quá trình tìm nhà trọ của người đi thuê cũng như việc tìm khách hàng của
các chủ trọ. Giúp cho những công việc trước kia của họ trở nên đơn giản, thuận tiện hơn,
tiết kiệm thời gian, công sức để có thể tìm được một nơi ở phù hợp

2.3. Phạm vi hệ thống

- Users và Visitors

Users và Visitors có thể tìm kiếm và xem các bài đăng trong hệ thống. Đồng thời họ
cũng có thể báo cáo các bài đăng sai phạm cho Administrators xử lý. Sau khi đăng ký tài
khoản, Users có thể đăng bài để quảng bá phòng của họ và quản lý bài đăng đó.

6
- Administrators

Administrators có trách nhiệm giám sát tất cả các tài khoản của Users và các bài đăng
của họ. Tất cả các bài đăng của Users khi đăng lên đều phải được Administrators phê
duyệt. Để đảm bảo độ tin cậy của hệ thống, Administrators có thể xem các báo cáo do
Users thực hiện, xóa các bài đăng spam và xóa những Users không chấp thuận theo yêu
cầu của hệ thống và có các hành vi lạm dụng.

Stakeholders

- Nhà tài trợ: Tập đoàn viễn thông ABCs

- Đối tác truyền thông: VnExpress, Dantri, VietnamNet

- Cổng thanh toán: ngân hàng, ví điện tử : MBBank, Momo, Zalopay

7
3. NẮM BẮT YÊU CẦU
3.1. Quy trình nghiệp vụ
3.1.1. Quy trình đặt phòng

8
3.1.2. Quy trình đăng phòng

9
3.1.3. Quy trình duyệt phòng

10
3.1.4. Quy trình sửa phòng

11
3.1.5. Quy trình cập nhật thông tin cá nhân

12
3.1.6. Quy trình đăng nhập

13
3.1.7. Quy trình xóa người dùng

14
3.1.8. Quy trình báo cáo bài viết

15
3.1.9. Quy trình xử lý báo cáo

16
3.1.10. Quy trình đăng ký tài khoản

17
3.1.11. Mô hình phân cấp chức năng

18
3.2. Mô hình ca sử dụng
3.2.1. Biểu đồ ca sử dụng mức tổng thể của hệ thống

19
3.2.2. Biểu đồ ca sử dụng mức chi tiết

3.2.2.1. Đăng nhập

3.2.2.2. Đặt phòng

3.2.2.3. Xử lý báo cáo từ người dùng

20
3.2.2.4. Tạo tài khoản

3.2.2.5. Cập nhật thông tin cá nhân

3.2.2.6. Duyệt phòng

21
3.2.2.7. Xóa phòng

3.2.2.8. Sửa phòng

3.2.2.9. Đăng phòng

22
3.2.2.10. Báo cáo phòng

3.2.2.11. Tìm phòng

3.2.2.12. Xem phòng

23
 3.2.2.13. Xóa User

3.2.3. Đặc tả các ca sử dụng

Use Case Đăng phòng

Actor User

Brief Description Ca sử dụng này mô tả cách User đăng một phòng lên hệ
thống.

Pre-conditions User đã đăng nhập vào hệ thống.

Basic Flows Ca sử dụng bắt đầu khi User yêu cầu đăng một phòng.

1. Hệ thống hiển thị một form và yêu cầu User nhập vào
các thông tin:

- Chủ đề

- Thể loại

- Địa chỉ

24
 - Giá

- Mô tả

- Ảnh

2. Khi User cung cấp đủ các thông tin, hệ thống sẽ sinh

ngẫu nhiên 1 ID duy nhất sau đó gán cho phòng, và thêm
phòng vừa tạo vào hàng đợi duyệt.

Nếu bất kì trường thông tin bắt buộc nào không được nhập,
Alternative Flows hệ thống sẽ hiển thị một thông báo lỗi. User có thể bổ sung
thông tin trong form tạo phòng hoặc dừng việc tạo phòng,
khi đó ca sử dụng kết thúc.

Post-conditions Nếu ca sử dụng thành công, phòng được tạo và chờ được
duyệt. Nếu không, hệ thống giữ nguyên trạng thái.

Special Requirements Không có

Use Case Duyệt phòng

Actor Administrator

Brief Description Ca sử dụng này mô tả cách Administrator phê duyệt các

phòng hoặc xóa chúng.

Pre-conditions Administrator cần phải đăng nhập vào hệ thống.

25
Basic Flows Ca sử dụng bắt đầu khi Administrator xem danh sách các
phòng chưa được duyệt.

1. Hệ thống hiển thị danh sách những phòng chưa được

duyệt. Khi đó, hệ thống sẽ hiển thị 2 lựa chọn, “Phê duyệt”
hoặc “Xóa”.

2. Nếu Administrator chọn “Phê duyệt”, luồng phụ “Phê

duyệt phòng" sẽ được chạy. Nếu chọn “Xóa”, luồng phụ
“Xoá phòng" sẽ được chạy.

- Phê duyệt phòng

1. Hệ thống yêu cầu Administrator xác nhận quyết định

duyệt phòng.

2. Administrator xác nhận việc duyệt phòng.

3. Hệ thống thống thay đổi trạng thái phòng thành

“Approved”.

- Xoá phòng

1. Hệ thống yêu cầu Administrator xác nhận quyết định xóa

phòng.

2. Administrator xác nhận việc xoá phòng.

3. Hệ thống xoá phòng.

Trong khi thực hiện những luồng phụ, Administrator chọn

Alternative Flows “Huỷ", phòng sẽ không được duyệt hay bị xoá.

Post-conditions Nếu ca sử dụng thành công, phòng sẽ được thay đổi trạng
thái và được đăng lên trên hệ thống hoặc bị xóa. Nếu

26
 không, trạng thái của phòng không đổi

Special Requirements Không có

Use Case Đặt phòng

Actor User, Payment System

Brief Description Ca sử dụng này mô tả cách User thực hiện đặt một phòng
phù hợp với nhu cầu của họ.

Pre-conditions User đã đăng nhập vào hệ thống

Basic Flows - Ca sử dụng sẽ bắt đầu khi User bấm vào nút “Đặt
phòng” khi đang xem thông tin về phòng:
1. Hệ thống yêu cầu User lựa chọn phương thức thanh
toán,
2. User lựa chọn phương thức thanh toán, hệ thống sẽ
chuyển hướng giao diện thanh toán do Payment
System cung cấp tùy vào phương thức thanh toán đã
lựa chọn.
3. User tiến hành quá trình thanh toán.
4. Payment System xử lý việc thanh toán.
5. Nếu quá trình thanh toán thành công, hệ thống sẽ
cập nhật trạng thái của phòng thành đã được đặt.

27
 - Việc thanh toán bị hủy:
Alternative Flows Trong quá trình thanh toán, User quyết định “Hủy”
bất cứ thời điểm nào, hệ thống sẽ ngừng quá trình,
ca sử dụng kết thúc.
- Xử lý việc thanh toán gặp lỗi:
Nếu Payment System gặp bất cứ lỗi nào trong quá
trình xử lý thanh toán, hệ thống sẽ hiển thị thông báo
lỗi, ca sử dụng bắt đầu lại từ đầu.
- Việc cập nhật thông tin lỗi:
Nếu việc cập nhật thông tin bị lỗi, hệ thống sẽ gửi
yêu cầu hoàn trả tiền đến Payment System. Payment
System sẽ xử lý việc hoàn trả tiền cho User.

Post-conditions Nếu ca sử dụng thành công, trạng thái của phòng trên hệ
thống sẽ thay đổi.

Special Requirements User có tài khoản thanh toán online tại các ngân hàng

Use Case Tìm phòng

Actor User, Visitor

Brief Description Ca sử dụng này mô tả cách User hoặc Visitor tìm kiếm
phòng phù hợp với nhu cầu của họ.

Pre-conditions Không có

28
Basic Flows Ca sử dụng bắt đầu khi User/Visitor muốn tìm kiếm phòng.

1. Hệ thống sẽ hiển thị form với những thuộc tính mong

muốn :

- Chủ đề

- Thể loại

- Địa chỉ

- Giá

- Mô tả

- ID người đăng

2. User/Visitor tiến hành nhập các thông tin. Khi

User/Visitor bấm vào nút “Tìm kiếm”, hệ thống sẽ thực
hiện một query lên room database và hiển thị danh sách kết
quả.

Nếu bất kì trường thông tin bắt buộc nào không được nhập,
Alternative Flows hệ thống sẽ hiển thị một thông báo lỗi. User/Visitor có thể
tùy chỉnh các thuộc tính mong muốn trong form tìm kiếm
hoặc dừng việc tìm kiếm phòng, khi đó ca sử dụng kết thúc.

Post-conditions Nếu ca sử dụng thành công, danh sách những phòng đáp
ứng được những thuộc tính đã đề ra sẽ được hiển thị.

Special Requirements Không có

Use Case Xem phòng

29
Actor User, Visitor.

Brief Description Ca sử dụng này mô tả cách User/Visitor xem thông tin về

một phòng được đăng trên hệ thống.

Pre-conditions Không có

Basic Flows - Ca sử dụng bắt đầu khi User/Visitor truy cập vào
đường link của phòng hoặc lựa chọn một phòng từ
trong danh sách các phòng đã tìm kiếm:
Hệ thống sẽ hiển thị các thông tin chi tiết về phòng
cũng như thông tin về User đã đăng phòng đó như
tên, địa chỉ, các thông tin liên lạc, …

Không có
Alternative Flows

Post-conditions Không có

Special Requirements Không có

Use Case Đăng nhập

Actor User, Administrator

30
Brief Description Ca sử dụng này mô tả cách User/Administrator đăng nhập
vào hệ thống.

Pre-conditions Hệ thống ở trạng thái cần đăng nhập và có màn hình đăng
nhập hiển thị.

Basic Flows Ca sử dụng bắt đầu khi User/Administrator muốn đăng

nhập vào hệ thống.

1. User / Administrator nhập tên tài khoản và mật khẩu.

2. Hệ thống kiểm tra tên tài khoản và mật khẩu đã nhập và

đưa User / Administrator vào trong hệ thống

Alternative Flows - Nếu nhập vào tên tài khoản và mật khẩu không hợp
lệ (thông tin sai hoặc vi phạm các ràng buộc), hệ
thống sẽ hiển thị một thông báo lỗi.
User/Administrator có thể lựa chọn bắt đầu lại quá
trình đăng nhập hoặc hủy đăng nhập, khi đó ca sử
dụng kết thúc.
- Nếu bất kì trường thông tin bắt buộc nào không
được nhập, hệ thống sẽ hiển thị một thông báo lỗi.
User/Administrator có thể tiếp tục nhập thông tin
hoặc dừng việc đăng nhập, khi đó ca sử dụng kết
thúc.

Post-conditions Nếu ca sử dụng thành công, User / Administrator đã được

đăng nhập vào hệ thống. Nếu không, trạng thái hệ thống
không thay đổi.

31
 Special Requirements Không có

3.

Use Case Tạo tài khoản

Actor Visitor

Brief Description Ca sử dụng này mô tả cách Visitor tạo tài khoản trên hệ
thống.

Pre-conditions Không có

Basic Flows Ca sử dụng bắt đầu khi Visitor yêu cầu tạo tài khoản trên
website.

1. Hệ thống sẽ hiển thị một form yêu cầu người dùng nhập
vào các thông tin

- Tên tài khoản.

- Mật khẩu.

- Họ và tên.

- Số điện thoại.

- Địa chỉ email.

2. Khi Visitor đã cung cấp đầy đủ các thông tin được yêu
cầu, hệ thống sẽ kiểm tra để đảm bảo tên tài khoản chưa

32
 được sử dụng và các trường bắt buộc được nhập đầy đủ
cũng như các ràng buộc dữ liệu đi kèm. Sau đó, hệ thống sẽ
tiến hành tạo và thêm tài khoản mới với những thông tin
trên vào trong user database

Alternative Flows - Nếu bất kì trường thông tin bắt buộc nào không
được nhập, hệ thống sẽ hiển thị một thông báo lỗi.
Visitor có thể bổ sung thông tin trong form tạo tài
khoản hoặc dừng việc tạo tài khoản, khi đó ca sử
dụng kết thúc
- Nếu như tên tài khoản người dùng nhập vào đã tồn
tại, hệ thống sẽ hiển thị một thông báo lỗi. Visitor có
thể nhập lại một tên tài khoản khác hoặc dừng việc
tạo tài khoản, khi đó ca sử dụng kết thúc

Post-conditions Nếu ca sử dụng thành công, một account mới được thêm
vào hệ thống. Nếu không, trạng thái của hệ thống sẽ giữ
nguyên.

Special Requirements Không có

Use Case Cập nhật thông tin tài khoản

Actor User

Brief Description Ca sử dụng này mô tả cách User cập nhật thông tin về tài
khoản của họ trong hệ thống.

33
Pre-conditions User cần phải đăng nhập vào hệ thống.

Basic Flows Ca sử dụng bắt đầu khi User yêu cầu cập nhật thông tin tài
khoản.

1. Hệ thống sẽ hiển thị những trường thông tin có thể chỉnh

sửa được và yêu cầu người dùng thực hiện thay đổi.

- Mật khẩu

- Họ và tên

- Số điện thoại

- Địa chỉ email

2. Khi người dùng đã cung cấp các thông tin yêu cầu, hệ
thống tiến hành kiểm tra các ràng buộc đi kèm sau đó cập
nhật thông tin về tài khoản trong user database.

Nếu bất kì trường thông tin bắt buộc nào bị bỏ trống, hệ

Alternative Flows thống sẽ hiển thị một thông báo lỗi. User có thể thay đổi
thông tin trong form cập nhật thông tin tài khoản hoặc dừng
việc cập nhật thông tin tài khoản, khi đó ca sử dụng kết
thúc.

Post-conditions Nếu ca sử dụng thành công, thông tin tài khoản sẽ được cập
nhật. Nếu không, trạng thái của hệ thống sẽ giữ nguyên.

Special Requirements Không có

34
Use Case Xóa phòng

Actor Administrator

Brief Description Ca sử dụng này cho phép Administrator xoá một phòng
khỏi hệ thống.

Pre-conditions Hệ thống ở trạng thái cần đăng nhập và có màn hình đăng
nhập hiển thị.

Basic Flows Ca sử dụng bắt đầu khi Administrator muốn xoá một phòng
trên hệ thống.

1. Hệ thống sẽ hiển thị một danh sách các phòng cùng

thông tin để Administrator lựa chọn.

2. Administrator chọn phòng muốn xoá.

3. Hệ thống yêu cầu Administrator xác nhận việc xoá

phòng.

4. Administrator xác nhận.

5. Hệ thống tiến hành xóa phòng.

Nếu Administrator quyết định không xoá phòng, quá trình

Alternative Flows xoá sẽ bị huỷ và ca sử dụng quay lại từ đầu.

Post-conditions Nếu ca sử dụng thành công, phòng sẽ bị xoá khỏi hệ thống.

Nếu không, trạng thái của hệ thống sẽ giữ nguyên.

35
Special Requirements Không có

Use Case Sửa phòng

Actor User

Brief Description Ca sử dụng này mô tả cách User chỉnh sửa phòng họ đã

đăng trước đó.

Pre-conditions User đã đăng nhập vào hệ thống và phòng mà họ đã đăng

đang được hiển thị.

Basic Flows Ca sử dụng bắt đầu khi User muốn chỉnh sửa phòng mà họ
đã đăng.

1. Hệ thống sẽ hiển thị các trường thông tin về phòng để

User chỉnh sửa.

2. Nếu User chọn “Gỡ phòng", luồng phụ "Gỡ phòng" sẽ

được chạy. Ngược lại luồng phụ "Cập nhật phòng" sẽ được
chạy.

- Gỡ phòng

1. Hệ thống yêu cầu User xác nhận việc gỡ phòng.

2. User xác nhận.

3. Hệ thống xoá phòng khỏi hệ thống.

36
 - Cập nhật phòng

1. User thực hiện các thay đổi thông tin của phòng.

2. User chọn "Cập nhật"

3. Hệ thống sẽ cập nhật thông tin phòng và đưa phòng trở

về trạng thái đợi duyệt.

- Thay đổi bị hủy

Alternative Flows
Nếu User chọn "Hủy", hệ thống sẽ không cập nhật hoặc
xoá, ca sử dụng kết thúc.

- Thông tin phòng thiếu hoặc không hợp lệ

Trong luồng phụ "Cập nhật phòng", nếu User không nhập
đủ những trường bắt buộc hoặc giá trị nhập vào không hợp
lệ, hệ thống sẽ hiển thị thông báo lỗi. Ca sử dụng tiếp tục.

- Việc gỡ phòng bị hủy

Trong luồng phụ "Gỡ phòng", User quyết định hủy việc gỡ
phòng, hệ thống sẽ không xoá phòng và ca sử dụng tiếp tục.

Post-conditions Nếu ca sử dụng thành công, phòng sẽ được cập nhật thông
tin hoặc gỡ khỏi hệ thống. Nếu không, phòng sẽ không bị
thay đổi

Special Requirements Không có

Use Case Báo cáo phòng

37
Actor User

Brief Description Ca sử dụng này mô tả cách User báo cáo một phòng được
đăng trên hệ thống.

Pre-conditions User đang xem một phòng không do họ đăng và bấm vào
nút “Report".

Basic Flows Ca sử dụng bắt đầu khi User bấm vào nút "Báo cáo" khi
đang xem thông tin về phòng.

1. Hệ thống hiển thị một form và yêu cầu User giải thích lý
do cho việc báo cáo phòng ( thông tin trùng lặp, sai lệch,
…).

2. Khi User cung cấp những thông tin được yêu cầu, hệ
thống sẽ sinh 1 ngẫu nhiên 1 ID duy nhất để gán cho báo
cáo và lưu báo cáo đã tạo vào trong report database

Nếu bất kì trường thông tin bắt buộc nào không được nhập,
Alternative Flows hệ thống sẽ hiển thị một thông báo lỗi. User có thể bổ sung
thông tin trong form báo cáo hoặc dừng việc báo cáo
phòng, khi đó ca sử dụng kết thúc.

Post-conditions Nếu ca sử dụng thành công, một báo cáo được tạo ra chứa
thông tin được cung cấp bởi User, kèm theo một ID duy
nhất và ID của phòng bị báo cáo. Nếu không, hệ thống sẽ
giữ nguyên trạng thái

Special Requirements Không có

38
Use Case Xóa người dùng

Actor Administrator

Brief Description Ca sử dụng này mô tả cách Administrator xóa một User

khỏi hệ thống.

Pre-conditions Administrator đã đăng nhập vào hệ thống.

Basic Flows - Ca sử dụng bắt đầu khi Administrator muốn xóa

một User trên hệ thống:
1. Hệ thống sẽ hiển thị một danh sách các User cùng
thông tin để Administrator lựa chọn.
2. Administrator chọn User muốn xóa.
3. Hệ thống yêu cầu Administrator xác nhận việc xóa
User.
4. Administrator xác nhận.
5. Hệ thống tiến hành xóa User

- Nếu Administrator quyết định không xóa phòng, quá

Alternative Flows trình xóa sẽ bị hủy và ca sử dụng quay lại từ đầu.

Post-conditions Nếu ca sử dụng thành công, User sẽ bị xóa khỏi hệ thống.

Nếu không, trạng thái của hệ thống sẽ giữ nguyên.

Special Requirements Không có

39
Use Case Xử lý báo cáo từ người dùng

Actor Administrator

Brief Description Ca sử dụng này mô tả cách Administrator xem danh sách

các phòng bị báo cáo và quyết định xóa phòng đó hoặc xóa
báo cáo.

Pre-conditions Administrator đã đăng nhập vào hệ thống

Basic Flows - Ca sử dụng bắt đầu khi Administrator yêu cầu

xem danh sách các báo cáo tử User:
1. Hệ thống hiển thị danh sách các báo cáo cùng với
thông tin về phòng, người dùng và báo cáo như đã
được mô tả trong ca sử dụng “báo cáo phòng”. Hệ
thống sẽ hiển thị hai lựa chọn: “Xóa phòng” hoặc
“Xóa báo cáo”.
2. Nếu Administrator chọn xóa phòng thì luồng phụ
“Xóa phòng” sẽ được thực thi. Ngược lại luồng phụ
“Xóa báo cáo” sẽ được thực thi.

- Xóa phòng:
1. Hệ thống yêu cầu Administrator xác nhận quyết định
2. Admin xác nhận việc xóa phòng.
3. Hệ thống xóa phòng.

- Xóa báo cáo:

1. Hệ thống yêu cầu Administrator xác nhận quyết định
2. Admin xác nhận việc xóa báo cáo.
3. Hệ thống xóa báo cáo.

40
 - Việc xử lý báo cáo bị hủy:
Alternative Flows Nếu trong hai luồng phụ, Administrator chọn “Hủy”,
quá trình xóa bị hủy và ca sử dụng quay lại từ đầu

Post-conditions Nếu ca sử dụng thành công, phòng hoặc báo cáo sẽ được
xóa khỏi hệ thống. Nếu không hệ thống sẽ giữ nguyên trạng
thái.

Special Requirements Không có

3.2.4. Đặc tả bổ sung

Chức năng

Những người dùng trong hệ thống phải có khả năng thực hiện công việc của mình
một cách song song.

Tính khả dụng

Hệ thống phải dễ dàng để sử dụng, người dùng mới có thể học cách sử dụng trong
khoảng 1 giờ. Giao diện người dùng thân thiện, gần gũi và trực quan.

Tính tin cậy

Hệ thống cần phải sẵn sàng 24/7. Có ít hơn 5% downtime.

Tính hiệu năng

Hệ thống hỗ trợ lên tới 2000 người dùng cùng lúc truy cập vào database cũng như
100 người dùng cùng lúc truy cập vào server vào bất cứ lúc nào. Hệ thống cung cấp truy
cập tới database với độ trễ thấp hơn 5s. Hệ thống phải hoàn thành được 90% các chức
năng trong khoảng 30s.

Tính hỗ trợ

41
 Không có.

4. PHÂN TÍCH
4.1. Phân tích kiến trúc

Hệ thống gồm 3 lớp :

- Lớp Application : Lớp chứa các phần tử thiết kế tương ứng với từng ca sử dụng,
chính là những thành phần tương tác với người dùng, xử lý Input/Output từ người dùng.

- Lớp Business Services : Lớp chứa các thành phần nghiệp vụ chính có thể truy cập
được từ lớp Application.

- Lớp Middleware : Lớp cung cấp các dịch vụ để trao đổi dữ liệu và giao tiếp mạng.

42
4.2. Phân tích các ca sử dụng
4.2.1. Đăng nhập

43
4.2.2. Tạo tài khoản

44
4.2.3. Cập nhật thông tin cá nhân

45
4.2.4. Duyệt phòng

46
4.2.5. Xóa phòng

47
4.2.6. Sửa phòng

48
4.2.7. Đăng phòng

49
4.2.8. Báo cáo phòng

50
4.2.9. Tìm phòng

51
4.2.10. Xem phòng

52
4.2.11. Đặt phòng

53
4.2.12. Xóa User

54
4.2.13. Xử lý báo cáo từ người dùng

55
5. THIẾT KẾ

5.1. Kiến trúc vật lý

- Presentation tier : Gồm nhiều Client ( PC, Laptop, Smartphone, … ) là các thiết bị để
hiển thị, xử lý nhập xuất từ người dùng, gửi yêu cầu tới Server để thực hiện.
- Application tier : Web Server thực hiện các dịch vụ được client yêu cầu, gửi các yêu cầu
truy xuất dữ liệu tới Database Server.
- Data tier : Database Server thực hiện lưu trữ, quản lý dữ liệu, xử lý truy xuất dữ liệu

5.2. Xác định các phần tử thiết kế

5.2.1. Các gói thiết kế

- Application Package : Chứa các lớp biên và các lớp điều khiển ở phía Client.
- Business Services Package : Chứa các database subsystem và các giao diện cũng như
lớp thực thể.
- Middleware Package : Bao gồm JPA cung cấp truy cập tới database và Java Spring
framework, cung cấp các dịch vụ mạng,..

5.2.2. Các lớp thiết kế

56
Lớp phân tích Phần tử thiết kế

Account Account, Database subsystem

Room Room, Database subsystem

Report Report, Database subsystem

CreateAccountController UserController

UpdateProfileController

DeleteUserController AdminController

ApproveRoomController

ProcessReportController

EditRoomController RoomController

ReportRoomController

PublishRoomController

DeleteRoomController

ViewRoomController

CreateAccountForm Ánh xạ trực tiếp sang các lớp thiết kế

UpdateProfileForm

DeleteUserForm

ApproveRoomForm

ProcessReportForm

EditRoomForm

ReportRoomForm

PublishRoomForm

DeleteRoomForm

ViewRoomForm

57
5.3. Thiết kế các giao diện
5.3.1. Trang chủ

5.3.2. Đăng nhập

58
5.3.3. Trang cá nhân

5.3.4. Chỉnh sửa trang cá nhân

59
5.3.5. Đăng phòng

60
61
5.3.6. Danh sách phòng

5.3.7. Chi tiết phòng

62
5.3.8. Thanh toán

5.4. Thiết kế các lớp

5.4.1. Đăng nhập

63
5.4.2. Tạo tài khoản

5.4.3. Cập nhật thông tin cá nhân

64
5.4.4. Duyệt phòng

65
5.4.5. Xóa phòng

66
5.4.6. Sửa phòng

5.4.7. Đăng phòng

67
5.4.8. Báo cáo phòng

5.4.9. Tìm phòng

68
5.4.10. Xem phòng

5.4.11. Đặt phòng

69
5.4.12. Xóa User

5.4.13. Xử lý báo cáo từ người dùng

70
5.5. Thiết kế Database

71