Vận dụng công nghệ hướng đối tượng sử dụng mẫu thiết kế để phát triển ứng dụng Tổ chức và quản lý hoạt động giao công việc

-1-
MỤC LỤC
MỤC LỤC 1
DANH MỤC CÁC HÌNH VẼ VÀ ĐỒ THỊ 4
DANH MỤC CÁC BẢNG 7
MỞ ĐẦU 8
1. Cơ sở khoa học và thực tiễn của đề tài: 8
2. Mục tiêu và phạm vi nghiên cứu của luận văn 10
3. Nội dung nghiên cứu và thực hiện của luận văn 10
4. Tóm tắt cấu trúc của luận văn 10
CHƢƠNG 1. TỔNG QUAN VỀ MÔ HÌNH SỬ DỤNG LẠI 12
1.1. Giới thiệu chung 12
1.2. Tổng quan về các mẫu thiết kế (Design Pattern) 12
1.2.1. Mẫu thiết kế là gì ? 12
1.2.1.1. Các định nghĩa về mẫu thiết kế [4,9] 12
1.2.1.2. Các thành phần của mẫu thiết kế [8,9] 13
1.2.2. Danh mục các mẫu thiết kế và phân loại [9] 14
1.2.3. Sơ đồ mối quan hệ giữa các mẫu thiết kế [9] 15
1.3. 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 [8,9,10] 16
1.3.1. Mẫu Observer (mẫu quan sát) 16
1.3.2. Mẫu Command (mẫu thực hiện lệnh) 18
1.3.3. Mẫu State (mẫu trạng thái) 20
1.3.4. Mẫu Template Method (phƣơng thức tiêu bản) 22
1.3.5. Mẫu Chain of Responsibility (chuỗi các trách nhiệm) 23
1.3.6. Mẫu Interpreter (mẫu phiên dịch) 25
1.3.7. Mẫu Interator (mẫu lặp) 26
1.3.8. Mẫu Mediator (mẫu trung gian) 27
1.3.9. Mẫu Memento (mẫu lƣu giữ) 29
1.3.10. Mẫu Strategy (mẫu chiến lƣợc) 31

1.3.11. Mẫu Visitor (mẫu kiểm tra) 32
CHƢƠNG 2. VẬN DỤNG MẪU THIẾT KẾ HÀNH VI TIẾN HÀNH PHÂN TÍCH
THIẾT KẾ VÀ XÂY DỰNG HỆ THỐNG “TỔ CHỨC VÀ QUẢN LÝ HOẠT ĐỘNG
GIAO CÔNG VIỆC” 36
2.1. Nắm bắt yêu cầu bài toán 36
2.1.1. Bài toán đặt ra 36


-2-
2.1.2. Phạm vi bài toán 36
2.1.3. Mô tả nghiệp vụ quản lý 37
2.1.3.1. Xác định các thông tin chung về quản lý công việc 37
2.1.3.2. Công tác quản lý hoạt động giao công việc 38
2.1.3.3. Sơ đồ tiến trình quản lý hoạt động giao công việc 39
2.1.3.4. Các yêu cầu xây dựng hệ thống quản lý hoạt động giao công việc . 39
2.1.3.5. Các chức năng hệ thống 40
2.1.4. Từ điển dữ liệu và mô hình lĩnh vực nghiệp vụ 41
2.1.4.1. Các khái niệm dự tuyển cho nghiệp vụ quản lý giao việc 41
2.1.4.2. Mô hình lĩnh vực nghiệp vụ 41
2.2. Đặc tả hệ thống 42
2.2.1 Các tác nhân (Actor) trong hệ thống 42
2.2.2. Các ca sử dụng (Usecase) của hệ thống 44
2.2.2.1. Ca sử dụng Đăng nhập hệ thống 44
2.2.2.2. Ca sử dụng Tạo công việc mới 44
2.2.2.3. Ca sử dụng Sửa thông tin hồ sơ công việc 45
2.2.2.4. Ca sử dụng Xoá hồ sơ công việc 45
2.2.2.5. Ca sử dụng Phân giải quyết công việc 45
2.2.2.6. Ca sử dụng Chỉ đạo giải quyết công việc 46
2.2.2.7. Ca sử dụng sửa Chỉ đạo giải quyết công việc 46
2.2.2.8. Ca sử dụng Giải quyết công việc 46

