Nástroje byznys modelování

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Nástroje byznys modelování BAKALÁŘSKÁ PRÁCE Vítězslav Kalábek Brno 2009

2

3 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vítězslav Kalábek

4 Poděkování Především děkuji vedoucímu této bakalářské práce RNDr. Jaroslavu Ráčkovi, Ph.D. za velmi vstřícný přístup, cenné rady a připomínky, které mi při tvorbě poskytl. Další díky patří RNDr. Tomáši Ludíkovi za mnoho doplňujících informací, které jsem při tvorbě práce využil. Na závěr bych rád poděkoval Mgr. Jarmile Kalábkové za závěrečnou kontrolu a korekturu, bez které by práce jistě obsahovala mnoho větších i menších chyb.

5 Shrnutí práce Práce čtenáře seznamuje s nástroji, které je možné využít pro byznys modelování. Po vysvětlení základní teorie následuje popis samotných nástrojů, kdy jsou nejdříve představeny základní elementy, se kterými se lze setkat, následně je předveden ukázkový příklad, který umožňuje jednotlivé nástroje mezi sebou porovnat. Výsledné diagramy jsou umístěny v přílohách, kde se nachází i zmínka o softwaru, který je možné pro tvorbu modelů využít. Klíčová slova nástroj byznys modelování, procesní řízení, síťový diagram, procesní diagram, software pro tvorbu byznys modelů

6 Obsah 1. Úvod Základní pojmy byznys modelování Nástroje byznys modelování Textový popis Vývojový diagram (flowchart) Diagram datových toků s řízením (control data flow diagram) IDEF Event-driven Process Chain UML, diagram aktivit (activity diagram) Notace Together Workflow Editoru BPMN (Business Process Model Notation) Petriho sítě (Petri net) Závěr...41 Použitá literatura...43 Internetové zdroje...44 Příloha 1 - Vývojový diagram procesu obsluhy výpůjčky...45 Příloha 2 - Vývojový diagram dekomponovaného subprocesu Práce ve skladu...46 Příloha 3 - CDFD procesu obsluhy výpůjčky...47 Příloha 4 - CDFD dekomponovaného subprocesu Práce ve skladu...48 Příloha 5 - Diagram IDEF0 procesu obsluhy výpůjčky...49 Příloha 6 - Diagram IDEF0 dekomponovaného subprocesu Práce ve skladu...50 Příloha 7 - EPC diagram procesu obsluhy výpůjčky...51 Příloha 8 - Rozšířený EPC diagram procesu obsluhy výpůjčky...52 Příloha 9 - EPC dekomponovaného subprocesu Práce ve skladu...53 Příloha 10 - Diagram aktivit procesu obsluhy výpůjčky...54 Příloha 11 - Diagram aktivit dekomponovaného subprocesu Práce ve skladu...55 Příloha 12 - Diagram Together Workflow Editoru pro proces obsluhy výpůjčky...56 Příloha 13 - Diagram TWE pro dekomponovaný proces Práce ve skladu...57 Příloha 14 - BPD procesu obsluhy výpůjčky...58 Příloha 15 - BPD dekomponovaného subprocesu Práce ve skladu...59 Příloha 16 - Petriho síť procesu obsluhy výpůjčky...60 Příloha 17 - Petriho síť dekomponovaného subprocesu Práce ve skladu...61 Příloha 18 - Software pro byznys modelování, Microsoft Visio...62 Příloha 19 - Software pro byznys modelování, Case Studio Příloha 20 - Software pro byznys modelování, Visual Paradigm...64 Příloha 21 - Software pro byznys modelování, Together Workflow Editor...65 Příloha 22 - Software pro byznys modelování, BizAgi Process Modeler...66 Příloha 23 - Software pro byznys modelování, WoPeD...67

7 1. Úvod Žijeme ve světe plném informačních technologií. Počítače již dávno nejsou záležitostí specializovaných pracovišť, ale pomáhají nám i v odvětvích, kde by je čekal jen málokdo. Pomocí vhodného softwaru můžeme například namodelovat jakýkoli postup nebo pracovní činnost, hledat jejich nedostatky a úzká místa. Tvorbu takového modelu nazýváme byznys modelování. Byznys modelování nám umožňuje rozebrat tento postup či činnost (ať už se jedná o skládání automobilu z jednotlivých dílů, nebo vyplnění žádosti o stipendium) na jeho stavební kameny. Ty následně obvykle zakreslíme do diagramu a propojíme s daty, která jsou mezi těmito stavebními kameny vyměňována, případně je alespoň poskládáme za sebe pomocí kontrolních toků. Na závěr přimícháme lidské zdroje a výsledek můžeme využít k prezentacím, simulacím, popřípadě následnému vylepšení tohoto procesu. Tématem této bakalářské práce budou nástroje, které můžeme k byznys modelování využít. Tak jako každé odvětví, i byznys modelování se dynamicky vyvíjí. Vznikají nové nástroje a staré jsou zapomínány. Pokusíme se proto zmapovat ty momentálně nejrozšířenější, krátce si popíšeme jejich historii, načež přejdeme k elementům, kterých daný nástroj používá. Na závěr u každého z nástrojů namodelujeme jednoduchý příklad a výsledky krátce zhodnotíme. Tento příklad bude spojovacím mostem, který nám umožní hledat rozdíly a uvažovat nad tím, který z nástrojů je vhodný pro specifické situace. Pokusíme se odhalit jejich přednosti i nedostatky. Kromě toho budou představeny softwarové nástroje, které nám umožní modely tvořit, upravovat, případně pomocí nich dokonce běh modelovaného procesu simulovat. I těch existuje nepřeberné množství a je proto dobré vědět, po kterém z nich sáhnout. Hlavním přínosem práce bude možnost porovnání nástrojů mezi sebou, zvláště pak na dříve uvedeném příkladu. Pokud je totiž naskládáme vedle sebe, můžeme si vytvořit názor a vybrat svůj oblíbený podstatně jednodušeji, než při čtení každé z dokumentací samostatně. 7

8 2. Základní pojmy byznys modelování Abychom byli schopni porozumět následujícím kapitolám, vysvětleme si hned ze začátku alespoň nejpodstatnější pojmy z oblasti byznys modelování. Podobně jako kdekoli jinde je možné setkat se i zde s mnoha terminologiemi. My se v textu ale dále pokusíme zaměřit pouze na jednu, aby zbytečně nedocházelo ke zmatkům. Je také důležité zachovat kontext s anglickým názvoslovím. Ať už z důvodu toho, že dosud nebyl zaveden žádný český ekvivalent, nebo kvůli snazšímu porozumění při čtení anglicky psaných textů pojednávajících o byznys modelování. Byznys proces (business process) Proces je po částech uspořádaná množina činností, jež s využitím zdrojů na základě jednoho nebo více vstupů tvoří opakovatelným způsobem požadovaný výstup. 1 Pojem po částech uspořádané množina říká, že ne všechny činnosti, z nichž se proces skládá, můžeme za sebe jednoznačně seřadit. K tomu dochází, pokud jsou dvě činnosti prováděny paralelně, tedy zároveň. Druhou důležitou podmínkou pro proces je jeho opakovatelnost. Pokud tedy nastanou dvakrát po sobě naprosto identické předpoklady pro vykonání procesu, měli bychom získat dvakrát stejný výsledek. Byznys modelování (business modeling) Model je abstraktní, obvykle zjednodušená reprezentace určitého objektu nebo systému, pojatá z určitého úhlu pohledu. Tvorbu modelů pak nazýváme modelováním. Za byznys modelování tedy označujeme tvorbu abstraktní reprezentace byznys procesů. Výsledkem byznys modelování je v podstatě specifikace byznys procesu. Proto se také můžeme setkat s pojmem modelování byznys procesů, který je s byznys modelováním zaměnitelný. Modely můžeme dělit na formální a neformální. Neformální popis je obvykle jednodušeji pochopitelný, na druhou stranu ale nemusí být dostatečně přesný. Formální modely mají naproti tomu přesně popsanou sémantiku a syntax a lze je použít pro další zpracování počítačem. Jako model obvykle budeme v této práci označovat soubor síťových diagramů a popisných textů, které proces popisují. 1 jedná se o lehce upravenou definici dle RNDr. Jaroslava Ráčka, Ph.D. 8

