Index of /rozprawy2/10896

Pełen tekst

(1)AGH University of Science and Technology in Krakow Faculty of Electrical Engineering, Automatics, Computer Science and Biomedical Engineering. P H D D ISSERTATION M ETHODS FOR M ODELING AND I NTEGRATION OF B USINESS P ROCESSES WITH RULES. AUTHOR : Krzysztof Kluza. S UPERVISOR : Grzegorz J. Nalepa Ph.D. Kraków 2014.

(2) Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Wydział Elektrotechniki, Automatyki, Informatyki i In˙zynierii Biomedycznej. ROZPRAWA D OKTORSKA M ETODY MODELOWANIA I INTEGRACJI PROCESÓW Z REGUŁAMI BIZNESOWYMI. AUTOR : Krzysztof Kluza. P ROMOTOR : dr hab. inz˙ . Grzegorz J. Nalepa. Kraków 2014.

(3) iii. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(4) iv. Darkowi. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(5) Podzi˛ekowania Chciałbym serdecznie podzi˛ekować wszystkim osobom, które w jakikolwiek sposób przyczyniły si˛e do powstania tej pracy. Zapewne nie zdołam wymienić wszystkich, takz˙ e tym, o których przez nieuwag˛e zapomniałem, winien b˛ed˛e piwo (a tym w cia˛z˙ y czekolad˛e). Rozprawa ta nigdy nie powstałaby, gdyby nie moi ukochani rodzice, którzy cały czas wspieraja˛ mnie we wszystkim co robi˛e. Kocham Was! <3 Za wsparcie dzi˛ekuj˛e równiez˙ mojemu bratu i siostrze, a takz˙ e szwagrowi i trójce moich cudownych siostrzeńców! Równiez˙ nie powstałaby bez Darka oraz wszystkich moich niesamowitych przyjaciół oraz rodzeństwa facebookowego – Eliasza, Jadzi, Ksi˛ez˙ niczki, Leszka, Piotrusia, Paris, Pauliny, Tomcia, Weroniki, Wiktorii, Roberta, [tu dopisz swoje imi˛e je´sli jeste´s moim przyjacielem lub moja˛ przyjaciółka]. ˛ Specjalne podzi˛ekowania dla cioci Lidki, która nie pozwoliła mi umrzeć z głodu w trakcie pisania tej rozprawy. Niestety przytyłem :( Na szcz˛esćie zrzuc˛e to c´ wiczac ˛ BOKWA fitness i tu podzi˛ekowania dla wszystkich instruktorów za trzymanie kciuków za mój doktorat. Dzi˛ekuj˛e równiez˙ tym, przy których moje z˙ ycie nabiera barw – całej zwariowanej ekipie Creative Cracow, a takz˙ e mojej cudownej grupie z zaj˛ec´ Chińskiego (a szczególnie najlepszej nauczycielce Lee Hui!) Nie obejdzie si˛e równiez˙ bez podzi˛ekowań dla osób z AGH, w szczególno´sci dla całej Katedry Informatyki Stosowanej oraz Katedry Automatyki i Inz˙ ynierii Biomedycznej, bo to praca tutaj doprowadziła mnie do tego momentu; takz˙ e dla moich studentów za wyrozumiało´sc´ w opó´znieniu sprawdzania ich prac... Ogromne podzi˛ekowania adresuj˛e do tych studentów, którzy szczególnie angaz˙ uja˛ si˛e w projekty, którymi si˛e opiekuj˛e. W szczególno´sci nie mógłbym nie wymienić Artura Smaronia, który zaskakuje mnie na kaz˙ dych konsultacjach rewelacyjnymi pomysłami oraz ich implementacjami. Dzi˛ekuj˛e równiez˙ uczestnikom szeregu konferencji BPM za interesujace ˛ dyskuje, mnóstwo cennych rad. Szczególne Piotrkowi za cenne dyskusje dot. praktycznych aspektów BPM. Moje losy równiez˙ mogłyby si˛e potoczyć inaczej, gdyby nie cenne rozmowy konferencyjne ze znakomitymi profesorami, takimi jak Wil van der Aalst, Hajo A. Reijers, Jan Mendling, Jan Vanthienen i wielu innych. Dzi˛ekuj˛e za wskazówki i motywacj˛e! Ogromne podzi˛ekowania nalez˙ a˛ si˛e dla całego zespołu GEIST, bo bez was niczego by nie było. W szczególno´sci za bezpo´srednia˛ pomoc przy tej rozprawie dzi˛ekuj˛e Krzy´skowi (i jego cudownej z˙ onie, z˙ e mu pozwalała czasem zostać dłuz˙ ej w pracy, by´smy mogli porozmawiać) oraz Mateuszowi. Na koniec zostawiam najwaz˙ niejsze podzi˛ekowania: dla prof. Antoniego Lig˛ezy, za czuwanie nad wszystkim nad czym tylko moz˙ na czuwać; dla prof. Marcina Szpyrki za wiar˛e w to, z˙ e jest mnie w stanie nauczyć matematyki; dla mojego promotora dra hab. inz˙ . Grzegorza J. Nalepy oraz jego z˙ ony za nieustanne motywowanie mnie do pracy!. v.

(6) Abstract This dissertation is concerned with methods for modeling and integration of Business Processes with Business Rules. Processes provide a universal method of describing operational aspects of business. Rules, in turn, support declarative specification of domain knowledge. Although there is a difference in abstraction levels between both modeling techniques, rules can be complementary to processes. Rules can be efficiently used to specify process low-level logic, while processes can serve as a procedural specification of the workflow, including the inference control. The main goal of the dissertation is to provide an efficient and formalized method for integration of processes with rules that supports design of the integrated models as well as addresses such challenges as: 1) the design representation mismatch (between the abstract analytical models and the executable ones); 2) providing a way of keeping up with specification changes (model should be susceptible to change); and 3) supporting execution of such integrated models. To accomplish this goal, the dissertation makes the following original contributions. First of all, it introduces a formalized General Business Logic Model – a process model integrated with rules. This integrated model was applied to combine a process model with the Semantic Knowledge Engineering approach in order to define the SKE-specific Business Logic Model. This is followed by the extension of the formalization of Attribute Relationship Diagrams, in order to describe the algorithm for automatic generation of Business Process models from ARD models. Using the algorithm, an executable process model can be generated along with decision table schemas for rules (rule templates for rule sets grouped in decision tables). Such a model can be treated as a structured rule base that provides explicit inference flow determined by the process control flow. This approach fits well into the Model-Driven Engineering paradigm. Finally, the modeling and execution environment for such integrated models was presented. In order to evaluate the results of this dissertation, the practical evaluation of the approach is provided. It consists of using the SKE-specific Business Logic Models for the formalization of selected benchmark cases, which are measured, and then deployed and tested. Considering the results of the evaluation, the proposed approach provides an efficient method for integration of Business Processes with Business Rules that allows for generating BPMN models integrated with the XTT2 rules from the SKE approach.. vi.

