Nghiên cứu các mẫu thiết kế và ứng dụng để xây dựng hệ thống quản lý thông tin tổng thể cho doanh nghiệp

MỤC LỤC

BẢNG CHỮ VIẾT TẮT 5

DANH MỤC CÁC HÌNH VẼ VÀ ðỒ THỊ 6

MỞ ðẦU 9

1. Cơ sở khoa học và thực tiễn của ñề tài: 9

2. Mục tiêu và phạm vi nghiên cứu của luận văn 11

3. Nội dung nghiên cứu và thực hiện của luận văn 11

4. Tóm tắt cấu trúc của luận văn 12

CHƯƠNG 1 13

TỔNG QUAN VỀ MÔ HÌNH SỬ DỤNG LẠI 13

1.1. Giới thiệu chung 13

1.2. Tổng quan về các mẫu thiết kế 13

1.2.1. Mẫu thiết kế là gì ? 13

1.2.1.1. Các ñịnh nghĩa về mẫu thiết kế [4,9] 13

1.2.1.2. Các thành phần của mẫu thiết kế [8,9] 14

1.2.2. Danh mục các mẫu thiết kế và phân loại [9] 15

1.2.3. Sơ ñồ mối quan hệ giữa các mẫu thiết kế [9] 17

1.3. Một số mẫu thiết kế ñiển hình trong các ứng dụng quản lý. 17

1.3.1. Mẫu Quan sát 18

1.3.2. Mẫu Thực hiện lệnh 20

1.3.3. Mẫu Trạng thái 22

1.3.4. Mẫu Phương thức tiêu bản 23

1.3.5. Mẫu Chuỗi các trách nhiệm 24

1.3.6. Mẫu Chiến lược 26

1.3.7. Mẫu Kịch bản thao tác 28

1.3.8. Mẫu Mô hình lĩnh vực 29

1.3.9. Mẫu Cổng dữ liệu của bảng 31

1.3.10. Mẫu ðối tượng chuyển ñổi dữ liệu 33

CHƯƠNG 2 36

- 2 -

TỔNG QUAN VỀ HỆ THỐNG HOẠCH ðỊNH NGUỒN LỰC DOANH NGHIỆP -
ERP 36

2.1. Lịch sử hình thành 36

2.2. ERM- Sự tích hợp ERP và Nghiệp vụ sản xuất kinh doanh 40

2.3. Lợi ích của danh nghiệp khi sử dụng ERP 43

2.3.1 Tiếp cận thông tin quản trị ñáng tin cậy 43

2.3.2 Công tác kế toán chính xác hơn 43

2.3.3 Cải tiến quản lý hàng tồn kho 43

2.3.4 Tăng hiệu quả sản xuất 43

2.3.5 Quản lý nhân sự hiệu quả hơn 44

2.3.6 Các qui trình kinh doanh ñược xác ñịnh rõ ràng hơn 44

CHƯƠNG 3 45

ỨNG DỤNG CÁC MẪU THIẾT KẾ ðỂ XÂY DỰNG CÁC PHÂN HỆ TRONG HỆ
THỐNG QUẢN LÝ DOANH NGHIỆP 45

3.1. Phân hệ chính: Các lớp cơ sở, quản lý bảo mật, báo cáo. 45

3.1.1. Bài toán ñặt ra 45

3.1.2. Phạm vi bài toán 46

3.1.3. Phân tích yêu cầu bài toán và xác ñịnh giải pháp 46

3.1.4. Thiết kế Phân hệ chính 47

3.1.4.1. Thiết kế các lớp xử lý, truy cập CSDL 48

3.1.4.2. Chức năng Quản lý bảo mật ứng dụng 53

3.1.4.3. Chức năng Quản lý cấu trúc các bảng dữ liệu 69

3.2. Phân hệ Quản lý mua bán vật tư – nguyên liệu 74

3.2.1. Bài toán ñặt ra 74

3.2.2. Phạm vi bài toán 75

3.2.3. Mô tả nghiệp vụ quản lý 75

3.2.3.1. Xác ñịnh các thông tin chung về quản lý mua bán vật tư,
nguyên liệu 75

3.2.3.2. Công tác quản lý hoạt ñộng mua bán vật tư - nguyên liệu 78

- 3 -

3.2.3.3. Sơ ñồ tiến trình quản lý hoạt ñộng mua bán vật tư 79

3.2.3.4. Các yêu cầu của phân hệ quản lý mua bán vật tư-nguyên liệu80

3.2.3.5. Các chức năng của Phân hệ quản lý mua bán vật tư-nguyên
liệu 80

3.2.3.6. Từ ñiển dữ liệu và mô hình lĩnh vực nghiệp vụ 81

3.2.4. ðặc tả hệ thống 83

3.2.4.1. Các tác nhân của hệ thống 83

3.2.4.2. Các ca sử dụng tiêu biểu của hệ thống 85

3.2.4.3. Mô hình ca sử dụng tổng thể 88

3.2.4.4. Mô tả chi tiết các ca sử dụng 89

3.2.5. Phân tích hệ thống 95

3.2.5.1. Phân tích các ca sử dụng 95

3.2.5.1. Phân tích các lớp 101

3.2.6. Thiết kế hệ thống 105

3.2.6.1. Kiến trúc vật lý của ứng dụng 105

3.2.6.2. Xác ñịnh các gói thiết kế 106

3.2.6.3. Thiết kế cho từng ca sử dụng 106

CHƯƠNG 4 109

CÀI ðẶT VÀ TRIỂN KHAI HỆ THỐNG 109

4.1. Các yêu cầu cài ñặt triển khai hệ thống 109

4.2. Giới thiệu chương trình 110

4.2.1. Các mục tiêu mà hệ thống ñạt ñược 110

4.2.2. Cấu trúc chương trình 110

4.2.3. Các ñối tượng sử dụng chương trình 111

4.2.4. Giao diện một số chức năng chính 112

4.3. Khả năng triển khai áp dụng 114

KẾT LUẬN 115

1. Các kết quả ñạt ñược 115

2. Những vấn ñề tồn tại và hướng phát triển 116

- 4 -

TÀI LIỆU THAM KHẢO 117

Tài liệu tiếng Việt 117

Tài liệu tiếng Anh 117

Các trang Web 118

Bộ công cụ 118





