TRƯỜNG ĐẠI HỌC ĐIỆN LỰC

KHOA CÔNG NGHỆ THÔNG TIN

BÁO CÁO THỰC TẬP TỐT NGHIỆP

ĐỀ TÀI: SPA TRONG PHẦN MỀM QUẢN LÝ DOANH
NGHIỆP ECS

Sinh viên thực hiện : NGUYỄN THANH TÙNG

Giảng viên hướng dẫn : TS. VŨ VĂN ĐỊNH

Ngành : CÔNG NGHỆ THÔNG TIN

Chuyên ngành : CÔNG NGHỆ PHẦN MỀM

Lớp : D13CNPM4

Khóa : 2018-2023

Hà Nội, tháng 10 năm 2022

 PHIẾU CHẤM ĐIỂM

Sinh viên thực hiện:

STT Họ và tên Nội dung thực hiện Điểm Chữ ký

1 Nguyễn Thanh Tùng

18810310359

Giáo viên chấm điểm:

Họ và tên Chữ ký Ghi chú

Giáo viên 1:

Giáo viên 2:

2
 Mục Lục
PHIẾU CHẤM ĐIỂM .............................................................................................2
LỜI MỞ ĐẦU ...........................................................................................................6
CHƯƠNG 1: GIỚI THIỆU ĐỀ TÀI ......................................................................8
1.1. Đặt vấn đề .......................................................................................................8
1.2. Mục tiêu và phạm vi dự án ...........................................................................8
1.3. Định hướng giải pháp ....................................................................................9
1.4. Bố cục bài báo cáo ........................................................................................10
CHƯƠNG 2: KHẢO SÁT VÀ PHÂN TÍCH THIẾT KẾ HỆ THỐNG ...........12
2.1. Khảo sát hệ thống ........................................................................................12
2.1.1. Tổng quan về quản lý doanh nghiệp ....................................................12
2.1.2. Hệ thống hiện tại ....................................................................................12
2.1.3. Nội dung khảo sát và đánh giá hiện trạng...........................................12
2.1.4. Nắm bắt yêu cầu.....................................................................................13
2.2. Tổng quan chức năng ..................................................................................16
2.2.1. Biểu đồ use case tổng quát ....................................................................17
2.2.2. Biểu đồ use case phân rã chức năng “Timesheet Management” ......18
2.2.3. Biểu đồ use case phân rã chức năng “Project Management” ...........19
2.2.4. Biểu đồ use case phân rã chức năng “User Management” ................20
2.2.5. Biểu đồ use case phân rã chức năng “Post Management” ................21
2.2.6. Biểu đồ use case phân rã chức năng “Add Timesheet Management”
............................................................................................................................22
2.2.7. Biểu đồ use case phân rã chức năng “Add Timesheet Approval
Management” ...................................................................................................23
2.2.8. Biểu đồ use case phân rã chức năng “Comment Post” ......................24
2.3. Đặc tả chức năng ..........................................................................................25
2.3.1. Đặc tả yêu cầu chức năng đăng nhập ..................................................25
2.3.2. Đặc tả yêu cầu chức năng Check in .....................................................27

3
 2.3.3. Đặc tả yêu cầu chức năng Check out ...................................................29
2.3.4. Đặc tả yêu cầu chức năng Add Timesheet Management ...................32
2.3.5. Đặc tả yêu cầu chức năng Add Timesheet Approval Management..35
2.3.6. Đặc tả yêu cầu chức năng Project Management ................................37
2.3.7. Đặc tả yêu cầu chức năng User Management .....................................40
2.3.8. Đặc tả yêu cầu chức năng Post Management......................................44
2.4. Yêu cầu phi chức năng ................................................................................47
CHƯƠNG 3: CÔNG NGHỆ SỬ DỤNG .............................................................48
3.1. Single page application ................................................................................48
3.1.1. Định nghĩa ..............................................................................................48
3.1.2. Cơ sở lý thuyết .......................................................................................49
3.1.3. Những bất cập khác ...............................................................................49
3.2. Lập trình front-end......................................................................................51
3.2.1. Ngôn ngữ.................................................................................................51
3.2.2. Framework khác ....................................................................................52
3.3. Lập trình back-end ......................................................................................52
3.3.1. Ngôn ngữ lập trình PHP và framework Laravel ................................52
3.2.2. Cơ sở dữ liệu...........................................................................................53
CHƯƠNG 4: PHÁT TRIỂN VÀ TRIỂN KHAI ỨNG DỤNG ..........................54
4.1. Thiết kế kiến trúc .........................................................................................54
4.1.1. Lựa chọn kiến trúc phần mềm .............................................................54
4.1.2. Thiết kế tổng quan .................................................................................55
4.2. Thiết kế chi tiết .............................................................................................56
4.2.1. Thiết kế giao diện ...................................................................................56
4.2.2. Thiết kế lớp .............................................................................................60
4.2.3. Thiết kế cơ sở dữ liệu.............................................................................63
4.3. Xây dựng ứng dụng .....................................................................................68

4
 4.3.1. Thư viện và công cụ sử dụng ................................................................68
4.3.2. Minh họa các chức năng chính .............................................................69
4.4. Kiểm thử và triển khai ................................................................................72
4.4.1. Kiểm thử .................................................................................................72
4.4.2. Triển khai ...............................................................................................73
KẾT LUẬN .............................................................................................................77
TÀI LIỆU THAM KHẢO .....................................................................................78

5
 Danh Mục Hình Ảnh
Hình 2.1: Mô hình các tác ........................................................................................16

Hình 2.2: Biểu đồ use case tổng quát.......................................................................17

Hình 2.3: Biểu đồ use case phân rã Timesheet Management ..................................18

Hình 2.4: Biểu đồ use case phân rã Project Management .......................................19

Hình 2.5: Biểu đồ use case phân rã User Management ...........................................20

Hình 2.6: Biểu đồ use case phân rã Post Management ............................................21

Hình 2.7: Biểu đồ use case phân rã Add Timesheet Management ..........................22

Hình 2.8: Biểu đồ use case phân rã Add Timesheet Approval Management ..........23

Hình 2.9: Biểu đồ use case phân rã Comment post .................................................24

Hình 2.10: Biểu đồ hoạt động chức năng Đăng Nhập .............................................26

Hình 2.11: Biểu đồ use case chức năng Check in....................................................28

Hình 2.12: Biểu đồ hoạt động chức năng Check out ...............................................31

Hình 2.13: Biểu đồ use case chức năng Bổ sung công ............................................34

Hình 2.14: Biểu đồ hoạt động chức năng Duyệt bổ sung công ...............................36

Hình 2.15: Biểu đồ hoạt động chức năng Quản lý dự án ........................................39

Hình 2.15: Biểu đồ hoạt động chức năng User Management ..................................43

Hình 2.16: Biểu đồ hoạt động chức năng Post Management ..................................46

Hình 3.1: Mô hình MVC..........................................................................................50

Hình 4.1: Mô hình client server ...............................................................................54

Hình 4.2: Biểu đồ phụ thuộc gói ..............................................................................55

Hình 4.3: Layout ECS nội bộ...................................................................................57

6
Hình 4.4: Layout ECS customer ..............................................................................58

Hình 4.5: Nhập Liệu ................................................................................................58

Hình 4.6: Confirm ....................................................................................................59

Hình 4.7: Notification ..............................................................................................59

Hình 4.8: Biểu đồ dữ liệu quan hệ ...........................................................................63

Hình 4.9: Trang đăng nhập ......................................................................................69

Hình 4.10: Trang chủ ...............................................................................................71

Hình 4.11: Màn Additional Timesheet Create .........................................................71

Hình 4.12: Màn Additional Timesheet List .............................................................72

Hình 4.13: Màn Additional Project..........................................................................73

7
 Danh Mục Bảng
Bảng 2.1: Bảng dữ liệu đầu vào của use case “Sign up” .........................................27

Bảng 2.2: Bảng dữ liệu đầu vào của use case “Add timesheet” ..............................34

Bảng 2.3: Bảng dữ liệu đầu vào của use case “Add timesheet Approval” ..............36

Bảng 2.4: Bảng dữ liệu đầu vào của use case “Project Management” ....................39

Bảng 2.5: Bảng dữ liệu đầu vào của use case “User Management” ........................43

Bảng 2.6: Bảng dữ liệu đầu vào của use case “Post Management” ........................46

Bảng 4.1: Bảng mô tả lớp “TimesheetController” ..................................................61

Bảng 4.2: Bảng mô tả lớp “AddTimesheetController”............................................62

Bảng 4.3: Bảng mô tả lớp “ProjectController” ........................................................62

Bảng 4.4: Bảng mô tả lớp “UserController”............................................................64

Bảng 4.5: Bảng mô tả lớp “PostController” ............................................................64

Bảng 4.6: Danh sách thư viện và công cụ sử dụng ..................................................69

Bảng 4.7: Bảng kiểm thử chức năng CRUD dự án .................................................74

8
 LỜI MỞ ĐẦU
Hiện nay, CNTT đang phát triển mạnh mẽ ở nước ta. Máy tính điện tử không
còn là phương tiện quý hiếm mà đang ngày một gần gũi với con người. Công tác
quản lý ngày càng được nhiều cơ quan và các đơn vị quan tâm nhưng quản lý thế
nào và quản lý làm sao cho đạt hiệu quả cao như: nhanh, bảo mật, thân thiện, dễ sử
dụng và làm việc được từ xa.

