Nghiên cứu mẫu thiết kế kiến trúc phần mềm trong java

Nó không chỉ dùng để viết các ứng dụng chạy đơn lẻ hay trong mạng mà còn để xây dựng các trình điều khiển thiết bị cho điện thoại di động, PDA, … Các phương pháp phân tích thiết kế hướng

LỜI CAM ĐOAN

Tôi xin cam đoan bản luận văn “Nghiên cứu mẫu thiết kế kiến trúc phần mềm trong Java” là công trình nghiên cứu của tôi dưới sự hướng dẫn khoa học của PGS.TS Đặng Văn Đức, tham khảo các nguồn tài liệu đã được chỉ rõ trong trích dẫn và danh mục tài liệu tham khảo Các nội dung công bố

và kết quả trình bày trong luận văn này là trung thực và chưa từng được ai công bố trong bất cứ công trình nào

Thái Nguyên, tháng 10 năm 2010

Nguyễn Quang Huy

Lời cảm ơn

Tôi xin gửi lời cảm ơn sâu sắc tới PGS.TS Đặng Văn Đức – Viện Công nghệ thông tin, người đã tận tình có những chỉ bảo cần thiết để giúp đỡ tôi trong suốt quá trình nghiên cứu và phát triển luận văn.

Xin chân thành cảm ơn quý Thầy cô trong khoa Sau đại học trường Đại học Thái Nguyên đã nhiệt tình giảng dạy, trang bị cho tôi những kiến thức quý báu trong suốt thời gian học tập tại trường.

Xin chân thành cảm ơn các bạn cùng lớp, đồng nghiệp và đơn vị nơi tôi công tác đã tạo điều kiện cho tôi hoàn thành luận văn này.

Xin gửi lời cảm ơn tới gia đình tôi đã động viên tôi trong suốt quá trình học và hoàn thành luận văn.

MỤC LỤC

LỜI CAM ĐOAN i

MỤC LỤC iii

DANH MỤC CÁC TỪ VIẾT TẮT v

MỞ ĐẦU 1

CHƯƠNG I TỔNG QUAN VỀ MẪU THIẾT KẾ VÀ NGÔN NGỮ 3

MÔ HÌNH HÓA THỐNG NHẤT UML 3

1.1 Tổng quan về mẫu thiết kế 3

1.1.1 Vấn đề trong thiết kế phần mềm hướng đối tượng 3

1.1.2 Lịch sử Mẫu thiết kế 3

1.1.3 Mẫu thiết kế là gì ? 5

1.1.4 Một số vấn đề về mẫu thiết kế 5

1.2 Ngôn ngữ mô hình hóa thống nhất UML 7

1.2.1 Khái quát về UML 7

1.2.2 Biểu đồ lớp (Class Diagrams) 8

1.2.3 Lược đồ trình tự (Sequence Diagrams) 14

Chương II CÁC MẪU THIẾT KẾ KIẾN TRÚC PHẦN MỀM TRONG JAVA 17

2.1 Mẫu khởi tạo 17

2.1.1 Factory Method 17

2.1.2 Singleton 18

2.1.3 Abstract Factory 19

2.1.4 Prototype 21

2.1.5 Builder 21

2.2 Mẫu cấu trúc 23

2.2.1 Decorator 23

2.2.2 Adapter 24

2.2.3 Façade 25

2.2.4 Proxy 26

2.2.5 Bridge 27

2.2.7 Flyweight 31

2.3 Mẫu hành vi 32

2.3.1 Mẫu Chain of Responsibility 33

2.3.2 Command 36

2.3.3 Interperter 38

2.3.4 Iterator 39

2.3.5 Mediator 40

2.3.6 Memento 41

2.3.7 Observer 42

2.3.8 Sate 43

2.3.9 Strategy 44

2.3.10 Template Method 45

2.3.11 Visitor 46

2.4 Mẫu tương tranh 47

2.4.1 Critical Section 47

2.4.2 Consistent Lock Order 50

2.4.3 Guarded Suspension 52

2.4.4 Read-Write Lock 53

Chương III PHÁT TRIỂN CHƯƠNG TRÌNH THỬ NGHIỆM 56

3.1 Cơ sở lý thuyết 56

3.1.1 Giao dịch phân tán 56

3.1.2 Các vấn đề về xung đột dữ liệu và một số giải thuật điều khiển 57

3.2 Xây dựng chương trình thử nghiệm 61

3.2.1 Sơ đồ UML 61

3.2.2 Lập trình mođun demo 62

3.2.3 Đánh giá kết quả thu được 64

KẾT LUẬN 65

HƯỚNG PHÁT TRIỂN 66

TÀI LIỆU THAM KHẢO 67

MỞ ĐẦU

Ngôn ngữ lập trình Java được Sun Microsystems giới thiệu vào tháng 6 năm

1995 Từ đó, nó đã trở thành một công cụ lập trình của các lập trình viên chuyênnghiệp Java được sử dụng rộng rãi để viết chương trình chạy trên Internet Nó làngôn ngữ lập trình hướng đối tượng độc lập thiết bị, không phụ thuộc vào hệ điềuhành Nó không chỉ dùng để viết các ứng dụng chạy đơn lẻ hay trong mạng mà còn

để xây dựng các trình điều khiển thiết bị cho điện thoại di động, PDA, …

Các phương pháp phân tích thiết kế hướng đối tượng đã phát triển rất mạnh

mẽ và góp phần đáng kể vào việc cải tiến chất lượng của phần mềm nhờ vào khảnăng xây dựng các lớp đối tượng có tính tái sử dụng cao, dễ bảo trì và mở rộng

Ngôn ngữ UML (Unified Modeling Language) được đề xuất để sử dụng như một

ngôn ngữ chuẩn để mô hình hóa các thành tố phần mềm trong quá trình phân tíchthiết kế hướng đối tượng

Tuy nhiên, các phương pháp hướng đối tượng tập trung chủ yếu vào các hoạtđộng tổng thể trong tiến trình phát triển phần mềm hướng đối tượng Những phươngpháp này thường không giải quyết các vấn đề chi tiết nảy sinh trong quá trình thiết

