Đồ án nhập môn công nghệ phần mềm đề tài QUẢN LÝ BÁN BÁO

IE213.M22 – Kỹ thuật phát triển hệ thống Web 13 | P a g e Author & History: Reference Material: Đăng ký Use Case Thumbnail: UC01 – Đăng ký Use Case Description: Use-case cho phép

Trang 1

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

KHOA HỌC MÁY TÍNH

BÁO CÁO ĐỒ ÁN NHẬP MÔN CÔNG NGHỆ PHẦN MỀN

Đề tài: QUẢN LÝ BÁN BÁO

Trang 2

IE213.M22 – Kỹ thuật phát triển hệ thống Web

2 | P a g e

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

……., ngày…… tháng……năm 2022

Người nhận xét

(Ký tên và ghi rõ họ tên)

Trang 3

3 | P a g e

BẢNG PHÂN CÔNG, ĐÁNH GIÁ THÀNH VIÊN:

Bảng 1: Bảng phân công, đánh giá thành viên

Trang 4

Khái niệm thuật ngữ

- User Story là một tài liệu sơ giản về yêu cầu sản phẩm với góc nhìn người dùng Thông thường, User Story do khách hàng, hoặc đại điện của khách hàng viết, tuy nhiên nếu có sự cộng tác của Nhóm Phát triển thì nhóm và khách hàng sẽ có sự chia sẻ hiểu biết về sản phẩm tốt hơn

- Các quy trình theo hướng kế hoạch (Plan-driven processes) là quá trình trong đó tất cả các hoạt động của quá trình được lên kế hoạch trước và tiến độ được đo lường theo kế hoạch này

Trang 5

5 | P a g e

- Báo cáo

1.3.2 Công cụ sử dụng quản lý dự án

- Công cụ trao đổi thông tin

o Ứng dụng Microsoft Teams: nơi thông báo các việc quan trọng, meeting trao đổi giữa các thành viên

o Ứng dụng Messenger: nơi trao đổi các thông tin, chia sẻ các giữa các thành viên trong nhóm

Trước khi bắt đầu mỗi sprint sẽ có một meeting thảo luận và sau khi hoàn thành Sprint,

sẽ có một meeting để nhóm trưởng đề xuất, góp ý các sản phẩm các thành viên đã làm

- Công cụ lưu trữ tài liệu: Google Drive

- Công cụ quản lý Product Backlog: Trello

Trong mỗi sprint (1-2 tuần), công việc sẽ được quản lý ở Trello:

- Danh sách nhiệm vụ: nơi giao các nhiệm vụ cho từng nhóm phát triển nhỏ

- Bảng công việc: nơi các công việc của từng nhóm nhỏ được chỉ định cụ thể,

có thời gian hoàn thành Khi hoàn thành sẽ được đánh dấu là hoàn thành

- Ghi chú: ghi lại các ghi chú trong khi phát triển hệ thống

- Công cụ quản lý phiên bản: Git với Github, các công việc, sản phẩm của các thành viên sẽ được đưa lên git quản lý:

o Branch: Quy định mỗi branch sẽ được đặt tên theo task được giao của từng nhóm nhỏ thành viên

o Sau khi công việc nào commit và push thành công và tạo pull-request sẽ được đánh dấu hoàn thành

o Sau khi công việc hoàn thành sẽ được merge vào branch main

Trang 6

Tác nhân (actor)

Là người dùng của hệ thống, tác nhân thực hiện các use case Một tác nhân có thể thực hiện nhiều use case và ngược lại một use case cũng có thể được thực hiện bởi nhiều tác nhân

Quan hệ include

Mô tả việc một Use Case lớn được chia ra thành các Use Case nhỏ để dễ cài đặt (module hóa) hoặc thể hiện sự dùng lại

Quan hệ extend

Quan hệ Extend được sử dụng khi có một Use Case được tạo ra để bổ sung chức năng cho một Use Case có sẵn và được sử dụng trong một điều kiện nhất định nào đó

Use case

Tên các use case thể hiện một chức năng xác định của hệ thống

Trang 7

7 | P a g e

Quan hệ inherit

Nghĩa là một use case thực hiện hành vi được mô tả bởi một use case trừu tượng cấp cao hơn Trong khi một use case trừu tượng chứa mô tả tổng quát về cách một tác nhân