BẢNG CHỮ VIẾT TẮT
Chữ viết tắt Tên ñầy ñủ
APICS American Production and Inventory Control Society
BOM Bill of Materials
CSDL Cơ Sở Dữ Liệu
ERP Enterprise Resource Planning
ERM Enterprise Resource Management
GOF Gang Of Four
GUI Graphic User Interface
MRP Material Requirements Planning
MRP II Manufacturing Resource Planning
NCC Nhà cung cấp
SQL Strured-Query Languague
VT-NL Vật tư- Nguyên liệu


DANH MỤC CÁC HÌNH VẼ VÀ ðỒ THỊ
Hình 1.1: Sơ ñồ mối quan hệ giữa các mẫu thiết kế 17

Hình 1.2: Cấu trúc mẫu Observer 18

Hình 1.3: Biểu ñồ cộng tác của mẫu Observer 19

Hình 1.4: Cấu trúc mẫu Command 20

Hình 1.5: Biểu ñồ cộng tác của mẫu Command 21

Hình 1.6: Cấu trúc mẫu State 22

Hình 1.7: Cấu trúc mẫu Template Method 23

Hình 1.8.1: Cấu trúc mẫu Chain of Responsibility 25

Hình 1.8.2: Cấu trúc mẫu Chain of Responsibility 25

Hình 1.9: Cấu trúc mẫu Strategy 26

Hình 1.10: Cấu trúc mẫu Transaction Script 28

Hình 1.11: Cấu trúc mẫu Transaction Script kết hợp với mẫu Command 29

Hình 1.12: Cấu trúc mẫu Domain Model sử dụng mẫu Strategy 30

Hình 1.13: Cấu trúc mẫu Table Data Gateway 32

Hình 1.14: Cấu trúc mẫu Data Transfer Object 34

Hình 2.1 Lịch sử phát triển của ERP 37

Hình 2.2 ERM – Sự tích hợp ERP và nghiệp vụ 41

Hình 2.3 ðịnh nghĩa mô hình ERM. 42

Hình 3.1. Kiến trúc hệ thống dựa trên mẫu MVC 47

Hình 3.2. Kiến trúc các lớp giao tiếp CSDL sử dụng mẫu thiết kế 48

Hình 3.3. Sử dụng Table Definition ñể giảm thiểu thay ñổi. 50

Hình 3.4. Cấu trúc các phân lớp quản lý các gói của mỗi Phân hệ trong hệ thống 51

Hình 3.5. Lược ñồ lớp xử lý dữ liệu của ñối tượng Nhân viên. 53

Hình 3.6. Quá trình ñăng nhập hệ thống. 54

Hình 3.7. Mô hình tổng thể các ca sử dụng liên quan ñến bảo mật. 54

Hình 3.8. Các lớp thực thi ca sử dụng ðăng nhập 59

Hình 3.9. Biểu ñồ cộng tác ca sử dụng ðăng nhập. 60

Hình 3.10. Các lớp thực thi ca sử dụng ðổi mật khẩu. 60

Hình 3.11. Biểu ñồ cộng tác ca sử dụng ðổi mật khẩu 61

Hình 3.12. Các lớp trong ca sử dụng Cập nhật nhóm quyền 61

Hình 3.13. Biểu ñồ cộng tác ca sử dụng Cập nhật nhóm quyền. 62

- 7 -

Hình 3.14. Các lớp trong ca sử dụng Phân quyền. 62

Hình 3.15. Biểu ñồ cộng tác ca sử dụng Phân quyền 63

Hình 3.16. Lớp thiết kế ca sử dụng ðăng nhập chưa áp dụng mẫu 65

Hình 3.17. Các lớp thiết kế trong ca sử dụng ðăng nhập áp dụng các mẫu thiết kế. 66

Hình 3.18. Các lớp thiết kế ca sử dụng ðổi mật khẩu chưa áp dụng mẫu 67

Hình 3.19. Các lớp thiết kế trong ca sử dụng ðổi mật khẩu áp dụng các mẫu thiết kế.
67

Hình 3.20. Kiến trúc các lớp bảo mật ứng dụng 68

Hình 3.21. Mô hình ca sử dụng phần Quản lý cấu trúc bảng 70

Hình 3.22. Các lớp của ca sử dụng Cập Nhật Nhóm Bảng 70

Hình 3.23. Biểu ñồ cộng tác ca sử dụng Cập Nhật Nhóm Bảng 71

Hình 3.24. Các lớp của ca sử dụng Cập Nhật Bảng 71

Hình 3.25. Biểu ñồ cộng tác ca sử dụng Cập Nhật Bảng 72

Hình 3.26. Các lớp thiết kế trong ca sử dụng Cập nhật nhóm bảng 72

Hình 3.27. Các lớp thiết kế trong ca sử dụng cập nhật nhóm bảng áp dụng mẫu 73

Hình 3.28. Các lớp thiết kế trong ca sử dụng Cập nhật bảng 73

Hình 3.29. Các lớp thiết kế trong ca sử dụng Cập nhật bảng áp dụng mẫu 73

Hình 3.30. Kiến trúc lớp của phần Quản lý cấu trúc bảng 74

Hình 3.31. Mô hình phân cấp quản lý trong doanh nghiệp 76

Hình 3.32: Sơ ñồ tiến trình quản lý mua bán VT-NL 79

Hình 3.33: Mô hình khái niệm của chức năng Quản lý mua bán VT-NL 83

Hình 3.34: Mô hình ca sử dụng tổng thể của Phân hệ Quản lý mua bán VT-NL 88

Hình 3.35: Các lớp thực thi ca sử dụng Lập phiếu yêu cầu mua 95

Hình 3.36: Biểu ñồ cộng tác các lớp ca sử dụng Lập phiếu yêu cầu mua 96

Hình 3.37: Các lớp thực thi ca sử dụng Lập yêu cầu báo giá 96

Hình 3.38: Biểu ñồ cộng tác các lớp ca sử dụng Lập yêu cầu báo giá 97

Hình 3.39: Các lớp thực thi ca sử dụng Lập yêu cầu ñặt hàng 97

Hình 3.40: Biểu ñồ cộng tác các lớp ca sử dụng Lập yêu cầu ñặt hàng 98

Hình 3.41: Các lớp phân tích thực thi ca sử dụng Lập phiếu Nhận hàng 98

Hình 3.42: Biểu ñồ cộng tác các lớp ca sử dụng Lập phiếu nhận hàng 99

Hình 3.43: Các lớp phân tích thực thi ca sử dụng Lập phiếu yêu cầu thanh toán 100

Hình 3.44: Biểu ñồ cộng tác các lớp ca sử dụng Lập phiếu nhận hàng 100

