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 násobnost složka 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 <<include>> (<<vložit>>) 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> (<<rozšířit>>) 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 80-247-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