Phát triển phần mềm định hướng mẫu và ứng dụng phát triển hệ thống cho thuê KIOT trên nền WEB

của phát triển hướng đối tượng truyền thống ta sẽ được xem xét lại trong POAD, bởi vì sử dụng các Mẫu thiết kế đã được cải tiến từ rất nhiều ứng dụng thành công  Việc làm tài liệu tốt h

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NHÂM NHƯ LIÊM

PHÁT TRIỂN PHẦN MỀM ĐỊNH HƯỚNG MẪU

VÀ ỨNG DỤNG PHÁT TRIỂN HỆ THỐNG CHO THUÊ KIOT TRÊN NỀN WEB

LUẬN VĂN THẠC SĨ

HÀ NỘI - 2011

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NHÂM NHƯ LIÊM

PHÁT TRIỂN PHẦN MỀM ĐỊNH HƯỚNG MẪU

VÀ ỨNG DỤNG PHÁT TRIỂN HỆ THỐNG CHO THUÊ KIOT TRÊN NỀN WEB

Ngành : Công nghệ thông tin Chuyên ngành : Công nghệ phần mềm

LUẬN VĂN THẠC SĨ

HƯỚNG DẪN KHOA HỌC: PGS.TS NGUYỄN VĂN VỴ

HÀ NỘI - 2011

MỤC LỤC

LỜI CẢM ƠN 3

LỜI CAM ĐOAN 4

MỤC LỤC 5

DANH MỤC CÁC HÌNH 7

CHƯƠNG 1:TỔNG QUAN PHÁT TRIỂN PHẦN MỀM ĐỊNH HƯỚNG MẪU 11

1.1 Tổng quan 11

1.1.1 Mẫu là gì 11

1.1.2 Vòng đời của một mẫu 13

1.2.Giới thiệu về phát triển phần mềm định hướng mẫu 14

1.3 Các đặc trưng của phát triển phần mềm hướng mẫu 16

1.3.1 Tính điều khiển bởi mẫu (Pattern-Driven) 16

1.3.2 Tính phát triển dựa trên thành phần 16

1.3.3 Tính phát triển từ kiến trúc 17

1.3.4 Tính phát triển được điều khiển từ thư viện mẫu 17

1.3.5 Tính sử dụng lại ở mức thiết kế 17

1.3.6 Tính phát triển phân cấp 18

1.3.7 Tính phát triển lặp 19

1.4 Tiến trình phân tích thiết kế hướng mẫu 19

1.4.1 Pha phân tích 20

1.4.2 Pha thiết kế 22

1.4.3 Pha làm mịn thiết kế 24

1.5 Những lợi ích và hạn chế của POAD 26

1.5.1 Các ưu điểm 26

1.5.2 Các mặt hạn chế 28

CHƯƠNG 2: MỘT SỐ MẪU TRONG PHÁT TRIỂN KIẾN TRÚC PHẦN MỀM 29

2.1 Giới thiệu về mẫu 29

2.2 Phân loại về mẫu 29

2.2.1 Nhóm mâu kiến tạo (Creational Pattern) 30

2.2.2 Nhóm mẫu cấu trúc (Structural Pattern) 30

2.2.3 Nhóm mẫu hành vi (Behavioral Pattern) 31

2.3 Một số mẫu tiêu biểu 32

2.3.1 Mẫu MVC 32

2.3.2 Mẫu Kiến trúc Add-Ins 34

2.3.3 Mẫu kiến trúc phân tầng (Layered Architecture) 35

2.3.4 Mẫu thiết kế Abstract Factory 37

2.3.5 Mẫu thiết kế Factory 38

2.3.6 Mẫu thiết kế State 39

2.3.7 Mẫu thiết kế Strategy 40

3.3.8 Mẫu thiết kế Observer 41

CHƯƠNG 3: PHÁT TRIỂN HỆ THỐNG KIOT CHO THUÊ TRÊN NỀN WEB 43

3.1 Mô tả bài toán 43

3.1.1 Thông tin chung 43

3.1.2 Các hoạt động của hệ thống 43

3.1.3 Biểu đồ hoạt động 46

3.1.4 Biểu đồ miền đối tượng nghiệp vụ 48

3.2 Phát triển mô hình ca sử dụng 49

3.2.1 Xác định tác nhân 49

3.2.2 Xác định ca sử dụng 50

3.2.3 Mô hình ca sử dụng mức gộp 51

3.2.4 Mô hình ca sử dụng chi tiết 53

3.2.5 Mô tả chi tiết ca sử dụng 55

3.3 Phân tích hệ thống 60

3.3.1 Phân tích ca sử dụng 61

3.3.2 Chọn lựa mẫu 66

3.4 Thiết kế hệ thống 70

3.4.1 Thiết kế kiến trúc hệ thống 70

3.4.2 Sơ đồ mức mẫu cho hệ thống Kiot 71

3.4.3 Sơ đồ giao diện mức mẫu cho hệ thống Kiot 71

3.4.4 Thiết kế chi tiết lớp đối tượng 72

3.4.5 Thiết kế chi tiết tầng truy xuất dữ liệu 72

3.4.6 Thiết kế chi tiết tầng nghiệp vụ 74

3.4.7 Thiết kế chức năng quản lý gian hàng cho thuê 76

3.4.8 Thiết kế chi tiết chức năng quản lý giỏ hàng 78

3.4.9 Thiết kế chi tiết chức xử lý đơn hàng 79

3.4.10 Thiết kế Database 81

CHƯƠNG 4: TRIỂN KHAI VÀ ĐÁNH GIÁ KẾT QUẢ 82

4.1 Lựa chọn môi trường phát triển 82

4.1.1 Lựa chọn ngôn ngữ lập trình 82

4.1.2 Lựa chọn MVC 82

4.1.3 Lựa chọn mẫu Ajax 83

4.2 Triển khai hệ thống 84

4.3 Môt số chức năng hệ thống 85

4.3.1 Giao diện chính một gian hàng 85

4.3.2 Chức năng đăng ký gian hàng 86

4.3.3 Chức năng quản lý giỏ hàng 86

4.3.3 Chức năng đặt mua và thanh toán 86

4.4 Đánh giá kết quả thử nghiệm chương trình 87

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 88

TÀI LIỆU THAM KHẢO 90

DANH MỤC CÁC HÌNH

Hình 1.1: Vòng đời của một Mẫu 13

Hình 1.2: Các ký hiệu đƣợc sử dụng miêu tả POAD 20

Hình 1.3: Pha phân tích POAD 21

Hình 1.4: Pha phân tích POAD 23

Hình 1.5: Tiến trình làm mịn thiết kế POAD 25

Hình 2.1: Mối quan hệ giữa các Pattern GoF 29

Hình 2.2: Sơ đồ mẫu MVC 33

Hình 2.3: Kiến trúc Add-Ins 34

Hình 2.4: Kiến trúc phân tầng 36

Hình 2.5: Ví dụ về sử dụng mẫu thiết kế Abstract Factory 37

Hình 2.6: Ví dụ về mẫu thiết kế Factory 38

Hình 2.7: Ví dụ về mẫu thiết kế State 39

Hình 2.8: Ví dụ về mẫu thiết kế Strategy 40

Hình 2.9: Ví dụ mẫu thiết kế Observer 41

Hình 3.1: Biểu đồ hoạt động thuê gian hàng 46

Hình 3.2: Biểu đồ hoạt động mua sản phẩm trên gian hàng 47

Hình 3.3: Biểu đồ hoạt động xử lý đơn hàng 48

Hình 3.4: Mô hình miền đối tƣợng nghiệp vụ 48

Hình 3.5: Các tác nhận của hệ thống 49

Hình 3.6: Biểu đồ ca sử dụng mức gộp 51

Hình 3.7: Gói ca sử dụng đăng ký gian hàng 53

Hình 3.8: Gói ca sử dụng quản trị hệ thống gian hàng 53

Hình 3.9: Gói ca sử dụng quản lý tài nguyên 54

Hình 3.10: Gói ca sử dụng quản lý bán hàng 54

Hình 3.11: Gói ca sử dụng mua sản phẩm trên gian hàng 55

Hình 3.12: Biểu đồ tuần tự đăng ký thuê gian hàng 61

Hình 3.13: Biểu đồ tuần tự quản lý gian hàng cho thuê 62

Hình 3.14: Biểu đồ tuần tự quản lý giỏ hàng 63

Hình 3.15: Biểu đồ tuần tự mua sản phẩm trên gian hàng 64

Hình 3.16: Biểu đồ tuần tự quản lý đơn hàng 65

Hình 3.17: Mấu kiến trúc 3 tầng cho phát triển 67

Hình 3.18: Mấu kiến MVC cho phát triển 68

Hình 3.19: Áp dụng mẫu kiến trúc 3 tầng cho hệ thống 70

Hình 3.20: Sơ đồ thiết kế mức mẫu cho hệ thống kiot 71

Hình 3.21: Sơ Sơ đồ thiết kế giao diện mức mẫu 71

Hình 3.22: Lớp đối tƣợng chi tiết hệ thống kiot 72

Hình 3.23: Lớp chi tiết áp dụng mẫu Factory cho tầng truy xuất dữ liệu DAO 73

Hình 3.24: Lớp chi tiết áp dụng mẫu Factory cho tầng xử lý nghiệp vụ 75

Hình 3.25: Biểu đồ trạng thái một gian hàng 76

Hình 3.26: Lớp chi tiết áp dụng mẫu State cho quản lý gian hàng 77

Hình 3.27: Lớp chi tiết áp dụng mẫu Oberver cho đổi thông tin giỏ hàng 78

Hình 3.28: Biểu đồ trạng thái của một đơn đặt hàng 79

Hình 3.29: Lớp chi tiết áp dụng mẫu State cho quản lý đơn đặt hàng 80

Hình 3.30: Thiết kế database 81

Hình 4.1: Mô hình MVC cùng Struts 83 Hình 4.2: Framework DWR Ajax phát triển web 83

MỞ ĐẦU