- 8 -

Hình 3.45: Kiến trúc vật lý của ứng dụng. 105

Hình 3.46: Các lớp thiết kế ca sử dụng Lập yêu cầu mua hàng. 106

Hình 3.47: Các lớp thiết kế ca sử dụng Lập yêu cầu mua hàng sử dụng mẫu. 107

Hình 3.48: Các lớp thiết kế ca sử dụng Lập yêu cầu báo giá. 107

Hình 3.49: Các lớp thiết kế ca sử dụng Lập yêu cầu báo giá. 108

Hình 3.50: Lớp thiết kế yêu cầu mua hàng áp dụng mẫu State 108

Hình 4.1: Giao diện chính của chương trình. 112

Hình 4.2: Giao diện quản lý thực ñơn. 112

Hình 4.3: Giao diện quản lý Báo cáo. 113

Hình 4.4: Giao diện quản lý Khách hàng. 114

MỞ ðẦU
1. Cơ sở khoa học và thực tiễn của ñề tài:

a. Cơ sở khoa học và ý nghĩa thực tiễn của việc nghiên cứu và ứng dụng các mô
hình sử dụng lại vào quá trình thiết kế phần mềm:
Một trong những giải pháp ñể nâng cao năng suất của quá trình phát triển phần
mềm là xây dựng những giải pháp ñể có thể sử dụng lại trong các bước tiếp theo hoặc
trong các dự án phần mềm khác. Sự ra ñời của những giải pháp hướng ñối tượng mà
chủ yếu là phân tích thiết kế và lập trình hượng ñối tượng ñã ñem lại những bước tiến
ñáng kể. Trong ñó, thiết kế hướng ñối tượng ñóng vai trò ñịnh hướng và quyết ñịnh
ñến việc sử dụng lại những tài nguyên trong quá trình phát triển phần mềm.
Thiết kế hướng ñối tượng cho phép chúng ta theo dõi và quản lý ñược sự phụ
thuộc giữa các mô ñun trong kiến trúc của hệ thống. Tuy nhiên, thiết kế một phần mềm
hướng ñối tượng ñã khó, việc thiết kế phần mềm hướng ñối tượng với các thành phần
có thể sử dụng lại thậm chí còn khó hơn nhiều. Trước tiên, cần phải tìm ra các ñối
tượng thật chính xác, thể hiện chúng dưới các lớp ñối tượng với mức ñộ trừu tượng
phù hợp. ðồng thời, ta cũng cần chỉ ra ñược sơ ñồ thừa kế, mối liên hệ và giao tiếp của
những ñối tượng này. Những yêu cầu trên cần thiết kế ñể ñáp ứng ñược yêu cầu của
bài toán hiện tại song cũng cần có tính tổng quát và linh hoạt ñủ ñể có thể giải quyết
một phần hoặc toàn bộ các bài toán có thể gặp trong tương lai.
Một kinh nghiệm thường ñược áp dụng trong quá trình thiết kế là không tìm cách
giải quyết mọi vấn ñề bằng những thành phần căn bản. Thay vào ñó, ta cần tìm cách áp
dụng những mô hình ñã thành công trong thực tế ñối với một số bài toán tương tự ñã
từng gặp. Một khi mô hình giải quyết ñã ñủ hoàn thiện, nó có thể ñược sử dụng lại
nhiều lần trong những lớp bài toán với yêu cầu nhất ñịnh. Khi ñó, người thiết kế khi
gặp một bài toàn nào ñó, qua xem xét ñể xác ñịnh ñược lớp bài toán, họ có thể tìm ra
ñược mô hình thiết kế phù hợp và áp dụng ngay những mô hình ñó vào thiết kế của
mình mà không cần phải xem xét lại từ ñầu.
Việc nghiên cứu và ứng dụng các mô hình sử dụng lại vào quá trình thiết kế phần
mềm là một bước tiếp cận mới trong khâu phân tích và thiết kế phần mềm hướng ñối
tượng. Việc áp dụng các mô hình sử dụng lại vào quá trình thiết kế làm giảm thiểu thời
gian và chi phí ñể thiết kế phần mềm, nâng cao khả năng ứng dụng và mở rộng phát
triển trong tương lai của phần mềm ứng dụng. Thiết kế phần mềm là một trong những

khâu quan trọng nhất của quy trình xây dựng phần mềm, giai ñoạn này quyết ñịnh rất
lớn ñến sự thành công hay thất bại của phần mềm. Các mô hình sử dụng lại ñã ñược
- 10 -

nghiên cứu và áp dụng thành công vào thực tế, dó ñó việc áp dụng các mô hình sử
dụng lại vào quá trình thiết kế làm giảm thiểu tính rủi ro trong quá trình xây dựng phần
mềm sau này.
b. Cơ sở khoa học và ý nghĩa thực tiễn của việc nghiên cứu, thiết kế và xây dựng
Hệ thống Quản lý tổng thể doanh nghiệp:
Ngày nay, với sự phát triển nhanh chóng của khoa học kỹ thuật nói chung và
công nghệ thông tin nói riêng ñã mang lại nhiều thành tựu to lớn. Những thành tựu của
khoa học ñược áp dụng trong tất cả các hoạt ñộng của con người và ñã ñem lại những
thành công hết sức lớn lao. Ở Việt Nam hiện nay, các công ty, xí nghiệp và các doanh
nghiệp vừa và nhỏ hầu hết ñã trang bị cơ sở hạ tầng về máy tính và kết nối mạng ñã
tạo cơ sở cho việc áp dụng những công nghệ mới của mạng máy tính và Internet vào
lĩnh vực tìm kiếm, tổ chức và xử lý thông tin phục vụ công tác ñiều hành và quản lý
sản xuất. Với cơ sở hạ tầng công nghệ thông tin ngày càng phát triển mở rộng, các tổ
chức, doanh nghiệp ngày càng có nhu cầu tin học hoá mọi lĩnh vực công việc, sản
xuất, quản lý,… và mong muốn mọi thông tin quản lý ñiều hành sản xuất ñều ñược lưu
trữ trên máy tính một cách tập trung ñể có thể tra cứu tìm kiếm dễ dàng và nhanh
chóng mỗi khi có nhu cầu.
Hiện nay hầu hết các doanh nghiệp ñã ứng dụng CNTT trong việc quản lý ñiều
hành doanh nghiệp của mình. Tuy nhiên, qua khảo sát thực tế cho thấy, hầu hết các hệ
thống phần mềm của các doanh nghiệp ñang hoạt ñộng khá ñộc lập, hầu như không
liên kết ñược với nhau hoặc nếu có thì liên kế với nhau một cách rất hạn chế. Chính vì
việc liên kết các hệ thống phần mềm khác nhau trong một doanh nghiệp thành một hệ
thống tập trung, quản lý tổng thể và chia sẻ thông tin trong doanh nghiệp một cách
ñồng nhất, trong suốt là một nhu cầu hết sức cấp thiết.
Từ nhu cầu thực tiễn xã hội và ñặc biệt là của ñơn vị ñang công tác, cùng với cơ
sở khoa học của việc nghiên cứu ứng dụng các mô hình sử dụng lại vào quá trình phân

