UML teorie k zápočtovému testu a ke zkoušce IT

Prezentace na téma: "UML teorie k zápočtovému testu a ke zkoušce IT"— Transkript prezentace:

1 UML teorie k zápočtovému testu a ke zkoušce IT
Dobrý zdroj k UML:

2 Objektově orientovaný přístup (úvod)

3 Objektově orientovaný přístup (úvod)
Proč objekty? Objektový přístup umožňuje lepší využití kódu než knihovny procedur, možnost znovupoužití. Elegantně se zvládnou prostředky pro okenní rozhraní systémů. Dávkové úlohy se staly interaktivními (objekt reaguje na více podnětů, na každý jinak). Metodický faktor (mnoho dřívějších doporučení je nyní skryto v definici tříd a objektovém přístupu). Definice Objekt je cokoliv, jakákoliv věc, stavební jednotka, která modeluje nějakou část světa (člověk, tiskárna, kamera, faktura, hotelový pokoj, pacient, diagnoza,…) Objekty (pohromadě jsou zde uzavřena data i jejich vlastnosti a chování) jednoho systému jsou propojené vazbami a působí na sebe navzájem.

4 Objekt v OOP Základní vlastnosti objektu – struktura objektu
Objekt obsahuje 1. vnitřní paměť (má vlastnost něco si pamatovat) - atributy objektu, zvenčí je objektu nepřístupná, je jeho soukromou záležitostí, co si objekt pamatuje a jak. Představuje stav objektu. Stav objektu se mění podle chování objektu. Stav objektu je definován hodnotami všech atributů v daný okamžik. 2. metody objektu (procedury a funkce, obecněji posloupnost kódu pgmu, které vykonávají nějakou činnost nad vnitřní pamětí). Opět zvnějšku neviditelné a nepřístupné. Představuje chování objektu, schopnost objektu něco dělat. 3. jiné objekty, kterým je schopen poslat zprávy a tak řídit jejich činnost.

5 Objekt v OOP Obr. 2x obecný objekt
4. schopnost přijmout a zpracovat zprávu (požadavek) zvnějšku. Každý objekt obsahuje tzv. protokol zpráv v rozhraní (přiřazení zprávy metodě objektu). Každá zpráva může mít vstupní a výstupní parametry, jediná možnost, jak spolupracovat s objektem, je poslat mu zprávu. Lze také říci, že zpráva slouží k „vybírání“ údajů z objektů resp. k „zapisování“ údajů do objektů, také ke spouštění dalších operací. Protokol je množina všech zpráv, které je možné objektu poslat. Bez znalosti protokolu uživatelé s objekty nemohou pracovat, nevědí, co objekty umějí udělat. Obr. 2x obecný objekt

6 Objekt v OOP - zprávy Zpráva je komunikační jednotka mezi dvěma objekty, která umožňuje, aby funkce SW aplikace byla výsledkem spolupráce skupiny objektů. Zprávy jsou tvořeny kombinací řídících a datových toků. Typy zpráv Konstruktor pro tvorbu objektů. Destruktor pro rušení objektů. Modifikátor pro modifikaci stavu objektů. Selektor vrací info o stavu objektu. Iterátor pro prohlížení obsahu datové struktury. Typy přenosu zpráv Jednoduchý přenos Synchronizovaný přenos Asynchronní přenos

7 Objekt v OOP- odvozené vlastnosti
Odvozené vlastnosti objektu Používání abstrakce Existence objektů Definování tříd objektů Zapouzdření (nejdůležitější princip OOP) Ukrývání implementace Komunikace objektů Polymorfismus Dědičnost

8 Objekt v OOP- odvozené vlastnosti
Abstrakce (proces vytváření jednoduché reprezentace složité reality). Objekty a třídy (objekt má atributy, chování, vztahy s jinými objekty, třída je abstrakce objektů se stejnými vlastnostmi). Zapouzdření (encapsulating) data a funkce s nimi pracující jsou spojeny do jednoho objektu, data jsou skryta před ostatními objekty a lze k nim přistupovat pouze pomocí metod objektu. Výhody: data jsou chráněna před narušením zvenku, ostatní objekty nemusí znát vnitřní strukturu dat, realizace změny v datech je jednodušší, projeví se jen v jedné třídě. Ukrývání implementace (možnost používat metody objektů bez znalosti jejich implementace).