kế phần mềm Để bổ sung cho phương pháp hướng đối tượng, các mẫu thiết hướngđối tượng là một tiếp cận độc đáo, được đề xuất để giải quyết các vấn đề nảy sinhtrong quá trình thiết kế phần mềm hướng đối tượng Các mẫu GoF có tầm quantrọng và ảnh hưởng rất lớn đối với giới nghiên cứu cũng như giới công nghiệp phầnmềm Rất nhiều công trình đặc sắc khác về mẫu thiết kế hướng đối tượng được đềxuất để giải nhiều vấn đề đặc thù cho từng lĩnh vực ứng dụng phần mềm Trong đó,tôi quan tâm đến việc nghiên cứu các mẫu thiết kế để áp dụng trong quá trình pháttriển phần mềm hướng đối tượng, đặc biệt là giải quyết các vấn đề về cài đặt giaodiện người dùng và các vấn đề liên quan đến các ứng dụng trong Java Vì thế, tôi đã

thực hiện đề tài luận văn: “Nghiên cứu mẫu thiết kế kiến trúc phần mềm trong Java”.

kế hướng đối tượng bằng ngôn ngữ mô hình hóa thống nhất UML (Unified Modeling Language) Đồng thời sử dụng được một số mẫu thiết kế vào công đoạn

xây dựng kiến trúc phần mềm bằng ngôn ngữ Java

Bố cục của luận văn bao gồm phần mở đầu, phần kết luận và ba chương nộidung được tổ chức như sau:

Chương I Tổng quan về mẫu thiết kế và ngôn ngữ mô hình hóa thống nhất UML

Chương này trình bày tổng quan về mẫu thiết kế kiến trúc phần mềm hướng đối tượng, lịch sử phát triển, định nghĩa mẫu thiết kế và một số vấn đề về mẫu Khái quát về ngôn ngữ mô hình hóa thống nhất UML, các biểu đồ cấu trúc, biểu đồ hành

vi, biểu đồ quản lý mô hình, các ký pháp của UML…

Chương II Các mẫu thiết kế kiến trúc phần mềm trong Java

Trong chương này tập trung vào trình bày các mẫu thiết kế kiến trúc phần mềm trong Java bao gồm các mẫu khởi tạo, mẫu cấu trúc, mẫu hành vi, mẫu tương tranh Các mẫu được mô tả, định nghĩa đưa ra mô hình UML và sau đó là ví dụ áp dụng

Chương III Phát triển chương trình thử nghiệm

Trong chương này phát triển ứng dụng sử dụng mẫu thiết kế, chủ yếu tập trung minh họa việc sử dụng các mẫu tương tranh để giải quyết xung đột trong môi trường mạng, môi trường đa tiến trình Chương trình được phân tích và thiết kế bằng UML lập trình mô-đun demo bằng Java

CHƯƠNG I TỔNG QUAN VỀ MẪU THIẾT KẾ VÀ NGÔN NGỮ

MÔ HÌNH HÓA THỐNG NHẤT UML 1.1 Tổng quan về mẫu thiết kế

1.1.1 Vấn đề trong thiết kế phần mềm hướng đối tượng

Việc thiết kế một phần mềm hướng đối tượng là một công việc khó, và việcthiết kế một một phần mềm hướng đối tượng phục vụ cho mục đích dùng lại cònkhó hơn Chúng ta phải tìm ra những đối tượng phù hợp, đại diện cho một lớp cácđối tượng Sau đó thiết kế giao diện và cây kế thừa cho chúng, thiết lập mối quan hệgiữa chúng Thiết kế của chúng ta phải đảm bảo là giải quyết được các vấn đề hiệntại, có thể tiến hành mở rộng trong tương lai mà tránh phải thiết kế lại phần mềm

Và một tiêu trí quan trọng là phải nhỏ gọn Thiết kế một phần mềm hướng đốitượng phục vụ cho mục đích dùng lại là một công việc khó, phức tạp vì vậy chúng

ta không thể mong chờ thiết kế của mình sẽ là đúng, và đảm bảo các tiêu trí trênngay được Thực tế là nó cần phải được thử nghiệm sau vài lần và sau đó nó sẽđược sửa chữa lại Đứng trước một vấn đề, một người phân tích thiết kế tốt có thểđưa ra nhiều phương án giải quyết, anh ta phải duyệt qua tất cả các phương án vàrồi chọn ra cho mình một phương án tốt nhất Phương án tốt nhất này sẽ được anh tadùng đi dùng lại nhiều lần, và dùng mỗi khi gặp vấn đề tương tự Mà trong phântích thiết kế phần mềm hướng đối tượng ta luôn gặp lại những vấn đề tương tự nhưnhau

1.1.2 Lịch sử Mẫu thiết kế

Ý tưởng dùng mẫu xuất phát từ ngành kiến trúc, Alexander, Ishikawa,Silverstein, Jacobson, Fiksdahl-King và Angel (1977) lần đầu tiên đưa ra ý tưởngdùng các mẫu chuẩn trong thiết kế xây dựng và truyền thông Họ đã xác định và lậpsưu liệu các mẫu có liên quan để có thể dùng để giải quyết các vấn đề thường xảy ratrong thiết kế các cao ốc Mỗi mẫu này là một cách thiết kế, chúng đã được pháttriển hàng trăm năm như là các giải pháp cho các vấn đề mà người ta làm trong lĩnhvực xây dựng thường gặp Các giải pháp tốt nhất có được ngày hôm nay là qua mộtquá trình sàng lọc tự nhiên Mặc dù nghành công nghệ phần mềm không có lịch sử

một nghành công nghiệp tiên tiến, tiếp thu tất cả những gì tốt đẹp nhất từ cácnghành khác Mẫu được xem là giải pháp tốt để giải quyết vấn đề xây dựng hệthống phần mềm.