Đứng trước diễn biến phức tạp của dịch covid-19 chúng ta luôn tuân thủ quy
tắc 5K và sẵn sàng thực hiện chủ chương: “Ai ở đâu ở yên đó” của nhà nước. Với
việc học online chúng ta có phần mềm rất nổi tiếng như: zoom, google meet,... Trong
doanh nghiệp cũng áp dụng làm remote- tức làm việc tại nhà, làm việc từ xa của các
công ty doanh nghiệp ngày càng phổ biến. Chính vì vậy cần có những phần mềm
quản lý thay cho tệp hồ sơ dày cộp, thay cho những ngăn tủ chứa đựng hồ sơ chiếm
nhiều diện tích và có thể ta phải mất nhiều thời gian để tìm kiếm các thông tin cần
thiết hay những dữ liệu quan trọng. Tất cả những điều bất tiện trên có thể được tích
hợp trong phần mềm quản lý một sản phẩm nào đó.

Xây dựng một hệ thống quản lý bán hàng phù hợp với công tác quản lý doanh
nghiệp có ý nghĩa to lớn. Chính vì vậy mà em chọn đề tài “SPA trong Phần mềm
quản lý doanh nghiệp ECS”, trong quá trình làm báo cáo cũng như xây dựng, sẽ còn
rất nhiều nhược điểm, thiếu sót, rất mong được thầy cô chỉ dẫn và bổ sung để bản
báo cáo này được hoàn thiện hơn. Em xin cảm ơn thầy Vũ Văn Định đã chỉ dẫn để
em có thể hoàn thiện bản báo cáo này.

9
 DANH MỤC CÁC TỪ VIẾT TẮT

Application Programming Interface

API
Giao diện lập trình ứng dụng

HyperText Markup Language

HTML
Ngôn ngữ đánh dấu siêu văn bản

Cascading Style Sheets

CSS
Ngôn ngữ định dạng kiểu

Single page application

SPA
Ứng dụng một trang

Multiple pages application

MPA
Ứng dụng nhiều trang

CNTT Công nghệ thông tin

ĐATN Đồ án tốt nghiệp

SV Sinh viên

10
 CHƯƠNG 1: GIỚI THIỆU ĐỀ TÀI
1.1. Đặt vấn đề
Để một doanh nghiệp có thể phát triển toàn diện ngoài việc phát triển chất
lượng sản phẩm, nhân lực thì yếu tố truyền thông luôn là một yếu tố cần thiết và
quan trọng trong việc quảng bá hoặc giới thiệu hình ảnh công ty với các người dùng.
Có rất nhiều cách thức quảng bá khác nhưng những bài post chia sẻ về kiến thức
chuyên môn hay các diễn đàn chia sẻ thông tin, kiến thức luôn là cái gì đó hay ho và
thiết thực hơn.

Hiện nay trên google có rất nhiều diễn đàn, blog chia sẻ về kiến thức, … Để
doanh nghiệp có thể thu hút khách tới thăm diễn đàn, trang web của mình ngoài kiến
thức hay ho, mới lạ, thông tin thú vị thì việc có một trang web có giao diện đẹp, hiệu
ứng mượt mà, … là một trong những yếu tố rất quan trọng góp phần tạo quảng bá
cho doanh nghiệp. Nhiều website, Blog, diễn đàn ra đời nhằm phục vụ độc giả, giúp
họ tìm được những kiến thức thú vị và giải quyết vấn đề gặp phải. Tuy nhiên đối mặt
với với lượng lớn dữ liệu, các website gặp khó khăn với tốc độ tải trang, làm tăng
thời gian chờ của người dùng khi truy cập và thao tác dữ liệu trên website.

Vì vậy, trong báo cáo này, em mong muốn thiết kế và xây dựng được website
quản lý doanh nghiệp với giao diện người dùng theo hướng ứng dụng một trang
(single page application) với các chức năng cơ bản dành cho người dùng có thể xem
bài post, đọc và comment, … và độc giả có thể tìm, bình luận, tham gia vào những
cuộc trò chuyện.
1.2. Mục tiêu và phạm vi dự án
Đề tài xây dựng phần mềm quản lý doanh nghiệp ECS có mục tiêu giúp các
doanh nghiệp có thể quản lý user, quản lý dự án, quản lý bài post, chấm công. Bên

11
phía giao diện người dùng, Website giúp các người dung có thể tìm kiếm, đọc và
comment bài post, tham gia các cuộc trò chuyện.
Em xây dựng hệ thống quản lý doanh nghiệp là một ứng dụng web một trang
(single page application) có các chức năng dành khách vãng lai (người tham quan
website, đọc post, bình luận) và cho các thành viên nội bộ (người dùng phần với các
quyền khác nhau), quản trị viên.
➢ Dành cho quản trị viên:
▪ Quản lý chấm công
▪ Quản lý bài Post
▪ Quản lý người dùng
▪ Quản lý dự án
▪ Quản lý bổ sung công
➢ Dành cho nhân viên nội bô:
▪ Chấm công
▪ Bổ sung công
▪ Quản lý bài Post
➢ Dành cho khách vãng lai:
▪ Đọc bài post
▪ Tìm kiếm bài post
▪ Bình luận
1.3. Định hướng giải pháp
Hệ thống quản lý doanh nghiệp ECS xây dựng là một ứng dụng một trang
(single page application) cho giao diện người dùng. Lý do em chọn giải pháp này vì
khả năng xử lý, và tốc độ nổi bật của nó

Single page application là một ứng dụng web tương tác với người dùng bằng
cách tự động viết lại trang web hiện tại với dữ liệu từ web server thay vì phương

12
pháp mặc định của trình duyệt web là tải toàn bộ trang mới. Do đó, các tài nguyên
của trang web được trình duyệt sẽ được tải một lần duy nhất, các tài nguyên thích
hợp sẽ được tải và thêm vào trang khi cần thiết để đáp lại hành vi của người dùng.
Đối mặt với vấn đề dữ liệu thay đổi liên tục như: thời gian áp dụng khuyến mại, số
lượng sách, các sách mới được thêm vào, single page application thể hiện rõ điểm
mạnh của mình là tốc độ load dữ liệu đảm bảo dữ liệu hiển thị với thời gian thực của
người dùng.
Đóng góp chính hệ thống của em là tạo được website quản lý doanh nghiệp
với quản lý các bài post chia sẻ kiến thức tốt đối với lượng dữ liệu lớn và mà vẫn
có tính ổn định, tốc độ cao tăng tính trải nghiệm người dùng.
1.4. Bố cục bài báo cáo
Phần còn lại của báo cáo gồm 3 chương:
Chương 2, em khảo sát hiện trạng từ ba nguồn chính: người dùng/khách hàng,
các hệ thống đã có, các sản phẩm tương tự. Từ đó em phân tích, đánh giá ưu nhược
điểm của sản phẩm của mình và tiến hành phân tích sâu về các yêu cầu chức năng
đối với từng actor tham gia nghiệp vụ bằng các use case. Trong chương này, em
cũng sẽ nêu các yêu cầu phi chức năng như: hiệu năng, độ tin cậy, tính dễ dùng, tính
dễ bảo trì, hoặc các yêu cầu về mặt kỹ thuật như về CSDL, công nghệ sử dụng, …
Chương 3, sau khi phân tích các yêu cầu chức năng và phi chức năng cho hệ
thống, em tiến hành lựa chọn công nghệ phù hợp và tiến hành giới thiệu, mô tả chúng
trong chương 3. Em tiến hành xây dựng website theo mô hình client server, theo đó
client side và server side giao tiếp thông qua giao thức Http/Https. Phía client em sử
dụng framework javascrip, Taiwild, ngoài ra là Livewire để xây dụng single page
application (SPA). Phía server, em sử dụng laravel, đó là framework rất mạnh của
php hỗ trợ bảo mật và truy xuất dữ liệu từ database. Và còn một số công nghệ khác
như ứng dụng web service, các nền tảng ứng dụng và ứng dụng để giải quyết vấn đề,
em sẽ mô tả chi tiết trong chương 3.
13
 Chương 4, đây là chương em sẽ tiến hành thiết kế hệ thống dựa trên những
phân tích nghiệp vụ ở chương 2 và phù hợp triển khai với những công nghệ lựa chọn
ở chương 3. Trong chương 4, em sẽ thiết kế kiến trúc phần mềm, thiết kế chi tiết
giao diện, lớp, cơ sở dữ liệu sau đó xây dựng ứng dụng, thể hiện kết quả đạt được và
minh hoạ các chức năng chính. Em sẽ kiểm thử các trường hợp cho 2 chức năng
quan trọng nhất.
Kết luận, Em sẽ kết luận về sản phẩm đã thực hiện, và đưa ra hướng phát triển
dựa trên tiêu chí trải nghiệm người dùng.
Sau đây, em sẽ trình bày chương 2: Khảo sát và Phân tích thiết kế HT bài
toán trong xây dựng hệ thống TT quản lý doanh nghiệp ECS.

14
 CHƯƠNG 2: KHẢO SÁT VÀ PHÂN TÍCH THIẾT KẾ HỆ
