E-business modellező nyelvek összehasonlítása és fejlődési trendjei

E-business modellező nyelvek összehasonlítása és fejlődési trendjei Kovács Gábor 2012. november-december Kivonat E dokumentum célja a e-business modellező nyelveket áttekintő 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ődési trendjeinek áttekintésével. Az előző dokumentumban bemutatott négy modellező 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ő Az utóbbi évtized során az e-business modellezés és a modellező nyelvek nagy fejlődésen mentek keresztül. Nyelvek tucatjait vezették be, amelyek közül számos megfelelő 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ő nyelv rendelkezik ipari és technológiai támogatással: a BPMN és a BPEL azonban ezek fejlődésére hatással lehet a többi jelenleg is létező és az esetleg már a gyakorlatból kiveszett nyelvek. A modellező nyelveket jellemzően 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ődésének mozgatórugói kettősek, 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ől megvizsgálja a nyelveket. Bemutatja a nyelvek matematikai hátterét, kifejező 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ő 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ődések modellezése, valamint a szervezeti és a technológiai infrastruktúra modellezése. 2. Folyamatmodellező 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ői felülettel és egy XML alapú szövegreprezentációval is. A nagy modellező 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ődlegesen modellezési célzattal került kialakításra. Habár a 2. változat már a végrehajtást helyezi előté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ődlegesen inkább üzleti elemzők és folyamattervezők, mintsem szoftvertervezők és -mérnökök. Matematikai értelemben a BPMN egy Petri-háló alapú megoldás, ennek megfelelően alkalmas arra, hogy egy folyamatmodell helyességét ellenő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űkődésének leírását is. Az együttműködésnek két különböző 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ől, van lehetőség arra is, hogy egyetlen folyamat összhangolását írjuk le, amely nem feltétlenül tartalmazza a résztvevő 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őforrás, egy szervezeti hierarchiába illeszkedő szerep, vagy egy technológiai infrastruktúrában létező 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ő elemre mutat, vagy olyan vállalati erőforrásokat reprezentáló adatobjektumokkal vannak összekötve pontozott nyíllal, amelyek az erőforrásokra mutatnak. Üzenetváltás alapú együttműködést két folyamat között pedig a szaggatott nyíl jelez a küldőtől a fogadó fél 2