9 Síťový diagram (network diagram) Síťový diagram je obecným typem diagramu, který zobrazuje propojenou skupinu nebo systém. Síťové diagramy nám umožňují procesy graficky znázornit. Vizualizují činnosti a přechody mezi nimi. Obvykle se jedná o grafy bez kružnic. Kružnice se sice mohou objevit, ale jejich přítomnost může diagram znepřehlednit a je tak lepší se případných kružnic zbavit. Síťové diagramy můžeme dále dělit na dvě skupiny podle významu hran a uzlů. AOA (Activity on arrow) - hrany reprezentují aktivity, uzly události, které tyto aktivity nějakým způsobem ohraničují. AON (Activity on node) - hrany reprezentují závislosti mezi aktivitami, které jsou zobrazeny uzly. Workflow Workflow je automatizovaný byznys proces. Z předchozí definice vyplývá, že pojmy workflow a byznys model jsou na určité úrovni zaměnitelné. Jako workflow totiž může být označen jakýkoli dostatečně formálně definovaný byznys proces, který může být řízen k tomu určeným softwarem. Pro pojem workflow se běžně nepoužívá žádný český ekvivalent, proto se i v rámci práce budeme držet pojmu anglického. Aktivita (activity) Aktivita je jednou dále nedělitelnou činností byznys procesu. Jednotlivé funkce prezentované v byznys modelu mohou být obvykle dekomponovány až do té doby, kdy se jedná pouze o aktivity. Je vhodné nalézt takový poměr obsáhlosti a počtu diagramů v modelu, aby byl výsledek co nejpřehlednější. Dekompozice (decomposition) Dekompozice je rozložení složitého problému do několika menších, které jsou uchopitelnější a lépe pochopitelné. Zobrazit celý proces v jediném diagramu by bylo prakticky nemožné, přinejmenším velmi nepřehledné. Proto většinou využíváme dekompozice, která umožňuje subprocesy zobrazené na jednom diagramu rozebrat v diagramu dalším a postupně tak zjemňovat definici procesu. Při dekompozici je velmi důležité důsledně diagramy pojmenovávat, aby nevznikal zmatek a bylo jasné, který diagram je dekompozicí dané funkce. 9

10 Obrázek 1: Princip dekompozice Role (Workflow participant) Role je soubor vzájemně se doplňujících dovedností. 2 V poměrně nepochopitelné definici není třeba hledat složitosti. Role zahrnuje chování, kompetence a zodpovědnost a je poté přiřazena osobám, které nějakým způsobem do chodu procesu zasahují. Mapování jednotlivých osob k aktivitám by totiž bylo neefektivní a problematické, pokud by došlo k výměně dané osoby, případně pokud by stejnou aktivitu mohlo vykonávat více osob. 2 definice dle skript Metody byznys modelování 10

11 Zdroj (Resource) Zdroj je prostředek nutný k vykonání aktivity. Mezi zdroje nezapočítáváme pouze hmotné prostředky, které jsou aktivitou spotřebovávány, ale například právě i osoby, které jsou následně mapovány na role. Tyto pak označujeme jako lidské zdroje. Obrázek 2: Metamodel procesu Na závěr kapitoly si představme metamodel procesu. Ten umožňuje získat kontext mezi dříve definovanými pojmy. 11

12 3. Nástroje byznys modelování Teď, když známe všechny důležité pojmy, můžeme se pustit do samotného jádra práce, tedy popisu jednotlivých nástrojů, které můžeme použít k tvorbě byznys modelů. K tomu, abychom mohli modely mezi sebou porovnat, nám nejlépe dopomůže jednoduchý ukázkový příklad procesu. Takový příklad, který bychom mohli snadno namodelovat za pomoci všech představených nástrojů a díky tomu by pak byly jejich rozdíly snadno viditelné. V následujícím textu nám za tento příklad poslouží proces obsluhy výpůjčky knihy v knihovně. Podobný proces si jistě každý dokáže snadno představit a tím pádem i pochopit to, jak funguje. Většina nástrojů nám umožní vytvořit jako model procesu diagram. Diagramy se proto pokusíme v prostoru uspořádat podobně, aby o to víc vynikly rozdíly, které by jinak nemusely být příliš patrné. To samé platí o dekompozici. Pokud to bude jen trochu možné, bude proces dekomponován pomocí všech nástrojů stejně. 12

13 3.1 Textový popis Nejjednodušší, ale také nejméně formální možností definice procesu je jeho textový popis. Ten sice umožňuje snadno proces popsat prakticky komukoli, na druhou stranu ale samotná slova může každý pochopit vlastním způsobem a tím princip fungování procesu pochopit nesprávně. Textový popis našeho procesu obsluhujícího výpůjčku v knihovně by mohl vypadat následovně. Knihovna dostane od čtenáře žádost o výpůjčku. Knihovnice zkontroluje, zda je čtenář v knihovně registrován a zda knihovna požadovanou knihu vlastní. Pokud není některá z podmínek splněna, je proces ukončen chybou. Následně dojde ke kontrole momentální dostupnosti knihy v knihovně. Pokud je kniha dostupná, je zarezervována a čtenáři je o tom odeslána zpráva. Čtenář má deset dní na to, aby se do knihovny dostavil a knihu si vyzvedl. Při včasném příchodu čtenáře je kniha předána a toto předání je zaevidováno. V případě, že uplyne od rezervace deset dní, je zrušena a proces je ukončen. Není-li kniha v knihovně dostupná, probíhá čekání na navrácení knihy a zároveň je kontrolován externí sklad, zda se kniha nenachází v něm. Pokud je kniha navrácena do knihovny nebo nalezena ve skladu a do knihovny dovezena, je zarezervována a proces pokračuje stejným způsobem jako v případě, že kniha byla dostupná v knihovně okamžitě. Práce ve skladu probíhají následujícím způsobem. Je provedena kontrola, zda se kniha ve skladu nachází. V případě, že není nalezena, nastává čekání na její dostupnost. Dostupná kniha je připravena na převoz a následně dopravena do knihovny. Je jasné, že takovýto popis je poměrně nepřehledný, nepřesný a udělat si pomocí něj představu o tom, jak celý proces funguje, není vůbec jednoduché. Ke zpřehlednění nám pomůže snad jen použití co nejjednoduššího jazyka bez přílišného množství přídavných jmen a vhodné dělení textu na odstavce. Na druhou stranu se bez textového popisu neobejdeme. Každý proces, který chceme modelovat, by měl být nejdříve popsán textovou formou, ze které následně vycházíme. Proto i při práci se všemi dále popsanými modelovacími nástroji budeme de facto vycházet z právě uvedeného textového popisu. 13

14 3.2 Vývojový diagram (flowchart) Vývojové diagramy byly představeny již v roce 1921 Frankem Gilbrehtem3. Jedná se o velmi široce používaný nástroj, který bývá často používán pro vizualizaci algoritmů. Jelikož definice pojmu algoritmus4 a proces jsou v podstatě velmi podobné, byly vývojové diagramy používány i jako jeden z prvních modelovacích nástrojů pro byznys modely. Bohužel není grafický jazyk vývojových diagramů příliš bohatý a obsahuje běžně pouze následující elementy. Startovací a ukončující aktivita (start, end) Tyto aktivity jsou obvykle zobrazeny zakulaceným obdélníkem a jsou pojmenovány jednoduše jako start a konec. Startovací aktivita se objevuje v diagramu pouze jedna, zatímco ukončujících může být více. Každý pak označuje ukončení procesu za jiných okolností. Startovací ani ukončující aktivita nevykonává žádnou činnost kromě samotného odstartování nebo ukončení procesu. Umožňuje nám pouze jednodušší orientaci v diagramu. Krok procesu (processing step) Kroky procesu jsou zobrazeny na diagramu obdélníčky. Podle názvosloví byznys modelování se může se jednat o aktivitu nebo subproces. Pojmenování by mělo být voleno tak, aby bylo dostatečně jasné, co daný krok vykonává. Kroky procesu můžeme dále dekomponovat. Na diagramu lze takový krok rozpoznat podle toho, že má zdvojené boční strany. Rozhodovací blok (decision) Rozhodovací blok znázorňuje podmínku nebo kontrolu. Podle výsledku pak proces může pokračovat jednou z vycházejících větví. Na diagramu je zobrazen kosočtvercem stojícím na jednom z vrcholů. Kontrolní toky (flow of control) Kontrolní toky na diagramech znázorňují přechody mezi ostatními elementy diagramu. Obvykle není nutné, aby byly pojmenovány. Pojmenování využíváme pouze tehdy, pokud je zdrojem toku rozhodovací blok. Pak pojmenování označuje výsledek tohoto bloku. Na diagramech jsou kontrolní toky znázorněny šipkami. 3 viz 4 definici je možné najít například na 14