Suốt những năm đầu 1990, thiết kế mẫu được thảo luận ở các hội thảoworkshop, sau đó người ta nỗ lực để đưa ra danh sách các mẫu và lập sưu liệu vềchúng Những người tham gia bị dồn vào việc cần thiết phải cung cấp một số kiểucấu trúc ở một mức quan niệm cao hơn đối tượng và lớp để cấu trúc này có thể đượcdùng để tổ chức các lớp Đây là kết quả của sự nhận thức được rằng việc dùng các

kỹ thuật hướng đối tượng độc lập sẽ không mang lại những cải tiến đáng kể đối vớichất lượng cũng như hiệu quả của công việc phát triển phần mềm Mẫu được xem làcách tổ chức việc phát triển hướng đối tượng, cách đóng gói các kinh nghiệm củanhững ngưòi đi trước và rất hiệu quả trong thực hành

Năm 1994 tại hội nghị PloP (Pattern Language of Programming Design) đãđược tổ chức Cũng trong năm này quyển sách Design Patterns: Elements ofReusable Object Oriented Software (Gamma, Johnson, Helm và Vhissdes, 1995) đãđược xuất bản đúng vào thời điểm diễn ra hội nghị OOPSLA’94 Đây là một tài liệucòn phôi thai trong việc làm nỗi bật ảnh hưởng của mẫu đối với việc phát triển phầnmềm, sự đóng góp của nó là xây dựng các mẫu thành các danh mục (catalogue) vớiđịnh dạng chuẩn được dùng làm tài liệu cho mỗi mẫu và nổi tiếng với tên Gang ofFour (bộ tứ), và các mẫu nó thường được gọi là các mẫu Gang of Four Còn rấtnhiều các cuốn sách khác xuất hiện trong hai năm sau, và các định dạng chuẩn khácđược đưa ra

Năm 2000 Evitts có tổng kết về cách các mẫu xâm nhập vào thế giới phầnmềm (sách của ông lúc bấy giờ chỉ nói về những mẫu có thể được sử dụng trongUML chứ chưa đưa ra khái niệm những mẫu thiết kế một cách tổng quát) Ông côngnhận Kent Beck và Ward Cunningham là những người phát triển những mẫu đầutiên với SmallTalk trong công việc của họ được báo cáo tại hội nghị OOPSLA’87

Có 5 mẫu mà Kent Beck và Ward Cunningham đã tìm ra trong việc kết hợp các

người dùng của một hệ thống mà họ đang thiết kế Năm mẫu này đều được áp dụng

để thiết kế giao diện người dùng trong môi trường Windows

1.1.3 Mẫu thiết kế là gì ?

Mẫu thiết kế mô tả một giải pháp chung đối với một vấn đề nào đó trongthiết kế thường được “lặp lại” trong nhiều dự án Nói một cách khác, một Pattern cóthể được xem như một “khuôn mẫu” có sẵn áp dụng được cho nhiều tình huốngkhác nhau để giải quyết một vấn đề cụ thể Trong bất kỳ hệ thống phần mềm hướngđối tượng nào chúng ta cũng có thể bắt gặp các vấn đề lặp lại

+ Là những thiết kế đã được sử dụng và được đánh giá tốt

+ Giúp giải quyết những vấn đề thiết kế thường gặp

+ Chú trọng đến việc giúp cho bản thiết kế có tính uyển chuyển, dễ nâng cấpthay đổi

Christopher Alexander nói rằng: “Mỗi một mẫu mô tả một vấn đề xảy ra lặp

đi lặp lại trong môi trường và mô tả cái cốt lõi của giải pháp để cho vấn đề đó Bằngcách nào đó bạn đã dùng nó cả triệu lần mà không làm giống nhau hai lần”

1.1.4 Một số vấn đề về mẫu thiết kế

Mẫu thiết kế là khái niệm rộng và bao quát trong công đoạn thiết kế phầnmềm Giống như các yêu cầu của thiết kế và phân tích hướng đối tượng (nhằm đạtđược khả năng tái sử dụng), việc sử dụng các mẫu cũng cần đạt được khả năng tái

sử dụng các giải pháp chuẩn đối với các vấn đề thường xuyên xảy ra Mẫu thiết kếgiúp đỡ thúc đẩy sử dụng lại trong pha thiết kế vì chúng cung cấp từ vựng chung chothiết kế, chúng cung cấp những phương tiện để hiểu thiết kế, và chúng được tạo thànhkhối hợp nhất từ đó xây dựng những ứng dụng phức tạp hơn

Mẫu thiết kế không đơn thuần là một bước nào đó trong giai đoạn phát triểnphần mềm mà nó đóng vai trò là sáng kiến để giải quyết một bài toán thông dụngnào đó Các giai đoạn phần mềm vẫn hoàn chỉnh mà không có mẫu thiết kế, nhưng

sự góp mặt của mẫu thiết kế sẽ giúp cho việc xác định bài toán cần giải quyết nhanhgọn hơn, từ đó đưa ra cách giải quyết hợp lý

mà mẫu thiết kế còn được sử dụng nhằm cô lập các thay đổi trong mã nguồn, từ đólàm cho hệ thống có khả năng tái sử dụng cao Điều này là tất yếu vì mẫu tuân thủrất nghiêm ngặt các nguyên lý thiết kế hướng đối tượng

Cũng giống như mẫu trong phần mềm nói chung, mẫu thiết kế là sự hìnhthức hóa của các cách tiếp cận một vấn đề thường gặp trong một ngữ cảnh cụ thể.Mỗi mẫu thiết kế là một giải pháp cho một vấn đề thiết kế cụ thể trong một ngữcảnh xác định Giải pháp được đưa ra đã được kiểm nghiệm, được sử dụng nhiềulần đem lại kết quả tốt và do đó được trìu tượng hóa thành một mẫu mẫu thiết kếchính là kinh nghiệm thiết kế được đúc kết lại thành mẫu chuẩn mực Sử dụng mẫuthiết kế người thiết kế không phải thiết kế hệ thống từ đầu, không phải giải quyết lạinhững bài toán đã được giải quyết mà sử dụng các kinh nghiệm, tri thức và kết quả

