Tải bản đầy đủ
MÔ HÌNH HÓA THỐNG NHẤT UML

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

Tải bản đầy đủ

-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

<>

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