15 Obrázek 3: Elementy vývojového diagramu Vývojový diagram procesu obsluhy výpůjčky Vývojový diagram ukázkového procesu je možné zhlédnout na obrázku v příloze 1. Celý proces začíná startovací aktivitou a následuje kontrola, zda je čtenář zaregistrován. Ta je, ostatně jako všechny další kontroly, namodelována pomocí rozhodovacího bloku. Pokud čtenář není v databázi registrací nalezen, proces je ukončen. Naopak při úspěšné autentizaci proběhne kontrola, zda knihovna požadovanou knihu vlastní. Při záporném výsledku je proces ukončen (využíváme stejnou ukončovací aktivitu jako při nepodařené autentizaci uživatele. V obou případech se jedná o ukončení v podstatě ze stejného důvodu, nejedná se proto o chybu). Po potvrzení vlastnictví knihy pokračujeme dalším krokem, kterým je ověření dostupnosti knihy. Podle zadání by mohly probíhat kontrola registrace čtenáře a kontrola vlastnictví knihy paralelně. To nám bohužel vývojový diagram neumožňuje namodelovat. V tomto případě se ale nejedná o velký problém a oba kroky jdou tak jednoduše za sebou. V případě, že je kniha v knihovně nalezena, proces pokračuje rezervací knihy. Problém ale nastane při snaze namodelovat případ, kdy kniha dostupná není. Potřebujeme totiž zároveň kontrolovat, zda kniha nebyla vrácena do knihovny, případně zda nebyla nalezena ve skladu. Ani jedna z těchto činností nemá přednost a v případě, že bychom tyto kroky zařadili za sebe, zasekli bychom se na prvním z nich i za předpokladu, že by druhý krok umožnil knihu dodat. Rozhodl jsem se pro poměrně nestandardní přístup, a to použití dvou větví s jedním popiskem, což nám v podstatě umožňuje znázornit jejich paralelní průběh. Práce ve skladu jsou jediným subprocesem tohoto modelu, což poznáme podle zdvojených bočních stran obdélníku, který tento krok znázorňuje. Krok rezervace knihy může být započat, pokud je splněna alespoň jedna z podmínek. Buď byla kniha v knihovně dostupná okamžitě, byla dovezena ze skladu, nebo byla navrácena. O rezervaci je následně pomocí dalšího kroku odeslána zpráva. 15

16 Další rozhodovací blok směruje aktivitu dál podle toho, zda se čtenář pro knihu do knihovny dostavil do 10 dní. Pokud se tak nestane, je rezervace zrušena a celý proces ukončen. Po úspěšném předání knihy je výpůjčka už jen pomocí posledního kroku zaevidována a celý proces je ukončen. V příloze 2 je možné prohlédnout si ještě dekompozici subprocesu Práce ve skladu. Ten už je poměrně jednoduchý a skládá se pouze ze tří kroků a jednoho rozhodovacího bloku. Nejdříve pomocí rozhodovacího bloku zkontrolujeme, podobně jako v knihovně, zda je kniha ve skladu dostupná. Pokud je kniha ve skladu nalezena, je pomocí dalšího kroku připravena k přepravě, následně je v posledním kroku přepravena do knihovny a subproces je ukončen. Pokud kniha není ve skladu dostupná, pokračuje proces čekáním. Kniha se z nějakého důvodu může navrátit ne do knihovny, ale do skladu. A právě tento případ tento krok ošetřuje. Zhodnocení vývojového diagramu Jediné, co nám vývojový diagram dovoluje zobrazit, je jednoduché rozhodování a elementární činnosti, ze kterých se modelovaný proces skládá. Pokud je naším cílem modelovat složitější proces, ve kterém si s jednoduchým rozhodováním nevystačíme, je vývojový diagram nástrojem nevhodným. Hlavní problém tkví v nemožnosti namodelovat paralelní vykonávání dvou a více aktivit. Můžeme sice zvolit jinou cestu, ale pak model může zbytečně nabývat na obsáhlosti a přitom nebude vypovídat o tom, jak proces ve skutečnosti funguje. Je třeba si uvědomit, že se nejedná o nástroj uzpůsobený pro byznys modelování. Proto pokud existuje jiná cesta, doporučuji se vývojovým diagramům vyhnout velkým obloukem. 16

17 3.3 Diagram datových toků s řízením (control data flow diagram) Diagram datových toků s řízením (často je používána zkratka CDFD) je dalším z nejdéle používaných nástrojů pro modelování procesu. Jeho počátky lze nalézt již v 70. letech 20. století a za jeho vynálezce je označován Larry Constantine5. Jelikož se jedná o velmi široce používaný modelovací nástroj (používá se například i ve strukturované analýze systémů), dá se předpokládat, že existuje velké množství lidí, kteří jsou schopni tyto diagramy číst. Na druhou stranu velkou nevýhodou je to, že se lze setkat s mnoha grafickými notacemi a ačkoli ty jsou velmi podobné, může být výsledek zavádějící. Rozeberme si teď jednotlivé elementy, se kterými se lze na CDFD diagramech setkat. Terminátor (terminator) Terminátor v CDFD diagramu reprezentuje roli. Tedy kohokoli, kdo do procesu zasahuje zvenčí. Značí se obvykle čtvercem, pouze v notaci SSADM se můžeme setkat s oválem. Pro přehlednost se snažíme terminátory kreslit po stranách diagramu. Můžeme se také setkat s několika reprezentacemi jednoho terminátoru. Ty znázorňují jeden terminátor, dosáhneme tím ovšem větší přehlednosti. Pro snadnější orientaci lze použít pro různé terminátory různé barvy. Proces (process) Jedná se buď o subprocesy procesu zobrazeného na aktuálním diagramu, nebo aktivity. Každý proces je označen jednak názvem, který by měl popisovat, co se vlastně v procesu děje, jednak řetězcem čísel, pomocí kterého je možné se zorientovat mezi jednotlivými diagramy. Řízení (Control process) Řízení je zvláštním případem procesu, který umožňuje upřesnit spouštěcí podmínky klasických procesů. S těmi komunikují pomocí vstupních a výstupních signálů, které znázorňují speciální řídící toky (control flow). Graficky řídící procesy i toky zobrazujeme stejně jako jejich běžné varianty, pouze použijeme přerušované čáry místo plné. Datový tok(data flow) Jak již název napovídá, datové toky znázorňují data, která si vyměňují procesy mezi sebou, případně která jsou vyměňována mezi terminátory a procesy. Datové toky jsou zobrazeny šipkami. V různých notacích se můžeme setkat pouze s různými požadavky na jejich zalamování. Problémem může být rozmístit ostatní elementy na diagramu tak, aby se datové toky mezi nimi co nejméně křížily. Při pojmenovávání toků je důležité dávat si pozor, aby 5 viz 17

18 dva toky, které znamenají něco jiného, neměly stejné jméno. Proto se často v názvech lze setkat s přídavnými jmény, které přesněji popisují data, která jsou tokem vyměňována. Paměťové místo (datastore) Paměťové místo znázorňuje úložiště dat (například databázi), do kterého lze ukládat data pro pozdější použití, případně naopak dříve uložená data číst. V případě byznys modelování nemusí paměťové místo znamenat nutně jen něco imaginárního. Stejně znázorňujeme například skladiště materiálu, který je během procesu využit. Obrázek 4: Elementy CDFD v různých notacích Při tvorbě CDFD diagramu je nutné vyhnout se datovým tokům vedoucím mezi dvěma terminátory, případně mezi terminátorem a paměťovým místem. Tato komunikace by vždy měla být zprostředkovaná nějakým procesem, i kdyby byl přidán v podstatě uměle. V analýze a návrhu systémů se hovoří o pravidle, kdy by na diagramu nemělo kvůli přehlednosti být zobrazeno v součtu více než 9 a naopak méně než 5 procesů a pamětí.6 Troufám si ale říci, že s dostatečnou mírou rozumu a estetického cítění je možné tento počet při modelování byznys procesů překročit. Jedná se tedy spíše o doporučení. Další odlišnost je pak v komunikaci mezi procesy a paměťovými místy. Při modelování byznys procesů není nutné, aby do každého paměťového místa bylo v procesu zapisováno 6 pro více informací nahlédněte do slajdů předmětu Analýza a návrh systémů 18