tích thiết kế phần mềm, luận văn ñã chọn ñề tài với tên gọi “Nghiên cứu các mẫu thiết
kế và ứng dụng ñể xây dựng Hệ thống Quản lý thông tin tổng thể doanh nghiệp”.
Mục tiêu của bài toán “Xây dựng Hệ thống Quản lý thông tin tổng thể cho doanh
nghiệp” là xây dựng một hệ thống quản lý thông tin bao gồm nhiều Phân hệ. Mỗi một
Phân hệ giải quyết ñược chọn vẹn một hay một số yêu cầu của bài toán nghiệp vụ-
quản lý thông tin của doanh nghiệp.
Hệ thống ñược xây dựng sử dụng các công nghệ kỹ thuật mới như: ứng dụng
hướng tiếp cận áp dụng các mẫu thiết kế, sử dụng công cụ mô hình hoá UML ñể phân
tích và thiết kế bài toán theo mô hình hướng ñối tượng; ứng dụng công nghệ ứng dụng
- 11 -

chủ-khách (COM+) ñể cập nhật và xử lý thông tin. ðồng thời hệ thống cũng ñược thiết
kế ñể có thể chạy ñược cả trên nền Web lẫn desktop application.
Với hướng tiếp cận phân tích và thiết kế hệ thống áp dụng công nghệ hướng ñối
tượng sử dụng các mẫu thiết kế, và sử dụng công nghệ .NET của Microsoft ñể xây
dựng và phát triển hệ thống, cho phép hệ thống dễ bảo trì và phát triển mở rộng trong
tương lai ñáp ứng ñược các yêu cầu thay ñổi và phát triển ngày càng cao của xã hội.
Hệ thống ñược xây dựng hoàn toàn khả thi khi ñược áp dụng vào các tổ chức và doanh
nghiệp có kết nối mạng máy tính.
2. Mục tiêu và phạm vi nghiên cứu của luận văn
– Nghiên cứu các mô hình sử dụng lại và nắm bắt ñược mục tiêu, ý nghĩa và
cách thức, tình huống áp dụng các mô hình sử dụng lại vào giải quyết các vấn
ñề cụ thể. Qua ñó, tổng hợp lại một số mẫu ñiển hình về hành vi và trình diễn,
và một số mẫu tiêu biểu ứng dụng trong các hệ thống quản lý doanh nghiệp.
– Nắm bắt ñược phương pháp phân tích thiết kế hướng ñối tượng một hệ thống.
Sử dụng phương pháp phân tích thiết kế hướng ñối tượng, áp dụng các mẫu
thiết kế ñể phân tích, thiết kế hệ thống quản lý thông tin tổng thể cho các
doanh nghiệp.
– Từ kết quả phân tích và thiết kế tiến hành xây dựng hệ thống dựa trên các
công cụ và môi trường ñã lựa chọn.

– Thực hiện triển khai và áp dụng hệ thống tại một ñơn vị.
3. Nội dung nghiên cứu và thực hiện của luận văn
– Tổng quan về phát triển phần mềm và sử dụng lại
– Nghiên cứu một số mẫu ñiển hình về hành vi và trình diễn cũng như các mẫu
ñiển hình của các ứng dụng doanh nghiệp.
– Tổng quan về hệ thống hoạch ñịnh nguồn lực doanh nghiệp ERP.
– Vận dụng mẫu thiết kế cũng như lý thuyết về ERP ñể tiến hành phân tích và
thiết kế Hệ thống quản lý thông tin tổng thể cho doanh nghiệp.
– Xây dựng chương trình và tiến hành cài ñặt thử nghiệm.



- 12 -

4. Tóm tắt cấu trúc của luận văn
Luận văn bao gồm các phần sau:
MỞ ðẦU: Giới thiệu lý do chọn ñề tài luận văn, nhu cầu thực tiễn và khả năng
ứng dụng của luận văn.
CHƯƠNG 1: Tổng quan về mô hình sử dụng lại.
Chương này giới thiệu tổng quan về phần mềm sử dụng lại, giới thiệu tổng quan
về các mẫu thiết kế, giới thiệu chi tiết một số mẫu thiết kế ñiển hình về hành vi và
trình diễn hay ñược dùng trong các ứng dụng doanh nghiệp.
CHƯƠNG 2: Tổng quan về Hệ thống Hoạch ñịnh nguồn lực doanh nghiệp ERP.
Chương này giới thiệu tổng quan về hệ thống ERP, lịch sử hình thành cũng như
xu hướng phát triển, tiến hóa của ERP. Qua ñó ñưa ra ñược những khái niệm cũng như
cái nhìn tổng thể về hệ thống quản lý thông tin tổng thể của doanh nghiệp, phục vụ cho
việc phân tích, thiết kế hệ thống quản lý thông tin tổng thể ở chương 3.
CHƯƠNG 3: Ứng dụng các mẫu thiết kế ñể xây dựng các Phân hệ của hệ thống
Quản lý thông tin tổng thể doanh nghiệp.
Chương này mô tả việc cận dụng các mẫu thiết kế ñể phân tích, thiết kế và xây

