Diagram aktivit
Author
Albert FloresDiagram 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. 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.
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 +moreC3. A9_toky. 29'>objekty (data) jako parametry a naopak předávat objekty na výstupu . Aktivita je pak spuštěna, pokud jsou všechny parametry naplněny (a případné řídicí toky přivedeny).
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.
Soubor: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. +more Do každé oblasti se kreslí akce vykonávané člověkem v určité roli nebo systémem.
Modelují se pouze aktivní akce. Pokud je systém použit pouze jako nástroj např. +more 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 (Soubor:initial. +morepng ). 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).
Ukončení aktivity
Celá aktivita je ukončena po průchodu koncovým bodem (Soubor:Final. +morepng ). Pokud chceme ukončit pouze jednu větev procesu, použije se symbol konce toku (Soubor:Flow_Final. png ).
Řídicí tok
Sekvence vykonávání jednotlivých kroků je definována pomocí šipek, které označují řídící tok.
Soubor: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.
Soubor:diagram_aktivit_flow2.png
Rozhodnutí
Podmíněný tok se typicky používá na výstupech symbolu rozhodnutí (Soubor:diagram_aktivit_desicion. +morepng). 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.
Soubor:diagram_aktivit_decision2_big.png
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. +more Podobně, pokud nedojde ke splnění výstupní podmínky, nebude krok ukončen a řízení předáno.
Soubor:diagram_aktivit_condition.png
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).
Soubor:diagram_aktivit_Kroky_spojeni.png
Spojení
Pokud chceme vykonat krok po provedení jakéhokoliv kroku předchozího, musíme použít symbol spojení (merge - Soubor:diagram_aktivit_desicion. +morepng ; stejný symbol se používá i pro rozhodnutí), do kterého vstupuje více kroků a vystupuje jeden krok.
Soubor: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“. +morepng'>Soubor: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. Soubor:diagram_aktivit_vypocet2. png |
---|
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. +more čeká se na dokončení všech větví.
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í. +more 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 - Soubor:diagram_aktivit_Udalost. +morepng) a znamená, že po každém výskytu události, je spuštěn příslušný řídicí tok.
Soubor:diagram_aktivit_Udalost1.png
Č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 -+morepng'>Soubor:diagram_aktivit_Udalost_time_symbol. png ). Řídící tok se spustí po uplynutí definovaného časového úseku od spuštění akce.
Soubor: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. +morepng'>Soubor: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. Soubor: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í: Soubor: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. +more Soubor:diagram_aktivit_udalost_5dni. png |
---|
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. +more Soubor: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. +more Soubor: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. Soubor: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. Soubor: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
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 -+morepng'>Soubor:diagram_aktivit_Udalost_send_symbol. png ). Generování události neovlivňuje aktuální tok aktivity (dá se říci, že se jedná o zvláštní typ akce).
Soubor:diagram_aktivit_Udalost_send_examplel.png
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. +more). Část procesu, kterou můžeme chtít přerušit - typicky „transakci“, ohraničíme pomocí regionu (interruptible activity region - Soubor:diagram_aktivit_Udalost_region_symbol. png). Událost pomocí přerušovacího toku (interrupt flow - Soubor: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á.
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. +more 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í. Soubor:diagram_aktivit_Udalosti_region_example1. png |
---|
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.
Soubor:diagram_aktivit_DATA_symbol.png
Nebo lze použít jinou notaci pro znázornění předávaného objektu.
Soubor:diagram_aktivit_DATA_symbol2.png
Podobně jako u +moreAD_kroku_aktivity'>ří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. +morepng'>Soubor: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. |
---|
Soubor: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. +more Soubor: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: Soubor:diagram_aktivit_DATA_zdvojeni_correct1. png Pokud chceme pracovat se stejnou objednávkou v obou krocích je nutno objektový tok rozdělit: Soubor:diagram_aktivit_DATA_zdvojeni_correct2. png |
---|
Odkazy
Reference
Související články
Externí odkazy
[url=http://www. agilemodeling. +morecom/artifacts/activityDiagram. htm]Introduction to UML 2 Activity Diagrams[/url] * [url=http://www. agilemodeling. com/style/activityDiagram. htm]UML 2 Activity Diagram Guidelines[/url] * [url=http://www. conradbock. org/#UML2]UML 2 Activity and Action Models[/url].