sẽ sử dụng hệ thống, thì use case cụ thể tương ứng được kế thừa từ use case tổng quát sẽ mô tả các bước thực tế trong việc xác định người dùng

Boundary

Ranh giới hệ thống để ngăn cách tác nhân khỏi use case Các tác nhân đều ở ngoài ranh giới còn use case thì ở bên trong

Notes

Ghi chú thêm thông tin về ý nghĩa của use case, có thể giải thích các mối quan hệgiữa use case Cung cấp thông tin bổ sung của tác nhân và làm nổi bật một số use case nhất định

Trang 8

8 | P a g e

Mô tả sơ đồ Use-case tổng quát:

- Người dùng có thể đăng nhập vào trang web để tương tác với các tính năng, nhưng trước tiên họ phải có tài khoản Nếu không có, người dùng bắt buộc phải đăng ký tài khoản trước khi đăng nhập Người dùng có thể xem, tìm kiếm, so sánh các sản phẩm cùng loại để đưa ra lựa chọn tốt hơn Nếu người dùng muốn đặt sản phẩm, thanh toán hay hủy đơn hàng, họ phải đăng nhập vào trang web trước Ngoài ra, người dùng có thể xem, tìm kiếm các bài viết về sản phẩm để hiểu rõ về sản phẩm sắp mua

- Admin kế thừa tất cả các chức năng của User Thêm vào đó, Admin nắm quyền quản lý bài viết, quản lý đơn hàng, quản lý người dùng

Trang 9

9 | P a g e

1.4.2 Danh sách các actor và mô tả

1 A01 User Tác nhân User là những người có quyền xem, tìm

kiếm bài viết, sản phẩm, so sánh các sản phẩm Ngoài ra, tác nhân có quyền đặt sản phẩm, thanh toán hoặc hủy đơn hàng nhưng chỉ được sử dụng những tính năng đó khi đã đăng nhập

2 A02 Admin Tác nhân Admin là những người quản lý trang

web nắm quyền quản lý bài viết, quản lý sản phẩm, đơn hàng, người dùng

1.4.3 Danh sách các Use-case

1 UC01 Đăng ký Cho phép người dùng

đăng ký tài khoản

- Đăng ký

2 UC02 Đăng nhập Cho phép người dùng có

thể đăng nhập vào hệ thống

- Đăng nhập

3 UC03 Đăng xuất Cho phép người dùng có

thể đăng xuất khỏi hệ thống

- Đăng xuất

4 UC04 Quản lý

người dùng

Cho phép Admin có quyền quản lý thông tin người dùng

- Thêm thông tin người dùng

- Xóa thông tin người dùng

Trang 10

- Thêm bài viết

- Xóa bài viết

- Sửa bài viết

7 UC07 Đặt sản

phẩm

Cho phép người dùng có quyền đặt sản

- Đặt sản phẩm

8 UC08 Thanh toán

sản phẩm

Cho phép người dùng thanh toán sản phẩm trực tuyến

- Thanh toán sản phẩm

9 UC09 Hủy đơn

hàng

Cho phép người dùng hủy đơn hàng khi không có nhu cầu mua hay do những vấn đề bất cập khác với điều kiện chưa nhận hàng

- Hủy đơn hàng

1.4.4 Đặc tả các chức năng

Use Case Thumbnail:

Trang 11

Use Case Description:

<Đây là một mô tả ngắn gọn cho Use-case Mô tả này nằm trong một câu đến một đoạn ngắn mô tả mục đích hay cách sử dụng của nó.>

Preconditions:

<Điều kiện tiên quyết là những điều kiện cần được thỏa mãn trước khi thực hiện được

mô tả của việc bắt đầu use-case>

Postconditions:

<Hậu điều kiện là những điều kiện phải được đáp ứng khi use-case kết thúc>

Actor:

Use Case Relationships:

Basic Flow (Text):

1.<mô tả bước thực hiện>

2.<mô tả bước thực hiện> (A1, E1, E2)

3.<mô tả bước thực hiện> (A2, E2)

Trang 12

12 | P a g e

<<include>> <Thumbnail của các use-case được bao gồm>