felé mutatva. A tevékenységek a modellezett vállalatban végrehajtásra kerülő üzleti tevékenységeket jelölnek. A tevékenység lehet egyszerű üzleti feladat vagy összetett folyamat, illetve egyidejűleg vagy ciklikusan is végrehajtható. A tevékenységeket lekerekített szélű 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ő eseményeket kettős határvonalú körrel, míg kimeneti eseményeket vastag vonalú körrel. Az esemény jelezheti egy üzenet elkapását, határidőt, egy üzleti szabály alkalmazását, hibát, egy hiba kompenzációját, valamint ezek tetszőleges 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űbb 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őre meghatározott feltételek mentén a feltételekre kizárólagosan illeszkedő, egyetlen kimeneti ágat aktivizál. Az esemény alapú XOR-kapu a következő 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ő végrehajtási ágat is aktiválhatnak, és több beérkező ág is aktiválhatja őket az egyesítésnél. Az összetett kapuk pedig lehetővé teszik tetszőleges 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 WS- BPEL2.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őrendszer hajtja végre, amelyek webszolgáltatásokra képződnek le a szolgáltatás alapú architektúrában. Mintegy tucat kereskedelmi és ingyenes BPEL motor érhető el. A BPEL jelentős 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ű programozási nyelv XML nyelvű 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őek. A BPEL maga nem rendelkezik grafikus megjelenítővel, ugyanakkor a legtöbb szoftvereszköz lehetővé teszi az XML állomány grafikus fejlesztését a saját felületén keresztül. Az üzleti modellezés nézőpontjá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őforrásai csak a legmagasabb szolgáltatási szinten érhetőek el. BPEL kétféle folyamatdefiníciót tesz lehetővé: van absztrakt és végrehajtható folyamatok írhatók le. Az előbbi 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ők és végrehajthatók. A BPEL folyamat szintaktikailag alaptevékenységekből, valamint vezérlési szerkezetekből é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ő hívások más webszolgáltatásoktól, változóhozzárendelés, időtúllépési események, hibaesemény létrehozása, kompenzáció, eseménygenerálás, várakozás, valamint a befejeződés. Ezen alaptevékenységek blokkokba szervezhetőek. Minden blokk rendelkezik belső változókkal a bejövő és kimenő üzenetek paramétereinek tárolására, a számításokra, hibakezelésre és -elkapásra, eseménykezelésre a bejövő 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ően a soros lefutás, amelyet párhuzamosra lehet változtatni. Van lehetőség ciklusokat és elágazó vezérlési szerkezeteket létrehozni a bérkező üzenettől vagy valamely változó értékétől függően. 2.3. Unified Modeling Language A szabványos UML ábrák a szoftvertervező mérnököket célozzák meg, és csak meglehetősen korlátozott mértékű 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ől á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ően 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őforrá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ősségeinek leírását teszi lehetővé. A technikai infrastruktúra pedig telepítési ábrákkal jellemezhető. 2.4. Yet Another Workflow Language A munkafolyamat-minták definíciója a szerzőket (Wil van der Aalst and Arthur ter Hofstede) egy új modellező 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őforrá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ők a munkafolyamat-minták összegyűjté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ővé 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ő 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őnye az üzleti környezetben lévő kiegészítő 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ő 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ő nyelv követi az e szabvány által definiált szemantikát, a különböző szállítók által készített szoftver eszközök közötti együttműködés egyszerűbben biztosítható. Akárcsak a BPMN-t, ezt is OMG szabványosította, így elsősorban 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ő 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őfutá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űveletek (operation) aktiválásának időbeli rendezésére vonatkozó kényszerek megadásával. Másrészről processzkoreográfia specifikációja is lehetséget a megfigyelendő ü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ővé: egy folyam alapú modellt, amivel egy webszolgáltatás működése tervezhető, és egy globális modellt, amivel az üzenetváltások írhatók le, vagyis a szereplők 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ő 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ő 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ő 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űködésre. A szabvány a legfontosabb műveleteket, ü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ő 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ől áll. A Business Domain View egy specializált használati eset diagram, ami az üzleti területtel kapcsolatos információkat gyűjt össze: kik a szereplők, 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őbeli rendezését és logikai függősé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űködés megfigyelhető viselkedése írható le. Az együttműködés modelljében a szereplőket szerepkör vagy résztvevő szerint osztályozzák, a közöttük lévő kapcsolatot egy csatorna típus valósítja meg. A koreográfia az ezen szolgáltatások közötti együttműködési protokoll, ami üzleti információcseréket reprezentáló tevékenységekből, munkaszakaszokból, illetve mérföldkövekből á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ővé. 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ővé. Az ebxml kiegészíti mind a BPMN-t, mind a BPEL-t. A BPMN ugyan lehetővé 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őforrá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ő ü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 megőrzésére, hat alkalmazható tranzakciómintát definiát, amelyek után egyértelműen eldönthető minden résztvevő számára, hogy az üzenetátvitel sikeres volt-e. Ha egy kollaborációban kettőnél több szereplő vesz rész, akkor az dekomponálható bilaterális együttműkö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ő üzleti partnerek menetközbeni automatikus felderítése így sem egyszerű 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űbben kereshetők, publikálhatók és integrálhatók. A WSML [19] e csoport egy specifikációja, ami webszolgáltatásokat és szolgáltatásmodellező 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ű szabványt az egészségügyi adatok UML-ben való modellezhetőségéről [3]. 3.7. RosettaNet A RosettaNet [2] jelenleg talán legszélesebb körben használt üzleti kollaborációs szabvány. Fő célja eredetileg és fő alkalmazási jelenleg is az elektronikai eszközök gyárói beszállítói láncával kapcsolatos együttműködések formalizálása. A szabvány Partner Interface Process (PIP) gyűjtőnéven üzenetváltás-mintákat definiál megadva az XML formátumú üzenetsablonokat is. Mindemellett a RosettaNet szabványos együttműkö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őek lesznek UML-ben is. 4. Az e-business modellező nyelvek fejlődési trendjei Az e-business modellező nyelvek jövőbeli fejlődé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ő 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ő 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ő három terület aktuális kutatási eredményei kerülnek áttekintésre. 4.1. Szükség van-e a modellező 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ő szoftver eszközt, annak eszköztárának döntő 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ől 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ű 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ő nyelvek elemeinek gyakorlati alkalmazására vonatkozó tapasztalati útmutatója [21]. Az egyik következtetésük az, hogy a processzmodellt tanácsos egyszerűnek, 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ő nyelvek elemzésének azon alkalmazási területek, példák azonosításával járul hozzá a fejlődéshez, ahol azok hatékonyan alkalmazhatók, illetve ahol nem rendelkeznek megfelelő kifejező erővel. Az akadémiai szféra a formális modellek meghatározása mellett az üzleti folyamat modellező nyelvek fejlődését a munkafolyamatok és az üzenetváltási minták bevezetésével is támogatta, amelyet a valós életben működő üzleti helyzetek absztrakt matematikai leírásával valósított meg[22, 23, 24]. A formális modellezés eszközei jellemzően három végrehajtási kényszert biztosítanak nevezetesen soros, párhuzamos és alternatív végrehajtást, amelyről bebizonyították, hogy nem elégséges önmagában az összes vezérlési folyam, adatfolyam, erőforrá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ős mennyiségű viselkedési mintát, illetve kényszerhalmazt határoz meg, amely lehetővé teszi a különféle modellező nyelvek kifejező erejének összehasonlítását. A különböző e-business modellező nyelvekkel kapcsolatban Mili és társai [25] adnak részletekbe menő ö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ővé tevő 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ősé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őt a folyamathoz rendelő szervezeti nézet. A 1 ezen aspektusok alapján hasonlítja össze a bemutatott nyelveket. 11

