You are on page 1of 47

CHƯƠNG 4:UML và mô hình hoá hướng đối tượng

Chương 4: UML và mô hình hoá hướng đối tượng.................... 1


CHƯƠNG 4 : UML (UNIFIED MODELING LANGUAGE)
VÀ MÔ HÌNH HOÁ HƯỚNG ĐỐI TƯỢNG (OBJECT-
ORIENTED MODELING)..........................................................3
I Mục tiêu..................................................................................... 3
II UML là gì? .............................................................................. 3
II.1 Ba dạng của UML.............................................................. 4
II.1.1 Ngôn ngữ (Language)........................................................ 4
II.1.2 Mô hình (Model)................................................................ 7
II.1.3 Hợp nhất (Unified)............................................................. 8
II.2 Mục tiêu và phạm vi.......................................................... 8
II.3 Lịch sử phát triển............................................................. 10
II.3.1 Giai đoạn manh mún ....................................................... 10
II.3.2 Giai đoạn của sự hợp nhất ............................................... 11
II.3.3 Giai đoạn của sự chuẩn hoá ............................................ 11
II.3.4 Giai đoạn duyệt lại........................................................... 11
II.3.5 Giai đoạn của sự công nghiệp hoá................................... 12
III UML và quy trình................................................................. 12
III.1 Áp dụng cách tiếp cận theo mô hình thác nước (waterfall
approach)................................................................................ 13
III.2 Áp dụng cách tiếp cận lặp (Iterative Approach)............. 14
III.2.1 Use cases.........................................................................17
III.2.2 Kiểu kiến trúc (Architecture).......................................... 17
III.2.3 Sự rủi ro (Risk)............................................................... 18
IV Mô hình hoá hướng đối tượng (Object-Oriented Modeling) 19
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 1
CHƯƠNG 4:UML và mô hình hoá hướng đối tượng
IV.1 Xác định yêu cầu hệ thống quản lý dự án (Project
Management System Requirements)...................................... 20
IV.1.1 Bộ chữ cái (Alphabets), từ (words), và câu (sentences). 22
IV.1.2 Alphabet......................................................................... 23
IV.1.3 Words............................................................................. 23
IV.1.4 Sentences........................................................................ 25
IV.2 Mô hình hướng đối tượng (Object-Oriented Paradigm) 27
IV.2.1 Concepts......................................................................... 27
IV.2.2 Các nguyên lý cơ bản (Principles)..................................35
V Phần mềm (Software)............................................................ 47
VI Tài liệu tham khảo ............................................................... 47

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 2


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng

CHƯƠNG 4 : UML (UNIFIED


MODELING LANGUAGE) VÀ MÔ
HÌNH HOÁ HƯỚNG ĐỐI TƯỢNG
(OBJECT-ORIENTED
MODELING)
I Mục tiêu
Mục tiêu của chương này nhằm giúp bạn:
• Tìm hiểu về ngôn ngữ mô hình hoá thống nhất
(UML).
• Tìm hiểu mô hình hướng đối tượng
• Cách kết hợp phân tích hướng đối tượng với UML.

II UML là gì?
UML là một ngôn ngữ trực quan với mục tiêu sử dụng cho
việc mô hình hoá và truyền đạt các ý tưởng về hệ thống thông
qua việc sử dụng các lược đồ (diagrams) và các văn bản. Ví dụ,
hình 4.1 truyền đạt thông tin sau:
Một manager lãnh đạo một nhóm thực hiện dự án.
Mỗi manager có một tên, số điện thoại, khởi đầu dự án, kết thúc
dự án.

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 3


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
Mỗi dự án có một tên (name), ngày bắt đầu (start date), và ngày
kết thúc (end date).
Mỗi nhóm làm việc (team) có một mô tả, đó là thông tin được
quan tâm liên quan đến nhóm.
Nếu bạn cảm thấy rằng hình II.1 không tạo nên ý nghĩa đầy đủ
thì cũng đừng qua lo lắng, bởi chúng ta sẽ khảo sát tỉ mỉ hơn
hình này và UML trong trình bày chi tiết hơn ở phần sau của
chương này.

(Hình II.1)

II.1 Ba dạng của UML


Như chúng ta đã biết, UML là chữ viết tắt của Unified
Modeling Language. Mỗi từ nói lên một khía cạnh quan trọng
của UML. Các phần trình bày sau đây sẽ đề cập đến các khía
cạnh này sẽ được đề cập sau đây với thứ tự đảo ngược.

II.1.1 Ngôn ngữ (Language)


Một ngôn ngữ cho phép chúng ta truyền đạt ý tưởng về
một chủ đề. Trong phát triển hệ thống, chủ đề bao gồm các yêu
cầu và hệ thống. Nếu không có một ngôn ngữ chung thì các
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 4
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
thành viên của nhóm làm việc thật khó khăn khi giao tiếp và
cộng tác với nhau để phát triển thành công một hệ thống.
Ngôn ngữ, trong ý nghĩa rộng, không phải bao giờ cũng
bao gồm các từ được viết. Ví dụ, chúng ta thường sử dụng
“ngôn ngữ đếm - counting language" để hướng dẫn trẻ con đếm
và làm các phép tính đơn giản. Đứa trẻ có thể dựa vào số lượng
các quả táo, các quả cam, những viên sỏi, hay một số loại khác
để trình bày số lượng. Đối với đứa trẻ, việc trình bày số 5 có thể
được tương ứng với 5 trái táo. Các phép toán cộng và trừ tương
ứng với việc thêm vào hoặc lấy ra các quả táo. Những người lớn
chúng ta thì khác, thích sử dụng ngôn ngữ số học hơn, mà tiêu
biểu là số lượng lớn sủ dụng sử dụng một chuỗi các chữ số
Arabic, và sử dụng các toán tử + và - để biểu trưng cho phép
cộng và phép trừ.
Hình II.2 trình bày sự tương phản giữa ngôn ngữ đếm
của trẻ con với ngôn ngữ số học trừu tượng hơn được người lớn
sử dụng.

(Hình II.2)
Bây giờ chúng ta xét hai ngôn ngữ này đối với việc truyền đạt số
lượng xác định các ngày cho một dự án. Làm theo và biểu thị số
lượng của số năm, ngôn ngữ đếm sử dụng năm đối tượng trong
khi ngôn ngữ số học sử dụng chuỗi “5”. Làm theo và biểu thị số
lượng phức tạp hơn, 365, ngôn ngữ đếm sử dụng 365 đối tượng
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 5
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
(điều này có thể không khả thi), trong khi ngôn ngữ số học sử
dụng chuỗi “365”. Để biểu thị số lượng bốn và phân nửa, ngôn
ngữ đếm sử dụng bốn đối tượng và một nửa của đối tượng (điều
này lại cũng có thể không khả thi) và ngôn ngữ số học sử dụng
chuỗi "4.5". Bởi vì số học cho phép chúng ta dễ dàng và thực tế
hơn trong việc biểu thị phạm vi số lượng rộng hơn ngôn ngữ
đếm, nó được cho là có ý nghĩa hơn ngôn ngữ đếm. Tương tự
như vậy, biểu thị số lượng với việc sử dụng số học ngắn gọn hơn
so với ngôn ngữ đếm. Bằng việc sử dụng các ngôn ngữ có ý
nghĩa hơn, chúng ta có thể truyền đạt thông tin phức tạp về chủ
đề phức tạp trong một kiểu ngắn gọn hơn.
Phát biểu hơi có phần hình thức, UML là một ngôn ngữ dùng để
cụ thể hoá (đặc tả - specifying), trực quan hoá (mô hình hoá trực
quan - visualizing), xây dựng (constructing), và tài liệu hoá các
quy trình nhân tố của hệ thống. Một quy trình nhân tố hệ thống
là cách tiếp cận các trọng tâm trên một hệ thống, bao gồm các
bước sản sinh và duy trì dựa trên các yêu cầu hệ thống phải đáp
ứng.
• Specifying : bao gồm việc tạo một mô hình mô tả một hệ
thống, nó nhằm giúp giải quyết các vấn đề phân tích,
thiết kế, cài đặt hệ thống một cách chính xác, rõ ràng,
đầy đủ và thông suốt trong quá trình phát triển phần
mềm.
• Visualizing : bao gồm việc sử dụng các lược đồ để thông
qua đó truyền đạt ý tưởng mô hình (mô hình là ý tưởng
và các lược đồ có vai trò trình bày ý tưởng), nó giúp cho
ý tưởng cài đặt và thực tế cài đặt được nhất quán.
• Constructing : bao gồm việc sử dụng sự mô tả trực quan
này để xây dựng hệ thống, giống như cách mà một bản
thiết kế nhà được sử dụng để xây dựng một building.

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 6


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
• Documenting : sử dụng các mô hình và lược đồ để tài
liệu hoá lại kiến trúc của hệ thống bao gồm các hiểu biết
về các yêu cầu và quy trình xuyên suốt toàn bộ hệ thống.
UML là ngôn ngữ mô hình hoá chuẩn tuy nhiên chính tự nó
không là một quy trình phát triển phần mềm (Nó độc lập với
ngôn ngữ lập trình và quy trình phát triển phần mềm). Một quy
trình áp dụng tập hợp các bước được mô tả bởi một phương
pháp luận (methodology) giải quyết một vấn đề và phát triển
một hệ thống thoả mãn các yêu cầu của người dùng nó. Một
phương pháp (method) chỉ nhằm vào một phần của quy trình
phát triển; Ví dụ như: thu thập các yêu cầu, phân tích, thiết kế,
và vân vân, trong khi một phương pháp luận nhằm vào toàn bộ
quy trình phát triển xuất phát từ việc thu thập các yêu cầu cho
đến khi hệ thống được tạo nên sẵn sàng đối với những người
dùng nó. Các cách khác nhau đối với việc thu thập và sử dụng
các yêu cầu, phân tích các yêu cầu, thiết kế một hệ thống, và vân
vân được hiểu như là các phương pháp kỹ thuật. Các sưu liệu
(Artifacts) là sản phẩm công việc được sản sinh và sử dụng bên
trong một quy trình, bao gồm tài liệu cho sự giao tiếp giữa các
nhóm làm việc trên một hệ thống và hệ thống vật lý của chính
nó. Mỗi loại lược đồ UML cũng được hiểu như là một phương
pháp kỹ thuật mô hình hoá.

II.1.2 Mô hình (Model)


