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

ĐẠ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




2

ĐẠ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
Mã số : 60.48.10



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

5


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

6

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



7

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
8


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

9


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.
10

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.

11

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ệ

12

giữa chúng[ Buschmann et al. 1996]. Các mẫu Broker, Blackboard, và Filters-
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.
 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ế.

13

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
14

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
15

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.
16

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
17

ứ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.
1.3.5. Tính sử dụng lại ở mức thiết kế
Tiếp cận POAD khuyến khích dùng lại ở mức thiết kế bằng việc sử dụng lại các
mẫu thiết kế cấu trúc để xây dựng các thiết kế ứng dụng. So sánh với sử dùng lại mã,
ta thấy một số ƣu điểm sau :
18

 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
19

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ự
20

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,


Chế tác (artifact)/
sản phẩm (product)


một tiến trình sử
dụng một chế tác
một tiến trình tao
ra một chế tác
tiến trình
(process)
1 tiến trình sử dụng

1 tiến trình khác
21

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 (acquain-
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
22

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.
23

 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
24

ứ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.

25

 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

26

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.
1.5.1. Các ƣu điểm
 Thiết kế hƣớng đối tƣợng áp dụng tiến trình phát triển POAD, giảm bớt các hành
động thực hiện 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
27

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ƣ
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.
 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