dựng một số Phân hệ trong hệ thống Quản lý thông tin tổng thể cho doanh nghiệp.
CHƯƠNG 4: Cài ñặt
Chương này nêu các yêu cầu và môi trường cài ñặt, triển khai hệ thống. Giới
thiệu một số chức năng chính và ñưa ra một số màn hình nhập liệu, báo cáo của
chương trình. Khả năng triển khai áp dụng chương trình trong thực tiễn.
KẾT LUẬN: Phần này nêu kết quả ñạt ñược của luận văn và ñề xuất phương
hướng nâng cấp và mở rộng ứng dụng ñề tài vào thực tiễn trong tương lai.
CHƯƠNG 1
TỔNG QUAN VỀ MÔ HÌNH SỬ DỤNG LẠI
1.1. Giới thiệu chung
Thiết kế phần mềm là một công ñoạn quan trọng trong quy trình xây dựng và
phát triển phần mềm. Cũng như việc thiết kế phần mềm truyền thống, việc thiết kế
phần mềm hướng ñối tượng cần phải ñáp ứng ñược yêu cầu của bài toán, song cũng
cần có tính tổng quát và linh hoạt ñủ ñể có thể giải quyết một phần hoặc toàn bộ các
bài toán có thể gặp trong tương lai.
Trong quá trình xây dựng và phát triển phần mềm, các thay ñổi do yêu cầu từ
phía khách hàng, các ñiều kiện phát sinh hay việc thiết kế một cách cứng nhắc trong
quá trình thiết kế thường làm cho hệ thống trở nên rối rắm, các mô ñun càng ngày càng
bị phụ thuộc vào nhau. Sự phụ thuộc này làm cho phần mềm ngày càng trở nên phình
to và khó bảo trì, thậm chí dẫn ñến thất bại.
Phương pháp lập trình hướng ñối tượng ra ñời góp phần giúp cho việc thiết kế
phần mềm trở nên dễ dàng và linh ñộng hơn. Thiết kế hướng ñối tượng cho phép theo
dõi và quản lý ñược sự phụ thuộc giữa các mô ñun trong kiến trúc của hệ thống.
Việc tìm cách áp dụng những mô hình ñã thành công trong thực tế ñối với một số
bài toán tương tự ñã từng gặp và áp dụng những mô hình ñó vào thiết kế của mình mà
không cần phải xem xét lại từ ñầu, ñảm bảo tiết kiệm chí phí, thời gian xây dựng và
phát triển phần mềm, nâng cao ñộ tinh cậy và chất lượng phần mềm.
Năm 1995, Erich Gamma, Richard Helm, Join Vlissides, và Ralph Johnson
(Gang of Four - GOF) ñã công bố cuốn sách của họ “Elements of reusable Object-
Oriented Software” ñánh dấu sự ra ñời của “Mẫu thiết kế”. ðây là một bước tiến vô

cùng quan trọng ñối với việc thiết kế phần mềm hướng ñối tượng.
1.2. Tổng quan về các mẫu thiết kế
1.2.1. Mẫu thiết kế là gì ?
1.2.1.1. Các ñịnh nghĩa về mẫu thiết kế [4,9]
 Mẫu thiết kế (Design Pattern) là một cặp giải pháp/vấn ñề ñược ñặt tên có thể áp
dụng trong những ngữ cảnh mới và những hướng dẫn ñể áp dụng nó trong
những tình huống mới như thế nào. [3]
 Mẫu thiết kế không ñơn thuần là một bước nào ñó trong các giai ñoạn phát triển
phần mềm mà nó ñóng vai trò là sáng kiến ñể giải quyết một bài toán thông
- 14 -

dụng nào ñó. Các giai ñoạn phần mềm vẫn hoàn chỉnh mà không có mẫu thiết
kế, nhưng sự góp mặt của mẫu thiết kế sẽ giúp cho việc xác ñịnh bài toán cần
giải quyết nhanh gọn hơn, từ ñó ñưa ra cách giải quyết hợp lý. [9]
 Mẫu thiết kế không chỉ ñược sử dụng ñể xác ñịnh bài toán và cách giải quyết mà
còn ñược sử dụng nhằm cô lập các thay ñổi trong mã nguồn, từ ñó làm cho hệ
thống có khả năng tái sử dụng cao do mẫu thiết kế tuân thủ rất nghiêm ngặt các
nguyên lý thiết kế hướng ñối tượng. [9]
Việc xác ñịnh thế nào là một mẫu thiết kế phụ thuộc vào các nhìn nhận vấn ñề
của mỗi người. Theo GOF, cách nhìn nhận phổ biến nhất về các mẫu thiết kế là coi
chúng giống như các mô tả về các ñối tượng phục vụ mục ñích trao ñổi thông tin trong
quá trình thiết kế ñã ñược hiệu chỉnh ñể giải quyết những yêu cầu thiết kế trong những
trường hợp nhất ñịnh.
1.2.1.2. Các thành phần của mẫu thiết kế [8,9]
Mỗi mẫu thiết kế trước tiên mô tả một bài toán mà ta gặp nhiều lần rồi mô tả
những yếu tố căn bản nhất ñể giải quyết bài toán theo cách mà ta có thể áp dụng lại
nhiều lần. Dựa trên mô tả như trên về các mẫu thiết kế, ta thấy chúng bao gồm những
thành phần cơ bản sau:
 Tên: Là tên gọi qua ñó ta có thể mô tả bài toán cần giải quyết, giải pháp thực
hiện hay kết quả. Việc ñặt tên mẫu thiết kế cho phép mô tả các bài toán và giải

pháp một cách ngắn gọn. Tạo thành một ngôn ngữ trong cộng ñồng những người
thiết kế. Ví dụ, khi nói ñến mẫu thiết kế “Façade”, ta hình dung ngay ñến mô
hình thiết kế một ñối tượng với vai trò giao dịch của một tập các thành phần nhỏ
hơn.
 Bài toán: Cho phép xác ñịnh trong trường hợp nào thì áp dụng mẫu thiết kế
thông qua mô tả bài toán và ngữ cảnh của bài toán ñó.
 Giải pháp giải quyết bài toán: Mô tả những thành phần tạo nên mẫu thiết kế
(các lớp, các ñối tượng) cùng mối quan hệ, vai trò và cách thức phối hợp giữa
chúng (cấu trúc, thừa kế). Giải pháp không ñề cập ñến cách thức thiết kế hay
thực hiện cụ thể nào vì nó ñược áp dụng trong rất nhiều tình huống khác nhau.
Thay vào ñó, giải pháp của mẫu thiết kế ñược mô tả với tính khái quát cao với
cách thức tổ chức chung nhất của các thành phần trong việc giải quyết bài toán.
- 15 -

Ví dụ như mẫu thiết kế ñược gọi như một thành ngữ (mẫu GRASP), mẫu thiết kế
có thể mô tả bằng lời hoặc mô hình thiết kế hay bằng mã nguồn.
 Hệ quả: Là những gì thu nhận ñược cùng với những yếu tố cần cân nhắc khi áp