THỐNG
2.1. Khảo sát hệ thống
2.1.1. Tổng quan về quản lý doanh nghiệp
Đề tài vừa có giá trị trong thực tế vừa có giá trị trong việc học tập vì sau khi
thực hiện đề tài, em vừa nắm được vững hơn kiến thức môn học vừa bồi dưỡng cho
bản thân thêm kiến thức về nghiệp vụ quản lý trong các doanh nghiệp, công ty góp
phần nâng cao trình độ chuyên môn của mỗi cá nhân.
Trong khuôn khổ đề tài môn học này, mục tiêu chính yếu là để rèn luyện chúng
em thực hiện xây dựng hệ thống với các nhiệm vụ cơ bản: quản lý hệ thống của một
doanh nghiệp. Bên cạnh đó là sự hỗ trợ cho việc quản lý công số, dự án, chấm công,
nhân sự. Đồng thời luyện tập kiến thức của các môn: phân tích thiết kế hệ thống,
phân tích thiết kế hướng đối tượng, lập trình Laravel, MySQL, Taiwild…
2.1.2. Hệ thống hiện tại
Chúng ta xây dựng hệ thống mới nhằm mục đích thay thế hệ thống cũ đã có
phần không phù hợp với nhu cầu của người sử dụng.
Việc khảo sát nhằm để:
− Tiếp cận với nghiệp vụ chuyên môn, môi trường hoạt động của hệ thống.

− Tìm hiểu chức năng, nhiệm vụ và cùng cách hoạt động của hệ thống.

− Chỉ ra những chỗ hợp lý của hệ thống, cần được kế thừa và các chỗ bất hợp
lý của hệ thống, cần nghiên cứu khắc phục.

2.1.3. Nội dung khảo sát và đánh giá hiện trạng
− Tìm hiểu cơ cấu tổ chức và nguyên tắc hoạt động của hệ thống quản lý

− Nghiên cứu công việc, nhiệm vụ, trách nhiệm của từng đối tượng trong hệ
thống, quyền hạn của từng đối tượng trong hệ thống.

15
 − Thu thập và nghiên cứu các phương thức hoạt động của công ty.

− Thu thập các đòi hỏi về thông tin, các ý kiến đánh giá, phàn nàn về hiện trạng,
các dự đoán, kế hoạch và nguyện vọng trong tương lai.

2.1.4. Nắm bắt yêu cầu

❖ Mô tả yêu cầu của bài toán
Yêu cầu xây dựng một hệ thống quản lý việc của doanh nghiệp.
- Hằng ngày nhân viên có thể chấm công tại nhà, và sau 17h30 nhân viên có thể
chấm công checkout. Nếu vô tình quên chấm công, Hãy thu thập bằng chứng và bổ
sung công rồi chọn người để duyệt.
- Nhân viên cũng có thể viết blog, chia sẻ kiến thức, viết bài post để mọi người
có thể cùng thảo luận.
- Admin sẽ nắm được tình hình của doanh nghiệp, số lượng và tình trạng của
nhân viên có đang rảnh hay đang trong dự án nào không. Đồng thời, nếu được chọn
là người để duyệt danh sách bổ sung thì admin mới có quyền duyệt
- Admin sẽ tạo dự án để quản lý danh sách các dự án, đồng thời cũng nắm bắt
được tình hình nhân sự hiện đang rảnh hay đang trong dự án.
❖ Mục tiêu của hệ thống
Nhằm giúp cho doanh nghiệp nâng cao chất lượng quản lý đối với nhân viên
đồng thời cũng là đảm bảo quyền lợi của nhân viên một cách hiệu quả nhầt và công
bằng nhất.
❖ Đánh giá hiện trạng
Sau khi khảo sát và tìm hiểu về hệ thống quản lý hiện tại thấy được những
mặt ưu và nhược điểm như sau:
• Ưu điểm:
- Chi phí thấp.
- Không đòi hỏi nhiều về trình độ tin học
• Nhược điểm:
16
 - Thiếu phương tiện quản lý.
- Với chức năng hiện tai thì không làm việc được tại nhà.
- Khối lượng giấy tờ sử dụng và lưu trữ nhiều.
- Thông tin quản lý không đa dạng.
- Tốn nhiều thời gian cho công tác quản lý, tổng hợp báo cáo thống kê
- Khó khăn trong quản lý thuốc, lưu trữ, tìm kiếm.
- Khó khăn trong những quy trình báo cáo, thống kê…
- Tốn nhiều nhân lực, sức người
• Giải pháp:
Với hệ thống quản lý như trên thì doanh nghiệp sẽ gặp nhiều khó khăn trong
công việc quản lý cũng như diễn biến phức tập của dich covid-19 khi phải theo yêu
cầu của nhà nước là việc dãn cách xã hội. Từ đó đặt ra một bài toán cho doanh nghiệp
làm sao để vừa quản lý nhân sự cũng như quyền lợi của nhân đồng thời thực hiện
đúng yêu cầu giãn cách xã hội lại vừa có thể đảm bảo hiệu quả khi làm việc từ xa.
Việc xây dựng một hệ thống để quản lý doanh nghiệp, chấm công là vô cùng cần
thiết và cấp bách.
❖ Xác định các Actor
Thành viên nội bộ
Là người trực tiếp sử dụng hệ thống. Nhân viên có thể xem được danh sách
hàng ngày mình chấm công, và có thể tạo bổ sung công và chọn người duyệt.
Sau khi tạo bổ sung công, nhân viên có thể thêm sửa xóa đơn bổ sung vừa tạo,
sau đó đợi chờ duyệt từ phía người duyệt. Hãy để lại lý do thuyết phục để người
duyệt có thể xem xét duyệt cho một cách nhanh chóng nhất
Admin
Là người có quyền cao nhất sẽ là đọc, kiểm tra và duyệt hoặc hủy bỏ những
danh sách bổ sung công của người gửi.

17
 Ngoài ra, Admin có thể tạo được tạo dự án mới và để trạng chưa triển khai,
đã xong và đang triển khai. Admin cũng có thể tìm kiếm danh sách dự cũ và mới
nhất dựa và trạng thái, đơn vị hoặc tên dự án.
Khách
Là tất cả mọi người đều có thể truy cập để đọc, tìm kiếm các thông thông tin
được chia sẻ bởi các Thành viên nội bộ.
Ngoài ra khách đến thăm còn các thể comment, thảo luận 1 về đề với các
thành viên nội.

Hình 2.1: Mô hình các tác

18
2.2. Tổng quan chức năng

2.2.1. Biểu đồ use case tổng quát

Hình 2.2: Biểu đồ use case tổng quát

19
2.2.2. Biểu đồ use case phân rã chức năng “Timesheet Management”

Hình 2.3: Biểu đồ use case phân rã Timesheet Management

Hình 2.3 là biểu đồ use case phân rã Timesheet Management. Thành viên nội
bộ hằng ngày sẽ khi làm việc sẽ ấn Check In để cập nhật giờ vào, và khi kết thúc thì
bấm Check out để cập nhật giờ ra. Tìm kiếm thông tin các tháng trước, năm trước
với trường: start date và end date.

20
2.2.3. Biểu đồ use case phân rã chức năng “Project Management”

Hình 2.4: Biểu đồ use case phân rã Project Management

Hình 2.4 là Biểu đồ use case phân rã Project Management. Khi có dự án mới,
Admin sẽ quản lý dự án bằng cách: thêm, sửa, xóa dự án, tìm kiếm dự án. Tìm kiếm
theo nhiều trường: project name, project type, project status, project department.

Ngoài ra Admin có cố thể xem được biểu đồ thống kê của các nhân viên để
biết được nhân viên nào đang rảnh, nhân viên nào đang trong dự án.

21
2.2.4. Biểu đồ use case phân rã chức năng “User Management”

Hình 2.5: Biểu đồ use case phân rã User Management

Hình 2.5 là Biểu đồ use case phân rã User Management. Khi có nhân viên
mới, Admin sẽ quản lý nhân viên bằng cách: thêm, sửa, xóa dự án, tìm kiếm nhân
viên. Tìm kiếm theo nhiều trường: name, ID, department, location.

Ngoài ra Admin còn xem được thông tin của những nhân đã rời đi.

22
2.2.5. Biểu đồ use case phân rã chức năng “Post Management”

Hình 2.6: Biểu đồ use case phân rã Post Management

Hình 2.6 là Biểu đồ use case phân rã Post Management. Với nhân viên nội bộ
có thể quản lý bài post của riêng bằng cách: thêm, sửa, xóa bài post và tìm kiếm bài
post theo trường: title, category và status.

Với Admin có thể quản lý tất cả các bài post ở chế độ Public của các nhân
viên từ đó có thể kiểm soát được các bài đăng để chọn lựa những bài post phù hợp.

23
2.2.6. Biểu đồ use case phân rã chức năng “Add Timesheet Management”

Hình 2.7: Biểu đồ use case phân rã Add Timesheet Management

Hình 2.7 là Biểu đồ use case phân rã Add Timesheet Management. Nhân viên
nội bộ khi quên chấm công, nhân viên có thể: thêm đơn bổ sung, sửa, xóa, xem chi
tiết đơn bổ sung. Tìm kiếm đơn bổ sung với các trường: start date, end date.

24
2.2.7. Biểu đồ use case phân rã chức năng “Add Timesheet Approval
Management”

Hình 2.8: Biểu đồ use case phân rã Add Timesheet Approval Management

Hình 2.8 là Biểu đồ use case phân rã Add Timesheet Approval Management.
Admin sẽ có quyền duyệt hoặc từ chối các đơn bổ sung mà nhân viên nội bộ yêu cầu
bổ sung, để thuận tiện Admin có thể Approval All hoặc Reject All. Tìm kiếm các
đơn duyệt qua trường: ID/name, start date, end date.