9 Objekt v OOP- pohledy Pozn. OO programátor je buď tvůrce třídy nebo klientský programátor. Na objekt se díváme dvěma pohledy a) objekt, který použijeme v programu již jako hotový, naprogramovaný, zajímají nás veřejná data a operace, b) objekt, který máme za úkol zhotovit nebo opravit. Ad a) zajímá nás popis zpráv a co se voláním těchto zpráv děje, tedy zajímáme se o chování objektu (pro klientské programátory). Ad b) zajímají nás všechny vlastnosti, objekt musíme otevřít a zpracovat jeho vnitřek, vždy na úrovni, kde je to třeba (pro programátory tvůrce).

10 Objekt v OOP- odvozené vlastnosti
Komunikace objektů (aby existovala, musí mít jeden objekt přístup k druhému – musí mít odkaz na druhý objekt). Dědičnost (vlastnost tříd viz dále). Polymorfismus (stejná zpráva může vyvolávat různé operace) Pokud mají různé objekty shodné protokoly, nemusí to znamenat, že mají stejnou datovou strukturu a stejné metody. Objekty různých tříd mají metodu se stejným jménem, přičemž její implementace se v jednotlivých třídách může lišit. Tj. dva různé objekty mohou přijmout tutéž zprávu a každý z nich na základě této zprávy vyvolá jinou metodu (operace “zobraz” vyvolaná zasláním zprávy jednou zobrazí text a jednou obrázek). Jinými slovy jedna zpráva - dva různé objekty - dvě různé metody - dvojí reakce na tutéž zprávu.

11 Objekt v OOP- odvozené vlastnosti

12 Třída v OOP - vlastnosti
Třída je předpis pro budoucí objekt (abstrakce), ale samotnou realizací pro řešení analytického problému je objekt jako instance třídy. Merunka: “Třída objektů slouží k tomu, abychom mohli strukturu dat a množinu metod patřících jednomu druhu objektu jednoduše popsat společně pro všechny objekty, které do daného druhu patří. Na třídy v OOP vlastně nahlížíme jako na popis toho, jaké druhy objektů v systému potřebujeme. Pro každou třídu pak definujeme, jakou budou mít její objekty strukturu a metody.” Platí: objekt je instance třídy, objekt přebírá vlastnosti třídy, třída má deklaraci, výčet atributů, metody, objekt má hodnoty atributů a nemůže mít jiné metody než jeho třída.

13 Třída v OOP - vlastnosti
Dědičnost - sdílení kódu je znovupoužitelnost na úrovni deklarace třídy, dědění je vztah mezi třídami nikoli mezi jejich objekty, třída, ze které se dědí je předek (nadtřída), třída, která dědí je potomek (podtřída). odvozená třída obsahuje všechny datové položky třídy předka a kopíruje rozhraní předka, tj. zprávy, které můžeme poslat objektům předka můžeme poslat i objektům potomka. Objekty potomka dědí i chování předka, ale chceme-li, aby potomek měl jiné chování, můžeme přidat novou metodu nebo změnit metodu předka překrytím, zastíněním – overriding viz předchozí obr. existují dva projevy dědění: generalizace (navrhnu objekty (třídy), k nim rodiče), specializace (navrhnu třídu, z ní potomky).

14 Specifikace třídy Specifikace třídy obsahuje Jméno třídy
Atributy třídy Operace, které jsou platné pro všechny objekty třídy. Viditelnost atributů a operací Private - neviditelné, důsledně zapouzdřené části třídy Protected - viditelné pouze z dané třídy odvozeným objektům Public – jsou viditelné všem objektům třídy

15 Další pojmy v OOP Zpráva - požadavek, který jeden objekt posílá druhému. Link - spojení mezi objekty, realizováno tak, že procedura jednoho objektu volá proceduru druhého objektu. Asociace - spojení mezi třídami, které může a nemusí být realizováno linkem - zobecnění linku. Každý objekt má svou identitu. Každý objekt má odpovědnost za svou činnost. ”Objekt má chování” znamená, že objekt vlastní metody, které toto chování zajistí.

16 Vizuální modelování – modelování pomocí UML
Vlastnosti “Informace v obrázcích” Prostředek komunikace (modely, diagramy) Zachycuje obch. procesy, věcnou problematiku, architekturu systému Je podporováno silnou notací a metodologiemi Metodologie Booch, Coad,Yourdon OMT (Object Modeling Technik), Rumbaugh OOSE (Object-Oriented Software Engineering) Jacobson (scénáře Use Case) Modely vytváříme proto, že nejsme schopni plně pochopit komplexní systém jako celek. Model je zjednodušení reality. Díky modelům vizualizujeme stávající nebo vytvářený systém, specifikujeme strukturu nebo chování systému, získáváme základ pro konstrukci systému a dokumentujeme rozhodnutí o systému.

