Phân tích và thiết kế hướng mẫu

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
B¶o vÖ luËn v¨n th¹c sÜ


Phân tích và thiết kế hướng mẫu

Học viên : Chu Thị Hồng Hải
Người hướng dẫn : PGS.TS Nguyễn Văn Vỵ



Chu Thị Hồng Hải – Luận văn Thạc sĩ



CÁC THUẬT NGỮ VIẾT TẮT

Design pettern
Mẫu thiết kế
Coding
Mã hóa
Code
Mã lệnh
Incidental or ad hoc
Sự xác định hay tuỳ hứng
GOF(gang of five)
Nhóm 5 thành viên
Creational Patterns
Các mẫu tạo
Structual Patterns
Các mẫu cấu trúc

Behavioral Pattern
Các mẫu hành vi
POAD
Phân tích và thiết kế hướng mẫu
Use case diagram
Biểu đồ ca sử dụng
Class diagram
Biểu đồ lớp
Activity diagram
Biểu đồ hành động
Collaboration diagram
Biểu đồ cộng tác
Sequence diagram
Biểu đồ tuần tự
Implementation diagram
Biểu đồ thực thi
Component diagram
Biểu đồ thành phần
Framework
Khung làm việc
IDOMS
Thành ngữ
Abstract factory pattern
Mẫu chế tạo trừu tượng
FactoryPattern
Mẫu chế tạo
Base- class
Lớp cơ sở
Singleton Pattern
Mẫu đơn chiếc

PROXY PATTERN
Mẫu uỷ nhiệm
proxy class
Lớp uỷ nhiệm
Remote Proxy
Uỷ nhiệm từ xa
Virtual Proxy
Uỷ nhiệm ảo
Monitor Proxy
Uỷ nhiệm màn hình
Protection proxy
Chống uỷ nhiệm
Cache proxy
Không gian lưu trữ tạm thời
Firewall proxy
Uỷ nhiệm bảo vệ
Smart reference proxy
Kiểm soát các đối tượng bổ sung
Synchoronization Proxy
Uỷ nhiệm đồng bộ
Copy_ on_write proxy.
Cho phép ghi vaò đĩa mọi lúc
Adapter pattern
Mẫu thích nghi
wrapper pattern
Mẫu bao bọc



DANH MỤC BẢNG BIỂU

Hình1.1 Chúng ta có thể biên soạn các thiết kế bằng việc sử dụng các mẫu thiết kế
không?
Hình 1.2. Minh hoạ vòng đời của mẫu
Hình 2.1 Biểu đồ lớp cuả mẫu chế tạo
Hình 2.2 Biểu đồ lớp của mẫu chế tạo trừu tượng
Hình 2.3 Biểu đồ lớp trong mẫu đơn chiếc
Hình 2.4 Ví dụ mẫu đơn chiếc
Hình 2.5 Ví dụ biểu đồ lớp đơn chiếc
Hình 2.6 Biểu đồ lớp mẫu uỷ nhiệm
Hình 2.7 Biểu đồ lớp mẫu thích nghi
Hình 2.8 Hình minh hoạ các phần tử mẫu phức hợp
Hình 2.9 Minh hoạ các phần tử của Composite pattern
Hình 2.10 Sơ đồ mối liên kết các mẫu thiết kế
Hình 3.1 Sơ đồ tổ chức trường đại học quản trị kinh doanh HN
Hình 3.2.1 Mô hình khái niệm (hình 1)
Hình 3.2.2 Mô hình khái niệm (hình 2)
Hình 3.2.3 Mô hình khái niệm (hình 3)
Hình 3.3 Biểu đồ ca sử dụng gói “Cập nhật sinh viên ”
Hình 3.4 Biểu đồ ca sử dụng gói “Quản lý lớp học ”
Hình 3.5 Biểu đồ ca sử dụng gói “quản lý học phí”
Hình 3.6 Biểu đồ ca sử dụng gói “Quản lý khen thưởng kỷ luật”
Hình 3.7 Biểu đồ ca sử dụng gói “Quản lý thực tập”
Hình 3.8 Biểu đồ ca sử dụng gói “Quản lý sinh viên trả nợ”
Hình 3.9 Biểu đồ ca sử dụng gói “Quản lý sinh viên làm khoá luận tốt nghiệp”
Hình 3.10 Biểu đồ ca sử dụng gói “Quản lý công tác tốt nghiệp”
Hình 3.11 Biểu đồ tuần t ự hệ thống “cập nhật sinh viên”


Hình 3.12 Biểu đồ lớp gói “ Cập nhật sinh viên”
Hình 3.13 Biểu đồ tuần tự khái niệm “ Cập nhật sinh viên”

Hình 3.14 Biểu đồ tuần tự gói “Thông tin lớp học”
Hình 3.15. Biểu đồ lớp gói “Thông tin lớp học”
Hình 3.16 Biểu đồ tuần tự khái niệm “Phân lớp”
Hình 3.17 Biểu đồ tuần tự khái niệm “quản lý học phí”
Hình 3.18 Biểu đồ lớp “quản lý học phí”
Hình 3.19 Biểu đồ tuần tự khái niệm lớp “Khen thưởng kỷ luật”
Hình 3.20 Biểu đồ lớp “Khen thưởng kỷ luật”
Hình 3.21 Biểu đồ tuần tự khái niệm “Khen thưởng kỷ luật”
Hình 3.22 Biểu đồ tuần tự hệ thống “Quản lý học viên trả nợ”
Hình 3.23 Biểu đồ lớp “Quản lý học viên trả nợ”
Hình 3.24 Biểu đồ tu ần t ự “Quản lý học viên trả nợ”
Hình 3.25 Biểu đồ tuần tự khái niệm lớp “Quản lý khoá luận tốt nghiệp”
Hình 3.26 Biểu đồ lớp “Quản lý khoá luận tốt nghiệp”
Hình 3.27 Biểu đồ tuần tự lớp “Quản lý sinh viên thực tập”
Hình 3.28 Biểu đồ lớp “Quản lý sinh viên thực tập”
Hình 3.29 Biểu đồ tu ần t ự “Quản lý sinh viên thực tập”
Hình 3.30 Biểu đồ tu ần t ự “Quản lý công tác tốt nghiệp”
Hình 3.31 Biểu đồ l ớp “Quản lý công tác tốt nghiệp”
Hình 3.32 Sơ đồ thiết kế lớp sinh viên ban đầu
Hình 3.33 Sơ đồ thiết kế lớp sinh viên sau khi biến đổi
Hình 3.34 Sơ đồ thiết kế lớp sinh viên
Hình 3.35 Sơ đồ thiết kế lớp sinh viên áp d ụng mẫu Bridge
Hình 3.36 Biểu đồ lớp “ Quản lý học phí”
Hình 3.37 Biểu đồ lớp có áp dụng mẫu “ Quản lý học phí”