Mô hình (model) có thể được hiểu như là một cách mô tả
một chủ đề, một đối tượng. Nó là sự đơn giản hoá thế giới thực.
Ví dụ, như đã đề cập ở phần trước, để mô hình và biểu diễn số
lượng năm, ngôn ngữ đếm sử dụng năm đối tượng, trong khi
ngôn ngữ số học sử dụng chuỗi "5". Một mô hình captures một
tập hợp các ý tưởng được hiểu như là sự trừu tượng hoá liên
quan các đối tượng của nó. Không có mô hình, thật là khó khăn
để các thành viên nhóm làm việc có cách hiểu chung về các yêu
cầu và cái nhìn đối với hệ thống và họ sẽ rất khó khăn khi suy
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 7
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
xét tác động của những thay đổi xảy ra trong khi triển khai hệ
thống.
Khi tạo một mô hình, nếu chúng ta cố gắng trình bày mọi
thứ của vấn đề tất cả đồng thời, chúng ta sẽ sẽ bị chôn vùi bởi số
lượng thông tin. Vì vậy, thật là quan trọng đối với việc tập trung
nắm bắt các thông tin có liên quan đã được yêu cầu để hiểu vấn
đề trong tầm kiểm soát, giải quyết vấn đề, và bổ sung giải pháp,
đồng thời loại trừ mọi thông tin không thích hợp, những thông
tin có thể làm cản trở sự xúc tiến của chúng ta. Với việc quản lý
cẩn thận những trừu tượng hoá nào tạo nên mô hình, chúng được
chi tiết như thế nào, và khi nào capture chúng trong suốt quá
trình phát triển, chúng ta có thể quản lý tốt hơn toàn bộ các rắc
rối phức tạp trong phát triển hệ thống.

II.1.3 Hợp nhất (Unified)


Thuật ngữ unified ám chỉ đến sự kiện tổ chức Object
Management Group (OMG), một tổ chức tiêu chuẩn hoá quốc
tế công nhận. Với việc hợp nhất các kí hiệu sử dụng, UML
cung cấp một nền tảng chuẩn trong việc phân tích thiết kế. Điều
này giúp các thành viên mới của nhóm nhanh chóng trở nên hữu
ích trong việc góp phần phát triển hệ thống.

II.2 Mục tiêu và phạm vi


Với việc tìm hiểu các mục tiêu của OMG và phạm vi đối với
UML, chúng ta có thể hiểu được động cơ thúc đẩy đằng sau
UML. Các mục tiêu của OMG đối với UML:
• Sẵn sàng để dùng (Ready to use)
• Có ý nghĩa (Expressive)
• Đơn giản (Simple)
• Rõ ràng, chính xác (Precise)
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 8
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
• Có thể mở rộng (Extensible)
• Không phụ thuộc sự cài đặt (Implementation-
independent)
• Không phụ thuộc quy trình (Process-independent)
Bởi đang sẵn sàng để dùng, có đầy đủ ý nghĩa, đơn giản và
rõ ràng chính xác, UML có thể nagy lập tức đựoc sử dụng để
phát triển các dự án. Để làm cho các mô hình triển khai rõ ràng
chính xác, OMG đưa vào ngôn ngữ gọi là ngôn ngữ ràng buộc
đối tượng - Object Constraint Language (OCL), một ngôn ngữ
phụ cho việc gắn các điều kiện mà những phần tử của một mô
hình phải đáp ứng đối với mô hình để sẽ được xem xét đúng (Sẽ
đề cập đến ngôn ngữ này ở bài khác).
Một ngôn ngữ mở rộng cho phép chúng ta định nghĩa các
khái niệm mới, tương tự việc đưa vào các từ mới và việc mở
rộng từ vựng của một ngôn ngữ tự nhiên.
Một ngôn ngữ implementation-independent có thể được sử
dụng không phụ thuộc bất kỳ công nghệ cài đặt nào, ví dụ như
Java hay .NET.
Một ngôn ngữ process-independent có thể được sử dụng với
nhiều loại quy trình khác nhau.
Phạm vi khi tạo UML của OMG bao gồm việc kết hợp của
ba ngôn ngữ mô hình hoá trong các phương pháp phát triển hệ
thống nổi bật nhất – Phương pháp Booch ’93 của Grady Booch,
phương pháp kỹ thuật mô hình hoá đối tượng của James
Rumbaugh (OMT) và phương pháp công nghệ phần mềm hướng
đối tượng của Ivar Jacobson (Object-Oriented Software
Engineering (OOSE)) với những công nghệ thực hành tốt nhất
của kỹ nghệ công nghệ và hê thống thông tin. Riêng biệt nhau,
chúng chỉ là các phương pháp, nhưng gắn với nhau, chúng hình
thành một phương pháp luận khá đầy đủ.

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 9


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng

II.3 Lịch sử phát triển


Quá trình phát triển của UML bao gồm năm giai đoạn thời
điểm phân biệt. Với việc tìm hiểu các giai đoạn này, bạn có thể
hiểu tại sao UML nổi bật lên và ngày nay nó vẫn đang tiến triển
như thế nào.

II.3.1 Giai đoạn manh mún


Khoảng giữa những năm 1970 và 1990, các tổ chức bắt
đầu hiểu được giá trị của phần mềm đối với hoạt động của
doanh nghiệp tuy nhiên chỉ có một tập hợp manh mún các
phương pháp kỹ thuật cho việc sản sinh và duy trì phần mềm.
Nằm trong số đó các phương pháp và kỹ thuật nổi bật tập trung
vào việc sản sinh và duy trì phần mềm một cách hiệu quả hơn
(mỗi chúng có riêng của nó ngôn ngữ mô hình hoá), ba phương
pháp nổi bật lên là:
• Phương pháp Booch ‘93 của Grady Booch (xuất phát từ
Booch ‘91) nhấn mạnh việc thiết kế và xây dựng hệ
thống phần mềm.
• Phương pháp Object Modeling Technique (OMT) -2 của
James Rumbaugh (xuất phất từ OMT-1) nhấn mạnh việc
phân tích hệ thống phần mềm.
• Phương pháp Object-Oriented Software Engineering
(OOSE) của Ivar Jacobson nhấn mạnh việc phân tích các
yêu cầu và business engineering.
Giống như phương pháp hướng đối tượng bắt đầu tiến
triển xuất phát từ phương pháp cấu trúc, công nghệ phân mảnh
xung quanh ba phương pháp này và một số phương pháp khác.
Những người đang làm việc theo một phương pháp nào đó sẽ
khó mà hiểu được những sưu liệu được sản sinh với việc sử
dụng một phương pháp khác.

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 10


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
II.3.2 Giai đoạn của sự hợp nhất
Khoảng giữa những năm 1990 và 1997, the UML 1.0
được đưa ra. James Rumbaugh, và sau đó là Ivar Jacobson, phối
hợp với Grady Booch tại công ty phần mềm Rational thống nhất
các phương pháp của họ. Bởi những kết quả cố gắng hợp nhất
của họ, chúng được hiểu như là Bộ ba những người bạn (Three
Amigos). Khi mà các tổ chức bắt đầu thấy được các giá trị của
UML, nhóm nghiên cứu phân tích thiết kế hướng đối tượng của
OMG đã đưa ra một thỉnh cầu về việc thiết lập một chuẩn định
nghĩa ý nghĩa các khái niệm kỹ thuật hướng đối tượng cho các
công cụ hỗ trợ phân tích và thiết kế hướng đối tượng. Cùng với
một số các tổ chức khác, công ty phần mềm Rational đã hình
thành nên hiệp hội các đối tác UML (UML Partners
Consortium), và những người cùng hợp tác này đã đệ trình phiên
bản 1.0 của UML tới tổ chức OMG như là môt trong số những
đáp trả đối với đề xuất ban đầu của tổ chức này.

II.3.3 Giai đoạn của sự chuẩn hoá


Vào thời điểm nửa sau của năm 1997, phiên bản UML 1.1
được đưa ra. Tất cả các đáp trả đối với các đề xuất ban đầu được
kết hợp vào trong phiên bản 1.1 của UML. Tổ chức OMG đã
chấp nhận UML1.1.

II.3.4 Giai đoạn duyệt lại


Sau khi UML 1.1 được công nhận, một số phiên bản khác
của UML đã được đưa ra. Một số chương trình chuyên dụng
phục vụ cho UML cũng đã được ra đời, như IBM Rational Rose,
Argo UML, Visual Paradigm for UML, Umbrello (Linux).

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 11


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
II.3.5 Giai đoạn của sự công nghiệp hoá
Đồng thời với giai đoạn duyệt lại, OMG đề xuất chuẩn
UML với mục tiêu chuẩn hoá quốc tế như là một Publicly
Available Specification (PAS) qua tổ chức quốc tế về tiêu chuẩn
hoá (ISO).

III UML và quy trình


Mặc dù UML độc lập với quy trình, nhưng các tác giả của
nó muốn rằng một quy trình hướng use-case, hướng kiến trúc,
có tính lặp và tăng dần. Với việc hiểu mối liên quan như thế nào
của UML đối với quy trình và loại quy trình mà các tác giả
UML hướng đến, bạn có thể hiểu tốt hơn cách tiếp cận tốt nhất
trong việc học UML. Tuy nhiên, một loại quy trình bất kỳ -
tham chí không có các đặc trưng này – vẫn có thể sử dụng
UML.
Nói chung, mỗi quy trình chu trình sống trong phát triển
hệ thống bao gồm các loại hoạt động của chu trình sống sau:

• Các hoạt động thu thập yêu cầu nhằm nắm bắt được các
yêu cầu với mục tiêu xác định rõ hệ thống sẽ phải làm gì.
• Các hoạt động phân tích để hiểu rõ các yêu cầu.
• Các hoạt động thiết kế (Design) để xác định một hệ sẽ
phải làm như thế nào để thoả mãn các yêu cầu của nó.
• Các hoạt động cài đặt để xây dựng một hệ thống.
• Các hoạt động kiểm thử để xác nhận rằng hệ thống thoả
các yêu cầu của nó.
• Các hoạt động triển khai để tạo nên một hệ thống sẵn
dùng đối với những người dùng nó

Có nhiều kiểu tiếp cận đối với việc áp dụng các hoạt động
này để triển khai hệ thống. Theo truyền thống, kiểu tiếp cận theo

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 12


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
mô hình thác nước thường được áp dụng. Hiện nay, cách tiếp
cận lặp được dùng phổ biến hơn.

III.1 Áp dụng cách tiếp cận theo mô hình thác


