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

Diagram tříd