2.2.2.9. Ca sử dụng Báo cáo thống kê 47
2.2.2.10. Ca sử dụng Xem và tra cứu công việc 47
2.2.2.11. Ca sử dụng Cập nhật danh mục từ điển 47
2.2.2.12. Ca sử dụng Cập nhật ngƣời dùng 48
2.2.2.13. Ca sử dụng Cập nhật nhóm quyền 48
2.2.2.14. Ca sử dụng Phân quyền truy nhập 48
2.2.3. Mô hình ca sử dụng tổng thể 49
2.2.3.1. Gói ca sử dụng Đăng nhập hệ thống 49
2.2.3.2. Gói ca sử dụng Quản lý giải quyết công việc 50
2.2.3.3. Gói ca sử dụng Quản trị tiện ích 51
2.2.3.4. Gói ca sử dụng Báo cáo thống kê 51
2.2.3.5. Gói ca sử dụng Quản trị phân quyền ngƣời dùng 51
2.2.4. Mô tả chi tiết các ca sử dụng 52
2.2.4.1. Gói ca sử dụng Đăng nhập hệ thống 52
2.2.4.2. Gói ca sử dụng Quản lý giải quyết công việc 53
2.2.4.3. Gói ca sử dụng Quản trị tiện ích 60


-3-
2.2.4.4. Gói ca sử dụng Báo cáo thống kê 63
2.2.4.5. Gói ca sử dụng Quản trị phân quyền ngƣời dùng 67
2.3. Phân tích hệ thống 69
2.3.1. Phân tích các ca sử dụng 69
2.3.1.1. Gói ca sử dụng Đăng nhập hệ thống 69
2.3.1.2. Gói ca sử dụng Quản lý giải quyết công việc 71
2.3.1.3. Gói ca sử dụng Quản trị tiện ích 79
2.3.1.4. Gói ca sử dụng Báo cáo thống kê 82
2.3.1.5. Gói ca sử dụng Quản trị phân quyền ngƣời dùng 86
2.3.2. Phân tích các lớp 89
2.3.2.1. Lớp biên 89

2.3.2.2. Lớp điều khiển 91
2.3.2.3. Lớp thực thể 94
2.4. Thiết kế hệ thống 96
2.4.1. Kiến trúc vật lý của ứng dụng 96
2.4.2. Xác định các gói thiết kế 96
2.4.3. Thiết kế cho từng ca sử dụng 97
2.4.3.1. Gói ca sử dụng Đăng nhập hệ thống 97
2.4.3.2. Gói ca sử dụng Quản lý giải quyết công việc 100
2.4.3.3. Gói ca sử dụng Quản trị tiện ích 114
2.4.3.4. Gói ca sử dụng phục vụ tra cứu, báo cáo, thống kê 116
2.4.3.5. Gói ca sử dụng Quản trị phân quyền ngƣời dùng 122
2.4.4. Thiết kế một số lớp 123
2.4.4.1. Lớp giao diện 123
2.4.4.2. Lớp điều khiển 125
2.4.4.3. Lớp thực thể 127
CHƢƠNG 3. CÀI ĐẶT VÀ TRIỂN KHAI HỆ THỐNG 135
3.1. Các yêu cầu cài đặt triển khai hệ thống 135
3.2. Giới thiệu chƣơng trình 136
3.2.1. Các mục tiêu mà hệ thống đạt đƣợc 136
3.2.2. Cấu trúc chƣơng trình 137
3.2.3. Các đối tƣợng sử dụng chƣơng trình 137
3.2.4. Giao diện một số chức năng chính 137
3.3. Khả năng triển khai áp dụng 142
KẾT LUẬN 143
1. Các kết quả đạt đƣợc 143