25
2.2.8. Biểu đồ use case phân rã chức năng “Comment Post”

Hình 2.9: Biểu đồ use case phân rã Comment post

Hình 2.9 là Biểu đồ use case phân rã Comment post. Khách vãng lai có thể
nhìn thấy bài viết qua list bài viết, new post, popular post để xem chi tiết bài viết và
like hoặc comment bài viết. Nhân viên nội bộ cũng thể tương tác qua lại với khách
trong các bài viết để thảo luận các vấn đề liên quan.

26
2.3. Đặc tả chức năng
2.3.1. Đặc tả yêu cầu chức năng đăng nhập
2.3.1.1. Use case chức năng đăng nhập
a. Mô tả use case
Mỗi người trong chúng ta đều cần phải có tài khoản riêng để đăng nhập, khi
đó chúng ta có check in và check out để chấm công cho ngày hôm đó. Hoặc nếu
quên chấm chúng ta có thể bổ sung hoặc đơn giản chỉ là tìm kiếm những danh sách
bổ sung công hoặc tìm kiếm những dự án theo lựa chọn tìm kiếm.

b. Tác nhân

Admin và nhân viên nội bộ.

c. Tiền điều kiện

Không.

d. Luồng sự kiện chính

Khi người dùng nhập tài khoản và mật khẩu sẽ có 2 trường hợp xảy ra.
• Trường hợp đầu tiên, người dùng nhập sai tài khoản mật khẩu hoặc nhập mật
khẩu không đủ 8 kí tự, đăng nhập thất bại.
• Trường hợp thứ 2 là người dùng nhập đúng tài khoản, mật khẩu đăng nhập
thành công, hệ thống chuyển qua trang Home.

e. Luồng sự kiện phụ

• Người dùng bỏ trống tài khoản hoặc mật khẩu, hệ thống sẽ yêu cầu nhập đầy
đủ.
• Người dùng nhập tài khoản mật khẩu đúng định dạng nhưng tài khoản chưa
tồn tại. Hệ thống thông báo: “Sai tài khoản hoặc tên đăng nhập”.

f. dữ liệu đầu vào

27
 Bắt
Trường dữ liệu Mô tả Điều kiện hợp lệ Ví dụ
buộc?
Email String Có Địa chỉ email hợp lệ tung@gmail.com

Password String Có Đúng mật khẩu ToiLa12#$

được lưu trong db
Bảng 2.1: Bảng dữ liệu đầu vào của use case “Sign up”

2.3.1.2. Biểu đồ hoạt động của chức năng đăng nhập

Hình 2.10: Biểu đồ hoạt động chức năng Đăng Nhập

28
2.3.2. Đặc tả yêu cầu chức năng Check in
2.3.2.1. Use case chức năng Check in
a. Mô tả use case

Hàng ngày cứ đến 0h ngày hôm sau, sẽ có batch chạy để sinh ra 1 bản ghi mới
của ngày hiện tại. Nhân viên khi làm việc sẽ checkin, và checkin chỉ được check 1
lần duy nhất.

➢ Nếu Checkin trước 8h thì Checkin đều là 8h, còn sau 8h sẽ bằng số giờ
lúc đó, tức:
Checkin = 7h55 => checkin = 8h
Checkin= 8h30 => checkin = 8h30
➢ Nếu checkin sau 17h30, công sẽ không được tính

b. Tác nhân

Nhân viên nội bộ.

c. Tiền điều kiện

Người dùng đăng nhập thành công với vai trò member

d. Luồng sự kiện chính

• Người dùng truy cập vào vào hệ thống sau khi qua bước đăng nhập
• Chọn button “Check in”
• Disabled check in đồng thời hiển thị thời gian vừa chấm công

e. Luồng sự kiện phụ

• Người dùng quên bấm nút “Check in”

• Người dùng chưa ấn Check in mà đã Ấn vào button “Check out”
• Người dùng click liên tục vào button Check in

29
f. Dữ liệu đầu vào

Button “Check in”

g. Dữ liệu đầu ra

List Timesheet, cột Check in đã được cập nhật giờ hiện tại
2.3.2.2. Biểu đồ hoạt động của chức năng Check in

Hình 2.11: Biểu đồ hoạt động chức năng Check in

30
2.3.3. Đặc tả yêu cầu chức năng Check out
2.3.3.1. Use case chức năng Check out
a. Mô tả use case
Hàng ngày cứ đến 0h ngày hôm sau, sẽ có batch chạy để sinh ra 1 bản ghi mới
của ngày hiện tại. Nhân viên khi làm việc sẽ checkin, làm xong thì checkout. Tính
công sẽ được khi mà có cả checkin và checkout, nếu thiếu 1 trong 2 checkin,
checkout thì tổng công sẽ ko đc tính.

Tính công = Tổng sáng + Tổng chiều (max = 8 tiếng)

❖ Nếu Checkin trước 12h

➢ Nếu Checkin trước 8h thì Checkin đều là 8h, còn sau 8h sẽ bằng số
giờ lúc đó, tức:
Checkin = 7h55 => checkin = 8h
Checkin= 8h30 => checkin = 8h30
➢ Nếu Checkout trước 12h:

Tổng sáng = Checkout – checkin (max = 4 tiếng)

➢ Nếu checkout sau 12h

Tổng sáng = 12h – checkin (max = 4 tiếng)
➢ Nếu checkout sau 13h30
Tổng chiều = checkout – 13h30 (max = 4 tiếng)
❖ Nếu Checkin sau 12h (đồng nghĩa checkout ko thể nào trước 12h, và chỉ tính
tổng chiều )
➢ Checkin từ 12h- 13h30:
Tổng chiều = checkout – 13h30 (max = 4 tiếng)
➢ Checkout sau 17h30:
Tổng chiều = 17h30 – checkin (max = 4 tiếng)

31
b. Tác nhân

Nhân viên nội bộ.

c. Tiền điều kiện

Người dùng đăng nhập thành công với vai trò member

d. Luồng sự kiện chính

• Người dùng truy cập vào vào hệ thống sau khi qua bước đăng nhập
• Chọn button “Check out”
• Lưu thông tin check out đồng thời hiển thị toàn bộ thời gian trong ngày làm
việc hôm đó

e. Luồng sự kiện phụ

• Người dùng quên bấm nút “Check out”

• Người dùng chưa ấn Check in mà đã Ấn vào button “Check out”
• Người dùng click liên tục vào button Check out

f. Dữ liệu đầu vào

Button “Check out”

g. Dữ liệu đầu ra

List Timesheet, cột Check out đã được cập nhật giờ hiện tại, đồng thời các
cột: Checkin pay, Checkout pay, Lunch break time, Actual working time, Paid
working time, Note cũng sẽ được update.

32
2.3.3.2. Biểu đồ hoạt động của chức năng Check out

Hình 2.12: Biểu đồ hoạt động chức năng Check out

33
2.3.4. Đặc tả yêu cầu chức năng Add Timesheet Management
2.3.4.1. Use case chức năng Add Timesheet Management

a. Mô tả use case

Bổ sung rất cần thiết khi chúng ta quên chấm công, Hãy chọn ngày muốn bổ
sung công và chuẩn bị bằng chứng để gửi đến người kiểm duyệt danh sách bổ sung
công.

b. Tác nhân

Nhân viên nội bộ.

c. Tiền điều kiện

Người dùng đăng nhập thành công với vai trò member

d. Luồng sự kiện chính

• Người dùng truy cập vào vào hệ thống sau khi qua bước đăng nhập
• Chọn button “Additional Timesheet”
• Lưu thông tin vào bảng Add timesheet đồng thời chuyển trạng thái là chờ
duyệt, Và di chuyển đến màn “Danh sách bổ sung công”

e. Luồng sự kiện phụ

• Người dùng nhập sai định dạng file ảnh

• Người dùng bổ trống file ảnh
• Người dùng chưa điền lý do
• Người dùng click liên tục vào button Save

f. dữ liệu đầu vào

34
 Bắt
Trường dữ liệu Mô tả Điều kiện hợp lệ Ví dụ
buộc?

Additional date Date Có Date phải chọn nhỏ 2022-10-04

hơn hoặc bằng ngày
hiện tại
Admin String Có Sẽ mặc định nếu Tùng NT
Admin nếu không
chọn
Check in request Date Có Chọn Giờ muốn 08:00:00
duyệt
Checkout request Date Có Chọn Giờ muốn 17:30:00
duyệt
Evidence Image Có Chọn ảnh dưới Chamcong.png
dạng: jpg,png,jpeg
Reason String Có Không được bổ Em quên chấm
trống công
Bảng 2.2: Bảng dữ liệu đầu vào của use case “Add timesheet”

g. Dữ liệu đầu ra

Đi đến list add timesheet đã tạo

35
2.3.4.2. Biểu đồ hoạt động của chức năng Add Timesheet Management

Hình 2.13: Biểu đồ hoạt động chức năng Bổ sung công

36
2.3.5. Đặc tả yêu cầu chức năng Add Timesheet Approval Management
2.3.5.1. Use case chức năng Add Timesheet Approval Management
a. Mô tả use case

Admin mới có quyền duyệt những danh sách mà người dùng tạo, Admin cần
phải xem kĩ lý do và xem bằng chứng thật kĩ lưỡng trước khi duyệt hoặc hủy duyệt.

b. Tác nhân

Admin

c. Tiền điều kiện

Người dùng đăng nhập thành công với vai trò Admin và phải đơn yêu cầu bổ
sung từ các nhân viên nội bộ