Hình 3.38 Biểu đồ lớp có áp dụng mẫu “ Quản lý học phí”
Hình 3.39 Giao diện cập nhật sinh viên

1
MỤC LỤC
MỤC LỤC 1
Chương 1 Error! Bookmark not defined.
MẪU THIẾT KẾ VÀ PHÂN TÍCH HƯỚNG MẪU 2
1.1. Giới thiệu chung 2
1.2. Chúng ta tái sử dụng cái gì? 3
1.3. Biên soạn mẫu thiết kế 4
1.4. Các thành phần của mẫu thiết kế 6
1.5. Mô tả mẫu thiết kế 7
1.6 .Thiết kế hướng mẫu 9
1.7. Phân tích thiết kế hướng đối tượng là một giải pháp 12
1.8. Mẫu thiết kế và kỹ nghệ phần mềm 14
1.9. Đặc điểm chung của mẫu 22
1.10. Những cách tiếp cận thành phần mẫu thiết kế 23
Chương 2 Error! Bookmark not defined.
CÁC LOẠI MẪU THIẾT KẾ 24
2.1. Phân loại mẫu 24
2.2. Mẫu thiết kế với từng bài toán 24
2.3. Mẫu chế tạo 26
2.4. Mẫu chế tạo trừu tượng (Abstractfactory pattern) 28
2.5. Mẫu đơn chiếc 29
2.6. Mẫu uỷ nhiệm 33
2.7. Mẫu thích nghi 35
2.8. Mẫu bao bọc 37
2.9. Mẫu phức hợp 38
2.10. Sơ đồ mối liên kết các mẫu thiết kế 39
Chương 3 40
ỨNG DỤNG MẪU 40

Phân tích thiết kế hệ thống Quản Lý Sinh Viên 40
3.1. Mô tả bài toán 40
3.2. Phát triển hệ thống quản lý 46
3.3. Mô tả các ca sử dụng của hệ thống 53
3.4. Phân tích hệ thống 78
3.5. Hợp đồng cho các thao tác hệ thống 95
3.6. Biểu đồ lớp 106
3.7. Mô tả chi tiết các lớp đối tượng 113
3.8. Thiết kế giao diện 117
KẾT LUẬN 119
TÀI LIỆU THAM KHẢO 120


2
CHƢƠNG 1
MẪU THIẾT KẾ VÀ PHÂN TÍCH HƢỚNG MẪU
1.1. Giới thiệu chung
Chúng ta đã biết, cái khó nhất trong xây dựng phần mềm không phải là mã hoá, mà
là những quyết định thiết kế ban đầu và các quyết định đi theo từng bước trong quá
trình thiết kế. Những quyết định này ảnh hưởng tới toàn bộ quá trình xây dựng và
phát triển hệ thống cũng như các đặc trưng quan trọng của hệ thống được xây dựng :
tính dễ bảo trì, độ tin cậy, tính an toàn…
Nhận xét trên có thể làm cho nhiều nhà phát triển phần mềm không hài lòng vì họ
phần lớn là những chuyên gia mã hoá.
Chúng ta biết rằng, thiết kế là một giai đoạn có vai trò quyết định trong vòng đời
phát triển của hệ thống phần mềm. Một thiết kế tốt sẽ cho một sản phẩm tốt và nói
chung một bản thiết kế tồi sẽ ảnh hưởng tới chất lượng cuối cùng của sản phẩm. Câu
hỏi đặt ra ở đây là: làm thế nào để có được bản thiết kế tốt? Và làm thế nào để đánh
giá được một thiết kế của ta là tốt trong khi chưa có sản phẩm cuối cùng để kiểm định
từng quyết định của chúng ta trong từng giai đoạn thiết kế.

Yêu cầu về kiến trúc phần mềm đã nhận ra nghịch lý này từ rất lâu. Sự thay đổi từ
một vòng đời phát triển trong mô hình thác nước tới quá trình gia tăng của các vòng
đời nguyễn mẫu là một minh chứng đặc biệt. Trong bất kỳ một tổ chức nào thì nguyên
mẫu luôn luôn được đánh giá kỹ. Khi mà bạn không biết liệu ý tưởng của bạn có thực
hiện được không, và cố gắng làm giảm các lỗi xuất hiện khi kiểm thử thì chúng ta
biết được mọi thứ nảy sinh trong giai đoạn cuối của quá trình triển khai và mã hoá đã
có nhiều vấn đề mà ta không ý thức được từ giai đoạn thiết kế.
Thật là khó để có được một người chúng ta tin tưởng và chúng ta có thể nêu ra vấn
đề và nhận lại được các câu trả lời hữu ích như: “ tôi đã triển khai cái này trước, nó
không làm việc bởi vì…” hoặc “ Tôi đã triển khai nó trước và chỉ có cách này để thực


3
hiện nó. Hơn nữa triển khai theo cách này cũng có một số ưu điểm và một số
nhược điểm”.
Để có được đáp án tốt cho các câu hỏi đặt ra như trên, không có phương án nào tốt
hơn là xây dựng theo các mẫu thiết kế (patterns). Các mẫu này được giới thiệu để sử
dụng như một lời chỉ dẫn từ các chuyên gia. Sức mạnh thực sự đằng sau các mẫu
chính là sự trừu tượng của chúng trong thế giới thực. Kinh nghiệm của các nhà thiết
kế và phát triển phần mềm cũng như các giải pháp thiết kế đã được đưa và trong các
mẫu nhằm giảm bớt các vấn đề của pha thiết kế cho người sử dụng và phát triển sau
này. Những mẫu thiết kế đã chứa đựng những kinh nghiệm của họ và giới thiệu
chúng tới tất cả các nhà thiết kế khác bằng các định dạng mà chúng xác định những
vấn đề cần được giải quyết, và đã được giải quyết như thế nào? tại sao giải quyết bằng
cách này là tốt và những vấn đề liên quan đến quá trình triển khai các giải pháp đó.
Do đó, mẫu thiết kế chính là kinh nghiệm đúc kết của các nhà phát triển và thiết kế
phần mềm trong suốt quá trình triển khai hàng loạt các ứng dụng, sau đó được tóm
lược lại ở giai đoạn thiết kế có thể đi cùng với một vài ví dụ. Từ đó những nhà thiết
kế khác sử dụng và triển khai các mẫu cho việc phát triển của các ứng dụng mới.
Những quyết định trong pha thiết kế là nhân tố chính để phát triển ứng dụng. Chúng