-4-
2. Những vấn đề tồn tại và hƣớng mở rộng và phát triển 143
TÀI LIỆU THAM KHẢO 145

Tài liệu tiếng Việt 145
Tài liệu tiếng Anh 145
Các trang Web 146
Bộ công cụ 146

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ế 16
Hình 1.2: Cấu trúc mẫu Observer 17
Hình 1.3: Biểu đồ cộng tác của mẫu Observer 18
Hình 1.4: Cấu trúc mẫu Command 19
Hình 1.5: Biểu đồ cộng tác của mẫu Command 20
Hình 1.6: Cấu trúc mẫu State 21
Hình 1.7: Cấu trúc mẫu Template Method 22
Hình 1.8: Cấu trúc mẫu Chain of Responsibility 24
Hình 1.9: Cấu trúc mẫu Interpreter 25
Hình 1.10: Cấu trúc mẫu Interator 26
Hình 1.11: Cấu trúc mẫu Mediator 28
Hình 1.12: Cấu trúc mẫu Memento 30
Hình 1.13: Biểu đồ cộng tác của mẫu Memento 30
Hình 1.14: Cấu trúc mẫu Strategy 31
Hình 1.15: Cấu trúc mẫu Visitor 33
Hình 1.16: Biểu đồ cộng tác của mẫu Visitor 34
Hình 2.1. Mô hình phân cấp quản lý trong doanh nghiệp 37
Hình 2.2: Sơ đồ tiến trình quản lý hoạt động giao công việc 39
Hình 2.3: Mô hình khái niệm hệ thống tổ chức và quản lý giao công việc 42
Hình 2.4: Gói ca sử dụng Đăng nhập hệ thống 49
Hình 2.5: Gói ca sử dụng Quản lý giải quyết công việc 50
Hình 2.6: Gói ca sử dụng Quản trị tiện ích 51
Hình 2.7: Gói ca sử dụng Báo cáo thống kê 51

-5-
Hình 2.8: Gói ca sử dụng Quản trị phân quyền ngƣời dùng 52
Hình 2.9: Các lớp phân tích thực thi ca sử dụng Đăng nhập 70
Hình 2.10: Biểu đồ cộng tác ca sử dụng Đăng nhập 70
Hình 2.11: Các lớp phân tích thực thi ca sử dụng Đổi mật khẩu 71
Hình 2.12: Biểu đồ cộng tác ca sử dụng Đổi mật khẩu 71
Hình 2.13: Các lớp phân tích thực thi ca sử dụng Tạo công việc mới 72
Hình 2.14: Biểu đồ cộng tác ca sử dụng Tạo công việc mới 72
Hình 2.15: Các lớp phân tích thực thi ca sử dụng Sửa nội dung công việc 73
Hình 2.16: Biểu đồ cộng tác ca sử dụng Sửa nội dung công việc 73
Hình 2.17: Các lớp phân tích thực thi ca sử dụng Xoá công việc 74
Hình 2.18: Biểu đồ cộng tác ca sử dụng Xoá công việc 74
Hình 2.19: Các lớp phân tích thực thi ca sử dụng Phân công việc 75
Hình 2.20: Biểu đồ cộng tác ca sử dụng Phân công việc 76
Hình 2.21: Các lớp phân tích thực thi ca sử dụng Chỉ đạo giải quyết công việc 77
Hình 2.22: Biểu đồ cộng tác ca sử dụng Chỉ đạo giải quyết công việc 77
Hình 2.23: Các lớp phân tích thực thi ca sử dụng Giải quyết công việc 78
Hình 2.24: Biểu đồ cộng tác ca sử dụng Giải quyết công việc 79
Hình 2.25: Các lớp phân tích thực thi ca sử dụng Cập nhật Phòng ban 79
Hình 2.26: Biểu đồ cộng tác ca sử dụng Cập nhật Phòng ban 80
Hình 2.27: Các lớp phân tích thực thi ca sử dụng Cập nhật Nhân viên 80
Hình 2.28: Biểu đồ cộng tác ca sử dụng Cập nhật Nhân viên 81
Hình 2.29: Các lớp phân tích thực thi ca sử dụng Cập nhật Loại công việc 81
Hình 2.30: Biểu đồ cộng tác ca sử dụng Cập nhật Loại công việc 82
Hình 2.31: Các lớp phân tích thực thi ca sử dụng Tra cứu công việc 83
Hình 2.32: Biểu đồ cộng tác ca sử dụng Tra cứu công việc 83
Hình 2.33: Các lớp phân tích thực thi ca sử dụng Báo cáo công việc 84
Hình 2.34: Biểu đồ cộng tác ca sử dụng Báo cáo công việc 85
Hình 2.35: Các lớp phân tích thực thi ca sử dụng Vẽ biểu đồ Gantt 86

