Diagram aktivit

Z Wikipedie, otevřené encyklopedie
Skočit na: Navigace, Hledání

Diagram aktivit je jeden z UML diagramů, které popisují chování. Tento diagram se používá pro modelování procedurální logiky, procesů a zachycení workflow.[1] Každý procesdiagramu aktivit je reprezentován sekvencí jednotlivých kroků, které jsou v modelu zakresleny jako

  • akce – atomické dále nedělitelné kroky
  • vnořené aktivity – volání jiných procesů (aktivit), tyto aktivity mohou být reprezentovány dalším diagramem aktivit.

Sekvenci jednotlivých kroků v diagramu aktivit určuje řídicí tok.[2]

Aktivita[editovat | editovat zdroj]

Aktivita je to, co je modelováno pomoci diagramu aktivit, tedy business proces, workflow nebo procedurální logika.

Aktivita example.png

Parametry aktivity[editovat | editovat zdroj]

Aktivita může přebírat na vstupu objekty (data) jako parametry a naopak předávat objekty na výstupu [2]. Aktivita je pak spuštěna, pokud jsou všechny parametry naplněny (a případné řídicí toky přivedeny).[1]

Akce[editovat | editovat zdroj]

Akcí se rozumí činnost, která je aktivně vykonávána uvnitř aktivity s tím, že akcí může být i vnořená aktivita.

AKCE aktvita axample.png

Akce může být vykonávána buď člověkem v určité roli, nebo systémem. V diagramu aktivit jsou jednotlivé role a systémy znázorněny jako oblasti – zobrazené jako čáry se jménem rozdělující aktivitu. Do každé oblasti se kreslí akce vykonávané člověkem v určité roli nebo systémem.[1]

Swinline.png

Modelují se pouze aktivní akce. Pokud je systém použit pouze jako nástroj např. k uložení dat, není v tomto modelu zvlášť kreslena akce „Uživatel zadá data“ a „Systém uloží data“, ale pouze „Uživatel vloží data“. Detailní informace bude zanesena teprve při modelování pro implementaci daného systému – na úrovni modelu business procesu (ne systému) není takováto informace relevantní (v případě potřeby lze informaci o použitém systému zadat do popisu – poznámky – aktivity nebo akce).

Tok aktivity[editovat | editovat zdroj]

Inicializace aktivity[editovat | editovat zdroj]

Aktivita začíná v bodě, který je obvykle označen pomocí symbolu inicializace (Initial.png ).[2] Inicializačních bodů může být v aktivitě více - pak se současně spouští paralelní toky. Podobně se spouští toky ve všech krocích, které nemají žádný vstupní tok (kromě událostí). Pokud není explicitně tok řízení vyznačen, může být startovacím bodem událost, která je aktivovaná hned po inicializaci aktivity (nemá vstupní tok), nebo je první akce v rámci aktivity inicializovaná objektem, který je do aktivity předán z vnějšku (parametr aktivity).[2]

Ukončení aktivity[editovat | editovat zdroj]

Celá aktivita je ukončena po průchodu koncovým bodem (Final.png ).[2] Pokud chceme ukončit pouze jednu větev procesu, použije se symbol konce toku (Flow Final.png ).[2]

Řídicí tok[editovat | editovat zdroj]

Sekvence vykonávání jednotlivých kroků je definována pomocí šipek, které označují řídící tok.[2]

Diagram aktivit flow.png

Řídící tok je možno omezit podmínkou. Poté dojde k vyvolání následujícího kroku pouze v případě, že je podmínka splněna.[1]

Diagram aktivit flow2.png

Rozhodnutí[editovat | editovat zdroj]

Podmíněný tok se typicky používá na výstupech symbolu rozhodnutí (Diagram aktivit desicion.png).[2] Rozhodnutí není z hlediska procesu chápáno jako krok – tj. aktivně prováděná činnost, ale pouze jako informace, že bude tok procesu pokračovat jednou z větví podle definovaných podmínek.[1]

Diagram aktivit decision2 big.png

Vstupní a výstupní podmínky[editovat | editovat zdroj]

Tok lze také podmínit pomocí vstupních (pre-condition) a výstupních podmínek (post-condition). Není-li splněna vstupní podmínka, nebude krok spuštěn. Podobně, pokud nedojde ke splnění výstupní podmínky, nebude krok ukončen a řízení předáno.

Diagram aktivit condition.png

Provedení kroku aktivity[editovat | editovat zdroj]

Pokud je krok procesu následovníkem více kroků, pak je tento krok spuštěn a vykonán až po provedení všech předchozích kroků (přesněji po příchodu řídícího toku ze všech větví – za splnění případných omezujících podmínek).[1]

Diagram aktivit Kroky spojeni.png

Spojení[editovat | editovat zdroj]

Pokud chceme vykonat krok po provedení jakéhokoliv kroku předchozího, musíme použít symbol spojení (merge - Diagram aktivit desicion.png ; stejný symbol se používá i pro rozhodnutí), do kterého vstupuje více kroků a vystupuje jeden krok.[2]