(7) Streszczenie Rozprawa dotyczy metod modelowania i integracji procesów z regułami biznesowymi. Procesy biznesowe stanowia˛ uniwersalna˛ metod˛e pozwalajac ˛ a˛ opisać działalno´sc´ operacyjna˛ przedsi˛ebiorstw i organizacji, natomiast reguły umoz˙ liwiaja˛ deklaratywny opis wykorzystywanej wiedzy. Chociaz˙ wyst˛epuje róz˙ nica w poziomach abstrakcji mi˛edzy procesami i regułami, w praktyce reguły moga˛ stanowić istotne uzupełnienie procesu. W szczególno´sci moga˛ być uz˙ ywane do opisu niskopoziomowej logiki procesu, natomiast procesy do opisu przepływu pracy, który moz˙ e jednocze´snie okre´slać proces wnioskowania w bazie wiedzy. Problemem naukowym rozwaz˙ anym w niniejszej rozprawie jest efektywna metoda integracji procesów biznesowych z regułami biznesowymi, która wspiera projektowanie zintegrowanych modeli, jednocze´snie b˛edac ˛ w stanie sprostać wyzwaniom, takim jak niedopasowanie reprezentacji modelu (w szczególno´sci niedopasowanie wyst˛epujace ˛ pomi˛edzy abstrakcyjnymi modelami analitycznymi, a modelami wykonywalnymi), zapewnienie łatwo´sci modyfikacji modelu przy zmianie specyfikacji, a takz˙ e wspieranie uruchamiania tego typu modeli zintegrowanych. W celu rozwiazania ˛ postawionego problemu, w rozprawie wprowadzono oraz sformalizowano ogólny model logiki biznesowej, który łaczy ˛ procesy z regułami biznesowymi. Ten ogólny model został uz˙ yty do formalnego opisu integracji modeli procesów w notacji BPMN z regułami XTT2 uz˙ ywanymi w metodzie Semantycznej Inz˙ ynierii Wiedzy. Ponadto rozszerzono opis formalny diagramu ARD (zalez˙ no´sci pomi˛edzy atrybutami) oraz metody ich tworzenia, w celu formalnego opisania algorytmu automatycznego generowania zintegrowanych modeli na podstawie specyfikacji systemu w postaci takich diagramów. Algorytm tworzy wykonywalny model procesu zintegrowany ze schematami odpowiednich tablic decyzyjnych dla reguł. Model ten moz˙ e być traktowany jako ustrukturalizowana baza wiedzy, okre´slajaca ˛ przepływ wnioskowania przy uz˙ yciu przepływu sterowania w procesie. Na koniec zaproponowane zostało s´rodowisko do modelowania i uruchamiania modeli zintegrowanych. W celu ewaluacji przedstawionych rezultatów, opracowane zostały przykłady, dla których wg opisanego algorytmu wygenerowane zostały modele zintegrowane. Zostały one opisane przy uz˙ yciu zaproponowanej formalizacji, przeanalizowano dla nich odpowiednie metryki złoz˙ ono´sci, a nast˛epnie w ramach walidacji zostały one wdroz˙ one w s´rodowisku uruchomieniowym oraz przetestowane. W rezultacie wykazano, z˙ e zaproponowane podej´scie stanowi efektywna˛ metod˛e integracji procesów z regułami biznesowymi. vii.

(8) Contents 1 Introduction. 1. 1.1. Motivation, Scope and Research Problem . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Goal and Plan of the Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.3. Original Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 1.4. Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 2 Business Processes. 6. 2.1. BPM Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 2.2. Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1. Process Modeling Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10. 2.2.2. BPMN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15. 2.2.3. BPMN Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18. 2.2.4. BPMN Pragmatics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19. 2.3. Model Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24. 2.4. Complexity Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25. 2.5. Process Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.5.1. Business Process Execution Language . . . . . . . . . . . . . . . . . . . . . . . . . 27. 2.5.2. Runtime Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28. 3 Business Rules. 31. 3.1. Business Rules Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31. 3.2. Rules Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32. 3.3. 3.2.1. Decision Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32. 3.2.2. Decision Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34. 3.2.3. Reasoning Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35. 3.2.4. Categories of Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35. Rule Languages and Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.1. Rule Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 viii.

(9) ix. CONTENTS. 3.3.2. Visual Rule Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38. 3.4. Selected Tools Supporting Rule Modularization . . . . . . . . . . . . . . . . . . . . . . . . 40. 3.5. Business Rules in Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42. 4 Formal Model for Business Processes with Rules. 48. 4.1. Motivation and Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48. 4.2. Process Model Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51. 4.3. Formal Description of BPMN Process Model . . . . . . . . . . . . . . . . . . . . . . . . . 52. 4.4. General Business Logic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59. 4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67. 5 Extension of Semantic Knowledge Engineering with Business Processes. 68. 5.1. Attributive Logic with Set Values over Finite Domains . . . . . . . . . . . . . . . . . . . . 68. 5.2. Formulation of XTT2 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70. 5.3. SKE-specific Business Logic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73. 5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75. 6 Automatic Generation of Business Process Models. 76. 6.1. Formalization of ARD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76. 6.2. Algorithm for BPMN Model Generation from ARD . . . . . . . . . . . . . . . . . . . . . 84. 6.3. Design Example: Algorithm Applied to the PLI Case . . . . . . . . . . . . . . . . . . . . . 89. 6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90. 7 Modeling and Execution Environment for Integrated Models 7.1. 7.2. 7.3. 7.4 K. Kluza. 94. Semantic Knowledge Engineering Design Process . . . . . . . . . . . . . . . . . . . . . . 95 7.1.1. Conceptual Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95. 7.1.2. Logical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96. 7.1.3. Physical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97. SKE-based Design Process for the Integrated Approach . . . . . . . . . . . . . . . . . . . 98 7.2.1. Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100. 7.2.2. Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103. Model-based Perspective on the Integrated Approach . . . . . . . . . . . . . . . . . . . . . 104 7.3.1. Meta Object Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104. 7.3.2. Model Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105. 7.3.3. Business Logic Model in the Context of MDA . . . . . . . . . . . . . . . . . . . . . 106. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Methods for Modeling and Integration of Business Processes with Rules.

(10) x. CONTENTS. 8 Evaluation of the Approach. 108. 8.1. Evaluation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108. 8.2. Modeling of Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 8.2.1. Case 1: Polish Liability Insurance . . . . . . . . . . . . . . . . . . . . . . . . . . . 109. 8.2.2. Case 2: EUrent Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115. 8.2.3. Case 3: UServ Financial Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 121. 8.3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131. 8.4. Measurement of Model Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134. 8.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 8.5.1. Evaluation Procedure Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136. 8.5.2. Identified Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137. 9 Concluding Remarks and Future Work. 138. 9.1. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138. 9.2. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140. A Models for the Benchmark Cases A.1. 141. PLI models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 A.1.1 ARD model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 A.1.2 BPMN model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 A.1.3 XTT2 model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146. A.2. EUrent models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 A.2.1 ARD model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 A.2.2 BPMN model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 A.2.3 XTT2 model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169. A.3. Userv models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 A.3.1 ARD model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 A.3.2 BPMN model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 A.3.3 XTT2 model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190. Bibliography. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules. 214.

(11) List of Abbreviations AI. –. Artificial Intelligence. AV-Pair Table. –. Attribute-Value Pair Table. ARD. –. Attribute Relationship Diagrams. ALSV(FD). –. Attributive Logic with Set Values over Finite Domains. AGD. –. Average Gateway Degree. BLD. –. Basic Logic Dialect. BOM. –. Bill Of Materials. B2B. –. Business-to-Business. BPEL4WS. –. Business Process Execution Language for Web Services. BPMN. –. Business Process Model and Notation. BR. –. Business Rules. BRG. –. Business Rules Group. BRMS. –. Business Rule Management Systems. CNC. –. Coefficient of Network Complexity. CTL. –. Computational Tree Logic. CIM. –. Computation Independent Business Models. D3. –. Decision Dependency Design. DMN. –. Decision Model and Notation. DPD. –. Design Process Diagram. EAI. –. Enterprise Application Integration. EUrent. –. EUrent Company. EPC. –. Event-Driven Process Chain. GH. –. Gateway Heterogenity. GoM. –. Guidelines of Modeling. IDEF3. –. Integrated DEFinition Method 3. IC. –. Interface Complexity. LTL. –. Linear Temporal Logic. LOC. –. Lines of Code. MGD. –. Maximum Gateway Degree. MOF. –. Meta Object Facility. MDE. –. Model-Driven Engineering. MDA. –. Model Driven Architecture.

