Rozšíření Petriho sítí pro modelování správy pracovních procesů

Abstrakt
Správa pracovních procesů (Workflow management) slibuje řešení dlouhodobého problému kontroly, sledování, optimalizace a podpory obchodních procesů. Hlavní oporou tohoto přístupu je jasné vyjádření logiky obchodních procesů, což umožňuje počítačovou podporu. Na následujících stránkách jsou popisovány výhody a nevýhody použití Petriho síti pro účely popisu procesů a dále popis určitých rozšíření, která se snaží odstranit některá slabá místa klasických Petriho sítí pro dané účely.

Obsah

1. Úvod

1.1 Systémy správy pracovních procesů (WfMS)

• Měl by být založen na formálním a proveditelném procesním modelu tak, aby metodicky pokrýval jak analýzu sytému, tak jeho simulaci.
• Měl by oddělit procesy od aplikačních programů tak, aby podporoval změny a vývoj procesů a sdílení částí procesů.
• Aplikační struktura systému pracovních procesů, tj. uspořádání a vztahy programových komponent a uživatelské činnosti musí být určeny pouze procesním modelem.
• Kontrola pracovních toků by měla být prováděna interpretací procesního modelu (jako DB systémy oddělily data od aplikačních programů, tak interpret pracovních procesů odděluje procesy od aplikačních programů).
• Konkrétní aktivity jsou řízeny procesním modelem, který lze kdykoliv změnit. To mimo jiné znamená, že celý WfMS musí mít otevřené aplikační rozhraní tak, aby umožňoval snadné přidávání nových aplikačních komponent.
• Skládání a vztahy mezi jednotlivými komponentami pro podporu procesů by měli podporovat decentralizovanou strategii.
• Musí podporovat vzájemnou spolupráci mechanismů, které pracují s heterogenitou a autonomií a musí poskytovat synchronizaci a konzistenci v distribuovaném prostředí.

1.2 Použití Petriho sítí

1. Formální sémantika s grafickým zápisem - řídící logika může být popsána graficky a přesto formálně. Formalizováno je i několik rozšíření Petriho sítí (barva, čas, hierarchie). Toho je možno velmi výhodně využít ve fázi návrhu a hlavně analýzy procesního modelu. Formální model je jednoznačný (význam konstrukcí je jasný), může být použit pro definici smluv, je nezávislý na nástrojích, je vhodný pro posuzování vlastností procesů (živost), umožňuje použití analytických technik.

2. Je založen na stavech místo na událostech - současné techniky pro modelování procesů (od datových toků až po algebru procesů) jsou založeny na událostech a stavy jsou “implicitní”. Stejně je to i se současnými WfMS. Jestliže se ovšem podíváme na následující obrázek, tak vidíme, že rozdíl mezi modelem založeným na událostech a modelem založeným na stavech (i když se zdá velmi jemný) má dosti značný vliv na možnosti popisu procesu. Je možno odlišit uvolnění úlohy od provedení úlohy (definice různých spouštěčů), snadné modelování soutěžících úloh (uživatel, čas) a další.
3. Bohaté analytické techniky - model procesů, který může být použit na různých úrovních rozhodování řídících pracovníků může být použit i pro analýzu některých vlastností takového modelu. Např. určení spolehlivosti procedury pracovního procesu, kam patří určení živosti, zbytečných úloh (neúčastní se zpracování procesů), ukončení procedury pro jakoukoliv úlohu, nebo celkový čas potřebný na provedení úlohy. Je také snadné určit časy odezvy, čekací stavy a “zaneprázdnění” zdrojů (uživatelů, skupin uživatelů).

Pro popis procesů jsou ovšem klasické C/E Petriho sítě nevhodné v tom smyslu, že jejich sémantické prostředky jsou velmi chudé, i když na druhou stranu existují velmi silné formální prostředky pro analýzu C/E sítí. Pro uspokojivý popis skutečných procesů je nutné použít Petriho sítě vysoké úrovně (High Level Petri Nets), jejichž sémantika je obohacena o barvu, čas a hierarchie. Tyto rozšíření jsou potřeba pro uspokojivou aplikaci Petriho sítí na popis rozsáhlých řídících procesů.

