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

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

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

Incidental or ad hoc Sự xác định hay tuỳ hứng

Structual Patterns Các mẫu cấu trúc

Collaboration diagram Biểu đồ cộng tác

Implementation diagram Biểu đồ thực thi

Abstract factory pattern Mẫu chế tạo trừu tượng

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

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.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.39 Giao diện cập nhật sinh viên

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

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

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

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:

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

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.

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

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

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

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

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

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ò

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

như những khối hợp nhất cơ bản của họ

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?

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?

đạ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

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ể

đó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

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,

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

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

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

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

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

mẫu Ông là tác giả của rất nhiều mẫu trong lĩnh vực các hệ thống truyền thông và các

ứng dụng phân tán

Douglas Schmidt đã làm việc trên mẫu về các ứng dụng cho vấn đề phát triển khung làm việc Ông đã tạo ra các yếu tố cơ bản của cấu trúc vào trong các siêu mẫu được sử dụng để phát triển các khung làm việc và điền địa chỉ Hot- Sport và Hooks/templates

tiếp cận trong việc phát triển khung làm việc

Kiến trúc phần mềm hướng mẫu: Một hệ thống mẫu còn được gọi “Gang of five”, hướng vào việc sử dụng các mẫu ở mức kiến trúc trong quá trình phát triển phần mềm Những tác giả phân loại các mẫu phần mềm như những mẫu kiến trúc, mẫu thiết kế và những thành ngữ Hầu hết sự đóng góp của họ được hướng về khía cạnh kiến trúc mẫu Những quyển sách của họ cùng với những quyển sách của Gof đánh

dấu điểm bắt đầu của những người mới trong cộng đồng mẫu

1.8.3.3 Vòng đời mẫu

Chúng ta đã sử dụng mô hình vòng đời để tăng tính tin cậy của các mẫu đã được chọn cho các thành phần thiết kế Công việc này cho thấy có sự lặp đi lặp lại có cải tiến được phát triển trên mẫu trước khi nó được làm tài liệu cho việc sử dụng lại

1.9 Đặc điểm chung của mẫu

Mẫu được hiểu theo nghĩa tái sử dụng ý tưởng hơn là mã lệnh: Mẫu cho phép các nhà thiết kế có thể cùng ngồi lại với nhau và cùng giải quyết một vấn đề nào đó mà không phải mất nhiều thời gian bàn cãi Trong rất nhiều trường hợp, dự án phần mềm

Hình 1.2 Minh hoạ vòng đời của mẫu

Các tác giả

cộng đồng xây dựng mẫu

Người dùng mẫu

thất bại là do các nhà phát triển không có được sự hiểu biết chung trong các vấn đề kiến trúc phần mềm Ngoài ra, mẫu cũng cung cấp những thuật ngữ và khái niệm chung trong thiết kế Nói một cách đơn giản, khi đề cập đến một mẫu nào đấy, bất kỳ

ai có hiểu biết về mẫu đó đều có thể nhanh chóng hình dung ra “bức tranh “ của giải pháp Và cuối cùng, nếu áp dụng mẫu hiệu quả thì việc bảo trì phần mềm cũng được

tiến hành thuận lợi hơn, nắm bắt kiến trúc hệ thống nhanh hơn

Mẫu hỗ trợ tái sử dụng kiến trúc và mô hình thiết kế phần mềm theo qui mô lớn Ở đây chúng ta cần phân biệt mẫu thiết kế với khung làm việc Khung làm việc hỗ trợ tái sử dụng mô hình thiết kế và mã nguồn ở mức chi tiết hơn Trong khi đó mẫu thiết

kế được vận dụng ở mức tổng quát hơn, giúp các nhà phát triển hình dung và nghi nhận các cấu trúc tĩnh và động cũng như quan hệ tương tác giữa các giải pháp trong

quá trình thiết kế ứng dụng đối với các chuyên khu riêng biệt

Mẫu đa tương thích: Mẫu không phụ thuộc vào ngôn ngữ lập trình, công nghệ hoặc

các nền tảng lớn như J2W của Sun hay Microsofft, NET framework

