E-business modellez˝o nyelvek összehasonlítása és fejl˝odési trendjei Kovács Gábor 2012. november-december Kivonat E dokumentum célja a e-business modellez˝o nyelveket áttekint˝o dokumentum [1] kiegészítése a nyelvek képességeinek, korlátainak bemutatásával, illetve a nemzetközi tudományos és szakmai közösség által vázolt fejl˝odési trendjeinek áttekintésével. Az el˝oz˝o dokumentumban bemutatott négy modellez˝o nyelven túl további esetenként már historikus nyelvek is bemutatásra kerülnek különös tekintettel az üzleti kollaborációk során használt doménspecifikus nyelvekre. A fókuszban most is a bemutatott nyelvekkel való modellezés alapelvei állnak, és nem a nyelvek szintaxisa.
1. Bevezet˝o Az utóbbi évtized során az e-business modellezés és a modellez˝o nyelvek nagy fejl˝odésen mentek keresztül. Nyelvek tucatjait vezették be, amelyek közül számos megfelel˝o szoftvereszközök hiánya, illetve elterjedsége, valamint iparági támogatás hiányában kiveszett a mindennapi gyakorlatból. Jelenleg két modellez˝o nyelv rendelkezik ipari és technológiai támogatással: a BPMN és a BPEL azonban ezek fejl˝odésére hatással lehet a többi jelenleg is létez˝o és az esetleg már a gyakorlatból kiveszett nyelvek. A modellez˝o nyelveket jellemz˝oen a legnagyobb iparági szállítók által támogatott szabványosítási szervezetek fejlesztik, azonban van példa az akadémiai szférában fejlesztett nyelvre is. A nyelvek fejl˝odésének mozgatórugói kett˝osek, támaszkodnak az ipari igények változásaira, és mindeközben figyelembe veszik a modellezés és szimuláció témakörében elért elméleti eredményeket. A dokumentum mindkét szemszögb˝ol megvizsgálja a nyelveket. Bemutatja a nyelvek matematikai hátterét, kifejez˝o erejét, és olyan szoftvertechnológiai koncepciók kifejezésére való alkalmasságukat, mint például a tranzakciók modellezése vagy hibák fellépése esetén a kompenzáció. Üzleti szempontból a nyelvek eszköztárának 1
vizsgálata a f˝o kérdés, vagyis, hogy a nyelv képes-e olyan az üzleti modellezésben használt aspektusok figyelembe vételére, mint a B2B interkaciók, automatikus és manuális feladatok megkülönböztetése, feladatok életciklus-menedzsmentje, szerz˝odések modellezése, valamint a szervezeti és a technológiai infrastruktúra modellezése.
2. Folyamatmodellez˝o nyelvek áttekintése 2.1. Business Process Modeling Notation A BPMN 2 az OMG által 2011-ben kiadott szabvány [4]. A BPMN új változata már rendelkezik egy folyamatábra alapú grafikus kezel˝oi felülettel és egy XML alapú szövegreprezentációval is. A nagy modellez˝o nyelveket szállítókat bevonták a grafikai jelölések szabványosításába, éppen ezért minden szoftvereszköz ugyanazokat a szimbólumokat használja a folyamatmodellezésben. A BPMN els˝odlegesen modellezési célzattal került kialakításra. Habár a 2. változat már a végrehajtást helyezi el˝otérbe, célja továbbra is általános; egy emberi megértést támogató leírása az üzleti környezetnek. A megcélzott felhasználók els˝odlegesen inkább üzleti elemz˝ok és folyamattervez˝ok, mintsem szoftvertervez˝ok és -mérnökök. Matematikai értelemben a BPMN egy Petri-háló alapú megoldás, ennek megfelel˝oen alkalmas arra, hogy egy folyamatmodell helyességét elleno˝ rizni és igazolni tudja. A BPMN támogatja mind az eseti üzleti folyamatok összhangolását, valamint a különféle folyamatok együttm˝uk˝odésének leírását is. Az együttm˝uködésnek két különböz˝o nézete lehet. Lehet több folyam együttesen jelen ugyanabban az ábrában, jelölve az összes kapcsolódó kommunikációs elemeket közöttük. Másrészr˝ol, van lehet˝oség arra is, hogy egyetlen folyamat összhangolását írjuk le, amely nem feltétlenül tartalmazza a résztvev˝o folyamatok definícióját. A BPMN folyamatot végrehajtó szervezetet egy téglalap jelöli grafikusan, horizontálisan vagy vertikálisan tartalmazza a szervezet nevét. A konkrét feladat végrehajtója lehet emberi er˝oforrás, egy szervezeti hierarchiába illeszked˝o szerep, vagy egy technológiai infrastruktúrában létez˝o szolgáltatás, amelyet egy sávval jeleznek a téglalapon belül, azaz egy címkével ellátott négyszöggel a végrehajtó szervezet négyszögén belül. A BPMN folyamatmodell három elemi egységet tartalmaz: tevékenységeket, eseményeket és kapukat. Ezek az egységek vagy folytonos, vastag nyíllal vannak összekötve, ahol is a nyíl a végrehajtási láncban következ˝o elemre mutat, vagy olyan vállalati er˝oforrásokat reprezentáló adatobjektumokkal vannak összekötve pontozott nyíllal, amelyek az er˝oforrásokra mutatnak. Üzenetváltás alapú együttm˝uködést két folyamat között pedig a szaggatott nyíl jelez a küld˝ot˝ol a fogadó fél 2
felé mutatva. A tevékenységek a modellezett vállalatban végrehajtásra kerül˝o üzleti tevékenységeket jelölnek. A tevékenység lehet egyszer˝u üzleti feladat vagy összetett folyamat, illetve egyidej˝uleg vagy ciklikusan is végrehajtható. A tevékenységeket lekerekített szél˝u négyszögekkel jelöljük. Az események azokat a történéseket jelölik, amely a végrehajtás során keletkeznek, indíthatják, megszakíthatják vagy befejezhetik a folyamat végrehajtását, vagy eseményeket generálhatnak más folyamatok részére. A folyamat maga egy bemeneti és egy kimeneti esemény között értelmezett. A bemeneti eseményeket körrel jelöljük, közbens˝o eseményeket kett˝os határvonalú körrel, míg kimeneti eseményeket vastag vonalú körrel. Az esemény jelezheti egy üzenet elkapását, határid˝ot, egy üzleti szabály alkalmazását, hibát, egy hiba kompenzációját, valamint ezek tetsz˝oleges kombinációját is. A kapuk a vezérlési folyamat szétválását és egyesítését jelzik. Öt kaputípust határoztak meg. A legegyszer˝ubb az ÉS-kapu, amely két vagy több kimeneti folyamatot hoz létre a szétválásnál, illetve szinkronizálást valósít meg, azaz az egyesítésnél valamennyi folyamág eredményét megvárja. Az adat alapú XOR-kapu el˝ore meghatározott feltételek mentén a feltételekre kizárólagosan illeszked˝o, egyetlen kimeneti ágat aktivizál. Az esemény alapú XOR-kapu a következ˝o köztes esemény függvényében választja ki azt az egyetlen ágat, amelyen a végrehajtás folytatódik. Amennyiben az XOR-kapukat egyesítésre használjuk, akkor kizárólag egy bemenet aktiválhatja az egyetlen kimeneti ágat. Az OR-kapuk több, különböz˝o végrehajtási ágat is aktiválhatnak, és több beérkez˝o ág is aktiválhatja o˝ ket az egyesítésnél. Az összetett kapuk pedig lehet˝ové teszik tetsz˝oleges szétválási és egyesítési tulajdonság kialakítását.
2.2. Business Process Execution Language BPEL az egy OASIS által szabványosított, webszolgáltatás alapú üzleti folyamat-végrehajtási nyelv. A jelenlegi legfrissebb szabvány a 2007-ban kiadott WSBPEL2.0 [5]. A BPEL is a könyv megírásának idejében a legmeghatározóbb üzleti folyamat összhangolási nyelv. A BPEL folyamatokat az üzletifolyamatkezel˝orendszer hajtja végre, amelyek webszolgáltatásokra képz˝odnek le a szolgáltatás alapú architektúrában. Mintegy tucat kereskedelmi és ingyenes BPEL motor érhet˝o el. A BPEL jelent˝os szoftvermérnöki tudást igényel. Matematikailag a π-kalkulusra épül; a szinkron és aszinkron webszolgáltatás kommunikációra fókuszál. A szöveges dokumentuma egy magas szint˝u programozási nyelv XML nyelv˝u leírása; változók, hozzárendelések, elágazások, ciklusok jól azonosíthatóak. Mindemellett a BPEL minden eszközt biztosít a tevékenységek párhuzamos végrehajtására, tranzakció- és kivételkezelésre, valamint kompenzációra. Az adatok XML, 3
XSD vagy XPath formában rögzíthet˝oek. A BPEL maga nem rendelkezik grafikus megjelenít˝ovel, ugyanakkor a legtöbb szoftvereszköz lehet˝ové teszi az XML állomány grafikus fejlesztését a saját felületén keresztül. Az üzleti modellezés néz˝opontjából tekintve a BPEL folyamat egy automatizált vagy a szervezet egy tagja által nyújtott szolgáltatás. A szervezet humán és technológiai er˝oforrásai csak a legmagasabb szolgáltatási szinten érhet˝oek el. BPEL kétféle folyamatdefiníciót tesz lehet˝ové: van absztrakt és végrehajtható folyamatok írhatók le. Az el˝obbi a folyamatok koreográfiájának kialakítását biztosítja, míg az utóbbi az egyetlen folyamat általi összhangolást biztosítja. Az absztrakt folyamatok lényegében sosem használtak, eközben az összhangolt folyamatokat szinte azonnal webszolgáltatásként telepíthet˝ok és végrehajthatók. A BPEL folyamat szintaktikailag alaptevékenységekb˝ol, valamint vezérlési szerkezetekb˝ol és blokkokból állnak össze. Az alaptevékenységek a webszolgáltatás-hívások, a hívásfogadás és -válaszolás, bejöv˝o hívások más webszolgáltatásoktól, változóhozzárendelés, id˝otúllépési események, hibaesemény létrehozása, kompenzáció, eseménygenerálás, várakozás, valamint a befejez˝odés. Ezen alaptevékenységek blokkokba szervezhet˝oek. Minden blokk rendelkezik bels˝o változókkal a bejöv˝o és kimen˝o üzenetek paramétereinek tárolására, a számításokra, hibakezelésre és -elkapásra, eseménykezelésre a bejöv˝o hívások fogadására, valamint kompenzáció leírókra a kompenzációk kezelésére. Az alapértelmezett feldolgozási mód a tevékenységeket illet˝oen a soros lefutás, amelyet párhuzamosra lehet változtatni. Van lehet˝oség ciklusokat és elágazó vezérlési szerkezeteket létrehozni a bérkez˝o üzenett˝ol vagy valamely változó értékét˝ol függ˝oen.
2.3. Unified Modeling Language A szabványos UML ábrák a szoftvertervez˝o mérnököket célozzák meg, és csak meglehet˝osen korlátozott mérték˝u támogatása van az üzleti folyamatok modellezésére a BPMN és a BPEL nyelvekhez képest. A tevékenységábrák használhatóak üzleti folyamatok komplex munkafolyamatminták nélküli összhangolására. A tevékenységábrák az állapotgépek absztrakciójára épül, így rendelkezik folyamatábra reprezentációval. Tevékenységekb˝ol áll, amelyek további tevékenységeket szólíthatnak meg, rendelkeznek bemeneti és kimeneti eseményekkel, döntésekkel, objektum asszociációkkal és tevékenységi sávokkal (swimlanes). A vezérlési és az adatfolyam szétválik egymástól, a vezérlési folyamatok határozzák meg a végrehajtási kényszereket, az adatfolyamok pedig a tevékenység bemeneti és kimeneti adatformátumát. Bebizonyították [6], hogy munkafolyamat-mintákat le lehet írni tevékenységábrák segítségével. Ugyanakkor az UML 2 tevékenységábráit kritikával is illették [7] amiért is nem lehet a szinkronizációt megfelel˝oen leírni az egyes tevékenységre vonatkozóan, és emiatt kevésbé jól alkalmazható üzleti folyamatok modellezésére. 4
A tevékenységábrák mellett további ábrák is alkalmasak üzleti folyamatok modellezésére. Emberi er˝oforrások az használati eset (use case) ábrákkal és objektumdiagramokkal is leírhatóak úgy, hogy az egyes használati esetek a feladathozzárendelést, míg az objektumdiagram a személyzet, azok szerepeinek és a szervezeten belüli felel˝osségeinek leírását teszi lehet˝ové. A technikai infrastruktúra pedig telepítési ábrákkal jellemezhet˝o.
2.4. Yet Another Workflow Language A munkafolyamat-minták definíciója a szerz˝oket (Wil van der Aalst and Arthur ter Hofstede) egy új modellez˝o nyelv megalkotására sarkallta: YAWL (Yet Another Modeling Language) [8]. A YAWL nem kereskedelmi termék, nyílt forrású és nyílt forrású szoftver eszközök állnak rendelkezésre üzleti folyamatok modelljeinek szerkesztésére és végrehajtására. A YAWL Editor támogatja a manuális feladatok és a rendszerfeladatok definícióját, valamint a humán és nem humán er˝oforrások reprezentációját. Az üzleti adatok XSD, XPath és XQuery segítségével adhatók meg akárcsak BPEL-ben. A YAWL Engine egy üzletifolyamatmenedzsment-rendszer, amely alkalmas a YAWL-ban megadott üzleti folyamatok végrehajtására. A nyelv maga formálisan a Petri-hálók absztrakcióból származik, rendelkezik grafikus reprezentációval, és épít mindazon tapasztalatokra, amiket a szerz˝ok a munkafolyamat-minták összegy˝ujtése során szert tettek [9]. A Petri-háló szemantikát a vezérlési folyam mintáinak széles köre egészíti ki. A formális szemantika lehet˝ové teszi az e nyelven megadott üzleti folyamatok modelljeinek matematikai validációját és analízisét.
2.5. Business Process Modeling Language A BPML (Business Process Modeling Language) [10] egy a BPMI.org (the Business Process Management Initiative) által 2002-ben szabványosított historikus nyelv, aminek a fejlesztése a küls˝o támogatottság hiányában leállt. A BPML formális modellen alapult, és mind absztakt, mind futtatható folyamatok modellezésére alkalmas volt. Egyik nagy el˝onye az üzleti környezetben lév˝o kiegészít˝o entitások modellezésének támogatása. Emellett lehetséges benne a processzek hierarchikus definícióvá való dekompozíciója, támogatja a tranzakciók, kompenzációk, kivételkezelés modellezését, valamint az adatmenedzsmentet, és párhuzamos folyamatok modellezésére is alkalmas.
5
2.6. Business Process Definition Metamodel A BPDM [11] minden üzleti modellez˝o nyelvre érvényes egységes követelményrendszert és metamodellt definiál. Az alapötlet mögötte az, hogy amennyiben minden e-business modellez˝o nyelv követi az e szabvány által definiált szemantikát, a különböz˝o szállítók által készített szoftver eszközök közötti együttm˝uködés egyszer˝ubben biztosítható. Akárcsak a BPMN-t, ezt is OMG szabványosította, így els˝osorban a BPMN szemantikájára épül, azonban a processzek végrehajtási szemantikájának definíciójába a BPEL alapelveit is belevették. A szabvány maga UML osztálydiagramokat definiál, amelyeket csomagokba rendeztek a folyamat (Activity Model), a koregoráfia (Interaction Protocol Model) és e kett˝o közös viselkedési elemek szerint. A végrehajtás, a végrehajtási szabályok és a teljesítménymodell a közös infrastruktúra csomagban (Common Infrastructure) található. A nyelvek közötti átjárhatóság hatékonyabbá tételére a BPDM egységes XML alapú szerializációs formátumot javasol, ami alternatívául szolgálhat az XPDL helyett
2.7. XLANG Az XLANG [12] a Microsoft által 2001-ben bemutatott XML alapú processzleíró nyelv, a BPEL egyik el˝ofutára. Ez egy kiterjesztése a WSDL (Web Services Description Language) dokumentumnak, így a processz specifikációja a magába az interfészleíróba kerül. Az XLANG processzmodellek a π-kalkulus absztakcióra épülnek, és két nézetük van. Egyrészt lehetséges benne processzviselkedés tervezése a WSDL m˝uveletek (operation) aktiválásának id˝obeli rendezésére vonatkozó kényszerek megadásával. Másrészr˝ol processzkoreográfia specifikációja is lehetséget a megfigyelend˝o üzenetek sorrendjének megadásával.
2.8. Web Services Flow Language A WSFL [13] szintén egy XML alapú processzleíró nyelv, amit 2001-ben fejlesztett ki az IBM, azonban ipari támogatottság híján a BPEL szabványosítási folyamatának elindultával felhagyott a további fejlesztésével és támogatásával. A nyelv kétféle processzmodellt definícióját teszi lehet˝ové: egy folyam alapú modellt, amivel egy webszolgáltatás m˝uködése tervezhet˝o, és egy globális modellt, amivel az üzenetváltások írhatók le, vagyis a szerepl˝ok közötti koreográfia.
2.9. XML Process Definition Language Az XPDL [14] a Workflow Management Coalition (WfMC) által kidolgozott szabvány, az üzleti folyamat modellek modellez˝o szoftverek közötti hordozható6
ságának biztosítását célozza meg azáltal, hogy egy XML alapú szöveges szerializációs formátumot specifikál. Azon modellez˝o nyelvek számára, amelyek kizálólag grafikus ábrázolással rendelkeznek, ez a nyelv egy tárolási formátumot is biztosít egyben, számos kereskedelmi forgalomban kaptható üzleti folyamat modellez˝o eszköz használja a BPMN 1.1 szerializációs formátumaként. Mivel a BPMN 2.0 már önálló XML sémával rendelkezik, ez a nyelv hamarosan kiveszhet a gyakorlatból. Bár a BPEL saját szöveges leírással rendelkezik, amit nem szükséges más formátumra átalakítani, lehetséges a BPEL folyamatok absztakt részének XPDL formátumú tárolása.
3. Kollaborációleíró nyelvek áttekintése 3.1. UML Az UN/EIDFACT egy a 2000-es évek elején az ENSZ Centre of Trade Facilitation and E-business munkacsoportja által kidolgozott szabvány adminisztratív, kereskedelmi és szállítási területen való együttm˝uködésre. A szabvány a legfontosabb m˝uveleteket, üzenetformátumokat definiálja, és útmutatást az az üzenetek tervezésére. Ugyanez a munkacsoport kidolgozott egy UML 1.4-es verzión alapuló modellez˝o módszertant, az UMM-et (UN/CEFACT’s Modeling Methodology) [15], ami szervezetek közötti üzleti koreográfiák szolgáltatásorientált környezetben való megvalósítására nyújt egy keretrendszert. A keretrendszer három nézetb˝ol áll. A Business Domain View egy specializált használati eset diagram, ami az üzleti területtel kapcsolatos információkat gy˝ujt össze: kik a szerepl˝ok, mik a folyamatok. A Business Requirements View részleteiben írja le a folyamatokat a tevékenységek rendezésével egy aktivitás diagramon megadva az üzleti entitások életciklusát egy állapotgéppel, és egy használati eset diagramon definiálja az üzleti kollaborációkat. A Business Transaction View az információcserék koreográfiáját definiálja egy aktivitás diagramon, az üzleti adatokat osztálydiagramokkal adják meg.
3.2. Web Service Choreography Interface A Web Services Choreography (WS-Choreography) [16] a W3C korábbi szabványa a szolgáltatásorientált architektúrán megvalósított kollaborációs protokollok leírására. A WSCI a szolgáltatás megfigyelt viselkedésének leírását helyezi a középpontba megadva az üzenetváltások id˝obeli rendezését és logikai függ˝oségeit.
7
3.3. Web Services Choreography Description Language A Web Services Choreography Description Language (WS-CDL) [17] a W3C XML alapú koreográfialeíró nyelve, amivel e-business szolgáltatások közötti peerto-peer együttm˝uködés megfigyelhet˝o viselkedése írható le. Az együttm˝uködés modelljében a szerepl˝oket szerepkör vagy résztvev˝o szerint osztályozzák, a közöttük lév˝o kapcsolatot egy csatorna típus valósítja meg. A koreográfia az ezen szolgáltatások közötti együttm˝uködési protokoll, ami üzleti információcseréket reprezentáló tevékenységekb˝ol, munkaszakaszokból, illetve mérföldkövekb˝ol áll, amelyek rendezése lehet soros, párhuzamos vagy feltételes.
3.4. ebXML Az OASIS által kidolgozott ebXML (Electronic Business using eXtensible Markup Language) XML alapú specifikációsorozat [18] üzleti kollaborációk végrehajtását modellezi és teszi lehet˝ové. A szabvány egyik célja, hogy bármely két üzleti partner, aki saját a technológiai infrastruktúráját emXML konform módon alakítja ki, képes közös üzleti célt realizálni egy ebXML koreográfiával. A másik cél az absztakt üzleti folyamatok végrehajthatóvá tétele, amit a Business Service Interface Configuration szabvány alkalmazása tesz lehet˝ové. Az ebXML kiegészíti mind a BPMN-t, mind a BPEL-t. A BPMN ugyan lehet˝ové teszi koreográfiák definícióját, azonban azok kollaboratív végrehajtására már nem terjed ki, a BPEL folyamatok végrehajthatósága egyetlen szervezetre korlátozódik, nem vehetik igénybe más szervezetek er˝oforrásait. Az ebXML szabvány szerint minden egyes üzleti partner egy vagy több üzleti szerepet tölt be egy kollaborációban. A kollaboráció üzleti tranzakciókon keresztül zajlik le, ami nem jelent mást, mint az ebXML szabványnak megfelel˝o üzleti dokumentumok átvitelét. A koreográfia, ami bármilyen nyelven megadható, akár BPMN-ben is, az üzleti tranzakciók sorrendjét definiálja. A szabvány különös figyelmet fordít a partnerek közötti kommunikáció állapotának konzisztens mego˝ rzésére, hat alkalmazható tranzakciómintát definiát, amelyek után egyértelm˝uen eldönthet˝o minden résztvev˝o számára, hogy az üzenetátvitel sikeres volt-e. Ha egy kollaborációban kett˝onél több szerepl˝o vesz rész, akkor az dekomponálható bilaterális együttm˝uködések sorozatára.
3.5. Web Services Modeling Language A szolgáltatásorientált architektúrában a webszolgáltatások meghatározó szereppel rendelkeznek. Mindazonáltal a megfelel˝o üzleti partnerek menetközbeni automatikus felderítése így sem egyszer˝u feladat. Az ESSI WSMO munkacsoport európai kutatócsapatok munkáját hangolja össze szemantikus webszolgáltatások 8
területén. A szemantikus webszolgáltatások a szemantikus web alapelvét használják ki: egyszer˝ubben kereshet˝ok, publikálhatók és integrálhatók. A WSML [19] e csoport egy specifikációja, ami webszolgáltatásokat és szolgáltatásmodellez˝o ontológiákat definiál.
3.6. HL7 A HL7 egy egészségügyi információs rendszerek szabványosítása céljából 1987-ben alapított szervezet, ami kiadott egy HL7 Reference Implementation Model nev˝u szabványt az egészségügyi adatok UML-ben való modellezhet˝oségér˝ol [3].
3.7. RosettaNet A RosettaNet [2] jelenleg talán legszélesebb körben használt üzleti kollaborációs szabvány. F˝o célja eredetileg és f˝o alkalmazási jelenleg is az elektronikai eszközök gyárói beszállítói láncával kapcsolatos együttm˝uködések formalizálása. A szabvány Partner Interface Process (PIP) gy˝ujt˝onéven üzenetváltás-mintákat definiál megadva az XML formátumú üzenetsablonokat is. Mindemellett a RosettaNet szabványos együttm˝uködésre képes ebXML-t és webszolgáltatásokat használó üzleti partnerekkel is. A szabványok nem tartalmaznak modelleket, azonban az üzenetformátumok elérhet˝oek lesznek UML-ben is.
4. Az e-business modellez˝o nyelvek fejl˝odési trendjei Az e-business modellez˝o nyelvek jöv˝obeli fejl˝odését továbbra is az üzleti követelmények változása fogja vezérelni, és a legnagyobb szállítók által alkotott szabványosítási szervezetek fogják kivitelezni. Mindazonáltal az akadémiai szféra szerepet játszhat új modellezési aspektusok és potenciális követelmények azonosításában, és hatással lehet a szoftver eszközök fejlesztésére a modellvalidáció és a szimuláció elméleti hátterének kidolgozgásával. A modellez˝o nyelvekhez kapcsolódó tudományos munkák több nagy témakört ölelnek fel. Ilyen például • a nyelvek elemzése és összehasonlító értékelése, • a nyelvek szemantikájának finomítása és kiterjesztése,
9
• a nyelvek közötti szemantikus különbségek áthidalása és transzformáció megvalósítása a modellek hordozhatóságának, migrálhatóságának javítása végett, valamint • a különböz˝o nyelvekkel kifejezett formális modell verifikációja és validációja. Ez utóbbi a formális módszerek világába vezet, ami túlmutat a dokumentum céljain, keretein. A továbbiakban az els˝o három terület aktuális kutatási eredményei kerülnek áttekintésre.
4.1. Szükség van-e a modellez˝o nyelvek fejlesztésére? A címben feltett kérdés, bármennyire is fájdalmas az akadémiai szférának, jogos. A mindennapi ipari gyakorlat szerint jelenleg, mégha használnak is egy modellez˝o szoftver eszközt, annak eszköztárának dönt˝o többsége homályban marad. Ezt illusztálja cikkükben zur Muehlen és Recker [20], akik a BPMN tekintetében vizsgálják meg az elméleti és gyakorlati felhasználást. A BPMN modellelemek széles eszköztárával rendelkezik, azonban a gyakorlatban elkészített valódi BPMN modellek elemzéséb˝ol megállapítható, hogy az iparban modellezéssel foglalkozó szakemberek ódzodnak az összetett modellezési struktúrák használatától, és kizárólag nagyon magas szint˝u modelleket definiálnak. Ezért felteszik a kérdést, hogy szükség van-e újabb és újabb kiterjesztésekre. Ezzel a megfontolással teljesen összhangban van Mendling és társainak modellez˝o nyelvek elemeinek gyakorlati alkalmazására vonatkozó tapasztalati útmutatója [21]. Az egyik következtetésük az, hogy a processzmodellt tanácsos egyszer˝unek, kevés modellelemet tartalmazónak megtartani, és a komplexitást inkább több dekompozíciós szinten megvalósítani.
4.2. A nyelvek elemzése, értékelése, összehasonlítása Az e-business modellez˝o nyelvek elemzésének azon alkalmazási területek, példák azonosításával járul hozzá a fejl˝odéshez, ahol azok hatékonyan alkalmazhatók, illetve ahol nem rendelkeznek megfelel˝o kifejez˝o er˝ovel. Az akadémiai szféra a formális modellek meghatározása mellett az üzleti folyamat modellez˝o nyelvek fejl˝odését a munkafolyamatok és az üzenetváltási minták bevezetésével is támogatta, amelyet a valós életben m˝uköd˝o üzleti helyzetek absztrakt matematikai leírásával valósított meg[22, 23, 24]. A formális modellezés eszközei jellemz˝oen három végrehajtási kényszert biztosítanak – nevezetesen soros, párhuzamos és alternatív végrehajtást –, amelyr˝ol bebizonyították, hogy nem elégséges önmagában az összes vezérlési folyam, adatfolyam, er˝oforrás-hozzáférés és kivételkezelési viselkedés leírására [9]. A [9] ezen 10
felül további, jelent˝os mennyiség˝u viselkedési mintát, illetve kényszerhalmazt határoz meg, amely lehet˝ové teszi a különféle modellez˝o nyelvek kifejez˝o erejének összehasonlítását. A különböz˝o e-business modellez˝o nyelvekkel kapcsolatban Mili és társai [25] adnak részletekbe men˝o összehasonlítást. A nyelvek csoportosíthatók aszerint, hogy mi az alkalmazásuk üzleti célja: • az üzleti folyamat emberi megértést támogató leírása, • az üzleti folyamat optimalizálását lehet˝ové tev˝o elemzés, vagy • az üzleti folyamat adott szervezeti és technológiai infrastruktúrával támogatott végrehajtása. Mivel ezek maguk az üzleti folyamatok összetettek, ezért ezek a nyelvek több nézetet is definiálnak az egyes részletek ábrázolására. Ilyen a processzmodell elemei közötti függ˝oségeket leíró funkcionális nézet, a vezérlési információkat definiáló dinamikus nézet, az adatáramlást, illetve -manipulációt magadó információs nézet, és a végrehajtó szerepl˝ot a folyamathoz rendel˝o szervezeti nézet. A 1 ezen aspektusok alapján hasonlítja össze a bemutatott nyelveket.
11
12
Nyelv BPMN BPEL UML YAWL BPML BPDM XLANG WSFL XPDL WSCI WS-CDL ebXML RosettaNet HL7
Leírás igen igen igen igen igen igen igen igen igen igen igen igen igen
Elemzés Végrehajtás igen a jöv˝oben igen igen igen igen igen igen igen igen igen igen igen igen igen igen igen igen igen igen igen igen
Funkcionális Dinamikus Információs Szervezeti igen igen XML igen igen igen igen igen XML igen igen igen igen igen igen igen igen igen XML igen XML igen XML igen igen igen igen igen igen
1. táblázat. Nyelvek csoportosítása a folyamatok alkalmazási területe és nézetei szerint [25]
4.3. A nyelvek és modellek kiterjesztése A BPMN 2-es verziója nagy számú modellelemet kínál a viselkedés leírására, azonban a nemfunkcionális követelmények kifejezésére nagyon sz˝uk eszköztárral rendelkezik. Ez a jelenleg egyik legintenzívebben kutatott terület. Movakova és társai [26] és Bruckner és társai [27] BPMN adatobjektumokhoz javasoltak annotációs kiegészítést, ami lehet˝ové teszi a biztonsági követelmények kifejezését. A nemfunkcionális követelmények másik nagy csoportját a teljesítménykövetelmények jelentik. Pavlovski és Zhou [28], valamint Bocciarelli és D’Ambrogio [29] vizuális komponens bevezetését javasolta e célból. Milanovic és társai [30] egy új, üzleti szabályokon alapuló átjárótípus bevezetését javasolják, ami szerintük jobb megfelelést biztosítana a munkafolyamattervezési mintákhoz. A szoftvertechnológia egyik felkaptt ága napjainkban a követelményelemzés, és az aspektusorientált modellezés. Amikor a magas szint˝u üzleti célokból funkcionális dekompozícióval alacsonyabb absztakciós szinten található üzleti tevékenységet származtatnak, mindig maradnak olyan elemei a modellnek, amelyek a modellben szétszórva jelennek meg. A szofvertechnológiában ezeket átmetsz˝o követelményeknek nevezik, és a jobb karbantarthatóságot biztosító modularizálásukra aspektusorientált módszereket dolgoztak ki. Ennek az elvnek az átültetését javasolják Charfi és társai [31], valamint Nogueira és társai [32] szoftver eszközös megoldást kínálva.
4.4. Modellek transzformációja A modelltranszformációval foglalkozó irodalom a különböz˝o e-business modellez˝o technikák közötti szemanitiku rés áthidalhatóságát elemzik. A modellek közötti átjárhatóság biztosítására az els˝o lépés a közös szerializációs formátum, amit az XPDL biztosíthat, azonban mivel az messze nem teljes kör˝u, további megoldások szükségesek. A BPMN és a BPEL közötti transzformációra már a BPDM szabvány [4] is ad megoldást: a BPMN folyamatsávjait BPEL folyamatokra képezi le. A szabvány megjegyezi, hogy nem minen BPMN elem rendelkezik magától értet˝od˝o BPEL megfelel˝ovel, továbbá míg a BPEL folyamatnak helyesnek, holtpontmentesnek és megfelel˝oen szinkronizáltnak kell lennie a végrehajthatóság érdekében, ugyanez egy BPMN modellel szemben nem követelmény. Ouyang és társai [33] ennél tovább mentek, cikkükben azonosították a két nyelv megfeleltethet˝o szintaktikai elemeit, és bemutatták a BPMN-r˝ol BPEL-re fordítást megvalósító nyílt forráskódú BPMN2BPEL nev˝u szoftverüket. A BPMN új szabványában bemutatott változások közelebb viszik az abban megadott modelleket a BPEL-szer˝u végrehajthatósághoz. A BPMN modellek vég13
rehajtására Antosz és társai [34] mutatnak be megoldást. Weiss [35] munkjában a BPMN és az UML közötti átjárást vizsgálja meg az információs infrastruktúra és a szolgáltatások hatékonyabb modellezése végett. Leképezések nem csak folyamatmodellez˝o nyelvek között léteznek, hanem koreográfiamodellek között is definiálhatók. Hofreiter [36] ebXML és UML között javasol egy ilyen megfeleltetést.
5. Összefoglalás Ez a dokumentum a jelenleg és a közelmúltban használt e-business modellez˝o nyelveket tekintette át megvizsgálva azok potenciális alkalmazási területeit legyen szó leírásról, elemzésr˝o vagy végrehajtásról, a nyelvek célközönségét és korlátait. A kutatók és az iparban dolgozó szakemberek célkesztjében jelenleg két nyelv áll, a BPMN és a BPEL, ezek továbbfejlesztésén, tökéletesítésén fáradoznak. A BPMN hosszú távon az általános célú üzleti folyamat modellez˝o nyelvvé válhat, azonban addig nagyon hosszú az út. Noha a nyelv már így is modellelemek b˝oséges eszköztátával rendelkezik, a folyamat- és kollaborációmodellezés teljes egészét nem képes jelenleg úgy lefedni, mint az UML a szoftvertechnológiai modellezést. A modellek végrehajtása doménspecifikus technológiákkal vagy szolgáltatásorientált architektúrában a kiváló technológiai támogatással rendelkez˝o BPELlel történik, amely így a végrehajtható modellek megjelenéséig domináns marad.
Hivatkozások [1] Kovács G. E-business modellez˝o nyelvek. Technical report, Budapesti M˝uszaki és Gazdaságtudományi Egyetem, November 2012. [2] RosettaNet. RosettaNet. http://www.rosettanet.org/ TheStandards/tabid/287/Default.aspx, 2012. [3] HL7. HL7 reference information mode. http://archive. hl7.org/v3ballotarchive/v3ballot2008may/html/ infrastructure/rim/rim.htm, December 17 2003. [4] OMG. Business Process Model and Notation (BPMN) Version 2.0. http: //www.omg.org/spec/BPMN/2.0/, January 3 2011. [5] OASIS. Web Services Business Process Execution Language Version 2.0. http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0. html, April 1 2007. 14
[6] Foerster A. Engels G. Schattkowsky T. Activity Diagram Patterns for Modeling Quality Constraints in Business Processes. In L. B. Williams, editor, MoDELS 200, volume LNCS 3713, pages 2–16, Jamaica, 2005. Springer. [7] Schattkowsky T. Förster A. On the Pitfalls of UML 2 Activity Modeling. In International Workshop on Modeling in Software Engineering (MISE’07), page 8, Minneapolis, 2007. IEEE CS. [8] YAWL Foundation. YAWL Manuals. http://www. yawlfoundation.org/pages/support/manuals.html, April 1 2012. [9] Workflow Patterns Initiative. Patterns. http://www. workflowpatterns.com/patterns/, January 1 2010. [10] Business Process Management Initiative. Business Process Modeling Language, 2002. [11] OMG. Business Process Definition Metamodel. http://www.omg. org/spec/BPDM/, November 3 2008. [12] Microsoft Corporation. XLANG. http://xml.coverpages.org/ XLANG-C-200106.html, January 1 2001. [13] IBM. WSFL in action. http://www.ibm.com/developerworks/ webservices/library/ws-wsfl1/, January 1 2002. [14] Workflow Management Coalition. XPDL Support and Resources. http: //www.wfmc.org/xpdl.html, October 10 2008. [15] UN/CEFACT. UMM Meta Model – Foundation Module, 2006. [16] World Wide Web Consortium. Web Service Choreography Interface (WSCI) 1.0. http://www.w3.org/TR/wsci/, August 8 2002. [17] World Wide Web Consortium. Web Services Choreography Description Language. http://www.w3.org/TR/ws-cdl-10/, November 9 2005. [18] OASIS. ebXML Business Process Specification Schema Technical Specification. http://www.oasis-open.org/standards, December 21 2006. [19] WSMO. WSML Language Reference. http://www.wsmo.org/TR/ d16/d16.1/v1.0/, August 8 2008. 15
[20] zur Muehlen M. Recker J. How Much Language Is Enough? Theoretical and Practical Use of the Business Process Modeling Notation. In Z. B. Léonard, editor, 20th Conference on Advanced Information Systems Engineering, volume LNCS 5074, page 465–479, Montpellier, 2008. Springer. [21] Mendling J. Reijers H. van der Aalst W. Seven process modeling guidelines (7PMG). Information and Software Technology, 52:127–136, 2010. [22] van der Aalst W. M. Patterns and XPDL: A Critical Evaluation of the XML Process Definition Language. Technical report, Eindhoven University of Technology, Eindhoven, 2003. [23] van der Aalst W. ter Hofstede A. Kiepuszewski B. Barros A. Workflow Patterns. Distributed and Parallel Databases, 14(1):5–51, 2003. [24] Weske M. Business Process Management. Springer, Berlin Heidelberg, 2007. [25] Mili H. Tremblay G. Bou Jaoude G. Lefebvre E. Elabed L. El Boussaidi G. Business Process Modeling Languages: Sorting Through the Alphabet Soup. Computing Surveys, 43(1):4, 2010. [26] Monakova G. Brucker A. Schaad A. Security and Safety of Assets in Business Processes. In 27th Annual ACM Symposium on Applied Computing, pages 1667–1673, Riva del Garda, 2012. ACM. [27] Brucker A. Hang I. Luckemeyer G. Ruparel R. SecureBPMN: Modeling and Enforcing Access Control Requirements in Business Processes. In 7th ACM Symposium on Access Control Models And Technologies, pages 123–125, Newark, 2012. ACM. [28] Pavlovski C. J. Zou J. Non-Functional Requirements in Business Process Modeling. In 5th Asia-Pacific Conference on Conceptual Modelling (APCCM 2008), pages 103–112, Wollongong, 2008. Australian Computer Society. [29] Bocciarelli P. D’Ambrogio A. A BPMN Extension for Modeling Non Functional Properties of Business Processes. pages 160–168, San Diego, 2011. Society for Computer Simulation International. [30] Milanovi´c M. Gaševi´c D. Wagner G. Devedži´c V. Modeling Service Orchestrations with a Rule-enhanced Business Process Language. In Conference of the Center for Advanced Studies on Collaborative Research, pages 70–85, Toronto, 2009. IBM. 16
[31] Charfi A. Müller H. Mezini M. Aspect-Oriented Business Process Modeling with AO4BPMN. In 6th European Conference Modelling Foundations and Applications, volume LNCS 6138, pages 48–61, Paris, 2010. Springer. [32] Nogueira Santos F. J. Cappelli C. Santoro F. M. Leite J. C. Batista T. V. Using Goals to Identify Aspects in Business Process Models. In International workshop on Early Aspects, pages 19–23, Porto de Galinhas, 2011. ACM. [33] Ouyang C. Dumas M. van der Aalst W. ter Hofstede A. Mendling J. From Business Process Models to Process-Oriented Software Systems. Transactions on Software Engineering and Methodology, 19(1), 2009. ´ [34] Antosz K. Swirad S. Nie´c D. Osi´nski P. Zapart K. Safena and QBPM – a proposition for modeling and enacting processes in Supply Chain Network. In Research in Applied Computation Symposium (RACS 2011), pages 209– 215, Miami, 2011. ACM. [35] Weiss P. Service-Based Realization of Business Processes Driven by Control-Flow Patterns. In Central and East European Conference on Software Engineering Techniques, volume LNCS 4980, pages 91–102, Brno, 2008. Springer. [36] Hofreiter B. Registering UML Models for Global and Local Choreographies. In 10th International Conference on Electronic Commerce (ICEC), page 37, Innsbruck, 2008. ACM.
17
