Workflow és Petri hálók Workflow fogalma Mai világunkban egyre nagyobb szerepet kapnak a workflow által irányított rendszerek és a workflow alapú szemléletek. A workflow, vagy munkafolyamat definícióját több oldalról is megközelíthetjük. A workflow alapvetően megismételhető üzleti tevékenységi minták sorozatából áll, amelyet egy szervezet erőforrásainak folyamatokká alakításával nyerünk. Ezek a folyamatok anyagátalakítással, szolgáltatások nyújtásával, információ feldolgozással foglalkoznak. Egy absztraktabb vagy magasabb szintű megközelítésből a workflow egy reprezentációja a valódi munkamentnek. A workflow egy munkafolyamat lépéseit foglalja össze, amely állhat feladatokból, eseményekből, interakciókból. A workflow lépései több személyhez is kötődhetnek. A folyamat végeredményeként a szervezet tevékenységeit bővítjük újabb értékekkel. Egy szekvenciális workflow-ban minden lépés függ az azt megelőző lépéstől, azonban léteznek párhuzamos workflow-k is melyekben a kettő vagy több lépés egyszerre is történhet. A workflow egy másik definícióban egy gráf, mely megszabott konstrukciókból állhat. A workflow egyik előnye, hogy algoritmizálható, könnyen programmá alakítható. Ez abból fakad, hogy a workflow-ban megtalálhatóak a programozásban megszokott konstrukciók. A workflow gráfban használható konstrukciók a következőek:
szekvencia o A feladatok a workflow által definiált sorrendben történő szekvenciális végrehajtása
párhuzamos végrehajtás o Párhuzamos
workflow-kban
két
feladat
párhuzamos
végrehajtása
is
előfordulhat
elágazás o A workflow-ban találhatóak döntési pontok. Az elágazás egy feltétel kiértékelése után annak eredményének ágán található feladat végrehajtása.
iteráció o Amíg az iteráció feltétele igaz, addig az utána lévő feladatok többszörös végrehajtása.
Üzleti folyamatok A workflow-k egyik legfontosabb felhasználási területe az üzleti folyamatok tervezése, így a workflow fogalmához szorosan kapcsolódik az üzletifolyamat-kezelés (Business Process Management röviden BPM) fogalma. Az üzletifolyamat-kezelés egy teljes körű kezelési megközelítés, amely arra fókuszál, hogy elegyengessen egy szervezetet a kliensek akaratával és szükségleteivel. Elősegíti a hatékonyságot az újítások és rugalmasság felé való törekvés és a technikai integráció során. A BPM folyamatosan próbálja meg tökéletesíteni a folyamatokat. Épp ezért „folyamatoptimalizációs folyamatként” is lehet értelmezni. Az üzleti folyamatok speciális workflow-k, amelyek gráfja különleges elemeket tartalmaznak. A lehetséges elemek: Flow objektumok, összekötő objektumok, asszociációk. A flow objektumok lehetnek események, tevékenységek vagy kapuk. Az események lehetnek a workflow belépési és kilépési pontjai, emellett lehetnek köztes események. A tevékenységek lehetnek feladatok (task), alfeladatok (subprocess), tranzakciók vagy hívási tevékenységek (call activity). A kapuk alatt az elágazási pontokat értjük. Ezek a pontok lehetnek valamilyen eseménnyel kapcsolatosak, amely lehet egy kitüntetett esemény, egy párhuzamos független esemény, de akár egy komplexebb feltételrendszer eredménye is. Az üzleti folyamatokat workflow-k segítségével automatizálni is szokták. Az üzleti folyamatok különböző dokumentumokat, döntési pontokat tartalmaznak, melyeket azonosítanunk kell és szabályokat kell rájuk felállítani az automatizálás során. Mindezek lehetővé teszik, hogy létrehozzunk egy szabály alapú döntéshozó rendszert, amely felgyorsítja a szervezet működését. Az üzleti folyamatok automatizálásának kialakítását négy fázisra lehet bontani: felmérés és tervezés, végrehajtás, monitorozás és folyamat optimalizáció.
Felmérés és tervezés fázis magába foglalja mind a meglévő folyamatok felmérését és azonosítását, mind az elvárt működési modellek meghatározását. A tervezési szakasz kiterjed továbbá a „mi lenne ha” típusú elemzések elvégzésére, pl. „Mi lenne, ha egy adott feladat erőforrása a meghatározotthoz képest 80%-ra csökkenne?” A tervezési szakasz eredményeinek implementációja, mely érinti mind az emberek, a rendszerhasználat és folyamati lépések körét már önmagában csökkenti a folyamatokban felmerülő hibák számát, előfordulását.
Végrehajtás fázis során a tervezés alatt meghatározott üzleti folyamatok leképezése történik oly módon, hogy törekedni kell az emberi interakció csökkentésére. A korábbi
üzleti folyamatokkal ellentétben az automatizált üzleti folyamatok szabályozottabbak, így egyszerűbb a változtatásuk és javításuk egyaránt.
Monitorozás az automatizált folyamatok nyomon követését jelenti, mely megteremti a hibák és problémák feltárásának lehetőségét és végső soron a folyamati lépések javítását.
Optimalizálási folyamat magába foglalja a monitorozási fázisból származó információk feldolgozását, valamint a folyamatok hatékonyságának növelési lehetőségét, mely jelentős anyagi és időbeli megtakarítást eredményez a vállalat számára.
Gyakorlati példák Review process A szoftverfejlesztés folyamatában elterjedt statikus tesztelési forma a review-k használata. Ez a szoftverfejlesztés minden szakaszában jelen van, a kezdeti specifikációktól kezdve a szoftver karbantartási fázisáig. A review vonatkozhat a fejlesztés menete során létrejött specifikációs, design vagy tesztelési dokumentumokra, vagy a forráskódra. Minden review során azonban követni kell egy process-t, amelynek megszegése review violation-nel jár. A folyamat definiálása egy workflow segítségével a legegyszerűbb. A workflowban megjelölt eszközökbe integrálnunk kell a megjelölt eseményeket és a process-től való eltérés esetén jelezni a review violation-t a felhasználónak. Egy code review esetében ez a review process az ábrán látható lépésekből állhat. Amint láthatjuk a workflow-ban egy belépési pont, egy végpont és több döntési pont is található. A workflow definiálja a review menetét, amitől eltérő útvonal esetén review violation-t követünk el. A gráfban több ciklust is találhatunk, amelynek oka, hogy a döntési pontok mind egy visszább lévő csúcsra mutatnak a gráfban. A code review főbb lépéseit leolvashatjuk a gráfról, amelyek addig ismétlődnek, amíg a kódban minden hiba kijavításra nem kerül, a két darab approve-ot el nem éri a kód értékelése és sikeresen elvégzi a fejlesztő a kódbázisba történő integrációt.
1. ábra: Review folyamat
Integrálási projektek A szoftverfejlesztési projektek nagy százalékát teszik ki manapság az integrálási projektek. A fejlesztőcégek célja egy szoftvertermékbe minél több funkcionalitást beletenni és minél több más programmal együttműködni. Az objektum orientált programozási modell ezt nagyban támogatja, mivel egyik fő célja a szoftver-újrahasznosítás, a szoftverek komponensekre bontása és azon komponensek újra felhasználása más és más programokban. A komponensek együttműködésére, kommunikációjára közös interfészeket használnak, amely lehet egy nyelvi interfész, hálózati protokoll vagy egy operációs rendszer által nyújtott adatátviteli forma (például pipe-ok). Ezt használják ki a workflow alapú integrációs projektek. Egy biztosítónál, banknál vagy kormányszervezetnél az ügyvitelt számos különböző szoftver segíti, különböző felhasználói felülettel. Az új alkalmazottnak ezek betanulása és kezelése problémát jelenthet. Ennek
megoldására használhatunk workflow-kat is megkönnyíteni ezt a betanulási fázist, vagy felgyorsítani a mindennapos munka menetét. A workflow-k használatát itt egy integrált workflow alapú kliensre értjük. Egy biztosító által használt programban minden folyamat definiálható egy workflow segítségével. Például vegyük az új káreset kitöltésének folyamatát. A káreset felvételénél megadott mezők kitöltése kötelező, mint a név, születési dátum, káreset helye, biztosított azonosítószáma, azonban vannak bizonyos mezők, amelyek csak bizonyos károk esetén szükségesek, mint egy autó rendszáma autóbaleset esetén. Azonosítva ezeket a döntési pontokat máris előállíthatunk egy folyamatábrát, amelyből generálhatunk egy form halmazt, amelyek meghatározott sorrendben követik egymást a kitöltött adatok függvényében. Ezeket a form-okat a biztosítást kezelő programba integrálva irányíthatjuk az ügyvitel menetét, ahol az alkalmazott folyamatosan láthatja, milyen esetben milyen mezők kitöltését várjuk el. Amennyiben a form-okat vezérlő program integrálva párhuzamosan fut a biztosítást kezelő programmal egy választott interfészen keresztül kommunikálva, képes lehet a workflow rendszerbe bevitt adatokat szinkronizálni a másik programmal, így konzisztensen tartva az adatbázist. Ez esetben a felhasználó a képernyő jobb oldalán láthatja a workflow szoftver által nyújtott leegyszerűsített lehetőségeket, a képernyő bal oldalán pedig az eredeti szoftver mezőit, mellyel a szinkronizáció történik.
2. ábra: Üzleti logikába integrált workflow alapú kliens
Windows Workflow Foundation Mivel a workflow-k egyszerűen algoritmizálhatóak, ezt egyes programozási eszközöknél is kihasználták. Erre egy példa a Windows Workflow Foundation (továbbiakban WF), amely egy egyszerűen elsajátítható eszközt ad számunkra .NET alapú programok fejlesztésére workflowk segítségével.
A WF elsősorban egy olyan eszköz, melynek segítségével workflow modellekből vagyunk képesek programokat generálni. A WF fő célja az üzleti folyamatok modellezhetősége volt. A Windows Workflow Foundation egy API, amely lehetővé teszi a programozók számára, hogy üzleti folyamatokat tervezzenek előre definiált tevékenységek halmazából. A WF lehetővé teszi, hogy a Visual Studio tervezőjének segítségével előállítsuk a vázát a programunknak workflow segítségével, majd kitöltsük ezt a vázat a szükséges plusz kódunkkal. A designer lehető teszi, hogy a megszokott workflow elemekkel és azok mellé a .NET-ben található programozási eszközökkel kiegészítve felépítsük azt az üzleti folyamatot, amelyet le szeretnénk implementálni programunkban. A WF segítségével könnyen összeállíthatunk egy konzolos alkalmazást, vagy az elkészített workflow-nkat lefordíthatjuk egy dll állományként, amelyet később más programunkban felhasználhatunk, amely a workflow-ban meghatározott üzleti folyamatot követi.
3. ábra: Windows Workflow Foundation tervező
Workflow fejlesztési módszerek Az üzleti folyamatokat nem elég definiálni, hatékonynak is kell lenniük. Ahhoz, hogy az üzleti folyamatokat hatékonyabbá tegyük a következő módszereket használhatjuk:
Six Sigma o Bármilyen üzleti folyamat esetében, a szigma érték egy olyan mérőszámot jelöl, amely azt fejezi ki, hogy a vevők által támasztott követelményekkel
szemben miként teljesít az adott folyamat. A szigma értéke a hiba valószínűségének Minél
magasabb
mértékét a
szigma
mutatja. értéke
annál
jobb.
A Six Sigma módszert alkalmazó folyamatok esetében kevesebb, mint 3,4 hibás vagy nem-megfelelő egység jut (egy) millió egységre - vagyis úgy is mondhatjuk, hogy ezek a folyamatok 99,99966 %-ban hibamentesek. Tehát a Six Sigma lényege az egységes, hibamentes termelés, amelyet csak úgy érhetünk el, ha hatékony üzleti folyamatokat használunk a termelés során és ragaszkodunk ezekhez a folyamatokhoz. A módszer elsődleges célja az egységes minőségű termékek előállítása.
Total Quality Management o A TQM egy szervezet hosszú távú céljai eléréséhez folyamatos javításokat alkalmazó módszer, amely a szervezet minden aspektusára kiterjedő folyamatokat fejleszti a rövidtávú célok elérése helyett.
Business Process Reengineering o A BPR egy üzleti management stratégia, ami a workflow-k és üzleti folyamatok elemzésére és tervezésére koncentrál egy szervezeten belül.
Lean systems o A Six Sigma-val közösen szokták említeni a Lean-t, ami egy vállalatszervezési, vállalatirányítási rendszer, amelynek célja, hogy a vállalat minél gazdaságosabban állítsa elő a termékeit. A módszer alapja, hogy a termelésből, az üzleti folyamatokból minden felesleges tényezőt, pazarlást eltávolítunk.
Theory of Constraints o A TOC egy management paradigma, amelynek lényege, hogy a kezelt rendszert, szervezetet egy olyan entitásként azonosítja, amely korlátozva van céljai elérésében valamilyen megszorítások miatt. A módszer célja ezeknek a megszorító tényezőknek az azonosítása és azok megkerülése, esetleges eliminálása a rendszerből.
Neural Workflow o A neurális workflow-k a megszokott workflow felépítés helyett az emberi agy felépítésén alapulnak, mint a mesterséges neuronhálók.
Petri-háló és a workflow kapcsolata A Petri háló tulajdonképpen egy páros gráf, amely helyekből és átmenetekből áll. A helyeket körrel, míg az átmeneteket négyzettel vagy téglalappal jelöljük. A programozásban az átmenetek felelnek meg az utasításoknak, míg a helyek a program különböző állapotainak. Azt, hogy a rendszer adott pillanatban melyik állapotban van, úgynevezett súlyozással jelezzük. A súly jelölésére kis fekete pontot használunk, amelyet az adott hely (körrel jelölt) szimbólumába rajzolunk, ezeket tokeneknek nevezzük. A helyeket és az átmeneteket élek kötik össze. Az éleket nyilakkal jelöljük, amelynek a feje a cél hálóelem felé mutat. Az élekkel fejezzük ki a hálón belüli kapcsolatokat, állapotváltozási lehetőségeket, irányokat. A Petri-hálókban használható konstrukciók:
Szekvenciális végrehajtás – Előbb A majd B
Párhuzamos végrehajtás – A és B egyszerre vagy bármely sorrendben o AND-split o AND-join
Szelektív végrehajtás – A vagy B o OR-split o OR-join
Iteráció – A végrehajtása többször
A workflowkat modellezhetjük Petri-hálókkal a megfelelő átírási szabályok segítségével. Egy workflowt úgy tudunk Petri-hálóval modellezni, hogy a feltételeket helyeknek, a feladatokat átmeneteknek feleltetjük meg. Az engedélyezett átmenetek a munkaegységeknek felelnek meg, az átmenetek tüzelése a tevékenységeknek. A megfelelő döntési pontokat a workflow-ban átírhatjuk a fent említett split és join konstrukciókra.
Felhasznált irodalom http://en.wikipedia.org/wiki/Workflow http://www.businessdictionary.com/definition/workflow.html http://en.wikipedia.org/wiki/Business_Process_Model_and_Notation#Flow_objects_and_con necting_objects http://www.docuvantage.com/what-are-business-process-management-and-workflow
http://www.lpsolutions.hu/bpm.htm http://www.businessdictionary.com/definition/total-quality-management-TQM.html http://www.di.unipi.it/~giangi/CORSI/SISD/Lezioni/WFModel.pdf Andrew Troelsen - Pro C# and .NET 4.5 Framework