19 i čteno. O zapisování a čtení se totiž mohou starat dva odlišné procesy, přičemž my modelujeme právě jeden z nich. Diagram datových toků procesu obsluhy výpůjčky Diagram datových toků obsluhy výpůjčky je možné vidět v příloze 3. Rozložení prvků může působit poměrně netradičně. Snahou ale bylo elementy uspořádat podobně jako na diagramech vytvořených ostatními nástroji. Celý proces odstartuje to, že čtenář odešle žádost o výpůjčku. Tento požadavek je odeslán procesu Kontrola registrace. Ten porovná získaná data s paměťovým místem Katalog čtenářů a pokud najde shodu, odešle dál již autorizovanou žádost o výpůjčku. Následně je podobným způsobem zkontrolováno, zda knihovna požadovanou knihu vlastní. Při pozitivním výsledku proběhne kontrola dostupnosti knihy. Ta využívá paměti Knihy v knihovně. Pokud kniha dostupná není, je odeslána žádost o knihu procesu Čekání na navrácení knihy a terminátoru Obsluha skladu. Obsluha skladu pak využije přijatých dat v subprocesu Práce ve skladu, který je dále dekomponován. Rezervace knihy může být provedena, pokud přijme knihu odeslanou ze skladu, vrácenou do knihovny, případně byla-li kniha při kontrole dostupnosti nalezena ihned. Na rozdíl od vývojového diagramu není třeba modelovat speciální proces pro odeslání zprávy čtenáři. Ten totiž nahrazuje datový tok nesoucí zprávu z procesu k terminátoru. Po rezervaci pokračujeme čekáním na dostavení čtenáře. V případě, že se čtenář dostaví včas, je kniha předána knihovnici a ta ji pomocí procesu Předání knihy čtenáři předá. Zároveň je celá výpůjčka zaznamenána do paměti Výpůjčky. Naopak pokud se čtenář do deseti dní v knihovně neukáže, je rezervace pomocí dalšího procesu zrušena a informace je zapsána do paměťového místa Knihy v knihovně. Dekomponovaný proces Obsluha skladu je opět velmi jednoduchý a nachází se k nahlédnutí v příloze 4. Obsluha skladu dodá procesu Kontrola dostupnosti knihy data o knize, která je požadována. Pokud je tato kniha nalezena, je dalším procesem připravena a odeslána řidiči, který se už postará o její dopravu. Na rozdíl od vývojového diagramu pak není třeba modelovat speciální proces pro přepravu, protože tato činnost je zde namodelována datovým tokem. Pokud kniha ve skladu nalezena není, čekáme na její dostupnost podobně jako v případě vývojového diagramu. Zhodnocení diagramu datových toků s řízením Diagram datových toků s řízením nám umožňuje zakreslit rozdělení procesu na jeho elementární činnosti a především zobrazit a analyzovat toky dat, jejich transformaci a cesty. Přehlednost vytvořených diagramů je na poměrně dobré úrovni, zvláště pokud se nám daří proces rozumně dekomponovat a držet na uzdě počet elementů na jednom diagramu. Nej19

20 větším nepřítelem je křížení datových toků na diagramu, nicméně i tomu se dá zabránit vhodným znásobením terminátorů na diagramu. Pokud nás na modelu zajímá hlavně to, jak jsou během procesu přeměňována data, případně materiál na výsledný produkt, je CDFD velmi vhodným adeptem na modelovací nástroj. Na druhou stranu je ale možné vytvořit CDFD prakticky bez datových toků a využít pouze toky kontrolní. V tomto případě zobrazujeme pouze jejich posloupnosti a lze částečně zobrazit i podmínky spuštění jednotlivých procesů. 20

21 3.4 IDEF Rodina nástrojů IDEF (Integration DEFinition), dříve označována jako ICAM Definition, byla vyvinuta v 80. letech na základě požadavků U.S. Airforce s cílem nalézt nástroje pro analýzu komunikace mezi lidmi a zefektivnění výroby7. Výsledkem byla široká paleta nástrojů pro tvorbu nejenom byznys procesů. Oficiální stránky nástroje8 hovoří o pěti typech modelů, pomocí kterých lze ve výsledku vytvořit velmi detailní náhled na proces. My se budeme hlouběji zabývat pouze jedním z nich, a to IDEF0. Tento nástroj poskytuje modelovací jazyk s velmi přesně danou sémantikou i syntaxí, který umožňuje pomocí sady diagramů a doprovodných textů provést funkční analýzu procesu. To znamená, že naším hlavním úkolem bude rozložit proces na subprocesy, případně aktivity, a podobně jako u CDFD zobrazit datové toky, řízení a zdroje. Podoba diagramů IDEF0 byla odvozena z graficky orientovaného jazyka SATD9 a lze najít jakousi paralelu například se vzhledem CDFD diagramů podle notace SSADM. Na diagramu IDEF0 se lze setkat pouze ze dvěma hlavními komponentami. Funkce (function) Funkce je znázorněním subprocesu nebo aktivity a je vždy krátce pojmenovaná tak, aby bylo jasné, co daná funkce vykonává. Každá z funkcí je také očíslována. Toto číslo je použito pro snadnou orientaci mezi diagramy při použití dekompozice. Že je funkce dále dekomponována, poznáme podle odkazu pod pravým dolním rohem obdélníčku, který funkci zobrazuje. Datový toky (data flow) Druhou komponentou použitou v IDEF0 diagramech jsou pak data, která jsou nějak svázána s některou z funkcí. Ta jsou znázorněna šipkami. Hrot šipky určuje, zda jsou data funkcí vysílána či naopak přijímána. Pokud je potřeba šipku zahnout, ohýbáme vždy o úhel 90. Zlom šipky se pak obvykle zaobluje. Velmi důležitou roli hraje směr, ze kterého šipky do funkce vstupují, nebo kterým naopak vystupují Vstup (input) - přicházejí do funkce vždy zleva. Jedná se o data nebo objekty, které budou následně funkcí transformovány na výstup Výstup (output) - odcházejí z funkce směrem doprava. Jedná se o data produkovaná funkcí, jinak řečeno transformovaný vstup Řízení (control) - přichází do funkce shora. Specifikuje předpoklady, za kterých funkce produkuje korektní výstup. 7 informace získány ze skript Metody byznys modelování 8 viz 9 více informací na wiki 21

22 Mechanismus (mechanism) - přichází do funkce zespodu. Určuje prostředky nutné pro provedení funkce. Obrázek 5: Ukázka jednoduchého diagramu IDEF0 Další důležité informace se nachází ve spodní části diagramu. Ta obsahuje název a číslo uzlu diagramu. To nám umožňuje snadno pochopit kontext mezi jednotlivými diagramy. Číslo uzlu je tvořeno spojením čísla uzlu vyššího diagramu a funkce, která je dekomponována. Diagram IDEF0 procesu obsluhy výpůjčky Diagram IDEF0 procesu obsluhy výpůjčky je možno vidět v příloze 5. Hned na první pohled asi nepříjemně překvapí velmi špatná přehlednost diagramu. Jedním z důvodů je jistě poměrně velké překročení počtu elementů doporučovaných na jeden diagram. Ten je ale překročen z důvodu dodržení dekompozice použité na ostatních diagramech. V případě IDEF0 diagramu není bohužel možné udržet rozložení elementů v prostoru podobně jako na jiných diagramech z důvodu významu směru datových toků. První funkcí je Kontrola identity uživatele. Jejím vstupem je požadavek výpůjčky a je řízena evidencí čtenářů. Podle toho, zda je čtenář nalezen v evidenci, nebo ne, je výsledkem buď autentizovaný požadavek výpůjčky, nebo zamítnutý požadavek výpůjčky. Ten dále nevstupuje do další funkce, a proto je v tomto případě proces ukončen. 22

