Diagramy sekvencí 1
Diagram sekvencí (sequence diagram) Zobrazuje, jak objekty spolupracují Na rozdíl od stavového diagramu zachycují komunikaci více objektů Popisuje zprávy mezi objekty jaké zprávy, komu a kdy jsou zasílány Interakce mezi objekty probíhají v čase (začátek, konec interakce) Časová osa je v diagramu vnímána shora dolů 2
Kreslení diagramu sekvencí Objekty v diagramu se kreslí jako obdélníky s (podtrženým) názvem (v ArgoUML bez podtržení za lomítkem) v horní části diagramu Objekty se kreslí vedle sebe Zprávy jsou zachyceny jako plné šipky Čas zachycen vertikálně (plyne shora dolů) od každého objektu vede dolů svislá přerušovaná čára životočára Na životočáře je obdélníček značí aktivaci objektu ta představuje vykonání operace, kterou má objekt za úkol provádět výška obdélníku značí délku aktivace objektu 3
Příklad diagramu 4
Zprávy Jednoduchá zpráva přechod řízení z jednoho objektu na druhý (kreslí se jako obyčejná šipka) Synchronní zpráva odesílající objekt čeká, dokud nedostane odpověď od objektu, kterému posílá zprávu (kreslí se jako šipka s vyplněným hrotem) Asynchronní zpráva odesílající objekt na nic nečeká a pokračuje (kreslí se jako šipka s polovinou hrotu v ArgoUML jako obyčejná šipka) 5
Čas Čas plyne shora dolů Zpráva zakreslená výše byla odeslána dříve, než zpráva zakreslená níže Různé stavy daného objektu je možné zachytit jako různé objekty Nebo lze vytvořit hybridní diagram, kde jsou jednotlivé stavy zachyceny na jedné životočáře 6
Diagram sekvencí a případy užití Diagram sekvencí může zachycovat interakce, ke kterým dochází v rámci určitého případu/případů užití, např.: 7
Instanční a generické diagramy sekvencí Instanční diagram sekvencí popisuje jediný scénář (jednu instanci) celého případu užití Generický diagram sekvencí zachycuje různé (pokud možno všechny) scénáře, tj. různé instance celého případu užití nutnost stanovit podmínky odesílání zpráv v různých scénářích 8
Vytvoření a zrušení objektu v sekvenci V systémech běžně objekty vznikají a zanikají (např. nabídky, dočasné soubory, ) Vznik objektu v objektovém programování iniciuje konstruktor - v ArgoUML vložení Create Action Zrušení objektu v objektovém programování iniciuje destruktor - v ArgoUML vložení Destroy Action 9
Vytvoření a zrušení objektu 10
Rekurze Někdy dochází k tomu, že objekt posílá zprávu sám sobě dochází k rekurzi (k rekurentnímu volání sama sebe) V diagramu sekvencí se rekurze naznačí šipkou, která začíná i končí ve stejném objektu, příp. směřuje k obdélníčku, který překrývá aktivaci 11
Příklad rekurze a podmínky 12
Diagramy činnosti 13
Diagram činnosti (activity diagram) Jde jiný pohled na stavový diagram Stavový diagram se soustřeďuje na objekt, který se mění při nějakém procesu Diagram činnosti se soustřeďuje na tok činností, které probíhají při nějakém procesu ukazuje, jak tyto činnosti na sobě závisí Může zobrazovat činnosti i ve vztahu k uživatelským rolím 14
Diagram činnosti (activity diagram) počáteční stav role činnost nebo stav rozhodování přechod mezi stavy 15 koncový stav
Kreslení rozhodování Rozhodování se zakreslí: oddělenými šipkami vedoucími z jedné činnosti nebo použije se diagram pro větvení - kosočtverec Ke každé větvi je nutné připsat podmínku do hranatých závorek Druhý způsob je přehlednější 16
Paralelní dráhy K popisu činností, které provádějí jednotlivé role je možné zakreslit paralelní dráhy Paralelní dráha pro danou roli je zakreslena jako obdélník, ve kterém jsou zakresleny ty činnosti, které provádí daná role Název role je v záhlaví obdélníku 17
Souběžné cesty Někdy je potřeba rozdělit tok činností do několika větví, které se budou vykonávat souběžně Rozdělení se provede pomocí diagramu Fork Po provedení souběžných činností se tok opět spojí pomocí diagramu Join 18
Souběžné cesty
Použití proměnných Pokud diagram zachycuje provedené určité operace (např. výpočet hodnoty funkce, ), je třeba zachytit stav pomocí určitých proměnných: název proměnné, která má obsahovat návratovou hodnotu := (symbol přiřazení) výsledek příp. vypočtený pomocí konkrétní metody, včetně parametrů (tj. signaturu) V ArgoUML se podobná přiřazení zapisují do těla skriptu v EntryAction u dané činnosti 20
Použití proměnných
Diagramy spolupráce 22
Diagram spolupráce (collaboration diagram) Zachycuje podobné informace jako sekvenční diagram - je významově ekvivalentní diagramu sekvencí (jeden diagram lze převést na druhý) Klade důraz na objekty (třídy) místo na čas, kdy jsou odesílány zprávy Zdůrazněna je komunikace objektů pomocí zpráv Jednotlivé zprávy mezi objekty (třídami) jsou číslovány Je rozšířením diagramu objektů 23
Kreslení diagramů sekvencí Objekty v diagramu se kreslí jako obdélníky s (podtrženým) názvem Vztahy mezi objekty zachycuje plná čára (příp. s orientací) Zprávy mezi objekty se zakreslí pomocí šipky, která směřuje k cílovému objektu šipka je popsána názvem zprávy v závorkách lze případně zapsat parametry zprávy Pořadí zasílání zpráv se značí pomocí číslic před názvem zprávy a dvojtečkou 24
Příklad 25
Zachycení stavů objektů Zakreslete objekt k jeho názvu připište do hranatých závorek název stavu Tentýž objekt v dalším stavu zachytíte jako nový objekt s názvem stavu opět v hranatých závorkách Přechod z jednoho stavu do druhého zachytíme pomocí přerušované šipky (zachycuje závislost) označené např. stereotypem <<stane se>> 26
Zobrazení stavů objektů 27
Podmínky a opakování Podmínka se zapisuje do hranatých závorek vlevo od čísla zprávy Opakování zprávy označíme hvězdičkou před závorkou s podmínkou Jednotlivé zprávy mohou být jen pojmenovány nebo mohou přímo obsahovat konkrétní akci, a to včetně příslušných parametrů. 28
Příklad 29
Více cílových objektů Pokud má objekt zprávou oslovit více objektů najednou, pak: u zprávy použijeme opakování (hvězdičku s podmínkou v hranatých závorkách) jako cíl zakreslíme tři částečně se překrývající objekty 30
Příklad oslovení více objektů najednou 31
Znázornění vrácených výsledků Pokud zpráva oslovuje druhý objekt s tím, že požaduje navrácení určité hodnoty, ze to v UML znázornit takto do názvu zprávy se uvede: název proměnné, která má obsahovat návratovou hodnotu := (symbol přiřazení) výsledek příp. vypočtený pomocí konkrétní metody, včetně parametrů (tj. signaturu) 32
Příklad vracení hodnoty 33
Aktivní objekt Řízení komunikace mezi objekty může někdy záviset na jednom aktivním objektu, který zasílá zprávy ostatním objektům Aktivní objekt označujeme silnějším rámečkem kolem objektu Pokud to v UML editoru nelze provést (ArgoUML), můžeme jej odlišit např. barevně Pokud dva aktivní objekty vykonávají stejnou činnost, hovoříme o souběžnosti 34
Synchronizace objektů Pokud je třeba zachytit synchronní odeslání zprávy až poté, co byly odeslány jiné zprávy, je možné seznam čísel těchto zpráv oddělených čárkami uvést na začátku synchronizované zprávy a oddělit od názvu zprávy lomítkem 35
Diagramy komponent 36
Diagram komponent (component diagram) Týká se počítačových systémů Vývoj programů probíhá často po jednotlivých komponentách Komponenty mají rozhraní a spolupracují spolu pomocí těchto rozhraní Na vývoji tak mohou spolupracovat týmy lidí Rozhraní umožňují komunikovat i zcela odlišným aplikacím
Diagram komponent (component diagram) objekt komponenta závislost
Co je komponenta? Je to fyzická součást systému (kus softwaru nebo hardwaru) Lze si ji představit jako softwarovou (nebo hardwarovou) implementaci třídy nebo (a to zpravidla) několika tříd Umožňuje opakované použití S okolím komunikuje pomocí rozhraní
Proč modelovat komponenty? Aby zákazník mohl vidět strukturu hotového systému Aby vývojáři dopředu věděli, co a s čím budou dělat Aby osoby pověřené sepsáním dokumentace věděly, o čem psát Abychom si sami usnadnili opakované použití komponent
Komponenty a rozhraní Rozhraní (viz diagramy tříd) si lze představit jako sadu operací, které třída (zde komponenta) nabízí okolnímu světu Okolní svět komunikuje s komponentou přes rozhraní V UML není prakticky rozdíl mezi rozhraním komponenty a rozhraním třídy Realizace je vztah mezi komponentou a jejím rozhraním Komponenta může zpřístupnit své rozhraní dalším komponentám, které toto rozhraní mohou použít hovoříme o exportním rozhraní Pokud některá komponenta používá služby (rozhraní) jiných komponent, říkáme, že používá importní rozhraní
Nahrazování a opakované použití komponent Jednu komponentu můžeme nahradit jinou komponentou, pokud používají stejné rozhraní Pokud chceme vytvořit komponentu, která je opakovaně použitelná v různých systémech, je nutné, aby k jejímu rozhraní mohlo přistupovat co největší množství dalších komponent Pokud je k dispozici model rozhraní komponenty, pak není nutné procházet zdrojové texty, pokud budeme chtít danou komponentu použít
Typy komponent Rozmisťované komponenty tvoří základ spustitelných systémů (např..exe nebo.dll soubory, prvky ActiveX, Java Beans,.py soubory pro Python,...) Podpůrné komponenty z nich se vytváří rozmisťované komponenty (např. datové soubory, soubory se zdrojovým kódem,.pyc soubory pro Python (někdy ale.pyc soubor může být chápán jako rozmisťovaná komponenta),...) Prováděcí komponenty vznikají až za běhu systému (dočasné soubory,...)
Kreslení diagramů komponent 44
Kreslení rozhraní
Zakreslení závislostí
Diagramy nasazení 47
Diagram nasazení (deployment diagram) Umožňuje zachytit fyzickou architekturu (počítačového) systému K zachycení částí systému se využívajíí diagramy komponent Je možné zachytit jednotlivé vztahy, vazby, závislosti i fyzické spojení
Diagram nasazení (deployment diagram) uzel spojení vazba komponenta
Uzly Uzel hlavní prvek diagramu nasazení V diagramu se znázorňuje jako kvádr Uzel většinou v diagramu nasazení reprezentuje hardwarový prvek Uzel jako hardwarový prvek může být typu: procesor uzel, který umí spouštět komponentu zařízení neumí spouštět komponentu často představuje způsob rozhraní s vnějším světem Název uzlu může obsahovat i název balíčku (pokud je uzel součástí balíčku)
Znázornění typů uzlů
Diagram nasazení v UML Diagram nasazení ukazuje, jak bude (fyzický) systém vypadat po sestavení V diagramu je možné použít i jiné symboly podle potřeby (např. ikonu serveru, switche, tiskárny,...) tj. vlastně grafické stereotypy Ortodoxní UML diagramy je možné smíchat s jinými diagramy cílem je přehlednost
Literatura 1. Enterprise Architect. Dostupné z: http://www.sparxsystems.com.au/ 2. Schmuller, J. Myslíme v jazyku UML: knihovna programátora. 1. vyd. Grada Publishing. Praha: 2001. ISBN 80-247-0029-8. 3. Miller, R. Practical UML: A Hands-On Introduction for Developers. URL: http://dn.codegear.com/article/31863 4. UML Resource Page. URL: http://www.uml.org/ 53