đã có từ trước Điều này làm cho chất lượng thiết kế tốt hơn, tăng tính sử dụng củabản thiết kế và tạo điều kiện cho người thiết kế tập trung vào sáng tạo những cáimới

Khung (Frameworks) cũng có đặc tính tương tự như mẫu thiết kế và dễ gây

ra nhầm lẫn với mẫu thiết kế (Design Patterns) Bảng sau phân biệt khung vớimẫu thiết kế.

Những mẫu thiết kế là những giải

 Giảm bớt thời gian phát triển

 Giúp đỡ cải thiện chất lượng phầnmềm dưới dạng phần mềm dùng lạiđược, có thể duy trì được, dễ mởrộng

 Giảm bớt thời gian phát triểnMẫu là lôgíc Khung là về vật lý hơn, trong khi chúng

tồn tại trong các mẫu của phần mềm

Thông thường, mẫu thường được mô

tả độc lập với ngôn ngữ lập trình hoặc

được thực hiện chi tiết

Vì khung tồn tại trong mẫu của phần mềmnào đó, chúng được thực hiện cụ thể

Mẫu chung hơn và có thể được sử

dụng trong gần như bất kỳ loại ứng

dụng nào

Khung cung cấp chức năng trong lĩnh vực

cụ thể

Một mẫu thiết kế không tự ý tồn tại

trong mẫu của một thành phần phần

mềm Nó cần thực hiện rõ ràng mỗi

thời điểm nó được sử dụng

Khung tự nó thì không phải là ứng dụngđầy đủ Những ứng dụng đầy đủ trực tiếp

có thể được xây dựng bởi hoặc thừa kếnhững thành phần không đổi

1.2 Ngôn ngữ mô hình hóa thống nhất UML

1.2.1 Khái quát về UML

UML đưa ra mười hai biểu đồ nhằm trình bày về việc phân tích yêu cầu củaứng dụng và thiết kế các giải pháp Trong mười hai biểu đồ có thể phân chia thành

ba nhóm như sau:

- Biểu đồ cấu trúc (Structure Diagrams)

UML cung cấp bốn biểu đồ cấu trúc sau đây có thể dùng để biểu diễn cấutrúc tĩnh của ứng dụng

1 Biểu đồ lớp (Class diagrams)

2 Biểu đồ đối tượng (Object diagrams)

3 Biểu đồ thành phần (Component diagrams)

4 Biểu đồ triển khai (Deployment diagrams)

- Biểu đồ hành vi (Behavior Diagrams)

UML cung cấp năm biểu đồ hành vi sau đây dùng để biểu diễn hành vi độngbên ngoài của ứng dụng

1 Biểu đồ trường hợp sử dụng (Use Case diagrams)

2 Biểu đồ trình tự (Sequence diagrams)

3 Biểu đồ hoạt động (Activity diagrams)

5 Biểu đồ trạng thái (Statechart diagram)

- Biểu đồ quản lý mô hình (Model Management Diagrams)

UML cung cấp ba biểu đồ quản lý mô hình sau đây miêu tả làm thế nào để tổchức và quản lý các mô-đun ứng dụng khác nhau

1 Gói (Packages)

2 Hệ thống con (Subsystems)

3 Mô hình (Models)

1.2.2 Biểu đồ lớp (Class Diagrams)

Biểu đồ lớp là biểu đồ quan trọng nhất trong hầu hết các phương pháp hướngđối tượng Biểu đồ lớp cho ta cái nhìn tổng quan về hệ thống bằng cách biểu diễncác lớp và các mối quan hệ giữa chúng Nó thể hiện mặt tĩnh của hệ thống

- Lớp (Class)

Một lớp biểu diễn cho sự mô tả trừu tượng một tập các đối tượng có cùng tính chất, thao tác và ngữ nghĩa Lớp có thể được xem là một kiểu dữ liệu Trong UML, lớp được biểu diễn bằng một hình chữ nhật và gồm ba phần: tên lớp, các thuộc tính và các thao tác Trong đó, phần dành cho các thuộc tính

và các thao tác có thể không được hiển thị.

TÊN LỚP

- Các thuộc tính + Các thao tác

Ký hiệu lớp

- Lớp nội (Inner Class)

Lớp nội là lớp được định nghĩa bên trong lớp khác Các khái niệm về lớp nộiđược tồn tại trong các ngôn ngữ hướng đối tượng như Java, C++ (thông qua struct

và enum) và C# (với các lớp thực sự bên trong) nhưng không phải là một khái niệmhướng đối tượng chuẩn

UML không cung cấp cách biểu diễn lớp nội Các ký hiệu sau đây được sửdụng để thể hiện lớp nội, vị trí của lớp nội được đặt trong phần khai báo phươngthức của lớp mà nó được định nghĩa bên trong.

Biểu diễn lớp nội

- Các từ khóa định mức truy xuất (Access Specifiers)

Trong Java, để có thể thấy được các thành phần khác nhau của đối tượng vàkhả năng truy cập vào chúng bằng các đối tượng khác nhau được điều khiển bằngcách sử dụng từ khóa định mức truy xuất Quyền truy cập các phương thức và thuộctính có thể được xác định bằng cách sử dụng ký hiệu trong bảng

Bảng liệt kê quyền truy cập và phạm vi của chúng

Specifier Các lớp trong

cùng một gói

Các lớp trong các gói khác

Các lớp con trong cùng một gói

Các lớp con trong các gói khác

Protected Có thể truy cập Không thể truy cập Có thể truy cập Có thể truy cập Friendly Có thể truy cập Không thể truy cập Có thể truy cập Không thể truy cập Private Không thể truy cập Không thể truy cập Không thể truy cập Không thể truy cập

FileLogger +getInstance():FileLogger

Biểu diễn phương thức tĩnh

- Lớp trừu tượng / Phương thức trừu tượng (Abstract Class / Method)