ta cần phải đưa ra những quyết định thiết kế tốt. Trong thực tế, chúng ta không thể
đưa ra được quyết định thiết kế tốt trừ khi chúng ta có kinh nghiệm về các vấn đề
chúng ta đang giải quyết. Các nhà thiết kế và phát triển phần mềm có kinh nghiệm đã
chuyển những kinh nghiệm của mình thành mẫu thiết kế. Sau đó những nhà thiết kế
sau này chỉ cần tìm các mẫu phù hợp với mục đích của mình rồi áp dụng mà không
cần tốn nhiều công sức trong pha thiết kế mà vẫn đạt được mục tiêu thiết kế. Vậy,
thiết kế các mẫu giúp tăng mức độ tái sử dụng.
1.2. Chúng ta tái sử dụng cái gì?
Việc sử dụng lại phần mềm là một cách tiếp cận để xúc tiến quá trình phát triển
phần mềm. Câu hỏi đặt ra là, chúng ta có thể sử dụng lạI những cái gì? và sử dụng
như thế nào? Đã từ lâu mã lệnh là đối tượng được sử dụng lại thường xuyên nhất.


4
Trước khi phát triển một thành phần phần mềm, chúng ta tìm trên Internet những mã
nguồn mở, sau đó có thể mượn, sửa đổi và dùng lại. Việc sử dụng lại những thiết kế
thường là rất ít so với sử dụng lại mã bởi vì sự phức tạp và khó khăn trong việc xây
dựng thiết kế và khởi tạo chúng. Hơn nữa, mã hữu hình hơn thiết kế nếu như chúng ta
dùng mã đó với một chút thay đổi hoặc không thay đổi.
Tuy nhiên, không thể chắc chắn rằng chúng ta tìm được một hộp đen các thành phần
để thoả mãn tất cả các yêu cầu của chúng ta, và cũng rất mạo hiểm nếu ta sửa đổi
phần mã nguồn, vì khi sửa đổi có thể phá vỡ mối liên kết giữa các thành phần cũng
như các đặc tính chức năng ban đầu của nó. Do đó, rất nhiều nhà phát triển phần
mềm thích sử dụng lại ý tưởng của các giải pháp và họ đã thực hiện theo phương pháp
này. Những thiết kế đã được giới thiệu ở mức cao hơn trong số các mẫu của các mô
hình thiết kế và các mô hình này yêu cầu phải được cài đặt và thực thi.
Mẫu thiết kế đã thúc đẩy việc sử dụng lại các sản phẩm trong pha thiết kế bởi vì nó
đã cung cấp các mô hình thiết kế là những mô hình có thể dùng lại. Ở một phạm vi
rộng rãi, có khả năng thích nghi cao.
1.3. Biên soạn mẫu thiết kế

Khi chúng ta xem xét các công việc và những tài liệu hiện có cho các mẫu thiết kế,
chúng ta nhận thấy rằng, hầu hết công sức bỏ ra dành để tìm ra và làm tài liệu cho
các mẫu. Một phần nhỏ công việc còn lạI liên quan đến tính hệ thống của việc áp
dụng những thiết kế được sử dụng lại để triển khai các ứng dụng mới. Vấn đề đáng
được chú ý hơn là, biên soạn các mẫu thiết kế như thế nào để phát triển phần mềm và
tiếp cận cách kết hợp chúng như thế nào để có được nhiều sự hỗ trợ từ các mô hình
thiết kế với ngôn ngữ mô hình hoá thống nhất ( Unified Modeling Lauguge – UML).
Nói chung, có thể phân loại những cách tiếp cận để thiết kế các ứng dụng có sử
dụng mẫu theo các khía cạnh sau:


5
1.3.1. Xác định hay tuỳ hứng
Một mẫu thiết kế cung cấp một giải pháp cùng với tập hợp các đối tượng và các hệ
quả nhằm áp dụng giải pháp này
1.3.2. Có tính hệ thống
Một cách tiếp cận có hệ thống để thiết kế các mẫu là chỉ cần áp dụng theo trình tự
một mẫu nhất định. Cách tiếp cận hệ thống được phân loại như sau:
1.3.2.1. Ngôn ngữ mẫu
Một ngôn ngữ mẫu cung cấp một tập hợp các mẫu, chúng giải quyết các vấn đề
trong một miền đặc biệt. Những ngôn ngữ mẫu không chỉ cung cấp một tập hợp các
mẫu mà còn cung cấp mối quan hệ giữa các mẫu này. Chúng đưa ra các tiến trình để
áp dụng ngôn ngữ nhằm giải quyết hoàn toàn một tập hợp cụ thể của các vấn đề thiết
kế.
1.3.2.2. Phát triển tiến trình
Một tiến trình phát triển có hệ thống định nghĩa một cách tiếp cận các mẫu hợp
thành, các bước phân tích và thiết kế, thiết kế các mẫu, và các công cụ để tự động hoá
các bước phát triển.
Chúng ta chấp nhận một tiến trình phát triển có tính hệ thống để phát triển các mẫu,
đó là cách duy nhất để làm các mẫu thiết kế cho một yêu cầu chung trong phát triển

phần mềm nhằm cải thiện của quá trình thực thi các mẫu thiết kế có tính hệ thống
trong phát triển phần mềm mà chúng ta cần tới
Định nghĩa kỹ thuật hợp thành có thể sử dụng để xây dựng các ứng dụng bằng quá
trình biên soạn những mẫu thiết kế và hỗ trợ những kỹ thuật hợp thành với những
mô hình ngôn ngữ riêng và các khung nhìn.


6
1.4. Các thành phần của mẫu thiết kế
Mỗi mẫu thiết kế (Design Pattern) 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:
1.4.1. Tên mẫu
Tên mẫu (Design Pattern Name) là tên gọi qua đó ta có thể hình dung được bài toán
cần giải quyết và 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. 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ế "Facade " , ta hình
dung ngay đến mô hình thiết kế một đối tượng với vai trò “interfacce” của một tập các
thành phần nhỏ hơn.
1.4.2. Vấn đề
Vấn đề (Problem) cho phép xác định trong trường hợp nào thì áp dụng mẫu thông
qua mô tả bài toán và ngữ cảnh của bài toán đó.
1.4.3. Giải pháp
Giải pháp (Solution) mô tả những thành phần tạo nên mẫu thiết kế cùng mối quan
hệ, vai trò và cách thức phối hợp giữa chúng. 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.
1.4.4. Hệ quả

Hệ quả (Consequences) cho thấy việc áp dụng các giải pháp để giải quyết những vấn
đề có hiệu quả hay không. Nói cách khác, hệ quả đặt ra cho bạn cách lựa chọn, từ đó
bạn có thể xem xét lựa chọn nào là phù hợp nhất, tốt nhất.