Tiềm năng ứng dụng của mẫu là rất lớn Các thiết kế dựa trên mẫu được sử dụng khá nhiều ở các phần mềm mã nguồn mở Trong các dạng ứng dụng này, có thể dễ dàng nhận ra một số tên lớp chứa các tiền tố hoặc hậu tố như Factory, Proxy,

Adapter

1.10 Những cách tiếp cận thành phần mẫu thiết kế

Việc sử dụng mẫu trong thiết kế ứng dụng đã có những thành công nhất định Một

số nhà phân tích sử dụng khung làm việc để phát triển các ứng dụng theo cách hướng

mẫu Nhưng một số tác giả khác lại áp dụng mẫu thiết kế với UML

CHƯƠNG 2 CÁC LOẠI MẪU THIẾT KẾ

2.1 Phân loại mẫu

Mẫu được phân loại ra làm 3 nhóm chính sau đây:

a Các mẫu tạo

Các mẫu tạo (Creational Pattern) gồm: Factory, Abstract Factory, Singleton,

Prototype, Builder… Liên quan đến quá trình khởi tạo đối tượng cụ thể từ một định

nghĩa trừu tượng(abstract class, interface)

b Các mẫu cấu trúc

Các mẫu cấu trúc (Structural Pattern) gồm: Proxy, Adapter, Wrapper, Bridge,

Facade, Flyweight, visitor… Liên quan đến vấn đề làm thế nào để các lớp và đối

tượng kết hợp với nhau tạo thành các cấu trúc lớn hơn

c Các mẫu hành vi

Các mẫu hành vi (Behavioral pattern) observer, state, command, Interator…Mô tả

cách thức để các lớp hoặc các đối tượng có thể giao tiếp với nhau

2.2 Mẫu thiết kế với từng bài toán

Trong quá trình thiết kế, chúng ta luôn gặp những sự kiện đó là sự phụ thuộc lẫn nhau giữa các đối tượng trong hệ thống Sự phụ thuộc này đôi khi cho phép ta giải quyết các vấn đề trước mắt thật nhanh chóng Nhưng phần mềm được tạo ra thường không chỉ để giải quyết các vấn đề trước mắt, nó luôn thay đổi vì các yêu cầu thay đổi chức năng không chỉ là cập nhật chức năng đã có mà còn thêm mới các chức năng

mới

Mỗi khi phần mềm cần thêm một yêu cầu mới, chúng ta thường phải thiết kế lại, thậm chí cài đặt lại và kiểm thử lại xem các chức năng mới thêm vào có tương thích với các chức năng cũ hay không, và các chức năng cũ có cần thay đổi để phù hợp với

các chức năng mới hay không những điều đó làm chúng ta mất nhiều thời gian và tiền bạc Vì thế, mục tiêu của bầt kì nhà thiết kế nào là có thể dự đoán được các thay đổi trong tương lai của phần mềm Trên cơ sở đó, thiết kế một hệ thống sao cho bất

kỳ sự thay đổi nào trong tương lai cũng không làm ảnh hưởng đến những phần còn lại

của hệ thống

Một phần mềm không kiên định, phức tạp hoá và có quá nhiều các thành phần lệ thuộc vào nhau, cần phải thiết kế lại đều do xuất phát từ những nguyên nhân sau: – Các đối tượng đều được tạo ra từ các lớp cụ thể thay vì sử dụng các lớp ảo (interface) làm cho việc thay đổi và cập nhật trong tương lai sẻ trở lên phức tạp

Vì vậy sử dụng các mẫu: Abstract Factory, Factory Method, Prototype

– Phần mềm phụ thuộc vào phần cứng hệ điều hành Một chương trình được thiết

kế trên Windows sẽ chạy không hiệu qủa trên Linux vì các hàm APIs và platform hoàn toàn khác biệt nhau Do đó, cần phải thiết kế chương trình có thể linh hoạt chuyển đổi không phụ thuộc vào bất kỳ hệ điều hành, phần cứng nào

Vì vậy sử dụng các mẫu: Abstrac Factory, Bridge

