4. část: Modelování procesu

Petr Vašíček, IBA CZ

Minule jsme si představili grafickou notaci BPMN, jež je de facto standardem pro modelování business procesů, a uvedli jsme si nejčastěji používané elementy této notace včetně jejich vysvětlení na jednoduchém příkladu. V tomto díle budeme již modelovat proces popsaný v druhé části našeho seriálu. Začneme tvorbou modelu na vysoké úrovni a budeme dále zpřesňovat subproces znázorňující založení objednávky. Cílem bude uvést model do tvaru, který bude převeditelný do jazyka pro popis procesů na vykonatelné úrovni, v našem případě do jazyka BPEL (Business Process Executional Language).

Každý proces je možné vyjádřit různými typy diagramů a s různou mírou přesnosti podle toho, k jakému účelu bude sloužit. Jinak vypadá diagram, sloužící k hrubému náhledu na proces, a jinak diagram, jenž bude předlohou pro implementaci procesu v jazyce BPEL.

Neexistuje žádná specifická metodika, se kterou je BPMN spjato a která by popisovala, jakým způsobem se mají procesy modelovat a jakým postupem modely zpřesňovat. Obvyklé je však začít u modelu procesu na vysoké úrovni, tedy sekvenci subprocesů, a následně modelovat tyto jednotlivé subprocesy. Nejprve lze vytvořit hrubý model subprocesu a pak jej dále zjemňovat, přidávat aktivity, uspořádávat elementy do plaveckých drah atd.

V tomto díle se pokusíme nastínit jeden z možných způsobů, kterým toho lze docílit. Zopakujme tedy, že našim cílem bude vyjádřit proces ve tvaru, ve kterém ho budeme moci co nejsnáze převést do spustitelné podoby, tedy implementovat v jazyce BPEL. U minulého dílu seriálu se rozvinula zajímavá diskuze zejména ohledně názvosloví aktivit a událostí a bude určitě přínosem, pokud se i tentokrát podělíte o svoje názory a zkušenosti.

Tvorba high-level modelu

Diagram procesu na vysoké úrovni, tzv. high-level diagram, je zobrazen jako sekvence subprocesů. Jak bylo napsáno v minulém díle, subproces je aktivita, pod kterou se skrývá samostatný proces se svým počátkem a koncem. Tento subproces je zinicializován z high-level procesu v okamžiku, kdy do něj vstoupí tok procesu. Poté, co subproces skončí, pokračuje high-level proces sekvenčním tokem, vedoucím z grafického objektu, značícího subproces.

V našem seriálu se budeme věnovat pouze jednomu samostatnému procesu (Založit objednávku), jenž již nebude dekomponován na další subprocesy. Nyní se ale podívejme, jak by mohl vypadat high-level proces, kde Založit objednávku je jedním ze subprocesů:



Proces začíná požadavkem na vytvoření objednávky a následuje první subproces, Založit objednávku. Výsledkem tohoto subprocesu je mimo jiné to, zda byla objednávka schválena či nikoliv. Pokud byla zamítnuta, high-level proces je ukončen, v opačném případě pokračuje dál třemi zaznačenými subprocesy.

Modelování subprocesu

Soustřeďme se nyní na samostatný proces Založit objednávku. Ten začne požadavkem na vytvoření objednávky od Objednatele. Touto událostí by odstartoval uvedený high-level proces, my ji ale budeme chtít přesunout do procesu Založit objednávku, abychom ten mohli později implementovat jako samostatný proces bez implementování high-level procesu.

Budeme se tedy držet popisu, který jsme uvedli ve druhém díle seriálu. Po vytvoření objednávky probíhá její posouzení technickým oddělením. Pokud ji schválí, dojde k rozhodnutí podle ceny objednávky. V případě, že je nižší než 40.000 Kč, je objednávka přímo schválena, v opačném případě je navíc předána ke schválení finančnímu řediteli. Budeme nyní modelovat jen hrubý diagram procesu a využijeme tedy pouze základních grafických elementů notace BPMN – startovních a ukončovacích událostí, aktivit, rozhodovací brány a sekvenčního toku.



Uspořádání aktivit do plaveckých drah