Hình 2.36: Biểu đồ cộng tác ca sử dụng Vẽ biểu đồ Gantt 86
Hình 2.37: Các lớp phân tích thực thi ca sử dụng Cập nhật nhóm quyền 87
Hình 2.38: Biểu đồ cộng tác ca sử dụng Cập nhật nhóm quyền 87
Hình 2.39: Các lớp phân tích thực thi ca sử dụng Phân quyền ngƣời dùng 88


-6-
Hình 2.40: Biểu đồ cộng tác ca sử dụng Phân quyền ngƣời dùng 89
Hình 2.41: Kiến trúc vật lý của ứng dụng 96
Hình 2.42: Biểu đồ lớp thiết kế thực thi ca sử dụng Đăng nhập 97
Hình 2.43: Biểu đồ cộng tác ca sử dụng Đăng nhập 98
Hình 2.44: Biểu đồ lớp thiết kế ca sử dụng Đăng nhập áp dụng mẫu Singleton 99
Hình 2.45: Biểu đồ lớp thiết kế thực thi ca sử dụng Đổi mật khẩu 100
Hình 2.46: Biểu đồ cộng tác ca sử dụng Đổi mật khẩu 100
Hình 2.47: Biểu đồ lớp thiết kế thực thi ca sử dụng Tạo công việc mới 101
Hình 2.48: Biểu đồ cộng tác ca sử dụng Tạo công việc mới 101
Hình 2.49. Biểu đồ lớp thiết kế thực thi ca sử dụng Tạo công việc mới áp dụng mẫu
thiết kế Observer 103
Hình 2.50: Biểu đồ cộng tác ca sử dụng Tạo công việc mới áp dụng mẫu thiết kế
Observer 104
Hình 2.51: Biểu đồ lớp thiết kế thực thi ca sử dụng Sửa nội dung công việc 105
Hình 2.52: Biểu đồ cộng tác ca sử dụng Sửa nội dung công việc 106
Hình 2.53: Biểu đồ lớp thiết kế thực thi ca sử dụng Xoá công việc 106
Hình 2.54: Biểu đồ cộng tác ca sử dụng Xoá công việc 107
Hình 2.55: Biểu đồ lớp thiết kế thực thi ca sử dụng Phân công việc 107
Hình 2.56: Biểu đồ cộng tác ca sử dụng Phân công việc 108
Hình 2.57. Biểu đồ lớp thiết kế thực thi ca sử dụng Phân công việc áp dụng mẫu thiết
kế State 110
Hình 2.58: Biểu đồ cộng tác ca sử dụng Phân công việc áp dụng mẫu thiết kế State 111
Hình 2.59: Biểu đồ lớp thiết kế thực thi ca sử dụng Chỉ đạo công việc 112

Hình 2.60: Biểu đồ cộng tác ca sử dụng Chỉ đạo công việc 112
Hình 2.61: Biểu đồ lớp thiết kế thực thi ca sử dụng Giải quyết công việc 113
Hình 2.62: Biểu đồ cộng tác ca sử dụng Giải quyết công việc 114
Hình 2.63: Biểu đồ lớp thiết kế thực thi ca sử dụng Cập nhật Phòng ban 114
Hình 2.64: Biểu đồ cộng tác ca sử dụng Cập nhật Phòng ban 115
Hình 2.65: Biểu đồ lớp thiết kế thực thi ca sử dụng Cập nhật Nhân viên 115
Hình 2.66: Biểu đồ cộng tác ca sử dụng Cập nhật Nhân viên 116
Hình 2.67: Biểu đồ lớp thiết kế thực thi ca sử dụng Tra cứu công việc 116
Hình 2.68: Biểu đồ cộng tác ca sử dụng Tra cứu công việc 117