Diagram aktivit Merge.png


Příklad:

Chceme-li modelovat proces, kdy sčítáme všechna čísla v seznamu, nelze použít model na následujícím obrázku, protože před provedením kroku „Vezmi další číslo“ by se proces zastavil a čekal na příchod toku z podmínky větví „NE“.

Diagram aktivit vypocet1.png

Pokud do modelu vložíme symbol spojení, pak je krok „Vezmi další číslo“ vyvolám buď po ukončení kroku „Nastav seznam před začátek“ nebo po každém průchodu větví „NE“ – má pouze jeden vstupní tok.

Diagram aktivit vypocet2.png

Rozdělovník a spojovník[editovat | editovat zdroj]

V případě paralelně prováděných akcí, je možné použít rozdělovník (fork) a spojovník se synchronizací (join). Tok je pak rozdělen do více větví a před spojením dochází k synchronizaci, tj. čeká se na dokončení všech větví.[2]

Diagram aktivit Fork join.png

Události[editovat | editovat zdroj]

Příchozí událost[editovat | editovat zdroj]

V některých případech je nutné, aby proces reagoval na nějakou událost zvenčí. Například:

  • Pokud se řeší upomínky u nezaplacených faktur a v průběhu procesu dojde platba, je potřeba proces ukončit a zrušit odeslání upomínky.
  • Klient je požádán o doplnění potřebných údajů a proces čeká na jejich doplnění. Zadání potřebných údajů je událostí, která „reaktivuje“ proces.

Takováto událost se v procesu kreslí pomocí symbolu pro příchozí událost (receive - Diagram aktivit Udalost.png) a znamená, že po každém výskytu události, je spuštěn příslušný řídicí tok [1]

Diagram aktivit Udalost1.png

Časová událost[editovat | editovat zdroj]

Jiným typem události je reakce na uplynutí daného časového úseku od spuštění akce. Tento typ události je v modelu znázorněn s použitím symbolu časová událost (receive time event -Diagram aktivit Udalost time symbol.png )[2]. Řídící tok se spustí po uplynutí definovaného časového úseku od spuštění akce.

Diagram aktivit Udalost3 time.png

Mnohdy je třeba omezit vyvolání reakce na událost pouze po průchodu určitými kroky procesu. V tom případě se řídící tok aktivující reakci na událost přivede na vstup události.


Příklad:

Po potvrzení objednávky se čeká na její úhradu, poté je zboží vyskladněno.

Diagram aktivit Udalost priklad err.png


V případě, že neomezíme aktivaci události, bude krok „Vyskladnění zboží“ vyvolán pokaždé, když přijde nějaká platba, tj. i před dokončením objednávky nebo v případě více objednávek i opakovaně po příchodu každé platby. V tomto případě považujeme takovéto chování za nevhodné. Chtěli bychom vyskladnit zboží pouze pro potvrzenou objednávku.

Diagram aktivit Udalost priklad.png

Událost je možno přijmout až po potvrzení objednávky a to pouze jednou (pokud nebude v procesu opakováno volání kroku „potvrzení objednávky“).


Pokud bychom chtěli reagovat na každou příchozí platbu, ale až po potvrzení objednávky, je možné použít výstupní podmínku u události – pokud není podmínka splněna, není spuštěn řídící tok následující za událostí:

Diagram aktivit Udalost priklad condition.png

Příklad:

Klientovi je odesláno zboží. Pracovník klientského centra pět dní po odeslání volá zákazníkovi pro potvrzení, že zboží bylo v pořádku doručeno.

Diagram aktivit udalost 5dni.png

V případě, že chceme na událost reagovat jen po určitou dobu, nebo čekáme na více událostí, dokud nenastane první z nich, je nutné události omezit výstupní podmínkou.


Příklad:

Klientovi je odesláno zboží. V případě, že zboží nebylo vráceno dodavatelskou firmou, pracovník klientského centra pět dní po odeslání volá zákazníkovi pro potvrzení, zda zboží bylo v pořádku doručeno.

Diagram aktivit udalost 5dni cond.png


Příklad:

Klientovi je odeslána upomínka a čeká se na doručení platby. Pokud však platba nedojde do 2 týdnů, je objednávka zrušena.

Diagram aktivit Udalost cond2.png

Díky výstupním podmínkám se provede větev za událostí pouze v případě, že je relevantní.

Ve složitějším případě budeme po příchodu platby po termínu vracet peníze.

Diagram aktivit Udalost cond podminky2.png

Pokud přijde platba, tak již není událost omezena na výstupu, ale je podmíněno předání toku ke kompletaci objednávky a k vrácení platby. Pokud dojde k vypršení termínu a platba nepřišla, objednávka je zrušena a pokud v průběhu kroku „zrušení objednávky“ dojde k příchodu platby (tj. před ukončením aktivity), je provedeno vrácení peněz (předán podmíněný tok od „příchodu platby“ k „vracení peněz“).