nước (waterfall approach)
Khi áp dụng cách tiếp cận theo mô hình thác nước, các
hoạt động chu trình sống được thực thi trong sự tiếp nối đơn,
tuyến tính đối với tất cả các yêu cầu. Thường thì các kết quả
khám phá (trong khoảng thời gian các hoạt động kiểm thử khi
mà các mảng khác nhau của hệ thống được tích hợp) của các
vấn đề liên quan chất lượng vẫn còn ẩn dấu trong khoảng thời
gian của các hoạt động thiết kế và cài đặt. Bởi vì các vấn đề như
vậy được khám phá muộn trong quá trình triển khai có thể sẽ
quá muộn để giải quyết chúng hay chúng có thể có thể quá tốn
kém để giải quyết. Ví dụ, việc khám phá rằng hiệu suất của một
hệ quản trị cơ sở dữ liệu cụ thể sẽ không đủ cho các ứng dụng sử
dụng nó sau khi tất cả các ứng dụng đã được triển khai trình bày
một vấn đề lớn.
Xét một dự án bao gồm 10 yêu cầu, , có lẽ phát sinh 10
loại báo cáo khác nhau mỗi báo cáo xuất phát từ một yêu cầu
riêng biệt. Bên trong cách tiếp cận mô hình thác nước, tất cả các
yêu cầu được tiếp nhận và phân tích, và toàn bộ hệ thống được
thiết kế, cài đặt, kiểm thử, và triển khai theo một cách tuần tự.
Bên trong một cách tiếp cận như vậy, UML có thể dễ dàng được
sử dụng để truyền đạt các yêu cầu và sự mô tả của hệ thống. Tuy
nhiên, bởi vì các hoạt động được thực hiện trong một cách tiếp
nối tuyến tính đơn đối với tất cả các yêu cầu, các mô hình UML
cần phải hoàn tất rõ ràng tại mỗi bước. Mức độ hoàn tất đầy đủ
ở đây thường khó khăn để đánh giá hay đạt được, bởi vì trong
khi UML là rõ ràng hơn ngôn ngữ tự nhiên, nó lại ít rõ ràng hơn
các ngôn ngữ lập trình. Vì thế, hơn cả trọng tâm hướng về hệ
thống, các nhóm làm việc sử dụng UML với cách tiếp cận mô
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 13
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
hình thác nước thường phải nổ lực trong sự cố gắng để xác định
rõ liệu các mô hình UML của họ hoàn toàn đầy đủ hay chưa.

III.2 Áp dụng cách tiếp cận lặp (Iterative


Approach)
Khi áp dụng phương pháp lặp, các tập con bất kỳ của các
hoạt động chu trình sống được thực hiện ở các thời điểm khác
nhau để hiểu tốt hơn các yêu cầu và dần dần phát triển hệ thống
mạnh hơn. Qua mỗi chu kỳ hoạt động này hay một tập hợp các
hoạt động này được hiểu là một hoạt động mang tính lặp, và một
loạt các hoạt động lặp theo cách hành xử suy xét đúng từng
bước đến các kết quả sau cùng theo mục tiêu cuối cùng của hệ
thống. Điều này cho phép bạn hiểu tốt hơn các yêu cầu và từng
bước phát triển một hệ thống thích hợp hơn qua việc tinh chế
liên tục và gia tăng việc đạt được chi tiết hơn khi bạn thực hiện
càng nhiều sự lặp lại. Ví dụ, bạn có thể kiểm tra và khám phá
hiệu suất của một hệ quản trị cơ sở dữ liệu cụ thể và phát hiện ra
rằng nó sẽ không đủ đáp ứng cho các ứng dụng sẽ sử dụng nó
trước khi các ứng dụng đã được triển khai hoàn tất, và theo đó
tạo nên các sửa đổi thích hợp đối với các ứng dụng hay kiểm tra
và khám phá việc sử dụng hệ quản trị cơ sở dữ liệu khác trước
khi nó trở nên qua trễ hay quá tốn kém.
Xét một dự án gồm có việc phát sinh 10 loại báo cáo khác
nhau. Bên trong một cách tiếp cận lặp, một loạy các hoạt động
lặp có thể như sau:

1. Chúng ta nhận được năm yêu cầu có tên là R1, R2, R3,
R4, R5 và phân tích ba trong năm yêu cầu này (có thể là
R1, R3, và R5).
2. Chúng ta thu thập năm yêu cầu mới có tên từ R6, R7,
R8, R8, R10, phân tích hai yêu cầu mà ta đã không phân
tích trong hoạt động lặp trước R2 và R4, và thiết kế, cài
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 14
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
đặt, và kiểm tra hệ thống đáp ứng ba yêu cầu đã được
phân tích trong hoạt động lặp trước (R1, R3, và R5) và
hai yêu cầu đã được phân tích trong hoạt động lặp này
(R2 và R4), nhưng chúng ta không triển khai hệ thống
bởi vì chúng ta không đủ thời gian phân phối cho sự lặp
đối với hoạt động đó.
3. Chúng ta triển khai hệ thống thoả mãn năm yêu cầu đã
được kiểm thử trong hoạt động lặp trước đó (R1R5) và
tiếp tục làm việc dựa trên các yêu cầu khác(R6 R10).
4. Chúng ta tiếp tục làm việc trên hệ thống tuy nhiên phải
hướng sự thay đổi đến một yêu cầu đã được triển khai
(có thể là R3), các thay đổi đối với các yêu cầu khác hày
còn chưa được triển khai (có thể là R6 và R10), và các
thay đổi kỹ thuật khác đối với hệ thống.

Chuỗi tiếp nối của sự lặp đi lặp lại này có thể có vẽ hỗn
độn; tuy nhiên, cách tiếp cận lặp chỉ là một khái niệm và UML
chỉ là một ngôn ngữ; như vậy, một phương pháp luận được cần
đến khi sử dụng UML trên những dự án thực tế. Khi việc lặp đi
lặp lại được sử dụng với một phương pháp luận, chúng không
phải hỗn độn mà là được tổ chức và khá động bên trong ngữ
cảnh của phương pháp luận.
Một cách tiếp cận đối với sự triển khai hệ thống mang đến
những lợi ích sau:

• Chúng ta có thể quản lý sự phức tạp tốt hơn với việc xây
dựng một hệ thống theo hướng tăng trưởng dần dần thay
vì tất cả một lần.
• Chúng ta có thể quản lý tốt hơn việc thay đổi các yêu cầu
với việc hợp nhất các thay đổi xuyên suốt quy trình và
không cố gắng bắt buộc theo hướng tất cả các yêu cầu
chỉ một lần.
• Chúng ta có thể cung cấp các giải pháp theo từng phần
tới những người dùng xuyên suốt quy trình hơn là đợi
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 15
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
cho đến kết thúc quy trình, tại thời điểm mà họ nhận toàn
bộ hệ thống và có thể kết luận rằng đó không là những gì
họ mong chờ.
• Chúng ta có thể cố đạt cho được phản hồi từ những
người dùng liên quan đến những phần đã được triển khai
của hệ thống, theo đó chúng ta có thể hoàn chỉnh các
thay đổi và hướng sự tiến triển của chúng ta trong việc
cung cấp một hệ thống mạnh hơn phù hợp với các yêu
cầu của họ..

Một quy trình lặp là sự tăng trưởng bởi vì chúng ta không


đơn giản là làm lại cùng những yêu cầu trong các hoật động lặp
liên tục, mà là hướng đến càng ngày càng nhiều các yêu cầu
trong các hoạt động lặp liên tục. Tương tự như vậy, các hoạt
động có thể xảy ra sự hoạt động song song của các hoạt động lặp
đơn lẻ khi chúng tập trung trên các phần khác nhau của hệ thống
và không có sự xung đột. Vì thế, một tiếp cận lặp bao gồm một
chuỗi các hoạt động lặp ở nơi mà hệ thống phát triển tăng
trưởng. Thậm chí dù một cách tiếp cận như vậy thường được
hiểu như là lặp và tăng trưởng, trên thực tế nó là lặp, tăng trưởng
và song song. Bởi vì cách tiếp cận như vậy phát triển hệ thống
dần dần thông qua việc tinh chế liên tục và sự tăng trưởng dần
dần các chi tiết, chúng ta có thể xác định mức độ đầy đủ thích
hợp của các mô hình UML của chúng ta hơn là với việc sử dụng
các tiếp cận theo mô hình thác nước. Ví dụ, nếu chúng ta có một
câu hỏi hay mối quan tâm cần hướng tới, và nếu chúng ta không
sẵn sàng sử dụng các mô hình UML của chúng ta để hướng đến
mối quan tâm đó, có lẽ chúng ta cần phải tốn nhiều công phu để
chi tiết hoá chúng hơn nữa; mặc khác, chúng ta có thể tiến hành
mà không tiêu phí thời gian và sự cố gắng chi tiết hoá hơn nữa
các mô hình UML của chúng ta.
Với cách tiếp cận động như vậy trong đó các hoạt động
bên trong hoạt động lặp xảy ra song song và hệ thống được xây
dựng tăng trưởng, chúng ta làm như thế nào để các hoạt động
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 16
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
được tổ chức và hướng tới việc thoả mãn các yêu cầu? Làm thể
nào để chúng ta duy trì trọng tâm trên hệ thống và ngăn ngừa
việc xây dựng một hệ thống khó bảo trì và tốn kém bởi vì nó
đơn giản là một tập hợp những phần được gắn kết với nhau
không với một số lược đồtổng quát? Những yêu cầu nào chúng
ta hướng tới trước tiên, và những bộ phận nào của hệ thống
chúng ta cài đặt trước tiên? Answering these questions is where
use cases, architecture, and risk management are critical within
an iterative approach.

III.2.1 Use cases


Một use case là một yêu cầu chức năng được mô tả theo
góc độ của người dùng hệ thống. Ví dụ, các yêu cầu chức năng
đối với hầu hết các hệ thống bao gồm các chức năng bảo mật
cho phép người dùng đang nhập và ra khỏi hệ thống, nhập dữ
liệu, xử lý dữ liệu, phát sinh các báo cáo, ... (Chúng ta sẽ tìm
hiểu Use case kỹ hơn ở phần sau).
Một use-case hướng quy trình là một khía cạnh mà chúng
ta có thể sử dụng use cases để hoạch định và thực thi các hoạt
động lặp. Điều này cho phép chúng ta tổ chức các hoạt động và
điều chỉnh tập trung vào trong tâm việc cài đặt các yêu cầu của
hệ thống. Đó là, chúng ta nắm bắt và phân tích các use case,
thiết kế và cài đặt một hệ thống nhằm đáp ứng chúng, kiểm thử
và triển khai hệ thống, và hoạch định các hoạt động lặp sau này.
Vì thế, các use case là chất gắn kết tất cả các hoạt động bên
trong một hoạt động lặp.