– Phần mềm phụ thuộc vào chi tiết của đối tượng như cách thức hoạt động như thế nào, được lưu trữ tại stack nào, thực thi ra sao, có ràng buộc quan hệ nào không Client biết quá nhiều về đối tượng mà nó gọi tới thường luôn có xu hướng thay đổi nếu đối tượng thay đổi Chính vì thế, chúng ta cần giấu đi những thông tin không cần thiết của đối tượng với client Vì vậy sử dụng Abstract Factory, Bridge, Memento, proxy

– Cách giải quyết một bài toán nào đó tại thời điểm này có thể chưa tốt và nó phải cần được mở rộng thay thế hoặc tối ưu hoá Việc phụ thuộc vào một vấn đề cụ thể thường làm thay đổi các đối tượng liên quan, thậm chí gây ra sự thay đổi dây chuyền Do đó, các thuật toán càng độc lập bao nhiêu thì càng hạn chế được sự ràng buộc bấy nhiêu Vì vậy sử dụng các mẫu: Builder Iterator, Strategy, Template, Method, Visitor

– Phần mềm phụ thuộc chặt chẽ giữa các đối tượng Do lớp đối tượng A và đối tượng B liên kết phụ thuộc với nhau quá chặt nên rất khó có thể thay đổi lớp A

nếu không hiểu rõ về lớp B Vì vậy sử dụng Abstract Factory, Bridge,

Command, Observer

Thiết kế mẫu đưa ra ý tưởng để khắc phục các vấn đề trên, cho phép ta xây dựng các kiến trúc độc lập nhau, sao cho bất cứ sự thay đổi của phần nào trong hệ thống cũng không làm ảnh hưởng hoặc ảnh hưởng rất ít đến các phần còn lại của hệ thống, từ đó

làm cho phần mềm trở nên kiên định và linh động hơn

2.3 Mẫu chế tạo

2.3.1 Định nghĩa

Mẫu chế tạo (Factory Pattern) định nghĩa một lớp (interface, abstract, class)

đóng vai trò như một “ nhà xưởng” có nhiệm vụ trừu tượng hoá quá trình khởi tạo đối tượng “ cụ thể” khi ứng dụng chạy Tại thời điểm thiết kế, đối tượng được định nghĩa trừu 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

2.3.2 Đặc Điểm

Mẫu chế tạo kiểm soát được các hoạt động trong suốt chu kỳ sống của đối tượng,

như khởi tạo đối tượng, huỷ đối tượng…Đảm bảo cho các đối tượng được thực thi an toàn Nắm được thông tin về những đối tượng nào được tạo ra và được khởi tạo ra sao Nói cách khác, các đối tượng được quản lý tốt và an toàn hơn Factory Đối tượng của Factory thường được đặt tên theo những chuẩn khác nhau nhưng vẫn có thể

dễ dàng nhận ra thiết kế Factory chứa trong đó Ví dụ: BankFactory…

Tính chất đóng gói thể hiện rõ trong mẫu Factory, các thông tin liên quan đến truy cập đối tượng được che giấu trong Factory Thiết kế Factory luôn có một thủ tục khởi

tạo đối tượng, ví dụ creatObject()

Mẫu Factory luôn tuân thủ nguyên tắc thiết kế (Dependency inversion Principle -

DIP) không nên phụ thuộc vào những thứ quá cụ thể

2.3.3 Phân loại

Mẫu Factory được thiết kế theo một trong hai cách sau đây:

a Lớp cơ sở (Base- class) : mẫu này sử dụng tính chất thừa kế để phân loại các đối

tượng được tạo ra

b Đối tượng cơ sở(Base – object): Sử dụng mối quan hệ kết hợp để tham chiếu tới

một đối tượng sẽ được tạo ra Đối tượng được tạo ra sẽ trở thành một phần hay thuộc tính của lớp Factory Chúng ta thường hay gặp loại này trong mẫu chế tạo trừu

tượng(Abstrac Factory Pattern)

2.3.4 Một biểu đồ lớp bằng UML của mẫu chế tạo

Hình 2.1 Biểu đồ lớp cuả mẫu chế tạo

2.4 Mẫu chế tạo trừu tƣợng (Abstractfactory pattern)