Một phương thức mà không có khai báo bên trong gọi là phương thức trừutượng Một lớp với ít nhất một phương thức trừu tượng được coi là lớp trừu tượng.Các đối tượng khác không thể tạo ra thể hiện của lớp trừu tượng Một lớp con củalớp trừu tượng phải thực hiện cài đặt tất cả các phương thức trừu tượng của lớp trừutượng hay được khai báo chính nó là một lớp trừu tượng

Lớp hay phương thức thể hiện bằng tên được in nghiêng là lớp hay phươngthức trừu tượng Lớp Creator trong hình là một lớp trừu tượng với một phươngthức trừu tượng là factoryMethod

Biểu diễn lớp / phương thức trừu tượng

- Ngoại lệ (Exception)

Một mũi tên vẽ bằng nét đứt với một nhãn đặc trưng “throws” được sử dụng

để cho biết cụ thể phương pháp ném một ngoại lệ Các mũi tên chỉ từ phương thứctới lớp ngoại lệ Cả hai phương pháp isValid và save trong hình biểu thị (có thể)

ném ra một ngoại lệ kiểu java.rmi.RemoteException.

Biểu diễn phương thức ném ra một ngoại lệ

- Ghi chú (Note)

Ghi chú đi kèm theo lược đồ UML cung cấp thông tin bổ sung cho một biểutượng chẳng hạn như lời dẫn giải, các ràng buộc hoặc mã trình Nói chung, ghi chú

Creator factoryMethod():ParentClass

có thể gán với bất kỳ thành phần nào của lược đồ trong bất kỳ lược đồ UML nào.

Chi chú biểu diễn bằng hình chữ nhật gấp góc và được gắn vào bất kỳ thànhphần nào của lược đồ UML bằng một đường nét đứt Ví dụ sau đây cho thấy ghichú được gắn với thuộc tính của một lớp

Customer

customerID : Integer Unique system generated ID

Ghi chú cung cấp bổ sung thêm thông tin

- Khái quát hóa (Generalization)

Khái quát hóa được sử dụng để miêu tả khái niệm thừa kế trong hướng đốitượng khi có một lớp cơ sở với hành vi thông thường và mỗi lớp có nguồn gốc của

nó có chứa hành vi / chi tiết cụ thể

Trong hình, mũi tên rỗng đầu chỉ từ lớp con Shark/Whale đến lớp cha

Fish thể hiện quan hệ khái quát hóa

Fish

- Giao diện (Interface)

Giao diện là tập hợp các thao tác được sử dụng để chỉ ra các dịch vụ của mộtlớp hay một thành phần Mỗi giao diện thường mô tả một phần hành vi của lớp màthấy được từ bên ngoài Giao diện chỉ định nghĩa đặc tả cấu trúc bên trong màkhông có cài đặt chúng Giao diện thường không đứng một mình mà được gắn vàolớp hay thành phần thực hiện giao diện

Giao diện có thể được biểu diễn bằng hình chữ nhật giống như thiết lập lớp

với dòng “interface” trên tên của giao diện Hình sau thể hiện giao diện với tên là

VisitorInterface

<<interface>>

VisitorInterface visit()

getOrderTotal():double

- Hiện thực hóa (Realization)

Hiện thực hóa là quan hệ giữa hai sự mô tả của cùng một phần tử mô hình –giữa đặc tả và cài đặt của nó, nhưng tại những mức trừu tượng khác nhau Hiện thựchóa được sử dụng để biểu diễn cho sự cài đặt của một giao diện

Trong cả hai hình sau, lớp OrderVisitor thực hiện cài đặt giao diện đãđược khai báo bởi VisitorInterface (Java) interface

- Phụ thuộc (Dependency)

Quan hệ phụ thuộc biểu diễn mối quan hệ ngữ nghĩa giữa hai hoặc nhiềuphần tử mô hình, trong đó việc thay đổi của thành phần đích có thể đòi hỏi sự thayđổi của thành phần nguồn

Lớp Order trong hình thực hiện phương thức execute của lớp DBUtil để

thực hiện truy vấn SQL và do đó phụ thuộc vào nó.

Order

DBUtil execute()

OrderVisitor visit()

getOrderTotal():double

- Lớp kết hợp (Class Association)

Lớp kết hợp quy định các mối liên hệ cấu trúc giữa các lớp Khái niệm vềtính nhiều trình bày sau đây có quan hệ rất chặt chẽ với lớp kết hợp

 Tính nhiều (Multiplicity)

Khái niệm tính nhiều được sử dụng để chỉ ra số lượng thể hiện của một lớp

có quan hệ với thể hiện của lớp khác Bảng sau liệt kê các giá trị khác nhau có thể được sử dụng để cho biết tính nhiều.

 Điều khiển được (Navigability)

Khi lớp A chứa thông tin cần thiết thuộc phạm vi của lớp B, khi đó điềukhiển là từ lớp A tới lớp B Nói cách khác, lớp A biết lớp B nhưng không phảingược lại

Trong hình, một thể hiện của lớp LogAbstraction chứa đối tượng

LoggerBridge và có thể đạt được quyền điều khiển nó trực tiếp Do đó đối tượng

LoggerBridge chịu điều khiển từ thể hiện LogAbstraction

 Hợp thành (Composition)

Lớp A chứa lớp B Phát biểu này thể hiện quyền sở hữu mạnh của lớp A lớp toàn thể và lớp B - lớp bộ phận Nói cách khác, lớp bộ phận không có ý nghĩatồn tại nếu không có lớp toàn thể

-Trong hình:

- Một chi tiết đơn hàng là một phần của một đơn đặt hàng

- Một chi tiết đơn hàng không thể tồn tại mà không có một đơn đặt hàng

LogAbstraction bridge:LoggerBridge

LoggerBridge logList()

 Kết tập (Aggregation)

Quan hệ này thấp hơn quan hệ hợp thành Lớp toàn thể có vai trò quan trọnghơn lớp bộ phận nhưng không giống như trường hợp của quan hệ hợp thành, lớp bộphận có thể tồn tại mà không cần có lớp toàn thể

Trong hình:

- Cầu thủ là bộ phận của đội bóng