III.2.2 Kiểu kiến trúc (Architecture)


Architecture chứa các thành tố (elements) tạo nên một hệ
thống và cách mà chúng làm việc với nhau để cung cấp các chức
năng của hệ thống. Ví dụ, hầu hết các hệ thống bao gồm các
phần tử với mục đích điều khiển chức năng bảo mật, nhập và xử
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 17
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
lý dữ liệu, việc phát sinh dữ liệu, và vân vân. Các phần tử và các
mối quan hệ của chúng được hiểu như là cấu trúc của hệ thống.
Việc mô hình hoá cấu trúc của một hệ thống được hiểu như là
mô hình hoá cấu trúc (structural modeling). Tôi sẽ đề cập chi tiết
hơn vấn đề ở phần sau của chương này. Những phần tử và cách
chúng tương tác, cộng tác được hiểu như là các hành vi của hệ
thống. Mô hình hoá một hành vi của hệ thống được hiểu như là
mô hình hoá hành vi (behavioral modeling). Vấn đề này sẽ được
đề cập chi tiết hơn ở phần sau. Các loại thành tố khác nhau cấu
toạ nên một kiến trúc của hệ thống, Cả hai cấu trúc và hành vi,
được xác định bởi mô hình hướng đối tượng (object-oriented
paradigm). Các yếu tố cơ bản và khái niệm của mô hình hướng
đối tượng sẽ được đề cập ở phần sau.

III.2.3 Sự rủi ro (Risk)


Một rủi ro là bất kỳ sự trở ngại hay không hiểu biết có thể
làm cản trở sự thành công của bạn. Ví dụ, Khi phát triển một hệ
thống, các rủi ro bao gồm những điều như thiếu nguồn vốn,
những thành viên nhóm làm việc thiếu kinh nghiệm với các
trách nhiệm then chốt, và công nghệ thay đổi.
Để xác định những use cases nào nên điều khiển một hoạt
động lặp và những phần nào của kiến trúc tập trung trong hoạt
động lặp, chúng ta trước hết nhận dạng các rủi ro của hệ thống.
Sau đó chúng ta hướng các use case đương đầu với các rủi ro
cao nhất và các thành tố của kiến trúc này, khi xây dựng, giải
quyết các rủi ro cao nhất. Cách tiếp cận như vậy thường được
hiểu như là sự đương đầu với rủi ro (risk confronting).
Một lần nữa xét dự án bao gồm việc phát sinh 10 kiểu báo
cáo khác nhau. Phát biểu rằng ba báo cáo (có thể là R1, R3, và
R5) yêu cầu truy cập cơ sở dữ liệu quan trọng, và rằng bốn báo
cáo (có thể là R3, R6, R8, và R10) yêu cầu người dùng nhập đầy
đủ ý nghĩa. Có lẻ có hai rủi ro: rủi ro không có giao diện người

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 18


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
dùng trực quan ( intuitive ) (có tên là X1) và rủi ro của việc có
một hệ quản trị cơ sở dữ liệu không hiệu quả (có tên là X2).
Xuất phát từ các mô tả này, chúng ta hiểu rằng R1, R3, và R5 là
liên đới với rủi ro X1, và rằng R3, R6, R8, và R10 có liên quan
với X2. Nếu X1 là then chốt hơn đối với dự án của bạn, và có
khả năng xảy ra cao hơn hay có ảnh hưởng cao hơn với dự án,
chúng ta sẽ hướng R1, R3, và R5 hay nhiều yêu của họ như là
các ứng viên thích hợp đầu tiên, bởi vì chúng đe doạ rủi ro X1.
Nếu X2 là then chốt hơn đối với dự án của bạn, và có khả năng
xảy ra cao hơn hay có ảnh hưởng cao hơn với dự án, chúng ta sẽ
hướng R3, R6, R8, và R10 hay nhiều yêu cầu của họ như là ứng
viên thích hợp đầu tiên bởi vì chúng đe doạ rủi ro X2. Tuy
nhiên, trong mọi trường hợp, chúng ta phải nhằm vào R3 đầu
tiên, bởi vì nó hướng đến cả hai rủi ro.
UML cung cấp các kỹ thuật mô hình hoá cấu trúc và hành
vi có thể được sử dụng trong một quy trình dạng bậc thang
(step-wise) được hướng bởi các yêu cầu, tập trung vào việc phát
triển một hệ thống đúng đắn hợp lý về kiến trúc đáp ứng các yêu
cầu và cho phép bạn đương đầu các rủi ro xuyên suốt quá trình
phát triển hệ thống.

IV Mô hình hoá hướng đối tượng


(Object-Oriented Modeling)
Trong phần này chúng ta sẽ tìm hiểu mô hình hướng đối
tượng và các kỹ thuật môt hình hoá của UML. Trong khi UML
là một ngôn ngữ cho việc truyền đạt ý tưởng về một hệ thống và
và các yêu cầu của nó, chúng ta truyền đạt sự tri thức của chúng
ta về vấn đề bằng cách sử dụng một bảng chữ cái, các từ, câu,
đoạn văn, mục, và tài liệu. Trong phần này chúng ta sẽ đề cập
đến các vấn đề sau:
 Các khái niệm về câu, từ và bảng chữ cái trong UML.

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 19


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
 Các khái niệm và nguyên lý của của mô hình hướng đối
tượng.
 Một số kỹ thuật mô hình hoá UML.
 Kiến trúc View.
 Cách lập tài liệu các mô hình UML.

IV.1 Xác định yêu cầu hệ thống quản lý dự án


(Project Management System Requirements)
Một chuyên viên quản lý dự án (project manager ) sử dụng hệ
thống quản lý dự án để quản lý một dự án. Một chuyên viên
quản lý dự án lãnh đạo một nhóm thực hiện dự án làm việc kể từ
lúc bắt đầu đến ngày kết thúc của dự án. Khi một dự án được tạo
nên trong hệ thống quản lý dự án, chuyên viên quản lý dự án có
thể khởi đầu và kết thúc muộn dự án bởi để hoàn tất nó hay hay
vì một số lý do nào đó.
Một dự án sử dụng các yêu cầu như một đầu vào. Một hệ thống
được sinh ra (hay một phần của hệ thống) là kết quả đầu ra của
dự án. Xác định các yêu cầu và hệ thống là các kết quả công
việc: những gì được tạo ra, được sử dụng, được cập nhật, và
được phát sinh suốt dự án. Mỗi sản phẩm công việc có một mô
tả, phần trăm hoàn tất, và có thể được xác nhận thông qua (xác
nhận tính hợp lệ). Tuy nhiên, sự xác nhận thông qua phụ thuộc
loại sản phẩm công việc. Ví dụ, các yêu cầu được xác nhận
thông qua bởi người dùng trong workshops, và hệ thống sẽ được
kiểm thử dựa vào các yêu cầu.
hệ thống quản lý dự án phải có khả năng vận dụng để kiểm soát
kịch bản sau đây:
• A là một chuyên viên quản lý, quản lý ba dự án, tên của
ba dự án này là Eagle, Falcon, và Hawk.

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 20


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
• Tất cả các dự án dính líu đến các nhóm làm việc nặc
danh hay không có tên.
• Dự án Eagle sản sinh một hệ thống quản lý dự án, giống
như đã được mô tả.
• Dự án Falcon đang sử dụng nền tảng Java để sản sinh ra
loại hệ thống khác, nó nhằm mục tiêu hướng tới thị
trường rộng.
• Dự án Hawk đang sử dụng nền tảng Microsoft .NET để
sản sinh một hệ thống tương tự dự án Falcon, ngoại trừ
việc nó có bổ sung thêm các yêu cầu đặc trưng của đơn
vị tổ chức (organization-specific). Vì thế, các dự án
Falcon và Hawk chia sẻ một số yêu cầu chung, trong khi
đó dự án Hawk bổ sung các yêu cầu đặc trưng theo đơn
vị tổ chức.

Khi tạo một dự án, chuyên viên quản lý dự án sử dụng một


giao diện người dùng để nhập vào thông tin liên lạc của anh ta
(với số lượng tối thiểu, tên và số điện thoại), tên của dự án, ngày
bắt đầu và ngày kết thúc, sự mô tả các yêu cầu và hệ thống, và
sự mô tả của nhóm làm việc. Mỗi khi thông tin yêu cầu được
cung cấp, hệ thống xử lý thích đáng yêu cầu lưu trữ thông tin và
xác nhận sự hoàn tất. Thoạt tiên, dự án là inactive. Nó trở nên
active khi nguồn nhân lực được gán tới dự án, có thể trở nên
inactive lần nữa nếu nguồn nhân lực được lấy ra khỏi dự án, và
loại bỏ khỏi hệ thống một khi nó được hoàn tất.

Đối với mục tiêu kiểm định và bảo mật, dự án hệ thống


quản lý có hai phần, giao diện người dùng và cơ sở dữ liệu. Cơ
sở dữ liệu của dự án hệ thống quản lý thực thi trên một server
trung tâm. Giao diện người dùng của dự án hệ thống quản lý
thực thi trên một máy tính client (máy desktop), truy xuất đến

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 21


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
một máy in, và sử dụng cơ sở dữ liệu để lưu trữ thông tin liên
quan dự án.

Sự mô tả này cung cấp chi tiết đầy đủ; tuy nhiên, nó


không cung cấp tất cả chi tiết liên quan đến hệ thống quản lý dự
án. Với việc sử dụng UML, chúng ta sẽ có khả năng hiểu tốt hơn
sự mô tả này, và với việc sử dụng một quy trình, chúng ta có thể
có khả năng điều tra thông tin thiếu đối với phát triển hệ thống.

IV.1.1 Bộ chữ cái (Alphabets), từ (words), và câu


(sentences)