2.4.1 Định nghĩa

Mẫu Abstract Factory cung cấp một giao diện lớp có chức năng tạo ra một tập hợp các đối tượng liên quan hoặc phụ thuộc lẫn nhau mà không chỉ ra đó là những lớp cụ

thể nào tại thời điểm thiết kế

Về bản chất, mẫu Abstract Factory chỉ khác mẫu Factory ở chỗ bản thân đối tượng factory không được chỉ ra cụ thể tại thời điểm thiết kế, tức nó là một giao diện hoặc lớp trừu tượng (interface, absstract) Nếu như mẫu Factory phân loại đối tượng dựa trên tham số đầu vào thì đối với mẫu Abstract Factory p, thủ tục createObject() còn phụ thuộc vào các yếu tố phụ khác như môi trường hệ điều hành Ứng với mỗi yếu

tố phụ thứ hai ta có một lớp Factory cụ thể

2.4.2 Thiết kế động với mẫu chế tạo trừu tượng

Một trong những vấn đề gặp phải là khung giao diện Abstract Factory thường hay bị sửa đổi, thí dụ như bổ sung thủ tục chẳng hạn, khi đó các lớp cụ thể thực thi giao diện này sẽ phải được dịch và triển khia lại Để giảm nhẹ vấn đề này người ta thường thiết

kế giao diện Abstract Factory một cách linh hoạt

2.4.3 Biểu đồ lớp bằng UML của mẫu

2.5 Mẫu đơn chiếc

Mẫu đơn chiếc (Singleton Pattern -Static Factory Pattern) đảm bảo một lớp chỉ có một thể hiện duy nhất được tạo ra và đồng thời cung cấp một truy cập toàn cục đến

đối tượng được tạo ra

Hình 2.2 Biểu đồ lớp của mẫu chế tạo trừu tượng

Hình 2.3 Minh hoạ biểu đồ lớp của mẫu đơn chiếc

2.5.1 Địng nghĩa

Mẫu đơn chiếc là mẫu đảm bảo rằng, một lớp chỉ có một thể hiện duy nhất và trong

đó cung cấp một cổng giao tiếp chung nhất để truy cập vào lớp đó

Hộp thoại Find, là ví dụ cụ thể cho mẫu đơn chiếc chỉ một hộp thoại duy nhất xuất

hiện dù chọn menu nhiều lần

Hình 2.4 Ví dụ mẫu đơn chiếc

Một số ví dụ về mẫu Singleton: file system, file manager, window manager

2.5.2 Lợi ích

Việc sử dụng mẫu Singleton đem lại các lợi ích sau:

— Quản lý việc truy cập tốt hơn vì chỉ có một thể hiện đơn nhất

— Cho phép cải tiến các tác vụ (operations) và các thể hiện (representation) do mẫu

có thể được kế thừa và tuỳ biến lại thông qua một thể hiện của lớp con

— Quản lý số lượng thể hiện của một lớp, không nhất thiết chỉ có một thể hiện mà có

số thể hiện xác định

— Khả chuyển hơn so với việc dùng một lớp có thuộc tính là tĩnh, vì việc dùng lớp tĩnh chỉ có thể sử dụng một thể hiện duy nhất, còn mẫu đơn chiếc cho phép quản lý các thể hiện tốt hơn và tuỳ biến theo điều kiện cụ thể

2.5.3 Trường hợp sử dụng

Ta có thể sử dụng mẫu đơn chiếc trong những trường hợp sau:

— Chỉ cần một thể hiện duy nhất của một lớp

— Khi thể hiện duy nhất có thể thay đổi thông qua việc thừa kế, người dùng có thể sử dụng thể hiện thừa kế đó mà không cần thay đổi các đoạn mã của chương trình

2.5.4 Cách thực hiện

Thực hiện mẫu đơn chiếc theo các bước sau:

— Định nghĩa một thuộc tính riêng (Private) và tĩnh (static) trong các lớp Singleton: instance

— Định nghĩa tất cả các constructor thành các protected hoặc các private để người dùng không thể tạo thực thể trực tiếp từ lớp

— Định nghĩa một accessor Public và static trong lớp: getInstance()