17 UML Unified Modeling Language
UML poskytuje pravidla pro pojmenování, rozsah platnosti, rozsah viditelnosti, omezení, provedení modelu různé specifikace rozšiřitelnost jako jsou stereotypy, dodané hodnoty přestože je nejčastěji spojován s modelováním OO SW díky svým rozšířením má mnohem širší využití, je to pouhá notace, syntaxe (standard pro zobrazení a popis modelů), univerzální jazyk pro vizuální modelování, nikoliv metodika modelování. Metodikou je Unified Process.

18 UML Unified Modeling Language
Definice: UML je standardní jazyk pro vizualizaci, specifikaci, konstrukci a dokumentaci prvků projektu, ve kterém hraje významnou roli vývoj software. Obsahuje stavební bloky, společné mechanismy a architekturu. Stavební bloky UML předměty (thinks) – prvky modelu vztahy (relationship) – pojítka mezi prvky, diagramy (diagrams) – vizualizace co bude systém dělat a jak to bude dělat.

19 UML Unified Modeling Language
UML – skupiny artefaktů Týkající se struktury systému tvoří statickou část modelu, třídy, rozhraní, use case, komponenty, uzly. Týkající se chování systému tvoří dynamickou část modelu, interakce, stavy, aktivity. Týkající se organizace systému package. Týkající se vysvětlení účelu popisy, anotace, poznámky.

20 UML Unified Modeling Language
UML - vztahy Agregace (závislost) a kompozice jeden prvek závisí na druhém. Asociace propojení prvků. Dědičnost specializace/generalizace.

21 UML Unified Modeling Language
UML - diagram Grafická reprezentace obsahu modelu zachycení prvků a jejich vztahů. Pohled na systém z různých perspektiv Různé typy diagramů Diagram případů užití (use case), tříd, složené struktury, objektů, sekvenční, komunikační, stavový, aktivit, komponent, nasazení, balíčků (package), zjednodušené interakce a časování. Jednotlivé typy diagramů odpovídají pohledům na navrhovaný systém. Statické a dynamické pohledy, pohled uživatele (Use case diagram), pohled technologický (diagram nasazení).

22 Klasifikace diagramů UML

23 Use case diagram UML 1. Diagram Use case (UCD, diagram případů užití)
jeho vypracování je obsahem use case analýzy, zachycuje funkcionalitu systému z pohledu uživatele, popisuje chování systému z hlediska uživatele. 4 prvky diagramu use case Aktor (vymezením aktorů specifikujeme okolí systému a vymezíme jeho hranice). Use case (případ užití, typ jednání, funkcionalita,systému, kterou využívá aktor), Vztah (mezi aktorem a use case, mezi use case, výjimečně mezi aktory), Hranice systému s názvem aplikace.

24 Use case diagram UML Aktor (kdokoliv nebo cokoliv mimo systém, kdo nějak komunikuje a interaguje se systémem) zachycení okolí systému, prvky aktivně komunikující se systémem. uživatelé - role jiné softwarové systémy čas Use case (typ jednání, případ užití) jakákoliv funkčnost, která dává měřitelnou hodnotu uživatelům tohoto systému, aktorům, reprezentuje ucelenou funkcionalitu problémové domény. Profesor Student Údržba seznamu Údržba kurzu Rozvrh kurzu

25 Use case diagram UML 3 typy vztahů v UCD
1. Vztahy mezi aktorem a use case –komunikační - aktor komunikuje se systémem, využívá daný use case (vyvolává a účastní se use case). Student Seznam studentů v kurzu Profesor Údržba studijního plánu Systém placení Správce Údržba rozvrhu

26 Use case diagram UML 2. Vztahy mezi use case
Use case mohou vzájemně spolupracovat ( slouží pro zjednodušení modelu a podobá se dekompozici). Rozeznáváme dva typy vztahů mezi samotnými use case: Vazba include (dříve uses) - povinný vztah, oba spojené use case se musí povinně provést, použijeme tam, kde se část use case v navrhovaném systému může opakovat. Vazba extend rozšiřující vztah, za jistých podmínek se vykonávají oba use case, použijeme pro volitelné chování, pro chování za specifických podmínek, pro chování podle volby aktora. 3. Vztahy mezi aktory