Stejný příklad je možné namodelovat jinak.

Diagram aktivit Udalost cond podminky2b.png

V tomto případě po výskytu události „příchod platby“ je podmíněno předání toku pouze k akci „kompletace objednávky“. Pokud dojde k vypršení termínu a platba nepřišla, objednávka je zrušena a pokud v průběhu kroku „zrušení objednávky“ dojde k příchodu platby (tj. před ukončením aktivity), je provedeno vrácení peněz (oba příchozí toky k akci „vracení peněz“ jsou aktivní).

Spuštění události[editovat | editovat zdroj]

Aktivita také může generovat událost pro jiný proces (nebo jinou část aktivity). Pro generování události se použije symbol spuštění události (send -Diagram aktivit Udalost send symbol.png )[2]. Generování události neovlivňuje aktuální tok aktivity (dá se říci, že se jedná o zvláštní typ akce).

Diagram aktivit Udalost send examplel.png

Region[editovat | editovat zdroj]

V některých případech je nutno po výskytu události zrušit provádění části procesu a vykonat nějakou jinou činnost (např. opravu, storno apod.). Část procesu, kterou můžeme chtít přerušit – typicky „transakci“, ohraničíme pomocí regionu (interruptible activity region - Diagram aktivit Udalost region symbol.png)[1]. Událost pomocí přerušovacího toku (interrupt flow - Diagram aktivit Udalosti region interrupt symbol.png) spouští aktivitu, která typicky zajišťuje zrušení prováděných (provedených) akcí. Původní tok v regionu zaniká.[2]


Příklad:

Klient nakoupil zboží na splátky, tedy čerpal spotřebitelský úvěr, který pravidelně splácí. Po splacení úvěru, je úvěr uzavřen. Pokud klient požádá o předčasné splacení celého úvěru, je po přijetí platby opět úvěr uzavřen. O splacení úvěru lze požádat během celé doby splácení.


Diagram aktivit Udalosti region example1.png

Data (objektové toky)[editovat | editovat zdroj]

Pokud jsou mezi jednotlivými akcemi či aktivitami předávána procesně významná data, modelují se objektové toky. Informace o předávaném typu objektu/třídě je připojena k symbolu akce či aktivity.[2]

Diagram aktivit DATA symbol.png

Nebo lze použít jinou notaci pro znázornění předávaného objektu.[2]

Diagram aktivit DATA symbol2.png

Podobně jako u řídících toků je akce provedena až v případě, že jsou provedeny všechny předcházející kroky (řídící toky) a jsou k dispozici všechny objekty (objektové toky).

Pokud je objekt předáván do více kroků, je prvním prováděným krokem uzamčen a není již k dispozici. Proto je možno takovéto předání použít pouze v případě, že můžeme z kontextu vyloučit potřebu provedení více kroků.


Příklad:

Po potvrzení objednávky a její kompletaci je kompletovaná objednávka buď předaná externímu dopravci, nebo je uložená na dočasném skladu. Diagram aktivit DATA zdvojeni jeden.png

Oba způsoby dopravy zpracovávají jednu objednávku, ale řídící tok zajistí, že bude proveden pouze jeden z kroků (krok se provede po „přivedení“ všech řídících i objektových toků) a tím nedojde k uzamčení objednávky v druhém kroku.

V případě, že je potřeba použít objekt ve více následných krocích, je potřeba použít rozdělovník. V tomto případě dojde k vytvoření kopie objektu a nedojde k jeho uzamčení „konkurenčními“ kroky.

Diagram aktivit DATA zdvojeni fork.png


Příklad:

Po kompletaci objednávky, je hotová objednávka vyskladněná a předána dopravci. Oba kroky pracují s objednávkou.


Diagram aktivit DATA zdvojeni err.png


V tomto případě by v kroku „vyskladnění“ došlo ke „zkonzumování“ objednávky a krok „předání externímu dopravci“ by nebyl spuštěn, protože by nedostal na vstup objekt s objednávkou.


Správně lze model nakreslit dvěma způsoby:

Pokud není potřeba sledovat další řídící tok, je možné použít pouze následné objektové toky. Zejména pokud lze očekávat při „vyskladnění“ změnu dat objednávky:

Diagram aktivit DATA zdvojeni correct1.png

Pokud chceme pracovat se stejnou objednávkou v obou krocích je nutno objektový tok rozdělit:

Diagram aktivit DATA zdvojeni correct2.png

Odkazy[editovat | editovat zdroj]

Reference[editovat | editovat zdroj]

  1. a b c d e f g h FOWLER, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition). 3. vyd. [s.l.] : Addison-Wesley Professional, 2003. ISBN 0-321-19368-7. Kapitola Activity Diagrams.   (anglicky)
  2. a b c d e f g h i j k l m n o Object Management Group, Inc.. OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 [online]. Object Management Group, Inc.. Kapitola Activities. Dostupné online.  (anglicky)

Související články[editovat | editovat zdroj]

Externí odkazy[editovat | editovat zdroj]