— Thực hiện "Lazzy initialization"- khởi động chậm, khởi tạo khi yêu cầu trong getInstance(): trả về một thể hiện mới hay một giá trị rỗng (null) tuỳ thuộc vào một biến boolean, biến này như một cờ hiệu dùng báo xem lớp đó đã có thể hiện hay chưa

— Client chỉ dùng getInstance() để tạo đối tượng của lớp Singleton

— Thừa kế cũng được hỗ trợ, nhưng không nạp chồng (overridden) các phương thức Static: lớp cơ sở phải được khai bào là friend với lớp dẫn xuất (để truy xuất đến prrotected constructor)

Trong chế độ đa luồng, mẫu Singleton có thể làm việc không tốt: hai thread có thể gọi phương thức sinh đối tượng cùng thời điểm và hai thể hiện sẽ được tạo ra

2.5.5 Ứng dụng của mẫu đơn chiếc

Ứng dụng rõ rệt nhất của mẫu đơn chiếc có thể thấy trong dịch vụ web khi triệu gọi các đối tượng từ xa, ở đó đối tượng nằm trên server hoặc sẽ phục vụ chung cho tất cả các ứng dụng khách (singleton) hoặc sẽ chỉ đáp ứng một ứng dụng khách riêng lẻ nào

đó rồi tự bị phá huỷ sau đó(single call)

2.5.6 Nhận xét

Chúng ta xét trường hợp có nhiều đối tượng có cùng chung một số tính chất nào đó được tạo ra ứng với mỗi một yêu cầu từ các đối tượng khách (client), lúc này độ phức tạp sẽ tăng lên và ứng dụng sẽ chiếm dụng nhiều vùng nhớ hơn Mẫu đơn chiếc là một giải pháp đặc biệt của mẫu chế tạo ở chỗ đối tượng sinh ra la điểm truy cập toàn cục

Hình 2.5 Biểu đồ lớp trong mẫu đơn chiếc

“duy nhất” đối với mọi chương trình gọi đến, hay nói một cách khác tất cả các đối

tượng khách gọi đến đều chia sẻ đối tượng được tạo ra

2.6 Mẫu uỷ nhiệm

2.6.1 Định nghĩa

Mẫu uỷ nhiệm (proxy pattern): là mẫu thiết kế mà ở đó tất cả các truy cập trực tiếp

một đối tượng nào đó sẽ được chuyển hướng vào một đối tượng trung gian lớp uỷ

nhiệm (proxy class)

Nếu như mẫu uỷ nhiệm giúp quản lý đối tượng tốt hơn mà còn có nhiệm vụ bảo vệ việc truy cập một đối tượng bằng cách thông qua proxy, hay còn gọi là truy cập gián tiếp Mẫu Proxy được uỷ quyền về phía ứng dụng khách cho phép tương tác với đối tượng đích theo những cách khác nhau, như gửi yêu cầu một dịch vụ nào đó, theo dõi trạng thái và vòng đời đối tượng, xây dựng lớp vỏ bảo vệ đối tượng…Thí dụ, chúng ta phát hiện ra một đối tượng như một thư viện DLL có thể bị khai thác truy cập vào trong một số trường quan trọng, khi đó chúng ta không thể mở mã nguồn thư viện đã được dịch để vá lỗ hổng Giải pháp lúc này là xây dựng một proxy ngăn chặn truy

cập các trường đó và cuối cùng biện dịch lại thành một DLL mới

— Uỷ nhiệm ảo(Virtual Proxy): tạo ra một đối tượng trung gian mỗi khi có yêu cầu tại thời điểm thực thi ứng dụng, nhờ đó làm tăng hiệu suất của ứng dụng

— Uỷ nhiệm màn hình(Monitor Proxy): sẽ thiết lập các ràng buộc bảo mật trên đối tượng cần bảo vệ, ngăn không cho client truy cập một số trường quan trọng của đối tượng

— Uỷ nhiệm bảo vệ (Protection proxy): Đối với proxy này thì phạm vi truy cập của các client khác nhau sẽ khác nhau Protection Proxy sẽ kiểm tra các quyền truy cập của client khi có dịch vụ được yêu cầu