Định hướng mẫu là một giải pháp công nghệ cho việc phát triển các phần mềm phức tạp, đảm bảo có kiến trúc tốt, có tính mở cao giúp cho việc bảo trì thuận lợi và hiệu quả Việc áp dụng định hướng mẫu còn giúp tái sử dụng kiến trúc các mô hình thiết kế của phần mềm tốt đã có Nhờ vậy, giảm được cả chi phí về thời gian lẫn công sức phát triển Dịch vụ E-commerce không ngừng phát trên thế giới và việt nam Các doanh nghiệp ngày càng nhận thấy tầm quan trọng trong việc quảng bá và bản hàng trên mạng Nhưng vấn đề lớn nhất của họ là làm sao triển khai một cách nhanh chóng

và hiệu quả và chi phí thấp Từ nhu cầu thực tế của Việt nam, đề tài ―phát triển phần mềm định hướng mẫu và áp dụng phát triển hệ thống thuê kiot trên nền web‖ được đề xuất Với giải pháp này, doanh nghiệp có thể thuê kiot trực tuyến sử dụng như là một gian hàng trực tuyến của mình để thực hiện các hoạt động E-commerce một cách đơn giản và hiệu quả Hệ thống áp dụng công nghệ phát triển phần mềm định hướng mẫu

có thể thạo ra mô hình dịch vụ cho thuê kiot mong muốn, và cũng dễ dàng bổ xung, hoàn thiện để có thể đáp ứng được nhu cầu thay đổi không ngừng của doanh nghiệp trong quá trình kinh doanh của họ

Kết quả chính đạt được của luận văn:

Nghiên cứu giải quyết vấn đề: Phát triển phần mềm hướng mẫu và ứng dụng cho mẫu giải quyết một bài toán thực tế Công nghệ sử dụng ở đây là công nghệ hướng đối tựợng định hướng mẫu Nhờ công nghệ này mà việc phát triển ―Hệ thống cho thuê kiot trên nền web‖ đã thực hiện một cách thuận lợi, mà việc áp dụng phân tích thiết kế hướng đối tượng truyền thống khó đạt được kết quả Hệ thống chương trình xây dựng

đã được triển khai trên thực tế và được nhiều khách hàng thuê đánh giá tốt

Luận văn gồm 4 chương:

Chương 1: Giới thiệu tổng quan về phát triển phần mềm định hướng mẫu

Chương này đưa ra những hạn chế của việc phát triển phần mềm hướng đối tượng truyền thống, từ đó nêu bật đặc trưng và lợi ích của phương pháp phát triển phần mềm định hướng mẫu Tiếp theo trình bày cách tiếp cận phát triển định hướng mẫu với các pha khác, các bước cụ thể như phân tích yêu cầu, thiết kế

Chương 2: Giới thiệu một số mẫu đã áp dụng trong thực tế

Chương này giới thiệu về một số mẫu đã được áp dụng rất phổ biến trong phát triển phần mềm và đặc biệt cho ứng dụng sẽ triển khai ở chương sau

Chương 3: Ứng dụng phát triển phần mềm định hướng mẫu để giải quyết bài toán xây dựng hệ thống kiot cho thuê trên nên web

Chương này giới thiệu về bài toán ―Hệ thống cho thuê kiot trên nền web” và

quá trình ứng dụng phát triển định hướng mậu để thực hiện các bước triển khai bài toán

Chương 4: Cài đặt bài toán và đánh giá

Chương này trình bày việc lựa chọn ngôn ngữ và môi trương triển khai chương trình theo tiến trình, phương pháp đã giới thiệu ở chương 3 và đánh giá khái quát về kết quả đã đạt được

Cuối cùng là kết luận và hướng phát triển tiếp theo của đề tài

CHƯƠNG 1 TỔNG QUAN PHÁT TRIỂN PHẦN MỀM ĐỊNH HƯỚNG MẪU

1.1 Tổng quan

Các ứng dụng phần mềm ngày càng trở lên phức tạp Chúng ta đang tìm kiếm

cách tiếp cận phát triển phần mềm sao cho đơn giản, giảm công sức và thời gian, đồng thời nâng cao chất lượng và đảm bảo khả năng tái sử dụng lại Đây là vấn đề khó với

mô hình phát triển phần mềm truyền thống Phát triển phần mềm định hướng mẫu ra đời là một cách để giải quyết các vấn đề trên Bất kì vòng đời phát triển phần mềm nào cũng có một số giai đoạn phát triển Các giai đoạn ấy thường bao gồm việc phân tích, thiết kế, thiết kế chi tiết, cài đặt và kiểm thử Các mẫu có thể đóng một vai trò vô cùng quan trọng trong mọi giai đoạn trong vòng đời phần mềm Mặc dù các mẫu được đưa

ra vào lúc ban đầu để phục vụ việc dùng lại ở giai đoạn thiết kế (các mẫu thiết kế), thực tế cũng đã nhận thấy rõ được sự hữu ích của các mẫu ở tất cả các giai đoạn khác của vòng đời phần mềm

1.1.1 Mẫu là gì

Nói chung, một mẫu là một vấn đề thường hay xảy ra trong thiết kế và cài đặt phần mềm, và sau đó mô tả giải pháp để vấn đề theo một cách như vậy có thể được dùng lại Các mẫu được đưa ra để chứng minh cho các bài thiết kế được thực hiện tốt hơn Dây là sự truyền bá của tri thức và kinh nghiệm truyền từ những người có kinh nghiệm sang cho những người thiếu kinh nghiệm Chính vì mục đích này, công việc được thúc đẩy để chứng minh và khám phá ra các Mẫu mới trong các miền khác nhau Các mẫu có thể được phân loại theo các giai đoạn phát triển, đó là: Mẫu Phân tích[

Fowler 1997], các mẫu Kiến trúc[ Buschmann et al 1996], các Mẫu thiết kế[ Gamma

et al, 1995] và các idiom (thành ngữ) [Coplien 1992]:

 Các mẫu phân tích: Việc phân tích là việc tìm kiếm phía sau các yêu cầu để hiểu các vấn đề Martin Fowler 1997 đã định nghĩa các mẫu phân tích như là ― …các nhóm ý tưởng thể hiện việc xây dựng phổ biến trong mô hình nghiệp vụ” Fow-

ler đã chứng minh một vài Mẫu phân tích trên tích lũy kinh nghiệm làm dự án dành cho một vài lĩnh vực kinh doanh Các mẫu Kiểu, Giám sát và Đo đếm là các Mẫu trong số các Mẫu phân tích đã được Fowler chứng minh

 Các mẫu kiến trúc: một Mẫu kiến trúc giải thích một giản đồ tổ chức có kiến trúc

cơ bản cốt lõi cho các hệ thống phần mềm Nó cung cấp một bộ các hệ thống

con được định nghĩa trước hoặc các thành phần, chỉ định các trách nhiệm của chúng và bao gộp các luật cùng với hướng dẫn cho việc tổ chức các quan hệ

giữa chúng[ Buschmann et al 1996] Các mẫu Broker, Blackboard, và Pipes là các mẫu thuộc loại này Các mẫu kiến trúc là một biện pháp chứng minh kiến trúc dành cho các hệ thống phức tạp và không đồng nhất, vì vậy việc giúp quản lý tự động là rất phức tạp

Filters- Các mẫu thiết kế: một mẫu thiết kế cung cấp một biểu đồ cho việc cải tiến các hệ

thống con hoặc 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 chung Nó mô tả một cách phổ biến kiến trúc đặc biệt của các thành phần giải quyết vấn đề thiết kế tổng quát trong một ngữ cảnh cụ thể[ Gamma et al

1995] Các mẫu chiến lược, trạng thái, và Proxy là những ví dụ thuộc loại này

 Thành ngữ (Idioms): thành ngữ là một Mẫu mức thấp đặc trưng cho một ngôn

ngữ lập trình Một thành ngữ mô tả cách thức để triển khai các khía cạnh phổ biến của các thành phần hoặc các mối quan hệ giữa chúng bằng cách dùng các đặc trưng của ngôn ngữ lập trình đã cho như C++, Java, hoặc Smalltalk Các ví

dụ về thành ngữ là cách thức để cài đặt các Singletons trong C++[Buschmann et

al 1996] và con trỏ được đếm Counted Pointer[ Coplien 1992]

Các Mẫu là các kinh nghiệm thiết kế đã được kiểm chứng tốt Người ta thường nói rằng các Mẫu được khám phá ra hoặc được chứng minh chứ không nói là nó được phát minh ra bởi vì chúng phải phát triển lên từ nhiều dự án thực sự đang tồn tại Các Mẫu đưa ra các cách rất xúc tích và hiệu quả để chuyển các ý tưởng và các kinh nghiệm Phần mềm vào trong các vấn đề thực tế

1.1.2 Vòng đời của một mẫu

Để giải thích về vòng đời của một Mẫu chúng ta xem xét hình sau:

Hình 1.1: Vòng đời của một Mẫu Giai đoạn 1: Khai phá Trong việc tạo ra bất kì mẫu thiết kế nào, giai đoạn đầu tiên

đều liên quan tới việc chứng minh khởi đầu của một Mẫu Hành động chinh trong giai đoạn này là việc khai mở các Mẫu Tác giả của một Mẫu phải quyết định điều gì tạo thành một mẫu, điều gì làm cho nó có thể được người khác sử dụng lại, nó phục vụ cho miền nào và vì thế nó chỉ rõ đó có phải là một Mẫu hay không Một số người thực hành trong cộng đồng Mẫu thể hiện ―Luật bộ 3‖ (Rule of three) đủ để chứng minh cho một Mẫu ví dụ, việc dùng Mẫu trong 3 hoặc nhiều dự án cụ thể hơn) Đầu ra của giai đoạn này là một phiên bản của Mẫu như đã được tác giả chứng minh

Giai đoạn 2: Hoàn thiện Giai đoạn thứ 2 được các nhà nghiên cứu và các nhà thực

hành có kinh nghiệm đề cập đến việc đánh giá và cải tiến các Mẫu Trong giai đoạn này Mẫu của tác giả được đưa ra để xem xét trong các cuộc hội thảo PloP hàng năm Sau đó được phân công cho một nhà phê bình Trong cộng đồng Mẫu, một nhà phê bình trên thực tế là một người hướng dẫn làm việc với tác giả trên tiến trình phỏng vấn