23 Autentizovaný požadavek výpůjčky dále zpracovává funkce Kontrola vlastnictví knihy, která funguje velmi podobně, pouze využívá evidence knih. Výstupem při provedení funkce je Schválený požadavek výpůjčky. Ten je odeslán jako řízení funkci Kontrola dostupnosti knihy. Vstupem této funkce jsou knihy v knihovně (pro srovnání, v CDFD je tento vstup znázorněn paměťovým místem) a podle výsledku je pak odeslána buď žádost o knihu, nebo kniha k rezervaci, která byla získána ze vstupu. Žádost o knihu je využita ve funkcích Čekání na navrácení knihy a Práce ve skladu jako řízení. Vstupem první z nich jsou Vrácené knihy, druhé Knihy ve skladu. Výstup obou funkcí je totožný. Kniha k rezervaci. Funkce Rezervace knihy může přijmout potřebný vstup, Knihu k rezervaci, z jedné ze tří předchozích funkcí. Není třeba žádného řízení, funkce se pouze postará o to, aby byla kniha zarezervována, a odešle zarezervovanou knihu do dvou dalších funkcí. Těmi jsou Zrušení rezervace a Předání knihy čtenáři. Kromě toho je výstupem funkce ještě zpráva o rezervaci knihy, která by měla být přijata čtenářem. Čtenář bohužel nemůže být v diagramu znázorněn, proto nezbývá, než dostatečně přesně pojmenovat datový tok, aby bylo jasné, komu je určen. Funkce Zrušení rezervace může být spuštěna pouze za předpokladu, že od zarezervování knihy uběhlo 10 dní (o kontrolu se stará řízení funkce), a jejím výstupem je volná kniha. Naopak pokud se čtenář do deseti dní dostaví, je spuštěna funkce Předání knihy čtenáři, jejímž výstupem je předaná kniha a informace o výpůjčce. Tyto informace následně zpracuje poslední funkce, Zaznamenání výpůjčky. Dekomponovaný subproces už je podstatně přehlednější, obsahuje totiž jen 3 funkce, které se postarají o připravení a doručení knihy ze skladu do knihovny. Jistě nepřekvapí velká podobnost s CDFD diagramem, takže ani zde není třeba funkce pro přepravu. Tu totiž v podstatě znázorňuje datový tok vycházející z poslední funkce. Zhodnocení IDEF0 Diagram IDEF0 umožňuje znázornit rozdělení procesu na subprocesy a data, se kterými tyto subprocesy pracují. Umožňuje tak zachytit, jak se data transformují a k čemu jsou následně použita. Největší překážkou může být rozlišení, zda má být tok označen jako vstup, nebo řízení. Po pochopení definic je ale následné čtení diagramů díky rozdělení toků na různé směry poměrně jednoduché a není problém pochopit, jak proces funguje. Zároveň je nutné pochválit, že je metoda dobře popsaná co se syntaxe, tak i sémantiky týče. Nástroj je na tom ale poměrně špatně, co se přehlednosti týče. Při tvorbě větších diagramů většinou není možné vyhnout se křížení toků, případně jsou elementy na diagramu vedle sebe nasázeny poměrně hustě. Je proto vhodné držet se doporučeného počtu elementů na diagram. 23

24 3.5 Event-driven Process Chain Event-driven Process Chain (často se lze setkat se zkratkou EPC) bychom mohli přibližně přeložit jako diagram procesu řízeného událostmi. Jelikož se ale žádný překlad běžně nepoužívá, držme se názvu anglického, či spíše zkratky EPC. Autory tohoto nástroje byli pánové Keller, Nüttgens a Scheer10 a jejich primárním cílem bylo právě vytvoření takového modelovacího nástroje, který by nám pomocí událostí a aktivit umožňoval snadno a přehledně popsat proces. Zatímco úkolem IDEF0 nebo CDFD bylo hlavně pomoci nám odhalit funkce a data, které si tyto funkce předávají, EPC nám pomáhá určit, jak by se vlastně měl takový proces chovat, jak bude realizován a především jaký bude jeho časový průběh. Mnohé z aktivit totiž mohou probíhat souběžně (paralelně), což nám EPC umožní snadno zobrazit. Na modelu EPC se tak můžeme setkat s následujícími elementy. Aktivita (activity) Aktivita na diagramu reprezentuje nějakou činnost a je znázorněna obdélníčkem, obvykle se zakulacenými rohy. V podstatě se tedy podle názvosloví definovaném ve druhé kapitole může jednat buď o subproces, nebo aktivitu. Pro přehlednost jednotlivé elementy diagramu obvykle vybarvujeme. Aktivita je pak vybarvena zeleně. Událost (event) Události jsou na diagramu zobrazeny červeně vybarvenými šestiúhelníky. Znázorňují situace, které mohou nastat před (případně po) vykonáním aktivity. V podstatě můžeme hovořit i o vstupní a výstupní podmínce aktivity. Na diagramu se ve většině případů střídá událost s aktivitou, je proto zřejmé, že událost je obvykle vstupní podmínkou některé z aktivit a zároveň výstupní podmínkou aktivity jiné. Diagram vždy začíná a končí událostí. Takové události pak označujeme jako počáteční a ukončující. Logická spojka (connection) Logické spojky nám umožňují rozdělovat tok procesu na více větví, případně tyto větve spojovat. V EPC používáme pouze tři z mnoha známých spojek, sice AND, OR a XOR. Spojka AND požaduje splnění obou podmínek, OR vyžaduje alespoň jednu a XOR právě jednu. V diagramu značíme logickou spojku kolečkem s příslušným znaménkem logické spojky. Lze se setkat se spojkami ve dvou rolích - split (rozdělovací) a join (slučovací). Split spojka má jeden vstup a dva výstupy, naopak join spojka tvoří ze dvou vstupů jeden výstup. Doba trvání logických spojek je v procesu nulová. 10 informace získány ze skript Metody byznys modelování 24

25 Organizační jednotka (organization unit) Organizační jednotka určuje osobu nebo oddělení, které je zodpovědné za určitou aktivitu. Jedná se tedy v podstatě o role definované v druhé kapitole. Na diagramech organizační jednotky zobrazujeme ve žlutě vybarveném oválu s uříznutým rožkem. Lze se také setkat se zobrazením rolí jako obdélníčku stejné barvy. Informace, materiál, zdroj (information, material, resource) Element zobrazený na diagramu modře vybarveným obdélníčkem může znázorňovat například objekty nebo informace, které jsou nutné pro provedení aktivity, případně které jsou při probíhání aktivity spotřebovávány. V podstatě se jedná o entitu velmi podobnou jako paměťová místa v CDFD, tedy zdroj nebo úložiště dat, případně materiálu. Kontrolní tok (control flow) Pomocí kontrolních toků jsou ostatní elementy propojeny. Umožňují nám zobrazit časovou posloupnost aktivit. Na diagramech jsou kontrolní toky znázorněny pomocí šipek Obrázek 6: Elementy diagramu EPC EPC diagram procesu obsluhy výpůjčky Na základní EPC diagram procesu, který se objevuje v celé práci, je možné nahlédnout v příloze 6. Celý proces startuje událost, kdy přijde žádost o výpůjčku, a dále se tok rozděluje pomocí AND splitu na dvě větve. Paralelně je provedena kontrola identity uživatele a vlastnictví knihy. Následuje XOR split. Pokud uživatel není v knihovně registrován, nebo knihovna požadovanou knihu nevlastní, je požadavek zamítnut a celý proces je ukončen. Následuje AND join, který čeká, zda dostane jak potvrzení autentizace uživatele, tak vlastnictví knihy. Dále nastává událost, která říká, že je požadavek autentizován. Následuje kontrola dostupnosti knihy. Jelikož se proces může opět rozdělit na dvě možnosti, objevuje se XOR split a nastává buď událost, která říká, že je kniha v knihovně dostupná, nebo nedostupná. Pokud je kniha v knihovně nedostupná, jsou spuštěny dvě aktivity paralelně. Jsou prováděny práce ve skladu (jedná se o subproces, který bude dále dekomponován na vlastním diagramu) a zároveň čekáme na navrácení knihy od některého z předchozích čtenářů. 25