27 Příklady rozšíření a rozpracování v use case diagramu
Příklad use case diagramu Pomocí generalizace aktora lze tento UCD zjednodušit

28 Příklady rozšíření a rozpracování v use case diagramu
Generalizace use case Vztah extend

29 Příklady rozšíření a rozpracování v use case diagramu
Vztah include

30 Use case diagram UML Popis use case
Stručná charakteristika (1 - 3 věty), používají se slova z problémové domény ne technologické a odborné výrazy z IT. Scénář pro složitější use case nutné podmínky před spuštěním, nutné podmínky po ukončení, tok událostí - sekvence akcí. Jeden scénář “HAPPY DAY” (obsahuje základní tok událostí a subtoky), ostatní scénáře jsou alternativní, chybové. Význam use case diagramu zaznamenání uživatelů systému, zachycení požadavků na systém, pro kontrolu a akceptaci požadavků na systém vizualizace a organizace požadavků ve standardní formě, pro nalezení objektů, tříd a zodpovědností z popisu scénářů, pro testování, řízení projektu ...

31 Use case diagram UML (půjčovna CD)

32 Use case diagram UML Scénář Význam use case diagramu
zaznamenání uživatelů systému, zachycení požadavků na systém, pro kontrolu a akceptaci požadavků na systém vizualizace a organizace požadavků ve standardní formě, pro nalezení objektů, tříd a zodpovědností z popisu scénářů, pro testování, řízení projektu ... Scénář Více variant, nejjednodušší verze je komunikace aktora se systémem pomocí tabulky )viz cvičení), jak to podporují CASE nástroje. Lze i podrobněji viz další snímek včetně alternativ nebo chyb.

33 Scénář (tok událostí) pro Use Case Evidence rezervace (půjčovna CD)
Předpoklady Tento Use Case začne, když člen nemůže být uspokojen, protože dané CD není momentálně na skladě, nebo daný titul není v půjčovně k dispozici. Hlavní tok Tento Use Case začíná, když člen předloží asistentovi svoje identifikační číslo a název titulu, který si chce zarezervovat. Asistent zkontroluje existenci člena v databázi členů (A-1), zkontroluje, zda titul existuje v databázi titulů (A-2) a zkontroluje, zda jsou všechny kopie daného titulu zapůjčeny (A-3). Pokud má někdo kopii zapůjčenu déle než 10 dní, je upomenut o navrácení (S-1). Je založen záznam o rezervaci této kopie pro daného člena. Je vytištěn doklad o rezervaci titulu. Subtoky S-1: Asistent vyhledá všechny členy, který mají půjčený daný titul a zkontroluje délku jejich půjčky. Pro ty, kteří mají půjčku delší než 10 dnů, vytiskne upomínku. Alternativní toky A-1 : Je vloženo špatné ID člena, nebo člen neexistuje. Asistent může opakovat vstup ID nebo vložit údaje o členu (bude řešeno v Use Case Přidání nového člena), nebo ukončit Use Case. A-2 : Je vložen špatný titul, nebo titul neexistuje v půjčovně. Asistent ukončí Use Case (není založena rezervace) a vytiskne objednávku na daný titul (Use Case Objednání materiálu). A-3 : Asistent zjistí kdo má půjčené kopie a vloží rezervaci pro člena.

34 Sekvenční diagram UML 2. Diagram sekvenční
Zachycuje interakci mezi objekty, zachycuje zasílání zpráv mezi objekty v rámci systému. Zachycuje dynamické chování s orientací na čas. Vlastnosti sekvenčního diagramu Objekty sekvenčního diagramu spolu komunikují pomocí zasílání zpráv. Popisuje jeden průchod zpráv systémem. Nemá přímé výrazové prostředky pro smyčky, větvení a podmínky. Pro jednoduché případy použiji poznámky. Složité případy řeším separátními diagramy.

35 Sekvenční diagram UML (půjčovna CD)

36 Fragmenty v sekvenčních diagramech
Kombinované fragmenty jsou části sekvenčních diagramů, mají operátory a mohou obsahovat kontrolní podmínky přechodů. Lze je jako prvky přetahovat do jiných sekvenčních diagramů. Nejpoužívanější operátory jsou opt, alt, loop. Opt – operace se vykoná při splnění určitých podmínek. Alt – provedou se operace podle splnění podmínek, volba mezi několika alternativami Loop – opakování operace minkrát až maxkrát Loop min. max. Viz obrázky dále