- Cầu thủ có thể tham gia vào nhiều đội khác và vì thế, khi một đội

bị giải thể, cầu thủ vẫn còn

1.2.3 Lược đồ trình tự (Sequence Diagrams)

Là một dạng biểu đồ tương tác (interaction), biểu diễn sự tương tác giữa các

đối tượng theo thứ tự thời gian Nó mô tả các đối tượng liên quan trong một tình

huống cụ thể và các bước tuần tự trong việc trao đổi các thông báo (message) giữa

các đối tượng đó để thực hiện một chức năng nào đó của hệ thống

- Đối tượng (Object)

Đối tượng trong biểu đồ được biểu diễn bằng hình chữ nhật, trong hình chữnhật là tên của nó Hình sau biểu diễn đối tượng Controller

- Thông điệp (Message)

Thông điệp được vẽ bằng mũi tên đóng đi từ chu kỳ sống của đối tượng nàyđến chu kỳ sống của đối tượng khác Trên mũi tên là tên thông điệp Mỗi thông điệp

là biểu diễn một đối tượng gọi hàm của đối tượng khác Khi định nghĩa thao tác cholớp sau này thì mỗi thông điệp sẽ trở thành thao tác Hình sau biểu diễn thông điệp

save:

- Thông điệp phản thân (Self Call)

Một đối tượng còn có thể gửi thông điệp đến chính nó Các thông điệp này gọi là phản thân, nó chỉ ra rằng đối tượng gọi chính thao tác của mình Hình sau biểu diễn thông điệp phản thân createSQL:

Ví dụ tạo ra một lược đồ mẫu với các chức năng sau đây, bằng cách sử dụngcác biểu tượng khác nhau của lược đồ trình tự đã được trình bày ở trên

 Một người sử dụng Internet nhập dữ liệu vào một mẫu đăng ký trực

tuyến và gửi đi

 Tất cả các thông tin của người dùng đầu tiên được đối tượng

: Controller : Account : DBManager

Online user enters the

data in the account

registration form and

đối tượng hoàn chỉnh Việc xây dựng một framework cho ứng dụng mà có thể đạidiện cho nhiều đối tượng tài liệu cho người dùng Có hai loại lớp trừu tượng chủchốt trong framework này là lớp ứng dụng và tài liệu Cả hai lớp đều là lớp trừutượng, và trình khách phải xây dựng các dẫn xuất, các lớp con để hiện thực hoá, tạo

ra đối tượng phù hợp với yêu cầu của ứng dụng Chẳng hạn để tạo ra một ứng dụngDrawing, chúng ta định nghĩa một lớp DrawingApplication và một lớpDrawingDocument Lớp ứng dụng chịu trách nhiệm quản lý tài liệu và chúng ta sẽtạo ra chúng khi có nhu cầu

- Định nghĩa Factory Method

Factory Method là một giao diện cho việc tạo ra một đối tượng, nhưng đểcho lớp dẫn xuất quyết định lớp nào sẽ được tạo.Factory method để cho một lớp trìhoãn sự thể nghiệm một lớp con

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

ConcreteProduct (SkillsPage, EducationPage, ExperiencePage)

- Cài đặt giao diện Product

Creator (Document)

- 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 ConcreteProduct mặc định

- Có thể gọi Factory Method để tạo ra một đối tượng Product

ConcreteCreator (Report, Resume)

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

2.1.2 Singleton

- Vấn đề đặt ra

Ta hãy xem xét về một đối tượng quản lý tài nguyên trong các ứng dụng.Mỗi ứng dụng có một bộ quản lý tài nguyên, nó cung cấp các điểm truy cập cho cácđối tượng khác trong ứng dụng Các đối tượng (ta gọi là đối tượng khách) có thểthực hiện lấy ra từ bộ quản lý tài nguyên những gì chúng cần và thay đổi giá trị nằmbên trong bộ quản lý tài nguyên đó Để truy cập vào bộ quản lý tài nguyên đốitượng khách cần phải có một thể nghiệm của bộ quản lý tài nguyên, như vậy trongmột ứng dụng sẽ có rất nhiều thể nghiệm của bộ quản lý tài nguyên được tạo ra

- Định nghĩa một thao tác tạo thể nghiệm cho phép đối tượng khách truynhập đến thể nghiệm đồng nhất của nó như một thao tác của lớp

- Chịu trách nhiệm cho việc tạo ra và duy trì thể nghiệm đồng nhất của chínhnó

2.1.3 Abstract Factory

- Vấn đề đặt ra

Chúng ta có thể để ý thấy trong các hệ điều hành giao diện đồ hoạ, một bộcông cụ muốn cung cấp một giao diện người dùng dựa trên chuẩn look-and-feel,chẳng hạn như chương trình trình diễn tài liệu Microsoft Office PowerPoint Có rấtnhiều kiểu giao diện look-and-feel và cả những hành vi giao diện người dùng khácnhau được thể hiện ở đây như thanh cuộn tài liệu (scroll bar), cửa sổ (window), nút

bấm (button), hộp soạn thảo (editbox) Nếu xem chúng là các đối tượng thì chúng

ta thấy chúng có một số đặc điểm và hành vi khá giống nhau về mặt hình thứcnhưng lại khác nhau về cách thực hiện Chẳng hạn đối tượng button và window,editbox có cùng các thuộc tính là chiều rộng, chiều cao, toạ độ… Có các phươngthức là Resize(), SetPosition() Tuy nhiên các đối tượng này không thể gộp chungvào một lớp được vì theo nguyên lý xây dựng lớp thì các đối tượng thuộc lớp phải

có các phương thức hoạt động giống nhau Trong khi ở đây tuy rằng các đối tượng

có cùng giao diện nhưng cách thực hiện các hành vi tương ứng lại hoàn toàn khácnhau

Vấn đề đặt ra là phải xây dựng một lớp tổng quát, có thể chứa hết đượcnhững điểm chung của các đối tượng này để từ đó có thể dễ dàng sử dụng lại, ta gọilớp này là WidgetFactory Các lớp của các đối tượng window, button, editbox kếthừa từ lớp này Trong thiết kế hướng đối tượng, xây dựng một mô hình các lớp nhưthế được tối ưu hoá như sau:

