BÀI 1:
GII THIU UML

UML là vit tt ca Unified Modeling Language (ngôn ng mô hình hóa thng nht). ó là
mt trong các công c ni bt nht trong vic phát trin h thng ngày nay. Ti sao vy?
UML cho phép ngi xây dng h thng không ch to ra các bn thit k cha ng nhng
cái nhìn/nhn thc ca h theo mt cách d hiu và chun xác mà còn có th truyn t vi
nhau v chúng.
Ni dung chính trong bài hc:
+ Ti sao UML là cn thit
+ UML hình thành nh th nào
+ Các loi s  (diagram) khác nhau ca UML
+ Ti sao cn thit phi s dng nhiu loi diagram khác nhau
Thut ng: trong giáo trình này, h thng (system) c xem là s kt hp gia phn mm
(software) và phn cng (hardware) nh m cung cp mt gii pháp cho mt vn . Phát
trin h thng (system development) là vic to ra mt h thng cho khách hàng, ngi có
vn  cn gii quyt. Mt phân tích viên (analyst) tài liu hóa vn  ca khách hàng và
chuyn nó sang ngi phát trin (developer), lp trình viên (programmer)  xây dng
phn mm gii quyt vn  và trin khai phn mm trên phn cng máy tính.

UML hình thành nh th nào
UML là sn phm trí óc ca Grady Booch, James Rumbaugh và Ivar Jacobson. Trong
nhng n!m t" 80 n 90, m#i ngi trên làm vic ti nhng t chc khác nhau và phát minh
phng pháp phân tích thit k hng i tng riêng ca mình. Nhng phng pháp ca
h t c tính u vit hn so vi nhiu phng pháp khác. n gia nhng n!m 90, h
bt u mn ý t$ng ca nhau và dn tin n hp tác cùng nhau.
N!m 1994, Rumbaugh gia nhp Rational Rose Corporation cùng vi Booch và sau ó mt
n!m thì Jacobson c%ng cùng gia nhp.
Phiên bn kh$i u ca UML bt u c truyn bá khp ngành công nghip phn mm và
em li nhng thay i áng k. Nhiu công ty phn mm cm thy r ng UML áp ng
c mc tiêu chin lc ca h, do vy mt liên minh tm thi c dng lên. Các thành

