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

NGUYỄN QUANG HUY

NGHIÊN CỨU MẪU THIẾT KẾ KIẾN TRÚC

PHẦN MỀM TRONG JAVA

LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH

Thái Nguyên - 2010

NGUYỄN QUANG HUY

NGHIÊN CỨU MẪU THIẾT KẾ KIẾN TRÚC

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 16

2.1 Mẫu khởi tạo 16

2.1.1 Factory Method 16

2.1.2 Singleton 17

2.1.3 Abstract Factory 18

2.1.4 Prototype 20

2.1.5 Builder 20

2.2 Mẫu cấu trúc 22

2.2.1 Decorator 22

2.2.2 Adapter 23

2.2.3 Façade 24

2.2.4 Proxy 25

2.2.5 Bridge 26

2.2.6 Composite 28

2.2.7 Flyweight 30

2.3 Mẫu hành vi 31

2.3.1 Mẫu Chain of Responsibility 32

2.3.2 Command 35

2.3.3 Interperter 37

2.3.4 Iterator 38

2.3.5 Mediator 39

2.3.6 Memento 40

2.3.7 Observer 41

2.3.8 Sate 42

2.3.9 Strategy 43

2.3.10 Template Method 44

2.3.11 Visitor 45

2.4 Mẫu tương tranh 46

2.4.1 Critical Section 46

2.4.2 Consistent Lock Order 49

2.4.3 Guarded Suspension 51

2.4.4 Read-Write Lock 52

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

3.1 Cơ sở lý thuyết 55

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

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 56

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

3.2.1 Sơ đồ UML 60

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ên nghiệ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ều hà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ích thiế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ương phá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 sinh trong quá trình thiết kế phần mềm hướng đối tượng Các mẫu GoF có tầm quan trọ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ần mề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át triể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 giao diệ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”

Mục tiêu đề tài là nghiên cứu, nắm vững được phương pháp phân tích thiết

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ội dung đượ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ệc thiế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òn khó 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ện tạ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 đối tượ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ên ngay đượ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 ta dù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ân tí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ưởng dù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ập sư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 ra trong 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át triể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ĩnh vự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ột quá 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ử

phát triển lâu dài như nghành kiến trúc, xây dựng nhưng Công nghệ phần mềm là 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ác nghà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ảo workshop, 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ểu cấ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ể được dù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ới chấ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ủa nhữ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 of Reusable 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ệu cò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ần mề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 of Four (bộ tứ), và các mẫu nó thường được gọi là các mẫu Gang of Four Còn rất nhiề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ần mề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 trong UML 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ông nhận Kent Beck và Ward Cunningham là những người phát triển những mẫu đầu tiê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 đó trong thiết kế thường được “lặp lại” trong nhiều dự án Nói một cách khác, một 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ống khác nhau để giải quyết một vấn đề cụ thể Trong bất kỳ hệ thống phần mềm hướng đối tượng nào chúng ta cũng có thể bắt gặp các vấn đề lặp lại

+ 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ấp thay đổ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ằng cá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ần mề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 cho thiế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ành

khố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ển phầ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ụng nà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 nhanh gọn hơn, từ đó đưa ra cách giải quyết hợp lý

Mẫu thiết kế không chỉ được sử dụng để xác định bài toán và cách giải quyết

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ình thứ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ều lầ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ẫu thiế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ại nhữ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ủa bả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ái

mớ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ới mẫu thiết kế

Design Patterns Frameworks

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ần mề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ển

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ềm nà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ấu trú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 động bê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)