7
1.5. Mô tả mẫu thiết kế
Cách thức mô tả góp phần quan trọng trong việc hiểu và áp dụng mẫu thiết kế.
Những tiêu chí cơ bản trong mô tả các mẫu thiết kế bao gồm: đơn giản, chính xác và
đầy đủ. Như vậy, cần có một khuôn dạng mô tả thích hợp để đáp ứng các mẫu thiết kế
khác nhau. Đồng thời, khuôn dạng này cũng cho phép người xây dựng và người sử
dụng có chung một cách nhìn và tiếp cận đối với mẫu thiết kế.
Theo GOF (Gang of Five), một mẫu thiết kế được mô tả với các nội dung sau:
1.5.1. Tên gọi và phân loại
Tên gọi cần chuyển tải những yếu tố căn bản nhất của mẫu thiết kế, thường tên gọi
chỉ bao gồm một đến hai từ. Hơn nữa, tên gọi của mẫu thiết kế sẽ trở thành một phần
trong bộ từ vựng để trao đổi về các mô hình thiết kế nên cần cân nhắc và lựa chọn kỹ
lưỡng. Việc phân loại cho phép xác định mẫu thiết kế thuộc nhóm nào. Theo GOF,
các mẫu thiết kế đựơc phân thành ba nhóm: nhóm mẫu tạo(creational), nhóm cấu
trúc(structural) và nhóm hành vi (behavioral).
1.5.2. Mục đích
Mẫu thiết kế cho biết:
— Mẫu thiết kế có chức năng gì.
— Lý do và mục đích của mẫu thiết kế
— Mẫu thiết kế giải quyết bài toán cụ thể nào.
1.5.3. Các tên gọi khác
Một mẫu thiết kế có thể có nhiều tên gọi khác nhau tuỳ theo cách gọi tên của người
thiết kế . Ví dụ, với mẫu thiết kế Factory Method, người ta có thể gọi nó với tên
Virtual Constructor. Cả hai tên gọi trên đều đúng để chỉ mô hình thiết kế với việc tạo
ra một giao diện trong việc khởi tạo các đối tượng và việc tạo đối tượng cụ thể thì do

các lớp triển khai giao diện này thực hiện.


8
1.5.4. Lý do sử dụng
Mẫu chỉ ra một ngữ cảnh trong đó mô tả bài toán thiết kế gặp phải và cách thức giải
quyết vấn đề của các lớp, đối tượng được thiết kế theo mẫu.
1.5.5. Khả năng áp dụng
Mẫu cho biết có thể áp dụng trong trường hợp nào. Đồng thời, chỉ ra những trường
hợp thiết kế chưa tốt mà mẫu có thể khắc phục được cùng với cách nhận biết những
lỗi thiết kế đó.
1.5.6. Cấu Trúc
Cấu trúc mẫu là mô tả bằng hình ảnh của các đối tượng được sử dụng trong thiết kế
mẫu.
Các thành phần tham gia, các lớp/ đối tượng tham gia vào mẫu và vai trò của chúng.
1.5.7. Kết Quả
Mẫu cho biết:
– Thiết kế mẫu này có tác động thế nào tới mục tiêu thiết kế.
– Những ràng buộc giữa các yếu tố và kết quả trong mẫu.
– Những yếu tố của kiến trúc hệ thống có thể thay đổi mà không ảnh hưởng
đến thiết kế mẫu.
1.5.8.Triển Khai
Mẫu cho biết:
– Những khó khăn, những dấu hiệu hoặc những công nghệ cần phải lưu ý
khi triển khai mô hình.
– Có những yếu tố phụ thuộc vào từng ngôn ngữ cụ thể hay không.


9
1.6 .Thiết kế hƣớng mẫu

Trong khi một ý tưởng lớn của nghiên cứu và thực tiễn đã được triển khai để tìm ra
mẫu dáng thiết kế mới thì có rất ít những vấn đề liên quan tới các tiến trình có tính hệ
thống của sự gắn kết và soạn thảo các mẫu dáng thiết kế để phát triển các ứng dụng
phần mềm. Chương này sẽ đặc biệt hướng vào vấn đề này đồng thời cung cấp một
phương pháp luận thực hành để biên soạn và triển khai những mẫu thiết kế.
Phân tích và thiết kế hướng mẫu (Pattern – Oriented Analysis and Design- POAD)
là một cách tiếp cận kiến trúc cấu thành nhằm gắn kết các mẫu ở mức thiết kế. Nó sử
dụng các khái niệm của cấu trúc các mẫu thiết kế như là các thành phần thiết kế với
các giao diện.
Phân tích và thiết kế hướng mẫu dựa trên tiền đề là: tại một mức thiết kế nào đó,
người ta biết các mẫu có thể sử dụng được trong ứng dụng và nó thực sự không lấn át
công việc của người thiết kế với những chi tiết của thiết kế bên trong mỗi mẫu.
1.6.1. Vai trò của mẫu trong phát triển phần mềm
Khi sự phức tạp của các hệ thống phần mềm gia tăng, chúng ta tìm kiếm cách tiếp
cận để làm đơn giản hoá sự phát triển của các ứng dụng phần mềm. Các mẫu thiết kế
hứa hẹn sớm đem lại lợi ích của việc tái sử dụng trong vòng đời phát triển. Để có
được lợi ích trong quá trình triển khai những giải pháp thiết kế đã được khẳng định
này, chúng ta cần phải định nghĩa các kỹ thuật cấu thành thiết kế để xây dựng ứng
dụng sử dụng các mẫu. Những mô hình thiết kế linh hoạt cần phải được phát triển để
hỗ trợ cho kỹ thuật này.
Tái sử dụng phần mềm trong các ứng dụng thực tế là một nhiệm vụ khó và nó thực
sự quan trọng để giảm bớt công sức phát triển và đảm bảo chất lượng phần mềm cao
hơn. Các mẫu thiết kế có tác dụng thúc đẩy trong việc sử dụng lại các sản phẩm trong
pha thiết kế, bởi vì chúng cung cấp một tập hợp các từ vựng thông thường cho thiết
kế. Chúng còn cung cấp một ngữ nghĩa giúp cho việc hiểu các thiết kế và chúng chỉ ra
các khối xây dựng từ các ứng dụng phức tạp hơn đã được xây dựng. Sự tập hợp từ
nhiều danh mục mẫu sẵn có đã khuyến khích hình thành các ý tưởng xa hơn về việc


10