(12) NLP. –. Natural Language Processing. NOAC. –. Number of activities and control flow elements. NOAJS. –. Number of activities, joins and splits. NOA. –. Number of activities. OCL. –. Object Constraint Language. OMG. –. Object Management Group. OWL2. –. OWL 2 Web Ontology Language. PIM. –. Platform Independent Models. PSM. –. Platform Specific Models. PLI. –. Polish Liability Insurance. PVM. –. Process Virtual Machine. PRD. –. Production Rule Dialect. PRR. –. Production Rule Representation. PBWD. –. Product Based Workflow Design. PDM. –. Product Data Model. PST. –. Product Structure Tree. RDR. –. Ripple Down Rules. rBPMN. –. Rule-based BPMN. RIF. –. Rule Interchange Format. RuleML. –. Rule Markup Language. SBVR. –. Semantics of Business Vocabulary and Business Rules. SAL. –. Set Attributive Logic. SE. –. Software Engineering. TPH. –. Transformation Process History. URML. –. UML-Based Rule Modeling Language. UML AD. –. UML Activiti Diagram. UML. –. Unified Modeling Language. URI. –. Uniform Resource Identifier. UServ. –. UServ Financial Services. WSDL. –. Web Services Description Language. WfMC. –. Workflow Management Coalition. WFM. –. Workflow Management. XTT2. –. EXtended Tabular Trees version 2. YAWL. –. Yet Another Workflow Language.