4 Biểu đồ cộng tác (Collaboration 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ễn cá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ị

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ệm hướ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ương thứ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ằng cá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ộc tí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

Public Có thể truy cập Có thể truy cập Có thể truy cập Có thể truy cập 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

Static

Đường gạch dưới một biến hoặc một phương thức của lớp chỉ ra nó là tĩnh Trong ví dụ, phương thức getInstance là phương thức tĩnh của lớp FileLogger Các đối tượng khách có thể gọi phương thức getInstance trong lớp FileLogger mà không cần tạo ra thể hiện của nó

An_Inner_Class

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ừu tượ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ủa lớ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ừu tượ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ương thứ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ương thứ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ức tớ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ệ

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ành phần nào của lược đồ UML bằng một đường nét đứt Ví dụ sau đây cho thấy ghi chú được gắn với thuộc tính của một lớp

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 đối tượ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

- 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ột lớ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ào lớ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

Fish

- 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ực hó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ều phầ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ó

- 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ều khiể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ải ngược lại

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

 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ĩa tồ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

 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ọng hơ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ể

- 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 cho lớ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ụng cá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

Online user enters the

data in the account

registration form and

submits

Message to a

different object

Self method call

Chương II CÁC MẪU THIẾT KẾ KIẾN TRÚC PHẦN MỀM TRONG JAVA 2.1 Mẫu khởi tạo

2.1.1 Factory Method

- Vấn đề đặt ra

Các framework thường sử dụng các lớp trừu tượng để định nghĩa và duy trì mối quan hệ giữa các đối tượng Một framework thường đảm nhiệm việc tạo ra các đối tượng hoàn chỉnh Việc xây dựng một framework cho ứng dụng mà có thể đại diệ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ừu tượ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ụng Drawing, chúng ta định nghĩa một lớp DrawingApplication và một lớp DrawingDocument 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

- Sơ đồ UML

Product (Page)

- Đị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 ConcreteProduct

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ằm bên trong bộ quản lý tài nguyên đó Để truy cập vào bộ quản lý tài nguyên đối tượ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 trong mộ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

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ất nhiều kiểu giao diện look-and-feel và cả những hành vi giao diện người dùng khác nhau đượ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ức như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ương thức là Resize(), SetPosition() Tuy nhiên các đối tượng này không thể gộp chung và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ác nhau

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 được nhữ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ọi lớ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ột giao 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ượng ConcreteFactory (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

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

giao diện đồ sộ Việc khởi tạo ứng dụng thường gặp nhiều khó khăn Chúng ta không thể dồn tất cả công việc khởi tạo này cho một hàm khởi tạo Vì như thế sẽ rất khó kiểm soát hết, và hơn nữa không phải lúc nào các thành phần của ứng dụng cũng được khởi tạo một cách đồng bộ Có thành phần được tạo ra vào lúc dịch chương trình nhưng cũng có thành phần tuỳ theo từng yêu cầu của người dùng, tuỳ vào hoàn cảnh của ứng dụng, mà nó sẽ được tạo ra Do vậy người ta giao công việc này cho một đối tượng chịu trách nhiệm khởi tạo, và chia việc khởi tạo ứng dụng 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ãy tưở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ột cá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 độc lậ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 ra chiế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ệc khở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 đối tượng ở các hoàn cảnh khác nhau

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 giao diệ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

- 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ện cho việc lắp ráp các bộ phận trong kết quả cuối cùng

- Sơ đồ UML

Component (LibraryItem)

- Định nghĩa giao diện cho đối tượng mà có thể có nhiệm vụ thêm nó vào một cách động

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ó

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ện củ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ột lớ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 quan hoặc không được dự đoán trước, các lớp đó không nhất thiết phải có giao diện tươ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ệc phâ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ùng mộ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ột giao 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

Các thành phần tham gia:

- 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 cho thí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ự giao tiế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àng tổ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 trong một hệ thống con Façade định nghĩa một giao diện ở mức cao hơn, 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êu cầ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ình tạ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ó Trong trườ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, tinh xả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

tượng định nghĩa một giao diện cho trừu tượng đó, và các lớp con cụ thể thực hiện

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ày làm nó khó thay đổi, mở rộng, và sử dụng lại các abstraction, các thành phần bổ sung một cách độc lập Trong trường hợp này dùng một mẫu Bridge là thích hợp nhất

- Đị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ó

tác nguyên thuỷ và lớp trừu tượng định nghĩa một thao tác mức trên dựa những thao tác nguyên thuỷ này

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ác thà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ác lớ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ác thà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ác thà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ác thà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 truy nhậ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úc cây để biểu diễn hệ thống phân lớp: bộ phận – toàn bộ Composite cho phép các client 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ống nhất

- Biểu đồ UML

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ột cá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 con củ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ành phầ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ốt thiế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ình huố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ượng ConcreteFlyweight