làm sao để sử dụng những giải pháp có thể tin cậy được để phát triển các ứng dụng.
Các nhà nghiên cứu và thiết kế có kinh nghiệm đã mất nhiều công sức trong việc làm
tài liệu có chất lượng thực tế cao trong thiết kế phần mềm như những mẫu thiết kế.
Trong khi có rất nhiều sự chú ý được quan tâm để tìm và làm tài liệu cho các mẫu
thiết kế, thì các kỹ thuật để triển khai và gắn kết các giải pháp thiết kế đã được chứng
minh này vẫn còn thiếu các hệ thống hỗ trợ.
Thiết kế các ứng dụng bằng cách triển khai có hệ thống các mẫu thiết kế không
phải là một quá trình bình thường. Mặc dù cách tiếp cận cho thiết kế sử dụng công
nghệ mẫu cấu thành đã được đề xướng, nhưng còn thiếu tiến trình hệ thống làm
chúng nhanh tới đích.
1.6.2. Mục đích của phân tích thiết kế hướng mẫu
Khi yêu cầu về các hệ thống phần mềm tăng, các nhà nghiên cứu cũng như các nhà
thực hành đã tìm kiếm các phương pháp luận và công nghệ để tự động hoá quá trình
sản xuất phần mềm và làm thuận lợi qúa trình bảo trì hệ thống. Những công nghệ này
xuất hiện gần đây bao gồm các mẫu thiết kế và các khung làm việc. Trường hợp đặc
biệt, trong cùng một khoảng thời gian chúng ta nhận thấy sự cần thiết của một phương
pháp luận phát triển để phát triển các hệ thống phức tạp với qui mô lớn, và học được
kinh nghiệm của các nhà thiết kế hệ thống khác trong việc giải quyết các vấn đề lặp
lại của thiết kế.
Tài liệu của mẫu thiết kế miêu tả chi tiết về một mẫu như: cách dùng, cấu trúc, hành
vi của những người tham gia, những phần tử, những hệ quả, và những nguyên tắc chỉ
đạo cho việc triển khai. Chúng ta hiểu lỗi là gì, làm sao để biên soạn những mẫu này
để phát triển các ứng dụng. Một hệ thống hoàn chỉnh không thể và cũng không bao
giờ được xây dựng từ một mẫu đơn. Nó là sự hợp nhất và cấu thành của nhiều mẫu
mà xây dựng lên một hệ thống hoàn chỉnh.
Chúng ta có thể soạn các mẫu ở cùng một mức của lớp hoặc một mức của đối
tượng. Các mô hình lớp trình bày khía cạnh triển khai và bảo trì của một mẫu. Trong
khi các mô hình đối tượng trình bày về sự thực hiện, hành vi và khía cạnh vai trò.
Các nhà nghiên cứu và các nhà thực thi quan tâm tơi vấn đề kết hợp sử dụng vai trò

11
các mẫu và mô hình nghiệp vụ. Các vấn đề của soạn mẫu như các lớp thành phần ít
được chú ý hơn. Chúng ta tin rằng, các mẫu không chỉ nói về các hành vi hoặc các vai
trò mà các khía cạnh cấu trúc là một vấn đề mà chúng ta đã sử dụng trong phương
pháp lập trình truyền thống với ngôn ngữ lập trình hướng đối tượng. Tuy nhiên, nó dễ
hiểu hơn mối quan hệ giữa các đối tượng sử dụng các mô hình hành vi, nó cũng dễ
hơn để thực hiện các hành vi đó nếu chúng ta có mô hình cấu trúc của các lớp và mối
quan hệ của chúng. Còn tuyệt vời hơn nếu các nhà thiết kế và phát triển vẫn sử dụng
các ngôn ngữ lập trình hướng đối tượng như C++, java và quả thật là không hấp dẫn
nếu họ sử dụng các ngôn ngữ cấu trúc không chuẩn khác. Bởi vậy, tiếp cận một mẫu
hợp thành có sử dụng các mô hình cấu trúc có ánh xạ 1-1 tới cấu trúc chương trình
như mô hình lớp là cần thiết.
Mục đích của phân tích và thiết kế hướng mẫu là đẩy mạnh quá trình phát triển trên
nền mẫu. Chúng ta đang tìm kiếm những cách sao cho nhiều nhà thiết kế sử dụng
nhiều các mẫu hơn. Chúng ta muốn thu hút những nhà thiết kế mới để giúp họ sử
dụng các mẫu một cách đơn giản theo từng tiến trình của họ. Đẩy mạnh sự phát phát
triển trên nền mẫu chúng ta cần định nghĩa những cách tiếp cận cấu thành dễ sử dụng.
Phát triển các cách tiếp cận có hệ thống để gắn kết các mẫu: Một nhu cầu ngày càng
cấp thiết là phát triển những cách tiếp cận các thành phần một cách hệ thống nhằm
làm đơn giản hoá quá trình kết hợp các mẫu. Các mô hình làm đơn giản quá trình kết
hợp giữa các mẫu trong pha thiết kế phải được phát triển để hỗ trợ cho cách tiếp cận
này.
Phát triển thiết kế các khung làm việc: Chúng ta có thể làm đơn giản hoá sự phát
triển của các khung thiết kế bằng cách sử dụng các mẫu như các khối thiết kế hợp
nhất.
Cải thiện chất lượng thiết kế: Các mẫu thiết kế là những thiết kế có chất lượng tốt.
Việc sử dụng lại những mẫu trong một thiết kế được định trước để cải thiện chất
lượng thiết kế của các ứng dụng phần mềm được xây dựng nhờ sử dụng những mẫu
như những khối hợp nhất cơ bản của họ.

12
1.6.3. Những vấn đề thiết kế hướng mẫu
Để thúc đẩy sự phát triển của các mẫu cơ sở và xây dựng các cách tiếp cận mới để
biên soạn các mẫu thì chúng ta còn phải đương đầu với rất nhiều thách thức:
Cái gì là cơ sở để phân loại mẫu như một thành phần thiết kế? Để sử dụng các mẫu
như là một khối hợp nhất chúng ta cần phải tìm ra các đặc trưng mà mẫu được phân
lọai như một thành phân thiết kế. Làm sao chúng ta có thể định nghĩa những giao diện
mẫu cho mục đích hợp nhất với các mẫu khác. Chúng ta có thể biên soạn những ứng
dụng đơn độc từ các mẫu thiết kế? Nhiều ứng dụng sử dụng một hoặc nhiều mẫu
trong khi thiết kế. Thách thức ở đây là liệu các ứng dụng có thể xây dựng bằng cách
kết hợp các mẫu thiết kế không? Giao diện của các mẫu này như thế nào? giao diện
của các mẫu là gì? và giao diện nào không thích ứng với những vấn đề có thể xuất
hiện? Các loại mẫu gì được sử dụng? Chúng ta phát triển các ứng dụng có sử dụng
các mẫu thiết kế một cách hệ thống như thế nào? Có tiến trình thiết kế tốt để phát
triển các ứng dụng sử dụng các mẫu đã thiết kế như những khối hợp nhất không?









1.7. Phân tích thiết kế hƣớng đối tƣợng là một giải pháp
Chúng ta phát triển phân tích thiết kế hướng đối tượng để giải quyết các vấn đề nêu
trên. Trong phân tích thiết kế hướng đối tượng, các mẫu liên quan đến thiết kế mức
cao, và những phần tử của chúng được kết hợp trong các giai đoạn thiết kế kế tiếp để

Chúng giao tiếp như thế nào?
Người quan sát mẫu
Mẫuchiến lược
Mẫu trạng thái
Hình1.1 Có thể soạn thảo các thiết kế bằng việc sử dụng các mẫu thiết kế không?