(13) List of Figures 2.1. Comparison of Workflow Management and Business Process Management (based on [235]). 7. 2.2. Business Process Management Lifecycle [282] . . . . . . . . . . . . . . . . . . . . . . . .. 9. 2.3. BPMN core objects of internal Business Process Model [86] . . . . . . . . . . . . . . . . . 15. 2.4. Fragment of the BPMN MOF metamodel [177] . . . . . . . . . . . . . . . . . . . . . . . . 17. 2.5. Symmetric vicious circle with inclusive gateways . . . . . . . . . . . . . . . . . . . . . . . 18. 2.6. Exemplary models with correct BPMN syntax but violating (above) or following (below) a style rule defined by Silver [214]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21. 2.7. Service organization paradigms (based on [184]): orchestration (left), choreography (right) . 28. 2.8. Top leaders in BPMS systems (according to Gartner Group and Forrester Wave reports) . . . 29. 2.9. Components of Business Process engines a) Activiti (left), b) jBPM (right) . . . . . . . . . . 29. 3.1. An example of a decision tree corresponding to the decision table from Table 3.3 . . . . . . 34. 3.2. An example of an OCL expression [197] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38. 3.3. An example of URML model for production rule . . . . . . . . . . . . . . . . . . . . . . . 40. 3.4. Decision process modeled using a BPMN gateway and sequence flow guards . . . . . . . . 42. 3.5. Decision process of the model from Figure 3.4 modeled using a BR task . . . . . . . . . . . 43. 3.6. Visualization of the set of rules in BPMN using conditional events (a set of rules correspons to the decision table from Table 3.3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43. 3.7. Visualizing a rule in BPMN (using the method proposed in [30]) . . . . . . . . . . . . . . . 44. 3.8. A fragment of an exemplary rBPMN model . . . . . . . . . . . . . . . . . . . . . . . . . . 45. 3.9. Designing BP with BR in Business Process Visual Architect . . . . . . . . . . . . . . . . . 47. 4.1. Conditional Sequence Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60. 4.2. Conditional (Start and Intermediate) Events . . . . . . . . . . . . . . . . . . . . . . . . . . 61. 4.3. Conditional (Non-interruptive and Interrputive) Boundary Events . . . . . . . . . . . . . . . 61. 4.4. Event Subprocesses with Conditional Start Event . . . . . . . . . . . . . . . . . . . . . . . 61. 4.5. Business Rule task (a standard and a call activity task) . . . . . . . . . . . . . . . . . . . . 62. 4.6. Exclusive, Inclusive (Multi-choice) and Complex Diverging Gateways . . . . . . . . . . . . 62. 4.7. Converging Complex Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 xiii.

(14) LIST OF FIGURES. xiv. 4.8. Gateway after BR task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63. 4.9. Gateway preceded by a subprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64. 4.10 Even-based Exclusive Gateways (non-instantiating and instantiating) . . . . . . . . . . . . . 64 4.11 Loop Activity (a task and a subprocess) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.12 Multiinstance task (parallel, sequentiall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.13 Lanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.1. Decision table schema (left) and the same table filled in with rules (right) [95] . . . . . . . . 82. 6.2. The outline of our approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85. 6.3. The steps of algorithm presented in a process model . . . . . . . . . . . . . . . . . . . . . . 86. 6.4. The “Develop Business Rule task” subprocess . . . . . . . . . . . . . . . . . . . . . . . . . 86. 6.5. Phase ¶: Generating Business Rule tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 90. 6.6. Phase ·: Generating User tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91. 6.7. Phase ¸: Adding a Start event to the process model . . . . . . . . . . . . . . . . . . . . . . 91. 6.8. Phase ¸: Generating additional Business Rule tasks . . . . . . . . . . . . . . . . . . . . . . 92. 6.9. Phase ¹: Adding connections between element . . . . . . . . . . . . . . . . . . . . . . . . 92. 6.10 Phase º: Adding a User task displaying the results of the process . . . . . . . . . . . . . . . 92 6.11 The BPMN model for the PLI case study with forms and rules . . . . . . . . . . . . . . . . 93 7.1. Overview of the Semantic Knowledge Engineering Design Process [146] . . . . . . . . . . . 96. 7.2. The ARD diagram for the presented example in the HJEd editor . . . . . . . . . . . . . . . 97. 7.3. Screenshot from the HQEd editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98. 7.4. An overview of the proposed design approach . . . . . . . . . . . . . . . . . . . . . . . . . 99. 7.5. An outline of the Oryx editor’s architecture [231]. . . . . . . . . . . . . . . . . . . . . . . . 101. 7.6. Screenshot from the prototype Oryx GUI for XTT2 [87] . . . . . . . . . . . . . . . . . . . 101. 7.7. An exemplary process model in BPWiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102. 7.8. A fragment of the MOF metamodel abstract syntax (for MOF 1.4) [45] . . . . . . . . . . . . 104. 7.9. Traditional OMG Modeling Infrastructure [62] . . . . . . . . . . . . . . . . . . . . . . . . 105. 7.10 Major steps in the MDA development process [84] . . . . . . . . . . . . . . . . . . . . . . 106 7.11 Business Logic Model in the MOF Modeling Infrastructure . . . . . . . . . . . . . . . . . . 106 7.12 The integrated approach steps in the context of the MDE development process . . . . . . . . 107 8.1. The BPMN model for the PLI case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111. 8.2. The BPMN model for the PLI case study with forms and rules . . . . . . . . . . . . . . . . 114. 8.3. The ARD model for the EURent case study . . . . . . . . . . . . . . . . . . . . . . . . . . 116. 8.4. The BPMN model for the EURent case study . . . . . . . . . . . . . . . . . . . . . . . . . 118. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(15) LIST OF FIGURES. xv. 8.5. The BPMN model for the EURent case study with forms and rules . . . . . . . . . . . . . . 120. 8.6. The ARD model for the UServ case study . . . . . . . . . . . . . . . . . . . . . . . . . . . 123. 8.7. The BPMN model for the UServ case study . . . . . . . . . . . . . . . . . . . . . . . . . . 128. 8.8. The BPMN model for the UServ case study with forms and rules (left part) . . . . . . . . . 129. 8.9. The BPMN model for the UServ case study with forms and rules (right part) . . . . . . . . . 130. 8.10 The jUnit tests for the PLI model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 A.1 The BPMN model for the PLI case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 A.2 The TPH model for the EURent case study . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 A.3 The BPMN model for the EURent case study . . . . . . . . . . . . . . . . . . . . . . . . . 165 A.4 The TPH model for the UServ case study . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 A.5 The BPMN model for the UServ case study . . . . . . . . . . . . . . . . . . . . . . . . . . 187. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(16) Chapter 1. Introduction This chapter introduces the reader to the content of the dissertation. It consists of four sections: Section 1.1 presents the background of the research, defines the scope of the thesis and argues why it is an important issue in the field of Computer Science. Section 1.2 specifies the goal of the research and describes the steps taken to achieve it. Section 1.3 emphasizes the original contribution of the thesis. Section 1.4 discusses the issues that were deliberately not addressed in this thesis.. 1.1. Motivation, Scope and Research Problem. Business Process Management (BPM) [40, 267] is a holistic approach for improving organization’s workflow in order to align processes with client needs. It focuses on reengineering of processes to obtain optimization of procedures, increase efficiency and effectiveness by the constant process improvement. In such the approach, a Business Process (BP) can be simply defined as a collection of related tasks which produces a specific service or product for a customer [121]. Models of BPs are intended to be a bridge between technical and business people. They are simple and visualizations make them much easier to understand than using a textual description. Thus, modeling is an essential part of BPM. Since a properly designed model should not require major changes or enhancements, it is important to provide an efficient modeling approach. According to Friedrich et al. [47], the acquisition of process models can consume up to 60% of the time spent on process management projects. It is so, because BPs are mostly modeled manually by a designer. This time can be shortened if models are generated automatically. Another important aspect of Business Process Management is Business Process Enactment [267]. It focuses on executing BP models in order to support BPM with IT system. In practice, manually designed process models have to be complemented with additional configuration and implementation in order to be executed in the BP runtime environment.. 1.

(17) 1.2. Goal and Plan of the Work. 2. Although processes provide a universal method of describing operational aspects of business, detailed aspects of process logic should be described on different abstraction level. Business Rules (BR) can be successfully used to specify process low-level logic [27, 98]. What is important, the BR approach supports the specification of knowledge in a declarative manner. There is a difference in abstraction levels of BP and BR; however, rules can be to a certain degree complementary to processes. BR provide declarative specification of domain knowledge, which can be encoded into a process model. On the other hand, a process can be used as a procedural specification of the workflow, including the inference control [97]. The use of BR in BP design also helps to simplify complex decision modeling. Although rules should describe business knowledge in a formalized way that can be further automated, there is no common understanding how process and rule models should be structured in order to be integrated [65]. The research problem considered in this dissertation is how to provide an efficient method for integration of Business Processes with Business Rules, that deals with such challenges as the design representation mismatch (especially between the abstract analytical models and the executable ones), providing a way of keeping up with specification changes and supporting execution of such integrated models. Therefore, in this thesis a method for integration of Business Processes with Business Rules is proposed. It focuses on modeling and execution of the integrated model. The problem is considered using the existing representation methods for processes and rules, specifically Business Process Model and Notation (BPMN) [177] for visual BP models, and eXtended Tabular Trees version 2 (XTT2) [157] – a formalized rule representation developed as a part of the Semantic Knowledge Engineering (SKE) approach [146]. Moreover, the presented research focuses on automatic generation of such integrated models from Attribute Relationship Diagrams (ARD) [153]. The ARD method is a part of the SKE approach. The suitable algorithm for generating BPMN process models from ARD is proposed. Using the algorithm, an executable process model can be generated along with decision table schemas for rules (rule templates for rule sets grouped in decision tables). Such a model can be treated as a structured rule base that provides explicit inference flow determined by the process control flow. Such an approach fits into the Model-Driven Engineering (MDE) paradigm [213].. 1.2. Goal and Plan of the Work. The main goal of the work presented in this thesis is to provide an efficient method for integration of Business Processes with Business Rules that supports design and execution of the integrated models as well as solves the challenges mentioned above.. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(18) 1.2. Goal and Plan of the Work. 3. It is assumed that the goal of this work can be reached in the following steps: 1. Definition of the formalized General Business Logic Model. 2. Application of the model to the SKE approach and formulation of SKE-specific Business Logic Model. 3. Definition of the algorithm that allows for transforming ARD diagrams to BPMN models. These steps are discussed in details in the further part of the thesis that is organized as follows: The next two chapters position the research presented in this thesis by overviewing current literature relevant to the topic of modeling and integration of Business Processes and Business Rules. Chapter 2 provides an overview of the Business Processes field, emphasizing the Business Process Management Life Cycle (Section 2.1) and describing in detail selected relevant research topics concerning Business Process modeling (Section 2.2), the existing process model generation approaches (Section 2.3), complexity assessment (Section 2.4) as well as execution environment issues (Section 2.5). Chapter 3 outlines the Business Rules approach (Section 3.1), highliting Business Rules modeling (Section 3.2), representation issues (Section 3.3) and tool support (Section 3.4), as well as Business Rules in the context of Business Process (Section 3.5). Chapter 4 discusses the motivation for the research by presenting selected challenges (Section 4.1) and approaches to formalization of a process model (Section 4.2). It introduces a formal description of the BPMN process model (Section 4.3) and its integration with rules – General Business Logic Model (Section 4.4). Chapter 5 gives an overview of the Semantic Knowledge Engineering approach. The chapter provides a short introduction to Attributive Logic with Set Values over Finite Domains (Section 5.1) and formulation of the XTT2 Rules (Section 5.2). Finally, it presents how the SKE approach can be integrated with BPMN process model as the SKE-specific Business Business Logic Model (Section 5.3). Chapter 6 presents the algorithm for automatic generation of Business Process models. It introduces the extended formalization of ARD (Section 6.1), describes the algorithm for a BPMN Model generation from the ARD model (Section 6.2) and shows a design example for the application of the algorithm (Section 6.3). Chapter 7 describes the modeling and execution environment supporting the presented approach. The chapter compares the SKE approach (Section 7.1) and the design process for the integrated approach (Section 7.2) introduced in the previous chapters, and presents the MDE model-based perspective, consistent with MDE, on the research results (Section 7.3). The chapter is concluded in the final section (Section 7.4). In Chapter 8 the practical evaluation of the approach is provided. It consists of defining the steps of the evaluation procedure (Section 8.1), providing the SKE-specific Business Logic Models for the selected benchmark cases (Section 8.2). Then the deployment results for the selected models are presented (Section 8.3) as well as suitable metrics for models are measured and analyzed (Section 8.4). The evaluation is concluded in the final section (Section 8.5). Chapter 9 finishes the dissertation by providing a summary of the presented work with conclusions and directions for future work.. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(19) 1.3. Original Contribution. 1.3. 4. Original Contribution. The following results are considered to be the original contribution of this thesis: 1. Introduction and formalization of the General Business Logic Model – the formal description of the BPMN process model and its integration with rules are presented in Sections 4.3 and 4.4 in Chapter 4. 2. Definition of the SKE-specific Business Logic Model – Generality of the introduced General Business Logic Model allows for its application to specific approaches. Thus, a BPMN process model is integrated with the SKE approach as the SKE-specific Business Business Logic Model, presented in Section 5.3 in Chapter 5. 3. Extension of formalization of the Attribute Relationship Diagram method – in order to support formal description of the translation algorithm, the improved formalization of the ARD model from the SKE approach is introduced in Section 6.1 in Chapter 6. 4. Definition of the translation from an ARD model into an SKE-specific Business Logic Model – the algorithm for automatic generation of Business Process models from ARD models along with an exemplary translation is presented in Sections 6.2 and 6.3 in Chapter 6. 5. Providing the modeling and execution environment for the integrated approach – models that are a result of the proposed translation are supported by the modeling and execution environment presented in Section 7.2 in Chapter 7.. 1.4. Exclusions. As Business Process Management constitutes a wide research area [242], this thesis is focused on modeling and executing of Business Process models with rules. Therefore neighbour aspects related to selecting model from collections (like merging models or configuring models) [36], monitoring and adapting processes [140], analyzing models (verifying, conformance checking) [240, 7, 58, 208], improving models using e.g. simulation [6, 67] are not significant in this context and are not discussed as related works. Moreover, the dissertation also omits the broad process mining field as process mining techniques are based on event data [241] and the approach presented in the thesis is based on data model prepared for the specific domain and not related to the observed behavior from logs. The work described in this dissertation is supported by the “Methodology for designing Hierarchical Business Processes integrated with Business Rules” (H I B U P RO B U RUL) research project funded from NCN (National Science Center) resources for science according to decision no. DEC-2011/03/N/ST6/009091 . 1. See: http://geist.agh.edu.pl/pub:projects:hibuproburul:start.. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(20) 1.4. Exclusions. 5. The author was also involved in the number of other projects that allowed him to get knowledge related to Business Processes and Business Rules and gain experience in this area: • 2008-2009 – H E K AT E (MNiSW N516 024 32/2878): Hybrid Knowledge Engineering2 . • 2009-2011 – R EBIT (POIG 1.3.1): Business and Technological Rules Management3 . • 2010-2012 – BIMLOQ (MNiSW N516 422338): Business Models Optimization for Quality4 . • 2012-2015 – P ROSECCO (PBS1/B3/14/2012): Processes Semantics Collaboration for Companies5 .. 2. See: http://hekate.ia.agh.edu.pl. See: http://www.rebit.zarz.agh.edu.pl. 4 See: http://bimloq.ia.agh.edu.pl. 5 See: http://prosecco.agh.edu.pl. 3. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(21) Chapter 2. Business Processes This chapter positions the research presented in this thesis by reviewing current literature relevant to the topic of Business Processes. Section 2.1 provides an overview of the Business Processes field, emphasizing the Business Process Management Life Cycle. In Section 2.2, the following aspects of BP modeling are considered: syntax and semantics, strategies for BP modeling, design patterns and hierarchization issues. Section 2.3 gives an overview of the existing process model generation approaches. Section 2.4 presents selected complexity metrics for process models. BP execution issues are elaborated in Section 2.5.. 2.1. BPM Life Cycle. Business Process Management (BPM) [267] is a modern approach to improving organization’s workflow, which focuses on reengineering of processes to obtain optimization of procedures, increase efficiency and effectiveness by constant process improvement. The key aspect of BPM is a Business Process (BP). Although there is no single definition of a Business Process, the existing definitions have many things in common [29, 59, 271, 121]. A BP is usually described as a collection of related activities which transform different kinds of clearly specified inputs to produce a customer value, mainly considered as products or services and organizational goals, as output. Different definitions emphasize various aspects of such defined processes. Davenport described a process highlighting the importance of producing an output for a customer – how work is done [29]. Definition of Eriksson and Penker emphasizes how work is performed rather than describing products or services, results of a process [43]. Jacobson, in turn, underlined that a process should be customer-oriented and meet an individual customer’s needs [72]. A wider conceptualization of process was presented by Melao and Pidd [129]. They gave four perspectives on business process to understand BPs more fully. In their approach, BPs can be seen as either deterministic machines, complex dynamic systems, interacting feedback loops or social constructs. 6.

(22) 2.1. BPM Life Cycle. 7. Figure 2.1: Comparison of Workflow Management and Business Process Management (based on [235]) Thus, Business Process Management requires a specification of many aspects, such as goals, inputs, outputs, used resources, activities and their order, impact to other organizational units, customers and owners for each of managed processes to enable real benefits. It unifies the previously distinct disciplines such as Process Modeling, Simulation, Workflow, Enterprise Application Integration (EAI), and Business-toBusiness (B2B) integration into a single standard [182]. Therefore, BPM is often considered as either a legacy or the next step afer workflows. Workflow Management Coalition (WfMC) [268] defines a workflow [110] in terms of automation of a business process during which documents, information or tasks are passed from one participant to another for action, according to a defined set of procedural rules. According to van der Aalst et al. [235], BPM is a broader term than Workflow Management (WFM). BPM supports business processes using methods, techniques, and software in designing, enacting, controlling, and analyzing processes involving humans, organizations, applications, documents and other information sources. It is restricted to operational processes, thus it excludes processes that cannot be made explicit. A simple approach to process management distinguishes four phases of supporting processes [235]: 1. process design, in which the process is designed or redesigned, 2. system configuration, in which the design is implemented by configuring process management system, 3. process enactment, in which the operational business process is executed using the configured system, 4. diagnosis, in which the process is analyzed or verified to identify things that can be improved. The relationship between WFM and BPM is presented in Figure 2.1. As one can observe, BPM extends the traditional WFM approach. In the case of the WFM systems, they do not support diagnosis phase, and such features as simulation, verification or validation of process designs. Various definitions of BPM emphasize different aspects of process management: • Hill et al. underlined the process-oriented non-technological aspect [63], • Havey focused on standards for process modeling [60], K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(23) 2.1. BPM Life Cycle. 8. • Recker et al. stressed that apart from activities, BPM also deals with involved resources in light of their contribution to business performance [191], • According to Weske, BPM is influenced by concepts and technologies from different areas of business administration and computer science [267], • Jeston and Nelis highlighted the important factor of the management of organizational change and the associated people (staff) in BPM [75], • Smith and Finger emphazised creating and optimizing BP on the fly [217], • Khan pointed out that an essential BPM issue is to increase profitability, improve productivity and responsiveness, and reduce costs [81], • Elzinga also noticed that the key BPM aspect is a systematic and structured approach to improve the quality of products and services [41], • Commonly, BPM is understood as a top-down methodology for organizing, managing, and measuring the organization based on the organization’s processes [273].. Although many aspects of BPM have been debated in literature, one of the fundamental BPM issues is a repeating sequence of steps, the so-called Business Process Management Lifecycle (see Figure 2.2). The main idea behind the BPM lifecycle is to manage and improve BPs over business changes. Due to the use of clearly defined phases, BPM enables the continuous maintainance and the evolution of processes. During iterations, such parameters of business processes as cost, time, quality of output or customer satisfaction can be improved causing an improvement of the whole process.. Thus, BPM is in fact the application of the management cycle to organization’s business processes [282]. The BPM lifecycle starts with specification of organizational and process goals as well as an assessment of environmental factors having an effect on the organization BPs. In the following process design phase, the organization processes are to be identified or redesigned. In this phase the particular process details should be specified and the proper variables that will influence the process design should be identified as well. During the next phase the previously specified process models are implemented in the environment manually via procedure handbooks or using BPM or workflow software. Finally, the implemented process can be instantiated and executed. During execution, the performance is monitored in order to control and improve the process. Data produced during the process enactment and monitoring phases, aggregated from multiple process instances, can be used in the evaluation phase, which purpose is to formulate the results suitable for process improvement.. The following subsection describes research directions concerning Business Process Modeling approach in Business Process Design phase. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(24) 9. 2.1. BPM Life Cycle. Figure 2.2: Business Process Management Lifecycle [282]. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(25) 2.2. Process Modeling. 2.2. 10. Process Modeling. BP modeling is an essential part of BPM. As properly designed model will not require major changes or enhancements, it is important to provide an efficient modeling approach to a designer. The most commonly approach used for modeling BPs is activity flow-oriented one, which is frequently referred to as "workflow" representation. Consequently, such approaches are often referred to as workfloworiented. Although the representation of the flow of data through an information system models its process aspect as well, the data-oriented approaches, such as Data Flow Diagrams or Entity Relationship Diagrams [38], are out of scope of this thesis as they do not model the process directly.. 2.2.1. Process Modeling Languages. Although there are many process modeling languages, we focus here on the six visual and most successful ones: EPC, IDEF3, UML AD, Petri net, YAWL and BPMN. Processes in these languages consist of activities, which may be decomposed to subactivities. The order of activities defines the sequence of work. In the lower level, each activity transforms some inputs into outputs. Table 2.1 presents a simple yet illustrative example of a car rental process [242] in the abovementioned notations. The process starts with a registering request, and then extra insurance can be added. When check-in is initiated, the customer can select a car; at the same time the driver’s license is checked and the customer’s credit card is charged. The process ends when the chosen car is supplied to the customer. This exemplary process contains only basic control flow elements, which can be represented in all of these languages. However, it is important to mention that the expressiveness of each of these languages is much higher than the required for this example. In the following subsections each notation is shortly introduced and then an evaluative analysis of these languages is provided. Event-driven Process Chain (EPC) Event-Driven Process Chain (EPC) is a simple graphical modeling language for modeling processes introduced by August-Wilhelm Scheer [211]. It became a widespread process modeling language, because of the success of products such as SAP R/3, which is the leading ERP-system used by more than 200,000 customers1 all over the world, or the ARIS tool, a BPM platform with over 7,500 licenses2 . The EPC models are directed graphs visualizing the control flow [200]. Each EPC consists of events, functions and connectors, starts with at least one event and ends with at least one event, In EPC, each event triggers a function that leads to a new event. The notation supports three types of connectors (AND, XOR, 1 2. See: http://www.sap.com/corporate-en/our-company/history/index.epx (accessed 30.06.2014). See: http://www.softwareag.com/corporate/company/companyinfo/history/ (accessed 30.06.2014).. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(26) start. K. Kluza. 1. Register request. Register request. needed. Methods for Modeling and Integration of Business Processes with Rules. Initiate check-in. Check driver's license. Charge credit card. ready to be charged. Select car. ready to be checked. ready to be selected. 3. &. 6. Charge credit card. 5. Check driver's license. 4. &. Integrated DEFinition Method 3 (IDEF3). X. Initiate check-in. Select car. redy for supply. 7. Supply car. Supply car end. start. Register request. Initiate check-in Charge credit card. Check driver's license. Select car. Add extra insurance. add extra insurance. skip extra insurance. Initiate check-in. Petri net. initiate check-in. Charge credit card. Check driver's license. Select car. charge credit card. check driver's license. select car. UML Activiti Diagram (UML AD). no. Add extra insurance. end. Supply car. Supply car. supply car. Business Process Model and Notation (BPMN). Register request. register request. extra insurance?. yes. Table 2.1: Car rental exemplary process in various process modeling notations. Yet Another Workflow Language (YAWL). X. Add extra insurance. 2. added. Event-driven Process Chain (EPC). no need. Add extra insurance. 2.2. Process Modeling. 11.

(27) 2.2. Process Modeling. 12. OR) which can be used to model splits and joins. Although the core set of EPC modeling elements is small and consists of events, functions and connectors, neither the syntax nor the semantics of an event-driven process chain are well defined [238], especially in the case of extended EPCs with extra elements [212, 99]. However, some attempts to formalize the semantics of EPC were made in [238, 246].. Integrated DEFinition Method 3 (IDEF3) Integrated Definition (IDEF) is a family of modeling languages that arose in the 1979s out of the U.S. Air Force in order to increase manufacturing productivity [134, 8]. The IDEF suite contains sixteen types of modeling languages in the field of systems and software engineering; however, the majority is still under development and only IDEF0-4 are commonly used in practice. Among the IDEF languages, IDEF3 is concerned with modeling the processes of a business or its systems [135, 9]. IDEF3 Process Flow diagram consists of such elements as Unit of Behavior (UOB) boxes, precedence links, junctions (AND, XOR, OR), referents, and notes. An IDEF3 process description organizes the network of relations between situations in a specified scenario from the process-centered perspective.. UML Activiti Diagram (UML AD) The Unified Modeling Language (UML) [175] from the Object Management Group (OMG) constitutes a standardized notation for modeling software applications [68]. This multipurpose modeling language offers a variety of notations to capture different aspects of software [44, 185]. UML has become the dominant notation among software engineers and attempts to be a universal visual notation for software design. Activity diagram (AD) is a kind of the UML behavior diagrams for modeling dynamic aspects of the system, which focuses on the flow of activities involved in a single process and shows the dependencies among them [148, 90]. Although UML AD can be used for process modeling purposes [73, 42, 190], its complex nature makes it a barrier for non-technicians [182], and it is not suitable for all aspects of this type of modelling [206]. A simple process in UML AD consists of a sequence of nodes modeled using control-flow and objectflow. The control-flow comprises two types of nodes: action nodes (activities to be performed or signals to be received/sent by the process) and control nodes, which model sequencing and parallel or alternative branching. The flow of data between nodes can be represented by associations of object nodes with activities. Although the UML 2.0 [175] semantics is more precise than it was with UML 1.1 or UML 1.5 [168], there are still many ambiguities. One of the features of UML is the stereotype mechanism which extends the language semantics. They can be grouped into profiles which contain sets of stereotypes from a specific context. There is an ongoing research, such as [104], on precising, extending or redefining the semantics to overcome UML limitations. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(28) 2.2. Process Modeling. 13. Petri net Petri net [142] offers a graphical notation for modeling processes that include choice, iteration, and concurrent execution. A classical Petri net is a directed graph composed of two types of nodes: places and transitions. An arc in the net may connect a place to a transition or vice versa, but no arc may connect two nodes of the same type. A transition can have a number of input and output places. As Petri nets have an exact mathematical definition of their execution semantics and a well-developed mathematical theory for process analysis, they are suitable for modeling, analysis and simulation of dynamic systems. As generally the execution of Petri nets is nondeterministic, they are well suited for modeling the concurrent behavior of distributed systems [224]. Although there are serious limitations in Petri nets [15], according to van der Aalst, they have at least three advantages for being used as a workflow language. These are formal semantics, state-based instead of (just) event-based, and abundance of analysis techniques [240]. Moreover, they are quite expressive compared to many process languages [226]. However, van der Aalst and ter Hofstede do not propose Petri nets as an end-user language, but only use it for clarification, semantics formalization and analysis [250].. Yet Another Workflow Language (YAWL) YAWL3 is a Petri Net based workflow language [229, 249]. Having formal semantics, it supports specification of the control flow and the data perspective of business processes. The language encompasses workflow patterns to guarantee language expressibility [248]. The YAWL language extends the class of workflow nets with multiple instances, OR-joins and cancelations. Workflow net (WF-net) [236] is a subset of Petri net used to model workflows. In a WF-net, there is a unique input place and a unique output place and every other place and transition are on a directed path from input to output place, and WF-nets introduce additional notations for joins and splits (AND and XOR). In the case of YAWL, in contrast to Petri nets and WF-nets, its syntax allows tasks to be directly connected, which helps compress the visual representation of a YAWL model. What is worth noting, YAWL has a formal semantics and can offer powerful means for design time workflow checks [277]. Moreover, in contrast to UML or EPCs, YAWL models are executable and can be executed by the YAWL workflow engine released under the LGPL licence [243]. Although YAWL, in comparison to other workflow languages, can handle a significant number of control-flow patterns [248], it is very simple in terms of the number of available elements and constructs. 3. See: http://www.yawlfoundation.org (accessed 30.06.2014).. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(29) 2.2. Process Modeling. 14. Business Process Model and Notation (BPMN) BPMN [177], adopted by the OMG group, is the most widely used notation for modeling BPs. As the notation is quite complex, there are many additional documents explaining the notation [176, 269, 182], as well as several handbooks [3, 271, 214] and many papers devoted exclusively to this notation, e.g. [28, 275], as well as its application to various areas, e.g. [100, 118, 125, 225]. The BPMN notation uses a set of models with predefined graphical elements to depict a process and how it is performed. The current BPMN 2.0 specification [177] defines three models to cover various aspects of Business Processes: 1. Process Model — describes the ways in which operations are carried out to accomplish the intended objectives of an organization. The process can be modeled on different abstraction levels: public (collaborative Business 2 Business Processes) or private (internal Business Processes). 2. Choreography Model — defines expected behavior between two or more interacting business participants in the process. 3. Collaboration Model — can include Processes and/or Choreographies, and provides a Conversation view (which specifies the relation of message exchanges). In most cases, using only the Process Model is sufficient. In the cases of the previously presented notations, only internal Business Process Model is comparable to them. Comparison of the approaches Table 2.2 presents an evaluative analysis of the described Business Process modeling languages (the summary prepared on the basis of [122, 243, 192, 120, 263, 222]). Below, the description of symbols used in the table is presented: l. –. supported by the notation,. w. –. partially supported (not standardized or possible to present but not directly),. m. –. not supported.. As one can see from the Table 2.2, BPMN 2.0, a de facto industry standard for modeling processes, supports most of the listed elements. Thus, in the further considerations, the focus will be on this notation. Similarly to other languages, in the business process modeling languages three aspects can be distinguished: syntax, semantics and pragmatics. These aspects of the BPMN language will be elaborated in the following subsections.. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(30) 15. 2.2. Process Modeling. Year Creator Background Standardised Metamodel Formal methods Purpose Graphical Execution Atomic Activities Subprocess Events AND XOR Gateways OR Complex Internal Participants External Data flow Data Data objects Data repository. Petri net 1962 C. Petri Academic N.A. m l w m w w l w w m m m m m m m. Business Process modeling languages EPC IDEF3 UML AD YAWL 1992 1995 1997 2004 A.-W. Scheer U.S. Air Force OMG van der Aaalst Academic Industry Industry Academic No Yes Yes No w m l m m m m w l l l l m m m l w w l l w w l l l m l l l l l l l l l l l l l l m m w w l m l w m m l m l m l w w w l w m m l m. BPMN 2004 OMG Industry Yes l m l l l l l l l l l l l l l w. Table 2.2: Comparison of the supported elements in process modeling languages. 2.2.2. BPMN Syntax. Although the current BPMN 2.0 specification [177] defines three models to cover various aspects of processes, in most cases, including the research presented in this thesis, Business Process Model is sufficient or even too expressive to represent complex processes. The model uses four basic categories of elements to model BPs: flow objects (activities, gateways, and events), connecting objects (sequence flows, message flows, and associations), swimlanes, and artifacts, as shown in Figure 2.3. Flow Objects. Connecting Objects. Swimlanes. Artifacts. Sequence Flow Data Object. Gateways. Pool Annotation text. Message Flow. Text Annotations Activities Association. Lanes (within a pool). Events. Group. Figure 2.3: BPMN core objects of internal Business Process Model [86] K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(31) 16. 2.2. Process Modeling. In the case of flow object elements, activities denote tasks that have to be performed, events denote something that happens during the lifetime of the process, and gateways determine forking and merging. simple eq eq simple simple eq. of the sequence flow between tasks in a process, depending on some conditions (AND, XOR, OR, eventbased). The sequence flow between flow object elements is used to model the flow of control in a process. TheAmessage flow between selected elements is to model the flow of messages between participants of A used A A A A a process (which are depicted as different pools). BPMN 2.0 defines more than 100 elements, thus practitioners differentiate them based on the degree of model detail. Three levels of models can be distinguished [214]: descriptive level, which is the basic level B B that uses a very intuitive subset path” B of BPMN to reflect a “happy Bscenario and all major activities in a proB B B B B. A. A. A. cess; analytical level, dedicated to analysts, modelers and business architects that use complex structures and A. A. A. C. C. A. C. A. C. C. A. C. C. C. C. elements to design fully representative processes, and executable level for technicians in which execution details can be captured in the model. Although the BPMN 2.0 specification defines connection rules for sequence and message flows conA. A. A A A necting elements, it also provides the metamodel for the notation. Metamodel is one of methods used for A C. C. C. C. C. C. defining the syntax of visual languages. The abstract B B syntax of BPMN is defined by the BPMN metamodel, B B. B. B. which is a part of the BPMN 2.0 specification [177]. A fragment of the metamodel defining process and flow elements is presented in Figure 2.4. Despite the fact that the syntax of the language is well defined, two models with different structure, B. B. B. B. B. B. B. B. B. but behaviorally equivalent, can be both correct and unambiguous. This stems from the BPMN specification A. A. A. A. A. A. A. A. A. allowing for expressing theC same semantics using various syntactic structures. Table 2.3 presents an example C C C. C. C. C. C. C. of different exclusive choice representations in BPMN 2.0 [272].. A. A. A. A C. B. B. KluzaKluza Krzysztof KrzysztofKrzysztof Kluza. B. C. A. A A. C. C. B. B. B. C. A. A. C. C B. B. C. C. B. 6 of 76 of 7 6 of 7in BPMN Table 2.3: Different exclusive choice representations 2.0 [272]. BPMN processes can be regarded as equivalent if both of them can be transformed into a common graphical representation [105]. As in various application domains there is a need to compare process models [244], there is ongoing research in the area of process models equivalences [4, 244, 272] as well as process similarity detection [33, 35, 278, 32]. Analysis of Petri nets models equivalences can be found in [4, 244], while the thorough research in the area of BPMN models equivalences was carried by Vitus Lam and can be found in his papers [105, 106, 107]. Although Lam’s equivalences of models are formalized, he analyzes only several equivalence patterns. A wider range of equivalence patterns was presented in an overview paper by Kluza and Kaczor [86]. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(32) 17. 2.2. Process Modeling. Figure 10.2 - Process class diagram. Figure 2.4: Fragment of the BPMN MOF metamodel [177]. A Process is a CallableElement, allowing it to be referenced and reused by other Processes via the Call Activity construct. In this capacity, a Process MAY reference a set of Interfaces that define its external behavior.. Similarity business models have beenwithin suggested different purposes, e.g. meaA Process is ameasures reusable for element and process can be imported and used otherfor Definitions. suring 10.3 compliance between and actual searching of forarelated models in a repository [35]. Figure shows the detailsreference of the attributes andmodels model or associations Process. Similarity is typically quantified by a distance function that captures the amount of differences between a pair of process models [32]. Respectively, the distance between two process models that are equivalent should be close to 0 (process models are identical if their distance equals 0). The extensive research on similarity search and measure was conducted by Dijkman et al. [33, 35, 278, 32]. They proposed graph matching algorithms for searching similar process models [33], developed structural similarity measure that compares element labels as well as the topology of process models in order to estimate model similarities [35], as well as developed the technique for fast similarity search that uses similarity estimation based on on small characteristics of model fragments for finding potentially relevant models to Business be compared using the and graph 146 Process Model Notation, v2.0 matching techniques [278]. The next subsection presents another aspects of the language – the BPMN semantics. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(33) 18. 2.2. Process Modeling. 2.2.3. BPMN Semantics. BPMN 1.0 specification [170] described the semantics of BPMN flow objects in natural language as well as defined the mapping of BPMN elements to BPEL4WS [210]. However, as BPMN is graph-based and BPEL is a block-structured language, the mapping turned out to be very limited, incomplete, and definitely not straightforward [181, 265]. One of the fundamental definitions in BPMN 1.0 was the specification of inclusive gateway behaviour [170]: Process flow shall continue when the signals (tokens) arrive from all of the incoming sequence flow that are expecting a signal based on the upstream structure of the process (e.g. an upstream inclusive decision). Using this definition, a process modeling the so-called symmetric vicious circle has ambiguous semantics (see Figure 2.5), as it is not clear if the process flow may continue.. Figure 2.5: Symmetric vicious circle with inclusive gateways In the BPMN 2.0 specification [177] some of these ambiguities were clarified. Currently, the inclusive gateway is activated if at least one incoming sequence flow has at least one token and for each empty incoming sequence flow, there is no token in the graph anywhere upstream of this sequence flow, i.e. there is no directed sequence flow path from a token to this sequence flow unless • the path visits the inclusive gateway, or • the path visits a node that has a directed path to a non-empty incoming sequence flow of the inclusive gateway. Such clarification in the specification solves a problem in simple cases, however BPMN 2.0 semantics is designed mostly for safe processes e.g. processes that not suffer from lack of synchronization, etc. Moreover, although the natural language specification of the semantics is precise enough for intuitive understanding, it is often not sufficient for implementation, simulation or verification purposes. Taking into account the existing issues with BPMN semantics many researchers tried to define it. Thus, there are several attepts to formalize some subsets of the BPMN control flow elements or constructs for various purposes. Dijkman et al. presented the mapping of core subset of BPMN elements to Petri nets [34]. Their semantics does not model or-joins and splits from the core subset or more complex constructs. Wong and Gibbons defined a Z model [221] of BPMN syntax and described a behavioural semantics in terms of K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(34) 2.2. Process Modeling. 19. the process algebra CSP [274]. They extended and evaluated their work in [275]. In their research, in turn, they not considered such constructs like non-local semantics of or-joins. Lam used linear temporal logic (LTL) to represent selected BPMN 1.2 constructs for the formal analysis [106, 108]. The most complete BPMN 2.0 formalization to date was presented by Van Gorp and Dijkman in [37, 253]. They proposed a formalization of a subset of the BPMN 2.0 execution semantics in terms of graph rewrite rules which can be used for simulation, animation and execution purposes. The next subsection presents the last aspect of the language – the pragmatics of use.. 2.2.4. BPMN Pragmatics. Apart from the language syntax and semantics, in practice the pragmatics of its use is essential. As to present real life BPMN language pragmatics of business process modeling, in the next subsections the following issues are elaborated consecutively: strategies for BP modeling, modeling techniques and styles, workflow patterns, modularization approaches, and other methods for managing model complexity. Strategies for Business Process Modeling Havey distinguished four strategies for business process modeling [60]: • Top-down approach – specification begins with the general feature description and then the process is defined in more and more detail, on lower abstraction levels. Such an approach focuses on business needs and the subordination of specific solutions. However, minor errors on higher levels can enlarge in the detailed structure causing serious problems. • Bottom-up approach – specification begins with process elements and sub-processes, then these parts are combined to form a comprehensive process. This approach focuses on specific tasks, subprocesses and products. However, such a defined process can be too detailed what can complicate the process, especially if parts are modeled by different designers or based on different sources. • Inside-out approach – specification in this approach focuses on core processes that are identified first, and then based on such structure subsequent supporting elements, sub-processes and tasks are specified. Although the approach is a compromise between top-down and bottom-up approaches and should be free from disadvantages of these two approaches, it can be problematic to determine which processes and sub-processes are important and how to model them. Moreover, errors revealed in the model can enforce modeling process from scratch. • Mixed approach – specification in this strategy is a combination of all of the above approaches. They are used to model business process optimally and minimize probability of errors that could arise using just one of the approaches. Regardless of the chosen strategy, modeling method is also crucial. The following subsection discusses BPMN modeling techniques and style. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.

(35) 2.2. Process Modeling. 20. Modeling Techniques and Style There are several modeling guidelines that support different techniques and styles. Becker at al. describe the Guidelines of Modeling (GoM) with quality considerations for process models [10]. GoM consists of six guidelines to improve the model quality by taking into account such issues as correctness, relevance, economic efficiency, clarity, comparability, and systematic design. Mendling et al. focused on the prioritizing several guidelines with the help of industry experts, and then they define desirable characteristics of a process model by formulating seven guidelines which should be taken into consideration when modeling business processes [133]: 1. Model as structured as possible. 2. Decompose a model with more than 50 elements. 3. Use as few elements in the model as possible. 4. Use verb-object activity labels. 5. Minimize the routing paths per element. 6. Use one start and one end event. 7. Avoid OR routing elements. Both presented guidelines constitute rather a static view by focusing on the resulting process model, but not on the act of modeling itself. The guidelines concerning modeling style were proposed by Silver [214]. He described 58 style rules which constitute basic principles of compositions intended to make process logic clear. One of the examples of such a rule is illustrated in Figure 2.6. The figure presents two models, both of which are correct in terms of the BPMN syntax. However, the model above violates the rule no. 10 defined by Silver in the following way [214]: If a subprocess is followed by a gateway labeled as a question, the subprocess should have multiple end events, and one of them should match the gateway label.. A more empirical approach that focuses on the modeler’s interactions with the modeling environment was proposed by Pinggera et al. [187]. They investigated the real process followed to create the process model. In their research, they used cluster analysis to identify different modeling styles. As a result, they distinguished three different modeling styles and validated the retrieved clusters using a series of measures for quantifying the process of process modeling [186]. However, they did not specify any guidelines, so their conclusions are not very useful for modelers so far. Design patterns constitute a practical solution developed in Software Engineering [218]. Currently, they are often applied as general reusable solutions to commonly occurring problems within a given context. The next subsection provides a short overview of workflow patterns which are a specialized form of design patterns that refer to solutions related to process modeling. K. Kluza. Methods for Modeling and Integration of Business Processes with Rules.