-7-
Hình 2.69: Biểu đồ lớp thiết kế thực thi ca sử dụng Báo cáo công việc 118
Hình 2.70: Biểu đồ cộng tác ca sử dụng Báo cáo công việc 118
Hình 2.71: Áp dụng mẫu thiết kế Composite vào lớp CongViec thực hiện tổng hợp,
báo cáo, hiển thị thông tin trong ca sử dụng Báo cáo công việc 120
Hình 2.72: Biểu đồ cộng tác ca sử dụng Báo cáo công việc áp dụng mẫu thiết kế
Composite vào lớp CongViec 120
Hình 2.73: Biểu đồ lớp thiết kế thực thi ca sử dụng Vẽ biểu đồ Gantt 121
Hình 2.74: Biểu đồ cộng tác ca sử dụng Vẽ biểu đồ Gantt 121
Hình 2.75: Biểu đồ lớp thiết kế thực thi ca sử dụng Cập nhật nhóm quyền 122
Hình 2.76: Biểu đồ cộng tác ca sử dụng Cập nhật nhóm quyền 122
Hình 2.77: Biểu đồ lớp thực thi ca sử dụng Phân quyền chức năng 123
Hình 2.78: Biểu đồ cộng tác ca sử dụng Phân quyền chức năng 123

DANH MỤC CÁC BẢNG
Bảng 2.1: Các chức năng hệ thống 41
Bảng 2.2: Các khái niệm dự tuyển cho nghiệp vụ quản lý giao việc 41
Bảng 2.3: Mô tả các tác nhân trong hệ thống 44

-8-
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
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ử


-9-
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
úng dụng “Tổ chức và quản lý hoạt động giao công việc”:
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 cu
̉
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 đa
̃

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 va
̀
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 để có thể tra cứu tìm kiếm dễ dàng và nhanh chóng mỗi khi có nhu
cầu.
Hoạt động giao việc và điều hành xử lý việc thực hiện công việc là một hoạt
động chủ đạo trong hầu hết các tổ chức, doanh nghiệp. Tuy nhiên, qua khảo sát thực tế
cho thấy, hiện nay việc tổ chức và quản lý hoạt động giao công việc trong các tổ chức,
xí nghiệp chủ yếu thực hiện trực tiếp bằng miệng và quản lý dựa trên trên giấy tờ. Do
đó, để tổ chức và theo dõi điều hành một công việc thực hiện qua nhiều ngƣời, nhiều
cấp, trên nhiều giai đoạn thời gian kha
́
c nhau gặp rất nhiều khó khăn . Việc tin học hoá
hoạt động này để có thể tổ chức xử lý, theo dõi hoạt động giao công việc trên hệ thống
máy tính là nhu cầu cấp thiết.
Việc ứng dụng công nghệ thông tin vào tổ chức, quản lý hoạt động giao công
việc là một trong các biện pháp có ý nghĩa thiết thực trong việc áp dụng các thành tựu
khoa học kỹ thuật vào công tác điều hành và quản lý sản xuất trong các doanh nghiệp.
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 “Vận dụng công nghệ
hướng đối tượng sử dụng mẫu thiết kế để phát triển ứng dụng „Tổ chức và quản lý
hoạt động giao công việc‟”.
Mục tiêu của bài toán “Xây dựng ứng dụng tổ chức và quản lý hoạt động giao
công việc” là xây dựng một hệ thống thông tin tổ chức và quản lý các hoạt động giao
công việc đang thực hiện trong một tổ chức, doanh nghiệp phân theo các cấp quản lý
theo từng đầu ngƣời cụ thể dựa trên mạng máy tính. Hệ thống giúp các cấp lãnh đạo