- Định nghĩa:

Mẫu Abstract Factory là một mẫu thiết kế mà cung cấp cho trình khách mộtgiao diện cho một họ hoặc một tập các đối tượng thuộc các lớp khác nhau nhưng cócùng chung giao diện với nhau mà không phải trực tiếp làm việc với từng lớp con

cụ thể

- Lược đồ UML

Abstract Factory (ContinentFactory)

- Khai báo một giao diện cho các thao tác để tạo ra các dẫn xuất trừu tượngConcreteFactory (AfricaFactory, AmericaFactory)

- Cài đặt các thao tác để tạo ra các đối tượng dẫn xuất chi tiết

AbstractProduct (Herbivore, Carnivore)

- Khai báo một giao diện cho một kiểu đối tượng dẫn xuất

Product (Wildebeest, Lion, Bison, Wolf)

- Định nghĩa một đối tượng dẫn xuất được tạo ra bởi một factory cụ thểtương ứng Cài đặt giao diện AbstractProduct

Client (AnimalWorld)

- Sử dụng giao diện được khai báo bởi các lớp AbstractFactory vàAbstractProduct

2.1.4 Prototype

- Định nghĩa

Prototype là mẫu thiết kế chỉ định ra một đối tượng đặc biệt để khởi tạo, nó

sử dụng một thể nghiệm sơ khai rồi sau đó sao chép ra các đối tượng khác từ mẫuđối tượng này

riêng rẽ, để có thể tiến hành khởi tạo riêng biệt ở các hoàn cảnh khác nhau Hãytưởng tượng việc tạo ra đối tượng của ta giống như như việc chúng ta tạo ra chiếc

xe đạp Đầu tiên ta tạo ra khung xe, sau đó tạo ra bánh xe, chúng ta tạo ra buđông

xe, xích, líp Việc tạo ra các bộ phận này không nhất thiết phải đựơc thực hiện mộtcách đồng thời hay theo một trật tự nào cả, và nó có thể được tạo ra một cách độclập bởi nhiều người Nhưng trong một mô hình sản xuất như vậy, bao giờ việc tạo rachiếc xe cũng được khép kín để tạo ra chiếc xe hoàn chỉnh, đó là nhà máy sản xuất

xe đạp Ta gọi đối tượng nhà máy sản xuất xe đạp này là Builder (người xây dựng)

- Định nghĩa

Builder là mẫu thiết kế hướng đối tượng được tạo ra để chia một công việckhởi tạo phức tạp của một đối tượng ra riêng rẽ từ đó có thể tiến hành khởi tạo đốitượng ở các hoàn cảnh khác nhau

- Sơ đồ UML

ConcreteBuilder

BuildPart() GetResult()

ConcreteBuilder (MotorCycleBuilder, CarBuilder, ScooterBuilder)

- Xây dựng và lắp ráp các phần của dẫn xuất bằng việc cài đặt bổ sung giaodiện Builder

- Định nghĩa và giữ liên kết đến đại diện mà nó tạo ra

- Cung cấp một giao diện cho việc gọi dẫn xuất ra

Director (Shop)

- Xây dựng một đối tượng sử dụng giao diện Builder

Product (Vehicle)

- Biểu diễn các đối tượng phức tạp ConcreteBuilder dựng nên các đại diệnbên trong của dẫn xuất và định nghĩa quá trình xử lý bằng các thành phần lắp rápcủa nó

- Gộp các lớp mà định nghĩa các bộ phận cấu thành, bao gồm các giao diệncho việc lắp ráp các bộ phận trong kết quả cuối cùng

ConcreteDecoratorB

Operation() AddedBehavior()

ConcreteComponent (Book, Video)

- Định nghĩa một đối tượng để có thể gắn nhiệm vụ thêm thành phần cho nó

Decorator (Decorator)

giao diện mà phù hợp với giao diện của thành phần.

Trong một trường hợp khác ta muốn sử dụng một lớp đã tồn tại và giao diệncủa nó không phù hợp với giao diện của một lớp mà ta yêu cầu Ta muốn tạo ra mộtlớp có khả năng được dùng lại, lớp đó cho phép kết hợp với các lớp không liên quanhoặc không được dự đoán trước, các lớp đó không nhất thiết phải có giao diệntương thích với nhau (Chỉ với đối tượng adapter) ta cần sử dụng một vài lớp con đãtồn tại, nhưng để làm cho các giao diện của chúng tương thích với nhau bằng việcphân lớp các giao diện đó là việc làm không thực tế, để làm được điều này ta dùngmột đối tượng adapter để biến đổi giao diện lớp cha của nó

- Định nghĩa

Adapter là mẫu thiết kế dùng để biến đổi giao diện của một lớp thành mộtgiao diện khác mà clients yêu cầu Adapter ngăn cản các lớp làm việc cùng nhau đókhông thể làm bằng cách nào khác bởi giao diện không tương thích

- Sơ đồ UML

- Target: định nghĩa một miền giao diện đặc biệt mà Client sử dụng.

- Client: cộng tác với các đối tượng tương thích với giao diện Target

- Adaptee: định nghĩa một giao diện đã tồn tại mà cần phải làm biến đổi chothích hợp

- Adapter: làm tương thích giao diện của Adaptee với giao diện của Target

2.2.3 Façade

- Vấn đề đặt ra

Khi cấu trúc hóa một hệ thống thành các hệ thống con sẽ giúp làm giảm độphức tạp của hệ thống Một mục tiêu thiết kế thông thường là tối thiểu hóa sự giaotiếp và phụ thuộc giữa các hệ thống con Một cách để đạt được mục tiêu này là đưa

ra đối tượng Façade, đối tượng này cung cấp một giao diện đơn giản để dễ dàngtổng quát hóa cho một hệ thống con hơn

Chúng ta sẽ dùng mẫu Façade để giải quyết vấn đề này