Bởi vì công nghệ xác định và bổ sung yêu cầu là phức tạp
và liên tục thay đổi, một ngôn ngữ không chỉ phải truyền truyền
ý tưởng dễ dàng một vấn đề, mà còn cho phép chúng ta quản lý
các thay đổi và sự phức tạp tốt hơn khi chúng ta truyền đạt ý
tưởng về một vấn đề. Một ngôn ngữ dựa trên cơ sở một mô
hình, một quan điểm nhìn về một vấn đề, những định nghĩa các
loại khái niệm mà chúng có thể được sử dụng trong ngôn ngữ và
các yếu tố cơ bản của việc tại sao chúng có thể được dùng cho
mục đích thực tế nào đó. Một cú pháp của ngôn ngữ xác định
các ký hiệu (ký pháp – notation) được sử dụng cho sự truyền đạt
và được xác định bởi bộ chữ cái của ngôn ngữ. Các ngữ nghĩa
của ngôn ngữ xác định ý nghĩa mà nó đã được truyền đạt và đã
được xác định bởi các từ các câu của ngôn ngữ. Cú pháp của
UML bao gồm các lược đồ (diagrams), và các ngữ nghĩa của nó
dựa trên mô hình hướng đối tượng.

Đối với sự truyền đạt bằng cách sử dụng một ngôn ngữ,
chúng ta phải biết bộ chữ cái của nó, cách mà bộ chữ cái của nó
được sử dụng để hình thành các từ, và cách mà các từ của nó
được sử dụng để hình thành nên câu. Chúng ta cũng phải biết
các khái niệm và nguyên lý cơ sở của mô hình bên dưới nó.
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 22
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
IV.1.2 Alphabet

Một alphabet định nghĩa những phần đơn giản nhất của
một ngôn ngữ: bộ chữ cái (letters), các ký tự (characters), các ký
hiệu (signs), và bộ dấu (marks). Ví dụ, bộ chữ cái của tiếng Anh
có 26 chữ cái. Alphabet của UML bao gồm các mẩu ký hiệu
(Các hình chữ nhật (rectangles), các đường thẳng (lines), và các
thành tố đồ hoạ khác) và chuỗi các ký tự ; đơn vị nhỏ nhất có ý
nghĩa trong một ngôn ngữ là các từ của nó (words)

IV.1.3 Words

Một từ là một nhóm các thành tố xuất phát từ alphabet


của ngôn ngữ định nghĩa một đơn vị có đầy đủ ý nghĩa. Ví dụ,
ngôn ngữ tiếng Anh có các từ khác nhau, bao gồm "project,"
"manager," "team," "lead," "execute," và vân vân. Trong UML,
các từ phụ thuộc theo hai loại hay kiểu chung:

Concepts

Concepts được trình bày như là các hình chữ nhật hay
các ký hiệu có hình dáng thuần nhất (solid-outline) được
gán nhãn với một cái tên.

Mối quan hệ (relationships) giữa các concepts

Mối quan hệ giữa các concepts được trình bày như là các
đường thẳng hướng việc kết kết các ký hiệu được gán
nhãn với một cái tên.

Ngoài các tên của chúng, concepts và relationships có thể có


chuỗi ký tự khác được gắn tới chúng nhằm xác định rõ thông tin
khác.
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 23
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
Hình 4.1 trình bày các concepts được nhận dạng từ các yêu cầu
hệ thống quản lý dự án với việc tập trung sự chú ý trên các danh
từ, bao gồm: Project, Manager, Team, Work Product,
Requirement, và System.

Work Product

Requirement System

Project

Manager Team

(Hình 4.1)

Tương tự như vậy, Hình 4.2 trình bày các mối quan hệ khác
nhau được nhận dạng từ các yêu cầu hệ thống quản lý dự án
bằng cách tập trung chú ý trên các động từ, bao gồm Manage,
Lead, Execute, Input, và Output.

Input Output

Lead

Manage Execute

(Hình 4.2)

Thông thường bạn sẽ không muốn trình bày tất cả các


relationships này một cách riêng biệt như trong hình 4.2, mà sẽ
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 24
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
kết hợp chúng với các concepts trình bày trong hình Hình 4.1.
Khi bạn kết hợp các relationships với các concepts, bạn thật sự
đang kết hợp các từ UML để hình thành các câu UML.

IV.1.4 Sentences

Một sentence là một nhóm các từ xuất phát từ các từ vựng của
ngôn ngữ định nghĩa một đơn vị văn phạm có ý nghĩa đang chứa
đựng một vấn đề và một sự biểu diễn về vấn đề. Ngữ pháp của
một ngôn ngữ xác định các quy tắc đối với việc kết hợp các từ
để hình thành các câu. Ví dụ, tiếng Anh có các quy tắc đối với
việc kết hợp các từ để hình thành câu, chẳng hạn câu "a manager
leads a team" tuân theo các quy tắc ngữ pháp, trái lại câu "leads
manager team" thì không. Các câu UML là các phân mảnh lược
đồ hay các lược đồ rất đơn giản.

Hình 4.3 trình bày một UML sentence với sự truyền đạt rằng
một nhóm làm việc (team) sẽ thực hiện một dự án như là đã
được biểu thị trong các yêu cầu hệ thống quản lý dự án. Team và
Project là các khái niệm (concepts), chúng ở dạng (danh từ -
nouns), và Execute là mối quan hệ (ở dạng động từ - verb) giữa
hai khái niệm.

Team

Execute

Projects

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 25


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
(Hình 4.3)

Hình 4.4 trình bày một UML sentence tinh tế hơn, trong đó một
chuyên viên quản lý quản lý một dự án và lãnh đạo một nhóm.

manager
manage

lead

teams projects

(Hình 4.4 Một manager quản lý một project và lãnh đạo một
team (Version 1))

Chú ý rằng hình 4.4 truyền đạt ý tưởng về mối quan hệ của
manager với một team và một project, tuy nhiên nó không
truyền đạt rằng nhóm làm việc (team) sẽ thực thi (execute) một
dự án (project), như đã trình bày ở hình 4.3. Giống như ngôn
ngữ English, chúng ta có thể truyền đạt mọi thứ chúng ta muốn
bằng cách sử dụng UML.

Vị trí nhìn thấy của các khái niệm và các mối quan hệ không
mang bất kỳ một ý nghĩa đặc biệt nào miễn là các ký hiệu không
lồng trong bên trong một ký hiệu khác. Một mối quan hệ thường
được đọc trái sang phải và từ trên xuống dưới; mặt khác, tên của
nó có thể có một mũi tên hình tam giác đặc biểu thị hướng đọc;
mũi tên này có ý nghĩa mô tả mối quan hệ giữa các khái niệm.
Ví dụ, Hình 4.5 truyền đạt thông tin giống như Hình 4.4.

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 26


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng

(Hình 4.5 Một manager quản lý một project và lãnh đạo một
team (Version 2))

Trong hình 4.5, nếu tôi không trình bày hình mũi tên chỉ hướng
kèm theo relationship, chúng ta vẫn hiểu rằng các manager quản
lý các projects và lãnh đạo các nhóm làm việc, bởi vì đó là
những gì mà nó có ý nghĩa đối với một manager. Đây là lý do tại
sao nó là quan trọng để hiểu các ngữ nghĩa của những gì mà
chúng ta mô tả trong UML hơn là đơn giản cú pháp. Việc nói
rằng các nhóm làm việc (teams) lãnh đạo (lead) các manager và
các dự án (projects) quản lý (manage) các manager sẽ là vô
nghĩa!

IV.2 Mô hình hướng đối tượng (Object-Oriented


Paradigm)

Trong phần này chúng ta sẽ tìm hiểu làm thế nào để sử


dụng các words và sentences UML đơn giản, chúng ta sẽ xem
xét mô hình hướng đối tượng mà các ngữ nghĩa của UML đã lấy
đó làm cơ sở. Chúng ta sẽ tìm hiểu làm thế nào các khái niệm
(concepts ) hướng đối tượng cho phép chúng ta nhìn bao quát
thế giới xung quanh chúng ta, và tại làm sao các nguyên lý
(principles) của mô hình cho phép chúng ta quản lý sự thay đổi
và độ phức tạp tốt hơn.

IV.2.1 Concepts

Mô hình hướng đối tượng dựa trên một số concepts


chính mà chúng cho phép chúng ta có cái nhìn thế giới xung
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 27
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
quanh chúng ta. Sau đây, chúng ta sẽ thảo luận về các concepts
chính này.

IV.2.1.1Classes, associations, objects, và links

Các hình 4.3  hình 4.5 trình bày các sentences tổng quát, bởi
vì chúng không nhận biết các projects, managers, teams, và vân
vân cụ thể. Các khái niệm tổng quát được trình bày trong
sentences được hiểu như là các classes, và các relationships tổng
quát được hiểu như là các quan hệ kết hợp (associations). Tương
tự như các ngôn ngữ tự nhiên, chúng ta cũng có thể truyền đạt ý
tưởng vào trong UML với việc sử dụng các sentences cụ thể bao
gồm cụ thể các projects, managers, teams, và vân vân, tại đó các
khái niệm cụ thể được hiểu như là các đối tượng (objects) và các
quan hệ cụ thể cụ thể được hiểu như là các liên kết (links).

Một class định nghĩa một loại đối tượng và các đặc trưng của
các đối tượng của nó, và một đối tượng (object) là một thể hiện
(instance) của một class. Ví dụ, Hình 4.4 và Hình 4.5 trình bày
ba classes, bao gồm Manager, Team, và Project. Chúng ta có
thể có nhiều managers, teams, và projects, và mỗi manager,
team, và project cụ thể là một thể hiện (instance) hay đối tượng
(object) của class của nó. Trong UML, một concept cụ thể được
trình bày với việc sử dụng cùng ký hiệu như concept tổng quát
của nó. Ký hiệu được gán nhãn với một tên cụ thể theo ngay sau
đó là dấu hai chấm và kế đó là tên của concept tổng quát của nó.
Toàn bộ chuỗi này, bao gồm tên được xác định, hai chấm, và tên
tổng quát, phải được gạch dưới. Cả hai tên là không bắt buộc, và
dấu hai chấm chỉ được trình bày khi concept tổng quát được xác
định. Hình 4.6 trình bày một class cụ thể cho mỗi ba đối tượng
đã trình bày trước đây trong các Hình 4.4 và Hình 4.5.

Một quan hệ kết hợp (association) định nghĩa một loại liên kết
(link) và các đặc trưng của các liên kết của nó, và một liên kết là
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 28
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
một thể hiện (instance) của một quan hệ kết hợp. Một quan hệ
(relationship) cụ thể được trình bày như là một đường dẫn và có
thể được gán nhãn với tên quan hệ (relationship) của nó được
gạch dưới. Hình 4.6 trình bày hai liên kết cụ thể của các quan hệ
kết hợp đã được trình bày trước đây trong các Hình 4.4 và Hình
4.5.