Jelikož značky v modelovaném systému často reprezentují objekty (dokumenty, zdroje, zboží), je v mnoha případech potřeba reprezentovat atributy těchto objektů. Tyto atributy se u Petriho sítí označují jako barva. Jestliže popis značek rozšíříme o čas - časové razítko, tak získáme časové barvené Petriho sítě, které jsou schopné stručně popsat mnoho řídících procesů, tak se dostáváme do dalších potíží. Výsledné modely jsou ovšem velmi rozsáhlé. Proto zavádíme konstrukci hierarchie, kterou nazýváme systém. Systém je souhrn míst, přechodů a případně podsystémů.
 

Další nevýhodou je, že neexistuje systematická správa vnějších zdrojů a nejsou podporovány obousměrné vztahy. V procesních sítí je možno zpracovávat spouštěcí signály z vnějšího okolí, ale ty obsahují pouze kontrolní informace v předem daném kontextu.

2. Zdroje v pracovních procesech

Úkolem WfMS a řídícího inženýrství je optimálně přeuspořádat množinu obchodních objektů, obchodních aktivit, zaměstnance, programy a kontrolní informace, které jsou mezi aktivitami vyměňovány. Tyto fyzické zdroje můžeme rozdělit na následující:

1. obchodní objekty - zde jsou míněny formuláře, dokumenty, archivní složky, objednávky, dodávkové listy, účty, atd. Tyto objekty mohou být primitivní, nebo složené.
2. aktivity - jednotky práce, které jsou spouštěny požadavkem na službu, zprávou o výsledku, nebo výskytem události. Jestliže aktivita “běží”, tak ji nazveme činností
3. vztahy mezi systémovými zdroji - odpovídají komunikačním linkám
4. činitelé - spouštějí aktivity - ruční, automatické, poloautomatické
5. role - pozice činitele v organizační struktuře, slouží k asociace činitelů a aktivit, které mohou činitelé spouštět.

Tato definice je mnohem vhodnější pro praktické použití, kdy je v modelech potřeba brát v úvahu v některých případech velmi široké okolí systému.

3. Objektové sítě vyššího stupně (HOON)

3.1 Prvky grafického jazyka

3.2 Struktura

Kontrolní sítě jsou odpovědné za správu zdrojů a interakci s uživatelem za běhu. Do obou těchto typů sítí patří CPs, které tvoří jejich rozhraní. Značky v CP mohou na jedné straně představovat požadavky, nebo potvrzení pro kontrolní síť, na druhou stranu mohou zastupovat čtyři typy zdrojů: síťové objekty (podsítě), komponentní objekty (programové komponenty), datové objekty (perzistentní data) a činitele (osoby, nebo programový kód).

Obecně mohou být na každém CP viditelné všechny sdílené zdroje. Viditelnost objektů je ovšem možno kontrolovat podle různých strategií Správcem zdrojů.

Tato struktura dovoluje, aby pracovní sítě generovaly požadavky na další zdroje, nebo výjimky. Na druhou stranu je možné do kontrolní míst přidávat nové značky.

3.3 Značky

Síťová úroveň
Na síťové úrovni jsou definovány síťové šablony pro často používané síťové struktury. Jsou to abstraktní podsítě bez kontrolních značek (neexistuje dědičnost, jsou tedy “ploché” a bez zprávy zdrojů). Z těchto šablon je možno přiřazením kontrolních značek odvozovat síťové objekty se jménem. Každá kontrolní značka, která zastupuje síťový objekt může mít přiřazeny predikáty, které určují podmínky pro aktivaci.