gii thc. Class diagram tr giúp v m(t phân tích. Chúng cho phép các phân tích viên nói
chuyn vi khách hàng vi nhng ngôn t" ca h và t" ó khuyn khích khách hàng trình
bày các chi tit quan trng ca vn  h g(p phi.
S  i tng (Object diagram)
Thut ng: Mt i tng (object) là mt th hin ca mt class - mt vt c th có các giá
tr' c th cho các thuc tính và hành vi. Ví d, cái máy gi(t ca bn có nhãn hiu là
“Laundatorium”, tên i là “Washmeister”, s serial là GL57774 và sc cha là 16 kg. ó
chính là mt i tng.
Hình 1.2 cho thy UML biu din mt object. Chú ý r ng biu tng là mt hình ch nht
nh biu tng class, nhng tên gch di. Tên ca mt th hin c th n m bên trái du :,
còn tên class n m bên phi.
Hình 1.2
Biu tng object ca UML S  tình hung ng dng (Use Case Diagram)
Thut ng: Mt tình hung ng dng (use case) là mt mô t v mt hành vi ca h thng
t" quan im ngi dùng. i vi ngi phát trin h thng, ây là mt công c có giá tr':
nó là mt k* thut th-và-úng (tried-and-true technique) cho vic thu thp yêu cu h
thng t" quan im ngi dùng. iu ó rt quan trng nu mc tiêu là xây dng mt h
thng mà con ngi thc có th s dng.
Chúng ta s& tìm hiu sâu hn v use case sau này. Bây gi, hãy xem ví d hình 1.3, chúng ta
dùng máy gi(t rõ ràng  gi(t áo qun.
Hình 1.3
S  use case ca UML Thut ng: Hình nhân (stick) nh) tng trng cho ngi dùng máy gi(t c gi là tác
nhân (actor). Hình ellipse biu din use case. Chú ý r ng actor–thc th kích hot use case–
có th là con ngi ho(c mt h thng khác.

9. Nc vt thoát ra thông qua ng thoát
10. Trng quay 1 chiu nhanh dn trong vòng 5 phút
11. Trng ng"ng quay và vic gi(t hoàn tt.
Hình 1.5 biu din sequence diagram ghi nhn các tng tác gia cp nc, trng gi(t và
ng thoát (biu din b ng các hình ch nht phía trên) din ra theo thi gian. Thi gian
trong diagram trôi theo chiu t" trên xung.
Hình 1.5
S  trình t ca UML

Tr$ li ý t$ng v trng thái, chúng ta có th phân chia các bc 1 và 2 là trng thái ngâm,
các bc 3 và 4 là trng thái gi(t, các bc 5-7 là trng thái gi% và bc 8-10 là trng thái
vt.
S  hot ng (Activity Diagram)
Các hot ng xut hin trong mt use case ho(c trong mt hành vi ca object thng din
ra theo mt trình t nh 11 bc $ ví d trên. Hình 1.6 cho thy cách s  hot ng UML
biu din các bc 4-6 ca trình t.
Hình 1.6
S  hot ng ca UML
S  cng tác (Collaboration Diagram)
Các thành phn ca h thng làm vic vi nhau  hoàn thành mc tiêu (t ra và mt ngôn
ng mô hình hóa cn có cách biu din s hp tác này. S  cng tác UML c thit k

ta a chúng vào trong mt package, biu din nh hình 1.10.
Hình 1.10
Gói UML cho phép
nhóm các thành phn
ca mt diagram

Ghi chú (Note)
Thut ng: Ghi chú (note) ca UML giúp tránh mt thành phn nào ó trong diagram b'
hiu nhm.
Hình 1.11
Trong bt c diagram
nào, ta cng có th thêm
các ghi chú

Mu (Stereotype)
Thut ng: M.u (stereotype) cho phép dùng các thành phn UML s+n có  ch bin ra
nhng cái mi.

Thut ng: Khái nim giao din (interface) là mt ví d tt cho stereotype. Mt interface là
mt class ch có operation mà không có attribute. Nó chính là mt tp các hành vi mà ta
mun dùng li nhiu ln trên khp mô hình. Thay vì ngh- ra mt thành phn mi  biu
din mt interface, ta có th dùng mt biu tng class vi <<interface>> gn phía trên tên
class.
Hình 1.12
Mt stereotype cho phép
to mt thành phn mi
t nhng cái sn có.

Ti sao cn thit phi s dng nhiu loi diagram khác nhau?
Thut ng: Mt h thng có nhiu ngi quan tâm vi nhiu khía cnh khác nhau, h c

+ S tru tng hóa (abstraction)
+ S tha k (inheritance)
+ Tính a hình (polymorphism)
+ Tính óng gói (encapsulation)
+ Vic truyn thông ip (message sending)
+ Mi kt hp (association)
+ S tp hp (aggregation)
Hng i tng em li nhng i thay rt ln cho th gii phn mm. Nó c xem là
mt cách thc mi  to chng trình và có rt nhiu u im. Nó hng theo cách tip
cn da trên thành phn (component-based approach)  phát trin phn mm sao cho mt
h thng chính là mt tp các i tng (object). Sau ó, ta có th m rng h thng bng
cách tng cng kh nng cho các thành phn sn có hoc thêm các thành phn mi. cui
cùng, ta có th tái s dng các object ã to cho h thng trc ó khi xây dng mt h
thng mi, làm ct gim áng k thi gian phát trin h thng.
Hng i tng rt quan trng i vi ngành công ngh phn mm và OMG (Object
Management Group) là mt t chc ã thit lp các chu n cho vic phát trin hng i
tng. UML cho phép ta xây dng các mô hình d! dùng, d! hiu c"a các i tng sao cho
các lp trình viên có th to ra chúng trong phn mm.
Hng i tng ch# là mt tp ý tng da trên mt s nguyên lý c s. Trong bài này,
chúng ta s$ tìm hiu các nguyên lý ó.
i tng (object) có mi ni
%i tng có tính c th, nói cách khác chúng t&n ti xung quanh ta, chúng to nên th gii.
Nh ã  cp trong bài trc, phn mm ngày nay có xu hng mô ph'ng th gii hoc
mt phn nh' c"a thê 1gii, do vy các chng trình thng “bt trc” các object trong th
gii thc.
Thut ng: %i tng (object) là mt th hin (instance) c"a mt lp (class). M(i ngi
chúng ta là mt th hin c"a lp con ngi (person class). Mt object có cu trúc
(structure). Ngh)a là nó có các thuc tính (attribute, property) và hành vi (behavior). Mt
hành vi c"a object bao g&m các hành ng (operation) mà nó thc hin. Thuc tính và hành
vi kt hp thành c trng (feature) c"a object.

hình gn vi thc t
hn.
Trang 3 – Bài 2
Các khái nim
S tru tng hóa (abstraction):
Thut ng: s tru tng hóa là s n gin hóa, lc b' i các tính cht, hành ng c"a
mt thc th  ch# còn li nhng gì cn thit.
Các loi vn  khác nhau òi h'i mc  thông tin khác nhau. Hình 2.2 xây dng mt mô
hình washing machine vi nhiu thuc tính và hành vi hn so vi Hình 2.1. Làm nh th có
cn thit không?
Nu ta là thành viên trong mt nhóm vi nhim v to mt chng trình máy tính mô ph'ng
chính xác cách thc mt máy git hot ng thì vic b sung thuc tính, hành vi nh ã nói
là rt cn thit. Mt chng trình máy tính nh th (dùng cho k- s thit k máy git) phi
có " thông tin  d tính chính xác v nhng s$ di!n ra khi máy git c to ra, khi nó
vn hành thc t. %i vi các loi chng trình nh th, có th loi b' nhng thuc tính
không thc s hu dng nh thuc tính serial number.
Vi ví d khác, nu chúng ta to mt phn mm theo dõi các giao d.ch trong mt ca hàng
git "i có nhiu máy git thì vic b sung thuc tính, hành vi nh ã nói là không cn thit.
Chúng ta có th gi li thuc tính serial number cho m(i i tng máy git.

S tha k (inheritance):
Thut ng: Mt class là mt lp các object (trong phn mm, nó là mt m,u cho vic to
object mi). Ngc li, mt object là mt th hin (instance) c"a mt class và nó có tt c
các c tính mà class có. %iu này gi là s tha k (inheritance). Bt c thuc tính và

là subclass
Tính a hình (polymorphism):
Thut ng: ôi khi, mt hành vi (operation) có cùng tên trong các class khác nhau. Ví d,
“open” ca ln, “open” ca s, “open” tp chí, món quà, tài khon ngân hàng, …Trong m(i
trng hp ó, chúng ta thc hin mt hành vi khác nhau. Trong hng i tng, mt
hành vi cùng tên có th c thc hin khác nhau vi nhng class khác nhau. %iu này
c gi là tính a hình (polymorphism).
Hình 2.5
Trong tính a hình, mt
hành vi có th có cùng
tên trong nhng class
khác nhau và tin hành
khác nhau trong mi
class. Trang 5 – Bài 2
Tính óng gói (encapsulation):
Khi mt object thc thi các hành vi c"a nó, các hành vi này b. che du (xem hình 2.6). Khi
chúng ta xem tivi, chúng ta không bit và không quan tâm n các linh kin in t phc
tp phía sau màn hình tivi, c*ng nh nhiu hành vi nhm quét nh lên màn hình.
Hình 2.6
Các object óng gói
nhng gì chúng thc
hin. Ngha là, chúng
du i các hot ng
bên trong ca các hành

Trang 6 – Bài 2
Mi kt hp (association):
Thông thng, các object không c lp mà có quan h vi nhau. Ví d, khi bn bt Tivi,
theo thut ng hng i tng, bn và tivi có mt mi kt hp (association). Mi kt hp
“turn-on” là mi kt hp n hng (unidirectional), nh hình 2.8.
Ngoài ra còn có mi kt hp hai hng (bidirectional), ch+ng hn nh “is married to”.
Hình 2.8
Các object thng kt
hp vi nhau theo mt
vài cách. Khi mt ngi
bt TV, ngi ó ang
trong mi kt hp n
hng vi TV.

%ôi khi mt object có th kt hp vi mt object khác theo nhiu cách. Nu bn và &ng
nghip là bn bè thì gia 2 ngi có 2 association là “is the friend of” và “is the coworker
of”. Xem hình 2.9.
Hình 2.9
Các object ôi khi kt
hp vi nhau theo
nhiu cách.
Mt class có th kt hp cùng lúc vi nhiu class khác nhau. Mt ngi có th i trên ô tô
và ngi c*ng có th i trên xe bus. Xem hình 2.10.
Hình 2.10
Mt class có th kt hp
vi nhiu class khác.



Thut ng: Mt dng c bit c"a aggregation liên quan n quan h cht ch$ gia mt
aggregation object vi các thành phn c"a nó. Nó c gi là s cu thành (composition).
%im chính yu c"a composition là các thành phn t&n ti nh là nhng component ch#
trong composite object thôi. Ví d, 1 sáo smi (shirt) là mt composite c"a 1 thân (body), 1
c áo (collar), 2 tay áo (sleeve), mt s nút áo (button), khuyt áo (buttonhold) và c tay áo
(cuff). Nu tách kh'i shirt thì collar tr nên vô dng.
%ôi khi, mt thành phn trong mt composition không t&n ti mãi cùng composition. Ví d
lá (leaf) tên mt cây (tree) có th tàn trc khi cây cht. D) nhiên, nu ta h"y cây thì lá c*ng
cht theo (xem hình 2.12)
Khái nim aggregation và composition quan trng bi chúng phn ánh nhng s vic rt
thông thng và giúp chúng ta to ra các mô hình gn ging vi thc t.

Trang 8 – Bài 2
Hình 2.11
Trong mt composition,
mt thành phn có th
“cht” trc khi
composition “cht”.
Nu ta hy s cu thành
(composite) thì các
thành phn cng b hy
theo. Tóm lc
Hng i tng là mt tp các t tng da trên mt s nguyên lý c bn. Mt i tng
là mt th hin c"a mt lp. Mt lp loi tng quát c"a các i tng có c"ng thuc tính và
hành vi. Khi ta to mt i tng, vn  là cn xác .nh nhng thuc tính và hành vi cho
i tng.

Ni dung chính trong bài hc:
+ Trc quan hóa mt lp (class)
+ Các thuc tính (attribute)
+ Các hành vi (operation)
+ Các áp ng (responsibility) và ràng buc (constraint)

Trc quan hóa mt lp (class):
Chúng ta ã bit rng 1 hình ch nht là biu tng dùng  biu din 1 class trong UML.
Tên ca class, theo qui c, là mt t vi ký t u vit hoa, xut hin phía trên ca hình
ch nht. Nu tên class có 2 t tr lên thì kt các t sát vi nhau vi ch hoa u t (ví d
WashingMachine trong hình 3.1).
Hình 3.1
Biu tng class trong UML

Mt cu trúc UML khác, gi là gói (package), có th óng vai trò trong tên ca mt class.
Nh ã gii thiu trong các bài trc, mt package, c biu din nh mt tabbed folder,
là cách ca UML nhm t chc các thành phn ca diagram. Xem biu tng package trong
hình 3.2.
Hình 3.2
Ví d package UML

Thut ng: Nu lp WashingMachine là thành phn ca mt package có tên là Household
appliances, ta có th t tên cho class là Household appliances::WashingMachine. 2 du hai
chm tách ri tên package bên trái vi tên class bên phi. Loi tên class này gi là mt tên
ng dn (pathname). Xem hình 3.3
Hình 3.3
Mt class vi mt pathname T

UML cho phép a vào các thông tin b sung cho các thuc tính. Trong biu tng class, ta
có th c t mt kiu d liu cho tng giá tr ca thuc tính. Nhng kiu d liu có th là
string, floating-point number, integer và boolean. ! mô t kiu, dùng mt du : ng"n cách
gia tên thuc tính vi tên kiu. Ngoài ra, có th ch# ra giá tr mc nh (default value) cho
mt thuc tính. Hình 3.6 ch# ra các cách c t thuc tính.
Hình 3.6
Mt thuc tính có th
cho bit kiu ca nó
cng nh giá tr mc
nh.
T
rang
3

–
B
à
i 3

Các hành vi (operation):
Thut ng: Mt hành vi (operation) là cái mà mt class có th t làm c hoc chúng ta
(hoc class khác) có th làm cho class ó. Gi$ng nh tên thuc tính, mt tên hành vi c%ng
ch# toàn ch thng khi nó có 1 t. Nu tên hành vi gm 2 t tr lên thì m i t bt u bng
ch hoa ri kt lin vi nhau. Danh sách các operation nm bên di danh sách các
attribute.
Hình 3.7
Danh sách các hành vi

–
B
à
i 3

Hình 3.9
Trong thc t, ta không
phi luôn luôn biu
din tt c các thuc
tính và hành vi ca mt
class.
Thut ng: !ôi lúc cn biu din mt vài (không phi tt c) attribute và operation. ! làm
iu này, ta hin th nhng gì cn thit ri theo sau danh sách là du ba chm. !iu này
c gi là s t)nh lc (ellipsis) và vic b( qua mt vài attribute hoc operation c gi
là t)nh lc mt class. Hình 3.10 cho thy cách s& dng mt t)nh lc.
Hình 3.10
Mt tnh lc cho thy
các operation không
phi là tp y .
Nu danh sách các attribute và operation quá dài, ta có th dùng mt stereotype  t chc
cho danh sách cô ng h*n. Mt stereotype là cách ca UML cho phép ta m rng nó: cho
phép ta to các thành phn mi riêng bit cho vn  c th ang cn gii quyt. Nh ã 
cp trong các bài trc, ta biu din stereotype nh mt tên gi trong cp ngoc nhn gi là
guillemet. !$i vi mt danh sách thuc tính, ta có th dùng mt stereotype nh tiêu  cho
mt tp thuc tính con.
Hình 3.11
S dng mt stereotype

responsibility ca class
trong mt vùng di
danh sách các
operation.
Thut ng: ! thêm mt ràng buc (constraint), dùng du ngoc móc bao ly ni dung
ràng buc. Ni dung ràng buc trong ngoc c t các lut mà class phi tuân th. Ví d,
trong lp WashingMachine, ta mu$n c t rng sc cha ca mt máy git ch# có th là 16,
18 hoc 24 pound (có ngh)a ràng buc trên thuc tính capacity ca lp WashingMachine), ta
vit {capacity=16 or 18 or 24 lb) gn vi biu tng lp WashingMachine.
Hình 3.13
Lut trong ngoc móc
ràng buc thuc tính
capacity vi 1 trong 3
giá tr có th. Ghi chú (note):
Ngoài attribute, operation, responsibility và constraint, ta còn có th thêm thông tin vào mt
class di dng ghi chú (note) ính kèm class.
Ta thng thêm mt note cho mt attribute hay operation. Hình 3.14 biu din mt note cho
bit cách thc sinh s$ serial number cho các object trong lp WashingMachine.

T
rang
6

–

Bài tp:
1. Mô t ngn cho môn hockey:

Trang 1 – Bài 4
BÀI 4
LÀM VIC VI MI QUAN H

Ni dung chính trong bài hc:
+ Mi kt hp (association)
+ Lng s (multiplicity)
+ Các mi kt hp nh tính (qualified association)
+ Các mi kt hp phn hi (reflexive association)
+ Tha k và tng quát hóa (inheritance and generalization)
+ S ph thuc (dependency)

Mi kt hp (association):
Thut ng: Khi các lass kt ni vi nhau thì s kt ni ó c gi là mi kt hp
(association). Hãy cùng xem xét mi kt hp gia mt cu th (player) và mt i bóng
(team). Ta có th mô t c im association này bng mt câu “mt player chi trong mt
team”. Ta hình dung assocition nh mt ng ni gia 2 class vi tên ca association
(“plays on”) nm trên ng ni. Ngoài ra hng ca quan h còn c ch ra bi hình tam
giác nh. Hình 4.1 cho thy cách trc quan hóa mi kt hp “plays on” gia player và team.

Hình 4.1
Mt kt hp gia mt
player và mt team.

Khi 2 class kt hp vi nhau thì mi class s óng mt vai trò (role) trong mi kt hp ó.
Ta có th biu din các vai trò trên diagram bng cách vit chúng gn ng ni. Trong
association gia player và team, nu i bóng là chuyên nghip thì team s có vai trò

ký. Ta th hin qui t$c này trong mô hình bng cách t t “ordered” trong cp du móc (ký
hiu ràng buc) gn lp Customer, nh hình 4.5.
Hình 4.5
Có th t mt ràng buc
trên mt association.
Trong ví d này,
association tên “Serves”
b ràng buc rng
BankTeller phi phc v
Customer theo trt t xp
hàng.
Mt lo%i ràng buc khác là quan h hoc (or), ký hiu bi {or} trên mt ng &t nét ni 2
ng association. Hình 4.6 mô hình hóa vic hc sinh ph thông chn mt khóa hc v
hc thu"t hay khóa hc v thng m%i.

Trang 3 – Bài 4
Hình 4.6
Mi quan h Or gia 2
association là mt ràng
buc.

Lp kt hp (association class):
Thut ng: Mt association có th có các attribute và operation nh class. Trong trng
hp này, ta có mt lp kt hp (association class). Ta trc quan hóa mt association class
ging nh vi class thông thng và dùng mt ng &t nét ni nó vi ng association.
Mt association class c'ng có th có association vi các class khác. Hình 4.7 cho thy mt
association class, thay th cho association tên “Plays On”, kt hp vi class General
Manager.
Hình 4.7
Mt association class