13
đạt được thiết kế đầy đủ và chính xác. Cách tiếp cận phân tích thiết kế hướng đối
tượng cung cấp các giải pháp sau.
1.7.1. Mô hình mẫu cho các thành phần thiết kế
Từ khi các mẫu được coi là các khối hợp nhất của thiết kế hướng mẫu, thì trước hết
chúng ta cần phải sở hữu các đặc trưng của một thành phần, tức là khả năng soạn mẫu
trong giai đoạn thiết kế. Yêu cầu định nghĩa giao diện mẫu và những thuộc tính mẫu
cần thiết để cho phép mẫu trở thành một thành phần thiết kế. POAD định nghĩa một
kiểu những mẫu đặc biệt gọi là: cấu trúc mẫu thiết kế , định nghĩa nhiều mức trừu
tượng và khung nhìn logic trong thiết kế với cấu trúc các mẫu. POAD cũng định
nghĩa cách làm thế nào để những mức thiết kế hiện thời có thể lần vết được tới những
mức thiết kế thấp hơn dưới dạng các lớp.
1.7.2. Một phương pháp luận thiết kế
Chúng ta thảo luận một phương pháp luận thiết kế để xây dựng những thiết kế
hướng mẫu. POAD là một minh chứng rõ ràng về việc học các mẫu như là một vấn đề
cốt lõi của các khối hợp nhất trong thiết kế hướng đối tượng. Trong POAD chúng ta
học từ kinh nghiệm của phương pháp phân tích thiết kế hướng đối tượng và định
nghĩa một phương thức hướng mẫu mới dựa trên cú pháp và ngữ nghĩa của ngôn ngữ
UML. Chúng ta gọi những thiết kế phát triển ứng dụng theo phương pháp này là:
thiết kế hướng mẫu
1.7.3. Ứng dụng POAD trong thế giới thực
Mục tiêu chính của POAD là cung cấp một giải pháp để cải thiện thực tiễn của việc
triển khai mẫu thiết kế một cách có hệ thống trong phát triển ứng dụng. Chúng ta tin

tưởng rằng, các vấn đề phải được phát hiện và ngăn chặn ngay trong pha phân tích và
pha thiết kế của vòng đời phát triển. Cách tiếp cận mà chúng ta sử dụng để phát triển
phương pháp luận POAD để xây dựng các khối thiết kế hướng đối tượng có sử dụng
các mẫu thiết kế như những khối hợp nhất của nó. Có ba vấn đề chính là: công nghệ,
tiến trình, và các khía cạnh tổ chức.


14
1.7.3.1. Các khía cạnh công nghệ
Đây là vấn đề xác định nền tảng của phương pháp thiết kế, nó bao gồm các khái
niệm, các ký pháp, các mô hình trực quan và hình thức. Các định nghĩa về mô hình
trực quan được sử dụng để gắn kết cấu trúc các mẫu nhằm phát triển thiết kế hướng
mẫu. Ở đây sẽ giới thiệu các khái niệm của giao diện mẫu và thảo luận về mối liên
hệ của các thành phần và kiến trúc phần mềm cho mục đích này. Ở đây cũng thảo
luận về cú pháp và ngữ nghĩa của UML cung cấp cho phương pháp luận POAD.
1.7.3.2. Khía cạnh xử lý
Khía cạnh này xác định nghĩa nhiệm vụ và các bước cần thiết để phát triển thiết kế
hướng mẫu. Dựa vào các mô hình trực quan, sự phân tích và bước thiết kế đựơc xác
định, sản phẩm đầu ra và phân phối chúng trong mỗi bước cũng được xác định.
1.7.3.2. Các Khía cạnh tổ chức
Vấn đề này được xác định như thế nào để việc tổ chức thực hiện đạt được hiệu quả
mà phương pháp đem lại.
1.8. Mẫu thiết kế và kỹ nghệ phần mềm
1.8.1. Những mẫu thiết kế trong vòng đời phát triển phần mềm
Nhiều người thiết kế ứng dụng được khuyến khích để dùng những thành phần có thể
sử dụng lại nhằm giảm công sức và thời gian phát triển phần mềm. Mức độ sử dụng
lại được quyết định bởi những nhà tham gia phát triển ứng dụng. Một quyết định thiết
kế đơn giản như việc sử dụng lại một thư viện lớp hoặc một giao diện lập trình ứng
dụng(API) là những thứ thông thường nhất và dễ sử dụng. Một mức phức tạp hơn của
sử dụng lại là sử dụng lại những mẫu và những khung làm việc, trong đó người thiết

kế có sẵn một tập hợp rất nhiều mẫu với nội dung rộng hơn rất nhiều so với những
quyết định thiết kế cần thiết.
Bất kỳ một vòng đời phát triển phần mềm nào cũng bao gồm một số pha phát triển:
phân tích, thiết kế, trình bày chi tiết thiết kế, triển khai và kiểm thử. Các mẫu có thể


15
đóng một vai trò quan trọng trong một hoặc trong mọi pha của vòng đời phát triển
phần mềm. Tuy nhiên, các mẫu đầu tiên được giới thiệu chỉ nhằm phục vụ vấn đề sử
dụng lại trong pha thiết kế. Nhưng rất nhiều nhà triển khai đã tận dụng lợi ích của
mẫu trong tất cả các pha của vòng đời phát triển phần mềm.
Các mẫu thiết kế sẽ tồn tại rất lâu. Càng nhiều nhà thiết kế và nhà phát triển dùng
các mẫu thì họ càng được thuyết phục rằng, chúng phải là một quá trình bộ phận được
hợp thành từ bất kỳ một tiến trình phát triển phần mềm nào. Tính đa dạng của các ứng
dụng với các mẫu được sử dụng và sự hữu ích của chúng là bằng chứng cụ thể về
tính bền vững của những mẫu thiết kế.
Phiên bản tiếp theo của các ứng dụng hướng đối tượng và các khung làm việc sẽ
chứa các mẫu rõ ràng. Các mẫu cũng sẽ tiếp tục được sử dụng để làm tài liệu mẫu và
nội dung của các khung làm việc. Những miền và những chủ đề chính khác cũng đem
lại nhiều lợi ích từ quá trình tập hợp các mẫu nhỏ cụ thể như sau:
a. Phân phối các đối tượng: Những ứng dụng tính toán song song và các đối
tượng được nối mạng đã làm được tài liệu trong thập niên qua.
b. Các hệ thống thời gian thực và các hệ thống nhúng: Một số lượng lớn các hệ
thống tính toán gia tăng là hệ thống nhúng, chúng bao gồm các hệ thống điều khiển tự
động, các ứng dụng dựa trên các ứng dụng của ô tô, phần mềm điều khiển cho các thiết
bị tự động hoá nhà máy và các thiết bị tính toán cầm tay. Rất nhiều hệ thống trong số
các hệ thống này là đối tượng của việc tính toán chặt chẽ các tài nguyên hạn hẹp. Đặc
biệt là vấn đề lần vết và thời gian đã sử dụng trước đó.
Phát triển các hệ thống nhúng và hệ thống thời gian thực với chất lượng cao là một
điều rất khó và nó hơi nghiêng về “nghệ thuật đen”.