từng cấp một để cải tiến Mẫu đã đưa ra Vào phút cuối của tiến trình phỏng vấn, Mẫu hoặc được nhận đưa vào thảo luận hoặc bị từ chối Các mẫu được chấp nhận sẽ được phỏng vấn lại trong cuộc họp với một nhóm các tác giả có kinh nghiệm Họ tạo ra các yêu cầu cho các cải tiến đối với Mẫu và chia sẻ kinh nghiệm của họ trong việc giải quyết các vấn đề cùng nhau Đối tượng của giai đoạn này là giúp đỡ tác giả của Mẫu cải thiện phiên bản Mẫu Trong một vài trường hợp Mẫu có thể bị loại vì sự thiếu hợp

lý và thiếu tiềm năng dùng lại Đầu ra của giai đoạn này là Mẫu được chứng minh tốt cho việc dùng lại đối với những người mới làm quen, các nhà thiết kế ứng dụng, và các nhà phát triển Sau đó phiên bản được xem lại sẽ được công bố trong Biên bản lưu của cuộc họp

Giai đoạn 3: Việc dùng lại Giai đoạn thứ 3 liên quan đến việc dùng lại Mẫu trong

các ứng dụng Người dùng cung cấp thông tin phản hồi cho tác giả của Mẫu những trở ngại mà họ phải đối mặt trong khi cài đặt và dùng chúng, và đưa ra các yêu cầu cải tiến các Mẫu đó

Tiến trình trên được lập lại vì mỗi Mẫu sẽ được cải tiến liên tục Chúng ta tin rằng các Mẫu đã được chứng minh tính đúng đắn trong việc dùng lại sẽ đạt được chất lượng cao, bởi vì nó đã trải qua một số giai đoạn cải tiến Chất lượng cao là một thuộc tính then chốt của thành phần thiết kế và vì vậy các Mẫu tuân theo vòng đời phát triển này sẽ đủ điều kiện để là các thành phần thiết kế

1.2 Giới thiệu về phát triển phần mềm định hướng mẫu

Kiến trúc phần mềm thực chất là việc xem xét cấu trúc của một ứng dụng hơn là chức năng của nó [Shaw & Garlan 1996] Khi chọn và thiết kế một kiến trúc tốt làm ảnh hưởng đến các thuộc tính chức năng và phi chức năng của ứng dụng, nhờ đó sẽ dễ dàng tích hợp, đạt hiệu quả và an toàn cao vì đã có sự chuẩn bị trước các thay đổi [Dy-son & Anderson, 1997] Khi phát triển một kiến trúc của một ứng dụng phần mềm, chúng ta không quan tâm đến thực thi, mà quan tâm chủ yếu đến các chức năng và được định vị các thành phần và xác định sự tương tác của chúng

Trong POAD chúng ta xây dựng các ứng dụng từ tập hợp các mẫu thiết kế cấu trúc, đó là các thành phần thiết kế Chúng ta chọn một mẫu để giải quyết môt vấn đề thiết kế cụ thể và xác định mối quan hệ giữa các mẫu và cách thức chúng tương tác với nhau Do đó, các mô hình kết quả từ POAD có thể được sử dụng như là khung nhìn kiến trúc của ứng dụng Phân rã ở mức cao của các ứng dụng được xem xét là một cách tiếp cận dựa trên kiến trúc

 Những thiết kế hướng đối tượng là kết quả của việc áp dụng tiến trình phát triển POAD, nó sẽ làm giảm bớt các các hành động chế tác lại Đó là vì một phần của

tiến trình tái chế đã được thực hiện trong chính các mẫu ‖Các mẫu thiết kế nắm bắt được nhiều cấu trúc là kết quả của sự tái chế‖ Rất nhiều phương pháp luận

của phát triển hướng đối tượng truyền thống ta sẽ được xem xét lại trong POAD, bởi vì sử dụng các Mẫu thiết kế đã được cải tiến từ rất nhiều ứng dụng thành công

 Việc làm tài liệu tốt hơn của thiết kế ứng dụng/khung làm việc Các biểu đồ mức

mẫu cung cấp khung nhìn trừu tượng ở mức cao của thiết kế Các khung nhìn trừu tượng này như những tài liệu thiết kế cho ứng dụng, do đó chúng ta có thể cải tiến khả năng hiểu được của thiết kế Ở rất nhiều quy trình phát triển hướng đối tượng khác, các gói và các hệ thống con được sử dụng để nhóm các lớp lại với nhau Những cái được đưa vào cùng một gói thường là quyết định thiết kế quan trọng Trong POAD, phần bên trong mẫu là đã được biết, chính là những

mô hình lớp được thiết kế tốt Rủi ro trong việc sử dụng sai các khung làm việc thiết kế hướng đối tượng được giảm bớt nhờ tác dụng của sự cải tiến khả năng hiểu được của các thiết kế, của các lớp Kết quả của các tầng được đưa vào gần đây và tính lần vết đến các mức thiết kế thấp hơn cho thấy rằng, thiết kế là dễ hiểu hơn

 Sử dụng các mẫu như các khối xây dựng đem lại khung nhìn kiến trúc của ứng dụng, bởi vì chúng ta không cụ thể được các vấn đề thực thi tại khung nhìn trừu

tượng mức cao của giao diện các mẫu Các thành phần kiến trúc của chúng ta trên thực tế là các phần tử thiết kế bên trong giới hạn của sự cộng tác giữa các lớp Do đó, chúng ta có khả năng lần vết đến khung nhìn kiến trúc từ thiết kế mức thấp đến các khung nhìn thực thi

 Những thiết kế hướng mẫu cho chất lượng cao hơn các thiết kế hướng đối tượng,

bởi vì chúng sử dụng các mẫu thiết kế đã được làm tài liệu chất lượng cao, các giải pháp đã được kiểm trứng cho các vấn đề thiết kế

 “Các mẫu triển khai” khi thực thi các mẫu thiết kế, những người lập trình tạo,

mở rộng và chỉnh sửa các lớp ở khắp nơi của phần mềm Nó có thể tạo ra sự duy trì chính và khả năng lần vết, vì các lập trình viên ―đánh mất khả năng nhìn của các mẫu ban đầu‖ Phương pháp POAD quan tâm đến vấn đề này bởi với các khung nhìn mức mẫu được thêm vào các lớp trên các pha thiết kế mức cao, các mẫu được xử lý như là các thực thể thiết kế

 Phương pháp POAD dựa trên thành phần Nó chuyển các nỗ lực phát triển từ

việc tạo ra thiết kế đến việc lựa chọn, làm thích nghi và ghép nối các mảnh thiết

kế Mặt khác, nó không phải là sự cắm, lắp ghép và vận hành tiến trình như cách hiểu thông thường từ sự phát triển phần mềm dựa trên thành phần, bởi vì sự làm thích nghi và sự kết hợp các thành phần là các mảnh thiết kế Người thiết kế vẫn phải làm việc trên chi tiết cụ thể bên trong và các đặc tả triển khai

1.3 Các đặc trưng của phát triển phần mềm hướng mẫu

1.3.1 Tính điều khiển bởi mẫu (Pattern-Driven)

Phần lớn các phân tích hướng đối tượng và các phương pháp luận thiết kế sử dụng các lớp và các đối tượng như là các khối xây dựng thiết kế Nhiều ngôn ngữ mô hình hóa hướng đối tượng như UML, cung cấp các cơ chế nhóm gộp như các gói và hệ con để cấu trúc một khung nhìn lớn của thiết kế Các cơ chế nhóm gộp được sử dụng

để quản lý sự phức tạp của mô hình bằng cách xem thiết kế như là số các gói cộng tác, tức là được phân rã và làm mịn

Tiếp cận POAD được điều khiển bằng mẫu có nghĩa là, mọi thứ bắt đầu từ việc thể hiện các mẫu trong thiết kế Trong POAD, ta xây dựng các ứng dụng từ các khối thiết kế lớn, tức là từ các mẫu thiết kế cấu trúc Trong ngữ cảnh này, các mẫu được sử dụng các cơ chế nhóm gộp và đồng thời như các giải pháp thiết kế có thể dùng lại được Với cơ chế nhóm gộp, một mẫu sẽ bao gói một tập các lớp để giải quyết một vấn

đề thiết kế cụ thể Như một giải pháp thiết kế có thể dùng lại, mỗi mẫu cung cấp một giải pháp trừu tượng cho các vấn đề thiết kế phổ biến POAD dựa trên các mẫu giống như các khối xây dựng có thể sử dụng lại của các thiết kế ứng dụng

1.3.2 Tính phát triển dựa trên thành phần

Kỹ nghệ phần mềm dựa trên thành phần (componnt-based engineering) đang nổi

lên như mô hình có lợi cho phát triển phần mềm, mở ra nhiều hứa hẹn cho việc sử

dụng lại phần mềm: Bản chất của việc xác định một thành phần, khi nào một thành phần có thể được sử dụng trong phát triển phần mềm và ở các pha phát triển nào Một

thành phần có thể được trừu tượng hóa một chức năng, dữ liệu, gói hay cấu trúc hệ thống Nhìn chung, nhiều người ám chỉ một thành phần như một lớp, một đoạn mã, một đoạn thiết kế, một module có khả năng thực thi, một thư viện liên kết tại thời gian chạy (thư viện động, DLL) hay là một thư viện tĩnh Các thành phần có thể được phân loại dựa trên các đặc tính của chúng:

 Các thành phần đặc tả: Đặc tả các chức năng hay hành vi mong đợi của một

thành phần giúp cho người phát triển tự do áp dụng thành phần trong các ngôn ngữ lập trình khác nhau

 Khả năng thực thi: Các thành phần có thể thực thi được có thể là các thư viện

tĩnh, DLLs hoặc là các mảnh có khả năng thực thi của một ứng dụng Thông thường, mã nguồn của các thành phần này không có sẵn, nhưng các hướng dẫn

để tích hợp chúng trong quá trình phát triển được đưa ra trong các tài liệu phân phối cùng thành phần tương ứng

 Các thành phần thiết kế Một thành phần có thể là một nguyên tắc hay cấu trúc

thiết kế Các được sử dụng như các khối xây dựng thiết kế trong việc cấu trúc

ứng dụng hướng đối tượng Thông thường, các thành phần loại này được sử dụng như là các hộp trắng tại mức thiết kế

