Professional Documents
Culture Documents
Phan Tich HTTT Bang UML
Phan Tich HTTT Bang UML
Phn cu hi
Phn cu hi
Phn Cu hi
Phn cu hi
Chng 6: M HNH NG
1- S cn thit c m hnh ng (Dynamic model)
2- Cc thnh phn ca m hnh ng
3- u im ca m hnh ng
4- S kin v thng ip (Event & Message)
4.1- S kin (Event)
4.2- Thng ip (Message)
5- Biu tun t (Sequence diagram)
6- Biu cng tc (Collaboration Diagram)
Phn cu hi
1- DN NHP
1.1- Tnh trc quan:
Chng ta c th thy rng: "Mt s tp hp d liu phc tp nht nh khi
c trnh by bng th s truyn ti n ngi c nhiu thng tin hn
so vi cc d liu th". Vi phn mm cng vy, khi ngnh Cng nghip
ca chng ta ngy cng pht trin, cc h thng s tr nn phc tp hn.
Kh nng nm bt v kim sot s phc tp ca chng ta i km vi
kh nng trnh by h thng mt cch ton din - mt s trnh by vt ra
ngoi gii hn ca nhng dng lnh th. S thnh cng trn th trng ca
nhng ngn ng nh Visual Basic v phn giao din trc quan ca C++,
Java cho thy s trnh by trc quan mang tnh ct yu i vi qu
trnh pht trin cc h thng phc tp.
Hnh 1.3: S tng qut cc giai on ca Chu Trnh Pht Trin Phn Mm
trnh
hng
tng
(Object
Oriented
Programming - OOP):
Giai on xy dng phn mm c th c thc hin s dng k thut lp trnh
hng i tng. l phng thc thc hin thit k hng i tng qua vic
s dng mt ngn ng lp trnh c h tr cc tnh nng hng i tng. Mt vi
ngn ng hng i tng thng c nhc ti l C++ v Java. Kt qu chung
cuc ca giai on ny l mt lot cc code chy c, n ch c a vo s
dng sau khi tri qua nhiu vng quay ca nhiu bc th nghim khc nhau.
PHN CU HI
Hi: Mt s tp hp d liu phc tp nht nh khi c trnh by bng th
s truyn ti n ngi c nhiu thng tin hn so vi cc d liu th?
p: ng
Hi: M hnh gip chng ta t chc, trnh by trc quan, thu hiu v to nn
cc h thng phc tp.
p: ng
PHN CU HI
Hi: UML (Unifield Modeling Language) l g?
p: Ngn ng m hnh ha thng nht UML l mt ngn ng biu
din m hnh theo hng i tng.
Hi: im khc nhau c bn gia phng php (method) v mt ngn ng m
hnh ho (modeling language) l g?
p: im khc nhau c bn gia mt phng php v mt ngn ng
m hnh ho l ngn ng m hnh ho khng c mt tin trnh (process)
hay cc cu lnh (instruction) m t nhng cng vic ngi s dng cn
lm m n bao gm cc k hiu nhng biu tng c dng trong m
hnh v mt tp cc quy tc ch cch s dng chng.
4- BIU (DIAGRAM)
Biu l cc hnh v bao gm cc k hiu phn t m hnh ha c sp xp
minh ha mt thnh phn c th hay mt kha cnh c th ca h thng. Mt
m hnh h thng thng c nhiu loi biu , mi loi c nhiu biu khc
nhau. Mt biu l mt thnh phn ca mt hng nhn c th; v khi c v
ra, n thng thng cng c xp vo mt hng nhn. Mt khc, mt s loi
biu c th l thnh phn ca nhiu hng nhn khc nhau, ty thuc vo ni
dung ca biu .
Phn sau miu t cc khi nim cn bn nm ng sau mi loi biu . Tt c
cc chi tit v biu , ng cnh ca chng, ngha chnh xc ca chng v s
tng tc gia chng vi nhau c miu t chi tit trong cc chng sau (m
hnh i tng m hnh ng). Cc biu ly lm v d y c ly ra t
nhiu loi h thng khc nhau ch ra nt phong ph v kh nng p dng
rng khp ca ULM.
4.1- Biu Use case (Use Case Diagram):
Mt biu Use case ch ra mt s lng cc tc nhn ngoi cnh v mi lin kt
ca chng i vi Use case m h thng cung cp (nhn hnh 3.2). Mt Use case
l mt li miu t ca mt chc nng m h thng cung cp. Li miu t Use
case thng l mt vn bn ti liu, nhng km theo cng c th l mt biu
hot ng. Cc Use case c miu t duy nht theo hng nhn t ngoi vo
ca cc tc nhn (hnh vi ca h thng theo nh s mong i ca ngi s
dng), khng miu t chc nng c cung cp s hot ng ni b bn trong
h thng ra sao. Cc Use case nh ngha cc yu cu v mt chc nng i vi
h thng. Cc biu Use case s c miu t chi tit hn trong chng 4 (Use
case).
7- M RNG UML
UML c th c m rng hoc c th c sa i ph hp vi mt phng
php c bit, mt t chc c th hay mt ngi dng c th. Chng ta s bn
lun s qua n ba c ch m rng UML: khun mu (stereotype), gi tr nh
km (tagged value) v hn ch (constraint).
7.1- Khun mu (Stereotype)
C ch m rng khun mu nh ngha mt loi phn t m hnh mi da trn
mt phn t m hnh tn ti. Khun mu c th c coi l "tng t" nh
mt phn t c sn, cng thm phn quy nh ng ngha (semantic) ring
bit khng c trong phn t gc kia. Khun mu ca mt phn t c th c s
dng trong cng tnh hung nh phn t cn bn. Khun mu da trn tt c cc
loi phn t m hnh sn c - lp, nt mng, thnh phn, cng nh cc mi quan
h nh lin kt, khi qut ha, s ph thuc. Ngn ng UML c cha mt s
lng ln cc khun mu c nh ngha sn v chng c s dng sa i
cc phn t m hnh sn c, thay cho vic phi nh ngha hon ton mi. C ch
ny gip gn gi tnh n gin ca nn tng ngn ng UML.
8- M HNH HA VI UML
Khi xy dng h thng vi UML, ngi ta khng ch xy dng duy nht mt m
hnh. S c nhiu m hnh khc nhau trong nhng giai on pht trin khc nhau,
nhm n cc mc ch khc nhau. Trong giai on phn tch, mc ch ca m
hnh l nm bt tt c cc yu cu i vi h thng v m hnh ha nn tng bao
gm cc lp v cc cng tc "i thc". Trong giai on thit k, mc ch ca
m hnh l m rng m hnh phn tch, to thnh mt gii php k thut kh thi,
c ch n mi trng ca cng vic xy dng (vit code). Trong giai on xy
dng code, m hnh chnh l nhng dng code ngun tht s, c vit nn v
c dch thnh cc chng trnh. V cui cng, trong giai on trin khai, mt
li miu t s gii thch h thng cn c trin khai ra sao trong kin trc vt l.
Kh nng theo di xuyn sut nhiu giai on v nhiu m hnh khc nhau c
m bo qua cc thuc tnh hoc cc mi quan h nng cao (refinement).
Mc d l cc m hnh khc nhau, nhng chng u c xy dng nn
m rng ni dung ca cc m hnh giai on trc. Chnh v th, tt c cc m
hnh u cn phi c gn gi tt ngi ta c th d dng i ngc li, m
rng ra hay ti thit lp m hnh phn tch khi u v ri dn dn tng bc
a cc s thay i vo m hnh thit k cng nh cc m hnh xy dng (hnh
3.19).
9- CNG C (TOOL)
S dng mt ngn ng m hnh ha phc tp v rng m nh UML cn thit s
tr gip ca cng c. Mc d phc tho u tin ca mt m hnh c th c
thc hin bng bng trng cng giy v mc, nhng cng vic bo tr, ng b
ha v m bo s nht qun trong mt lot cc biu khc nhau thng li
khng th tr thnh kh thi nu khng c cng c.
Th trng cng c m hnh ha dng trong mc s khi sut mt thi gian
di k t khi xut hin tng u tin v cc chng trnh tr gip cho vic to
chng trnh. Rt nhiu cng c trong thc t ch thng minh hn cc chng
trnh v mt cht, s dng mt vi quy ch kim tra tnh nht qun hoc mt vi
kin thc v phng php v ngn ng m hnh ha. Mc d c mt vi bc
tin nht nh v nhiu cng c hm nay ti gn sng kin khi thy kia
nhiu hn (Rational Rose), nhng th trng vn cn khng t cng c cha c
gt gia, vn cn cha li hoc nhng nt k quc, k c nhng vn n gin
nh copy v dn. Nhng cng c ny cn hn ch phng din rng tt c bn
chng u c ngn ng m hnh ha ring, hay t nht th cng c nhng nh
ngha ring ca chng v ngn ng ny.
Cng vi s ra i ca ngn ng UML, cc nh cung cp cng c m hnh ha gi
y c th dnh nhiu thi gian hn cho vic nng cp cng c, bi h khng cn
phi dn tm dn sc cho vic nh ngha cc phng php mi cng nh cc
ngn ng mi.
Mt cng c m hnh ha hn i cn phi cung cp cc chc nng sau:
V biu : cn phi to iu kin d dng v ra cc biu
trong ngn ng m hnh ha. Cng c cn phi kh nng thng
minh hiu mc ch ca cc biu v bit c nhng ng
ngha cng nh cc quy tc n gin, n c th cnh bo
hoc ngn chn vic s dng khng thch hp cc phn t m hnh.
Hot ng nh mt nh kho (Repository): cng c cn phi
h tr mt nh kho trung tm tt c cc thng tin v m hnh
c lu tr trong cng mt ch. Nu v d tn ca mt lp b thay
i trong mt biu , th s thay i ny cn phi xy ra trong tt
c cc biu khc c s dng lp ny.
10- TM TT V UML
UML t chc mt m hnh thnh mt lot cc hng nhn, th hin cc kha cnh
khc nhau ca h thng. Ch khi kt hp tt c cc hng nhn li vi nhau,
ngi ta mi co c mt bc tranh trn vn v h thng. Mt hng nhn khng
phi l mt hnh v, ni dung ca n c miu t qua cc biu , y l nhng
hnh v cha ng cc phn t m hnh ha. Mt biu bnh thng ch trnh
by mt phn ni dung ca mt hng nhn, v mt hng nhn c nh ngha
vi rt nhiu biu . Mt biu cha cc phn t m hnh, v d nh lp, i
tng, nt mng, thnh phn v nhng mi quan h nh ni kt, khi qut ha,
ph thuc. Cc phn t ny c ngha (semantic) v cc k hiu hnh hc.
Cc loi biu trong UML l: biu lp, biu i tng, biu Use case,
biu trng thi, biu trnh t, biu cng tc, biu hnh ng, biu
thnh phn v biu trin khai. Mc ch ca cc loi biu cng nh quy tc
v chng s c miu t chi tit trong chng sau.
UML c mt s c ch chung b sung thng tin khng th c th hin trong
qu trnh v biu . Nhng thng tin ny bao gm v d nhng thnh phn
trang tr, cc li ghi ch c th cha bt k loi thng tin no cng nh cc thuc
tnh c t. Ngoi ra cn c cc c ch m rng, bao gm gi tr nh km, hn
ch i vi phn t, v khun mu, nh ngha mt loi phn t m hnh mi da
trn mt phn t sn c.
Mt h thng s c miu t trong nhiu loi m hnh khc nhau, mi loi m
hnh nhm mt mc ch khc nhau. M hnh phn tch miu t nhng yu cu
v mt chc nng v m hnh ha cc lp ngoi i thc. M hnh thit k
chuyn ti kt qu phn tch thnh mt gii php k thut, theo khi nim ca
mt thit k phn mm hot ng hon chnh. M hnh xy dng code th hin
h thng qua vic tho chng cho n trong mt ngn ng lp trnh hng i
tng. V cui cng, m hnh trin khai nh v chng trnh va c to nn
trong mt kin trc vt l bao gm cc my tnh v cc trang thit b. Cng vic
c lm theo nhiu vng lp khc nhau ch khng phi ch l mt chui thc
hin mt ln.
s dng UML mt cch nghim chnh cho mt d n c tht ngoi i, bn
cn cng c. Mt cng c tn tin c kh nng cho ngi dng v biu , tr tt
c cc thng tin vo mt kho chung, cho php d dng dch chuyn gia cc
hng nhn v biu khc nhau trong m hnh, to bo co v ti liu, to
PHN CU HI
Hi: UML c cng c no gip nm bt cc yu cu ca khch hng (ngi s
dng)?
p: Use Case
Hi: Mt biu trong UML c bao cha cc hng nhn khc nhau.
p: Sai, mt hng nhn bao gm mt loi cc biu khc nhau
Hi: Hy lit k cc thnh phn ch yu ca ngn ng UML
p: Hng nhn( View), Biu (Diagram), Phn t m hnh, C ch
chung.
Hi: UML c cng c no phc v cho giai on th nghim n v (Unit
Testing)?
p: Biu lp v c t lp
Hi: UML c cng c no phc v cho giai on th nghim h thng (System
Testing)?
p: Use case Diagram
Hi: UML to nn tng cho vic giao tip gia khch hng, nh phn tch, nh
thit k v lp trnh vin.
p: ng
2- MT S V D USE CASE
Trong v d nh bng l trn, mt s nhng Use Case d thy nht l:
Mt khch hng m mt ti khon mi.
Phng u t tnh ton tin li cho cc ti khon u t.
Mt chng trnh u t mi c a vo p dng.
9- TH USE CASE
Mt trong cc mc ch chnh ca Use Case l th nghim (testing). C hai loi
th nghim khc nhau c thc hin y: kim tra (verification) v ph
duyt xc nhn (validation). Kim tra m bo l h thng c pht trin
ng n v ph hp vi cc c t c to ra. Ph duyt xc nhn m bo
rng h thng s c pht trin chnh l th m khch hng hoc ngi s
dng cui tht s cn n.
Cng vic ph duyt xc nhn c thc hin k trc giai on pht trin.
Ngay khi mt m hnh Use Case c hon tt (hay thm ch c th ang trong
giai on pht trin), m hnh ny phi c trnh by v tho lun vi khch
hng cng nh ngi s dng. H cn phi xc nhn rng m hnh ny l ng
n, hon tt v tha mn s mong i ca h i vi h thng; c bit l
phng cch m h thng cung cp chc nng cho h. lm iu , nh pht
trin phi m bo rng khch hng tht s hiu c m hnh v ngha ca
chng, trnh trng hp to ra nhng th khng th chp nhn ni. Trong
giai on ny, r rng l cc cu hi v cc tng s xut hin v chng cn
phi c b sung thm vo m hnh Use Case trc khi n giai on ph duyt
chung cuc. Giai on xc nhn cng c th c thc hin trong thi k th
nghim h thng, nhng im yu ca phng thc lm ny l nu h thng
khng tha mn nhng yu cu c th ca ngi s dng th ton b d n rt
c th s phi lm li t u.
PHN CU HI
Hi: Mt tc nhn (Actor) trong mt Use Case lun l mt con ngi
p: Sai, tc nhn l mt ngi hoc mt vt no tng tc vi h
thng.
Hi: H thng khc cng c th ng vai tr tc nhn trong mt Use Case?
p: ng
Hi: Mi h thng ch c mt Use Case?
p: Sai
Hi: Biu Use case m t chc nng h thng?
p: ng
2.2- Cc lp ng c vin:
Theo cc bc k trn trong phn u giai on phn tch, ta miu t c
mt s lp khc nhau. Nhng lp ny c gi l cc lp ng c vin, chng th
hin nhng lp c kh nng tn ti trong mt h thng cho trc. Mc d vy,
Biu phn 5.15 th hin rng gia hai lp c lin h, nhng khng h c
thng tin v s lng cc i tng trong quan h. Ta khng th bit mt khch
hng c th c bao nhiu ti khon v mt ti khon c th l ca chung cho bao
nhiu khch hng. Trong UML, loi thng tin nh th c gi l s lng phn
t (Cardinality) trong quan h.
5.3- S lng (Cardinality) trong lin h:
Hnh trn l v d cho mt biu lp tiu biu. Biu gii thch rng b phn
dch v ti khon tit kim ca mt nh bng c th c nhiu ti khon tit kim
nhng tt c nhng ti khon ny u thuc v b phn . Mt ti khon tit
kim v phn n li c th c nhiu ti liu, nhng nhng ti liu ny ch thuc
v mt ti khon tit kim m thi. Mt ti khon tit kim c th thuc v t 1
cho ti nhiu nht l 3 khch hng. Mi khch hng c th c nhiu hn mt ti
khon.
5.4- Pht hin lin h:
Thng s c nhiu mi lin h gia cc i tng trong mt h thng. Quyt
nh lin h no cn phi c thc thi l cng vic thc giai on thit k. C
th tm cc mi lin h qua vic nghin cu cc li pht biu vn , cc yu cu.
Ging nh danh t gip chng ta tm lp, cc ng t y s gip ta tm ra
cc mi quan h.
Mt vi li mch bo khi tm lin h:
V tr v mt vt l hoc s thay th, i din: Mi cm ng
t xc nh hay biu l mt v tr u l mt biu hin chc
chn cho lin h. V d: ti a im, ngi trong,
S bao cha: Cm ng t biu l s bao cha, v d nh: l
thnh phn ca....
Giao tip: C nhiu cm ng t biu l s giao tip, v d
truyn thng ip, ni chuyn vi,
Quyn s hu: V d: thuc v, ca,
6- Quan h kt tp (Aggregation)
6.1- Khi nim kt tp:
Kt tp l mt trng hp c bit ca lin h. Kt tp biu th rng quan h
gia cc lp da trn nn tng ca nguyn tc "mt tng th c to thnh bi
cc b phn". N c s dng khi chng ta mun to nn mt thc th mi
bng cch tp hp cc thc th tn ti vi nhau. Mt v d tiu biu ca kt tp
l chic xe t gm c bn bnh xe, mt ng c, mt khung gm, mt hp s,
v.v....
Qu trnh ghp cc b phn li vi nhau to nn thc th cn thit c gi l
s kt tp. Trong qu trnh tm lp, kt tp s c ch ti khi gp cc loi
ng t c to bi", "gm c", . Quan h kt tp khng c tn ring. Tn
ngm cha trong n l "bao gm cc thnh phn".
6.2- K hiu kt tp:
K hiu UML cho kt tp l ng thng vi hnh thoi (diamond) t st lp biu
th s kt tp (tng th).
Mt lp ti khon c to bi cc lp chi tit v khch hng, cc lnh giao dch
i vi ti khon cng nh cc quy nh ca nh bng.
Quan h trn c th c trnh by nh sau:
Trong hnh trn, ti khon l khi nim chung ca cc loi ti khon khc nhau
v cha nhng c t cn thit cho tt c cc loi ti khon. V d nh n c th
cha s ti khon v tn ch ti khon. Ta c th c hai loi ti khon c bit
suy ra t dng ti khon chung ny, mt loi mang tnh k hn v mt loi mang
tnh giao dch. Yu t chia cch hai lp ny vi nhau l cc quy nh chuyn
ngnh hay ng hn l phng thc hot ng ca hai loi ti khon.
Trong hnh trn, yu t phn bit trong lp ti khon l "loi ti khon". Chng
ta gi thit rng ch c hai loi ti khon, mt mang tnh k hn v mt mang
tnh giao dch. Theo , ta phi to ra hai lp con, mt cho cc ti khon mang
tnh k hn v mt cho cc ti khon mang tnh giao dch.
Trong m hnh i tng, khng nht thit phi nu bt yu t phn bit. Yu t
phn bit lun c mt trong mt cu trc phn cp lp cha/ con, d c c
nhn mnh trong m hnh i tng hay khng. Mc du vy, m bo cho
mt m hnh c nh ngha r rng, trnh by yu t phn bit vn lun l
cng vic nn thc hin.
7.2.1- Lp tru tng
Quan st cu trc trong hnh trn, ta thy lp ti khon s khng bao gi c
thc th ha, c ngha l h thng s khng bao gi to ra cc i tng thuc
lp ny. Nguyn nhn l v lp ti khon mang tnh khi qut cao n mc
vic khi to lp ny s khng c mt ngha no ng k. Lp ti khon mc
d vy vn ng mt vai tr quan trng trong vic khi qut ha cc thuc tnh
s c cn n trong cc lp dn xut t n. Nhng loi lp nh th c dng
cung cp mt cy cu trc lp v khng c s tn ti y ngha trong
mt m hnh tht s ngoi i, chng c gi l lp tru trng (abstract
class).
7.2.2- To lp tru tng
Cc lp tru trng l kt qu ca qu trnh khi qut ha. Hy quan st v d
cu trc lp sau y. Lp ti khon ng u cy cu trc v c gi l lp cn
bn. Lp cn bn ca mt cy cu trc cha nhng thuc tnh c khi qut
ha v c th c p dng cho mi lp dn xut t n. Trong qu trnh khi
qut ha, cc thuc tnh c dng chung trong cc lp chuyn bit c a ln
lp cha. Lp cha v cui c to bi cc thuc tnh chung ca tt c cc lp dn
xut t n. Nhng lp cha dng nh vy trong rt nhiu trng hp s mang tnh
khi qut tuyt i v s khng theo ui mc ch khi to, chng c li ng x
ging nh mt thng cha (container) cho tt c cc thuc tnh chung ca cc
lp dn xut. Nhng lp nh th trong trng hp chung thng l kt qu nh
Phn cu hi
Chng 6: M HNH NG
3- U IM CA M HNH NG:
Bt c khi no c nhng ng x ng cn phi c nghin cu hoc th hin,
chng ta s phi dng n m hnh ng.
M hnh ng ng mt vai tr v cng quan trng trong nhng trng hp nh:
Cc h thng mang tnh tng tc cao
H thng c s dng cc trang thit b ngoi vi c th gi nn cc
ng x ca h thng.
M hnh ng khng t ra tht s hu hiu trong trng hp ca cc h thng
tnh. V d mt h thng ch nhm mc ch nhp d liu lu tr vo mt
ngn hng d liu.
Mt m hnh ng tp trung vo cc chui tng tc (biu cng tc) v vo
yu t thi gian ca cc s kin (biu tun t). Mt m hnh ng c th c
s dng cho mc ch th hin r rng theo thi gian hot ng ca h thng
nu trong thi gian ny c nhng i tng:
c to ra
B xa i
c lu tr
B hy
Hy quan st trng hp rt tin mt v tng tc ca khch hng i vi nh
bng:
Khch hng in tt c cc chi tit cn thit vo giy yu cu rt
tin mt.
Khch hng a giy yu cu cho mt nhn vin pht th xp
hng.
Nhn vin pht th ghi s ca giy yu cu rt tin vo danh sch.
ng tc ghi s ca giy yu cu rt tin c thc hin tun t,
tng ng vi nhng s th tun t c pht ra.
Mt tm th xp hng (token) c trao cho khch hng.
Khch hng i vo hng xp, ch nhn vin bn casse gi ng s
th ca mnh.
Song song vi qu trnh ch ca khch hng, giy yu cu rt tin
ca anh ta tri qua nhiu giai on trong ni b nh bng.
Hnh 6.9- Bin i trng thi khng c s kin t ngoi. S thay i trng thi
xy ra khi cc hot ng trong mi trng thi c thc hin xong.
7.3- Nhn bit trng thi v s kin
Qu trnh pht hin s kin v trng thi v mt bn cht bao gm vic hi mt
s cc cu hi thch hp:
Mt i tng c th c nhng trng thi no?: Hy lit k ra tt c
nhng trng thi m mt i tng c th c trong vng i ca n.
Nhng s kin no c th xy ra?: Bi s kin gy ra vic thay i
trng thi nn nhn ra cc s kin l mt bc quan trng nhn
din trng thi.
Trng thi mi s l g?: Sau khi nhn din s kin, hy xc nh
trng thi khi s kin ny xy ra v trng thi sau khi s kin ny
xy ra.
C nhng th tc no s c thc thi?: Hy n cc th tc
nh hng n trng thi ca mt i tng.
Chui tng tc gia cc i tng l g?: Tng tc gia cc i
tng cng c th nh hng n trng thi ca i tng.
Qui nh no s c p dng cho cc phn ng ca cc i tng
vi nhau?: Cc qui nh kim ta phn ng i vi mt s kin s
xc nh r hn cc trng thi.
Nhng s kin v s chuyn ti no l khng th xy ra?: Nhiu
khi c mt s s kin hoc s thay i trng thi khng th xy ra.
V d nh bn mt chic t c bn ri.
Ci g khin cho mt i tng c to ra?: i tng c to ra
tr li cho mt s kin. V d nh mt sinh vin ghi danh cho
mt kha hc.
Hnh
6.12-
Khi
mt
ngi
gi
tc
PrintAllCustomer
(trong
lp
12- TM TT V M HNH NG
Tt c cc h thng u c cu trc tnh v c ng x ng. Cu trc c th c
miu t qua cc phn t m hnh tnh, v d nh lp, quan h gia cc lp, nt
mng v thnh phn. Khi nim ng x miu t cc phn t m hnh trong ni
b cu trc s tng tc vi nhau dc theo tin trnh thi gian ra sao. thng
l nhng tng tc c xc nh trc v c th c m hnh ha. M hnh ha
ng x ng ca mt h thng gi l m hnh ng, c UML h tr. C tt c
PHN CU HI
Hi: Th no l mt vng lp?
p: Mt chui s kin c th c nhc i, nhc li v s ln c gi l
vng lp (loop).
Hi: M hnh ng chnh l m hnh i tng cng thm phn ng x ng
ca h thng
p: ng
Hi: Cc s kin c lp cng c th l cc s kin song song
p: ng
tm
ICONIX is
Introduction
pleased
to
to offer
the
Unified
a one-day
Modeling
course titled
Language
"An
(UML)".
associated
Unified
Process.
the
course
instructor's
is
own
presented
UML
in
material.
six
parts:
Behavioral
(Dynamic)
Diagrams
Unified
Process-related
extensions
associated
with
with
visual
modeling
tools.
Monica,
CA
90405/Tel
(310)458-0092/Fax
(310)396-3454/email: marketing@iconixsw.com
and
component
reduce
cost
technology,
and
visual
time-to-market.
programming,
These
patterns
techniques
and
include
frameworks.
Importance
Of
Modeling
of
the
UML
Support
higher-level
development
concepts
such
as
collaborations,
of
the
OMG-UML
that is
use-case
driven, architecture
and
the
UML
incremental.
Outside
The
Scope
of
While the UML aims to simplify and standardize modeling it is not an all
encompassing language. This gives it the flexibility to be used to design a variety
of systems over a wide spectrum of industries. Some major areas outside of the
scope of the UML include:
Programming Languages
The UML, a visual modeling language, is not intended to be a visual
programming language, in the sense of having all the necessary visual and
semantic support to replace programming languages. The UML is a language for
visualizing, specifying, constructing, and documenting the artifacts of a softwareintensive system, but it does draw the line as you move toward code. The UML
does have a tight mapping to a family of OO languages, so that you can get the
best of both worlds
Tools
Standardizing a language is necessarily the foundation for tools and process. The
primary goal of the OMG RFP was to enable tool interoperability. However, tools
and their interoperability are very dependent on a solid semantic and notation
definition, such as the UML provides. The UML defines a semantic metamodel,
not a tool interface, storage, or run-time model, although these should be fairly
close to one another.
Process
of
UML
and
How
It
Became
An
OMG
Standard
Identifiable object-oriented modeling languages began to appear between mid1970 and the late 1980s as various methodologists experimented with different
approaches to object-oriented analysis and design. The number of identified
modeling languages increased from less than 10 to more than 50 during the
period between 1989-1994. Many users of OO methods had trouble finding
complete satisfaction in any one modeling language, fueling the "method wars."
By the mid-1990s, new iterations of these methods began to appear and these
methods began to incorporate each others techniques, and a few clearly
prominent methods emerged.
The development of UML began in late 1994 when Grady Booch and Jim
Rumbaugh of Rational Software Corporation began their work on unifying the
Booch and OMT (Object Modeling Technique) methods. In the Fall of 1995, Ivar
Jacobson and his Objectory company joined Rational and this unification effort,
merging in the OOSE (Object-Oriented Software Engineering) method.
As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch,
Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling
language for three reasons. First, these methods were already evolving toward
each other independently. It made sense to continue that evolution together
rather than apart, eliminating the potential for any unnecessary and gratuitous
differences that would further confuse users. Second, by unifying the semantics
and notation, they could bring some stability to the object-oriented marketplace,
allowing projects to settle on one mature modeling language and letting tool
builders focus on delivering more useful features. Third, they expected that their
collaboration would yield improvements in all three earlier methods, helping
them to capture lessons learned and to address problems that none of their
methods previously handled well.
As they began their unification, they established four goals to focus their efforts:
Enable the modeling of systems (and not just software) using objectoriented concepts.
The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML
0.9 and 0.91 documents in June and October of 1996. During 1996, the UML
authors invited and received feedback from the general community. They
incorporated this feedback, but it was clear that additional focused attention was
still required.
While Rational was bringing UML together, efforts were being made on achieving
the broader goal of an industry standard modeling language. In early 1995, Ivar
Jacobson (then Chief Technology Officer of Objectory) and Richard Soley (then
Chief
Technology
Officer
of
OMG)
decided
to
push
harder
to
achieve
Present
and
Future
The UML is nonproprietary and open to all. It addresses the needs of user and
scientific communities, as established by experience with the underlying methods
on which it is based. Many methodologists, organizations, and tool vendors have
committed to use it. Since the UML builds upon similar semantics and notation
Meta
Object
Facility
The main purpose of the OMG MOF is to provide a set of CORBA interfaces that
can be used to define and manipulate a set of interoperable metamodels. The
MOF is a key building block in the construction of CORBA-based distributed
development environments.
The Meta Object Facility represents the integration of work currently underway
by the OMG members in the areas of object repositories, object modeling tools,
and meta data management in distributed object environments. The MOF
specification uses the Unified Modeling Language (UML) notation. The facility
interface
and
semantics
incorporate
some
of
the
advanced
meta
data
specification
enhances
meta
data
management
and
meta
data
Copyright
1997-2001
All
For
Object
Management
Group,
Rights
questions
about
the
Inc.
Reserved.
WEBSITE,
please
contact
webeditor@omg.org
For
TECHNICAL
webtech@omg.org
questions,
please
contact
Introduction
You're proficient in C++, Java or another OO language, you're designing class
hierarchies, using inheritance, and manipulating complex pointer relationships to
store the necessary links between your classes. You've probably drawn blobs
(representing classes in some way) on whiteboards, with connecting lines to
indicate the relationships between classes (inheritance or other). Perhaps you're
feeling the need for a more formal notation to express your designs - using
something that is language independent, and that enables you to consider the
important aspects of design leaving the detail for later.
Alternatively, perhaps you're a Project Manager, looking to formalise the OO
design process a little to make sure you're getting the most from your move to
C++/Java or a similar language.
In this paper, I take a look at the UML (Unified Modelling Language) notation for
Object Oriented Analysis and Design - the emerging standard designed by Booch,
Rumbaugh and Jacobson, each of whom previously had their own notations
published independently.
The starting point is Object Modelling, a technique that enables you to focus on
class structure, inheritance, etc., whilst avoiding language specifics such as
pointer dereferencing.
Object Modelling In UML
Head-Office
class
(containing
"bankName"
and
"address"
fields,
Implicit in the decision to use inheritance and redefine methods in subclasses is the fact that the system, when implemented, will use the
polymorphism features of the target language (C++, Java...) to enable all
Accounts to be treated in a single coherent fashion, regardless of the
particular charges mechanism involved. This is of course one of the
reasons we use an object-oriented development language in the first place.
Each Account "belongs-to" exactly one owner - the Customer class on the
diagram. Customers, on the other hand, may have many Accounts.
It's worth noting here that because an Account may "belong-to" a Customer,
both CurrentAccounts and SavingsAccounts may also belong to a Customer. In
other words, the "belongs-to" relationship between Accounts and Customers is
inherited by the CurrentAccount and SavingsAccount classes. This fact simplifies
the diagram considerably, removing the need for these relationships to be noted
explicitly. This simplification will also be apparent in our final implementation of
the system.
Finally, you can see that there are two relationships shown between the
Account and the Transaction classes. This is because, in our banking
system, each individual transaction (credit, debit, etc.) must have two
associated accounts - the Account the money is "debit(ed)-from", and the
C++!):
Object
Models
OK, that's fine, you may say, but how do Object Models relate to C++ or Java,
exactly? Lets take a look at a sub-set of our previous example
class
Account
/*...
data...
*/
public:
virtual
void
CalcCharges();
void
PrintStatement();
};
class
SavingsAccount:
/*
public
any
Account
additional
data
{
*/
public:
virtual
/*
void
use
CalcCharges();
the
base
/*
class
re-definition
PrintStatement
method
*/
*/
};
class
SavingsAccount:
/*
public
any
Account
additional
data
{
*/
public:
virtual
/*
void
use
CalcCharges();
the
base
/*
another
class
re-definition
*/
method
*/
PrintStatement
};
Transaction
value;
/*
date;
/*
stored
date
in
pence
of
transaction
*/
*/
public:
/*
Access
and
Date(date_t);
functions
/*
date_t
set
Date();
Value(long);
long
Update
*/
/*
/*
Value();
get*/
set
/*
*/
*/
get
*/
};
TransactionList
TransactionList
Transaction
next;
data;
/*
ptr
/*
to
store
next
the
element
*/
here
*/
transaction
public:
void
Data
(Transaction
Transaction
void
*
NextItem(TransactionList
TransactionList
*);
/*
Data();
set
/*
*);
/*
NextItem();
set
/*
*/
get
*/
next
get
next
ptr
*/
ptr
*/
};
although
this
may
not
the
best
choice.
Amending our Account class definition to use this class gives us the following
new definition:
class
Account
TransactionList
TransactionList
debitedFrom;
/*
creditedTo;
debited
/*
credited
from
to
Tx
Tx
list*/
list
*/
public:
virtual
void
CalcCharges();
void PrintStatement();
/*
some
new
methods
DebitTx
(Transaction
*);
CreditTx
(Transaction
*);
Transaction*
NextDebitTx();
Transaction*
NextCreditTx();
to
manipulate
the
Add
Add
/*
/*
/*
Transaction
debit
credit
Iterator:get
/*
Iterator:get
list
Tx
*/
*/
Tx
*/
debit
Tx
*/
cred
Tx
*/
};
/*
sample
method
Account::DebitTx(Transaction
/*
add
new
list
TransactionList
implementation
contained
debitedFrom
at
theTx)
the
tmpTxLp
=
*/
beginning
of
the
list
*/
debitedFrom;
new
TransactionList;
debitedFrom->NextItem(tmpTxLp);
/*
new
put
the
transaction
data
into
the
list
*/
debitedFrom->Data(theTx);
};
Account
class
interface
has
limited
the
impact
of
the
relationship
Although
our
Object
Model
provided
starting
point
for
our
implementation, it was not complete, for example new methods have been
added to the Account class.
From these points we can see that we need to consider the wider requirements
of our system before we can come up with the right implementation of our
"debit-from"
relationship
(not
to
mention
the
many
other
classes
and
Cases
In
UML
Use Cases are used to document system requirements. They provide a useful
technique which, in conjunction with Object Modelling, help us to clarify exactly
what the system is supposed to do. Let's take a look at the requirements for our
banking system
:
Figure 9 - Use Cases for Banking System
The required business functions - that is, the type of operation you'd
expect to find on the menu of the application once it had been developed.
In this case we have identified the following functions:
Bank managers need to periodically print out a report detailing all the
customers who are overdrawn; these appear on the branch printer
Data processing staff use the system to do basic data entry (transactions
on accounts)
There are four distinct types of user of the system: Bank Managers; Clerks;
Data Processing Assistants; and Customers. Each type of user typically has
their own particular set of requirements for a system: hence identify user
types assists in identifying all the required system functions.
The Use Case diagramming technique allows us to make a first cut at defining
the system requirements, and will help us in presenting these requirements back
to the users of the system. It also partitions the system into single atomic
business functions, which may be used as a basis for costing the system, or for
planning a phased system delivery. In this case each successive phase would
deliver
further
batches
of
Use
Cases.
Further information is still required, however, to tie down the detail of what each
businese function does. Use Case Detail provides this information (explanatory
notes
are
shown
in
bold):
By:
Bank Manager
Inputs:
Details what information flows from the user to the system for this particular Use
Case.
theBranchSortCode - The Sort Code of the branch for which the report is
required.
theOverdraftPeriod - how long an Account has been overdrawn before it is forms
case
the
printer!
overdraft;
period
overdrawn
(days);
Printed for all accounts that have been overdrawn for a period greater than
theOverdraftPeriod, and which have not already been reported (on another
report) in the last 30 days.
Pre-Conditions:
What validity checks or constraints apply on the inputs (or the internal system as
a
whole,
in
some
cases).
the
reportedOnDate
field
of
overdrawn
accounts.
As work progresses on the Use Cases, the requirements of the system become
clearer enabling the Object Model to be updated in parallel, helping us make sure
our model (and the subsequent implementation in the chosen language) contains
all
the
necessary
classes
and
class
inter-links.
Whilst we're nearer to resolving some of the issues identified at the end of the
discussion of implementing Object Models, a number are still outstanding: we
still can't be sure in what direction the relationships must be implemented,
whether we have identified all the methods; or what implementation of the links
will best suit the use to which they'll be put. To sort out the remaining issues
we'll need to look in more detail exactly how each Use Case will be implemented,
using Sequence Diagrams.
Sequence
Diagrams
Sequence diagrams, performed on a per Use Case basis, examine the flow of
method
system.
call
calls
within
The Head-Office object (there is only one of them) has methods which
correspond to each Use Case - in this case an OverdrawnReport method
(this is a convenience for brevity, normally there would be a single
"InitialObject" which the system would know about, and which would
provide the entry point into the run-time model for all code).
The Branch object in turn passes the request on down to each Account it
holds (using the Account's OverdrawnReport method)!
checks if it has been overdrawn for greater than the period specified by
theOverdraftPeriod,
which
is
passed
as
an
argument
to
the
if appropriate it then calls one of its own methods to print the report
(detail not shown), and resets its lastReportDate attribute, again using its
own method.
We have added directionality to many of the links (e.g. see the arrowhead on the Branch to Account link).
Of course, we've only looked at one Use Case, so its likely the model will change
further as more sequence diagrams are developed.
The
Overall
Process
From the above discussion we can see that Use Cases and Sequence Diagrams
both add to integrity and completeness of our Object Model, and that a good
Object Model provides a firm foundation for a good design, and hence a good
implementation
system.
of
the
User Interface Design is the first step that focuses on the Technical
Domain aspects of the problem, and involves taking the Use Cases as
The separation between Problem Domain and the Technical Domain aspects of
the system is useful in large projects, allowing the focus of those working on the
project to be clearly divided, as summarised in figure 13:
may
be
merged,
if
desired.
company
specialising
in
OO
related
methods,
languages
and
technologies. For further information on OOA/D using UML, Java, C++, Design
Patterns or related topics please contact us
Copyright
This material remains the copyright of Ratio Group Ltd. Licence is granted for the
use of this material for personal development purposes only.