Với khuynh hướng gia tăng trong việc khám phá và thiết kế các mẫu trong nhiều
miền ứng dụng, sự phổ biến ngày càng tăng của việc áp dụng mẫu trong phát triển
phần mềm, những phương pháp phát triển phần mềm là rất quan trọng.


16
1.8.2. POAD và công nghệ hướng đối tượng
Trong hai thập niên trước, chỉ có vài phương pháp luận phân tích và thiết kế hướng
đối tượng được giới thiệu. Trong thời gian gần đây có rất nhiều phương pháp luận
phân tích thiết kế hướng đối tượng khác đã được đưa ra. Các phương pháp này chỉ
khác nhau trong cách tiếp cận không gian miền và tạo ra các mẫu phân tích và thiết kế
và chúng cũng khác nhau trong loại mô hình mà chúng tạo ra.
Sự đa dạng của phương pháp phân tích và thiết kế hướng đối tượng đã thúc đẩy sự
phát triển của ngôn ngữ mô hình hóa thống nhất(UML) như là một ngôn ngữ để chi
tiết hoá, làm trực quan, có cấu trúc và cung cấp những tài liệu đặc tả của các hệ thống
phần mềm cũng như cho các mô hình nghiệp vụ và các hệ thống không phần mềm
khác. Trước UML, đã có vài ngôn ngữ mô hình, hầu hết chúng chia sẻ một tập hợp
các khái niệm đã được công nhận và được biểu diễn khác nhau.
UML không chỉ là một ngôn ngữ trực quan để miêu tả, mà nó còn có cả cú pháp và
khả năng ngữ nghĩa. Các ký pháp của UML đại diện cho cú pháp đồ hoạ để biểu thị
ngữ nghĩa được miêu tả siêu mô hình UML cơ sở.
Siêu mô hình UML cung cấp định nghĩa rõ ràng và chung cả về cú pháp và ngữ
nghĩa của các phần tử trong UML.
a. Biểu đồ ca sử dụng (Use case diagram): Một ca sử dụng định nghĩa một kịch
bản mà hệ thống được sử dụng, đầu vào và đầu ra có thể của nó. Ca sử dụng là để phân
tích và sản sinh ra những kịch bản có thể. Tập hợp các kịch bản là một khía cạnh đặc
tả yêu cầu của ứng dụng. Biểu đồ ca sử dụng là các mô hình được sử dụng bởi các nhà
phân tích đại diện cho tất cả các cách dùng có thể của ứng dụng. Biểu đồ còn đưa ra
mối quan hệ giữa các ca sử dụng và từ đó thiết lập các mối quan hệ giữa các chức năng
của các ứng dụng.

b. Biểu đồ lớp (Class diagram): Một biểu đồ lớp mô tả một khía cạnh cấu trúc của
ứng dụng. Nó là một đại diện cho các lớp có thể và mối quan hệ giữa các lớp đó.
Biểu đồ lớp chi tiết đưa ra chi tiết về thiết kế, chúng bao gồm các thuộc tính, kiểu,


17
phương thức của chúng. Biểu đồ lớp là những mô hình cấu trúc quan trọng tới bất kỳ
phương pháp luận của phân tích thiết kế hướng đối tượng nào, một khi tất cả các
ngôn ngữ lập trình hướng đối tượng cung cấp sự hỗ trợ trực tiếp cho các phần tử có
mặt trong biểu đồ lớp.
c. Biểu đồ hoạt động (Activity diagram): Nó chỉ ra luồng đi từ hoạt động này sang
hoạt động khác trong hệ thống. Nó đặc biệt quan trong trong việc xây dựng mô hình
chức năng của hệ thống và nhấn mạnh tới việc chuyển đổi điều khiển giữa các đối
tượng. Những biểu đồ này giải thích các khía cạnh hành vi của các ứng dụng.
d. Biểu đồ trạng thái (State diagram): Các sơ đồ trạng thái là kỹ thuật để mô hình
hoá các hành vi trong các hệ thống lớn và phức tạp.
e. Biểu đồ tương tác (Interaction diagram): Biểu đồ tương tác bao gồm biểu đồ
tuần tự hoặc biểu đồ cộng tác :
– Biểu đồ tuần tự (Sequence diagram): Những sơ đồ kịch bản đối tượng là phương
tiện để ghi những quyết định thiết kế bằng việc khảo sát sự tương tác giữa các
đối tượng trong ứng dụng theo thời gian, theo ứng xử. Thông thường có một
hoặc nhiều kịch bản cho mỗi ca sử dụng.
– Biểu đồ cộng tác (Collaboration diagram): là kịch bản khác không tính đến các
yêu cầu tuần tự theo thời gian. Mục tiêu của biểu đồ là chỉ ra các đối tượng
tương tác với nhau như thế nào và việc gửi các thông điệp cho nhau.
g. Biểu đồ triển khai(Implementation diagram): Những biều đồ triển khai diễn đạt
kịch bản theo thời gian của ứng dụng. Biểu đồ triển khai cho biết kiến trúc vật lý của
hệ thống dưới dạng các node và mối liên hệ của chúng. Những biểu đồ triển khai có
liên quan tới các biểu đồ thành phần bên trong một nút tiêu biểu của một hay nhiều
hơn thành phần. Những phương tiện được cung cấp để xác định những thành phần

nào sẽ được thực thi trên những máy nào.
h. Biểu đồ thành phần (Component diagram): Một biểu đồ thành phần cho thấy
những thành phần ứng dụng và cách mà chúng tương tác với nhau. Nó miêu tả một
khía cạnh tĩnh của hệ thống. Biểu đồ các thành phần liên quan tới các biểu đồ lớp