<<extend>> <Thumbnail của các trường hợp use-case được mở rộng>

Priority:

<Tầm quan trọng của chức năng được mô tả bởi trường hợp sử dụng này: high/medium/low Điều này có thể dựa trên phân tích và hiểu biết về rủi ro và tầm quan trọng của việc sử dụng các trường hợp.>

Status:

Trang 13

13 | P a g e

<Trạng thái đầy đủ của tài liệu của trường hợp sử dụng này: initial/major/final Điều này

sẽ cho biết mức độ hoàn chỉnh của use-case>

Author & History:

<Tác giả gốc và các bổ ngữ của trường hợp sử dụng này.>

Reference Material:

<Các tài liệu tham khảo có liên quan, cũng như các nguồn từ use case đã được bắt đầu Bất kỳ tài liệu nào không là một thành phần của “flow” trong một use-case (chẳng hạn như công thức toán học, tài liệu pháp lý và tài liệu chính sách).>

Đăng ký

Use Case Thumbnail: UC01 – Đăng ký

Use Case Description: Use-case cho phép người dùng đăng ký tài khoản vào hệ thống Preconditions: không có

Postconditions: Người dùng đăng ký thành công

Actor: User, Admin

Use Case Relationships: Không

1 Người dùng yêu cầu đăng ký tài khoản, hệ thống hiển thị màn hình đăng ký và yêu cầu điền các thông tin người dùng

2 Người dùng điền các thông tin theo yêu cầu (A1)

3 Người dùng bấm đăng ký, hệ thống kiểm tra thông tin đăng ký (A2)

4 Hiển thị thông báo đăng ký thành công

5 Kết thúc Use-case

Trang 14

14 | P a g e

Alternative Flow:122

A1 – 1 Hệ thống hiển thị lỗi ngay tại dòng đăng ký

A1 – 2 Người dùng không sửa mà tiếp tục nhấn đăng ký

A1 – 3 Hệ thống thông báo lỗi đăng ký

A1 – 3 Use Case kết thúc không thành công

A2 – 1 Hệ thống thông báo tài khoản này hiện đã tồn tại

A2 – 2 Use Case kết thúc không thành công

Exceptions: Không

Constraints: Không

Metrics (Complexity): Complex Priority: High Status: Major

Reference Material: Không

Đăng nhập

Use Case Thumbnail: UC02 – Đăng nhập

Use Case Description: Use-case cho phép người dùng đăng nhập vào hệ thống để thực

hiện những chức năng của mình

Preconditions: Người dùng phải có tài khoản hệ thống

Trang 15

15 | P a g e

Postconditions: Người dùng đăng nhập thành công

Actor: Admin, User

Use Case Relationships: Đăng ký

1 Người dùng yêu cầu đăng nhập, hệ thống hiển thị màn hình đăng nhập và yêu cầu điền tên đăng nhập, mật khẩu

2 Người dùng nhập tên đăng nhập và mật khẩu Hệ thống hiển thị kiểm tra thông tin đăng nhập (A1, A2, A3)

3 Hệ thống thông báo đăng nhập thành công và cho phép người dùng đăng nhập vào hệ thống

4 Kết thúc Use-Case

<<extend>> UC01 – Đăng ký

Alternative Flow:

A1 – 1 Hệ thống hiển thị lại màn hình đăng nhập để người dùng nhập lại thông tin kèm theo thông báo tên đăng nhập và mật khẩu bị sai

A1 – 2 Quay lại bước 2 trong luồng sự kiện chính

A2 – 1 Hệ thống hiển thị màn hình để người dùng chọn chức năng quên mật khẩu trên màn hình đăng nhập

A2 – 2 Người dùng nhập email và chọn nút chức năng Lấy lại mật khẩu

A2 – 3 Hệ thống kiểm tra email hợp lệ và gửi liên kết để reset mật khẩu cho người dùng qua email

A2 – 4 Hệ thống hiển thị màn hình thông báo thành công

Trang 16

Metrics (Complexity): Complex Priority: High Status: Major

Trang 17

17 | P a g e

Đăng xuất

Use Case Thumbnail: UC03 – Đăng xuất

Use Case Description: Use case cho phép người dùng đăng xuất khỏi hệ thống