Trong POAD, các ứng dụng được xây dựng bằng cách sử dụng các thành phần thiết kế như là các khối xây dựng của chúng Nó tạo ra thiết kế mà bản chất là dựa trên thành phần, các thành phần đã sử dụng ở đây là các thành phần thiết kế hộp trắng Nó không làm giảm bớt sự quan trọng của việc sử dụng các giao diện để dính kết các thành phần này Trong POAD, các mẫu thiết kế cấu trúc được sử dụng như là các thành phần thiết kế

1.3.3 Tính phát triển từ kiến trúc

Kiến trúc phần mềm xem xét cấu trúc của một ứng dụng hơn là chức năng của nó [Shaw & Garlan 1996] Khi chọn một cấu trúc tốt làm ảnh hưởng đến các thuộc tính chức năng và phi chức năng của ứng dụng, như sự dễ dàng tích hợp, hiệu suất và vững chắc trước các thay đổi [Dyson & Anderson, 1997] Khi phát triển một kiến trúc ứng dụng, chúng ta không quan tâm đến các chi tiết về sự thực thi, mà quan tâm trước hết đến các chức năng được định vị các thành phần và xác định sự tương tác của chúng Trong POAD, chúng ta xây dựng các ứng dụng từ tập hợp các mẫu thiết kế cấu trúc, đó là các thành phần thiết kế Chúng ta chọn một mẫu để giải quyết một vấn đề thiết kế cụ thể và xác định mối quan hệ giữa các mẫu và cách thức chúng tương tác với nhau Do đó, các mô hình kết quả từ POAD có thể được sử dụng như là khung nhìn kiến trúc của ứng dụng Phân rã ở mức cao của các ứng dụng được xem xét là một cách tiếp cận dựa trên kiến trúc

1.3.4 Tính phát triển được điều khiển từ thư viện mẫu

POAD sử dụng các danh mục các mẫu thiết kế có sẵn Cách tiếp cận này chủ yếu dựa vào sự tồn tại của các thư viện mẫu thiết kế và có thể sử dụng lại nó có thể xem

và yêu cầu Do đó, nhiều vấn đề về thư viện sử dụng lại truyền thống được tổ chức và gắn với việc trích rút tài sản lưu trữ trong các thư viện mẫu Bản chất của một mẫu thúc đẩy cách tiếp cận khác để bảo trì và duyệt các thư viện khác với thư viện tài sản

mã nguồn Một thư viện của các mẫu là cần thiết cho cách tiếp cận POAD Tuy nhiên, các vấn đề liên quan đến việc xây dựng vào bảo trì các thư viện mẫu là các chủ đề nghiên cứu sau này

 Bản thiết kế phần mềm là sản phẩm từ các hoạt phức tạp của việc phát triển phần mềm, đặc biệt là phân tích yêu cầu và thiết kế ứng dụng

 Những quyết định trong thiết kế khó hơn và phức tạp hơn là các quyết định triển khai ở mức thấp Sử dụng thiết kế thành phần tốt sẽ cải tiến chất lượng phần mềm và làm giảm các rủi ro trong phát triển

 Thiết kế là một tiến trình lặp Thiết kế có thể được chỉ dẫn bởi quá trình phân tích

ở mức cao (từ trên xuống) cũng như tiếp cận phát triển ở mức thấp (dưới lên) Tiếp cận từ trên xuống đảm bảo rằng, thiết kế theo đúng các yêu cầu của người

sử dụng, trong khi đó tiếp cận từ dưới lên lại đảm bảo thiết kế có tính thực thi cao

 Việc sử dụng lại thường giống nhau nhiều ở mức thiết kế hơn là khía cạnh thực thi hay mã nguồn Thường khó để đạt được nhờ đặc tả thành phần hoặc từ các yêu cầu phía người sử dụng Sự thỏa mãn đối với các thiết kế có thể khả thi hơn nhờ có khả năng sử dụng lại các hộp trắng của thiết kế thông qua sự làm thích nghi

 Các mẫu thiết kế có tính cấu trúc là các giải pháp thiết kế có nhiều đặc điểm chung Những người thiết kế ứng dụng thường sử dụng giải pháp thiết kế phổ biến và tập trung vào các ứng dụng cụ thể

 Các ngôn ngữ lập trình không cung cấp sự trừu tượng hóa ở mức cao cần thiết phù hợp với các nhà thiết kế hệ thống Các mẫu thiết kế cấu trúc cung cấp sự trừu tượng hóa ở mức cao này bằng cách cô lập giữa các phần cung cấp có ý nghĩa và

có quan hệ với nhau

1.3.6 Tính phát triển phân cấp

Sự phân rã và tích hợp theo cách phân cấp thường được dùng cho các mỗi quan

hệ bao gồm hay toàn bộ bộ phận của các mô hình về POAD Khi xem xét mối quan hệ giữa toàn bộ và các bộ phận của nó, chúng ta có thể xác định ba loại cấu trúc phân cấp:

 Sự bao gói: Tổ hợp toàn bộ che giấu các thành phần bên trong với thế giới bên

ngoài

 Sự nhúng: Tổ hợp toàn bộ được cấu thành từ các thành phần mà thế giới bên

ngoài có thể nhìn thấy

 Sự phân rã ảo: Tổ hợp toàn bộ là những khái niệm, không tồn tại như là một chế

Tác Khi sử dụng các mẫu thiết kế cấu trúc như các thành phần thiết kế là một cách tiếp cận ảo để phân rã Đó là vì, chính bản thân các mẫu có thể không hữu hình so sánh với các lớp mà sẽ được thực thi trong cấu trúc mã, xây dựng và các thể hiện như các đối tượng Do đó mẫu có thể được xem như là một nhóm ảo Tại

mức biểu đồ mẫu, các mẫu bao gói các chi tiết bên trong chúng và đưa ra các giao diện

1.3.7 Tính phát triển lặp

Tiến trình phát triển là một quá trình lặp, giống như phân tích trước đây, khi sử dụng các biểu đồ tuần tự, thí dụ: các quan hệ giữa các lớp có thể thay đổi Những thay đổi này phải được phản hồi lại trong biểu đồ mức mẫu Công cụ hỗ trợ cho tiến trình nên duy trì sự nhất quán giữa các mô hình thiết kế Các bước thiết kế chi tiết mà đi theo các kỹ thuật hướng đối tượng truyền thống bằng cách xác định các chi tiết và các khía cạnh của các lớp và các chế tác thiết kế khác

1.4 Tiến trình phân tích thiết kế hướng mẫu

Các khía cạnh của tiến trình POAD giải thích các pha và các bước để phát triển một thiết kế ứng dụng có sử dụng các mẫu Đầu ra của tiến trình điều khiển là một thiết kế mẫu hướng đối tượng hoặc là một khung làm việc hướng mẫu Yêu cầu chính của đầu vào tiến trình là thư viện các mẫu thiết kế cấu trúc được xây dựng Chúng ta

sử dụng thuật ngữ pha để ám chỉ các giai đoạn đã được biết trong phát triển phần

mềm: phân tích, thiết kế, thiết kế chi tiết, thực thi, kiểm thử… Chúng ta sử dụng thuật

ngữ bước để chỉ các hoạt động hay bước tiến trình mà người phân tích hay thiết kế tiến hành bên trong các pha cụ thể Chúng ta sẽ giải thích mỗi bước của pha phát triển qua

mục đích, tiến trình và sản phẩm; Phần mục đích giải thích vì sao nhà thiết kế tiến

hành bước đó, phần tiến trình mô tả sự hoạt động mà người thiết kế thực hiện trong bước đó, phần sản phẩm mô tả đầu ra mong muốn của bước đó

Thông thường, tiến trình POAD gồm có 3 pha: Trong pha phần tích một tập các

mẫu được chọn từ một thư viện miền cụ thể Ở pha thiết kế ở mức cao, các mẫu được gắn lại với nhau bằng cách sử dụng các mô hình cấu thành mẫu để tạo ra biểu đồ lớp ban đầu, và pha làm mịn thiết kế biểu đồ lớp ban đầu được xử lý để tạo ra biểu đồ lớp đậm đặc hơn và sâu hơn cho ứng dụng

Mô hình thác nước được sử dụng để giải thích cho tiến trình POAD giúp ta có một cái nhìn tổng quát về các giai đoạn phát triển và các bước bên trong mỗi giai đoạn

Sự tăng trưởng và sự phát triển lặp được khuyến khích và trên thực tế được minh họa bằng cách sử dụng một vài vòng lặp trong các tiến trình Sự lặp lại từ một cho đến nhiều bước được khuyến khích và có thể thực hiện được bằng cách giữ các mô hình thiết kế đã được tạo ra trong mỗi bước và cung cấp sự lần vết theo các mô hình này nhờ sử dụng một môi trường phát triển hay một công cụ hỗ trợ

Hình minh họa các kí pháp mà chúng ta sử dụng để mô tả vòng đời của POAD Trong đó hình vuông để mô tả một tác nhân và hình eclip để mô tả một tiến trình trong một bước nào đó Nó minh họa toàn bộ các pha phát triển của POAD, cho thấy sự

phân tích, thiết kế và các pha làm mịn thiết kế, mỗi pha này được giải thích chi tiết hơn trong hình :

Hình 1.2: Các ký hiệu được sử dụng miêu tả POAD

Trong hình, pha phân tích gồm có bước phân tích yêu cầu, tiếp theo sau là một bước lựa chọn Trong phân tích yêu cầu, thành phần khái niệm hay logical được xác định, còn trong bước lựa chọn thì tập các mẫu cần cho các thành phần logical sẽ được lựa chọn Trong các phần tiếp, sẽ mô tả ngắn gọn về các bước trong ba pha nói trên

1.4.1 Pha phân tích

Giai đoạn phân tích bao gồm các hoạt động chính sau:

 Phân tích các yêu cầu để xác định các vấn đề cần giải quyết và phân chia ứng dụng thành một tập các thành phần logic thực hiện các chức năng

 Làm quen bước đầu với cơ sở dữ liệu để biết được các mẫu đang tồn tại

 Tìm và lấy ra các mẫu từ cơ sở dữ liệu miền cụ thể để chọn một tập các mẫu ứng viên cho mỗi thành phần chức năng

 Lựa chọn các mẫu từ tập mẫu ứng viên để sử dụng cho tiến trình thiết kế