Hình 4.6. Si quản lý dự án Eagle và lãnh đạo một nhóm làm việc
nặc danh

Si:Manager
Manage

Lead

:Teams Eagle:Projects

(Hình 4.6)

Hình 4.6, sentence cụ thể dựa trên sentence tổng quát đã được
trình bày trong các Hình 4.4 và Hình 4.5, trình bày có nghĩa
rằng Si, là một manager, quản lý dự án Eagle và lãnh đạo một
nhóm làm việc nặc danh hay không tên. Quy ước ký hiệu và tên
giữa một class và các thể hiện của nó, hay một quan hệ kết hợp
(association) và các thể hiện của nó, được sử dụng khắp cả UML
và được hiểu như là một type-instance dichotomy.

Mô hình hướng đối tượng nhìn thế giới thực như là một tập hợp
các đối tượng đơn nhất, thường được xem như là một society
của các đối tượng. Mỗi đối tượng có một chu trình sống, có thể
làm một số điều nào đó, và có thể sự liên lạc với các đối tượng
khác. Những gì mà một đối tượng hiểu và có thể làm được hiểu
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 29
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
như là các đặc trưng (features). Ví dụ, một manager được gán
tên của anh ta hay cô ta, có thể bắt đầu hay kết thúc một project,
và có thể liên hệ với một nhóm làm việc để lãnh đạo nhóm làm
việc và để thực hiện thành công project. Các đặc trưng phụ
thuộc theo hai loại hay kiểu chung là : Các thuộc tính
(attributes) và các phương thức (operations).

IV.2.1.2Attributes

Một điều gì đó mà một đối tượng hiểu được gọi là một


thuộc tính (attribute), về bản chất nó đại diện cho dữ liệu. Một
class định nghĩa các thuộc tính và một đối tượng có những giá
trị đối với các thuộc tính này. Ngay cả khi hai đối tượng có cùng
các giá trị đối với các thuộc tính của chúng, các đối tượng là duy
nhất và có các nhận dạng của chính nó. Trong một lược đồ
UML, một class có thể được trình bày với một ngăn thứ hai liệt
kê các thuộc tính này như là những chuỗi văn bản. Tương tự,
một đối tượng có thể được trình bày ở một ngăn thứ hai liệt kê
những thuộc tính này như là các chuỗi văn bản, mỗi trong chúng
được theo sau bởi ký hiệu dấu “ = ” và giá trị của nó. Chỉ những
thuộc tính mà chúng ta muốn truyền đạt là được biểu diễn;
những thuộc tính khác không quan trọng với chúng ta đối với
việc truyền đạt dựa trên lược đồ không cần cần được biểu diễn.
Các quan hệ kết hợp (Associations) và các thuộc tính được hiểu
như là các đặc trưng cấu trúc, bởi vì chúng truyền đạt cấu trúc
của class tương tự như cách mô hình hoá cấu trúc đã được thảo
luận ở phần bên trên của chương này.

Hình 4.7 bổ sung chi tiết Hình 4.4 và biểu diễn rằng một
manager có một tên, một nhóm làm việc có một mô tả, và một
dự án có một tên, ngày bắt đầu và ngày kết thúc.

Figure 2-7. Classes with attributes

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 30


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng

(Hình 4.7. Các Classes với những thuộc tính (attributes))

Hình 4.8 bổ sung chi tiết Hình 4.6 biểu diễn các đối tượng khác
nhau với các giá trị cho các thuộc tính được biểu thi trong Hình
4.7.

(Hình 4.8. Các đối tượng với những giá trị thuộc tính)

IV.2.1.3Operations và methods

Đại loại một số điều mà một đối tượng có thể làm là gọi một
operation hay đặc tả yêu cầu và thực chất tương ứng với việc xử
lý. Cách mà một đối tượng xử lý đối với một operation đã định
được hiểu như là phương thức (method) hay sự thực thi
(implementation) của operation . Ví dụ, khi sử dụng một ngôn
ngữ lập trình, chúng ta khai báo các hàm (functions) hay các thủ
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 31
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
tục (procedures) và định nghĩa phần thân của chúng (các dòng
lệnh bên trong hàm, thủ tục) xác định những gì mà các hàm hay
thủ tục thực hiện khi chúng được triệu gọi và được thực thi; một
sự khai báo hàm là operation, và sự định nghĩa phần thân là
method. Một class định nghĩa các operations và methods áp
dụng cho các đối tượng (objects) của nó. Một class có thể được
biểu diễn ở ngăn thứ ba với việc liệt kê các operations này như
là chuỗi văn bản. Các phương thức của một class – mà lệnh cài
đặt trên thực tế của các operations – không được biểu diễn trên
một class, tuy nhiên có thể được mô tả bằng cách sử dụng các
kữ thuật mô hình hoá UML khác. Một đối tượng (object) trong
phần trình bày sẽ không có ngăn thứ ba, bởi vì tất cả các đối
tượng của một có cùng các operations và chia sẻ các phương
thức class của chúng. Tương tự, chỉ những operations mà chúng
ta muốn truyền đạt trên một lược đồ nhất định mới cần được
biểu diễn. Những operations khác mà chúng không có tầm quan
trọng với chúng ta đối với việc truyền đạt trên lược đồ nhất định
không cần được biểu diễn. Nếu các thuộc tính không được biểu
diễn, Một ngăn thuộc tính rỗng phải được biểu diễn sao cho
ngăn thứ ba được sử dụng để liệt kê các operations. Các
Operations và các methods được hiểu như là các đặc trưng hành
vi (behavioral features), bởi vì chúng truyền đạt các hành vi của
một class giống như đối với cách mô hình hoá hành vi đã được
sử dụng để truyền đạt hành vi đã thảo luận ở phần trước của
chương này.

Với việc biểu diễn hai operations, Initiate Project và


Terminate Project, Hình 4.9 trình bày rằng một manager có
thể bắt đầu hay kết thúc một project. Chú ý rằng ngăn thứ hai
của Manager là rỗng, bởi vì ở đây tôi chỉ đề cập đến các
operations của Manager.

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 32


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng

(Hình 4.9. Classes với các operations)

Hình 4.10 sự kết hợp Hình 4.7 và Hình 4.9 với việc sử dụng các
thuộc tính và các operations cho mỗi class trên cùng lược đồ.

(Hình 4.10. Classes với các attributes và operations)

IV.2.1.4Thông điệp (Messages) và tác nhân(stimuli)

Trong mô hình hướng đối tượng, sự truyền thông từ đối


tượng gởi tới đối tượng nhận được sử dụng để truyền đạt thông
tin hay việc xử lý thỉnh cầu. Ví dụ, chúng ta không bắt đầu một
project về phía một manager mà truyền đạt một thỉnh cầu tới
manager để bắt đầu project. Mỗi khi manager nhận thỉnh cầu,
một operation được triệu gọi để điều khiển thỉnh cầu, và
manager thực thi method tương ứng với operation.
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 33
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
Việc gởi một thỉnh cầu và sự việc nhận một thỉnh cầu là
các sự kiện (events hay occurrences).

Sự truyền thông (Communication) hay tương tác giữa


các đối tượng qua các links của chúng được gọi là một tác nhân
(stimulus), và sự truyền thông hay tương tác giữa các classes
qua các quan hệ kết hợp (associations) của chúng được gọi là
một thông điệp (message).

Một stimulus là một thể hiện (instance) của một thông


điệp tương tự cách một đối tượng là một thể hiện của một class
và một link là một thể hiện của một association. Sender được
hiểu là client, và receiver được hiểu như là supplier. Một
message hay stimulus được biểu diễn như là một mũi tên được
đính kèm tới một association hay link trỏ hướng từ sender tới
receiver và được gán nhãn với một con số tiếp nối theo trình tự
biểu diễn trình tự mà message hay stimulus gởi, theo sau là dấu
hai chấm và kế đó là tên của operation sẽ được triệu gọi.

Hình 4.11 biểu diễn rằng một manager gán các hoạt động
(activities) và các tác vụ hay nhiệm vụ(tasks) tới một nhóm làm
việc dựa trên các yêu cầu của một project (Một dự án có nhiều
hoạt động và một hoạt động có nhiều tác vụ hay nhiệm vụ).

(Hình 4.11. Phát sinh sự tương tác)

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 34


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
Hình 4.12 biểu diễn sự tương tác cụ thể giữa Si (là một
manager), dự án Eagle, và nhóm làm việc (không xác định cụ
thể).

(Hình 4.12. Chi tiết sự tương tác)

IV.2.2 Các nguyên lý cơ bản (Principles)

Mô hình hướng đối tượng dựa trên cơ sở nề tảng bốn


nguyên lý cơ bản cho phép chúng ta quản lý sự thay đổi và sự
phức tạp tốt hơn. Trong phần tiếp theo sau đây chúng ta sẽ thảo
luận về các nguyên lý cơ bản này.

IV.2.2.1 Sự trừu tượng hoá (Abstractions)

Các Concept và relationship được hiểu như là sự trừu


tượng hoá. Các Classe và quan hệ kết hợp (association) là sự
trừu tượng hoá chung hay sự trừu tượng hoá tổng (general
abstractions), và các đối tượng objects và các liên kết (links) là
sự trừu tượng hoá cụ thể (specific abstractions). Một sự trừu
tượng hoá được cho là tốt phải định nghĩa hợp lý và bao gồm
đầy đủ các thông tin cốt lõi nhằm để hiểu nó, ngoài ra loại trừ
các không tin phụ hay không thích đáng. Ví dụ, khi truyền đạt
thông tin về các manager, thật là cần thiết với việc chúng ta cần
biết tên của họ, và cũng thật là không cần thiết đối với chúng ta
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 35
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
việc biết họ sở hữu bao nhiêu có bao nhiêu vật nuôi làm kiểng,
nếu có. Cách làm là chúng ta xem xét nhiều manager khác nhau
để qua đó chúng ta có thể xác định những điểm nào là tương
đồng và những điểm nào là khác nhau để từ đó phân loại chúng
theo như các manager. Với việc sử dụng sự trừu tượng hoá được
định nghĩa tốt, chúng ta có thể quản lý sự phức tạp tốt hơn do
tập trung sự quan tâm trên những gì cốt lõi.

IV.2.2.2Tính đóng gói(Encapsulation)

Việc kết hợp các thuộc tính (attributes) và các operations