18
trong một thành phần liên kết tiêu biểu tới một hoặc nhiều lớp, giao diện hoặc cộng
tác. Các thành phần được sử dụng để mô hình những phần có thể thực thi và các ứng
dụng và mối quan hệ của chúng theo khía cạnh thời gian vận hành.
1.8.3. Mẫu thiết kế
Trong quá trình phát triển phần mềm hiện đại, kiến trúc tổng thể của dự án đóng một
vai trò quan trọng, đặc biệt là khung làm việc (framework) và mẫu thiết kế.
1.8.3.1. Mẫu là gì?
Nhìn chung, một mẫu là mô tả các vấn đề thường xuyên xuất hiện trong thiết kế,
triển khai phần mềm và các giải pháp cho nó theo cách có thể sử dụng lại được.
Những mẫu thiết c ó ý nghĩa thực tế tốt chúng là phương tiện thiết kế để làm tài liệu
là những mẫu thiết kế thực tế tốt, chúng là phương tiện để truyền đạt kiến thức và
những kinh nghiệm của các chuyên gia cho những người mới học.
Mẫu còn mô tả một giải pháp chung đối với một vấn đề nào đó trong thiết kế thường
được “lặp lại” trong nhiều dự án. Nói một cách khác, một mẫu có thể được xem như
một “khuôn dạng” có sẵn có thể áp dụng được cho nhiều tình huống khác nhau để giải
quyết một vấn đề cụ thể. Trong bất kỳ hệ thống phần mềm hướng đối tượng nào
chúng ta cũng có thể bắt gặp các vấn đề lặp lại.
a. Các mẫu mẫu phân tích
Các mẫu mẫu phân tích (Analysis Patterns) là để hiểu các vấn đề từ các yêu cầu bên
ngoài. Martin Fowler đã định nghĩa các mẫu phân tích như “ Nhóm những khái niệm
được đại diện cho một cấu trúc chung trong các mô hình nghiệp vụ”.
b. Các mẫu kiến trúc
Các mẫu kiến trúc (Structual Patterns) mô tả một cơ sở của sơ đồ tổ chức với cấu

trúc cơ bản cho hệ thống phần mềm. Nó cung cấp một tập hợp các tiền định nghĩa về
các hệ thống con hoặc các thành phần. Đồng thời chỉ rõ trách nhiệm của các thành
phần đó cùng các qui tắc và các nguyên tắc cho việc tạo lập mối quan hệ giữa chúng.


19
Những mẫu kiến trúc là phương tiện của kiến trúc cung cấp tài liệu cho những hệ
thống hỗn tạp và phức tạp, do đó nó giúp quản lý các ứng dụng phức tạp.
c. Mẫu thiết kế
Mẫu thiết kế (Design pettern) cung cấp một sơ đồ để làm mịn các hệ thống con, các
thành phần của một hệ thống phần mềm hoặc mối quan hệ giữa chúng. Nó mô tả một
cấu trúc xác định thông thường của những thành phần truyền thông mà chúng giải
quyết một vấn đề thiết kế chung trong một ngữ cảnh đặc biệt. Chiến lược trạng thái và
uỷ nhiệm mẫu là những ví dụ cho phạm trù này.
d. Thành ngữ
Thành ngữ (idoms) là một mẫu đặc biệt mức thấp cho một ngôn ngữ lập trình. Một
thành ngữ miêu tả làm sao để thực hiện những khía cạnh đặc biệt của thành phần hoặc
mối quan hệ giữa chúng khi sử dụng những đặc tính của một ngôn ngữ lập trình đã
cho như: C++, java hoặc smalltalk.
Những mẫu là các kinh nghiệm thiết kế đã được kiểm chứng. Phần lớn những mẫu
được tìm ra hoặc được làm tài liệu các mẫu được xây dựng lên từ nhiều dự án đã có
trong thực tế hơn là những mẫu được sáng chế ra. Các mẫu là cách mô tả ngắn gọn và
hiệu quả để truyền đạt những khái niệm và kinh nghiệm của các nhà phát triển từ các
vấn đề thực tế.
1.8.3.2. Lịch sử các mẫu
Ý tưởng của mẫu phần mềm được phát triển rất đa dạng. Kiến trúc sư Christopher
Alexander trường đại học California ở Berkeley là người phát triển nền tảng của mẫu.
Từ “mẫu” đã gần như gắn liền với sự nghiệp hoạt động của giáo sư. Giáo sư và nhóm
nghiên cứu của ông đã mất khoảng hơn 20 năm để phát triển một cách tiệp cận tới
các kiến trúc thông thường có sử dụng các mẫu. Alexander đã giới thiệu hơn 250 mẫu

với nhiều mức độ trừu tượng từ kiến trúc của một thành phố đến các thiết kế phòng.
Kiến trúc sư đã thành lập khung mẫu miêu tả cơ bản của một mẫu như một giải pháp


20
của vấn đề ở mức ngữ cảnh. Ông đã phát triển một nguyên mẫu từ các mẫu dùng
trong công việc của ông về công việc kiến trúc.
Kent Beck và Ward Cunningham[1] đã rất say mê áp dụng ý tưởng của Alexander
để phát triển các mẫu phần mềm. Họ đã tập hợp các mẫu đầu tiên nói về đặc tả giao
diện người dùng. Kent tập trung vào các thành ngữ cho Smalltalk và Ward diễn đạt
kinh nghiệm của mình bằng các hệ thông nghiệp vụ( hệ thống kế toán)
Erich Gamma đã xuất bản ấn phẩm đầu tiên về vấn đề sử dụng các mẫu trong phát
triển phần mềm năm 1991. Cuốn sách được viết ở Đức, nhưng cuốn sách này không
được chú ý nhiều. Bruce Anderson là một trong những nhà lãnh đạo trong cộng đồng
mẫu. Ông thành lập một ngân hàng mẫu ở OOPSLA vào đầu những năm 1990. Jim
Coplien miêu tả thành ngữ trên C++ trong quyển lập trình C++ tiên tiến . Theo một
cách nào đó, những thành ngữ này có liên quan tới ý tưởng của những giải pháp cung
cấp tài liệu cho những vấn đề thường xuyên. Một nhóm có tên là Hillside Group được
hình thành nhằm thăm dò sâu hơn những ý tưởng này và thúc đẩy sử dụng mẫu trong
quá trình phát triển phần mềm. Họ xây dựng mẫu nhằm dẫn dắt và hỗ trợ những thành
viên mới trong cộng đồng mẫu. Nhóm này được hình thành đầu tiên với tên PLOP
vào năm 1994.
Những kiến thức cơ bản của quá trình phát triển mẫu được Gang of Four (GoF)
xuất bản trong cuốn: những mẫu thiết kế: Những phần tử của phần mềm hướng đối
tượng đã được giới thiệu và được miêu tả dễ hiểu với mẫu thiết kế hướng đối tượng.
Gamma, Helm, Johnson, and Vlissides' work là đại diện cho lĩnh vực phân loại những
giải pháp thiết kế và việc sử dụng thông thường bên trong mẫu hướng đối tượng. Họ
xây dựng một tập hợp gồm 23 mẫu chia làm 3 phạm trù: theo hành vi, theo cấu trúc,
theo kiến tạo.
Peter Coad gần đây cũng nghiên cứu về các mẫu hướng đối tượng. Trong đó, ông đã

mô tả 7 loại mẫu cơ bản trong phân tích và thiết kế hướng đối tượng. Ông làm việc
dựa trên các mẫu, tức là nhờ vào việc phân tích một ứng dụng của miền đã được đưa
ra và sử dụng công nghệ hướng đối tượng để xây dựng các ứng dụng. Douglas
Schmidt cũng là một người dẫn đắt những người mới tham gia vào lĩnh vực dùng