Mục đích của giai đoạn này là xác định tập các mẫu thiết kế sẽ sử dụng trong thiết kế ứng dụng Bắt đầu từ các yêu cầu về chức năng của ứng dụng và một cơ sở dữ liệu mẫu thiết kế, các xuất phẩm của giai đoạn này bao gồm:

 Tập các mẫu được các nhà phân tích lựa chọn để dùng trong phát triển ứng dụng

 Sự hợp lý của việc lựa chọn các mẫu này

 Những vấn đề của ứng dụng cụ thể được xác định thông qua phân tích các yêu cầu của ứng dụng

 Tài liệu trình bày vì sao mà các mẫu được chọn là hướng đến giải quyết được các vấn đề đặt ra

Phân tích trong giai đoạn này không cần quan tâm đến các chi tiết bên trong mẫu Chẳng hạn, khi phân tích không cần đi sâu vào các chi tiết cụ thể, sơ đồ lớp bên trong,

1 tiến trình sử dụng

1 tiến trình khác

chuỗi tương tác giữa các thành phần, sự thay đổi của các trạng thái cấu trúc của mẫu

Ở giai đoạn này không cần thiết phải hiểu các mẫu giải quyết vấn đề như thế nào; thay vào đó cần quan tâm đến việc những mẫu nào được lựa chọn, tại sao lại lựa chọn những mẫu đó và so sánh tính ưu việt của các mẫu này với các mẫu ứng viên khác

Hình 1.3: Pha phân tích POAD

Đối tượng chính của pha phân tích trong POAD là xác định một tập các mẫu có thể sử dụng trong thiết kế ứng dụng Giả thiết rằng có tồn tại các thư viện mẫu mà từ

đó nhà phân tích có thể lựa chọn các mẫu Các thư viện mẫu có thể là thư viện mẫu của lĩnh vực cụ thể hoặc thư viện mẫu cho mục đích chung

Làm quen bước đầu

Mục đích của hoạt động này là để các nhà phân tích làm quen bước đầu tance) với các giải pháp đang tồn tại thể hiện qua các mẫu trong lĩnh vực ứng dụng này Đối tượng là giúp các nhà phân tích định danh được tập có thực các mẫu có thể đáp ứng được các yêu cầu của ứng dụng, tức là tập các thành phần mà có thể triển khai các giải pháp cụ thể cho ứng dụng Hoạt động này là một tiến trình mà nhờ nó nhà phân tích tự làm quen với các mẫu đang tồn tại có trong cơ sở dữ liệu Trong tiến trình này, nhà phân tích có được các hiểu biết về những giải pháp đã có trong lĩnh vực ứng dụng Điều đó cũng thường thấy như trong tiến trình phát triển phần mềm truyền thống Trên cơ sở thư viện này các nhà phát triển ứng dụng đưa ra chương trình tốt