-10-
nắm sát tình hình thực hiện công việc và đƣa ra ý kiến chỉ đạo va

̀
hƣớng giải quyết
đúng đắn, kịp thời nhằm nâng cao hiệu quả quản lý. Hệ thống cung cấp các đầu mục
tra cứu và tổng hợp các công việc đã và đang thực hiện trên mạng máy tính để làm các
thống kê, báo cáo định kỳ theo yêu cầu.
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ệ web đê
̉

câ
̣
p nhâ
̣
t va
̀
xƣ
̉
ly
́
thông tin.
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ệ web để 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.
– 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ế về hành vi và trình diễn để phân tích, thiết kế một ứng dụng cụ thể
trên máy tính.
– 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
– Một số mẫu điển hình về hành vi và trình diễn
– Vận dụng mẫu thiết kế hành vi tiến hành phân tích và thiết kế ứng dụng ứng
dụng “Tổ chức và quản lý hoạt động giao công việc”
– Xây dựng chƣơng trình và tiến hành cài đặt thử nghiệm
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:


-11-
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.
CHƢƠNG 2: Vận dụng mẫu thiết kế hành vi tiến hành phân tích, thiết kế và xây dựng
hệ thống tổ chức và quản lý hoạt động giao công việc.
Chƣơng này chỉ ra các ca sử dụng, các tác nhân của hệ thống, các mô hình ca sử
dụng, mô tả và làm mịn dần bằng việc mô tả, phân tích từng ca sử dụng. Phần thiết kế
chỉ ra mô hình thiết kế một số ca sử dụng cơ bản.

CHƢƠNG 3: Cài đặt và triển khai hệ thống.
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.


-12-
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) đã 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ế (Design Pattern)
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ế 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. [4]
 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


-13-
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
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.


-14-
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.
b. Theo phạm vi sử dụng: các mẫu thiết kế đƣợc phân thành 2 nhóm:


-15-
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.
1.2.3. Sơ đồ mối quan hệ giữa các mẫu thiết kế [9]


-16-

Hình 1.1: Sơ đồ mối quan hệ giữa các mẫu thiết kế
1.3. 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
[8,9,10]
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ế về hành vi và trình diễn đƣợc ứng dụng nhiều trong phân tích và thiết kế
phần mềm, từ đó làm cơ sở để thực hiện áp dụng vào phân tích và thiết kế hệ thống ở
phần sau.
1.3.1. Mẫu Observer (mẫu quan sát)
1.3.1.1. Ý nghĩa


-17-
Đị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 Observers 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
đố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).


-18-
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
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
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 Observe 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.
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 Command (mẫu thực hiện lệnh)
1.3.2.1. Ý nghĩa


-19-
Mẫu này 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 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.
 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


-20-

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 (Redu),… 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 (command) 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
1.3.3. Mẫu State (mẫu trạng thái)
1.3.3.1. Ý nghĩa
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ả


-21-
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.
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