— Uỷ nhiệm bộ đệm (Cache proxy): Cung cấp không gian lưu trữ tạm thời cho các kết quả trả về đối tượng nào đó, kết quả này sẽ được tái sử dụng cho các client chia sẻ chung một yêu cầu gửi đến và do đó làm tăng đáng kể hiệu suất chương trình

— Uỷ nhiệm bức tường lửa (Firewall proxy): Bảo vệ đối tượng từ chối các yêu cầu xuất xứ từ các client không tín nhiệm

— Uỷ nhiệm tham chiếu thông minh (Smart reference proxy): Là nơi kiểm soát các hoạt động bổ sung mỗi khi đối tượng được tham chiếu, ví dụ như kiểm soát vòng đời của đôí tượng, lưu lại số lần tham chiếu vào đối tượng…

— Uỷ nhiệm đồng bộ (Synchoronization Proxy): Đảm bảo nhiều client có thể truy cập vào cùng một đối tượng mà không gây xung đột Thực tế có rất nhiều tình huống khiến chúng ta phải nghĩ đến thiết kế này Một Synchronization proxy được thiết lập có thể kiểm soát được nhiều yêu cầu cập nhập dữ liệu một cách đồng thời, tại thời điểm bắt đầu cập nhật chỉ có một client với mức ưu tiên cao nhất giành được khoá để đánh dấu rằng các client khác cần phải chờ đến lượt Synchronization proxy hoạt động rất hiệu quả và phổ biến trong thiết kế các bài toán đa tuyến Một hiện tượng hay xảy ra với thiết kế này là khi một client nào đó chiếm dụng khoá khá lâu khiến cho số lượng các client trong danh sách hàng đợi cứ tăng lên, và do

đó hoạt động của hệ thống bị ngưng trệ, có thể dẫn đến hiện tượng “tắt nghẽn” là hiện tượng khoá được giữ vô thời hạn bởi một đối tượng nào đó Trong trường hợp này người ta cải tiến thành mẫu thiết kế phức tạp hơn đó là Copy_ on_write proxy

— Uỷ nhiệm sao chép ghi ra (Copy - on – write proxy): Đảm bảo rằng sẽ không có client nào phải chờ vô thời hạn Thiết kế này rất phức tạp do đó chỉ nên ứng dụng

nó thay thế cho synchronization proxy khi hệ thống được dự đoán sẽ thường xuyên

bị ngưng trệ hoặc các hiện tượng tắc nghẽn xảy ra

2.6.3 Đặc điểm chung

Mẫu Proxy có những đặc điểm chung sau đây:

— Cung cấp mức truy cập gián tiếp vào một đối tượng

— Tham chiếu vào đối tượng đích và chuyển tiếp các yêu cầu đến đối tượng đó

— Cả Proxy và đối tượng đích đều thừa kế hoặc thực thi chung một lớp giao diện Mã máy dịch cho lớp giao diện thường “nhẹ” hơn các lớp cụ thể và do đó có thể giảm được thời gian tải dữ liệu giữa server và client

2.6.4 Biểu đồ lớp bằng UML của mẫu

Hình 2.6 Biểu đồ lớp mẫu uỷ nhiệm

2.7 Mẫu thích nghi

2.7.1 Định nghĩa

Mẫu thích nghi (adapter pattern) biến đổi giao diện của một lớp thành một giao diện khác mà các đối tượng client có thể hiểu được Lớp với giao diện được tạo ra gọi là Adapter Nguyên tắc cơ bản của mẫu thích nghi nằm ở chỗ làm thế nào để các lớp với

các giao diện không tương thích có thể làm việc được với nhau

Nguyên lý xây dựng mẫu thích nghi khá đơn giản: chúng ta xây dựng một lớp với một giao diện mong muốn sao cho lớp đó giao tiếp được với một lớp cho trước ứng

với một giao diện khác

Mẫu thích nghi không quản lý tập trung các đối tượng gần giống như mẫu chế tạo,

mà kết nối với nhiều lớp không có liên quan gì với nhau Ví dụ, lớp A sau khi thực thi