Phân tích và thi tk

H th ng thông tin v i UML

c

c 45 ti t LT + 30 ti t TH

’c  TS. D ng Ki u Hoa Ɗ Tôn Th t Hoà An


c



 c
Chương 1: TӘNG QUAN Vӄ PHÂN TÍCH THIӂT Kӂ Hӊ THӔNG

›››

1- DҮN NHҰP:

1.1- Tính trӵc quan:

Chúng ta có thӇ thҩy rҵng: "Mӝt sӕ tұp hӧp dӳ liӋu phӭc tҥp nhҩt đӏnh khi đưӧc trình bày
bҵng đӗ thӏ sӁ truyӅn tҧi đӃn ngưӡi đӑc nhiӅu thông tin hơn so vӟi các dӳ liӋu thô". Vӟi
phҫn mӅm cũng vұy, khi ngành Công nghiӋp cӫa chúng ta ngày càng phát triӇn, các hӋ
thӕng sӁ trӣ nên phӭc tҥp hơn. Khҧ năng nҳm bҳt và kiӇm soát sӵ phӭc tҥp đó cӫa chúng
ta đi kèm vӟi khҧ năng trình bày hӋ thӕng mӝt cách toàn diӋn - mӝt sӵ trình bày vưӧt ra
ngoài giӟi hҥn cӫa nhӳng dòng lӋnh thô. Sӵ thành công trên thӏ trưӡng cӫa nhӳng ngôn
ngӳ như Visual Basic và phҫn giao diӋn trӵc quan cӫa C++, Java đã cho thҩy sӵ trình bày
trӵc quan mang tính cӕt yӃu đӕi vӟi quá trình phát triӇn các hӋ thӕng phӭc tҥp.

1.2- Mô hình trӯu tưӧng:

Trưӟc đây, có mӝt thӡi gian dài, ngành công nghiӋp chúng ta đã phҧi nói tӟi mӝt "Cuӝc
khӫng hoҧng phҫn mӅm". Các cuӝc tranh luұn đӅu dӵa trên thӵc tӃ là chҷng nhӳng nhiӅu
đӗ án phҫn mӅm không thӇ sҧn sinh ra nhӳng hӋ thӕng thoҧ mãn đòi hӓi và nhu cҫu cӫa
khách hàng, mà còn vưӧt quá ngân sách và thӡi hҥn. Các công nghӋ mӟi như lұp trình
hưӟng đӕi tưӧng, lұp trình trӵc quan cũng như các môi trưӡng phát triӇn tiên tiӃn có giúp
chúng ta nâng cao năng suҩt lao đӝng, nhưng trong nhiӅu trưӡng hӧp, chúng chӍ hưӟng
tӟi tҫng thҩp nhҩt cӫa viӋc phát triӇn phҫn mӅm: phҫn viӃt lӋnh (coding). Mӝt trong
nhӳng vҩn đӅ chính cӫa ngành phát triӇn phҫn mӅm thӡi nay là có nhiӅu đӗ án bҳt tay vào
lұp trình quá sӟm và tұp trung quá nhiӅu vào viӋc viӃt code. Lý do mӝt phҫn là do ban
quҧn trӏ thiӃu hiӇu biӃt vӅ quy trình phát triӇn phҫn mӅm và hӑ nҧy lo âu khi thҩy đӝi
quân lұp trình cӫa hӑ không viӃt code. Và bҧn thân các lұp trình viên cũng cҧm thҩy an
tâm hơn khi hӑ ngӗi viӃt code - vӕn là tác vө mà hӑ quen thuӝc! ± hơn là khi xây dӵng
các mô hình trӯu tưӧng cho hӋ thӕng mà hӑ phҧi tҥo nên.

1.3- Mô hình hóa trӵc quan:

Mô hình hoá trӵc quan là mӝt phương thӭc tư duy vӅ vҩn đӅ sӱ dөng các mô hình đưӧc
tә chӭc xoay quanh các khái niӋm đӡi thӵc. Mô hình giúp chúng ta hiӇu vҩn đӅ, giao tiӃp
vӟi mӑi ngưӡi có liên quan đӃn dӵ án (khách hàng, chuyên gia lĩnh vӵc thuӝc đӅ án, nhà
phân tích, nhà thiӃt kӃ, «). Mô hình rҩt hӳu dөng trong viӋc mô hình hoá doanh nghiӋp,
soҥn thҧo tài liӋu, thiӃt kӃ chương trình cũng như ngân hàng dӳ liӋu. Mô hình giúp hiӇu
các đòi hӓi cӫa hӋ thӕng tӕt hơn, tҥo các thiӃt kӃ rõ ràng hơn và xây dӵng nên các hӋ
thӕng dӉ bҧo trì hơn.

Mô hình là kӃt quҧ cӫa sӵ trӯu tưӧng hóa nhҵm miêu tҧ các thành phҫn cӕt yӃu cӫa mӝt
vҩn đӅ hay mӝt cҩu trúc phӭc tҥp qua viӋc lӑc bӟt các chi tiӃt không quan trӑng và làm
cho vҩn đӅ trӣ thành dӉ hiӇu hơn. Trӯu tưӧng hóa là mӝt năng lӵc căn bҧn cӫa con ngưӡi,
cho phép chúng ta giҧi quyӃt các vҩn đӅ phӭc tҥp. Các kӻ sư, nghӋ sĩ và thӧ thӫ công đã
xây dӵng mô hình tӯ hàng ngàn năm nay đӇ thӱ nghiӋm thiӃt kӃ trưӟc khi thӵc hiӋn. Phát
triӇn phҫn mӅm cũng không là ngoҥi lӋ. ĐӇ xây dӵng các hӋ thӕng phӭc tҥp, nhà phát
triӇn phҧi trӯu tưӧng hóa nhiӅu hưӟng nhìn khác nhau cӫa hӋ thӕng, sӱ dөng ký hiӋu
chính xác đӇ xây dӵng mô hình, kiӇm tra xem mô hình có thӓa mãn các đòi hӓi cӫa hӋ
thӕng, và dҫn dҫn bә sung thêm chi tiӃt đӇ chuyӇn các mô hình thành thӵc hiӋn.

Chúng ta xây dӵng mô hình cho các hӋ thӕng phӭc tҥp bӣi chúng ta không thӇ hiӇu thҩu
đáo nhӳng hӋ thӕng như thӃ trong trҥng thái toàn vҽn cӫa chúng. Khҧ năng thҩu hiӇu và
nҳm bҳt tính phӭc tҥp cӫa con ngưӡi là có hҥn. ĐiӅu này ta có thӇ thҩy rõ trong ví dө cӫa
ngành xây dӵng. NӃu bҥn muӕn tҥo mӝt túp lӅu ӣ góc vưӡn, bҥn có thӇ bҳt tay vào xây
ngay. NӃu bҥn xây mӝt ngôi nhà, có lӁ bҥn sӁ cҫn tӟi bҧn vӁ, nhưng nӃu bҥn muӕn xây
mӝt toà nhà chӑc trӡi thì chҳc chҳn bҥn không thӇ không cҫn bҧn vӁ. ThӃ giӟi phҫn mӅm
cӫa chúng ta cũng thӃ. ChӍ tұp trung vào các dòng code hay thұm chí cҧ phân tích Forms
trong Visual Basic chҷng cung cҩp mӝt cái nhìn toàn cөc vӅ viӋc phát triӇn đӗ án. Xây
dӵng mô hình cho phép nhà thiӃt kӃ tұp trung vào bӭc tranh lӟn vӅ sӵ tương tác giӳa các
thành phҫn trong đӗ án, tránh bӏ sa lҫy vào nhӳng chi tiӃt riêng biӋt cӫa tӯng thành phҫn.

Mӝt môi trưӡng kinh doanh mang tính cҥnh tranh gay gҳt và luôn luôn thay đәi dүn đӃn
tính phӭc tҥp ngày càng tăng cao, và tính phӭc tҥp này đһt ra nhӳng thách thӭc đһc trưng
cho các nhà phát triӇn hӋ thӕng. Mô hình giúp chúng ta tә chӭc, trình bày trӵc quan, thҩu
hiӇu và tҥo nên các hӋ thӕng phӭc tҥp. Chúng giúp chúng ta đáp ӭng các thách thӭc cӫa
viӋc phát triӇn phҫn mӅm, hôm nay cũng như ngày mai.

2- MÔ TҦ CHU TRÌNH PHÁT TRIӆN PHҪN MӄM:

2.1- Software Development ± mӝt bài toán phӭc tҥp:

Kinh nghiӋm cӫa nhiӅu nhà thiӃt kӃ và phát triӇn cho thҩy phát triӇn phҫn mӅm là mӝt bài
toán phӭc tҥp. Xin nêu mӝt sӕ các lý do thưӡng đưӧc kӇ đӃn:

- Nhӳng ngưӡi phát triӇn phҫn mӅm rҩt khó hiӇu cho đúng nhӳng gì ngưӡi dùng
cҫn

- Yêu cҫu cӫa ngưӡi dùng thưӡng thay đәi trong thӡi gian phát triӇn.

- Yêu cҫu thưӡng đưӧc miêu tҧ bҵng văn bҧn, dài dòng, khó hiӇu, nhiӅu khi thұm
chí mâu thuүn.

- Đӝi quân phát triӇn phҫn mӅm, vӕn là ngưӡi "ngoài cuӝc", rҩt khó nhұn thӭc
thҩu đáo các mӕi quan hӋ tiӅm ҭn và phӭc tҥp cҫn đưӧc thӇ hiӋn chính xác trong các ӭng
dөng lӟn.
 - Khҧ năng nҳm bҳt các dӳ liӋu phӭc tҥp cӫa con ngưӡi (tҥi cùng mӝt thӡi điӇm)
là có hҥn.

- Khó đӏnh lưӧng chính xác hiӋu suҩt cӫa thành phҭm và thӓa mãn chính xác sӵ
mong chӡ tӯ phía ngưӡi dùng.

- Chӑn lӵa phҫn cӭng và phҫn mӅm thích hӧp cho giҧi pháp là mӝt trong nhӳng
thách thӭc lӟn đӕi vӟi Designer.

Phҫn mӅm ngoài ra cҫn có khҧ năng Y
  và 

. Phҫn mӅm đưӧc thiӃt
kӃ tӕt là phҫn mӅm đӭng vӳng trưӟc nhӳng biӃn đәi trong môi trưӡng, dù tӯ phía cӝng
đӗng ngưӡi dùng hay tӯ phía công nghӋ. Ví dө phҫn mӅm đã đưӧc phát triӇn cho mӝt nhà
băng cҫn có khҧ năng tái sӱ dөng cho mӝt nhà băng khác vӟi rҩt ít sӱa đәi hoһc hoàn toàn
không cҫn sӱa đәi. Phҫn mӅm thoҧ mãn các yêu cҫu đó đưӧc coi là phҫn mӅm có khҧ
năng thích ӭng.

Mӝt phҫn mӅm có khҧ năng mӣ rӝng là phҫn mӅm đưӧc thiӃt kӃ sao cho dӉ phát triӇn
theo yêu cҫu cӫa ngưӡi dùng mà không cҫn sӱa chӳa nhiӅu.

Chính vì vұy, mӝt sӕ các khiӃm khuyӃt thưӡng gһp trong phát triӇn phҫn mӅm là:

- HiӇu không đúng nhӳng gì ngưӡi dùng cҫn

- Không thӇ thích ӭng cho phù hӧp vӟi nhӳng thay đәi vӅ yêu cҫu đӕi vӟi hӋ
thӕng

- Các Module không khӟp vӟi nhau

- Phҫn mӅm khó bҧo trì và nâng cҩp, mӣ rӝng

- Phát hiӋn trӉ các lӛ hәng cӫa dӵ án

- Chҩt lưӧng phҫn mӅm kém

- HiӋu năng cӫa phҫn mӅm thҩp

- Các thành viên trong nhóm không biӃt đưӧc ai đã thay đәi cái gì, khi nào, ӣ đâu,
tҥi sao phҧi thay đәi.

2.2- Chu Trình Phát TriӇn Phҫn MӅm (Software Development Life Cycle):

Vì phát triӇn phҫn mӅm là mӝt bài toán khó, nên có lӁ trưӟc hӃt ta cҫn điӇm qua mӝt sӕ
các công viӋc căn bҧn cӫa quá trình này. Thưӡng ngưӡi ta hay tұp hӧp chúng theo tiӃn
trình thӡi gian mӝt cách tương đӕi, xoay quanh chu trình cӫa mӝt phҫn mӅm, dүn tӟi kӃt
qӫa khái niӋm Chu Trình Phát TriӇn Phҫn MӅm (Software Development Life Cycle -
SDLC) như sau:
Chu Trình Phát TriӇn Phҫn MӅm là mӝt chuӛi các hoҥt đӝng cӫa nhà phân tích (Analyst),
nhà thiӃt kӃ (Designer), ngưӡi phát triӇn (Developer) và ngưӡi dùng (User) đӇ phát triӇn
và thӵc hiӋn mӝt hӋ thӕng thông tin. Nhӳng hoҥt đӝng này đưӧc thӵc hiӋn trong nhiӅu
giai đӑan khác nhau.

Nhà phân tích (Analyst): là ngưӡi nghiên cӭu yêu cҫu cӫa khách hàng/ngưӡi dùng đӇ
đӏnh nghĩa mӝt phҥm vi bài toán, nhұn dҥng nhu cҫu cӫa mӝt tә chӭc, xác đӏnh xem nhân
lӵc, phương pháp và công nghӋ máy tính có thӇ làm sao đӇ cҧi thiӋn mӝt cách tӕt nhҩt
công tác cӫa tә chӭc này.

Nhà thiӃt kӃ (Designer): thiӃt kӃ hӋ thӕng theo hưӟng cҩu trúc cӫa database, screens,
forms và reports ± quyӃt đӏnh các yêu cҫu vӅ phҫn cӭng và phҫn mӅm cho hӋ thӕng cҫn
đưӧc phát triӇn.

Chuyên gia lĩnh vӵc (Domain Experts): là nhӳng ngưӡi hiӇu thӵc chҩt vҩn đӅ cùng tҩt
cҧ nhӳng sӵ phӭc tҥp cӫa hӋ thӕng cҫn tin hӑc hoá. Hӑ không nhҩt thiӃt phҧi là nhà lұp
trình, nhưng hӑ có thӇ giúp nhà lұp trình hiӇu yêu cҫu đһt ra đӕi vӟi hӋ thӕng cҫn phát
triӇn. Quá trình phát triӇn phҫn mӅm sӁ có rҩt nhiӅu thuұn lӧi nӃu đӝi ngũ làm phҫn mӅm
có đưӧc sӵ trӧ giúp cӫa hӑ.

Lұp trình viên (Programmer): là nhӳng ngưӡi dӵa trên các phân tích và thiӃt kӃ đӇ viӃt
chương trình (coding) cho hӋ thӕng bҵng ngôn ngӳ lұp trình đã đưӧc thӕng nhҩt.

Ngưӡi dùng (User): là đӕi tưӧng phөc vө cӫa hӋ thӕng cҫn đưӧc phát triӇn.

ĐӇ cho rõ hơn, xin lҩy ví dө vӅ mӝt vҩn đӅ đơn giҧn sau:

Ngưӡi bình thưӡng chúng ta khi nhìn mӝt chiӃc xe ô tô thưӡng sӁ có mӝt bӭc tranh tӯ
bên ngoài như sau:

Vҩn đӅ

Hình 1.1: Nhìn vҩn đӅ ô tô cӫa ngưӡi bình thưӡng

Chuyên gia lĩnh vӵc sӁ giúp nhà phân tích "trình bày lҥi" vҩn đӅ như sau:
 Hình 1.2: Nhìn vҩn đӅ ô tô cӫa chuyên gia phân tích

Chính vì sӵ trӧ giúp cӫa chuyên gia lĩnh vӵc có thӇ đóng vai trò rҩt quan trӑng nên trong
nhӳng giai đoҥn đҫu cӫa quá trình phát triӇn phҫn mӅm, kӃt quҧ phân tích nên đưӧc thӇ
hiӋn sao cho dӉ hiӇu đӕi vӟi các chuyên gia lĩnh vӵc. Đây cũng là môt trong rҩt nhiӅu lý
do khiӃn cho phương pháp hưӟng đӕi tưӧng đưӧc nhiӅu ngưӡi hưӣng ӭng.

2.3- Các giai đoҥn cӫa Chu Trình Phát TriӇn Phҫn MӅm:

Chu trình cӫa mӝt phҫn mӅm có thӇ đưӧc chia thành các giai đoҥn như sau:

- Nghiên cӭu sơ bӝ (Preliminary Investigation hay còn gӑi là Feasibility Study)

- Phân tích yêu cҫu (Analysis)

- ThiӃt kӃ hӋ thӕng (Design of the System)

- Xây dӵng phҫn mӅm (Software Construction)

- Thӱ nghiӋm hӋ thӕng (System Testing)

- Thӵc hiӋn, triӇn khai (System Implementation)

- Bҧo trì, nâng cҩp (System Maintenance)

a) Nghiên cӭu sơ bӝ:

Câu hӓi quan trӑng nhҩt khi phát triӇn mӝt hӋ thӕng hoàn toàn không phҧi câu hӓi mang
tính phương pháp luұn. Mà cũng chҷng phҧi câu hӓi vӅ kӻ thuұt. Nó là mӝt câu hӓi
dưӡng như có vҿ đơn giҧn, nhưng thұt ra đһc biӋt khó trҧ lӡi: ³Đây có đúng là mӝt hӋ
thӕng đӇ thӵc hiӋn không?´ Đáng buӗn là chính câu hӓi này trong thӵc tӃ thưӡng chҷng
hӅ đưӧc đһt ra và lҥi càng không đưӧc trҧ lӡi. Mһc dù viӋc lҫm lүn vӅ phương pháp hay
quyӃt đӏnh sai lҫm vӅ kӻ thuұt cũng có thӇ dүn tӟi thҩt bҥi, nhưng thưӡng thì dӵ án có thӇ
đưӧc cӭu vãn nӃu có đҫy đӫ tài nguyên cùng sӵ cӕ gҳng quên mình cӫa các nhân viên tài
giӓi. Nhưng sӁ chҷng mӝt ai và mӝt điӅu gì cӭu vãn cho mӝt hӋ thӕng phҫn mӅm hoàn
toàn chҷng đưӧc cҫn tӟi hoһc cӕ gҳng tӵ đӝng hóa mӝt quy trình lҫm lҥc.

Trưӟc khi bҳt tay vào mӝt dӵ án, bҥn phҧi có mӝt ý tưӣng cho nó. Ý tưӣng này đi song
song vӟi viӋc nҳm bҳt các yêu cҫu và xuҩt hiӋn trong giai đoҥn khӣi đҫu. Nó hoàn tҩt mӝt
phát biӇu: "HӋ thӕng mà chúng ta mong muӕn sӁ làm đưӧc nhӳng viӋc như sau ....".
Trong suӕt giai đoҥn này, chúng ta tҥo nên mӝt bӭc tranh vӅ ý tưӣng đó, rҩt nhiӅu giҧ
thuyӃt sӁ đưӧc công nhұn hay loҥi bӓ. Các hoҥt đӝng trong thӡi gian này thưӡng bao gӗm
thu thұp các ý tưӣng, nhұn biӃt rӫi ro, nhұn biӃt các giao diӋn bên ngoài, nhұn biӃt các
các chӭc năng chính mà hӋ thӕng cҫn cung cҩp, và có thӇ tҥo mӝt vài nguyên mүu dùng
đӇ ³minh chӭng các khái niӋm cӫa hӋ thӕng´. Ý tưӣng có thӇ đӃn tӯ nhiӅu nguӗn khác
nhau: khách hàng, chuyên gia lĩnh vӵc, các nhà phát triӇn khác, chuyên gia vӅ kӻ nghӋ,
các bҧn nghiên cӭu tính khҧ thi cũng như viӋc xem xét các hӋ thӕng khác đang tӗn tҥi.
Mӝt khía cҥnh cҫn nhҳc tӟi là code viӃt trong thӡi kǤ này thưӡng sӁ bӏ "bӓ đi´, bӣi chúng
đưӧc viӃt nhҵm mөc đích thҭm tra hay trӧ giúp các giҧ thuyӃt khác nhau, chӭ chưa phҧi
thӭ code đưӧc viӃt theo kӃt quҧ phân tích và thiӃt kӃ thҩu đáo.

Trong giai đӑan nghiên cӭu sơ bӝ, nhóm phát triӇn hӋ thӕng cҫn xem xét các yêu cҫu cӫa
doanh nghiӋp (cҫn dùng hӋ thӕng), nhӳng nguӗn tài nguyên có thӇ sӱ dөng, công nghӋ
cũng như cӝng đӗng ngưӡi dùng cùng các ý tưӣng cӫa hӑ đӕi vӟi hӋ thӕng mӟi. Có thӇ
thӵc hiӋn thҧo luұn, nghiên cӭu, xem xét khía cҥnh thương mҥi, phân tích khҧ năng lӡi-
lӛ, phân tích các trưӡng hӧp sӱ dөng và tҥo các nguyên mүu đӇ xây dӵng nên mӝt khái
niӋm cho hӋ thӕng đích cùng vӟi các mөc đích, quyӅn ưu tiên và phҥm vi cӫa nó.

Thưӡng trong giai đoҥn này ngưӡi ta cũng tiӃn hành tҥo mӝt phiên bҧn thô cӫa lӏch trình
và kӃ hoҥch sӱ dөng tài nguyên.

Mӝt giai đoҥn nghiên cӭu sơ bӝ thích đáng sӁ lұp nên tұp hӧp các yêu cҫu (dù ӣ mӭc đӝ
khái quát cao) đӕi vӟi mӝt hӋ thӕng khҧ thi và đưӧc mong muӕn, kӇ cҧ vӅ phương diӋn
kӻ thuұt lүn xã hӝi. Mӝt giai đoҥn nghiên cӭu sơ bӝ không đưӧc thӵc hiӋn thoҧ đáng sӁ
dүn tӟi các hӋ thӕng không đưӧc mong muӕn, đҳt tiӅn, bҩt khҧ thi và đưӧc đӏnh nghĩa
lҫm lҥc ± nhӳng hӋ thӕng thӯơng chҷng đưӧc hoàn tҩt hay sӱ dөng.

KӃt quҧ cӫa giai đoҥn nghiên cӭu sơ bӝ là Báo Cáo KӃt Quҧ Nghiên Cӭu Tính Khҧ Thi.
Khi hӋ thӕng tương lai đưӧc chҩp nhұn dӵa trên bҧn báo cáo này cũng là lúc giai đoҥn
Phân tích bҳt đҫu.

b) Phân tích yêu cҫu

Sau khi đã xem xét vӅ tính khҧ thi cӫa hӋ thӕng cũng như tҥo lұp mӝt bӭc tranh sơ bӝ cӫa
dӵ án, chúng ta bưӟc sang giai đoҥn thưӡng đưӧc coi là quan trӑng nhҩt trong các công
viӋc lұp trình: hiӇu hӋ thӕng cҫn xây dӵng. Ngưӡi thӵc hiӋn công viӋc này là nhà phân
tích.

Quá trình phân tích nhìn chung là hӋ quҧ cӫa viӋc trҧ lӡi câu hӓi "HӋ thӕng cҫn phҧi làm
gì?". Quá trình phân tích bao gӗm viӋc nghiên cӭu chi tiӃt hӋ thӕng doanh nghiӋp hiӋn
thӡi, tìm cho ra nguyên lý hoҥt đӝng cӫa nó và nhӳng vӏ trí có thӇ đưӧc nâng cao, cҧi
thiӋn. Bên cҥnh đó là viӋc nghiên cӭu xem xét các chӭc năng mà hӋ thӕng cҫn cung cҩp
và các mӕi quan hӋ cӫa chúng, bên trong cũng như vӟi phía ngoài hӋ thӕng. Trong toàn
bӝ giai đoҥn này, nhà phân tích và ngưӡi dùng cҫn cӝng tác mұt thiӃt vӟi nhau đӇ xác
đӏnh các yêu cҫu đӕi vӟi hӋ thӕng, tӭc là các tính năng mӟi cҫn phҧi đưӧc đưa vào hӋ
thӕng.

Nhӳng mөc tiêu cө thӇ cӫa giai đoҥn phân tích là:

- Xác đӏnh hӋ thӕng cҫn phҧi làm gì.

- Nghiên cӭu thҩu đáo tҩt cҧ các chӭc năng cҫn cung cҩp và nhӳng yӃu tӕ liên
quan

- Xây dӵng mӝt mô hình nêu bұt bҧn chҩt vҩn đӅ tӯ mӝt hưӟng nhìn có thӵc
(trong đӡi sӕng thӵc).

- Trao đӏnh nghĩa vҩn đӅ cho chuyên gia lĩnh vӵc đӇ nhұn sӵ đánh giá, góp ý.

- KӃt quҧ cӫa giai đoҥn phân tích là bҧn Đһc Tҧ Yêu Cҫu (Requirements
Specifications).

c) ThiӃt kӃ hӋ thӕng

Sau giai đoҥn phân tích, khi các yêu cҫu cө thӇ đӕi vӟi hӋ thӕng đã đưӧc xác đӏnh, giai
đoҥn tiӃp theo là thiӃt kӃ cho các yêu cҫu mӟi. Công tác thiӃt kӃ xoay quanh câu hӓi
chính: HӋ thӕng làm cách nào đӇ thӓa mãn các yêu cҫu đã đưӧc nêu trong Đһc Tҧ Yêu
Cҫu?

Mӝt sӕ các công viӋc thưӡng đưӧc thӵc hiӋn trong giai đoҥn thiӃt kӃ:

- Nhұn biӃt form nhұp liӋu tùy theo các thành phҫn dӳ liӋu cҫn nhұp.

- Nhұn biӃt reports và nhӳng output mà hӋ thӕng mӟi phҧi sҧn sinh

- ThiӃt kӃ forms (vӁ trên giҩy hay máy tính, sӱ dөng công cө thiӃt kӃ)

- Nhұn biӃt các thành phҫn dӳ liӋu và bҧng đӇ tҥo database

- Ưӟc tính các thӫ tөc giҧi thích quá trình xӱ lý tӯ input đӃn output.

KӃt quҧ giai đoҥn thiӃt kӃ là Đһc Tҧ ThiӃt KӃ (Design Specifications). Bҧn Đһc Tҧ ThiӃt
KӃ Chi TiӃt sӁ đưӧc chuyӇn sang cho các lұp trình viên đӇ thӵc hiӋn giai đoҥn xây dӵng
phҫn mӅm.

d) Xây dӵng phҫn mӅm

Đây là giai đoҥn viӃt lӋnh (code) thӵc sӵ, tҥo hӋ thӕng. Tӯng ngưӡi viӃt code thӵc hiӋn
nhӳng yêu cҫu đã đưӧc nhà thiӃt kӃ đӏnh sҹn. Cũng chính ngưӡi viӃt code chӏu trách
nhiӋm viӃt tài liӋu liên quan đӃn chương trình, giҧi thích thӫ tөc (procedure) mà anh ta
tҥo nên đưӧc viӃt như thӃ nào và lý do cho viӋc này.

ĐӇ đҧm bҧo chương trình đưӧc viӃt nên phҧi thoҧ mãn mӑi yêu cҫu có ghi trưӟc trong
bҧn Đһc Tҧ ThiӃt KӃ Chi TiӃt, ngưӡi viӃt code cũng đӗng thӡi phҧi tiӃn hành thӱ nghiӋm
phҫn chương trình cӫa mình. Phҫn thӱ nghiӋm trong giai đoҥn này có thӇ đưӧc chia thành
hai bưӟc chính:

Thӱ nghiӋm đơn vӏ:

Ngưӡi viӃt code chҥy thӱ các phҫn chương trình cӫa mình vӟi dӳ liӋu giҧ (test/dummy
data). ViӋc này đưӧc thӵc hiӋn theo mӝt kӃ hoҥch thӱ, cũng do chính ngưӡi viӃt code
soҥn ra. Mөc đích chính trong giai đoҥn thӱ này là xem chương trình có cho ra nhӳng kӃt
quҧ mong đӧi. Giai đoҥn thӱ nghiӋm đơn vӏ nhiӅu khi đưӧc gӑi là "Thӱ hӝp trҳng"
(White Box Testing)

Thӱ nghiӋm đơn vӏ đӝc lұp:

Công viӋc này do mӝt thành viên khác trong nhóm đҧm trách. Cҫn chӑn ngưӡi không có
liên quan trӵc tiӃp đӃn viӋc viӃt code cӫa đơn vӏ chương trình cҫn thӱ nghiӋm đӇ đҧm bҧo
tính ³đӝc lұp´. Công viӋc thӱ đӧt này cũng đưӧc thӵc hiӋn dӵa trên kӃ hoҥch thӱ do
ngưӡi viӃt code soҥn nên.

e) Thӱ nghiӋm hӋ thӕng

Sau khi các thӫ tөc đã đưӧc thӱ nghiӋm riêng, cҫn phҧi thӱ nghiӋm toàn bӝ hӋ thӕng. Mӑi
thӫ tөc đưӧc tích hӧp và chҥy thӱ, kiӇm tra xem mӑi chi tiӃt ghi trong Đһc Tҧ Yêu Cҫu
và nhӳng mong chӡ cӫa ngưӡi dùng có đưӧc thoҧ mãn. Dӳ liӋu thӱ cҫn đưӧc chӑn lӑc
đһc biӋt, kӃt quҧ cҫn đưӧc phân tích đӇ phát hiӋn mӑi lӋch lҥc so vӟi mong chӡ.

f) Thӵc hiӋn, triӇn khai

Trong giai đoҥn này, hӋ thӕng vӯa phát triӇn sӁ đưӧc triӇn khai sao cho phía ngưӡi dùng.
Trưӟc khi đӇ ngưӡi dùng thұt sӵ bҳt tay vào sӱ dөng hӋ thӕng, nhóm các nhà phát triӇn
cҫn tҥo các file dӳ liӋu cҫn thiӃt cũng như huҩn luyӋn cho ngưӡi dùng, đӇ đҧm bҧo hӋ
thӕng đưӧc sӱ dөng hӳu hiӋu nhҩt.

g) Bҧo trì, nâng cҩp

Tùy theo các biӃn đәi trong môi trưӡng sӱ dөng, hӋ thӕng có thӇ trӣ nên lӛi thӡi hay cҫn
phҧi đưӧc sӱa đәi nâng cҩp đӇ sӱ dөng có hiӋu quҧ. Hoҥt đӝng bҧo trì hӋ thӕng có thӇ rҩt
khác biӋt tùy theo mӭc đӝ sӱa đәi và nâng cҩp cҫn thiӃt.
Sơ đӗ tәng quát các giai đoҥn cӫa Chu Trình Phát TriӇn Phҫn MӅm:

Hình 1.3: Sơ đӗ tәng quát các giai đoҥn cӫa Chu Trình Phát TriӇn Phҫn MӅm

3- PHƯƠNG PHÁP HƯӞNG CHӬC NĂNG VÀ PHƯƠNG PHÁP

HƯӞNG ĐӔI TƯӦNG:

3.1- Phương pháp hưӟng chӭc năng:

Đây là lӕi tiӃp cұn truyӅn thӕng cӫa ngành Công nghӋ phҫn mӅm. Theo lӕi tiӃp cұn này,
chúng ta quan tâm chӫ yӃu tӟi nhӳng thông tin mà hӋ thӕng sӁ giӳ gìn. Chúng ta hӓi
ngưӡi dùng xem hӑ sӁ cҫn nhӳng thông tin nào, rӗi chúng ta thiӃt kӃ ngân hàng dӳ liӋu đӇ
chӭa nhӳng thông tin đó, cung cҩp Forms đӇ nhұp thông tin và in báo cáo đӇ trình bày
các thông tin. Nói mӝt cách khác, chúng ta tұp trung vào thông tin và không mҩy đӇ ý
đӃn nhӳng gì có thӇ xҧy ra vӟi nhӳng hӋ thӕng đó và cách hoҥt đӝng (ӭng xӱ) cӫa hӋ
thӕng là ra sao. Đây là lӕi tiӋm cұn xoay quanh dӳ liӋu và đã đưӧc áp dөng đӇ tҥo nên
hàng ngàn hӋ thӕng trong suӕt nhiӅu năm trӡi.

Lӕi tiӃp cұn xoay quanh dӳ liӋu là phương pháp tӕt cho viӋc thiӃt kӃ ngân hàng dӳ liӋu và
nҳm bҳt thông tin, nhưng nӃu áp dөng cho viӋc thiӃt kӃ ӭng dөng lҥi có thӇ khiӃn phát
sinh nhiӅu khó khăn. Mӝt trong nhӳng thách thӭc lӟn là yêu cҫu đӕi vӟi các hӋ thӕng
thưӡng xuyên thay đәi. Mӝt hӋ thӕng xoay quanh dӳ liӋu có thӇ dӇ dàng xӱ lý viӋc thay
đәi ngân hàng dӳ liӋu, nhưng lҥi khó thӵc thi nhӳng thay đәi trong nguyên tҳc nghiӋp vө
hay cách hoҥt đӝng cӫa hӋ thӕng.

Phương pháp hưӟng đӕi tưӧng đã đưӧc phát triӇn đӇ trҧ lӡi cho vҩn đӅ đó. Vӟi lӕi tiӃp
cұn hưӟng đӕi tưӧng, chúng ta tұp trung vào cҧ hai mһt cӫa vҩn đӅ : thông tin vàcách
hoҥt đӝng.

3.2- Phương pháp hưӟng đӕi tưӧng:

÷
 Y là thuұt ngӳ thông dөng hiӋn thӡi cӫa ngành công nghiӋp phҫn mӅm.
Các công ty đang nhanh chóng tìm cách áp dөng và tích hӧp công nghӋ mӟi này vào các
ӭng dөng cӫa hӑ. Thұt sӵ là đa phҫn các ӭng dөng hiӋn thӡi đӅu mang tính hưӟng đӕi
tưӧng. Nhưng hưӟng đӕi tưӧng có nghĩa là gì?

Lӕi tiӃp cұn hưӟng đӕi tưӧng là mӝt lӕi tư duy vӅ vҩn đӅ theo lӕi ánh xҥ các thành phҫn
trong bài toán vào các đӕi tưӧng ngoài đӡi thӵc. Vӟi lӕi tiӃp cұn này, chúng ta chia ӭng
dөng thành các thành phҫn nhӓ, gӑi là các đӕi tưӧng, chúng tương đӕi đӝc lұp vӟi nhau.
Sau đó ta có thӇ xây dӵng ӭng dөng bҵng cách chҳp các đӕi tưӧng đó lҥi vӟi nhau. Hãy
nghĩ đӃn trò chơi xây lâu đài bҵng các mүu gӛ. Bưӟc đҫu tiên là tҥo hay mua mӝt vài loҥi
mүu gӛ căn bҧn, tӯ đó tҥo nên các khӕi xây dӵng căn bҧn cӫa mình. Mӝt khi đã có các
khӕi xây dӵng đó, bҥn có thӇ chҳp ráp chúng lҥi vӟi nhau đӇ tҥo lâu đài. Tương tӵ như
vұy mӝt khi đã xây dӵng mӝt sӕ đӕi tưӧng căn bҧn trong thӃ giӟi máy tính, bҥn có thӇ
chҳp chúng lҥi vӟi nhau đӇ tҥo ӭng dөng cӫa mình.

Xin lҩy mӝt ví dө đơn giҧn: vҩn đӅ rút tiӅn mһt tҥi nhà băng. Các ³mүu gӛ³ thành phҫn ӣ
đây sӁ là ánh xҥ cӫa các đӕi tưӧng ngoài đӡi thӵc như tài khoҧn, nhân viên, khách hàng,
«Và ӭng dөng sӁ đưӧc sӁ đưӧc nhұn diӋn cũng như giҧi đáp xoay quanh các đӕi tưӧng
đó.

- ƯU ĐIӆM CӪA MÔ HÌNH HƯӞNG ĐӔI TƯӦNG:

.1- Tính tái sӱ dөng (Reusable)

Phương pháp phân tích và thiӃt kӃ hưӟng đӕi tưӧng thӵc hiӋn theo các thuұt ngӳ và khái
niӋm cӫa phҥm vi lĩnh vӵc ӭng dөng (tӭc là cӫa doanh nghiӋp hay đơn vӏ mà hӋ thӕng
tương lai cҫn phөc vө), nên nó tҥo sӵ tiӃp cұn tương ӭng giӳa hӋ thӕng và vҩn đӅ thӵc
ngoài đӡi. Trong ví dө bán xe ô tô, mӑi giai đoҥn phân tích thiӃt kӃ và thӵc hiӋn đӅu xoay
quanh các khái niӋm như khách hàng, nhân viên bán hàng, xe ô tô, « Vì quá trình phát
triӇn phҫn mӅm đӗng thӡi là quá trình cӝng tác cӫa khách hàng/ngưӡi dùng, nhà phân
tích, nhà thiӃt kӃ, nhà phát triӇn, chuyên gia lĩnh vӵc, chuyên gia kӻ thuұt, ... nên lӕi tiӃp
cұn này khiӃn cho viӋc giao tiӃp giӳa hӑ vӟi nhau đưӧc dӉ dàng hơn.

Mӝt trong nhӳng ưu điӇm quan trӑng bұc nhҩt cӫa phương pháp phân tích và thiӃt kӃ
hưӟng đӕi tưӧng là tính tái sӱ dөng: bҥn có thӇ tҥo các thành phҫn (đӕi tưӧng) mӝt lҫn và
dùng chúng nhiӅu lҫn sau đó. Giӕng như viӋc bҥn có thӇ tái sӱ dөng các khӕi xây dӵng
(hay bҧn sao cӫa nó ) trong mӝt toà lâu đài, mӝt ngôi nhà ӣ, mӝt con tàu vũ trө, bҥn cũng
có thӇ tái sӱ dөng các thành phҫn (đӕi tưӧng) căn bҧn trong các thiӃt kӃ hưӟng đӕi tưӧng
cũng như code cӫa mӝt hӋ thӕng kӃ toán, hӋ thӕng kiӇm kê, hoһc mӝt hӋ thӕng đһt hàng.

Vì các đӕi tưӧng đã đưӧc thӱ nghiӋm kӻ càng trong lҫn dùng trưӟc đó, nên khҧ năng tái
sӱ dөng đӕi tưӧng có tác dөng giҧm thiӇu lӛi và các khó khăn trong viӋc bҧo trì, giúp
tăng tӕc đӝ thiӃt kӃ và phát triӇn phҫn mӅm.

Phương pháp hưӟng đӕi tưӧng giúp chúng ta xӱ lý các vҩn đӅ phӭc tҥp trong phát triӇn
phҫn mӅm và tҥo ra các thӃ hӋ phҫn mӅm có khҧ năng thích ӭng và bӅn chҳc.

.2- Các giai đoҥn cӫa chu trình phát triӇn phҫn mӅm vӟi mô hình hưӟng đӕi
tưӧng:

Phân tích hưӟng đӕi tưӧng (Object Oriented Analysis - OOA):

Là giai đӑan phát triӇn mӝt mô hình chính xác và súc tích cӫa vҩn đӅ, có thành phҫn là
các đӕi tưӧng và khái niӋm đӡi thӵc, dӉ hiӇu đӕi vӟi ngưӡi sӱ dөng.

Trong giai đoҥn OOA, vҩn đӅ đưӧc trình bày bҵng các thuұt ngӳ tương ӭng vӟi các đӕi
tưӧng có thӵc. Thêm vào đó, hӋ thӕng cҫn phҧi đưӧc đӏnh nghĩa sao cho ngưӡi không
chuyên Tin hӑc có thӇ dӉ dàng hiӇu đưӧc.

Dӵa trên mӝt vҩn đӅ có sҹn, nhà phân tích cҫn ánh xҥ các đӕi tưӧng hay thӵc thӇ có thӵc
như khách hàng, ô tô, ngưӡi bán hàng, « vào thiӃt kӃ đӇ tҥo ra đưӧc bҧn thiӃt kӃ gҫn cұn
vӟi tình huӕng thӵc. Mô hình thiӃt kӃ sӁ chӭa các thӵc thӇ trong mӝt vҩn đӅ có thӵc và
giӳ nguyên các mүu hình vӅ cҩu trúc, quan hӋ cũng như hành vi cӫa chúng. Nói mӝt cách
khác, sӱ dөng phương pháp hưӟng đӕi tưӧng chúng ta có thӇ mô hình hóa các thӵc thӇ
thuӝc mӝt vҩn đӅ có thӵc mà vүn giӳ đưӧc cҩu trúc, quan hӋ cũng như hành vi cӫa chúng.

Đӕi vӟi ví dө mӝt phòng bán ô tô, giai đoҥn OOA sӁ nhұn biӃt đưӧc các thӵc thӇ như:

- Khách hàng

- Ngưӡi bán hàng

- PhiӃu đһt hàng

- PhiӃu (hoá đơn) thanh toán

- Xe ô tô

Tương tác và quan hӋ giӳa các đӕi tưӧng trên là:

- Ngưӡi bán hàng dүn khách hàng tham quan phòng trưng bày xe.

- Khách hàng chӑn mӝt chiӃc xe

 - Khách hàng viӃt phiӃu đһt xe

- Khách hàng trҧ tiӅn xe

- Xe ô tô đưӧc giao đӃn cho khách hàng

Đӕi vӟi ví dө nhà băng lҿ, giai đoҥn OOA sӁ nhұn biӃt đưӧc các thӵc thӇ như:

- Loҥi tài khoҧn: ATM (rút tiӅn tӵ đӝng), Savings (tiӃt kiӋm), Current (bình
thưӡng), Fixed (đҫu tư), ...

- Khách hàng

- Nhân viên

- Phòng máy tính.

Tương tác và quan hӋ giӳa các đӕi tưӧng trên:

- Mӝt khách hàng mӟi mӣ mӝt tài khoҧn tiӃt kiӋm

- ChuyӇn tiӅn tӯ tài khoҧn tiӃt kiӋm sang tài khoҧn đҫu tư

- ChuyӇn tiӅn tӯ tài khoҧn tiӃt kiӋm sang tài khoҧn ATM

Xin chú ý là ӣ đây, như đã nói, ta chú ý đӃn cҧ  khía cҥnh: thông tin và cách hoҥt đӝng
cӫa hӋ thӕng (tӭc là nhӳng gì có thӇ xҧy ra vӟi nhӳng thông tin đó).

Lӕi phân tích bҵng kiӇu ánh xҥ "đӡi thӵc´ vào máy tính như thӃ thұt sӵ là ưu điӇm lӟn
cӫa phương pháp hưӟng đӕi tưӧng.

ThiӃt kӃ hưӟng đӕi tưӧng (Object Oriented Design - OOD):

Là giai đoҥn tә chӭc chương trình thành các tұp hӧp đӕi tưӧng cӝng tác, mӛi đӕi tưӧng
trong đó là thӵc thӇ cӫa mӝt lӟp. Các lӟp là thành viên cӫa mӝt cây cҩu trúc vӟi mӕi quan
hӋ thӯa kӃ.

Mөc đích cӫa giai đoҥn OOD là tҥo thiӃt kӃ dӵa trên kӃt quҧ cӫa giai đoҥn OOA, dӵa trên
nhӳng quy đӏnh phi chӭc năng, nhӳng yêu cҫu vӅ môi trưӡng, nhӳng yêu cҫu vӅ khҧ năng
thӵc thi, .... OOD tұp trung vào viӋc cҧi thiӋn kӃt quҧ cӫa OOA, tӕi ưu hóa giҧi pháp đã
đưӧc cung cҩp trong khi vүn đҧm bҧo thoҧ mãn tҩt cҧ các yêu cҫu đã đưӧc xác lұp.

Trong giai đoҥn OOD, nhà thiӃt kӃ đӏnh nghĩa các chӭc năng, thӫ tөc (operations), thuӝc
tính (attributes) cũng như mӕi quan hӋ cӫa mӝt hay nhiӅu lӟp (class) và quyӃt đӏnh chúng
cҫn phҧi đưӧc điӅu chӍnh sao cho phù hӧp vӟi môi trưӡng phát triӇn. Đây cũng là giai
đoҥn đӇ thiӃt kӃ ngân hàng dӳ liӋu và áp dөng các kӻ thuұt tiêu chuҭn hóa.
VӅ cuӕi giai đoҥn OOD, nhà thiӃt kӃ đưa ra mӝt loҥt các biӇu đӗ (diagram) khác nhau.
Các biӇu đӗ này có thӇ đưӧc chia thành hai nhóm chính là Tĩnh và đӝng. Các biӇu đӗ tĩnh
biӇu thӏ các lӟp và đӕi tưӧng, trong khi biӇu đӗ đӝng biӇu thӏ tương tác giӳa các lӟp và
phương thӭc hoҥt đӝng chính xác cӫa chúng. Các lӟp đó sau này có thӇ đưӧc nhóm thành
các gói (Packages) tӭc là các đơn vӏ thành phҫn nhӓ hơn cӫa ӭng dөng.

Lұp trình hưӟng đӕi tưӧng (Object Oriented Programming - OOP):

Giai đoҥn xây dӵng phҫn mӅm có thӇ đưӧc thӵc hiӋn sӱ dөng kӻ thuұt lұp trình
hưӟng đӕi tưӧng. Đó là phương thӭc thӵc hiӋn thiӃt kӃ hưӟng đӕi tưӧng qua viӋc sӱ dөng
mӝt ngôn ngӳ lұp trình có hӛ trӧ các tính năng hưӟng đӕi tưӧng. Mӝt vài ngôn ngӳ
hưӟng đӕi tưӧng thưӡng đưӧc nhҳc tӟi là C++ và Java. KӃt quҧ chung cuӝc cӫa giai đoҥn
này là mӝt loҥt các code chҥy đưӧc, nó chӍ đưӧc đưa vào sӱ dөng sau khi đã trҧi qua
nhiӅu vòng quay cӫa nhiӅu bưӟc thӱ nghiӋm khác nhau.

PHҪN CÂU HӒI

Hӓi: Mӝt sӕ tұp hӧp dӳ liӋu phӭc tҥp nhҩt đӏnh khi đưӧc trình bày bҵng đӗ thӏ sӁ truyӅn
tҧi đӃn ngưӡi đӑc nhiӅu thông tin hơn so vӟi các dӳ liӋu thô?

Đáp: Đúng

Hӓi: Mô hình giúp chúng ta tә chӭc, trình bày trӵc quan, thҩu hiӇu và tҥo nên các hӋ
thӕng phӭc tҥp.

Đáp: Đúng

Hӓi: Ưu điӇm lӟn nhҩt cӫa mô hình hưӟng đӕi tưӧng là tính tái sӱ dөng (Reusable)?

Đáp: Đúng.

›››
 Chương 2: NGÔN NGӲ MÔ HÌNH HOÁ THӔNG NHҨT LÀ GÌ

›››

1- GIӞI THIӊU UML:

1.1- Mô hình hóa hӋ thӕng phҫn mӅm:

Như đã trình bày ӣ phҫn trưӟc, mөc tiêu cӫa giai đoҥn phân tích hӋ thӕng là sҧn xuҩt ra
mӝt mô hình tәng thӇ cӫa hӋ thӕng cҫn xây dӵng. Mô hình này cҫn phҧi đưӧc trình bày
theo hưӟng nhìn (View) cӫa khách hàng hay ngưӡi sӱ dөng và làm sao đӇ hӑ hiӇu đưӧc.
Mô hình này cũng có thӇ đưӧc sӱ dөng đӇ xác đӏnh các yêu cҫu cӫa ngưӡi dùng đӕi vӟi
hӋ thӕng và qua đó giúp chúng ta đánh giá tính khҧ thi cӫa dӵ án.

Tҫm quan trӑng cӫa mô hình đã đưӧc lĩnh hӝi mӝt cách thҩu đáo trong hҫu như tҩt cҧ các
ngành khoa hӑc kӻ thuұt tӯ nhiӅu thӃ kӹ nay. Bҩt kǤ ӣ đâu, khi muӕn xây dӵng mӝt vұt
thӇ nào đó, đҫu tiên ngưӡi ta đã tҥo nên các bҧn vӁ đӇ quyӃt đӏnh cҧ ngoҥi hình lүn
phương thӭc hoҥt đӝng cӫa nó. Chҷng hҥn các bҧn vӁ kӻ thuұt thưӡng gһp là mӝt dҥng
mô hình quen thuӝc. Mô hình nhìn chung là mӝt cách mô tҧ cӫa mӝt vұt thӇ nào đó. Vұt
đó có thӇ tӗn tҥi trong mӝt sӕ giai đoҥn nhҩt đӏnh, dù đó là giai đoҥn thiӃt kӃ hay giai
đoҥn xây dӵng hoһc chӍ là mӝt kӃ hoҥch. Nhà thiӃt kӃ cҫn phҧi tҥo ra các mô hình mô tҧ
tҩt cҧ các khía cҥnh khác nhau cӫa sҧn phҭm. Ngoài ra, mӝt mô hình có thӇ đưӧc chia
thành nhiӅu hưӟng nhìn, mӛi hưӟng nhìn trong sӕ chúng sӁ mô tҧ mӝt khía cҥnh riêng
biӋt cӫa sҧn phҭm hay hӋ thӕng cҫn đưӧc xây dӵng. Mӝt mô hình cũng có thӇ đưӧc xây
dӵng trong nhiӅu giai đoҥn và ӣ mӛi giai đoҥn, mô hình sӁ đưӧc bә sung thêm mӝt sӕ chi
tiӃt nhҩt đӏnh.

Mô hình thưӡng đưӧc mô tҧ trong ngôn ngӳ trӵc quan, điӅu đó có nghĩa là đa phҫn các
thông tin đưӧc thӇ hiӋn bҵng các ký hiӋu đӗ hӑa và các kӃt nӕi giӳa chúng, chӍ khi cҫn
thiӃt mӝt sӕ thông tin mӟi đưӧc biӇu diӉn ӣ dҥng văn bҧn; Theo đúng như câu ngҥn ngӳ
"Mӝt bӭc tranh nói nhiӅu hơn cҧ ngàn tӯ". Tҥo mô hình cho các hӋ thӕng phҫn mӅm
trưӟc khi thӵc sӵ xây dӵng nên chúng, đã trӣ thành mӝt chuҭn mӵc trong viӋc phát triӇn
phҫn mӅm và đưӧc chҩp nhұn trong cӝng đӗng làm phҫn mӅm giӕng như trong bҩt kǤ
mӝt ngành khoa hӑc kӻ thuұt nào khác. ViӋc biӇu diӉn mô hình phҧi thoã mãn các yӃu tӕ
sau:

- Chính xác (accurate): Mô tҧ đúng hӋ thӕng cҫn xây dӵng.

- Đӗng nhҩt (consistent): Các view khác nhau không đưӧc mâu thuҭn vӟi nhau.

- Có thӇ hiӇu đưӧc (understandable): Cho nhӳng ngưӡi xây dӵng lүn sӱ dөng

- DӉ thay đәi (changeable)

- DӉ dàng liên lҥc vӟi các mô hình khác.

Có thӇ nói thêm rҵng mô hình là mӝt sӵ đơn giҧn hoá hiӋn thӵc. Mô hình đưӧc xây dӵng
nên đӇ chúng ta dӉ dàng hiӇu và hiӇu tӕt hơn hӋ thӕng cҫn xây dӵng. Tҥo mô hình sӁ giúp
cho chúng ta hiӇu thҩu đáo mӝt hӋ thӕng phӭc tҥp trong sӵ toàn thӇ cӫa nó.

Nói tóm lҥi, mô hình hóa mӝt hӋ thӕng nhҵm mөc đích:

- Hình dung mӝt hӋ thӕng theo thӵc tӃ hay theo mong muӕn cӫa chúng ta .

- ChӍ rõ cҩu trúc hoһc ӭng xӱ cӫa hӋ thӕng.

- Tҥo mӝt khuôn mүu hưӟng dүn nhà phát triӇn trong suӕt quá trình xây dӵng hӋ
thӕng.

- Ghi lҥi các quyӃt đӏnh cӫa nhà phát triӇn đӇ sӱ dөng sau này.

1.2- Trưӟc khi UML ra đӡi:

Đҫu nhӳng năm 1980, ngành công nghӋ phҫn mӅm chӍ có duy nhҩt mӝt ngôn ngӳ hưӟng
đӕi tưӧng là Simula. Sang nӱa sau cӫa thұp kӹ 1980, các ngôn ngӳ hưӟng đӕi tưӧng như
Smalltalk và C++ xuҩt hiӋn. Cùng vӟi chúng, nҧy sinh nhu cҫu mô hình hoá các hӋ thӕng
phҫn mӅm theo hưӟng đӕi tưӧng. Và mӝt vài trong sӕ nhӳng ngôn ngӳ mô hình hoá xuҩt
hiӋn nhӳng năm đҫu thұp kӹ 90 đưӧc nhiӅu ngưӡi dùng là:

- Grady Booch¶s Booch Modeling Methodology

- James Rambaugh¶s Object Modeling Technique ± OMT

- Ivar Jacobson¶s OOSE Methodology

- Hewlett- Packard¶s Fusion

- Coad and Yordon¶s OOA and OOD

Mӛi phương pháp luұn và ngôn ngӳ trên đӅu có hӋ thӕng ký hiӋu riêng, phương pháp xӱ
lý riêng và công cө hӛ trӧ riêng, khiӃn nҧy ra cuӝc tranh luұn phương pháp nào là tӕt
nhҩt. Đây là cuӝc tranh luұn khó có câu trҧ lӡi, bӣi tҩt cҧ các phương pháp trên đӅu có
nhӳng điӇm mҥnh và điӇm yӃu riêng. Vì thӃ, các nhà phát triӇn phҫn mӅm nhiӅu kinh
nghiӋm thưӡng sӱ dөng phӕi hӧp các điӇm mҥnh cӫa mӛi phương pháp cho ӭng dөng cӫa
mình. Trong thӵc tӃ, sӵ khác biӋt giӳa các phương pháp đó hҫu như không đáng kӇ và
theo cùng tiӃn trình thӡi gian, tҩt cҧ nhӳng phương pháp trên đã tiӋm cұn lҥi và bә sung
lүn cho nhau. Chính hiӋn thӵc này đã đưӧc nhӳng ngưӡi tiên phong trong lĩnh vӵc mô
hình hoá hưӟng đӕi tưӧng nhұn ra và hӑ quyӃt đӏnh ngӗi lҥi cùng nhau đӇ tích hӧp nhӳng
điӇm mҥnh cӫa mӛi phương pháp và đưa ra mӝt mô hình thӕng nhҩt cho lĩnh vӵc công
nghӋ phҫn mӅm.

1.3- Sӵ ra đӡi cӫa UML:

Trong bӕi cҧnh trên, ngưӡi ta nhұn thҩy cҫn thiӃt phҧi cung cҩp mӝt phương pháp tiӋm
cұn đưӧc chuҭn hoá và thӕng nhҩt cho viӋc mô hình hoá hưӟng đӕi tưӧng. Yêu cҫu cө thӇ
là đưa ra mӝt tұp hӧp chuҭn hoá các ký hiӋu (Notation) và các biӇu đӗ (Diagram) đӇ nҳm
bҳt các quyӃt đӏnh vӅ mһt thiӃt kӃ mӝt cách rõ ràng, rành mҥch. Đã có ba công trình tiên
phong nhҳm tӟi mөc tiêu đó, chúng đưӧc thӵc hiӋn dưӟi sӵ lãnh đҥo cӫa James
Rumbaugh, Grady Booch và Ivar Jacobson. Chính nhӳng cӕ gҳng này dүn đӃn kӃt quҧ là
xây dӵng đưӧc mӝt Ngôn Ngӳ Mô Hình Hoá Thӕng Nhҩt (Unifield Modeling Language
± UML).

UML là mӝt ngôn ngӳ mô hình hoá thӕng nhҩt có phҫn chính bao gӗm nhӳng ký hiӋu
hình hӑc, đưӧc các phương pháp hưӟng đӕi tưӧng sӱ dөng đӇ thӇ hiӋn và miêu tҧ các
thiӃt kӃ cӫa mӝt hӋ thӕng. Nó là mӝt ngôn ngӳ đӇ đһc tҧ, trӵc quan hoá, xây dӵng và làm
sưu liӋu cho nhiӅu khía cҥnh khác nhau cӫa mӝt hӋ thӕng có nӗng đӝ phҫn mӅm cao.
UML có thӇ đưӧc sӱ dөng làm công cө giao tiӃp giӳa ngưӡi dùng, nhà phân tích, nhà
thiӃt kӃ và nhà phát triӇn phҫn mӅm.

Trong quá trình phát triӇn có nhiӅu công ty đã hӛ trӧ và khuyӃn khích phát triӇn UML có
thӇ kӇ tӟi như : Hewlett Packard, Microsoft, Oracle, IBM, Unisys.

1.- UML (Unifield Modeling Language):

Ngôn ngӳ mô hình hóa thӕng nhҩt (Unifield Modeling Language ± UML) là mӝt ngôn
ngӳ đӇ biӇu diӉn mô hình theo hưӟng đӕi tưӧng đưӧc xây dӵng bӣi ba tác giҧ trên vӟi
chӫ đích là:

- Mô hình hoá các hӋ thӕng sӱ dөng các khái niӋm hưӟng đӕi tưӧng.

- ThiӃt lұp mӝt kӃt nӕi tӯ nhұn thӭc cӫa con ngưӡi đӃn các sӵ kiӋn cҫn mô hình
hoá.

- Giҧi quyӃt vҩn đӅ vӅ mӭc đӝ thӯa kӃ trong các hӋ thӕng phӭc tҥp, có nhiӅu ràng
buӝc khác nhau.

- Tҥo mӝt ngôn ngӳ mô hình hoá có thӇ sӱ dөng đưӧc bӣi ngưӡi và máy.

1.5- Phương pháp và các ngôn ngӳ mô hình hoá:

Phương pháp hay phương thӭc (method) là mӝt cách trӵc tiӃp cҩu trúc hoá sӵ suy nghĩ và
hành đӝng cӫa con ngưӡi. Phương pháp cho ngưӡi sӱ dөng biӃt phҧi làm gì, làm như thӃ
nào, khi nào và tҥi sao (mөc đích cӫa hành đӝng). Phương pháp chӭa các mô hình
(model), các mô hình đưӧc dùng đӇ mô tҧ nhӳng gì sӱ dөng cho viӋc truyӅn đҥt kӃt quҧ
trong quá trình sӱ dөng phương pháp. ĐiӇm khác nhau chính giӳa mӝt phương pháp và
mӝt ngôn ngӳ mô hình hoá (modeling language) là ngôn ngӳ mô hình hoá không có mӝt
tiӃn trình (process) hay các câu lӋnh (instruction) mô tҧ nhӳng công viӋc ngưӡi sӱ dөng
cҫn làm.
Mӝt mô hình đưӧc biӇu diӉn theo mӝt ngôn ngӳ mô hình hoá. Ngôn ngӳ mô hình hoá bao
gӗm các ký hiӋu ± nhӳng biӇu tưӧng đưӧc dùng trong mô hình ± và mӝt tұp các quy tҳc
chӍ cách sӱ dөng chúng. Các quy tҳc này bao gӗm:

- Syntactic (Cú pháp): cho biӃt hình dҥng các biӇu tưӧng và cách kӃt hӧp chúng
trong ngôn ngӳ.

- Semantic (Ngӳ nghĩa): cho biӃt ý nghĩa cӫa mӛi biӇu tưӧng, chúng đưӧc hiӇu
thӃ nào khi nҵm trong hoһc không nҵm trong ngӳ cҧnh cӫa các biӇu tưӧng khác.

- Pragmatic : đӏnh nghĩa ý nghĩa cӫa biӇu tưӧng đӇ sao cho mөc đích cӫa mô hình
đưӧc thӇ hiӋn và mӑi ngưӡi có thӇ hiӇu đưӧc.

2- UML TRONG PHÂN TÍCH THIӂT Kӂ Hӊ THӔNG:

UML có thӇ đưӧc sӱ dөng trong nhiӅu giai đoҥn, tӯ phát triӇn, thiӃt kӃ cho tӟi thӵc hiӋn
và bҧo trì. Vì mөc đích chính cӫa ngôn ngӳ này là dùng các biӇu đӗ hưӟng đӕi tưӧng đӇ
mô tҧ hӋ thӕng nên miӅn ӭng dөng cӫa UML bao gӗm nhiӅu loҥi hӋ thӕng khác nhau
như:

- HӋ thӕng thӕng tin (Information System): Cҩt giӳ, lҩy, biӃn đәi biӇu diӉn thông
tin cho ngưӡi sӱ dөng. Xӱ lý nhӳng khoҧng dӳ liӋu lӟn có các quan hӋ phӭc tҥp , mà
chúng đưӧc lưu trӳ trong các cơ sӣ dӳ liӋu quan hӋ hay hưӟng đӕi tưӧng .

- HӋ thӕng kӻ thuұt (Technical System): Xӱ lý và điӅu khiӇn các thiӃt bӏ kӻ thuұt

như viӉn thông, hӋ thӕng quân sӵ, hay các quá trình công nghiӋp. Đây là loҥi thiӃt bӏ phҧi
xӱ lý các giao tiӃp đһc biӋt , không có phҫn mӅm chuҭn và thưӡng là các hӋ thӕng thӡi
gian thӵc (real time).

- HӋ thӕng nhúng (Embeded System): Thӵc hiӋn trên phҫn cӭng gҳn vào các
thiӃt bӏ như điӋn thoҥi di đӝng, điӅu khiӇn xe hơi, « ĐiӅu này đưӧc thӵc hiӋn bҵng viӋc
lұp trình mӭc thҩp vӟi hӛ trӧ thӡi gian thӵc. Nhӳng hӋ thӕng này thưӡng không có các
thiӃt bӏ như màn hình đĩa cӭng, «

- HӋ thӕng phân bӕ ( Distributed System): Đưӧc phân bӕ trên mӝt sӕ máy cho
phép truyӅn dӳ liӋu tӯ nơi này đӃn nơi khác mӝt cách dӉ dàng. Chúng đòi hӓi các cơ chӃ
liên lҥc đӗng bӝ đӇ đҧm bҧo toàn vҽn dӳ liӋu và thưӡng đưӧc xây dӵng trên mӝt sӕ các
kӻ thuұt đӕi tưӧng như CORBA, COM/DCOM, hay Java Beans/RMI.

- HӋ thӕng Giao dӏch (Business System): Mô tҧ mөc đích, tài nguyên (con ngưӡi,
máy tính, «), các quy tҳc (luұt pháp, chiӃn thuұt kinh doanh, cơ chӃ, «), và công viӋc
hoҥt đӝng kinh doanh.

- Phҫn mӅm hӋ thӕng (System Software): Đӏnh nghĩa cơ sӣ hҥ tҫng kӻ thuұt cho
phҫn mӅm khác sӱ dөng, chҷng hҥn như hӋ điӅu hành, cơ sӣ dӳ liӋu, giao diӋn ngưӡi sӱ
dөng.
3- UML VÀ CÁC GIAI ĐOҤN PHÁT TRIӆN Hӊ THӔNG
Preliminary Investigation: use cases thӇ hiӋn các yêu cҫu cӫa ngưӡi dùng. Phҫn miêu tҧ
use case xác đӏnh các yêu cҫu, phҫn diagram thӇ hiӋn mӕi quan hӋ và giao tiӃp vӟi hӋ
thӕng.

Analysis: Mөc đích chính cӫa giai đӑan này là trӯu tưӧng hóa và tìm hiӇu các cơ cҩu có
trong phҥm vi bài toán. Class diagrams trên bình diӋn trӯu tưӧng hóa các thӵc thӇ ngoài
đӡi thӵc đưӧc sӱ dөng đӇ làm rõ sӵ tӗn tҥi cũng như mӕi quan hӋ cӫa chúng. ChӍ nhӳng
lӟp (class) nҵm trong phҥm vi bài toán mӟi đáng quan tâm.

Design: KӃt quҧ phҫn analysis đưӧc phát triӇn thành giҧi pháp kӻ thuұt. Các lӟp đưӧc mô
hình hóa chi tiӃt đӇ cung cҩp hҥ tҫng kӻ thuұt như giao diӋn, nӅn tҧng cho database, «
KӃt quҧ phҫn Design là các đһc tҧ chi tiӃt cho giai đoҥn xây dӵng phҫn mӅm.

Development: Mô hình Design đưӧc chuyӇn thành code. Programmer sӱ dөng các UML
diagrams trong giai đoҥn Design đӇ hiӇu vҩn đӅ và tҥo code.

Testing: Sӱ dөng các UML diagrams trong các giai đoҥn trưӟc. Có 4 hình thӭc kiӇm tra
hӋ thӕng:

u
  (class diagrams & class specifications) : kiӇm tra tӯng đơn thӇ, đưӧc
dùng đӇ kiӇm tra các lӟp hay các nhóm đơn thӇ.

u 
  (integration diagrams & collaboration diagrams) : kiӇm tra
tích hӧp là kiӇm tra kӃt hӧp các component vӟi các lӟp đӇ xem chúng hoҥt đӝng vӟi nhau
có đúng không.

-    (use-case diagrams) : kiӅm tra xem hӋ thӕng có đáp ӭng đưӧc
chӭc năng mà ngưӡi sӱ dөng yêu cҫu hay không.

u 
 : KiӇm tra tính chҩp nhұn đưӧc cӫa hӋ thӕng, thưӡng đưӧc
thӵc hiӋn bӣi khách hàng, viӋc kiӇm tra này thӵc hiӋn tương tӵ như kiӇm tra hӋ thӕng.

PHҪN CÂU HӒI

Hӓi: UML (Unifield Modeling Language) là gì?

Đáp: Ngôn ngӳ mô hình hóa thӕng nhҩt ± UML là mӝt ngôn ngӳ đӇ biӇu diӉn mô hình
theo hưӟng đӕi tưӧng.

Hӓi: ĐiӇm khác nhau cơ bҧn giӳa phương pháp (method) và mӝt ngôn ngӳ mô hình hoá
(modeling language) là gì?
Đáp: ĐiӇm khác nhau cơ bҧn giӳa mӝt phương pháp và mӝt ngôn ngӳ mô hình hoá là
ngôn ngӳ mô hình hoá không có mӝt tiӃn trình (process) hay các câu lӋnh (instruction)
mô tҧ nhӳng công viӋc ngưӡi sӱ dөng cҫn làm mà nó bao gӗm các ký hiӋu ± nhӳng biӇu
tưӧng đưӧc dùng trong mô hình ± và mӝt tұp các quy tҳc chӍ cách sӱ dөng chúng.

›››
 Chương 3: KHÁI QUÁT Vӄ UML

›››

1- UML VÀ CÁC GIAI ĐOҤN CӪA CHU TRÌNH PHÁT TRIӆN

PHҪN MӄM

1.1- Giai đoҥn nghiên cӭu sơ bӝ:

UML đưa ra khái niӋm Use Case đӇ nҳm bҳt các yêu cҫu cӫa khách hàng (ngưӡi sӱ
dөng). UML sӱ dөng biӇu đӗ Use case (Use Case Diagram) đӇ nêu bұt mӕi quan hӋ cũng
như sӵ giao tiӃp vӟi hӋ thӕng.

Qua phương pháp mô hình hóa Use case, các tác nhân (Actor) bên ngoài quan tâm đӃn hӋ
thӕng sӁ đưӧc mô hình hóa song song vӟi chӭc năng mà hӑ đòi hӓi tӯ phía hӋ thӕng (tӭc
là Use case). Các tác nhân và các Use case đưӧc mô hình hóa cùng các mӕi quan hӋ và
đưӧc miêu tҧ trong biӇu đӗ Use case cӫa UML. Mӛi mӝt Use case đưӧc mô tҧ trong tài
liӋu, và nó sӁ đһc tҧ các yêu cҫu cӫa khách hàng: Anh ta hay chӏ ta chӡ đӧi điӅu gì ӣ phía
hӋ thӕng mà không hӅ đӇ ý đӃn viӋc chӭc năng này sӁ đưӧc thӵc thi ra sao.

1.2- Giai đoҥn phân tích:

Giai đoҥn phân tích quan tâm đӃn quá trình trӯu tưӧng hóa đҫu tiên (các lӟp và các đӕi
tưӧng) cũng như cơ chӃ hiӋn hӳu trong phҥm vi vҩn đӅ. Sau khi nhà phân tích đã nhұn
biӃt đưӧc các lӟp thành phҫn cӫa mô hình cũng như mӕi quan hӋ giӳa chúng vӟi nhau,
các lӟp cùng các mӕi quan hӋ đó sӁ đưӧc miêu tҧ bҵng công cө biӇu đӗ lӟp (class
diagram) cӫa UML. Sӵ cӝng tác giӳa các lӟp nhҵm thӵc hiӋn các Use case cũng sӁ đưӧc
miêu tҧ nhӡ vào các mô hình đӝng (dynamic models) cӫa UML. Trong giai đoҥn phân
tích, chӍ duy nhҩt các lӟp có tӗn tҥi trong phҥm vi vҩn đӅ (các khái niӋm đӡi thӵc) là
đưӧc mô hình hóa. Các lӟp kӻ thuұt đӏnh nghĩa chi tiӃt cũng như giҧi pháp trong hӋ thӕng
phҫn mӅm, ví dө như các lӟp cho giao diӋn ngưӡi dùng, cho ngân hàng dӳ liӋu, cho sӵ
giao tiӃp, trùng hӧp, v.v..., chưa phҧi là mӕi quan tâm cӫa giai đoҥn này.

1.3- Giai đoҥn thiӃt kӃ:

Trong giai đoҥn này, kӃt quҧ cӫa giai đoҥn phân tích sӁ đưӧc mӣ rӝng thành mӝt giҧi
pháp kӻ thuұt. Các lӟp mӟi sӁ đưӧc bә sung đӇ tҥo thành mӝt hҥ tҫng cơ sӣ kӻ thuұt:
Giao diӋn ngưӡi dùng, các chӭc năng đӇ lưu trӳ các đӕi tưӧng trong ngân hàng dӳ liӋu,
giao tiӃp vӟi các hӋ thӕng khác, giao diӋn vӟi các thiӃt bӏ ngoҥi vi và các máy móc khác
trong hӋ thӕng, .... Các lӟp thuӝc phҥm vi vҩn đӅ có tӯ giai đoҥn phân tích sӁ đưӧc
"nhúng" vào hҥ tҫng cơ sӣ kӻ thuұt này, tҥo ra khҧ năng thay đәi trong cҧ hai phương
diӋn: Phҥm vi vҩn đӅ và hҥ tҫng cơ sӣ. Giai đoҥn thiӃt kӃ sӁ đưa ra kӃt quҧ là bҧn đһc tҧ
chi tiӃt cho giai đoҥn xây dӵng hӋ thӕng.

1.- Giai đoҥn xây dӵng:

Trong giai đoҥn xây dӵng (giai đoҥn lұp trình), các lӟp cӫa giai đoҥn thiӃt kӃ sӁ đưӧc
biӃn thành nhӳng dòng code cө thӇ trong mӝt ngôn ngӳ lұp trình hưӟng đӕi tưӧng cө thӇ
(không nên dùng mӝt ngôn ngӳ lұp trình hưӟng chӭc năng!). Phө thuӝc vào khҧ năng cӫa
ngôn ngӳ đưӧc sӱ dөng, đây có thӇ là mӝt công viӋc khó khăn hay dӉ dàng. Khi tҥo ra
các mô hình phân tích và thiӃt kӃ trong UML, tӕt nhҩt nên cӕ gҳng né tránh viӋc ngay lұp
tӭc biӃn đәi các mô hình này thành các dòng code. Trong nhӳng giai đoҥn trưӟc, mô hình
đưӧc sӱ dөng đӇ dӉ hiӇu, dӉ giao tiӃp và tҥo nên cҩu trúc cӫa hӋ thӕng; vì vұy, vӝi vàng
đưa ra nhӳng kӃt luұn vӅ viӋc viӃt code có thӇ sӁ thành mӝt trӣ ngҥi cho viӋc tҥo ra các
mô hình chính xác và đơn giҧn. Giai đoҥn xây dӵng là mӝt giai đoҥn riêng biӋt, nơi các
mô hình đưӧc chuyӇn thành code.

1.5- Thӱ nghiӋm:

Như đã trình bày trong phҫn Chu Trình Phát TriӇn Phҫn MӅm, mӝt hӋ thӕng phҫn mӅm
thưӡng đưӧc thӱ nghiӋm qua nhiӅu giai đoҥn và vӟi nhiӅu nhóm thӱ nghiӋm khác nhau.
Các nhóm sӱ dөng nhiӅu loҥi biӇu đӗ UML khác nhau làm nӅn tҧng cho công viӋc cӫa
mình: Thӱ nghiӋm đơn vӏ sӱ dөng biӇu đӗ lӟp (class diagram) và đһc tҧ lӟp, thӱ nghiӋm
tích hӧp thưӡng sӱ dөng biӇu đӗ thành phҫn (component diagram) và biӇu đӗ cӝng tác
(collaboration diagram), và giai đoҥn thӱ nghiӋm hӋ thӕng sӱ dөng biӇu đӗ Use case (use
case diagram) đӇ đҧm bҧo hӋ thӕng có phương thӭc hoҥt đӝng đúng như đã đưӧc đӏnh
nghĩa tӯ ban đҫu trong các biӇu đӗ này.

2- CÁC THÀNH PHҪN CӪA NGÔN NGӲ UML

Ngôn ngӳ UML bao gӗm mӝt loҥt các phҫn tӱ đӗ hӑa (graphic element) có thӇ đưӧc kӃp
hӧp vӟi nhau đӇ tҥo ra các biӇu đӗ. Bӣi đây là mӝt ngôn ngӳ, nên UML cũng có các
nguyên tҳc đӇ kӃt hӧp các phҫn tӱ đó.

Mӝt sӕ nhӳng thành phҫn chӫ yӃu cӫa ngôn ngӳ UML:

÷
   Hưӟng nhìn chӍ ra nhӳng khía cҥnh khác nhau cӫa hӋ thӕng
cҫn phҧi đưӧc mô hình hóa. Mӝt hưӟng nhìn không phҧi là mӝt bҧn vӁ, mà là mӝt sӵ trӯu
tưӧng hóa bao gӗm mӝt loҥt các biӇu đӗ khác nhau. ChӍ qua viӋc đӏnh nghĩa cӫa mӝt loҥt
các hưӟng nhìn khác nhau, mӛi hưӟng nhìn chӍ ra mӝt khía cҥnh riêng biӋt cӫa hӋ thӕng,
ngưӡi ta mӟi có thӇ tҥo dӵng nên mӝt bӭc tranh hoàn thiӋn vӅ hӋ thӕng. Cũng chính các
hưӟng nhìn này nӕi kӃt ngôn ngӳ mô hình hóa vӟi quy trình đưӧc chӑn cho giai đoҥn
phát triӇn.

      BiӇu đӗ là các hình vӁ miêu tҧ nӝi dung trong mӝt hưӟng
nhìn. UML có tҩt cҧ 9 loҥi biӇu đӗ khác nhau đưӧc sӱ dөng trong nhӳng sӵ kӃt hӧp khác
nhau đӇ cung cҩp tҩt cҧ các hưӟng nhìn cӫa mӝt hӋ thӕng.

 Y    !!Y Các khái niӋm đưӧc sӱ dөng trong các
biӇu đӗ đưӧc gӑi là các phҫn tӱ mô hình, thӇ hiӋn các khái niӋm hưӟng đӕi tưӧng quen
thuӝc. Ví dө như lӟp, đӕi tưӧng, thông điӋp cũng như các quan hӋ giӳa các khái niӋm
này, bao gӗm cҧ liên kӃt, phө thuӝc, khái quát hóa. Mӝt phҫn tӱ mô hình thưӡng đưӧc sӱ
dөng trong nhiӅu biӇu đӗ khác nhau, nhưng nó luôn luôn có chӍ mӝt ý nghĩa và mӝt kí
hiӋu.

]   "   Cơ chӃ chung cung cҩp thêm nhӳng lӡi nhұn xét bә sung, các
thông tin cũng như các quy tҳc ngӳ pháp chung vӅ mӝt phҫn tӱ mô hình; chúng còn cung
cҩp thêm các cơ chӃ đӇ có thӇ mӣ rӝng ngôn ngӳ UML cho phù hӧp vӟi mӝt phương
pháp xác đӏnh (mӝt quy trình, mӝt tә chӭc hoһc mӝt ngưӡi dùng).

3- HƯӞNG NHÌN (VIEW)

Mô hình hóa mӝt hӋ thӕng phӭc tҥp là mӝt viӋc làm khó khăn. Lý tưӣng nhҩt là toàn bӝ
hӋ thӕng đưӧc miêu tҧ chӍ trong mӝt bҧn vӁ, mӝt bҧn vӁ đӏnh nghĩa mӝt cách rõ ràng và
mҥch lҥc toàn bӝ hӋ thӕng, mӝt bҧn vӁ ngoài ra lҥi còn dӉ giao tiӃp và dӉ hiӇu. Mһc dù
vұy, thưӡng thì đây là chuyӋn bҩt khҧ thi. Mӝt bҧn vӁ không thӇ nҳm bҳt tҩt cҧ các thông
tin cҫn thiӃt đӇ miêu tҧ mӝt hӋ thӕng. Mӝt hӋ thӕng cҫn phҧi đưӧc miêu tҧ vӟi mӝt loҥt
các khía cҥnh khác nhau: VӅ mһt chӭc năng (cҩu trúc tĩnh cӫa nó cũng như các tương tác
đӝng), vӅ mһt phi chӭc năng (yêu cҫu vӅ thӡi gian, vӅ đӝ đáng tin cұy, vӅ quá trình thӵc
thi, v.v. và v.v.) cũng như vӅ khía cҥnh tә chӭc (tә chӭc làm viӋc, ánh xҥ nó vào các code
module, ...). Vì vұy mӝt hӋ thӕng thưӡng đưӧc miêu tҧ trong mӝt loҥt các hưӟng nhìn
khác nhau, mӛi hưӟng nhìn sӁ thӇ hiӋn mӝt bӭc ҧnh ánh xҥ cӫa toàn bӝ hӋ thӕng và chӍ ra
mӝt khía cҥnh riêng cӫa hӋ thӕng.

Hình 3.1- Các View trong UML

Mӛi mӝt hưӟng nhìn đưӧc miêu tҧ trong mӝt loҥt các biӇu đӗ, chӭa đӵng các thông tin
nêu bұt khía cҥnh đһc biӋt đó cӫa hӋ thӕng. Trong thӵc tӃ khi phân tích và thiӃt kӃ rҩt dӉ
xҧy ra sӵ trùng lһp thông tin, cho nên mӝt biӇu đӗ trên thұt tӃ có thӇ là thành phҫn cӫa
nhiӅu hưӟng nhìn khác nhau. Khi nhìn hӋ thӕng tӯ nhiӅu hưӟng nhìn khác nhau, tҥi mӝt
thӡi điӇm có thӇ ngưӡi ta chӍ tұp trung vào mӝt khía cҥnh cӫa hӋ thӕng. Mӝt biӇu đӗ
trong mӝt hưӟng nhìn cө thӇ nào đó cҫn phҧi đӫ đӝ đơn giҧn đӇ tҥo điӅu kiӋn giao tiӃp dӉ
dàng, đӇ dính liӅn vӟi các biӇu đӗ khác cũng như các hưӟng nhìn khác, làm sao cho bӭc
tranh toàn cҧnh cӫa hӋ thӕng đưӧc miêu tҧ bҵng sӵ kӃt hӧp tҩt cҧ các thông tin tӯ tҩt cҧ
các hưӟng nhìn. Mӝt biӇu đӗ chӭa các kí hiӋu hình hӑc mô tҧ các phҫn tӱ mô hình cӫa hӋ
thӕng. UML có tҩt cҧ các hưӟng nhìn sau:

- Hưӟng nhìn Use case (use case view) : đây là hưӟng nhìn chӍ ra khía cҥnh chӭc
năng cӫa mӝt hӋ thӕng, nhìn tӯ hưӟng tác nhân bên ngoài.

- Hưӟng nhìn logic (logical view): chӍ ra chӭc năng sӁ đưӧc thiӃt kӃ bên trong hӋ
thӕng như thӃ nào, qua các khái niӋm vӅ cҩu trúc tĩnh cũng như ӭng xӱ đӝng cӫa hӋ
thӕng.

- Hưӟng nhìn thành phҫn (component view): chӍ ra khía cҥnh tә chӭc cӫa các
thành phҫn code.

- Hưӟng nhìn song song (concurrency view): chӍ ra sӵ tӗn tҥi song song/ trùng
hӧp trong hӋ thӕng, hưӟng đӃn vҩn đӅ giao tiӃp và đӗng bӝ hóa trong hӋ thӕng.

- Hưӟng nhìn triӇn khai (deployment view): chӍ ra khía cҥnh triӇn khai hӋ thӕng
vào các kiӃn trúc vұt lý (các máy tính hay trang thiӃt bӏ đưӧc coi là trҥm công tác).

Khi bҥn chӑn công cө đӇ vӁ biӇu đӗ, hãy chӑn công cө nào tҥo điӅu kiӋn dӉ dàng
chuyӇn tӯ hưӟng nhìn này sang hưӟng nhìn khác. Ngoài ra, cho mөc đích quan sát mӝt
chӭc năng sӁ đưӧc thiӃt kӃ như thӃ nào, công cө này cũng phҧi tҥo điӅu kiӋn dӉ dàng cho
bҥn chuyӇn sang hưӟng nhìn Use case (đӇ xem chӭc năng này đưӧc miêu tҧ như thӃ nào
tӯ phía tác nhân), hoһc chuyӇn sang hưӟng nhìn triӇn khai (đӇ xem chӭc năng này sӁ
đưӧc phân bӕ ra sao trong cҩu trúc vұt lý - Nói mӝt cách khác là nó có thӇ nҵm trong máy
tính nào).

Ngoài các hưӟng nhìn kӇ trên, ngành công nghiӋp phҫn mӅm còn sӱ dөng cҧ các hưӟng
nhìn khác, ví dө hưӟng nhìn tĩnh-đӝng, hưӟng nhìn logic-vұt lý, quy trình nghiӋp vө
(workflow) và các hưӟng nhìn khác. UML không yêu cҫu chúng ta phҧi sӱ dөng các
hưӟng nhìn này, nhưng đây cũng chính là nhӳng hưӟng nhìn mà các nhà thiӃt kӃ cӫa
UML đã nghĩ tӟi, nên có khҧ năng nhiӅu công cө sӁ dӵa trên các hưӟng nhìn đó.

3.1- Hưӟng nhìn Use case (Use case View):

Hưӟng nhìn Use case miêu tҧ chӭc năng cӫa hӋ thӕng sӁ phҧi cung cҩp do đưӧc tác nhân
tӯ bên ngoài mong đӧi. Tác nhân là thӵc thӇ tương tác vӟi hӋ thӕng; đó có thӇ là mӝt
ngưӡi sӱ dөng hoһc là mӝt hӋ thӕng khác. Hưӟng nhìn Use case là hưӟng nhìn dành cho
khách hàng, nhà thiӃt kӃ, nhà phát triӇn và ngưӡi thӱ nghiӋm; nó đưӧc miêu tҧ qua các
biӇu đӗ Use case (use case diagram) và thӍnh thoҧng cũng bao gӗm cҧ các biӇu đӗ hoҥt
đӝng (activity diagram). Cách sӱ dөng hӋ thӕng nhìn chung sӁ đưӧc miêu tҧ qua mӝt loҥt
các Use case trong hưӟng nhìn Use case, nơi mӛi mӝt Use case là mӝt lӡi miêu tҧ mang
tính đһc thù cho mӝt tính năng cӫa hӋ thӕng (có nghĩa là mӝt chӭc năng đưӧc mong đӧi).

Hưӟng nhìn Use case mang tính trung tâm, bӣi nó đһt ra nӝi dung thúc đҭy sӵ phát triӇn
các hưӟng nhìn khác. Mөc tiêu chung cӫa hӋ thӕng là cung cҩp các chӭc năng miêu tҧ
trong hưӟng nhìn này ± cùng vӟi mӝt vài các thuӝc tính mang tính phi chӭc năng khác ±
vì thӃ hưӟng nhìn này có ҧnh hưӣng đӃn tҩt cҧ các hưӟng nhìn khác. Hưӟng nhìn này
cũng đưӧc sӱ dөng đӇ thҭm tra (verify) hӋ thӕng qua viӋc thӱ nghiӋm xem hưӟng nhìn
Use case có đúng vӟi mong đӧi cӫa khách hàng (Hӓi: "Đây có phҧi là thӭ bҥn muӕn")
cũng như có đúng vӟi hӋ thӕng vӯa đưӧc hoàn thành (Hӓi: "HӋ thӕng có hoҥt đӝng như
đã đһc tҧ?´).

3.2- Hưӟng nhìn logic (Logical View):

Hưӟng nhìn logic miêu tҧ phương thӭc mà các chӭc năng cӫa hӋ thӕng sӁ đưӧc cung cҩp.
Chӫ yӃu nó đưӧc sӱ dөng cho các nhà thiӃt kӃ và nhà phát triӇn. Ngưӧc lҥi vӟi hưӟng
nhìn Use case, hưӟng nhìn logic nhìn vào phía bên trong cӫa hӋ thӕng. Nó miêu tҧ kӇ cҧ
cҩu trúc tĩnh (lӟp, đӕi tưӧng, và quan hӋ) cũng như sӵ tương tác đӝng sӁ xҧy ra khi các
đӕi tưӧng gӱi thông điӋp cho nhau đӇ cung cҩp chӭc năng đã đӏnh sҹn. Hưӟng nhìn logic
đӏnh nghĩa các thuӝc tính như trưӡng tӗn (persistency) hoһc song song (concurrency),
cũng như các giao diӋn cũng như cҩu trúc nӝi tҥi cӫa các lӟp.

Cҩu trúc tĩnh đưӧc miêu tҧ bҵng các biӇu đӗ lӟp (class diagram) và biӇu đӗ đӕi tưӧng
(object diagram). Quá trình mô hình hóa đӝng đưӧc miêu tҧ trong các biӇu đӗ trҥng thái
(state diagram), biӇu đӗ trình tӵ (sequence diagram), biӇu đӗ tương tác (collaboration
diagram) và biӇu đӗ hoҥt đӝng (activity diagram).

3.3- Hưӟng nhìn thành phҫn (Component View):

Là mӝt lӡi miêu tҧ cӫa viӋc thӵc thi các modul cũng như sӵ phө thuӝc giӳa chúng vӟi
nhau. Nó thưӡng đưӧc sӱ dөng cho nhà phát triӇn và thưӡng bao gӗm nhiӅu biӇu đӗ
thành phҫn. Thành phҫn ӣ đây là các modul lӋnh thuӝc nhiӅu loҥi khác nhau, sӁ đưӧc chӍ
ra trong biӇu đӗ cùng vӟi cҩu trúc cũng như sӵ phө thuӝc cӫa chúng. Các thông tin bә
sung vӅ các thành phҫn, ví dө như vӏ trí cӫa tài nguyên (trách nhiӋm đӕi vӟi mӝt thành
phҫn), hoһc các thông tin quҧn trӏ khác, ví dө như mӝt bҧn báo cáo vӅ tiӃn trình cӫa công
viӋc cũng có thӇ đưӧc bә sung vào đây.

3.- Hưӟng nhìn song song (Concurrency View):

Hưӟng nhìn song song nhҳm tӟi sӵ chia hӋ thӕng thành các qui trình (process) và các bӝ
xӱ lý (processor). Khía cҥnh này, vӕn là mӝt thuӝc tính phi chӭc năng cӫa hӋ thӕng, cho
phép chúng ta sӱ dөng mӝt cách hӳu hiӋu các nguӗn tài nguyên, thӵc thi song song, cũng
như xӱ lý các sӵ kiӋn không đӗng bӝ tӯ môi trưӡng. Bên cҥnh viӋc chia hӋ thӕng thành
các tiӇu trình có thӇ đưӧc thӵc thi song song, hưӟng nhìn này cũng phҧi quan tâm đӃn
vҩn đӅ giao tiӃp và đӗng bӝ hóa các tiӇu trình đó.

Hưӟng nhìn song song giành cho nhà phát triӇn và ngưӡi tích hӧp hӋ thӕng, nó bao gӗm
các biӇu đӗ đӝng (trҥng thái, trình tӵ, tương tác và hoҥt đӝng) cùng các biӇu đӗ thӵc thi
(biӇu đӗ thành phҫn và biӇu đӗ triӇn khai).

3.5- Hưӟng nhìn triӇn khai (Deployment View):

Cuӕi cùng, hưӟng nhìn triӇn khai chӍ cho chúng ta sơ đӗ triӇn khai vӅ mһt vұt lý cӫa hӋ
thӕng, ví dө như các máy tính cũng như các máy móc và sӵ liên kӃt giӳa chúng vӟi nhau.
Hưӟng nhìn triӇn khai giành cho các nhà phát triӇn, ngưӡi tích hӧp cũng như ngưӡi thӱ
nghiӋm hӋ thӕng và đưӧc thӇ hiӋn bҵng các biӇu đӗ triӇn khai. Hưӟng nhìn này cũng bao
gӗm sӵ ánh xҥ các thành phҫn cӫa hӋ thӕng vào cҩu trúc vұt lý; ví dө như chương trình
nào hay đӕi tưӧng nào sӁ đưӧc thӵc thi trên máy tính nào.

- BIӆU ĐӖ (DIAGRAM)

BiӇu đӗ là các hình vӁ bao gӗm các ký hiӋu phҫn tӱ mô hình hóa đưӧc sҳp xӃp đӇ minh
hӑa mӝt thành phҫn cө thӇ hay mӝt khía cҥnh cө thӇ cӫa hӋ thӕng. Mӝt mô hình hӋ thӕng
thưӡng có nhiӅu loҥi biӇu đӗ, mӛi loҥi có nhiӅu biӇu đӗ khác nhau. Mӝt biӇu đӗ là mӝt
thành phҫn cӫa mӝt hưӟng nhìn cө thӇ; và khi đưӧc vӁ ra, nó thưӡng thưӡng cũng đưӧc
xӃp vào mӝt hưӟng nhìn. Mһt khác, mӝt sӕ loҥi biӇu đӗ có thӇ là thành phҫn cӫa nhiӅu
hưӟng nhìn khác nhau, tùy thuӝc vào nӝi dung cӫa biӇu đӗ.

Phҫn sau miêu tҧ các khái niӋm căn bҧn nҵm đҵng sau mӛi loҥi biӇu đӗ. Tҩt cҧ các chi
tiӃt vӅ biӇu đӗ, ngӳ cҧnh cӫa chúng, ý nghĩa chính xác cӫa chúng và sӵ tương tác giӳa
chúng vӟi nhau đưӧc miêu tҧ chi tiӃt trong các chương sau (mô hình đӕi tưӧng ± mô hình
đӝng). Các biӇu đӗ lҩy làm ví dө ӣ đây đưӧc lҩy ra tӯ nhiӅu loҥi hӋ thӕng khác nhau đӇ
chӍ ra nét phong phú và khҧ năng áp dөng rӝng khҳp cӫa ULM.

.1- BiӇu đӗ Use case (Use Case Diagram):

Mӝt biӇu đӗ Use case chӍ ra mӝt sӕ lưӧng các tác nhân ngoҥi cҧnh và mӕi liên kӃt cӫa
chúng đӕi vӟi Use case mà hӋ thӕng cung cҩp (nhìn hình 3.2). Mӝt Use case là mӝt lӡi
miêu tҧ cӫa mӝt chӭc năng mà hӋ thӕng cung cҩp. Lӡi miêu tҧ Use case thưӡng là mӝt
văn bҧn tài liӋu, nhưng kèm theo đó cũng có thӇ là mӝt biӇu đӗ hoҥt đӝng. Các Use case
đưӧc miêu tҧ duy nhҩt theo hưӟng nhìn tӯ ngoài vào cӫa các tác nhân (hành vi cӫa hӋ
thӕng theo như sӵ mong đӧi cӫa ngưӡi sӱ dөng), không miêu tҧ chӭc năng đưӧc cung cҩp
sӁ hoҥt đӝng nӝi bӝ bên trong hӋ thӕng ra sao. Các Use case đӏnh nghĩa các yêu cҫu vӅ
mһt chӭc năng đӕi vӟi hӋ thӕng. Các biӇu đӗ Use case sӁ đưӧc miêu tҧ chi tiӃt hơn trong
chương 4 (Use case).
Hình 3.2- BiӇu đӗ use case cӫa mӝt công ty bҧo hiӇm

.2- BiӇu đӗ lӟp (Class Diagram):

Mӝt biӇu đӗ lӟp chӍ ra cҩu trúc tĩnh cӫa các lӟp trong hӋ thӕng (nhìn hình 3.3). Các lӟp là
đҥi diӋn cho các ³vұt´ đưӧc xӱ lý trong hӋ thӕng. Các lӟp có thӇ quan hӋ vӟi nhau trong
nhiӅu dҥng thӭc: liên kӃt (associated - đưӧc nӕi kӃt vӟi nhau), phө thuӝc (dependent -
mӝt lӟp này phө thuӝc vào lӟp khác), chuyên biӋt hóa (specialized - mӝt lӟp này là mӝt
kӃt quҧ chuyên biӋt hóa cӫa lӟp khác), hay đóng gói ( packaged - hӧp vӟi nhau thành mӝt
đơn vӏ). Tҩt cҧ các mӕi quan hӋ đó đӅu đưӧc thӇ hiӋn trong biӇu đӗ lӟp, đi kèm vӟi cҩu
trúc bên trong cӫa các lӟp theo khái niӋm thuӝc tính (attribute) và thӫ tөc (operation).
BiӇu đӗ đưӧc coi là biӇu đӗ tĩnh theo phương diӋn cҩu trúc đưӧc miêu tҧ ӣ đây có hiӋu
lӵc tҥi bҩt kǤ thӡi điӇm nào trong toàn bӝ vòng đӡi hӋ thӕng.

Mӝt hӋ thӕng thưӡng sӁ có mӝt loҥt các biӇu đӗ lӟp ± chҷng phҧi bao giӡ tҩt cҧ các biӇu
đӗ lӟp này cũng đưӧc nhұp vào mӝt biӇu đӗ lӟp tәng thӇ duy nhҩt ± và mӝt lӟp có thӇ
tham gia vào nhiӅu biӇu đӗ lӟp. BiӇu đӗ lӟp đưӧc miêu tҧ chi tiӃt trong chương sau.
 Hình 3.3 - BiӇu đӗ lӟp cho mӝt giao dӏch Tài chính

.3- BiӇu đӗ đӕi tưӧng (Object Diagram):

Mӝt biӇu đӗ đӕi tưӧng là mӝt phiên bҧn cӫa biӇu đӗ lӟp và thưӡng cũng sӱ dөng các ký
hiӋu như biӇu đӗ lӟp. Sӵ khác biӋt giӳa hai loҥi biӇu đӗ này nҵm ӣ chӛ biӇu đӗ đӕi tưӧng
chӍ ra mӝt loҥt các đӕi tưӧng thӵc thӇ cӫa lӟp, thay vì các lӟp. Mӝt biӇu đӗ đӕi tưӧng vì
vұy là mӝt ví dө cӫa biӇu đӗ lӟp, chӍ ra mӝt bӭc tranh thӵc tӃ có thӇ xҧy ra khi hӋ thӕng
thӵc thi: bӭc tranh mà hӋ thӕng có thӇ có tҥi mӝt thӡi điӇm nào đó. BiӇu đӗ đӕi tưӧng sӱ
dөng chung các ký hiӋu cӫa biӇu đӗ lӟp, chӍ trӯ hai ngoҥi lӋ: đӕi tưӧng đưӧc viӃt vӟi tên
đưӧc gҥch dưӟi và tҩt cҧ các thӵc thӇ trong mӝt mӕi quan hӋ đӅu đưӧc chӍ ra (nhìn hình
3.4).

BiӇu đӗ đӕi tưӧng không quan trӑng bҵng biӇu đӗ lӟp, chúng có thӇ đưӧc sӱ dөng đӇ ví
dө hóa mӝt biӇu đӗ lӟp phӭc tҥp, chӍ ra vӟi nhӳng thӵc thӇ cө thӇ và nhӳng mӕi quan hӋ
như thӃ thì bӭc tranh toàn cҧnh sӁ ra sao. Mӝt biӇu đӗ đӕi tưӧng thưӡng thưӡng đưӧc sӱ
dөng làm mӝt thành phҫn cӫa mӝt biӇu đӗ cӝng tác (collaboration), chӍ ra lӕi ӭng xӱ
đӝng giӳa mӝt loҥt các đӕi tưӧng.

Hình 3. - BiӇu đӗ lӟp và biӇu đӗ đӕi tưӧng thӇ hiӋn cӫa lӟp

.- BiӇu đӗ trҥng thái (State Diagram):

Mӝt biӇu đӗ trҥng thái thưӡng là mӝt sӵ bә sung cho lӡi miêu tҧ mӝt lӟp. Nó chӍ ra tҩt cҧ
các trҥng thái mà đӕi tưӧng cӫa lӟp này có thӇ có, và nhӳng sӵ kiӋn (event) nào sӁ gây ra
sӵ thay đәi trҥng thái (hình 3.5). Mӝt sӵ kiӋn có thӇ xҧy ra khi mӝt đӕi tưӧng tӵ gӱi
thông điӋp đӃn cho nó - ví dө như đӇ thông báo rҵng mӝt khoҧng thӡi gian đưӧc xác đӏnh
đã qua đi ± hay là mӝt sӕ điӅu kiӋn nào đó đã đưӧc thӓa mãn. Mӝt sӵ thay đәi trҥng thái
đưӧc gӑi là mӝt sӵ       (State Transition). Mӝt chuyӇn đәi trҥng thái
cũng có thӇ có mӝt hành đӝng liên quan, xác đӏnh điӅu gì phҧi đưӧc thӵc hiӋn khi sӵ
chuyӇn đәi trҥng thái này diӉn ra.

BiӇu đӗ trҥng thái không đưӧc vӁ cho tҩt cҧ các lӟp, mà chӍ riêng cho nhӳng lӟp có mӝt
sӕ lưӧng các trҥng thái đưӧc đӏnh nghĩa rõ ràng và hành vi cӫa lӟp bӏ ҧnh hưӣng và thay
đәi qua các trҥng thái khác nhau. BiӇu đӗ trҥng thái cũng có thӇ đưӧc vӁ cho hӋ thӕng
tәng thӇ. BiӇu đӗ trҥng thái đưӧc miêu tҧ chi tiӃt hơn trong chương sau (Mô hình đӝng).

Hình 3.5- Mӝt ví dө vӅ biӇu đӗ trҥng thái

.5- BiӇu đӗ trình tӵ (Sequence Diagram):

Mӝt biӇu đӗ trình tӵ chӍ ra mӝt cӝng tác đӝng giӳa mӝt loҥt các đӕi tưӧng (xem hình 3.6).
Khía cҥnh quan trӑng cӫa biӇu đӗ này là chӍ ra trình tӵ các thông điӋp (message) đưӧc
gӱi giӳa các đӕi tưӧng. Nó cũng chӍ ra trình tӵ tương tác giӳa các đӕi tưӧng, điӅu sӁ xҧy
ra tҥi mӝt thӡi điӇm cө thӇ nào đó trong trình tӵ thӵc thi cӫa hӋ thӕng. Các biӇu đӗ trình
tӵ chӭa mӝt loҥt các đӕi tưӧng đưӧc biӇu diӉn bҵng các đưӡng thҷng đӭng. Trөc thӡi
gian có hưӟng tӯ trên xuӕng dưӟi trong biӇu đӗ, và biӇu đӗ chӍ ra sӵ trao đәi thông điӋp
giӳa các đӕi tưӧng khi thӡi gian trôi qua. Các thông điӋp đưӧc biӇu diӉn bҵng các đưӡng
gҥch ngang gҳn liӅn vӟi mũi tên (biӇu thӏ thông điӋp) nӕi liӅn giӳa nhӳng đưӡng thҷng
đӭng thӇ hiӋn đӕi tưӧng. Trөc thӡi gian cùng nhӳng lӡi nhұn xét khác thưӡng sӁ đưӧc
đưa vào phҫn lӅ cӫa biӇu đӗ.

Hình 3.6 - Mӝt biӇu đӗ trình tӵ cho Print Server

.6- BiӇu đӗ cӝng tác (Collaboration Diagram):

Mӝt biӇu đӗ cӝng tác chӍ ra mӝt sӵ cӝng tác đӝng, cũng giӕng như mӝt biӇu đӗ trình tӵ.
Thưӡng ngưӡi ta sӁ chӑn hoһc dùng biӇu đӗ trình tӵ hoһc dùng biӇu đӗ cӝng tác. Bên
cҥnh viӋc thӇ hiӋn sӵ trao đәi thông điӋp (đưӧc gӑi là  ), biӇu đӗ cӝng tác chӍ ra
các đӕi tưӧng và quan hӋ cӫa chúng (nhiӅu khi đưӧc gӑi là ngӳ cҧnh). ViӋc nên sӱ dөng
biӇu đӗ trình tӵ hay biӇu đӗ cӝng tác thưӡng sӁ đưӧc quyӃt đӏnh theo nguyên tҳc chung
sau: NӃu thӡi gian hay trình tӵ là yӃu tӕ quan trӑng nhҩt cҫn phҧi nhҩn mҥnh thì hãy chӑn
biӇu đ

5- PHҪN TӰ MÔ HÌNH (MODEL ELEMENT):

Các khái niӋm đưӧc sӱ dөng trong các biӇu đӗ đưӧc gӑi là các phҫn tӱ mô hình (model
element). Mӝt phҫn tӱ mô hình đưӧc đӏnh nghĩa vӟi ngӳ nghĩa (semantic), đó là mӝt đӏnh
nghĩa vӅ bҧn chҩt phҫn tӱ hay là mӝt xác đӏnh ý nghĩa chính xác xem nó sӁ thӇ hiӋn điӅu
gì trong nhӳng lӡi khҷng đӏnh rõ ràng. Mӛi phҫn tӱ mô hình còn có mӝt sӵ miêu tҧ trӵc
quan, mӝt ký hiӋu hình hӑc đưӧc sӱ dөng đӇ miêu tҧ phҫn tӱ này trong biӇu đӗ. Mӝt phҫn
tӱ có thӇ tӗn tҥi trong nhiӅu dҥng biӇu đӗ khác nhau, nhưng cũng có nhӳng nguyên tҳc
xác đӏnh loҥi phҫn tӱ nào có thӇ đưӧc chӍ ra trong loҥi biӇu đӗ nào. Mӝt vài ví dө cho
phҫn tӱ vô hình là lӟp, đӕi tưӧng, trҥng thái, nút mҥng, gói, thành phҫn (hình 3.11).

Hình 3.11- Các thành phҫn mô hình thưӡng dùng

Hình 3.12 chӍ ra mӝt vài ví dө cӫa mӕi quan hӋ, đây cũng là mӝt dҥng phҫn tӱ mô hình,
chúng đưӧc sӱ dөng đӇ nӕi các phҫn tӱ mô hình khác vӟi nhau. Mӝt vài loҥi quan hӋ
đáng chú ý:

[ M   (Association) : nӕi các phҫn tӱ và các thӵc thӇ nӕi (link).
 [   
(Generalization): còn đưӧc gӑi là tính thӯa kӃ, có ý nghĩa rҵng
mӝt phҫn tӱ này có thӇ là mӝt sӵ chuyên biӋt hóa cӫa mӝt phҫn tӱ khác.

[   ! (Dependency): chӍ ra rҵng mӝt phҫn tӱ này phө thuӝc trong mӝt
phương thӭc nào đó vào mӝt phҫn tӱ khác.

[  " (Aggregation): Mӝt dҥng cӫa nӕi kӃt, trong đó mӝt phҫn tӱ này chӭa các
phҫn tӱ khác.

Ngoài ra còn có các phҫn tӱ mô hình khác như thông điӋp (Message), hành đӝng
(action) và khuôn mүu (stereotype). Tҩt cҧ các phҫn tӱ mô hình, ý nghĩa cӫa chúng cũng
như nhӳng ӭng dөng đӅu đưӧc giҧi thích kӻ lưӥng hơn trong các chương sau.

Hình 3.12 ± các ví dө vӅ vài loҥi quan hӋ

6- CƠ CHӂ CHUNG (GENERAL MECHANISM):

UML thӇ hiӋn mӝt sӕ các cơ chӃ chung trong tҩt cҧ các biӇu đӗ nhҵm mөc đích cung cҩp
thêm các thông tin bә sung, thưӡng đây là nhӳng thông tin không thӇ đưӧc thӇ hiӋn qua
các chӭc năng và khҧ năng cơ bҧn cӫa các phҫn tӱ mô hình.

6.1- Trang trí (Adornment)

Các sӵ trang trí trӵc quan có thӇ đưӧc sӱ dөng kèm thêm vào các phҫn tӱ mô hình trong
biӇu đӗ. Đӝng tác trang trí bә sung thêm ngӳ nghĩa cho phҫn tӱ. Mӝt ví dө là kӻ thuұt
đưӧc sӱ dөng đӇ phân biӋt mӝt loҥi thӵc thӇ (lӟp) và mӝt thӵc thӇ. Khi thӇ hiӋn mӝt loҥi,
tên phҫn tӱ sӁ đưӧc in đұm. Khi cũng chính phҫn tӱ đó thӇ hiӋn chӍ mӝt thӵc thӇ cӫa loҥi
này, tên phҫn tӱ sӁ đưӧc gҥch dưӟi và có thӇ đưӧc coi là cҧ tên cӫa thӵc thӇ lүn tên cӫa
loҥi đó. Mӝt hình chӳ nhұt thӇ hiӋn lӟp vӟi tên đưӧc in đұm sӁ thӇ hiӋn mӝt lӟp và tên
đưӧc gҥch dưӟi sӁ thӇ hiӋn mӝt đӕi tưӧng, đây là mӝt ví dө tiêu biӇu cӫa adornment.
Cũng nguyên tҳc đó đưӧc áp dөng cho các nút mҥng, khi ký hiӋu nút đưӧc in đұm là thӇ
hiӋn mӝt loҥi nút, ví dө như máy in (Printer), khi ký hiӋu đưӧc gҥch dưӟi là thӇ hiӋn mӝt
thӵc thӇ cӫa lӟp nút mҥng này ví dө John¶s HP 5MP-printer. Các kiӇu trang trí khác là
các lӡi đһc tҧ vӅ sӕ lưӧng trong quan hӋ (multiplicity), nơi sӕ lưӧng là mӝt sӕ hay mӝt
khoҧng sӕ chӍ ra bao nhiêu thӵc thӇ cӫa các loҥi thӵc thӇ đưӧc nӕi vӟi nhau sӁ có thӇ
tham gia trong mӝt quan hӋ. Kí hiӋu trang trí đưӧc viӃt gҫn phҫn tӱ mô hình đưӧc mà nó
bә sung thông tin (hình 3.13).

Hình 3.13 - Phân biӋt giӳa lӟp và đӕi tưӧng bҵng trang trí

6.2- Ghi chú (Note)

Cho dù mӝt ngôn ngӳ mô hình hóa có đưӧc mӣ rӝng đӃn bao nhiêu chăng nӳa, nó cũng
không thӇ đӏnh nghĩa tҩt cҧ mӑi viӋc. Nhҵm tҥo điӅu kiӋn bә sung thêm cho mӝt mô hình
nhӳng thông tin không thӇ đưӧc thӇ hiӋn bҵng phҫn tӱ mô hình, UML cung cҩp khҧ năng
kèm theo lӡi ghi chú. Mӝt lӡi ghi chú có thӇ đưӧc đӇ bҩt kǤ nơi nào trong bҩt kǤ biӇu đӗ
nào, và nó có thӇ chӭa bҩt kǤ loҥi thông tin nào. Dҥng thông tin cӫa bҧn thân nó là chuӛi
ký tӵ (string), không đưӧc UML diӉn giҧi. Lӡi ghi chú thưӡng đi kèm theo mӝt sӕ các
phҫn tӱ mô hình trong biӇu đӗ, đưӧc nӕi bҵng mӝt đưӡng chҩm chҩm, chӍ ra phҫn tӱ mô
hình nào đưӧc chi tiӃt hóa hoһc đưӧc giҧi thích (hình 3.14).

Mӝt lӡi ghi chú thưӡng chӭa lӡi nhұn xét hoһc các câu hӓi cӫa nhà tҥo mô hình, ví dө lӡi
nhҳc nhӣ cҫn phҧi xӱ lý vҩn đӅ nào đó trong thӡi gian sau này. Lӡi ghi chú cũng có thӇ
chӭa các thông tin dҥng khuôn mүu (stereotype).

Hình 3.1 - Mӝt ví dө vӅ ghi chú

6.3- Đһc tҧ (Specification)

Các phҫn tӱ mô hình có thuӝc tính (Property) chӭa các giá trӏ dӳ liӋu vӅ phҫn tӱ này. Mӝt
thuӝc tính đưӧc đӏnh nghĩa vӟi mӝt tên và mӝt   # $ % (tagged value), thưӡng
chúng ӣ trong mӝt dҥng thông tin đưӧc xác đӏnh trưӟc, ví dө như sӕ nguyên hay chuӛi kí
tӵ. Có mӝt loҥt thuӝc tính đã đưӧc đӏnh nghĩa trưӟc, ví dө như tài liӋu (docement), trách
nhiӋm (Responsibility), sӵ trưӡng tӗn (Persistence) và tính song song (Conccurency).

Thuӝc tính đưӧc sӱ dөng đӇ thêm các đһc tҧ bә sung vӅ mӝt phҫn tӱ, nhӳng thông tin
bình thưӡng ra không đưӧc thӇ hiӋn trong biӇu đӗ. Ví dө tiêu biӇu là mӝt lӟp sӁ đưӧc
miêu tҧ bҵng mӝt tài liӋu văn bҧn nhҩt đӏnh, cung cҩp nhiӅu thông tin hơn vӅ trách nhiӋm
cũng như khҧ năng cӫa lӟp này. Loҥi đһc tҧ này bình thưӡng ra không đưӧc chӍ ra trong
các biӇu đӗ, nhưng thưӡng thì trong đa phҫn các công cө mô hình hóa chúng sӁ có thӇ
đưӧc truy cұp qua hành đӝng nhҩp nút vào mӝt phҫn tӱ nào đó, hiӋu quҧ là mӝt cӱa sә
chӭa đһc tҧ vӟi tҩt cҧ các thuӝc tính sӁ đưӧc chӍ ra (Hình 3.15).

Hình 3.15- Mӝt cӱa sә đһc tҧ thӇ hiӋn các đһc tính cӫa class

7- MӢ RӜNG UML

UML có thӇ đưӧc mӣ rӝng hoһc có thӇ đưӧc sӱa đәi đӇ phù hӧp vӟi mӝt phương pháp
đһc biӋt, mӝt tә chӭc cө thӇ hay mӝt ngưӡi dùng cө thӇ. Chúng ta sӁ bàn luұn sơ qua đӃn
ba cơ chӃ mӣ rӝng UML: khuôn mүu (stereotype), giá trӏ đính kèm (tagged value) và hҥn
chӃ (constraint).

7.1- Khuôn mүu (Stereotype)

Cơ chӃ mӣ rӝng khuôn mүu đӏnh nghĩa mӝt loҥi phҫn tӱ mô hình mӟi dӵa trên mӝt phҫn
tӱ mô hình đã tӗn tҥi. Khuôn mүu có thӇ đưӧc coi là "tương tӵ" như mӝt phҫn tӱ đã có
sҹn, cӝng thêm phҫn quy đӏnh ngӳ nghĩa (semantic) riêng biӋt không có trong phҫn tӱ
gӕc kia. Khuôn mүu cӫa mӝt phҫn tӱ có thӇ đưӧc sӱ dөng trong cùng tình huӕng như
phҫn tӱ căn bҧn. Khuôn mүu dӵa trên tҩt cҧ các loҥi phҫn tӱ mô hình sҹn có - lӟp, nút
mҥng, thành phҫn, cũng như các mӕi quan hӋ như liên kӃt, khái quát hóa, sӵ phө thuӝc.
Ngôn ngӳ UML có chӭa mӝt sӕ lưӧng lӟn các khuôn mүu đưӧc đӏnh nghĩa sҹn và chúng
đưӧc sӱ dөng đӇ sӱa đәi các phҫn tӱ mô hình sҹn có, thay cho viӋc phҧi đӏnh nghĩa hoàn
toàn mӟi. Cơ chӃ này giúp gìn giӳ tính đơn giҧn cӫa nӅn tҧng ngôn ngӳ UML.

Khuôn mүu đưӧc miêu tҧ qua viӋc đưa tên cӫa chúng vào trong mӝt cһp ký tӵ ngoһc
nhӑn <<>>, theo như trong hình 3.16. Ký tӵ ngoһc nhӑn này đưӧc gӑi là guillements.
Khuôn mүu cũng có thӇ có kí hiӋu hình hӑc riêng. Mӝt phҫn tӱ cӫa mӝt loҥi khuôn mүu
cө thӇ có thӇ đưӧc thӇ hiӋn bӣi tên khuôn mүu đi kèm ký hiӋu hình hӑc mô tҧ phҫn tӱ căn
bҧn, hay là sӵ kӃt hӧp cӫa cҧ hai yӃu tӕ này. Bҩt kǤ khi nào mӝt phҫn tӱ mô hình đưӧc
nӕi kӃt vӟi mӝt tên hoһc kí hiӋu khuôn mүu, ta sӁ đӑc "đây là mӝt loҥi phҫn tӱ thuӝc loҥi
khuôn mүu...". Ví dө, mӝt lӟp vӟi <<Window>> sӁ đưӧc gӑi là "mӝt lӟp trong dҥng
khuôn mүu cӱa sә", ý nghĩa cӫa nó là mӝt dҥng lӟp cӱa sә. Nhӳng thuӝc tính cө thӇ mà
mӝt lӟp cӱa sә cҫn phҧi có sӁ đưӧc đӏnh nghĩa khi khuôn mүu này đưӧc đӏnh nghĩa.

Như đã nói, khuôn mүu là mӝt cơ chӃ mӣ rӝng xuҩt sҳc, là mӝt cơ chӃ ngăn cho ngôn
ngӳ UML không trӣ nên quá phӭc tҥp, mһc dù vүn cho phép thӵc hiӋn sӵ mӣ rӝng và sӱa
đәi cҫn thiӃt. Đa phҫn các phҫn tӱ mô hình mӟi mà bҥn cҫn đӃn đӅu có mӝt khuôn mүu
nӅn tҧng trong ngôn ngӳ UML. Mӝt khuôn mүu sau đó có thӇ đưӧc sӱ dөng đӇ cӝng
thêm các ngӳ nghĩa cҫn thiӃt, nhҵm mөc đích đӏnh nghĩa nên các phҫn tӱ mô hình còn
thiӃu.

Hình 3.16- Customer là mӝt lӟp khuôn mүu <<Actor>>

7.2- Giá trӏ đính kèm (Tagged Value)

Như đã nói, các phҫn tӱ mô hình có thӇ có các thuӝc tính chӭa mӝt cһp tên-giá trӏ vӅ bҧn
thân chúng (hình 3.17). Các thuӝc tính này cũng còn đưӧc gӑi là các gía trӏ đính kèm.
UML có chӭa mӝt loҥt các thuӝc tính đưӧc đӏnh nghĩa trưӟc, nhưng kӇ cҧ ngưӡi sӱ dөng
cũng có thӇ đӏnh nghĩa ra các thuӝc tính mӟi đӇ chӭa các thông tin bә sung vӅ các phҫn
tӱ mô hình. Mӑi hình dҥng thông tin đӅu có thӇ đưӧc đính kèm vào phҫn tӱ: các thông tin
chuyên biӋt vӅ phương pháp, các thông tin cӫa nhà quҧn trӏ vӅ tiӃn trình mô hình hóa, các
thông tin đưӧc sӱ dөng bӣi các công cө khác, ví dө như các công cө tҥo code, hay bҩt kǤ
mӝt loҥi thông tin nào mà ngưӡi sӱ dөng muӕn đính kèm vào phҫn tӱ mô hình.
 Hình 3.17 - Mӝt ví dө vӅ Tagged Value

7.3- Hҥn chӃ (Constraint)

Mӝt sӵ hҥn chӃ là mӝt sӵ giӟi hҥn vӅ sӵ sӱ dөng hoһc ý nghĩa cӫa mӝt phҫn tӱ. Sӵ hҥn
chӃ hoһc sӁ đưӧc khai báo trong công cө và đưӧc sӱ dөng nhiӅu lҫn trong rҩt nhiӅu biӇu
đӗ khác nhau, hay đưӧc đӏnh nghĩa và sӱ dөng trong chӍ mӝt biӇu đӗ, theo như nhu cҫu.

Hình 3.18 chӍ ra mӕi quan hӋ nӕi kӃt giӳa nhóm các công dân lӟn tuәi và lӟp con ngưӡi,
chӍ ra rҵng nhóm công dân có thӇ có nhiӅu ngưӡi liên quan. Mһc dù vұy, đӇ miêu tҧ rҵng
chӍ nhӳng ngưӡi nào lӟn hơn 60 tuәi mӟi có thӇ tham gia vào nhóm này, ngưӡi ta đӏnh
nghĩa mӝt sӵ hҥn chӃ, hҥn hҽp tiêu chuҭn tham gia đӕi vӟi chӍ nhӳng ngưӡi nào mà thuӝc
tính tuәi tác có giá trӏ lӟn hơn 60. Đӏnh nghĩa này sӁ hҥn chӃ sӕ lưӧng nhӳng ngưӡi đưӧc
sӱ dөng trong mӕi quan hӋ. NӃu không có nó, ngưӡi ta rҩt dӉ hiӇu lҫm khi diӉn tҧ biӇu
đӗ. Trong trưӡng hӧp tӗi tӋ, nó có thӇ dүn đӃn sӵ thӵc thi sai trái cӫa hӋ thӕng.

Trong trưӡng hӧp này, hҥn chӃ đưӧc đӏnh nghĩa và ӭng dөng trӵc tiӃp trong chính biӇu
đӗ mà nó đưӧc cҫn tӟi. Nhưng nhìn chung thì hҥn chӃ cũng có thӇ đưӧc đӏnh nghĩa vӟi
tên cùng lӡi đһc tҧ riêng, ví dө như: "công dân già" và "ngưӡi có tuәi lӟn hơn 60", và hҥn
chӃ này sӁ đưӧc sӱ dөng trong nhiӅu biӇu đӗ khác nhau. UML có chӭa mӝt loҥt các hҥn
chӃ đưӧc đӏnh nghĩa sҹn, chúng đưӧc miêu tҧ chi tiӃt trong các chương sau.

Hình 3.18- Mӝt ràng buӝc hҥn chӃ đӕi tưӧng Person góp phҫn vào quan hӋ kӃt hӧp

8- MÔ HÌNH HÓA VӞI UML

Khi xây dӵng hӋ thӕng vӟi UML, ngưӡi ta không chӍ xây dӵng duy nhҩt mӝt mô hình. SӁ
có nhiӅu mô hình khác nhau trong nhӳng giai đoҥn phát triӇn khác nhau, nhҳm đӃn các
mөc đích khác nhau. Trong giai đoҥn phân tích, mөc đích cӫa mô hình là nҳm bҳt tҩt cҧ
các yêu cҫu đӕi vӟi hӋ thӕng và mô hình hóa nӅn tҧng bao gӗm các lӟp và các cӝng tác
"đӡi thӵc". Trong giai đoҥn thiӃt kӃ, mөc đích cӫa mô hình là mӣ rӝng mô hình phân tích,
tҥo thành mӝt giҧi pháp kӻ thuұt khҧ thi, có chú ý đӃn môi trưӡng cӫa công viӋc xây dӵng
(viӃt code). Trong giai đoҥn xây dӵng code, mô hình chính là nhӳng dòng code nguӗn
thұt sӵ, đưӧc viӃt nên và đưӧc dӏch thành các chương trình. Và cuӕi cùng, trong giai đoҥn
triӇn khai, mӝt lӡi miêu tҧ sӁ giҧi thích hӋ thӕng cҫn đưӧc triӇn khai ra sao trong kiӃn trúc
vұt lý. Khҧ năng theo dõi xuyên suӕt nhiӅu giai đoҥn và nhiӅu mô hình khác nhau đưӧc
đҧm bҧo qua các thuӝc tính hoһc các mӕi quan hӋ nâng cao (refinement).

Mһc dù đó là các mô hình khác nhau, nhưng chúng đӅu đưӧc xây dӵng nên đӇ mӣ rӝng
nӝi dung cӫa các mô hình ӣ giai đoҥn trưӟc. Chính vì thӃ, tҩt cҧ các mô hình đӅu cҫn phҧi
đưӧc gìn giӳ tӕt đӇ ngưӡi ta có thӇ dӉ dàng đi ngưӧc lҥi, mӣ rӝng ra hay tái thiӃt lұp mô
hình phân tích khӣi đҫu và rӗi dҫn dҫn tӯng bưӟc đưa các sӵ thay đәi vào mô hình thiӃt
kӃ cũng như các mô hình xây dӵng (hình 3.19).

Hình 3.19- Mӝt hӋ thӕng đưӧc mô tҧ trong nhiӅu mô hình

Bҧn thân ngôn ngӳ UML không phө thuӝc vào giai đoҥn, có nghĩa là cũng nhӳng nguyên
tҳc ngôn ngӳ đó và cũng nhӳng biӇu đӗ đó đưӧc sӱ dөng đӇ mô hình hóa nhӳng sӵ viӋc
khác nhau trong nhӳng giai đoҥn khác nhau. Nhà thiӃt kӃ nҳm quyӅn quyӃt đӏnh xem mӝt
mô hình sӁ phҧi thay đәi nhҵm đҥt đưӧc nhӳng mөc đích nào và bao trùm nhӳng phҥm vi
nào. Ngôn ngӳ mô hình hóa chӍ cung cҩp khҧ năng đӇ tҥo ra các mô hình trong mӝt
phong cách mӣ rӝng và nhҩt quán.

Khi mô hình hóa bҵng ngôn ngӳ UML, toàn bӝ công viӋc cҫn phҧi đưӧc thӵc hiӋn theo
mӝt phương pháp hay mӝt qui trình, xác đӏnh rõ nhӳng bưӟc công viӋc nào phҧi đưӧc
tiӃn hành và chúng phҧi đưӧc thӵc thi ra sao. Mӝt qui trình như vұy thưӡng sӁ chia công
viӋc ra thành các vòng lһp kӃ tiӃp, mӛi vòng lһp bao gӗm các công viӋc: & $ '
() & $)  )  *)   
. Mһc dù vұy, cũng có mӝt quy trình nhӓ hơn
đӅ cұp tӟi nӝi dung cӫa viӋc mô hình hóa. Bình thưӡng ra, khi sҧn xuҩt mӝt mô hình hoһc
sҧn xuҩt chӍ mӝt biӇu đӗ duy nhҩt, công viӋc sӁ bҳt đҫu bҵng viӋc thu thұp mӝt nhóm
thích hӧp các cá nhân khác nhau, trình bày vҩn đӅ và mөc tiêu; hӑ cӝng tác cho mӝt giai
đoҥn hӝi thҧo khoa hӑc và phác thҧo, trao đәi nhӳng sáng kiӃn và ý tưӣng vӅ mô hình có
thӇ. Công cө đưӧc sӱ dөng trong giai đoҥn này là hӃt sӭc khác biӋt và mang tính ngүu
hӭng - thưӡng là giҩy dán   hay bҧng trҳng. Công viӋc đưӧc quyӃt đӏnh chӯng nào
nhӳng ngưӡi tham gia có cҧm giác hӑ đã có đưӧc mӝt nӅn tҧng thӵc tiӉn cho mӝt mô
hình (giӕng như mӝt tiêu đӅ). KӃt quҧ sau đó sӁ đưӧc đưa vào mӝt công cө, mô hình tiêu
đӅ đưӧc tә chӭc, và sau đó mӝt biӇu đӗ thӵc sӵ sӁ đưӧc tҥo dӵng nên, phù hӧp vӟi nhӳng
quy đӏnh cӫa ngôn ngӳ mô hình hóa. Sau đó, mô hình đưӧc chi tiӃt hóa qua nhӳng công
viӋc mang tính vòng lһp, càng ngày càng có nhiӅu chi tiӃt vӅ giҧi pháp đưӧc phát hiӋn,
đưӧc dӳ liӋu hóa và đưӧc bә sung. Khi đã có nhiӅu thông tin hơn đưӧc thu thұp vӅ vҩn đӅ
cũng như giҧi pháp cӫa nó, tiêu đӅ ban đҫu dҫn dҫn trӣ thành mӝt lӡi chuҭn đoán cho mӝt
mô hình có khҧ năng sӱ dөng. Khi mô hình đã gҫn hoàn thiӋn, mӝt sӵ tích hӧp và thҭm
đӏnh sӁ đưӧc thӵc hiӋn, dүn tӟi viӋc mô hình hoһc biӇu đӗ sӁ đưӧc tích hӧp vӟi nhӳng mô
hình và biӇu đӗ khác trong cùng dӵ án đӇ đҧm bҧo sӵ nhҩt quán. Mô hình sau đó cũng
đưӧc kiӇm tra lҥi đӇ chҳc chҳn nó đang giҧi quyӃt đúng vҩn đӅ cҫn giҧi quyӃt (hình 3.20).
 Hình 3.20 - Mӝt tiӃn trình cho công viӋc mô hình hoá thӵc tӃ

Cuӕi cùng, mô hình sӁ đưӧc thӵc thi và triӇn khai thành mӝt loҥt các nguyên mүu
(prototype), nguyên mүu này sӁ đưӧc kiӇm tra đӇ tìm khiӃm khuyӃt. Các khiӃm khuyӃt
bao gӗm kӇ cҧ các chӭc năng còn thiӃu, sӵ thӵc hiӋn tӗi tӋ hay phí sҧn xuҩt và phát triӇn
quá cao. Nhӳng khiӃm khuyӃt thưӡng sӁ ép nhà phát triӇn rà đi rà lҥi công viӋc cӫa mình
đӇ khҳc phөc chúng. NӃu vҩn đӅ là quá lӟn, nhà phát triӇn có thӇ sӁ đi ngưӧc lҥi tҩt cҧ
các bưӟc công viӋc cӫa mình cho tӟi tұn giai đoҥn sơ phác đҫu tiên. NӃu các vҩn đӅ này
không lӟn, nhà phát triӇn có lӁ chӍ cҫn thay đәi mӝt vài thành phҫn trong tә chӭc hoһc
đһc tҧ cӫa mô hình. Xin nhӟ rҵng bưӟc tҥo nguyên mүu không thӇ đưӧc thӵc hiӋn ngay
lұp tӭc sau khi hoàn tҩt biӇu đӗ; nó chӍ nên đưӧc thӵc hiӋn khi đã có mӝt sӕ lưӧng lӟn
các biӇu đӗ liên quan. Nguyên mүu sau này có thӇ đưӧc vӭt đi, có thӇ đưӧc tҥo dӵng nên
chӍ đӇ nhҵm mөc đích kiӇm tra, hoһc là nӃu bưӟc tҥo nguyên mүu này thành công, nó sӁ
trӣ thành mӝt vòng lһp trong quy trình phát triӇn thұt sӵ.

9- CÔNG CӨ (TOOL)

Sӱ dөng mӝt ngôn ngӳ mô hình hóa phӭc tҥp và rӝng mӣ như UML cҫn thiӃt sӵ trӧ giúp
cӫa công cө. Mһc dù phác thҧo đҫu tiên cӫa mӝt mô hình có thӇ đưӧc thӵc hiӋn bҵng
bҧng trҳng cùng giҩy và mӵc, nhưng công viӋc bҧo trì, đӗng bӝ hóa và đҧm bҧo sӵ nhҩt
quán trong mӝt loҥt các biӇu đӗ khác nhau thưӡng lҥi không thӇ trӣ thành khҧ thi nӃu
không có công cө.

Thӏ trưӡng công cө mô hình hóa đã dӯng trong mӭc đӝ sơ khӣi suӕt mӝt thӡi gian dài kӇ
tӯ khi xuҩt hiӋn ý tưӣng đҫu tiên vӅ các chương trình trӧ giúp cho viӋc tҥo chương trình.
Rҩt nhiӅu công cө trong thӵc tӃ chӍ thông minh hơn các chương trình vӁ mӝt chút, sӱ
dөng mӝt vài quy chӃ kiӇm tra tính nhҩt quán hoһc mӝt vài kiӃn thӭc vӅ phương pháp và
ngôn ngӳ mô hình hóa. Mһc dù đã có mӝt vài bưӟc tiӃn nhҩt đӏnh và nhiӅu công cө hôm
nay đã tӟi gҫn sáng kiӃn khӣi thӫy kia nhiӅu hơn (Rational Rose), nhưng thӏ trưӡng vүn
còn không ít công cө chưa đưӧc gӑt giũa, vүn còn chӭa lӛi hoһc nhӳng nét kǤ quһc, kӇ cҧ
nhӳng vҩn đӅ đơn giҧn như copy và dán. Nhӳng công cө này còn hҥn chӃ ӣ phương diӋn
rҵng tҩt cҧ bӑn chúng đӅu có ngôn ngӳ mô hình hóa riêng, hay ít nhҩt thì cũng có nhӳng
đӏnh nghĩa riêng cӫa chúng vӅ ngôn ngӳ này.

Cùng vӟi sӵ ra đӡi cӫa ngôn ngӳ UML, các nhà cung cҩp công cө mô hình hóa giӡ đây
có thӇ dành nhiӅu thӡi gian hơn cho viӋc nâng cҩp công cө, bӣi hӑ không cҫn phҧi dӗn
tâm dӗn sӭc cho viӋc đӏnh nghĩa các phương pháp mӟi cũng như các ngôn ngӳ mӟi.

Mӝt công cө mô hình hóa hӏên đҥi cҫn phҧi cung cҩp các chӭc năng sau:

w # : cҫn phҧi tҥo điӅu kiӋn dӉ dàng vӁ ra các biӇu đӗ trong ngôn ngӳ mô
hình hóa. Công cө cҫn phҧi đӫ khҧ năng thông minh đӇ hiӇu mөc đích cӫa các biӇu đӗ và
biӃt đưӧc nhӳng ngӳ nghĩa cũng như các quy tҳc đơn giҧn, đӫ đӇ nó có thӇ cҧnh báo hoһc
ngăn chһn viӋc sӱ dөng không thích hӧp các phҫn tӱ mô hình.

÷ $Y
 
Y %& (I' ( Y )): công cө cҫn phҧi hӛ trӧ mӝt nhà kho
trung tâm đӇ tҩt cҧ các thông tin vӅ mô hình đưӧc lưu trӳ trong cùng mӝt chӛ. NӃu ví dө
tên cӫa mӝt lӟp bӏ thay đәi trong mӝt biӇu đӗ, thì sӵ thay đәi này cҫn phҧi xҧy ra trong
tҩt cҧ các biӇu đӗ khác có sӱ dөng lӟp này.

÷ Y  * 
 (M Y ): công cө cҫn phҧi tҥo điӅu kiӋn dӉ dàng cho
ngưӡi sӱ dөng đӏnh hưӟng và chuyӇn dӏch trong mô hình đӇ theo dõi mӝt phҫn tӱ tӯ biӇu
đӗ này sang biӇu đӗ khác, hoһc đӇ mӣ rӝng lӡi miêu tҧ cӫa mӝt phҫn tӱ.

÷Y  +  (,!Y ( ('' Y: Công cө cҫn hӛ trӧ cho nhiӅu
ngưӡi sӱ dөng, và tҥo điӅu kiӋn cho hӑ cùng làm viӋc vӟi mӝt mô hình mà không ngăn
chһn hoһc quҩy phá lүn nhau.
 Ú 
Y$    Y: mӝt công cө cao cҩp cҫn phҧi có khҧ năng tҥo
ra code, nơi tҩt cҧ các thông tin trong mô hình đưӧc chuyӇn tҧi thành các khung code
(code skeletons), đưӧc sӱ dөng làm nӅn tҧng cho giai đoҥn xây dӵng chương trình.

Ú
Y$   I(   : Mӝt công cө cao cҩp cҫn phҧi có khҧ năng
đӑc nhӳng thành phҫn code đang tӗn tҥi và tӯ đó sҧn xuҩt ra mô hình. Tӯ đó suy ra, mӝt
mô hình có thӇ đưӧc làm tӯ nhӳng dòng code đã tӗn tҥi; hoһc mӝt nhà phát triӇn có thӇ
dӉ dàng chuyӇn đi chuyӇn vӅ giӳa công viӋc mô hình hóa và công viӋc lұp trình.

Ú
  '

,&
: mӝt công cө cҫn phҧi có khҧ năng tích hӧp vӟi
nhӳng công cө khác, vӟi cҧ viӋc phát triӇn môi trưӡng, ví dө như các trình soҥn thҧo
(editor), chương trình dӏch (compiler), chương trình tìm lӛi (debugger) cũng như các
công cө cӫa doanh nghiӋp khác như công cө quҧn trӏ cҩu hình, hӋ thӕng theo dõi các
phiên bҧn.

 -
Y  Y.Y/

Y 0Y  &
 : công cө cҫn
phҧi dӉ chuyӇn tҧi tӯ lӡi miêu tҧ ӣ cҩp trӯu tưӧng hóa cao nhҩt cӫa hӋ thӕng (tӭc là ӣ
dҥng mӝt lưӧng các gói khác nhau) đi xuӕng cho tӟi cҩp cӫa nhӳng dòng code thұt sӵ.
Sau đó, đӇ truy xuҩt nhӳng dòng lӋnh code cho mӝt thӫ tөc cө thӇ nào đó trong mӝt lӟp
nào đó, bҥn có thӇ chӍ cҫn nhҩp chuӝt vào tên cӫa thӫ tөc đó trong mӝt biӇu đӗ.

Ú  1    Mӝt mô hình hay mӝt biӇu đӗ cӫa mӝt mô hình nào đó cҫn
phҧi có khҧ năng đưӧc xuҩt ra tӯ mӝt công cө này rӗi nhұp vào mӝt công cө khác, giӕng
như nhӳng dòng lӋnh code đưӧc sҧn sinh trong mӝt công cө này có thӇ đưӧc sӱ dөng
trong mӝt công cө khác. Nguyên tҳc trao đәi đó cҫn phҧi đưӧc áp dөng cho các mô hình
trong mӝt ngôn ngӳ mô hình hóa đưӧc đӏnh nghĩa chính xác.

10- TÓM TҲT Vӄ UML

UML tә chӭc mӝt mô hình thành mӝt loҥt các hưӟng nhìn, thӇ hiӋn các khía cҥnh khác
nhau cӫa hӋ thӕng. ChӍ khi kӃt hӧp tҩt cҧ các hưӟng nhìn lҥi vӟi nhau, ngưӡi ta mӟi co
đưӧc mӝt bӭc tranh trӑn vҽn vӅ hӋ thӕng. Mӝt hưӟng nhìn không phҧi là mӝt hình vӁ, nӝi
dung cӫa nó đưӧc miêu tҧ qua các biӇu đӗ, đây là nhӳng hình vӁ chӭa đӵng các phҫn tӱ
mô hình hóa. Mӝt biӇu đӗ bình thưӡng chӍ trình bày mӝt phҫn nӝi dung cӫa mӝt hưӟng
nhìn, và mӝt hưӟng nhìn đưӧc đӏnh nghĩa vӟi rҩt nhiӅu biӇu đӗ. Mӝt biӇu đӗ chӭa các
phҫn tӱ mô hình, ví dө như lӟp, đӕi tưӧng, nút mҥng, thành phҫn và nhӳng mӕi quan hӋ
như nӕi kӃt, khái quát hóa, phө thuӝc. Các phҫn tӱ này có ý nghĩa (semantic) và các ký
hiӋu hình hӑc.

Các loҥi biӇu đӗ trong UML là: biӇu đӗ lӟp, biӇu đӗ đӕi tưӧng, biӇu đӗ Use case, biӇu đӗ
trҥng thái, biӇu đӗ trình tӵ, biӇu đӗ cӝng tác, biӇu đӗ hành đӝng, biӇu đӗ thành phҫn và
biӇu đӗ triӇn khai. Mөc đích cӫa các loҥi biӇu đӗ cũng như quy tҳc vӁ chúng sӁ đưӧc
miêu tҧ chi tiӃt trong chương sau.

UML có mӝt sӕ cơ chӃ chung đӇ bә sung thông tin không thӇ đưӧc thӇ hiӋn trong quá
trình vӁ biӇu đӗ. Nhӳng thông tin này bao gӗm ví dө nhӳng thành phҫn trang trí, các lӡi
ghi chú có thӇ chӭa bҩt kǤ loҥi thông tin nào cũng như các thuӝc tính đһc tҧ. Ngoài ra còn
có các cơ chӃ mӣ rӝng, bao gӗm giá trӏ đính kèm, hҥn chӃ đӕi vӟi phҫn tӱ, và khuôn mүu,
đӏnh nghĩa mӝt loҥi phҫn tӱ mô hình mӟi dӵa trên mӝt phҫn tӱ sҹn có.

Mӝt hӋ thӕng sӁ đưӧc miêu tҧ trong nhiӅu loҥi mô hình khác nhau, mӛi loҥi mô hình
nhҵm mӝt mөc đích khác nhau. Mô hình phân tích miêu tҧ nhӳng yêu cҫu vӅ mһt chӭc
năng và mô hình hóa các lӟp ngoài đӡi thӵc. Mô hình thiӃt kӃ chuyӇn tҧi kӃt quҧ phân
tích thành mӝt giҧi pháp kӻ thuұt, theo khái niӋm cӫa mӝt thiӃt kӃ phҫn mӅm hoҥt đӝng
hoàn chӍnh. Mô hình xây dӵng code thӇ hiӋn hӋ thӕng qua viӋc thҧo chương cho nó trong
mӝt ngôn ngӳ lұp trình hưӟng đӕi tưӧng. Và cuӕi cùng, mô hình triӇn khai đӏnh vӏ
chương trình vӯa đưӧc tҥo nên trong mӝt kiӃn trúc vұt lý bao gӗm các máy tính và các
trang thiӃt bӏ. Công viӋc đưӧc làm theo nhiӅu vòng lһp khác nhau chӭ không phҧi chӍ là
mӝt chuӛi thӵc hiӋn mӝt lҫn.

ĐӇ sӱ dөng UML mӝt cách nghiêm chӍnh cho mӝt dӵ án có thұt ngoài đӡi, bҥn cҫn công
cө. Mӝt công cө tân tiӃn có khҧ năng cho ngưӡi dùng vӁ biӇu đӗ, trӳ tҩt cҧ các thông tin
vào mӝt kho chung, cho phép dӉ dàng dӏch chuyӇn giӳa các hưӟng nhìn và biӇu đӗ khác
nhau trong mô hình, tҥo báo cáo và tài liӋu, tҥo khung code tӯ mô hình, đӑc nhӳng dòng
code sҹn có rӗi sҧn sinh ra mô hình tӯ đó, và dӉ dàng tích hӧp vӟi các công cө phát triӇn
khác.

PHҪN CÂU HӒI

Hӓi: UML có công cө nào giúp nҳm bҳt các yêu cҫu cӫa khách hàng (ngưӡi sӱ dөng)?

Đáp: Use Case

Hӓi: Mӝt biӇu đӗ trong UML có bao chӭa các hưӟng nhìn khác nhau.

Đáp: Sai, mӝt hưӟng nhìn bao gӗm mӝt loҥi các biӇu đӗ khác nhau

Hӓi: Hãy liӋt kê các thành phҫn chӫ yӃu cӫa ngôn ngӳ UML

Đáp: Hưӟng nhìn( View), BiӇu đӗ (Diagram), Phҫn tӱ mô hình, Cơ chӃ chung.

Hӓi: UML có công cө nào phөc vө cho giai đoҥn thӱ nghiӋm đơn vӏ (Unit Testing)?

Đáp: BiӇu đӗ lӟp và đһc tҧ lӟp

Hӓi: UML có công cө nào phөc vө cho giai đoҥn thӱ nghiӋm hӋ thӕng (System Testing)?

Đáp: Use case Diagram

Hӓi: UML tҥo nӅn tҧng cho viӋc giao tiӃp giӳa khách hàng, nhà phân tích, nhà thiӃt kӃ và
lұp trình viên.
Đáp: Đúng

›››

Chương : Mô hình hóa USE CASE

›››

1- GIӞI THIӊU USE CASE

Trong giai đoҥn phân tích, ngưӡi sӱ dөng cӝng tác cùng nhóm phát triӇn phҫn mӅm tҥo
nên mӝt tә hӧp thông tin quan trӑng vӅ yêu cҫu đӕi vӟi hӋ thӕng. Không chӍ là ngưӡi
cung cҩp thông tin, bҧn thân ngưӡi sӱ dөng còn là mӝt thành phҫn hӃt sӭc quan trӑng
trong bӭc tranh toàn cҧnh đó và nhóm phát triӇn cҫn phҧi chӍ ra đưӧc phương thӭc hoҥt
đӝng cӫa hӋ thӕng tương lai theo hưӟng nhìn cӫa ngưӡi sӱ dөng. HiӇu đưӧc điӇm quan
trӑng này là chìa khóa đӇ tҥo dӵng đưӧc nhӳng hӋ thӕng vӯa thoҧ mãn các yêu cҫu đһt ra
vӯa dӉ dàng sӱ dөng, thұm chí tҥo niӅm vui thích trong sӱ dөng.

Như vұy công cө giúp ta mô hình hoá hӋ thӕng tӯ hưӟng nhìn cӫa ngưӡi sӱ dөng gӑi là
Use Case. Và đӇ trҧ lӡi rõ hơn vӅ Use Case ta xét mӝt trưӡng hӧp sau:

Giҧ sӱ tôi quyӃt đӏnh mua mӝt chiӃc máy fax mӟi. Khi đӃn cӱa hàng máy văn phòng, tôi
mӟi nhұn ra là phҧi chӑn lӵa trong mӝt danh sách máy móc rҩt phong phú. Loҥi máy nào
sӁ đưӧc chӑn đây? Tôi tӵ hӓi thұt chính xác mình muӕn làm gì vӟi chiӃc máy fax sӁ
mua? Tôi muӕn có nhӳng tính năng nào? Tôi muӕn dùng bҵng giҩy thưӡng hay giҩy
thermal ? Tôi muӕn copy bҵng cái máy đó? Tôi muӕn nӕi nó vӟi máy tính cӫa mình? Tôi
muӕn dùng nó vӯa làm máy fax vӯa làm scanner? Tôi có cҫn phҧi gӣi fax thұt nhanh đӃn
mӭc đӝ cҫn mӝt chӭc năng chӑn sӕ tăng tӕc? LiӋu tôi có muӕn sӱ dөng máy fax này đӇ
phân biӋt giӳa mӝt cú điӋn thoҥi gӑi tӟi và mӝt bҧn fax gӣi tӟi ?.

Tҩt cҧ chúng ta đӅu trҧi qua nhӳng kinh nghiӋm như vұy khi quyӃt đӏnh mua mӝt món
hàng nào đó không phҧi vì niӅm vui bӝc phát. ViӋc chúng ta sӁ làm trong nhӳng trưӡng
hӧp như vұy là mӝt dҥng phân tích Use Case: Chúng ta tӵ hӓi mình sӁ sӱ dөng sҧn phҭm
(hay hӋ thӕng) sҳp bҳt ta bӓ ra mӝt khoҧn tiӅn đáng kӇ đó ra sao? Trҧ lӡi xong câu hӓi
trên ta mӟi có khҧ năng chӑn ra sҧn phҭm thoҧ mãn nhӳng đòi hӓi cӫa mình. ĐiӅu quan
trӑng ӣ đây là phҧi biӃt nhӳng đòi hӓi đó là gì.

Loҥi quy trình này đóng vai trò rҩt quan trӑng đӕi vӟi giai đoҥn phân tích cӫa mӝt nhóm
phát triӇn hӋ thӕng. Ngưӡi dùng muӕn sӱ dөng hӋ thӕng tương lai, hӋ thӕng mà bҥn sҳp
thiӃt kӃ và xây dӵng, như thӃ nào?

Use Case là mӝt công cө trӧ giúp cho công viӋc cӫa nhà phân tích cùng ngưӡi sӱ dөng
quyӃt đӏnh tính năng cӫa hӋ thӕng. Mӝt tұp hӧp các Use Case sӁ làm nәi bұt mӝt hӋ thӕng
theo phương diӋn nhӳng ngưӡi dùng đӏnh làm gì vӟi hӋ thӕng này.
ĐӇ làm rõ hơn, ta hãy xét mӝt ví dө nhà băng lҿ. HӋ thӕng tương lai trong trưӡng hӧp này
sӁ só nhiӅu ngưӡi sӱ dөng, mӛi ngưӡi sӁ giao tiӃp vӟi hӋ thӕng cho mӝt mөc đích khác
biӋt:

- Quҧn trӏ gia sӱ dөng hӋ thӕng cho mөc đích thӕng kê

- Nhân viên tiӃp khách sӱ dөng hӋ thӕng đӇ thӵc hiӋn các dӏch vө phөc vө khách
hàng.

- Nhân viên phòng đҫu tư sӱ dөng hӋ thӕng đӇ thӵc hiӋn các giao dӏch liên quan
đӃn đҫu tư.

- Nhân viên thҭm tra chӳ ký sӱ dөng hӋ thӕng cho mөc đích xác nhұn chӳ ký và
bҧo trì thông tin liên quan đӃn khách hàng.

- Khách hàng giao tiӃp vӟi hӋ thӕng (nhà băng) cho các hoҥt đӝng sӱ dөng dӏch
vө như mӣ tài khoҧn, gӱi tiӅn vào, rút tiӅn mһt, «

Quá trình tương tác giӳa ngưӡi sӱ dөng và hӋ thӕng trong mӛi mӝt tình huӕng kӇ trên sӁ
khác nhau và phө thuӝc vào chӭc năng mà ngưӡi sӱ dөng muӕn thӵc thi cùng hӋ thӕng.

Nhóm phát triӇn hӋ thӕng cҫn phҧi xây dӵng nên mӝt kӏch bҧn nêu bұt sӵ tương tác cҫn
thiӃt giӳa ngưӡi sӱ dөng và hӋ thӕng trong mӛi khҧ năng hoҥt đӝng. Ví dө như kӏch bҧn
cho sӵ tương tác giӳa nhân viên thu ngân và hӋ thӕng cӫa bӝ phұn tiӃt kiӋm trong suӕt
tiӃn trình cӫa mӝt giao dӏch. Mӝt kӏch bҧn khác ví dө là chuӛi tương tác xҧy ra giӳa bӝ
phұn tiӃt kiӋm và bӝ phұn đҫu tư trong mӝt giao dӏch chuyӇn tiӅn.

Nhìn chung, có thӇ coi mӝt Use case như là tұp hӧp cӫa mӝt loҥt các cҧnh kӏch vӅ viӋc sӱ
dөng hӋ thӕng. Mӛi cҧnh kӏch mô tҧ mӝt chuӛi các sӵ kiӋn. Mӛi mӝt chuӛi này sӁ đưӧc
kích hoҥt bӣi mӝt ngưӡi nào đó, mӝt hӋ thӕng khác hay là mӝt phҫn trang thiӃt bӏ nào đó,
hoһc là mӝt chuӛi thӡi gian. Nhӳng thӵc thӇ kích hoҥt nên các chuӛi sӵ kiӋn như thӃ
đưӧc gӑi là các Tác Nhân (Actor). KӃt quҧ cӫa chuӛi này phҧi có giá trӏ sӱ dөng đӕi vӟi
hoһc là tác nhân đã gây nên nó hoһc là mӝt tác nhân khác.

2- MӜT SӔ VÍ DӨ USE CASE

Trong ví dө nhà băng lҿ ӣ trên, mӝt sӕ nhӳng Use Case dӉ thҩy nhҩt là:

- Mӝt khách hàng mӣ mӝt tài khoҧn mӟi.

- Phòng đҫu tư tính toán tiӅn lãi cho các tài khoҧn đҫu tư.

- Mӝt chương trình đҫu tư mӟi đưӧc đưa vào áp dөng.

- Yêu cҫu chuyӇn tiӅn cӫa khách hàng đưӧc thӵc hiӋn.
 - ChuyӇn tiӅn theo kǤ hҥn tӯ mӝt tài khoҧn đҫu tư sang mӝt tài khoҧn tiӃt kiӋm.

3- SӴ CҪN THIӂT PHҦI CÓ USE CASE

Use Case là mӝt công cө xuҩt sҳc đӇ khuyӃn khích nhӳng ngưӡi dùng tiӅm năng nói vӅ
hӋ thӕng tӯ hưӟng nhìn cӫa hӑ. Đӕi vӟi ngưӡi dùng, chҷng phҧi bao giӡ viӋc thӇ hiӋn và
mô tҧ nhӳng ý đӏnh trong viӋc sӱ dөng hӋ thӕng cũng là chuyӋn dӉ dàng. Mӝt hiӋn thӵc
có thұt là ngưӡi sӱ dөng thưӡng biӃt nhiӅu hơn nhӳng gì mà hӑ có thӇ diӉn tҧ ra: Công cө
Use Case sӁ giúp cho nhóm phát triӇn bҿ gãy "lӟp băng" đó, ngoài ra mӝt sӵ trình bày
trӵc quan cũng cho phép bҥn kӃt hӧp các biӇu đӗ Use Case vӟi các loҥi biӇu đӗ khác.

Sáng kiӃn chӫ đҥo là lôi cuӕn đưӧc ngưӡi dùng tham gia vào nhӳng giai đoҥn đҫu tiên
cӫa quá trình phân tích và thiӃt kӃ hӋ thӕng. ViӋc này sӁ nâng cao xác suҩt cho viӋc hӋ
thӕng chung cuӝc trӣ thành mӝt công cө quen thuӝc đӕi vӟi các ngưӡi dùng mà nó dӵ
đӏnh sӁ trӧ giúp ± thay vì là mӝt tұp hӧp khó hiӇu và rӕi rҳm cӫa các khái niӋm máy tính
mà ngưӡi dùng trong giӟi doanh thương có cҧm giác không bao giӡ hiӇu đưӧc và không
thӇ làm viӋc cùng.

Công tác lôi kéo ngưӡi sӱ dөng tham gia tích cӵc vào quá trình phân tích là nӅn tҧng
quan trӑng cho viӋc tҥo dӵng mӝt mô hình "thành công", mӝt mô hình dӉ đưӧc ngưӡi sӱ
dөng hiӇu và chҩp nhұn sau khi đã thҭm xác các nhiӋm vө căn bҧn. Ngoài ra, Use Case
còn giúp nhóm phát triӇn quyӃt đӏnh các lӟp mà hӋ thӕng phҧi triӇn khai.

- MÔ HÌNH HÓA USE CASE

Trưӡng hӧp sӱ dөng là mӝt kӻ thuұt mô hình hóa đưӧc sӱ dөng đӇ mô tҧ mӝt hӋ thӕng
mӟi sӁ phҧi làm gì hoһc mӝt hӋ thӕng đang tӗn tҥi làm gì. Mӝt mô hình Use Case đưӧc
xây dӵng qua mӝt quá trình mang tính vòng lһp (interative), trong đó nhӳng cuӝc hӝi
thҧo bàn luұn giӳa nhóm phát triӇn hӋ thӕng và khách hàng (hoһc/và ngưӡi sӱ dөng cuӕi)
sӁ dүn tӟi mӝt đһc tҧ yêu cҫu đưӧc tҩt cҧ mӑi ngưӡi chҩp nhұn. Ngưӡi cha tinh thҫn cӫa
mô hình hóa Use Case là Ivar Jacobson, ông đã tҥo nên kӻ thuұt mô hình hóa dӵa trên
nhӳng kinh nghiӋm thu thұp đưӧc trong quá trình tҥo hӋ thӕng AXE cӫa hãng Erisson.
Use Case đã nhұn đưӧc mӝt sӵ quan tâm đһc biӋt lӟn lao tӯ phía cӝng đӗng hưӟng đӕi
tưӧng và đã tác đӝng lên rҩt nhiӅu phương pháp hưӟng đӕi tưӧng khác nhau.

Nhӳng thành phҫn quan trӑng nhҩt cӫa mӝt mô hình Use Case là Use Case, tác nhân và
hӋ thӕng. Ranh giӟi cӫa hӋ thӕng đưӧc đӏnh nghĩa qua chӭc năng tәng thӇ mà hӋ thӕng sӁ
thӵc thi. Chӭc năng tәng thӇ đưӧc thӇ hiӋn qua mӝt loҥt các Use Case và mӛi mӝt Use
Case đһc tҧ mӝt chӭc năng trӑn vҽn, có nghĩa là Use Case phҧi thӵc thi toàn bӝ chӭc
năng đó, tӯ sӵ kiӋn đưӧc kích hoҥt đҫu tiên bӣi mӝt tác nhân ngoҥi cҧnh cho tӟi khi chӭc
năng đòi hӓi đưӧc thӵc hiӋn hoàn tҩt. Mӝt Use Case luôn luôn phҧi cung cҩp mӝt giá trӏ
nào đó cho mӝt tác nhân, giá trӏ này là nhӳng gì mà tác nhân mong muӕn tӯ phía hӋ
thӕng. Tác nhân là bҩt kǤ mӝt thӵc thӇ ngoҥi cҧnh nào mong muӕn tương tác vӟi hӋ
thӕng. Thưӡng thưӡng, đó là mӝt ngưӡi sӱ dөng cӫa hӋ thӕng, nhưng nhiӅu khi cũng có
thӇ là mӝt hӋ thӕng khác hoһc là mӝt dҥng máy móc thiӃt bӏ phҫn cӭng nào đó cҫn tương
tác vӟi hӋ thӕng.
Trong kӻ thuұt mô hình hóa Use Case, hӋ thӕng sӁ có hình dҥng cӫa mӝt "hӝp đen" và
cung cҩp các Use Case. HӋ thӕng làm điӅu đó như thӃ nào, các Use Case đưӧc thӵc thi ra
sao, đó là nhӳng khía cҥnh chưa đưӧc đӅ cұp tӟi trong giai đoҥn này. Trong thӵc tӃ, nӃu
mô hình hóa Use Case đưӧc thӵc hiӋn trong nhӳng giai đoҥn đҫu cӫa dӵ án thì thưӡng
nhà phát triӇn sӁ không biӃt Use Case sau này sӁ đưӧc thӵc thi (tӭc là biӃn thành nhӳng
dòng code thұt sӵ) như thӃ nào.

Mөc tiêu chính yӃu đӕi vӟi các Use Case là:

- ĐӇ quyӃt đӏnh và mô tҧ các yêu cҫu vӅ mһt chӭc năng cӫa hӋ thӕng, đây là kӃt
quҧ rút ra tӯ sӵ thӓa thuұn giӳa khách hàng (và/hoһc ngưӡi sӱ dөng cuӕi) và nhóm phát
triӇn phҫn mӅm.

- ĐӇ tҥo nên mӝt lӡi mô tҧ rõ ràng và nhҩt quán vӅ viӋc hӋ thӕng cҫn phҧi làm gì,
làm sao đӇ mô hình có thӇ đưӧc sӱ dөng nhҩt quán suӕt toàn bӝ quá trình phát triӇn, đưӧc
sӱ dөng làm công cө giao tiӃp cho tҩt cҧ nhӳng ngưӡi phát triӇn nên các yêu cҫu này, và
đӇ tҥo nên mӝt nӅn tҧng cho viӋc tҥo nên các mô hình thiӃt kӃ cung cҩp các chӭc năng
đưӧc yêu cҫu.

- ĐӇ tҥo nên mӝt nӅn tҧng cho các bưӟc thӱ nghiӋm hӋ thӕng, đҧm bҧo hӋ thӕng
thӓa mãn đúng nhӳng yêu cҫu do ngưӡi sӱ dөng đưa ra. Trong thӵc tӃ thưӡng là đӇ trҧ lӡi
câu hӓi: LiӋu hӋ thӕng cuӕi cùng có thӵc hiӋn nhӳng chӭc năng mà khӣi đҫu khách hàng
đã đӅ nghӏ?

- ĐӇ cung cҩp khҧ năng theo dõi các yêu cҫu vӅ mһt chӭc năng đưӧc chuyӇn
thành các lӟp cө thӇ cũng như các thӫ tөc cө thӇ trong hӋ thӕng.

- ĐӇ đơn giҧn hóa viӋc thay đәi và mӣ rӝng hӋ thӕng qua viӋc thay đәi và mӣ
rӝng mô hình Use Case, sau đó chӍ theo dõi riêng nhӳng Use Case đã bӏ thay đәi cùng
nhӳng hiӋu ӭng cӫa chúng trong thiӃt kӃ hӋ thӕng và xây dӵng hӋ thӕng.

Nhӳng công viӋc cө thӇ cҫn thiӃt đӇ tҥo nên mӝt mô hình Use Case bao gӗm:

1. Đӏnh nghĩa hӋ thӕng (xác đӏnh phҥm vi hӋ thӕng)

2. Tìm ra các tác nhân cũng như các Use Case

3. Mô tҧ Use Case

4. Đӏnh nghĩa mӕi quan hӋ giӳa các Use Case

5. KiӇm tra và phê chuҭn mô hình.

Đây là mӝt công viӋc mang tính tương tác rҩt cao, bao gӗm nhӳng cuӝc thҧo luұn vӟi
khách hàng và nhӳng ngưӡi đҥi diӋn cho các loҥi tác nhân. Mô hình Use Case bao gӗm
các biӇu đӗ Use Case chӍ ra các tác nhân, Use Case và mӕi quan hӋ cӫa chúng vӟi nhau.
Các biӇu đӗ này cho ta mӝt cái nhìn tәng thӇ vӅ mô hình, nhưng nhӳng lӡi mô tҧ thӵc sӵ
cӫa tӯng Use Case thưӡng lҥi là văn bҧn. Vì các mô hình trӵc quan không thӇ cung cҩp
tҩt cҧ các thông tin cҫn thiӃt, nên cҫn thiӃt phҧi dùng cҧ hai kӻ thuұt trình bày đó.

Có rҩt nhiӅu ngưӡi quan tâm đӃn viӋc sӱ dөng các mô hình Use Case. Khách hàng
(và/hoһc ngưӡi sӱ dөng cuӕi) quan tâm đӃn chúng vì mô hình Use Case đһc tҧ chӭc năng
cӫa hӋ thӕng và mô tҧ xem hӋ thӕng có thӇ và sӁ đưӧc sӱ dөng ra sao. Các Use Case vì
vұy phҧi đưӧc mô tҧ trong nhӳng thuұt ngӳ và ngôn ngӳ cӫa khách hàng/ngưӡi sӱ dөng.

Nhà phát triӇn cҫn đӃn các mô hình Use Case đӇ hiӇu hӋ thӕng cҫn phҧi làm gì, và qua đó
có đưӧc mӝt nӅn tҧng cho nhӳng công viӋc tương lai (các mô hình khác, các cҩu trúc
thiӃt kӃ và viӋc thӵc thi xây dӵng hӋ thӕng bҵng code).

Các nhóm chuyên gia thӱ nghiӋm tích hӧp và thӱ nghiӋm hӋ thӕng cҫn đӃn Use Case đӇ
thӱ nghiӋm và kiӇm tra xem hӋ thӕng có đҧm bҧo sӁ thӵc hiӋn đúng chӭc năng đã đưӧc
đһc tҧ trong giai đoҥn đҫu.

Và cuӕi cùng, bҩt kǤ ngưӡi nào liên quan đӃn nhӳng hoҥt đӝng liên kӃt đӃn chӭc năng
cӫa hӋ thӕng đӅu có thӇ quan tâm đӃn các mô hình Use Case; ví dө như các nhóm tiӃp
thӏ, bán hàng, hӛ trӧ khách hàng và các nhóm soҥn thҧo tài liӋu.

Mô hình Use Case mô tҧ hưӟng nhìn Use Case cӫa hӋ thӕng. Hưӟng nhìn này là rҩt quan
trӑng, bӣi nó ҧnh hưӣng đӃn tҩt cҧ các hưӟng nhìn khác cӫa hӋ thӕng. Cҧ cҩu trúc logic
lүn cҩu trúc physic đӅu chӏu ҧnh hưӣng tӯ các Use Case, bӣi chӭc năng đưӧc đһc tҧ trong
mô hình này chính là nhӳng chӭc năng đưӧc thӵc thi trong các cҩu trúc kia. Mөc đích
cuӕi cùng là thiӃt kӃ ra mӝt giҧi pháp thӓa mãn các yêu cҫu đó.

Mô hình hóa các Use Case chҷng phҧi chӍ đưӧc dùng đӇ nҳm bҳt các yêu cҫu cӫa hӋ
thӕng mӟi; nó cũng còn đưӧc sӱ dөng đӇ hӛ trӧ cho viӋc phát triӇn mӝt phiên bҧn mӟi
cӫa hӋ thӕng. Khi phát triӇn mӝt phiên bҧn mӟi cӫa hӋ thӕng đang tӗn tҥi, ngưӡi ta sӁ bә
sung thêm các chӭc năng mӟi vào mô hình Use Case đã có bҵng cách thêm vào các tác
nhân mӟi cũng như các Use Case mӟi, hoһc là thay đәi đһc tҧ cӫa các Use Case đã có.
Khi bә sung thêm vào mô hình Use Case đang tӗn tҥi, hãy chú ý đӇ không bӓ ra bҩt kǤ
mӝt chӭc năng nào vүn còn đưӧc cҫn tӟi.

5- BIӆU ĐӖ USE CASE

Use Case đưӧc mô tҧ trong ngôn ngӳ UML qua biӇu đӗ Use Case (Use Case Diagram),
và mӝt mô hình Use Case có thӇ đưӧc chia thành mӝt sӕ lưӧng lӟn các biӇu đӗ như thӃ.
Mӝt biӇu đӗ Use Case chӭa các phҫn tӱ mô hình biӇu thӏ hӋ thӕng, tác nhân cũng như
Use Case và chӍ ra các mӕi quan hӋ giӳa các Use Case.

Lӡi mô tҧ nӝi dung Use Case thưӡng đưӧc cung cҩp dưӟi dҥng văn bҧn. Trong UML, lӡi
mô tҧ đó đưӧc coi là thuӝc tính "văn bҧn" (document) cӫa Use Case. Lӡi mô tҧ này bao
chӭa nhӳng thông tin quan trӑng, đӏnh nghĩa các yêu cҫu và chӭc năng cө thӇ. Thay cho
viӋc mô tҧ Use Case bҵng văn bҧn, bҥn cũng có thӇ vӁ mӝt biӇu đӗ hoҥt đӝng (activity
diagram). Mһc dҫu vұy, nên nhӟ rҵng mӝt Use Case cҫn phҧi đưӧc mô tҧ sao cho dӉ hiӇu
và dӉ giao tiӃp đӕi vӟi ngưӡi sӱ dөng, mà nhӳng cҩu trúc phӭc tҥp như mӝt biӇu đӗ hoҥt
đӝng có thӇ gây cҧm giác xa lҥ đӕi vӟi nhӳng ngưӡi không quen sӱ dөng.

Tóm tҳt: Mӝt biӇu đӗ Use Case thӇ hiӋn:

- HӋ thӕng

- Tác nhân

- Use Case.

Ví dө biӇu đӗ Use Case trong UML:

Hình .1- Mӝt ví dө biӇu đӗ Use case trong UML

Trong đó :

- HӋ thӕng đưӧc thӇ hiӋn qua hình chӳ nhұt vӟi tên hӋ thӕng ӣ bên trên

- Tác nhân đưӧc thӇ hiӋn qua kí hiӋu hình nhân

- Use Case đưӧc thӇ hiӋn qua hình ellipse

5.1- HӋ thӕng:

Vì hӋ thӕng là mӝt thành phҫn cӫa mô hình Use Case nên ranh giӟi cӫa hӋ thӕng mà ta
muӕn phát triӇn cҫn phҧi đưӧc đӏnh nghĩa rõ ràng. Xin nhӟ rҵng mӝt hӋ thӕng không phҧi
bao giӡ cũng nhҩt thiӃt là mӝt hӋ thӕng phҫn mӅm; nó có thӇ là mӝt chiӃc máy, hoһc là
mӝt doanh nghiӋp. Đӏnh nghĩa các ranh giӟi và trách nhiӋm cӫa hӋ thӕng không phҧi bao
giӡ cũng là viӋc dӉ dàng, bӣi không phҧi bao giӡ ngưӡi ta cũng rõ ràng nhìn ra tác vө nào
có khҧ năng đưӧc tӵ đӝng hóa tӕt nhҩt ӣ hӋ thӕng này và tác vө nào thì tӕt nhҩt nên thӵc
hiӋn thӫ công hoһc dành cho các hӋ thӕng khác. Mӝt khía cҥnh khác cҫn chú ý là hӋ
thӕng cҫn phҧi lӟn tӟi mӭc đӝ nào trong phiên bҧn đҫu tiên cӫa nó. Cӕ gҳng tӕi đa cho
phiên bҧn đҫu tiên cӫa hӋ thӕng thưӡng là cách mà ngưӡi ta hay thӵc hiӋn, thӃ nhưng
nhӳng mөc tiêu quá tҫm như vұy có thӇ khiӃn cho hӋ thӕng trӣ nên quá lӟn và thӡi gian
đӇ cung cҩp hӋ thӕng quá lâu. Mӝt sáng kiӃn tӕt hơn là xác nhұn cho rõ các chӭc năng
căn bҧn và tұp trung vào viӋc đӏnh nghĩa mӝt kiӃn trúc hӋ thӕng thích hӧp, rõ ràng, có
nӅn tҧng rӝng mӣ đӇ nhiӅu chӭc năng hơn có thӇ đưӧc bә sung vào hӋ thӕng này trong
các phiên bҧn sau.

YӃu tӕ quan trӑng là bҥn phҧi tҥo dӵng đưӧc mӝt bҧn catalog cӫa các khái niӋm (các thӵc
thӇ) trung tâm cùng vӟi các thuұt ngӳ và đӏnh nghĩa thích hӧp trong nhӳng giai đoҥn đҫu
cӫa thӡi kǤ phân tích. Đây chưa phҧi mô hình phҥm vi đӕi tưӧng, mà đúng hơn là mӝt cӕ
gҳng đӇ mô tҧ các thuұt ngӳ cӫa hӋ thӕng hoһc doanh nghiӋp mà chúng ta cҫn mô hình
hóa. Các thuұt ngӳ sau đó sӁ đưӧc dùng đӇ mô tҧ Use Case. Phương thӭc cө thӇ cӫa
catalog này có thӇ rҩt khác nhau; nó có thӇ là mӝt mô hình khái niӋm chӍ ra các mӕi quan
hӋ đơn giҧn hoһc chӍ là mӝt văn bҧn chӭa các thuұt ngӳ cùng lӡi mô tҧ vҳn tҳt nhӳng
thuұt ngӳ này trong thӃ giӟi thӵc.

5.2- Tác nhân:

Mӝt tác nhân là mӝt ngưӡi hoһc mӝt vұt nào đó tương tác vӟi hӋ thӕng, sӱ dөng hӋ thӕng.
Trong khái niӋm "tương tác vӟi hӋ thӕng", ý chúng ta muӕn nói rҵng tác nhân sӁ gӱi
thông điӋp đӃn hӋ thӕng hoһc là nhұn thông điӋp xuҩt phát tӯ hӋ thӕng, hoһc là thay đәi
các thông tin cùng vӟi hӋ thӕng. Nói mӝt cách ngҳn gӑn, tác nhân thӵc hiӋn các Use
Case. Thêm mӝt điӅu nӳa, mӝt tác nhân có thӇ là ngưӡi mà cũng có thӇ là mӝt hӋ thӕng
khác (ví dө như là mӝt chiӃc máy tính khác đưӧc nӕi kӃt vӟi hӋ thӕng cӫa chúng ta hoһc
mӝt loҥi trang thiӃt bӏ phҫn cӭng nào đó tương tác vӟi hӋ thӕng).

Mӝt tác nhân là mӝt dҥng thӵc thӇ (mӝt lӟp), chӭ không phҧi mӝt thӵc thӇ. Tác nhân mô
tҧ và đҥi diӋn cho mӝt vai trò, chӭ không phҧi là mӝt ngưӡi sӱ dөng thұt sӵ và cө thӇ cӫa
hӋ thӕng. NӃu mӝt anh chàng John nào đó muӕn mua hӧp đӗng bҧo hiӇm tӯ mӝt hãng
bҧo hiӇm, thì vai trò cӫa anh ta sӁ là ngưӡi mua hӧp đӗng bҧo hiӇm, và đây mӟi là thӭ mà
chúng ta muӕn mô hình hóa, chӭ không phҧi bҧn thân anh chàng John. Trong sӵ thӵc,
mӝt con ngưӡi cө thӇ có thӇ đóng vai trò làm nhiӅu tác nhân trong mӝt hӋ thӕng: mӝt
nhân viên ngân hàng đӗng thӡi cũng có thӇ là khách hàng cӫa chính ngân hàng đó. Mһt
khác, sӕ lưӧng các vai trò mà mӝt con ngưӡi cө thӇ đưӧc phép đҧm trách trong mӝt hӋ
thӕng cũng có thӇ bӏ hҥn chӃ, ví dө cùng mӝt ngưӡi không đưӧc phép vӯa soҥn hóa đơn
vӯa phê duyӋt hóa đơn đó. Mӝt tác nhân sӁ có mӝt tên, và cái tên này cҫn phҧi phҧn ánh
lҥi vai trò cӫa tác nhân. Cái tên đó không đưӧc phҧn ánh lҥi mӝt thӵc thӇ riêng biӋt cӫa
mӝt tác nhân, mà cũng không phҧn ánh chӭc năng cӫa tác nhân đó.

Mӝt tác nhân giao tiӃp vӟi hӋ thӕng bҵng cách gӱi hoһc là nhұn thông điӋp, giӕng như
khái niӋm chúng ta đã quen biӃt trong lұp trình hưӟng đӕi tưӧng. Mӝt Use Case bao giӡ
cũng đưӧc kích hoҥt bӣi mӝt tác nhân gӱi thông điӋp đӃn cho nó. Khi mӝt Use Case đưӧc
thӵc hiӋn, Use Case có thӇ gӱi thông điӋp đӃn mӝt hay là nhiӅu tác nhân. Nhӳng thông
điӋp này cũng có thӇ đӃn vӟi các tác nhân khác, bên cҥnh chính tác nhân đã kích hoҥt và
gây ra Use Case.

Tác nhân cũng có thӇ đưӧc xӃp loҥi. Mӝt tác nhân chính (Primary Actor) là tác nhân sӱ
dөng nhӳng chӭc năng căn bҧn cӫa hӋ thӕng, tӭc là các chӭc năng chính. Ví dө, trong
mӝt hӋ thӕng bҧo hiӇm, mӝt tác nhân căn bҧn có thӇ là tác nhân xӱ lý viӋc ghi danh và
quҧn lý các hӧp đӗng bҧo hiӇm. Mӝt tác nhân phө (secondary actor) là tác nhân sӱ dөng
các chӭc nһng phө cӫa hӋ thӕng, ví dө như các chӭc năng bҧo trì hӋ thӕng như quҧn trӏ
ngân hàng dӳ liӋu, giao tiӃp, back-up và các tác vө quҧn trӏ khác. Mӝt ví dө cho tác nhân
phө có thӇ là nhà quҧn trӏ hoһc là mӝt nhân viên sӱ dөng chӭc năng trong hӋ thӕng đӇ rút
ra các thông tin thӕng kê vӅ doanh nghiӋp. Cҧ hai loҥi tác nhân này đӅu đưӧc mô hình
hóa đӇ đҧm bҧo mô tҧ đҫy đӫ các chӭc năng cӫa hӋ thӕng, mһc dù các chӭc năng chính
mӟi thұt sӵ nҵm trong mӕi quan tâm chӫ yӃu cӫa khách hàng.

Tác nhân còn có thӇ đưӧc đӏnh nghĩa theo dҥng tác nhân chӫ đӝng (active actor) hay tác
nhân thө đӝng (passive actor). Mӝt tác nhân chӫ đӝng là tác nhân gây ra Use Case, trong
khi tác nhân thө đӝng không bao giӡ gây ra Use Case mà chӍ tham gia vào mӝt hoһc là
nhiӅu Use Case.

5.3- Tìm tác nhân:

Khi nhұn diӋn tác nhân, có nghĩa là chúng ta lӑc ra các thӵc thӇ đáng quan tâm theo khía
cҥnh sӱ dөng và tương tác vӟi hӋ thӕng. Sau đó chúng ta có thӇ thӱ đһt mình vào vӏ trí
cӫa tác nhân đӇ cӕ gҳng nhұn ra các yêu cҫu và đòi hӓi cӫa tác nhân đӕi vӟi hӋ thӕng và
xác đӏnh tác nhân cҫn nhӳng Use Case nào. Có thӇ nhұn diӋn ra các tác nhân qua viӋc trҧ
lӡi mӝt sӕ các câu hӓi như sau:

- Ai sӁ sӱ dөng nhӳng chӭc năng chính cӫa hӋ thӕng (tác nhân chính)?

- Ai sӁ cҫn sӵ hӛ trӧ cӫa hӋ thӕng đӇ thӵc hiӋn nhӳng tác vө hàng ngày cӫa hӑ?

- Ai sӁ cҫn bҧo trì, quҧn trӏ và đҧm bҧo cho hӋ thӕng hoҥt đӝng (tác nhân phө)?

- HӋ thӕng sӁ phҧi xӱ lý và làm viӋc vӟi nhӳng trang thiӃt bӏ phҫn cӭng nào?

- HӋ thӕng cҫn phҧi tương tác vӟi các hӋ thӕng khác nào? Nhóm các hӋ thӕng này
đưӧc chia ra làm hai nhóm, nhóm kích hoҥt cho mӕi quan hӋ vӟi hӋ thӕng, và nhóm mà
hӋ thӕng cҫn phҧi xây dӵng cӫa chúng ta sӁ thiӃt lұp quan hӋ. Khái niӋm hӋ thӕng bao
gӗm cҧ các hӋ thӕng máy tính khác cũng như các ӭng dөng khác trong chính chiӃc máy
tính mà hӋ thӕng này sӁ hoҥt đӝng.

- Ai hay cái gì quan tâm đӃn kӃt quҧ (giá trӏ) mà hӋ thӕng sӁ sҧn sinh ra?

Khi đi tìm nhӳng ngưӡi sӱ dөng hӋ thӕng, đӯng quan sát nhӳng ngưӡi đang ngӗi ӣ trưӟc
màn hình máy tính. Nên nhӟ rҵng, ngưӡi sӱ dөng có thӇ là bҩt kǤ ngưӡi nào hay bҩt kǤ
vұt nào tương tác hoһc trӵc tiӃp hoһc gián tiӃp vӟi hӋ thӕng và sӱ dөng các dӏch vө cӫa
hӋ thӕng này đӇ đҥt đӃn mӝt kӃt quҧ nào đó. Đӯng quên rҵng mô hình hóa Use Case đưӧc
thӵc hiӋn đӇ mô hình hóa mӝt doanh nghiӋp, vì thӃ tác nhân thưӡng thưӡng là khách
hàng cӫa doanh nghiӋp đó. Tӯ đó suy ra hӑ không phҧi là ngưӡi sӱ dөng theo nghĩa đơn
giҧn và trӵc tiӃp là ngưӡi ngӗi trưӟc màn hình máy tính và thao tác vӟi máy tính.
ĐӇ có thӇ nhұn dҥng đưӧc tӕt nhiӅu tác nhân khác nhau, hãy tiӃn hành nghiên cӭu nhӳng
ngưӡi sӱ dөng cӫa hӋ thӕng hiӋn thӡi (mӝt hӋ thӕng thӫ công hoһc mӝt hӋ thӕng đang tӗn
tҥi), hӓi xem hӑ đóng nhӳng vai trò nào khi thӵc thi công viӋc hàng ngày cӫa hӑ vӟi hӋ
thӕng. Cũng ngưӡi sӱ dөng đó có thӇ thӵc thi nhiӅu vai trò khác nhau tҥi nhiӅu thӡi điӇm
khác nhau, tùy thuӝc vào viӋc chӭc năng nào trong hӋ thӕng đang đưӧc sӱ dөng.

Xin nhҳc lҥi, mӝt tác nhân là mӝt vai trò (mӝt lӟp), chӭ không phҧi mӝt thӵc thӇ riêng lҿ.
Mһc dù vұy, khi cung cҩp ví dө là mӝt vài các thӵc thӇ cӫa mӝt tác nhân, bҥn có thӇ đҧm
bҧo rҵng tác nhân đó thұt sӵ tӗn tҥi. Mӝt tác nhân phҧi có mӝt sӵ liên kӃt (Association)
nào đó vӟi mӝt hoһc là nhiӅu Use Case. Mһc dù có nhӳng tác nhân có thӇ không kích
hoҥt nên mӝt Use Case nào, nhưng tác nhân đó sӁ giao tiӃp ít nhҩt vӟi mӝt Use Case tҥi
mӝt thӡi điӇm nào đó. Cҫn phҧi đһt tên cho tác nhân làm sao đӇ tên phҧn ánh đúng vai trò
cӫa tác nhân đó trong hӋ thӕng.

5.- BiӇu diӉn tác nhân trong ngôn ngӳ UML:

Tác nhân trong UML là mӝt lӟp vӟi biӋt ngӳ "Actor" (Tác nhân) và tên cӫa lӟp này là tên
cӫa tác nhân (phҧn ánh vai trò cӫa tác nhân). Mӝt lӟp tác nhân có thӇ vӯa có thuӝc tính
(attribute) lүn hành vi (method) cũng như mӝt thuӝc tính tài liӋu (document) mô tҧ tác
nhân đó. Mӝt lӟp tác nhân có mӝt biӇu tưӧng chuҭn hóa, biӇu tưӧng "hình nhân":

Hình .2- biӇu tưӧng tác nhân trong UML

5.5- Use Case:

Mӝt Use Case là đҥi diӋn cho mӝt chӭc năng nguyên vҽn mà mӝt tác nhân nhұn đưӧc.
Mӝt Use Case trong ngôn ngӳ UML đưӧc đӏnh nghĩa là mӝt tұp hӧp cӫa các chuӛi hành
đӝng mà mӝt hӋ thӕng thӵc hiӋn đӇ tҥo ra mӝt kӃt quҧ có thӇ quan sát đưӧc, tӭc là mӝt
giá trӏ đӃn vӟi mӝt tác nhân cө thӇ. Nhӳng hành đӝng này có thӇ bao gӗm viӋc giao tiӃp
vӟi mӝt loҥt các tác nhân cũng như thӵc hiӋn tính toán và công viӋc nӝi bӝ bên trong hӋ
thӕng.

Các tính chҩt tiêu biӇu cӫa mӝt Use Case là:

- Mӝt Use Case bao giӡ cũng đưӧc gây ra bӣi mӝt tác nhân, đưӧc thӵc hiӋn nhân
danh mӝt tác nhân nào đó. Tác nhân phҧi ra lӋnh cho hӋ thӕng đӇ thӵc hiӋn Use Case đó,
dù là trӵc tiӃp hay gián tiӃp. HiӃm khi có tác nhân không liên quan đӃn viӋc gây ra mӝt
Use Case nào đó.
 - Mӝt Use Case phҧi cung cҩp mӝt giá trӏ cho mӝt tác nhân. Giá trӏ đó không phҧi
bao giӡ cũng cҫn thiӃt phҧi nәi trӝi ra ngoài, nhưng luôn phҧi đưӧc thҩy rõ.

- Mӝt Use Case là phҧi hoàn tҩt. Mӝt trong nhӳng lӛi thưӡng gһp là sҿ chia mӝt
Use Case thành các Use Case nhӓ hơn, và các Use Case này thӵc thi lүn nhau giӕng như
viӋc gӑi hàm cho mӝt ngôn ngӳ lұp trình. Mӝt Use Case sӁ không đưӧc coi là hoàn tҩt
chӯng nào mà giá trӏ cuӕi cùng cӫa nó chưa đưӧc sҧn sinh ra, thұm chí ngay cҧ khi đã
xҭy ra nhiӅu đӝng tác giao tiӃp (ví dө như đӕi thoҥi vӟi ngưӡi sӱ dөng).

Use Case đưӧc nӕi vӟi tác nhân qua liên kӃt (association). Đưӡng liên kӃt chӍ ra nhӳng
tác nhân nào giao tiӃp vӟi Use Case nào. Mӕi liên kӃt bình thưӡng ra là mӝt mӕi quan hӋ
1-1 và không có hưӟng. ĐiӅu đó muӕn nói lên rҵng mӝt thӵc thӇ cӫa lӟp tác nhân sӁ giao
tiӃp vӟi mӝt thӵc thӇ cӫa mӝt Use Case và cҧ hai có thӇ giao tiӃp vӟi nhau trong cҧ hai
chiӅu. Mӝt Use Case sӁ đưӧc đһt tên theo mӝt thӵc thӇ mà Use Case sӁ thӵc hiӋn, ví dө
như ký hӧp đӗng bҧo hiӇm, cұp nhұt danh sách, v.v«, và thưӡng là mӝt cөm tӯ hơn là
chӍ mӝt tӯ riêng lҿ.

Mӝt Use Case là mӝt lӟp, chӭ không phҧi mӝt thӵc thӇ. Nó mô tҧ trӑn vҽn mӝt chӭc
năng, kӇ cҧ các giҧi pháp bә sung và thay thӃ có thӇ có, các lӛi có thӇ xҧy ra cũng như
nhӳng ngoҥi lӋ có thӇ xҧy ra trong quá trình thӵc thi. Mӝt kӃt quҧ cӫa sӵ thӵc thӇ hóa
mӝt Use Case đưӧc gӑi là mӝt cҧnh kӏch (scenario) và nó đҥi diӋn cho mӝt sӵ sӱ dөng cө
thӇ cӫa hӋ thӕng (mӝt đưӡng dүn thӵc thi riêng biӋt qua hӋ thӕng). Ví dө mӝt cҧnh kӏch
cӫa Use Case "Ký hӧp đӗng bҧo hiӇm" có thӇ là "John liên hӋ vӟi hӋ thӕng qua điӋn thoҥi
rӗi sau đó ký hӧp đӗng bҧo hiӇm ô tô cho chiӃc xe Toyota Carolla mà anh ta vӯa mua."

5.6- Tìm Use Case:

Quá trình tìm các Use Case bҳt đҫu vӟi các tác nhân đã đưӧc xác đӏnh ӣ phҫn trưӟc. Đӕi
vӟi mӛi tác nhân, hãy hӓi các câu hӓi sau:

a. Tác nhân này cҫn nhӳng chӭc năng nào tӯ hӋ thӕng? Hành đӝng chính cӫa tác
nhân là gì ?.

Ví dө cho mӝt giao dӏch rút tiӅn bên máy ATM trong mӝt nhà băng lҿ, các hành đӝng
chính cӫa khách hàng (tác nhân) có thӇ là :

- Đút thҿ vào máy ATM

- Nhұp password

- Nhұp loҥi chuyӇn dӏch

- Nhұp sӕ tiӅn mһt muӕn rút ra

- Yêu cҫu vӅ loҥi tiӅn

 - Nhһt tiӅn ra tӯ máy

- Rút thҿ và tӡ in kӃt quҧ giao dӏch

b. Tác nhân có cҫn phҧi đӑc, phҧi tҥo, phҧi hӫy bӓ, phҧi sӱa chӳa, hay là lưu trӳ
mӝt loҥi thông tin nào đó trong hӋ thӕng?

Ví dө :

- Nhân viên nhà băng liӋu có quyӅn truy xuҩt hay thay đәi mӭc tiӅn lãi?

- Khách hàng có thӇ thay đәi password cӫa mình.

c. Tác nhân có cҫn phҧi báo cho hӋ thӕng biӃt vӅ nhӳng sӵ kiӋn nào đó? Nhӳng
sӵ kiӋn như thӃ sӁ đҥi diӋn cho nhӳng chӭc năng nào?

Ví dө :

- Khách hàng kӃt thúc tài khoҧn, nhân viên cung cҩp nhӳng thông tin này cho hӋ
thӕng.

- Có mӝt chương trình đҫu tư mӟi, các chi tiӃt cӫa chương trình này sӁ phҧi đưӧc
nhân viên nhà băng nhұp vào hӋ thӕng.

d. HӋ thӕng có cҫn phҧi thông báo cho Actor vӅ nhӳng thay đәi bҩt ngӡ trong nӝi
bӝ hӋ thӕng?

- Trong tài khoҧn còn quá ít tiӅn.

- Ba kǤ liên tiӃp tiӅn lương chưa đә vӅ tài khoҧn.

e. Công viӋc hàng ngày cӫa tác nhân có thӇ đưӧc đơn giҧn hóa hoһc hӳu hiӋu hóa
qua các chӭc năng mӟi trong hӋ thӕng (thưӡng đây là nhӳng chӭc năng tiêu biӇu chưa
đưӧc tӵ đӝng hóa trong hӋ thӕng)?

f. Các câu hӓi khác:

- Use Case có thӇ đưӧc gây ra bӣi các sӵ kiӋn nào khác?

Ví dө :

Sӵ kiӋn thӡi gian: Cuӕi tháng, hӃt hҥn đҫu tư.

Sӵ kiӋn bình thưӡng cӫa hӋ thӕng: Tӵ đӝng chuyӇn tiӅn theo các lӋnh xác đӏnh
trưӟc.
 Các sӵ kiӋn bҩt bình thưӡng: Hӧp đӗng đҫu tư kӃt thúc trưӟc thӡi hҥn.

- HӋ thӕng cҫn nhӳng thông tin đҫu vào/đҫu ra nào? Nhӳng thông tin đҫu vào/đҫu
ra đó tӯ đâu tӟi và sӁ đi đâu?

- Khó khăn và thiӃu hөt chính trong hӋ thӕng hiӋn thӡi nҵm ӣ đâu (thӫ công /tӵ
đӝng hóa)?

Đӕi vӟi nhóm câu hӓi cuӕi không có nghĩa là Use Case ӣ đây không có tác nhân, mà tác
nhân sӁ đưӧc nhұn ra chӍ khi chúng ta nhұn diӋn ra các Use Case này và sau đó xác đӏnh
tác nhân dӵa trên cơ sӣ là Use Case. Xin nhҳc lҥi, mӝt Use Case bao giӡ cũng phҧi đưӧc
liên kӃt vӟi ít nhҩt mӝt tác nhân.

5.7- Ví dө tìm Use Case:

Nhà băng ABC đưa ra các yêu cҫu sau:

- Mӝt khách hàng có thӇ muӕn gӱi tiӅn vào, rút tiӅn ra hoһc đơn giҧn kiӇm tra lҥi
sӕ tiӅn trong tài khoҧn cӫa anh ta qua máy tӵ đӝng rút tiӅn (ATM). Khi đưa tiӅn vào hoһc
rút tiӅn ra, cҫn phҧi ghi ra giҩy kӃt quҧ nhӳng chuyӇn dӏch đã thӵc hiӋn và trao tӡ giҩy
này cho khách hàng.

Quan sát các chӭc năng căn bҧn và các thành phҫn tham gia, ta thҩy có hai tác nhân dӉ
nhұn ra nhҩt là khách hàng và nhân viên thu ngân.

Qua đó, có thӇ nhân dҥng các Use Case sau:

- Gӱi tiӅn vào.

- Rút tiӅn ra.

- KiӇm tra mӭc tiӅn trong tài khoҧn

- Thӵc hiӋn các chuyӇn dӏch nӝi bӝ hӋ thӕng

- In kӃt quҧ các chuyӇn dӏch đã thӵc hiӋn.

 Hình .3 ± Các Use case trong hӋ thӕng ATM

Use Case gӱi tiӅn vào và rút tiӅn ra phө thuӝc vào Use Case thӵc hiӋn các chuyӇn dӏch
trong nӝi bӝ hӋ thӕng, viӋc thӵc hiӋn này vӅ phҫn nó lҥi phө thuӝc vào chӭc năng in ra
các công viӋc đã đưӧc thӵc hiӋn. KiӇm tra mӭc tiӅn trong tài khoҧn là mӝt Use Case đӝc
lұp, không phө thuӝc vào các Use Case khác.

6- CÁC BIӂN THӆ (VARIATIONS) TRONG MӜT USE CASE

Mӛi Use Case sӁ có mӝt dòng hành đӝng chính (Basic Course). Đó là tiӃn trình bình
thưӡng hay tiӃn trình mong đӧi đӕi vӟi Use Case này.

Ngoài ra, có thӇ còn có mӝt hay nhiӅu dòng hành đӝng thay thӃ (Alternative) khác.
Chúng có thӇ đưӧc chia làm hai nhóm chính:

- Thay thӃ bình thưӡng (Normal Alternative)

- ĐiӅu kiӋn gây lӛi (Error Condidtions)

Nhӳng gì mang tính bình thưӡng hơn trong Use Case đưӧc gӑi là Thay thӃ bình thưӡng.

Có thӇ miêu tҧ các dòng hành đӝng thay thӃ bҵng tӯ ngӳ (xem phҫn tài liӋu Use Case ).

Ví dө mӝt khách hàng có thӇ chӑn các loҥi giao dӏch sau cӫa ATM:

- Gӱi tiӅn vào

- Rút tiӅn ra
 - KiӇm tra mӭc tiӅn trong tài khoҧn

Đây là nhӳng ví dө cho các dòng hành đӝng thay thӃ bình thưӡng.

ĐiӅu kiӋn gây lӛi đҥi diӋn cho nhӳng bưӟc tiӃn hành bҩt bình thưӡng trong mӝt Use
Case. Cҫn phҧi tính trưӟc đӃn nhӳng điӅu kiӋn gây lӛi đó, ví dө :

- Mӭc tiӅn trong tài khoҧn không đӫ đӇ tiӃn hành giao dӏch

- Password không đúng

- ATM bӏ nghӁn thҿ

Hình sau nêu bұt dòng hành đӝng chính và nhӳng dòng hành đӝng thay thӃ cũng như sӵ
khác biӋt cӫa chúng đӕi vӟi tiӃn trình mong đӧi cӫa Use Case.

Hình . ± Các tiӃn trình trong hӋ thӕng ATM

7- QUAN Hӊ GIӲA CÁC USE CASE
Có ba loҥi quan hӋ Use Case: Quan hӋ mӣ rӝng, quan hӋ sӱ dөng và quan hӋ tҥo nhóm.
Quan hӋ mӣ rӝng và quan hӋ sӱ dөng là hai dҥng khác nhau cӫa tính thӯa kӃ. Quan hӋ tҥo
nhóm là mӝt phương cách đӇ đһt nhiӅu Use Case chung vӟi nhau vào trong mӝt gói.

7.1- Quan hӋ mӣ rӝng

NhiӅu khi trong quá trình phát triӇn Use Case, ngưӡi ta thҩy mӝt sӕ Use Case đã tӗn tҥi
cung cҩp mӝt phҫn nhӳng chӭc năng cҫn thiӃt cho mӝt Use Case mӟi. Trong mӝt trưӡng
hӧp như vұy, có thӇ đӏnh nghĩa mӝt Use Case mӟi là Use Case cũ cӝng thêm mӝt phҫn
mӟi. Mӝt Use Case như vұy đưӧc gӑi là mӝt Use Case mӣ rӝng (Extended Use Case ).
Trong quan hӋ mӣ rӝng, Use Case gӕc (Base Use Case ) đưӧc dùng đӇ mӣ rӝng phҧi là
mӝt Use Case hoàn thiӋn. Use Case mӣ rӝng không nhҩt thiӃt phҧi sӱ dөng toàn bӝ hành
vi cӫa Use Case gӕc.

BiӇu đӗ sau chӍ ra Use Case ³Ký hӧp đӗng mua ô tô´ là Use Case mӣ rӝng cӫa "Ký hӧp
đӗng bҧo hiӇm´.

Hình .5 - Quan hӋ mӣ rӝng giӳa các Use Case

Quan hӋ mӣ rӝng giӳa các Use Case đưӧc biӇu thӏ bҵng đoҥn thҷng vӟi hình tam giác
rӛng trӓ vӅ phía Use Case đưӧc dùng đӇ mӣ rӝng, đi kèm vӟi stereotype <<extends>>.

7.2- Quan hӋ sӱ dөng

Khi mӝt nhóm các Use Case cùng chung mӝt hành vi nào đó thì hành vi này có thӇ đưӧc
tách riêng ra thành mӝt Use Case riêng biӋt và nó có thӇ đưӧc sӱ dөng bӣi các Use Case
kia, mӝt mӕi quan hӋ như vұy đưӧc gӑi là quan hӋ sӱ dөng.

Trong quan hӋ sӱ dөng, phҧi sӱ dөng toàn bӝ Use Case khái quát hóa, nói mӝt cách khác,
ta có mӝt Use Case này sӱ dөng toàn bӝ mӝt Use Case khác. Các hành đӝng trong Use
Case khái quát hóa không cҫn phҧi đưӧc sӱ dөng trong cùng mӝt tiӃn trình. Chúng có thӇ
đưӧc trӝn lүn vӟi các hành đӝng xҧy ra trong Use Case chuyên biӋt hóa.

Hình .6 - Quan hӋ sӱ dөng giӳa các Use Case

Quan hӋ sӱ dөng giӳa các Use Case đưӧc biӇu thӏ bҵng đoҥn thҷng vӟi hình tam giác
rӛng trӓ vӅ phía Use Case đưӧc sӱ dөng, đi kèm vӟi stereotype <<uses>>.

7.3- Quan hӋ chung nhóm

Khi mӝt sӕ các Use Case cùng xӱ lý các chӭc năng tương tӵ hoһc có thӇ liên quan đӃn
nhau theo mӝt phương thӭc nào đó, ngưӡi ta thưӡng nhóm chúng lҥi vӟi nhau.

Nhóm các Use Case đưӧc thӵc hiӋn bҵng khái niӋm "Gói" (Package) cӫa UML. Gói
không cung cҩp giá trӏ gia tăng cho thiӃt kӃ.

Ví dө: tҩt cҧ các Use Case có liên quan đӃn sӵ tương tác giӳa khách hàng và nhân viên
thu ngân sӁ đưӧc nhóm thành "Package Khách hàng- N/v thu ngân"

Hình .7 ± Package cӫa UML

Tóm tҳt vӅ Use Case vӟi máy ATM trong ngân hàng lҿ:
Cho tӟi nay chúng ta đã xác đӏnh đưӧc mӝt vài Use Case, phân tích dòng hành đӝng
chính cũng như các dòng hành đӝng thay thӃ, cũng như rút ra các mӕi quan hӋ giӳa
chúng. BiӇu đӗ sau tәng hӧp nhӳng thông tin đã thu thұp đưӧc vӅ nhóm các Use Case căn
bҧn cӫa mӝt hӋ thӕng ATM.

Hình .8 - BiӇu đӗ mӝt sӕ Use Case trong hӋ thӕng ATM

8- MIÊU TҦ USE CASE

Như đã trình bày, lӡi miêu tҧ mӝt Use Case thưӡng đưӧc thӵc hiӋn trong văn bҧn. Đây là
lӡi đһc tҧ đơn giҧn và nhҩt quán vӅ viӋc các tác nhân và các Use Case (hӋ thӕng) tương
tác vӟi nhau ra sao. Nó tұp trung vào ӭng xӱ đӕi ngoҥi cӫa hӋ thӕng và không đӅ cұp tӟi
viӋc thӵc hiӋn nӝi bӝ bên trong hӋ thӕng. Ngôn ngӳ và các thuұt ngӳ đưӧc sӱ dөng trong
lӡi miêu tҧ chính là ngôn ngӳ và các thuұt ngӳ đưӧc sӱ dөng bӣi khách hàng/ngưӡi dùng.

Văn bҧn miêu tҧ cҫn phҧi bao gӗm nhӳng điӇm sau:

- Mөc đích cӫa Use Case: Mөc đích chung cuӝc cӫa Use Case là gì? Cái gì cҫn
phҧi đưӧc đҥt tӟi? Use Case nói chung đӅu mang tính hưӟng mөc đích và mөc đích cӫa
mӛi Use Case cҫn phҧi rõ ràng.

- Use Case đưӧc khӣi chҥy như thӃ nào: Tác nhân nào gây ra sӵ thӵc hiӋn Use
Case này? Trong hoàn cҧnh nào?

- Chuӛi các thông điӋp giӳa tác nhân và Use Case: Use Case và các tác nhân trao
đәi thông điӋp hay sӵ kiӋn nào đӇ thông báo lүn cho nhau, cұp nhұt hoһc nhұn thông tin
và giúp đӥ nhau quyӃt đӏnh? YӃu tӕ nào sӁ miêu tҧ dòng chҧy chính cӫa các thông điӋp
giӳa hӋ thӕng và tác nhân, và nhӳng thӵc thӇ nào trong hӋ thӕng đưӧc sӱ dөng hoһc là bӏ
thay đәi?

- Dòng chҧy thay thӃ trong mӝt Use Case: Mӝt Use Case có thӇ có nhӳng dòng
thӵc thi thay thӃ tùy thuӝc vào điӅu kiӋn. Hãy nhҳc đӃn các yӃu tӕ này, nhưng chú ý đӯng
miêu tҧ chúng quá chi tiӃt đӃn mӭc đӝ chúng có thӇ ³che khuҩt³ dòng chҧy chính cӫa các
hoҥt đӝng trong trưӡng hӧp căn bҧn. Nhӳng đӝng tác xӱ lý lӛi đһc biӋt sӁ đưӧc miêu tҧ
thành các Use Case khác.

- Use Case sӁ kӃt thúc vӟi mӝt giá trӏ đӕi vӟi tác nhân như thӃ nào: Hãy miêu tҧ
khi nào Use Case đưӧc coi là đã kӃt thúc, và loҥi giá trӏ mà nó cung cҩp đӃn tác nhân.

Hãy nhӟ rҵng lӡi miêu tҧ này sӁ xác đӏnh nhӳng gì đưӧc thӵc thi có liên quan đӃn tác
nhân bên ngoài, chӭ không phҧi nhӳng sӵ viӋc đưӧc thӵc hiӋn bên trong hӋ thӕng. Văn
bҧn phҧi rõ ràng, nhҩt quán, khiӃn cho khách hàng có thӇ dӉ dàng hiӇu và thҭm tra chúng
(đӇ rӗi đӗng ý rҵng nó đҥi diӋn cho nhӳng gì mà anh/cô ta muӕn tӯ phía hӋ thӕng). Tránh
dùng nhӳng câu văn phӭc tҥp, khó diӉn giҧi và dӉ hiӇu lҫm.

Mӝt Use Case cũng có thӇ đưӧc miêu tҧ qua mӝt biӇu đӗ hoҥt đӝng. BiӇu đӗ hoҥt đӝng
này chӍ ra chuӛi các hành đӝng, thӭ tӵ cӫa chúng, các quyӃt đӏnh chӑn lӵa đӇ xác đӏnh
xem hành đӝng nào sau đó sӁ đưӧc thӵc hiӋn.

ĐӇ bә sung cho lӡi miêu tҧ mӝt Use Case, ngưӡi ta thưӡng đưa ra mӝt loҥt các cҧnh kӏch
cө thӇ đӇ minh hӑa điӅu gì sӁ xҧy ra mӝt khi Use Case này đưӧc thӵc thӇ hóa. Lӡi miêu
tҧ cҧnh kӏch minh hӑa mӝt trưӡng hӧp đһc biӋt, khi cҧ tác nhân lүn Use Case đӅu đưӧc
coi là mӝt thӵc thӇ cө thӇ. Khách hàng có thӇ dӉ dàng hiӇu hơn toàn bӝ mӝt Use Case
phӭc tҥp nӃu có nhӳng cҧnh kӏch đưӧc miêu tҧ thӵc tiӉn hơn, minh hӑa lҥi lӕi ӭng xӱ và
phương thӭc hoҥt đӝng cӫa hӋ thӕng. Nhưng xin nhӟ rҵng, mӝt lӡi miêu tҧ cҧnh kӏch chӍ
là mӝt sӵ bә sung chӭ không phҧi là ӭng cӱ viên đӇ thay thӃ cho lӡi miêu tҧ Use Case.

Sau khi các Use Case đã đưӧc miêu tҧ, mӝt hoҥt đӝng và mӝt công viӋc đһc biӋt cҫn phҧi
thӵc hiӋn là thҭm tra xem các mӕi quan hӋ (đã đӅ cұp tӟi trong phҫn 2.7) có đưӧc nhұn
diӋn không. Trưӟc khi tҩt cҧ các Use Case đưӧc miêu tҧ, nhà phát triӇn chưa thӇ có đưӧc
nhӳng kiӃn thӭc hoàn tҩt và tәng thӇ đӇ xác đӏnh các mӕi quan hӋ thích hӧp, thӱ nghiӋm
làm theo phương thӭc đó có thӇ sӁ dүn đӃn mӝt tình huӕng nguy hiӇm. Trong thӡi gian
thӵc hiӋn công viӋc này, hãy trҧ lӡi các câu hӓi sau:

- Tҩt cҧ các tác nhân liên quan đӃn mӝt Use Case có mӕi liên kӃt giao tiӃp vӟi Use
Case đó không?

- Có tӗn tҥi nhӳng sӵ tương tӵ giӳa mӝt loҥt các tác nhân minh hӑa mӝt vai trò
chung và nhóm này liӋu có thӇ đưӧc miêu tҧ là mӝt lӟp tác nhân căn bҧn (base class)?
 - Có tӗn tҥi nhӳng sӵ tương tӵ giӳa mӝt loҥt các Use Case, minh hӑa mӝt dòng
chҧy hành đӝng chung? NӃu có, liӋu điӅu này có thӇ đưӧc miêu tҧ là mӝt mӕi quan hӋ sӱ
dөng đӃn vӟi mӝt Use Case khác?

- Có tӗn tҥi nhӳng trưӡng hӧp đһc biӋt cӫa mӝt Use Case có thӇ đưӧc miêu tҧ là
mӝt mӕi quan hӋ mӣ rӝng?

- Có tӗn tҥi mӝt tác nhân nào hay mӝt Use Case nào không có mӕi liên kӃt giao
tiӃp? NӃu có, chҳc chҳn ӣ đây đã có chuyӋn lҫm lҥc, sai trái: Tҥi sao lҥi xuҩt hiӋn tác
nhân này?

- Có lӡi yêu cҫu nào vӅ chӭc năng đã đưӧc xác đӏnh, nhưng lҥi không đưӧc bҩt kǤ
mӝt Use Case nào xӱ lý? NӃu thӃ, hãy tҥo mӝt Use Case cho yêu cҫu đó.

Văn bҧn miêu tҧ mӝt Use Case đơn giҧn:

Ví dө Use Case "Cung Cҩp Thông Tin VӅ Mӝt Tài Khoҧn Tҥi Nhà Băng ABC´: Sau khi
phân tích hӋ thӕng, ta nhұn thҩy cҫn có mӝt Use Case đӇ in lên màn hình cӫa nhân viên
nhà băng tҩt cҧ nhӳng chi tiӃt vӅ mӝt tài khoҧn cӫa mӝt khách hàng.

Đһc tҧ Use Case:

Chi tiӃt tài khoҧn: )) '
 +



Sӕ Use Case: UCSEC35

Miêu tҧ ngҳn: )) ' , - .
 +



Use Case "chi tiӃt tài khoҧn" cho phép nhân viên nhà băng xem các chi tiӃt cӫa mӝt tài
khoҧn mà anh ta đӏnh tìm hiӇu.

Dòng chҧy các sӵ kiӋn: )) /0 1 

Nhân viên chӑn Chi TiӃt Tài Khoҧn trên menu. Mӝt con đưӡng khác đӇ chӍ ra các thông
tin chi tiӃt cӫa tài khoҧn là gӑi tӯ Màn Hình Tóm Tҳt Thông Tin VӅ Tài Khoҧn (xem Use
Case sӕ UCSEC99).

Dòng hành đӝng chính: )) /0 1  2

Mӛi khách hàng sӁ có mӝt sӕ đӏnh danh gӑi là CustomerId. Mӝt khách hàng có thӇ có
nhiӅu tài khoҧn. Sau khi nhân viên nhұp CustomerId vào hӋ thӕng, màn hình phҧi in ra tҩt
cҧ nhӳng tài khoҧn thuӝc vӅ khách hàng này và thuӝc vӅ nhà băng ABC, rҧi rác tҥi tҩt cҧ
các chi nhánh. Khi chӑn tiӃp loҥi tài khoҧn và sӕ tài khoҧn, các chi tiӃt cӫa tài khoҧn
mong muӕn sӁ đưӧc in ra.
Loҥi tài khoҧn tiӃt kiӋm: NӃu loҥi tài khoҧn đưӧc chӑn là tài khoҧn tiӃt kiӋm, thì theo Use
Case sӕ UCSEC45, các chi tiӃt sau đây sӁ đưӧc in ra:

uMӭc tiӅn hiӋn có

uCác tӡ sec chưa thanh toán

uLưӧng tiӅn tín dөng đưӧc phép

uLưӧng tiӅn lãi cho tӟi ngày hôm nay

uLưӧng tiӅn tӕi thiӇu cҫn phҧi có trong tài khoҧn

Loҥi tài khoҧn đҫu tư: NӃu loҥi tài khoҧn đưӧc chӑn là loҥi đҫu tư, thì theo Use Case sӕ
UCSEC46, các chi tiӃt sau đây sӁ đưӧc in ra.

uHҥn đҫu tư

uSӕ tiӅn đҫu tư

uNgày đҫu tư

uLưӧng tiӅn cuӕi hҥn

uNgày cuӕi hҥn

uTӹ lӋ lӡi

Dòng hành đӝng thay thӃ: )) 3 1 



Không tìm thҩy chi tiӃt: Khi chӑn mӝt sӕ tài khoҧn không thích hӧp (không có tài khoҧn
tương ӭng) dù vì lý do chӭc năng hay kӻ thuұt, theo Use Case sӕ UCSEC12, hӋ thӕng sӁ
đưa ra mӝt màn hình báo lӛi.

ĐiӅu kiӋn thoát: ))
 +

  4   56

Nút Thoát: Khi chӑn nút thoát, ngưӡi sӱ dөng sӁ quay trӣ lҥi màn hình chính.

Nút Xem Thêm: Khi chӑn nút này, ngưӡi sӱ dөng sӁ đưӧc yêu cҫu chӑn loҥi tài khoҧn tӯ
mӝt danh sách đә xuӕng.

Nút Xem Giao Dӏch: Khi chӑn nút này, ngưӡi sӱ dөng sӁ đưӧc chuyӇn sang màn hình
"Giao dӏch" và theo Use Case sӕ UCSEC91, màn hình sӁ chӍ ra nhӳng giao dӏch đã xҧy ra
đӕi vӟi tài khoҧn, bên cҥnh nhӳng chi tiӃt chính cӫa tài khoҧn.
Nút Yêu Cҫu In KӃt Quҧ: Khi chӑn phҫn thӵc đơn này, kӃt quҧ giao dӏch theo Use Case
sӕ UCSEC70 sӁ đưӧc in ra ӣ mӝt máy in đӏa phương nӕi trӵc tiӃp vӟi máy tính cӫa nhân
viên.

Các yêu cҫu đһc biӋt: ))  ' ( 7 8*

Theo Use Case sӕ UCSEC110, hӋ thӕng có khҧ năng in lên màn hình bҵng nhӳng ngôn
ngӳ khác. Chӭc năng này sӁ đưӧc kích hoҥt khi ngưӡi sӱ dөng chӑn mөc Ngoҥi Ngӳ trên
menu.

ĐiӅu kiӋn trưӟc đó: )) 9 :,

 ; 
 +
 <  *

Bҧo an: Ngưӡi sӱ dөng (nhân viên tiӃp khách) đưӧc cung cҩp mӝt sӕ đӏnh danh riêng biӋt
đӇ truy nhұp vào hӋ thӕng.

Dӏch chuyӇn: Ngưӡi sӱ dөng chӍ đӃn đưӧc màn hình Chi TiӃt Tài Khoҧn sau khi đã truy
nhұp thành công và Identify thành công.

ĐiӅu kiӋn sau đó: )) 9 = :,


 
 +
 <  *6

HӋ thӕng sӁ không lưu trӳ lҥi bҩt kǤ mӝt thông tin nào liên quan tӟi khách hàng lên đĩa
cӭng cөc bӝ.

9- THӰ USE CASE

Mӝt trong các mөc đích chính cӫa Use Case là thӱ nghiӋm (testing). Có hai loҥi thӱ
nghiӋm khác nhau đưӧc thӵc hiӋn ӣ đây: kiӇm tra (verification) và phê duyӋt xác nhұn
(validation). KiӇm tra đҧm bҧo là hӋ thӕng đã đưӧc phát triӇn đúng đҳn và phù hӧp vӟi
các đһc tҧ đã đưӧc tҥo ra. Phê duyӋt xác nhұn đҧm bҧo rҵng hӋ thӕng sӁ đưӧc phát triӇn
chính là thӭ mà khách hàng hoһc ngưӡi sӱ dөng cuӕi thұt sӵ cҫn đӃn.

Công viӋc phê duyӋt xác nhұn đưӧc thӵc hiӋn kӅ trưӟc giai đoҥn phát triӇn. Ngay khi
mӝt mô hình Use Case đưӧc hoàn tҩt (hay thұm chí có thӇ đang trong giai đoҥn phát
triӇn), mô hình này phҧi đưӧc trình bày và thҧo luұn vӟi khách hàng cũng như ngưӡi sӱ
dөng. Hӑ cҫn phҧi xác nhұn rҵng mô hình này là đúng đҳn, hoàn tҩt và thӓa mãn sӵ mong
đӧi cӫa hӑ đӕi vӟi hӋ thӕng; đһc biӋt là phương cách mà hӋ thӕng cung cҩp chӭc năng
cho hӑ. ĐӇ làm điӅu đó, nhà phát triӇn phҧi đҧm bҧo rҵng khách hàng thұt sӵ hiӇu đưӧc
mô hình và ý nghĩa cӫa chúng, đӇ tránh trưӡng hӧp tҥo ra nhӳng thӭ không thӇ chҩp nhұn
nәi. Trong giai đoҥn này, rõ ràng là các câu hӓi và các ý tưӣng sӁ xuҩt hiӋn và chúng cҫn
phҧi đưӧc bә sung thêm vào mô hình Use Case trưӟc khi đӃn giai đoҥn phê duyӋt chung
cuӝc. Giai đoҥn xác nhұn cũng có thӇ đưӧc thӵc hiӋn trong thӡi kǤ thӱ nghiӋm hӋ thӕng,
nhưng điӇm yӃu cӫa phương thӭc làm này là nӃu hӋ thӕng không thӓa mãn nhӳng yêu
cҫu cө thӇ cӫa ngưӡi sӱ dөng thì toàn bӝ dӵ án rҩt có thӇ sӁ phҧi làm lҥi tӯ đҫu.

KiӇm tra hӋ thӕng là đӇ đҧm bҧo nó hoҥt đӝng đúng như đһc tҧ. ĐiӅu này không thӇ
đưӧc thӵc hiӋn trưӟc khi đã có nhӳng thành phҫn cӫa hӋ thӕng đưӧc tҥo ra. ChӍ sau đó
ngưӡi ta mӟi có thӇ thӱ xem hӋ thӕng có hoҥt đӝng đúng như đһc tҧ mà ngưӡi sӱ dөng đã
đưa ra, rҵng các Use Case thӵc hiӋn đúng theo như nhӳng lӡi đã miêu tҧ trong mô hình,
rҵng chúng hoҥt đӝng theo đúng phương thӭc đã đưӧc miêu tҧ trong văn bҧn miêu tҧ Use
Case.

Đi bӝ dӑc Use Case.

Mӝt trong nhӳng kӻ thuұt hӳu dөng đưӧc dùng trong cҧ giai đoҥn đӏnh nghĩa lүn thӱ
nghiӋm Use Case gӑi là "Đi Bӝ Dӑc Use Case´. Theo kӻ thuұt này, nhiӅu ngưӡi khác
nhau trong nhóm làm mô hình sӁ đóng vai các tác nhân cũng như hӋ thӕng trong mӝt Use
Case cө thӇ. Ngưӡi đҧm nhұn vai tác nhân sӁ bҳt đҫu bҵng viӋc nói ra tác nhân làm gì vӟi
hӋ thӕng. KӃt quҧ cӫa công viӋc này là hӋ thӕng sӁ khӣi chҥy mӝt Use Case cө thӇ đưӧc
bҳt đҫu tӯ hành đӝng trên. Ngưӡi đóng vai hӋ thӕng sau đó sӁ nói anh ta làm gì khi Use
Case đưӧc thӵc hiӋn. Nhà phát triӇn đӭng ngoài trò chơi diӉn kӏch sӁ ghi chép và tìm
cách phát hiӋn ra các điӇm yӃu trong các Use Case đưӧc miêu tҧ bҵng các diӉn viên.
Trong trưӡng hӧp đһc thù, bҥn sӁ tìm thҩy rҵng có mӝt vài chuӛi hành đӝng bә sung
không đưӧc miêu tҧ cũng như mӝt vài hành đӝng không đưӧc miêu tҧ vӟi đҫy đӫ chi tiӃt.

Các "diӉn viên" càng hiӇu thҩu đáo khía cҥnh sӱ dөng cӫa hӋ thӕng bao nhiêu thì công
viӋc thӱ Use Case sӁ càng hiӋu quҧ bҩy nhiêu. ViӋc thay đәi các diӉn viên đӇ đóng nhӳng
vai trò khác nhau sӁ dүn tӟi nhӳng thay đәi trong miêu tҧ và hưӟng nhìn, cung cҩp dӳ
liӋu đҫu vào cho các nhà tҥo mô hình đӇ hӑ biӃt đưӧc làm cách nào có thӇ đưa ra nhӳng
lӡi miêu tҧ Use Case rõ ràng hơn, minh bҥch hơn, và chӍ ra nhӳng điӇm còn thiӃu. Mӝt
khi vai trò cӫa tҩt cҧ các tác nhân đã đưӧc diӉn và thӵc thi, và tҩt cҧ các Use Case đã
đưӧc thӵc thi theo kiӇu này, đó là thӡi điӇm mà ngưӡi ta nói mӝt quá trình thӱ nghiӋm
cӫa mô hình Use Case đã hoàn tҩt.

10- THӴC HIӊN CÁC USE CASE

Use Case là nhӳng lӡi miêu tҧ đӝc lұp vӟi sӵ thӵc thi các chӭc năng cӫa hӋ thӕng. ĐiӅu
đó có nghĩa là Use Case sӁ đưӧc thӵc hiӋn (thӵc thӇ hóa) trong hӋ thӕng, vұy nên trách
nhiӋm đӇ thӵc thi các hành đӝng đưӧc miêu tҧ trong tài liӋu Use Case đӅu đưӧc phân bә
vӅ cho các đӕi tưӧng cӝng tác thӵc thi chӭc năng đó.

Các nguyên tҳc cӫa UML cho viӋc thӵc hiӋn các Use Case là: Mӝt Use Case sӁ đưӧc thӵc
hiӋn trong mӝt sӵ cӝng tác (collaboration): Mӝt sӵ cӝng tác chӍ ra mӝt giҧi pháp (phө
thuӝc vào sӵ thӵc thi nӝi bӝ) cӫa mӝt Use Case sӱ dөng các khái niӋm lӟp/đӕi tưӧng và
mӕi quan hӋ giӳa chúng đӕi vӟi nhau (gӑi là > , ± : cӫa sӵ cӝng tác) cũng
như sӵ tương tác giӳa chúng đӇ đҥt tӟi chӭc năng mong muӕn (gӑi là chuӛi tương tác cӫa
sӵ cӝng tác). Kí hiӋu cho sӵ cӝng tác là mӝt hình ellipse có chӭa tên cӫa sӵ cӝng tác đó.

Mӝt sӵ cӝng tác đưӧc trình bày trong UML qua mӝt loҥt các biӇu đӗ chӍ ra cҧ ngӳ cҧnh
lүn chuӛi tương tác giӳa các thành phҫn tham gia: thành phҫn tham gia trong mӝt sӵ cӝng
tác là mӝt loҥt các lӟp (và trong mӝt thӵc thӇ cӝng tác: các đӕi tưӧng). Các biӇu đӗ sӱ
dөng ӣ đây là biӇu đӗ cӝng tác, biӇu đӗ chuӛi và biӇu đӗ hoҥt đӝng. Cҫn phҧi sӱ dөng
loҥi biӇu đӗ nào đӇ tҥo ra mӝt bӭc tranh bao quát vӅ sӵ cӝng tác là quyӃt đӏnh tùy thuӝc
vào tӯng trưӡng hӧp cө thӇ. Trong mӝt vài trưӡng hӧp, chӍ mӝt biӇu đӗ cӝng tác đã có
thӇ là đӫ; nhưng trong các trưӡng hӧp khác, ngưӡi ta nhҩt thiӃt cҫn tӟi sӵ kӃt hӧp cӫa
nhiӅu loҥi biӇu đӗ khác nhau.

Mӝt cҧnh kӏch (Scenario) là mӝt thӵc thӇ (instance) cӫa mӝt Use Case hay là mӝt sӵ cӝng
tác: mӝt cҧnh kӏch là mӝt chuӛi thӵc thi cө thӇ (mӝt dòng chҧy cө thӇ cӫa các sӵ kiӋn)
trình bày mӝt sӵ thӵc thӇ hóa cӫa mӝt Use Case (tӭc là mӝt lҫn sӱ dөng hӋ thӕng). Khi
mӝt cҧnh kӏch đưӧc quan sát trong tư cách mӝt Use Case, ngưӡi ta chӍ miêu tҧ nhӳng ӭng
xӱ bên ngoài hưӟng vӅ phía tác nhân. Khi quan sát mӝt cҧnh kӏch trong tư cách là mӝt
thӵc thӇ cӫa sӵ cӝng tác, ngưӡi ta sӁ miêu tҧ cҧ sӵ thӵc thi nӝi tҥi (các dòng lӋnh code)
cӫa các lӟp tham gia ӣ đây, thuұt toán cũng như thӫ tөc cӫa chúng cùng sӵ giao tiӃp giӳa
chúng vӟi nhau.

Tác vө thӵc hiӋn mӝt Use Case là chuyӇn các bưӟc và hành đӝng khác nhau trong lӡi
miêu tҧ Use Case thành lӟp (Class), thӫ tөc trong nhӳng lӟp này cũng như quan hӋ giӳa
chúng vӟi nhau. Nó đưӧc miêu tҧ là đӝng tác phân bә trách nhiӋm cӫa mӛi bưӟc đi trong
Use Case vào các lӟp tham gia sӵ cӝng tác thӵc hiӋn Use Case đó. Tҥi giai đoҥn này,
ngưӡi ta phҧi tìm ra mӝt giҧi pháp cung cҩp nhӳng hành vi hưӟng ngoҥi đã đưӧc xác đӏnh
cӫa Use Case; nó đưӧc miêu tҧ trong nhӳng thuұt ngӳ cӫa mӝt sӵ cӝng tác nӝi bӝ trong
hӋ thӕng.

Mӛi bưӟc hành đӝng trong Use Case sӁ đưӧc chuyӇn thành thӫ tөc (operation) trong các
lӟp tham gia. Mӝt bưӟc trong Use Case sӁ đưӧc chuyӇn thành mӝt loҥt các thӫ tөc tҥi
nhiӅu lӟp; rҩt hiӃm khi xҧy ra ánh xҥ 1-1 giӳa các hành đӝng trong Use Case và các thӫ
tөc đưӧc thӵc thi trong tương tác giӳa các đӕi tưӧng cӫa các lӟp tham gia. Cũng xin nhӟ
rҵng mӝt lӟp có thӇ tham gia nhiӅu Use Case khác nhau và trách nhiӋm cao nhҩt cӫa lӟp
nҵm chính trong viӋc kӃt tұp tҩt cҧ các vai trò mà lӟp này đҧm nhұn trong các Use Case
khác nhau.

Mӕi quan hӋ giӳa mӝt Use Case và sӵ thӵc thi nó theo khái niӋm cӝng tác đưӧc chӍ ra
hoһc qua mӝt mӕi quan hӋ nâng cao (refinement relationship) ± biӇu thӏ bҵng đoҥn thҷng
chҩm chҩm vӟi mũi tên - - - -> hay mӝt   1 ngҫm trong mӝt công cө nào đó. Mӝt
hyperlink trong mӝt công cө sӁ tҥo điӅu kiӋn chuyӇn tӯ viӋc quan sát mӝt Use Case trong
mӝt biӇu đӗ Use Case sang ngay sӵ cӝng tác thӵc thi Use Case đó. Các hyperlink cũng
đưӧc sӱ dөng đӇ chuyӇn tӯ Use Case này sang mӝt cҧnh kӏch (thưӡng là mӝt mô hình
đӝng ± biӇu đӗ hoҥt đӝng, biӇu đӗ chuӛi hay biӇu đӗ cӝng tác) miêu tҧ mӝt sӵ thӵc hiӋn
cө thӇ nào đó cӫa Use Case.

Phân bә trách nhiӋm cho các lӟp mӝt cách thành công là mӝt tác vө đòi hӓi kinh nghiӋm.
Cũng giӕng như mӑi công đoҥn hưӟng đӕi tưӧng khác, công viӋc này mang tính vòng lһp
(iterative). Nhà phát triӇn thӱ nghiӋm vӟi nhiӅu sӵ phân bә trách nhiӋm khác nhau và dҫn
dҫn nâng cҩp chúng trong giҧi pháp cӫa mình cho tӟi khi tҥo ra đưӧc mӝt mô hình thӵc
hiӋn chӭc năng đó, đӗng thӡi lҥi đӫ mӭc đӝ năng đӝng đӇ cho phép tiӃn hành các sӵ thay
đәi trong tương lai.
Jacobson sӱ dөng phương pháp đӏnh nghĩa ba loҥi đӕi tưӧng căn bҧn (có nghĩa là ba loҥi
lӟp): các đӕi tưӧng biên (boundary objects) , đӕi tưӧng chӍ huy (control objects) và đӕi
tưӧng thӵc thӇ (entity objects). Đӕi vӟi mӛi Use Case, các lӑai đӕi tưӧng này đưӧc sӱ
dөng đӇ miêu tҧ mӝt sӵ cӝng tác thӵc thi Use Case. Trách nhiӋm cӫa các loҥi đӕi tưӧng
kӇ trên như sau:

u2 Y Y Y : loҥi đӕi tưӧng này đҥi diӋn cho các thӵc thӇ cӫa bài toán
nҵm trong phҥm vi mà hӋ thӕng xӱ lý. Thưӡng chúng mang tính thө đӝng, theo khái niӋm
là chúng không tӵ gây nên các tương tác đӕi vӟi chúng. Trong mӝt hӋ thӕng thông tin,
các đӕi tưӧng thӵc thӇ thưӡng mang tính trưӡng tӗn (persistent) và đưӧc lưu trӳ trong
mӝt hӋ ngân hàng dӳ liӋu. Các đӕi tưӧng thӵc thӇ thưӡng tham gia vào nhiӅu Use Case
khác nhau.

u2 Y # 3: loҥi đӕi tưӧng này nҵm gҫn đưӡng ranh giӟi cӫa hӋ thӕng (mһc
dù vүn nҵm bên trong hӋ thӕng). Chúng tương tác vӟi các tác nhân nҵm bên ngoài hӋ
thӕng và nhұn thông điӋp cũng như gӱi thông điӋp đӃn các loҥi đӕi tưӧng khác nҵm bên
trong hӋ thӕng.

u2 Y  4 ): loҥi đӕi tưӧng này chӍ huy sӵ tương tác giӳa các nhóm đӕi
tưӧng. Mӝt đӕi tưӧng như thӃ có thӇ đóng vai trò "bӝ phұn điӅu khiӇn´ cho toàn bӝ mӝt
Use Case hoàn tҩt, hay nó có thӇ thӵc thi mӝt chuӛi hành đӝng chung cӫa nhiӅu Use
Case. Thưӡng thì mӝt đӕi tưӧng như vұy chӍ tӗn tҥi trong quá trình thӵc thi Use Case.

Ba loҥi đӕi tưӧng này có ba kí hiӋu khác nhau và có thӇ đưӧc sӱ dөng khi vӁ các loҥi biӇu
đӗ miêu tҧ cӝng tác hoһc biӇu đӗ lӟp. Sau khi đã đӏnh nghĩa nhiӅu loҥi đӕi tưӧng khác
nhau và xác nhұn các cӝng tác, ngưӡi ta có thӇ đӇ công đi tìm sӵ tương tӵ giӳa chúng đӇ
mӝt sӕ lӟp có thӇ đưӧc sӱ dөng trong mӝt loҥt các Use Case khác nhau. Sӱ dөng các Use
Case theo phương thӭc này ta có thӇ tҥo nên nӅn tҧng cho viӋc phân tích và thiӃt kӃ hӋ
thӕng; qui trình phát triӇn đưӧc Ivar Jacobson gӑi là "Qui Trình Phát TriӇn Theo Use
Case" (Use case ± driven).

Nhìn chung có nhiӅu phương pháp khác nhau đӇ phân bә trách nhiӋm tӯ Use Case vӅ cho
các lӟp. Có phương pháp đӅ nghӏ đҫu tiên phҧi tiӃn hành phân tích phҥm vi bài toán, chӍ
ra tҩt cҧ các lӟp thӵc thӇ (thuӝc phҥm vi bài toán) vӟi mӕi quan hӋ cӫa chúng vӟi nhau.
Sau đó nhà phát triӇn sӁ phân tích tӯng Use Case và phân bә trách nhiӋm cho các lӟp
trong mô hình phân tích (analysis model), nhiӅu khi sӁ thay đәi chúng hoһc bә sung thêm
các lӟp mӟi. Mӝt phương pháp khác lҥi đӅ nghӏ là nên lҩy các Use Case làm nӅn tҧng đӇ
tìm các lӟp, làm sao trong quá trình phân bә trách nhiӋm thì mô hình phân tích cӫa phҥm
vi bài toán sӁ tӯng bưӟc tӯng bưӟc đưӧc thiӃt lұp.

Mӝt điӇm quan trӑng cҫn phҧi nhҳc lҥi là công viӋc ӣ đây mang tính vòng lһp. Khi phân
bә trách nhiӋm cho các lӟp, ta có thӇ phát hiӋn ra sӵ thiӃu đӗng bӝ hoһc lӛi trong các biӇu
đӗ lӟp và qua đó, dүn đӃn viӋc sӱa chӳa trong biӇu đӗ lӟp. Nhӳng lӟp mӟi sӁ đưӧc nhұn
dҥng và tìm ra nhҵm mөc đích hӛ trӧ cho các Use Case. Trong mӝt sӕ trưӡng hӧp, thұm
chí có thӇ xҧy ra chuyӋn phҧi thay đәi hoһc sӱa chӳa cҧ biӇu đӗ Use Case vì khi hiӇu hӋ
thӕng mӝt cách sâu sҳc hơn, nhà phát triӇn sӁ nhұn ra rҵng có mӝt Use Case nào đó đã
không đưӧc miêu tҧ chính xác và đúng đҳn. Các Use Case giúp chúng ta tұp trung vào
khía cҥnh chӭc năng cӫa hӋ thӕng, làm sao phҧi đҧm bҧo cho nó đưӧc miêu tҧ chính xác
và đưӧc xây dӵng chính xác trong hӋ thӕng. Mӝt trong nhӳng vҩn đӅ xҧy ra vӟi nhiӅu
phương pháp hưӟng đӕi tưӧng mà không sӱ dөng đӃn khái niӋm Use Case là chúng tұp
trung quá nhiӅu vào cҩu trúc tĩnh cӫa các lӟp và các đӕi tưӧng (nhiӅu khi ngưӡi ta gӑi là
phương pháp mô hình hóa khái niӋm ± conceptual modeling) nhưng lҥi bӓ qua các khía
cҥnh chӭc năng và khía cҥnh đӝng cӫa hӋ thӕng.

11- TÓM TҲT Vӄ USE CASE

Mô hình Use Case là mӝt kӻ thuұt đưӧc sӱ dөng đӇ miêu tҧ nhӳng yêu cҫu mang tính
chӭc năng cӫa mӝt hӋ thӕng. Use Case đưӧc miêu tҧ qua các khái niӋm tác nhân bên
ngoài, Use Case và hӋ thӕng. Tác nhân tưӧng trưng cho mӝt vai trò và mӝt thӵc thӇ bên
ngoài ví dө như mӝt ngưӡi dùng, mӝt bӝ phұn phҫn cӭng hoһc mӝt hӋ thӕng khác tương
tác vӟi hӋ thӕng. Tác nhân gây ra và giao tiӃp vӟi các Use Case, trong khi mӝt Use Case
là mӝt tұp hӧp cӫa các chuӛi hành đӝng đưӧc thӵc hiӋn trong hӋ thӕng. Mӝt Use Case
phҧi cung cҩp mӝt giá trӏ cҫn hưӟng tӟi nào đó cho tác nhân, và bình thưӡng nó đưӧc
miêu tҧ bҵng văn bҧn. Tác nhân và Use Case là các lӟp. Mӝt tác nhân đưӧc liên kӃt vӟi
mӝt hoһc nhiӅu Use Case qua mӕi liên kӃt (Association) và cҧ tác nhân lүn Use Case đӅu
có thӇ có mӕi quan hӋ khái quát hóa, mӕi quan hӋ này miêu tҧ nhӳng ӭng xӱ chung trong
các lӟp cha, sӁ đưӧc thӯa kӃ bӣi mӝt hoһc nhiӅu lӟp con. Mӝt mô hình Use Case đưӧc
miêu tҧ bҵng mӝt hay nhiӅu biӇu đӗ trưӡng hӧp thuӝc ngôn ngӳ UML.

Use Case đưӧc thӵc hiӋn qua các sӵ cӝng tác. Mӝt sӵ cӝng tác là mӝt lӡi miêu tҧ mӝt ngӳ
cҧnh, chӍ ra các lӟp/ đӕi tưӧng và mӕi quan hӋ cӫa chúng và mӝt tương tác chӍ ra các
lӟp/đӕi tưӧng đó tương tác vӟi nhau ra sao đӇ thӵc hiӋn mӝt chӭc năng cө thӇ. Mӝt sӵ
cӝng tác đưӧc miêu tҧ bҵng biӇu đӗ hoҥt đӝng, biӇu đӗ cӝng tác và biӇu đӗ chuӛi. Khi
mӝt Use Case đưӧc thӵc hiӋn, trách nhiӋm cho mӛi bưӟc hành đӝng trong Use Case cҫn
phҧi đưӧc phân bә cho các lӟp tham gia sӵ cӝng tác đó, thưӡng là qua viӋc xác đӏnh các
thӫ tөc cӫa các lӟp này, đi song song vӟi phương thӭc mà chúng tương tác vӟi nhau. Mӝt
cҧnh kӏch là mӝt thӵc thӇ cӫa mӝt Use Case, hay mӝt sӵ cӝng tác, chӍ ra mӝt chuӛi thӵc
thi cө thӇ. Vì thӃ, mӝt cҧnh kӏch là mӝt sӵ minh hӑa hay là mӝt ví dө cӫa mӝt Use Case
hay là mӝt sӵ cӝng tác. Khi cҧnh kӏch đưӧc chӍ ra trong tư cách mӝt thӵc thӇ cӫa mӝt Use
Case, chӍ duy nhҩt sӵ tương tác giӳa Use Case và tác nhân ngoҥi lai sӁ đưӧc miêu tҧ,
nhưng khi cҧnh kӏch đưӧc quan sát và đưӧc chӍ ra theo hưӟng là mӝt thӵc thӇ cӫa mӝt sӵ
cӝng tác, thì sӵ tương tác giӳa các lӟp/đӕi tưӧng phía bên trong hӋ thӕng cũng sӁ đưӧc
miêu tҧ.

PHҪN CÂU HӒI

Hӓi: Mӝt tác nhân (Actor) trong mӝt Use Case luôn là mӝt con ngưӡi

Đáp: Sai, tác nhân là mӝt ngưӡi hoһc mӝt vұt nào đó tương tác vӟi hӋ thӕng.

Hӓi: HӋ thӕng khác cũng có thӇ đóng vai trò tác nhân trong mӝt Use Case?
Đáp: Đúng

Hӓi: Mӛi hӋ thӕng chӍ có mӝt Use Case?

Đáp: Sai

Hӓi: BiӇu đӗ Use case mô tҧ chӭc năng hӋ thӕng?

Đáp: Đúng

›››
 Chương 5 : MÔ HÌNH ĐӔI TƯӦNG

›››

1- LӞP, ĐӔI TƯӦNG VÀ QUAN Hӊ ± CÁC THÀNH PHҪN CƠ BҦN

CӪA MÔ HÌNH
Trong mô hình hóa hưӟng đӕi tưӧng, nhӳng phҫn tӱ cҩu thành căn bҧn nhҩt cӫa mô hình
là lӟp, đӕi tưӧng và mӕi quan hӋ giӳa chúng vӟi nhau. Lӟp và đӕi tưӧng sӁ mô hình hóa
nhӳng gì có trong hӋ thӕng mà chúng ta muӕn miêu tҧ, các mӕi quan hӋ sӁ biӇu thӏ cҩu
trúc. Đӝng tác phân lӟp (classification) đã đưӧc sӱ dөng tӯ hàng ngàn năm nay đӇ đơn
giҧn hóa viӋc miêu tҧ các hӋ thӕng phӭc tҥp. Khi loài ngưӡi biӃt đӃn viӋc lұp trình hưӟng
đӕi tưӧng đӇ xây dӵng các hӋ thӕng phҫn mӅm thì lӟp và các mӕi quan hӋ cӫa chúng
đưӧc chuyӇn thành các dòng code cө thӇ.

1.1- Đӕi tưӧng (Object)

Mӝt đӕi tưӧng là mӝt sӵ tưӧng trưng cho mӝt thӵc thӇ, hoһc là thӵc thӇ tӗn tҥi trong thӃ
giӟi đӡi thӵc hoһc thӵc thӇ mang tính khái niӋm. Mӝt đӕi tưӧng có thӇ tưӧng trưng cho
cái gì đó cө thӇ, ví dө như mӝt chiӃc xe ô tô chӣ hàng cӫa bҥn hoһc chiӃc máy tính cӫa
tôi, hoһc tưӧng trưng cho mӝt khái niӋm ví dө như mӝt quy trình hóa hӑc, mӝt giao dӏch
trong nhà băng, mӝt lӡi đһt hàng, nhӳng thông tin trong quá trình sӱ dөng tín dөng cӫa
khách hàng hay mӝt tӹ lӋ tiӅn lӡi.

Cũng có nhӳng đӕi tưӧng (ví dө như các đӕi tưӧng thӵc thi mӝt trong hӋ thӕng phҫn
mӅm) không thұt sӵ tӗn tҥi ӣ ngoài thӃ giӟi thӵc, nhưng là kӃt quҧ dүn xuҩt tӯ quá trình
nghiên cӭu cҩu trúc và ӭng xӱ cӫa các đӕi tưӧng ngoài thӃ giӟi thӵc. Nhӳng đӕi tưӧng
đó, dù là bҵng cách này hay cách khác, đӅu liên quan đӃn quan niӋm cӫa chúng ta vӅ thӃ
giӟi thӵc.

Mӝt đӕi tưӧng là mӝt khái niӋm, mӝt sӵ trӯu tưӧng hóa, hoһc là mӝt đӗ vұt vӟi ranh giӟi
và ý nghĩa đưӧc đӏnh nghĩa rõ ràng cho mӝt ӭng dөng nào đó. Mӛi đӕi tưӧng trong mӝt
hӋ thӕng đӅu có ba đһc tính: trҥng thái, ӭng xӱ và sӵ nhұn diӋn.

1.2- Trҥng thái, ӭng xӱ và nhұn diӋn cӫa đӕi tưӧng

Ú   ?

@ cӫa mӝt đӕi tưӧng là mӝt trong nhӳng hoàn cҧnh nơi đӕi tưӧng có thӇ
tӗn tҥi. Trҥng thái cӫa mӝt đӕi tưӧng thưӡng sӁ thay đәi theo thӡi gian, và nó đưӧc đӏnh
nghĩa qua mӝt tә hӧp các thuӝc tính, vӟi giá trӏ cӫa các thuӝc tính này cũng như mӕi quan
hӋ mà đӕi tưӧng có thӇ có vӟi các đӕi tưӧng khác. Ví dө mӝt danh sách ghi danh cho mӝt
lӟp hӑc trong hӋ thӕng trưӡng hӑc có thӇ có hai trҥng thái: trҥng thái đóng và trҥng thái
mӣ. NӃu danh sách sinh viên ghi danh cho lӟp hӑc này còn nhӓ hơn sӕ tӕi đa cho phép
(ví dө là 10), thì trҥng thái cӫa bҧng ghi danh này là mӣ. Mӝt khi đã đӫ 10 sinh viên ghi
danh cho lӟp, danh sách sӁ chuyӇn sang trҥng thái đóng.
 :A ?B
C @ xác đӏnh mӝt đӕi tưӧng sӁ phҧn ӭng như thӃ nào trưӟc nhӳng yêu
cҫu tӯ các đӕi tưӧng khác, nó tiêu biӇu cho nhӳng gì mà đӕi tưӧng này có thӇ làm. Ӭng
xӱ đưӧc thӵc thi qua loҥt các Phương thӭc (operation) cӫa đӕi tưӧng. Trong ví dө trưӡng
đҥi hӑc, mӝt đӕi tưӧng bҧng ghi danh lӟp hӑc có thӇ có ӭng xӱ là bә sung thêm mӝt sinh
viên hay xóa đi tên cӫa mӝt sinh viên khi sinh viên đăng ký hӑc hay bãi bӓ đăng ký.

 " /* ?/ @ đҧm bҧo rҵng mӛi đӕi tưӧng là duy nhҩt ± dù trҥng thái cӫa nó có
thӇ giӕng vӟi trҥng thái cӫa các đӕi tưӧng khác. Ví dө, khóa hӑc đҥi sӕ 101 chương 1 và
khóa hӑc đҥi sӕ 101 chương 2 là hai đӕi tưӧng trong hӋ thӕng ghi danh trưӡng hӑc. Mһc
dù cҧ hai đӅu thuӝc loҥi bҧng ghi danh, mӛi khóa hӑc vүn có sӵ nhұn dҥng duy nhҩt cӫa
mình.

1.3- Lӟp (Class):

Mӝt lӟp là mӝt lӡi miêu tҧ cӫa mӝt nhóm các đӕi tưӧng có chung thuӝc tính, chung
phương thӭc (ӭng xӱ), chung các mӕi quan hӋ vӟi các đӕi tưӧng khác và chung ngӳ
nghĩa (semantic). Nói như thӃ có nghĩa lӟp là mӝt khuôn mүu đӇ tҥo ra đӕi tưӧng. Mӛi
đӕi tưӧng là mӝt thӵc thӇ cӫa mӝt lӟp nào đó và mӝt đӕi tưӧng không thӇ là kӃt quҧ thӵc
thӇ hóa cӫa nhiӅu hơn mӝt lӟp. Chúng ta sӱ dөng khái niӋm lӟp đӇ bàn luұn vӅ các hӋ
thӕng và đӇ phân loҥi các đӕi tưӧng mà chúng ta đã nhұn dҥng ra trong thӃ giӟi thӵc.

Mӝt lӟp tӕt sӁ nҳm bҳt mӝt và chӍ mӝt sӵ trӯu tưӧng hóa - nó phҧi có mӝt chӫ đӅ chính.
Ví dө, mӝt lӟp vӯa có khҧ năng giӳ tҩt cҧ các thông tin vӅ mӝt sinh viên và thông tin vӅ
tҩt cҧ nhӳng lӟp hӑc mà ngưӡi sinh viên đó đã trҧi qua trong nhiӅu năm trưӟc không phҧi
là mӝt lӟp tӕt, bӣi nó không có chӫ đӅ chính. Lӟp này cҫn phҧi đưӧc chia ra làm hai lӟp
liên quan đӃn nhau: lӟp sinh viên và lӟp lӏch sӱ cӫa sinh viên.

Hình 5.1- Mӛi thӵc thӇ trong mô hình trên là mӝt lӟp

Khi tҥo dӵng mô hình cũng như thұt sӵ xây dӵng các hӋ thӕng doanh nghiӋp, các hӋ
thӕng thông tin, máy móc hoһc các lӑai hӋ thӕng khác, chúng ta cҫn sӱ dөng các khái
niӋm cӫa chính phҥm vi vҩn đӅ đӇ khiӃn cho mô hình dӉ hiӇu và dӉ giao tiӃp hơn. NӃu
chúng ta xây dӵng hӋ thӕng cho mӝt công ty bҧo hiӇm, mô hình cҫn phҧi dӵa trên các
khái niӋm cӫa ngành bҧo hiӇm. NӃu chúng ta xây dӵng mӝt hӋ thӕng cho quân đӝi, thì
các khái niӋm cӫa thӃ giӟi quân sӵ cҫn phҧi đưӧc sӱ dөng khi mô hình hóa hӋ thӕng. Mӝt
hӋ thӕng dӵa trên các khái niӋm chính cӫa mӝt ngành doanh nghiӋp nào đó có thӇ dӉ
đưӧc thiӃt kӃ lҥi cho phù hӧp vӟi nhӳng qui chӃ, chiӃn lưӧc và qui đӏnh mӟi, bӣi chúng ta
chӍ cҫn cân bҵng và khҳc phөc sӵ chênh lӋch giӳa công viӋc cũ và công viӋc mӟi. Khi các
mô hình đưӧc xây dӵng dӵa trên các khái niӋm lҩy ra tӯ cuӝc đӡi thӵc và dӵa trên các
khái niӋm thuӝc phҥm vi vҩn đӅ, hưӟng đӕi tưӧng sӁ là mӝt phương pháp rҩt thích hӧp
bӣi nӅn tҧng cӫa phương pháp hưӟng đӕi tưӧng là các lӟp, đӕi tưӧng và mӕi quan hӋ giӳa
chúng.

Mӝt lӟp là lӡi miêu tҧ cho mӝt dҥng đӕi tưӧng trong bҩt kǤ mӝt hӋ thӕng nào đó ± hӋ
thӕng thông tin, hӋ thӕng kӻ thuұt, hӋ thӕng nhúng thӡi gian thӵc, hӋ thӕng phân tán, hӋ
thӕng phҫn mӅm và hӋ thӕng doanh thương. Các vұt dөng (artifact) trong mӝt doanh
nghiӋp, nhӳng thông tin cҫn đưӧc lưu trӳ, phân tích hoһc các vai trò mà mӝt tác nhân
đҧm nhұn trong mӝt doanh nghiӋp thưӡng sӁ trӣ thành các lӟp trong các hӋ thӕng doanh
nghiӋp và hӋ thӕng thông tin.

Ví dө vӅ các lӟp trong doanh nghiӋp và các hӋ thӕng thông tin:

- Khách hàng

- Bҧn thương thuyӃt

- Hóa đơn

- Món nӧ

- Tài sҧn

- Bҧn công bӕ giá cә phiӃu

Các lӟp trong mӝt hӋ thӕng kӻ thuұt thưӡng bao gӗm các đӕi tưӧng kӻ thuұt, ví dө như
máy móc đưӧc sӱ dөng trong hӋ thӕng:

- Sensor

- Màn hình

- I/O card

- Đӝng cơ

- Nút bҩm

- Lӟp điӅu khiӇn

Các hӋ thӕng phҫn mӅm thưӡng có các lӟp đҥi diӋn cho các thӵc thӇ phҫn mӅm trong mӝt
hӋ điӅu hành:
 - File

- Chương trình chҥy đưӧc

- Trang thiӃt bӏ

- Icon

- Cӱa sә

- Thanh kéo

1.- BiӇu đӗ lӟp (Class diagram):

Mӝt biӇu đӗ lӟp là mӝt dҥng mô hình tĩnh. Mӝt biӇu đӗ lӟp miêu tҧ hưӟng nhìn tĩnh cӫa
mӝt hӋ thӕng bҵng các khái niӋm lӟp và mӕi quan hӋ giӳa chúng vӟi nhau. Mһc dù nó
cũng có nhӳng nét tương tӵ vӟi mӝt mô hình dӳ liӋu, nhưng nên nhӟ rҵng các lӟp không
phҧi chӍ thӇ hiӋn cҩu trúc thông tin mà còn miêu tҧ cҧ hình vi. Mӝt trong các mөc đích
cӫa biӇu đӗ lӟp là tҥo nӅn tҧng cho các biӇu đӗ khác, thӇ hiӋn các khía cҥnh khác cӫa hӋ
thӕng (ví dө như trҥng thái cӫa đӕi tưӧng hay cӝng tác đӝng giӳa các đӕi tưӧng, đưӧc chӍ
ra trong các biӇu đӗ đӝng). Mӝt lӟp trong mӝt biӇu đӗ lӟp có thӇ đưӧc thӵc thi trӵc tiӃp
trong mӝt ngôn ngӳ hưӟng đӕi tưӧng có hӛ trӧ trӵc tiӃp khái niӋm lӟp. Mӝt biӇu đӗ lӟp
chӍ chӍ ra các lӟp, nhưng bên cҥnh đó còn có mӝt biӃn tҩu hơi khác đi mӝt chút chӍ ra các
đӕi tưӧng thұt sӵ là các thӵc thӇ cӫa các lӟp này (biӇu đӗ đӕi tưӧng).

Hình 5.2-Mô hình lӟp trong UML

Hình 5.3- Mӝt lӟp cө thӇ vӟi các thuӝc tính

ĐӇ tҥo mӝt biӇu đӗ lӟp, đҫu tiên ta phҧi nhұn diӋn và miêu tҧ các lӟp. Mӝt khi đã có mӝt
sӕ lưӧng các lӟp, ta sӁ xét đӃn quan hӋ giӳa các lӟp đó vӟi nhau.

2- TÌM LӞP:

Hҫu như không có mӝt công thӭc chung cho viӋc phát hiӋn ra các lӟp. Đi tìm các lӟp là
mӝt công viӋc đòi hӓi trí sáng tҥo và cҫn phҧi đưӧc thӵc thi vӟi sӵ trӧ giúp cӫa chuyên
gia ӭng dөng. Vì qui trình phân tích và thiӃt kӃ mang tính vòng lһp, nên danh sách các
lӟp sӁ thay đәi theo thӡi gian. Tұp hӧp ban đҫu cӫa các lӟp tìm ra chưa chҳc đã là tұp hӧp
cuӕi cùng cӫa các lӟp sau này sӁ đưӧc thӵc thi và biӃn đәi thành code. Vì thӃ, thưӡng
ngưӡi ta hay sӱ dөng đӃn khái niӋm các 1; D A C' (Candidate Class) đӇ miêu tҧ tұp
hӧp nhӳng lӟp đҫu tiên đưӧc tìm ra cho hӋ thӕng.

Như đã nói trong phҫn 2.10 (Thӵc hiӋn Trưӡng hӧp sӱ dөng), trưӡng hӧp sӱ dөng là
nhӳng lӡi miêu tҧ chӭc năng cӫa hӋ thӕng, còn trách nhiӋm thӵc thi thuӝc vӅ các đӕi
tưӧng cӝng tác thӵc thi chӭc năng đó. Nói mӝt cách khác, chúng ta đi tìm các lӟp là đӇ
tiӃn tӟi tìm giҧi pháp cung cҩp nhӳng ӭng xӱ hưӟng ngoҥi đã đưӧc xác đӏnh trong các
trưӡng hӧp sӱ dөng.

Có nhiӅu phương pháp khác nhau đӇ thӵc hiӋn công viӋc đó. Có phương pháp đӅ nghӏ
tiӃn hành phân tích phҥm vi bài toán, chӍ ra tҩt cҧ các lӟp thӵc thӇ (thuӝc phҥm vi bài
toán) vӟi mӕi quan hӋ cӫa chúng vӟi nhau. Sau đó nhà phát triӇn sӁ phân tích tӯng trưӡng
hӧp sӱ dөng và phân bә trách nhiӋm cho các lӟp trong mô hình phân tích (analysis
model), nhiӅu khi sӁ thay đәi chúng hoһc bә sung thêm các lӟp mӟi. Có phương pháp đӅ
nghӏ nên lҩy các trưӡng hӧp sӱ dөng làm nӅn tҧng đӇ tìm các lӟp, làm sao trong quá trình
phân bә trách nhiӋm thì mô hình phân tích cӫa phҥm vi bài toán sӁ tӯng bưӟc tӯng bưӟc
đưӧc thiӃt lұp.

2.1- Phân tích phҥm vi bài toán đӇ tìm lӟp:

Quá trình phân tích phҥm vi bài toán thưӡng đưӧc bҳt đҫu vӟi các  *   
(Key Abstraction), mӝt công cө thưӡng đưӧc sӱ dөng đӇ nhұn diӋn và lӑc ra các lӟp ӭng
cӱ viên (Candidate class).

2.1.1- Khái niӋm then chӕt

Hãy lҩy ví dө mӝt nhà băng ABC, điӅu đҫu tiên ta nghĩ tӟi là gì? TiӅn! Bên cҥnh đó,
ABC còn phҧi có nhӳng thӵc thӇ liên quan tӟi tiӅn như sau:

- Khách hàng

- Sҧn phҭm (các tài khoҧn đưӧc coi là các sҧn phҭm cӫa mӝt nhà băng)

- Lӵc lưӧng nhân viên

- Ban quҧn trӏ nhà băng

 - Phòng máy tính trong nhà băng

Nhӳng thӵc thӇ này đưӧc gӑi là các khái niӋm then chӕt cho nhӳng gì mà nhà băng có thӇ
có. Khái niӋm then chӕt hoһc mang tính cҩu trúc (structural) hoһc mang tính chӭc năng
(functional). Thӵc thӇ mang tính cҩu trúc là nhӳng thӵc thӇ vұt lý tương tác vӟi nhà băng,
ví dө khách hàng. Thӵc thӇ mang tính chӭc năng là nhӳng chӭc năng mà nhà băng phҧi
thӵc hiӋn, ví dө duy trì mӝt tài khoҧn hoһc chuyӇn tiӅn tӯ tài khoҧn này sang tài khoҧn
khác. Khái niӋm then chӕt là các thӵc thӇ ta đӇ ý đӃn đҫu tiên. Chúng rҩt quan trӑng vì
giúp ta:

- Đӏnh nghĩa ranh giӟi cӫa vҩn đӅ

- Nhҩn mҥnh đӃn các thӵc thӇ có liên quan đӃn thiӃt kӃ cӫa hӋ thӕng

- Loҥi bӓ thӵc thӇ nҵm ngoài phҥm vi hӋ thӕng

- Các khái niӋm then chӕt thưӡng sӁ trӣ thành các lӟp trong mô hình phân tích

Mӝt khái niӋm then chӕt tóm lҥi là mӝt lӟp hay đӕi tưӧng thuӝc chuyên ngành cӫa phҥm
vi bài toán. Khi trình bày vӟi ngưӡi sӱ dөng, chúng có mӝt ánh xҥ 1-1 giӳa vӟi nhӳng
thӵc thӇ liên quan tӟi ngưӡi sӱ dөng như hóa đơn, sec, giҩy đӅ nghӏ rút tiӅn, sә tiӃt kiӋm,
thҿ rút tiӅn tӵ đӝng, nhân viên thu ngân, nhân viên nhà băng, các phòng ban,«.

Mӭc đӝ trӯu tưӧng:

Khi phân tích phҥm vi bài toán, cҫn chú ý rҵng mӭc đӝ trӯu tưӧng cӫa các khái niӋm then
chӕt là rҩt quan trӑng, bӣi mӭc đӝ trӯu tưӧng quá cao hay quá thҩp đӅu rҩt dӉ gây nhҫm
lүn.

Mӭc trӯu tưӧng quá cao dүn tӟi nhӳng đӏnh nghĩa quá khái quát vӅ mӝt thӵc thӇ, tҥo nên
mӝt cái nhìn vĩ mô và thưӡng không nhҳm vào mӝt mөc tiêu cө thӇ. Ví dө trong mӝt nhà
băng, ta không thӇ chӑn khái niӋm then chӕt là "ngưӡi", bӣi nó sӁ dүn đӃn lӡi miêu tҧ:
"Mӝt ngưӡi đӃn nhà băng đӇ gӱi tiӅn vào, và sӕ tiӅn đó đưӧc mӝt ngưӡi khác tiӃp nhұn."
± trong khi mӝt yêu cҫu quan trӑng ӣ đây là phҧi phân biӋt giӳa nhân viên vӟi khách
hàng vì chӭc năng cӫa hӑ là khác hҷn nhau.

Tương tӵ như vұy, mӭc trӯu tưӧng quá thҩp cũng dӉ gây hiӇu lҫm, bӣi nhӳng thông tin
quá vөn vһt chưa thích hӧp vӟi thӡi điӇm này. Ví dө nhӳng quyӃt đӏnh dҥng:

- Form mӣ tài khoҧn đòi hӓi tҩt cҧ 15 Entry.

- Nhӳng dӳ liӋu trên Form này đӅu phҧi đưӧc căn phҧi.

- Không có nhiӅu chӛ đӇ ghi đӏa chӍ cӫa khách hàng trên Form.

nên đưӧc đӇ dành cho các giai đoҥn sau.

Vài điӇm cҫn chú ý vӅ khái niӋm then chӕt:

Nhӳng thӵc thӇ xuҩt hiӋn đҫu tiên trong óc não chúng ta là nhӳng thӵc thӇ dӉ có khҧ
năng trӣ thành khái niӋm then chӕt cho mӝt vҩn đӅ đӏnh trưӟc.

Mӛi lҫn tìm thҩy mӝt khái niӋm then chӕt mӟi, cҫn xem xét nó theo cách nhìn cӫa vҩn đӅ,
có thӇ hӓi các câu hӓi sau :

- Nhӳng chӭc năng nào có thӇ đưӧc thӵc hiӋn đӕi vӟi thӵc thӇ này?

- ĐiӅu gì khiӃn nhӳng thӵc thӇ loҥi này đưӧc tҥo ra?

NӃu không có câu trҧ lӡi thích hӧp, cҫn phҧi suy nghĩ lҥi vӅ thӵc thӇ đó.

Mӛi khái niӋm then chӕt mӟi cҫn phҧi đưӧc đһt tên cho thích hӧp, miêu tҧ đúng chӭc
năng cӫa khái niӋm.

2.1.2- Nhұn dҥng lӟp và đӕi tưӧng

Nҳm vӳng khái niӋm lӟp, chúng ta có thӇ tương đӕi dӉ dàng tìm thҩy các lӟp và đӕi
tưӧng trong phҥm vi vҩn đӅ. Mӝt nguyên tҳc thô sơ thưӡng đưӧc áp dөng là danh tӯ
trong các lӡi phát biӇu bài toán thưӡng là các ӭng cӱ viên đӇ chuyӇn thành lӟp và đӕi
tưӧng.

Mӝt sӕ gӧi ý thӵc tӃ cho viӋc tìm lӟp trong phҥm vi vҩn đӅ:

Bưӟc đҫu tiên là cҫn phҧi tұp trung nghiên cӭu kӻ:

- Các danh tӯ trong nhӳng lӡi phát biӇu bài toán

- KiӃn thӭc chuyên ngành thuӝc phҥm vi bài toán

- Các Trưӡng hӧp sӱ dөng

Ví dө trong lӡi phát biӇu "Có mӝt sӕ tài khoҧn mang lҥi tiӅn lãi", ta thҩy có hai danh tӯ là
tài khoҧn và tiӅn lãi. Chúng có thӇ là các lӟp tiӅm năng cho mô hình nhà băng lҿ.

Thӭ hai, chúng ta cҫn chú ý đӃn các nhóm vұt thӇ trong hӋ thӕng hiӋn thӡi như:

- Các thӵc thӇ vұt lý cӫa hӋ thӕng: nhӳng vұt thӇ tương tác vӟi hӋ thӕng, ví dө
khách hàng.

- Các vұt thӇ hӳu hình: các vұt thӇ vұt lý mà ta có thӇ nhìn và sӡ thҩy. Ví dө như
công cө giao thông, sách vӣ, mӝt con ngưӡi, mӝt ngôi nhà,«. Trong mӝt nhà băng ABC,
đó có thӇ là tұp sec, phiӃu đӅ nghӏ rút tiӅn, sә tiӃt kiӋm, các loҥi Form cҫn thiӃt.
 - Các sӵ kiӋn (Events): Mӝt chiӃc xe bӏ hӓng, mӝt cái cӱa đưӧc mӣ ra. Trong mӝt
nhà băng là sӵ đáo hҥn mӝt tài khoҧn đҫu tư, hiӋn tưӧng rút quá nhiӅu tiӅn mһt trong mӝt
tài khoҧn bình thưӡng.

- Các vai trò (Role): Ví dө như mҽ, khách hàng, ngưӡi bán hàng, «. Trong mӝt
nhà băng, vai trò có thӇ là nhân viên, nhà quҧn trӏ, khách hàng, ...

- Các sӵ tương tác (Interactions): Ví dө viӋc bán hàng là mӝt chuӛi tương tác bao
gӗm khách hàng, ngưӡi bán hàng và sҧn phҭm. Trong mӝt nhà băng, viӋc mӣ mӝt tài
khoҧn mӟi sӁ yêu cҫu mӝt chuӛi tương tác giӳa nhân viên và khách hàng.

- Vӏ trí (Location): Mӝt đӗ vұt nào đó hoһc mӝt ngưӡi nào đó đưӧc gán cho mӝt
vӏ trí nào đó. Ví dө: Ôtô đӕi vӟi nhà đӇ xe. Trong mӝt nhà băng ta có thӇ thҩy nhân viên
thu ngân luôn đӭng ӣ cӱa sә cӫa mình.

- Đơn vӏ tә chӭc (Organisation Unit): Ví dө các phòng ban, phòng trưng bày sҧn
phҭm, các bӝ phұn. Trong mӝt nhà băng có thӇ có bӝ phұn tài khoҧn bình thưӡng, bӝ
phұn tài khoҧn tiӃt kiӋm, bӝ phұn tài khoҧn đҫu tư.

Bên cҥnh đó, còn nhiӅu câu hӓi khác giúp ta nhұn dҥng lӟp. Ví dө như :

- Ta có thông tin cҫn đưӧc lưu trӳ hoһc cҫn đưӧc phân tích không? NӃu có thông
tin cҫn phҧi đưӧc lưu trӳ, biӃn đәi, phân tích hoһc xӱ lý trong mӝt phương thӭc nào đó
thì chҳc chҳn đó sӁ là ӭng cӱ viên cho lӟp. Nhӳng thông tin này có thӇ là mӝt khái niӋm
luôn cҫn phҧi đưӧc ghi trong hӋ thӕng hoһc là sӵ kiӋn, giao dӏch xҧy ra tҥi mӝt thӡi điӇm
cө thӇ nào đó.

- Ta có các hӋ thӕng ngoҥi vi không? NӃu có, thưӡng chúng cũng đáng đưӧc quan
tâm tӟi khi tҥo dӵng mô hình. Các hӋ thӕng bên ngoài có thӇ đưӧc coi là các lӟp chӭa hӋ
thӕng cӫa chúng ta hoһc tương tác vӟi hӋ thӕng cӫa chúng ta.

- Chúng ta có các mүu, thư viӋn lӟp , thành phҫn và nhӳng thӭ khác không? NӃu
chúng ta có mүu, thư viӋn, thành phҫn tӯ các dӵ án trưӟc (xin đưӧc cӫa các bҥn đӗng
nghiӋp, mua đưӧc tӯ các nhà cung cҩp) thì chúng thưӡng cũng sӁ chӭa các ӭng cӱ viên
lӟp.

- Có thiӃt bӏ ngoҥi vi mà hӋ thӕng cӫa chúng ta cҫn xӱ lý không? Mӛi thiӃt bӏ kӻ

thuұt đưӧc nӕi vӟi hӋ thӕng cӫa chúng ta thưӡng sӁ trӣ thành ӭng cӱ viên cho lӟp xӱ lý
loҥi thiӃt bӏ ngoҥi vi này.

- Chúng ta có phҫn công viӋc tә chӭc không? Miêu tҧ mӝt đơn vӏ tә chӭc là công
viӋc đưӧc thӵc hiӋn vӟi các lӟp, đһc biӋt là trong các mô hình doanh nghiӋp.

2.1.3- Tәng kӃt vӅ các nguӗn thông tin cho viӋc tìm lӟp:

Nhìn chung, các nguӗn thông tin chính cҫn đһc biӋt chú ý khi tìm lӟp là :
 - Các lӡi phát biӇu yêu cҫu

- Các Trưӡng hӧp sӱ dөng

- Sӵ trӧ giúp cӫa các chuyên gia ӭng dөng

- Nghiên cӭu hӋ thӕng hiӋn thӡi

Loҥt các lӟp đҫu tiên đưӧc nhұn dҥng qua đây thưӡng đưӧc gӑi là các lӟp ӭng cӱ viên
(Candidate Class). Ngoài ra, nghiên cӭu nhӳng hӋ thӕng tương tӵ cũng có thӇ sӁ mang lҥi
cho ta các lӟp ӭng cӱ viên khác:

Khi nghiên cӭu hӋ thӕng hiӋn thӡi, hãy đӇ ý đӃn các danh tӯ và các khái niӋm then chӕt
đӇ nhұn ra lӟp ӭng cӱ viên. Không nên đưa các lӟp đã đưӧc nhұn diӋn mӝt lҫn nӳa vào
mô hình chӍ bӣi vì chúng đưӧc nhҳc lҥi ӣ đâu đó theo mӝt tên gӑi khác. Ví dө, mӝt hӋ
thӕng nhà băng có thӇ coi cùng mӝt khách hàng vӟi nhiӅu vӏ trí khác nhau là nhiӅu khách
hàng khác nhau. Cҫn chú ý khi phân tích nhӳng lӡi miêu tҧ như thӃ đӇ tránh dүn đӃn sӵ
trùng lһp trong quá trình nhұn diӋn lӟp.

Có nhiӅu nguӗn thông tin mà nhà thiӃt kӃ cҫn phҧi chú ý tӟi khi thiӃt kӃ lӟp và chӍ khi
làm như vұy, ta mӟi có thӇ tin chҳc vӅ khҧ năng tҥo dӵng mӝt mô hình tӕt. Hình sau tәng
kӃt các nguӗn thông tin kӇ trên.

Hình 5. - Nguӗn thông tin hӛ trӧ tìm lӟp

Các trưӡng hӧp sӱ dөng là nguӗn tӕt nhҩt cho viӋc nhұn diӋn lӟp và đӕi tưӧng. Cҫn
nghiên cӭu kӻ các Trưӡng hӧp sӱ dөng đӇ tìm các thuӝc tính (attribute) báo trưӟc sӵ tӗn
tҥi cӫa đӕi tưӧng hoһc lӟp tiӅm năng. Ví dө nӃu Trưӡng hӧp sӱ dөng yêu cҫu phҧi đưa
vào mӝt sӕ tài khoҧn (account-number) thì điӅu này trӓ tӟi sӵ tӗn tҥi cӫa mӝt đӕi tưӧng
tài khoҧn.

Mӝt nguӗn khác đӇ nhұn ra lӟp/đӕi tưӧng là các Input và Output cӫa hӋ thӕng. NӃu Input
bao gӗm tên khách hàng thì đây là tín hiӋu cho biӃt sӵ tӗn tҥi cӫa mӝt đӕi tưӧng khách
hàng, bӣi nó là mӝt attribute cӫa khách hàng.

Nói chuyӋn vӟi ngưӡi sӱ dөng cũng gӧi mӣ đӃn các khái niӋm then chӕt. Thưӡng thì
ngưӡi sӱ dөng miêu tҧ hӋ thӕng theo lӕi cҫn phҧi đưa vào nhӳng gì và mong chӡ kӃt quҧ
gì. Thông tin đưa vào và kӃt quҧ theo lӕi miêu tҧ cӫa ngưӡi sӱ dөng cҫn phҧi đưӧc tұp
hӧp lҥi vӟi nhau đӇ nhұn dҥng khái niӋm then chӕt.

2.2- Các lӟp ӭng cӱ viên:

Theo các bưӟc kӇ trên trong phҫn đҫu giai đoҥn phân tích, ta đã miêu tҧ đưӧc mӝt sӕ lӟp
khác nhau. Nhӳng lӟp này đưӧc gӑi là các lӟp ӭng cӱ viên, chúng thӇ hiӋn nhӳng lӟp có
khҧ năng tӗn tҥi trong mӝt hӋ thӕng cho trưӟc. Mһc dù vұy, đây vүn có thӇ chưa phҧi là
kӃt quҧ chung cuӝc, mӝt sӕ lӟp ӭng cӱ viên có thӇ sӁ bӏ loҥi bӓ trong các bưӟc sau vì
không thích hӧp.

Giai đoҥn đҫu khi đӏnh nghĩa các lӟp ӭng cӱ viên, ta chưa nên cӕ gҳng thanh lӑc các lӟp,
hãy tұp trung cáo mөc tiêu nghiên cӭu bao quát và toàn diӋn tӯ nhiӅu nguӗn thông tin
khác nhau đӇ không bӓ sót nhiӅu khía cҥnh cҫn xӱ lý.

Ví dө trong nhà mӝt băng lҿ, các lӟp ӭng cӱ viên có thӇ là:

- Khách hàng

- Các loҥi tài khoҧn khác nhau

- Sec, sә tiӃt kiӋm, đơn, «.

- PhiӃu yêu cҫu mӣ tài khoҧn mӟi

- Thҿ ATM

- Bҧn in thông tin vӅ tài khoҧn

- Giҩy chӭng nhұn tài khoҧn đҫu tư

- Thҿ xӃp hàng (Token), sӕ thӭ tӵ

- Nhân viên

- Nhân viên thu ngân

2.3- Loҥi bӓ các lӟp ӭng cӱ viên không thích hӧp:

Có rҩt nhiӅu loҥi lӟp ӭng cӱ viên không thích hӧp cҫn phҧi đưӧc loҥi bӓ:

Lӟp dư, thӯa: Khi có hơn mӝt lӟp đӏnh nghĩa cùng mӝt thӵc thӇ, nên giӳ lҥi lӟp tӕt nhҩt
và loҥi bӓ nhӳng lӟp khác. Ví dө, trong mӝt nhà băng có hai lӟp chӫ tài khoҧn và khách
hàng. Cҧ hai lӟp biӇu hiӋn cùng mӝt thӵc thӇ và vì thӃ chӍ cҫn giӳ lҥi mӝt.
Lӟp không thích hӧp: Lӟp đӏnh nghĩa ra nhӳng thӵc thӇ không liên quan đӃn vҩn đӅ
thӵc tҥi. Mӑi lӟp không xuҩt phát tӯ phҥm vi ӭng dөng cҫn phҧi đưӧc loҥi bӓ. Ví dө, lӟp
cӫa các máy đӃm tiӅn bên casse trong mӝt nhà băng có thӇ là mӝt ӭng cӱ viên cho khái
niӋm lӟp không thích hӧp.

Lӟp không rõ ràng: Lӟp không có chӭc năng cө thӇ đưӧc gӑi là các lӟp không rõ ràng.
Lӟp tӗn tҥi và có giá trӏ sӱ dөng trong mӝt hӋ thӕng là lӟp có mӝt chӭc năng đã đưӧc
nhұn diӋn và xác đӏnh rõ ràng. Các lӟp không rõ ràng cҫn phҧi đưӧc đӏnh nghĩa lҥi hoһc
loҥi bӓ. Ví dө quan sát nhiӅu bӝ phұn khác nhau trong mӝt nhà băng ABC. Mӝt trong
nhӳng bӝ phұn đã đưӧc nhұn diӋn có thӇ là bӝ phұn hành chính. Vì phҥm vi cho quá trình
vi tính hóa cӫa nhà băng hiӋn thӡi chưa bao gӗm mҧng hành chính nên lӟp này có thӇ
đưӧc coi là mӝt lӟp không rõ ràng (vì không có chӭc năng rõ ràng trong hӋ thӕng cҫn xây
dӵng trưӟc mҳt).

- Tương tӵ, nhӳng thuӝc tính và phương thӭc không rõ ràng cҫn phҧi đưӧc loҥi ra
khӓi danh sách các lӟp ӭng cӱ viên. Chúng không cҫn phҧi bӏ xoá hҷn, nhưng cҫn đưӧc
đưa ra ngoài đӇ ta có thӇ nhìn rõ các lӟp cҫn thiӃt đã đưӧc nhұn diӋn. Các ӭng xӱ đó sau
này có thӇ đưӧc gán cho các lӟp thích hӧp hơn.

- Các lӟp chӍ là vai trò (Role) đӕi vӟi mӝt lӟp khác: Hãy loҥi bӓ tҩt cҧ các vai trò
và giӳ lҥi lӟp chính. Ví dө nhà quҧn trӏ, nhân viên thu ngân, ngưӡi chҥy giҩy rҩt có thӇ
chӍ là vai trò cӫa lӟp nhân viên. Hãy giӳ lҥi lӟp nhân viên và loҥi bӓ tҩt cҧ nhӳng lӟp
khác chӍ là vai trò.

- Mӝt lӟp không cung cҩp ӭng xӱ cҫn thiӃt hoһc thuӝc tính cҫn thiӃt có thӇ sӁ là
lӟp không cҫn thiӃt. NhiӅu khi, có thӇ có mӝt lӟp chҷng cung cҩp mӝt thuӝc tính hoһc
ӭng xӱ nào mà chӍ đӏnh nghĩa mӝt tұp hӧp các mӕi quan hӋ. Nhӳng lӟp như thӃ cҫn phҧi
đưӧc nghiên cӭu kӻ đӇ xác đӏnh sӵ liên quan vӟi hӋ thӕng. V

3- LӞP VÀ ĐӔI TƯӦNG TRONG UML

UML thӇ hiӋn lӟp bҵng hình chӳ nhұt có 3 phҫn. Phҫn thӭ nhҩt chӭa tên lӟp. Trong phҫn
thӭ hai là thuӝc tính và các dӳ liӋu thành phҫn cӫa lӟp và trong phҫn thӭ ba là các
phương thӭc hay hàm thành phҫn cӫa lӟp.

3.1- Tên lӟp (lass name) :

Tên lӟp đưӧc in đұm (bold) và căn giӳa. Tên lӟp phҧi đưӧc dүn xuҩt tӯ phҥm vi vҩn đӅ
và rõ ràng như có thӇ. Vì thӃ nó là danh tӯ, ví dө như tài khoҧn, nhân viên, ....

3.2- Thuӝc tính (attribute):

Lӟp có thuӝc tính miêu tҧ nhӳng đһc điӇm cӫa đӕi tưӧng. Giá trӏ cӫa thuӝc tính thưӡng là
nhӳng dҥng dӳ liӋu đơn giҧn đưӧc đa phҫn các ngôn ngӳ lұp trình hӛ trӧ như Integer,
Boolean, Floats, Char, «
Thuӝc tính có thӇ có nhiӅu mӭc đӝ trông thҩy đưӧc (visibility) khác nhau, miêu tҧ liӋu
thuӝc tính đó có thӇ đưӧc truy xuҩt tӯ các lӟp khác, khác vӟi lӟp đӏnh nghĩa ra nó. NӃu
thuӝc tính có tính trông thҩy là công cӝng (public), thì nó có thӇ đưӧc nhìn thҩy và sӱ
dөng ngoài lӟp đó. NӃu thuӝc tính có tính trông thҩy là riêng (private), bҥn sӁ không thӇ
truy cұp nó tӯ bên ngoài lӟp đó. Mӝt tính trông thҩy khác là bҧo vӋ (protected), đưӧc sӱ
dөng chung vӟi công cө khái quát hóa và chuyên biӋt hóa. Nó cũng giӕng như các thuӝc
tính riêng nhưng đưӧc thӯz kӃ bӣi các lӟp dүn xuҩt.

Trong UML, thuӝc tính công cӝng mang kí hiӋu "+" và thuӝc tính riêng mang dҩu "-".

Giá trӏ đưӧc gán cho thuӝc tính có thӇ là mӝt cách đӇ miêu tҧ trҥng thái cӫa đӕi tưӧng.
Mӛi lҫn các giá trӏ này thay đәi là biӇu hiӋn cho thҩy có thӇ đã xҧy ra mӝt sӵ thay đәi
trong trҥng thái cӫa đӕi tưӧng.

Lưu ý: Mӑi đһc điӇm cӫa mӝt thӵc thӇ là nhӳng thông tin cҫn lưu trӳ đӅu có thӇ chuyӇn
thành thuӝc tính cӫa lӟp miêu tҧ loҥi thӵc thӇ đó.

3.3- Phương thӭc (methods):

Phương thӭc đӏnh nghĩa các hoҥt đӝng mà lӟp có thӇ thӵc hiӋn. Tҩt cҧ các đӕi tưӧng
đưӧc tҥo tӯ mӝt lӟp sӁ có chung thuӝc tính và phương thӭc. Phương thӭc đưӧc sӱ dөng
đӇ xӱ lý thay đәi các thuӝc tính cũng như thӵc hiӋn các công viӋc khác. Phương thӭc
thưӡng đưӧc gӑi là các hàm (function), nhưng chúng nҵm trong mӝt lӟp và chӍ có thӇ
đưӧc áp dөng cho các đӕi tưӧng cӫa lӟp này. Mӝt phương thӭc đưӧc miêu tҧ qua tên, giá
trӏ trҧ vӅ và danh sách cӫa 0 cho tӟi nhiӅu tham sӕ. Lúc thi hành, phương thӭc đưӧc gӑi
kèm theo mӝt đӕi tưӧng cӫa lӟp. Vì nhóm các phương thӭc miêu tҧ nhӳng dӏch vө mà
lӟp có thӇ cung cҩp nên chúng đưӧc coi là giao diӋn cӫa lӟp này. Giӕng như thuӝc tính,
phương thӭc cũng có tính trông thҩy đưӧc như công cӝng, riêng và bҧo vӋ.

Hình 5.5- Mӝt lӟp vӟi các thuӝc tính tiêu biӇu
 Hình 5.6- Mӝt lӟp vӟi các thuӝc tính chung và riêng

Hình 5.7- Mӝt lӟp vӟi các thuӝc tính và gía trӏ mһc nhiên

Hình 5.8- Mӝt lӟp gӗm các thuӝc tính vӟi gía trӏ mһc nhiên và thuӝc tính phҥm vi lӟp
 Hình 5.9- Mӝt thuӝc tính vӟi liӋt kê gía trӏ (status)

3.- Kí hiӋu đӕi tưӧng:

Đӕi tưӧng là thӵc thӇ cӫa các lӟp nên kí hiӋu dùng cho đӕi tưӧng cũng là kí hiӋu dùng
cho lӟp.

Hình 5.10-Ký hiӋu đӕi tưӧng

Hình trên đưӧc đӑc như sau: CAH là đӕi tưӧng cӫa lӟp AccountHolder. Các thuӝc tính
đưӧc gán giá trӏ, đây là các giá trӏ khi lӟp đưӧc thӵc thӇ hóa. Chú ý rҵng kí hiӋu đӕi
tưӧng không chӭa phҫn phương thӭc.

Hình 5.11- Các dҩu hiӋu hành đӝng

 Hình 5.12- Các giá trӏ mһc nhiên cӫa tham sӕ

- QUAN Hӊ GIӲA CÁC LӞP

BiӇu đӗ lӟp thӇ hiӋn các lӟp và các mӕi quan hӋ giӳa chúng. Quan hӋ giӳa các lӟp gӗm
có bӕn loҥi:

- Liên hӋ (Association)

- Khái quát hóa (Generalization)

- Phө thuӝc (Dependency)

- Nâng cҩp (Refinement)

Mӝt liên hӋ là mӝt sӵ nӕi kӃt giӳa các lӟp, cũng có nghĩa là sӵ nӕi kӃt giӳa các đӕi tưӧng
cӫa các lӟp này. Trong UML, mӝt liên hӋ đưӧc đӏnh nghĩa là mӝt mӕi quan hӋ miêu tҧ
mӝt tұp hӧp các nӕi kӃt (links), trong khi nӕi kӃt đưӧc đӏnh nghĩa là mӝt sӵ liên quan vӅ
ngӳ nghĩa (semantic connection) giӳa mӝt nhóm các đӕi tưӧng.

Khái quát hóa là mӕi quan hӋ giӳa mӝt yӃu tӕ mang tính khái quát cao hơn và mӝt yӃu tӕ
mang tính chuyên biӋt hơn. YӃu tӕ mang tính chuyên biӋt hơn có thӇ chӭa chӍ các thông
tin bә sung. Mӝt thӵc thӇ (mӝt đӕi tưӧng là mӝt thӵc thӇ cӫa mӝt lӟp) cӫa yӃu tӕ mang
tính chuyên biӋt hơn có thӇ đưӧc sӱ dөng ӣ bҩt cӭ nơi nào mà đӕi tưӧng mang tính khái
quát hóa hơn đưӧc phép.

Sӵ phө thuӝc là mӝt mӕi quan hӋ giӳa các yӃu tӕ, gӗm mӝt yӃu mang tính đӝc lұp và mӝt
yӃu tӕ mang tính phө thuӝc. Mӝt sӵ thay đәi trong yӃu tӕ đӝc lұp sӁ ҧnh hưӣng đӃn yӃu
tӕ phө thuӝc.

Mӝt sӵ nâng cҩp là mӕi quan hӋ giӳa hai lӡi miêu tҧ cӫa cùng mӝt sӵ vұt, nhưng ӣ nhӳng
mӭc đӝ trӯu tưӧng hóa khác nhau.

5- LIÊN Hӊ (ASSOCIATION)

Mӝt liên hӋ là mӝt sӵ nӕi kӃt giӳa các lӟp, mӝt liên quan vӅ ngӳ nghĩa giӳa các đӕi tưӧng
cӫa các lӟp tham gia. Liên hӋ thưӡng thưӡng mang tính hai chiӅu, có nghĩa khi mӝt đӕi
tưӧng này có liên hӋ vӟi mӝt đӕi tưӧng khác thì cҧ hai đӕi tưӧng này nhұn thҩy nhau.
Mӝt mӕi liên hӋ biӇu thӏ bҵng các đӕi tưӧng cӫa hai lӟp có nӕi kӃt vӟi nhau, ví dө rҵng
"chúng biӃt vӅ nhau", "đưӧc nӕi vӟi nhau", "cӭ mӛi X lҥi có mӝt Y", .... Lӟp và liên hӋ
giӳa các lӟp là nhӳng công cө rҩt mҥnh mӁ cho viӋc mô hình hóa các hӋ thӕng phӭc tҥp,
ví dө như cҩu trúc sҧn phҭm, cҩu trúc văn bҧn và tҩt cҧ các cҩu trúc thông tin khác.

Mӕi liên kӃt đưӧc thӇ hiӋn trong biӇu đӗ UML bҵng mӝt đưӡng thҷng nӕi hai lӟp.
 Hình 5.13-Mӝt lӟp Author kӃt hӧp vӟi lӟp Computer

5.1- Vai trò trong liên hӋ:

Mӝt liên hӋ có thӇ có các vai trò (Roles). Các vai trò đưӧc nӕi vӟi mӛi lӟp bao chӭa trong
quan hӋ. Vai trò cӫa mӝt lӟp là chӭc năng mà nó đҧm nhұn nhìn tӯ góc nhìn cӫa lӟp kia.
Tên vai trò đưӧc viӃt kèm vӟi mӝt mũi tên chӍ tӯ hưӟng lӟp chӫ nhân ra, thӇ hiӋn lӟp này
đóng vai trò như thӃ nào đӕi vӟi lӟp mà mũi tên chӍ đӃn.

Hình 5.1- Vai trò trong liên hӋ giӳa Customer và Account

Trong ví dө trên: mӝt khách hàng có thӇ là chӫ nhân cӫa mӝt tài khoҧn và tài khoҧn đưӧc
chiӃm giӳ bӣi khách hàng. Đưӡng thҷng thӇ hiӋn liên hӋ giӳa hai lӟp.

Mӝt sӕ điӇm cҫn chú ý khi đһt tên vai trò :

- Tên vai trò có thӇ bӓ đi nӃu trùng vӟi tên lӟp

- Tên vai trò phҧi là duy nhҩt.

- Tên vai trò phҧi khác vӟi các thuӝc tính cӫa lӟp.

- Tên vai trò phҧi miêu tҧ đưӧc chӭc năng mà lӟp này đҧm nhұn trong quan hӋ,
tӭc cҫn phҧi là các khái niӋm lҩy ra tӯ phҥm vi vҩn đӅ, giӕng như tên các lӟp.

5.2- Liên hӋ mӝt chiӅu (Uni-Directional Association):

Ta cũng có thӇ sӱ dөng mӕi liên hӋ mӝt chiӅu bҵng cách thêm mӝt mũi tên và mӝt đҫu
cӫa đưӡng thҷng nӕi kӃt. Mũi tên chӍ ra rҵng sӵ nӕi kӃt chӍ có thӇ đưӧc sӱ dөng duy nhҩt
theo chiӅu cӫa mũi tên.
 Hình 5.15- Liên hӋ mӝt chiӅu giӳa Interest và Account

BiӇu đӗ phҫn 5.15 thӇ hiӋn rҵng giӳa hai lӟp có liên hӋ, nhưng không hӅ có thông tin vӅ
sӕ lưӧng các đӕi tưӧng trong quan hӋ. Ta không thӇ biӃt mӝt khách hàng có thӇ có bao
nhiêu tài khoҧn và mӝt tài khoҧn có thӇ là cӫa chung cho bao nhiêu khách hàng. Trong
UML, loҥi thông tin như thӃ đưӧc gӑi là sӕ lưӧng phҫn tӱ (Cardinality) trong quan hӋ.

5.3- Sӕ lưӧng (Cardinality) trong liên hӋ:

Hình 5.16- Sӕ lưӧng trong liên hӋ giӳa Customer và Account

BiӇu đӗ trên nói rõ mӝt khách hàng có thӇ mӣ mӝt hoһc nhiӅu tài khoҧn và mӝt tài khoҧn
có thӇ thuӝc vӅ mӝt cho tӟi ba khách hàng.

Sӕ lưӧng đưӧc ghi ӣ phía đҫu đưӡng thҷng thӇ hiӋn liên hӋ, sát vào lӟp là miӅn áp dөng
cӫa nó. Phҥm vi cӫa sӕ lưӧng phҫn tӱ trong liên hӋ có thӇ tӯ 0-tӟi-1 (0..1), 0-tӟi-nhiӅu
(0..* hay ), mӝt-tӟi-nhiӅu (1..), hai (2), năm-tӟi-mưӡi mӝt (5..11). Cũng có thӇ miêu tҧ
mӝt dãy sӕ ví dө (1,4,6, 8..12). Giá trӏ mһc đӏnh là 1.
 Hình 5.17- Mӝt sơ đӗ lӟp tiêu biӇu

Hình trên là ví dө cho mӝt biӇu đӗ lӟp tiêu biӇu. BiӇu đӗ giҧi thích rҵng bӝ phұn dӏch vө
tài khoҧn tiӃt kiӋm cӫa mӝt nhà băng có thӇ có nhiӅu tài khoҧn tiӃt kiӋm nhưng tҩt cҧ
nhӳng tài khoҧn này đӅu thuӝc vӅ bӝ phұn đó. Mӝt tài khoҧn tiӃt kiӋm vӅ phҫn nó lҥi có
thӇ có nhiӅu tài liӋu, nhưng nhӳng tài liӋu này chӍ thuӝc vӅ mӝt tài khoҧn tiӃt kiӋm mà
thôi. Mӝt tài khoҧn tiӃt kiӋm có thӇ thuӝc vӅ tӯ 1 cho tӟi nhiӅu nhҩt là 3 khách hàng. Mӛi
khách hàng có thӇ có nhiӅu hơn mӝt tài khoҧn.

5.- Phát hiӋn liên hӋ:

Thưӡng sӁ có nhiӅu mӕi liên hӋ giӳa các đӕi tưӧng trong mӝt hӋ thӕng. QuyӃt đӏnh liên
hӋ nào cҫn phҧi đưӧc thӵc thi là công viӋc thөôc giai đoҥn thiӃt kӃ. Có thӇ tìm các mӕi
liên hӋ qua viӋc nghiên cӭu các lӡi phát biӇu vҩn đӅ, các yêu cҫu. Giӕng như danh tӯ đã
giúp chúng ta tìm lӟp, các đӝng tӯ ӣ đây sӁ giúp ta tìm ra các mӕi quan hӋ.

Mӝt vài lӡi mách bҧo khi tìm liên hӋ :

- Vӏ trí vӅ mһt vұt lý hoһc sӵ thay thӃ, đҥi diӋn: Mӛi cөm đӝng tӯ xác đӏnh hay
biӇu lӝ mӝt vӏ trí đӅu là mӝt biӇu hiӋn chҳc chҳn cho liên hӋ. Ví dө: tҥi đӏa điӇm, ngӗi
trong, «

- Sӵ bao chӭa: Cөm đӝng tӯ biӇu lӝ sӵ bao chӭa, ví dө như : là thành phҫn cӫa....

- Giao tiӃp: Có nhiӅu cөm đӝng tӯ biӇu lӝ sӵ giao tiӃp, ví dө truyӅn thông điӋp,
nói chuyӋn vӟi, «

- QuyӅn sӣ hӳu: Ví dө : thuӝc vӅ, cӫa, «

- Thoҧ mãn mӝt điӅu kiӋn: Nhӳng cөm tӯ như : làm viӋc cho, là chӗng/vӧ cӫa,
quҧn trӏ, «.

5.5- Xӱ lý các liên hӋ không cҫn thiӃt:

Sau khi tìm các mӕi liên hӋ, bưӟc tiӃp theo đó là phân biӋc các liên hӋ cҫn thiӃt ra khӓi
các liên hӋ không cҫn thiӃt. Liên hӋ không cҫn thiӃt có thӇ bao gӗm nhӳng liên hӋ bao
chӭa các lӟp ӭng cӱ viên đã bӏ loҥi trӯ hoһc các liên hӋ không liên quan đӃn hӋ thӕng. Có
nhӳng liên hӋ đưӧc tҥo ra nhҵm mөc đích tăng hiӋu quҧ. Nhӳng liên hӋ như thӃ là ví dө
tiêu tiӇu cӫa các chi tiӃt thӵc thi và không liên quan tӟi giai đoҥn này.

Cҫn chú ý phân biӋt giӳa hành đӝng và mӕi liên hӋ. Ngưӡi ta thưӡng có xu hưӟng miêu
tҧ hành đӝng như là liên hӋ, bӣi cҧ liên hӋ lүn hành đӝng đӅu đưӧc dүn xuҩt tӯ nhӳng
cөm tӯ mang tính đӝng tӯ trong bҧn miêu tҧ yêu cҫu. Các hành đӝng đã đưӧc thӇ hiӋn sai
thành liên hӋ cũng cҫn phҧi đưӧc loҥi bӓ. Khi làm viӋc này, có thӇ áp dөng mӝt nguyên
tҳc: liên hӋ là nӕi kӃt mang tính tĩnh giӳa các đӕi tưӧng, trong khi hành đӝng chӍ là thao
tác xҧy ra mӝt lҫn. Hành đӝng vì vұy nên đưӧc coi là Phương thӭc đӕi vӟi mӝt đӕi tưӧng
chӭ không phҧi quan hӋ giӳa các lӟp.

Ví dө vӟi "Ban quҧn trӏ nhà băng đuәi viӋc mӝt nhân viên", đӝng tӯ ³đuәi viӋc´ thӇ hiӋn
hành đӝng. Trong khi đó vӟi ³Mӝt nhân viên làm viӋc cho hãng" thì đӝng tӯ ³làm viӋc"
miêu tҧ liên hӋ giӳa hai lӟp nhân viên và hãng.

Trong khi cӕ gҳng loҥi bӓ các liên hӋ dư thӯa, bҥn sӁ thҩy có mӝt sӕ liên hӋ dư thӯa đã
"lҿn vào" mô hình cӫa chúng ta trong giai đoҥn thiӃt kӃ. Hình sau chӍ ra mӝt sӕ loҥi liên
hӋ dư thӯa cҫn đһc biӋt chú trӑng.

Hình 5.18- Loҥi bӓ các liên hӋ không cҫn thiӃt

5.6- Nâng cҩp các mӕi liên hӋ:

Mӝt khi các mӕi liên hӋ cҫn thiӃt đã đưӧc nhұn dҥng, bưӟc tiӃp theo là ngiên cӭu kӻ mô
hình và nâng cҩp các mӕi liên hӋ đó.

Đӝng tác nâng cҩp đҫu tiên là xem xét lҥi tên liên hӋ, tên vai trò, đһt lҥi cho đúng vӟi bҧn
chҩt quan hӋ mà chúng thӇ hiӋn. Mӛi liên hӋ cҫn phҧi đưӧc suy xét kӻ vӅ phương diӋn sӕ
lưӧng thành phҫn tham gia (Cardinality). Sӵ hҥn đӏnh (Qualification) cho liên hӋ đóng
mӝt vai trò quan trӑng ӣ đây, bә sung yӃu tӕ hҥn đӏnh có thӇ giúp làm giҧm sӕ lưӧng.
NӃu cҫn thiӃt, hãy bә sung các liên hӋ còn thiӃu. Nghiên cӭu kӻ các thuӝc tính, xem liӋu
trong sӕ chúng có thuӝc tính nào thұt ra thӇ hiӋn liên hӋ. NӃu có, hãy chuyӇn chúng thành
liên hӋ. Bә sung các thông tin và điӅu kiӋn cҫn thiӃt cũng như xem xét các mӕi liên hӋ
trong mô hình tәng thӇ đӇ xác đӏnh các dҥng quan hӋ giӳa chúng vӟi nhau.

5.6.1- Liên hӋ và yӃu tӕ hҥn đӏnh (Qualifier):

Mӝt liên hӋ đưӧc hҥn đӏnh liên hӋ hai lӟp và mӝt yӃu tӕ hҥn đӏnh (Qualifier) vӟi nhau.
YӃu tӕ hҥn đӏnh là mӝt thuӝc tính hҥn chӃ sӕ lưӧng thành phҫn tham gia trong mӝt mӕi
liên hӋ. Có thӇ hҥn đӏnh các mӕi liên hӋ mӝt-tӟi nhiӅu và nhiӅu-tӟi-nhiӅu. YӃu tӕ hҥn
đӏnh giúp phân biӋt trong nhóm đӕi tưӧng cӫa đҫu nhiӅu cӫa liên hӋ.

Ví dө mӝt thӵ mөc có nhiӅu tұp tin.Mӝt tұp tin chӍ thuӝc vӅ mӝt thư mөc mà thôi. Trong
mӝt thư mөc xác đӏnh, tên cӫa tұp tin sӁ xác đӏnh duy nhҩt tұp tin mang tên đó. Thư mөc
và Tұp tin là hai lӟp, và tên tұptin ӣ đây đóng vai trò yӃu tӕ hҥn đӏnh. Mӝt thư mөc và
mӝt tên tұp tin xác đӏnh mӝt tұp tin. YӃu tӕ hҥn đӏnh ӣ đây đã chuyӇn mӝt mӕi liên hӋ
mӝt-tӟi-nhiӅu thành liên hӋ mӝt-tӟi-mӝt.

Hình 5.19- Liên hӋ đưӧc hҥn đӏnh

5.6.2- Liên hӋ VÀ (AND Association)

Nhà băng nӑ đưa ra quy đӏnh: khách hàng khi muӕn mӣ mӝt tài khoҧn ATM phҧi là chӫ
nhân cӫa ít nhҩt mӝt tài khoҧn đҫu tư. Trong mӝt trưӡng hӧp như thӃ, mӕi liên hӋ VÀ
(AND) sӁ đưӧc thӇ hiӋn như sau:

Hình 5.20- Liên hӋ VÀ (AND Association)

BiӇu đӗ trên cho thҩy mӝt khách hàng có thӇ có nhiӅu hơn mӝt tài khoҧn đҫu tư có thӡi
hҥn và chӍ mӝt tài khoҧn ATM. Trong biӇu đӗ có mӝt mӕi liên hӋ VÀ ngҫm đưӧc áp
dөng giӳa nhóm tài khoҧn đҫu tư và tài khoҧn ATM mà mӝt khách hàng có thӇ có.

5.6.3- Liên hӋ HOҺC (OR Association)

Ví dө tҥi mӝt hãng bҧo hiӇm nӑ, cá nhân cũng công ty đӅu có thӇ ký hӧp đӗng bҧo hiӇm,
nhưng cá nhân và công ty không đưӧc phép có E 1 hӧp đӗng bҧo hiӇm như nhau.
Trong mӝt trưӡng hӧp như thӃ, giҧi pháp là sӱ dөng liên hӋ HOҺC (OR Association).
Mӝt liên hӋ HOҺC là mӝt sӵ hҥn chӃ đӕi vӟi mӝt nhóm hai hay nhiӅu liên hӋ, xác đӏnh
rҵng đӕi tưӧng cӫa mӝt lӟp này tҥi mӝt thӡi điӇm chӍ có thӇ tham gia vào nhiӅu nhҩt mӝt
trong các mӕi liên hӋ đó.

Hình 5.21- Mӝt liên hӋ OR mà biӇu thӏ chӍ mӝt liên hӋ là hӧp lӋ tҥi mӛi thӡi điӇm

5.6.- Liên hӋ đưӧc sҳp xӃp (Ordered Association)

Các mӕi nӕi kӃt (link) giӳa các đӕi tưӧng có mӝt trұt tӵ ngҫm đӏnh. Giá trӏ mһc đӏnh cӫa
trұt tӵ này là ngүu nhiên. Mӝt liên hӋ có trұt tӵ rõ ràng có thӇ đưӧc hiӇu là mӝt liên hӋ vӟi
trұt tӵ sҳp xӃp (sort order) trong nhóm các nӕi kӃt, nó sӁ đưӧc thӇ hiӋn như sau:

Hình 5.22- Tài khoҧn tiӃt kiӋm đưӧc sҳp xӃp theo khách hàng

Nhãn {ordered} đưӧc ghi gҫn lӟp có đӕi tưӧng đưӧc sҳp xӃp. BiӇu đӗ trên đưӧc đӑc là
các tài khoҧn tiӃt kiӋm đưӧc sҳp xӃp theo khách hàng.

5.6.5- Liên hӋ tam nguyên (Ternary Association)

Có thӇ có nhiӅu hơn hai lӟp nӕi kӃt vӟi nhau trong mӝt liên hӋ tam nguyên.
 Hình 5.23- Liên hӋ Tam nguyên

BiӇu đӗ trên đưӧc đӑc như sau: Mӝt khách hàng có thӇ quan hӋ vӟi bӝ phұn đҫu tư và
mӝt bӝ phұn đҫu tư có thӇ có mӝt hoһc nhiӅu khách hàng. Mӝt giҩy chӭng nhұn tài khoҧn
đҫu tư sӁ xuҩt hiӋn qua quan hӋ giӳa khách hàng và bӝ phұn đҫu tư.

5.6.6- Lӟp liên hӋ (Association Class)

Mӝt lӟp có thӇ đưӧc đính kèm theo mӝt liên hӋ, trong trưӡng hӧp này nó sӁ đưӧc gӑi là
mӝt lӟp liên hӋ. Mӝt lӟp liên hӋ không đưӧc nӕi tӟi bҩt kǤ mӝt lӟp nào cӫa mӕi liên hӋ,
mà tӟi chính bҧn thân mӕi liên hӋ. Cũng giӕng như mӝt lӟp bình thưӡng, lӟp liên hӋ có
thӇ có thuӝc tính, Phương thӭc và các quan hӋ khác. Lӟp liên hӋ đưӧc sӱ dөng đӇ bә sung
thêm thông tin cho nӕi kӃt (link), ví dө như thӡi điӇm nӕi kӃt đưӧc thiӃt lұp. Mӛi nӕi kӃt
cӫa liên hӋ gҳn liӅn vӟi mӝt đӕi tưӧng cӫa lӟp liên hӋ.

Ví dө sau miêu tҧ mӝt hӋ thӕng thang máy. Bӝ phұn điӅu khiӇn chӍ huy bӕn thang máy.
Cho mӛi nӕi kӃt giӳa nhóm thang máy và bӝ phұn điӅu khiӇn có mӝt hàng xӃp (queue).
Mӛi hàng lưu trӳ nhӳng yӅu cҫu kӇ cҧ tӯ phía bӝ phұn điӅu khiӇn lүn tӯ phía thang máy
(nhӳng nút bҩm bên trong thang). Khi bӝ phұn điӅu khiӇn chӑn mӝt thang máy đӇ thӵc
hiӋn mӝt lӡi yêu cҫu đӃn tӯ mӝt hành khách đӭng ngoài thang máy (mӝt hành khách trên
hành lang), nó sӁ đӑc các hàng và chӑn thang máy nào có hàng yêu cҫu ngҳn nhҩt.
 Hình 5.2- Lӟp liên hӋ (Association class)

5.6.7- Liên hӋ đӋ quy (Recursive Association)

Có thӇ liên kӃt mӝt lӟp vӟi bҧn thân nó trong mӝt mӕi liên hӋ. Mӕi liên hӋ ӣ đây vүn thӇ
hiӋn mӝt sӵ liên quan ngӳ nghĩa, nhưng các đӕi tưӧng đưӧc nӕi kӃt đӅu thuӝc chung mӝt
lӟp. Mӝt liên hӋ cӫa mӝt lӟp vӟi chính bҧn thân nó đưӧc gӑi là mӝt liên hӋ đӋ quy, và là
nӅn tҧng cho rҩt nhiӅu mô hình phӭc tҥp, sӱ dөng ví dө đӇ miêu tҧ các cҩu trúc sҧn phҭm.
Hình 5.25 chӍ ra mӝt ví dө cӫa liên hӋ đӋ quy và hình 5.26 là mӝt biӇu đӗ đӕi tưӧng cho
biӇu đӗ lӟp trong hình 5.25.

Hình 5.25- Mӝt mҥng gӗm nhiӅu nút nӕi vӟi nhau.
 Hình 5.26- Mӝt biӇu đӗ đӕi tưӧng cӫa hình 5.25, vӟi tên cӫa các đӕi tưӧng.

5- LIÊN Hӊ (ASSOCIATION)

Mӝt liên hӋ là mӝt sӵ nӕi kӃt giӳa các lӟp, mӝt liên quan vӅ ngӳ nghĩa giӳa các đӕi tưӧng
cӫa các lӟp tham gia. Liên hӋ thưӡng thưӡng mang tính hai chiӅu, có nghĩa khi mӝt đӕi
tưӧng này có liên hӋ vӟi mӝt đӕi tưӧng khác thì cҧ hai đӕi tưӧng này nhұn thҩy nhau.
Mӝt mӕi liên hӋ biӇu thӏ bҵng các đӕi tưӧng cӫa hai lӟp có nӕi kӃt vӟi nhau, ví dө rҵng
"chúng biӃt vӅ nhau", "đưӧc nӕi vӟi nhau", "cӭ mӛi X lҥi có mӝt Y", .... Lӟp và liên hӋ
giӳa các lӟp là nhӳng công cө rҩt mҥnh mӁ cho viӋc mô hình hóa các hӋ thӕng phӭc tҥp,
ví dө như cҩu trúc sҧn phҭm, cҩu trúc văn bҧn và tҩt cҧ các cҩu trúc thông tin khác.

Mӕi liên kӃt đưӧc thӇ hiӋn trong biӇu đӗ UML bҵng mӝt đưӡng thҷng nӕi hai lӟp.

Hình 5.13-Mӝt lӟp Author kӃt hӧp vӟi lӟp Computer

5.1- Vai trò trong liên hӋ:

Mӝt liên hӋ có thӇ có các vai trò (Roles). Các vai trò đưӧc nӕi vӟi mӛi lӟp bao chӭa trong
quan hӋ. Vai trò cӫa mӝt lӟp là chӭc năng mà nó đҧm nhұn nhìn tӯ góc nhìn cӫa lӟp kia.
Tên vai trò đưӧc viӃt kèm vӟi mӝt mũi tên chӍ tӯ hưӟng lӟp chӫ nhân ra, thӇ hiӋn lӟp này
đóng vai trò như thӃ nào đӕi vӟi lӟp mà mũi tên chӍ đӃn.
 Hình 5.1- Vai trò trong liên hӋ giӳa Customer và Account

Trong ví dө trên: mӝt khách hàng có thӇ là chӫ nhân cӫa mӝt tài khoҧn và tài khoҧn đưӧc
chiӃm giӳ bӣi khách hàng. Đưӡng thҷng thӇ hiӋn liên hӋ giӳa hai lӟp.

Mӝt sӕ điӇm cҫn chú ý khi đһt tên vai trò :

- Tên vai trò có thӇ bӓ đi nӃu trùng vӟi tên lӟp

- Tên vai trò phҧi là duy nhҩt.

- Tên vai trò phҧi khác vӟi các thuӝc tính cӫa lӟp.

- Tên vai trò phҧi miêu tҧ đưӧc chӭc năng mà lӟp này đҧm nhұn trong quan hӋ,
tӭc cҫn phҧi là các khái niӋm lҩy ra tӯ phҥm vi vҩn đӅ, giӕng như tên các lӟp.

5.2- Liên hӋ mӝt chiӅu (Uni-Directional Association):

Ta cũng có thӇ sӱ dөng mӕi liên hӋ mӝt chiӅu bҵng cách thêm mӝt mũi tên và mӝt đҫu
cӫa đưӡng thҷng nӕi kӃt. Mũi tên chӍ ra rҵng sӵ nӕi kӃt chӍ có thӇ đưӧc sӱ dөng duy nhҩt
theo chiӅu cӫa mũi tên.

Hình 5.15- Liên hӋ mӝt chiӅu giӳa Interest và Account

BiӇu đӗ phҫn 5.15 thӇ hiӋn rҵng giӳa hai lӟp có liên hӋ, nhưng không hӅ có thông tin vӅ
sӕ lưӧng các đӕi tưӧng trong quan hӋ. Ta không thӇ biӃt mӝt khách hàng có thӇ có bao
nhiêu tài khoҧn và mӝt tài khoҧn có thӇ là cӫa chung cho bao nhiêu khách hàng. Trong
UML, loҥi thông tin như thӃ đưӧc gӑi là sӕ lưӧng phҫn tӱ (Cardinality) trong quan hӋ.

5.3- Sӕ lưӧng (Cardinality) trong liên hӋ:

 Hình 5.16- Sӕ lưӧng trong liên hӋ giӳa Customer và Account

BiӇu đӗ trên nói rõ mӝt khách hàng có thӇ mӣ mӝt hoһc nhiӅu tài khoҧn và mӝt tài khoҧn
có thӇ thuӝc vӅ mӝt cho tӟi ba khách hàng.

Sӕ lưӧng đưӧc ghi ӣ phía đҫu đưӡng thҷng thӇ hiӋn liên hӋ, sát vào lӟp là miӅn áp dөng
cӫa nó. Phҥm vi cӫa sӕ lưӧng phҫn tӱ trong liên hӋ có thӇ tӯ 0-tӟi-1 (0..1), 0-tӟi-nhiӅu
(0..* hay ), mӝt-tӟi-nhiӅu (1..), hai (2), năm-tӟi-mưӡi mӝt (5..11). Cũng có thӇ miêu tҧ
mӝt dãy sӕ ví dө (1,4,6, 8..12). Giá trӏ mһc đӏnh là 1.

Hình 5.17- Mӝt sơ đӗ lӟp tiêu biӇu

Hình trên là ví dө cho mӝt biӇu đӗ lӟp tiêu biӇu. BiӇu đӗ giҧi thích rҵng bӝ phұn dӏch vө
tài khoҧn tiӃt kiӋm cӫa mӝt nhà băng có thӇ có nhiӅu tài khoҧn tiӃt kiӋm nhưng tҩt cҧ
nhӳng tài khoҧn này đӅu thuӝc vӅ bӝ phұn đó. Mӝt tài khoҧn tiӃt kiӋm vӅ phҫn nó lҥi có
thӇ có nhiӅu tài liӋu, nhưng nhӳng tài liӋu này chӍ thuӝc vӅ mӝt tài khoҧn tiӃt kiӋm mà
thôi. Mӝt tài khoҧn tiӃt kiӋm có thӇ thuӝc vӅ tӯ 1 cho tӟi nhiӅu nhҩt là 3 khách hàng. Mӛi
khách hàng có thӇ có nhiӅu hơn mӝt tài khoҧn.

5.- Phát hiӋn liên hӋ:

Thưӡng sӁ có nhiӅu mӕi liên hӋ giӳa các đӕi tưӧng trong mӝt hӋ thӕng. QuyӃt đӏnh liên
hӋ nào cҫn phҧi đưӧc thӵc thi là công viӋc thөôc giai đoҥn thiӃt kӃ. Có thӇ tìm các mӕi
liên hӋ qua viӋc nghiên cӭu các lӡi phát biӇu vҩn đӅ, các yêu cҫu. Giӕng như danh tӯ đã
giúp chúng ta tìm lӟp, các đӝng tӯ ӣ đây sӁ giúp ta tìm ra các mӕi quan hӋ.

Mӝt vài lӡi mách bҧo khi tìm liên hӋ :

- Vӏ trí vӅ mһt vұt lý hoһc sӵ thay thӃ, đҥi diӋn: Mӛi cөm đӝng tӯ xác đӏnh hay
biӇu lӝ mӝt vӏ trí đӅu là mӝt biӇu hiӋn chҳc chҳn cho liên hӋ. Ví dө: tҥi đӏa điӇm, ngӗi
trong, «

- Sӵ bao chӭa: Cөm đӝng tӯ biӇu lӝ sӵ bao chӭa, ví dө như : là thành phҫn cӫa....

- Giao tiӃp: Có nhiӅu cөm đӝng tӯ biӇu lӝ sӵ giao tiӃp, ví dө truyӅn thông điӋp,
nói chuyӋn vӟi, «

- QuyӅn sӣ hӳu: Ví dө : thuӝc vӅ, cӫa, «

- Thoҧ mãn mӝt điӅu kiӋn: Nhӳng cөm tӯ như : làm viӋc cho, là chӗng/vӧ cӫa,
quҧn trӏ, «.

5.5- Xӱ lý các liên hӋ không cҫn thiӃt:

Sau khi tìm các mӕi liên hӋ, bưӟc tiӃp theo đó là phân biӋc các liên hӋ cҫn thiӃt ra khӓi
các liên hӋ không cҫn thiӃt. Liên hӋ không cҫn thiӃt có thӇ bao gӗm nhӳng liên hӋ bao
chӭa các lӟp ӭng cӱ viên đã bӏ loҥi trӯ hoһc các liên hӋ không liên quan đӃn hӋ thӕng. Có
nhӳng liên hӋ đưӧc tҥo ra nhҵm mөc đích tăng hiӋu quҧ. Nhӳng liên hӋ như thӃ là ví dө
tiêu tiӇu cӫa các chi tiӃt thӵc thi và không liên quan tӟi giai đoҥn này.

Cҫn chú ý phân biӋt giӳa hành đӝng và mӕi liên hӋ. Ngưӡi ta thưӡng có xu hưӟng miêu
tҧ hành đӝng như là liên hӋ, bӣi cҧ liên hӋ lүn hành đӝng đӅu đưӧc dүn xuҩt tӯ nhӳng
cөm tӯ mang tính đӝng tӯ trong bҧn miêu tҧ yêu cҫu. Các hành đӝng đã đưӧc thӇ hiӋn sai
thành liên hӋ cũng cҫn phҧi đưӧc loҥi bӓ. Khi làm viӋc này, có thӇ áp dөng mӝt nguyên
tҳc: liên hӋ là nӕi kӃt mang tính tĩnh giӳa các đӕi tưӧng, trong khi hành đӝng chӍ là thao
tác xҧy ra mӝt lҫn. Hành đӝng vì vұy nên đưӧc coi là Phương thӭc đӕi vӟi mӝt đӕi tưӧng
chӭ không phҧi quan hӋ giӳa các lӟp.

Ví dө vӟi "Ban quҧn trӏ nhà băng đuәi viӋc mӝt nhân viên", đӝng tӯ ³đuәi viӋc´ thӇ hiӋn
hành đӝng. Trong khi đó vӟi ³Mӝt nhân viên làm viӋc cho hãng" thì đӝng tӯ ³làm viӋc"
miêu tҧ liên hӋ giӳa hai lӟp nhân viên và hãng.

Trong khi cӕ gҳng loҥi bӓ các liên hӋ dư thӯa, bҥn sӁ thҩy có mӝt sӕ liên hӋ dư thӯa đã
"lҿn vào" mô hình cӫa chúng ta trong giai đoҥn thiӃt kӃ. Hình sau chӍ ra mӝt sӕ loҥi liên
hӋ dư thӯa cҫn đһc biӋt chú trӑng.
 Hình 5.18- Loҥi bӓ các liên hӋ không cҫn thiӃt

5.6- Nâng cҩp các mӕi liên hӋ:

Mӝt khi các mӕi liên hӋ cҫn thiӃt đã đưӧc nhұn dҥng, bưӟc tiӃp theo là ngiên cӭu kӻ mô
hình và nâng cҩp các mӕi liên hӋ đó.

Đӝng tác nâng cҩp đҫu tiên là xem xét lҥi tên liên hӋ, tên vai trò, đһt lҥi cho đúng vӟi bҧn
chҩt quan hӋ mà chúng thӇ hiӋn. Mӛi liên hӋ cҫn phҧi đưӧc suy xét kӻ vӅ phương diӋn sӕ
lưӧng thành phҫn tham gia (Cardinality). Sӵ hҥn đӏnh (Qualification) cho liên hӋ đóng
mӝt vai trò quan trӑng ӣ đây, bә sung yӃu tӕ hҥn đӏnh có thӇ giúp làm giҧm sӕ lưӧng.
NӃu cҫn thiӃt, hãy bә sung các liên hӋ còn thiӃu. Nghiên cӭu kӻ các thuӝc tính, xem liӋu
trong sӕ chúng có thuӝc tính nào thұt ra thӇ hiӋn liên hӋ. NӃu có, hãy chuyӇn chúng thành
liên hӋ. Bә sung các thông tin và điӅu kiӋn cҫn thiӃt cũng như xem xét các mӕi liên hӋ
trong mô hình tәng thӇ đӇ xác đӏnh các dҥng quan hӋ giӳa chúng vӟi nhau.

5.6.1- Liên hӋ và yӃu tӕ hҥn đӏnh (Qualifier):

Mӝt liên hӋ đưӧc hҥn đӏnh liên hӋ hai lӟp và mӝt yӃu tӕ hҥn đӏnh (Qualifier) vӟi nhau.
YӃu tӕ hҥn đӏnh là mӝt thuӝc tính hҥn chӃ sӕ lưӧng thành phҫn tham gia trong mӝt mӕi
liên hӋ. Có thӇ hҥn đӏnh các mӕi liên hӋ mӝt-tӟi nhiӅu và nhiӅu-tӟi-nhiӅu. YӃu tӕ hҥn
đӏnh giúp phân biӋt trong nhóm đӕi tưӧng cӫa đҫu nhiӅu cӫa liên hӋ.

Ví dө mӝt thӵ mөc có nhiӅu tұp tin.Mӝt tұp tin chӍ thuӝc vӅ mӝt thư mөc mà thôi. Trong
mӝt thư mөc xác đӏnh, tên cӫa tұp tin sӁ xác đӏnh duy nhҩt tұp tin mang tên đó. Thư mөc
và Tұp tin là hai lӟp, và tên tұptin ӣ đây đóng vai trò yӃu tӕ hҥn đӏnh. Mӝt thư mөc và
mӝt tên tұp tin xác đӏnh mӝt tұp tin. YӃu tӕ hҥn đӏnh ӣ đây đã chuyӇn mӝt mӕi liên hӋ
mӝt-tӟi-nhiӅu thành liên hӋ mӝt-tӟi-mӝt.
 Hình 5.19- Liên hӋ đưӧc hҥn đӏnh

5.6.2- Liên hӋ VÀ (AND Association)

Nhà băng nӑ đưa ra quy đӏnh: khách hàng khi muӕn mӣ mӝt tài khoҧn ATM phҧi là chӫ
nhân cӫa ít nhҩt mӝt tài khoҧn đҫu tư. Trong mӝt trưӡng hӧp như thӃ, mӕi liên hӋ VÀ
(AND) sӁ đưӧc thӇ hiӋn như sau:

Hình 5.20- Liên hӋ VÀ (AND Association)

BiӇu đӗ trên cho thҩy mӝt khách hàng có thӇ có nhiӅu hơn mӝt tài khoҧn đҫu tư có thӡi
hҥn và chӍ mӝt tài khoҧn ATM. Trong biӇu đӗ có mӝt mӕi liên hӋ VÀ ngҫm đưӧc áp
dөng giӳa nhóm tài khoҧn đҫu tư và tài khoҧn ATM mà mӝt khách hàng có thӇ có.

5.6.3- Liên hӋ HOҺC (OR Association)

Ví dө tҥi mӝt hãng bҧo hiӇm nӑ, cá nhân cũng công ty đӅu có thӇ ký hӧp đӗng bҧo hiӇm,
nhưng cá nhân và công ty không đưӧc phép có E 1 hӧp đӗng bҧo hiӇm như nhau.
Trong mӝt trưӡng hӧp như thӃ, giҧi pháp là sӱ dөng liên hӋ HOҺC (OR Association).
Mӝt liên hӋ HOҺC là mӝt sӵ hҥn chӃ đӕi vӟi mӝt nhóm hai hay nhiӅu liên hӋ, xác đӏnh
rҵng đӕi tưӧng cӫa mӝt lӟp này tҥi mӝt thӡi điӇm chӍ có thӇ tham gia vào nhiӅu nhҩt mӝt
trong các mӕi liên hӋ đó.
 Hình 5.21- Mӝt liên hӋ OR mà biӇu thӏ chӍ mӝt liên hӋ là hӧp lӋ tҥi mӛi thӡi điӇm

5.6.- Liên hӋ đưӧc sҳp xӃp (Ordered Association)

Các mӕi nӕi kӃt (link) giӳa các đӕi tưӧng có mӝt trұt tӵ ngҫm đӏnh. Giá trӏ mһc đӏnh cӫa
trұt tӵ này là ngүu nhiên. Mӝt liên hӋ có trұt tӵ rõ ràng có thӇ đưӧc hiӇu là mӝt liên hӋ vӟi
trұt tӵ sҳp xӃp (sort order) trong nhóm các nӕi kӃt, nó sӁ đưӧc thӇ hiӋn như sau:

Hình 5.22- Tài khoҧn tiӃt kiӋm đưӧc sҳp xӃp theo khách hàng

Nhãn {ordered} đưӧc ghi gҫn lӟp có đӕi tưӧng đưӧc sҳp xӃp. BiӇu đӗ trên đưӧc đӑc là
các tài khoҧn tiӃt kiӋm đưӧc sҳp xӃp theo khách hàng.

5.6.5- Liên hӋ tam nguyên (Ternary Association)

Có thӇ có nhiӅu hơn hai lӟp nӕi kӃt vӟi nhau trong mӝt liên hӋ tam nguyên.
 Hình 5.23- Liên hӋ Tam nguyên

BiӇu đӗ trên đưӧc đӑc như sau: Mӝt khách hàng có thӇ quan hӋ vӟi bӝ phұn đҫu tư và
mӝt bӝ phұn đҫu tư có thӇ có mӝt hoһc nhiӅu khách hàng. Mӝt giҩy chӭng nhұn tài khoҧn
đҫu tư sӁ xuҩt hiӋn qua quan hӋ giӳa khách hàng và bӝ phұn đҫu tư.

5.6.6- Lӟp liên hӋ (Association Class)

Mӝt lӟp có thӇ đưӧc đính kèm theo mӝt liên hӋ, trong trưӡng hӧp này nó sӁ đưӧc gӑi là
mӝt lӟp liên hӋ. Mӝt lӟp liên hӋ không đưӧc nӕi tӟi bҩt kǤ mӝt lӟp nào cӫa mӕi liên hӋ,
mà tӟi chính bҧn thân mӕi liên hӋ. Cũng giӕng như mӝt lӟp bình thưӡng, lӟp liên hӋ có
thӇ có thuӝc tính, Phương thӭc và các quan hӋ khác. Lӟp liên hӋ đưӧc sӱ dөng đӇ bә sung
thêm thông tin cho nӕi kӃt (link), ví dө như thӡi điӇm nӕi kӃt đưӧc thiӃt lұp. Mӛi nӕi kӃt
cӫa liên hӋ gҳn liӅn vӟi mӝt đӕi tưӧng cӫa lӟp liên hӋ.

Ví dө sau miêu tҧ mӝt hӋ thӕng thang máy. Bӝ phұn điӅu khiӇn chӍ huy bӕn thang máy.
Cho mӛi nӕi kӃt giӳa nhóm thang máy và bӝ phұn điӅu khiӇn có mӝt hàng xӃp (queue).
Mӛi hàng lưu trӳ nhӳng yӅu cҫu kӇ cҧ tӯ phía bӝ phұn điӅu khiӇn lүn tӯ phía thang máy
(nhӳng nút bҩm bên trong thang). Khi bӝ phұn điӅu khiӇn chӑn mӝt thang máy đӇ thӵc
hiӋn mӝt lӡi yêu cҫu đӃn tӯ mӝt hành khách đӭng ngoài thang máy (mӝt hành khách trên
hành lang), nó sӁ đӑc các hàng và chӑn thang máy nào có hàng yêu cҫu ngҳn nhҩt.
 Hình 5.2- Lӟp liên hӋ (Association class)

5.6.7- Liên hӋ đӋ quy (Recursive Association)

Có thӇ liên kӃt mӝt lӟp vӟi bҧn thân nó trong mӝt mӕi liên hӋ. Mӕi liên hӋ ӣ đây vүn thӇ
hiӋn mӝt sӵ liên quan ngӳ nghĩa, nhưng các đӕi tưӧng đưӧc nӕi kӃt đӅu thuӝc chung mӝt
lӟp. Mӝt liên hӋ cӫa mӝt lӟp vӟi chính bҧn thân nó đưӧc gӑi là mӝt liên hӋ đӋ quy, và là
nӅn tҧng cho rҩt nhiӅu mô hình phӭc tҥp, sӱ dөng ví dө đӇ miêu tҧ các cҩu trúc sҧn phҭm.
Hình 5.25 chӍ ra mӝt ví dө cӫa liên hӋ đӋ quy và hình 5.26 là mӝt biӇu đӗ đӕi tưӧng cho
biӇu đӗ lӟp trong hình 5.25.

Hình 5.25- Mӝt mҥng gӗm nhiӅu nút nӕi vӟi nhau.
 Hình 5.26- Mӝt biӇu đӗ đӕi tưӧng cӫa hình 5.25, vӟi tên cӫa các đӕi tưӧng.

6- QUAN Hӊ KӂT TҰP (AGGREGATION)

6.1- Khái niӋm kӃt tұp:

KӃt tұp là mӝt trưӡng hӧp đһc biӋt cӫa liên hӋ. KӃt tұp biӇu thӏ rҵng quan hӋ giӳa các lӟp
dӵa trên nӅn tҧng cӫa nguyên tҳc "mӝt tәng thӇ đưӧc tҥo thành bӣi các bӝ phұn". Nó
đưӧc sӱ dөng khi chúng ta muӕn tҥo nên mӝt thӵc thӇ mӟi bҵng cách tұp hӧp các thӵc
thӇ tӗn tҥi vӟi nhau. Mӝt ví dө tiêu biӇu cӫa kӃt tұp là chiӃc xe ô tô gӗm có bӕn bánh xe,
mӝt đӝng cơ, mӝt khung gҫm, mӝt hӝp sӕ, v.v....

Quá trình ghép các bӝ phұn lҥi vӟi nhau đӇ tҥo nên thӵc thӇ cҫn thiӃt đưӧc gӑi là sӵ kӃt
tұp. Trong quá trình tìm lӟp, kӃt tұp sӁ đưӧc chú ý tӟi khi gһp các loҥi đӝng tӯ ³đưӧc tҥo
bӣi", "gӗm có", «. Quan hӋ kӃt tұp không có tên riêng. Tên ngҫm chӭa trong nó là "bao
gӗm các thành phҫn".

6.2- Kí hiӋu kӃt tұp:

Kí hiӋu UML cho kӃt tұp là đưӡng thҷng vӟi hình thoi (diamond) đһt sát lӟp biӇu thӏ sӵ
kӃt tұp (tәng thӇ).

Mӝt lӟp tài khoҧn đưӧc tҥo bӣi các lӟp chi tiӃt vӅ khách hàng, các lӋnh giao dӏch đӕi vӟi
tài khoҧn cũng như các quy đӏnh cӫa nhà băng.

Quan hӋ trên có thӇ đưӧc trình bày như sau:

 Hình 6.1- Quan hӋ kӃt tұp (1)

Mӛi thành phҫn tҥo nên kӃt tұp (tәng thӇ) đưӧc gӑi là mӝt bӝ phұn (aggregates). Mӛi bӝ
phұn vӅ phҫn nó lҥi có thӇ đưӧc tҥo bӣi các bӝ phұn khác.

Hình 6.2- Quan hӋ kӃt tұp (2)

Trong trưӡng hӧp tài khoҧn kӇ trên, mӝt trong các bӝ phұn cӫa nó là các chi tiӃt vӅ khách
hàng. Các chi tiӃt vӅ khách hàng lҥi bao gӗm danh sách chӫ tài khoҧn, danh sách đӏa chӍ,
các quy đӏnh vӅ kǤ hҥn cũng như các chi tiӃt khác khi mӣ tài khoҧn.

6.3- KӃt tұp và liên hӋ:

Khái niӋm kӃt tұp nҧy sinh trong tình huӕng mӝt thӵc thӇ bao gӗm nhiӅu thành phҫn khác
nhau. Liên hӋ giӳa các lӟp mһt khác là mӕi quan hӋ giӳa các thӵc thӇ.

Quan sát hình sau:

 Hình 6.3- KӃt tұp và liên hӋ

Mӝt tài khoҧn đưӧc tҥo bӣi các chi tiӃt vӅ khách hàng, các lӋnh giao dӏch đӕi vӟi tài
khoҧn cũng như các quy đӏnh cӫa nhà băng. Khách hàng không phҧi là là bӝ phұn cӫa tài
khoҧn, nhưng có quan hӋ vӟi tài khoҧn.

Nhìn chung, nӃu các lӟp đưӧc nӕi kӃt vӟi nhau mӝt cách chһt chӁ qua quan hӋ "toàn thӇ ±
bӝ phұn" thì ngưӡi ta có thӇ coi quan hӋ là kӃt tұp. Không có lӡi hưӟng dүn chҳc chҳn và
rõ ràng cho viӋc bao giӡ nên dùng kӃt tұp và bao giӡ nên dùng liên hӋ. Mӝt lӕi tiӋm cұn
nhҩt quán đi kèm vӟi nhӳng kiӃn thӭc sâu sҳc vӅ phҥm vi vҩn đӅ sӁ giúp nhà phân tích
chӑn giҧi pháp đúng đҳn.

7- KHÁI QUÁT HÓA VÀ CHUYÊN BIӊT HÓA (GENERALIZATION

& SPECIALIZATION)

Hãy quan sát cҩu trúc lӟp trong biӇu đӗ sau:

 Hình 7.1- Chuyên biӋt hoá (Specialization)

Trong hình trên, tài khoҧn là khái niӋm chung cӫa các loҥi tài khoҧn khác nhau và chӭa
nhӳng đһc tҧ cҫn thiӃt cho tҩt cҧ các loҥi tài khoҧn. Ví dө như nó có thӇ chӭa sӕ tài khoҧn
và tên chӫ tài khoҧn. Ta có thӇ có hai loҥi tài khoҧn đһc biӋt suy ra tӯ dҥng tài khoҧn
chung này, mӝt loҥi mang tính kǤ hҥn và mӝt loҥi mang tính giao dӏch. YӃu tӕ chia cách
hai lӟp này vӟi nhau là các quy đӏnh chuyên ngành hay đúng hơn là phương thӭc hoҥt
đӝng cӫa hai loҥi tài khoҧn.

Tương tӵ như vұy, tài khoҧn đҫu tư trung hҥn và dài hҥn lҥi là nhӳng khái niӋm chuyên
biӋt cӫa khái niӋm tài khoҧn có kǤ hҥn. Mһt khác, tài khoҧn bình thưӡng và tài khoҧn tiӃt
kiӋm là nhӳng trưӡng hӧp đһc biӋt cӫa loҥi tài khoҧn giao dӏch.

Loҥi cҩu trúc lӟp như thӃ đưӧc gӑi là mӝt cҩu trúc hình cây hoһc cҩu trúc phân cҩp. Khi
chúng ta dӏch chuyӇn tӯ điӇm xuҩt phát cӫa cây xuӕng dưӟi, chúng ta sӁ gһp các khái
niӋm càng ngày càng đưӧc chuyên biӋt hóa nhiӅu hơn. Theo con đưӡng đi tӯ tài khoҧn
đӃn tài khoҧn tiӃt kiӋm, ta sӁ phҧi đi qua lӟp tài khoҧn giao dӏch. Lӟp này tiӃp tөc phân
loҥi các lӟp chuyên biӋt hóa cao hơn, tùy thuӝc vào chӭc năng cӫa chúng.

7.1- Kí hiӋu khái quát hóa và chuyên biӋt hóa

Trong biӇu đӗ trên, các lӟp trong mӝt cҩu trúc cây đưӧc nӕi vӟi nhau bҵng mӝt mũi tên
rӛng , chӍ tӯ lӟp chuyên biӋt hơn tӟi lӟp khái quát hơn.

Hình 7.2- Khái quát hóa

Quá trình bҳt đҫu vӟi mӝt lӟp khái quát đӇ sҧn xuҩt ra các lӟp mang tính chuyên biӋt cao
hơn đưӧc gӑi là quá trình chuyên biӋt hoá (Specialization)

Chuyên biӋt hóa: là quá trình tinh chӃ mӝt lӟp thành nhӳng lӟp chuyên biӋt hơn.
Chuyên biӋt hóa bә sung thêm chi tiӃt và đһc tҧ cho lӟp kӃt quҧ. Lӟp mang tính khái quát
đưӧc gӑi là lӟp cha (superclass), kӃt quҧ chuyên biӋt hóa là viӋc tҥo ra các lӟp con
(Subclass).

Mһt khác, nӃu chúng ta đi dӑc cҩu trúc cây tӯ dưӟi lên, ta sӁ gһp các lӟp ngày càng mang
tính khái quát cao hơn - Ví dө tӯ lӟp tài khoҧn tiӃt kiӋm lên tӟi lӟp tài khoҧn. Con đưӡng
bҳt đҫu tӯ mӝt lӟp chuyên biӋt và khiӃn nó ngày càng mang tính khái quát cao hơn đưӧc
gӑi là quá trình khái quát hóa (Generalization). Lӟp chuyên biӋt ӣ đây đưӧc gӑi là lӟp
con, trong ví dө trên là tài khoҧn tiӃt kiӋm, trong khi lӟp khái quát kӃt quҧ đưӧc gӑi là lӟp
cha.

Chuyên biӋt hóa và khái quát hóa là hai con đưӡng khác nhau đӇ xem xét cùng mӝt mӕi
quan hӋ.

Mӝt lӟp là lӟp con cӫa mӝt lӟp này có thӇ đóng vài trò là mӝt lӟp cha cӫa lӟp khác.

7.2- YӃu tӕ phân biӋt (Discriminatior)

ĐӇ tҥo mӝt cҩu trúc phân cҩp, cҫn phҧi có mӝt sӕ thuӝc tính làm nӅn tҧng cho quá trình
chuyên biӋt hóa. Thuӝc tính đó đưӧc gӑi là yӃu tӕ phân biӋt (Discriminator).

Vӟi mӛi giá trӏ có thӇ gán cho yӃu tӕ phân biӋt trong lӟp cha, ta sӁ có mӝt lӟp con tương
ӭng.

Hình 7.3- YӃu tӕ phân biӋt (Discriminatior)

Trong hình trên, yӃu tӕ phân biӋt trong lӟp tài khoҧn là "loҥi tài khoҧn". Chúng ta giҧ
thiӃt rҵng chӍ có hai loҥi tài khoҧn, mӝt mang tính kǤ hҥn và mӝt mang tính giao dӏch.
Theo đó, ta phҧi tҥo ra hai lӟp con, mӝt cho các tài khoҧn mang tính kǤ hҥn và mӝt cho
các tài khoҧn mang tính giao dӏch.

Trong mô hình đӕi tưӧng, không nhҩt thiӃt phҧi nêu bұt yӃu tӕ phân biӋt. YӃu tӕ phân
biӋt luôn có mһt trong mӝt cҩu trúc phân cҩp lӟp cha/ con, dù có đưӧc nhҩn mҥnh trong
mô hình đӕi tưӧng hay không. Mһc dҫu vұy, đӇ đҧm bҧo cho mӝt mô hình đưӧc đӏnh
nghĩa rõ ràng, trình bày yӃu tӕ phân biӋt vүn luôn là công viӋc nên thӵc hiӋn.

7.2.1- Lӟp trӯu tưӧng

Quan sát cҩu trúc trong hình trên, ta thҩy lӟp tài khoҧn sӁ không bao giӡ đưӧc thӵc thӇ
hóa, có nghĩa là hӋ thӕng sӁ không bao giӡ tҥo ra các đӕi tưӧng thuӝc lӟp này. Nguyên
nhân là vì lӟp tài khoҧn mang tính khái quát cao đӃn mӭc đӝ viӋc khӣi tҥo lӟp này sӁ
không có mӝt ý nghĩa nào đáng kӇ. Lӟp tài khoҧn mһc dù vұy vүn đóng mӝt vai trò quan
trӑng trong viӋc khái quát hóa các thuӝc tính sӁ đưӧc cҫn đӃn trong các lӟp dүn xuҩt tӯ
nó. Nhӳng loҥi lӟp như thӃ đưӧc dùng đӇ cung cҩp mӝt cây cҩu trúc lӟp và không có sӵ
tӗn tҥi đҫy đӫ ý nghĩa trong mӝt mô hình thұt sӵ ngoài đӡi, chúng đưӧc gӑi là lӟp trӯu
trưӧng (abstract class).

7.2.2- Tҥo lӟp trӯu tưӧng

Các lӟp trӯu trưӧng là kӃt quҧ cӫa quá trình khái quát hóa. Hãy quan sát ví dө cҩu trúc
lӟp sau đây. Lӟp tài khoҧn đӭng đҫu cây cҩu trúc và đưӧc gӑi là lӟp căn bҧn. Lӟp căn
bҧn cӫa mӝt cây cҩu trúc chӭa nhӳng thuӝc tính đã đưӧc khái quát hóa và có thӇ đưӧc áp
dөng cho mӑi lӟp dүn xuҩt tӯ nó. Trong quá trình khái quát hóa, các thuӝc tính đưӧc
dùng chung trong các lӟp chuyên biӋt đưӧc đưa lên lӟp cha. Lӟp cha vӅ cuӕi đưӧc tҥo bӣi
các thuӝc tính chung cӫa tҩt cҧ các lӟp dүn xuҩt tӯ nó. Nhӳng lӟp cha dҥng như vұy trong
rҩt nhiӅu trưӡng hӧp sӁ mang tính khái quát tuyӋt đӕi và sӁ không theo đuәi mөc đích
khӣi tҥo, chúng có lӕi ӭng xӱ giӕng như mӝt thùng chӭa (container) cho tҩt cҧ các thuӝc
tính chung cӫa các lӟp dүn xuҩt. Nhӳng lӟp như thӃ trong trưӡng hӧp chung thưӡng là
kӃt quҧ ánh xҥ cӫa nhӳng danh tӯ trӯu tưӧng, là hӋ quҧ cӫa phương pháp sӱ dөng các
danh tӯ đӇ nhұn diӋn lӟp .

Hình 7.- Tҥo lӟp trӯu tưӧng

BiӇu đӗ trên cho ta mӝt ví dө vӅ khái quát hóa và các thuӝc tính chung, nó chӍ ra nhiӅu
lӟp chuyên biӋt. Chú ý rҵng cӭ theo mӛi mӭc chuyên biӋt hóa lҥi có thêm các thuӝc tính
đưӧc bә sung thêm cho các lӟp, khiӃn chúng mang tính chuyên biӋt cao hơn so vӟi các
lӟp cha ӣ mӭc trӯu tưӧng bên trên. Ví dө lӟp tài khoҧn có thuӝc tính là sӕ tài khoҧn và
tên khách hàng. Đây là nhӳng thuӝc tính hӃt sӭc chung chung. Tҩt cҧ các lӟp dүn xuҩt tӯ
nó, dù là trӵc tiӃp hay gián tiӃp (ӣ các mӭc đӝ trӯu tưӧng thҩp hơn nӳa), đӅu có quyӅn sӱ
dөng các thuӝc tính đó cӫa lӟp tài khoҧn. Các lӟp tài khoҧn có kǤ hҥn và tài khoҧn giao
dӏch là hai lӟp chuyên biӋt dүn xuҩt tӯ lӟp tài khoҧn. Chúng có nhӳng thuӝc tính chuyên
biӋt riêng cӫa chúng - ví dө mӭc thӡi gian (duration) đӕi vӟi lӟp tài khoҧn có kǤ hҥn và
mӭc tiӅn tӕi thiӇu đӕi vӟi lӟp tài khoҧn giao dӏch ± bên cҥnh hai thuӝc tính sӕ tài khoҧn
và tên khách hàng mà chúng thӯa kӃ tӯ lӟp tài khoҧn. Cũng tương tӵ như thӃ vӟi tài
khoҧn đҫu tư ngҳn hҥn và tài khoҧn đҫu tư trung hҥn là các loҥi lӟp thuӝc tài khoҧn có kǤ
hҥn, tài khoҧn tiӃt kiӋm và tài khoҧn bình thưӡng là các loҥi lӟp thuӝc lӟp tài khoҧn giao
dӏch.

7.2.3- Lӟp cө thӇ (concrete class)

Lӟp cө thӇ là nhӳng lӟp có thӇ thӵc thӇ hóa. Như đã nói tӯ trưӟc, các lӟp cө thӇ khi thӵc
thӇ hóa đưӧc gӑi là các đӕi tưӧng. Trong ví dө trên, các lӟp tài khoҧn đҫu tư ngҳn hҥn và
tài khoҧn đҫu tư dài hҥn có thӇ đưӧc thӵc thӇ hóa thành đӕi tưӧng. Tương tӵ đӕi vӟi tài
khoҧn tiӃt kiӋm và tài khoҧn bình thưӡng.

7.2.- Tәng kӃt vӅ phát triӇn cây cҩu trúc

Cơ chӃ dùng chung thuӝc tính và thӫ tөc sӱ dөng nguyên tҳc khái quát hóa đưӧc gӑi là
tính thӯa kӃ (inheritance). Sӱ dөng tính thӯa kӃ đӇ tinh chӃ (refine) các lӟp sӁ dүn tӟi
viӋc phát triӇn mӝt cây cҩu trúc. Nên phát hiӋn nhӳng ӭng xӱ (behaviour) chung trong
mӝt loҥt lӟp rӗi thӇ hiӋn nó thành mӝt lӟp cha. Sӵ khác biӋt trong ӭng xӱ cӫa cùng mӝt
lӟp sӁ dүn tӟi viӋc tҥo ra các lӟp con.

Khi phát triӇn cây cҩu trúc, hãy quan sát ӭng xӱ cӫa các lӟp. Trong trưӡng hӧp có mӝt
liên hӋ tӗn tҥi tӯ mӝt lӟp cө thӇ đӃn tҩt cҧ các lӟp con cӫa mӝt lӟp cha, nên dӏch chuyӇn
liên hӋ này lên lӟp cha.

NӃu tӗn tҥi mӝt liên hӋ giӳa mӝt lӟp nào đó và mӝt lӟp cha, hãy chuyên biӋt hóa và nâng
cao cҩu trúc đӇ xác đӏnh xem liӋu liên hӋ này có đưӧc áp dөng cho tҩt cҧ các lӟp con cӫa
lӟp cha nӑ hay không. NӃu có thì gán nó vào lӟp cha, nӃu không thì dӏch xuӕng cho
nhӳng lӟp con phù hӧp.

Trong khi tiӃn hành khái quát hóa, trӑng tâm công viӋc là xác đӏnh các ӭng xӱ chung
trong mӝt nhóm nhiӅu lӟp chuyên biӋt bұc trung. Khi đã xây dӵng đưӧc mӝt thӫ tөc hoһc
mӝt thuӝc tính chung, nên kiӇm tra lҥi xem chúng có thұt sӵ là yӃu tӕ chung cӫa tҩt cҧ
các lӟp chuyên biӋt trong phҥm vi này. Khái quát hóa đưӧc áp dөng chӍ khi chúng ta có
mӝt tұp hӧp các lӟp đӏnh nghĩa mӝt loҥi đӕi tưӧng riêng biӋt và có mӝt sӕ lưӧng lӟn các
ӭng xӱ chung. Trӑng tâm ӣ đây là tҥo nên lӟp cha chӭa các ӭng xӱ chung đó.

Khi chuyên biӋt hóa, ta đi tìm các sӵ khác biӋt trong ӭng xӱ đӇ tҥo các lӟp con thích ӭng.
Có nghĩa là ta xem xét mӝt lӟp tӗn tҥi, kiӇm tra xem có phҧi tҩt cҧ các ӭng xӱ cӫa nó đӅu
có khҧ năng áp dөng cho mӑi đӕi tưӧng. NӃu không, ta lӑc ra ӭng xӱ không phҧi lúc nào
cũng cҫn thiӃt và chia trưӡng hӧp nó ra thành các lӟp con. Trӑng tâm cӫa chuyên biӋt hóa
là tҥo các lӟp con.

Vӟi cơ chӃ thӯa kӃ, mӝt lӟp con sӁ kӃ thӯa mӑi thuӝc tính à thӫ tөc cӫa tҩt cҧ các lӟp cha
cӫa nó.

Hình sau làm rõ viӋc tҥo cҩu trúc lӟp sӱ dөng tính khái quát.

Hình 7.5- Phát triӇn hӋ thӕng lӟp (1)

Thưӡng xҧy ra trưӡng hӧp tҩt cҧ các lӟp con cùng tham gia vào mӝt liên hӋ hoһc kӃt tұp.
Trong trưӡng hӧp này nên tҥo lӟp cha đӏnh nghĩa liên hӋ /kӃt tұp đó. Hình sau giҧi thích
thêm điӇm này:
 Hình 7.6- Phát triӇn hӋ thӕng lӟp (2)

8- QUAN Hӊ PHӨ THUӜC VÀ NÂNG CҨP (DEPENDENCY &

REFINEMENT)
Bên cҥnh liên hӋ và khái quát hóa, UML còn đӏnh nghĩa hai loҥi quan hӋ khác. Quan hӋ
phө thuӝc (Dependency) là mӝt sӵ liên quan ngӳ nghĩa giӳa hai phҫn tӱ mô hình, mӝt
mang tính đӝc lұp và mӝt mang tính phө thuӝc. Mӑi sӵ thay đәi trong phҫn tӱ đӝc lұp sӁ
ҧnh hưӣng đӃn phҫn tӱ phө thuӝc. Phҫn tӱ mô hình ӣ đây có thӇ là mӝt lӟp, mӝt gói
(package), mӝt trưӡng hӧp sӱ dөng, .v.v... Có thӇ nêu mӝt vài cí dө cho sӵ phө thuӝc
như: mӝt lӟp lҩy tham sӕ là đӕi tưӧng cӫa mӝt lӟp khác, mӝt lӟp truy nhұp mӝt đӕi tưӧng
toàn cөc cӫa mӝt lӟp khác, mӝt lӟp gӑi mӝt thӫ tөc thuӝc thuӝc mӝt lӟp khác. Trong tҩt
cҧ các trưӡng hӧp trên đӅu có mӝt sӵ phө thuӝc cӫa mӝt lӟp này vào mӝt lӟp kia, mһc dù
chúng không có liên hӋ rõ ràng vӟi nhau.

Quan hӋ phө thuӝc đưӧc thӇ hiӋn bҵng đưӡng thҷng gҥch rӡi (dashed line) vӟi mũi tên
(và có thӇ thêm mӝt nhãn) giӳa các phҫn tӱ mô hình. NӃu sӱ dөng nhãn thì nó sӁ là mӝt
khuôn mүu (stereotype), xác đӏnh loҥi phө thuӝc. Hình sau chӍ ra mӝt sӵ phө thuӝc dҥng
"friend", có nghĩa rҵng mӝt phҫn tӱ mô hình nhұn đưӧc quyӅn truy cұp đһc biӋt tӟi cҩu
trúc nӝi bӝ cӫa phҫn tӱ thӭ hai (thұm chí tӟi cҧ nhӳng phҫn mang tính nhìn thҩy là
private).

Hình 8.1- Mӝt quan hӋ phө thuӝc giӳa các lӟp

Nâng cҩp (Refinement) là mӝt quan hӋ giӳa hai lӡi miêu tҧ cӫa cùng mӝt sӵ vұt, nhưng
ӣ nhӳng mӭc đӝ trӯu tưӧng hóa khác nhau. Nâng cҩp có thӇ là mӕi quan hӋ giӳa mӝt loҥi
đӕi tưӧng và lӟp thӵc hiӋn nó. Các nâng cҩp thưӡng gһp khác là quan hӋ giӳa mӝt lӟp
phân tích (trong mô hình phân tích) và mӝt lӟp thiӃt kӃ (trong mô hình thiӃt kӃ) đӅu mô
hình hóa cùng mӝt thӭ, quan hӋ giӳa mӝt lӡi miêu tҧ có mӭc trӯu tưӧng hóa cao và mӝt
lӡi miêu tҧ có mӭc trӯu tưӧng hóa thҩp (ví dө mӝt bӭc tranh khái quát cӫa mӝt sӵ cӝng
tác đӝng và mӝt biӇu đӗ chi tiӃt cӫa cũng cӝng tác đó). Quan hӋ nâng cҩp còn đưӧc sӱ
dөng đӇ mô hình hóa nhiӅu mӭc thӵc thi cӫa cùng mӝt thӭ (mӝt thӵc thi đơn giҧn và mӝt
thӵc thi phӭc tҥp hơn, hiӋu quҧ hơn).

Quan hӋ nâng cҩp đưӧc thӇ hiӋn bҵng đưӡng thҷng gҥch rӡi (dashed line) vӟi mũi tên
rӛng.
 Hình 8.2- Quan hӋ nâng cҩp

Quan hӋ nâng cҩp đưӧc sӱ dөng trong viӋc phӕi hӧp mô hình. Trong các dӵ án lӟn, mӑi
mô hình đӅu cҫn phҧi đưӧc phӕi hӧp vӟi nhau. Phӕi hӧp mô hình đưӧc sӱ dөng nhҵm
mөc đích:

- ChӍ ra mӕi liên quan giӳa các mô hình ӣ nhiӅu mӭc đӝ trӯu tưӧng khác nhau.

- ChӍ ra mӕi liên quan giӳa các mô hình ӣ nhiӅu giai đoҥn khác nhau (phân tích
yêu cҫu, phân tích, thiӃt kӃ, thӵc thi, ...) .

- Hӛ trӧ viӋc quҧn trӏ cҩu hình.

- Hӛ trӧ viӋc theo dõi trong mô hình.

9- NÂNG CҨP MÔ HÌNH QUA CÁC VÒNG LҺP Kӂ TIӂP

Cho tӟi thӡi điӇm này, chúng ta đi qua các bưӟc công viӋc phân tích căn bҧn và tҥo nên
phiên bҧn đҫu tiên cӫa mô hình đӕi tưӧng. Mô hình này cҫn phҧi đưӧc lҩy làm mөc tiêu
cho các vòng lһp nâng cҩp tiӃp theo.

Công viӋc nâng cҩp có thӇ đưӧc thӵc hiӋn bҵng cách đưa mô hình qua tҩt cҧ các giai
đoҥn phát triӇn mô hình đӕi tưӧng mӝt lҫn nӳa. Lҫn này, nhӳng kiӃn thӭc thu đưӧc trong
vòng phát triӇn đҫu sӁ tӓ ra rҩt hӳu dөng. Khi nâng cҩp mô hình cҫn chú ý đӃn các bưӟc
sau:

a) Nghiên cӭu các lӟp đӇ tìm các thuӝc tính và thӫ tөc không đӗng dҥng
(dissimilar). NӃu có, xҿ lӟp thành các thành phҫn đӇ tҥo tính đӗng nhҩt (harmony) trong
lӟp . Ví dө vӟi mӝt lӟp đҧm nhұn hai vai trò khác nhau, hãy xҿ lӟp thành các lӟp kӃt quҧ
vӟi nhӳng thӫ tөc đưӧc xác đӏnh rõ ràng.

b) NӃu phát hiӋn thҩy mӝt chӭc năng không hưӟng tӟi mӝt lӟp đích nào thì đó là
triӋu chӭng thiӃu lӟp. Hãy bә sung lӟp thiӃu và đưa thӫ tөc kӇ trên vào lӟp đó.

c) Khái quát hóa là còn chưa đӫ đӝ nӃu có các liên hӋ trùng lһp (nhiӅu liên hӋ
cùng đӏnh nghĩa mӝt quan hӋ). Trong trưӡng hӧp này, cҫn tҥo lӟp cha đӇ kӃt hӧp các mӕi
liên hӋ đó.
 d) NӃu mӝt vai trò mang mӝt ý nghĩa đһc biӋt quan trӑng đӕi vӟi hӋ thӕng thì
thưӡng nó cҫn mӝt lӟp riêng. Mӝt lӵa chӑn khác là biӃn liên hӋ đӏnh nghĩa vai trò này
thành mӝt lӟp liên hӋ.

e) NӃu mӝt lӟp thiӃu cҧ thuӝc tính lүn thӫ tөc và / hoһc liên hӋ thì rҩt có thӇ đây là
mӝt lӟp không cҫn thiӃt. Hãy loҥi bӓ nhӳng lӟp đó nӃu có thӇ.

f) Hãy rà sát toàn bӝ hӋ thӕng đӇ tìm nhӳng vai trò giӳa các lӟp còn chưa đưӧc
thӇ hiӋn. NӃu có, đây là triӋu chӭng thiӃu liên hӋ.

g) NӃu có mӝt liên hӋ giӳa các đӕi tưӧng nhưng lҥi chҷng đưӧc thӫ tөc nào sӱ
dөng tӟi thì rҩt có thӇ đây là mӝt liên hӋ không cҫn thiӃt. Ví dө ta đã xác đӏnh mӝt liên hӋ
giӳa nhân viên thu ngân và khách hàng nhưng lҥi không có thӫ tөc nào đưӧc đӏnh nghĩa
giӳa hai ngưӡi. Trong trưӡng hӧp này, rҩt có thӇ liên hӋ đó là không cҫn thiӃt.

Mӝt sӕ mách bҧo thӵc tӃ:

- Nghiên cӭu đӇ hiӇu thҩu đáo vҩn đӅ cҫn giҧi quyӃt:

Khi xây dӵng mô hình đӕi tưӧng, không nên bҳt đҫu bҵng cách viӃt ra các cҩu trúc lӟp,
các mӕi liên hӋ cũng như nhӳng mӕi quan hӋ thӯa kӃ lӝ rõ trên bӅ mһt và đұp thҷng vào
mҳt chúng ta. Hãy dành thӡi gian nghiên cӭu kӻ bҧn chҩt vҩn đӅ. Mô hình đӕi tưӧng phҧi
đưӧc thiӃt kӃ đӇ phù hӧp vӟi giҧi pháp cho vҩn đӅ mà chúng ta nhҳm tӟi.

- Cҭn thұn khi chӑn tên:

Tên cҫn đưӧc chӑn mӝt cách cҭn thұn bӣi nó chӭng nhұn sӵ tӗn tҥi các thӵc thӇ. Tên cҫn
phҧi chính xác, ngҳn gӑn, tránh gây bàn cãi. Tên phҧi thӇ hiӋn tәng thӇ đӕi tưӧng chӭ
không chӍ nhҳm tӟi mӝt khía cҥnh nào đó cӫa đӕi tưӧng.

Bҩt cӭ nơi nào có thӇ, hãy chӑn nhӳng tên nào bao chӭa các danh tӯ chuyên ngành quen
thuӝc đӕi vӟi ngưӡi sӱ dөng. Nhӳng tên tҥo ra nhӳng hình xa vӡi đӕi vӟi ngưӡi sӱ dөng,
hoһc các thӵc thӇ đưӧc đһt tên mӝt cách tӗi tӋ rҩt dӉ gây ra nhҫm lүn.

- Cҫn giӳ cho mô hình đӕi tưӧng đưӧc đơn giҧn:

Hãy kháng cӵ lҥi xu hưӟng tҥo ra các mô hình phӭc tҥp, chúng chӍ mang lҥi sӵ nhҫm lүn,
bӕi rӕi. Trong vòng đҫu cӫa quy trình mô hình hóa đӕi tưӧng, hãy xác đӏnh các mӕi liên
hӋ căn bҧn và gҥt ra ngoài các chi tiӃt, viӋc xem xét tӟi các sӕ lưӧng thành phҫn tham gia
(Cardinality) trong quan hӋ đưӧc đӇ dành cho giai đoҥn sau; rҩt có thӇ là ӣ vòng thӭ hai.
Tӕt nhҩt là các chi tiӃt phҧn ánh sӕ lưӧng các thành phҫn tham gian trong quan hӋ chӍ
đưӧc bә sung thêm vào trong vòng thӭ hai hoһc vòng thӭ ba cӫa công viӋc mô hình hóa
đӕi tưӧng. Thưӡng thưӡng, ngưӡi ta thҩy nhӳng phiên bҧn đҫu tiên cӫa mô hình thưӡng
chӍ chӭa các mӕi liên hӋ vӟi sӕ lưӧng là tӯ 0-tӟi-0; 0-tӟi-1, 1- tӟi-1; 1-tӟi-nhiӅu.

- Nên sӱ dөng các mӕi liên hӋ hҥn đӏnh bҩt cӭ khi nào có thӇ.
 - Tránh khái quát hóa quá nhiӅu. Thưӡng chӍ nên hҥn chӃ ӣ ba tҫng khái quát.

- Hãy nghiên cӭu thұt kӻ các mӕi liên hӋ 1-tӟi-nhiӅu. Chúng thưӡng có thӇ đưӧc
chuyӇn thành các quan hӋ 1-tӟi-0 hoһc 1-tӟi-1.

- Tҩt cҧ các mô hình cҫn phҧi đưӧc lҩy làm đӕi tưӧng cho viӋc tiӃp tөc nâng cҩp.
NӃu không thӵc hiӋn nhӳng vòng nâng cҩp sau đó, rҩt có thӇ mô hình cӫa chúng ta sӁ
thiӃu hoàn chӍnh.

- Đӝng tác đӇ cho nhӳng ngưӡi khác xem xét lҥi mô hình là rҩt quan trӑng.
Thưӡng sӵ liên quan quá cұn kӅ vӟi mô hình sӁ khiӃn chúng ta mù lòa, không nhұn
nhӳng ra khiӃm khuyӃt cӫa nó. Mӝt cái nhìn vô tư trong trưӡng hӧp này là rҩt cҫn thiӃt.

- Không nên mô hình hóa các mӕi liên hӋ thành thuӝc tính. NӃu điӅu này xҧy ra,
ta thưӡng có thӇ nhұn thҩy qua triӋu chӭng là mô hình thiӃu liên hӋ. Thêm vào đó, đã có
lúc ta bӓ qua sӵ cҫn thiӃt cӫa mӝt yӃu tӕ hҥn đӏnh.

ViӋc viӃt tài liӋu cho mô hình là vô cùng quan trӑng. Các tài liӋu cҫn phҧi nҳm bҳt thҩu
đáo nhӳng nguyên nhân nҵm đҵng sau mô hình và trình bày chúng chính xác như có thӇ.

10- CHҨT LƯӦNG MÔ HÌNH

Làm sao đӇ biӃt đưӧc mô hình là tӕt hay chưa tӕt? Mӝt ngôn ngӳ mô hình hóa có thӇ
cung cҩp ngӳ pháp và ngӳ nghĩa cho ta làm viӋc, nhưng nó không cho ta biӃt liӋu mӝt mô
hình vӯa đưӧc tҥo dӵng nên là tӕt hay không. YӃu tӕ này mӣ ra mӝt vҩn đӅ quan trӑng
trong viӋc xác đӏnh chҩt lưӧng mô hình. ĐiӅu chӫ chӕt khi chúng ta thiӃt kӃ mô hình là
thӭ chúng ta muӕn nói vӅ hiӋn thӵc. Mô hình mang lҥi sӵ diӉn giҧi cho nhӳng gì mà
chúng ta nghiên cӭu (hiӋn thӵc, mӝt viӉn cҧnh...).

Trong mӝt mô hình, yӃu tӕ quan trӑng bұt nhҩt là phҧi nҳm bҳt đưӧc bҧn chҩt cӫa vҩn đӅ.
Trong mӝt hӋ thӕng tài chính, chúng ta thưӡng mô hình hóa các hóa đơn chӭ không phҧi
các món nӧ. Trong đa phҫn doanh nghiӋp, bҧn thân hóa đơn không thұt sӵ có tҫm quan
trӑng đӃn như vұy, yӃu tӕ quan trӑng ӣ đây là các món nӧ. Mӝt hóa đơn chӍ là mӝt sӵ thӇ
hiӋn cӫa mӝt món nӧ, nhưng ta cҫn phҧi mô hình hóa làm sao đӇ phҧn ánh điӅu đó. Mӝt
khái niӋm khác là mӝt tài khoҧn ӣ nhà băng. Trong nhӳng năm 70 và 80 đã có rҩt nhiӅu
mô hình thӇ hiӋn tài khoҧn nhà băng. Khách hàng (chӫ nhân cӫa tài khoҧn tҥi nhà băng)
đưӧc coi là mӝt thành phҫn cӫa tài khoҧn này (mӝt tài khoҧn nhà băng đưӧc mô hình hóa
như là mӝt lӟp hoһc là mӝt thӵc thӇ và mӝt khách hàng là mӝt thuӝc tính). Khó khăn đҫu
tiên xҧy ra là nhà băng không thӇ xӱ lý tài khoҧn có nhiӅu chӫ. Vҩn đӅ thӭ hai là nhà
băng không thӇ tҥo ra các chiӃn lưӧc maketing nhҳm tӟi nhӳng khách hàng không có tài
khoҧn trong nhà băng chӍ bӣi vì hӑ không có đӏa chӍ.

Vì vұy, mӝt trong nhӳng khía cҥnh cӫa chҩt lưӧng mô hình là tính thích hӧp cӫa mô hình
đó. Mӝt mô hình thích hӧp phҧi nҳm bҳt các khía cҥnh quan trӑng cӫa đӕi tưӧng nghiên
cӭu. Nhӳng khía cҥnh khác trong viӋc đánh giá chҩt lưӧng là mô hình phҧi dӉ giao tiӃp,
phҧi có mӝt mөc tiêu cө thӇ, dӉ bҧo quҧn, mang tính vӳng bӅn và có khҧ năng tích hӧp.
NhiӅu mô hình cӫa cùng mӝt hӋ thӕng nhưng có các mөc đích khác nhau (hoһc là hưӟng
nhìn khác nhau) phҧi có khҧ năng tích hӧp đưӧc vӟi nhau.

Dù là sӱ dөng phương pháp nào hoһc ngôn ngӳ mô hình hóa nào, ta vүn còn phҧi đӕi mһt
vӟi các vҩn đӅ khác. Khi tҥo dӵng mô hình, chúng ta trӣ thành mӝt phҫn cӫa doanh
nghӏêp, có nghĩa là chúng ta cҫn phҧi quan sát hiӋu ӭng sӵ can thiӋp cӫa chúng ta vào
doanh nghiӋp. YӃu tӕ quan trӑng là cҫn phҧi xӱ lý tҩt cҧ các khía cҥnh cӫa sӵ can thiӋp
đó ví dө như vӅ chính sách, văn hóa, cҩu trúc xã hӝi và năng suҩt. NӃu không làm đưӧc
điӅu này, rҩt có thӇ ta không có khҧ năng phát hiӋn và nҳm bҳt tҩt cҧ nhӳng đòi hӓi cҫn
thiӃt tӯ phía khách hàng (cҫn chú ý rҵng nhӳng phát biӇu yêu cҫu đưӧc đưa ra không phҧi
bao giӡ cũng chính xác là nhӳng gì khách hàng thӵc sӵ cҫn). Hãy đһc biӋt chú ý đӃn các
vҩn đӅ vӟi chính sách nӝi bӝ, các mүu hình xã hӝi, các cҩu trúc không chính thӭc và các
thӃ lӵc bao quanh khách hàng.

10.1- ThӃ nào là mӝt mô hình tӕt?

Mӝt mô hình sӁ là mӝt mô hình tӕt nӃu ta có khҧ năng giao tiӃp vӟi nó, nӃu nó phù hӧp
vӟi các mөc đích cӫa nó và nӃu chúng ta đã nҳm bҳt đưӧc nhӳng điӇm cӕt yӃu cӫa vҩn
đӅ. Mӝt mô hình tӕt đòi hӓi thӡi gian xây dӵng; bình thưӡng ra nó đưӧc tҥo bӣi mӝt
nhóm phát triӇn, đưӧc thành lұp vӟi mӝt mөc đích cө thӇ. Mӝt trong nhӳng mөc đích này
có thӇ là huy đӝng toàn bӝ lӵc lưӧng đӇ phát hiӋn ra các yêu cҫu cӫa mӝt cơ quan. Mӝt
mөc đích khác rҩt có thӇ là mô hình hóa mӝt đһc tҧ yêu cҫu, thӵc hiӋn mӝt giai đoҥn phân
tích, hay vӁ mӝt bҧn thiӃt kӃ kӻ thuұt cho mӝt hӋ thӕng thông tin. Khi các cá nhân khác
nhau đưӧc tұp hӧp thành nhóm, đӝng tác này cҫn phҧi đưӧc thӵc hiӋn tұp trung vào mөc
tiêu đӏnh trưӟc. Các nhóm đӇ mô hình hóa mӝt doanh nghӏêp hoһc là mӝt hӋ thӕng thông
tin rҩt có thӇ đưӧc tҥo bӣi khách hàng, chuyên gia mô hình hóa và chuyên gia ӭng dөng.

10.2- Ta có thӇ giao tiӃp vӟi mô hình?

Tҥi sao mô hình lҥi phҧi là thӭ dӉ giao tiӃp? Tҩt cҧ các dӵ án, dù lӟn hay nhӓ, đӅu cҫn
phҧi đưӧc giao tiӃp. Con ngưӡi ta nói chuyӋn vӟi nhau. Hӑ đӑc các tài liӋu cӫa nhau và
thҧo luұn các nӝi dung cӫa chúng. Sáng kiӃn khӣi thӫy nҵm đҵng sau bҩt kǤ mӝt mô hình
nào cũng là đӇ tҥo ra khҧ năng giao tiӃp vӟi chúng. NӃu chúng ta tҥo ra các mô hình mà
không ai đӑc nәi, hiӇu nәi, thì đó là viӋc làm vô ý nghĩa. Mô hình chҷng phҧi đưӧc tҥo ra
bӣi ngưӡi dүn đҫu mӝt phương pháp hoһc ngưӡi dүn đҫu mӝt dӵ án ra lӋnh. Mô hình
đưӧc tҥo ra đӇ phөc vө cho viӋc giao tiӃp và tұp hӧp các cӕ gҳng cӫa chúng ta đӇ đҥt đӃn
năng suҩt, hiӋu quҧ và chҩt lưӧng cao như có thӇ.

10.3- Mô hình có phù hӧp vӟi mөc đích cӫa nó không?

Mӝt mô hình hình cҫn phҧi có mӝt mөc đích rõ ràng, sao cho ai dùng nó cũng nhұn đưӧc
ra. Tҩt cҧ các mô hình đӅu có mөc đích, nhưng thưӡng mөc đích này là ngҫm ҭn, và điӅu
này khiӃn cho viӋc sӱ dөng và hiӇu nó trӣ nên khó khăn. Các mô hình phân tích và mô
hình thiӃt kӃ có thӇ là mô hình cӫa cùng mӝt hӋ thӕng, nhưng chúng vүn là nhӳng mô
hình khác nhau và tұp trung vào các chӫ đӅ khác nhau (hay là chi tiӃt khác nhau). Cҫn
phҧi xác đӏnh rõ ràng mөc đích cho mӛi mô hình đӇ có thӇ kiӇm tra và phê duyӋt nó. NӃu
không có mөc đích rõ ràng, chúng ta ví dө rҩt có thӇ sӁ thҭm tra mӝt mô hình hình phân
tích như thӇ nó là mӝt mô hình thiӃt kӃ.

10.- Nҳm bҳt nhӳng điӇm trӑng yӃu

NhiӅu mô hình chӍ bao gӗm các tài liӋu cӫa doanh nghiӋp ± ví dө như các hóa đơn, nhӳng
thông tin nhұn đưӧc, các hӧp đӗng bҧo hiӇm. NӃu mô hình chӍ là sӵ bao gӗm các tài liӋu
thì điӅu gì sӁ xҧy ra nӃu doanh nghiӋp thay đәi? Đây là mӝt vҩn đӅ rҩt quan trӑng trong
thӵc tӃ. Chúng ta cҫn thiӃt phҧi nҳm bҳt bҧn chҩt cӫa doanh nghiӋp (tҥo nên phҫn nhân)
và mô hình xoay quanh các khái niӋm thiӃt yӃu đó đӇ có khҧ năng xӱ lý các thay đәi mӝt
cách thích hӧp. Hãy mô hình hóa phҫn nhân cӫa doanh nghiӋp và sau đó mӟi đӃn mӝt mô
hình diӉn giҧi phҫn nhân đó. Mӝt khi phҫn nhân đã đưӧc mô hình hóa, nhӳng thay đәi
nho nhӓ trong doanh nghiӋp có thӇ đưӧc xӱ lý qua viӋc sӱa đәi các lӟp diӉn giҧi các loҥi
đӕi tưӧng thuӝc phҫn nhân (ví dө như các hóa đơn là mӝt sӵ diӉn giҧi cӫa các món nӧ).

10.5- Phӕi hӧp các mô hình

Các mô hình khác nhau cӫa cùng mӝt hӋ thӕng phҧi có khҧ năng đưӧc kӃt hӧp và liên
quan đӃn nhau. Mӝt trong các khía cҥnh cӫa phӕi hӧp mô hình là sӵ tích hӧp. Tích hӧp
có nghĩa là mӝt nhóm các mô hình cùng chung mөc đích và thӇ hiӋn cùng mӝt thӭ (mһc
dù chúng có thӇ có nhiӅu hưӟng nhìn khác nhau, ví dө như mô hình đӝng, mô hình chӭc
năng, mô hình tĩnh), thì chúng phҧi có khҧ năng đưӧc ráp lҥi vӟi nhau mà không làm nҧy
sinh mâu thuүn.

Quan hӋ giӳa các mô hình ӣ nhӳng mӭc đӝ trӯu tưӧng khác nhau là mӝt khía cҥnh quan
trӑng khác. Nó là mӝt trong nhӳng chìa khóa dүn đӃn khҧ năng có thӇ theo dõi bưӟc phát
triӇn cӫa các phҫn tӱ khác nhau, phөc vө cho công nghӋ lұp trình. Quan hӋ giӳa các mӭc
đӝ trӯu tưӧng khác nhau có thӇ đưӧc thӇ hiӋn bҵng quan hӋ nâng cҩp trong UML. ĐiӅu
đó có nghĩa là các mô hình sӁ đưӧc phӕi hӧp tҥi mӛi mӝt mӭc đӝ trӯu tưӧng cũng như
đưӧc phӕi hӧp giӳa các mӭc đӝ trӯu tưӧng khác nhau.

10.6- Đӝ phӭc tҥp cӫa mô hình

Ngay cҧ khi các mô hình cӫa chúng ta dӉ dàng giao tiӃp, có mӝt mөc đích rõ ràng, nҳm
bҳt đưӧc nhӳng điӇm trӑng yӃu trong phҥm vi vҩn đӅ và có thӇ đưӧc phӕi hӧp vӟi nhau,
ta vүn có thӇ gһp khó khăn nӃu mô hình quá phӭc tҥp. Nhӳng mô hình cӵc kǤ phӭc tҥp sӁ
khó nghiên cӭu, khó thҭm tra, khó phê duyӋt và khó bҧo trì. Sáng kiӃn tӕt là hãy bҳt đҫu
vӟi mӝt mô hình đơn giҧn, và sau đó chi tiӃt hóa nhiӅu hơn bҵng cách sӱ dөng viӋc phӕi
hӧp mô hình. NӃu bҧn chҩt phҥm vi vҩn đӅ cӫa chúng ta là phӭc tҥp, hãy xҿ mô hình
thành nhiӅu mô hình khác nhau (sӱ dөng các tiӇu mô hình ± tӭc là các gói) và cӕ gҳng đӇ
qui trình này có thӇ kiӇm soát đưӧc tình huӕng.

11- TÓM TҲT Vӄ MÔ HÌNH ĐӔI TƯӦNG

Khi tҥo mô hình là chúng ta diӉn giҧi các chi tiӃt vӅ nhӳng gì mà chúng ta nghiên cӭu,
thӃ nhưng mӝt yӃu tӕ rҩt quan trӑng là mô hình phҧi nҳm bҳt đưӧc nhӳng điӇm trӑng yӃu
cӫa đӕi tưӧng nghiên cӭu. Mӝt đӕi tưӧng là mӝt thӭ gì đó mà chúng ta có thӇ nói vӅ và
có thӇ xӱ lý trong mӝt sӕ phương thӭc nào đó. Mӝt đӕi tưӧng tӗn tҥi trong thӃ giӟi thӵc
(hoһc nói cho chính xác hơn là trong sӵ hiӇu biӃt cӫa chúng ta vӅ thӃ giӟi thӵc). Mӝt đӕi
tưӧng có thӇ là mӝt thành phҫn cӫa mӝt hӋ thӕng nào đó trong thӃ giӟi ± mӝt chiӃc máy,
mӝt tә chӭc, mӝt doanh nghӏêp. Mӝt lӟp là lӡi miêu tҧ tӯ 0, 1 hoһc nhiӅu đӕi tưӧng vӟi
cùng lӕi ӭng xӱ. Lӟp và đӕi tưӧng đưӧc sӱ dөng đӇ bàn luұn vӅ các hӋ thӕng.

Khi chúng ta mô hình hóa, chúng ta sӱ dөng mӝt ngôn ngӳ mô hình hóa ví dө như UML,
cung cҩp cho chúng ta ngӳ pháp và ngӳ nghĩa đӇ tҥo dӵng mô hình. Ngôn ngӳ mô hình
hóa mһc dù vұy không thӇ cho chúng ta biӃt liӋu chúng ta đã tҥo ra mӝt mô hình tӕt hay
không. Chҩt lưӧng mô hình cҫn phҧi đưӧc chú ý riêng biӋt, điӅu đó có nghĩa là tҩt cҧ các
mô hình cҫn phҧi có mӝt mөc đích rõ ràng và chính xác và chúng phҧi nҳm bҳt đưӧc bҧn
chҩt cӫa đӕi tưӧng nghiên cӭu. Tҩt cҧ các mô hình cҫn phҧi đưӧc làm sao đӇ dӉ giao tiӃp,
dӉ thҭm tra, phê duyӋt và bҧo trì.

UML cung cҩp mô hình tĩnh, đӝng và theo chӭc năng. Mô hình tĩnh đưӧc thӇ hiӋn qua
các biӇu đӗ lӟp, bao gӗm các lӟp và mӕi quan hӋ giӳa chúng. Quan hӋ có thӇ là liên hӋ,
khái quát hoá, phө thuӝc hoһc là nâng cҩp. Mӝt mӕi quan hӋ liên hӋ là mӝt sӵ nӕi kӃt
giӳa các lӟp, có nghĩa là sӵ nӕi kӃt giӳa các đӕi tưӧng cӫa các lӟp này. Khái quát hóa là
quan hӋ giӳa mӝt phҫn tӱ mang tính khái quát hơn và mӝt phҫn tӱ mang tính chuyên biӋt
hơn. Phҫn tӱ mang tính chuyên biӋt hơn có thӇ chӍ chӭa các thông tin bә sung. Mӝt thӵc
thӇ (mӝt đӕi tưӧng là mӝt thӵc thӇ cӫa mӝt lӟp) cӫa phҫn tӱ chuyên biӋt hơn có thӇ đưӧc
sӱ dөng bҩt cӭ nơi nào mà thӵc thӇ cӫa phҫn tӱ khái quát hơn đưӧc cho phép. Phө thuӝc
là mӕi quan hӋ giӳa hai phҫn tӱ, mӝt mang tính đӝc lұp và mӝt mang tính phө thuӝc. Mӛi
thay đәi trong phҫn tӱ đӝc lұp sӁ gây tác đӝng đӃn phҫn tӱ phө thuӝc. Mӝt quan hӋ nâng
cҩp là mӝt quan hӋ giӳa hai lӡi miêu tҧ cӫa cùng mӝt thӭ nhưng ӣ nhӳng mӭc đӝ trӯu
tưӧng khác nhau.

PHҪN CÂU HӒI

Hӓi: Khi tҥo dӵng mô hình, cҫn sӱ dөng các khái niӋm cӫa chính phҥm vi vҩn đӅ đӇ mô
hình dӉ hiӇu và dӉ giao tiӃp.

Đáp: Đúng

Hӓi: Các lӟp chӍ thӇ hiӋn cҩu trúc thông tin?

Đáp: sai, các lӟp không phҧi chӍ thӇ hiӋn cҩu trúc thông tin mà còn mô tҧ cҧ hành vi.

Hӓi: Các khái niӋm then chӕt thưӡng sӁ trӣ thành các lӟp trong mô hình phân tích?

Đáp: Đúng

Hӓi: Thưӡng các danh tӯ trong các lӡi phát biӇu bài toán sӁ là ӭng cӱ viên đӇ chuyӇn
thành lӟp và đӕi tưӧng?
Đáp: Đúng

Hӓi: Quan hӋ kӃt hӧp (Association) giӳa các lӟp đӏnh nghĩa các mӕi liên quan có thӇ tӗn
tҥi giӳa các đӕi tưӧng?

Đáp: Đúng, ví dө mӝt mӕi quan hӋ kӃt hӧp là mӝt sӵ nӕi kӃt giӳa các lӟp, có nghĩa là sӵ
nӕi kӃt giӳa các đӕi tưӧng cӫa các lӟp này.

Hӓi: KӃt tұp biӇu thӏ rҵng quan hӋ giӳa các lӟp dӵa trên nӅn tҧng cӫa nguyên tҳc "mӝt
tәng thӇ đưӧc tҥo thành bӣi các bӝ phұn"

Đáp: Đúng, nó đưӧc sӱ dөng khi chúng ta muӕn tҥo nên mӝt thӵc thӇ mӟi bҵng cách tұp
hӧp các thӵc thӇ tӗn tҥi vӟi nhau

Hӓi: Khái quát hoá đưӧc sӱ dөng đӇ tҥo các lӟp con?

Đáp: Sai, khái quát hoá là quá trình bҳt đҫu tӯ mӝt lӟp chuyên biӋt và khiӃn nó ngày
càng mang tính khái quát cao hơn (lӟp cha)

Hӓi: Chuyên biӋt hoá bә sung thêm chi tiӃt và đһc tҧ cho lӟp kӃt quҧ?

Đáp: Đúng, chuyên biӋt hoá là quá trình tinh chӃ mӝt lӟp thành nhӳng lӟp chuyên biӋt
hơn (lӟp con)

›››
 Chương 6: MÔ HÌNH ĐӜNG

›››

1- SӴ CҪN THIӂT CÓ MÔ HÌNH ĐӜNG (DYNAMIC MODEL)

Mô hình đӕi tưӧng và quá trình phát triӇn nó là trӑng tâm cӫa nhӳng cuӝc thҧo luұn trong
chương trưӟc. Mô hình đӕi tưӧng đӏnh nghĩa hӋ thӕng theo khái niӋm các thành phҫn
tĩnh. Mô hình đӕi tưӧng miêu tҧ ӭng xӱ mang tính cҩu trúc và chӭc năng cӫa các lӟp.
Mһc dҫu vұy, đӇ mô hình hóa sӵ hoҥt đӝng thұt sӵ cӫa mӝt hӋ thӕng và trình bày mӝt
hưӟng nhìn đӕi vӟi hӋ thӕng trong thӡi gian hӋ thӕng hoҥt đӝng, chúng ta cҫn tӟi mô
hình đӝng (dynamic model).

Trong UML, mô hình đӝng đӅ cұp tӟi các trҥng thái khác nhau trong vòng đӡi cӫa mӝt
đӕi tưӧng thuӝc hӋ thӕng. Phương thӭc ӭng xӱ cӫa mӝt hӋ thӕng tҥi mӝt thӡi điӇm cө thӇ
sӁ đưӧc miêu tҧ bҵng các điӅu kiӋn khác nhau ҩn đӏnh cho sӵ hoҥt đӝng cӫa nó.

Mӝt yӃu tӕ hӃt sӭc quan trӑng là cҫn phҧi hiӇu cho đưӧc hӋ thӕng sӁ đáp lҥi nhӳng kích
thích tӯ phía bên ngoài ra sao, có nghĩa là chúng ta cҫn phҧi xác đӏnh và nghiên cӭu
nhӳng chuӛi các thӫ tөc sӁ là hӋ quҧ cӫa mӝt sӵ kích thích tӯ ngoài. Cho viӋc này, ta cҫn
tӟi mô hình đӝng bӣi trӑng tâm cӫa mô hình này là lӕi ӭng xӱ phө thuӝc vào thӡi gian
cӫa các đӕi tưӧng trong hӋ thӕng.

Chúng ta cҫn tӟi mô hình đӝng bӣi chúng ta cҫn thӇ hiӋn sӵ thay đәi xҧy ra trong hӋ
thӕng dӑc theo thӡi gian chҥy. Công cө miêu tҧ mô hình đӝng là không thӇ thiӃu ví dө
trong trưӡng hӧp các đӕi tưӧng trҧi qua nhiӅu giai đoҥn khác nhau trong thӡi gian hӋ
thӕng hoҥt đӝng. ĐiӅu đó có nghĩa là mһc dù đӕi tưӧng đưӧc tҥo ra mӝt lҫn, nhưng các
thuӝc tính cӫa chúng chӍ dҫn dҫn tӯng bưӟc nhұn đưӧc giá trӏ. Ví dө như mӝt tài khoҧn
đҫu tư có kǤ hҥn đưӧc tҥo ra, nhưng tәng sӕ tiӅn lãi cӝng dӗn cӫa nó chӍ đưӧc tăng lên
dҫn dҫn theo thӡi gian.

Các mô hình đӝng cũng là yӃu tӕ hӃt sӭc cҫn thiӃt đӇ miêu tҧ ӭng xӱ cӫa mӝt đӕi tưӧng
khi đưa ra các yêu cҫu hoһc thӵc thi các tác vө. Cҧ tác vө lүn dӏch vө, theo đӏnh nghĩa,
đӅu là các hoҥt đӝng đӝng và vì thӃ mà chӍ có thӇ đưӧc biӇu diӉn qua mӝt mô hình đӝng.

2- CÁC THÀNH PHҪN CӪA MÔ HÌNH ĐӜNG

Đӕi tưӧng trong các hӋ thӕng giao tiӃp vӟi nhau, chúng gӱi thông điӋp (message) đӃn
nhau. Ví dө mӝt đӕi tưӧng khách hàng là John gӱi mӝt thông điӋp mua hàng đӃn ngưӡi
bán hàng là Bill đӇ làm mӝt viӋc gì đó. Mӝt thông điӋp thưӡng là mӝt lӋnh gӑi thӫ tөc mà
mӝt đӕi tưӧng này gӑi qua mӝt đӕi tưӧng kia. Các đӕi tưӧng giao tiӃp vӟi nhau ra sao và
hiӋu ӭng cӫa sӵ giao tiӃp như thӃ đưӧc gӑi là khía cҥnh đӝng cӫa mӝt hӋ thӕng, ý nghĩa
cӫa khái niӋm này là câu hӓi: các đӕi tưӧng cӝng tác vӟi nhau qua giao tiӃp như thӃ nào
và các đӕi tưӧng trong mӝt hӋ thӕng thay đәi trҥng thái ra sao trong thӡi gian hӋ thӕng
hoҥt đӝng. Sӵ giao tiӃp trong mӝt nhóm các đӕi tưӧng nhҵm tҥo ra mӝt sӕ các lӋnh gӑi
hàm đưӧc gӑi là tương tác (interaction), tương tác có thӇ đưӧc thӇ hiӋn qua ba loҥi biӇu
đӗ: biӇu đӗ tuҫn tӵ (sequence Diagram), biӇu đӗ cӝng tác (collaboration Diagram) và
biӇu đӗ hoҥt đӝng (activity Diagram).

Trong chương này, chúng ta sӁ đӅ cұp tӟi bӕn loҥi biӇu đӗ đӝng cӫa UML:

- BiӇu đӗ trҥng thái: miêu tҧ mӝt đӕi tưӧng có thӇ có nhӳng trҥng thái nào trong
vòng đӡi cӫa nó, ӭng xӱ trong các trҥng thái đó cũng như các sӵ kiӋn nào gây ra sӵ
chuyӇn đәi trҥng thái, ví dө, mӝt tӡ hóa đơn có thӇ đưӧc trҧ tiӅn (trҥng thái đã trҧ tiӅn)
hoһc là chưa đưӧc trҧ tiӅn (trҥng thái chưa trҧ tiӅn).

- BiӇu đӗ tuҫn tӵ: miêu tҧ các đӕi tưӧng tương tác và giao tiӃp vӟi nhau ra sao.
Tiêu điӇm trong các biӇu đӗ tuҫn tӵ là thӡi gian. Các biӇu đӗ tuҫn tӵ chӍ ra chuӛi cӫa các
thông điӋp đưӧc gӱi và nhұn giӳa mӝt nhóm các đӕi tưӧng, nhҵm mөc đích thӵc hiӋn mӝt
sӕ chӭc năng.

- BiӇu đӗ cӝng tác: cũng miêu tҧ các đӕi tưӧng tương tác vӟi nhau ra sao, nhưng
trӑng điӇm trong mӝt biӇu đӗ cӝng tác là sӵ kiӋn. Tұp trung vào sӵ kiӋn có nghĩa là chú ý
đһc biӋt đӃn mӕi quan hӋ (nӕi kӃt) giӳa các đӕi tưӧng, và vì thӃ mà phҧi thӇ hiӋn chúng
mӝt cách rõ ràng trong biӇu đӗ.

- BiӇu đӗ hoҥt đӝng: là mӝt con đưӡng khác đӇ chӍ ra tương tác, nhưng chúng
tұp trung vào công viӋc. Khi các đӕi tưӧng tương tác vӟi nhau, các đӕi tưӧng cũng thӵc
hiӋn các tác vө, tӭc là các hoҥt đӝng. Nhӳng hoҥt đӝng này cùng thӭ tӵ cӫa chúng đưӧc
miêu tҧ trong biӇu đӗ hoҥt đӝng.

Vì biӇu đӗ tuҫn tӵ, biӇu đӗ cӝng tác lүn biӇu đӗ hoҥt đӝng đӅu chӍ ra tương tác nên
thưӡng bҥn sӁ phҧi chӑn nên sӱ dөng biӇu đӗ nào khi lұp tài liӋu cho mӝt tương tác.
QuyӃt đӏnh cӫa bҥn sӁ phө thuӝc vào viӋc khía cҥnh nào đưӧc coi là quan trӑng nhҩt.

Ngoài cҩu trúc tĩnh và ӭng xӱ đӝng, hưӟng nhìn chӭc năng cũng có thӇ đưӧc sӱ dөng đӇ
miêu tҧ hӋ thӕng. Hưӟng nhìn chӭc năng thӇ hiӋn các chӭc năng mà hӋ thӕng sӁ cung
cҩp. Trưӡng hӧp sӱ dөng chính là các lӡi miêu tҧ hӋ thӕng theo chӭc năng; chúng miêu tҧ
các tác nhân có thӇ sӱ dөng hӋ thӕng ra sao. Như đã đӅ cұp tӯ trưӟc, trưӡng hӧp sӱ dөng
bình thưӡng ra đưӧc mô hình hóa trong nhӳng giai đoҥn đҫu tiên cӫa quá trình phân tích,
nhҵm mөc đích miêu tҧ xem tác nhân có thӇ muӕn sӱ dөng hӋ thӕng như thӃ nào. Mô
hình trưӡng hӧp sӱ dөng chӍ nên nҳm bҳt duy nhҩt khía cҥnh tác nhân sӱ dөng hӋ thӕng,
không nên đӅ cұp khía cҥnh hӋ thӕng đưӧc xây dӵng bên trong ra sao. Lӟp và các tương
tác trong hӋ thӕng thӵc hiӋn trưӡng hӧp sӱ dөng. Tương tác đưӧc miêu tҧ bӣi các biӇu đӗ
tuҫn tӵ, biӇu đӗ cӝng tác và hoһc/và biӇu đӗ hoҥt đӝng, tӭc là có mӝt sӵ nӕi kӃt giӳa
hưӟng nhìn chӭc năng và hưӟng nhìn đӝng cӫa hӋ thӕng. Các lӟp đưӧc sӱ dөng trong
viӋc thӵc thi các trưӡng hӧp sӱ dөng đưӧc mô hình hóa và miêu tҧ qua các biӇu đӗ lӟp và
biӇu đӗ trҥng thái (mӝt biӇu đӗ trҥng thái sӁ đưӧc đính kèm cho mӝt lӟp, mӝt hӋ thӕng
con hoһc là mӝt hӋ thӕng). Trưӡng hӧp sӱ dөng và các mӕi quan hӋ cӫa chúng đӃn tương
tác đã đưӧc miêu tҧ trong chương 3 (trưӡng hӧp sӱ dөng).

Nhìn chung, mӝt mô hình đӝng miêu tҧ năm khía cҥnh căn bҧn khác nhau:
 Hình 6.1- Các thành phҫn cӫa mô hình đӝng

Các thành phҫn kӇ trên sӁ đưӧc đӅ cұp chi tiӃt hơn trong các phҫn sau.

Ngoài ra, mӝt mô hình đӝng cũng còn đưӧc sӱ dөng đӇ xác đӏnh các nguyên tҳc chuyên
ngành (business rule) cҫn phҧi đưӧc áp dөng trong mô hình. Nó cũng đưӧc sӱ dөng đӇ ҩn
đӏnh xem các nguyên tҳc đó đưӧc đưa vào nhӳng vӏ trí nào trong mô hình.

Mӝt vài ví dө cho nhӳng nguyên tҳc chuyên ngành cҫn phҧi đưӧc thӇ hiӋn trong mô hình
đӝng:

- Mӝt khách hàng không đưӧc quyӅn rút tiӅn ra nӃu không có đӫ mӭc tiӅn trong
tài khoҧn.

- Nhӳng món tiӅn đҫu tư có kǤ hҥn không thӇ chuyӇn sang mӝt tên khác trưӟc khi
đáo hҥn.

- Giӟi hҥn cao nhҩt trong mӝt lҫn rút tiӅn ra bҵng thҿ ATM là 500 USD.

3- ƯU ĐIӆM CӪA MÔ HÌNH ĐӜNG:

Bҩt cӭ khi nào có nhӳng ӭng xӱ đӝng cҫn phҧi đưӧc nghiên cӭu hoһc thӇ hiӋn, chúng ta
sӁ phҧi dùng đӃn mô hình đӝng.

Mô hình đӝng đóng mӝt vai trò vô cùng quan trӑng trong nhӳng trưӡng hӧp như:

- Các hӋ thӕng mang tính tương tác cao

- HӋ thӕng có sӱ dөng các trang thiӃt bӏ ngoҥi vi có thӇ gӑi nên các ӭng xӱ cӫa hӋ
thӕng.
Mô hình đӝng không tӓ ra thұt sӵ hӳu hiӋu trong trưӡng hӧp cӫa các hӋ thӕng tĩnh. Ví dө
mӝt hӋ thӕng chӍ nhҵm mөc đích nhұp dӳ liӋu đӇ lưu trӳ vào mӝt ngân hàng dӳ liӋu.

Mӝt mô hình đӝng tұp trung vào các chuӛi tương tác (biӇu đӗ cӝng tác) và vào yӃu tӕ
thӡi gian cӫa các sӵ kiӋn (biӇu đӗ tuҫn tӵ). Mӝt mô hình đӝng có thӇ đưӧc sӱ dөng cho
mөc đích thӇ hiӋn rõ ràng theo thӡi gian hoҥt đӝng cӫa hӋ thӕng nӃu trong thӡi gian này
có nhӳng đӕi tưӧng:

- Đưӧc tҥo ra

- Bӏ xóa đi

- Đưӧc lưu trӳ

- Bӏ hӫy

Hãy quan sát trưӡng hӧp rút tiӅn mһt và tương tác cӫa khách hàng đӕi vӟi nhà băng:

- Khách hàng điӅn tҩt cҧ các chi tiӃt cҫn thiӃt vào giҩy yêu cҫu rút tiӅn mһt.

- Khách hàng đưa giҩy yêu cҫu đó cho mӝt nhân viên phát thҿ xӃp hàng.

- Nhân viên phát thҿ ghi sӕ cӫa giҩy yêu cҫu rút tiӅn vào danh sách.

- Đӝng tác ghi sӕ cӫa giҩy yêu cҫu rút tiӅn đưӧc thӵc hiӋn tuҫn tӵ, tương ӭng vӟi
nhӳng sӕ thҿ tuҫn tӵ đưӧc phát ra.

- Mӝt tҩm thҿ xӃp hàng (token) đưӧc trao cho khách hàng.

- Khách hàng đi vào hàng xӃp, chӡ nhân viên bên casse gӑi đúng sӕ thҿ cӫa mình.

- Song song vӟi quá trình chӡ cӫa khách hàng, giҩy yêu cҫu rút tiӅn cӫa anh ta trҧi
qua nhiӅu giai đoҥn trong nӝi bӝ nhà băng.

- Chӳ ký cӫa khách hàng trên giҩy yêu cҫu rút tiӅn đưӧc thҭm tra.

- Giҩy yêu cҫu đưӧc xem xét vӅ phương diӋn sӕ tài khoҧn và mӭc tiӅn trong tài
khoҧn.

- NӃu mӝt trong hai điӅu kiӋn trên không đưӧc thӓa mãn, quá trình rút tiӅn mһt sӁ
bӏ chһn lҥi hoһc là đưӧc sӱa đәi và tiӃp tөc.

- Khi cҧ hai điӅu kiӋn nêu trên đưӧc thӓa mãn, giҩy yêu cҫu rút tiӅn mһt sӁ đưӧc
đưa đӃn cho nhân viên ngӗi bên casse, nơi khách hàng sӁ đưӧc gӑi tӟi tuҫn tӵ dưҥ theo sӕ
thҿ xӃp hàng.
 - Nhân viên bên casse đưa tiӅn mһt cho khách hàng.

Lӕi ӭng xӱ trong viӋc rút tiӅn mһt là mang tính đӝng. Suӕt quá trình rút tiӅn mһt, tương
tác và trình tӵ cӫa quá trình phө thuӝc vào mӝt sӕ các điӅu kiӋn xác đӏnh. Loҥi ӭng xӱ
này không thӇ đưӧc thӇ hiӋn qua mô hình đӕi tưӧng, đây là trưӡng hӧp ta cҫn đӃn mô
hình đӝng.

Mô hình đӝng cũng tӓ ra hӳu dөng trong trưӡng hӧp có nhӳng trang thiӃt bӏ trҧi qua tuҫn
tӵ các bưӟc trong mӝt vòng lһp và tiӃn trình phө thuӝc vào mӝt sӕ điӅu kiӋn nhҩt đӏnh. Ví
dө mӝt đӕi tưӧng mô hình hóa lӕi ӭng xӱ cӫa mӝt máy rút tiӅn mһt tӵ đӝng (ATM). Máy
ATM lҫn lưӧt đi qua các bưӟc cӫa mӝt vòng lһp mang tính thӫ tөc (chӭc năng), bҳt đҫu
tӯ viӋc mӝt thҿ ATM đưӧc đút vào trong máy, xӱ lý các yêu cҫu do khách hàng đưa ra,
dӯng lҥi và chӡ yêu cҫu giao dӏch khác, rӗi sau đó quay trӣ lҥi trҥng thái ban đҫu (đӭng
yên) sau khi thҿ ATM đã đưӧc rút ra ngoài.

Hình 6.2- Mô hình đӝng cӫa máy rút tiӅn ATM

- SӴ KIӊN VÀ THÔNG ĐIӊP (EVENT & MESSAGE)

.1- Sӵ kiӋn (Event):

Mӝt trong nhӳng thành phҫn quan trӑng bұc nhҩt cӫa mӝt đӕi tưӧng là sӵ kiӋn. Mӝt sӵ
kiӋn là mӝt sư kích thích đưӧc gӱi tӯ đӕi tưӧng này sang đӕi tưӧng khác.

Mӝt sӵ kiӋn là mӝt viӋc sӁ xҧy ra và có thӇ gây ra mӝt hành đӝng nào đó. Ví dө như khi
bҥn bҩm lên nút 1
trên máy CD-Player, nó sӁ bҳt đҫu chơi nhҥc (giҧ sӱ rҵng CD-
Player có điӋn, trong máy có đĩa CD và nói chung là dàn CD-Player hoҥt đӝng tӕt). Sӵ
kiӋn ӣ đây là bҥn nhҩn lên nút 1
, và hành đӝng ӣ đây là bҳt đҫu chơi nhҥc. NӃu có mӝt
sӵ nӕi kӃt đưӧc đӏnh nghĩa rõ ràng giӳa sӵ kiӋn và hành đӝng, ngưӡi ta gӑi nó là quan hӋ
nhân quҧ (Causality). Trong công nghӋ phҫn mӅm, chúng ta thưӡng chӍ mô hình hóa
các hӋ thӕng mang tính nhân quҧ, nơi sӵ kiӋn và hành đӝng đưӧc nӕi kӃt vӟi nhau. Mӝt
phҧn ví dө cӫa quan hӋ nhân quҧ: bҥn lái xe trên xa lӝ vӟi tӕc đӝ quá nhanh, cҧnh sát
ngăn xe lҥi. Đây không phҧi là nhân quҧ bӣi hành đӝng ngăn bҥn lҥi cӫa cҧnh sát không
chҳc chҳn bao giӡ cũng xҧy ra; vì thӃ mà không có mӝt sӵ nӕi kӃt đưӧc đӏnh nghĩa rõ
ràng giӳa sӵ kiӋn (lái xe quá nhanh) và hành đӝng (ngăn xe). Trong mô hình hóa, vұy là
ta quan tâm đӃn sӵ kiӋn theo nghĩa là bҩt kǤ hành đӝng nào khiӃn hӋ thӕng phҧn ӭng theo
mӝt cách nào đó.

Quan sát ví dө mӝt nhà băng lҿ, ta có mӝt vài ví dө vӅ sӵ kiӋn như sau:

- ĐiӅn mӝt tӡ giҩy yêu cҫu rút tiӅn.

- Sӵ đáo hҥn mӝt tài khoҧn đҫu tư có kǤ hҥn.

- KӃt thúc mӝt hӧp đӗng trưӟc kǤ hҥn.

- ĐiӅn mӝt giҩy yêu cҫu mӣ tài khoҧn.

UML biӃt đӃn tҩt cҧ bӕn loҥi sӵ kiӋn:

- Mӝt điӅu kiӋn trӣ thành đưӧc thӓa mãn (trӣ thành đúng)

- Nhұn đưӧc mӝt tín hiӋu ngoҥi tӯ mӝt đӕi tưӧng khác

- Nhұn đưӧc mӝt lӡi gӑi thӫ tөc tӯ mӝt đӕi tưӧng khác (hay tӯ chính đӕi tưӧng
đó).

- Mӝt khoҧng thӡi gian xác đӏnh trưӟc trôi qua.

Xin chú ý rҵng cҧ các lӛi xҧy ra cũng là sӵ kiӋn và có thӇ mang tính hӳu dөng rҩt lӟn đӕi
vӟi mô hình.



u5 & 6

!7'%( & 6' ,Y 


Các sӵ kiӋn có thӇ mang tính đӝc lұp hay liên quan đӃn nhau. Có mӝt sӕ sӵ kiӋn, theo
bҧn chҩt, phҧi đi trưӟc hoһc là xҧy ra sau các sӵ kiӋn khác. Ví dө:

- ĐiӅn các chi tiӃt trong mӝt tӡ yêu cҫu rút tiӅn mһt sӁ dүn tӟi viӋc nhұn đưӧc mӝt
sӕ thҿ xӃp hàng.

- Sӵ đáo hҥn cӫa mӝt tài khoҧn đҫu tư có kǤ hҥn sӁ dүn đӃn đӝng tác gia hҥn hoһc
rút tiӅn mһt.

- ĐiӅn các chi tiӃt trong mӝt giҩy yêu cҫu mӣ tài khoҧn sӁ dүn tӟi viӋc phҧi nӝp
mӝt khoҧn tiӅn tӕi thiӇu (theo quy đӏnh) vào tài khoҧn.

Các sӵ kiӋn đӝc lұp là nhӳng sӵ kiӋn không đưӧc nӕi kӃt vӟi nhau trong bҩt kǤ mӝt
phương diӋn nào. Ví dө:
 - Rút tiӅn mһt và đưa tiӅn vào tài khoҧn là các sӵ kiӋn đӝc lұp vӟi nhau.

- Mӣ mӝt tài khoҧn đҫu tư có kǤ hҥn và mӣ mӝt tài khoҧn giao dӏch là đӝc lұp vӟi
nhau.

- KӃt thúc trưӟc kǤ hҥn mӝt tài khoҧn đҫu tư và viӋc mӣ mӝt tài khoҧn đҫu tư có
kǤ hҥn khác là đӝc lұp vӟi nhau.

Các sӵ kiӋn đӝc lұp còn có thӇ đưӧc gӑi là các sӵ kiӋn song song hay đӗng thӡi. Bӣi
chúng không phө thuӝc vào nhau, nên các sӵ kiӋn này có thӇ xҧy ra tҥi cùng mӝt thӡi
điӇm.

Trong nhiӅu trưӡng hӧp, mӝt sӵ kiӋn riêng lҿ trong phҥm vi vҩn đӅ sӁ đưӧc chuyӇn tҧi
thành nhiӅu sӵ kiӋn trong hӋ thӕng. Ví dө: đưa giҩy yêu cҫu rút tiӅn mһt cho nhân viên
phát thҿ xӃp hàng sӁ có kӃt quҧ là mӝt loҥt các sӵ kiӋn nӕi tiӃp.

Có nhӳng tình huӕng nơi mӝt sӵ kiӋn riêng lҿ sӁ đưӧc nhұn bӣi nhiӅu đӕi tưӧng khác
nhau và khiӃn cho chúng phҧn ӭng thích hӧp. Ví dө như mӝt lӡi đӅ nghӏ ngăn mӝt tӡ séc
có thӇ đӗng thӡi đưӧc gӱi đӃn cho nhân viên thu ngân và nhân viên kiӇm tra séc.

.1.2-Sӵ kiӋn nӝi (internal) và sӵ kiӋn ngoҥi (external):

Sӵ kiӋn nӝi là các sӵ kiӋn xҧy ra trong nӝi bӝ hӋ thӕng. Đây là các sӵ kiӋn do mӝt đӕi
tưӧng này gây ra đӕi vӟi đӕi tưӧng khác. Ví dө, tính toán tiӅn lãi cho mӝt tài khoҧn đҫu
tư có kǤ hҥn sӁ đưӧc nӝi bӝ hӋ thӕng thӵc hiӋn, tuân theo mӝt đӕi tưӧng quan sát ngày
tháng.

Sӵ kiӋn ngoҥi là nhӳng sӵ kiӋn đưӧc kích nên tӯ phía bên ngoài biên giӟi cӫa hӋ thӕng,
ví dө như sӵ kӃt thúc trưӟc kǤ hҥn mӝt tài khoҧn đҫu tư.

.1.3- Sӵ kiӋn và lӟp sӵ kiӋn:

Lӟp sӵ kiӋn đӕi vӟi sӵ kiӋn cũng như lӟp đӕi vӟi đӕi tưӧng bình thưӡng. Lӡi đӏnh nghĩa
xác đӏnh mӝt loҥi sӵ kiӋn đưӧc gӑi là mӝt lӟp sӵ kiӋn.

Lӟp sӵ kiӋn ngoài ra còn có thӇ đưӧc phân loҥi:

u + $ *  ,: Lӟp sӵ kiӋn trong trưӡng hӧp này sӁ đưӧc thӵc thӇ hóa
đӇ chӍ ra mӝt sӵ kiӋn hoһc là mӝt tín hiӋu cӫa mӝt sӵ kiӋn.

u +  *   , /> 1*: thưӡng thì mӝt sӵ kiӋn có khҧ năng và chuyӇn
tҧi dӳ liӋu. Tҩt cҧ các sӵ kiӋn cҫn phҧi "biӃt đӃn´ các đӕi tưӧng sӁ nhұn đưӧc sӵ kiӋn này.
Thông tin vӅ ngưӡi nhұn sӵ kiӋn đưӧc gӑi là thông tin nhұn diӋn. Nói mӝt cách khác, yӃu
tӕ nhұn diӋn xác đӏnh các đӕi tưӧng sӁ nhұn sӵ kiӋn. Bên cҥnh đó, còn có thӇ có các dӳ
liӋu bә sung thuӝc vӅ các đӕi tưӧng khác, không nhҩt thiӃt phҧi là đӕi tưӧng gӱi hay nhұn
sӵ kiӋn.
VӅ mһt nguyên tҳc, các sӵ kiӋn thuӝc dҥng phát tin (Broadcast) sӁ đưӧc truyӅn đӃn cho
tҩt cҧ các đӕi tưӧng. NӃu sӵ kiӋn này là không quan trӑng đӕi vӟi đӕi tưӧng nào đó trong
trҥng thái hiӋn thӡi cӫa nó thì đӕi tưӧng sӁ bӓ qua sӵ kiӋn.

.2- Thông điӋp (Message):

Trong lұp trình hưӟng đӕi tưӧng, mӝt tương tác giӳa hai đӕi tưӧng đưӧc thӵc thi dưӟi
dҥng thông điӋp đưӧc gӱi tӯ đӕi tưӧng này sang đӕi tưӧng khác. Trong ngӳ cҧnh này,
yӃu tӕ quan trӑng là không nên hiӇu danh tӯ "thông điӋp´ quá chính xác theo nghĩa văn
hӑc bình thưӡng. Mӝt thông điӋp ӣ đây thưӡng đưӧc thӵc hiӋn qua mӝt lӋnh gӑi thӫ tөc
đơn giҧn (mӝt đӕi tưӧng này gӑi mӝt thӫ tөc cӫa mӝt đӕi tưӧng khác); khi thӫ tөc đã
đưӧc thӵc hiӋn xong, quyӅn điӅu khiӇn đưӧc trao trӣ vӅ cho đӕi tưӧng gӑi thӫ tөc cùng
vӟi giá trӏ trҧ vӅ. Mӝt thông điӋp mһt khác cũng có thӇ là mӝt thông điӋp thӵc thө đưӧc
gӱi qua mӝt sӕ cơ chӃ giao tiӃp nào đó, hoһc là qua mҥng hoһc là nӝi bӝ trong mӝt máy
tính, đây là điӅu thưӡng xҧy ra trong các hӋ thӕng thӡi gian thӵc. Thông điӋp đưӧc thӇ
hiӋn trong tҩt cҧ các loҥi biӇu đӗ đӝng (tuҫn tӵ, cӝng tác, hoҥt đӝng và trҥng thái) theo ý
nghĩa là sӵ giao tiӃp giӳa các đӕi tưӧng. Mӝt thông điӋp đưӧc vӁ là mӝt đưӧc thҷng vӟi
mũi tên nӕi giӳa đӕi tưӧng gӱi và đӕi tưӧng nhұn thông điӋp. Loҥi mũi tên sӁ chӍ rõ loҥi
thông điӋp.

Hình 6.3 chӍ rõ các loҥi thông điӋp đưӧc sӱ dөng trong UML.

Hình 6.3- Các ký hiӋu cӫa các kiӇu thông điӋp

uÚ  6'  /( '!: ChӍ miêu tҧ đơn giҧn chiӅu điӅu khiӇn. Nó chӍ ra
quyӅn điӅu khiӇn đưӧc trao tӯ đӕi tưӧng này sang cho đӕi tưӧng khác mà không kèm
thêm lӡi miêu tҧ bҩt kǤ mӝt chi tiӃt nào vӅ sӵ giao tiӃp đó. Loҥi thông điӋp này đưӧc sӱ
dөng khi ngưӡi ta không biӃt các chi tiӃt vӅ giao tiӃp hoһc coi chúng là không quan trӑng
đӕi vӟi biӇu đӗ.

uÚ  6'#

(()  (): thưӡng đưӧc thӵc thi là mӝt lӋnh gӑi thӫ
tөc. Thӫ tөc xӱ lý thông điӋp này phҧi đưӧc hoàn tҩt (bao gӗm bҩt kǤ nhӳng thông điӋp
nào đưӧc lӗng vào trong, đưӧc gӱi như là mӝt thành phҫn cӫa sӵ xӱ lý) trưӟc khi đӕi
tưӧng gӑi tiӃp tөc thӵc thi. Quá trình trӣ vӅ có thӇ đưӧc chӍ ra dưӟi dҥng thông điӋp đơn
giҧn.
 u Ú   6' &   #
 (()  (): đây là dҥng điӅu khiӇn trình tӵ
không đӗng bӝ, nơi không có mӝt sӵ trӣ vӅ đӕi vӟi đӕi tưӧng gӑi và nơi đӕi tưӧng gӱi
thông điӋp tiӃp tөc quá trình thӵc thi cӫa mình sau khi đã gӱi thông điӋp đi, không chӡ
cho tӟi khi nó đưӧc xӱ lý xong. Loҥi thông điӋp này thưӡng đưӧc sӱ dөng trong các hӋ
thӕng thӡi gian thӵc, nơi các đӕi tưӧng thӵc thi đӗng thӡi.

Thông điӋp đơn giҧn và thông điӋp đӗng bӝ có thӇ đưӧc kӃt hӧp vӟi nhau trong chӍ mӝt
đưӡng thҷng chӍ thông điӋp vӟi mũi tên chӍ thông điӋp đӗng bӝ ӣ mӝt phía và mũi tên chӍ
thông điӋp đơn giҧn ӣ phía kia. ĐiӅu này chӍ rõ rҵng sӵ trҧ vӅ đưӧc xҧy ra hҫu như ngay
lұp tӭc sau lӋnh gӑi hàm.

5- BIӆU ĐӖ TUҪN TӴ (SEQUENCE DIAGRAM)

BiӇu đӗ tuҫn tӵ minh hӑa các đӕi tưӧng tương tác vӟi nhau ra sao. Chúng tұp trung vào
các chuӛi thông điӋp, có nghĩa là các thông điӋp đưӧc gӱi và nhұn giӳa mӝt loҥt các đӕi
tưӧng như thӃ nào. BiӇu đӗ tuҫn tӵ có hai trөc: trөc nҵm dӑc chӍ thӡi gian, trөc nҵm
ngang chӍ ra mӝt tұp hӧp các đӕi tưӧng. Mӝt biӇu đӗ tuҫn tӵ cũng nêu bұt sӵ tương tác
trong mӝt cҧnh kӏch (scenario) ± mӝt sӵ tương tác sӁ xҧy ra tҥi mӝt thӡi điӇm nào đó
trong quá trình thӵc thi cӫa hӋ thӕng.

Tӯ các hình chӳ nhұt biӇu diӉn đӕi tưӧng có các đưӡng gҥch rӡi (dashed line) thҷng đӭng
biӇu thӏ đưӡng đӡi đӕi tưӧng, tӭc là sӵ tӗn tҥi cӫa đӕi tưӧng trong chuӛi tương tác. Trong
khoҧng thӡi gian này, đӕi tưӧng đưӧc thӵc thӇ hóa, sҹn sàng đӇ gӱi và nhұn thông điӋp.
Quá trình giao tiӃp giӳa các đӕi tưӧng đưӧc thӇ hiӋn bҵng các đưӡng thҷng thông điӋp
nҵm ngang nӕi các đưӡng đӡi đӕi tưӧng. Mӛi tên ӣ đҫu đưӡng thҷng sӁ chӍ ra loҥi thông
điӋp này mang tính đӗng bӝ, không đӗng bӝ hay đơn giҧn. ĐӇ đӑc biӇu đӗ tuҫn tӵ, hãy
bҳt đҫu tӯ phía bên trên cӫa biӇu đӗ rӗi chҥy dӑc xuӕng và quan sát sӵ trao đәi thông
điӋp giӳa các đӕi tưӧng xҧy ra dӑc theo tiӃn trình thӡi gian.

Ví dө hãy quan sát mӝt cҧnh kӏch rút tiӅn mһt tҥi mӝt máy ATM cӫa mӝt nhà băng lҿ:
 Hình 6.- BiӇu đӗ cҧnh kӏch rút tiӅn mһt tҥi máy ATM

BiӇu đӗ trên có thӇ đưӧc diӉn giҧi theo trình tӵ thӡi gian như sau:

- Có ba lӟp tham gia cҧnh kӏch này: khách hàng, máy ATM và tài khoҧn.

- Khách hàng đưa yêu cҫu rút tiӅn vào máy ATM

- Đӕi tưӧng máy ATM yêu cҫu khách hàng cung cҩp mã sӕ

- Mã sӕ đưӧc gӱi cho hӋ thӕng đӇ kiӇm tra tài khoҧn

- Đӕi tưӧng tài khoҧn kiӇm tra mã sӕ và báo kӃt quҧ kiӇm tra đӃn cho ATM

- ATM gӱi kӃt quҧ kiӇm tra này đӃn khách hàng

- Khách hàng nhұp sӕ tiӅn cҫn rút.

 - ATM gӱi sӕ tiӅn cҫn rút đӃn cho tài khoҧn

- Đӕi tưӧng tài khoҧn trӯ sӕ tiӅn đó vào mӭc tiӅn trong tài khoҧn. Tҥi thӡi điӇm
này, chúng ta thҩy có mӝt mũi tên quay trӣ lҥi chӍ vào đӕi tưӧng tài khoҧn. Ý nghĩa cӫa
nó là đӕi tưӧng tài khoҧn xӱ lý yêu cҫu này trong nӝi bӝ đӕi tưӧng và không gӱi sӵ kiӋn
đó ra ngoài.

- Đӕi tưӧng tài khoҧn trҧ vӅ mӭc tiӅn mӟi trong tài khoҧn cho máy ATM.

- Đӕi tưӧng ATM trҧ vӅ mӭc tiӅn mӟi trong tài khoҧn cho khách hàng và dĩ
nhiên, cҧ lưӧng tiӅn khách hàng đã yêu cҫu đưӧc rút.

Đӕi tưӧng tài khoҧn chӍ bҳt đҫu đưӧc sinh ra khi đӕi tưӧng ATM cҫn tӟi nó đӇ kiӇm tra
mã sӕ và đӕi tưӧng tài khoҧn tiӃp tөc sӕng cho tӟi khi giao dӏch đưӧc hoàn tҩt. Sau đó, nó
chӃt đi. Bӣi khách hàng có thӇ muӕn tiӃp tөc thӵc hiӋn các giao dӏch khác nên đӕi tưӧng
khách hàng và đӕi tưӧng máy ATM vүn tiӃp tөc tӗn tҥi, điӅu này đưӧc chӍ ra qua viӋc các
đưӡng đӡi đӕi tưӧng đưӧc kéo vưӧt quá đưӡng thҷng thӇ hiӋn sӵ kiӋn cuӕi cùng trong
chuӛi tương tác.

Loҥi tương tác này là rҩt hӳu dөng trong mӝt hӋ thӕng có mӝt sӕ lưӧng nhӓ các đӕi tưӧng
vӟi mӝt sӕ lưӧng lӟn các sӵ kiӋn xҧy ra giӳa chúng. Mһc dù vұy, khi sӕ lưӧng các đӕi
tưӧng trong mӝt hӋ thӕng tăng lên thì mô hình này sӁ không còn mҩy thích hӧp.

ĐӇ có thӇ vӁ biӇu đӗ tuҫn tӵ, đҫu tiên hãy xác đӏnh các đӕi tưӧng liên quan và thӇ hiӋn
các sӵ kiӋn xҧy ra giӳa chúng.

Khi vӁ biӇu đӗ tuҫn tӵ, cҫn chú ý:

- Sӵ kiӋn đưӧc biӇu diӉn bҵng các đưӡng thҷng nҵm ngang.

- Đӕi tưӧng bҵng các đưӡng nҵm dӑc.

- Thӡi gian đưӧc thӇ hiӋn bҵng đưӡng thҷng nҵm dӑc bҳt đҫu tӯ trên biӇu đӗ.
ĐiӅu đó có nghĩa là các sӵ kiӋn cҫn phҧi đưӧc thӇ hiӋn theo đúng thӭ tӵ mà chúng xҧy ra,
vӁ tӯ trên xuӕng dưӟi.

6- BIӆU ĐӖ CӜNG TÁC (COLLABORATION DIAGRAM)

Mӝt biӇu đӗ cӝng tác miêu tҧ tương tác giӳa các đӕi tưӧng cũng giӕng như biӇu đӗ tuҫn
tӵ, nhưng nó tұp trung trưӟc hӃt vào các sӵ kiӋn, tӭc là tұp trung chӫ yӃu vào sӵ tương
tác giӳa các đӕi tưӧng.

Trong mӝt biӇu đӗ cӝng tác, các đӕi tưӧng đưӧc biӇu diӉn bҵng kí hiӋu lӟp. Thӭ tӵ trong
biӇu đӗ cӝng tác đưӧc thӇ hiӋn bҵng cách đánh sӕ các thông điӋp. Kӻ thuұt đánh sӕ đưӧc
coi là hơi có phҫn khó hiӇu hơn so vӟi kӻ thuұt mũi tên sӱ dөng trong biӇu đӗ tuҫn tӵ.
Nhưng ưu điӇm cӫa biӇu đӗ cӝng tác là nó có thӇ chӍ ra các chi tiӃt vӅ các lӋnh gӑi hàm
(thӫ tөc), yӃu tӕ đưӧc né tránh trong biӇu đӗ tuҫn tӵ.

BiӇu đӗ sau đây là mӝt ví dө cho mӝt biӇu đӗ cӝng tác, đưӧc chuҭn bӏ cũng cho mӝt cҧnh
kӏch rút tiӅn mһt như trong biӇu đӗ tuҫn tӵ cӫa phҫn trưӟc. Hãy quan sát các thӭ tӵ sӕ
trong biӇu đӗ. Đҫu tiên thӫ tөc WithdrawalReq() đưӧc gӑi tӯ lӟp khách hàng. Đó là lӋnh
gӑi sӕ 1. Bưӟc tiӃp theo trong tuҫn tӵ là hàm AskForPin(), sӕ 1.1, đưӧc gӑi tӯ lӟp ATM.
Thông điӋp trong biӇu đӗ đưӧc viӃt dưӟi dҥng pin:= AskForPin(), thӇ hiӋn rҵng "giá trӏ
trҧ vӅ" cӫa hàm này chính là mã sӕ mà lӟp khách hàng sӁ cung cҩp.

Hình cung bên lӟp tài khoҧn biӇu thӏ rҵng hàm ComputeNetBalance() đưӧc gӑi trong nӝi
bӝ lӟp tài khoҧn và nó xӱ lý cөc bӝ. Thưӡng thì nó sӁ là mӝt thӫ tөc riêng (private) cӫa
lӟp.

Hình 6.5- Mӝt biӇu đӗ cӝng tác cӫa kích cҧnh rút tiӅn ӣ máy ATM

7- BIӆU ĐӖ TRҤNG THÁI (STATE DIAGRAM)

BiӇu đӗ trҥng thái nҳm bҳt vòng đӡi cӫa các đӕi tưӧng, các hӋ thӕng con (Subsystem) và
các hӋ thӕng. Chúng cho ta biӃt các trҥng thái mà mӝt đӕi tưӧng có thӇ có và các sӵ kiӋn
(các thông điӋp nhұn đưӧc, các khoҧng thӡi gian đã qua đi, các lӛi xҧy ra, các điӅu kiӋn
đưӧc thӓa mãn) sӁ ҧnh hưӣng đӃn nhӳng trҥng thái đó như thӃ nào dӑc theo tiӃn trình
thӡi gian. BiӇu đӗ trҥng thái có thӇ đính kèm vӟi tҩt cҧ các lӟp có nhӳng trҥng thái đưӧc
nhұn diӋn rõ ràng và có lӕi ӭng xӱ phӭc tҥp. BiӇu đӗ trҥng thái xác đӏnh ӭng xӱ và miêu
tҧ nó sӁ khác biӋt ra sao phө thuӝc vào trҥng thái, ngoài ra nó cũng còn miêu tҧ rõ nhӳng
sӵ kiӋn nào sӁ thay đәi trҥng thái cӫa các đӕi tưӧng cӫa mӝt lӟp.
7.1- Trҥng thái và sӵ biӃn đәi trҥng thái (State transition)

Tҩt cҧ các đӕi tưӧng đӅu có trҥng thái; trҥng thái là mӝt kӃt quҧ cӫa các hoҥt đӝng trưӟc
đó đã đưӧc đӕi tưӧng thӵc hiӋn và nó thưӡng đưӧc xác đӏnh qua giá trӏ cӫa các thuӝc tính
cũng như các nӕi kӃt cӫa đӕi tưӧng vӟi các đӕi tưӧng khác. Mӝt lӟp có thӇ có mӝt thuӝc
tính đһc biӋt xác đӏnh trҥng thái, hoһc trҥng thái cũng có thӇ đưӧc xác đӏnh qua giá trӏ cӫa
các thuӝc tính ³bình thưӡng" trong đӕi tưӧng. Ví dө vӅ các trҥng thái cӫa đӕi tưӧng:

- Hóa đơn (đӕi tưӧng) đã đưӧc trҧ tiӅn (trҥng thái).

- ChiӃc xe ô tô (đӕi tưӧng) đang đӭng yên (trҥng thái).

- Đӝng cơ (đӕi tưӧng) đang chҥy (trҥng thái).

- Jen (đӕi tưӧng) đang đóng vai trò ngưӡi bán hàng (trҥng thái).

- Kate (đӕi tưӧng) đã lҩy chӗng (trҥng thái).

Mӝt đӕi tưӧng sӁ thay đәi trҥng thái khi có mӝt viӋc nào đó xҧy ra, thӭ đưӧc gӑi là sӵ
kiӋn; ví dө có ai đó trҧ tiӅn cho hóa đơn, bұt đӝng cơ xe ô tô hay là lҩy chӗng lҩy vӧ.
Khía cҥnh đӝng có hai chiӅu không gian: tương tác và sӵ biӃn đәi trҥng thái nӝi bӝ.
Tương tác miêu tҧ lӕi ӭng xӱ đӕi ngoҥi cӫa các đӕi tưӧng và chӍ ra đӕi tưӧng này sӁ
tương tác vӟi các đӕi tưӧng khác ra sao (qua viӋc gӱi thông điӋp, nӕi kӃt hoһc chҩm dӭt
nӕi kӃt). Sӵ biӃn đәi trҥng thái nӝi bӝ miêu tҧ mӝt đӕi tưӧng sӁ thay đәi các trҥng thái ra
sao ± ví dө giá trӏ các thuӝc tính nӝi bӝ cӫa nó sӁ thay đәi như thӃ nào. BiӇu đӗ trҥng thái
đưӧc sӱ dөng đӇ miêu tҧ viӋc bҧn thân đӕi tưӧng phҧn ӭng ra sao trưӟc các sӵ kiӋn và
chúng thay đәi các trҥng thái nӝi bӝ cӫa chúng như thӃ nào, ví dө, mӝt hóa đơn sӁ chuyӇn
tӯ trҥng thái chưa trҧ tiӅn sang trҥng thái đã trҧ tiӅn khi có ai đó trҧ tiӅn cho nó. Khi mӝt
hóa đơn đưӧc tҥo ra, đҫu tiên nó bưӟc vào trҥng thái chưa đưӧc trҧ tiӅn.

7.2- BiӇu đӗ trҥng thái

BiӇu đӗ trҥng thái thӇ hiӋn nhӳng khía cҥnh mà ta quan tâm tӟi khi xem xét trҥng thái cӫa
mӝt đӕi tưӧng:

- Trҥng thái ban đҫu

- Mӝt sӕ trҥng thái ӣ giӳa

- Mӝt hoһc nhiӅu trҥng thái kӃt thúc

- Sӵ biӃn đәi giӳa các trҥng thái

- Nhӳng sӵ kiӋn gây nên sӵ biӃn đәi tӯ mӝt trҥng thái này sang trҥng thái khác
Hình sau sӁ chӍ ra các kí hiӋu UML thӇ hiӋn trҥng thái bҳt đҫu và trҥng thái kӃt thúc, sӵ
kiӋn cũng như các trҥng thái cӫa mӝt đӕi tưӧng.

Hình 6.6- Các ký hiӋu UML thӇ hiӋn bҳt đҫu, kӃt thúc, sӵ kiӋn và trҥng thái cӫa mӝt đӕi
tưӧng.

Hình 6.7- BiӇu đӗ trҥng thái thӵc hiӋn hoá đơn.

Mӝt trҥng thái có thӇ có ba thành phҫn, như đưӧc chӍ trong hình sau :

Hình 6.8- Các ngăn Tên, BiӃn trҥng thái và hành đӝng

Phҫn thӭ nhҩt chӍ ra tên cӫa trҥng thái, ví dө như chӡ, đã đưӧc trҧ tiӅn hay đang chuyӇn
đӝng. Phҫn thӭ hai (không bҳt buӝc) dành cho các biӃn trҥng thái. Đây là nhӳng thuӝc
tính cӫa lӟp đưӧc thӇ hiӋn qua biӇu đӗ trҥng thái; nhiӅu khi các biӃn tҥm thӡi cũng tӓ ra
rҩt hӳu dөng trong trҥng thái, ví dө như các loҥi biӃn đӃm (counter). Phҫn thӭ ba (không
bҳt buӝc) là phҫn dành cho hoҥt đӝng, nơi các sӵ kiӋn và các hành đӝng có thӇ đưӧc liӋt
kê. Có ba loҥi sӵ kiӋn chuҭn hóa có thӇ đưӧc sӱ dөng cho phҫn hành đӝng:  ? C5@F
: ?
@F và / ? *@. Loҥi  *  C5 đưӧc sӱ dөng đӇ xác đӏnh các hành
đӝng khӣi nhұp trҥng thái, ví dө gán giá trӏ cho mӝt thuӝc tính hoһc gӱi đi mӝt thông
điӋp.  * 
có thӇ đưӧc sӱ dөng đӇ xác đӏnh hành đӝng khi rӡi bӓ trҥng thái. 
*  * đưӧc sӱ dөng đӇ xác đӏnh hành đӝng cҫn phҧi đưӧc thӵc hiӋn trong trҥng
thái, ví dө như gӱi mӝt thông điӋp, chӡ, hay tính toán. Ba loҥi sӵ kiӋn chuҭn này không
thӇ đưӧc sӱ dөng cho các mөc đích khác.
Mӝt sӵ biӃn đәi trҥng thái thưӡng có mӝt sӵ kiӋn đi kèm vӟi nó, nhưng không bҳt buӝc.
NӃu có mӝt sӵ kiӋn đi kèm, sӵ thay đәi trҥng thái sӁ đưӧc thӵc hiӋn khi sӵ kiӋn kia xҧy
ra. Mӝt hành đӝng loҥi  * trong trҥng thái có thӇ là mӝt quá trình đang tiӃp diӉn
(ví dө chӡ, điӅu khiӇn các thӫ tөc,...) phҧi đưӧc thӵc hiӋn trong khi đӕi tưӧng vүn ӣ
nguyên trong trҥng thái này. Mӝt hành đӝng  * có thӇ bӏ ngҳt bӣi các sӵ kiӋn tӯ
ngoài, có nghĩa là mӝt sӵ kiӋn kiӋn gây nên mӝt sӵ biӃn đәi trҥng thái có thӇ ngưng ngҳt
mӝt hành đӝng thӵc hiӋn mang tính nӝi bӝ đang tiӃp diӉn.

Trong trưӡng hӧp mӝt sӵ biӃn đәi trҥng thái không có sӵ kiӋn đi kèm thì trҥng thái sӁ
thay đәi khi hành đӝng nӝi bӝ trong trҥng thái đã đưӧc thӵc hiӋn xong (hành đӝng nӝi bӝ
kiӇu đi vào, đi ra, thӵc hiӋn hay các hành đӝng do ngưӡi sӱ dөng đӏnh nghĩa). Theo đó,
khi tҩt cҧ các hành đӝng thuӝc trҥng thái đã đưӧc thӵc hiӋn xong, mӝt sӵ thay đәi trҥng
thái sӁ tӵ đӝng xҧy ra mà không cҫn sӵ kiӋn tӯ ngoài.

Hình 6.9- BiӃn đәi trҥng thái không có sӵ kiӋn tӯ ngoài. Sӵ thay đәi trҥng thái xҧy ra khi
các hoҥt đӝng trong mӛi trҥng thái đưӧc thӵc hiӋn xong.

7.3- Nhұn biӃt trҥng thái và sӵ kiӋn

Quá trình phát hiӋn sӵ kiӋn và trҥng thái vӅ mһt bҧn chҩt bao gӗm viӋc hӓi mӝt sӕ các
câu hӓi thích hӧp:

- Mӝt đӕi tưӧng có thӇ có nhӳng trҥng thái nào?: Hãy liӋt kê ra tҩt cҧ nhӳng trҥng
thái mà mӝt đӕi tưӧng có thӇ có trong vòng đӡi cӫa nó.

- Nhӳng sӵ kiӋn nào có thӇ xҧy ra?: Bӣi sӵ kiӋn gây ra viӋc thay đәi trҥng thái
nên nhұn ra các sӵ kiӋn là mӝt bưӟc quan trӑng đӇ nhұn diӋn trҥng thái.

- Trҥng thái mӟi sӁ là gì?: Sau khi nhұn diӋn sӵ kiӋn, hãy xác đӏnh trҥng thái khi
sӵ kiӋn này xҧy ra và trҥng thái sau khi sӵ kiӋn này xҧy ra.

- Có nhӳng thӫ tөc nào sӁ đưӧc thӵc thi?: Hãy đӇ ý đӃn các thӫ tөc ҧnh hưӣng đӃn
trҥng thái cӫa mӝt đӕi tưӧng.

- Chuӛi tương tác giӳa các đӕi tưӧng là gì?: Tương tác giӳa các đӕi tưӧng cũng có
thӇ ҧnh hưӣng đӃn trҥng thái cӫa đӕi tưӧng.

- Qui đӏnh nào sӁ đưӧc áp dөng cho các phҧn ӭng cӫa các đӕi tưӧng vӟi nhau?:
Các qui đӏnh kiӅm tӓa phҧn ӭng đӕi vӟi mӝt sӵ kiӋn sӁ xác đӏnh rõ hơn các trҥng thái.
 - Nhӳng sӵ kiӋn và sӵ chuyӇn tҧi nào là không thӇ xҧy ra?: NhiӅu khi có mӝt sӕ
sӵ kiӋn hoһc sӵ thay đәi trҥng thái không thӇ xҧy ra. Ví dө như bán mӝt chiӃc ô tô đã
đưӧc bán rӗi.

- Cái gì khiӃn cho mӝt đӕi tưӧng đưӧc tҥo ra?: Đӕi tưӧng đưӧc tҥo ra đӇ trҧ lӡi
cho mӝt sӵ kiӋn. Ví dө như mӝt sinh viên ghi danh cho mӝt khóa hӑc.

- Cái gì khiӃn cho mӝt đӕi tưӧng bӏ hӫy?: Đӕi tưӧng sӁ bӏ hӫy đi khi chúng không
đưӧc cҫn tӟi nӳa. Ví dө khi mӝt sinh viên kӃt thúc mӝt khóa hӑc.

- Cái gì khiӃn cho đӕi tưӧng cҫn phҧi đưӧc tái phân loҥi (reclassfied)?: Nhӳng
loҥi sӵ kiӋn như mӝt nhân viên đưӧc tăng chӭc thành nhà quҧn trӏ sӁ khiӃn cho đӝng tác
tái phân loҥi cӫa nhân viên đó đưӧc thӵc hiӋn.

7.- Mӝt sӕ lӡi mách bҧo cho viӋc tҥo dӵng biӇu đӗ trҥng thái

- ChuyӇn biӇu đӗ tuҫn tӵ thành biӇu đӗ trҥng thái.

- Xác đӏnh các vòng lһp (loop)

- Bә sung thêm các điӅu kiӋn biên và các điӅu kiӋn đһc biӋt

- Trӝn lүn các cҧnh kӏch khác vào trong biӇu đӗ trҥng thái.

Mӝt khi mô hình đã đưӧc tҥo nên, hãy nêu ra các câu hӓi và kiӇm tra xem mô hình có khҧ
năng cung cҩp tҩt cҧ các câu trҧ lӡi. Qui trình sau đây cҫn phҧi đưӧc nhҳc lҥi cho mӛi đӕi
tưӧng.

7..1- ChuyӇn biӇu đӗ tuҫn tӵ thành biӇu đӗ trҥng thái

Hãy dõi theo mӝt chuӛi các sӵ kiӋn đưӧc miêu tҧ trong biӇu đӗ, chuӛi này phҧi mang tính
tiêu biӇu cho các tương tác trong hӋ thӕng. Hãy quan sát các sӵ kiӋn ҧnh hưӣng đӃn đӕi
tưӧng mà ta đang nghiên cӭu.

Hãy sҳp xӃp các sӵ kiӋn thành mӝt đưӡng dүn, dán nhãn input (hoһc entry) và output
(exit) cho các sӵ kiӋn. Khoҧng cách giӳa hai sӵ kiӋn này sӁ là mӝt trҥng thái.

NӃu cҧnh kӏch có thӇ đưӧc nhҳc đi nhҳc lҥi rҩt nhiӅu lҫn (vô giӟi hҥn), hãy nӕi đưӡng dүn
tӯ trҥng thái cuӕi cùng đӃn trҥng thái đҫu tiên.

BiӇu đӗ sau đây chӍ ra biӇu đӗ trҥng thái cӫa mӝt lӟp máy ATM, đưӧc chiӃt suҩt tӯ biӇu
đӗ tuҫn tӵ hoһc biӇu đӗ cӝng tác đã đưӧc trình bày trong các phҫn trưӟc.
 Hình 6.10- ChuyӇn mӝt biӇu đӗ tuҫn tӵ sang biӇu đӗ trҥng thái

7..2- Nhұn ra các vòng lһp (loop)

Mӝt chuӛi sӵ kiӋn có thӇ đưӧc nhҳc đi nhҳc lҥi vô sӕ lҫn đưӧc gӑi là vòng lһp (loop).

Hình 6.11- BiӇu đӗ lһp

Chú ý:

- Trong mӝt vòng lһp, chuӛi các sӵ kiӋn đưӧc nhҳc đi nhҳc lҥi cҫn phҧi đӗng nhҩt
vӟi nhau. NӃu có mӝt chuӛi các sӵ kiӋn khác chuӛi khác thì trưӡng hӧp đó không có
vòng lһp.

- Lý tưӣng nhҩt là mӝt trҥng thái trong vòng lһp sӁ có sӵ kiӋn kӃt thúc. Đây là yӃu
tӕ quan trӑng, nӃu không thì vòng lһp sӁ không bao giӡ kӃt thúc.

7..3- Bә sung thêm các điӅu kiӋn biên và các điӅu kiӋn đһc biӋt

Sau khi đã hoàn tҩt biӇu đӗ trҥng thái cho mӑi đӕi tưӧng cҫn thiӃt trong hӋ thӕng, đã đӃn
lúc chúng ta cҫn kiӇm tra, đӕi chӭng chúng vӟi điӅu kiӋn biên và các điӅu kiӋn đһc biӋt
khác, nhӳng điӅu kiӋn rҩt có thӇ đã chưa đưӧc quan tâm đӫ đӝ trong thӡi gian tҥo dӵng
biӇu đӗ trҥng thái. ĐiӅu kiӋn biên là nhӳng điӅu kiӋn thao tác trên giá trӏ, đây là nhӳng
giá trӏ nҵm bên ranh giӟi cӫa mӝt điӅu kiӋn đӇ quyӃt đӏnh vӅ trҥng thái cӫa đӕi tưӧng, ví
dө như quy đӏnh vӅ kǤ hҥn cӫa mӝt tài khoҧn là 30 ngày thì ngày thӭ 31 đӕi vӟi tài khoҧn
này sӁ là mӝt điӅu kiӋn biên. Các điӅu kiӋn đһc biӋt là nhӳng điӅu kiӋn ngoҥi lӋ, ví dө
ngày thӭ 30 cӫa tháng 2 năm 2000 (nӃu có mӝt điӅu kiӋn thұt sӵ như vұy tӗn tҥi ngoài
đӡi thӵc).

7..- Trӝn lүn các cҧnh kӏch khác vào trong biӇu đӗ trҥng thái

Mӝt khi biӇu đӗ trҥng thái cho mӝt đӕi tưӧng đã sҹn sàng, chúng ta cҫn phҧi trӝn nhӳng
chuӛi sӵ kiӋn có ҧnh hưӣng đӃn đӕi tưӧng này vào trong biӇu đӗ trҥng thái. ĐiӅu này có
nghĩa là chúng ta cҫn phҧi quan sát các hiӋu ӭng gián tiӃp cӫa các sӵ kiӋn khác đӕi vӟi
đӕi tưӧng đang là chӫ đӅ chính cӫa biӇu đӗ trҥng thái. Đây là viӋc quan trӑng, bӣi các đӕi
tưӧng trong mӝt hӋ thӕng tương tác vӟi nhau và vì các đӕi tưӧng khác cũng có khҧ năng
gây nên sӵ kiӋn cho mӝt đӕi tưӧng đӏnh trưӟc, nên lӕi ӭng xӱ này cũng cҫn phҧi đưӧc thӇ
hiӋn trong biӇu đӗ trҥng thái.

ĐiӇm bҳt đҫu cho công viӋc này là:

- Ҩn đӏnh mӝt điӇm bҳt đҫu chung cho tҩt cҧ các chuӛi sӵ kiӋn bә sung.

- Xác đӏnh điӇm nơi các ӭng xӱ bҳt đҫu khác biӋt vӟi nhӳng ӭng xӱ đã đưӧc mô
hình hóa trong biӇu đӗ trҥng thái.

Bә sung thêm sӵ các biӃn đәi mӟi tӯ trҥng thái này, trong tư cách mӝt đưӡng dүn thay
thӃ. Cҫn đӇ ý đӃn nhӳng đưӡng dүn có vҿ ngoài đӗng nhҩt nhưng thұt ra có khác biӋt
trong mӝt tình huӕng nhҩt đӏnh nào đó.

Hãy chú ý đӃn các sӵ kiӋn xҧy ra trong nhӳng tình huӕng bҩt tiӋn. Mӛi sӵ kiӋn do khách
hàng hay ngưӡi sӱ dөng gây nên đӅu có thӇ sa vào trҥng thái cӫa các sӵ kiӋn bҩt tiӋn. HӋ
thӕng không nҳm quyӅn điӅu khiӇn đӕi vӟi ngưӡi sӱ dөng và ngưӡi sӱ dөng có thӇ quyӃt
đӏnh đӇ làm nҧy ra mӝt sӵ kiӋn tҥi mӝt thӡi điӇm tiӋn lӧi đӕi vӟi anh ta. Ví dө như khách
hàng có thӇ quyӃt đӏnh kӃt thúc trưӟc kǤ hҥn mӝt tài khoҧn đҫu tư.

Mӝt trưӡng hӧp khác cũng cҫn phҧi đưӧc xӱ lý là sӵ kiӋn do ngưӡi sӱ dөng gây nên
không thӇ xҧy ra. Có mӝt loҥt các lý do (ngưӡi sӱ dөng thiӃu tұp trung, buӗn nҧn, lơ
đãng...) khiӃn cho sӵ kiӋn loҥi này không xҧy ra. Cҧ trưӡng hӧp này cũng phҧi đưӧc xӱ
lý thҩu đáo. Ví dө mӝt khách hàng thҩt bҥi trong viӋc báo cho nhà băng biӃt nhӳng mӋnh
lӋnh cӫa anh ta vӅ kǤ hҥn cӫa tài khoҧn, mӝt tҩm séc đưӧc viӃt ra nhưng lҥi không có khҧ
năng giҧi tӓa mӭc tiӅn cҫn thiӃt.

Nhìn theo phương diӋn các biӇu đӗ trҥng thái như là mӝt thành phҫn cӫa mô hình đӝng,
cҫn chú ý nhӳng điӇm sau:

- BiӇu đӗ trҥng thái chӍ cҫn đưӧc tҥo dӵng nên cho các lӟp đӕi tưӧng có ӭng xӱ
đӝng quan trӑng.
 - Hãy thҭm tra biӇu đӗ trҥng thái theo khía cҥnh tính nhҩt quán đӕi vӟi nhӳng sӵ
kiӋn dùng chung đӇ cho toàn bӝ mô hình đӝng đưӧc đúng đҳn.

- Dùng các trưӡng hӧp sӱ dөng đӇ hӛ trӧ cho quá trình tҥo dӵng biӇu đӗ trҥng
thái.

- Khi đӏnh nghĩa mӝt trҥng thái, hãy chӍ đӇ ý đӃn nhӳng thuӝc tính liên quan.

8- BIӆU ĐӖ HOҤT ĐӜNG (ACTIVITY DIAGRAM)

BiӇu đӗ hoҥt đӝng nҳm bҳt hành đӝng và các kӃt quҧ cӫa chúng. BiӇu đӗ hoҥt đӝng tұp
trung vào công viӋc đưӧc thӵc hiӋn trong khi thӵc thi mӝt thӫ tөc (hàm), các hoҥt đӝng
trong mӝt lҫn thӵc thi mӝt trưӡng hӧp sӱ dөng hoһc trong mӝt đӕi tưӧng. BiӇu đӗ hoҥt
đӝng là mӝt biӃn thӇ cӫa biӇu đӗ trҥng thái và có mӝt mөc tiêu tương đӕi khác, đó là nҳm
bҳt hành đӝng (công viӋc và nhӳng hoҥt đӝng phҧi đưӧc thӵc hiӋn) cũng như kӃt quҧ cӫa
chúng theo sӵ biӃn đәi trҥng thái. Các trҥng thái trong biӇu đӗ hoҥt đӝng (đưӧc gӑi là các
trҥng thái hành đӝng) sӁ chuyӇn sang giai đoҥn kӃ tiӃp khi hành đӝng trong trҥng thái này
đã đưӧc thӵc hiӋn xong (mà không xác đӏnh bҩt kǤ mӝt sӵ kiӋn nào theo như nӝi dung
cӫa biӇu đӗ trҥng thái). Mӝt sӵ điӇm phân biӋt khác giӳa biӇu đӗ hoҥt đӝng và biӇu đӗ
trҥng thái là các hành đӝng cӫa nó đưӧc đӏnh vӏ trong các ! (( !). Mӝt luӗng
sӁ gom nhóm các hoҥt đӝng, chú ý tӟi khái niӋm ngưӡi chӏu trách nhiӋm cho chúng hoһc
chúng nҵm ӣ đâu trong mӝt tә chӭc. Mӝt biӇu đӗ hoҥt đӝng là mӝt phương pháp bә sung
cho viӋc miêu tҧ tương tác, đi kèm vӟi trách nhiӋm thӇ hiӋn rõ các hành đӝng xҧy ra như
thӃ nào, chúng làm gì (thay đәi trҥng thái đӕi tưӧng), chúng xҧy ra khi nào (chuӛi hành
đӝng), và chúng xҧy ra ӣ đâu (luӗng hành đӝng).

BiӇu đӗ hoҥt đӝng có thӇ đưӧc sӱ dөng cho nhiӅu mөc đích khác nhau, ví dө như:

- ĐӇ nҳm bҳt công viӋc (hành đӝng) sӁ phҧi đưӧc thӵc thi khi mӝt thӫ tөc đưӧc
thӵc hiӋn. Đây là tác dөng thưӡng gһp nhҩt và quan trӑng nhҩt cӫa biӇu đӗ hoҥt đӝng.

- ĐӇ nҳm bҳt công viӋc nӝi bӝ trong mӝt đӕi tưӧng.

- ĐӇ chӍ ra mӝt nhóm hành đӝng liên quan có thӇ đưӧc thӵc thi ra sao, và chúng
sӁ ҧnh hưӣng đӃn nhӳng đӕi tưӧng nҵm xung quanh chúng như thӃ nào.

- ĐӇ chӍ ra mӝt trưӡng hӧp sӱ dөng có thӇ đưӧc thӵc thӇ hóa như thӃ nào, theo
khái niӋm hành đӝng và các sӵ biӃn đәi trҥng thái cӫa đӕi tưӧng.

- ĐӇ chӍ ra mӝt doanh nghiӋp hoҥt đӝng như thӃ nào theo các khái niӋm công
nhân (tác nhân), qui trình nghiӋp vө (workflow), hoһc tә chӭc và đӕi tưӧng (các khía
cҥnh vұt lý cũng như tri thӭc đưӧc sӱ dөng trong doanh nghiӋp).

BiӇu đӗ hoҥt đӝng có thӇ đưӧc coi là mӝt loҥi Flow chart. ĐiӇm khác biӋt là Flow Chart
bình thưӡng ra chӍ đưӧc áp dөng đӕi vӟi các qui trình tuҫn tӵ, biӇu đӗ hoҥt đӝng có thӇ
xӱ lý cҧ các các qui trình song song.
Hành đӝng và sӵ thay đәi trҥng thái

Mӝt hành đӝng đưӧc thӵc hiӋn đӇ sҧn sinh ra mӝt kӃt quҧ. ViӋc thӵc thi cӫa thӫ tөc có
thӇ đưӧc miêu tҧ dưӟi dҥng mӝt tұp hӧp cӫa các hành đӝng liên quan, sau này chúng sӁ
đưӧc chuyӇn thành các dòng code thұt sӵ. Theo như đӏnh nghĩa ӣ phҫn trưӟc, mӝt biӇu đӗ
hoҥt đӝng chӍ ra các hành đӝng cùng mӕi quan hӋ giӳa chúng và có thӇ có mӝt điӇm bҳt
đҫu và mӝt điӇm kӃt thúc. BiӇu đӗ hoҥt đӝng sӱ dөng cũng cùng nhӳng ký hiӋu như trong
biӇu đӗ trҥng thái bình thưӡng.

Hình 6.12- Khi mӝt ngưӡi gӑi tác vө PrintAllCustomer (trong lӟp CustomerWindow),
các hành đӝng khӣi đӝng. hành đӝng đҫu tiên là hiӋn mӝt hӝp thông báo lên màn hình;
hành đӝng thӭ hai là tҥo mӝt tұp tin postscript; hành đӝng thӭ ba là gӣi file postscript đӃn
máy in; và hành đӝng thӭ tư là xóa hӝp thông báo trên màn hình. Các hành đӝng đưӧc
chuyӇn tiӃp tӵ đӝng; chúng xҧy ra ngay khi hành đӝng trong giai đoҥn nguӗn đưӧc thӵc
hiӋn.

Các sӵ thay đәi có thӇ đưӧc bҧo vӋ bӣi các điӅu kiӋn canh giӳ (Guard-condition), các
điӅu kiӋn này phҧi đưӧc thӓa mãn thì sӵ thay đәi mӟi nә ra. Mӝt ký hiӋu hình thoi đưӧc
sӱ dөng đӇ thӇ hiӋn mӝt quyӃt đӏnh. Ký hiӋu quyӃt đӏnh có thӇ có mӝt hoһc nhiӅu sӵ thay
đәi đi vào và mӝt hoһc nhiӅu sӵ thay đәi đi ra đưӧc dán nhãn đi kèm các điӅu kiӋn bҧo
vӋ. Bình thưӡng ra, mӝt trong sӕ các sӵ thay đәi đi ra bao giӡ cũng đưӧc thӓa mãn (là
đúng).

! sӵ thay đәi đưӧc chia thành hai hay nhiӅu sӵ thay đәi khác sӁ dүn đӃn các hành đӝng
xҧy ra song song. Các hành đӝng đưӧc thӵc hiӋn đӗng thӡi, mһc dù chúng cũng có thӇ
đưӧc thӵc hiӋn lҫn lưӧt tӯng cái mӝt. YӃu tӕ quan trӑng ӣ đây là tҩt cҧ các thay đәi đӗng
thӡi phҧi đưӧc thӵc hiӋn trưӟc khi chúng đưӧc thӕng nhҩt lҥi vӟi nhau (nӃu có). Mӝt
đưӡng thҷng nҵm ngang kҿ đұm (còn đưӧc gӑi là thanh đӗng hӝ hóa ± Synchronisation
Bar) chӍ rҵng mӝt sӵ thay đәi đưӧc chia thành nhiӅu nhánh khác nhau và chӍ ra mӝt sӵ
chia sҿ thành các hành đӝng song song. Cũng đưӡng thҷng đó đưӧc sӱ dөng đӇ chӍ ra sӵ
thӕng nhҩt các nhánh.

Kí hiӋu UML cho các thành phҫn căn bҧn cӫa biӇu đӗ hoҥt đӝng:
 u G ! (C ): là mӝt qui trình đưӧc đӏnh nghĩa rõ ràng, có thӇ đưӧc thӵc
thi qua mӝt hàm hoһc mӝt nhóm đӕi tưӧng. Hoҥt đӝng đưӧc thӇ hiӋn bҵng hình chӳ nhұt
bo tròn cҥnh.

- Thanh đӗng bӝ hóa (Synchronisation bar): chúng cho phép ta mӣ ra hoһc là

đóng lҥi các nhánh chҥy song song nӝi bӝ trong tiӃn trình.

Hình 6.13- Thanh đӗng bӝ hóa

u H9 * 
 > ?I
/ +/@: các biӇu thӭc logic có giá trӏ hoһc đúng
hoһc sai. ĐiӅu kiӋn canh giӳ đưӧc thӇ hiӋn trong ngoһc vuông, ví dө:

[Customer existing].

u H   # ?J @: đưӧc sӱ dөng đӇ chӍ ra các sӵ thay đәi khҧ
thi. Kí hiӋu là hình thoi.

Hình sau đây miêu tҧ mӝt đoҥn biӇu đӗ hoҥt đӝng cӫa máy ATM. Sau khi thҿ đưӧc đưa
vào máy, ta thҩy có ba hoҥt đӝng song song:

- Xác nhұn thҿ

- Xác nhұn mã sӕ PIN

- Xác nhұn sӕ tiӅn yêu cҫu đưӧc rút

ChӍ khi sӱ dөng biӇu đӗ hoҥt đӝng, các hoҥt đӝng song song như vұy mӟi có thӇ đưӧc
miêu tҧ. Mӛi mӝt hoҥt đӝng xác nhұn bҧn thân nó cũng đã có thӇ là mӝt quá trình riêng
biӋt.
 Hình 6.1- BiӇu đӗ hoҥt đӝng cӫa máy ATM

9- VÒNG ĐӠI ĐӔI TƯӦNG (OBJECT LIFECYCLE)

Vòng đӡi mà mӝt đӕi tưӧng đi qua phө thuӝc vào loҥi đӕi tưӧng. Có hai loҥi vòng đӡi
khác nhau đӕi vӟi mӝt đӕi tưӧng: vòng đӡi sinh ra rӗi chӃt đi; và vòng đӡi vòng lһp.

9.1- Vòng đӡi sinh ra và chӃt đi:

Trong mӝt vòng đӡi sinh ra rӗi chӃt đi:

- SӁ có mӝt hay nhiӅu trҥng thái nơi đӕi tưӧng bҳt đҫu tӗn tҥi. Nhӳng trҥng thái
này đưӧc gӑi là trҥng thái tҥo ra đӕi tưӧng.

- SӁ có mӝt hay nhiӅu trҥng thái đóng tư cách là điӇm kӃt thúc cho vòng đӡi cӫa
mӝt đӕi tưӧng. Nhӳng trҥng thái này đưӧc gӑi là trҥng thái kӃt thúc.

Có hai loҥi trҥng thái kӃt thúc. Mӝt dҥng trҥng thái kӃt thúc là loҥi nơi đӕi tưӧng bӏ hӫy
và không tiӃp tөc tӗn tҥi nӳa. Loҥi thӭ hai là dҥng trҥng thái kӃt thúc mà sau đó đӕi tưӧng
sӁ đưӧc lưu trӳ lҥi hoһc chuyӇn sang trҥng thái im lһng. Đӕi tưӧng tiӃp tөc tӗn tҥi nhưng
không tiӃp tөc thӇ hiӋn ӭng xӱ đӝng.
Sau trҥng thái khӣi tҥo và trưӟc trҥng thái kӃt thúc, đӕi tưӧng có thӇ đi qua mӝt hoһc là
nhiӅu trҥng thái trung gian. Tҥi mӛi mӝt thӡi điӇm, đӕi tưӧng phҧi ӣ mӝt trҥng thái hiӋn
thӡi.

Không có mӝt điӇm nào sau trҥng thái khӣi tҥo và trưӟc trҥng thái kӃt thúc mà đӕi tưӧng
lҥi không có trҥng thái.

Ví dө cho đӕi tưӧng có vòng đӡi sinh ra và chӃt đi: khách hàng, tài khoҧn.

9.2- Vòng đӡi lһp

Khác vӟi trưӡng hӧp sinh ra và chӃt đi, trong vòng đӡi vòng lһp:

- Đӕi tưӧng đưӧc coi là đã luôn luôn tӗn tҥi ӣ đây và sӁ còn mãi mãi tiӃp tөc tӗn
tҥi.

- Không có trҥng thái khӣi tҥo cũng không có trҥng thái kӃt thúc.

Mһc dù thұt ra đӕi tưӧng đã đưӧc tҥo ra tҥi mӝt thӡi điӇm nào đó và cũng sӁ thұt sӵ bӏ
hӫy diӋt tҥi mӝt thӡi điӇm nào đó, nhưng nó vүn đưӧc coi là luôn luôn tӗn tҥi và có mһt.
Thưӡng thì nhӳng đӕi tưӧng tӓ ra có mӝt vòng đӡi vòng lһp sӁ đưӧc tҥo ra tҥi thӡi điӇm
cài đһt hӋ thӕng và sӁ chӃt đi khi hӋ thӕng kӃt thúc.

Mӝt đӕi tưӧng vӟi vòng đӡi vòng lһp sӁ có mӝt hoһc là nhiӅu trҥng thái "ngӫ yên". Đó là
nhӳng trҥng thái nơi đӕi tưӧng nҵm chӡ mӝt sӵ kiӋn xҧy ra. Bên cҥnh đó, đӕi tưӧng cũng
luôn luôn ӣ trҥng thái hiӋn thӡi.

Ví dө cho đӕi tưӧng có vòng đӡi lһp lҥi: máy rút tiӅn tӵ đӝng (ATM), nhân viên thu ngân.

10- XEM XÉT LҤI MÔ HÌNH ĐӜNG

10.1- Thҭm vҩn biӇu đӗ trҥng thái

Sau khi đã hoàn tҩt các thành phҫn căn bҧn cӫa mô hình đӝng như các biӇu đӗ tuҫn tӵ,
biӇu đӗ cӝng tác, biӇu đӗ trҥng thái và biӇu đӗ hoҥt đӝng, nhóm phát triӇn có thӇ phác
thҧo biӇu đӗ thành phҫn và biӇu đӗ triӇn khai. BiӇu đӗ triӇn khai có thӇ đưӧc coi là biӇu
đӗ cuӕi cùng trong mô hình đӝng. Tӟi thӡi điӇm này, có thӇ coi là ta đã hoàn tҩt mӝt
phiên bҧn cӫa mô hình đӝng.

Phҫn quan trӑng nhҩt trong mô hình này là biӇu đӗ trҥng thái. Hãy tìm câu trҧ lӡi cho mӝt
loҥt các câu hӓi đӇ xác đӏnh xem biӇu đӗ trҥng thái đã đúng đҳn và có mӝt mӭc đӝ chi tiӃt
thích hӧp hay chưa. Công viӋc này cҫn nhҳm tӟi hai mөc đích:

- KiӇm tra tính trӑn vҽn cӫa mô hình

- Đҧm bҧo mӑi điӅu kiӋn gây lӛi đã đưӧc xӱ lý

Trong giai đoҥn này, có thӇ sӁ có các cҧnh kӏch (scenario) mӟi xuҩt hiӋn và gia nhұp
phҥm vi quan sát cӫa chúng ta, nӃu trưӟc đó có mӝt sӕ trҥng thái chưa đưӧc xӱ lý. Nhӳng
tình huӕng loҥi này là loҥi vҩn đӅ có thӇ đưӧc giҧi quyӃt, song có thӇ né tránh qua viӋc
xác đӏnh thұt đҫy đӫ các sӵ kiӋn và trҥng thái.

10.2- Phӕi hӧp sӵ kiӋn

Bưӟc cuӕi cùng là mӝt vòng kiӇm tra bә sung nhҵm đҧm bҧo tính đúng đҳn cӫa mô hình
đӝng:

- KiӇm tra đӇ đҧm bҧo mӛi thông điӋp đӅu có đӕi tưӧng gӱi và đӕi tưӧng nhұn.
Trong mӝt sӕ trưӡng hӧp, sӕ liӋu chính xác cӫa nhӳng đӕi tưӧng nhұn sӵ kiӋn có thӇ
không đưӧc biӃt tӟi, nhưng chúng ta phҧi đҧm bҧo rҵng chúng ta biӃt nhӳng lӟp nào sӁ
xӱ lý nhӳng sӵ kiӋn này.

- Hãy nghiên cӭu mô hình theo khía cҥnh trҥng thái, tìm ra nhӳng trҥng thái
không có trҥng thái dүn trưӟc và không có trҥng thái tiӃp theo. Nhӳng trҥng thái thái này
rҩt có thӇ là trҥng thái khӣi đҫu hoһc trҥng thái kӃt thúc. Mһc dù vұy, nӃu trҥng thái đó
không thuӝc vӅ mӝt trong hai loҥi trҥng thái kia, rҩt có thӇ đây là mӝt triӋu chӭng cho
thҩy mô hình còn thiӃu điӅu gì đó.

- Nhìn chung, tҩt cҧ các trҥng thái thưӡng đӅu có trҥng thái dүn trưӟc và trҥng thái
tiӃp sau.

- Hãy lҫn theo hӏêu ӭng cӫa các sӵ kiӋn đi vào (entry) đӇ đҧm bҧo là chúng tương
thích vӟi các trưӡng hӧp sӱ dөng nơi chúng xuҩt phát. ĐӇ làm điӅu này, hãy lҫn theo mӝt
sӵ kiӋn tӯ mӝt đӕi tưӧng này đӃn đӕi tưӧng khác, kiӇm tra xem mӛi sӵ kiӋn có phù hӧp
vӟi trưӡng hӧp sӱ dөng hay không. Trong trưӡng hӧp có mâu thuүn, hãy sӱa lҥi biӇu đӗ
trҥng thái hoһc trưӡng hӧp sӱ dөng đӇ đҧm bҧo sӵ nhҩt quán.

- KiӇm tra lҥi nhӳng lӛi đӗng bӝ, có thӇ chúng là kӃt quҧ cӫa mӝt sӵ kiӋn không
chӡ đӧi.

10.3- Bao giӡ thì sӱ dөng biӇu đӗ nào

Không cҫn phҧi vӁ tҩt cҧ các loҥi biӇu đӗ đӝng cho tҩt cҧ các loҥi hӋ thӕng. Mһc dù vұy,
trong mӝt sӕ trưӡng hӧp khác nhau chúng ta nhҩt thiӃt phҧi cҫn đӃn mӝt sӕ loҥi biӇu đӗ
đӝng nhҩt đӏnh. Sau đây là mӝt vài lӡi mách bҧo có thӇ giúp giҧi thích mӝt vài điӅu còn
chưa thông tӓ vӅ viӋc sӱ dөng các loҥi biӇu đӗ đӝng.

BiӇu đӗ tuҫn tӵ và biӇu đӗ cӝng tác đưӧc vӁ khi chúng ta muӕn xem xét ӭng xӱ đӝng cӫa
nhiӅu đӕi tưӧng/ lӟp trong nӝi bӝ mӝt cҧnh kӏch cӫa mӝt trưӡng hӧp sӱ dөng. BiӇu đӗ
tuҫn tӵ và biӇu đӗ cӝng tác rҩt hӳu dөng trong viӋc chӍ ra sӵ cӝng tác giӳa các đӕi tưӧng,
nhưng chúng lҥi không hӳu dөng khi muӕn miêu tҧ ӭng xӱ chính xác cӫa mӝt đӕi tưӧng.

BiӇu đӗ trҥng thái đưӧc sӱ dөng đӇ thӇ hiӋn ӭng xӱ chính xác cӫa mӝt đӕi tưӧng.
BiӇu đӗ hoҥt đӝng đưӧc sӱ dөng đӇ thӇ hiӋn lӕi ӭng xӱ xuyên suӕt nhiӅu trưӡng hӧp sӱ
dөng hoһc các tiӇu trình xҧy ra song song cӫa mӝt lҫn thӵc thi.

BiӇu đӗ thành phҫn và biӇu đӗ triӇn khai đưӧc sӱ dөng đӇ chӍ ra mӕi quan hӋ vұt lý giӳa
phҫn mӅm và các thành phҫn phҫn cӭng trong hӋ thӕng.

10.- Lӟp con và biӇu đӗ trҥng thái

Tҩt cҧ các lӟp con đӅu thӯa kӃ cҧ thuӝc tính cũng như các thӫ tөc cӫa lӟp cha. Vì vұy,
mӝt lӟp con cũng sӁ thӯa kӃ cҧ mô hình đӝng cӫa lӟp cha.

Ngoài biӇu đӗ trҥng thái đưӧc thӯa kӃ, lӟp con cũng có biӇu đӗ trҥng thái riêng cӫa nó.
BiӇu đӗ trҥng thái cӫa mӝt lӟp cha sӁ đưӧc mӣ rӝng đӇ bao chӭa lӕi ӭng xӱ chuyên biӋt
cӫa lӟp con.

BiӇu đӗ trҥng thái cӫa lӟp con và biӇu đӗ trҥng thái cӫa lӟp cha phҧi đưӧc bҧo trì riêng
biӋt và đӝc lұp. BiӇu đӗ trҥng thái cӫa lӟp con cҫn phҧi đưӧc đӏnh nghĩa sӱ dөng các
thuӝc tính cӫa lӟp con chӭ không phҧi chӍ bҵng các thuӝc tính cӫa lӟp cha. Mһt khác, vүn
có mӝt sӵ móc nӕi ngoài ý muӕn cӫa lӟp cha đӃn vӟi lӟp con thông qua các thuӝc tính
mà chúng sӱ dөng chung, ví dө chӍ nên xem xét biӇu đӗ trҥng thái cho các tài khoҧn có
kǤ hҥn theo phương diӋn sӵ thay đәi cӫa chính các thuӝc tính cӫa chúng, chӭ không phҧi
là thuӝc tính cӫa lӟp cha. Ta phҧi thӵc hiӋn như vұy đӇ né tránh trưӡng hӧp trӝn lүn
thuӝc tính cӫa lӟp con và lӟp cha.

ViӋc tuân thӫ quy tҳc kӇ trên trong quá trình vӁ biӇu đӗ trҥng thái cho mӝt lӟp con sӁ
đҧm bҧo tính môđun cho đӝng tác mӣ rӝng cӫa bҥn.

11- PHӔI HӦP MÔ HÌNH ĐӔI TƯӦNG VÀ MÔ HÌNH ĐӜNG

Khi kӃt hӧp giӳa các mô hình đӕi tưӧng và mô hình đӝng, mӛi sӵ kiӋn trong mô hình
đӝng cҫn phҧi tương thích vӟi mӝt thӫ tөc trong mô hình đӕi tưӧng. Tӯ đó suy ra, mӛi sӵ
thay đәi vӅ mһt trҥng thái trong mô hình đӝng cҫn phҧi phù hӧp vӟi mӝt thӫ tөc cӫa đӕi
tưӧng. Hành đӝng phө thuӝc vào trҥng thái cӫa đӕi tưӧng và vào sӵ kiӋn.

Mӕi quan hӋ giӳa mô hình đӕi tưӧng và mô hình đӝng có thӇ đưӧc miêu tҧ như sau:

- Mô hình đӕi tưӧng là cơ cҩu (framework) cho mô hình đӝng.

- Mô hình đӝng xác đӏnh các chuӛi thay đәi đưӧc phép xҧy ra đӕi vӟi các đӕi
tưӧng trong mô hình đӕi tưӧng.

- Mô hình đӝng bӏ hҥn chӃ chӍ trong nhӳng đӕi tưӧng có mһt trong mô hình đӕi
tưӧng cũng như cҩu trúc cӫa chúng.

- Không thӇ có mӝt mô hình đӝng cho mӝt đӕi tưӧng không tӗn tҥi trong mô hình
đӕi tưӧng. Có mӝt mӕi quan hӋ 1-1 giӳa mô hình đӕi tưӧng và mô hình đӝng.
 - Mô hình đӝng chính là mô hình đӕi tưӧng cӝng thêm vӟi phҫn ӭng xӱ "sӕng".

- Mô hình đӕi tưӧng miêu tҧ sӵ khác biӋt giӳa các đӕi tưӧng như là sӵ khác biӋt
giӳa các lӟp. Khi mӝt đӕi tưӧng ӭng xӱ khác mӝt đӕi tưӧng khác thì mӛi đӕi tưӧng trong
sӕ đó sӁ có mӝt lӟp riêng.

- Mһc dù vұy, trong mô hình đӝng, sӵ khác biӋt trong ӭng xӱ đӝng sӁ đưӧc mô
hình hóa thành các trҥng thái khác nhau cӫa cùng mӝt lӟp.

12- TÓM TҲT Vӄ MÔ HÌNH ĐӜNG

Tҩt cҧ các hӋ thӕng đӅu có cҩu trúc tĩnh và có ӭng xӱ đӝng. Cҩu trúc có thӇ đưӧc miêu tҧ
qua các phҫn tӱ mô hình tĩnh, ví dө như lӟp, quan hӋ giӳa các lӟp, nút mҥng và thành
phҫn. Khái niӋm ӭng xӱ miêu tҧ các phҫn tӱ mô hình trong nӝi bӝ cҩu trúc sӁ tương tác
vӟi nhau dӑc theo tiӃn trình thӡi gian ra sao. Đó thưӡng là nhӳng tương tác đưӧc xác đӏnh
trưӟc và có thӇ đưӧc mô hình hóa. Mô hình hóa ӭng xӱ đӝng cӫa mӝt hӋ thӕng gӑi là mô
hình đӝng, đưӧc UML hӛ trӧ. Có tҩt cҧ bӕn loҥi biӇu đӗ khác nhau, mӛi loҥi vӟi mӝt mөc
đích khác nhau: biӇu đӗ trҥng thái , biӇu đӗ tuҫn tӵ, biӇu đӗ cӝng tác và biӇu đӗ hoҥt
đӝng.

BiӇu đӗ trҥng thái đưӧc sӱ dөng đӇ miêu tҧ lӕi ӭng xӱ cũng như các trҥng thái nӝi bӝ
trong mӝt lӟp (nó cũng có thӇ đưӧc sӱ dөng cho các hӋ thӕng con hoһc cho toàn bӝ hӋ
thӕng). Nó tұp trung vào khía cҥnh các đӕi tưӧng theo tiӃn trình thӡi gian sӁ thay đәi các
trҥng thái cӫa chúng ra sao tùy theo nhӳng sӵ kiӋn xҧy ra, lӕi ӭng xӱ cũng như các hành
đӝng đưӧc thӵc hiӋn trong các trҥng thái, và bao giӡ thì sӵ thay đәi trҥng thái xҧy ra. Mӝt
sӵ kiӋn có thӇ nә ra khi mӝt điӅu kiӋn trӣ thành đưӧc thӓa mãn, khi nhұn mӝt tín hiӋu
hoһc lӋnh gӑi thӫ tөc, hoһc là khi mӝt khoҧng thӡi gian đӏnh trưӟc qua đi.

BiӇu đӗ tuҫn tӵ đưӧc sӱ dөng đӇ miêu tҧ mӝt nhóm các đӕi tưӧng sӁ tương tác vӟi nhau
trong mӝt cҧnh kӏch riêng biӋt như thӃ nào. Nó tұp trung vào chuӛi thông điӋp, tӭc là câu
hӓi các thông điӋp đưӧc gӱi và nhұn giӳa mӝt nhóm các đӕi tưӧng như thӃ nào. BiӇu đӗ
tuҫn tӵ có hai trөc; trөc dӑc chӍ thӡi gian và trөc nҵm ngang chӍ ra các đӕi tưӧng tham gia
cҧnh kӏch. Khía cҥnh quan trӑng nhҩt cӫa mӝt biӇu đӗ tuҫn tӵ là thӡi gian.

BiӇu đӗ cӝng tác đưӧc sӱ dөng đӇ miêu tҧ các đӕi tưӧng tương tác vӟi nhau trong không
gian bӝ nhӟ (space), có nghĩa là bên cҥnh các tương tác đӝng, nó còn miêu tҧ rõ ràng các
đӕi tưӧng đưӧc nӕi kӃt vӟi nhau như thӃ nào. Trong biӇu đӗ cӝng tác không có trөc cho
thӡi gian; thay vào đó, các thông điӋp sӁ đưӧc đánh sӕ đӇ tҥo chuӛi.

BiӇu đӗ hoҥt đӝng đưӧc sӱ dөng đӇ miêu tҧ sӵ viӋc xҧy ra ra sao, công viӋc đưӧc thӵc
hiӋn như thӃ nào. BiӇu đӗ hoҥt đӝng cũng có thӇ đưӧc sӱ dөng cho các thӫ tөc, các lӟp,
các trưӡng hӧp sӱ dөng, và cũng có thӇ đưӧc sӱ dөng đӇ chӍ ra các quy trình nghiӋp vө
(workflow).

PHҪN CÂU HӒI

Hӓi: ThӃ nào là mӝt vòng lһp?

Đáp: Mӝt chuәi sӵ kiӋn có thӇ đưӧc nhҳc đi, nhҳc lҥi vô sӕ lҫn đưӧc gӑi là vòng lһp
(loop).

Hӓi: Mô hình đӝng chính là mô hình đӕi tưӧng cӝng thêm phҫn ӭng xӱ đӝng cӫa hӋ
thӕng

Đáp: Đúng

Hӓi: Các sӵ kiӋn đӝc lұp cũng có thӇ là các sӵ kiӋn song song

Đáp: Đúng

Hӓi: Mӝt đӕi tưӧng không nhҩt thiӃt phҧi có trҥng thái.

Đáp: Sai, mӑi đӕi tưӧng đӅu có trҥng thái

Hӓi: Mӝt lӟp có thӇ có trҥng thái ban đҫu và trҥng thái kӃt thúc.

Đáp: Sai, mӝt đӕi tưӧng có thӇ có trҥng thái ban đҫu và trҥng thái kӃt thúc.

Hӓi: Mӝt vòng đӡi (chu trình) vòng lһp cӫa đӕi tưӧng không có trҥng thái khӣi tҥo cũng
không có trҥng thái kӃt thúc

Đáp: Đúng, đӕi tưӧng đưӧc coi là đã luôn luôn tӗn tҥi ӣ đây và sӁ còn mãi mãi tiӃp tөc
tӗn tҥi.

›››