V procesu vystupují tři aktoři – Objednatel, Technické oddělení a Finanční ředitel. Nyní budeme chtít uspořádat aktivity v procesu tak, abychom z diagramu mohli určit, kdo v něm provádí jakou činnost. K tomuto účelů slouží plavecké dráhy (swimlanes). Vytvoříme tedy jeden pool (v diagramu je pouze jeden proces), ten můžeme pojmenovat např. workflow, tedy „tok práce“. V něm vytvoříme plaveckou dráhu pro každého aktora, v diagramu tak budeme mít jeden pool, rozdělený na tři plavecké dráhy.



Zahrnutí systémových akcí do procesu

Naším cílem je převést proces na nižší úroveň, abychom jej mohli později snáze implementovat. Budeme tedy chtít zpřesnit proces zobrazení aktivit, jenž ukazují interakci s backendovou částí systému, v našem případě tedy např. modulem pro správu objednávek. Pokud uživatel vytvoří objednávku, budeme ji chtít zřejmě v systému uložit. Pokud je objednávka předána ke schválení nějaké roli, budeme to u ní chtít zachytit. A pokud je objednávka schválena či zamítnuta, chceme tento příznak u objednávky nastavit. Do diagramu přidáme novou plaveckou dráhu – Objednávkový modul. V ní vytvoříme zmíněné systémové akce (můžeme označit jako Service Task).



Vyjádření spustitelného procesu

Podívejme se nyní, jakým způsobem je proces „umístěn“ ve vyvíjeném systému. V prvním díle seriálu můžete na druhém obrázku vidět, že BPM vrstva se nachází mezi backendovou a prezentační vrstvou. Na následujícím obrázku jsou vybrány komponenty, na kterých můžeme vidět jakým způsobem proces interaguje se zbytkem systému. Uprostřed vidíme schéma nějakého procesu. Z jedné strany k němu přistupuje webová aplikace, tedy uživatelé. Na straně druhé proces komunikuje s moduly systému a využívá jejich funkcionality.



Nyní tedy potřebujeme proces dostat do tvaru, kdy bude na jedné straně komunikovat s uživateli a na straně druhé s backendovými moduly systému. Protože BPEL neumí řešit lidskou interakci s procesem, budou veškeré lidské akce „vytknuty“ z procesu a každá taková akce bude v procesu zaznačena přijmutím zprávy (message start/intermediate event) od účastníka procesu reprezentujícího právě lidské uživatele systému.

V procesu tak budeme mít tři účastíky, reprezentované třemi pooly – Uživatelé, Objednávkový modul a samotný proces, u něhož však nebudeme ohraničení poolu zobrazovat. První dva zmíněné pooly budou typu „blackbox“, nebude v nich tedy zobrazen jejich vlastní proces, pouze komunikace s hlavním procesem.



Vidíme, že takto vyjádřený proces skutečně interaguje na jedné straně s uživateli a na druhé s backendovou částí systému. Jeho rozhraní tvoří tři operace – vytvoření objednávky, rozhodnutí technického oddělení a rozhodnutí finančního ředitele. Tyto tři operace budou volány uživateli z webové aplikace. Na druhé straně proces volá rozhraní objednávkového modulu, jenž musí nabízet minimálně tři operace – vytvoření objednávky, nastavení schvalovatele a změnu stavu objednávky.

Takto specifikovaný proces již můžeme poměrně snadno převést do spustitelné podoby jeho implementací v nějakém jazyce pro popis vykonatelných procesů. V našem případě tedy do jazyka WS-BPEL. Proces bychom mohli ještě dále zpřesňovat, typicky odchytáváním výjimek a zaznačením chybového toku, specifikováním vypršení limitu (timeout) při čekání na rozhodnutí apod., ale pro jednoduchost již necháme proces v této formě.

V příštím díle

V příštím díle si představíme standard pro zápis spustitelných procesů, XML jazyk BPEL, ve kterém budeme dnes namodelovaný proces implementovat. Budeme poprvé pracovat s vývojovým nástrojem NetBeans a ukážeme si, jakým způsobem v něm lze implementovat navržený proces a ten pak nasadit do běhového prostředí (v našem případě BPEL engine v platformě OpenESB).