Preconditions: Người dùng cập thành công vào hệ thống

Postconditions: Đăng xuất thành công

Actor: Admin, User

Use Case Relationships: UC02-Đăng nhập

1 Người dùng chọn đăng xuất

2 Hệ ngắt phiên làm việc của người dùng

3 Hệ thống hiển thị giao diện trang chủ

<<include>> UC2 – Đăng nhập

Alternative Flow: Không có

Metrics (Complexity): Simple Priority: Medium Status: Major

Trang 18

18 | P a g e

Quản lý người dùng

UC04 – Quản lý người dùng

Use-case cho phép Admin thêm xóa sửa thông tin người dùng

Trang 19

19 | P a g e

❖ Thêm đơn hàng:

1 Khi nhận thông tin có người dùng thêm, Admin chọn thêm người dùng

2 Hệ thống hiển thị màn hình thêm User mới, yêu cầu Admin điền thông tin

3 Admin điền các trường thông tin cho User (A1, A2)

4 Hệ thống lưu các thông tin vừa tạo (A3)

❖ Sửa thông tin người dùng:

5 Admin chọn User cần chỉnh sửa

6 Hệ thống hiển thị màn hình chỉnh sửa User, yêu cầu Admin chỉnh sửa thông tin

7 Admin sửa thông tin rồi nhấn lưu (A1, A2)

8 Hệ thống lưu thông tin vừa chỉnh sửa (A3)

❖ Xóa người dùng:

9 Admin chọn User cần xóa

10 Hệ thống yêu cầu xác nhận việc xóa User

11 Admin lựa chọn xác nhận hoặc hủy yêu cầu (A4)

12 Hệ thống xóa User được chọn (A3)

<<include>>UC02 – Đăng nhập

A1 – 1 Hệ thống hiển thị lại màn hình thêm User để Admin nhập lại thông tin kèm theo thông báo thêm thất bại và lỗi xảy ra

A3 – 1 Hệ thống thông báo lỗi ra màn hình

Trang 20

20 | P a g e

A3 – 2 Use-case kết thúc không thành công

UC05 – Quản lý đơn hàng

Use-case cho phép Admin thêm xóa sửa thông tin đơn hàng

Trang 21

Use Case Relationships: UC02 – Đăng nhập

❖ Thêm đơn hàng:

13 Khi nhận thông tin có người dùng đặt sản phẩm Admin chọn thêm đơn hàng

14 Hệ thống hiển thị màn hình thêm đơn hàng mới, yêu cầu Admin điền thông tin

15 Admin điền các trường thông tin cho đơn hàng (A1, A2)

❖ Sửa thông tin đơn hàng:

17 Admin chọn User cần chỉnh sửa

18 Hệ thống hiển thị màn hình chỉnh sửa đơn hàng, yêu cầu Admin chỉnh sửa thông tin

❖ Xóa đơn hàng:

21 Khi người dùng hủy đơn hàng, Admin chọn xóa đơn hàng trong trang quản lý

22 Hệ thống yêu cầu xác nhận việc xóa đơn hàng

24 Hệ thống xóa đơn hàng được chọn (A3)

Trang 22

22 | P a g e

A1 – 1 Hệ thống hiển thị lại màn hình thêm User để Admin nhập lại thông tin kèm theo thông báo thêm thất bại và lỗi xảy ra

Metrics (Complexity): complex Priority: medium Status: major Reference Material: Không

Trang 23

23 | P a g e

Quản lý bài viết

UC06 – Quản lý bài viết

Use-case cho phép Admin thêm xóa sửa bài viết trên trang web

Use Case Relationships: UC02 – Đăng nhập

Trang 24

24 | P a g e

❖ Thêm bài viết:

25 Admin chọn thêm bài viết

26 Hệ thống hiển thị màn hình thêm bài viết mới, yêu cầu Admin điền thông tin

27 Admin điền các trường thông tin cho bài viết (A1, A2)

❖ Sửa bài viết:

29 Admin chọn bài viết cần chỉnh sửa

30 Hệ thống hiển thị màn hình chỉnh sửa bài viết, yêu cầu Admin chỉnh sửa thông tin

❖ Xóa bài viết:

33 Admin chọn bài viết cần xóa

