Professional Documents
Culture Documents
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.
(Hình II.1)
(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.
• 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
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 đó (R1R5) 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ọ..
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
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ệ 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.
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)
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
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.
(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.1 Concepts
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
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.
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.
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.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ụ).
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.
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)
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.
• 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.
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
• 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ó.
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 đó:
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.
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ó.
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.