dụng mẫu thiết kế ñể giải quyết bài toán. Hệ quả thường không ñược ñề cập khi
nói ñến một mẫu thiết kế nhưng ñây là yếu tố quyết ñịnh khi cần chọn lựa hoặc
phân tích chi phí và lợi ích khi áp dụng các mẫu thiết kế.
1.2.2. Danh mục các mẫu thiết kế và phân loại [9]
Erich Gamma và các ñồng sự của ông ñề xuất 23 mẫu thiết kế, và ñã ñưa ra hai
tiêu chí ñể phân loại các mẫu thiết kế này. ðó là phân loại theo mục ñích sử dụng
(purpose) và phạm vi áp dụng của mẫu (scope).
a. Theo mục ñích sử dụng: Các mẫu thiết kế ñược phân thành 3 nhóm: mẫu
kiến tạo, mẫu cấu trúc, mẫu hành vi.
 Mẫu kiến tạo (Creational Patterns): mẫu kiến tạo trừu tượng hoá quá trình khởi
tạo ñối tượng. Các mẫu này giúp hệ thống không phải phụ thuộc vào cách một
ñối tượng ñược tạo ra, xây dựng và thể hiện.
 Mẫu thiết kế kiến tạo bao gồm các mẫu sau: Abstract Factory, Builder, Factory

Method, Prototype, Singleton.
 Mẫu cấu trúc (Structural Patterns): mẫu thiết kế cấu trúc ñề cập ñến cách mà các
ñối tượng và lớp ñối tượng kết hợp ñể tạo nên một cấu trúc lớn hơn và hữu dụng
hơn. Việc thiết kế các lớp ñối tượng là nhằm ñáp ứng các ràng buộc cụ thể của
hệ thống. Mẫu cấu trúc mô tả mối quan hệ giữa các lớp này và sắp xếp sao cho
nếu có bất kì sự thay ñổi nào với hệ thống ñều không làm thay ñổi những quan
hệ ñó.
Mẫu thiết kế cấu trúc bao gồm các mẫu sau: Adapter, Bridge, Composite, Decorator,
Facade, Flyweight, Proxy.
 Mẫu hành vi (Behavioral Patterns): mẫu hành vi mô tả sự tương tác giữa các ñối
tượng và cách chúng phân phối, cộng tác, ñể giải quyết một hay một nhóm trách
nhiệm nào ñó.
Mẫu hành vi bao gồm các mẫu sau: Chain of Responsibility, Command, Interpreter,
Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.
- 16 -

b. Theo phạm vi sử dụng: các mẫu thiết kế ñược phân thành 2 nhóm:
Phạm vi ñược nói ñến khi ta quyết ñịnh nên áp dụng mẫu thiết kế vào các lớp hay
các ñối tượng.
 Mẫu thiết kế áp dụng cho Lớp (Class): các mẫu này mô tả và giải quyết mối
quan hệ giữa các lớp ñối tượng và lớp con của chúng. Các mối quan hệ này ñược
thiết lập qua cơ chế kế thừa và chỉ xảy ra ở thời ñiểm biên dịch chương trình
(compiler-time).
Các mẫu thuộc loại này bao gồm: Factory Method, Adapter (class), Interpreter,
Template Method.
 Mẫu thiết kế áp dụng cho ðối tượng (Object): các mẫu này mô tả và giải quyết
mối quan hệ giữa các ñối tượng. Các mối quan hệ này có thể thay ñổi tại thời
ñiểm chạy chương trình (run-time).
Các mẫu thuộc loại này bao gồm: Abstract Factory, Builder, Prototype, Singleton,
Adapter (object), Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Chain of

Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor.














- 17 -

1.2.3. Sơ ñồ mối quan hệ giữa các mẫu thiết kế [9]

Hình 1.1: Sơ ñồ mối quan hệ giữa các mẫu thiết kế
1.3. Một số mẫu thiết kế ñiển hình trong các ứng dụng quản lý.
Với phạm vi thực hiện của luận văn, phần này chỉ tổng hợp và giới thiệu một số
mẫu thiết kế ñiển hình về hành vi và trình diễn hay ñược dùng trong các ứng dụng
quản lý doanh nghiệp như là các mẫu thiết kế dành cho lý luận nghiệp vụ (domain
logic) hoặc các mẫu về hành vi quan hệ của các ñối tượng hoặc cấu trúc quan hệ của
các ñối tượng.
- 18 -

1.3.1. Mẫu Quan sát
1.3.1.1. Ý nghĩa

Mẫu quan sát (Observer) ñịnh nghĩa mối quan hệ phụ thuộc một - nhiều giữa các
ñối tượng sao cho khi một ñối tượng thay ñổi trạng thái thì tất cả các ñối tượng liên
quan cũng sẽ ñược thông báo và tự ñộng cập nhật theo.
1.3.1.2. Mô tả
Việc phân chia hệ thống thành nhiều lớp con có quan hệ với nhau là nhu cầu tất
yếu ñể có thể duy trì sự bền vững của hệ thống. Chúng ta không bao giờ muốn cài ñặt
hệ thống mà tất cả các lớp dính chặt lại với nhau, bởi vì ñiều này sẽ làm giảm tính tái
sử dụng lại của chúng.
Ví dụ, nhiều công cụ giao diện ñồ hoạ phân tách giao diện (GUI) ra khỏi dữ liệu
(Data) bên dưới. Các lớp ñịnh nghĩa cho giao diện và dữ liệu trên có thể kết hợp với
nhau ñể làm việc cũng như có thể ñược sử dụng 1 cách ñộc lập.
Mẫu Observer mô tả cách thiết lập mối quan hệ này. Có hai ñối tượng then chốt
trong mẫu này, ñó là Subject và Observer. Một ñối tượng Subject có thể có một hoặc
nhiều ñối tượng Observer phụ thuộc vào nó. Tất cả các ñối tượng Observer sẽ ñược
cảnh báo (notify) khi ñối tượng Subject có sự thay ñổi về trạng thái. Khi ñó, các ñối
tượng Observer sẽ lấy thông tin về trạng thái của ñối tượng Subject ñể tự cập nhật lại
trạng thái của chính nó.
1.3.1.3. Cấu trúc mẫu Observer

Hình 1.2: Cấu trúc mẫu Observer
Ở cấu trúc trên, khi khởi tạo một ñối tượng thuộc lớp ConcreteObserver thì sự
khởi tạo này phải dựa trên ñối tượng thuộc lớp ConcreteSubject ñể lấy thông tin trạng
thái hiện tại của ñối tượng Subject. ðặc ñiểm của mẫu này là sự ánh xạ qua lại giữa
- 19 -