34 Hệ thống yêu cầu xác nhận việc xóa bài viết

36 Hệ thống xóa bài biết được chọn (A3)

A1 – 1 Hệ thống hiển thị lại màn hình thêm bài viết để Admin nhập lại thông tin kèm theo thông báo thêm thất bại và lỗi xảy ra

Trang 25

Use Case Thumbnail: UC08 – Đặt sản phẩm

Use case cho phép user tiến hành đặt sản phẩm có trả tiền cọc trước là 7%

Preconditions:

User đã đăng nhập vào trang web

Postconditions:

User đặt sản phẩm thành công

Actor: User, Admin

Use Case Relationships:

Trang 26

26 | P a g e

3 User nhập thông tin người dùng (A2)

4 Hệ thống hiển thị thông tin hóa đơn về sản phẩm khoản thanh toán trước (A1)

5 User lựa chọn hình thức thanh toán và tiến hành thanh toán (A1, A3)

<<include>> <Đăng nhập>

A2 – 1 Hệ thống yêu cầu người dùng nhập lại thông tin

A2 – 1 Quay lại bước 2 của luồng sự kiện chính

A3 – 2 Use-case kết thúc không thành công

Trang 27

27 | P a g e

Thanh toán sản phẩm

UC08 – Thanh toán sản phẩm

Use case cho phép người dùng thanh toán sau khi nhận sản phẩm

Preconditions:

User đã đăng nhập tài khoản thành công

User đã tiến hành đặt hàng tại trang web

1 User vào giỏ hàng và chọn thanh toán sản phẩm (A1)

2 Hệ thống hiển thị đơn hàng đã đặt cho user xác nhận lại thông tin

3 User tiến hành xác nhận và chọn thanh toán khoản còn lại (A1)

4 Hệ thống hiển thị thanh toán thành công

Trang 28

28 | P a g e

<<include>> UC02 – Đăng nhập

<<include>> UC07 – Đặt sản phẩm

A1 – 2 Use-case kết thúc không thành công

Exceptions:

Không có

Constraints:

Không có

Metrics (Complexity): complex Priority: high Status: major

Phạm Văn Nghĩa

Công thức toán học trừ

Hủy đơn hàng

UC10 – Hủy đơn hàng

Trang 29

29 | P a g e

Use case cho phép người dùng hủy đơn hàng khi chưa nhận hàng

Preconditions:

User đã đăng nhập tài khoản thành công

User đã đặt sản phẩm mà chưa thanh toán

1.<mô tả bước thực hiện>

2.<mô tả bước thực hiện> (A1, E1, E2)

3.<mô tả bước thực hiện> (A2, E2)

<<include>> <Thumbnail của các use-case được bao gồm>

<<extend>> <Thumbnail của các trường hợp use-case được mở rộng>

Trang 30

30 | P a g e

Exceptions:

Priority:

<Tầm quan trọng của chức năng được mô tả bởi trường hợp sử dụng này: high/medium/low Điều này có thể dựa trên phân tích và hiểu biết về rủi ro và tầm quan trọng của việc sử dụng các trường hợp.>

Status:

<Trạng thái đầy đủ của tài liệu của trường hợp sử dụng này: initial/major/final Điều này

sẽ cho biết mức độ hoàn chỉnh của use-case>

<Tác giả gốc và các bổ ngữ của trường hợp sử dụng này.>

Trang 31

31 | P a g e

<Các tài liệu tham khảo có liên quan, cũng như các nguồn từ use case đã được bắt đầu Bất kỳ tài liệu nào không là một thành phần của “flow” trong một use-case (chẳng hạn như công thức toán học, tài liệu pháp lý và tài liệu chính sách).>

1.4.5 Sơ đồ tuần tự

Bảng chú thích các ký hiệu trong sơ đồ tuần tự:

Objects: Đối tượng Mô tả một đối tượng trong hệ

thống

Lifelines: Đường đời đối tượng Thời gian sống của đối tượng

Actor: Tác nhân Mô tả một tác nhân trong hệ

thống

Focus of control

Hiển thị khoảng thời gian mà một đối tượng thực hiện một hành động

Asynchronous Message: Thông điệp

Thông điệp không cần có một request trước hành động tiếp theo