- Định nghĩa

Mẫu Façade cung cấp một giao diện thống nhất cho một tập các giao diện

này làm cho hệ thống con được sử dụng dễ dàng hơn.

- Sơ đồ UML

Façade (MortgageApplication)

- Có thể xem như các lớp hệ thống con mà chịu trách nhiệm đối với các yêucầu đến nó

- Trình khác uỷ nhiệm yêu cầu tới một đối tượng của hệ thống con

Subsystem classes (Bank, Credit, Loan)

- Cài đặt chức năng của hệ thống con

- Giữ handle làm việc bằng đối tượng Façade

- Không có một kiến thức gì về Façade và giữ tham chiếu đến nó

2.2.4 Proxy

- Vấn đề đặt ra

Lý do để điều khiển truy nhập tới một đối tượng là làm theo toàn bộ quá trìnhtạo ra và khởi đầu của nó cho tới tận khi thực sự chúng ta cần sử dụng nó Trongtrường hợp này ta nên dùng mẫu thiết kế proxy Proxy có thể được ứng dụng tại bất

cứ nơi nào mà ở đó cần có một sự tham chiếu tới một đối tượng linh hoạt hơn, tinhxảo hơn so với việc sử dụng một con trỏ đơn giản

- Định nghĩa

Cung cấp một đại diện cho một đối tượng khác để điều khiển việc truy nhập nó

- Sơ đồ UML

Proxy (MathProxy)

- Duy trì một tham chiếu để cho proxy truy cập vào một đối tượng thực.Proxy có thể tham khả đến một chủ thể nếu như giao diện của RealSubject vàSubject là như nhau

- Cung cấp một giao diện xác định Subject để một proxy có thể thay thế chođối tượng thực

- Điều khiển truy cập tới đối tượng thực và có thể chịu trách nhiệm tạo ra vàxoá nó đi

- Trong các nhiệm vụ khác phụ thuộc vào từng loại proxy

Subject (IMath)

- Định nghĩa một giao diện chung cho chủ thể thực và Proxy để proxy có thể

sử dụng ở mọi nơi mà một RealSubject mong đợi

nó theo các cách khác nhau Nhưng cách tiếp cận này không đủ mềm dẻo Sự kếthừa ràng buộc một thành phần bổ sung thêm là cố định cho abstraction, điều nàylàm nó khó thay đổi, mở rộng, và sử dụng lại các abstraction, các thành phần bổ

- Định nghĩa một giao diện trừu tượng

- Duy trì một tham chiếu tới đối tượng của các lớp kế thừa từ nó

ConcreteImplementor (CustomersDataObject)

- Cài đặt giao diện đã được cài đặt và định nghĩa một cài đặt cụ thể

2.2.6 Composite

- Vấn đề đặt ra

Các ứng dụng đồ họa như bộ soạn thảo hình vẽ và các hệ thống lưu giữ biểu

đồ cho phép người sử dụng xây dựng lên các lược đồ phức tạp khác xa với cácthành phần cơ bản, đơn giản Người sử dụng có thể nhóm một số các thành phần đểtạo thành các thành phần khác lớn hơn, và các thành phần lớn hơn này lại có thểđược nhóm lại để tạo thành các thành phần lớn hơn nữa Một cài đặt đơn giản có thểxác định các lớp cho các thành phần đồ họa cơ bản như Text và Line, cộng với cáclớp khác cho phép hoạt động như các khuôn chứa các thành phần cơ bản đó

Nhưng có một vấn đề với cách tiếp cận này, đó là mã sử dụng các lớp đóphải tác động lên các đối tượng nguyên thủy (cơ bản) và các đối tượng bao hàm cácthành phần nguyên thủy ấy là khác nhau ngay cả khi hầu hết thời gian người sửdụng tác động lên chúng là như nhau Có sự phân biệt các đối tượng này làm choứng dụng trở nên phức tạp hơn Composite Pattern đề cập đến việc sử dụng cácthành phần đệ quy để làm cho các Client không tạo ra sự phân biệt trên

Giải pháp của Composite Pattern là một lớp trừu tượng biểu diễn cả cácthành phần cơ bản và các lớp chứa chúng Lớp này cũng xác định các thao tác truynhập và quản lý các con của nó

- Định nghĩa

Composite là mẫu thiết kế dùng để tạo ra các đối tượng trong các cấu trúccây để biểu diễn hệ thống phân lớp: bộ phận – toàn bộ Composite cho phép cácclient tác động đến từng đối tượng và các thành phần của đối tượng một cách thốngnhất

- Biểu đồ UML

Component

Operation() Add(in Component) Remove(in Component) GetChild(in index : int)

children 1

Component (DrawingElement)

- Khai báo giao diện cho các đối tượng trong một khối kết tập

- Cài đặt các phương thức mặc định cho giao diện chung của các lớp mộtcách phù hợp

- Khai báo một giao diện cho việc truy cập và quản lý các thành phần concủa nó

- Định nghĩa một giao diện cho việc truy cập các đối tượng cha của các thànhphần theo một cấu trúc đệ quy và cài đặt nó một cách phù hợp nhất

2.2.7 Flyweight

- Vấn đề đặt ra

Một vài ứng dụng có thể được lợi từ việc sử dụng các đối tượng xuyên suốtthiết kế của chúng, nhưng một cài đặt không tốt sẽ cản trở điều đó Trong tìnhhuống này chúng ta sẽ dùng mẫu thiết kế Flyweight để giải quyết

ConcreteFlyweight (CharacterA, CharacterB, , CharacterZ)

- Cài đặt giao diện Flyweight và thêm phần lưu trữ cho các trạng thái ngoài.Một đối tượng Concrete Flyweight phải được chia sẻ Bất cứ một trạng thái nào nólưu trữ đều phải là ở bên ngoài, phải độc lập với ngữ cảnh của đối tượngConcreteFlyweight

UnsharedConcreteFlyweight (not used )

- Không phải tất cả các lớp con đều cẩn phải chia sẻ Giao diên Flyweight