Diagram aktivit

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ý proces v diagramu 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

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

Parametry aktivity

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

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

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

Inicializace aktivity

Aktivita začíná v bodě, který je obvykle označen pomocí symbolu inicializace ( ).^[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

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

Řídicí tok

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

Ří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]

Rozhodnutí

Podmíněný tok se typicky používá na výstupech symbolu rozhodnutí ().^[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]

Vstupní a výstupní podmínky

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.

Provedení kroku aktivity

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]

Spojení

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

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“. 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.

Rozdělovník a spojovník

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]

Události

Příchozí událost

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 - ) a znamená, že po každém výskytu události, je spuštěn příslušný řídicí tok ^[1]

Časová událost

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 - )^[2]. Řídící tok se spustí po uplynutí definovaného časového úseku od spuštění akce.

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. 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. 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í:

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.

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.

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

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 - )^[2]. Generování události neovlivňuje aktuální tok aktivity (dá se říci, že se jedná o zvláštní typ akce).

Region

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 - )^[1]. Událost pomocí přerušovacího toku (interrupt flow - ) 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í.

Data (objektové toky)

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]

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

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

Příklad: Po kompletaci objednávky, je hotová objednávka vyskladněná a předána dopravci. Oba kroky pracují s objednávkou. 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: Pokud chceme pracovat se stejnou objednávkou v obou krocích je nutno objektový tok rozdělit:

Odkazy

Reference

↑ ^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)
↑ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j ^k ^l ^m ⁿ ^o Object Management Group, Inc. OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 [online]. Object Management Group, Inc., 2007 [cit. 2009-01-10]. Kapitola Activities. Dostupné v archivu pořízeném dne 2010-09-23. (anglicky)

Související články

Stavový diagram (UML)

Externí odkazy

Obrázky, zvuky či videa k tématu Diagram aktivit na Wikimedia Commons
(anglicky) Introduction to UML 2 Activity Diagrams
(anglicky) UML 2 Activity Diagram Guidelines
(anglicky) UML 2 Activity and Action Models

[fowler-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)

[omg-2] ↑ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j ^k ^l ^m ⁿ ^o Object Management Group, Inc. OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 [online]. Object Management Group, Inc., 2007 [cit. 2009-01-10]. Kapitola Activities. Dostupné v archivu pořízeném dne 2010-09-23. (anglicky)

[1]

[2]

Navigation

Navigace

Tématické portály