26 Po čekání na navrácení knihy se setkáme se dvěma událostmi za sebou. Nejedná se však o chybu, zkrátka jen proces může pokračovat pouze za předpokladu, že byla kniha navrácena a tím je spuštěna další událost, která říká, že je kniha dostupná. Po události, která říká, že je kniha dostupná, dojde k rezervaci a poslednímu větvení. Pokud kniha není čtenářem do deseti dní po rezervaci vyzvednuta, je kniha označena jako volná a proces je ukončen s tím, že je požadavek výpůjčky zrušen. Pokud se čtenář do knihovny včas dostaví, nastává příslušná událost a je spuštěna aktivita Předání knihy čtenáři. Po předání knihy už je celá výpůjčka pomocí další aktivity zaznamenána a proces je ukončen událostí Výpůjčka vyřízena. V příloze 7 je zařazen rozšířený diagram stejného procesu, který je obohacen o organizační jednotky, informace a materiál. Ten navíc ukazuje, kdo má dané aktivity na starosti a se kterými daty pracují. Na druhou stranu se ukazuje i nevýhoda, že v tak velkém diagramu je už poměrně problém zorientovat se. Nakonec si ještě v příloze 8 ukažme, jak by vypadal dekomponovaný subproces Práce ve skladu. Pokud ho porovnáme například s vývojovým diagramem, zjistíme, že v EPC diagramu jsou přidány všechny události, které dané aktivity spouští, což upřesňuje fungování procesu. Navíc je kontrola dostupnosti ve skladu rozdělena na dva elementy, protože v EPC není možné přiřadit spojce nějakou aktivitu a tím pádem je nutné pro aktivitu vytvořit vlastní element. Zhodnocení EPC Event-driven proces chain nám umožňuje namodelovat proces tak, aby bylo dobře vidět, jak jsou za sebou jednotlivé aktivity časově seřazeny, za jakých podmínek mohou být aktivity spuštěny a za jakých podmínek opět ukončeny. Navíc nám po rozšíření umožňují znázornit také organizační jednotky a zdroje, se kterými aktivity pracují. Co se přehlednosti týče, jsou na tom výsledné diagramy velmi dobře. Pokud použijeme rozšířenou variantu EPC, entit na diagramu sice přibude, ale díky barevnému i tvarovému rozlišení jednotlivých elementů není těžké se v procesu zorientovat. Jediné, co může dělat problémy, jsou logické spojky. Často se totiž stane, že jsou za sebou v diagramu dvě spojky, jedna v roli join a další v roli split, a to může být matoucí. Navíc je třeba dávat si pozor, abychom modelovali proces tak, aby nedošlo k zaseknutí. K tomu by mohlo dojít při nešikovném seřazení spojek za sebou. Pokud například nejdříve rozdělíme tok pomocí XOR splitu a následně tyto dvě větve spojíme AND joinem, není možné, aby takovýto proces dál pokračoval, protože podmínky pro AND join nebudou nikdy splněny. 26

27 3.6 UML, diagram aktivit (activity diagram) Jazyk UML byl původně svými autory (Booch, Rumbaugh a Jacobson) navržen za účelem sjednocení různých přístupů při tvorbě specifikací v různých fázích vývoje softwarového produktu. Postupem času se ale stal univerzálním jazykem pro vytvoření grafické dokumentace libovolných systémů, tedy je možné jej využít i pro byznys modelování. UML je neustále vyvíjeno a jeho aktuální verze je označena jako UML 2.2. V rámci jazyka se můžeme setkat s poměrně velkým množstvím diagramů, pro modelování byznys procesů je však nejdůležitější jeden z nich, sice diagram aktivit. Abychom byli schopni diagramy aktivit číst, představme si teď jeho nejdůležitější elementy. Startovací a ukončovací uzel (initial node, final node) Startovací uzel vždy modelovaný proces startuje, ukončovací naopak ukončuje. Žádnou jinou funkci neplní a neprobíhá v nich žádná jiná činnost. Na diagramu značíme startovací uzel černým kolečkem, ukončovací uzel černým kolečkem s dvojitou hraniční čárou. Aktivita (activita) Aktivita může na diagramu reprezentovat subproces, který může být dále dekomponován, případně atomickou aktivitu procesu. Aktivity jsou na diagramu znázorněny obdélníky se zakulacenými stranami. Aktivity se snažíme pojmenovávat tak, aby bylo jasné, co daná aktivita provádí. Událost (event) Objekt událost nám umožní znázornit na diagramu jakoukoli událost, na kterou je třeba během procesu reagovat. Běžnou událost na diagramu zobrazuje obdélník s jednou trojúhelníkově vykrojenou stranou. Pokud událost reaguje na nějaký časový údaj, nazýváme ji časovou událostí, kterou na diagramu symbolizují přesýpací hodiny. Rozhodovací blok (guard) Kosočtverec postavený na jednom z vrcholů v diagramu reprezentuje podmínku. Pro její popis lze popsat výstupní větve, což samo o sobě obvykle určí, o čem je rozhodováno. Můžeme ale popsat i samotný rozhodovací blok. V podstatě se jedná o spojku XOR. Podobně jako v EPC se používá také XOR join, který při vstupu alespoň jednoho toku dovolí procesu pokračovat. Synchronizace (synchronisation) Synchronizace je na diagramu znázorněna tlustou čarou a umožňuje nám rozdělit tok procesu na dvě paralelně probíhající větve, případně je následně opět spojit. Pokud je synchronizace použita pro spojení dvou toků, je pro pokračování nutné, aby byly přijaty oba vstupní toky. V podstatě se tedy jedná o spojku AND. 27

28 Kontrolní tok (control flow) Kontrolní tok umožňuje znázornit posloupnost jednotlivých elementů v diagramu. Kontrolní toky obvykle nejsou popisovány, výjimkou je situace, kdy je jejich zdrojem rozhodovací blok. Na diagramech jsou kontrolní toky znázorněny šipkami. Plavecká dráha (swimline) Pomocí plaveckých drah můžeme diagram rozdělit na několik částí, pomocí nichž lze rozpoznat, kdo je za kterou aktivitu zodpovědný. Tím v podstatě znázorňujeme role dle definice v druhé kapitole. Pokud plyne čas v diagramu shora dolů, plavecké dráhy vedou svisle, pokud plyne čas zleva doprava, používáme plavecké dráhy vodorovné. Obrázek 7: Elementy diagramu aktivit Diagram aktivit procesu obsluhy výpůjčky Digram aktivit obsluhy výpůjčky se nachází v příloze 9. Rozložení prvků na diagramu je v podstatě stejné jako na diagramech předchozích, pouze je použito rozložení zleva doprava. Po započetí procesu dochází k synchronnímu větvení a je paralelně provedena kontrola registrace uživatele a kontrola vlastnictví knihy. Na rozdíl od EPC ale není třeba kontrolu rozdělovat na aktivitu a logickou spojku. Oba elementy v diagramu aktivit vyjadřuje rozhodovací blok. Pokud knihu knihovna nevlastní, nebo uživatel není v knihovně registrován, je proces ukončen. Po úspěšné autentizaci a ověření vlastnictví knihy následuje kontrola dostupnosti knihy, kterou opět reprezentuje rozhodovací blok. V případě, že kniha není dostupná, tok se rozděluje na dvě větve. Zároveň čekáme na událost, která značí, že byla kniha navrácena do knihovny, a provádíme práce ve skladu. Práce ve skladu jsou subprocesem, použitý nástroj bohužel neumožňuje vizuální znázornění tohoto faktu. K rezervaci knihy a zároveň odeslání zprávy o této registraci může dojít, pokud je splněn alespoň jeden ze tří požadavků. Buď je kniha dostupná v knihovně hned při kontrole dostupnosti, byla dovezena ze skladu, nebo byla do knihovny navrácena. Tyto tři toky jsou spojeny pomocí rozhodovacího bloku. 28