(acquain-nhất cho ứng dụng của mình Trong POAD ta dựa trên cơ sở dữ liệu mẫu để lần lượt giải quyết các vấn đề đã được xác định trong ứng dụng

Sản phẩm của pha này là một tập các mẫu thiết kế đã các nhà phân tích ứng dụng chọn Chú ý là, ở pha này không có bất cứ chi tiết cụ thể nào về mẫu được đưa

ra Có nghĩa là, không có một mô hình lớp hoặc mô hình hành vi nào cần đưa ra ở đây

Tim, lấy ra các mẫu

Mục đích của hoạt động tim, lấy ra các mẫu (Retrieval) này là lấy ra được các

mẫu ứng viên từ cơ sở dữ liệu mẫu để sử dụng trong giai đoạn tiếp theo Hoạt đông này tập trung vào vấn đề: Lựa chọn một mẫu từ danh mục của các mẫu thiết kế như thế nào? Danh mục mẫu thường lưu dưới dạng của cơ sở dữ liệu mẫu: Các mẫu có mục đích chúng hay được dùng trong một lĩnh vực cụ thể Nói một cách ngắn gọn thì cơ sở mẫu chính là đầu vào của giai đoạn phân tích Trong tiến trình phân tích có hai hoạt động cần liên hệ với cơ sở mẫu là: Làm quen bước đầu, tìm và lấy ra các mẫu Làm quen bước đầu được định nghĩa như là trình duyệt qua các mẫu trong cơ sở dữ liệu mẫu Việc tìm và lấy ra các mẫu từ cơ sở dữ liệu mẫu tượng tự vấn đề tìm kiếm và lấy

ra một tài sản phần mềm từ thư viện tài sản, mà tài sản chính là các mẫu thiết kế, còn thư viện là cơ sở dữ liệu mẫu

Sản phẩm cuối cùng của hoạt động này là tập các mẫu ứng viên Tiếp theo, dựa

trên kết quả này để chọn ra các mẫu thiết kế sử dụng trong giai đoạn thiết kế

Lựa chọn mẫu

Mục đích của hoạt động lựa chọn mẫu là chọn ra các mẫu đáp ứng đầy đủ các trách nhiệm của mỗi thành phần khái niệm được xác định từ việc xác định yêu cầu của ứng dụng Các mẫu này sẽ được sử dụng trong giai đoạn thiết kế của phương pháp POAD để xây dựng các khung nhìn mức mẫu.Việc lựa chọn mẫu phù hợp với thành

phần khái niệm là một nhiệm vụ khó khăn ngay cả với một thư viện mẫu nhỏ Sản

phẩm của tiến trình này là tập các mẫu được sử dụng để thiết kế ứng dụng

1.4.2 Pha thiết kế

Trong giai đoạn này, các mẫu trong tập mẫu đã được lựa chọn qua giai đoạn phân tích được sử dụng làm cơ sở xây dựng bản thiết kế đầu tiên Các tài liệu của quá trình phân tích cũng được sử dụng để liên kết các mẫu với nhau nhằm phát triển thiết kế của ứng dụng Các tài liệu này chứa nhiều thông tin về cách thức giải quyết vấn đề của các mẫu và cách phân tích ứng dụng thành nhiều thành phần có khả năng tương ứng với mẫu

Giai đoạn thiết kế gồm ba hoạt động chính:

 Xây dựng sơ đồ mức mẫu thể hiện cấu tạo chung của các mẫu

 Xây dựng sơ đồ giao diện mức mẫu

 Xây dựng sơ đồ chi tiết ứng dụng với cấu tạo bên trong của các mẫu

Giai đoạn này tạo ra các mô hình thiết kế Mục đích của giai đoạn thiết kế là sử dụng các mẫu thiết kế làm đơn vị cơ sỏ để tạo ra các bản thiết kế của ứng dụng Bắt đầu từ tập các mẫu đã được lựa chọn trong giai đoạn phân tích Chi tiết của giai đoạn thiết kế gồm :

 Thiết kế tổng quát ứng dụng từ một hoặc nhiều sơ đồ mức mẫu

 Thiết kế giao diện dựa trên mối liên hệ giao diện giữa các mẫu

 Thiết kế chi tiết ứng dụng dựa trên cấu tạo bên trong của các mẫu

Hình 1.4: Pha phân tích POAD

Cấu trúc các mô hình mức mẫu

Mục đích của giai đoạn này là tạo ra mô hình thiết kế của ứng dụng dựa trên các mẫu thiết kế Kết quả của giai đoạn phân tích là đưa ra tập các mẫu có khả năng cung cấp các chức năng theo yêu cầu của người sử dụng Các mẫu này được sử dụng để thiết kế giao diện tổng quan của ứng dụng (high-level view) Giao diện tổng quan của

ứng dụng được tạo ra qua một số bước: phân loại mẫu, xác định mối quan hệ giữa các

loại này và phát triển sơ đồ mức mẫu Sản phẩm của giai đoạn này là sơ đồ mức mẫu của ứng dụng hoặc của mỗi hệ thống con hay khung làm việc

Cấu trúc các mô hình mức mẫu với các giao diện

Mục đích của giai đoạn này là phân tích quan hệ giữa các định danh mẫu và xác định quan hệ giữa các thể hiện của chúng Với mô hình thiết kế ở mức thấp hơn của ứng dụng cần xác định quan hệ phụ thuộc không chỉ giữa các mẫu, khối mẫu mà còn là giữa các thành phần bên trong của một mẫu và giữa các thành phần bên trong của mẫu này với các thành phần bên trong của các mẫu khác Đây chính là bước phát triển sơ

đồ thể hiện mức mẫu Sơ đồ này sẽ hỗ trợ việc xác định quan hệ phụ thuộc ở mức thấp hơn nữa giữa các lớp cụ thể Sơ đồ mức mẫu là bước trung gian, là cầu nối giữa hai mức thiết kế trừu tượng: ở mức cao là quan hệ giữa các mẫu, khối mẫu và mức thấp là

quan hệ giữa các lớp cụ thể, các thành phần bên trong của các mẫu Sản phẩm của quá trình này là sơ đồ thể hiện mức mẫu, chi tiết hơn sơ đồ mức mẫu, biểu diễn quan hệ giữa các thể của hiện mẫu

Cấu trúc các mô hình mức mẫu chi tiết

Mục đích của hoạt động này là dựa vào sơ đồ thể hiện mẫu tìm hiểu cấu trúc bên trong của mẫu, từ đó xây dựng sơ đồ lớp của ứng dụng Trong hoạt động này, người thiết kế tìm hiểu về sơ đồ lớp bên trong mẫu dựa trên sơ đồ thể hiện mẫu Người thiết

kế cần tìm hiểu các tài liệu mẫu, các thành phần cụ thể bên trong sơ đồ lớp và cách giải quyết các vấn đề thiết kế Những hiểu biết thu được từ hoạt động này rất hữu ích

cho việc xây dựng sơ đồ lớp cho toàn thể ứng dụng, Sản phẩm của giai đoạn này là sơ

đồ mẫu chi tiết sử dụng làm đầu vào trong các giai đoạn thiết kế sau

1.4.3 Pha làm mịn thiết kế

Trong pha làm mịn thiết kế, chúng ta tạo ra biểu đồ lớp của hệ ứng dụng khi sử dụng biểu đồ lớp của các khối mẫu được xây dựng Đầu vào của pha này là biểu đồ mức mẫu chi tiết đã xây dựng từ pha thiết kế Những biểu đồ thiết kế này được sử dụng để mô hình hóa ứng dụng như một tập các mẫu, các mối liên kết và các quan hệ giữa chúng Trong tiến trình thiết kế, nhà thiết kế đã nắm bắt được những chi tiết bên trong của mẫu thiết kế được chọn Chi tiết này sẽ hữu ích trong mọi hoạt động của pha làm mịn thiết kế

Pha làm mịn thiết kế có ba hoạt động chính:

 Thể hiện phần bên trong mẫu, mà ở đó chúng ta thêm bản chất của ứng dụng cụ

thể vào thiết kế bên trong của các mẫu

 Phát triển các biểu đồ lớp, xây dựng biểu đồ lớp ban đầu của ứng dụng

 Tối ưu thiết kế, là tối ưu biểu đồ lớp của ứng dụng bằng cách chồng lấp nếu có

thể các thể hiện của mẫu

Mục đích của pha này là tạo biểu đồ lớp của ứng dụng khi sử dụng biểu đồ lớp của mẫu và về miền cụ thể của ứng dụng Bắt đầu từ tập biểu đồ mức mẫu chi tiết được phát triển trong pha thiết kế trước Sản phẩm đưa ra từ pha làm mịn thiết kế bao gồm:

 Thể hiện ứng dụng cụ thể của mỗi mẫu thiết kế được sử dụng Đó là mô tả mô hình thiết kế gốc của mẫu khi sử dụng ứng dụng cụ thể và đặt tên mẫu thích hợp

 Các mô hình biểu đồ lớp ban đầu của thiết kế ứng dụng biểu diễn mô hình biểu

đồ thiết kế của ứng dụng như một bộ lắp ghép lỏng lẻo từ các mẫu

 Các mô hình biểu đồ lớp tối ưu cho ứng dụng mô tả mô hình biểu đồ lớp của ứng dụng một cách dày đặc và sâu sắc hơn Chúng sẽ đước sử dụng mà được sử dụng trong pha thiết kế chi tiết và triển khai

Hình 1.5: Tiến trình làm mịn thiết kế POAD

Minh họa bên trong mẫu

Mục đích của bước này là tạo một thể hiện của ứng dụng cụ thể của mẫu khi sử dụng biểu đồ mức mẫu chi tiết Người thiết kế tạo ra một thể hiện cho mỗi mẫu lựa chọn Thể hiện một mẫu thiết kế có nghĩa là biến nó thành một chế tác hữu hình Tiến trình thể hiện gồm việc mô tả các mẫu và các phần tử của nó trong một ngữ cảnh ứng dụng cụ thể Phần đầu của hoạt động này đã được hoàn thành trong pha thiết kế, khi người phân tích chọn một tên ứng dụng cụ thể cho thể hiện của mẫu Phần thứ hai liên

quan đến thể hiện các phần bên trong mẫu là chủ đề của hoạt động trong pha này Sản phẩm của pha này là các biểu đồ mức mẫu chi tiết của ứng dụng cụ thể Các biểu đồ

này thể hiện đầy đủ ứng dụng cụ thể thông qua các mẫu đã được lựa chọn

Phát triển biểu đồ lớp ban đầu

Mục đích của bước này là để phát triển biểu đồ lớp của ứng dụng khi sử dụng biểu đồ lớp chi tiết của mẫu Trong hoạt động này, chúng ta sử dụng biểu đồ mức mẫu chi tiết được phát triển từ pha thiết kế, các thể hiện của mẫu, các chi tiết thể hiện phần bên trong mẫu để tạo ra một biểu đồ lớp UML cho ứng dụng Một biểu đồ lớp, là bước

đầu phát triển mô hình mẫu thiết kế tĩnh của ứng dụng Sản phẩm của hoạt động này

là biểu đồ lớp UML ban đầu cho thiết kế ứng dụng Những biểu đồ, lớp còn chưa dày

đặc và cũng sâu sắc Chúng biểu diễn một sự ghép nối các thiết kế bên trong của các thể hiện mẫu

Tối ưu thiết kế

Mục đích của bước này là tối ưu hoá biểu đồ lớp UML ban đầu đã phát triển từ sớm trong pha làm mịn thiết kế Biểu đồ lớp tối ưu là hiên bản dày đặc và sâu sắc hơn những gì đã có của thiết kế chi tiết và triển khai Trong hoạt động này, việc tối ưu biểu

đồ lớp được tiến hành bằng cách loại bỏ bản sao các lớp trừu tượng và hợp nhất các

thành phần tham gia từ vài mẫu Sản phẩm của pha này là biểu đồ lớp tối ưu cho ứng dụng

1.5 Những lợi ích và hạn chế của POAD

Tiếp cận phát triển phần mềm định hướng mẫu là một trong ba hướng phát triển triển phần mềm đối tượng định hướng sử dụng lại Vậy cách tiếp cận này có những ưu điểm và hạn chế gì? Điều này rất cần thiết cho việc ứng dụng nó trong thực tiễn

truyền thống được thực hiện phân tích và cải tiến một cách sâu sắc trong POAD, bởi vì các thiết kế này đã được đúc rút ra cải tiến từ rất nhiều ứng dụng thành công

 Việc làm tài liệu tốt hơn của thiết kế ứng dụng/khung làm việc Các biểu đồ mức mẫu cung cấp khung nhìn ở mức cao của thiết kế Các khung nhìn trừu tượng này như những tài liệu thiết kế cho ứng dụng, do đó chúng ta có thể cải tiến khả năng hiểu được của thiết kế Ở rất nhiều quy trình phát triển hướng đối tượng khác, các gói và các hệ thống con được sử dụng để nhóm các lớp lại với nhau Những cái đưa vào cùng một gói thường là quyết định thiết kế quan trọng Trong POAD, phần bên trong mẫu là đã được biết, chính là những mô hình lớp được thiết kế tốt Rủi ro trong việc sử dụng sai các khung làm việc thiết kế hướng đối tượng được giảm bớt nhờ tác dụng của sự cải tiến khả năng hiểu được của các thiết kế, các lớp Kết quả của các mẫu tầng được đưa vào gần đây và tính lần vết đến các mức thiết kế thấp hơn làm cho thiết kế dễ hiểu hơn

 Sử dụng các mẫu như các khối xây dựng cho khung nhìn kiến trúc của ứng dụng, bởi vì chúng ta không cụ thể các vấn đề thực thi tại khung nhìn trừu tượng mức cao của giao diện các mẫu Tuy nhiên, các thành phần kiến trúc của chúng trên thực tế là các phần tử thiết kế bên trong giới hạn của sự cộng tác giữa các lớp Do

đó chúng ta có khả năng lần vết đến khung nhìn kiến trúc từ thiết kế mức thấp đến các khung nhìn thực thi

 Những thiết kế hướng mẫu cho chất lượng cao hơn các thiết kế hướng đối tượng truyền thống, bởi vì chúng sử dụng các mẫu thiết kế đã được làm tài liệu có chất lượng cao, các giải pháp đã được kiểm chứng cho các vấn đề thiết kế

 ―Các mẫu triển khai‖ khi thực thi các mẫu thiết kế, những người lập trình có thể

tạo, mở rộng và chỉnh sửa các lớp ở khắp nơi của phần mềm Nó có thể duy trì khả năng lần vết, giúp các lập trình viên không ―đánh mất khả năng nhìn các mẫu ban đầu‖ Phương pháp POAD quan tâm đến vấn đề này, bởi vì với các khung nhìn mức mẫu được thêm vào các pha thiết kế mức cao, các mẫu được xử lý như

 POAD cung cấp một giải pháp cho vấn đề khả năng lần vết đơn giản sử dụng các

mô hình thiết kế và nắm bắt khung nhìn ở mức cao của hệ thống Khi sử dụng các mô hình để nắm bắt những chi tiết và cung cấp một liên kết giữa khung nhìn

mức cao và các chi tiết mức thấp hơn Trong POAD, cấu trúc của các mẫu là lâu bền, có nghĩa là tất cả các lớp vẫn được thể hiện ở các mức thiết kế

1.5.2 Các mặt hạn chế

POAD gặp một số trở ngại:

 Sự hiểu được các mẫu vốn là các hoạt động tinh thần đặc biệt Để đưa ra quyết định đúng đắn trong việc chọn lựa mẫu trong thiết kế, người thiết kế phải hiểu được sự trả giá, động cơ thúc đẩy, sức mạnh và các mẫu liên quan Rất khó để phân tích được cái giá phải trả cho các lợi ích mà người thiết kế đạt được khi sử dụng mẫu trong phạm vi chất lượng của giải pháp đã được kiểm chứng

 Để trợ giúp quy trình POAD, hiện thời không đủ tài liệu của các kho mẫu được

tổ chức tốt Yếu tố cần thiết là có các kho mẫu được lưu trữ trong cơ sở dữ liệu Những thư viện này thường có thành phần truyền thống, như thư viện các vấn đề, các kỹ thuật trích rút thành phần và cấu trúc thư viện Khi sử dụng mẫu POAD giả định rằng, các giao diện mẫu được xác định trước Khái niệm các giao diện mẫu là mới, nhiều người còn xa lạ Chúng chỉ được sử dụng để sử dụng các mẫu tại mức biểu đồ lớp Trên thực tế, các tài liệu phần lớn mẫu hoàn toàn nói chưa nói đến những gì về đối tượng khách hay nhân tố bên ngoài sử dụng mẫu Chúng

ta vẫn phải yêu cầu một sự nỗ lực để xác định các giao diện mẫu cho các tài liệu

đã có và chỉ dẫn trên mẫu để có thể trợ giúp các nhà phát triển nhận diện và lựa chọn mẫu

CHƯƠNG 2 MỘT SỐ MẪU TRONG PHÁT TRIỂN KIẾN TRÚC PHẦN MỀM

2.1 Giới thiệu về mẫu

Ứng dụng của mẫu trong thực tế phân tích thiết kế phần mềm hướng đối tượng là rất lớn Hầu như cứ ở đâu có phần mềm hướng đối tượng thì ở đó có mẫu Mẫu được vận dụng linh hoạt và dưới nhiều hình thức khác nhau Trong chương này sẽ giới thiệu một số mẫu tiêu biểu trong thực tiễn phát triển phần mềm hướng đối tượng và cũng được sử dụng trong ứng dụng của luận văn này

2.2 Phân loại về mẫu

Hệ thống các mẫu hướng đối tượng hiện có 23 mẫu được trình bày trong cuốn

―Design patterns Elements of Reusable Object Oriented Software‖

Hình 2.1: Mối quan hệ giữa các Pattern GoF

Hệ thống các mẫu này có thể nói là đủ và tối ưu cho việc giải quyết phần lớn các vấn đề của bài toán phân tích thiết kế và xây dựng phần mềm trong thời điểm hiện tại

Hệ thống các mẫu được chia thành 3 nhóm: Nhóm mẫu kiến tạo(Creational Pattern), nhóm Mẫu cấu trúc (Structural Pattern), nhóm Mẫu hành vi (Behavioral Pattern)

2.2.1 Nhóm mâu kiến tạo (Creational Pattern)

Nhóm này liên quan tới việc tạo ra các thể nghiệm (instance) của đối tượng, tách biệt với cách được thực hiện từ ứng dụng Muốn xem xét thông tin của các mẫu trong nhóm này thì phải dựa vào biểu đồ nào phụ thuộc vào chính mẫu đó, mẫu thiên về hành vi hay cấu trúc

Nhóm này gồm có 5 mẫu:

1 Abstract Factory Cung cấp một giao diện cho việc tạo lập các đối tượng (có

liên hệ với nhau) mà không cần qui định lớp và xác định lớp

cụ thể (concrete) của đối tượng

2 Factory Method Định nghĩa một giao diện cho phép để sinh ra đối tượng

nhưng để cho lớp con quyết định lớp nào được dùng Nó cho phép một lớp chuyển quá trình khởi tạo đối tượng cho lớp

con

khỏi bản thân nó sao cho cùng một tiến trình xây dựng có thể

tạo được các biểu diễn khác nhau

đối tượng mẫu, việc tạo mới đối tượng nhờ vào sao chép đối tượng mẫu nầy

điểm truy xuất toàn cục đến nó

2.2.2 Nhóm mẫu cấu trúc (Structural Pattern)

Nhóm này liên quan tới các quan hệ cấu trúc giữa các thể nghiệm, dùng kế thừa, kết tập, tương tác Để xem thông tin về mẫu này phải dựa vào biểu đồ lớp của mẫu

Nhóm này gồm có 7 mẫu:

lớp thành một giao diện khác phù hợp với yêu cầu người sử

dụng

2 Bridge Tách rời ngữ nghĩa của một vấn đề khỏi việc cài đặt Mục đích

để cả hai bộ phận (ngữ nghĩa và cài đặt) có thể thay đổi độc

lập nhau

các đối tượng trong cấu trúc được thao tác theo một cách thuần nhất như nhau Tạo quan hệ thứ bậc bao gộp giữa các

đối tượng

chạy (dynamically)

trong một hệ thống con (subsystem) Nó định nghĩa giao diện mức cao hơn các giao diện có sẵn để làm cho hệ thống con dễ

sử dụng hơn

hoặc kiểm soát quá trình truy xuất đối tượng đó Đối tượng

thay thế gọi là proxy

lớn đối tượng (chẳng hạn paragraph, dòng, cột, ký tự…)

2.2.3 Nhóm mẫu hành vi (Behavioral Pattern)

Nhóm này liên quan đến các quan hệ gán trách nhiệm để cung cấp các chức năng giữa các đối tượng trong hệ thống Đối với các mẫu thuộc nhóm này ta có thể dựa vào biểu đồ cộng tác và biểu đồ diễn tiến Biểu đồ cộng tác và biểu đồ diễn tiến sẽ giải thích cho ta cách chuyển giao của các chức năng

Nhóm này gồm có 11 mẫu:

1 Chain of

đối tượng nhận thông điệp được kết nối thành một chuỗi và thông điệp được chuyển dọc theo chuỗi nầy đến khi gặp được đối tượng xử lý Tránh việc gắn kết cứng giữa phần tử gửi yêu cầu với phần tử nhận và xử lý yêu cầu bằng cách cho

phép hơn một đối tượng có có cơ hội xử lý yêu cầu

toán tổng quát gọi đến một số phương thức chưa được cài đặt

trong lớp cơ sở Việc cài đặt các phương thức được ủy nhiệm

cho các lớp kế thừa

cho một ngôn ngữ

thành một đối tượng Các yêu cầu sẽ được lưu trữ và gởi đi

như các đối tượng

5 Iterator Truy xuất các phần tử của đối tượng dạng tập hợp tuần tự

như danh sách, mảng…Mà không phụ thuộc vào biểu diễn

bên trong của các phần tử

số đối tượng với nhau

7 Memento Hiệu chỉnh và trả lại như cũ trạng thái bên trong của đối

tượng mà vẫn không vi phạm việc bao bọc dữ liệu

đối tượng thay đổi trạng thái thì tất cả các đối tượng phụ

thuộc nó cũng thay đổi theo

trong của nó thay đổi

10 Strategy Bao bọc một họ các thuật toán bằng các lớp đối tượng để

thuật toán có thể thay đổi độc lập đối với chương trình sử dụng thuật toán.Cung cấp một họ giải thuật cho phép chọn

lựa linh động một giải thuật cụ thể khi sử dụng

11 Visitor Cho phép định nghĩa thêm phép toán mới tác động lên các

phần tử của một cấu trúc đối tượng mà không cần thay đổi

trong khi mẫu Observer được đề xuất để giải quyết việc trình bày dữ liệu cho các ứng dụng truyền thống trên máy đơn, thì mẫu MVC dùng để thiết lập kiến trúc của ứng dụng trên Web

Mô hình tổng thể của mẫu MVC được trình bày như trong Hình 2.2 Các mũi tên

nét đứt trong hình có ý nghĩa là ―có thể truy xuất‖ hay là ―biết thông tin về‖ View và

Controller truy xuất được lẫn nhau, cùng biết thông tin về Model Tuy nhiên Model không thể truy xuất đến View cũng như Controller Theo mô hình này, mỗi thành phần của ứng dụng Web được tổ chức tách biệt thành 3 phần: Model (mô hình bên trong), View (hiển thị bên ngoài), Controller (bộ điều khiển nhập xuất và cập nhật phần hiển thị) Nhờ sự tách biệt ba khía cạnh này mà mẫu MVC giải quyết được nhiều vấn đề nảy sinh khi phát triển ứng dụng Web

Hình 2.2: Sơ đồ mẫu MVC

Mô hình trong (Model)

Mô hình là đối tượng biểu diễn thông tin nghiệp vụ bên trong ứng dụng đang xây dựng Đối tượng này bao bọc các thành phần dữ liệu và các phương thức liên quan đến ứng xử của nó Khi phát triển các lớp đối tượng này, người lập trình chỉ quan tâm cài đặt các xử lý hay tiến trình tác nghiệp của ứng dụng mà không cần quan tâm đến chúng được hiển thị ra các thiết bị xuất hay lấy vào từ thiết bị nhập như thế nào

Hiển thị bên ngoài (View)

Hiển thị là thành phần liên quan đến giao diện người dùng Người sử dụng

―thấy‖ được đối tượng nghiệp vụ bên trong ứng dụng nhờ phần hiển thị (tức là View) của nó Đối tượng có thể được hiển thị dưới dạng một trang HTML, một hộp chọn (listbox), hay một danh sách chọn dạng cây (tree view)

Bộ điều khiển (Controller)

Bộ điều khiển đảm nhiệm việc cập nhật bộ phận hiển thị (View) khi cần thiết Bộ điều khiển này nhận dữ liệu nhập từ người dùng, truy xuất các thông tin cần thiết từ

mô hình trong (Model), và xuất ra bộ hiển thị ở dạng thích ứng.Giao diện với người sử dụng phần mềm được thiết lập nhờ sự tương tác qua lại giữ hiển thị và bộ điều khiển:

hai bộ phận này chính là phần trình bày bên ngoài của đối tượng biểu diễn bên trong Người sử dụng chỉ biết về đối tượng bên trong thông qua phần bên ngoài là hiển thị và

Bộ điều khiển

Trong mô hình MVC, sự tách biệt giữa phần trình diễn khỏi phần biểu diễn trong (Model) chính là yếu tố quan trọng góp phần nâng cao chất lượng thiết kế phần mềm Việc tách biệt được mã nguồn liên quan đến nghiệp vụ ứng dụng và mã nguồn giao diện người dùng, tạo cơ chế để tránh được mã hóa cứng và trùng lặp mã nguồn, sự sửa đổi về mô hình trong không ảnh hưởng dây chuyền đưa đến việc sửa đổi nhiều phần giao diện người dùng bên ngoài Ứng dụng có thể phát triển và mở rộng: với cùng một

mô hình trong có thể có nhiều hình thức giao tiếp bên ngoài với người sử dụng (trình duyệt Web, giao tiếp dòng lệnh, hiển thị đồ họa…) Hầu hết các công nghệ hỗ trợ phát triển ứng dụng Web hiện đại đều sử dụng mô hình MVC giúp người phát triển phần mềm Web thiết kế được các ứng dụng dễ mở rộng và dễ bảo trì sau này, ví dụ với ngôn ngữ lập trình Java một số framework hỗ trợ mô hình MVC trong phát triển như: Struts, Spring, JSF… hay Dot.net có MVC Dot.net, Php Zend framework

2.3.2 Mẫu Kiến trúc Add-Ins

Kiến trúc phần mềm Add-Ins là một mô hình ứng dụng cho phép tạo ra một giao diện ghép nối các môđun ứng dụng một cách dễ dàng và cho phép mở rộng các chức năng của ứng dụng chính Việc áp dụng mẫu kiến trúc Add-ins là rất phổ biến trong các ứng dụng

Extensible Module

Gloabal Property Resource

Utilities

GUI Layer

Plugin Plugin

Plugin

Hình 2.3: Kiến trúc Add-Ins

Ứng dụng gồm có nhân ứng dụng (core) và các môđun được ghép nối là các gói DLL Cấu hình của ứng dụng được lưu vào các file định dạng XML Global property thường là các mẫu thực thể (datasim) có thể cấu hình các thành phần được

Global Properties: Lưu trữ các cấu hình của hệ thống

Resource: thường là các lớp singleton quản lý tài nguyên tập trung bao gồm

 Abstract Method Proxy,

 Facade và Memento (kết hợp với XML)

Extensible Module: Đây là phần quan trọng của nhân ứng dụng Nó cung cấp các

giao diện ghép nối với các mô đun bên ngoài Các lớp trong phần này thường được cài đặt dưới dạng các Entity patterns (mẫu thực thể), hay còn gọi là các Codon Mỗi codon gồm có:

 ID (name - chỉ duy nhất một tên cho một codon)

 Label (nhãn có thể trùng nhau)

 Class (đây là mã thực thi của codon đó) Class này thường là áp dụng mẫu Command

2.3.3 Mẫu kiến trúc phân tầng (Layered Architecture)

Trong việc phát triển phần mềm thì mẫu kiến trúc phân tầng―Layered ture‖ là một mô hình kiến trúc cơ bản cho chúng ta thiết kế ra một phần mềm có tính mềm dẻo và có tiến hóa cao hơn Trong phát triển phần mềm kiến trúc phân tầng thường được áp dụng với kiến trúc 3 tầng ―3 layer‖ Đó là một mô hình chuẩn khi phát triển một phần mềm ngày nay Nó bao gồm các tầng: Tầng giao diện (GUI Layer), tầng nghiệp vụ (Layer Business Logic) và tầng truy cập dữ liệu (Layer Data Access)

Tầng giao diện(GUI Presentation Layer): Tầng trình bày giao diện tạo lên giao diện

cho người dùng, nó sẽ là nơi trình bày dữ liệu tiếp nhận và kết xuất ra kết quả của chương trình cho người dùng và có nhiệm vụ xử lý, kiểm tra các dữ liệu nhập vào Tại tầng này tiếp nhận các sự kiện của người dùng, kiểm tra dữ liệu, gửi yêu cầu xử lý xuống tầng kế tiếp là tầng nghiệp vụ

Tầng xử lý nghiệp vụ (Business Logic Layer): Đây là tầng xử lý chính các dữ liệu

trước khi được đưa lên hiển thị trên màn hình hoặc xử lý các dữ liệu trước khi lưu dữ liệu xuống cơ sở dữ liệu Đây là nơi đê kiểm tra và thực thi các yêu cầu nghiệp vụ, tính toán các yêu cầu nghiệp vụ.Tại đây tất cả các logic nghiệp vụ được thực hiện Tại tầng này nó sẽ nhào nặn dữ liệu cho phù hợp trước khi lưu xuống hoặc hiển thị lên chương trình

Tầng truy xuất dữ liệu (Data Access Layer): Tầng truy xuất dữ liệu này sẽ lo nhiệm

vụ là đọc cơ sở dữ liệu lên, cập nhật cơ sở dữ liệu Tầng này làm nhiệm vụ là thao tác

trao đổi hệ thống với cơ sở dữ liệu

2.3.4 Mẫu thiết kế Abstract Factory

Mẫu thiết kế ―Abstract Factory‖ Cung cấp một giao diện cho việc tạo lập các đối

tượng (có liên hệ với nhau) mà không cần qui định và xác định lớp cụ thể (concrete) của đối tượng Các lớp sản xuất này có chung một giao diện được kế thừa từ một lớp cha thuần ảo gọi là ―lớp sản xuất ảo‖ Tức nó là một lớp giao diện hoặc lớp trừu tượng (interface, abstract) Việc tạo đối tượng còn phụ thuộc vào nhiều yếu tố khác nhau Ứng với mỗi yếu có một lớp cụ thể

Tình huống áp dụng:

 Hệ thống sử dụng nhiều họ đối tượng có chung đặc điểm gọi là các đối tượng cùng chung gia đình (families of objects)

 Tạo đối tượng độc lập với hệ thống sử dụng

 Các đối tượng cần phải được tạo ra như một tập hợp để có thể tương thích với nhau

 Hệ thống muốn cung cấp một tập các lớp mà chúng ta muốn thể hiện các ràng buộc, các mối quan hệ giữa chúng mà không phải là các thực thi của chúng Mỗi khi có thêm một "sản phẩm" ta lại phải định nghĩa thêm một lớp "sản xuất"

Hình 2.5: Ví dụ về sử dụng mẫu thiết kế Abstract Factory

Trong đó:

AbstractFactory: Định nghĩa một giao tiếp cho thao tác khởi tạo các "sản phẩm" ảo

ConcreteFactory: Thực thi giao tiếp AbstractFactory để tạo ra đối tượng cụ thể

AbstractProduct: Định nghĩa một lớp ảo cho một loại đối tương "sản phẩm"

Product: Kế thừa từ từ lớp "sản phẩm" ảo AbstractProduct, các lớp Product định

nghĩa từ đối tượng cụ thể

Client: Sử dụng các lớp AbstractFactory và AbstractProduct trong hệ thống

2.3.5 Mẫu thiết kế Factory

Mẫu thiết kế ―Factory‖ là mẫu thiết kế dùng để định nghĩa một giao diện cho

phép để sinh ra đối tượng nhưng để cho lớp con quyết định lớp nào được dùng Thực chất đó là việc chuyển quá trình khởi tạo đối tượng cho lớp con

Tình huống áp dụng:

 Một lớp không thể lường trước được các lớp của đối tượng đó phải khởi tạo

 Một lớp muốn các lớp con của nó chỉ rõ các đối tượng nó tạo ra

Hình 2.6: Ví dụ về mẫu thiết kế Factory

Trong đó:

Product: Định nghĩa giao diện của các đối tượng mà Factory Method tạo ra

ConcreteProduct: Cài đặt giao diện cho Product

Creator: Khai báo Factory Method mà trả về một đối tƣợng của kiểu Product Sự kiến

tạo này cũng có thể định nghĩa một cài đặt mặc định của Factory Method trả về một đối tƣợng

ConcreteCreator: Chồng lên Factory Method để trả về một thể nghiệm của một creteProduct

Con-2.3.6 Mẫu thiết kế State

Mẫu thiết kế ―State‖ cho phép một đối tƣợng thay đổi hành vi khi trạngthái bên trong của nó thay đổi

Tình huống áp dụng:

 Hành vi của đối tƣợng phụ thuộc vào trạng thái của nó và nó phải thay đổi hành

vi này khi trạng thái của nó thay đổi

 Khi một hành vi của một đối tƣợng đƣợc thay đổi theo các điều kiện nhất định và mỗi trạng thái là một nhánh của một điều kiện

Hình 2.7: Ví dụ về mẫu thiết kế State

Trong đó:

Context: Định nghĩa giao diện mà đối tƣợng khách quan tâm đến Duy trì một thể

nghiệm của một lớp ConcreteState mà định nghĩa trạng thái hiện tại

State: Định nghĩa một giao diện cho việc đóng gói hành vi kết hợp với trạng thái đặc

biệt của Context

Concrete State: Mỗi lớp con cài đặt một hành vi kết hợp với một trạng thái của

Con-text

2.3.7 Mẫu thiết kế Strategy

Mẫu thiết kế ―Strategy‖ là mẫu thiết kế dùng để định nghĩa một họ các thuật

toán, đóng gói mỗi thuật toán đó và làm cho chúng có khả năng thay đổi dễ dàng Mẫu này cho phép giả thuật tùy biến một cách độc lập khi sử dụng nó

Tình huống áp dụng:

 Nhiều lớp liên quan chỉ khác nhau ở cách xử lý yêu cầu

 Một thuật toán khi triển khai có nhiều cách thực hiện

 Cho phép lựa chọn cách ưu việt nhất trong sử dụng tài nguyên ví dụ như: chỗ ngồi, thời gian…

 Thuật toán dùng dữ liệu mà khách hàng không biết tới

 Dùng để thay thế việc khai hoá những cấu trúc dữ liệu phức tạp, đặc thù cho thuật toán

 Khi có nhiều cách xử lý khác nhau và những cách xử lý này có thể coi như câu lệnh chia nhánh trong phương thức Thay vì dùng cấu trúc điều kiện ta dùng mẫu ―Strategy‖ cài đặt riêng từng nhánh

Hình 2.8: Ví dụ về mẫu thiết kế Strategy

Trong đó:

Strategy: Khai báo một giao diện thông thường tới tất cả các giải thuật được hỗ trợ

ConcreteStrategy: Cài đặt giải thuật sử dụng giao diện Strategy

Context: Đƣợc cấu hình với một đối tƣợng ConcreteStrategy Duy trì một tham chiếu

tới một đối tƣợng Stategy Có thể định nghĩa một giao diện để cho Strategy truy nhập

dữ liệu của nó

3.3.8 Mẫu thiết kế Observer

Mẫu thiết kế ―Observer‖ mục đích nhƣ một quan sát viên nó định nghĩa một phụ thuộc 1- nhiều giữa các đối tƣợng để khi một đối tƣợng thay đổi trạng thái thì tất cả các phục thuộc của nó đƣợc nhận biết và thay đổi theo

Tình huống áp dụng:

 Khi trạng thái của một hoặc nhiều đối tƣợng thay đổi gây ra hành vi cho các đối tƣợng khác

 Cần giám sát các thay đổi để thông báo cho đối tƣợng khác biết

Hình 2.9: Ví dụ mẫu thiết kế Observer

Trong đó:

Subject: Hiểu về các Observer của nó Một số lƣợng bất kỳ Observer có thể theo dấu

một chủ thể nào đó Cung cấp một giao diện cho việc gắn và tách các đối tƣợng server

Ob-ConcreteSubject: Lưu trữ trạng thái của ConcreteObserver cần quan tâm Gửi tín hiệu

đến các observer của nó khi trạng thái của nó đã thay đổi

Observer: Định nghĩa một giao diện cập nhật cho các đối tượng mà sẽ nhận tín hiệu

của sự thay đổi tại chủ thể

ConcreteObserver: Duy trì một tham chiếu tới một đối tượng ConcreteSubject Lưu

trữ các trạng thái cố định Cài đặt giao diện cập nhật của Observer đẻ giữ các trạng thái cố định của nó