-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
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
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
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
-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
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
đề 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.
(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
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),
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
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
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
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 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ộ
Copyright: Tài liệu đại học ©