Komponentní úroveň
Na této úrovni mluvíme o programových podsystémech, nebo samostatných programových produktech. Dědičnost a klasifikace není uvažována. Objekty jsou černou skříňkou s dobře definovaným rozhraním, přes které jsou volány jednotlivé funkce objektu. Druhou možností komunikace s těmito objekty je zasílání zpráv.

Datová úroveň
Zde jsou uvažovány entity vytvořené OO technikami - zapouzdřením dat. Data jsou viditelná pouze přes služby - metody objektu, které s nimi pracují. Datové objekty jsou speciálním typem dat. Jsou sdílené a zůstávají fyzicky skryty. Manipulaci se sdílenými objekty provádí správce zdrojů a v modelu jsou pouze odkazy na tyto objekty. HOON podporuje kompletní OO model.

Pozn.: zprávy jsou v modelu buď na místech spojených s typem zpráva, nebo na meta místech. Instance zpráv jsou n-tice a mohou být použity pro výměnu zpráv a/nebo pro referenci sdílených objektů.

3.4 Meta místa

Barvení Petriho sítě nám umožní správně přiřadit vstupní značky na vstupní místa síťového objektu.

3.5 Další vlastnosti (postplaces, inscription, firing behaviour)

V modelu HOON mohou mít přechody implicitní postsety, které nejsou graficky vyjádřeny v grafu. To umožňuje dynamické vazby v rámci sítě. V tom případě hraje roli výběru kompatibilita a typová kontrola. V modelu jsou definovány dva typy: send a broadcast. V prvním případě existuje jediný příjemce, ale je o něm rozhodnuto až ve chvíli poslání značky. V druhém případě může být příjemců velké množství (pak je třeba např. uvažovat řešení množství konkrétních zdrojů a jejich správu).

Pozdní vazba (late-binding)

Ke značkám je možno přistupovat několika způsoby: first, last, user, labi. Poslední jmenovaný podporuje late-binding, kdy se dynamicky rozhoduje mezi dostupnými zdroji, daty, nebo síťovými objekty.

Spuštěním T₁ se s konečnou platností rozhodne o hodnotě EXP a tím se zvolí správná značka. Jestliže by od P₃ vedla kopírovací hrana s pozdní vazbou, tak po ukončení T’ bude značka (zdroj )vrácen zpět.

Jestliže dotyčná hrana bude mít označení FIRST/FIRST. Tak bude vzata první značka v řadě a zpět bude vrácena opět na první místo.

Inskripce

• Hrany - popis specifikuje kolekci značek, které mohou přes hranu přejít. Popisů může být několik spojených logickou spojkou AND, nebo OR. U hran s pozdní vazbou jsou výrazy určeny za běhu.
• Místa - značky jsou v místech uspořádány do pole, do kterého je možno přistupovat různými způsoby. U meta míst je definována vícerozměrné pole a při přístupu se používá popis <pod_místo, typ přístupu>.
• Přechody - zde jsou definovány predikáty odpálení, které určují podmínku nutnou pro provedení přechodu. Tyto logické výrazy se mění s příchody a odchody kontrolních značek v přechodu.

Změna stavu má tři fáze - odemknutí (preset odpovídá vstupním podmínkám), uvolnění (v případě pozdní vazby musí existovat odpovídající značky) a odpálení přechodu.

Samotné odpálení se řídí jedním ze tří následujících pravidel:

1. progress free (volný běh) - po uvolnění může přechod “vystřelit”, ale nikdy nemusí
2. progress prone (přikloněn k běhu) - odpálení závisí na jiných přechodech (může být i zrušeno) a nevíme ani kdy k němu dojde
3. immediate firing (okamžité odpálení) - po uvolnění musí být přechod okamžitě odpálen.

• vyhodnocení a aktivace kontrolních značek (týká se všech značek v příslušném CP) - příkladem je zpracování zdrojů, jež potom z CP zmizí.
• odebrání znače z presetu
• provedení činností měnících stav
• vytvoření nových značek v postsetu

4. Interpretace HOONa

5. Literatura