Professional Documents
Culture Documents
Phn cu hi
1- Gii thiu UML: 1.1- M hnh ha h thng phn mm. 1.2- Trc khi UML ra i. 1.3- S ra i ca UML.
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) 7- Biu trng thi (State 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.
2.2- Chu Trnh Pht Trin Phn Mm (Software Development Life Cycle):
V pht trin phn mm l mt bi ton kh, nn c l trc ht ta cn im qua mt s cc cng vic cn bn ca qu trnh ny. Thng ngi ta hay tp hp chng theo tin trnh thi gian mt cch tng i, xoay quanh chu trnh ca mt phn mm, dn ti kt qa khi nim Chu Trnh Pht Trin Phn Mm (Software Development Life Cycle - SDLC) nh sau: Chu Trnh Pht Trin Phn Mm l mt chui cc hot ng ca nh phn tch (Analyst), nh thit k (Designer), ngi pht trin (Developer) v ngi dng (User) pht trin v thc hin mt h thng thng tin. Nhng hot ng ny c thc hin trong nhiu giai an khc nhau. Nh phn tch (Analyst): l ngi nghin cu yu cu ca khch hng/ngi dng nh ngha mt phm vi bi ton, nhn dng nhu cu ca mt t chc, xc nh xem nhn lc, phng php v cng ngh my tnh c th lm sao ci thin mt cch tt nht cng tc ca t chc ny. Nh thit k (Designer): thit k h thng theo hng cu trc ca database, screens, forms v reports quyt nh cc yu cu v phn cng v phn mm cho h thng cn c pht trin. Chuyn gia lnh vc (Domain Experts): l nhng ngi hiu thc cht vn cng tt c nhng s phc tp ca h thng cn tin hc ho. H khng nht thit phi l nh lp trnh, nhng h c th gip nh lp trnh hiu yu cu t ra i vi h thng cn pht trin. Qu trnh pht trin phn mm s c rt nhiu thun li nu i ng lm phn mm c c s tr gip ca h. Lp trnh vin (Programmer): l nhng ngi da trn cc phn tch v thit k vit chng trnh (coding) cho h thng bng ngn ng lp trnh c thng nht.
Hnh 1.1: Nhn vn t ca ngi bnh thng Chuyn gia lnh vc s gip nh phn tch "trnh by li" vn nh sau:
Hnh 1.2: Nhn vn t ca chuyn gia phn tch Chnh v s tr gip ca chuyn gia lnh vc c th ng vai tr rt quan trng nn trong nhng giai on u ca qu trnh pht trin phn mm, kt qu phn tch nn c th hin sao cho d hiu i vi cc chuyn gia lnh vc. y cng l mt trong rt nhiu l do khin cho phng php hng i tng c nhiu ngi hng ng.
Hnh 1.3: S tng qut cc giai on ca Chu Trnh Pht Trin Phn Mm
3- Phng php hng chc nng v phng php hng i tng: 3.1- Phng php hng chc nng:
y l li tip cn truyn thng ca ngnh Cng ngh phn mm. Theo li tip cn ny, chng ta quan tm ch yu ti nhng thng tin m h thng s gi gn. Chng ta hi ngi dng xem h s cn nhng thng tin no, ri chng ta thit k ngn hng d liu cha nhng thng tin , cung cp Forms nhp thng tin v in bo co trnh by cc thng tin. Ni mt cch khc, chng ta tp trung vo thng tin v khng my n nhng g c th xy ra vi nhng h thng v cch hot ng (ng x) ca h thng l ra sao. y l li tim cn xoay quanh d liu v c p dng to nn hng ngn h thng trong sut nhiu nm tri. Li tip cn xoay quanh d liu l phng php tt cho vic thit k ngn hng d liu v nm bt thng tin, nhng nu p dng cho vic thit k ng dng li c th khin pht sinh nhiu kh khn. Mt trong nhng thch thc ln l yu cu i vi cc h thng thng xuyn thay i. Mt h thng xoay quanh d liu c th d dng x l vic thay i ngn hng
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 Hi: u im ln nht ca m hnh hng i tng l tnh ti s dng (Reusable)? 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.
Hnh 3.1- Cc View trong UML Mi mt hng nhn c miu t trong mt lot cc biu , cha ng cc thng tin nu bt kha cnh c bit ca h thng. Trong thc t khi phn tch v thit k rt d xy ra s trng lp thng tin, cho nn mt biu trn tht t c th l thnh phn ca nhiu hng nhn khc nhau. Khi nhn h thng t nhiu hng nhn khc nhau, ti mt thi im c th ngi ta ch tp trung vo mt kha cnh ca h thng. Mt biu trong mt hng nhn c th no cn phi n gin to iu kin giao tip d dng, dnh lin vi cc biu khc cng nh cc hng nhn khc, lm sao cho bc tranh ton cnh ca h thng c miu t bng s kt hp tt c cc thng tin t tt c cc hng nhn. Mt biu cha cc k hiu hnh hc m t cc phn t m hnh ca h thng. UML c tt c cc hng nhn sau: Hng nhn Use case (use case view): y l hng nhn ch ra kha cnh chc nng ca mt h thng, nhn t hng tc nhn bn ngoi. Hng nhn logic (logical view): ch ra chc nng s c thit k bn trong h thng nh th no, qua cc khi nim v cu trc tnh cng nh ng x ng ca h thng. Hng nhn thnh phn (component view): ch ra kha cnh t chc ca cc thnh phn code. Hng nhn song song (concurrency view): ch ra s tn ti song song/ trng hp trong h thng, hng n vn giao tip v ng b ha trong h thng. Hng nhn trin khai (deployment view): ch ra kha cnh trin khai h thng vo cc kin trc vt l (cc my tnh hay trang thit b c coi l trm cng tc).
4- BIU (DIAGRAM)
Hnh 3.2- Biu use case ca mt cng ty bo him 4.2- Biu lp (Class Diagram):
Hnh 3.3 - Biu lp cho mt giao dch Ti chnh 4.3- Biu i tng (Object Diagram): Mt biu i tng l mt phin bn ca biu lp v thng cng s dng cc k hiu nh biu lp. S khc bit gia hai loi biu ny nm ch biu i tng ch ra mt lot cc i tng thc th ca lp, thay v cc lp. Mt biu i tng v vy l mt v d ca biu lp, ch ra mt bc tranh thc t c th xy ra khi h thng thc thi: bc tranh m h thng c th c ti mt thi im no . Biu i tng s dng chung cc k hiu ca biu lp, ch tr hai ngoi l: i tng c vit vi tn c gch di v tt c cc thc th trong mt mi quan h u c ch ra (nhn hnh 3.4). Biu i tng khng quan trng bng biu lp, chng c th c s dng v d ha mt biu lp phc tp, ch ra vi nhng thc th c th v nhng mi quan h nh th th bc tranh ton cnh s ra sao. Mt biu i
Hnh 3.4 - Biu lp v biu i tng th hin ca lp 4.4- Biu trng thi (State Diagram): Mt biu trng thi thng l mt s b sung cho li miu t mt lp. N ch ra tt c cc trng thi m i tng ca lp ny c th c, v nhng s kin (event) no s gy ra s thay i trng thi (hnh 3.5). Mt s kin c th xy ra khi mt i tng t gi thng ip n cho n - v d nh thng bo rng mt khong thi gian c xc nh qua i hay l mt s iu kin no c tha mn. Mt s thay i trng thi c gi l mt s chuyn i trng thi (State Transition). Mt chuyn i trng thi cng c th c mt hnh ng lin quan, xc nh iu g phi c thc hin khi s chuyn i trng thi ny din ra. Biu trng thi khng c v cho tt c cc lp, m ch ring cho nhng lp c mt s lng cc trng thi c nh ngha r rng v hnh vi ca lp b nh hng v thay i qua cc trng thi khc nhau. Biu trng thi cng c th c v cho h thng tng th. Biu trng thi c miu t chi tit hn trong chng sau (M hnh ng).
Hnh 3.6 - Mt biu trnh t cho Print Server 4.6- Biu cng tc (Collaboration Diagram): Mt biu cng tc ch ra mt s cng tc ng, cng ging nh mt biu trnh t. Thng ngi ta s chn hoc dng biu trnh t hoc dng biu cng tc. Bn cnh vic th hin s trao i thng ip (c gi l tng tc), biu cng tc ch ra cc i tng v quan h ca chng (nhiu khi c gi l ng cnh). Vic nn s dng biu trnh t hay biu cng tc thng s c quyt nh theo nguyn tc chung sau: Nu thi gian hay trnh t l yu t quan trng nht cn phi nhn mnh th hy chn biu trnh t; nu ng cnh l yu t quan trng hn, hy chn biu cng tc. Trnh t tng tc gia cc i tng c th hin trong c hai loi biu ny. Biu cng tc c v theo dng mt biu i tng, ni mt lot cc i tng c ch ra cng vi mi quan h gia chng vi nhau (s dng nhng k hiu nh trong biu lp/ biu i tng). Cc mi tn c v gia cc i tng ch ra dng chy thng ip gia cc i tng. Cc thng ip thng c nh km theo cc nhn (label), mt trong nhng chc nng ca nhn l
Hnh 3.7 - Mt biu cng tc ca mt printer server 4.7- Biu hot ng (Activity Diagram): Mt biu hot ng ch ra mt trnh t ln lt ca cc hot ng (activity) (hnh 3.8). Biu hot ng thng c s dng miu t cc hot ng c thc hin trong mt th tc, mc d n cng c th c s dng miu t cc dng chy hot ng khc, v d nh trong mt Use case hay trong mt trnh t tng tc. Biu hot ng bao gm cc trng thi hnh ng, cha c t ca mt hot ng cn phi c thc hin (mt hnh ng - action). Mt trng thi hnh ng s qua i khi hnh ng c thc hin xong (khc vi biu trng thi: mt trng thi ch chuyn sang trng thi khc sau khi xy ra mt s kin r rng !). Dng iu khin y chy gia cc trng thi hnh ng lin kt vi nhau. Biu cn c th ch ra cc quyt nh, cc iu kin, cng nh phn thc thi song song ca cc trng thi hnh ng. Biu ngoi ra cn c th cha cc loi c t cho cc thng ip c gi i hoc c nhn v, trong t cch l thnh phn ca hnh ng c thc hin.
Hnh 3.8 - Mt biu hot ng cho mt printer server 4.8- Biu thnh phn (Component Diagram): Mt biu thnh phn ch ra cu trc vt l ca cc dng lnh (code) theo khi nim thnh phn code. Mt thnh phn code c th l mt tp tin source code, mt thnh phn nh phn (binary) hay mt thnh phn thc thi c (executable). Mt thnh phn cha cc thng tin v cc lp logic hoc cc lp m n thi hnh, nh th c ngha l n to ra mt nh x t hng nhn logic vo hng nhn thnh phn. Biu thnh phn cng ch ra nhng s ph thuc gia cc thnh phn vi nhau, tr gip cho cng vic phn tch hiu ng m mt thnh phn c thay i s gy ra i vi cc thnh phn khc. Thnh phn cng c th c miu t vi bt k loi giao din no m chng bc l, v d nh giao din OLE/COM; v chng c th c nhm gp li vi nhau thnh tng gi (package). Biu thnh phn c s dng trong cng vic lp trnh c th (xem hnh 3.9).
Hnh 3.11- Cc thnh phn m hnh thng dng Hnh 3.12 ch ra mt vi v d ca mi quan h, y cng l mt dng phn t m hnh, chng c s dng ni cc phn t m hnh khc vi nhau. Mt vi loi quan h ng ch : Ni kt (Association): ni cc phn t v cc thc th ni (link). Khi qut ha (Generalization): cn c gi l tnh tha k, c ngha rng mt phn t ny c th l mt s chuyn bit ha ca mt phn t khc. S ph thuc (Dependency): ch ra rng mt phn t ny ph thuc trong mt phng thc no vo mt phn t khc. Kt tp (Aggregation): Mt dng ca ni kt, trong mt phn t ny cha cc phn t khc. Ngoi ra cn c cc phn t m hnh khc nh thng ip (Message), hnh ng (action) v khun mu (stereotype). Tt c cc phn t m hnh, ngha ca chng cng nh nhng ng dng u c gii thch k lng hn trong cc chng sau.
Hnh 3.13 - Phn bit gia lp v i tng bng trang tr 6.2- Ghi ch (Note)
Hnh 3.14 - Mt v d v ghi ch 6.3- c t (Specification) Cc phn t m hnh c thuc tnh (Property) cha cc gi tr d liu v phn t ny. Mt thuc tnh c nh ngha vi mt tn v mt gi tr nh km (tagged value), thng chng trong mt dng thng tin c xc nh trc, v d nh s nguyn hay chui k t. C mt lot thuc tnh c nh ngha trc, v d nh ti liu (docement), trch nhim (Responsibility), s trng tn (Persistence) v tnh song song (Conccurency). Thuc tnh c s dng thm cc c t b sung v mt phn t, nhng thng tin bnh thng ra khng c th hin trong biu . V d tiu biu l mt lp s c miu t bng mt ti liu vn bn nht nh, cung cp nhiu thng tin hn v trch nhim cng nh kh nng ca lp ny. Loi c t ny bnh thng ra khng c ch ra trong cc biu , nhng thng th trong a phn cc cng c m hnh ha chng s c th c truy cp qua hnh ng nhp nt vo mt phn t no , hiu qu l mt ca s cha c t vi tt c cc thuc tnh s c ch ra (Hnh 3.15).
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. Khun mu c miu t qua vic a tn ca chng vo trong mt cp k t ngoc nhn <<>>, theo nh trong hnh 3.16. K t ngoc nhn ny c gi l
Hnh 3.16- Customer l mt lp khun mu <<Actor>> 7.2- Gi tr nh km (Tagged Value) Nh ni, cc phn t m hnh c th c cc thuc tnh cha mt cp tn-gi tr v bn thn chng (hnh 3.17). Cc thuc tnh ny cng cn c gi l cc ga tr nh km. UML c cha mt lot cc thuc tnh c nh ngha trc, nhng k c ngi s dng cng c th nh ngha ra cc thuc tnh mi cha cc thng tin b sung v cc phn t m hnh. Mi hnh dng thng tin u c th c nh km vo phn t: cc thng tin chuyn bit v phng php, cc thng tin ca nh qun tr v tin trnh m hnh ha, cc thng tin c s dng bi cc cng c khc, v d nh cc cng c to code, hay bt k mt loi thng tin no m ngi s dng mun nh km vo phn t m hnh.
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
Hnh 3.19- Mt h thng c m t trong nhiu m hnh Bn thn ngn ng UML khng ph thuc vo giai on, c ngha l cng nhng nguyn tc ngn ng v cng nhng biu c s dng m hnh ha nhng s vic khc nhau trong nhng giai on khc nhau. Nh thit k nm quyn quyt nh xem mt m hnh s phi thay i nhm t c nhng mc ch no v bao trm nhng phm vi no. Ngn ng m hnh ha ch cung cp kh nng to ra cc m hnh trong mt phong cch m rng v nht qun. Khi m hnh ha bng ngn ng UML, ton b cng vic cn phi c thc hin theo mt phng php hay mt qui trnh, xc nh r nhng bc cng vic no phi c tin hnh v chng phi c thc thi ra sao. Mt qui trnh nh vy thng s chia cng vic ra thnh cc vng lp k tip, mi vng lp bao gm cc cng vic: phn tch yu cu/ phn tch/ thit k/ thc hin/ trin khai. Mc d vy, cng c mt quy trnh nh hn cp ti ni dung ca vic m hnh ha. Bnh thng ra, khi sn xut mt m hnh hoc sn xut ch mt biu duy nht, cng vic s bt u bng vic thu thp mt nhm thch hp cc c nhn khc nhau, trnh by vn v mc tiu; h cng tc cho mt giai on hi tho
Hnh 3.20 - Mt tin trnh cho cng vic m hnh ho thc t Cui cng, m hnh s c thc thi v trin khai thnh mt lot cc nguyn mu (prototype), nguyn mu ny s c kim tra tm khim khuyt. Cc khim khuyt bao gm k c cc chc nng cn thiu, s thc hin ti t hay ph sn xut v pht trin qu cao. Nhng khim khuyt thng s p nh pht trin r i r li cng vic ca mnh khc phc chng. Nu vn l qu ln, nh pht trin c th s i ngc li tt c cc bc cng vic ca mnh cho ti tn giai on s phc u tin. Nu cc vn ny khng ln, nh pht trin c l ch cn thay i mt vi thnh phn trong t chc hoc c t ca m hnh. Xin nh rng bc to nguyn mu khng th c thc hin ngay lp tc sau khi hon tt biu ; n ch nn c thc hin khi c mt s lng ln cc biu lin quan. Nguyn mu sau ny c th c vt i, c th c to dng nn
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. H tr nh hng (Navigation): cng c cn phi to iu kin d dng cho ngi s dng nh hng v chuyn dch trong
10- TM TT V UML
PHN CU HI
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. Yu cu chuyn tin ca khch hng c thc hin.
Hnh 4.1- Mt v d biu Use case trong UML Trong : H thng c th hin qua hnh ch nht vi tn h thng bn trn Tc nhn c th hin qua k hiu hnh nhn
Hnh 4.2- biu tng tc nhn trong UML 5.5- Use Case: Mt Use Case l i din cho mt chc nng nguyn vn m mt tc nhn nhn c. Mt Use Case trong ngn ng UML c nh ngha l mt tp hp ca cc chui hnh ng m mt h thng thc hin to ra mt kt qu c th quan st c, tc l mt gi tr n vi mt tc nhn c th. Nhng hnh ng ny c th bao gm vic giao tip vi mt lot cc tc nhn cng nh thc hin tnh ton v cng vic ni b bn trong h thng. Cc tnh cht tiu biu ca mt Use Case l: Mt Use Case bao gi cng c gy ra bi mt tc nhn, c thc hin nhn danh mt tc nhn no . Tc nhn phi ra lnh cho h thng thc hin Use Case , d l trc tip hay gin tip. Him khi c tc nhn khng lin quan n vic gy ra mt Use Case no . Mt Use Case phi cung cp mt gi tr cho mt tc nhn. Gi tr khng phi bao gi cng cn thit phi ni tri ra ngoi, nhng lun phi c thy r. Mt Use Case l phi hon tt. Mt trong nhng li thng gp l s chia mt Use Case thnh cc Use Case nh hn, v cc Use Case ny thc thi ln nhau ging nh vic gi hm cho mt ngn ng lp trnh. Mt Use Case s khng c coi l hon tt chng no m gi
Hnh 4.3 Cc Use case trong h thng ATM Use Case gi tin vo v rt tin ra ph thuc vo Use Case thc hin cc chuyn dch trong ni b h thng, vic thc hin ny v phn n li ph thuc
Hnh 4.5 - Quan h m rng gia cc Use Case Quan h m rng gia cc Use Case c biu th bng on thng vi hnh tam gic rng tr v pha Use Case c dng m rng, i km vi stereotype <<extends>>. 7.2- Quan h s dng Khi mt nhm cc Use Case cng chung mt hnh vi no th hnh vi ny c th c tch ring ra thnh mt Use Case ring bit v n c th c s dng bi cc Use Case kia, mt mi quan h nh vy c gi l quan h s dng. Trong quan h s dng, phi s dng ton b Use Case khi qut ha, ni mt cch khc, ta c mt Use Case ny s dng ton b mt Use Case khc. Cc hnh ng trong Use Case khi qut ha khng cn phi c s dng trong cng mt tin trnh. Chng c th c trn ln vi cc hnh ng xy ra trong Use Case chuyn bit ha.
Hnh 4.7 Package ca UML Tm tt v Use Case vi my ATM trong ngn hng l: Cho ti nay chng ta xc nh c mt vi Use Case, phn tch dng hnh ng chnh cng nh cc dng hnh ng thay th, cng nh rt ra cc mi quan h gia chng. Biu sau tng hp nhng thng tin thu thp c v nhm cc Use Case cn bn ca mt h thng ATM.
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. Kim tra h thng l m bo n hot ng ng nh c t. iu ny khng th c thc hin trc khi c nhng thnh phn ca h thng c to ra. Ch sau ngi ta mi c th th xem h thng c hot ng ng nh
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
Khi to dng m hnh cng nh tht s xy dng cc h thng doanh nghip, cc h thng thng tin, my mc hoc cc lai h thng khc, chng ta cn s dng cc khi nim ca chnh phm vi vn khin cho m hnh d hiu v d giao tip hn. Nu chng ta xy dng h thng cho mt cng ty bo him, m hnh
to mt biu lp, u tin ta phi nhn din v miu t cc lp. Mt khi c mt s lng cc lp, ta s xt n quan h gia cc lp vi nhau. 2- Tm lp: Hu nh khng c mt cng thc chung cho vic pht hin ra cc lp. i tm cc lp l mt cng vic i hi tr sng to v cn phi c thc thi vi s tr gip ca chuyn gia ng dng. V qui trnh phn tch v thit k mang tnh vng lp, nn danh sch cc lp s thay i theo thi gian. Tp hp ban u ca cc lp tm ra cha chc l tp hp cui cng ca cc lp sau ny s c thc thi v bin i thnh code. V th, thng ngi ta hay s dng n khi nim cc lp ng c vin (Candidate Class) miu t tp hp nhng lp u tin c tm ra cho h thng. Nh ni trong phn 2.10 (Thc hin Trng hp s dng), trng hp s dng l nhng li miu t chc nng ca h thng, cn trch nhim thc thi thuc v cc i tng cng tc thc thi chc nng . Ni mt cch khc, chng ta i tm cc lp l tin ti tm gii php cung cp nhng ng x hng ngoi c xc nh trong cc trng hp s dng. C nhiu phng php khc nhau thc hin cng vic . C phng php ngh tin hnh phn tch phm vi bi ton, ch ra tt c cc lp thc th (thuc phm vi bi ton) vi mi quan h ca chng vi nhau. Sau nh pht trin s phn tch tng trng hp s dng v phn b trch nhim cho cc lp trong m hnh phn tch (analysis model), nhiu khi s thay i chng hoc b sung thm cc lp mi. C phng php ngh nn ly cc trng hp s dng lm nn tng tm cc lp, lm sao trong qu trnh phn b trch nhim th m hnh phn tch ca phm vi bi ton s tng bc tng bc c thit lp. 2.1- Phn tch phm vi bi ton tm lp:
Cc trng hp s dng l ngun tt nht cho vic nhn din lp v i tng. Cn nghin cu k cc Trng hp s dng tm cc thuc tnh (attribute) bo trc s tn ti ca i tng hoc lp tim nng. V d nu Trng hp s dng yu cu phi a vo mt s ti khon (account-number) th iu ny tr ti s tn ti ca mt i tng ti khon. Mt ngun khc nhn ra lp/i tng l cc Input v Output ca h thng. Nu Input bao gm tn khch hng th y l tn hiu cho bit s tn ti ca mt i tng khch hng, bi n l mt attribute ca khch hng. Ni chuyn vi ngi s dng cng gi m n cc khi nim then cht. Thng th ngi s dng miu t h thng theo li cn phi a vo nhng g v mong ch kt qu g. Thng tin a vo v kt qu theo li miu t ca ngi s dng cn phi c tp hp li vi nhau nhn dng khi nim then cht.
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, y vn c th cha phi l kt qu chung cuc, mt s lp ng c vin c th s b loi b trong cc bc sau v khng thch hp. Giai on u khi nh ngha cc lp ng c vin, ta cha nn c gng thanh lc cc lp, hy tp trung co mc tiu nghin cu bao qut v ton din t nhiu ngun thng tin khc nhau khng b st nhiu kha cnh cn x l. V d trong nh mt bng l, cc lp ng c vin c th l: Khch hng
Hnh trn c c nh sau: CAH l i tng ca lp AccountHolder. Cc thuc tnh c gn gi tr, y l cc gi tr khi lp c thc th ha. Ch rng k hiu i tng khng cha phn phng thc.
4- Quan h gia cc lp: Biu lp th hin cc lp v cc mi quan h gia chng. Quan h gia cc lp gm c bn loi: Lin h (Association) Khi qut ha (Generalization) Ph thuc (Dependency) Nng cp (Refinement) Mt lin h l mt s ni kt gia cc lp, cng c ngha l s ni kt gia cc i tng ca cc lp ny. Trong UML, mt lin h c nh ngha l mt mi quan h miu t mt tp hp cc ni kt (links), trong khi ni kt c nh ngha l mt s lin quan v ng ngha (semantic connection) gia mt nhm cc i tng. Khi qut ha l mi quan h gia mt yu t mang tnh khi qut cao hn v mt yu t mang tnh chuyn bit hn. Yu t mang tnh chuyn bit hn c th cha ch cc thng tin b sung. Mt thc th (mt i tng l mt thc th ca mt lp) ca yu t mang tnh chuyn bit hn c th c s dng bt c ni no m i tng mang tnh khi qut ha hn c php. S ph thuc l mt mi quan h gia cc yu t, gm mt yu mang tnh c lp v mt yu t mang tnh ph thuc. Mt s thay i trong yu t c lp s nh hng n yu t ph thuc. Mt s nng cp l mi quan h gia hai li miu t ca cng mt s vt, nhng nhng mc tru tng ha khc nhau. 5- Lin h (Association)
5.1- Vai tr trong lin h Mt lin h c th c cc vai tr (Roles). Cc vai tr c ni vi mi lp bao cha trong quan h. Vai tr ca mt lp l chc nng m n m nhn nhn t gc nhn ca lp kia. Tn vai tr c vit km vi mt mi tn ch t hng lp ch nhn ra, th hin lp ny ng vai tr nh th no i vi lp m mi tn ch n.
Trong v d trn: mt khch hng c th l ch nhn ca mt ti khon v ti khon c chim gi bi khch hng. ng thng th hin lin h gia hai lp. Mt s im cn ch khi t tn vai tr: Tn vai tr c th b i nu trng vi tn lp Tn vai tr phi l duy nht. Tn vai tr phi khc vi cc thuc tnh ca lp.
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:
Biu trn ni r mt khch hng c th m mt hoc nhiu ti khon v mt ti khon c th thuc v mt cho ti ba khch hng. S lng c ghi pha u ng thng th hin lin h, st vo lp l min p dng ca n. Phm vi ca s lng phn t trong lin h c th t 0-ti-1
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, Tho mn mt iu kin: Nhng cm t nh: lm vic cho, l chng/v ca, qun tr, . 5.5- X l cc lin h khng cn thit: Sau khi tm cc mi lin h, bc tip theo l phn bic cc lin h cn thit ra khi cc lin h khng cn thit. Lin h khng cn thit c th bao gm nhng lin h bao cha cc lp ng c vin b loi tr hoc cc lin h khng
5.6- Nng cp cc mi lin h: Mt khi cc mi lin h cn thit c nhn dng, bc tip theo l ngin cu k m hnh v nng cp cc mi lin h . ng tc nng cp u tin l xem xt li tn lin h, tn vai tr, t li cho ng vi bn cht quan h m chng th hin. Mi lin h cn phi c suy xt k v phng din s lng thnh phn tham gia (Cardinality). S hn nh (Qualification) cho lin h ng mt vai tr quan trng y, b sung yu t hn nh c th gip lm gim s lng. Nu cn thit, hy b sung cc lin h cn thiu. Nghin cu k cc thuc tnh, xem liu trong s chng c thuc tnh no tht ra th hin lin h. Nu c, hy chuyn chng thnh lin h. B sung cc thng tin v iu kin cn thit cng nh xem xt cc mi lin h trong m hnh tng th xc nh cc dng quan h gia chng vi nhau. 5.6.1- Lin h v yu t hn nh (Qualifier): Mt lin h c hn nh lin h hai lp v mt yu t hn nh (Qualifier) vi nhau. Yu t hn nh l mt thuc tnh hn ch s lng thnh phn tham gia
5.6.2- Lin h V (AND Association) Nh bng n a ra quy nh: khch hng khi mun m mt ti khon ATM phi l ch nhn ca t nht mt ti khon u t. Trong mt trng hp nh th, mi lin h V (AND) s c th hin nh sau:
Biu trn cho thy mt khch hng c th c nhiu hn mt ti khon u t c thi hn v ch mt ti khon ATM. Trong biu c mt mi lin h V ngm c p dng gia nhm ti khon u t v ti khon ATM m mt khch hng c th c. 5.6.3- Lin h HOC (OR Association) V d ti mt hng bo him n, c nhn cng cng ty u c th k hp ng bo him, nhng c nhn v cng ty khng c php c cng loi hp ng bo him nh nhau. Trong mt trng hp nh th, gii php l s dng lin h HOC (OR Association). Mt lin h HOC l mt s hn ch i vi mt nhm hai hay nhiu lin h, xc nh rng i tng ca mt lp ny ti mt thi im ch c th tham gia vo nhiu nht mt trong cc mi lin h .
5.6.4- Lin h c sp xp (Ordered Association) Cc mi ni kt (link) gia cc i tng c mt trt t ngm nh. Gi tr mc nh ca trt t ny l ngu nhin. Mt lin h c trt t r rng c th c hiu l mt lin h vi trt t sp xp (sort order) trong nhm cc ni kt, n s c th hin nh sau:
Biu trn c c nh sau: Mt khch hng c th quan h vi b phn u t v mt b phn u t c th c mt hoc nhiu khch hng. Mt giy chng nhn ti khon u t s xut hin qua quan h gia khch hng v b phn u t. 5.6.6- Lp lin h (Association Class) Mt lp c th c nh km theo mt lin h, trong trng hp ny n s c gi l mt lp lin h. Mt lp lin h khng c ni ti bt k mt lp no ca mi lin h, m ti chnh bn thn mi lin h. Cng ging nh mt lp bnh thng, lp lin h c th c thuc tnh, Phng thc v cc quan h khc. Lp lin h c s dng b sung thm thng tin cho ni kt (link), v d nh thi im ni kt c thit lp. Mi ni kt ca lin h gn lin vi mt i tng ca lp lin h. V d sau miu t mt h thng thang my. B phn iu khin ch huy bn thang my. Cho mi ni kt gia nhm thang my v b phn iu khin c mt hng xp (queue). Mi hng lu tr nhng yu cu k c t pha b phn iu khin ln t pha thang my (nhng nt bm bn trong thang). Khi b phn iu khin chn mt thang my thc hin mt li yu cu n t mt hnh khch ng ngoi thang my (mt hnh khch trn hnh lang), n s c cc hng v chn thang my no c hng yu cu ngn nht.
5.6.7- Lin h quy (Recursive Association) C th lin kt mt lp vi bn thn n trong mt mi lin h. Mi lin h y vn th hin mt s lin quan ng ngha, nhng cc i tng c ni kt u thuc chung mt lp. Mt lin h ca mt lp vi chnh bn thn n c gi l mt lin h quy, v l nn tng cho rt nhiu m hnh phc tp, s dng v d miu t cc cu trc sn phm. Hnh 5.25 ch ra mt v d ca lin h quy v hnh 5.26 l mt biu i tng cho biu lp trong hnh 5.25.
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:
Mi thnh phn to nn kt tp (tng th) c gi l mt b phn (aggregates). Mi b phn v phn n li c th c to bi cc b phn khc.
Trong trng hp ti khon k trn, mt trong cc b phn ca n l cc chi tit v khch hng. Cc chi tit v khch hng li bao gm danh sch ch ti khon, danh sch a ch, cc quy nh v k hn cng nh cc chi tit khc khi m ti khon. 6.3- Kt tp v lin h:
Mt ti khon c to bi cc chi tit v khch hng, cc lnh giao dch i vi ti khon cng nh cc quy nh ca nh bng. Khch hng khng phi l l b phn ca ti khon, nhng c quan h vi ti khon. Nhn chung, nu cc lp c ni kt vi nhau mt cch cht ch qua quan h "ton th b phn" th ngi ta c th coi quan h l kt tp. Khng c li hng dn chc chn v r rng cho vic bao gi nn dng kt tp v bao gi nn dng lin h. Mt li tim cn nht qun i km vi nhng kin thc su sc v phm vi vn s gip nh phn tch chn gii php ng n.
7- Khi qut ha v chuyn bit ha (Generalization & Specialization) Hy quan st cu trc lp trong biu 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. Tng t nh vy, ti khon u t trung hn v di hn li l nhng khi nim chuyn bit ca khi nim ti khon c k hn. Mt khc, ti khon bnh thng v ti khon tit kim l nhng trng hp c bit ca loi ti khon giao dch. Loi cu trc lp nh th c gi l mt cu trc hnh cy hoc cu trc phn cp. Khi chng ta dch chuyn t im xut pht ca cy xung di, chng ta s gp cc khi nim cng ngy cng c chuyn bit ha nhiu hn. Theo con ng i t ti khon n ti khon tit kim, ta s phi i qua lp ti khon giao dch. Lp ny tip tc phn loi cc lp chuyn bit ha cao hn, ty thuc vo chc nng ca chng. 7.1- K hiu khi qut ha v chuyn bit ha
Qu trnh bt u vi mt lp khi qut sn xut ra cc lp mang tnh chuyn bit cao hn c gi l qu trnh chuyn bit ho (Specialization) Chuyn bit ha: l qu trnh tinh ch mt lp thnh nhng lp chuyn bit hn. Chuyn bit ha b sung thm chi tit v c t cho lp kt qu. Lp mang tnh khi qut c gi l lp cha (superclass), kt qu chuyn bit ha l vic to ra cc lp con (Subclass). Mt khc, nu chng ta i dc cu trc cy t di ln, ta s gp cc lp ngy cng mang tnh khi qut cao hn - V d t lp ti khon tit kim ln ti lp ti khon. Con ng bt u t mt lp chuyn bit v khin n ngy cng mang tnh khi qut cao hn c gi l qu trnh khi qut ha (Generalization). Lp chuyn bit y c gi l lp con, trong v d trn l ti khon tit kim, trong khi lp khi qut kt qu c gi l lp cha. Chuyn bit ha v khi qut ha l hai con ng khc nhau xem xt cng mt mi quan h. Mt lp l lp con ca mt lp ny c th ng vi tr l mt lp cha ca lp khc. 7.2- Yu t phn bit (Discriminatior) to mt cu trc phn cp, cn phi c mt s thuc tnh lm nn tng cho qu trnh chuyn bit ha. Thuc tnh c gi l yu t phn bit (Discriminator). Vi mi gi tr c th gn cho yu t phn bit trong lp cha, ta s c mt lp con tng ng.
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
Biu trn cho ta mt v d v khi qut ha v cc thuc tnh chung, n ch ra nhiu lp chuyn bit. Ch rng c theo mi mc chuyn bit ha li c thm cc thuc tnh c b sung thm cho cc lp, khin chng mang tnh chuyn bit cao hn so vi cc lp cha mc tru tng bn trn. V d lp ti khon c thuc tnh l s ti khon v tn khch hng. y l nhng thuc tnh ht sc chung chung. Tt c cc lp dn xut t n, d l trc tip hay gin tip ( cc mc tru tng thp hn na), u c quyn s dng cc thuc tnh ca lp ti khon. Cc lp ti khon c k hn v ti khon giao dch l hai lp chuyn bit dn xut t lp ti khon. Chng c nhng thuc tnh chuyn bit
Thng xy ra trng hp tt c cc lp con cng tham gia vo mt lin h hoc kt tp. Trong trng hp ny nn to lp cha nh ngha lin h /kt tp . Hnh sau gii thch thm im ny:
8- Quan h ph thuc v nng cp (Dependency & Refinement) Bn cnh lin h v khi qut ha, UML cn nh ngha hai loi quan h khc. Quan h ph thuc (Dependency) l mt s lin quan ng ngha gia hai phn t m hnh, mt mang tnh c lp v mt mang tnh ph thuc. Mi s thay i trong phn t c lp s nh hng n phn t ph thuc. Phn t m hnh y c th l mt lp, mt gi (package), mt trng hp s dng,.v.v... C th nu mt vi c d cho s ph thuc nh: mt lp ly tham s l i tng ca mt lp khc, mt lp truy nhp mt i tng ton cc ca mt lp khc, mt lp gi mt th tc thuc thuc mt lp khc. Trong tt c cc trng hp trn u c mt s ph thuc ca mt lp ny vo mt lp kia, mc d chng khng c lin h r rng vi nhau. Quan h ph thuc c th hin bng ng thng gch ri (dashed line) vi mi tn (v c th thm mt nhn) gia cc phn t m hnh. Nu s dng nhn th n s l mt khun mu (stereotype), xc nh loi ph thuc. Hnh sau ch ra mt s ph thuc dng "friend", c ngha rng mt phn t m hnh nhn c quyn truy cp c bit ti cu trc ni b ca phn t th hai (thm ch ti c nhng phn mang tnh nhn thy l private).
Nng cp (Refinement) l mt quan h gia hai li miu t ca cng mt s vt, nhng nhng mc tru tng ha khc nhau. Nng cp c th l mi quan h gia mt loi i tng v lp thc hin n. Cc nng cp thng gp khc l quan h gia mt lp phn tch (trong m hnh phn tch) v mt lp thit k (trong m hnh thit k) u m hnh ha cng mt th, quan h gia mt li miu t c mc tru tng ha cao v mt li miu t c mc tru tng ha thp (v d mt bc tranh khi qut ca mt s cng tc ng v mt biu chi tit ca cng cng tc ). Quan h nng cp cn c s dng m
Quan h nng cp c s dng trong vic phi hp m hnh. Trong cc d n ln, mi m hnh u cn phi c phi hp vi nhau. Phi hp m hnh c s dng nhm mc ch: Ch ra mi lin quan gia cc m hnh nhiu mc tru tng khc nhau. Ch ra mi lin quan gia cc m hnh nhiu giai on khc nhau (phn tch yu cu, phn tch, thit k, thc thi,...). H tr vic qun tr cu hnh. H tr vic theo di trong m hnh. 9- Nng cp m hnh qua cc vng lp k tip Cho ti thi im ny, chng ta i qua cc bc cng vic phn tch cn bn v to nn phin bn u tin ca m hnh i tng. M hnh ny cn phi c ly lm mc tiu cho cc vng lp nng cp tip theo. Cng vic nng cp c th c thc hin bng cch a m hnh qua tt c cc giai on pht trin m hnh i tng mt ln na. Ln ny, nhng kin thc thu c trong vng pht trin u s t ra rt hu dng. Khi nng cp m hnh cn ch n cc bc sau: a) Nghin cu cc lp tm cc thuc tnh v th tc khng ng dng (dissimilar). Nu c, x lp thnh cc thnh phn to tnh ng nht (harmony) trong lp. V d vi mt lp m nhn hai vai tr khc nhau, hy x lp thnh cc lp kt qu vi nhng th tc c xc nh r rng. b) Nu pht hin thy mt chc nng khng hng ti mt lp ch no th l triu chng thiu lp. Hy b sung lp thiu v a th tc k trn vo lp . c) Khi qut ha l cn cha nu c cc lin h trng lp (nhiu lin h cng nh ngha mt quan h). Trong trng hp ny, cn to lp cha kt hp cc mi lin h .
Phn cu hi
Hi: Khi to dng m hnh, cn s dng cc khi nim ca chnh phm vi vn m hnh d hiu v d giao tip. p: ng Hi: Cc lp ch th hin cu trc thng tin? p: sai, cc lp khng phi ch th hin cu trc thng tin m cn m t c hnh vi. Hi: Cc khi nim then cht thng s tr thnh cc lp trong m hnh phn tch? p: ng Hi: Thng cc danh t trong cc li pht biu bi ton s l ng c vin chuyn thnh lp v i tng? p: ng Hi: Quan h kt hp (Association) gia cc lp nh ngha cc mi lin quan c th tn ti gia cc i tng? p: ng, v d mt mi quan h kt hp l mt s ni kt gia cc lp, c ngha l s ni kt gia cc i tng ca cc lp ny. Hi: 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"
Chng 6: M HNH NG
Hnh 6.1- Cc thnh phn ca m hnh ng Cc thnh phn k trn s c cp chi tit hn trong cc phn sau. Ngoi ra, mt m hnh ng cng cn c s dng xc nh cc nguyn tc chuyn ngnh (business rule) cn phi c p dng trong m hnh. N cng c s dng n nh xem cc nguyn tc c a vo nhng v tr no trong m hnh. Mt vi v d cho nhng nguyn tc chuyn ngnh cn phi c th hin trong m hnh ng: Mt khch hng khng c quyn rt tin ra nu khng c mc tin trong ti khon. Nhng mn tin u t c k hn khng th chuyn sang mt tn khc trc khi o hn. Gii hn cao nht trong mt ln rt tin ra bng th ATM l 500 USD.
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.4- Biu cnh kch rt tin mt ti my ATM Biu trn c th c din gii theo trnh t thi gian nh sau: C ba lp tham gia cnh kch ny: khch hng, my ATM v ti khon. Khch hng a yu cu rt tin vo my ATM i tng my ATM yu cu khch hng cung cp m s M s c gi cho h thng kim tra ti khon i tng ti khon kim tra m s v bo kt qu kim tra n cho ATM ATM gi kt qu kim tra ny n khch hng
Hnh 6.6- Cc k hiu UML th hin bt u, kt thc, s kin v trng thi ca mt i tng.
Hnh 6.7- Biu trng thi thc hin ho n. Mt trng thi c th c ba thnh phn, nh c ch trong hnh sau:
Hnh 6.8- Cc ngn Tn, Bin trng thi v hnh ng Phn th nht ch ra tn ca trng thi, v d nh ch, c tr tin hay ang chuyn ng. Phn th hai (khng bt buc) dnh cho cc bin trng thi. y l nhng thuc tnh ca lp c th hin qua biu trng thi; nhiu khi cc bin tm thi cng t ra rt hu dng trong trng thi, v d nh cc loi bin m (counter). Phn th ba (khng bt buc) l phn dnh cho hot ng, ni cc s kin v cc hnh ng c th c lit k. C ba loi s kin chun ha c th c s dng cho phn hnh ng: entry (i vo), exit (i ra), v do (thc hin). Loi s kin i vo c s dng xc nh cc hnh ng khi nhp trng thi, v d gn gi tr cho mt thuc tnh hoc gi i mt thng ip. S kin i ra c th c s dng xc nh hnh ng khi ri b trng thi. S kin thc hin c s dng xc nh hnh ng cn phi c thc hin
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.
(reclassfied)?: Nhng loi s kin nh mt nhn vin c tng chc thnh nh qun tr s khin cho ng tc ti phn loi ca nhn vin c thc hin. 7.4- Mt s li mch bo cho vic to dng biu trng thi Chuyn biu tun t thnh biu trng thi. Xc nh cc vng lp (loop) B sung thm cc iu kin bin v cc iu kin c bit Trn ln cc cnh kch khc vo trong biu trng thi. Mt khi m hnh c to nn, hy nu ra cc cu hi v kim tra xem m hnh c kh nng cung cp tt c cc cu tr li. Qui trnh sau y cn phi c nhc li cho mi i tng. 7.4.1- Chuyn biu tun t thnh biu trng thi Hy di theo mt chui cc s kin c miu t trong biu , chui ny phi mang tnh tiu biu cho cc tng tc trong h thng. Hy quan st cc s kin nh hng n i tng m ta ang nghin cu. Hy sp xp cc s kin thnh mt ng dn, dn nhn input (hoc entry) v output (exit) cho cc s kin. Khong cch gia hai s kin ny s l mt trng thi.
Hnh 6.10- Chuyn mt biu tun t sang biu trng thi 7.4.2- Nhn ra cc vng lp (loop) Mt chui s kin c th c nhc i nhc li v s ln c gi l vng lp (loop).
Hnh 6.11- Biu lp Ch : Trong mt vng lp, chui cc s kin c nhc i nhc li cn phi ng nht vi nhau. Nu c mt chui cc s kin khc chui khc th trng hp khng c vng lp. L tng nht l mt trng thi trong vng lp s c s kin kt thc. y l yu t quan trng, nu khng th vng lp s khng bao gi kt thc.
Hnh
6.12-
Khi
mt
ngi
gi
tc
PrintAllCustomer
(trong
lp
Hnh 6.13- Thanh ng b ha iu kin canh gi (Guard Condition): cc biu thc logic c gi tr hoc ng hoc sai. iu kin canh gi c th hin trong ngoc vung, v d: [Customer existing].
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
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
ICONIX is pleased to offer a one-day course titled "An Introduction to the Unified Modeling Language (UML)". "An Introduction to the Unified Modeling Language (UML)" was developed by Kendall Scott, co-author of the awardwinning book UML Distilled, as well as Use Case Driven Object Modeling with UML, and author of the forthcoming UML for the Rest of Us. The course is designed to help you quickly get up to speed on the essential aspects of the UML and the most relevant parts of the associated Unified Process. This one-day course is designed to provide a quick but insightful introduction to the standard visual modeling language, touching upon all of the key aspects of the UML and its relationship with the use-case-driven, architecturecentric, and iterative and incremental Unified Process. The course also provides pointers about how to go about learning more about the UML, from the published work of the 'three amigos' as well as the instructor's own UML material. The course is presented in six parts:
UML, how the language evolved from the work of the "three amigos," and principles of modeling.
Views,
Phases,
and
Diagrams
addresses
the
five
architectural views around which the UML is centered, the four Unified Process phases to which the UML relate, and the nine diagrams at the heart of the UML.
diagrams that focus on the structural aspects of a system being modeled, as well as the non-standard but popular package diagram.
Behavioral (Dynamic) Diagrams addresses the five UML diagrams that focus on the behavioral aspects of a system being modeled.
templates, processes and threads, and collaborations, which cross the conceptual boundaries that the diagrams establish.
Process-Specific
Extensions
addresses
the
class
stereotypes that are required for robustness analysis (which is discussed extensively Use Case Driven Object Modeling with UML), and other Unified Process-related extensions associated with testing, use cases, and requirements.
"An Introduction to the Unified Modeling Language (UML)" is suitable for anyone who is interested in learning about the UML. No knowledge of object orientation is assumed; however, the instructor can customize the course as needed to make it more suitable for students who do have that knowledge. The flavor of the course that involves work with Rose assumes no experience working with visual modeling tools.
*UML is a trademark of Object Management Group, Inc. in the U.S. and other countries.
ICONIX Software Engineering, Inc./2800 28th Street, Suite 320/Santa Monica, CA 90405/Tel (310)4580092/Fax (310)396-3454/email: marketing@iconixsw.com
Please note that this site is no longer being updated. Please click here to return to www.omg.org.
Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs. The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML was developed by Rational Software and its partners. It is the successor to the modeling languages found in the Booch, OOSE/Jacobson, OMT and other methods. Many companies are incorporating the UML as a standard into their development processes and products, which cover disciplines such as business modeling, requirements management, analysis & design, programming and testing. The Importance Of Modeling
Developing a model for an industrial-strength software system prior to its construction or renovation is as essential as having a blueprint for a building. Good models are essential for communication among project teams and to
Model elements fundamental modeling concepts and semantics. Notation visual rendering of model elements. Guidelines idioms of usage within the trade.
In the face of increasingly complex systems, visualization and modeling become essential. The UML is a well-defined and widely accepted response to that need. It is the visual modeling language of choice for building object-oriented and component-based systems. Goals of the UML
The primary goals in the design of the UML were as follows: 1) Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. 2) Provide extensibility and specialization mechanisms to extend the core concepts. 3) Be independent of particular programming languages and development processes. 4) Provide a formal basis for understanding the modeling language. 5) Encourage the growth of the OO tools market. 6) Support higher-level development concepts such as collaborations,
frameworks, patterns and components. 7) Integrate best practices. Scope of the OMG-UML
The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system. First and foremost, the Unified Modeling Language fuses the concepts of Booch, OMT and OOSE. The result is a single, common, and widely usable modeling language for users of these and other methods. Second, the Unified Modeling Language pushes the envelope of what can be done with existing methods. As an example, the UML authors targeted the modeling 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 Many organizations will use the UML as a common language for their project artifacts, but they will use the same UML diagram types in the context of
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.
Establish an explicit coupling to conceptual as well as executable artifacts. Address the issues of scale inherent in complex, mission-critical systems. Create a modeling language usable by both humans and machines.
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 from Booch, OMT, OOSE, and other leading methods and has incorporated input
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 management concepts that have been implemented in the commercial object repositories, development tools, and object framework products developed by the co-submitters. The specification enhances meta data management and meta data
interoperability in distributed object environments in general and in distributed development environments in particular. While the initial work addresses meta data interoperability in object analysis and design domain, it is anticipated that the MOF will be rich enough to support additional domains. Examples include metamodels that cover the application development life cycle as well as additional domains such as data warehouse management and business object
1997-2001
Object
Management
Group,
Inc.
Reserved. contact
webtech@omg.org
Figure 1 - Subset of UML Object Modelling Notation - A Summary Object Modelling is the central technique in UML. It is a language independent notation allowing the specification of classes, their data or attributes(private) and
Figure 2 - A Simple Banking System Object Model Examining this Object Model in more detail, we can see the following information about our class structure:
Head-Office
class
(containing
"bankName"
and
"address"
fields,
otherwise known as attributes) "administers" an (unspecified) number of Branch classes; whilst a Branch is "administered-by" exactly one HeadOffice (the little black arrows indicates the direction in which the name given to a relationship should be read). On the diagram this relationship is represented by the line from the Head-Office class to the Brach class which is labelled "administers". The "1" at the Head-Office end of the line shows that exactly one Head-Office is associated with each Branch (as you would expect). The "*" at the Branch end of the line shows that a HeadOffice "administers" many Branches - again as you would expect.
Similarly, a Branch class (which contains "manager" and "address" attributes) "holds" many Account classes; whilst each Account class "isheld-by" exactly one Branch. We can also see that we have determined
The inheritance "triangle" (labelled "account-type") shows us that our system knows about three types of Account: the basic account (in this case a virtual class called Account), and two specialised accounts - the CurrentAccount and SavingsAccount - which are derived from Account. The fact that the "CalcCharges" is shown in both sub-classes indicates that its implementation is re-defined for these classes (in C++ terms it is a virtual function). This is indicative of the fact that charges on a "SavingsAccount" are calculated in a completely different manner to charges on a "CurrentAccount".
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 Account the money is "credit(ed)-to". This enables the bank to record exactly where each transaction has come from, and gone to, so to speak.
+!): Figure 3 - Instance Diagram Showing Branch and Account objects By now, you may be beginning to see how Object Models can assist the analysis/design process. They assist in the clarification of the relationships that should be (somehow) represented in a software system. The important point to note hear is that we are first working out what relationships we need to represent in our system ("belongs-to", etc.), without worrying too much about exactly how they should be stored. Put another way, Object Modelling allows us to focus on exactly what problem we are trying to solve, before we look at the best way of implementing our model in a particular programming language.
: Figure 4 - Subset of Banking Model Our Object Model shows us that we need four classes: Transaction; Account; Current Account and Savings Account, and that our implementation must enable us to represent the fact that any particular Account has two sets of Transactions associated with it - which will be needed to implement the PrintStatement method. The Account, CurrentAccount and SavingsAccount classes are easily mapped to the C++ (or Java) inheritance mechanisms:
class /*... public: virtual void }; class /* public: virtual void CalcCharges(); /* re-definition */ SavingsAccount: any public additional Account data { */ void CalcCharges(); PrintStatement(); Account data... { */
Figure 5 - Mapping Object Model Inheritance To C++ Inheritance The Transaction class may be implemented as follows:
class long date_t public: /* Access Date(date_t); date_t Value(long); long }; Value(); Date(); /* /* and /* /* set get Update set functions */ get*/ */ */ */ value; date; Transaction /* /* stored date of in { pence transaction */ */
Figure 6 - Transaction Class In C++ This leaves us with the "debit-from" and "credit-to" relationships to be implemented. Here we have a number of choices: linked-lists; collection-classes; (dynamically bounded) arrays of pointers; etc. could all be used to represent these relationships.
class TransactionList Transaction public: void void }; Data * * (Transaction Data(); *); /* /* NextItem(); *); /* set get /* get next next ptr ptr set */ */ */ */ Transaction TransactionList * * TransactionList next; data; /* /* ptr store to the { next transaction element here */ */
NextItem(TransactionList
Figure 7 - Simple Transaction List Handler Class For brevity, a linked-list class with a somewhat limited interface is used in this example although this may not the best choice. Amending our Account class definition to use this class gives us the following new definition:
(Transaction (Transaction
NextDebitTx(); NextCreditTx();
Iterator:get Iterator:get
debitedFrom->Data(theTx);
Figure 8 - Account Class amended to use Transaction List Although this is a somewhat simplistic implementation - it demonstrates the point that the model shown in figure 4 is easily translated into C++. Of course, better implementations of the "debit-from" relationship are possible, but the fact that the Account class interface completely hides the underlying implementation of this relationship means that we can improve on our first cut implementation at a later date with little impact on our overall system code. In other words, use of the Account class interface has limited the impact of the relationship implementation method: something we strive to achieve when writing OO based applications. A couple of other points are worthy of note at this stage:
The linked list class contains pointers (references in Java) to Transaction objects. This is implicit in our Object Model, and is what the system's users would expect to see. To see why, consider the case when a new Transaction value is entered in error. The Transaction is linked to two accounts ("debit-from" and "credit-to"). If the Transaction object is shared, only one object need be modified to rectify the situation. Using two objects would either mean that either the system has to update two
Although our Object Model "debit-from" relationship uses a linked list, there are many alternatives to this choice - including the use of a relational database to underpin the system. The point is, however, no matter what mechanism is used, we are actually trying to implement a "many-to-one" relationship between an Account and a Transaction. It is this relationship that exists in the banking problem domain - not a relationship involving linked lists or collection classes. Object Modelling enables us to spot the relationship required by the problem domain, and then choose the best way of implementing it.
So far, we have only implemented the "debit-from" relationship in one direction- from the Account class to the Transaction class. Our model does not (yet) specify in which direction the relationship will be traversed. If we need to traverse the relationship in both directions - getting from the Transaction to the related Account - our implementation will prove insufficient, and some form of double pointer schema may be needed. Much work would have been saved if we had known this fact before we had started writing the code.
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.
Other factors may also influence our choice of implementation: do we need a direct form of access - for example using a Transaction number to go directly from the Account to the relevant Transaction? If we do, then a linked-list will prove an inefficient choice of implementation. Again, it would be very useful to know this type of information before we start trying to implement the relationship.
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 relationships that might be required). We can't produce a good design for a system unless we consider all the required functionality - in detail. Use Cases provide the mechanism for doing this. Use 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
: Figure 9 - Use Cases for Banking System This Use Case diagram shows us the following:
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
Customers may use the system for balance enquiries Data processing staff use the system to do basic data entry (transactions on accounts)
Clerks may periodically request statements on behalf of Customers; There are four distinct types of user of the system: Bank Managers; Clerks; Data Processing Assistants; and Customers. Each type of user
Use Case Detail: Overdrawn Report Used 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 part of the report. Outputs: Details what information flows from the system to the external environment, in this current case overdraft; the period overdrawn printer! (days); overdraftReport (to branchPrinter) - structured as follows: customer name; 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). theBranchSortCode - must be a branch sort code held within the system. theOverdraftPeriod - must be a number between 0 and 100 days. By:
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 method call Diagrams calls within a
Sequence diagrams, performed on a per Use Case basis, examine the flow of
Figure 10 - Sequence Diagram for Overdrawn Report Performing a complete analysis requires that each individual Use Case must be examined, although in practise only selected Use Cases may be examined. The Sequence Diagram in figure 10 shows the Overdrawn Report Use Case defined earlier. The Overdrawn Report Use Case is thus implemented as follows:
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 Head-Office OverdrawnReport method locates the relevant Branch (as determined by the Use Case input: theBranchUseCase) and cascades the request to the Branch by calling its OverdrawnReport method.
The Branch object in turn passes the request on down to each Account it holds (using the Account's OverdrawnReport method)!
Each Account then: checks if it has been overdrawn for greater than the period specified by theOverdraftPeriod, which is passed as an argument to the Account.OverdrawnReport method (the detail of this is not shown - but involves summing up all the Transactions it holds, and checking the date on which it last became overdrawn).
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.
Figure 11 - Updated Banking System Object Model Reviewing the Object Model (see figure 11), we can see a number of additions as a result of completing this Sequence Diagram:
OverdrawnReport methods have been added to the Branch and Account classes.
A lastReportedDate attribute and associated methods have been added to the Account class, along with a printOverdrawnReport method.
The "administers" relationship between Head-Office and Branch has been qualified to indicate that "direct access" via the Branch's "sort-code" is required across the link (thus assisting in link design) - note the consequent change in the multiplicity of the relationship from many-to-one to one-to-one.
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
Figure 12 - The Overall Process This approach separates the Problem and Technical Domain aspects of the project:
Problem Domain Analysis is concerned with capturing requirements and producing a first cut Object Model. Typically the Object Model will be incomplete, having only a subset of the class attributes and methods defined.
Problem Domain Design is concerned with finalising the detail of the problem domain parts of the Object Model, and results in an Object Model with a complete set of Problem Domain specific classes, attributes and methods.
User Interface Design is the first step that focuses on the Technical Domain aspects of the problem, and involves taking the Use Cases as defined earlier, and designing a Graphical User Interface appropriate to the Technical Architecture chosen for the project (MS Windows, X/Motif, etc.). Typically you would expect to find one controlling dialog box (which may use other subsidiary dialogs) for each Use Case in the system. Some prototyping may be appropriate at this point in the project. For small projects, prototyping and UI design may be undertaken in parallel with Use Case development.
Technical Domain, High Level Design focuses on adding classes to meet the technical needs of the project, and is driven by the technical architecture of the project. Classes may be GUI related, DBMS (object or relational) related, distribution related (CORBA, DCOM, etc.), external systems related, or may provide an interface to internal system components such as printers. Previous Sequence Diagrams may be updated to confirm the validity of the technical design - in particular you would expect to see GUI classes appearing between the System Boundary and the Problem Domain classes.
Finally, Detailed Technical Design, looks at link implementations, detailed data typing of attributes, full specification of all methods (including parameters), etc. The end result is a complete design of the full system.
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:
Figure 13 - Seperation Of Problem and Technical Domain Components of a System For smaller projects (one or two persons for a couple of months) the two domains may be merged, if desired. As mentioned previously, Use Cases may be used in phasing a project; the process shown earlier does not prohibit this. A project with 50 Use Cases could be structured in three phases as shown in figure 14:
Figure 14 - Evolutionary Phasing Of OO Project The object-based structure of the application lends itself well to this approach.
better modelling of the problem domain (equals happier users) better overall software design with a strong focus on class structure more flexible and maintainable systems through better class partitioning good documentation (the notations) - and a single central overall design notation (the Object Model)
a flexible approach to project phasing assistance in tie-ing down requirements, and less work (in the long run)
Mark Collins-Cope is Technical Director at Ratio Group Ltd., a consultancy and training 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.