d. Luồng sự kiện chính

• Admin truy cập vào vào hệ thống sau khi qua bước đăng nhập
• Chọn menu “Additional Timesheet Approval”
• Chọn button “Approved” để duyệt và chuyển trạng thái đã duyệt hoặc
Rejected để hủy và chuyển trạng thái đã hủy

e. Luồng sự kiện phụ

• Admin click vào check All Rejected

• Admin click vào check All Approved

f. dữ liệu đầu vào

Bắt
Trường dữ liệu Mô tả Điều kiện hợp lệ Ví dụ
buộc?

Comment: String Không Không được nhập Oke, đã được

quá dài duyệt
Bảng 2.3: Bảng dữ liệu đầu vào của use case “Add timesheet Approval”

37
g. Dữ liệu đầu ra
Đơn duyệt sẽ được xóa khỏi List Duyệt, đồng thời thay đổi trạng thái
Approved hoặc Reject trong List Add Timesheet của nhân viên đã tạo đơn

2.3.5.2. Biểu đồ hoạt động của chức năng Add Timesheet Approval
Management

Hình 2.14: Biểu đồ hoạt động chức năng Duyệt bổ sung công
38
2.3.6. Đặc tả yêu cầu chức năng Project Management
2.3.6.1. Use case chức năng Project Management
a. Mô tả use case

Admin mới có quyền tạo 1 dự án và add nhiều thành viên trong 1 dự án khác
nhau với các vai trò khác nhau. Có những thông tin chính như: Tên dự án, Khách
hàng, Kiểu dự án, Ngày bắt đầu, ngày kết thúc dự án, trạng thái dự án,...

b. Tác nhân

Admin

c. Tiền điều kiện

Người dùng đăng nhập thành công với vai trò Admin

d. Luồng sự kiện chính

• Admin truy cập vào vào hệ thống sau khi qua bước đăng nhập
• Chọn menu “Additional Project”
• Nhập thông tin cần thiết và Chọn button “Save infomation” để lưu thông tin
dự án, sau đó chuyển về màn “Project list”

e. Luồng sự kiện phụ

• Admin nhập thiếu thông tin

• Admin Không nhập thông tin
• Admin click liên tục vào button “Save infomation”

f. dữ liệu đầu vào

Bắt
Trường dữ liệu Mô tả Điều kiện hợp lệ Ví dụ
buộc?

Project Name String Có Không được trống Isol

39
 Bắt
Trường dữ liệu Mô tả Điều kiện hợp lệ Ví dụ
buộc?

Customer String Có Sẽ mặc định nếu EPU software

không chọn

Project Type String Có Sẽ mặc định nếu Lapo

không chọn
Value Contract Interger Có Không được trống 200
(mm) và số nguyên từ 1-
1000
Department String Có Sẽ mặc định nếu D1
Admin nếu không
chọn
Start Date Date Có Không được bổ 2022-08-01
trống
End Date Date Có Không trống và lớn 2022-12-30
hơn start date
Status String Có Sẽ mặc định nếu Developing
Admin nếu không
chọn
Description String Có Không được trống Dự án maintain

Staff String Có Không được trống Tùng NT

và không được trùng
Location String Có Sẽ mặc định nếu Developer
không chọn
Start Date(Staff Date Có Không trống và lớn 2022-11-09
Create) hơn start date, nhỏ
hơn end date
End Date(Staff Date Có Không trống và lớn 2022-12-22
Create) hơn start date, nhỏ
hơn end date và lớn
hơn start date(staff
create)
Effort (%) Interger Có Không trống và số 100
nguyên từ 1-100
Bảng 2.4: Bảng dữ liệu đầu vào của use case “Project Management”

40
g. Dữ liệu đầu ra

Đi đến màn List project và hiện ra các danh sách được thêm mới or cập nhật.
2.3.6.2. Biểu đồ hoạt động của chức năng Project Management

Hình 2.15: Biểu đồ hoạt động chức năng Quản lý dự án

41
2.3.7. Đặc tả yêu cầu chức năng User Management
2.3.7.1. Use case chức năng User Management
a. Mô tả use case

Admin sẽ nắm bắt được tình hình nhân sự của các nhân trong công ty

b. Tác nhân

Admin

c. Tiền điều kiện

Người dùng đăng nhập thành công với vai trò Admin

d. Luồng sự kiện chính

• User truy cập vào vào hệ thống sau khi qua bước đăng nhập
• Chọn menu “User Management”
• Nhập thông tin cần thiết và Chọn button “User Create” để thêm mới nhân
viên mới
• Nhập thông tin cần thiết và Chọn button “Save infomation” để lưu thông tin
dự án, sau đó chuyển về màn “User list”

e. Luồng sự kiện phụ

• Admin nhập thiếu thông tin

• Admin Không nhập thông tin
• Admin click liên tục vào button “Save infomation”.

f. dữ liệu đầu vào

Bắt
Trường dữ liệu Mô tả Điều kiện hợp lệ Ví dụ
buộc?

ID Interger Có Không được trống 446

42
 Bắt
Trường dữ liệu Mô tả Điều kiện hợp lệ Ví dụ
buộc?

Email String Có Không được trống tung@gmail.com

và kiểu mail

Name String Có Không được trống Tùng

Date of birth Date Có Không được trống 2000-07-07

Home town String Không Không quá 255 kí tự Đan Phượng, Hà

Nội

Current residence String Không Không quá 255 kí tự Đan Phượng

University String Không Không quá 255 kí tự Đại Học Điện

Lực

Working form String Có Sẽ mặc định nếu Full time

không chọn

Time start Date Có Không được trống 2021-11-09

Member company String Có Sẽ mặc định nếu Fabbi Hanoi

không chọn
Position String Có Sẽ mặc định nếu Member
không chọn
Division Date Có Sẽ mặc định nếu D2
không chọn
Location Date Có Sẽ mặc định nếu Developer
không chọn

Japanese Interger Không Không N2

43
 Personal photo Image Có Không được trống, Tung.jpg
và ảnh dạng: png,
jpg, jpeg
Gender String Có Sẽ mặc định nếu Male
không chọn

Nationality String Không Không quá 255 kí tự Việt Nam

Ethnic String Không Không quá 255 kí tự Kinh

Phone number Interger Có Được nhập 10 số và 0961024620

