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

-i-

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


- ii -

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.


- iii -

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............................................................................................................18
2.1.3 Abstract Factory.................................................................................................18
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

- iv -

2.2.6 Composite..........................................................................................................28
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.............................................................................................................41
2.3.6 Memento............................................................................................................42
2.3.7 Observer.............................................................................................................43
2.3.8 Sate.....................................................................................................................44
2.3.9 Strategy..............................................................................................................44
2.3.10 Template Method.............................................................................................45
2.3.11 Visitor..............................................................................................................46
2.4 Mẫu tương tranh...........................................................................................48
2.4.1. Critical Section.................................................................................................48
2.4.2 Consistent Lock Order.......................................................................................50
2.4.3 Guarded Suspension..........................................................................................52
2.4.4 Read-Write Lock................................................................................................54
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.......................58
3.2 Xây dựng chương trình thử nghiệm.............................................................62
3.2.1 Sơ đồ UML........................................................................................................62
3.2.2 Lập trình mođun demo.......................................................................................63
............................................................................................................................65
3.2.3 Đánh giá kết quả thu được.................................................................................65

KẾT LUẬN........................................................................................................... 66
HƯỚNG PHÁT TRIỂN......................................................................................... 67
TÀI LIỆU THAM KHẢO....................................................................................... 68


-v-

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

UML

Unified Modeling Language

CSDL

Cơ sở dữ liệu

DBMS

Database Management System (Hệ quản trị CSDL)

V

Validation (Thẩm tra)

R

Read (Đọc)

C

Computation (Tính toán)

W

Write (Ghi)


- vi -


-1-

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


-2-

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.


-3-

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ử


-4-

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


-5-

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


-6-

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
pháp có định kỳ cho những vấn đề
xuất hiện trong thời gian sống của
một ứng dụng phần mềm trong một
ngữ cảnh đặc biệt.
Các mục tiêu chính là:
• 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
Mẫu là lôgíc.

Một khung là nhóm những thành phần mà
hợp tác với nhau để cung cấp một kiến
trúc dùng lại được cho những ứng dụng
với lĩnh vực đã cho.
Các mục tiêu chính là:
• 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
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.


-7-

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.
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.
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.
Mẫu cung cấp một cách để làm “tốt”
thiết kế và được sử dụng để giúp thiết
kế khung.

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ể.
Khung cung cấp chức năng trong lĩnh vực
cụ thể
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.

Mẫu thiết kế có thể được sử dụng trong
thiết kế và thi hành của một khung. Khung
tiêu biểu gồm vài mẫu thiết kế.

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)


-8-

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ị.
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ệm
hướng đối tượng chuẩn.


-9-

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

An_Inner_Class

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
Public
Protected
Friendly
Private

Các lớp trong

Các lớp trong các

Các lớp con trong

Các lớp con trong

cùng một gói
Có thể truy cập

Có thể truy cập
Có thể truy cập
Không thể truy cập

gói khác
Có thể truy cập
Không thể truy cập
Không thể truy cập
Không thể truy cập

cùng một gói
Có thể truy cập
Có thể truy cập
Có thể truy cập
Không thể truy cập

các gói khác
Có thể truy cập
Có 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ó.
Bảng ký hiệu truy cập
Symbol

+
#
-

Scope
Public
Protected
Private

FileLogger
+getInstance():FileLogger


- 10 -

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.
Creator
factoryMethod():ParentClass

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.
RemoteAddress
isValid():boolean
save():boolean

<<throws>>

java.rmi.RemoteException
<<throws>>

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ểu
tượ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ú


- 11 -

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à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.
Customer

Unique system
generated ID

customerID : Integer

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

Shark

Whale

- 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
<<interface>>
VisitorInterface
visit()
getOrderTotal():double

- 12 -

- 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.
<<interface>>
VisitorInterface

OrderVisitor

visit()
getOrderTotal():double

visit()
getOrderTotal():double

OrderVisitor

visit()
getOrderTotal():double

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

DBUtil
Order
execute()


- 13 -

- 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.
Tính nhiều
1
0..1
*
0..*
1..*

Ý nghĩa
Không nhiều hơn một
Không hoặc một
Nhiều
Không hoặc nhiều
Một hoặc 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
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.
LogAbstraction
bridge:LoggerBridge

LoggerBridge

logList()

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


- 14 -

LineItem

Order
Consists of
1

Part of

1..*

 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ể.
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.

Player

Team
Consists of

*

Part of

1..*

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.

:Controller


- 15 -

- 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:

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:
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
Controller tiếp nhận.



Đối tượng Controller tạo ra một đối tượng Account với các dữ
liệu được gửi bởi người sử dụng.



Đối tượng Account được tạo ra và sử dụng một đối tượng
DBManager lưu dữ liệu vào cơ sở dữ liệu.


- 16 -

: Controller

: Account

: DBManager

An object
1: Account()
Online user enters the
data in the account
registration form and
submits
Message to a
different object

2: Save()

3: createSQL()
Self method
call
4: DBManager()

5: executeSQL(strSQL:String)

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


- 17 -

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

Creator
Product

FactoryMethod()
AnOperation()

ConcreteProduct

ConcreteCreator

product = FactoryMethod()

return new ConcreteProduct

FactoryMethod()

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


- 18 -

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.
- Định nghĩa
Singleton là mẫu thiết kế nhằm đảm bảo chỉ có duy nhất một thể nghiệm và
cung cấp điểm truy cập của nó một cách thống nhất toàn cục.
- Sơ đồ UML
Singleton
instance : Singleton
Singleton()
Instance() : Singleton

Singleton (LoadBalancer)
- Định nghĩa một thao tác tạo thể nghiệm cho phép đối tượng khách truy
nhậ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ính
nó.
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


- 19 -

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