tới hình thái classes và objects và việc che dấu các methods ở
đằng sau các operations được hiểu như là sự đóng gói
(encapsulation).

Sự kết hợp các thuộc tính và operation tới các classes và


các objects cũng được hiểu như là sự cục bộ hoá hay địa phương
hoá (localization). Với việc kết hợp các thuộc tính và các
operations vào trong các đơn thể (single units), chúng ta có thể
quản lý sự thay đổi và độ phức tạp tốt hơn bằng cách giảm bớt
số chỗ mà chúng ta phải quan tâm xem xét khi có một sự thay
đổi xảy ra. Ví dụ, khi có một thay đổi đối với class có tên
Manager, như lá một nhu cầu theo dõi số năm kinh nghiệm của
một manager, chúng đơn giản là cần tới class và cập nhật các
thuộc tính hay các operations của nó hơn là tới một nơi lưu trữ
dữ liệu để cập nhật dữ liệu của manager (hay các thuộc tính) và
nơi khác để cập nhật xử lý của nó (hay các operations).

Khi các classes hay các objects truyền đạt thông tin,
khách hàng (client) thường chỉ quan tâm đến các kết quả của
operation chớ không phải method mà nhà cung cấp (supplier) sử
dụng để thực hiện operation; do đó, một method có thể được che
dấu hoàn toàn khỏi những client của nó. Ví dụ, một manger thì
quan tâm đến việc có nhóm làm việc thực hiện một project, mà
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 36
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
không quan tâm đến chi tiết phức tạp của cách nhóm làm việc
thực hiện project. Một thuộc tính cũng có thể được tạo nên và
không cho phép truy cập hay ẩn đi đối với các client bởi vì nó
phải được truy cập thông qua các operation, thông qua các bộ
get và set, nó lấy và thiết lập giá trị của thuộc tính. Ví dụ, làm
thế nào để thông tin về ngân sách liên quan với một project được
lưu trữ có thể được che giấu đối với các khách hàng, bởi vì nó
được lưu trữ hoặc trong cơ sở dữ liệu hoặc trong một tập tin
không phải cơ sở dữ liệu quan hệ, và có thể được truy xuất
thông qua các operation: getter và setter.

Việc che giấu một phương thức (method) đằng sau một
operation cũng được hiểu như là việc che giấu thông tin. Cách
làm này cho phép chúng ta quản lý sự thay đổi và sự phức tạp
tốt hơn, bởi vì chúng ta có thể sửa đổi một phương thức của một
class mà không ảnh hưởng đến các client sử dụng operation
được cài đặt bởi method. Ví dụ, khi một manager quản lý nhóm
làm việc thực thi một project, nhóm làm việc có thể sử dụng các
kỹ thuật khác nhau, và có thể thay đổi các kỹ thuật mà không
ảnh hưởng đến manager. Hơn nữa, các bộ getter và setter đối với
ngân sách liên quan với một project có thể bị thay đổi nơi lưu
trữ ngân sách trong cơ sở dữ liệu thay thế cho việc lưu trữ trong
một tập tin không phải cơ sở dữ liệu, hoặc có sự thay đổi nơi lưu
trữ ngược lại, mà không làm ảnh hưởng tới các client.

IV.2.2.3 Sự tổng quát hoá (Generalization)

Hình 4.13 biểu diễn các classe tương ứng với các yêu cầu và hệ
thống dựa trên sự xác định các yêu cầu với case study hệ thống
quản lý project. Chú ý rằng Requirement và System (Hình
4.13) là các là các kết quả công việc với một vài thuộc tính và
operation giống nhau nhưng các method khác nhau đối với sự
kiểm tra tính hợp lệ và tính duy nhất của các thuộc tính đối với
classe của chúng. Đó là cả hai System và Requirement đều có
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 37
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
một thuộc tính Percent Complete và một thuộc tính
Description, tuy nhiên Requirement thì có một thuộc tính
Media trong khi System có một thuộc tính Platform. Trong khi
cả hai System và Requirement có một operation là Validate,
và Requirement thì có một operation là Publish trong khi
System có một operation là Deploy. Chúng ta có thể lợi dụng sự
tổng quát hoá để nắm bắt và tái sử dụng sự tương đồng của
chúng. Một sự tổng quát hoá được sử dụng giữa một class có
tính tổng quát hơn và một lớp class có tính chuyên biệt hơn chứa
đựng các thuộc tính, các relationship, các operation, và các
method xuất phát từ các class chung hơn. Một sự tổng quát hoá
được biểu diễn với một đường thẳng đậm có hướng từ class có
tính chuyên biệt hơn, với một tam giác rỗng lớn ở cuối đường
dẫn được kết nối tới class chung hơn.

(Hình 4.13)

Hình 4.14 biểu diễn cách mà một sự tổng quát hoá được sử dụng
để truyền đạt ý tưởng cả hai Requirement và System là sản
phẩm công việc có một sự mô tả, phần trăm hoàn tất, và có thể
được kiểm tra xác nhận tính hợp lệ. Chú ý rằng hoạt động
(operation) Validate chuyển vào trong class có tên Work
Product, tương tự đối với các thuộc tính Description và
Platform, tuy nhiên hoạt động Validate cũng xuất hiện trong
class Requirement và System. Trong phần kế, tôi sẽ thảo luận
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 38
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
tại sao hoạt động Validate trong tất cả các classe. Với việc sử
dụng sự tổng quát hoá, chúng ta có thể quản lý sự thay đổi và sự
phức tạp tốt hơn. Chúng ta thu được khả năng tái sử dụng những
đối tượng trừu tượng hoá đang tồn tại để định nghĩa các đối
tượng trừu tượng hoá mới, và các thay đổi mà chúng ta tạo nên
ở một class chung hơn sẽ được truyền tới các classe riêng biệt
hơn. Ví dụ, chúng ta có thể sử dụng class có tên Work Product
để định nghĩa các loại kết quả công việc khác như user
documentation, installation và administration manuals, và vân
vân cần thiết trong tương lai.

(Hình 4.14)

IV.2.2.4 Tính đa hình (Polymorphism)

Hình 4.14 biểu thị rằng hành động (operation) Validate


xuất hiện trong tất cả các classe. Nó được định danh hay khai
được khai báo trong lớp classe có tên Work Product , có thể với
một phương thức mặc định, trái lại lớp Requirement và lớp
System cung cấp các phương thức của riêng chúng đối với sự
xác nhận tính hợp lệ. Vì lý do đó, cần thiết cho việc các lớp
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 39
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
Requirement và System liệt kê các hành động Validate của
riêng chúng. Các lớp này được kế thừa hoàn toàn chức năng
Validate mặc định xuất phát lớp Work Product, bạn không
phải liệt kê lại phương thức Validate. Khả năng có nhiều
phương thức cho một hành động (operation) đơn lẻ được gọi là
tính đa hình (polymorphism).

Bởi vì một sự tổng quát hoá giữa một lớp tổng quát hơn
và một lớp chuyên biệt hơn cũng ngụ ý rằng các đối tượng của
lớp chuyên biệt hơn chính là các đối tượng được chuyên biệt hoá
của lớp tổng quát, về nguyên tắc các đối tượng của lớp chuyên
biệt có thể được thay thế cho các đối tượng của lớp tổng quát. Ví
dụ, các yêu cầu và hệ thống có thể được thay thế cho các sản
phẩm công việc. Việc đơn giản áp dụng hành động Validate
trên một sản phẩm công việc (work product) mà không biết lớp
thực sự của nó sẽ gây ra việc phương thức thích hợp sẽ được
triệu gọi. Với việc sử dụng tính đa hình (polymorphism), chúng
ta có thể quản lý sự thay đổi và sự phức tạp tốt hơn bởi việc sử
dụng lại các hành động (operations) với các phương thức mới,
và chúng ta có thể truyền đạt các thỉnh cầu mà không phải quản
lý các phương thực tế nào đã được triệu gọi. Đó là, chúng ta có
thể thao tác các sả phẩm công việc requirement, các sản phẩm
công việc system, và các loại sản phẩm công việc cụ thể khác
hoàn toàn như là các loại sản phẩm công việc tổng quát. Đối với
mỗi sản phẩm công việc requirement, phương thức Validate
được cung cấp bởi lớp Requirement được triệu gọi để điều
khiển (handle) các thỉnh cầu xác đinh tính hợp lệ . Đối với mỗi
sản phẩm công việc system, phương thức Validate được cung
cấp bởi lớp System dược triệu gọi để điều khiển các thỉnh cầu
xác định tính hợp lệ , và cũng như thế đối với bất kỳ loại sản
phẩm công việc nào khác.

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 40


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
IV.2.2.5 Paragraphs

Một paragraph là một nhóm của các sentences liên quan


tới một đối tượng chung. Ví dụ, ngôn ngữ English nhóm các câu
(sentences) vào trong các đoạn văn (paragraphs). Các đoạn văn
UML là các lược đồ (diagrams). Một lược đồ là một tập hợp các
câu của UML. Các thành tố (elements) cấu tạo nên một lược đồ
được hiểu như là các thành tố lược đồ. Ví dụ, tất cả các thành tố
trên những hình đã biểu diễn ở phần trên là các thành tố lược đồ.

Chủ đề chính liên quan đến những gì mà chúng ta truyền


đạt là một hệ thống tập trung vào trong một domain. Một
domain, cũng được hiểu như là một ngữ cảnh (context), là một
phạm vi khái quát của sự quan tâm có một tập hợp các concepts
và các relationships được chấp nhận. Các concepts này là các
lớp (classes), và các relationships của chúng lag các quan hệ kết
hợp (associations); cả hai được hiểu như là các thành tố domain
(domain elements). Cho ví dụ, hệ thống quản lý dự án có thể
được sử dụng để quản lý các dự án về các ngành kinh oanh khác
nhau, bao gồm chế tạo sản phẩm, các dịch vụ chiến lược, các
dịch vụ tài chính, tư vấn công nghệ thông tin, và vân vân, và
mỗi ngành nghề là một domain khác nhau. Việc hiểu biết một
domain người dùng có ý nghĩa then chốt như là một điểm khởi
đầu đối với việc phát triển một hệ thống mà người dùng sẽ tìm
thấy sự hữu ích và đáng giá.

Một hệ thống là một tập hợp các thành tố được tổ chức


