1

Diagramy tříd

2

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ů

3

Vizualizace třídy

4

Odpovědnosti, požadavky a omezení

5

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

6

Asociace tříd

třída asociace

název asociace

násobnost

popis role

7

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

8

Asociace jako třídy

asociace jako třída

9

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 ...

10

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ží)

11

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

12

Dědičnost, zobecnění,…

13

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.

14

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"

15

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)

16

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é

17

Specifikátory přístupu v UML

18

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

19

Konstruktory a destruktory v UML

20

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

21

Agregace tříd

seskupený objekt/třída

tvořící objekt/třída

diagram agregace

násobnost

22

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ů

23

Kompozice tříd

složený objekt/třída

složka

diagram kompozice násobnost

24

Omezení asociací

omezení: zde výběr jedné nebo druhé komponenty

25

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

26

Kontext a složený kontextový diagram v UML

27

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.

28

Rozhraní a realizace v UML

29

Diagramy případů užití

30

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

31

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ý

32

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

33

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

34

Ukázka: diagram případů 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

Ukázka: diagram užití tiskárny

40

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>>)

41

Příklad na vkládání případu užití

42

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>>)

43

Příklad na rozšiřování případu užití

44

Příklad s označením systému

45

Příklad se zakreslením autora a příjemce

46

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

47

Příklad na zobecnění

48

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í

49

Stavové diagramy

50

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

51

Diagramy stavů

52

Podrobnější informace o přechodu

53

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

54

Složený stav a sekvenční podstavy

55

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

56

Souběžné podstavy

57

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)

58

Ukládaný stav

59

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

60

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)

61

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