ñối tượng thuộc lớp Subject và các ñối tượng thuộc lớp Observer. ðối tượng
ConcreteObserver sẽ giữ con trỏ của ñối tượng ConcreteSubject. Ngược lại, lớp cha của
lớp ConcreteSubject (lớp Subject) sẽ giữ một mảng các con trỏ ñến lớp Observer (lớp cha
của lớp ConcreteObserver).
1.3.1.4. Biểu ñồ cộng tác

ðối tượng ConcreteSubject sẽ gửi thông báo tới các ñối tượng Observer của nó bất
cứ khi nào có sự thay ñổi trạng thái của các ñối tượng Observer.
Sau khi xác nhận sự thay ñổi trong ñối tượng ConcreteSubject, ñối tượng
ConcreteObserver có thể truy vấn thông tin của các ñối tượng Observer. ðối tượng
ConcreteObserver sử dụng thông tin này ñể ñồng bộ trạng thái của nó với các ñối tượng
Observer ñó.

Hình 1.3: Biểu ñồ cộng tác của mẫu Observer
1.3.1.5. Các tình huống áp dụng
Mẫu Observer thường ñược áp dụng khi: Ứng dụng có mối quan hệ phụ thuộc,
ñối tượng này phụ thuộc vào ñối tượng kia. Hoặc khi một sự thay ñổi ở ñối tượng này
dẫn ñến sự thay ñổi ở ñối tượng khác và chúng ta không biết chính xác có bao nhiêu
ñối tượng phải thay ñổi theo
1.3.1.6. Thuận lợi và hạn chế
Mẫu Observer giúp chúng ta sử dụng các ñối tượng chủ thể (Subject) và các ñối
tượng phụ thuộc vào trạng thái của nó (Observer) một cách ñộc lập.
Chúng ta có thể sử dụng lại những ñối tượng chủ thể Subject mà không phải sử
dụng lại các ñối tượng phụ thuộc trạng thái Observer của nó và ngược lại.
- 20 -

Chúng ta có thể thêm vào một hoặc nhiều ñối tượng phụ thuộc trạng thái
(Observer) mà không phải sửa ñổi lại ñối tượng chủ thể Subject hoặc các ñối tượng
Observer phụ thuộc trạng thái khác.
1.3.2. Mẫu Thực hiện lệnh
1.3.2.1. Ý nghĩa
Mẫu Thực hiện lệnh (Command) dùng ñể ñóng gói các yêu cầu khác nhau thành
từng ñối tượng thực hiện lệnh riêng biệt, do ñó cho phép tham số hoá các tác vụ từ
client với ñối tượng thực hiện lệnh khác nhau, ñưa vào hàng ñợi hoặc tệp tin sổ ghi
(log file) các yêu cầu, hỗ trợ việc phục hồi các tác vụ ñã thực hiện.
1.3.2.2. Mô tả

Mẫu này tạo ra các lớp lệnh Command giúp cho việc gọi thực hiện sau này ñược
dễ dàng. Mỗi lớp Command ñược ñịnh nghĩa tương ứng với một hành ñộng (action) của
một ñối tượng nhận (receiver) nào ñó (còn gọi là một cặp action-receiver). Sau này, khi
muốn thực hiện lệnh nào, ta chỉ cần gọi thực hiện tương ứng với Command tương ứng.
1.3.2.3. Cấu trúc mẫu Command

Hình 1.4: Cấu trúc mẫu Command
Các thành phần tham gia vào cấu trúc Command:
 Command: ðịnh nghĩa giao tiếp cho việc xử lý một tác vụ.
 ConcreteCommand: ðịnh nghĩa kết nối giữa một ñối tượng nhận và một
tác vụ thực hiện.
 Client: Tạo một ñối tượng ConcreteCommand và ñặt các ñối tượng nhận cho
nó.
 Invoker: Duyệt các Command ñể ñưa ra các yêu cầu khi cần.
- 21 -

 Receiver: nhận biết khi nào cần thực hiện tác vụ tương ứng với các yêu cầu
ñược gửi tới.
1.3.2.4. Biểu ñồ cộng tác của các ñối tượng tham gia vào mẫu

Hình 1.5: Biểu ñồ cộng tác của mẫu Command
Client tạo các ñối tượng ConcreteCommand và xác ñịnh các ñối tượng nhận tương
ứng. ðối tượng Invoker lưu giữ các ñối tượng ConcreteCommand ñể có thể duyệt và ñưa
ra các yêu cầu khi cần.
1.3.2.5. Các tình huống áp dụng
Có thể ứng dụng mẫu Command ñể xây dựng một thực ñơn bằng cách tạo một tập
hợp các Command tương ứng với các yêu cầu thực hiện các mục chọn trên thực ñơn…
Sử dụng mẫu này, ta có thể xây dựng các chức năng Phục hồi (undo), Thực hiện
lại (Redo),… bằng cách lưu lại các lệnh ñã ñược thực hiện vào một danh sách (queue,
history list, log,…). Sau ñó, chỉ cần dựa theo danh sách này ñể Phục hồi hoặc Thực

hiện lại lệnh tương ứng. ðể làm ñược ñiều này, trong lớp ConcreteCommand (kế thừa từ
lớp Command) phải xây dựng sẵn chức năng Phục hồi của chính nó. Khi ñó, một tập
hợp các lệnh ñã ñược thực hiện sẽ ñược Phục hồi bằng chức năng Thực hiện lại của
từng lệnh chứa trong nó.
1.3.2.6. Thuận lợi và hạn chế
Có thể dễ dàng thêm mới một Lệnh bởi vì chúng ta không phải sửa lại những lớp
cũ. Có thể tập hợp các Lệnh khác nhau lại thành một Lệnh tổng hợp.
Các ñối tượng Command có thể ñược xử lý và kế thừa giống như các ñối tượng
khác


- 22 -