cùng nhau nhằm một mục tiêu cụ thể. Các thành tố này được
hiểu như là các thành tố hệ thống. Để hiểu một hệ thống, chúng
ta tập trung sự quan tâm trên các kiến trúc của nó. Kiến trúc của
một hệ thống bao gồm các thành tố cấu tạo nên hệ thống và cách
mà chúng làm việc cùng nhau để cung cấp chức của năng hệ
thống. Các thành tố chính cấu tạo nên một hệ thống được hiểu
như là các thành tố kiến trúc. Các thành tố của một hệ thống và
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 41
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
các relationships của chúng định nghĩa cấu trúc của hệ thống, và
cách các thành tố tương tác và cộng tác định nghĩa hành vi
(behavior) của hệ thống.

Một hệ thống có thể được phân rả đệ quy thành các hệ


thống nhỏ hơn, được gọi là các hệ thống con (subsystems) và
các thành tố cơ sở (primitive elements). Các hệ thống con
(Subsystems) có thể lại được phân rả thêm nữa thành các hệ
thống con của hệ thống con (sub-subsystems) và các thành tố cơ
sở, và vân vân. Khi đã phân rả hoàn toàn, một hê thống và tất cả
các hệ thống con của nó bao gồm các thành tố cơ sở. Các thành
tố cơ sở không thể phân rả được thêm nữa. Ví dụ, hệ thống quản
lý dự án có thể được phân rả thành như sau đây:

• Một hệ thống con giao diện người dùng chịu trách nhiệm
cung cấp một giao diện mà qua đó người dùng có thể
tương tác với hệ thống.
• Một hệ thống con xử lý quy tắc doanh nghiệp chịu trách
nhiệm đối với việc cài đặt các chức năng theo quy tắc
doanh nghiệp.
• Một hệ thống con có ý nghĩa thành phần dữ liệu chịu
trách nhiệm đối với việc cài đặt chức năng lưu trữ dữ
liệu.

Khi mà các thành tố cơ sở của một hệ thống hay hệ thống


con là các đối tượng, hệ thống được xem như một hệ thống
hướng đối tượng (object-oriented system). Khi mà các thành tố
cơ sở chỉ là các thành tố dữ liệu và các hàm (functions) hay các
thủ tục (procedures), hệ thống được xem như là một hệ thống
không hướng đối tượng (non-object-oriented system).

UML cung cấp nhiều kỹ thuật mô hình hoá khác nhau để


truyền đạt ý tưởng với việc sử dụng các lược đồ (diagrams). Mỗi
loại lược đồ có thế mạnh đối với một số vụ việc nào đó về một
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 42
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
hệ thống, và số lượng bất kỳ các lược đồ có thể được sử dụng để
để truyền đạt ý tưởng về hệ thống.

Chúng ta sẽ tìm hiểu về các loại lược đồ này trong một


chương khác của quyển tài liệu này.

Ngoài ra, UML còn cho phép chúng ta định nghĩa các lược
đồ của chính mình, nếu cần thiết. Ví dụ, chúng ta có thể định
nghĩa một lược đồ dạng database schema truyền đạt ý tưởng về
các table trong một cơ sở dữ liệu và các mối qua hệ
(relationships) của chúng. Trong UML, các lược đồ diagrams
phụ thuộc hai loại hay kiểu khái quát chung: Cấu trúc
(structural) và hành vi (behavioral). Ngoài ra còn có các thành tố
chung hơn áp dụng cho cả hai kiểu lược đồ.

IV.2.2.6 Sections

Một section trong UML là một nhóm của những


paragraphs theo một vấn đề chung. Ví dụ, ngôn ngữ English
nhóm các đoạn văn (paragraphs) vào trong các đề mục
(sections). Các sections của UML là các kiến trúc view. Một
kiến trúc view là một loại lược đồ thể hiện về một tập hợp các
vấn đề quan tâm riêng biệt hay nói cách khác mỗi view là một
thể hiện của hệ thống được mô hình hoá. Toàn bộ các kiến trúc
view khác nhau xác định các cách khác nhau mà qua nó chúng
ta có thể hiểu được một hệ thống. Ví dụ, tất cả các hình được
biểu diễn ở phần bên trên trong chương này có thể được tổ chức
vào trong các view khác nhau, bao gồm functional, structural,
behavioral, và những phần khác của hệ thống quản lý dự án. Các
thành tố cấu tạo nên một view được hiểu như là các thành tố
view. Ví dụ, toàn bộ các thành tố trong những hình như đã đề
cập là các thành tố view khi chúng ta sắp xếp phân loại lược đồ
mà trên đó chúng xuất hiện trong một view cụ thể.

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 43


CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
Bởi vì UML là một ngôn ngữ chứ không phải một
phương pháp luận (methodology), nó không bắt buộc tường
minh mọi kiến trúc view, tuy nhiên các lược đồ UML có thể
được tổ chức tổng quát xung quanh các kiến trúc view tổng quát
thường được sử dụng sau đây:

• Kiến trúc use-case view hay user view hay scenario view

Tập trung sự quan tâm trên chức năng của một hệ thống,
sử dụng các lược đồ use-case để mô tả những chức năng
nào mà hệ thống cung cấp cho những người dùng của nó.

• Kiến trúc Structure view hay Static view hay Logical


view

Tập trung sự chú ý trên cấu trúc của một hệ thống, với
việc sử dụng các lược lớp (class) và các lược đồ đối
tượng để mô tả các thành tố và các mối quan hệ nào cấu
tạo nên hệ thống. Trong đó:

o Lược đồ lớp (class diagram): Mô tả cấu trúc tĩnh


của hệ thống, thể hiện các thành phần hệ thống
xử lý được.
o Lược đồ đối tượng (Object diagram): Mô tả cấu
trúc tĩnh của hệ thống tại thời điểm xác định, nó
có thể được xem như một thể hiện của lược đồ
lớp.
• Kiến trúc behavioral view hay Dynamic view

Tập trung sự chú ý trên hành vi của hệ thống, với việc sử


dụng các lược đồ tuần tự (sequence), cộng tác
(collaboration), trang thái (state), và hoạt động (activity)
để mô tả sự tương tác (interactions) và sự cộng tác
(collaborations) của các thành tố cấu tạo nên hệ thống.
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 44
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
• Kiến trúc component view hay implementation view

Tập trung sự chú ý trên sự thực thi của một hệ thống, với
việc sử dụng các lược đồ thành phần (component
diagrams) để mô tả cách hệ thống được thực thi. Hay nói
cách khác, nó mô tả tổ chức các thành phần thực thi
trong hệ thống.

• Mô hình kiến trúc deployment view hay environment


view

Tập trung sự chú ý vào môi trường thực thi, với việc sử
dụng các lược đồ triển khai (deployment diagrams) để
mô tả cách hệ thống hiện có thực thi trong môi trường
của nó.

Mặc dù mỗi loại lược đồ được tổ chức xung quanh một


kiến trúc view đơn lẻ, loại lược đồ bất kỳ có thể được sử dụng
trong kiến trúc view bất kỳ. Ví dụ, một lược đồ tương tác
(interaction diagram) có thể được sử dụng trong một use-case
view để mô tả cách những người dùng tương tác với một hệ
thống. Hơn nữa, UML cho phép chúng ta định nghĩa các kiến
trúc view của riêng mình, nếu cần thiết. Ví dụ, chúng ta có thể
định nghĩa một một kiến trúc view lưu trữ dữ liệu, và chúng ta
có thể định nghĩa một loại lược đồ mới, có lẽ được gọi là một
lược đồ database schema, để mô tả các table trong một database
và các mối quan hệ giữa chúng. Chúng ta có thể kế đó sử dụng
các loại lược đồ khác để mô tả các triggers và các stored
procedures trong một database.

IV.2.2.7 Documents

Một document của UML là một nhóm của các sections theo một
chủ đề chung, với việc bao gồm các lược đồ non-UML bất kỳ,
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 45
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
những tài liệu nguyên bản, và thông tin khác. Các tài liệu UML
là các mô hình (models). Ví dụ, ngôn ngữ English nhóm các
sections vào trong các documents. Một model là một trình bày
của một hệ thống. Ví dụ, toàn bộ những hình trong chương này
và các tài liệu nguyên bản của chúng là một model của hệ thống
quản lý dự án. Các thành tố cấu tạo nên một model được hiểu
như là các thành tố model. Ví dụ, mọi thành tố được sử dụng
trên các lược đồ trong chương này, với việc cung cấp tất cả các
tài liệu cần thiết cho việc mô tả thành tố, các hình thái một thành
tố model.

Mối qua hệ giữa các model, các kiến trúc view, và các
lược đồ (diagrams) tương tự như các mối quan hệ giữa các
databases, views, và truy vấn dữ liệu (queries). Một database
houses data, các view tổ chức các tập con dữ liệu thành thông tin
đầy đủ ý nghĩa. Một thành tố model tương tự như một thành tố
dữ liệu trong cơ sở dữ liệu, các thành tố view thì tương tự như
các thành tố dữ liệu được sử dụng bên trong các view, và các
thành tố lược đồ tương tự như các thành tố dữ liệu được sử dụng
bên trong các truy vấn dữ liệu.

Bởi vì UML là một ngôn ngữ chứ không phải là một


phương pháp luận, nó không bắt buộc tường minh mọi bước đối
với việc áp dụng các model triển khai hệ thống dựa trên các yêu
cầu của nó, trái lại bất kỳ phương pháp luận nào nói chung có
thể hướng vào các model trong sự kết hợp với các kiến trúc view
này.

Các mô hình (Models) và các lược đồ (diagrams) giúp


chúng ta nắm bắt và truyền đạt những gì chúng ta hiểu về các
yêu cầu và hệ thống xuyên suốt toàn bộ quá trình chu trình sống
triển khai hệ thống. Chúng không chỉ cho phép chúng ta quản lý
sự thay đổi và sự phức tạp, mà còn giúp chúng ta đánh giá sự
hiểu biết của chúng ta còn hơn là phải tiêu tốn các nguồn tài
Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 46
CHƯƠNG 4: UML và mô hình hoá hướng đối tượng
nguyên cho việc sản sinh ra một hệ thống mà nó không thể được
chấp nhận hoặc không đủ đáp ứng các yêu cầu. Các mô hình
capture tất cả chi tiết nhằm vượt qua sự cách biệt lớn giữ các
yêu cầu và hệ thống.

V Phần mềm (Software)


 Rational Rose hoặc Microsoft Visial

VI Tài liệu tham khảo


1. Learning UML - Sinan Si Alhir (O'Reilly) July
2003

Phân tích thiết kế hệ thống – GV: Trần Xuân Hải Trang 47

You might also like