37 Fragmenty v sekvenčních diagramech UML obecně

38 Fragmenty v sekvenčních diagramech UML (příklad)
Větvení pomocí opt a alt Příklad alt (alternativa)

39 Fragmenty v sekvenčních diagramech UML (příklad)
Iterace s operátory loop a break

40 Diagram komunikace UML
3. Diagram komunikace spolupráce Ukazuje tytéž informace jako sekvenční diagram, ale NE s ohledem na čas, ale na propojení mezi objekty, jaké zprávy si objekty vyměňují. Slouží pro pozdější určení vztahů mezi objekty datové vztahy - dány distribucí informací, komunikační vztahy - dány spoluprací mezi objekty.

41 Diagram přehledu interakcí
4. Interaction overwiev diagram je diagram aktivit a diagram sekvenční v jednom diagramu. Místo aktivity je v diagramu aktivit sekvenční diagram. Viz obr.

42 Diagram tříd UML 5. Diagram tříd
Třída je abstrakce objektů, které mají společné chování a o kterých nás zajímají stejné informace. V OOP je to šablona pro instance objektů. Statický pohled na modelovaný systém. Vytváří se v etapě analýzy a postupně se zpřesňuje, je základem pro implementaci a nástrojem pro dokumentaci.

43 Diagram tříd UML Třída Třídy vyhledáváme analýzou problémové domény (podstatná jména ze scénářů). Třída je zapouzdřením určitého chování a určitých informací. Zapouzdření je koncept, který dává ve třídě dohromady to, co spolu souvisí a dává nějaký smysl. Třída obsahuje jméno atributy operace.

44 Diagram tříd UML Operace třídy
Operace, které třída definuje,představují její chování nebo také zprávy, kterým třída rozumí. Zdrojem pro hledání operací jsou především scénáře use case analýzy. Atributy třídy Atributy třídy jsou informace, které o třídě uchováváme. Zdrojem pro atributy třídy jsou věcné znalosti o dané problematice a analýza podrobných požadavků uživatelů. Atributy třídy by měly být atomické a nedělitelné.

45 Diagram tříd UML - Vztahy mezi třídami
Třídy nejsou v systému osamocené, jejich objekty ke svému chování potřebují využít schopností jiných objektů. Třídy mezi sebou sdílí informace. Asociace (Slabá vazba mezi třídami), např. čtenář a kniha Neříká nic jiného, než to, že dvě třídy mají mezi sebou vztah, tedy že o sobě vědí. Defaultně obousměrná vazba. Může být definováno jméno asociace, role a násobnost (kolik instancí třídy existuje vůči jiné třídě). Agregace (volná vazba mezi třídami), např. počítač a periferní zařízení Představuje vztah skládání celku z částí, celek odpovídá za vytvoření a zrušení částí, je to vztah celku k jedné části, definujeme násobnost, jméno a role ne. Kompozice (nejsilnější forma asociace, velmi pevná vazba mezi třídami), např. faktura a řádek faktury, třída se skládá z jiných závislých tříd Třídy tvoří hierarchii Dědičnost (nejsilnější forma vazby mezi dvěma a více třídami). Generalizace/specializace Potomek dědí celou specifikaci svých předků (atributy i operace). Viditelnost prvků určuje, jak jsou děděny (public a protected jsou v potomkovi přístupné, private ne). Vztah mezi třídou a speciálním případem této třídy. Rozlišuje, co je stejné a co jiné.

46 Diagram tříd UML (půjčovna CD)
Rekurzivní asociace (asociace na sebe sama). Asociativní třída (atributy asociace) Pokud sama asociace nese určité informace, které nemohou být atributy ani jedné z asociovaných tříd. Hovoříme o „link class“. Může mít atributy i operace. Např. vztah mezi osobou (jméno, rcislo), firmou (název) je vazba s asociativní třídou pracovní poměr (datum nástupu, funkce, plat).