1.3.3. Mẫu Trạng thái
1.3.3.2. Ý nghĩa
Mẫu Trạng thái (State) cho phép ñối tượng có thể tự ñiều chỉnh hành vi khi trạng
thái của nó thay ñổi (hành vi của ñối tượng phụ thuộc vào trạng thái của nó).
1.3.3.2. Mô tả
Mẫu này dùng ñể mô tả làm thế nào ñối tượng có thể tự ñưa ra các ứng xử khác
nhau tương ứng với mỗi trạng thái vào thời ñiểm chạy.
Mẫu này ñưa ra một lớp trừu tượng (Abstract) ñại diện cho các trạng thái của ñối
tượng trong ngữ cảnh hiện tại (Context), ở ñây ta gọi là lớp State. Lớp này cung cấp
giao diện chung cho tất cả các lớp ñại diện các trạng thái khác nhau của ngữ cảnh
Context. Các lớp con, kế thừa từ lớp State này (ConcreteStateA, ConcreteStateB, …), sẽ
cung cấp chi tiết các ứng xử tương ứng với trạng thái của nó. ðối tượng State có thể
truy xuất ñối tượng Context khi cần thiết ñể nắm giữ các yêu cầu của ñối tượng Context
.
Lớp Context sẽ giữ một biến ñối tượng trạng thái (một lớp con của lớp State sẽ
lưu giữ trạng thái hiện hành). Lớp Context sẽ uỷ nhiệm tất cả các lời gọi trạng thái ñến
cho biến ñối tượng này.

1.3.3.3. Cấu trúc mẫu State

Hình 1.6: Cấu trúc mẫu State
Các thành phần tham gia vào cấu trúc State:
 Context: Chứa các yêu cầu, các phương thức từ phía Client. Lưu giữ một thể
hiện (instance) của trạng thái hiện hành (thuộc lớp ConcreteState).
 State: Chứa các ứng xử có liên quan ñến các trạng thái của ñối tượng
Context.
 ConcreteState: các lớp con cài ñặt các ứng xử tương ứng với các trạng thái
của ñối tượng Context trên.
- 23 -

1.3.3.4. Các tình huống áp dụng
Ứng xử của một ñối tượng phụ thuộc vào trạng thái của ñối tượng ñó, ứng xử của
nó có thể thay ñổi vào thời ñiểm chạy và phụ thuộc vào trạng thái lúc ñó.
Sự ñiều khiển có thể quá lớn và các nhánh trong cùng một cấu trúc ñiều kiện
If-else phụ thuộc vào các trạng thái khác nhau của ñối tượng. Mẫu này sẽ tách mỗi
nhánh của cấu trúc ñiều kiện trên thành một lớp riêng biệt, do ñó có thể xử lý các trạng
thái của ñối tượng một cách ñộc lập, không phụ thuộc nhiều vào các ñối tượng khác.
1.3.3.5. Thuận lợi và hạn chế
Những ñối tượng State có thể ñược chia sẻ. Hệ thống sử dụng các ñối tượng state
chia sẽ nhằm làm tăng tính linh hoạt và dễ nâng cấp, thay ñổi sau này.
Sử dụng mẫu này làm cho các sự chuyển ñổi trạng thái trong hệ thống ñược rõ
ràng.
1.3.4. Mẫu Phương thức tiêu bản
1.3.4.1. Ý nghĩa
Mỗi thuật toán bao gồm một tập các hành ñộng theo một thứ tự xác ñịnh và mỗi
hành ñộng sẽ ñược cài ñặt khác nhau tuỳ thuộc vào các thể hiện khác nhau của ñối
tượng. Mẫu Phương thức tiêu bản (Template Method) giúp chúng ta ñịnh nghĩa thứ tự
các hành ñộng này và cho phép các lớp con của nó ñịnh nghĩa lại các hành ñộng tuỳ

thuộc vào ngữ cảnh cụ thể.
1.3.4.2. Cấu trúc mẫu

Hình 1.7: Cấu trúc mẫu Template Method


- 24 -

Các thành phần tham gia vào cấu trúc mẫu Template Method:
 Lớp AbstractClass là lớp trừu tượng ñịnh nghĩa khung của thuật toán trong
phương thức mẫu (Template Method).
 Lớp ConcreteClass cài ñặt cách thực hiện các hành vi cụ thể
(PrimitiveOperation). Trong phương thức mẫu, các hành vi cụ thể sẽ ñược
thực hiện theo một thứ tự nhất ñịnh. Mỗi lớp con có một cách cài ñặt cách
thực hiện các hành vi cụ thể này khác nhau.
1.3.4.3. Các tình huống áp dụng
Sử dụng mẫu Template Method khi cần ñịnh nghĩa thứ tự của một thuật toán và
chuyển cho các lớp con thực thi những hành vi cụ thể của thuật toán. Lớp cha sẽ cài
ñặt các hành vi chung, các lớp con sẽ kế thừa và sử dụng lại các phương thức này và
chỉ cần cài ñặt lại các hành vi riêng của nó.
1.3.4.4. Thuận lợi và hạn chế
Sử dụng mẫu này, các phương thức chung ñược cài ñặt ở lớp cha, các lớp con chỉ
cần kế thừa và sử dụng mà không cần cài ñặt lại. ðiều này giúp tránh ñược sự trùng
lắp mã chương trình.
Mẫu này thường ñược sử dụng trong các lớp thư viện dùng ñể gọi các hàm hook.
ðây là những hàm có sẵn trong các thư viện cho phép người dùng kế thừa và cài ñặt
lại.
1.3.5. Mẫu Chuỗi các trách nhiệm
1.3.5.1. Ý nghĩa
Mẫu Chuỗi các trách nhiệm cho phép ñối tượng gửi yêu cầu (Sender), có thể

không cần biết ñến ñối tượng sẽ nhận yêu cầu ñó (Receiver), bằng cách thêm vào các
ñối tượng một phương thức ñể có thể nắm giữ yêu cầu. Các ñối tượng sẽ ñược tổ chức
thành một chuỗi mắt xích, yêu cầu ñược gửi sẽ ñược duyệt theo chuỗi mắt xích này
cho ñến khi có một ñối tượng trong mắt xích nhận lấy yêu cầu của nó.
1.3.5.2. Mô tả
Mẫu này tổ chức hệ thống các ñối tượng thành một chuỗi mắt xích từ cụ thể ñến
tổng quát. Mỗi ñối tượng trong mắt xích này sẽ ñược cung cấp một phương thức ñể có
thể nắm giữ và xử lý yêu cầu. Yêu cầu sẽ ñược trượt qua chuỗi mắt xích này theo thứ
tự, từng ñối tượng trong mắt xích sẽ ñược nhận yêu cầu. Nếu ñúng là yêu cầu dành cho
nó thì nó sẽ xử lý, nếu không yêu cầu sẽ tiếp tục gửi ñi cho các mắt xích ñằng sau nó.