-22-
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 Template Method (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 này 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
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à


-23-
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 Chain of Responsibility (chuỗi các trách nhiệm)
1.3.5.1. Ý nghĩa
Mẫu này 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ó.
1.3.5.3. Cấu trúc mẫu

Có thể mô tả cấu trúc của mẫu theo cách sau:


-24-

Hình 1.8: Cấu trúc mẫu Chain of Responsibility
Các thành phần tham gia vào cấu trúc mẫu Chain of Responsibility:
 Handler: Định nghĩa một giao tiếp chung cho việc nắm giữ yêu cầu. Cài
đặt một con trỏ kết nối Successor tới các Handler khác.
 ConcreteHandler: Nắm giữ yêu cầu mà nó chịu trách nhiệm. Các
ConcreteHandler có thể truy xuất đối tƣợng đƣợc liên kết bởi con trỏ kết
nối Successor của nó. Nếu nó có thể nắm giữ yêu cầu đƣợc gửi đến, nó sẽ
thực hiện. Nếu không thì nó sẽ tiếp tục gửi yêu cầu cho Successor của nó để
chuyên yêu cầu cho đối tƣợng kế tiếp.
 Client: Kích hoạt yêu cầu cho một đối tƣợng ConcreteHandle trong chuỗi
mắt xích. Khi Client kích hoạt một yêu cầu, yêu cầu này sẽ đƣợc gửi đi theo
chuỗi mắt xích cho đến khi có một đối tƣợng ConcreteHandler nào đó nhận
yêu cầu này để xử lý.
1.3.5.4. Các tình huống áp dụng

Có nhiều hơn một đối tƣợng có thể nắm giữ yêu cầu.
Khi muốn gửi một yêu cầu tới nhiều đối tƣợng khác nhau mà không cần phải xác
định rõ ràng đó là đối tƣợng nào.
Khi tập các đối tƣợng giữ yêu cầu cần đƣợc xác định một cách linh động.
1.3.5.5. Thuận lợi và hạn chế
Giúp giảm sự phụ thuộc giữa các đối tƣợng: mẫu này giải phóng một đối tƣợng
khi biết đối tƣợng khác đang nắm giữ yêu cầu. Cả đối tƣợng gửi và nhận đều không
biết nhau và một đối tƣợng trong chuỗi mắt xích không cần phải biết cầu trúc của
chuỗi mắt xích.
Việc giao nhiệm vụ cho các đối tƣợng đƣợc thực hiện một cách linh hoạt. Mẫu
này cho phép phân phối công việc giữa các đối tƣợng một cách linh hoạt, có thể thêm
hoặc thay đổi việc nắm giữ các yêu cầu bằng cách thêm hay làm thay đổi chuỗi mắt
xích ở thời điểm chạy chƣơng trình.
Nhƣợc điểm của mẫu này là việc xác nhận đƣợc yêu cầu này có đƣợc xử lý hay
không, yêu cầu có thể đi đến cuối chuỗi mắt xích mà không đƣợc xử lý. Một yêu cầu
cũng có thể không đƣợc xử lý nếu chuỗi mắt xích không đƣợc cấu hình một cách phù


-25-
hợp.
1.3.6. Mẫu Interpreter (mẫu phiên dịch)
1.3.6.1. Ý nghĩa
Mẫu này dùng để xây dựng một kiến trúc ngữ pháp cho một ngôn ngữ. Dựa vào
kiến trúc này, một chƣơng trình thông dịch có thể hiểu đƣợc ý nghĩa của những câu
lệnh đƣợc viết bằng ngôn ngữ đó.
1.3.6.2. Cấu trúc mẫu

Hình 1.9: Cấu trúc mẫu Interpreter
Các thành phần tham gia vào cấu trúc mẫu Interpreter:
 AbstractExpresion: lớp trừu tƣợng, khai báo các tác vụ có thể thực hiện

đƣợc trên tất cả các nút trong cây cú pháp.
 TerminalExpression: Cài đặt tác vụ thông dịch cho những ký pháp nguyên
tố của ngôn ngữ đặc tả.
 NonterminalExpression: Có thể chứa các TerminalExpression bên trong
và cũng có thể chứa một NonterminalExpression khác. Nó đóng vai trò nhƣ
là ngữ pháp của ngôn ngữ đặc tả.
 Context: Là đối tƣợng chứa thông tin để thực hiện thông dịch. Đối tƣợng
này là toàn cục đối với toàn quá trình thông dịch.
1.3.6.4. Các tình huống áp dụng
Sử dụng mẫu Interpreter khi gặp vấn đề cần giải quyết lặp lại tƣơng đối nhiều và
ta có thể biểu diễn vấn đề bằng một ngôn ngữ đặc tả tƣơng đối đơn giản (ngôn ngữ đặc
tả này do ta tự thiết kế và xây dựng hoặc là những quy tắc đã có sẵn).
1.3.6.5. Thuận lợi và hạn chế
Một số ứng dụng đặc thù sẽ trở nên đơn giản khi cài đặt nếu ta xây dựng một bộ