ЈЕДАН НОВИ ПРИСТУП У ПРЕВОЂЕЊУ ИЗ BPMN а У BPEL ONE NEW APPROACH IN TRANSLATING FROM BPMN TO BPEL Александар Недељковић Факултет организационих наука, Београд Садржај BPMN и BPEL су два највише коришћена стандарда у моделовању пословних процеса. Први је графички језик који се користи за анализу и моделовање пословних процеса. Други је рачунарски извршни језик који служи за извршавање пословних процеса. Проблем превођења из BPMN у BPEL je нарочито тежак. У овом раду дат је један нов алгоритам који преводи BPMN дијаграме пословног процеса у шаблон BPEL процесне дефиниције пословних процеса. Abstract BPMN and BPEL are the two most frequently used standard in the modeling business processes. The first is a graphical language that is used for the analysis and modeling of business processes. The second is a computed executable language that is used to execute business processes. The problem of translation from BPMN to BPEL is particularly difficult. In this paper, a new algorithm is given that translates BPMN business process diagram to template of BPEL process definition of business processes. 1. УВОД Предмет рада је проблем превођења са BPMN а на BPEL. Ово је добро познат проблем који се са променљивим успехом решава на многим универзитетима и институтима, као и у мултинационалним компанијама. Овај проблем припада дисциплини аутоматизације пословних процеса. Проблем превођења из BPMN а у BPEL има нарочиту тежину, јер се ради о превођењу са језика који су графовски орјентисани (BPMN), на блоковски орјентисан језик ( BPEL). Графовски орјентисани језици дефинишу контролни ток помоћу лукова који представљају логичку везу између чворова [3]. Чворова може бити више врста, зависно од језика. Блоковски орјентисани језици дефинишу контролни ток угнежђавањем команди и конструкта који се користе за представљање конкурентности, секвенце, петљи итд [3]. BPEL није чисто блоковски језик јер има контролне линкове, који су графовски концепт, али се може усвојити да је блоковски орјентисан унутар овог рада. Људи који користе BPMN су углавном менаџери, власници процеса, или људи који учествују у извршавању процеса. Ови људи имају велико знање о процесу, али по правилу врло мало знања о IT технологијама, које се користе за извршавање модела процеса. Са друге стране, људи који користе BPEL су програмери, који по правилу немају знање о процесу и како би исти требало да се моделује, а поседују знање о IT технологијама којима се омогућава извршавање модела. Ове две групе људи, као што је већ наведено, имају комплементарна знања, у чему се огледа још један аспект овог проблема. Решење овог проблема (што је и циљ рада) јесте да се дефинише процедура која за свој улаз има процесни дијаграм у BPMN у, док је излаз исте шаблон дефиниције процеса у BPEL у, за даљу манипулацију. При томе улаз може бити било који BPMN дијаграм. Излаз, тј. шаблон, са друге стране мора бити читљив, због даље манипулације и одржавања. Иако је овај рад фокусиран искључиво на BPMN и BPEL, резултати који су овде показани могу се применити на било који други пар стандарда (графовски и блоковски орјентисани) који се користе у BPM у, али и у неким другим научним дисциплинама. 2. ПРЕВОЂЕЊЕ ИЗ BPMN а у BPEL Постоји већ неколико алгоритама који се користе за превођење из BPMN а у BPEL. Ови алгоритми називају се алгоритам заснован на обрасцима, алгоритам заснован на контролним линковима, и алгоритам заснован на манипулаторима догађаја. Сваки од ових алгоритама детаљно је описан у литератури [4]. Због ограниченог простора, у овом раду се користе појмови дефинисани у литератури [4]. Ови појмови су основни дијаграм пословних процеса, добро формирани дијаграм пословног процеса, компонента дијаграма пословног процеса и добро структурирана компонента дијаграма пословног процеса. Циљ је да се, због читљивости резултујућег BPEL кода ове компоненте дијаграма пословног процеса преведу директно у структуриране конструкте BPEL кода. 606
На слици 2.1 приказане су добро структуриране компоненте, дефинисане у литератури [4]. У решењу који се предлаже, креће се од комплетног процесног дијаграма као целине. Ово решење претпоставља да процесни дијаграм садржи искључиво добро структуриране компоненте [4], осим REPEAT-WHILE компоненте. Такође се сматра да је дијаграм добро формиран [4], и да има по један почетни и један завршни догађај. Уколико су испуњени сви услови наведени у претходном пасусу, може се претпоставити да за сваки објекат x у процесном дијаграму постоји коначан број случаја. Овај број случаја се значајно смањује када су познати скупови претходних и следећих објеката објекта x који описују његову позицију у дијаграму. Стога је могуће генерисати скуп правила који одређују структуру процесног дијаграма, која се после преводи у BPEL користећи његове структуриране конструкте. Стога је нов алгоритам назван алгоритам заснован на скуповима претходних и следећих елемената. Код у BPEL у се генерише за сваки објекат x посебно, али када се прође комплетан процесни дијаграм, добија се валидни шаблон процесне дефиниције пословног процеса у BPEL у. e1 SEQUENCE компонента e 1 t n FLOW компонента b 2 e 1 default IF компонента t n У овом раду се сматра да објекат x припада скупу актовности, средњих догађаја и скретница. Почетни и завршни догађаји се не разматрају, али су укључени у правила која одређују структуру процесног дијаграма. На слици 2.2 дата су пресликавања различитих типова објекта x за различите типове његовог претходног и следећег елемента. На слици је са predi(x) означен један од претходних објеката објекта x, док је са succi(x) означен један од следећих објеката објекта x. e 1 t 2 e 2 t r t n PICK компонента У овом раду се за функцију Mapping(x) не сматра превођење само објекта x, него превођење које се генерише и на основу скупа претходних и следећих објеката објекта x. Када се у даљем тексту наведе да објекат може имати било који или произвољан тип, сматра се да може имати тип у који се налази у добро структурираним компонентама, када се из њих изузме REPEAT-WHILE компонента.. WHILE компонента ~ На основу свега наведеног, могу се написати правила о генерисању BPEL кода за следеће случајеве типова објекта x (узимајући у обзир типове његових претходних и следећих објеката): уколико x има тип активности или средњег догађаја, pred(x) има тип почетног догађаја, онда се генерише део кода као на слици 2.2а. Објекат succ(x) може имати било који тип; ~ REPEAT компонента ~b 1 t 2 REPEAT+WHILE компонента Слика 2.1 Добро структуриране компоненте 607
уколико x има тип активности или средњег догађаја, succ(x) има тип завршног догађаја, онда се генерише део кода као на слици 2.2б. Објекат pred(x) може имати било који тип; уколико x и succ(x) имају тип активности или средњег догађаја, а pred(x) нема тип активности или средњег догађаја, генерише се код као у првом случају на слици 2.2в, уколико x и pred(x) имају тип активности или средњег догађаја, а succ(x) нема тип активности или средњег догађаја, генерише се код као у другом случају на слици 2.2в, и уколико x, pred(x) и succ(x) имају тип активности или средњег догађаја, генерише се код као у последњем случају на слици 2.2в; уколико x има тип паралелне скретнице рачвања, генерише се код као на слици 2.2г. Објекти pred(x), succ1(x),, succn(x) могу имати било који тип; уколико x има тип паралелне скретнице спајања, генерише се код као на слици 2.2д. Објекти pred1(x),, predn(x) и succ(x) могу имати било који тип; рачвања, a succn(x) има тип ексклузивне скретнице спајања (да би се обезбедио подразумевани ток) генерише се код као на слици 2.2ђ. Објекти pred(x), succ1(x),, succn-1(x) могу имати било који тип; уколико x има тип ексклзивне скретнице спајања, a predn(x) има тип ексклузивне скретнице рачвања (исто као малопре, да би се обезбедио подразумевани ток), генерише се код као на слици 2.2е. Објекти pred1(x),, predn-1(x), и succ(x) могу имати било који тип, док; базиране на догађајима и succn(x) није ексклузивна скретница спајања, генерише се код као на слици 2.2ж. Са слике се види да генерисани код зависи од тога шта је на почетку гране која излази из скретнице (догађај или активност пријема поруке). Објекти pred(x), succ1(x),, succn-1(x) могу имати било који тип; спајања и predn(x) није ексклузивна скретница рачвања, генерише се код као на слици 2.2з. Објекти pred1(x),, predn-1(x) и succ(x) могу имати било који тип; 608
на слици 2.2к. Објекти pred1(x) и succ1(x) могу имати произвољан тип; рачвања (са дефинисаним подразумеваним током) и ако је pred2(x) ексклузивна скретница спајања, генерише се код као на слици 2.2л. Објекти pred1(x) и succ1(x) могу имати произвољан тип. Овај алгоритам је потребно поредити са већ постојећим решењима, како би се показао његов допринос у побољшању решавања проблема превођења из BPMN а у BPEL. Приликом дефинисања критеријума за поређење алгоритама за превођење из BPMN а у BPEL, потребно је установити какав би био идеалан алгоритам. Прво је потребно установити какав се резултат жели постићи овим алгоритмом. Слика 2.2 Пресликавање за различите случајеве елемента x у зависности од скупа претходних и следећих елемената спајања, и када је succ(x) ексклузивна скретница рачвања (са дефинисаним подразумеваним током), генерише се код као на слици 2.2и. Објекти pred1(x) и pred2(x) могу имати било који тип; рачвања (са дефинисаним под разумеваним током) и када је succ(x) ексклузивна скретница спајања, генерише се код као на слици 2.2ј. Објекти succ1(x) и succ2(x) могу имати произвољан тип; спајања и ако је pred2(x) ексклузивна скретница рачвања ( са дефинисаним подразумеваним током), генерише се код као Као што је већ речено, потребно је генерисати читљив BPEL код. Овај услов је потребан јер је овај код потребно одржавати. Даље, такође је потребно да улаз алгоритма може бити произвољан процесни дијаграм. Овај услов је потребан јер постоји небројен број различитих типова пословних процеса који се моделују. Могуће је изменити процесне дијаграме тако да садрже исту логику и редослед извршавања активности, и да истовремено упадну у скуп типова процесних дијаграма који могу да буду улаз за алгоритам. Међутим елегантније је решење проширити скуп типова процесних дијаграма који могу бити улаз за алгоритам. Трећи услов је да алгоритам буде једноставан за реализацију. Овај услов, поред јефтиније реализације (мања употреба времена и људских ресурса за имплементацију) омогућава и брже извршавање алгоритма. Значи, идеалан алгоритам даје читљив BPEL код, и може за улаз узети произвољан процесни дијаграм у BPMN у. Такође је пожељно да овај алгоритам буде што једноставнији. Из последње две реченице се могу издвојити три критеријума за поређење алгоритама из BPMN а у BPEL: читљивост и разумљивост резултујућег BPEL кода, величина скупа различитих типова улазних дијаграма, сложеност алгоритма. За сваки од наведених алгоритама дефинисани су следећи тежински фактори приказани у табели 1 Усвојено је правило да је збир сва три тежинска коефицијента једнак 1. 609
Табела 1 Тежински фактори за дефинисане критеријуме Критеријум Тежински фактор Читљивост и разумљивост резултујућег BPEL кода 0.5 Величина скупа различитих типова улазних дијаграма 0.2 Сложеност алгоритма 0.3 Први критеријум, читљивост и разумљивост резултујућег BPEL кода је и примарни, јер се овај код углавном користи за даљу манипулацију (функције Mapping(x) у горњем тексту) од стране софтверских инжењера. Стога је јако битно да је могуће разумети код. Зато се овом критеријуму додељује тежински фактор 0.5. Други критеријум је величина скупа различитих типова процесних дијаграма које алгоритам може да прими као улаз. Међутим, постоје елементи процесног дијаграма у BPMN у који се не могу изразити у BPEL у [5], тако да овај критеријум има мању тежину од првог 0.2. Последњи критеријум који се наводи је сложеност алгоритма, тј. могућности његове имплементације. Сложенији алгоритми се, по правилу теже имплементирају, па је стога пожељно да алгоритам буде што простији, у циљу имплементације. Стога је његова тежина тј. тежински фактор 0.2. У даљем тексту следи поређење алгоритама наведеног у овом раду и алгоритама наведених у литаратури [4] по овим критеријумима. По првом критеријуму прво место деле алгоритам заснован на обрасцима и алгоритам заснован на претходним и следећим елементима, јер користе структуриране BPEL конструкте у генерисању резултујућег кода. Овакав код је читљив, разумљив, и лако се одржава. Проналажење жељеног дела кода који треба да се промени, замени или исправи је једноставно. Други алгоритам по овом критеријуму је алгоритам заснован на контролним линковима. Као што му само име каже, заснован је на контролним линковима, тако да је јако тешко испратити све контролне линкове који се појављују у коду. Проналажење жељеног дела кода је зато сложено. И трећи је алгоритам заснован на манипулаторима догађаја. Овај алгоритам повезује елементе у резултујућем BPEL коду помоћу порука, које је исто тако тешко пратити кроз код. Проналажење жељеног дела кода је сложеније него код алгоритма заснованог на контролним линковима, зато што се поруке теже прате него контролни линкови. Поређење по другом критеријуму као победника даје алгоритам заснован на манипулаторима догађаја, јер исти може да представи било који BPMN процесни дијаграм у коме су елементи који могу да се представе у BPEL у [5]. контролним линковима је други по овом критеријуму. Овај критеријум не може за улаз да узме процесне дијаграме који садрже образац вишеструких инстанци, и неструктуриране петље, тј. петље које садрже више од једне улазно/излазне тачке. Сви остали типови процесних дијаграма могу бити улаз за овај алгоритам. Трећи по овом критеријуму је алгоритам заснован на обрасцима. Овај алгоритам може за улаз да узме само оне процесне дијаграме који садрже добро структириране компоненте дефинисане у литератури [4]. И последњи алгоритам по овом критеријуму јесте алгоритам заснован на претходним и следећим елементима, јер је његов скуп различитих типова процесних дијаграма који могу бити улаз подскуп (нема REPEAT WHILE компоненте). Када се сви алгоритми пореде по трећем критеријуму, прво место заузима алгоритам заснован на манипулаторима догађаја. За текући елемент се генерише код, без потребе да се зна било шта друго о процесном дијаграму. Други алгоритам јесте алгоритам заснован на скуповима претходних и следећих елемената. За његову имплементацију потребно је знање не само о текућем елементу, већ и о скупу његових претходних и следећих елемената. Трећи алгоритам по овом критеријуму јесте алгоритам заснован на контролним линковима. Последњи алгоритам јесте алгоритам заснован на обрасцима. Наиме, јако је сложено поредити део по део процесног дијаграма са добро структурираним компонентама дефинисаним у литератури [4]. Потребно је нагласити да алгоритам заснован на контролним линковима има две мане. Прва је да овај алгоритам може маскирати мртву тачку. То значи да се неке активности у резултујућем BPEL коду неће извршити. Друга је да свако извршавање активности може окинути највише једно извршење било које следеће активности. У табели 2 приказани су резултати поређења по изабраним критеријумима. За сваки алгоритам је наведен број поена по појединачном критеријуму и скалиран збир поена по свим критеријумима. Поени по појединачном критеријуму се добијају тако што први алгоритам добија 4 поена, други 3 итд. Уколико су два критеријума иста по поједином критеријуму, добијају по 3 поена, следећи 2 итд. 610
Табела 2 Резултати поређења алгоритама Критеријум I II III Укупно обрасцима контролним линковима манипулаторима догађаја скупу претходних и следећих елемената 3 2 1 2.2 2 3 2 2.2 1 4 4 2.5 3 1 3 2.6 Као најбољи алгоритам изабран је алгоритам заснован на скупу претходних и следећих елемената. Овај алгоритам има највише поена по вишекритеријумској анализи. 3. ЗАКЉУЧАК У овом раду представљен је један нови алгоритам за превођење из BPMN процесних дијаграма у BPEL шаблон процесне дефиниције, алгоритам заснован на скупу претходних и следећих елемената. Представљена је основна идеја алгоритма, а затим и његов детаљан опис. Извршено је поређење новог алгоритма са већ постојећим решењима. Претходно су дефинисани критеријуми за поређење, и такође дефинисане њихове тежине. Дати су резултати поређења и изабран најбољи алгоритам. Даљи рад на овом алгоритму могао би тећи у правцу проширивања скупа типова улазних BPMN дијаграма. Овај правац развоја препоручује се, јер је ово за сада највећа мана овог алгоритма. Ово проширивање могуће је спровести проналажењем нових правила која би се интегрисала у алгоритам Резултати приказани у овом раду могу се применити не само на превођење из BPMN а у BPEL, већ и на било који други пар стандарда, (графовски и блоковски орјентисани) који уопште не морају да буду из ове области науке (менаџмента). 4. ЛИТЕРАТУРА 1. Business Process Model and Notation (BPMN) Version 2.0 Specification 2011 2. Web Services Business Process Execution Language Version 2.0 OASIS Standard 3. Shuai G., Jinhua X., 2009 Interaction Mismatch Discovery based Transformation from BPMN to BPEL. IEEE International Conference on Services Computing 4. Ouyang, C., Dumas, M., Van der Aalst, W. M. P., ter Hofstede, A.H.M., and Mendling, J. 2009. From business process models to process-oriented software systems. ACM Trans. Softw. Eng. Methodol. 5. Mendling J., Recker J., 2006 On the Translation between BPMN and BPEL: Conceptual Mismatch between Process Modeling Languages, International Journal of Business Process Integration and Management. 6. zur Muehlen М., 2007 Business Process Management Standards Origin, Overview, and Directions, BPM Standards Tutorial. 611