Trang 32

32 | P a g e

Synchronous Message: Thông điệp đồng bộ

Dùng để giao tiếp giữa các đối tượng và lớp Thông điệp đồng

bộ cần có một yêu cầu (request) trước hành động tiếp theo

Reply or Return Message: Thông điệp trả lời hoặc trả

về

Là thông điệp trả lời lại khi có request hoặc sau khi kiểm tra tính đúng đắn của một điều kiện nào đó

Self message

Là thông điệp trả lời lại khi có request hoặc sau khi kiểm tra tính đúng đắn của một điều kiện nào đó

Weak Sequencing fragment (seq)

Là tất cả các messages phải được xử lý tuần tự trước trước khi request có thể bắt đầu Trong dó mỗi message được ngăn cách nhau bới đừng thẳng nét đứt

Alternative fragment (alt)

Là mô hình cấu trúc if – then – else Trong đó message nằm ở trên đường thẳng nét đứt là điều kiện true, ở dưới là false

Trang 33

33 | P a g e

Option fragment (opt)

Là mô hình cấu trúc switch – case Trong đó mỗi case sẽ được ngăn cách nhau bởi đường thẳng nét đứt

Đăng ký

Trang 34

34 | P a g e

Mô tả sơ đồ tuần tự đăng ký:

o Bước 1: Người dùng điền email trên trang đăng ký

o Bước 2: Trang đăng ký truyền thông tin email đến controller

o Bước 3: Controller gửi thông tin email đến database

o Bước 4: Database trả về kết quả

o Bước 5: Database kiểm tra thấy email này hợp lệ và có thể sử dụng

o Bước 6: Database kiểm tra thấy thông tin email không hợp lệ (đã tồn tại/ sai quy định, )

o Bước 7: Người dùng điền mật khẩu và xác nhận mật khẩu

Trang 35

35 | P a g e

o Bước 8: Truyền thông tin đăng ký đến controller

o Bước 9: Controller kiểm tra mật khẩu hợp lệ

o Bước 10: Controller kiểm tra thấy mật khẩu không hợp lệ hoặc xác nhận mật khẩu không trùng khớp, yêu cầu nhập lại

o Bước 11: Người dùng nhập tên và số điện thoại

o Bước 12: Trang đăng ký gửi yêu cầu tạo người dùn đến controller

o Bước 13: Controller thực hiện thêm người dùng vào database

o Bước 15: Thêm người dùng mới thành công

o Bước 16: Thêm người dùng mới thất bại

Đăng nhập

Trang 36

36 | P a g e

Mô tả sơ đồ tuần tự đăng nhập:

▪ Bước 1: Người dùng nhập thông tin tài khoản vào giao diện đăng nhập, nếu người dùng quên mật khẩu chuyển đến bước 10

▪ Bước 2: Người dùng chọn đăng nhập, thông tin đăng nhập được gửi controller

▪ Bước 3: Controller gửi thông tin đăng nhập đến database để kiểm tra

▪ Bước 4: Database tài khoản kiểm tra thông tin đăng nhập có đúng với tài khoản

có trong database hay không Nếu có tiếp tục bước 5, nếu không đến bước 7

▪ Bước 5: Database thông báo tài khoản hợp lệ và đăng nhập thành công

▪ Bước 6: Controller hiển thị giao diện trang chủ cho người dùng Usecase kết thúc

▪ Bước 7: Database thông báo tài khoản không hợp lệ và đăng nhập không thành công

▪ Bước 8: Controller thông báo đăng nhập thất bại trên giao diện đăng nhập

▪ Bước 9: Thông báo yêu cầu kiểm tra lại thông tin đăng nhập đến người dùng Usecase kết thúc

▪ Bước 10: Khi người dùng ấn chọn quên mật khẩu

▪ Bước 11: Hiển thị giao diện quên mật khẩu

▪ Bước 12: Người dùng nhập email để xác định tài khoản

▪ Bước 13: Người dùng chọn lấy lại mật khẩu

▪ Bước 14: Gửi yêu cầu quên mật khẩu đến controller

▪ Bước 15: Controller yêu cầu lấy mật khẩu từ database

▪ Bước 16: Database kiểm tra thông thông tin email có hợp lệ hay không, nếu hợp