29 Poté co je kniha zarezervována, čekáme pomocí rozhodovacího bloku, než si čtenář přijde knihu vyzvednout. Pokud se tak nestane do deseti dnů, je kniha označena jako volná a proces je ukončen. Při příchodu čtenáře je kniha čtenáři předána a celá výpůjčka je zaznamenána do systému. Plavecké dráhy na diagramu zobrazují rozdělení aktivit mezi jednotlivé role. Jedinou aktivitou, za kterou není zodpovědná knihovnice, ale obsluha skladu, jsou práce ve skladu. Na diagramu v příloze 10 je možné nahlédnout na dekomponovaný proces Práce ve skladu. Není ale nutné popisovat žádné zvláštní konstrukce ani vysvětlovat a zdůvodňovat použité elementy. Zhodnocení diagramu aktivit Diagram aktivit nám umožňuje přehledně zobrazit seřazení aktivit za sebou v čase a tyto aktivity přiřadit k rolím. Kromě toho lze využít i znázornění událostí, což výsledné diagramy ještě obohacuje a umožňuje nám tak procesy lépe namodelovat. Největším problémem při tvorbě modelového příkladu kupodivu bylo sehnat vhodný softwarový nástroj. Většina softwarových nástrojů je totiž zaměřena především na vývoj softwaru a jedná se proto o obrovské složité programy. Diagram aktivit může být dobrou náhradou za vývojový diagram. Grafická notace je velmi podobná, umožňuje nám nicméně zobrazit i paralelně prováděné aktivity a tím se ztrácí hlavní nevýhoda vývojových diagramů. Na závěr je také důležité zmínit, že UML je velmi rozšířený a známý jazyk, z čehož se dá usoudit, že výsledné diagramy budou pochopitelné pro velké množství lidí. 29

30 3.7 Notace Together Workflow Editoru Hned na začátku kapitoly je třeba říct, že Together Workflow Editor není notací pro byznys modelování, nýbrž softwarovým nástrojem, jehož notaci pro tvorbu byznys modelů si teď představíme. Tato notace je úzce spjatá s jinou, kterou představila organizace Workflow Management Coalition11 a její hlavní předností je, že umožňuje snadný export do XPDL. Formátu, který vychází z jazyka XML a umožňuje tak snadnou interpretaci modelu počítačem. Tím pádem se jedná o nástroj vhodný pro tvorbu worklow. Together Workflow Editor vyvíjí, jak již název napovídá, společnost Together a v současné době lze na internetu volně stáhnout verzi 2.4. Podívejme se teď s jakými elementy se lze na diagramech vytvořených s pomocí této notace setkat. Start procesu a konec procesu (start of process, end of process) Význam tohoto elementu je v podstatě stejný jako v dříve představených modelech. Startuje, případně ukončuje proces. Má nulovou dobu trvání a nic nevykonává. Umožňuje pouze snadnější orientaci v diagramu. Aktivita (activity) Že aktivita může v diagramu reprezentovat atomickou aktivitu, případně dále dekomponovaný subproces jistě nebude žádným překvapením. V této notaci se lze setkat s několika typy aktivit. Všechny jsou znázorněny obdélníčky, nicméně jednotlivé typy jsou od sebe graficky rozlišeny. Aktivita bez implementace (activity without implementation) označuje takovou aktivitu, která musí být vykonána manuálně některým účastníkem procesu. Automatizovaná aktivita (tool activity) je, jak již název napovídá, prováděna automaticky. To ovšem neznamená, že ji nemá nikdo na starosti. Stále spadá do kompetence některého z účastníků. Souběžná aktivita (subflow activity) umožňuje znázornit několik aktivit jako jednu. Nejedná se ale o subproces, pouze o zpřehlednění diagramu. Bloková aktivita (block aktivity) je znázorněním subprocesu, tedy činnosti, která může být dále dekomponována na atomické aktivity na dalším diagramu. To zvyšuje přehlednost diagramu. Na rozdíl od souběžné aktivity by mělo smysl vykonávat subproces samostatně. Směrovací aktivita (route activity) může sloužit pro vytvoření libovolného větvení, případně jako pomocná aktivita s nulovou dobou trvání. Zajímavé je v notaci Together Workflow editoru značení spojek AND a XOR. Pro tyto spojky není zaveden žádný speciální element, ale lze je vyčíst z tvaru elementu, který 11 oficiální stránky WFMC lze nalézt na 30

31 znázorňuje aktivitu. Pravá a levá strana obdélníčku může být rovná, vypouklá, případně vyříznutá. Spojku XOR, která je nastavena implicitně, značí rovná strana obdélníčku. Jestliže tedy chceme naznačit, že proces bude pokračovat pouze jedním z přechodů, bude pravá strana obdélníčku rovná. Pro vyjádření, že pro chod aktivity je nutný pouze jeden vstupní tok, naopak bude rovná levá strana. Pokud jsou pro vykonání aktivity nutné všechny příchozí toky, je levá strana vyříznutá. Naopak pokud chceme, aby byly vykonány obě následující aktivity, do kterých vedou toky, zvolíme vypouklou pravou stranu. Přechod (flow) Přechody propojují jednotlivé aktivity a označují, která aktivita následuje po vykonání jiné. I s přechody se lze setkat v několika variantách. Veškeré přechody jsou znázorněny šipkami, jednotlivé varianty jsou od sebe ale graficky odlišeny. Nepodmíněný přechod (unconditional) je základní variantou, kterou použijeme v případě, že je tento přechod proveden vždy, bez ohledu na jakékoli podmínky. Podmíněný přechod (conditional) označuje, že touto cestou bude proces pokračovat pouze při splnění nějaké podmínky. Pokud není splněna ani jedna z podmínek pro přechod po některé z podmínečných větví, pokračuje proces po větvi otherwise. Při provádění aktivity může dojít k výjimce. Pak proces pokračuje po speciálním výjimkovém přechodu (exception). Pokud není výjimka nějak identifikovaná, pokračuje proces po přechodu implicitní výjimky (default exception) Role (role) Role na diagramu znázorňují jednotlivé účastníky, kteří do procesu nějak zasahují. Graficky lze od sebe jednotlivé role rozpoznat jako pruhy, na které je diagram vodorovně rozdělen. Jedná se tak v podstatě o plavecké dráhy, se kterými se lze setkat i v jiných notacích. Kromě rolí, které sami vytvoříme, do diagramu bývá přidána speciální role Arbitrary expression. Do této plavecké dráhy jsou pak automaticky zařazeny všechny směrovací, blokové a souběžné aktivity. Obrázek 8: Elementy diagramu Together Workflow Editoru 31

32 Diagram procesu obsluhy výpůjčky v notaci Together Workflow Editoru Diagram zobrazující model obsluhy výpůjčky podle notace Together Workflow editoru je možné vidět v příloze 11. Kvůli přehlednosti není zavedena speciální plavecká dráha pro směrovací a souběžné aktivity. Model obsluhy výpůjčky začíná startovací aktivitou, a následuje aktivita směrovací, která rozděluje tok na dvě větve. Notace sama o sobě totiž neumožňuje, aby vycházely dvě větve hned ze startovací aktivity. Pravá strana této aktivity je vyboulená, což naznačuje, že obě následující větve budou vykonány paralelně. Je zkontrolováno, zda je uživatel v knihovně registrován a zda požadovanou knihu knihovna vlastní. V případě, že podmínka není splněna, pokračujeme do směrovací aktivity (notace neumožňuje jednou větví proces ukončit, druhou pokračovat) a z ní do ukončovací aktivity. Pokud jsou obě kontroly provedeny úspěšně, může nastat kontrola dostupnosti knihy v knihovně. Jestliže zjistíme, že je kniha v knihovně dostupná, pokračujeme do směrovací aktivity, která nám umožní rozdělení toku. Následně můžeme provést zároveň rezervaci požadované knihy a odeslat zprávu o tom, že tato rezervace byla provedena. Další směrovací aktivita není sice nutná, je ovšem použita kvůli větší přehlednosti diagramu. Proces pak může pokračovat předáním knihy, případně zrušením registrace. Po předání knihy je výpůjčka pomocí poslední aktivity zaznamenána a proces je ukončen. Naopak pokud kniha v knihovně dostupná není, pokračujeme do směrovací aktivity, která nám umožní paralelní provedení aktivity prací ve skladu a čekání na navrácení knihy do knihovny. Po provedení alespoň jedné z aktivit proces pokračuje rezervací knihy a dále stejným způsobem jako v případě, kdy byla kniha v knihovně okamžitě dostupná. Pokud nás zajímá rozdělení aktivit na manuální a automatické, lze z diagramu snadno vyčíst, že jedinou aktivitou, která je prováděna manuálně, je Předání knihy. Jedinou blokovou aktivitou v modelu jsou Práce ve skladu. Ty jsou zobrazeny na vlastním diagramu, který krátce popíšeme dále v textu. Poslední důležitou věcí je, že všechny aktivity zobrazené na hlavním diagramu, až na Práce ve skladu, jsou přiřazeny knihovnici. Diagram dekomponovaného procesu Práce ve skladu je možné vidět v příloze 12. Je už podstatně jednodušší a skládá se pouze ze čtyř aktivit. Po započetí procesu zkontrolujeme pomocí jedné aktivity dostupnost knihy ve skladu a pokud je kniha nalezena, další aktivita se postará o to, aby byla kniha dovezena do knihovny. Pokud nalezena není, čekáme za využití další aktivity do doby, než se ve skladu objeví. Aktivity jsou na diagramu rozděleny mezi dvě role, řidič a obsluha skladu. Zatímco obsluha skladu se postará o kontrolu dostupnosti knihy a čekání na její případnou dostupnost, o dopravu knih do knihovny se stará řidič. První dvě aktivity na dekomponovaném diagramu jsou automatické, příprava knihy k přepravě a samotná doprava jsou aktivity manuální. 32