12 Nyelv Leírás Elemzés Végrehajtás Funkcionális Dinamikus Információs Szervezeti BPMN igen igen a jövőben igen BPEL igen igen igen igen XML UML igen igen igen igen igen igen igen YAWL igen igen igen igen XML BPML igen igen igen igen igen BPDM igen igen igen igen igen XLANG igen igen igen igen WSFL igen igen igen igen XPDL igen igen igen XML WSCI igen igen igen XML WS-CDL igen igen igen XML ebxml igen igen igen igen igen igen RosettaNet igen igen igen igen igen HL7 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űk 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ővé 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ű ü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ő 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ő e-business modellező 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ő 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ű, 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ődő BPEL megfelelővel, továbbá míg a BPEL folyamatnak helyesnek, holtpontmentesnek és megfelelően 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ő szintaktikai elemeit, és bemutatták a BPMN-ről BPEL-re fordítást megvalósító nyílt forráskódú BPMN2BPEL nevű szoftverüket. A BPMN új szabványában bemutatott változások közelebb viszik az abban megadott modelleket a BPEL-szerű végrehajthatósághoz. A BPMN modellek vég- 13

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ő 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ő nyelveket tekintette át megvizsgálva azok potenciális alkalmazási területeit legyen szó leírásról, elemzésrő 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ő nyelvvé válhat, azonban addig nagyon hosszú az út. Noha a nyelv már így is modellelemek bősé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ő 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ő nyelvek. Technical report, Budapesti Műszaki é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ć M. Gašević D. Wagner G. Devedžić 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. Świrad S. Nieć D. Osiński 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