47 Stavový diagram UML Chování systému je modelováno především pomocí diagramů aktivit i stavových diagramů. 6. Stavový diagram Používá se k modelování životního cyklu jednoho objektu. Hovoříme o objektech s výrazným dynamickým chováním nověji reaktivní objekty. Stavový diagram modeluje chování systému napříč všemi use casy. Znázorňuje, jak se stavy objektu mění v závislosti na událostech, které se ho dotýkají Stav objektu je dán hodnotami jeho atributů. Stav objektu může ovlivňovat jeho chování. Stav objektu je zachycen na stavovém diagramu jako stav jednoho objektu jedné třídy bez vazeb na jiné objekty nebo jiné třídy.

48 Stavový diagram UML (objekt Titul v půjčovně CD, nebo Objednávka)

49 Diagram složené struktury
7. Composite structure diagram Composite structure diagram, česky asi diagram složené struktury, zachycuje vnitřní strukturu nějaké třídy a spolupráce uvnitř této třídy a mezi třídou a jejím okolím. Typicky jej používáme pro třídy, které jsou složené z většího počtu instancí jiných tříd a diagramem tuto vnitřní složenou strukturu popisujeme (od toho také název diagramu).

50 Diagram balíčků a objektový diagram
Balíčky (package) používáme pro větší projekty pro udržení kontroly nad velkou strukturou, pro lepší testování, pro návrh komponent, webových služeb. Jde o logické seskupování a sdružování prvků (třídy, use case). Nejčastěji se používá pro třídy, jejichž objekty spolu logicky souvisejí a komunikují mezi sebou, poskytují ucelený balík služeb. Závislost nastane, pokud změna v definici jednoho prvku vyvolá změnu v definici druhého prvku (jedna třída posílá zprávu jiné třídě). Uvnitř package najdeme dědičnost, agregaci, kompozici. Balíček by měl mít jednoduché rozhraní, minimum vazeb na jiné balíčky. Uvnitř balíčku je vždy část diagramu tříd, use case diagramu. 9. Objektový diagram je instance diagramu tříd v daném okamžiku.

51 Diagram balíčků a objektový diagram

52 Diagram aktivit UML 10. Diagram aktivit
Použití pro modelování systémů pracujících v reálném čase, systémů pro řízení technologických procesů, nebo paralelních procesů a jejich synchronizaci. Další použití pro znázornění složitého scénáře a doplnění sekvenčního diagramu. Lze používat symbolů rozhodování (tzv. hodnocení přechodů), symbolů rozvětvení (jeden vstup několik výstupů), spojení (více vstupů jeden výstup), plavecké dráhy – swimlanes pro specifikace osob, oddělení nebo tříd zodpovědných za aktivitu.

53 Diagram aktivit (tvorba filmů)

54 Diagram aktivit (příklad)

55 Diagram časování 11. Timing diagram - pro real time systémy, kde závislost na čase je důležitým parametrem

56 Diagram časování

57 Diagram komponent 12. Diagram komponent je již realizační, podívejte se na něj na

58 Diagram nasazení (Deployment diagram)
Etapa Nasazení (implementační etapa) je proces přiřazení artefaktů (soubory, skripty, DB tabulky, modely UML) uzlům (např. PC, server, prostředí zpracování). 13. Diagram nasazení umožňuje modelovat distribuci SW systému na fyzickém HW. Ukazuje fyzický hardware na němž bude softwarový systém (komponenta) spuštěn a také způsob, jak je SW na tomto HW nasazen. Diagram nasazení ukazuje: Uzly – typy HW, na nichž bude systém spuštěn (osobní PC, server). Relace – typy spojení mezi uzly (komunikační kanál, který slouží k přenosu informací, např. HTTP). Komponenty – typy komponent nasazených na určité uzly (modul IS, MS Word).

59 Diagram nasazení

60 Diagram nasazení

61 Postup při modelování Sestavte use case diagram
Vytvořte jednoduchý diagram tříd (doménový diagram) Proveďte realizaci use cse (každý složitější use case popište scénářem a vytvořte interakční diagramy) Diagram sekvenční (nejprve základní a jednoduché, v dalších iteracích analytického poznání doplňte fragmenty) Diagram aktivit Doplňte diagram tříd o atributy a operace, které přibyly realizací use case (tedy z diagramů interakce) Můžete přidat komunikační diagram (pro lepší znázornění posílání zpráv mezi třídami). Pro třídy s výrazným dynamickým chováním vytvořte stavové diagramy. Doplňte atributy a operace do tříd podle stavových diagramů. Vytvořte další diagramy podle potřeby a zakončete diagramem komponent a nasazení.