Programovßnφ, stejn∞ jako mnohΘ dalÜφ oblasti lidskΘ Φinnosti, mß svß "hesla dne" a kdo se jimi nezaklφnß, nenφ zkrßtka "in". M≤dnφ konjunktura takovΘho hesla ale neznamenß, ₧e se za nφm nem∙₧e skr²vat u₧iteΦnß v∞c - a prßv∞ tak je tomu s trojicφ pφsmenek, o nφ₧ se mluvφ stßle vφce: UML.
Co (a na co) je UML
Zkratka UML pochßzφ z anglickΘho Unified Modeling Language, a znamenß tedy "sjednocen² modelovacφ jazyk". Ne₧ vysv∞tlφme, o co jde, zaΦneme trochu zeÜiroka.
Ka₧d² program, ka₧dß softwarovß aplikace p°edstavuje vlastn∞ poΦφtaΦov² model n∞jakΘho problΘmu. ProgramovΘ vybavenφ zabezpeΦujφcφ chod elektronickΘho obchodu musφ modelovat chod tohoto obchodu; program, kter² °φdφ vst°ikovßnφ do spalovacφho motoru, p°edstavuje model toku paliva tφmto motorem. Platφ to dokonce i pro akΦnφ poΦφtaΦovΘ hry - t°eba dnes u₧ skoro zapomenut² Doom p°edstavuje model jakΘsi zßkladny napadenΘ zl²mi p°φÜerami. N∞kterΘ modely mohou b²t zjednoduÜenΘ, jinΘ musφ p°esn∞ odpovφdat skuteΦnosti - to zßvisφ na okolnostech.
K tomu, abychom mohli napsat dobrou aplikaci, musφme nejprve pochopit °eÜen² problΘm. To znamenß, ₧e musφme pochopit, jak bude pou₧φvßn systΘm, ve kterΘm naÜe aplikace pob∞₧φ nebo kter² modeluje, jakΘ t°φdy objekt∙ se v systΘmu vyskytujφ a jakΘ jsou jejich vzßjemnΘ vztahy, jakΘ instance t∞chto t°φd jsou pot°eba, jak²mi stavy m∙₧e nßÜ systΘm prochßzet a jak mohou tyto stavy za sebou nßsledovat, jakΘ Φinnosti a v jakΘm po°adφ systΘm vykonßvß a mnohΘ dalÜφ. Ukßzalo se toti₧, ₧e sprßvn∞ pochopit ·lohu a zjistit, oΦ v nφ jde, je mo₧nß kardinßlnφ problΘm programovßnφ. Je to n∞kdy t∞₧Üφ, ne₧ vytvo°it celou implementaci. (P°irovnßme-li tvorbu softwaru ke stavebnictvφ, nabφzφ se provokativnφ otßzka: Je dneÜnφ programßtor spφÜe architekt domu, stavbyvedoucφ, nebo zednφk? Anebo - jak tomu takΘ b²vß - vÜechno dohromady?)
VÜimn∞te si, ₧e zatφm stßle hovo°φme o systΘmu, nikoli o programu. V tΘto fßzi nßm toti₧ jde o pochopenφ °eÜenΘho problΘmu, tedy o vytvo°enφ modelu - t°eba na papφ°e nebo pomocφ obrßzk∙ a text∙ v poΦφtaΦi, nikoli jeÜt∞ o vlastnφ programovßnφ. A prßv∞ tady je "parketa" pro UML.
Modelovacφ jazyk UML je souhrn r∙zn²ch diagram∙, kterΘ popisujφ jednotlivΘ aspekty modelovanΘho systΘmu a tak umo₧≥ujφ tento systΘm pochopit. Je jasnΘ, ₧e UML musφ b²t nezßvisl² na programovacφm jazyku, kter² nakonec k °eÜenφ ·lohy pou₧ijeme - mlΦky ovÜem p°edpoklßdß, ₧e tento jazyk bude objektov∞ orientovan². (Programßto°i pou₧φvajφcφ Φist∞ objektovΘ jazyky, jako t°eba CLOS nebo Smalltalk, si ovÜem st∞₧ujφ, ₧e jim v UML chybφ delegovßnφ, zßvislosti, metat°φdy a dalÜφ v∞ci, kterΘ tyto jazyky poskytujφ, a dodßvajφ, ₧e UML je Üit² na mφru hybridnφm jazyk∙m typu C++.)
Vytvß°enφ diagram∙ tu₧kou na papφ°e by ovÜem bylo pracnΘ a v praxi nepou₧itelnΘ. Na trhu se proto vyskytuje °ada editor∙ UML, od freewarov²ch nebo lacin²ch sharewarov²ch a₧ po velice drahΘ profesionßlnφ nßstroje. ╪ada z nich takΘ umo₧≥uje na zßklad∞ t∞chto diagram∙ generovat zdrojov² k≤d, tedy p°edevÜφm kostry t°φd a jejich metod. PokroΦilejÜφ nßstroje zvlßdajφ i zp∞tnΘ in₧en²rstvφ - to znamenß, ₧e z hotovΘho zdrojovΘho textu programu dokß₧φ vytvo°it n∞kterΘ z diagram∙ UML.
Trocha historie
Ne₧ se pustφme do povφdßnφ o jednotliv²ch diagramech, kterΘ v UML pou₧φvßme, podφvejme se na n∞kterΘ historickΘ souvislosti. U₧ jsme °ekli, ₧e UML p°edpoklßdß objektovou orientaci, a proto p°eskoΦφme prehistorii a zaΦneme ve druhΘ polovin∞ Üedesßt²ch let, kdy objekty vstupujφ na scΘnu.
V roce 1966 publikovali O.-J. Dahl a K. Nygaard prvnφ objektov∞ orientovan² jazyk Simula. O rok pozd∞ji dali k dispozici upravenou verzi, pozd∞ji oznaΦovanou Simula 67. èlo o rozÜφ°enφ jazyka Algol 60, ve kterΘm se objevily t°φdy, d∞diΦnost i polymorfismus; sl∙vko "objekt" se zde sice jeÜt∞ nepou₧φvalo, ale to na v∞ci nic nem∞nφ.
Na konci 60. let byly takΘ poprvΘ zve°ejn∞ny prßce, kterΘ se zab²valy sprßvnostφ softwaru - vzpome≥me alespo≥ na znßm² Dijkstr∙v Φlßnek o Ükodlivosti skok∙ [1], kter² vyvolal °adu diskusφ a dnes u₧ pat°φ ke "klasice" programßtorskΘ literatury. Z tΘto doby pochßzejφ takΘ jeho myÜlenky o tvorb∞ softwaru ve vrstvßch abstrakcφ a po₧adavek maximßlnφ nezßvislosti, maximßlnφho odd∞lenφ t∞chto vrstev. Jde vlastn∞ o zapouzd°enφ, jednu z podstatn²ch idejφ objektov∞ orientovanΘho programovßnφ.
V tΘ₧e dob∞ se takΘ objevujφ prvnφ ·vahy o softwarovΘ krizi - v²poΦetnφ kapacita poΦφtaΦ∙ rapidn∞ rostla, ale zp∙sob tvorby program∙ od konce padesßt²ch let, od p°φchodu Fortranu a dalÜφch vyÜÜφch programovacφch jazyk∙, v podstat∞ nijak nepokroΦil. Rozsah program∙ ovÜem prudce nar∙stal a s tφm i mno₧stvφ chyb v nich - a takΘ rozsah Ükod, kterΘ tyto chyby zp∙sobily. Teoretici pak formulujφ mj. po₧adavky na robustnost a znovupou₧itelnost vytvo°enΘho k≤du.
V sedmdesßt²ch letech se objevily prvnφ "malΘ" poΦφtaΦe a s nimi idea grafickΘho u₧ivatelskΘho rozhranφ operaΦnφho systΘmu. V²vojov² t²m firmy Xerox ve v²zkumnΘm st°edisku v Palo Alto (PARC), v n∞m₧ pracovali mj. A. Kay a A. Goldbergovß, se pokusil pro jeden z poΦφtaΦ∙ takov²to operaΦnφ systΘm vyvinout; vedlejÜφm produktem (ovÜem nikoli co do v²znamu) byl prvnφ Φist∞ objektov² programovacφ jazyk Smalltalk. Zde se poprvΘ objevuje termφn "objekt"; tento jazyk takΘ p°ichßzφ s ideou programu slo₧enΘho v²hradn∞ z objekt∙ (instancφ t°φd), kterΘ ned∞lajφ nic jinΘho, ne₧ ₧e si posφlajφ zprßvy.
V pr∙b∞hu osmdesßt²ch let p°ichßzejφ na scΘnu osobnφ poΦφtaΦe; jejich nßstup znamenß prudkΘ rozÜφ°enφ softwarovΘho trhu a urychlenφ v²voje, a to jak hardwaru a softwaru, tak i teorie. ObjektovΘ programovßnφ se zaΦφnß z teorie p°esunovat do praxe - nikoli ovÜem zßsluhou Smalltalku, ale dφky smφÜen²m jazyk∙m, jako byl Turbo Pascal nebo C++. Tv∙rci t∞chto jazyk∙ se samoz°ejm∞ Simulou i Smalltalkem inspirovali, ale tφm, ₧e vytvo°ili jazyk, kter² objektovΘ myÜlenφ striktn∞ nevy₧adoval, poskytli praktick²m programßtor∙m Φas na p°echod od strukturovanΘho programovßnφ k p°ijetφ nov²ch programovacφch paradigmat. Pod tlakem nabφdky objektov²ch knihoven - nap°. pro tvorbu grafickΘho u₧ivatelskΘho rozhranφ program∙, jako jsou MFC nebo OWL - zßrove≥ praktiΦtφ programßto°i pochopili, ₧e p°ed objekty "nenφ ·niku", a ₧e by se s nimi tedy p°ece jen m∞li zaΦφt seznamovat.
Koncem osmdesßt²ch a zaΦßtkem devadesßt²ch let se mnoh²m zdßlo, ₧e prßv∞ objektov∞ orientovanΘ programovßnφ p°edstavuje °eÜenφ softwarovΘ krize. Praxe ovÜem ukazuje, ₧e samotnΘ objekty nestaΦφ, ₧e i objektov∞ vytvo°enΘ programy mohou b²t ÜpatnΘ. Ze zkuÜenosti vφme, ₧e Üpatn∞ navr₧en² objektov² program m∙₧e b²t h∙°e udr₧ovateln² a upravovateln² ne₧ Üpatn∞ navr₧en² program strukturovan². (èpatn∞ navr₧en² objektov² program je nap°φklad takov², ve kterΘm je nepo°ßdek v k≤du, funkce jsou nelogicky rozesety po r∙zn²ch objektech, obsahuje nemnemotechnickß Φi p°φmo nesmyslnß pojmenovßnφ, najdeme v n∞m nelogickΘ zßvislosti Φßstφ programu mezi sebou. Mezi typickΘ chyby takΘ pat°φ nesprßvnΘ aplikovßnφ vazeb - nap°. chybnΘ pou₧itφ d∞d∞nφ v p°φpadech, kdy se naprosto nehodφ).
Ukßzala se tedy pot°eba vytvo°it nßstroje pro objektovou anal²zu a nßvrh program∙ - podobn∞ jako se od sedmdesßt²ch let s ·sp∞chem vyu₧φvaly metody pro strukturovanou anal²zu a nßvrh. (P°ipome≥me si nap°. Jacksonovy diagramy a nßstroje CASE na nich zalo₧enΘ - mnohΘ z nich se pou₧φvajφ dodnes.) Na p°elomu osmdesßt²ch a devadesßt²ch let se skuteΦn∞ °ada navzßjem si konkurujφcφch metod pro objektov∞ orientovanou anal²zu a nßvrh objevila a s nimi takΘ prvnφ nßstroje CASE, kterΘ je vyu₧φvaly. Zmφnφme se alespo≥ krßtce o n∞kter²ch z nich.
Z prost°edφ Smalltalku a firmy Xerox pochßzejφ karty CRC (Class-Responsibility-Collaboration). Jsou to papφrovΘ lφstky, na nich₧ jsou popisy t°φd, p°φp. instancφ, a zprßvy, kterΘ mohou odeslat; jejich pomocφ se vytvo°φ model systΘmu a testuje se jeho sprßvnost.
Nßvrhy metod pro objektovou anal²zu a nßvrh vytvo°ili P. Coad, E. Yourdon, J. Odell a dalÜφ. Jednu z ·sp∞Ün²ch metod vypracoval G. Booch p°i v²voji systΘm∙ v jazyce Ada ve svΘ firm∞ Rational Software; publikoval ji v na poΦßtku 90. let v knize [2].
J. Rumbaugh vedl v²vojov² t²m ve v²zkumn²ch laborato°φch firmy General Electric. V²sledkem jeho prßce byla Objektovß modelovacφ metoda (Object Modeling Technique, OMT), publikovanß poprvΘ v r. 1991 [3].
I. Jacobson, autor metody Objectory, vychßzel ze zkuÜenostφ, kterΘ zφskal u spoleΦnosti Ericsson p°i modelovßnφ telefonnφch za°φzenφ. Jako prvnφ zavedl pojem "p°φpad u₧itφ" (use case) [4].
V²voj pokraΦoval a v polovin∞ devadesßt²ch let u₧ existovala nep°ehlednß °ada metod pro objektovou anal²zu a nßvrh a takΘ °ada navzßjem se potφrajφcφch metodik∙. Konsorcium OMG proto p°iÜlo se snahou o standardizaci, jak se zdßlo, dosti beznad∞jnou - °ad∞ lidφ byla protivnß i jen samotnß idea standardizace. (Jeden vtip z tΘ doby, tedy jeÜt∞ p°ed 11. zß°φm 2001: Jak² je rozdφl mezi teroristou a - nejen objektov²m - metodikem? S teroristou se n∞kdy dß vyjednßvat.)
V roce 1994 ale J. Rumbaugh opustil GE a p°ipojil se k G. Boochovi a jeho firm∞ Rational Software. O rok pozd∞ji prohlßsili, ₧e "vßlka o metody skonΦila, my jsme vyhrßli"; z°ejm∞ se tak cht∞li pokusit o prosazenφ standardizace po zp∙sobu n∞kter²ch velk²ch firem. ╪ada metodik∙ pochopiteln∞ ihned zaΦala formovat antiboochovskou koalici...
V roce 1995 pak G. Booch a J. Rumbaugh publikovali "unifikovanou metodu" (Unified Method) verze 0.8. V tΘ dob∞ se k nim p°ipojil i I. Jacobson. O rok pozd∞ji se skupina OMG zaΦala znovu sna₧it o dosa₧enφ standardizace na poli metodik objektovΘ anal²zy a nßvrhu a na jejφ v²zvu p°edlo₧ila °ada firem svß °eÜenφ - Rational Software p°isp∞la p°epracovanou verzφ svΘ unifikovanΘ metody pod oznaΦenφm UML 1.0. Jako oficißlnφ standard pak pracovnφ skupina OMG p°ijala verzi 1.1, kterß vznikla slouΦenφm UML 1.0 s n∞kter²mi dalÜφmi nßvrhy. Nßsledovalo jeÜt∞ n∞kolik dalÜφch revizφ, a₧ se v roce 1999 objevila verze 1.3. V²voj UML vÜem zdaleka nenφ uzav°en.
Jako perliΦku uve∩me, ₧e pro G. Boocha, J. Rumbaugha a I. Jacobsona se postupn∞ ujala anglicko-Üpan∞lskß p°ezdφvka The Three Amigos, co₧ je narß₧ka na jak²si film (v LatinskΘ Americe se pr² pou₧φvß podobn∞ dvojjazyΦn² p°eklad Los Tres Buddies). U nßs se v poslednφ dob∞ objevil pon∞kud posm∞Ün² nßzev svatß trojice, nejspφÜ jako reakce na skuteΦnost, ₧e knihy o UML, ke kter²m napφÜe n∞kdo z nich p°edmluvu a na jejich₧ obßlce je logo obsahujφcφ jejich jmΘna, se prodßvajφ nejen podstatn∞ lΘpe, ale i podstatn∞ drß₧...
Vra¥me se ale k UML. I kdy₧ jsme v p°edchozφm textu hovo°ili p°edevÜφm o metodikßch, samotn² jazyk UML ₧ßdnou metodiku neobsahuje. UML je nßstroj pro zßpis v²sledk∙ anal²zy a nßvrhu - tedy jazykov∞ nezßvislΘho modelu - a metodiku, podle nφ₧ budeme anal²zu a nßvrh provßd∞t, si musφme zvolit. Firma Rational Software navrhla v rßmci UML tzv. "racionßlnφ unifikovan² proces" (Rational Unified Process, RUP; p°eklad "unifikovan² proces firmy Rational" by vÜak mo₧nß byl v²sti₧n∞jÜφ). Vedle toho ovÜem existuje i °ada dalÜφch metod, kterΘ vznikly na mnoha pracoviÜtφch po celΘm sv∞t∞ a typicky odrß₧ejφ specifika problΘm∙, se kter²mi se tamnφ v²vojß°i setkßvajφ. My zde ovÜem nechceme hovo°it o metodikßch, ale p°edevÜφm o vlastnφm UML.
Diagramy v UML
U₧ jsme si °ekli, ₧e model v UML se sklßdß z °ady diagram∙, kterΘ popisujφ nejr∙zn∞jÜφ aspekty °eÜenΘho problΘmu. Podφvejme se tedy alespo≥ v krßtkosti na n∞kterΘ z nich.
P°φpady u₧itφ
Diagram p°φpad∙ u₧itφ pomßhß pochopit, jak bude dan² systΘm pou₧φvßn, k Φemu slou₧φ. M∙₧eme se na n∞j dφvat jako na grafickΘ vyjßd°enφ vÜech mo₧n²ch scΘnß°∙ nebo zp∙sob∙ pou₧itφ systΘmu u₧ivateli.
AktΘr a p°φpad u₧itφ
Diagram p°φpad∙ u₧itφ obsahuje dv∞ zßkladnφ ikony: P°φpad u₧itφ (use case, setkßme se takΘ s p°ekladem "u₧itnß Φinnost") a aktΘr (tΘ₧ "·Φastnφk", "participant", anglicky actor; ·dajn∞ jde o Üpatn² p°eklad ze ÜvΘdÜtiny, p∙vodn∞ se tato entita m∞la jmenovat role). P°φpad u₧itφ se znßzor≥uje ovßlem, v n∞m₧ je zapsßna Φinnost, kterou systΘm - na podn∞t aktΘra - provede, nebo Φinnost, jejφ₧ v²sledek aktΘr obdr₧φ a p°φpadn∞ n∞jak vyu₧ije. AktΘr se znßzor≥uje schematickou figurkou Φlov∞ka, k nφ₧ b²vß p°ipojen struΦn² popis jeho role. Obrßzek 1 obsahuje dva aktΘry a jeden p°φpad u₧itφ.
Poznamenejme, ₧e n∞kterΘ editory UML zapisujφ Φinnost p°φpadu u₧itφ pod ikonu, nikoli do nφ.
AktΘr a systΘm
D∙le₧itΘ je, ₧e aktΘrem m∙₧e b²t kdokoli nebo cokoli, co interaguje s modelovan²m systΘmem - m∙₧e to b²t nap°. dalÜφ program, z hlediska naÜeho systΘmu chßpan² jako externφ, m∙₧e to b²t datov² zdroj atd. Nemusφ to tedy b²t jen Φlov∞k.
P°itom si musφme uv∞domit, ₧e aktΘr nenφ souΦßstφ modelovanΘho systΘmu. Nalezenφ vÜech aktΘr∙ vÜak m∙₧e poslou₧it k p°esnΘmu vymezenφ hranic systΘmu - tato hranice se do diagramu p°φpad∙ u₧itφ obΦas takΘ zakresluje jako Φßra odd∞lujφcφ vÜechny p°φpady u₧itφ od aktΘr∙.
Vztah mezi aktΘrem a p°φpadem u₧itφ se znßzor≥uje Φarou, kterß je spojuje. Zpravidla se vlevo od p°φpadu u₧itφ zakresluje aktΘr, kter² p°φpad u₧itφ vyvolß, a vpravo aktΘr, kter² p°ijme v²slednß data. (To nemusφ b²t t²₧ aktΘr: Jeden Φlov∞k m∙₧e dßt p°φkaz, aby banka vyplatila z jeho ·Φtu penφze n∞komu jinΘmu. Plßtce je zde jeden aktΘr, p°φjemce pen∞z je jin² aktΘr, jak ukazuje obr. 1.)
Typick² diagram p°φpad∙ u₧itφ ovÜem na rozdφl od naÜeho obrßzku obsahuje desφtky aktΘr∙ a desφtky nebo stovky p°φpad∙ u₧itφ.
Diagram p°φpad∙ u₧itφ m∙₧e takΘ vyjad°ovat vztahy mezi r∙zn²mi p°φpady u₧itφ. Jestli₧e se urΦitß Φinnost opakuje jako souΦßst n∞kolika p°φpad∙ u₧itφ, lze ji vyjßd°it samostatnou ikonou a pak na ni v dalÜφch p°φpadech u₧itφ odkßzat; hovo°φme o vztahu zahrnovßnφ (anglicky include). Kdybychom z∙stali u p°φkladu bankovnφho systΘmu a pokraΦovali v anal²ze, zjistili bychom, ₧e vyplacenφ pen∞z je jen jedna z mnoha Φinnostφ, kterΘ tento systΘm umφ. DalÜφ bude nap°. p°ipsßnφ ·rok∙, p°evod pen∞z atd. VÜechny tyto operace ale budou zahrnovat nap°. kontrolu stavu ·Φtu.
Tento vztah v diagramu p°φpad∙ u₧itφ vyjad°ujeme Φßrkovanou Üipkou sm∞°ujφcφ k ovßlu zahrnovanΘho p°φpadu u₧itφ, k nφ₧ p°ipφÜeme slovo "include" nebo "zahrnuje" v t∞chto podivn²ch uvozovkßch. (Takov²mto popis∙m p°ipojen²m ke spojnicφm se v UML °φkß stereotyp a slou₧φ k up°esn∞nφ druhu vazby nebo typu prvku v diagramu.) P°φklad ukazuje obrßzek 2.
M∙₧e se takΘ stßt, ₧e jeden p°φpad u₧itφ p°edstavuje rozÜφ°enφ p∙sobnosti p°φpadu jinΘho; hovo°φme o vztahu rozÜi°ovßnφ (anglicky extend). V diagramech p°φpad∙ u₧itφ ho znßzor≥ujeme podobn∞ jako vztah zahrnovßnφ, pouze do stereotypu zapφÜeme slovo "extend" nebo "rozÜi°uje"; Üipka sm∞°uje od rozÜi°ujφcφho k "p∙vodnφmu" p°φpadu u₧itφ. P°itom obvykle specifikujeme i tzv. body rozÜφ°enφ, v nich₧ jsou k p∙vodnφmu p°φpadu u₧itφ p°idßny dalÜφ Φinnosti.
DalÜφm vztahem, kter² lze mezi p°φpady u₧itφ najφt, je generalizace (zobecn∞nφ), resp. - podφvßme-li se na to z druhΘ strany - specializace (zvlßÜtnφ p°φpad). Je to vztah velice podobn² d∞diΦnosti mezi t°φdami a znßzor≥uje se plnou Üipkou sm∞°ujφcφ k obecn∞jÜφmu p°φpadu u₧itφ. Z∙staneme-li u bankovnφho systΘmu, zjistφme, ₧e jak p°ipsßnφ ·rok∙, tak p°evod pen∞z bankovnφm p°φkazem majφ mnohΘ spoleΦnΘ rysy. PopφÜeme je tedy jako obecnou Φinnost "p°evod pen∞z" a p°ipsßnφ ·rok∙, stejn∞ jako p°evod p°φkazem z ·Φtu na ·Φet specifikujeme jako specializace tΘto obecnΘ Φinnosti.
Komentß°
Obrßzek 1 takΘ ukazuje, jak se v UML - nejen v diagramech p°φpad∙ u₧itφ - zapisujφ komentß°e: Text komentß°e je uzav°en v ikon∞ p°ipomφnajφcφ list papφru s ohnut²m rohem. K souΦßsti, jφ₧ se komentß° t²kß, je p°ipojena Φßrkovanou Φarou.
Diagramy t°φd a diagramy objekt∙
Diagramy t°φd jsou nejznßm∞jÜφ a nejspφÜ i nejpou₧φvan∞jÜφ z diagram∙ jazyka UML. Vyjad°ujφ t°φdy, kterΘ se v systΘmu vyskytujφ, a vztahy mezi nimi - d∞diΦnost, asociaci, agregaci atd. Diagramy objekt∙ jsou podobnΘ, zachycujφ vÜak objekty - tedy jednotlivΘ instance t°φd.
Ikona t°φdy a objektu
T°φdu v UML znßzor≥ujeme obdΘlnφkem, kter² v mß zßhlavφ zapsßno jmΘno t°φdy. Pod nφm, odd∞leny vodorovnou Φarou, jsou jmΘna atribut∙ - datov²ch slo₧ek - tΘto t°φdy. Pod atributy, op∞t pod vodorovnou Φarou, jsou jmΘna metod - tedy operacφ, kterΘ mohou b²t s instancemi provßd∞ny. U atribut∙ m∙₧eme vyznaΦit i jejich datov² typ: za jmΘno atributu p°ipφÜeme dvojteΦku a za ni oznaΦenφ typu.
U vÜech slo₧ek, tj. u atribut∙ i u metod, m∙₧eme takΘ vyznaΦit p°φstupovß prßva. Ve°ejn∞ p°φstupnΘ (public) slo₧ky oznaΦφme symbolem +, chrßn∞nΘ (protected) znakem # a soukromΘ (private) znakem -. Toto oznaΦenφ se zapisuje p°ed jmΘno slo₧ky.
Pokud nepot°ebujeme slo₧ky t°φdy vyznaΦovat, pou₧φvßme zjednoduÜenou ikonu, kterß obsahuje pouze jmΘno t°φdy.
╚asto takΘ pot°ebujeme znßzornit objekty, tj. instance naÜich t°φd. Ikona objektu je podobnß ikon∞ t°φdy, pouze v zßhlavφ obsahuje jmΘno objektu spolu se jmΘnem t°φdy a u atribut∙ m∙₧eme p°ipojit i jejich hodnoty. Obrßzek 3 ukazuje ·plnou a zjednoduÜenou ikonu t°φdy Bod, kterß reprezentuje bod ve dvourozm∞rnΘm prostoru, a ikonu instance tΘto t°φdy.
P°φÜt∞
Zatφm jsme se seznßmili s diagramem p°φpad∙ u₧itφ a zaΦali jsme si povφdat o diagramu t°φd a diagramu objekt∙. P°φÜt∞ povφdßnφ o diagramu t°φd dokonΦφme a podφvßme se na n∞kterΘ dalÜφ diagramy.
Vojt∞ch Merunka, Miroslav Virius
Odkazy
[1] Edsger W. Dijkstra: Go To Statement Considered Harmful. Communications of the ACM 11 (1968), Φ. 3, str. 147.
[2] Grady Booch: Object-Oriented Analysis and Design with Applications. 2nd edition. Addison-Wesley, 1994.
[3] James Rumbaugh a dalÜφ: Object-Oriented Modeling and Design. Prentice Hall, 1991.
[4] Ivar Jacobson a dalÜφ: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley 1992.
[5] Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language User Guide. Addison-Wesley, 1999.
[6] Martin Fowler: UML Distilled. 2nd Edition. Addison-Wesley, 2000.
[7] Joseph Schmuller: Myslφme v jazyku UML. Grada Publishing, Praha 2001.
[8] Meilir Page-Jones: Zßklady objektov∞ orientovanΘho nßvrhu v UML. Grada Publishing, Praha 2001.
