Diagramy tříd
1
Diagram tříd (class diagram)
Zobrazuje třídy v daném systému a vztahy mezi nimi Zobrazuje statický stav – ukazuje vzájemné interakce, ale neukazuje co se při těchto interakcích děje Při znázornění vztahů (vazeb) je možné zaznamenat i jejich násobnosti Složitější systémy je možné zobrazovat "ve větším měřítku" – pomocí tzv. balíčků 2
Vizualizace třídy
3
Odpovědnosti, požadavky a omezení
4
Asociace tříd
Asociace – zachycení vztahů mezi instancemi tříd V UML diagramu tříd se zachycuje jako nepřerušovaná čára, případně s orientací (tzv. navigabilita – průchodnost – podporuje rychlý přechod na instance druhé třídy) Konce asociace mohou popisovat role daných tříd v asociaci Násobnosti – specifikují, kolikrát se daná třída může ve vztahu vyskytovat: − − − −
1..1 právě jednou 0..1 nejvýše jednou 1..* nejméně jednou 0..* libovolně krát
5
Asociace tříd
popis role třída
asociace název asociace násobnost
6
Asociace jako třídy
Někdy má samotná asociace tříd další vlastnosti, které je vhodné uchovávat mimo asociované třídy, např. v případě golfového míčku by to mohla být informace o hrách, které hráč s daným míčkem absolvoval Pak je vhodné zobrazit asociaci jako třídu a dát jí potřebné další atributy či metody Asociace jako třída se zobrazuje pomocí diagramu třídy, od něhož vede čárkovaný spoj k samotné asociaci 7
Asociace jako třídy
asociace jako třída 8
Motivace k dědičnosti
Existuje řada případů, kdy potřebujeme pracovat s objekty, které jsou „příbuzné“ – mají některé atributy stejné Je zbytečné je znovu programovat Atributy a metody můžeme zdědit od jiné třídy (jiných tříd) Jednodušší a spolehlivější údržba programu po jednotlivých třídách ... 9
Hierarchie tříd
Nadtřída (od ní se dědí) – základní třída, rodič Podtřída (dědí od nadtřídy) – odvozená třída, potomek Zjištění existence vztahu mezi třídami: test „je“ (např. pokud má smysl věta: „je golfový míček zboží?“, pak třída golfového míčku může zdědit vlastnosti od třídy zboží) 10
Typy dědičnosti
Jednoduchá dědičnost – potomek dědí vlastnosti od jednoho rodiče Vícenásobná dědičnost – potomek dědí vlastnosti od více rodičů – mělo by být dodrženo, že každá rodičovská třída projde testem „je“ a že rodičovské třídy jsou na sobě nezávislé – mohou vznikat problémy Opakované použití jednoduché dědičnosti 11
Dědičnost, zobecnění,…
12
Abstrakce a abstraktní třídy
Abstrakce je způsob, kterým může programátor nadtřídy donutit programátora podtřídy, aby znovu definoval metodu nebo třídu (v C++ se používá např. klíčové slovo abstract pro danou metodu) Abstraktní metoda nemusí mít žádné tělo Abstraktní třída je třída, kterou je možno použít jako nadtřídu, ale nelze vytvářet její instance. 13
Mnohotvarost (polymorphism)
Mnohotvarost: prostředek, jehož pomocí může být jediný název operace nebo atributu definován na základě více než jedné třídy a může nabývat různých implementací v každé z těchto tříd Mnohotvarost: vlastnost, jejímž prostřednictvím může atribut nebo proměnná ukazovat (obsahovat identifikátor) na objekty různých tříd v různých okamžicích Přepisování (overriding): změna definice metody zadané ve třídě T v jedné z podřízených tříd třídy T Přetěžování (overloading) názvu nebo symbolu: daný název nebo symbol má několik operací (či operátorů) definovaných v jedné třídě Např.: "a" * 3 , 3 * "a"
14
Zapouzdření – základ pro ochranu atributů a metod
Zapouzdření: seskupení souvisejících idejí (vlastností, chování,…) do jedné jednotky, na kterou se lze následně odkazovat jediným názvem Objektově orientované zapouzdření: zabalení operací (metod) a atributů představující nějaký stav do jednoho objektu, takže daný stav je přístupný či upravitelný pouze prostřednictvím rozhraní poskytovaného zapouzdřením (tedy pomocí operací či metod)
15
Ochrana atributů a metod pomocí specifikátorů přístupu
Specifikátor přístupu je (zpravidla) klíčové slovo programovacího jazyka, které říká, jaká část programu může přistupovat k atributům a metodám Typy přístupů: − − −
veřejný (public) – dostupné komukoliv soukromý (private) – dostupné jen v rámci dané třídy chráněný (protected) – dostupné v rámci dané třídy a jejích potomků, pro zbytek světa se chovají jako soukromé
16
Specifikátory přístupu v UML
17
Konstruktory a destruktory
Konstruktor je speciální metoda, která slouží k vytvoření instance dané třídy a často také k inicializaci atributů instance Destruktor je speciální metoda, která uvolňuje všechny prostředky, které daná instance (objekt) používá (např. paměť) Některé jazyky mají automatickou správu paměti (např. Java, Python), některé ne (např. C++) a je na programátorovi, aby správně definoval příslušné destruktory 18
Konstruktory a destruktory v UML
19
Agregace tříd
Agregace tříd (seskupení) – asociace, která označuje, z jakých částí se skládá celek Celek se nazývá agregační (seskupený) objekt, jeho části pak konstituční (tvořící) objekty Charakteristiky agregace: − − −
seskupený objekt může existovat bez svých tvořících objektů objekt může být tvořícím i pro více seskupení agregace bývá homeometrická – konstituenti budou pravděpodobně stejného typu
20
Agregace tříd seskupený objekt/třída
násobnost tvořící objekt/třída
diagram agregace 21
Kompozice tříd
Kompozice tříd (složení) – silnější typ agregace – asociace, která označuje, z jakých částí se skládá celek Celek se nazývá kompozitní (složený) objekt, jeho části pak komponentní (složkové) objekty Charakteristiky kompozice: − − −
složený objekt neexistuje bez svých komponent každý objekt komponenty může být v daný okamžik součástí jen jedné kompozice kompozice bývá heterometrická – komponenty budou pravděpodobně různých typů 22
Kompozice tříd složený objekt/třída diagram kompozice
složka
násobnost
23
Omezení asociací
omezení: zde výběr jedné nebo druhé komponenty 24
Kontexty
Někdy je výhodné nebo potřebné zabývat se daným systémem ve vztahu (v kontextu) k některé jeho specifické části, která má svou vnitřní strukturu Lze použít složený kontextový diagram třídy – tj. diagram třídy s dalším diagramem tříd zakresleným uvnitř – viz příklad Diagram kontextu systému zachycuje systém v kontextu určité třídy (s důrazem na určitou třídu) – ta je zachycena složeným kontextovým diagramem – viz příklad 25
Kontext a složený kontextový diagram v UML
26
Rozhraní a realizace
Některé třídy mohou mít stejné nebo podobné chování, ačkoliv nemají společného rodiče Operace (i jejich kód) pro jednu takovou třídu bychom mohli použít i u ostatních nebo vytvořit skupinu operací, která je společná více třídám Rozhraní je (opakovaně použitelná) skupina operací, která specifikuje určitý aspekt chování třídy a které třída používá ve vztahu k jiným třídám Říkáme, že třída realizuje rozhraní, když rozhraní představuje souhrn (ne nutně všech) operací, které třída provádí Třída může realizovat i více něž jedno rozhraní a rozhraní může být realizováno i více než jednou třídou. 27
Rozhraní a realizace v UML
28
Diagramy případů užití
29
Diagram případů užití (use case diagram)
Vysvětluje, co systém dělá z pohledu vnějšího pozorovatele a uživatele Důraz je kladen na to, co systém dělá – spíše než na to, jak to dělá Diagramy případů užití jsou podobné scénářům Jsou užitečné: − − −
pro specifikaci vlastností systému (požadavků na systém) usnadňují komunikaci s klienty při vývoji pomáhají sestavit sady testovacích úloh 30
Proč používat případy užití
Pro uživatele není vždy snadné formulovat, jak budou systém využívat Do počáteční analýzy a návrhu systému je důležité zapojit také budoucí uživatele systému Případ užití vede potenciální uživatele systému k tomu, aby o systému hovořili ze své pozice Cílem je navrhnout systém tak, aby byl pro uživatele prospěšný a dobře použitelný 31
Případy užití
Případ užití je soubor scénářů pro používání systému Každý ze scénářů popisuje sled (sekvenci) událostí Každou sekvenci inicializuje osoba, jiný systém, část hardwaru nebo uplynutí určitého času (tzv. participanti - účastníci) Výsledkem sekvence musí být něco, co používá buď participant, který sekvenci inicializoval, nebo jiný participant 32
Kreslení diagramů případů užití
Případ užití – elipsa Uživatel (participant, účastník) – panáček Propojení případu užití s uživatelem – plná čára Uživatelé zpravidla stojí vně systému a případy užití se zakreslují dovnitř obdélníku V obdélníku by měl být přehledně zapsán název systému Uživatel, který provede akci, jež spustí případ užití, se zpravidla kreslí vlevo, uživatel, který obdrží výstup z případu užití, se kreslí vpravo 33
Ukázka: diagram případů užití tiskárny
34
Ukázka: diagram užití tiskárny
35
Ukázka: diagram užití tiskárny
36
Ukázka: diagram užití tiskárny
37
Ukázka: diagram užití tiskárny
38
Ukázka: diagram užití tiskárny
39
Vkládání případů užití
Některé případy užití se opakují a jsou součástí jiných případů užití (např. při opravě je nutné nejprve otevřít kryt tiskárny, stejně jako při výměně spotřebního materiálu) Tyto opakující se případy užití je možné pojmenovat a vložit je do jiných případů užití Vkládaný případ užití nikdy neexistuje samostatně – je vždy součástí jiného případu užití Diagramem vkládání případu užití je čárkovaná šipka označená stereotypem <
> (<>) 40
Příklad na vkládání případu užití
41
Rozšiřování případu užití
Opakovaně je možné použít případ užití i tak, že ke stávajícímu případu užití přidáme další kroky – případy užití (např. součástí opravy tiskárny může být také její vyčištění a otestování) Tyto další případy užití (tzv. rozšíření) je možné pojmenovat a rozšířit o ně stávající případy užití Původní případy užití se označují také jako základní Rozšíření je možné provést jen na určitých místech – bodech rozšíření Diagramem rozšiřování případu užití je čárkovaná šipka označená stereotypem <<extend> (<>) 42
Příklad na rozšiřování případu užití
43
Příklad s označením systému
44
Příklad se zakreslením autora a příjemce
45
Zobecnění a seskupování
Zobecnění případu užití funguje podobně, jako u tříd Vztah zobecnění můžeme použít i mezi účastníky Seskupovat můžeme podobné případy užití – zakreslují se opět do diagramu balíčku
46
Příklad na zobecnění
47
Místo diagramů případů užití v analýze
Kroky při analýze: −
−
rozhovory s klientem – vzniknou diagramy tříd (zmapování domény systému, tj. oblasti, kde systém pracuje) rozhovory s uživateli – postupně se převezme terminologie:
odhalit jednotlivé účastníky, funkce systému a základní případy užití popisující funkce systému – zjistí se hranice systému a jeho rozsah - diagram vysokoúrovňových případů užití podrobnější popis každého požadavku na systém – vzniknou další, podrobnější diagramy případů užití 48
Stavové diagramy
49
Diagram stavů (statechart diagram)
Zobrazuje možné stavy určitého objektu Zobrazuje přechody mezi nimi, včetně možných akcí, které je nutno provést při těchto přechodech Zobrazuje počáteční a koncové stavy Je schopný popsat časové změny UML modelu Bývá také označován jako stavový stroj 50
Diagramy stavů
51
Podrobnější informace o přechodu
52
Složený stav a sekvenční podstavy
Někdy je nutné podrobněji zachytit chování v určitém stavu Podstavy mohou popisovat jednotlivé změny Mohou se cyklicky opakovat Pokud nastávají jeden po druhém, hovoříme o sekvenčních podstavech
53
Složený stav a sekvenční podstavy
54
Souběžné podstavy
Některé složené stavy obsahují několik souběžných procesů Každý z těchto procesů je možné zachytit pomocí stavového diagramu (např. jako sekvenční podstavy) Souběžným procesům odpovídají souběžné stavy Ve složeném stavu se souběžné procesy oddělují čárkovanou čarou 55
Souběžné podstavy
56
Ukládaný stav
Někdy je důležité pamatovat si, co se dříve odehrálo (např. jak se uživatel již jednou rozhodl, abychom se ho nemuseli ptát stále znovu na stejnou věc) Ukládaný stav – pamatuje si historii Hluboký ukládaný stav – pamatuje si celou historii (označuje se H* v kroužku – jde o pseudostav) Mělký ukládaný stav – pamatuje si jen podstav v dané úrovni (označuje se H v kroužku – jde o pseudostav) 57
Ukládaný stav
58
Zprávy a signály
Přechod z jednoho stavu do jiného bývá startován nějakou zprávou mezi objekty (např. při stisku tlačítka zprávou od uživatele, zprávou od časovače po uplynutí nějakého času apod.) Zpráva, která spustí stavový přechod se na nazývá signál Signál je v zásadě také objekt – má své atributy a operace, lze z něj dědit,… Přechod bez spouštěcí události může nastat, když skončí akce 59
Místo stavových diagramů v analýze
Diagramy stavů: − − − −
zachycují dynamiku změn objektů mohou být složité – odpovídají složitosti popisovaného systému pomáhají analytikům i vývojářům pochopit chování objektů v systému usnadní implementaci objektů a jejich chování v systému (to nakonec výrazně pomůže vývojářům v jejich práci)
60
Literatura 1.Enterprise Architect. dostupné z: http://www.sparxsystems.com.au/ 2. Schmuller, J. Myslíme v jazyku UML. Knihovna programátora. 1. vyd. Praha: Grada, 2001. ISBN 80247-0029-8 3. Keogh, J., Giannini, M. OOP bez předchozích znalostí: průvodce pro samouky. 1. vyd. Computer Press. Brno: 2006. ISBN 80-251-0973-9. 4. Harms, D., McDonald, K. Začínáme programovat v jazyce Python. 1. vyd. Computer Press. Brno: 2003. ISBN 80-7226-799-X. 5. Python.org documentation. URL: http://python.org/doc/ 6. Švec, J. Létající cirkus: Python tutoriál. URL: http://www.root.cz/data/letajici_cirkus.pdf
61
