..
ĐẠI HỌC THÁI NGUYÊN
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
Lê Thị Bắc
PHÂN TÍCH THIẾT KẾ HƯỚNG MẪU
VÀ ỨNG DỤNG VÀO BÀI TOÁN QUẢN LÝ
ĐỀ TÀI, DỰ ÁN CỦA SỞ KHOA HỌC VÀ
CÔNG NGHỆ THÁI NGUYÊN
CHUYÊN NGÀNH: KHOA HỌC MÁY TÍNH
MÃ SỐ: 60. 48. 01
LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH
NGƯỜI HƯỚNG DẪN KHOA HỌC
PGS.TS. Nguyễn Văn Vỵ
Thái Nguyên – 2012
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
http://www.lrc-tnu.edu.vn
LỜI CAM ĐOAN
Tôi xin cam đoan về toàn bộ nội dung của luận văn, những điều đƣợc
trình bày hoặc là của cá nhân hoặc là đƣợc tổng hợp từ nhiều nguồn tài liệu.
Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và đƣợc trích dẫn hợp
pháp.
Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo
quy định cho lời cam đoan của mình.
Lê Thị Bắc
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên
http://www.lrc-tnu.edu.vn
2
BẢNG CÁC CHỮ VIẾT TẮT
Viết tắt
Tên đầy đủ
RUP
Rational Unified Process
OOPSLA
Ọbect-Oriented Programming, Systems, Languages,
and Applications conference
PloP
Pattern Languages of Programs
POSA
Pattern-Oriented Software Architecture
POAD
Pattern Oriented Analysis and Design
UML
Unified Modeling Language
GoF
Gang og Four
ĐTDA
Đề tài dự án
KHCN
Khoa học Công nghệ
CNTT
Công nghệ thong tin
UBND
Ủy ban Nhân dân
CSDL
Cơ sở dữ liệu
QLKH
Quản lý khoa học
NCKH
Nghiên cứu khoa học
DM
Danh mục
NSD
Ngƣời sử dụng
DL
Dữ liệu
PK
Primary Key
FK
Foreign Key
3
DANH SÁCH CÁC BẢNG VÀ HÌNH VẼ
Số
Tên bảng và hình
Trang
Hình 3.1 Sơ đồ tiến trình hoạt động quản lý đề tài, dự án
34
Hình 3.2 Mô hình triển khai hệ thống
40
Hình 4.1 Mô hình ca sử dụng mức tổng thể của hệ thống quản
44
lý đề tài dự án
Hình 4.2 Biểu đồ tuần tự hệ thống đăng nhập
56
Hình 4.3 Biểu đồ tuần tự hệ thống Quản trị ngƣời sử dụng
57
Hình 4.4 Biểu đồ tuần tự chức năng QL DTDA đang triển khai
59
Hình 4.5 Biểu đồ trình tự thống kê, báo cáo
61
Hình 4.6 Mô hình khái niệm phân tích lĩnh vực
63
Hình 4.7 Biểu đồ cộng tác quản trị ngƣời sử dụng
64
Hình 4.8 Biểu đồ cộng tác quản trị danh mục
65
Hình 4.9 Biểu đồ cộng tác quản lý đề tài, dự án đang triển khai
66
Hình 4.10 Biểu đồ cộng tác thống kê báo cáo.
67
Hình 4.11 Các lớp thiết kế cơ bản của hệ thống
69
Hình 4.12 Giao diện chƣơng trình quản lý đề tài dự án
75
Hình 4.13 Danh sách đề tài, dự án
76
Hình 4.14 Danh mục lĩnh vực công nghệ
76
Hình 4.15 Bảng danh mục cán bộ tham gia đề tài
77
Hình 4.16 Chi tiết danh sách đề tài dự án đang triển khai
78
4
MỤC LỤC
LỜI CAM ĐOAN ............................................................................................. 1
BẢNG CÁC CHỮ VIẾT TẮT .......................................................................... 2
DANH SÁCH CÁC BẢNG VÀ HÌNH VẼ ...................................................... 3
MỤC LỤC ......................................................................................................... 4
LỜI NÓI ĐẦU .................................................................................................. 6
CHƢƠNG 1: TỔNG QUAN VỀ MẪU THIẾT KẾ ......................................... 8
1.1 Lịch sử phát triển mẫu thiết thiết kế ........................................................ 8
1.2 Khái niệm về mẫu thiết kế (Design pattern) ......................................... 10
1.3 Hệ thống các mẫu thiết kế và phân loại ................................................. 11
1.4 Phân loại mẫu ........................................................................................ 15
1.5 Lợi ích của việc sử dụng các mẫu trong thiết kế ................................... 17
1.6 Áp dụng mẫu thiết kế trong phát triển phần mềm ................................. 21
CHƢƠNG 2 : QUY TRÌNH PHÂN TÍCH VÀ THIẾT KẾ HƢỚNG MẪU . 22
2.1 Các bƣớc của tiến trình phân tích và thiết kế hƣớng mẫu ..................... 22
2.2 Phân tích và đặc tả yêu cầu hệ thống ..................................................... 26
2.3 Tiến trình sử dụng mẫu thiết kế ............................................................. 27
CHƢƠNG 3 : BÀI TOÁN NGHIỆP VỤ VÀ GIẢI PHÁP GIẢI QUYẾT
VẤN ĐỀ .......................................................................................................... 29
3.1 Khảo sát thu thập dữ liệu và mô tả bài toán .......................................... 29
3.2 Mô tả hoạt động nghiệp vụ của hệ thống (mô hình nghiệp vụ)............. 29
3.3 Những vấn đề và tồn tại trong hệ thống quản lý đề tài NCKH ............. 38
3.4 Giải pháp tổng thể công nghệ thông tin cho bài toán đặt ra. ................. 38
3.5 Mô hình triển khai ................................................................................. 40
CHƢƠNG 4. PHÂN TÍCH VÀ THIẾT KẾ BÀI TOÁN ĐỊNH HƢỚNG
MẪU................................................................................................................ 42
4.1 Phát triển mô hình nghiệp vụ ................................................................. 42
5
4.2 Mô hình ca sử dụng: .............................................................................. 44
4.3 Phân tích hệ thống ................................................................................. 56
4.4 Mô hình khái niệm phân tích lĩnh vực: .................................................. 63
4.5 Thiết kế hệ thống : ................................................................................ 64
4.6 Bảng dữ liệu: ......................................................................................... 70
4.7 Cài đặt và thử nghiệm một số modul .................................................... 75
6
LỜI NÓI ĐẦU
Phát triển phần mềm theo định hƣớng đối tƣợng ngày càng phát triển
mạnh mẽ và đang chiếm ƣu thế do những đặc trƣng vƣợt trội của nó. Trong
toàn bộ tiến trình phát triển phần mềm, phân tích thiết kế vẫn là một khâu khó
khăn, phức tạp nhất và đòi hỏi ngƣời thực hiện có trình độ cao, có nhiều kinh
nghiệm. Chất lƣợng của phần mềm đạt đƣợc phụ thuộc chủ yếu ở khâu này,
tức là phụ thuộc vào chất lƣợng thiết kế. Tuân thủ theo quy trình RUP, sau
một quá trình phát triển sẽ ta nhận đƣợc một thiết kế hƣớng đối tƣợng của hệ
thống. Có một số tiêu chí về thiết kế tốt cho phép ngƣời ta xem xét nó và hoàn
thiện. Nhƣng một cách khác để hoàn thiện thiết kế thƣờng đƣợc áp dụng, đó
là xem xét thiết kế để cải tiến nó trên cơ sở các kiến thức về các mẫu thiết kế
(design patterns). Các mẫu thiết kế là các giải pháp đã đƣợc các nhà thiết kế
có kinh nghiệm nghiên cứu và hoàn thiện cho những vấn đề thƣờng gặp trong
thiết kế.
Một cách làm triệt để hơn để sử dụng lại các mẫu cho thiết kế là phân
tích thiết kế định hƣớng mẫu. Đây là một trong ba hƣớng sử dụng lại của phát
triển phần mềm hƣớng đối tƣợng – sử dụng lại các mẫu. Với mong muốn áp
dụng các công nghệ mới cho phát triển phần mềm, tôi đã chọn đề tài “Phân
tích thiết kế hướng mẫu và ứng dụng cho bài toán quản lý đề tài, dự án của sở
Khoa học và Công nghệ Thái Nguyên “ làm đề tài của luận văn.
Theo phƣơng pháp phân tích thiết kế định hƣớng mẫu, ngƣời ta sử dụng
các mẫu thiết kế ngay sau khi đặc tả yêu cầu. Nhƣ vậy, sau khi đặc tả yêu cầu
của bài toán theo phƣơng pháp hƣớng đối tƣợng, ta phải tìm kiếm các mẫu
tƣơng ứng cho mỗi đặc tả chi tiết. Khó khăn lớn ở đây là có rất nhiều mẫu
khác nhau, làm sao chọn đƣợc một mẫu thích hợp. Hơn nữa, các đặc trƣng mô
tả mẫu là tƣơng đối trừu tƣợng, có sự khác biệt đáng kể với các đặc trƣng đặc
tả yêu cầu. Vì thế đòi hỏi ngƣời phát triển hệ thống có hiểu biết sâu xắc về
mỗi mẫu, nắm chắc đƣợc yêu cầu của vấn để đặt ra, để từ đó chọn ra một mẫu
giải quyết đƣợc yêu cầu của vấn đề. Mặt khác, cùng một yêu cầu, có thể có
nhiều mẫu có khả năng đáp ứng đƣợc yêu cầu đó. Đây lại là một cách lựa
7
chọn đòi hỏi phải có kinh nghiệm từ thực tiễn triển khai ứng dụng. Theo
phƣơng pháp này, ta đã bỏ qua đƣợc các bƣớc đi tuần tự, từ mức cao đến mức
chi tiết của giai đoạn phân tích và thiết kế, thƣờng tốn nhiều thời gian công
sức với nhiều mô hình phƣơng pháp khác nhau. Vì vậy đây là cách làm hiệu
quả, vừa tiết kiệm thời gian, công sức và vẫn cho phép nhận đƣợc một thiết kế
tốt. Mặc dù hƣớng này là rất khó khăn, với mong muốn thử nghiệm công
nghệ và nâng cao kỹ năng phân tích thiết kế, tôi chọn nó để giải quyết bài
toán đặt ra.
8
CHƢƠNG 1: TỔNG QUAN VỀ MẪU THIẾT KẾ
1.1 Lịch sử phát triển mẫu thiết thiết kế
Sự xuất hiện của mẫu xuất phát từ rất nhiều sáng kiến khác nhau. Kiến
trúc sƣ Christopher Alexander, giáo sƣ kiến trúc tại trƣờng đại học California
ở Berkeley, đã phát triển nền tảng cho các Mẫu. Từ «Mẫu» (Pattern) có liên
quan hầu hết tới toàn bộ công việc của ông. Ông và nhóm nghiên cứu của
mình đã sử dụng trên 20 năm cho việc phát triển một cách tiếp cận đến kiến
trúc lớn bằng cách dùng các Mẫu. Alexander đã mô tả trên 250 mẫu qua một
hệ quan điểm trừu tƣợng rất rộng, từ các kiến trúc của thị trấn đến các thiết kế
phòng. Ông đã tìm ra một khuôn mẫu mô tả các yếu tố cơ bản của Pattern, đó
là Giải pháp-Vấn đề-Ngữ cảnh. Ông đã viết một cuốn sách về các Mẫu kiến
trúc [4].
Kent Beck and Ward Cunningham đã rất nhiệt tình trong việc áp dụng
các ý tƣởng của Alexander vào việc phát triển phần mềm. Họ đã viết bộ
Pattern đầu tiên về giao diện ngƣời dùng.
Ấn phẩm đầu tiên trình bày về việc dùng các Pattern trong phát triển
phần mềm là luận án tiến sĩ năm 1991 của Erich Gamma, đƣợc viết ở Đức,
lúc đó tác phẩm này chƣa phổ biến. “Gần một nửa các Mẫu Pattern được mô
tả sau này [3] được chứng minh là trước đó có trong luận văn tiến sĩ của
ông” [5].
Bruce Anderson là một trong những ngƣời đi đầu trong nghiên cứu về
Pattern. Ông có một cuộc hội thảo về chủ đề Pattern ở OOPSLA (ỌbectOriented Programming, Systems, Languages, and Applications conference)
vào khoảng những năm 1990; Jim ? đã mô tả các thành ngữ bằng ngôn ngữ
C++ trong cuốn sách của ông có tựa đề là “Advanced C++ Programming
9
Styles and Idioms”. Các thành ngữ đó dù cách này hay cách khác đều liên
quan đến các ý tƣởng của các giải pháp cho các vấn đề thƣờng xuyên xảy ra.
Một nhóm đƣợc gọi là Hillside Group đƣợc thành lập để khám phá thêm về
các ý tƣởng này và đẩy mạnh việc dùng các Mẫu trong việc phát triển phần
mềm. Họ đã làm việc để chỉ đạo và hỗ trợ cho các thành viên mới trong cộng
đồng Pattern. Nhóm này đã thành lập nên Ngôn ngữ mẫu cho chƣơng trình
(Pattern Languages of Programs- PloP) lần đầu tiên vào năm 1994 tại một hội
nghị. Tri thức chung về mẫu đã đƣợc thể hiện tốt trong một cuốn sách gồm 4
ngƣời cùng tham gia viết, Design Patterns: Elements of Object-Oriented
Software [3], họ đã phân loại và mô tả rất rõ 23 mẫu thiết kế đƣợc dùng rất
phổ biến trong lập trình hƣớng đối tƣợng.
Peter Coad đã làm việc với các Mẫu hƣớng đối tƣợng từ rất sớm [6]. Ông đã
mô tả 7 mẫu đơn giản trong phân tích và thiết kế. Ông đã làm việc trên các
Mẫu hỗ trợ phân tích miền ứng dụng và dùng công nghệ hƣớng đối tƣợng để
xây dựng các ứng dụng [7]. Douglas Schmidt cũng là một trong những ngƣời
đầu tiên nghiên cứu về mẫu; ông là tác giả của nhiều Mẫu trong các hệ thống
giao tiếp và các ứng dụng phân tán [8]. Wolfgang Pree đã làm việc trên các
mẫu dành cho việc phát triển khung làm việc (framework) [9]. Ông đã phân
nhóm các nguyên lý mang tính cấu trúc thành các Siêu Mẫu (MetaPattern)
đƣợc dùng để phát triển các khung làm việc. Pattern-Oriented Software: A
Pattern System, cũng đƣợc coi là cuốn sách “Tốp 5” [5], chú trọng vào việc
dùng các Mẫu ở mức kiến trúc của phát triển phần mềm. Các tác giả đã phân
loại các Mẫu phần mềm nhƣ là các Mẫu kiến trúc, các mẫu thiết kế và các
Thành ngữ. Phần lớn sự đóng góp của họ đều đƣợc hƣớng tới các Mẫu kiến
trúc. Cuốn sách của họ cùng với cuốn sách của bốn tác giả Erich Gamma,
Richard Helm, Ralph Johnson, John Vlissides là những tài liệu rất tốt cho
những ngƣời mới bắt đầu nghiên cứu mẫu. Quyển 2 của tập sách Pattern-
10
Oriented Software Architecture - POSA [10] mô tả các mẫu cho các đối
tƣợng đồng thời (concurrent) và đối tƣợng mạng, giải thích các Mẫu và thể
hiện kĩ thuật xây dựng các ứng dụng phân tán. Cuốn sách bao gồm các mẫu
truy cập dịch vụ, các Mẫu Cấu hình, các mẫu điều khiển sự kiện, các mẫu
đồng bộ hoá và các mẫu Đồng thời. Một ngôn ngữ mẫu dành cho MiddleWare
và các ứng dụng cũng đƣợc mô tả.
Một vài cuộc hội thảo đã diễn ra để đánh giá và làm tài liệu các Mẫu mới. Các
cuộc hội thảo hàng năm về ngôn ngữ Pattern là các nguồn chính cho việc
đánh giá và lập danh mục mẫu. Các Mẫu hoàn thiện đã đƣợc làm tài liệu trong
tập các quyển sách về ngôn ngữ mẫu cho thiết kế chƣơng trình [11].
1.2 Khái niệm về mẫu thiết kế (Design pattern)
Theo định nghĩa của Christopher Alexander: “Một mẫu mô tả một vấn đề xảy
ra lặp đi lặp lại và mô tả phần cốt lõi của giải pháp cho vấn đề đó, chúng ta
có thể sử dụng lại giải pháp đã có hàng triệu lần”[3].
Nói chung, một mẫu mô tả một vấn đề thƣờng xảy ra trong phát triển phần
mềm và mô tả giải pháp cho vấn đề đó theo cách có thể dùng lại đƣợc. Các
mẫu là phƣơng tiện truyền bá tri thức và kinh nghiệm, truyền từ những ngƣời
giàu kinh nghiệm đến những ngƣời thiếu kinh nghiệm.
Hầu hết các mẫu được xây dựng để hỗ trợ chỉ cho tiếp cận hướng đối
tượng
Thông thƣờng một mẫu đƣợc thể hiện với 4 yếu tố chính:
Tên mẫu: cụm từ ngắn, cho phép tham chiếu đến mẫu
Vấn đề: mô tả khi nào áp dụng mẫu, giải thích vấn đề và khung cảnh.
Giải pháp cho vấn đề: mô tả các yếu tố tạo nên thiết kế, các mối quan
hệ giữa chúng, các trách nhiệm và sự cộng tác giữa chúng. Giải pháp
không mô tả thiết kế hoặc triển khai cụ thể, vì một mẫu có thể đƣợc áp
11
dụng trong nhiều tình huống khác nhau. Mẫu chỉ cung cấp bản mô tả
trừu tƣợng về một vấn đề thiết kế và việc sắp xếp các yếu tố ở mức
chung nhất để giải quyết nó.
Kết quả: là các kết quả của việc áp dụng mẫu. Vì chúng ta luôn phải
trả giá cho việc áp dụng mẫu nên trƣớc đó chúng ta cần xác định chi
phí bỏ ra cũng nhƣ kết quả thu về để có thể quyết định lựa chọn mẫu
phù hợp và áp dụng nó.
Ví dụ:
Tên mẫu:
Creator
Vấn đề:
Ai có trách nhiệm tạo ra một thể hiện mới của một lớp?
Giải pháp
Lớp B có trách nhiệm tạo ra một thể hiện mới của lớp A nếu
một trong các điều kiện dƣới đây thỏa mãn:
- B là một tập hợp các đối tƣợng A (B và A có mối quan hệ
aggregate)
- B chứa các đối tƣợng A (B và A có mối quan hệ contain)
- B lƣu lại các thể hiện của các đối tƣợng A
- B sử dụng các đối tƣợng A
- B có dữ liệu khởi tạo mà đƣợc truyền tới A khi nó đƣợc tạo.
1.3 Hệ thống các mẫu thiết kế và phân loại
Hệ thống các mẫu thiết kế hiện có 23 mẫu đƣợc định nghĩa trong cuốn
“Design patterns Elements of Reusable Object Oriented Software”. Hệ thống
các mẫu này có thể nói là đủ và tối ƣu cho việc giải quyết hết các vấn đề của
bài toán phân tích thiết kế và xây dựng phần mềm trong thời điểm hiện tại.
TT Tên mẫu
Vai trò của mẫu
12
1.
Abstract Factory
Cung cấp giao diện để tạo họ các đối tƣợng độc lập
hoặc liên quan nhau mà không cần đặc tả các lớp cụ
thể của chúng.
2.
Adapter
Chuyển đổi giao diện của một lớp thành giao diện
khác mà clients mong đợi
3.
Bridge
Tách riêng một sự trừu tƣợng với triển khai nó để
hai việc độc lập với nhau
4.
Builder
Phân tách việc xây dựng một đối tƣợng phức tạp
với thể hiện của nó để cùng một tiến trình xây dựng
có th tạo ra nhiều thể hiện khác nhau.
5.
Chain
Responsibility
of Tránh ghép nối đối tƣợng gửi yêu cầu với đối tƣợng
nhận nó bằng cách cho phép nhiều đối tƣợng có cơ
hội nhận yêu cầu đó. Tạo thành dãy các đối tƣợng
nhận và truyền yêu cầu qua dãy này cho tới khi một
đối tƣợng nhận xử lý đƣợc yêu cầu.
6.
Command
Đóng gói một yêu cầu thành một đối tƣợng, nhờ đó
ta có thể tham số hóa các clients với các yêu cầu
khác nhau, các hàng đợi và hỗ trợ các tác vụ không
cho phép hủy.
7.
Composite
Ghép các đối tƣợng tạo thành cấu trúc cây để tạo
thành phân cấp toàn thể - bộ phận treat
8.
Decorator
Gắn các trách nhiệm bổ sung cho một đối tƣợng
theo cách động, hỗ trợ cho việc bổ sung chức năng.
9.
Facade
Cung cấp một giao diện thống nhất cho một tập các
giao diện trong một hệ thống con. Façade định
nghĩa một giao diện mức cao mà làm cho các hệ
13
thống con dễ sử dụng.
10. Factory Method
Định nghĩa một giao diện để tạo một đối tƣợng
nhƣng cho phép các lớp con quyết định lớp nào để
làm thể hiện.
11. Flyweight
Sử dụng chia sẻ để hỗ trợ số lƣợng lớn các đối
tƣợng đƣợc làm mịn một cách hiệu quả.
12. Interpreter
Đƣa ra một ngôn ngữ, định nghĩa một thể hiện cùng
với một đối tƣợng biểu thị mà dùng thể hiện này để
biểu thị các câu trong ngôn ngữ.
13. Iterator
Cung cấp một cách để truy cập các yếu tố của một
đối tƣợng tập hợp một cách tuần tự mà không làm
lộ thể hiện cơ sở của nó.
14. Mediator
Định nghĩa một đối tƣợng mà che giấu thông tin về
một tập các đối tƣợng tƣơng tác với nhau nhƣ thế
nào. Mediator đảm bảo kết nối lỏng lẻo bằng cách
giữ các đối tƣợng khỏi sự tham chiếu từ các đối
tƣợng khác.
15. Memento
Không xâm phạm vào tính bao gói và che giấu
thông tin, nó nắm bắt trạng thái bên trong của đối
tƣợng để sau đó đối tƣợng có thể quay trở về trạng
thái này.
16. Observer
Định nghĩa một hoặc nhiều sự phụ thuộc giữa các
đối tƣợng
17. Prototype
Đặc tả các loại đối tƣợng để tạo, sử dụng thể hiện
khuôn mẫu và tạo đối tƣợng mới bằng cách sao
chép khuôn mẫu này
14
18. Proxy
Cung cấp một đại diện cho một đối tƣợng để điều
khiển truy nhập đến nó.
19. Singleton
Đảm bảo một lớp chỉ có một thể hiện và cung cấp
điểm truy nhập toàn cục cho nó.
20. State
Cho phép một đối tƣợng thay đổi hành vi của nó
khi trạng thái bên trong nó thay đổi
21. Strategy
Định nghĩa họ các thuật toán, đóng gói nó, làm cho
chúng có thể hoán đổi cho nhau và không phụ
thuộc vào đối tƣợng dùng nó.
22. Template Method
Định nghĩa khung thuật toán cho một tác vụ
23. Visitor
Thể hiện một tác vụ đƣợc thực hiện trên các yếu tố
của một cấu trúc đối tƣợng. Mẫu cho phép định
nghĩa một tác vụ mới mà không thay đổi lớp các
yếu tố mà nó thao tác trên đó.
Có nhiều mẫu thiết kế dành riêng cho từng lĩnh vực cụ thể:
Mẫu thiết kế cho hệ thống điều khiển phƣơng tiện tự động.
Mẫu thiết kế cho hệ thống âm nhạc có tƣơng tác.
Mẫu thiết kế cho các dịch vụ mạng với cấu hình linh hoạt trong các hệ
thống phân tán.
45 mẫu thiết kế cho các hệ thống thời gian thực và hệ thống phân tán.
Các mẫu thiết kế theo công nghệ J2EE.
Các mẫu Expert, Creator, LowCoupling, High Cohension và Controller.
15
1.4 Phân loại mẫu
Có nhiều cách phân loại khác nhau. Ngoài cách phân loại theo từng lĩnh vực
áp dụng hay từng loại hệ thống cụ thể nhƣ đƣợc trình bày ở mục 4 thì tất cả
các mẫu mà có thể áp dụng đƣợc cho nhiều lĩnh vực khác nhau có thể đƣợc
phân loại theo 2 tiêu chí dƣới đây:
Theo mục đích sử dụng
Creational
Structural
Behavioral
Giải quyết các việc tạo Giải quyết mối quan hệ Mô tả các cách thức mà
các lớp và các đối cấu trúc giữa các lớp và các lớp và các đối
tượng
các đối tượng
tượng tương tác với
nhau và sự phân bổ
trách nhiệm giữa chúng
Factory Method
Adapter
Interpreter
Abstract Factory
Adapter
Template Method
Builder
Bridge
Chain of Responsibility
Prototype
Composite
Command
Singleton
Decorator
Interator
Façade
Mediator
Flyweight
Memento
Proxy
Observer
State
Strategy
Visitor
Theo phạm vi/đối tượng áp dụng
Class
Factory Method
16
Adapter
Interpreter
Template Method
Object
Abstract
Adapter
Chain of Responsibility
Factory
Bridge
Command
Builder
Composite
Interator
Prototype
Decorator
Mediator
Singleton
Façade
Memento
Flyweight
Observer
Proxy
State
Strategy
Visitor
Class:
- Các mẫu áp dụng chủ yếu lên các lớp
- Giải quyết mối quan hệ giữa các lớp và các lớp con. Các mối quan hệ này
đƣợc thiết lập qua thừa kế, là mối quan hệ tĩnh, tại thời gian biên dịch.
Object:
- Các mẫu áp dụng chủ yếu lên các đối tƣợng.
- Giải quyết mối quan hệ giữa các đối tƣợng, là mối quan hệ động và thay đổi
tại thời gian chạy.
Các mẫu cấu trúc áp dụng trên lớp dùng thừa kế để cấu thành lớp.
Các mẫu cấu trúc áp dụng trên đối tƣợng mô tả các cách để kết hợp các đối
tƣợng.
Các mẫu hành vi áp dụng trên lớp dùng thừa kế để mô tả các thuật toán và các
luồng điều khiển
17
Các mẫu hành vi áp dụng trên đối tƣợng mô tả cách thức mà một nhóm đối
tƣợng cộng tác với nhau để thực hiện một nhiệm vụ mà không có một đối
tƣợng riêng lẻ nào có thể thực hiện độc lập.
Ngoài ra, chúng ta có thể phân loại mẫu theo ngôn ngữ triển khai mẫu:
Ngôn ngữ Java: interfaces, responsibility, construction, operations, and
extensions.
1.5 Lợi ích của việc sử dụng các mẫu trong thiết kế
Mẫu thiết kế giải quyết nhiều vấn đề mà các nhà thiết kế hƣớng đối tƣợng
phải đối mặt và bằng nhiều cách khác nhau. Dƣới đây là một số vấn đề mà
mẫu có thể giải quyết và cách thức mẫu giải quyết các vấn đề đó.
- Tìm các đối tượng (object) phù hợp
Trong thiết kế hƣớng đối tƣợng, chúng ta cần phân chia một hệ thống thành
các đối tƣợng. Việc này là không dễ dàng vì thiết kế của chúng ta phải đảm
bảo các tiêu chí nhƣ bao gói, mịn, độc lập, mềm dẻo, hiệu năng, tái sử
dụng,… Các tiêu chí này thƣờng mâu thuẫn nhau.
Đã có nhiều cách tiếp cận khác nhau để thực hiện công việc này, hoặc là viết
ra một câu mô tả ngắn về vấn đề với các danh từ và các động từ, chúng ta tạo
ra các lớp (class) và phƣơng thức (method) của các lớp tƣơng ứng với các
danh từ và các động từ tìm đƣợc trong câu mô tả, hoặc là chúng ta mô hình
hóa các đối tƣợng của thế giới thực và chuyển các đối tƣợng đƣợc tìm thấy
trong giai đoạn phân tích sang giai đoạn thiết kế.
Các mẫu thiết kế giúp chúng ta xác định các đối tƣợng phù hợp. Ví dụ, các
đối tƣợng thể hiện các vi xử lý hay các thuật toán mà không xuất hiện trong
thế giới thực nhƣng chúng lại là phần cốt lõi của các thiết kế mềm dẻo. Mẫu
Strategy mô tả cách triển khai họ các thuật toán. Mẫu State thể hiện mỗi trạng
thái của một thực thể nhƣ là một đối tƣợng. Các đối tƣợng này ít khi đƣợc tìm
18
thấy trong giai đoạn phân tích hoặc giai đoạn đầu của thiết kế, chúng chỉ đƣợc
nhận ra khi hoàn thiện thiết kế để tăng tính mềm dẻo và tăng khả năng tái sử
dụng của thiết kế.
- Quyết định kĩch cỡ của các đối tượng
Các mẫu hỗ trợ việc xác định đối tƣợng, phân chia đối tƣợng để thu đƣợc các
đối tƣợng với kích thƣớc nhỏ hơn. Ví dụ, Mẫu Abstract Factory và mẫu
Builder sinh ra các đối tƣợng mà trách nhiệm duy nhất của chúng là tạo ra các
đối tƣợng khác, mẫu Visitor và mẫu Command sinh ra các đối tƣợng mà trách
nhiệm duy nhất của chúng là triển khai một yêu cầu trên một đối tƣợng khác
hoặc trên một nhóm đối tƣợng khác.
- Đặc tả các giao diện đối tượng (object interface)
Các tác vụ (operator) của đối tƣợng đƣợc mô tả bằng tên tác vụ, tham số, giá
trị trả về. Mô tả tác vụ còn đƣợc gọi là khai báo tác vụ. Tập hợp tất cả các
khai báo tác vụ của một đối tƣợng tạo thành giao diện của đối tƣợng đó. Giao
diện của một đối tƣợng thể hiện các yêu cầu có thể đƣợc gửi đến đối tƣợng
đó, bất kỳ yêu cầu nào mà khớp với một khai báo trong giao diện đều có thể
đƣợc gửi tới đối tƣợng.
Một kiểu (type) là một tên gọi đƣợc sử dụng để nói đến một giao diện cụ thể.
Chúng ta nói rằng, một đối tƣợng có kiểu Window nếu nó chấp nhận tất cả
các yêu cầu cho các tác vụ đƣợc định nghĩa trong giao diện có tên là Window.
Một đối tƣợng có nhiều kiểu và các đối tƣợng khác nhau có thể chia xẻ cùng
một kiểu. Một phần của giao diện đối tƣợng có thể đặc trƣng bởi một kiểu và
các phần khác thì bởi các kiểu khác. Hai đối tƣợng của cùng một kiểu chỉ cần
chia xẻ các phần giao diện của chúng. Các giao diện có thể chứa các giao diện
khác nhƣ là các tập con của chúng. Chúng ta nói rằng một kiểu là kiểu con
của kiểu khác nếu giao diện của nó chứa giao diện của siêu kiểu của nó (kiểu
19
cha của nó). Thông thƣờng chúng ta nói, một kiểu con thừa kế giao diện của
kiểu cha của nó.
Các giao diện là các đối tƣợng cơ bản của các hệ thống hƣớng đối tƣợng. Các
đối tƣợng đựợc biết chỉ qua giao diện của chúng. Không có cách nào để biết
bất cứ điều gì về một đối tƣợng mà không thông qua giao diện của nó.
Hai đối tƣợng có triển khai khác nhau hoàn toàn có thể có giao diện giống
nhau. Khi một yêu cầu đƣợc gửi đến một đối tƣợng, tác vụ nào đƣợc thực
hiện là phụ thuộc vào cả đối tƣợng gửi và đối tƣợng nhận yêu cầu.
Các đối tƣợng khác nhau hỗ trợ các yêu cầu giống nhau có thể có các triển
khai khác nhau của tác vụ mà đáp ứng các yêu cầu đó. Liên kết của một yêu
cầu tới một đối tƣợng và một trong các tác vụ của nó tại thời gian chạy đƣợc
gọi là liên kết động (dynamic binding).
Liên kết động có nghĩa là một yêu cầu không đƣợc hồi đáp cho tới thời gian
chạy. Kết quả là chúng ta có thể viết ra các chƣơng trình mà mong đợi một
đối tƣợng với một giao diện cụ thể. Biết rằng bất kỳ đối tƣợng nào có giao
diện đúng sẽ chấp nhận yêu cầu. Tuy nhiên liên kết động cho phép chúng ta
nhận ra các đối tƣợng mà có các giao diện giống nhau ở mỗi thời gian chạy
khác nhau. Tính chất này đƣợc gọi là đa hình (polymorphism), nó là khái
niệm chính trong hệ thống hƣớng đối tƣợng. Đa hình tách biệt các đối tƣợng
và giúp chúng có những mối quan hệ khác nhau ở mỗi thời gian chạy.
Các mẫu thiết kế giúp định nghĩa các giao diện bằng cách nhận ra các yếu tố
chính và các loại dữ liệu chính mà có thể gửi và nhận qua giao diện. Mẫu thiết
kế cũng có thể cho ta biết những gì không nên đặt ở trên giao diện, chẳng hạn
mẫu Memento. Mẫu này mô tả cách bao gói và lƣu trữ trạng thái bên trong
của đối tƣợng để đối tƣợng có thể quay về trạng thái đó trong tƣơng lai.
Các mẫu thiết kế cũng đặc tả mối quan hệ giữa các giao diện. Cụ thể, chúng
thƣờng yêu cầu một vài lớp có các giao diện tƣơng tự nhau hoặc chúng đặt
- Xem thêm -