33 Zhodnocení notace Together Workflow editoru Together Workflow editor je záležitostí dosti specifickou a úzce zaměřenou. To, že se jedná o nástroj postavený na jazyku XPDL, z něj dělá favorita pro implementaci workflow, nicméně možnosti prezentace výsledných diagramů jsou mizerné. Pochválit je třeba také rozdělení na automatické a manuální aktivity a zajímavě vyřešené logické spojky, které snižují počet elementů na diagramu. Na druhou stranu je v mnoha případech nutné používat směrovací aktivity, které mohou působit zmatečně, pokud není dostatečně vysvětlena jejich funkce. 33

34 3.8 BPMN (Business Process Model Notation) Standard Business Process Modeling Notation byl vyvinut skupinou Business Process Management Initiative12 v roce 2004, od té doby ale vývoj stále pokračuje. Na závěr roku 2008 byla přislíbena nová verze BPMN 2.0, nicméně práce se zdržely a v době psaní této práce nebyla dokumentace k novému standardu dostupná, proto se zaměříme na verzi 1.2 vypuštěnou na svět v lednu Primárním cílem bylo poskytnout takovou notaci, která by byla jednoduše pochopitelná všemi firemními uživateli, tedy od firemních analytiků, přes vývojáře, až po pracovníky, kteří budou následně procesy řídit a monitorovat. A tak vznikl Business Process Diagram (BPD), který je pomocí BPMN definován. Ten přináší jednoduchou množinu grafických prvků, které jsou od sebe snadno rozlišitelné a hlavně je snadno pochopitelné, co který z nich označuje. BPMN je vhodným nástrojem nejen pro modelování samotných proces, můžeme snadno modelovat i komunikaci mezi nimi. Takovým modelům pak říkáme B2B, neboli business to business. Pro začátek si ale tradičně popišme základní prvky, se kterými se lze na BPD setkat. Aktivita (activity) Význam aktivity je v podstatě stejný jako v jiných modelech. Může tedy znázorňovat subproces, případně atomickou aktivitu modelovaného procesu. Na diagramu jsou aktivity znázorněny obdélníky se zakulacenými rohy. Že je proces dále dekomponován, lze poznat podle ikonky +. Navíc je možné zobrazit, že aktivita může probíhat v cyklu, dokud není splněna podmínka. Tuto skutečnost značíme šipkou stočenou do kolečka ve spodní části aktivity. Poslední speciální variantou je aktivita, která může běžet ve více instancích najednou. Do spodní části pak kreslíme tři obdélníčky. Událost (event) Události, které nějakým způsobem ovlivňují běh procesu, znázorňuje na diagramu stejnojmenný element. Na diagramu jsou události značeny kolečkem. Nejčastěji se lze setkat s takovými událostmi, za kterých může další aktivita začít, nebo naopak současná skončit. Podobně jako v předchozích modelech se i na BPD lze setkat s počáteční, průběhovou a ukončovací událostí. Kromě toho je možné pomocí sady speciálních symbolů upřesnit, o jakou událost se jedná. Těchto událostí existuje poměrně velké množství. Popišme si ty z nich, se kterými se lze setkat nejčastěji. jednoduchá událost je variantou, u které není nijak upřesněno, o jakou událost se jedná. Pokud nelze vybrat přesnější typ, použijeme jednoduchou událost komunikační událost má vždy něco společného s odesíláním či přijímáním jakýchkoli zpráv. Komunikační událost obsahuje ikonku obálky 12 oficiální stránky skupiny se nacházejí na 34

35 časová událost značí, že nastal nějaký důležitý moment v čase, který ovlivňuje běh procesu. V kolečku události jsou pak nakresleny hodiny podmínková událost je taková, při které se mění důležité okolnosti, za kterých se proces vykonává. Takovou událost označuje list papíru v kolečku signální událost značí zachycení nějakého signálu, který může být přijat například z jiného, paralelně probíhajícího procesu. Na diagramu je zakreslena trojúhelníčkem v kolečku dvě odkazové události mohou být použity jako náhrada toku, pokud se diagram nevejde na jeden papír. Je vhodné tuto událost dále popsat pomocí anotace. Upřesňující ikonkou je šipka pomocí chybové události můžeme zareagovat na jakoukoli chybu, která během procesu nastane. Tento typ události poznáme podle ikonky blesku stornovací událost umožňuje ošetřit zrušení procesu nebo jeho části kýmkoli, kdo do procesu zasahuje. V kolečku je nakreslen křížek událost okamžitého ukončení umožňuje přesně to, co říká její název. Značí ji plné kolečko v kroužku. posledním typem je složená událost. Ta může označovat složitější složení některých ze dříve popsaných událostí. Je označena pětiúhelníkem v kolečku Brána (gateway) Brána označuje rozdělení, případně souběh větví procesu. Jedná se tedy v podstatě o jiné pojmenování logických spojek. V BPMN se můžeme setkat hlavně se spojkou XOR nebo AND. XOR značíme kosočtvercem postaveným na jednom z vrcholů, AND má navíc uvnitř znak +. Pokud může proces pokračovat jednou, případně více větvemi, jedná se o spojku OR, která je znázorněna kolečkem uprostřed kosočtverce. Poslední z bran, se kterou se lze poměrně často setkat, je brána reagující na událost. Za takovou branou jsou ve všech směrech umístěny události a proces pokračuje tou větví, jejíž událost nastala jako první. Taková brána je označena pravidelným pětiúhelníkem. Pokud brána pracuje se složitějším spojením dříve představených spojek, je možné do kosočtverce zakreslit hvězdičku, která tuto skutečnost označuje. Tok (flow) Lze se setkat se třemi základními druhy toků. Prvním z nich je sekvenční tok (sequence flow), který ukazuje posloupnost jednotlivých aktivit, událostí a bran. Tyto toky znázorňuje plná šipka s plným hrotem. Dále se lze setkat s tokem zpráv (message flow). Ten se užívá hlavně v B2B diagramech, případně při propojení aktivity s datovým objektem. Znázorňuje tok zpráv mezi jednotlivými prvky. Tok zpráv na diagramu znázorňuje přerušovaná šipka, obvykle s prázdným hrotem. 35

36 Poslední variantou je pak asociace (association), která umožňuje spojit objekt s dodatečnými informacemi o něm. Asociace je na diagramech znázorněna tečkovanou čárou. Datový objekt (data object) Datový objekt umožňuje zobrazit data, případně materiál, se kterým aktivity pracují. Jedná se tedy v podstatě o element stejného významu jako například paměťová místa v CDFD. Na diagramu jej znázorňuje obdélník s přeloženým rohem (list papíru). Skupina (group) Pokud potřebujeme znázornit, že několik aktivit v procesu má něco společného, například kvůli dokumentaci, můžeme využít elementu skupiny. Takovou skupinu pak uzavřeme do obdélníku kresleného přerušovanou čarou. Anotace (annotation) Anotace je v podstatě přídavným textovým popiskem vnořeným do diagramu, který může pomoci pochopení jiného elementu. Anotaci potom s tímto elementem spojujeme pomocí asociačního toku. Plavecká dráha (swimline) Diagram může být rozdělen do drah, které pak označují role zasahující do procesu. Do drah můžeme rozdělit aktivity podle toho, kdo za ně zodpovídá. Jelikož čas v BPD plyne zleva doprava, dráhy dělí celý diagram (lze se setkat s anglickým označením pool, neboli bazén) na horizontální vrstvy. Obrázek 9: Elementy BPD 36