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) role
počáteční stav
č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-00298. 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