format bắt đầu là số:
0
Relative`s phone Interger Không Được nhập 10 số và 0123456789
number format bắt đầu là số:
0
CMND/Passport Interger Có Không quá 255 kí tự 568995572345

Date Range Date Không Không 2021-06-09

Place of issue String Không Không quá 255 kí tự Hà Nội

Visa (if possible) String Không Không quá 255 kí tự

Duration Visa String Không Không quá 255 kí tự

Link Facebook String Không Không quá 255 kí tự

Bảng 2.5: Bảng dữ liệu đầu vào của use case “User Management”

g. Dữ liệu đầu ra
Đi đến màn List User

44
2.3.7.2. Biểu đồ hoạt động của chức năng User Management

Hình 2.16: Biểu đồ hoạt động chức năng User Management

45
2.3.8. Đặc tả yêu cầu chức năng Post Management
2.3.8.1. Use case chức năng Post Management
a. Mô tả use case

Admin hay bất kì ai trong nhân viên nội đều có thể tạo viết để chia sẻ kiến
thức hay blog tâm sự, thông báo,...

b. Tác nhân

Admin, Nhân viên nội bộ

c. Tiền điều kiện

Người dùng đăng nhập thành công với vai trò Admin hoặc member

d. Luồng sự kiện chính

• User/Admin truy cập vào vào hệ thống sau khi qua bước đăng nhập
• Chọn menu “Post Management”
• Nhập thông tin cần thiết và Chọn button “Create new Post” để thêm bài viết
mới
• Nhập thông tin cần thiết và Chọn button “Save infomation” để lưu thông tin
dự án, sau đó chuyển về màn “Post list”

e. Luồng sự kiện phụ

• Admin/Nhân viên nhập thiếu thông tin

• Admin/Nhân viên Không nhập thông tin
• Admin click liên tục vào button “Save infomation”.
• Admin/Nhân viên ấn vào btn “Cancel”

f. dữ liệu đầu vào

46
 Bắt
Trường dữ liệu Mô tả Điều kiện hợp lệ Ví dụ
buộc?

Title String Có Không được trống Chào buổi sáng

vui vẻ cùng với
tôi
Slug String Không Nếu không nhập sẽ chao-buoi-sang-
mặc định theo title vui-ve-cung-voi-
toi
Category String Có Sẽ mặc định nếu World
không chọn
Status Date Có Nếu không nhập sẽ Draff
mặc định theo Draff
Image String Có Không được trống, Tung.png
và ảnh dạng: png,
jpg, jpeg
About author String Không Không quá 255 kí tự Xin chào các bạn
tôi là Shin_kun,
hãy liên hệ với
tôi qua fb:
Nguyễn Tùng
Description String Có Không được trống Các bạn nghĩ sao
khi vào 1 buổi
sáng chúng ta có
thể bổ sung
vitamin tốt cho
cơ thể và cung
cấp đầy đủ dinh
dưỡng
Content String Có Không được trống xin chào hì hì,...
cấp đầy đủ dinh
dưỡng
Bảng 2.6: Bảng dữ liệu đầu vào của use case “Post Management”

g. Dữ liệu đầu ra
Đi đến màn List Post

47
2.3.8.2. Biểu đồ hoạt động của chức năng Post Management

Hình 2.17: Biểu đồ hoạt động chức năng Post Management

48
2.4. Yêu cầu phi chức năng

Hệ thống em xây dựng có các yêu cầu phi chức năng:

Hiệu năng: thời gian tải trang lần đầu khi truy cập website không quá 10 giây,
trong các thao tác của khách hàng với website thời gian đợi không quá 5 giây. Hệ
thống thiết kế với công suất truy cập tại một thời điểm tối đa 500 lượt.
Độ tin cậy: hệ thống hoạt động có khả năng chịu lỗi cao, thời gian khắc phục
lỗi tối đa 2 tiếng, khoảng cách giữa 2 lỗi liên tiếp gần nhất là một tháng.
Tính dễ dùng: giao diện website đơn giản, dễ học cách sử dụng, dễ dùng. Truy
cập ít xảy ra lỗi hệ thống. Website sử dụng thời gian thực, mang lại sự hài lòng cho
khách hàng. Website chạy được trên tất cả các trình duyệt như Microsoft edge,
Chrome, Firefox, …
Tính dễ bảo trì: em xây dựng website bằng các framework mới hiện nay như
laravel (framework php), nên có cộng đồng hỗ trợ mạnh không dễ lỗi thời. Do đó
khá năng bảo trì nâng cấp website cao.
Cơ sở dữ liệu: em sử dụng cơ sở dữ liệu Mysql, chạy trên web server Apache.
Chúng đều được tích hợp trên Laragon hỗ trợ trên tất cả các hệ điều hành từ Cross-
platform, Window, MacOS và Linux.
Như vậy, trong chương 2 em đã trình bày khảo sát và phân tích yêu cầu cho
website bán sách cũng như mô tả yêu cầu chức năng và phi chức năng của hệ thống.
Trong chương tiếp theo, em sẽ trình bày về công nghệ sử dụng để xây dựng lên
website của mình.

49
 CHƯƠNG 3: CÔNG NGHỆ SỬ DỤNG
Như đã trình bày ở mục 2.1, tốc độ tải trang của website quyết định rất lớn
đến việc khách hàng có muốn ở lại website của bạn hay không. Chưa nói đến việc
quyết định đặt mua sách, một website có tốc độ cao, phù hợp với trải nghiệm người
dùng sẽ tạo sự hài lòng và cảm giác tin cậy đối với khách hàng. Hơn nữa đối với một
website bán hàng, dữ liệu liên tục phải được cập nhật để việc quản lý hàng hoá, đơn
hàng không gặp phải những trường hợp khó khăn như nhận đơn hàng nhưng trong
kho đã hết. Khách hàng đặt hàng mà bị huỷ đơn do hết hàng sẽ có thiện cảm rất xấu,
nên tỉ lệ quay lại mua hàng sẽ giảm thấp.
Dựa trên những phân tích trên em quyết định sử dụng những công nghệ Single
page application để tạo ứng dụng web một trang, ngôn ngữ phía front-end như html,
css vs Taiwind, js với Jquery, ngôn ngữ lập trình backend PHP sử dụng framework
Laravel, Livewire, cơ sở dữ liệu Mysql chạy trên web server apache
3.1. Single page application

3.1.1. Định nghĩa

Theo Wikipedia, Single page application (SPA) là một ứng dụng web hay một
website tương tác với người dùng bằng cách tự động viết lại trang web hiện tại với
dữ liệu từ web server, thay vì phương pháp mặc định của trình duyệt web là tải toàn
bộ các trang mới. Mục tiêu là chuyển tiếp nhanh hơn cũng chính là tăng tốc web.
Trong SPA, làm mới trang không bao giờ xảy ra. Thay vào đó, tất cả mã html,
css, javascript cần thiết được trình duyệt truy xuất với mỗi lần tải trang duy nhất.
Các tài nguyên thích hợp được tải và thêm vào trang khi cần thiết, thường là để đáp
lại hành động của người dùng. Vì vậy trang web của chúng ta sẽ không tải lại tại bất
kì thời điểm nào trong quy trình, cũng không chuyển tiếp quyền kiểm soát sang một
trang khác.

50
3.1.2. Cơ sở lý thuyết
Một website theo mô hình client server dù là SPA hay không thì client và
server đều làm nhiệm vụ của riêng nó. Nhưng đối với SPA, sự tách biệt giữa client
side và server side rõ ràng hơn bao giờ hết. Client side làm nhiều việc hơn không chỉ
đơn thuần là hiển thị giao diện còn validate, tạo hiệu ứng, …

Một SPA gồm 4 tầng: tầng domain, tầng store, tầng application services, và tầng
view

• Tầng domain: domain có vai trò mô tả state và lưu trữ business logic. Nó đại
diện cho phần lõi của ứng dụng và thể hiện ở tầng view. Chúng ta sử dụng
tầng domain bất kể framework được sử dụng là gì, Angular, React hay Vue.
• Tầng store: là nơi lưu trữ state của ứng dụng
• Tầng application services: thao tác với luồng state giống như các request Ajax
• Tầng view: bao gồm các container và presentational componet

Có rất nhiều nội dung được lặp lại trên đa số các website. Một số thành phần vẫn
được giữ nguyên khi người dùng điều hướng web như: header, footer, logo,
navigation bar …, một số thì nằm ở những vị trí cố định (filter bar, banner). SPA sử
dụng hiệu quả những sự lặp lại này. Nhờ vào sự linh động viết lại những thành phần
thay đổi trong trang thay vì tải lại toàn bộ một trang, SPA loại bỏ sự ngắt quãng khi
người dùng trải nghiệm những trang nối tiếp nhau.
3.1.3. Những bất cập khác
Trái ngược với single page application chính là multiple pages application.
Theo đó, website theo multiple pages application gồm nhiều trang web được điều
hướng bên server theo thao tác cũng người dùng. Ví dụ như trong php, file điều
hướng là index.php. Mỗi lần chuyển hướng, trình duyệt sẽ tải lại hoàn toàn nội dụng

51
của một trang và tải xuống lại toàn bộ tài nguyên của trang web ngay cả các thành
phần lặp lại trong tất cả các trang như header, footer.
Trước khi SPA ra đời, lập trình web theo hướng multiple pages application
thường tuân theo mô hình MVC (kiểu lập trình truyền thống gồm 3 thành phần
model, view, controller).
Mô hình MVC:

Hình 0.1 Mô hình MVC

Hình 3.1 mô tả sự tương tác giữa các thành phần trong mô hình MVC. Mô hình
gồm ba thành phần chính: Model (M), View (V), Controller (C).

• Model: là phần có nhiệm vụ thao tác với cơ sở dữ liệu. Nó chứa tất cả các
hàm, phương thức truy vấn trực tiếp với cơ sở dữ liệu và controller sẽ thông
qua các hàm, phương thức đó để lấy dữ liệu rồi gửi qua view
• View: là phần giao diện hiển thị trên trình duyệt cho người dùng, có chức năng
ghi nhận hành vi của người dùng và trả lại kết quả nhận được từ controller
• Controller: đây là thành phần đóng vai trò quản lý và điều phối luồng hoạt
động của ứng dụng. Nó sẽ nhận request từ client, truy vấn cơ sở dữ liệu thông
qua model và trả kết quả về view
52
3.2. Lập trình front-end
3.2.1. Ngôn ngữ
HTML (viết tắt của từ Hypertext Markup Language, hay là "Ngôn ngữ Đánh
dấu Siêu văn bản") là một ngôn ngữ đánh dấu được thiết kế ra để tạo nên các trang
web trên World Wide Web. Cùng với CSS và JavaScript, HTML là một trong những
ngôn ngữ quan trọng trong lĩnh vực thiết kế website. HTML được định nghĩa như là
một ứng dụng đơn giản của SGML và được sử dụng trong các tổ chức cần đến các
yêu cầu xuất bản phức tạp. HTML đã trở thành một chuẩn mực của Internet do tổ
chức World Wide Web Consortium (W3C) duy trì. Phiên bản chính thức mới nhất
của HTML là HTML 4.01 (1999). Sau đó, các nhà phát triển đã thay thế nó
bằng XHTML. Hiện nay, phiên bản mới nhất của ngôn ngữ này là HTML5.

CSS (Cascading style sheets) được dùng để miêu tả cách trình bày các tài liệu
viết bằng ngôn ngữ HTML và XHTML. Tác dụng của CSS là hạn chế tối thiểu việc
làm rối mã HTML của trang web bằng các thẻ quy định kiểu dáng (chữ đậm, chữ in
nghiêng, chữ có gạch chân, chữ màu), khiến mã nguồn của trang Web được gọn
gàng hơn, tách nội dung của trang web và định dạng hiển thị, dễ dàng cho việc cập
nhật nội dung; Tạo ra các kiểu dáng có thể áp dụng cho nhiều trang Web, giúp tránh
phải lặp lại việc định dạng cho các trang Web giống nhau.

JavaScript (JS): là một ngôn ngữ lập trình thông dịch được phát triển từ các
khái niệm nguyên mẫu được dùng rộng rãi cho các trang web (client-side) cũng như
phía server-side (với Nodejs). Nếu nói HTML là khung xương của người máy, CSS
là quần áo, thì JS được coi là động cơ để người máy đó hoạt động. JS tạo lên sự
sống động của trang web, giúp người dùng thực hiện tương tác với trang web trên
chính client-side. Đó cũng chính là điểm khách biệt giữa một trang web động với
một trang web tĩnh.

53
3.2.2. Framework khác

Taiwind: là utility-first CSS framework cung cấp các class thực thi những
chức năng nhỏ trong giao diện như .text-black .p-4 ... để xây dựng nhanh chóng các
giao diện người dùng tùy chỉnh. Đây là một css framework cấp thấp, có thể tùy chỉnh
cao, cung cấp cho bạn tất cả các công cụ bạn cần để xây dựng các thiết kế riêng mà
không có bất kỳ sự ràng buộc nào.

Livewire: là một full-stack framework cho Laravel giúp việc xây dựng các
giao diện động trở nên đơn giản hơn. Đây là một stack tuyệt vời để lựa chọn nếu bạn
muốn xây dựng một SPA nhưng cảm thấy khó khăn khi tìm hiểu về các framework
như React.js và Vue.js.
3.3. Lập trình back-end
3.3.1. Ngôn ngữ lập trình PHP và framework Laravel
PHP: Hypertext Preprocessor, là một ngôn ngữ lập trình kịch bản hay một
loại mã lệnh dùng để phát triển ứng dụng bên phía máy chủ (server side), mã nguồn
mở, dùng cho mục đích tổng quát. Nó rất thích hợp với web và có thể dễ dàng nhúng
vào trang html. Do được tối ưu hoá cho các ứng dụng web, tốc độ nhanh, nhỏ gọn,
cú pháp giống Java và C, dễ học và thời gian xây dựng sản phẩm tương đối ngắn so
với các ngôn ngữ lập trình khác nên PHP nhanh chóng trở thành ngôn ngữ lập trình
web phổ biến nhất thế giới.
Laravel là framework cực mạnh của PHP, và là framework PHP phổ biến nhất,
tốt nhất hiện nay. Em sử dụng Laravel vì những ưu điểm tuyệt vời của nó: tốc độ xử
lý nhanh, nguồn tài nguyên vô cùng lớn và sẵn có, dễ sử dụng, tính bảo mật cao. Nó
sử dụng PDO để chống tấn công SQL Injection, sử dụng một field token để chống
tấn công kiểu CSRF. Nó dễ dàng kết nối và truy xuất dữ liệu từ database thông qua
lớp Model.

54
3.3.2. Cơ sở dữ liệu
MySQL là một hệ thống quản trị cơ sở dữ liệu mã nguồn mở phổ biến nhất
trên thế giới, hoạt động theo mô hình client-server. MySQL được các nhà phát triển,
lập trình viên rất ưa chuộng trong quá trình phát triển ứng dụng vì nó có tốc độ cao,
ổn định và dễ sử dụng, có tính khả chuyển, hoạt động trên nhiều hệ điều hành cung
cập một lượng lớn các hàm tiện ích mạnh. Vì vậy, MySQL rất thích hợp cho các ứng
dụng có truy cập CSDL trên internet. MySQL là hệ quản trị cơ sở dữ liệu quan hệ
sử dụng ngôn ngữ truy vấn có cấu trúc (SQL). MySQL hỗ trợ rất tốt cho PHP, làm
nơi lưu trữ thông tin trên các trang web.
Workbrech: hoạt động dựa trên sự tích hợp của 5 phần mềm chính là Cross-
Platform (X), Apache (A), MariaDB (M), PHP (P), và Perl (P). Workbrech là chương
trình tạo web server được ứng dụng trên các hệ điều hành Linux, MacOS, Windows,
Cross-Platform, Solaris. Ưu điểm của Workbrech là phần mềm mã nguồn mở, có
cấu hình tương đối đơn giản, gọn nhẹ, hỗ trợ PHP, MySQL chạy trên web server
Apache.

55
 CHƯƠNG 4: PHÁT TRIỂN VÀ TRIỂN KHAI ỨNG DỤNG

4.1. Thiết kế kiến trúc

4.1.1. Lựa chọn kiến trúc phần mềm
Kiến trúc client server là mô hình nổi tiếng trên mạng máy tính, phổ biến và
được áp dụng rộng rãi trên các trang web hiện nay.

Hình 0.2 Mô hình client server

Ý tưởng của mô hình kiến trúc này là: client (máy khách) sẽ gửi yêu cầu
(request) đến server (máy chủ, cung ứng dịch vụ cho máy khách). Server sẽ xử lý dữ
liệu và gửi kết quả về cho client
Là kiến trúc gồm 2 thành phần chính là máy khách (client) và máy chủ (server).
• Server là nơi lưu trữ tài nguyên, cài đặt các chương trình dịch vụ và thực hiện
các yêu cầu của client. Đây là một máy tính hoặc một chuỗi các máy tính liên
kết với nhau có tốc độ xử lý cao dùng để phục vụ cho việc chia sẻ tài nguyên
như file ảnh, file html, dữ liệu, … cho nhiều máy khách

56
 • Client đóng vai trò gửi yêu cầu đến server để thực hiện một nhiệm vụ nào đó
như lấy dữ liệu từ database, gửi mail, …. Client gồm máy tính và thiết bị điện
tử nói chung như desktop, laptop.

Kiến trúc này cho phép mạng tập chung các ứng dụng và chức năng tại một hay
nhiều máy chủ chuyển dụng. Khi nhận một yêu cầu từ client, server này có thể gửi
tiếp yêu cầu vừa nhận được cho server khác ví dụ như database serve vì bản thân nó
không thể xử lý yêu cầu này được. Các máy chủ trở thành trung tâm của hệ thống,
cho phép chia sẻ tài nguyên tới nhiều client. Mô hình này tận dụng được ưu điểm
tốc độ xử lý, truy vấn dữ liệu của server. Một ứng dụng SPA xử dụng mô hình kiến
trúc client server làm cho client side và server side tách biệt rõ hơn bao giờ hết.
Trong đó client side xử lý nhiều hơn giúp giảm tải cho server.
Trong quá trình hoạt động, client server luôn phải giao tiếp với nhau. Toàn bộ
quá trình giao tiếp giữa client và server dựa trên giao thức chuẩn TCP/IP.
4.1.2. Thiết kế tổng quan

Hình 0.2: Biểu đồ phụ thuộc gói

57
 Hình 4.2 là biểu đồ gói phụ thuộc gồm các gói: views, route, controller,
Middleware, Provider, và models.
Views: là gói bao gồm các thành phần (component) trong giao diện, mỗi
component thực hiện một vai trò nhất định và có thể có liên kết với nhau tạo nên
một trang hoàn chỉnh
Route: Là package bên phía backend, chứa các lớp: api, web, … dùng để xác
định phương thức trong controller nào được gọi.
Controller: gồm các class xử lý và yêu cầu các lớp models lấy dữ liệu trong
database và trả về response cho trình duyệt
Middleware: là phần nằm giữa Route và Controller, gồm các lớp có nhiệm vụ
kiểm tra, bảo vệ sự truy cập không hợp lệ vào controller với điều kiện xác định. Có
nghĩa là nếu bạn định nghĩa trong class của Middleware là bạn phải đăng nhập để sử
dụng phương thức nào đó trong controller, thì nếu bạn chưa đăng nhập thì có gọi
phương thức đó cũng sẽ không được thực thi
Provider: gồm các class như AuthServiceProvider, RouteServiceProvider,…
hỗ trợ cho việc định tuyến hay bảo mật trong Route
Models: Gồm các class kế thừa class Model, có nhiệm vụ khởi tạo hoặc lấy
dữ liệu trong database.
4.2. Thiết kế chi tiết
4.2.1. Thiết kế giao diện
4.2.1.1. Yêu cầu về thiết kế
Giao diện phần mềm hướng tới sự thân thiện với người dùng. Giao diện phải
đảm bảo hiển thị tốt trên các màn hình máy tính từ 14 inch đến 18,5 inch. Các thông
tin, thông báo phải được hiển thị đầy đủ. Bố cục giao diện cân đối, các thành phần
có sự kết hợp hài hoà phù hợp với chuỗi thao tác của người dùng phục vụ một nghiệp
vụ nào đó … Màu sắc đơn giản hài hoà mang lại cảm giác dễ chịu cho người dùng.

58
Hình ảnh có kích thước hợp lý, không làm ảnh hưởng đến tốc độ tải trang. Font chữ
đơn giản không màu mè.
Website có hai kiểu giao diện chính: giao diện dành cho quản trị viên và dành
cho khách hàng.
Đối với giao diện của quản trị viên: các ô nhập liệu phải được thiết kế sao cho
không cần dùng chuột, thao tác người dùng liên tục, các ô phải có sự liên kết chặt
chẽ với nhau giúp người dùng thấy rõ sự tương quan giữa các dữ liệu.
Đối với khách hàng: tránh làm gián đoạn thao tác của người dùng. Hiển thị
thông tin dữ liệu đầy đủ.
Sau đây là phần thiết kế màn hình
4.2.1.2. Thiết kế giao diện màn hình
Gồm các màn hình 2 loại màn hình: dành cho nội bộ và người dùng. Chúng
không quá khác biệt, chủ yếu khác ở layout chung, các form nhập liệu gần giống
nhau, các thông báo, xác nhận như nhau.

Hình 0.3: Layout ECS nội bộ

59
Hình 0.4: Layout ECS customer

Hình 0.5: Nhập Liệu

60
 Hình 0.6: Confirm

Hình 0.7: Notification

61
4.2.2. Thiết kế lớp
Trong ứng dụng web quản lý doanh nghiệp có 2 lớp quan trọng nhất là
TimesheetController và PostController.

TimesheetController

STT Tên phương thức Mô tả

index index and search date Timesheets
1.
checkIn checkin date Timesheets
2.
checkOut checkout date Timesheets
3.

Bảng 0.1 Bảng mô tả lớp “TimesheetController”

AddTimesheetController

STT Tên phương thức Mô tả

insertAddTimesheet get id timesheet and call Users is admin
1.
listAddTimesheet index list additional timesheet
2.
addTimeSheet create additional timesheet
3.
listDetailAddTimeshe List detail Additional timesheet
4.
et
editAddTimesheet edit Additional timesheet
5.
updateAddTimesheet update Additional timesheet
6.
deleteAddTimesheet delete Additional timesheet
7.
approvalTimesheet list add-timesheet approval
8.

62
 getAddtimesheetById get timesheet by id
9.
approvalOrReject approval Additional timesheet
10.
updateAll update Additional Timesheets
11.

Bảng 0.2. Bảng mô tả lớp “AddTimesheetController”

ProjectController

STT Tên phương thức Mô tả

index Index and search Project
1.
insert Show screen Create project
2.
create Create new project
3.
edit view edit project
4.
update update Project
5.
deletePrj Delete project
6.
detail Detail project
7.
chartStatus Chart user status: free or working
8.

Bảng 0.3. Bảng mô tả lớp “ProjectController”

63
 UserController

STT Tên phương thức Mô tả

create Show the form for creating a new user
1.
insert insert a new user created resource in
2.
storage.
index Show all users
3.
edit Show the form for editing user by ID
4.
update Update user by id resource in storage.
5.
delete Delete user by id resource in storage.
6.
leave Show all users leave
7.
detail Show detail user
8.

Bảng 0.4. Bảng mô tả lớp “UserController”

PostController

STT Tên phương thức Mô tả

index show all list post
1.
create Create new a post
2.
insert insert a new post
3.
edit find post by slug
4.
update Update post by id
5.

64
 delete Delete post
6.
detail detail post
7.
uploadImage Upload Image Ckeditor
8.

Bảng 0.5. Bảng mô tả lớp “PostController”

4.2.3. Thiết kế cơ sở dữ liệu

4.2.3.1. Sơ đồ quan hệ

Hình 4.8: Biểu đồ dữ liệu quan hệ

65
4.2.3.2. Chi tiết các bảng
Bảng users

Bảng Timesheets

66
Bảng AddTimesheets

Bảng Departments

Bảng Project Type

67
Bảng Roles

Bảng User has project

Bảng Project

68
Bảng Positions

Bảng Departments

Bảng Comments

69
4.3. Xây dựng ứng dụng
4.3.1. Thư viện và công cụ sử dụng
Mục đích Công cụ Địa chỉ URL
IDE lập trình Visual studio https://code.visualstudio.com/
code 64 bit
version 1.56
Chương trình tạo MySQL https://www.mysql.com/products/workbench
web server Workbench
8.0 CE
Công cụ thiết kế Astah UML https://astah.net/
bản vẽ
Công cụ thiết kế Draw https://app.diagrams.net/
E-R diagram
Ngôn ngữ lập PHP 7.4.11 https://www.php.net
trình back end
Frame work back Laravel 8 https://laravel.com/docs/8.x
end
Ngôn ngữ lập JavaScript
trình front-end ES6
Ngôn ngữ front- Html5, css3
end
Framework front- Bootstrap4, https://getbootstrap.com
end Taiwind

Bảng 0.6: Danh sách thư viện và công cụ sử dụng

70
4.3.2. Minh họa các chức năng chính

Hình 4.9: Trang đăng nhập

Hình 4.15 là trang login Yêu cầu người dùng cần nhập đúng Email và
Password để có thể truy cập vào được Hệ Thống
o Khi người dùng nhập đúng dữ liệu vào tên đăng nhập và mật khẩu.
o Người dùng nhấn vào nút Login
o Nhập chính xác giao diện đăng nhập sẽ được chuyển sang giao diện
chính

71
 Hình 4.10: Trang chủ
Hình 4.16 là khi đăng nhập thành công, Trang Chủ sẽ hiện ra với các thanh
menu nằm bên trái bao gồm: Dashboard, Timesheet, Overtime, Additional
Timesheet, Additional Project, Instructions for use.

Hình 4.11: Màn Additional Timesheet Create

72
 Hình 4.17 là giao diện màn Bổ sung công, Bạn sẽ chọn admin kiểm duyệt, và
lấy ảnh làm bằng chứng và điền lý do. Hãy nhớ không được bổ trống.

Hình 4.12: Màn Additional Timesheet List

Hình 4.18 là giao danh sách công số đã tạo với các chức năng là:
❖ Xem chi tiết: Khi nhấn vào button: ‘Detail’ tức hiển thị chi tiết Bổ sung
công
❖ Chỉnh Sửa
❖ Xóa đơn bổ sung đã tạo
❖ Tìm kiếm đơn bổ sung công

73
 Hình 4.13: Màn Additional Project
Hình 4.19, Đây là giao diện mà tạo dự án, Bạn có thể tạo với các thông tin
như: tên dự án, loại dự án, khách hàng, Phòng ban, Ngày bắt đầu, ngày kết thúc,
trạng thái dự án, Mô tả. Bên cạnh đó là có thể thêm các member với các vị trí như
developer, tester,.. khác nhau. Với điều kiện thỏa mãn là start date của project luôn
nhỏ hơn hoặc bằng end date của project, start date mà user tham ra luôn nằm trong
khoảng thời gian diễn ra trong dự án, Và end date user cũng nằm trong khoảng thời
gian diễn ra dự và luôn lớn hơn hoặc bằng start date user tham ra.
4.4. Kiểm thử và triển khai
4.4.1. Kiểm thử
Kiểm thử cho chức năng CRUD project
Chức năng Giá trị đầu vào Đầu ra cần đạt Kết quả
Thêm dự án Nhập thiếu một Khung input đỏ và khi trỏ Đạt
hoặc nhiều các chuột sẽ hiển thị yêu cầu
trường bắt buộc

74
 người dùng điền thông
tin trường này
Cập nhật hoặc Click vào button Button không hoạt động Đạt
xoá dự án cập nhật hoặc và đặt màu background
xoá thể hiện không thể ấn
Xoá dự án Chọn sách cần Hiển thị cảnh báo xác Đạt
xoá nhận xoá. Xác nhận thì
xoá và thông báo xoá
thành công
Tìm kiếm Nhập thông tin Hiển thị danh sách sách Đạt
các trường cần tương ứng với tất cả
tìm kiếm thông tin đã nhập. Các ô
không nhập mặc định sẽ
không tìm kiếm.
Phân trang Click vào button Hiển thị danh sách sách Đạt
next page hoặc tương ứng không bỏ sót
pre page bản ghi nào

Bảng 0.7: Bảng kiểm thử chức năng CRUD dự án

75
4.4.2. Triển khai
Thiết bị triển khai: laptop dell inspiron 3542, intel(R) core i5-4210U, ram 8gb,
màn hình 15,6 inch.
Một số phần mềm cần cài đặt:

• Hệ điều hành window 10 pro

• Visual studio code 64 bit version 1.56
• Xampp 64 bit version 8.0.6
• NodeJs version 14.17.0
• Composer

Tải code về, có hai phần code là back-end và front-end. Sau đó, ở fontend chạy
lệnh npm install để npm tải các package cần dùng về. Ở phần back-end, chạy lệnh
composer init để composer tải các package, và dependencies của tệp composer.json
về. Tạo database trong phpmyadmin của Xampp và import data vào.

76
 KẾT LUẬN

Trong quá trình thực hiện báo cáo môn “Thực tập tốt nghiệp”, em đã cố gắng
hết sức để tìm hiểu và học hỏi nhưng vì khả năng còn hạn chế nên không tránh khỏi
những sai sót, nên có thể chưa giải quyết được triệt để những vấn đề đặt ra. Chúng
em rất mong nhận được sự thông cảm của các quý thầy cô. Chúng em xin chân thành
cảm ơn.

Những kết quả đạt được:

- Củng cố kinh nghiệm làm việc nhóm

- Biết cách quản lý dự án, và xem được tiến độ dự án
- Có thêm kinh nghiệm làm php-laravel, Taiwild, HTML, CSS, JS
- Có thêm kinh nghiệm ước tính thời gian, ...

Những hạn chế:

- Do còn hạn chế nên chưa thể hoàn thiện hết các chức năng
- Nghiệp vụ chỉ dừng ở mực làm được và nhanh nhưng chưa được tối ưu.
- Mặc dù đã làm được trang web SPA không load lại trang giúp 1 phần tăng
trải nghiệp cho client nhưng performance vẫn chưa mượt, có rất nhiều
nguyên nhưng chủ yếu là chưa tối ưu được câu truy vấn, …

Hướng phát triển trong tương lai:

- Sửa chữa các lỗi nhỏ còn tồn lại trong dự án

- Sẽ phát triển thêm ở giao diện người dùng với chức năng ví dụ như: Mua
bán giữa các thành viên nội bộ, trang tin tức nội bộ kết hợp phần mềm chat
để các thành viên nội bộ có thể tương tác với nhau.

77
 TÀI LIỆU THAM KHẢO
[1] Trang web: https://laravel.com/
[2] Trang web: https://laravel-livewire.com/
[3] Trang web: https://tailwindcss.com/
[4] Trang web: https://laragon.org/

78