lệ thì chuyển đến bước 17, nếu không hợp lệ chuyển đến bước 20

▪ Bước 17: Database thông báo tài khoản hợp lệ và gửi mật khẩu đến controller

▪ Bước 18: Controller tiến hành gửi mật khẩu đến email tương ứng của người dùng

và gửi thông báo lấy lại mật khẩu thành công

▪ Bước 19: Hiển thị thông báo lấy lại mật khẩu thành công Yêu cầu người dùng lấy mật khẩu mới từ email và quay lại bước 1

▪ Bước 20: Gửi thông báo email sai đến controller

▪ Bước 21: Controller gửi thông báo email sai đến giao diện quên mật khẩu

▪ Bước 22: Thông báo tới email sai tới tới người dùng, yêu cầu kiếm tra lại email Nếu người dùng muốn tiếp tục quay lại bước 12 Nếu không usecase kết thúc không thành công

Trang 37

37 | P a g e

Đăng xuất

Mô tả sơ đồ tuần tự đăng xuất:

o Bước 1: Người dùng dùng chọn đăng xuất

o Bước 2: Gửi yêu cầu đăng xuất đến Đăng xuất Controller

o Bước 3: Đăng xuất Controller xác nhận và gửi lệnh đến Database

o Bước 4: Đăng xuất thành công

o Bước 5: Controller trả về trạng thái đăng xuất thành công

Quản lý người dùng

Trang 38

38 | P a g e

Mô tả sơ đồ tuần tự quản lý người dùng:

o Bước 1: Admin truy cập trang quản lý người dùng

o Bước 2: Trang quản lý gửi yêu cầu danh sách người dùng đến controller

o Bước 3: Controller gửi yêu cầu danh sách đến database

o Bước 4: Database trả về dữ liệu

Trang 39

39 | P a g e

o Bước 5: Controller trả về danh sách người dùng, admin sau đó có 2 lựa chọn, nếu muốn vô hiệu hóa tài khoản thì tiếp tục bước 6, nếu muốn kích hoạt tài khoản thì đến bước 14

o Bước 6: Admin lựa chọn vô hiệu hóa tài khoản

o Bước 7: Trang quản lý gửi yêu cầu vô hiệu hóa tài khoản người dùng đến controller

o Bước 8: Controller tiến hành vô hiệu hóa tài khoản

o Bước 10: Vô hiệu hóa tài khoản thành công

o Bước 11: Vô hiệu hóa tài khoản thất bại

o Bước 12: Admin lựa chọn kích hoạt tài khoản

o Bước 13: Trang quản lý gửi yêu cầu kích hoạt tài khoản người dùng đến controller

o Bước 14: Controller thực hiện cầu kích hoạt

o Bước 16: Database kích hoạt tài khoản thành công

o Bước 17: Database kích hoạt tài khoản thất bại

Trang 40

40 | P a g e

Quản lý đơn hàng

Mô tả sơ đồ tuần tự quản lý đơn hàng

▪ Bước 1: Controller lấy dữ liệu thông tin đơn hàng từ database

▪ Bước 2: Database trả về dữ liệu đơn hàng

▪ Bước 3: Controller hiển thị giao diện quản lý đơn hàng chứa thông tin các đơn hàng của khách

▪ Bước 4: Người dùng chọn chức năng đặt sản phẩm thì chuyển đến bước 5, cập nhật thì đến bước 6 và xóa thì đến bước 7

▪ Bước 5: Chuyển đến usecase thêm đơn hàng

▪ Bước 6: Chuyển đến usecase cập nhật đơn hàng

▪ Bước 7: Chuyển đến usecase xóa đơn hàng

Tiêu đề	Quản Lý Bán Báo
Tác giả	Phạm Văn Nghĩa, Nguyễn Minh Nhật
Trường học	Trường Đại Học Công Nghệ Thông Tin, Đại Học Quốc Gia Thành Phố Hồ Chí Minh
Chuyên ngành	Kỹ thuật phát triển hệ thống Web
Thể loại	Đồ án nhập môn công nghệ phần mềm
Năm xuất bản	2022
Thành phố	TP. Hồ Chí Minh

Định dạng
Số trang	134
Dung lượng	1,95 MB