From Protos to BPMN and back - TU/e · A mapping from Protos to BPMN and back is developed to...

Eindhoven University of Technology

MASTER

From Protos to BPMN and back

van Roermund, M.J.

Award date:2007

Link to publication

DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

https://research.tue.nl/en/studentthesis/from-protos-to-bpmn-and-back(670f937d-fbce-4232-9792-deb12756c2a6).html

EINDHOVEN UNIVERSITY OF TECHNOLOGYDepartment of Mathematics and Computer Science

From Protos to BPMN and back

byMark van Roermund

A thesis submitted to the Eindhoven

University of Technology in conformity

with the requirements for the degree of

Master of Science

Supervisors:Prof.dr.ir. W.M.P. van der Aalst (TU/e)

Ir. B.R. Grunbauer (Pallas Athena)Dr. A.K. Alves de Medeiros (TU/e)

Apeldoorn, August 2007

Abstract

Over the last few years, the Business Process Modeling Notation (BPMN) spec-ification [26] has become a standard graphical notation for capturing businessprocesses. Pallas Athena likes to explore the possibilities of BPMN, in par-ticular in relation to their business process modelling tool Protos. This thesisaims at examining the state-of-the-art with respect to BPMN, mapping Protosto BPMN and back, and implementing a proof-of-concept of these mappings.Moreover, a contribution is made to the troublesome semantics of OR-joins.

A critical analysis and an extensive tools evaluation is conducted in orderto assess the state-of-the-art with respect to the BPMN specification. Thecritical analysis focusses on the scope, a number of related standards, and thelack of formal semantics or BPMN. The tools evaluation gives an impression ofthe extent to which the BPMN standard is taken seriously by vendors in themarketplace.

A mapping from Protos to BPMN and back is developed to investigate thefeasibility and profitability of supporting BPMN in future versions of Protos.These mappings are presented using various characteristic modelling patternsin Protos and BPMN, supplemented with several assumptions, semantical is-sues, and interesting themes. A proof of concept consisting of two ExtensibleStylesheet Language (XSL) transformations between Protos and JViews BPMNModeler, a freeware modeler from ILOG, is implemented to demonstrate thefeasibility and viability of the mappings. In addition, the proof-of-conceptimplementation allows one to get acquainted with the mappings by means ofexperiments and provides a tangible way of communicating the potential ofBPMN for Protos.

Protos and BPMN have in common that they allow for OR-joins. However, OR-joins are rather problematic when implementing workflows. First of all, thereare all kinds of semantical problems. Second, any reasonable implementationof the OR-join is computational expensive as it requires repeated state-spaceexplorations. In this thesis, a pattern-matching approach is presented that il-lustrates that the structure of a process model provides a promising startingpoint for removing OR-joins without changing the behaviour. The approachuses so-called EWF-nets and R-nets as an abstraction mechanism, for makingit applicable to a wide range of process models in all kinds of languages andnotations, including Protos, BPMN, EPCs, and YAWL. A pseudo-code algo-rithm is presented that typically removes lots of OR-joins based on a numberof patterns and rules.

i

Acknowledgements

Finally, the Master programme Business Information Systems at the Eind-hoven University of Technology is soon to be concluded, leaving this MasterThesis as one of the last tangible remains. Before presenting the result, Iwould like to thank those who, in one way or another, have participated in therealisation of this project.

I would like to express my gratitude to Wil van der Aalst for his encouragingguidance and support throughout the project, and for sharing his stimulatingand inspiring ideas and insights.

I would like to thank Dolf Grunbauer, Paul Berens, and Maarte van Hattemfor numerous stimulating and fruitful discussions. In particular, I would like tothank Dolf Grunbauer for his continuous support with a great deal of humorand enthusiasm.

I want to thank Ana Karla Alves de Medeiros for providing valuable feedback.

Last but not least, I would like to thank my parents for their unconditionalsupport during the years of education.

Mark van RoermundApeldoorn, August 2007

iii

Contents

Abstract i

Acknowledgements iii

Contents v

List of Acronyms ix

1 Introduction 11.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Approach and Outline . . . . . . . . . . . . . . . . . . . . . . . 2

2 BPMN Evaluation 32.1 Critical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Related Specifications . . . . . . . . . . . . . . . . . . . 42.1.3 Lack of a Formal Foundation . . . . . . . . . . . . . . . 52.1.4 Ontological Analysis . . . . . . . . . . . . . . . . . . . . 6

2.2 Tools Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Tools Overview . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 BPMN Conformance . . . . . . . . . . . . . . . . . . . . 10

2.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Mapping from Protos to BPMN 173.1 Pattern Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.2 Parallel Behaviour . . . . . . . . . . . . . . . . . . . . . 203.1.3 Wait for Event . . . . . . . . . . . . . . . . . . . . . . . 223.1.4 Exclusive Choice . . . . . . . . . . . . . . . . . . . . . . 243.1.5 Deferred Choice . . . . . . . . . . . . . . . . . . . . . . 273.1.6 Deadline Monitoring . . . . . . . . . . . . . . . . . . . . 283.1.7 Process Instantiation . . . . . . . . . . . . . . . . . . . . 293.1.8 Process Termination . . . . . . . . . . . . . . . . . . . . 30

3.2 Connection Semantics . . . . . . . . . . . . . . . . . . . . . . . 323.2.1 Converging Connections . . . . . . . . . . . . . . . . . . 323.2.2 Diverging Connections . . . . . . . . . . . . . . . . . . . 34

3.3 Interesting Themes . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.1 Lack of States . . . . . . . . . . . . . . . . . . . . . . . . 363.3.2 Consequences of Semantical Decisions . . . . . . . . . . 37

v

vi Contents

4 Mapping from BPMN to Protos 394.1 Pattern Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.1 Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . 394.1.2 Wait for Event . . . . . . . . . . . . . . . . . . . . . . . 424.1.3 Event-Based Decision . . . . . . . . . . . . . . . . . . . 444.1.4 Parallel Behaviour . . . . . . . . . . . . . . . . . . . . . 454.1.5 Ad-Hoc Sub-Process . . . . . . . . . . . . . . . . . . . . 474.1.6 Activity Looping . . . . . . . . . . . . . . . . . . . . . . 504.1.7 Exception Handling . . . . . . . . . . . . . . . . . . . . 514.1.8 Transaction Sub Process . . . . . . . . . . . . . . . . . . 524.1.9 Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2 Semantical Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2.1 Multiple Start Events . . . . . . . . . . . . . . . . . . . 564.2.2 OR-join . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2.3 Exception and Compensation Handling . . . . . . . . . 57

4.3 Interesting Themes . . . . . . . . . . . . . . . . . . . . . . . . . 584.3.1 Expression Language . . . . . . . . . . . . . . . . . . . . 584.3.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 58

5 Proof of Concept 615.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.1 Exclusive Decision and Termination . . . . . . . . . . . 635.2.2 Wait for Event . . . . . . . . . . . . . . . . . . . . . . . 665.2.3 Deferred Choice . . . . . . . . . . . . . . . . . . . . . . 685.2.4 Link Events . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6 Reducible OR-joins 756.1 Problem Statement and Approach . . . . . . . . . . . . . . . . 756.2 Preliminaries: EWF-nets and R-nets . . . . . . . . . . . . . . . 77

6.2.1 EWF-nets . . . . . . . . . . . . . . . . . . . . . . . . . . 776.2.2 Valid EWF-nets . . . . . . . . . . . . . . . . . . . . . . 786.2.3 R-nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.2.4 Graphical Notation for Pattern Matching over R-nets . 80

6.3 Basic and Reduction Patterns . . . . . . . . . . . . . . . . . . . 856.4 Reduction Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.4.1 REDUCE-OR-OR . . . . . . . . . . . . . . . . . . . . . 896.4.2 REDUCE-XOR-OR . . . . . . . . . . . . . . . . . . . . 906.4.3 REDUCE-AND-OR . . . . . . . . . . . . . . . . . . . . 91

6.5 Auxiliary Patterns . . . . . . . . . . . . . . . . . . . . . . . . . 926.6 Auxiliary Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.6.1 AUX-INSERT-OR-SPLIT . . . . . . . . . . . . . . . . . 946.6.2 AUX-INSERT-JOIN . . . . . . . . . . . . . . . . . . . . 956.6.3 AUX-NO-OR-FOLD and AUX-LUCKY-FOLD . . . . . 97

6.7 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.8 Possible Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 102

6.8.1 Generic BASIC-XOR-OR and REDUCE-XOR-OR . . . 1026.8.2 Generic BASIC-AND-OR and REDUCE-AND-OR . . . 106

6.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Contents vii

7 Conclusions and Recommendations 1117.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . 113

A Protos in a Nutshell 115A.1 Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115A.2 Statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115A.3 Activities and Sub-Processes . . . . . . . . . . . . . . . . . . . 116A.4 Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118A.5 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118A.6 Documents and Data . . . . . . . . . . . . . . . . . . . . . . . . 119A.7 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120A.8 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120A.9 Protos Process Modeler . . . . . . . . . . . . . . . . . . . . . . 121

B BPMN in a Nutshell 123B.1 Flow Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

B.1.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123B.1.2 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 124B.1.3 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 125

B.2 Swimlanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126B.3 Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127B.4 Connecting Objects . . . . . . . . . . . . . . . . . . . . . . . . 128B.5 Example Business Process . . . . . . . . . . . . . . . . . . . . . 129

C Tools Evaluation Results 131C.1 Results per Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 131C.2 Overview of the Results . . . . . . . . . . . . . . . . . . . . . . 155C.3 Tools Ranking . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

D Detailed Mappings from Protos to BPMN 161D.1 Process Model Mappings . . . . . . . . . . . . . . . . . . . . . . 161D.2 Main Process Mappings . . . . . . . . . . . . . . . . . . . . . . 163D.3 Trigger Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 164D.4 Activity and Sub-Process Mappings . . . . . . . . . . . . . . . 165D.5 Status Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 169D.6 Connection and Trigger Connection Mappings . . . . . . . . . . 170

E Detailed Mapping from BPMN to Protos 173E.1 Business Process Diagram Mappings . . . . . . . . . . . . . . . 173E.2 Process Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 174E.3 Common Graphical Object Mappings . . . . . . . . . . . . . . 175E.4 Common Flow Object Mappings . . . . . . . . . . . . . . . . . 176E.5 Event Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 176E.6 Activity Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 179E.7 Gateway Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 182E.8 Swimlane Mappings . . . . . . . . . . . . . . . . . . . . . . . . 185E.9 Artifact Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 186E.10 Connecting Object Mappings . . . . . . . . . . . . . . . . . . . 188

viii Contents

F Example Reducible OR-joins 191

Bibliography 205

List of Acronyms

Business Process Diagram (BPD)

A BPD displays a business process in BPMN.

Business Process Definition Metamodel (BPDM)

BPDM is an XML-based metamodel proposal for business processes beingdeveloped by the OMG.

Business Process Execution Language for Web Services (BPEL4WS)

BPEL4WS is an XML-based executable modelling language for businessprocesses.

Business Process Management (BPM)

BPM is a field of knowledge that includes methods, techniques, and toolsto support the design, enactment, management, and analysis of opera-tional business processes.

Business Process Management Initiative (BPMI)

BPMI developed a number of standards and merged in 1995 with theOMG.

Business Process Modeling Notation (BPMN)

BPMN is a standardised graphical notation adopted by the OMG fordrawing business processes.

Event-driven Process Chains (EPCs)

EPC is a business process modelling language for the representation oftemporal and logical dependencies of activities in a business process.

Object Management Group (OMG)

The OMG is a consortium that developed several standards, includingCORBA, UML, and BPMN.

Process Analysing Language (PAL)

PAL is the proprietary file format of Protos.

ix

x List of Acronyms

Unified Modeling Language (UML)

UML is a standardised specification language adopted by the OMG forobject modelling.

Workflow Management Coalition (WfMC)

The Workflow Management Coalition was founded in 1993 to create andcontribute to process related standards.

Extensible Markup Language (XML)

XML is a general-purpose markup language, which facilitates the sharingof data across different information systems.

XML Process Definition Language (XPDL)

XPDL is an XML-based format standardised by the WfMC to store andinterchange business process definitions across different workflow prod-ucts.

Extensible Stylesheet Language (XSL)

XSL is an XML-based stylesheet language consisting of XSLT, XPath,and XSL-FO.

XSL-Formatting Objects (XSL-FO)

XSL-FO is a language for formatting XML documents.

XSL Transformations (XSLT)

XSTL is a language for transforming XML documents.

Yet Another Workflow Language (YAWL)

YAWL is a workflow language that uses Petri nets extended with con-structs to address multiple instances, advanced synchronisation, and can-cellation patterns, as a starting point.

Chapter 1

Introduction

Business Process Management (BPM) has become an omnipresent and wide-spread field of knowledge affecting various businesses. BPM is concerned with‘supporting business processes using methods, techniques, and software to de-sign, enact, control, and analyse operational processes involving humans, or-ganisations, applications, documents and other sources of information’ [12].For numerous businesses, it is impossible to imagine life today without BPM.

The thesis at hand is the result of a Master project conducted at Pallas Athena1

in Apeldoorn. Pallas Athena develops and implements software for businessprocess modelling, workflow management, and case handling.2 In addition, itprovides training and consultancy. The three main products of Pallas Athenaare Protos, Protos Activate, and FLOWer, which will converge into a completeBPM Suite in the near future. Protos is a business process modelling prod-uct specialised in modelling, documenting, interchanging, and communicatingthe work processes in businesses. FLOWer is a case handling solution [5] forcontrolling and managing complex business processes. Protos Activate assistsin creating a complete workflow system by activating process models that aredeveloped with the help of Protos.

1.1 Problem Statement

Over the last few years, the BPMN specification [26] has become a standardgraphical notation for capturing business processes. Pallas Athena would liketo explore the possibilities of BPMN. Consequently, three research questionswere formulated:

1. What is the state-of-the-art with respect to BPMN, i.e., how is the spec-ification defined and what kind of tool support is available?

2. Can Protos be mapped onto BPMN?3. Can BPMN be mapped onto Protos?

1http://www.pallas-athena.com/2‘Unlike workflow management, which uses predefined process control structures to de-

termine what should be done during a workflow process, case handling focuses on what canbe done to achieve a business goal’ [5].

1

http://www.pallas-athena.com/

2 CHAPTER 1. INTRODUCTION

In answering these research questions, several semantical issues arose. In partic-ular, the so-called OR-join has problems with respect to semantics, implemen-tation, and performance. As a result, a fourth research question was defined:

4. Is it possible to remove OR-joins?

1.2 Approach and Outline

Chapter 2 contains a critical analysis and an extensive tools evaluation in orderto assess the state-of-the-art with respect to the BPMN specification. Chapters3 and 4 present mappings from Protos to BPMN and back. A proof-of-conceptimplementation is presented in Chapter 5, so as to demonstrate the feasibilityand viability of these mappings.

A contribution to the troublesome semantics for OR-joins is made in Chapter6 by presenting a pattern-matching approach that takes the structure of aprocess model as a starting point for removing OR-joins without changing thebehaviour. This approach is applicable to a wide range of process models inall kinds of languages and notations, including Protos, BPMN, EPCs, YAWL,etc [26, 11, 27].

Finally, in concluding the thesis at hand, Chapter 7 comes up with summarisingconclusions along with a number of recommendations.

Chapter 2

BPMN Evaluation

Over the last few years, the Business Process Modeling Notation (BPMN) spec-ification has emerged as a standard notation for capturing business processes,especially in the early stages of system development. The specification wasdeveloped by the Business Process Management Initiative (BPMI)1 and thefirst version was released in May 2004. Stephen A. White of the IBM Corpo-ration is the author of the first specification and several members of the BPMINotation Working Group contributed to its development [26, pp.6–7]. Thespecification is currently being maintained by the Object Management Group(OMG)2, since their merger in June 2005. The OMG Final Adopted BPMN1.0 Specification [26] was published in February 2006.

In order to rate the BPMN specification at its true value, a critical analysis ofthe specification has been conducted, supplemented with an extensive evalua-tion of tools from vendors in the BPM marketplace that claim to support thespecification to a considerable extent.

2.1 Critical Analysis

The critical analysis covers various aspects of the BPMN specification. Read-ers not familiar with BPMN can find a brief introduction to this notation inAppendix B. Firstly, a definition of the scope is presented. Secondly, a numberof related standards are discussed. Thirdly, the lack of formal semantics isdiscussed. Finally, an assessment of the specification from an ontological pointof view is presented.

2.1.1 Scope

The primary goal of the BPMN specification is to provide a standard modellingnotation for business processes that is readily recognisable and comprehensibleby, and interchangeable across all business stakeholders, including business an-

1http://www.bpmi.org/2http://www.omg.org/

3

http://www.bpmi.org/

http://www.omg.org/

4 CHAPTER 2. BPMN EVALUATION

alysts, technical developers and business managers. BPMN was also developedto provide a business-oriented notation to visualise various XML languages pri-marily designed and optimised for the execution of business processes, such asthe Business Process Execution Language for Web Services (BPEL4WS) [6].BPMN intends to complement for the lack of a human level of inter-operabilityand portability in those languages and to bridge the gap between the businessprocess design and process implementation [26].

According to the specification, BPMN confines itself to the support of mod-elling concepts that are applicable to business processes. Any other type ofmodelling by organisations for business purposes would be beyond the scopeof BPMN. For instance, the modelling of organisational structures, resources,functional breakdowns, data, strategy, and business rules would not be a partof BPMN. However, the presence of the concepts Pool and Lane for represent-ing participants and roles, and the presence of the concepts Message Flow,Data Object, and Association for representing the flow of data and associatingdata to activities, suggests a contradiction with the original goals. It is obvi-ous though that these concepts do not provide a means for representing thesubtleties associated with the modelling of data, organisational structures, andresources [29].

2.1.2 Related Specifications

The BPEL4WS specification [6] defines an XML-based executable modellinglanguage for business processes. The influence of BPEL4WS on the BPMNspecification is striking. Chapter 11 and 12, and Annex A are completely de-voted to a mapping from BPMN to BPEL4WS. Moreover, several attributes inthe BPMN specifications originate from attributes in BPEL4WS. For example,the boolean attributes SuppressJoinFailure and EnableInstance-Compensationare added to a Process in order to indicate whether join failures should be sup-pressed and compensation can be performed after the process has completednormally.

The BPMN Finalisation Task Force within the OMG has had an ongoing dis-cussion about whether BPEL4WS should be a normative part of the BPMNspecification.3 Some argue that it might be better to include this mapping inits entirety in an appendix, because the translation could be different depend-ing on the particular implementation of BPEL4WS. Anyway, it is safe to saythat a mapping from BPMN to BPEL4WS is nontrivial, because BPMN lacksa formal foundation (as discussed in the remainder), has several known openissues, and an expressive power that differs from BPEL4WS.

The XML Process Definition Language (XPDL) specification [18] is an XML-based format standardised by the Workflow Management Coalition (WfMC)4

for storing and interchanging business process definitions across different work-flow products. The initial version of this specification was lacking a specificgraphical representation. However, the second version was expanded to sup-

3Issues for the mailing list of the BPMN Finalisation Task Force are available at:http://www.omg.org/issues/bpmn-ftf.html

4http://www.wfmc.org/

http://www.wfmc.org/

2.1. CRITICAL ANALYSIS 5

port specific mechanisms that allow round-trip development from BPMN toXPDL and back to BPMN to a considerable extent. This clearly shows thatthe WfMC is pushing this standard to become the main file format for BPMN,but that matter is still undecided.

In [14, 20], the concept of a ‘BPMN-XPDL-BPEL value chain’ is discussed.5

Metaphorically speaking, this value chain starts by drawing a BPMN diagram,then saving the partial diagram as XPDL during development, and ultimatelytranslating to BPEL4WS parts of the process focussed on data exchange. Inaddition to this, Keith Swenson from the WfMC claims that: ‘Many peopletoday automatically assume that BPEL and XPDL are direct competitors.This is not at all true. BPEL and XPDL are entirely different things forentirely different purposes’ [20]. He argues that BPEL4WS is an executionlanguage – a programming language with variables and and operations – thathas no concepts to support the graphical representation of a diagram, whileXPDL is a process design format – a file format – that represents the drawingof process definitions. Be that as it may, BPEL and XPDL are competing withone another in the marketplace.

The Business Process Definition Metamodel (BPDM) specification is an XML-based metamodel proposal for business processes being developed by the OMG.This metamodel aims, amongst others, at unifying the diverse graphical andtextual notations for business processes definitions that exist in the industryand providing the ability to interchange business process specifications acrossworkflow products. The former indicates that the OMG would like the BPDMspecification to become the metamodel for their own BPMN specification. Thelatter seems to imply that it is the ambition of the OMG to render unnecessarythe XPDL specification of the WfMC.

The Unified Modeling Language (UML) is a standardised specification languageadopted by the OMG for object modelling. UML offers several notations forcapturing different aspects of software structure and behaviour. One of thesenotations, namely Activity Diagrams, is intended for modelling computationaland business processes. In [25], Stephen White, the author of initial version ofBPMN, shows that several workflow patterns [16] can similarly be representedin UML 2.0 Activity Diagrams as in BPMN Business Process Diagrams. Amore detailed pattern-based analysis of UML Activity Diagrams is presentedin [28].

2.1.3 Lack of a Formal Foundation

Any notation for business process models benefits from a formal foundation.Formal models do not leave any scope for ambiguity, increase the potential foranalysis, and can be understood by the various stakeholders involved. Businessprocess models can be rather complex and the use of a formal language for theirspecification is the only way to guarantee that alternative interpretations areruled out [3].

5This concept was first credited to an analyst called Sandy Kemsley by Keith Swensonfrom the WfMC.


The BPMN specification lacks a formal foundation as well as a file formatto store the diagrams. The informal semantics of a Business Process Dia-gram (BPD) are contained in the graphical notation and numerous attributes.Consequently, different stakeholders might assign different meanings to thesame process model, especially to sophisticated design features like intermedi-ate events, transaction compensation, and collaborating processes synchronisedthrough messages [19].

It appears that the developers within the OMG are in disagreement about theultimate purpose for BPMN. Some might be satisfied with just a diagram no-tations, while others want to make BPMN a standard notation with a rich andprecise semantics for executable process design. From another point of view, itseems like one is trying to have it both ways: have easily understood executionsemantics and, at the same time, giving the business modeler complete freedomof action [19].

Recently, some attempts are made to attach a formal semantics to BPMN. In[7], a formal semantics of a subset of BPMN defined in terms of a mapping toPetri nets has been proposed, with the purpose of being able to statically checkthe semantic correctness of process models. One of the constructs left aside inthis formalisation is the Inclusive Gateway, which is also known as the OR-join.In [8], an additional proposal is presented for a formalisation of the enablementrules for a subset of BPMN objects, including the Inclusive Gateway. All inall, it is reasonable to conclude that a complete formalisation for BPMN willtake some time (if at all possible).

2.1.4 Ontological Analysis

In [15] the BPMN standard is evaluated from the viewpoint of the Bunge Wandand Weber (BWW) ontology [21, 22, 23]. This ontology was developed to helpdefine and build information systems that contain the necessary representa-tions of real world concepts. In general, ‘ontology studies the nature of theworld and attempts to organise and describe what exists in reality, in termsof the properties of, the structure of, and the interactions between real-worldthings’ [17]. The evaluation based on the BWW ontology aims at identify-ing ontological shortcomings and gaining further insights in the suitability ofBPMN as a standard for Business Process Modelling. Based on the findingsfrom the ontological analysis the authors made a number of propositions withrespect to ontological completeness, construct excess, construct overload, andconstruct redundancy. Although the authors hold strong views, their resultsshould be seen as possible indications rather than evidence for shortcomings ofBPMN.

Ontological completeness is about whether all real-world concepts identified bythe BWW ontology can be modelled in BPMN. The lack of a representation fora construct in BPMN might incite users to make inappropriate use of existingconstructs or adopt constructs from other modelling languages and notations.The authors conclude that BPMN lacks a representation for states, history,and system structure. The lack of a state representation might cause users tobe unable to determine which states can be expected to occur, and which states

2.1. CRITICAL ANALYSIS 7

can occur but should not be allowed to. Since BPMN has no notion of history,for example with the help of state change logging, problems with respect torecovery and reliability of interacting entities might be expected. The authorsstate that the lack of a representation for system structure reveals itself in thefact that there is no thorough demarcation of the system and the things withinthe system, which harms the understandability of Pools and Lanes in BPMNmodels.

The construct excess perspective uncovers BPMN constructs that have no real-world meaning. Users might wonder what purpose these construct were in-tended to serve. The authors point at several super types in BPMN, such asEvent and Gateway, which are further specified in the specification and aretherefore redundant according to the BWW ontology. Furthermore, the fol-lowing BPMN constructs seem to have no real-world meaning according tothe BWW ontology: Link, Off-Page Connector, Association Flow, Text Anno-tation, Group, Standard Loop Activity, Multiple Instances Activity, NormalFlow, and the various Gateway types.

Construct overload deals with BPMN constructs to which more than one con-struct in the BWW ontology has been mapped. The authors state that thePool and Lane constructs in BPMN map to several BWW constructs, includingThing and System. Consequently, users might need additional knowledge thatis not contained in the model in order to fully understand which real-worldconcept is being modelled. For instance, it might be unclear whether a Lane isused to represent an organisational entry, an application system, or anythingelse.

Construct Redundancy is about ontological constructs to which more than oneBPMN construct can be mapped. This is unwished-for, because it makes usersuncertain about the construct that should be used to represent a particularreal-world concept. The authors state that a Thing can be represented by aPool as well as a Lane. For example, users might wonder whether it best to usea Pool or a Lane to represent an organisational department. Similar confusioncould be caused by a Transformation and an Event. The authors argue thatthe former could amongst others be mapped to a Task, a Sub Process, and aTransaction, while the latter one could be mapped to the BPMN constructsStart Event, Intermediate Event, and End Event which come in various types,like Message, Timer, Error, etc. However, one might argue that although thegraphical appearance of the various Activities and Events in BPMN are quitesimilar, a clear semantical distinction can be stated in terms of their use.

As discussed before, it is often claimed that BPMN is directly translatableinto BPEL4WS specifications. The authors argue that this claim can onlybe supported to a certain extent from an ontological point of view, becauseBPEL4WS lacks ontological expressiveness compared to BPMN. Especially thedemarcation of a system from its environment and the decomposition of a sys-tem into subsystems might not be unambiguously translatable into executableBPEL4WS specifications without some additional modelling and specificationefforts.

In conclusion, the ontological evaluation of BPMN provides a number of pos-sible indications for shortcomings of BPMN. However, evaluating BPMN from


an ontological point of view has known limitations. For example, since theBWW ontology cannot tell the difference between an Explicit Choice workflowpattern [16] (see Section 3.1.4 on page 24) and a Deferred Choice workflowpattern [16] (see Section 3.1.5 on page 27), it would be considered constructredundancy.

2.2 Tools Evaluation

In December 2006 an evaluation of business process modelling tools has beenperformed with respect to conformance to the BPMN standard. This sectionelaborates on the tools evaluation by explaining the approach, discussing sev-eral evaluation results, and finally drawing some conclusions.

Many commercial and open-source tools that fully or partly implement theBPMN standard are currently on the market. The list of current and plannedimplementers of the BPMN standard published on the website of the ObjectManagement Group (OMG) is used as a starting point6. The tools evaluationis based on twenty-three tools that are available on the Internet as either anevaluation copy or an unrestricted copy, with the exception of IndustryPrintProcess Modeler of Deloitte, which is developed for internal use.

The tools evaluation serves multiple goals. Firstly, it gives an impression of theextent to which the BPMN standard is taken seriously by vendors in the mar-ketplace. Secondly, it reveals strengths and weaknesses of the BPMN standardin the way vendors implement the standard. Finally, the tools evaluation helpsto select an appropriate tool for the proof of concept presented in Chapter 5 ofthe mappings between Protos and BPMN. Note that the tools are merely eval-uated on their support for the BPMN standard and that the evaluation shouldtherefore not be interpreted as an assessment of the complete functionality ofthese tools.

An overview of the evaluated tools and several aggregated evaluation resultswill be presented in the remainder. Readers interested in screen captures,succinct descriptions, and more detailed evaluation results per tool are directedto Appendix C.

2.2.1 Tools Overview

Table 2.1 presents an overview of the twenty-three evaluated tools. The firsttwo columns show the name of a tool and the company it belongs to. The thirdcolumn indicates the way a tool provides support for the BPMN standard. Themajority of the tools provides a modelling environment in which BPMN supportis embedded. For the remaining tools: two of them provide support for theBPMN standard using an add-in for such a modelling environment, three ofthem are stand-alone and purpose-made for BPMN modelling, and the othertwo tools are add-ins for Microsoft Office Visio.

6http://www.bpmn.org/BPMN Supporters.htm

http://www.bpmn.org/BPMN_Supporters.htm

2.2. TOOLS EVALUATION 9

Free- FileTool Company Form ware FormatActiveModelerAvantage 1.0

Kaisha-Tec Stand-alone Yes XML

AG AENEIS 5 Intellior Embedded No XMLAquaLogic BPMDesigner 5.7

BEA Embedded No XML

BPMS Designer 4.0 Intalio Embedded Yes OtherBusiness ProcessVisual Architect 2.0

VisualParadigm

Embedded No XML

Business Studio 1.1 TIBCO Embedded Yes XPDLConvergence Studio 1.5 M1 Global Embedded No XMLCorporate Modeler 10 Casewise Add-in No XMLeBPMN Designer 1.0 Soyatec Stand-alone Yes XMLEnterprise Architect 6.5 Sparx Add-in No OtheriGrafx Process 2006 Corel Embedded No OtherIndustryPrint ProcessModeler 4.0

Deloitte Stand-alone No XML

iServer BPMN Stencil1.0.9

OrbusSoftware

Visio add-in Yes XPDL

JViews BPMNModeler 1.0

ILOG Embedded Yes XML

LegaSuite BPM Studio6.0

SeagullSoftware

Embedded No XML

MagicDraw UML 12.0EAP beta

No Magic Embedded No XML

Mega Suite MegaInternational

Embedded No XML

PowerDesigner 12.0 Sybase Embedded No XMLProcess Modeler 4 ITPearls Visio add-in No XPDLProcess Modeler 6.8 Savvion Embedded No XMLSelect Architect 7.0 Select Busi-

ness SolutionsEmbedded No XML

System Architect 10.4 Telelogic Embedded No XMLTogether 2006 Borland Embedded No XML

Table 2.1: Overview of the evaluated tools

The fourth column of Table 2.1 shows whether a tool is freeware or not. It turnsout that six out of the twenty-three tools are freeware: ActiveModeler Avantage1.0 (from Kaisha-Tec), BPMS Designer 4.0 (from Intalio), Business Studio1.1 (from Tibco), eBPMN Designer 1.0 (from Soyatec), iServer BPMN Stencil1.0.9 (from Orbus Software), and JViews BPMN Modeler 1.0 (from ILOG). Therightmost column indicates whether a tool provides a file format for exchanginga BPD across modelling tools. Only the tools Business Studio 1.1, iServerBPMN Stencil 1.0.9, and Process Modeler 4 (from ITPearls) support the XPDL1.0 standard developed by the WfMC. None of the evaluated tools supportsthe second version of this standard, which incorporates several BPMN elements


that were not present in the first version. All other tools use a proprietary fileformat for storing models, thus hindering the exchange of process models acrossmodelling tools. To put this disadvantage into perspective, the proprietaryfile formats of seventeen out of the remaining twenty tools are based uponthe Extensible Markup Language (XML) standard, making the parsing andtransformation easier.

Figure 2.1 aggregates the data in the last three columns of Table 2.1 in termsof percentages using pie charts. It clearly shows that the greater part of theevaluated tools embeds support for the BPMN standard in a larger modellingenvironment that is not freeware and uses a proprietary XML file format tostore models.

(a) Form (b) Freeware

(c) File format

Figure 2.1: Graphical view of the aggregated values for the columns ‘Form’,‘Freeware’, and ‘File Format’ in Table 2.1

2.2.2 BPMN Conformance

The tools evaluation helps to gain a clear insight into the extent to which theevaluated tools are within the conformance rules of the BPMN standard. Itallows a quick comparison of the BPMN conformance across tools with respectto a particular element, a group of related elements, or all elements.

As discussed in Appendix B, BPMN distinguishes between a Core ElementSet that contains only the elements that define the basic look-and-feel and aComplete Element Set that extends the Core Element Set in order to be ableto handle more advanced modelling situations. For instance, the Core ElementSet contains a basic circular shape to represent an Event, while the CompleteElement Set contains circular shapes with a single thin line, a double thin line,or a single thick line to represent a Start Event, an Intermediate Event, or anEnd Event, respectively. Since the Complete Element Set is rather extensive,the tools evaluation subdivides it into four sets that contain various Eventtypes, Activity types, Gateway types, and Connecting Objects. Table 2.2 onthe next page presents all five sets, that is, one for the Core Element Set and

2.2. TOOLS EVALUATION 11

four sets that together cover the Complete Element Set. Note that the elementsin the set of Event types are a combination of a Flow type and a Trigger/Resulttype, e.g., a Message Start Event.

Element Set ElementsCore Element Set Event, Activity, Gateway, Sequence Flow, Message

Flow, Association, Pool, Lane, Data Object, Group,Text Annotation

Event types Flow type: Start Event, Intermediate Event, EndEventTrigger/Result type: Message, Timer, Error, Cancel,Compensation, Rule, Link, Multiple, Terminate

Activity types Collapsed Sub-Process, Expanded Sub-Process,Reference Sub-Process, Independent Sub-Process,Transaction Sub-Process, Ad-Hoc Sub-Process,Compensation Activity, Activity Looping, MultipleInstances Activity

Gateway types Data-Based Exclusive Gateway, Event-BasedExclusive Gateway, Inclusive Gateway, ParallelGateway, Complex Gateway

Connecting Objects Conditional Flow, Default Flow, Exception Flow,Compensation Association

Table 2.2: Element sets used in the tool evaluation

For the benefit of mutual comparison, Table 2.3 on the following page presentsan overview of the extent to which the evaluated tools conform to the BPMNstandard. A conformance percentage for each element set in Table 2.2 is pre-sented. In addition, the rightmost column shows overall scores that are basedon the conformance percentages of the separate element sets. Note that thetools are listed in descending order by their overall scores. Figure 2.2 on page 13graphically shows the construction of the overall scores per tool out of the con-formance percentages for the separate element sets. Readers interested in theunderlying aggregation method or detailed evaluations results per element arereferred to Appendix C.3. Note that Table 2.3 corresponds exactly to TableC.5 in this appendix.

As shown in the rightmost column of Table 2.3, sixteen out of the twenty-three tools conform to the BPMN standard for more than 70%, ten tools formore than 90%, and No Magic MagicDraw UML 12.0 EAP beta and BorlandTogether 2006 provide complete support. Six tools support the Core ElementSet (second column) completely, twelve tools support this element set for morethan 90%, and up to nineteen tools support this set for at least 70%. Notethat any of the ten tools that conforms to the BPMN standard for more than90% also conforms to the Core Element Set for more than 90%.


Tool Cor

eEle

men

tSet

Eve

nt

Types

Act

ivity

Types

Gat

eway

Types

Con

nec

ting

Obje

cts

Ove

rall

Sco

re

MagicDraw UML 12.0 EAP beta 100 100 100 100 100 100Together 2006 100 100 100 100 100 100Business Process Visual Architect 2.0 100 100 100 100 94 99eBPMN Designer 1.0* 91 100 100 100 100 98Enterprise Architect 6.5 93 100 97 95 100 97iServer BPMN Stencil 1.0.9* 100 100 78 100 100 96Select Architect 7.0 95 100 81 100 100 95ActiveModeler Avantage 1.0* 95 94 100 100 81 94Process Modeler 4 100 100 56 100 100 91iGrafx Process 2006 91 89 89 80 100 90JViews BPMN Modeler 1.0* 82 100 67 100 94 88System Architect 10.4 100 86 97 95 50 86AG AENEIS 5 84 88 64 100 63 80PowerDesigner 12.0 82 100 64 100 56 80BPMS Designer 4.0* 77 79 53 80 94 77Corporate Modeler 10 95 100 31 70 75 74Business Studio 1.1* 66 39 78 85 75 69Convergence Studio 1.5 68 46 44 80 69 61IndustryPrint Process Modeler 4.0 73 100 19 60 31 57Mega Suite 73 18 47 35 56 46AquaLogic BPM Designer 5.7 52 53 33 40 19 39Process Modeler 6.8 73 33 22 30 0 32LegaSuite BPM Studio 6.0 45 39 19 25 0 26

Table 2.3: Overview of the BPMN conformance per tool (%). The tools withan asterisk (*) are freeware.7

7Note that this table is based on a thorough evaluation at the end of 2006. The authortried to make a fair comparison, but is not responsible for any errors or misinterpretations.Moreover, the weights of the different parts of the evaluation are rather arbitrary. The onlygoal is to give some insight into the true support of the BPMN standard.

2.2

.T

OO

LS

EVA

LU

AT

ION

13

Figure 2.2: Construction of the overall BPMN conformance scores per tool (%)


Based on the tools evaluation, two tools have been selected for use in thefollowing chapters:

� The tool JViews BPMN Modeler 1.0 (from ILOG) has been selectedfor the proof-of-concept implementation, i.e., the realisation of concretemapping from Protos to BPMN and vice-versa (cf. Chapter 5). Thistool has been chosen because it satisfies three requirements: (i) it has astraightforward XML file format, (ii) it conforms to almost 90% of theBPMN standard, and (iii) it is freeware, thus readily available to anyone.Note that the freeware tools ActiveModeler Avantage 1.0 (from Kaisha-Tec), eBPMN Designer 1.0 (from Soyatec), and iServer BPMN stencil1.0.9 (from Orbus Software), support the BPMN standard to a largerextent. However, the first two tools use a less straightforward file formatand the latter one requires Microsoft Visio to be installed.

� The tool ActiveModeler Avantage 1.0 has been selected to illustrate themappings between Protos and BPMN in the next two chapters, becauseit is freeware and its graphical design is pleasant to the eye. Note that itsless straightforward file format is of no importance for this visual purpose.

2.3 Conclusions

The primary goal of the BPMN specification of the OMG is to provide a stan-dard modelling notation for business processes that is readily recognisable andcomprehensible by all business stakeholders. BPMN provides little or no sup-port for the modelling of organisational structures, resources, functional break-downs, data, strategy, and business rules.

BPEL4WS is an XML-based executable modelling language for business pro-cesses that has a rather large influence on the BPMN specification, becauseChapters 11 and 12, and Annex A are completely devoted to a partial map-ping from BPMN to BPEL4WS. The XPDL specification is an XML-basedformat for storing and interchanging business process definitions across differ-ent workflow products. The alterations to the first version of this specificationindicate that the WfMC is pushing this standard to become the main file formatfor BPMN. Although XPDL and BPEL4WS seem to serve different purposes,these specifications are competing with one another in the marketplace. TheBPDM specification is an XML-based metamodel proposal for business pro-cesses languages and notations such as BPMN. Like BPMN, UML ActivityDiagrams provide a notation for modelling business processes.

Currently, the BPMN specification is subject to multiple interpretations, be-cause it lacks formal semantics. As a consequence, several semantical issuesarose during the development and implementation of a mapping from Protosto BPMN and back (cf. Chapters 3, 4, and 5). For example, some issues withrespect to the semantics of multiple Start Events, exception handling, com-pensation handling, and OR-joins will be discussed in Section 4.2. Since theproblems with respect to the semantics, implementation, and performance ofOR-joins apply to all kinds of other languages and notions, a generic approach

2.3. CONCLUSIONS 15

for removing OR-joins from a process model without changing the behaviouris presented in Chapter 6.

It would seem that the developers within the OMG are in disagreement aboutwhether the ultimate purpose for BPMN should be just a diagram notationor a standard notation with rich and precise semantics for executable processdesign. Although some scientific attempts are made to formalise the semanticsof BPMN, it is reasonable to conclude that a complete formalisation for BPMNwill take some time (if at all possible).

An evaluation based on the BWW ontology suggests a number of ontologicalshortcomings with respect to ontological completeness, construct excess, con-struct overload, and construct redundancy. First of all, BPMN lacks a represen-tation for states, history, and system structure. Furthermore, several objectsappear to have no or more than one real-world meaning. Finally, a mappingfrom BPMN to BPEL4WS is anything but trivial, because BPEL4WS lacksontological expressiveness compared to BPMN.

The tools evaluation has shown that the greater part of the evaluated toolsembeds support for the BPMN standard in a larger modelling environmentthat is not freeware and uses a proprietary XML file format to store models.Sixteen out of the twenty-three tools conform to the BPMN standard for morethan 70%, ten for more than 90%, and No Magic MagicDraw UML 12.0 EAPbeta and Borland Together 2006 provide complete support.

ActiveModeler Avantage 1.0 from Kaisha-Tec will be used to illustrate themapping from Protos to BPMN and vice-versa (cf. Chapters 3 and 4). JViewsBPMN Modeler 1.0 from ILOG will be used for the proof-of-concept imple-mentation of these mappings (cf. Chapter 5).

Chapter 3

Mapping from Protos to BPMN

This chapter presents a mapping from Protos to the BPMN. First variousmappings of characteristic patterns in Protos will be presented, then someassumptions will be presented, and finally a number of interesting themes willbe discussed. Appendix D provides a detailed mapping from object propertiesin Protos to object attributes in BPMN. Readers not familiar with either Protosor BPMN are advised to read Appendices A and B before proceeding with thischapter. All BPMN diagrams in this chapter are created with ActiveModelerAvantage, a freeware BPMN modeler from Kaisha-Tec included in the toolsevaluation in Section 2.2 on page 8.

3.1 Pattern Mappings

The mapping is presented using various patterns in the following sections. Eachsection elaborates on a characteristic modelling pattern in Protos and showshow it can be modelled in BPMN.

The semantics of a Protos model are captured by a graphical representationcomplemented with properties that can be set using properties dialogs. Thesemantics of a BPMN model are captured by a graphical representation com-plemented with attributes. Since various attributes have no graphical repre-sentation in BPMN, Text Annotations are used to show the relevant attributescorresponding to an object.

3.1.1 Sequence

This section presents the mapping of a sequence of Activities in Protos to asequence of Tasks in BPMN. Figure 3.1 on the next page presents a processconsisting of three sequential Activities to (i) register for a course, (ii) followseveral course lessons, and (iii) round of with an exam.

Figure 3.2 shows the General Tab and Description Tab of the properties di-alog corresponding to Activity ‘Register for Course’. The Name property ofthe Activity Object is set on the General Tab to ‘Register for Course’. The

17

18 CHAPTER 3. MAPPING FROM PROTOS TO BPMN

Figure 3.1: Sequence in Protos

Type property is set to ‘Basic’, which is the default Activity type in Protos.Properties Start Sub-Process and Start Process Model are enabled to indicatethat Activity ‘Register for Course’ is instantiated when the Process Model isinstantiated. These last two properties will be discussed in more detail in Sec-tion 3.1.7 on page 29. Finally, the Description property on the DescriptionTab is set to ‘Identification required’ to inform users of the model that it isnecessary to identify oneself in order to register for the course.

(a) General Tab (b) Description Tab

Figure 3.2: Properties dialog of Activity ‘Register for Course’ in Protos

Figures 3.3(a) and 3.3(b) on the next page show the General Tab and Descrip-tion Tab of the properties dialog corresponding to Connection ‘RegistrationCompleted’. The Name and Description property are similar to that of anActivity and the From and To properties on the General Tab identify thesource and target Objects of this Connection. The From and To propertiesare automatically set by Protos upon creation of the Connection to ‘Main Pro-cess.Register for Course’ and ‘Main Process.Follow Course Lessons’. The partbefore the dot indicates that the Connection is contained in a Process called‘Main Process’ and the part after the dot refers to the Name property of theconnected Object, that is, ‘Register for Course’ and ‘Follow Course Lessons’,

3.1. PATTERN MAPPINGS 19

respectively.


Figure 3.3: Properties dialog of Connection ‘Registration Completed’

Figure 3.4 on the following page shows how the sequential Protos process in Fig-ure 3.1 can be modelled in BPMN. An Activity Object in Protos is mapped toa Task Object in BPMN. Connections between Activities in Protos are mappedto Sequence Flows in BPMN. Text Annotations present the attribute valuesof the various BPMN Objects. Tasks and Sequence Flows have attributes ‘Id’,‘Name’, and ‘Documentation’ in common. The ‘Id’ attribute represents anObject identifier which corresponds to a Protos identifier which is not visibleand automatically set by Protos1. The ‘Name’ attribute is similar to the Nameproperty in Protos. For example, both the Name property of the first Pro-tos Activity in Figure 3.2(a) and the Name attribute in the Text Annotationattached to the first Task in Figure 3.4 are set to ‘Register for Course’. TheDescription property in Protos, see Figure 3.2(b), corresponds to the Docu-mentation attribute in BPMN, see again the Text Annotation attached to thefirst Task in Figure 3.4.

Figure 3.4 shows that the ActivityType attribute for a Task is set to ‘Task’to distinguish it from a Sub-Process. The TaskType attributes of the threeTasks is set to ‘None’, which means that the type of the task is left open. Sincethis is the default type for a Task, it is an appropriate mapping for the BasicActivity type in Protos, see Figure 3.2(a). The Source and Target attributesshown in the Text Annotation attached to the Sequence Flow between the leftand middle Task in Figure 3.4 refer to the ‘Id’ attributes of those Tasks andcorrespond to the From and To properties of the Protos Connection as shownin Figure 3.3(a).

1Protos hides object identifiers in an underlying database and in its proprietary PAL fileformat.


Figure 3.4: Sequence in BPMN

3.1.2 Parallel Behaviour

This section presents the mapping of parallel Activities in Protos to parallelTasks in BPMN. Figure 3.5 presents a process consisting of five Activities inwhich one registers at a driving school, then follows practical lessons and theorylessons rounded of with a theory exam in parallel, and finally takes a practicalexam when one has completed all lessons and passed the theory exam.

Figure 3.5: Parallel Behaviour in Protos

The properties for the Activities and Connections in Figure 3.5 are similar tothose in the previous section. Since the purpose of this process is to illustratethe representation of parallel behaviour in Protos and BPMN, the uncondi-tional outgoing connections of Activity ‘Register at Driving School’ and theincoming connections of Activity ‘Pass Practical Exam’ are of particular inter-est. The default semantics of an Activity with multiple unconditional outgoingconnections in Protos are that all these connections are enabled when the Ac-tivity completes. On the other hand, the default semantics of an Activity withmultiple incoming connections are that the Activity will only start when allincoming connection are enabled, that is, the incoming connections are syn-chronised. In other words, one is allowed to take theory and driving lessonswhen the registration is completed and the practical exam may only be taken


when one passed the theory exam and took sufficient driving lessons.

A Parallel Gateway in BPMN is used to branch and synchronise parallel Se-quence Flows. Figure 3.6 shows a mapping for the Protos process in Figure 3.5.Activities and Connections are similarly mapped to Tasks and Sequence Flowsas in the previous section. However, the parallel behaviour is captured by twoParallel Gateways. The Text Annotations attached to these Gateways showthat a Gateway has attributes ‘Id’, ‘Name’, and ‘Documentation’ in commonwith Activities and Sequence Flows. Since the Gateways do not directly cor-respond to any Protos Object in Figure 3.6, the identifier and name attributesare fresh. In this example, the Documentation attributes are used to informusers about the start and end of parallel flow.

Figure 3.6: Parallel behaviour in BPMN (variant 1)

The GatewayType attributes of both Gateways are set to ‘AND’ to indicateparallel behaviour. A plus marker within the diamond of such a Gateway isthe visual counterpart for this attribute. Parallel Gateways have an Outgo-ingSequenceFlow attribute for each outgoing Sequence Flow, which refers tothe identifier of that outgoing Sequence Flow. These Sequence Flows shouldbe unconditional, which is why the ConditionType attribute is set to ‘None’ inthis example. As shown in Figure 3.6, the left Gateway refers to the identifiersof the two outgoing Sequence Flows, i.e., ‘seqDriving’ and ‘seqTheory’, and theright Gateway refers to the Sequence Flow with identifier ‘seqPracExam’.

Figure 3.7 on the next page presents an alternative mapping for the Protosmodel in Figure 3.5, which differs from the mapping in Figure 3.6 by the absenceof the left Parallel Gateway. These mappings are behaviourally equivalent,because an Activity with multiple unconditional outgoing Sequence Flow alsorepresents parallel flow. Note that the removal of the right Parallel Gatewaychanges the semantics, see Section 3.1.4 on page 24.


Figure 3.7: Parallel behaviour in BPMN (variant 2)

3.1.3 Wait for Event

It is common in Protos to model a situation in which the progress of the processdepends on the occurrence of an event. Figure 3.8 presents a process in whichone requests certain information, then waits for the information to arrive, andfinally processes that information. Activity Objects ‘Request Information’ and‘Process Information’ request and process the information, respectively. StatusObject ‘Wait for Information’ models the moment of rest between requestingand receiving the information. Mail Trigger Object ‘Information Received’models the arrival of the information. Since the Trigger Connection and theConnection originating from the Status Object both target at Activity ‘ProcessInformation’, synchronisation takes place which sees to it that one can onlyprocess the information when the information has arrived.

Figure 3.8: Wait for event in Protos

The properties of the Activities and Connections are similar to the propertiesshown in Figures 3.2 and 3.3 on page 19. Figure 3.9 on the facing page showsthe General Tabs of the Status Object and the Trigger Object in Figure 3.8.Both tabs contain a Name property, which is set to ‘Wait for Information’ and‘Information Received’, respectively. The Type property on the General Tab ofthe Trigger is set to ‘Mail’ to indicate that the requested information will arriveby mail. The Waiting Period property is not set since it is not relevant for aMail Trigger. Finally, the Cyclic property, which indicates that the occurrenceof the trigger may occur in consecutive cycles, is not enabled, because it isassumed that the information will arrive in one piece and only once. TheDescription Tabs for the Status Object and Trigger Object are similar to theDescription Tab of an Activity or Connection, see for example Figure 3.3(a)on page 19.

Figure 3.10 on the facing page presents a mapping for the model in Figure 3.8.The attributes of both Tasks are similar to those of the Tasks in Section 3.1.1on page 17. Since BPMN has no notion of states, the Status Object ‘Wait for


(a) Status General Tab (b) Trigger General Tab

Figure 3.9: Properties dialogs of Status ‘Wait for Information’ and Trigger‘Information Received’

Information’ is implicitly mapped to BPMN. Mail Trigger Object ‘InformationReceived’ is mapped to a Message Intermediate Event between Activities ‘Re-quest Information’ and ‘Process Information’. When an Intermediate Event isused in such a way in BPMN, it means that the occurrence of an Event, inthis case a message containing the requested information, is required for theprocess to make progress.2 So, the Intermediate Event appropriately maps thesemantics of the Status Object and Trigger Object in Figure 3.8 with this dif-ference that the state in which one is waiting for information is not explicitlymodelled.

Figure 3.10: Wait for event in BPMN

The Text Annotations in Figure 3.10 show that an Intermediate Event has at-tributes ‘Id’, ‘Name’, and ‘Documentation’ in common with Activities, Gate-ways, and Sequence Flows. The Name attribute corresponds to the Name

2Note that the BPMN specification is unclear about whether such an Intermediate Eventcould occur before the preceding Activity has finished. However, in this case it would bepeculiar if the information could be received before the request is sent.


property of the Trigger Object, i.e., ‘Information Received’. The Documenta-tion attribute is used to inform users that the process waits for information toarrive before it makes progress. The EventType attribute indicates that it isan Intermediate Event instead of a Start Event or an End Event. The Triggerattribute is set to ‘Message’ to model that the process waits for a message tooccur.

3.1.4 Exclusive Choice

A exclusive choice can amongst others be modelled in Protos using an Activity.Figure 3.11 presents a process in which one chooses a means of transport, thatis, either by car or by public transport, then travels to a specific destination,and finally pays a visit.

Figure 3.11: Exclusive choice in Protos

The exclusive choice to travel by car or by public transport is modelled by set-ting the Outgoing Connections property of Activity ‘Choose Means of Trans-port’ to ‘xor split’, as shown in Figure 3.12 on the next page. The labels ‘car’and ‘public transport’ are added to the outgoing Connections for readabilitypurposes, because the Outgoing Connections property has no graphical ap-pearance. Note that the decision to travel by car or by public transport is notmodelled using a Status after Activity ‘Choose Means of Transport’, becausethe decision would then depend on the occurrence of some events, as will beexplained in the next section.

Status ‘Arrived at Destination’ in Figure 3.11 models the state in which onehas arrived at the destination. The two exclusive incoming Connections aremerged using this state. These Connections could also be merged at Activity‘Pay a Visit’ by setting the Incoming Connections property of this Activityto ‘xor join’, similar to the Outgoing Connections property discussed above.Unfortunately, the properties Incoming Connections and Outgoing Connectionsare only available for Activities in Protos. Moreover, these properties have nographical representation, which hampers the readability of a Proces Model.Therefore, it is preferred to use a Status, because it explicitly shows that theConnections are merged.

Figure 3.13 on page 26 presents a mapping for the Protos model in Figure 3.11.In this mapping a Data-Based Exclusive Gateway, indicated by diamond with


Figure 3.12: Outgoing Connections properties of Activity ‘Choose Means ofTransport’ is set to ‘xor split’

a cross marker, is used to model the exclusive choice and to merge exclu-sive Sequence Flows. The difference in behaviour with a Parallel Gateway, asdiscussed in Section 3.1.1 on page 17, is captured by a number of attributesthat are shown in the Text Annotations attached to the Gateways. Attributes‘GatewayType’ and ‘XORType’ are set to ‘XOR’ and ‘Data’, respectively, toindicate that the Gateway has exclusive behaviour which is based on data.That is, the exclusive choice to travel by Car or by Public Transport, modelledby the top Gateway in Figure 3.13, is based on the value of some data insteadof the occurrence of a particular event. These attributes are the same for thebottom Gateway. Note that the XORType attribute is superfluous, because nochoice based has to be taken.

Attribute ‘MarkerVisible’ is set to ‘True’ to show the optional cross markerof both Gateways. An Exclusive Data-Based Gateway has a ‘Gate’ attributefor each outgoing Sequence Flow. These attributes refer among others to cor-responding Sequence Flows. For example, the ‘Gate’ attributes of the topGateway in Figure 3.13 on the next page, refer to outgoing Sequence Flowswith identifiers ‘seqCar’ and ‘seqPublicTransport’. These Sequences Flows areconditional, which is modelled by setting the ConditionType attribute to ‘Ex-pression’ and the ConditionExpression attribute to the some expression. Thisreveals a difficult problem in the mapping, because expressions should complyto a particular expression language. BPMN contains an ExpressionLanguageattribute that allows modelers to specify an expression language for a BPD. Amapping from a Protos model to a BPD with the same expression language israther straightforward, but a tricky translation between expressions is requiredotherwise.

Figure 3.14 on the following page presents an alternative mapping for the Protosmodel in Figure 3.11 on the preceding page. Task ‘Choose Means of Transport’


Figure 3.13: Exclusive choice in BPMN (variant 1)

uses two outgoing Conditional Sequence Flows to model the exclusive choice.Moreover, Task ‘Pay a Visit’ effectively merges the two incoming SequenceFlows, since each ‘token’ that arrives on an incoming Sequence Flow createsa new instance of this Task. Note that both the outgoing Sequence Flows ofTask ‘Choose Means of Transport’ and those of the top Gateway in Figure3.13 are conditional, but that the diamond marker should not be present whenattached to an Exclusive Gateway. The Text Annotations attached to theConditional Sequence Flow to Task ‘Travel by Public Transport’ indicates thatall attributes are the same as in Figure 3.13. Thus, both mappings have thesame problems w.r.t. the translation between expressions.

Figure 3.14: Exclusive choice in BPMN (variant 2)


3.1.5 Deferred Choice

A Deferred Choice workflow pattern [16] postpones the moment of choice ina process until some event occurs. Figure 3.15 presents a process in whichone requests information from a customer, then either processes the informa-tion when it is received within a single week, or quits the information requestotherwise. The choice to either perform Activity ‘Quit Information Request’or Task ‘Process Information’ is an example of a deferred choice, because thechoice is postponed until either the event modelled by Time Trigger Object‘Wait One Week’ or Message Trigger Object ‘Information Required’ occurs.In other words, the state modelled by Status Object ‘Wait for Information’ isonly left when one of these events occurs, because the incoming Connections ofActivities ‘Process Information’ and ‘Quit Information Request’ are synchro-nised. Note that this is the default join behaviour of an Activity, which can bealtered using the Incoming Connections property, as discussed in the previoussection.

Figure 3.15: Deferred choice in Protos

An Event-Based Exclusive Gateway – indicated by a solid black star inside acircle with a double line – in combination with Intermediate Events is used inBPMN to model a deferred choice. Figure 3.16 on the next page presents amapping for the model in Figure 3.15. The Timer and Message IntermediateEvents model the waiting period until one week has passed or information hasarrived. Exactly one path that starts from the Exclusive Event-Based Gatewaywill be taken based on which event occurs first.

The Text Annotation attached to the Event-Based Exclusive Gateway showsthat the attributes are similar to the ones for a Data-Based Exclusive Gateway,see for example Figure 3.13 on the facing page. The difference is that theXORType attribute is set to ‘Event’. Furthermore, outgoing Sequence Flowsof an Event-Based Exclusive Gateway should be unconditional, which is whythe ConditionType attributes for these Sequence Flows is set to ‘None’.

Note that the EventType attributes for the Intermediate Events are set to‘Intermediate’ to distinguish them from a Start or End Event and that theTrigger attributes are set to ‘Mail’ and ‘Timer’, respectively, to indicate thecauses for the events.


Figure 3.16: Deferred choice in BPMN

3.1.6 Deadline Monitoring

Figure 3.17 presents a process in which one requests information from a cus-tomer and processes that information when it arrives. One reminds the cus-tomer by phone about the information request when the information is notreceived within one week. Moreover, one quits the information request whenthe information is still not received three days after the reminder by phone.This process differs from the process in the previous section by reminding thecustomer by phone followed by a waiting period of three more days.

Figure 3.17: Deadline monitoring in Protos

Figure 3.18 on the facing page presents a mapping for the Protos model in Fig-ure 3.17. Since the process is an extension to the one presented in the previoussection, only the differences are discussed. A second Event-Based Gateway,which attributes are similarly mapped to the first one, is added to model theadditional waiting period of three days. Again, the outgoing connections areunconditional and target at Intermediate Events of type Message and Timer.Note that Trigger ‘Information Received’ in Figure 3.17 is mapped to two In-termediate Events in Figure 3.18, because an Intermediate Event is not allowedto have more than one incoming Sequence Flow. As a consequence, it is not


possible to explicitly model which Event has to be triggered when the informa-tion is received. A Data Based Exclusive Gateway, as discussed in Section 3.1.4on page 24, is used to merge the two exclusive Sequence Flows that originatefrom these Events. When Event ‘Information Received2’ occurs before Event‘Wait Three Days’, Task ‘Process Information’ will be performed, otherwiseTask ‘Quit Information Request’ will be performed.

Figure 3.18: Deadline monitoring in BPMN

3.1.7 Process Instantiation

Figure 3.19 presents a process in which one books a flight and a hotel in par-allel. The two solid green squares on both Activities Object indicate that theActivities will be instantiated when the Process Model will be instantiated.Both Activities will be performed in parallel and exactly once for each case. Acase will be completed when both Activities have completed.

Figure 3.19: Process Instantiation in Protos

Figure 3.20 on the following page shows the properties dialog of Activity ‘BookFlight’. Both the properties ‘Start Sub-Process’ and ‘Start Process Model’are enabled, which indicates that this Activity will be instantiated when the


Process Model will be instantiated. Note that these properties correspond tothe two green squares on the two Activity Objects in Figure 3.19.

Figure 3.20: Properties dialog of Activity ‘Book Flight’

Figure 3.21 presents two mappings for the Protos model in Figure 3.19 on thepreceding page. BPMN allows a Process to be defined without a Start Eventor an End Event. However, at least one End Event should be present in case aStart Event is used, and vice-versa. The model in Figure 3.21(a) uses no StartEvent or End Event, which means that both Tasks are instantiated when theenclosing process is instantiated and that the process ends when both Taskshave completed their execution. The model in Figure 3.21(b) behaves equally,but it uses a Start Event and an End Event. The Start Event creates a parallelflow to Task ‘Book Flight’ and ‘Book Hotel’, and the End Event explicitlymodels where the process ends.

(a) Without Start and End Event (b) With Start and End Event

Figure 3.21: Process Instantiation in BPMN

3.1.8 Process Termination

Figure 3.22 on the next page presents a process in which one evaluates a reportand then either sends or discards the report based on the outcome of the


evaluation. This process is another example of an explicit choice as discussedin Section 3.1.4.

Figure 3.22: Process termination in Protos

The interesting thing is that both the ‘End Sub-Process’ and ‘End ProcessModel’ properties of Activity ‘Discard Report’ are enabled (indicated by twored squares). This means that the complete process terminates when the reportis discarded. Figure 3.23 shows how these properties can be set on the GeneralTab of the properties dialog.

Figure 3.23: Properties dialog of Activity ‘Discard Report’

Figure 3.24 on the next page shows the mapping for the Protos model in Figure3.22. The Activities and Connections are mapped similarly to the mappingpresented in Section 3.1.4. The Terminate End Event captures the terminationbehaviour when the report is discarded. The Text Annotation shows that aTerminate End Event is modelled by setting attribute ‘EventType’ to ‘End’and attribute ‘Trigger’ to ‘Terminate’. Note that the BPMN specification isunclear about whether a Terminate End Event within a Sub-Process will onlyterminate that Sub-Process or the complete Proces.


Figure 3.24: Process termination in BPMN

3.2 Connection Semantics

The strength of Protos is that it allows modelers to model complex processeswith little training. On the other hand, Protos lacks a (formal) semantics.This makes little difference when the only intention is to approximately modela process without executing or mapping it to another language or notation.

In particular, the semantics of connections in Protos require further explanationin the context of the mappings between Protos and BPMN. Protos differen-tiates between three type of connections: Connections, Trigger Connections,and Buffer Connections. Buffer Connections are left out of consideration inthe mappings between Protos and BPMN, because BPMN lacks a suitablerepresentation for a Buffer Object. A Trigger Connection is a connection thattargets at, or originates from a Trigger Object. All other connections betweenStatus Objects, Activity Objects, and Sub-Process Objects are Connections.

Protos offers six different types of Trigger Connections. A Trigger Connectionthat originates from a Trigger Object has type Start, Restart, or Cancel. Thelatter two types are only defined for Trigger Connections that connect twoTriggers, that is, Triggers can only be restarted or cancelled by other Triggers.A Trigger Connection that originates from an Activity, a Sub-Process, or aStatus is either of type Set, Turn Off, or Restart. Although the graphicalrepresentation of a Trigger Connection indicates the type by its striped linepattern, it requires a trained eye to distinguish the different types. Therefore,labels will be used to illustrate the type of a Trigger Connections in this sectionto prevent any misunderstandings.

3.2.1 Converging Connections

Converging connections are connections that target at the same Object. AllConnections, and Trigger Connections of type Start that target at an ActivityObject will be joined according to the Incoming Connections property, whichcan be set to ‘and join’, ‘xor join, or ‘or join’. Since a Sub-Process lacks thisproperty, it is assumed that such incoming connections will be synchronised.All Connections and Trigger Connections of type Start that target at a StatusObject will be merged. Synchronisation means that the process continues whenall incoming connections are simultaneously enabled and merging means that

3.2. CONNECTION SEMANTICS 33

the process continues when any of the incoming connections is enabled. ATrigger Object synchronises all incoming Connections and Trigger Connectionsof type Start. Moreover, Trigger Connections of type Restart of Cancel thattarget at a Trigger are synchronised per type, which means that a TriggerObject is restarted when all incoming Trigger Connections of type Restart areenabled, and cancelled when all incoming Trigger Connections of type Cancelare enabled. Note that this behaviour is similar for all types of Trigger, e.g.,Time, Mail, and File Triggers. These semantics are best explained with thehelp of some examples.

Figure 3.25 shows two versions of a process in which one first books a busi-ness trip and applies for a visa, then waits for the visa to be ready and thetravel papers to arrive, and finally goes on the business trip. The model onthe left uses an Activity Object to model the business trip, while the model onthe right uses a Sub-Process. Furthermore, the latter model uses two StatusObjects to explicitly model waiting moments. Since all incoming Connectionsand Trigger Connections of type Start of an Activity Object or a Sub-ProcessObject are synchronised (by default), Activity or Sub-Process ‘Go on BusinessTrip’ starts only when the visa has been applied and ready, the business triphas been booked, and the travel papers have been arrived. These synchronisa-tion semantics are irrespective of whether the waiting moments are modelledexplicitly or not.

(a) (b)

Figure 3.25: Incoming connection semantics for Activity and Sub-Process

Figure 3.26 presents a model in which one writes a report or receives a report bymail and then archives that report. Since all incoming Connections and TriggerConnections of type Start of a Trigger Object are merged, any report, whetherones writes it by its own or it arrives by mail, is archived. In other words, whenone writes a report and another report arrives by mail, two separate reportsare archived.

Figure 3.26: Incoming connection semantics for Status

Figure 3.27 on the following page presents a model for an alarm based on a


motion sensor and a fingerprint sensor. When the alarm is set and the motionsensor detects a person, this person has thirty seconds to put a finger on thefingerprint identification sensor to prevent the police from being informed. Thisbehaviour indicates that incoming Trigger Connections of type Set and Startare synchronised, while Trigger Connections of type Cancel are synchronisedseparately. In other words, Trigger ‘30 Second to Identify’ is started when boththe alarm is set and the motion sensor detects a person, and cancelled whenthe event modelled by Trigger ‘Fingerprint Identification’ occurs.

Figure 3.27: Incoming connection semantics for Trigger

Figure 3.28 presents a model in which one turns on a light that is turned offwhen both a heat sensor and a motion sensor do not detect a person for tenminutes. This behaviour indicates that incoming Trigger Connections of Trig-ger Connections of type Restart are synchronised separately from any TriggerConnections of type Set, Start or Cancel.

Figure 3.28: Incoming connection semantics for Trigger (2)

3.2.2 Diverging Connections

Diverging connections are connections that originate from the same Object.The semantics for outgoing connections of an Activity Object, a Sub-ProcessObject, or a Trigger Object are that any outgoing connection without con-dition, or with a condition that evaluates to true is enabled. Moreover, theOutgoing Connections property of Activity can also be set to ‘xor split’ or‘or-split’ instead of its default value of ‘and split’. If this property is set to‘xor split’ exactly one of these connections is enabled, and one or more of theseconnections are enabled if it is set to ‘or split’. Figure 3.29 on the facing pagepresents a model in which a questionaire is sent to a group of participants.After one day the first returned questionnaires are processed and ten iPodsare put up for raffle amongst the corresponding participants as a reward fortheir quick reactions. After one week the remaining returned questionnairesare processed and five iPods are put up for raffle amongst these participant.

No connection in Figure 3.29 has a condition associated with it. The be-haviour of this process indicates that all unconditional outgoing connectionsare enabled by default upon completion of an Activity Object – similar for a

3.3. INTERESTING THEMES 35

Sub-Process Object – and the occurrence of an event modelled by a TriggerObject. For example, upon completion of Activity ‘Send Questionnaire’ bothTriggers ‘Wait One Day’ and ‘Wait One Week’ are set and both Connections toActivities ‘Process First Results’ and ‘Process Remaining Results’ are enabled.As explained before, the latter two Activities should only start when the otherTrigger Connections of type Start are also enabled.

Figure 3.29: Outgoing connection semantics for Trigger, Activity, and Sub-Process

Figure 3.30 illustrates the semantics of a Status with multiple outgoing connec-tions. It presents a model in which one travels to a station and then decidesto travel by train, bus, or taxi. Since trains and busses run according to aset timetable, two Time Trigger Objects are used to model the time until thenext arrival of a bus or train. On the other hand, it is assumed that taxisare directly available. No connection in the model has a condition associatedwith it. The behaviour of this process indicates that all unconditional outgoingconnections of a Status are enabled until exactly one them is chosen; the otherones are then disabled. That is, one exclusively chooses to travel by train, bus,or taxi. When one or more outgoing connections of a Status have a condition,exactly one of the connections is chosen for which these condition evaluates totrue.

Figure 3.30: Outgoing connection semantics for Status

3.3 Interesting Themes

This section discusses two interesting themes related to the mapping fromProtos to BPMN. First the influence on the mapping of the lack of states inBPMN is discussed. Then some of the consequences of making the Protossemantics more formal are presented.


3.3.1 Lack of States

In Section 2.1.4, the BPMN specification has been evaluated with the help ofthe Bunge Wand and Weber (BWW) ontology [21, 22, 23]. From the viewpointof ontological completeness, it became apparent that BPMN lacks a suitablerepresentation for states.

The lack of a representation for states complicates the mapping from Protos toBPMN. Since Protos uses Status Objects to model states or ‘moments of rest’,a certain degree of creativity is required to come up with a suitable mappingfor these objects. In general, four cases have to be considered. The moststraightforward case is that of a Status with exactly one input and one output.Such a Status is best mapped to a Connection that directly connects the inputto the output.

Secondly, a Status with multiple inputs and a single output corresponds to theSimple Merge workflow pattern [16], because each enablement of an incomingconnection results in the thread of control being passed to the only outgoingconnection. As discussed in Section 3.1.4 on page 24, the behaviour of such aStatus can be modelled using a Data-Based Exclusive Gateway in BPMN.

Thirdly, a Status with a single input and multiple outputs corresponds to aDeferred Choice workflow pattern [16], which means that it models a pointin a process where one of several outgoing connections is chosen based on theoccurrence of a number of events within the operational environment. BPMNsupports this pattern with the help of an Event-Based Exclusive Gateway, asshown in Section 3.1.5 on page 27.

Finally, a Status with multiple inputs and multiple outputs represents either aMilestone workflow pattern or a combination of a Simple Merge (on the inputside) and Deferred Choice workflow pattern [16] (on the output side). Thelatter combination of patterns corresponds to an Event-Based Exclusive Gate-way in BPMN. However, the lack of states hampers a suitable representationfor a Milestone pattern in BPMN. Figure 3.31 shows a process in Protos thatmodels the enrolment procedure for students. Activity ‘Enrol Student’ canonly be performed when new enrolments are being accepted, that is, after Ac-tivity ‘Open Enrolment’ has completed and before Activity ‘Close Enrolment’commences. Status ‘Accept Enrolments’ models a milestone pattern in Protos.

Figure 3.31: Representation of a milestone in Protos


In [16], Stephen White, the author of the initial BPMN specification, proposesa representation for a milestone in BPMN. Figure 3.32 illustrates this proposalapplied to the Protos model in shown Figure 3.31. This mapping has severaldeficiencies. For example, the execution of Activity ‘Enrol Student’ in Protosdoes not influence the state modelled by Status ‘Accept Enrolment’, while Task‘Close Enrolment’ in BPMN cannot commence (if the deadline has expired)during the execution of Task ‘Enrol Student’.

Figure 3.32: Incorrect representation of a milestone in BPMN

3.3.2 Consequences of Semantical Decisions

Protos was developed as an easy-to-use graphical modelling tool with ‘fluid’semantics. This makes Protos an appropriate tool for various companies andemployees, because it gives users a free hand to develop a contextualised andpersonalised modelling style according to the circumstances. On the otherhand, different users might have different interpretations of the same processmodel.

In time, the need for transforming Protos models to other languages and no-tations, such as BPMN and BPEL4WS, and in particular for activating andexecuting these models became apparent. Protos Activate is a shining exampleof this.3 Several modelling restrictions are called into being during the devel-opment of Protos Activate in order to remove semantical ambiguities. Theserestrictions enable an unambiguous mapping from a Protos model to a FLOWermodel.

It requires other modelling skills to design a Protos model with the intention toactivate it than to design it for communication or documentation purposes only,because specific modelling constructs are no longer allowed or have differentsemantics. Therefore, it is important to support companies and employees thatuse Protos to adapt their personal modelling style, in order not to deter theseusers from using Protos as their modelling tool.

Several semantical decisions have also been made for the mapping from Pro-tos to BPMN. Since this mapping was developed from the viewpoint of bothProtos and BPMN, it is likely that some of these semantical decisions are indisagreement with the ones for Protos Activate. This means that the seman-tics of Protos may differ based on the purpose for which it is used. The more

3As discussed in Chapter 1, Pallas Athena has two other main products besides Protos:FLOWer and Protos Activate. FLOWer offers a case handling and workflow solution andProtos Activate provides the link between Protos and FLOWer by activating Protos models.


semantics coexist, the more important it becomes to harmonise these differentsemantics.

In conclusion, companies and employees that work with Protos should be sup-ported to adapt their modelling style when the semantics of Protos becomemore formal and any change to the semantics needed to perform a certaintransformation should preferably be harmonised with all other transformations.

Chapter 4

Mapping from BPMN to Protos

This chapter presents a mapping from the BPMN to Protos. First variousmappings of characteristic patterns in BPMN will be presented, then some se-mantical issues will be presented, and finally a number of interesting themeswill be discussed. Appendix E provides a detailed mapping from object at-tributes in BPMN to object properties in Protos.

4.1 Pattern Mappings

The mapping is presented using various patterns in the following sections. Eachsection elaborates on a characteristic modelling pattern in BPMN and showshow it can be modelled in Protos.

The semantics of a BPMN model are captured by a graphical representationcomplemented with attributes. Since various attributes have no graphical rep-resentation in BPMN, Text Annotations are used to show the relevant at-tributes corresponding to an object. The semantics of a Protos model arecaptured by a graphical representation complemented with properties that canbe set using properties dialogs.

4.1.1 Sequence

Figure 4.1 on the following page presents a sequential BPMN process in whichone sets a date for a holiday, books the holiday, and finally goes on the holiday.The start and end of this process are modelled using a Start Event and anEnd Event. Setting a date and going on the holiday are modelled using a Task.Booking the holiday is modelled as a Sub-Process, because it is assumed that itconsists of booking the flight as well as booking the hotel. This Sub-Process isshown in Figure 4.1 as a Collapsed Sub-Process (indicated by the plus marker).

A Text Annotation attached to an Object in Figure 4.1 presents the attributevalues of that Object. Events, Tasks, Sub-Processes, and Sequence Flows haveattributes Id, Name, and Documentation in common. The first two representthe identifier and name of an Object. The latter one can be used by the modeler

39

40 CHAPTER 4. MAPPING FROM BPMN TO PROTOS

Figure 4.1: Sequence in BPMN

to provide the user of the model with additional information, for example, theDocumentation attribute of Task ‘Set a Date’ is set to ‘Inform employer’ toadvise users of the model to inform their employer about the holiday.

The EventType attribute is used for Events in BPMN to distinguish betweenStart Events, Intermediate Events, and End Events, as shown in Figure 4.1.Moreover, the Trigger attribute of the Start Event and the Result attributeof End Event are set to ‘None’ to indicate that no cause or consequence isspecified for these Events.

BPMN distinguishes between a Task and a Sub-Process with the help of theActivityType attribute of an Activity. The TaskType attribute of Task ‘Seta Date’ is set to ‘None’ to indicate that no specific task type is set. TheSubProcessType attribute of Sub-Process ‘Book Holiday’ is set to ‘Embedded’to indicate that the Sub-Process is defined at this place in the BPD instead ofusing a reference to another process in a possibly different BPD.

The Source and Target attributes of a Sequence Flow indicate the Source Ob-ject and Target Object of that Sequence Flow. For example, these attributesof Sequence Flow ‘Date Set’ refer to the identifiers of Task ‘Set a Date’ andSub-Process ‘Book Holiday’, that is, identifiers ‘tskDate’ and ‘subBook’. TheConditionType and Quantity attributes of Sequence Flow ‘Date Set’ indicatethat the Sequence Flow is unconditional and that one token is generated uponcompletion of Task ‘Set a Date’.

Figure 4.2 on the next page shows how the sequential process in Figure 4.1 canbe modelled in Protos. Both Task Objects are mapped to an Activity Object,the Sub-Process to a Sub-Process, and the Sequence Flows to Connections inProtos. Events in BPMN with Trigger or Result None can be used to indicatesome change of state in the Process. Protos uses a Status to model a state, buta Process should not start or end with a Status.1 Therefore, Start Event ‘Start’and End Event ‘End’ in Figure 4.2 are not mapped to Protos. An additionalreason for not mapping a Start Event to a Status is that a Start Event createsparallel flow while a Status has an exclusive behaviour. On the other hand, an

1This is not a restriction of Protos, but a preferred and recommended way of modelling.


Intermediate Event without a Trigger has exactly one input and one output(see, for example, Figure B.1(b) on page 124) and therefore corresponds to aStatus with one input and one output in Protos.

Figure 4.2: Sequence in Protos

Figure 4.3 shows the General Tab and the Description Tab of the propertiesdialog corresponding to Activity ‘Set a Date’. The Name property of theActivity Object is set on the General Tab to ‘Set a Date’ and the Descriptionproperty on the Description Tab to ‘Inform Employer’, similar to the Nameand Documentation attributes of Task ‘Set a Date’ in Figure 4.1. The ‘Id’attribute of a BPMN Object corresponds to a Protos identifier which is notvisible and is automatically set by Protos2. The Type property of the ActivityObject is set on the General Tab to ‘Basic’, which is the default Activity typein Protos, and therefore a suitable mapping for the None TaskType of a Taskin BPMN.


Figure 4.3: Properties dialog of Activity ‘Set a Date’

Figure 4.4 on the following page shows the General Tabs of the propertiesdialogs corresponding to Sub-Process ‘Book Holiday’ and Connection ‘DateSet’. The Name and Description properties for these Objects are similar to thatof an Activity. The From and To properties on the General Tab of Connection‘Date Set’ identify the source and target Objects of this Connection. Theseproperties are automatically set by Protos upon creation of the Connection to‘Main Process.Set a Date’ and ‘Main Process.Book Holiday’. The part before

2As indicated before, Protos hides object identifiers in an underlying database and in itsproprietary PAL file format.


the dot indicates that the Connection is contained in a Process called ‘MainProcess’ and the part after the dot refers to the Name property of the connectedObject, that is, ‘Set a Date’ and ‘Book Holiday’, respectively. The Conditionproperty on the General Tab is left blank, because the Sequence Flows inFigure 4.1 on page 40 are unconditional.

(a) Sub-Process General Tab (b) Connection General Tab

Figure 4.4: Properties dialog of Sub-Process ‘Book Holiday’ and Connection‘Date set’


Figure 4.5 presents a process in which a woman conceives a baby and givesbirth to that baby after nine months. A Timer Intermediate Event is used asa delay mechanism to model the nine months waiting time.3

Figure 4.5: Wait for Event in BPMN

Tasks ‘Conceive Baby’ and ‘Give Birth to Baby’ have similar attributes tothe Tasks in the previous section. The attributes of the Event in between are

3Note that the BPMN specification is unclear about whether such an Intermediate Eventcould occur before the preceding Activity has finished. However, in this case it would bepeculiar if the nine months could start before the baby is conceived.


shown in the Text Annotation. It has attributes Id, Name, and Documentationin common with Activities and Sequence Flows. The EventType attributeindicates that it is an Intermediate Event, the Trigger attribute indicates thatit has a Timer Trigger, and the TimeDate attribute specifies that the womanwill give birth to the baby after nine months. Note that BPMN merely specifiesthat the TimeDate attribute has type Date and does not mention anythingabout a format to use.

Figure 4.6 shows how the process in Figure 4.5 can be modelled in Protos.Both Task Objects are mapped to an Activity Object in Protos and the TimerIntermediate Event is mapped to a Time Trigger.

Figure 4.6: Wait for Event in Protos

Figure 4.7 shows the properties dialog for this Trigger. The Name propertycorresponds to the Name attribute in BPMN and is set to ‘Nine Months’. TheWaiting Period property specifies the relative number of days, hours, and min-utes, separated by colons, after which the Trigger should execute. Nine monthscorresponds to about 275 days, so this property is set to ‘275:0:0’. Note thata nontrivial translation is required for this mapping, because the TimeDateattribute discussed above uses an unknown format. The Type attribute indi-cates that it is a Timer Trigger. The Cyclic property in Figure 4.7 is disabled,because attribute TimeDate represents a single (i.e., noncyclic) point in time.On the other hand, if attribute TimeCycle had been used instead of attributeTimeDate, the Cyclic property would have been enabled.

(a) Trigger General Tab (b) Trigger Connection General Tab

Figure 4.7: Properties dialogs of Trigger ‘Wait Nine Months’ and Trigger Con-nection ‘Baby Conceived’


Finally, it is common to use a Status in combination with a Trigger in Protosto model a situation in which the progress of the process depends on the oc-currence of an event. An example of such a model is shown in Section 3.1.3 onpage 22.

4.1.3 Event-Based Decision

Figure 4.8 presents a process in which the publisher of a magazine sends arequest to a subscriber to renew his or her subscription. When the subscribersends a positive or negative response, the subscription is renewed or discon-tinued, respectively. The subscription is automatically renewed when the sub-scriber does not respond before the end of the month.

Figure 4.8: Event-Based Decision in BPMN

Message Intermediate Events ‘Yes’ and ‘No’ are used to model a positive ornegative response from the subscriber. Timer Intermediate Event is used tomodel the end of the month. The attributes of Event ‘Yes’ are shown in theassociated Text Annotation. Attribute EventType indicates that it is an Inter-mediate Event and attribute Trigger indicates that it has a Message Trigger.

The Event-Based Exclusive Gateway after Activity ‘Request to Renew Sub-scription’ models the waiting period until either the subscriber sends a responseor the end of the month is reached. The attributes of this Gateway are shownin the associated Text Annotation. Attribute GatewayType indicates that itis an Exclusive Gateway and attribute XORType indicates, moreover, that itis an Event-Based Exclusive Gateway.

Figure 4.9 on the facing page shows how the process in Figure 4.8 can bemodelled in Protos. Each Task is mapped into an Activity Object in Protos.The Event-Based Exclusive Gateway is mapped to a Status. The Activitiesto renew, discontinue, or automatically renew the subscription become theoutputs of this Status. The Intermediate Events that decide which of these


Activities will be executed are mapped to two Mail Triggers and one TimeTrigger that are also added as inputs to these Activities.

Figure 4.9: Event-Based Decision in Protos

The Incoming Connections properties of the activities to renew, discontinue, orautomatically renew the subscription are set to ‘and join’ to ensure that syn-chronisation takes place. The Status models the waiting period until one of theevents occurs and the corresponding Activity will be executed. The exclusivebehaviour of the Status ensures that only one the Activities will be executed.Finally, the Trigger Connection from Activity ‘Request to Renew Subscription’to Time Trigger ‘End of the Month’ is added, because it is common in Protosto (explicitly) start a Time Trigger, in contrast to other types of Triggers.

4.1.4 Parallel Behaviour

Figure 4.10 on the next page presents a process in which one buys cleaningproducts, then ventilates and cleans the house in parallel, and finally puts awaythe cleaning products. One ventilates the house by ventilating the ground floorand ventilating the second floor in parallel. One cleans the house by vacuum-cleaning the floors and then mopping the floors and cleaning the windows inparallel.

This process contains several ways of parallel branching and synchronisation.The left Parallel Gateway creates two parallel branches, while the right Par-allel Gateway synchronises three parallel branches. The attributes of theseGateways are shown by the associated Text Annotations. Attribute Gateway-Type is set for both Gateways to ‘AND’ to indicate Parallel behaviour. TheOutgoingSequenceFlow attributes refers to the Sequence Flows that originatesfrom the Gateway. For example, the left Gateway refers to the identifiers ‘se-qVentilate’ and ‘seqVacuum’, which correspond to the Id attributes of the twooutgoing Sequence Flows of the Gateway.

Task ‘Vacuum-clean Floors’ also creates two parallel branches, because it hastwo Unconditional Sequence Flows that are both enabled upon completion ofthe Activity. Expanded Sub-Process ‘Ventilate House’ is a so-called parallel


Figure 4.10: Parallel behaviour in BPMN

box, which is used to show a number of parallel Activities in a compact way.No Start Events, End Events, and Connections are used in a parallel box,which means that Task ‘Ventilate Ground Floor’ and ‘Ventilate Second Floor’are instantiated when the Sub-Process is instantiated, and that both Activitiesare synchronised before the flow continues to the right Gateway in Figure 4.10.

Figure 4.11 on the facing page shows how the process in Figure 4.10 can bemodelled in Protos. As discussed in Section 4.1.1, the Start Event and EndEvent are not mapped to Protos. Task ‘Buy Cleaning Products’ and the sub-sequent Parallel Gateway are mapped to Activity ‘Buy Cleaning Products’.The routing behaviour of the Gateway is captured by setting the OutgoingConnections property of the Activity to ‘and split’ on the Simulation Tab ofthe properties dialog, as shown in Figure 4.12 on the next page. Note that, incase of an Exclusive Gateway or an Inclusive Gateway, this property is set to‘xor split’ or ‘or split’, respectively. The parallel branching behaviour of Task‘Vacuum-clean Floors’ is captured by mapping it to an Activity in Protos forwhich the Outgoing Connections property is also set to ‘and split’.

Task ‘Put Away Cleaning Products’ and the preceding Parallel Gateway aremapped to Activity ‘Put Away Cleaning Products’. The routing behaviourof the Gateway is captured by setting the Incoming Connections property ofthe Activity to ‘and join’ on the Simulation Tab of the properties dialog. Un-fortunately, the properties Incoming Connections and Outgoing Connectionsare only available for Activities in Protos. Moreover, these properties have nographical representation, which hampers the readability of a Proces Model.

Similar to BPMN, any Activity in a Protos Process without inputs is instanti-ated (exactly once) upon instantiation of the enclosing Process, and a processcompletes when all Activities have completed. Therefore, Sub-Process ‘Venti-late House’ that encloses Tasks ‘Ventilate Ground Floor’ and ‘Ventilate SecondFloor’ in Figure 4.10 are straightforwardly mapped to the Sub-Process and two


(a) Spring Cleaning

(b) Sub-Process ‘Ventilate House’

Figure 4.11: Parallel behaviour in Protos

Figure 4.12: Incoming Connections and Outgoing Connections properties ofActivity ‘Buy Cleaning Products’

Activities in Figure 4.11(b).

4.1.5 Ad-Hoc Sub-Process

Figure 4.13 on the following page presents a process in which one conductsresearch, writes several chapters, and then publishes it as a thesis. One breaksup the writing of a chapter into researching the topic, writing text, editing text,generating graphics, including graphics in text, and organising references.


(a) Write and Publish Thesis

(b) Ad-Hoc Sub-Process ‘Write Thesis’

Figure 4.13: Ad-Hoc Sub-Process in BPMN

Two Data-Based Exclusive Gateways are used to implement the loop that mod-els the writing of a chapter in each iteration. Gateway ‘Done?’ implementsthe decision to publish the thesis or to write another chapter. The former ismodelled using a Conditional Sequence Flow and the latter with the help of aDefault Sequence Flow. The attributes of these Sequence Flows are shown inthe associated Text Annotations. Attribute ConditionType indicates whetherthe Sequence Flow is Default or Conditional. The ConditionalExpression at-tribute of the Conditional Sequence Flow contains the expression that specifieswhen the thesis is finished and ready to be published. This attribute is leftopen, because it depends on the expression language that is used by a BPD.

The Default Sequence Flow is enabled when the expression of the ConditionalSequence Flow evaluates to false. Gateway ‘(Re)start writing’ merges the De-fault Sequence Flow before Sub-Process ‘Write Chapter’. Attribute Gateway-Type specifies that the Gateway has XOR behaviour and attribute XORTypespecifies that it is Data-Based. Attribute MarkerVisible specifies that the (op-tional) cross marker is placed within the diamond shape of the Gateway.


Sub-Process ‘Write Chapter’ is collapsed in Figure 4.13(a) and expanded inFigure 4.13(b). The tilde symbol centred at the bottom of the shape indi-cates that it is an Ad-Hoc Sub-Process, which means that it contains a groupof Activities without pre-defined sequence relationships. The sequence andnumber of performances for each of the contained Activities is determined bythe performers only. The attributes of the Expanded Ad-Hoc Sub Process areshown by the associated Text Annotation. Attributes ActivityType and Sub-ProcessType indicate that it is an Embedded Sub-Process, as explained Sec-tion 4.1.1 on page 39. Attribute AdHoc is enabled to specify that Sub-Process‘Write Chapter’ is Ad-Hoc. Attribute AdHocOrdering is set to ‘Sequential’to model that the Tasks within this Sub-Process should be performed sequen-tially. Finally, attribute AdHocCompletionCondition, which defines when theSub-Process will complete, is left open, because the BPMN specification is notclear about how such an expression should be specified. For example, thisattribute can be used to specify that each Activity within the Ad-Hoc Sub-Process should be performed at least once.

Figure 4.14 shows how the process in Figure 4.13 can be modelled in Pro-tos. Data-Based Exclusive Gateway ‘(Re)start Writing’ is mapped to a Status.Data-Based Exclusive Gateway ‘Done?’ is mapped to fresh Activity ‘(Re)startWriting’ for which the Incoming Connections property is set to ‘xor split’ onthe Simulation Tab of the properties dialog. Note that this Activity is used forrouting purposes only.

(a) Write and Publish Thesis

(b) Ad-Hoc Sub-Process ‘Write Thesis’

Figure 4.14: Ad-Hoc Sub-Process in Protos

Protos does not support Ad-Hoc Sub-Processes, so the mapping presented inFigure 4.14(b) is not complete. In this mapping, all Activities within Sub-Process ‘Write Process’ are instantiated (exactly once) when the enclosing Sub-Process is instantiated, which corresponds to a ‘parallel box’ in BPMN thathas been discussed in the previous section. However, adding properties similarto the attributes AdHoc, AdHocOrdering, and AdHocCompletionCondition toa Sub-Process would be sufficient to support such Ad-Hoc Sub-Processes.

Figure 4.15 on the next page presents a behaviourally equivalent alternativefor the BPMN Process shown in 4.13(a). In this alternative, the decision towrite another chapter or to publish the thesis is modelled by attaching theConditional Sequence Flow and the Default Sequence Flow directly to Sub-Process ‘Write Chapter’ instead of separately modelling this decision using an


Exclusive Data-Based Gateway.

Figure 4.15: Alternative version for the process model shown in Figure 4.13(a)

Since a Sub-Process in Protos has no Outgoing Connections property, the be-haviour of the outgoing Sequence Flows of Sub-Process ‘Write Chapter’ ismapped to an Activity in Protos for which the Outgoing Connections prop-erty is set to ‘xor-split’. Therefore, the BPMN model in Figure 4.15 also mapsto the Protos model in 4.14.

4.1.6 Activity Looping

Figure 4.16 presents a model that represents the same process as the one inthe previous section, in which one writes several chapters and then publishesit as a thesis. A Standard Loop Sub-Process, which is also still Ad-Hoc, hasbeen used to model the writing of the chapters instead of Data-Based ExclusiveGateways that place the Sub-Process in a loop.

Figure 4.16: Activity Looping in BPMN

The attributes of Sub-Process ‘Write Chapters’ are shown in the associatedText Annotation. Only the bottom four are added with respect to the model inFigure 4.13(a) on page 48. Attribute LoopType specifies that it is a StandardLoop Sub-Process. Attributes LoopCondition specifies the condition that isevaluated each iteration of the loop. Whether this happens before the Sub-Process starts or after the Sub-Process finishes, is modelled with the help of


attribute TestTime. Attribute LoopMaximum specifies the maximum numberof iterations.

Figure 4.17 shows how the process in Figure 4.16 can be modelled in Protos.The Standard Loop Activity is mapped to Sub-Process ‘Write Chapters’ forwhich the Multiple property is enabled, as shown in Figure 4.18. Moreover,properties are ‘Start Sub-Process’ and ‘Start Process Model’ are also enabled,because the Sub-Process has no inputs and resides in the Main Process.

Figure 4.17: Activity Looping in Protos

Figure 4.18: Properties dialog of Sub-Process ‘Write Chapters’

4.1.7 Exception Handling

Figure 4.19 on the following page presents a process in which one moderates ane-mail discussion and reviews the status of that discussion after one week. ATimer Intermediate Event on the boundary of Task ‘Moderate E-mail Discus-sion’ creates Exception Flow, which causes Task ‘Review Status of Discussion’to be performed.

Figure 4.20 on the next page shows how the process in Figure 4.19 can poten-tially be modelled in Protos. Timer Intermediate Event ‘One Week’ maps toa Time Trigger. As discussed in Section 4.1.2, the Waiting Period propertyof a Time Trigger uses a format that contains the number of days, hours, andminutes separated by colons. Therefore, the Waiting Period property is set to‘07:00:00’ to represent one week.


Figure 4.19: Exception handling in BPMN

Figure 4.20: Exception handling in Protos

Currently, Protos does not support the modelling of exceptions. Label ‘excep-tion::’ of the Trigger Connection that originates from Trigger ‘One Week’ shownin Figure 4.20 provides a provisional mapping for an Exception Flow in BPMN.Note that the introduction of a boolean property for a Trigger Connection inProtos to indicate whether the Trigger Connection models an exception or not,would be sufficient to support exceptions, because the type and consequencesof an exception can already be modelled using Triggers. For example, TimeTrigger ‘One Week’ indicates that the exception will cause Activity ‘ReviewStatus of Discussion’ to be performed after a specified period of time.

4.1.8 Transaction Sub Process

Figure 4.21 on the next page presents a transactional process in which onebooks a flight and a hotel. Note that this process is based on Figure 10.59 onpage 135 in [26] and is frequently referred to in discussions about BPMN. Onecharges the buyer when both bookings succeed. When one of the bookings fails,which is indicated by the Exception Flow that starts from the Cancel Interme-diate Event on the boundary of Sub-Process ‘Bookings’, one sends an unavail-ability notice. When an exception occurs, which is indicated by the ExceptionFlow that starts from the Error Intermediate Event on the boundary of Sub-Process ‘Bookings’, one handles it through customer service. CompensationTasks ‘Cancel Flight’ and ‘Cancel Hotel’ are connected through CompensationIntermediate Events on the boundary and Associations to Tasks ‘Book Flight’and ‘Book Hotel’, respectively, to model what happens when compensation isrequired. Note that Activities ‘Book Flight’ and ‘Book Hotel’ are both instan-tiated when the Transaction is instantiated, because a Start Event in BPMNcreates parallel Flow


Figure 4.21: Transaction in BPMN

The double boundary and attribute IsATransaction of Sub-Process ‘Bookings’indicate that it is a Transaction. Attributes TransactionId, TransactionProto-col, TransactionMethod specify that ‘transBookings’ is the Transaction identi-fier, WS-Protocol is the Transaction protocol, and Compensation is the methodused to undo a Transaction that has been cancelled.

Currently, Protos has no concept of transactions and compensation. Therefore,a potential mapping for the model shown in Figure 4.21 is presented in Figures4.22 and 4.23. A new type of Sub-Process needs to be introduced to properlyrepresent a Transaction in Protos. Similar to the mapping in the previoussection, the Exception Flow is provisionally mapped to a Trigger Connectionfor which the label is set to ‘exception::’. Moreover, Protos has no notionof events that trigger cancellation or the receipt of an error, so Cancel andError Events in BPMN are provisionally mapped to Mail Triggers for which anExtra Information property (shown as a Tip on the top left corner of a TriggerObject) indicates the actual type. In order to properly map these Events, thenumber of available types (i.e., Type property) for a Trigger Object in Protosshould be extended.

Figure 4.22: Transaction in Protos


Figure 4.23 shows how the Booking Transaction Sub-Process in Figure 4.19 canpotentially be modelled in Protos. Note that the Start Event and End Eventshown in Figure 4.19 are omitted in Protos, as discussed in Section 4.1.1 onpage 39 and that property ‘Start Sub-Process’ is enabled for Activities ‘BookFlight’ and ‘Book Hotel’ to indicate that these Activities are instantiated whenthe enclosing Sub-Process is instantiated. Compensation Flow is provisionallymapped to a Trigger Connection with the label set to ‘compensation::’. Theintroduction of a Compensation Trigger and a boolean property for a TriggerConnection in Protos to indicate whether the Trigger Connection models acompensation or not, would be sufficient to support compensations to the sameextent as BPMN.

Figure 4.23: Sub-Process ‘Bookings’ in Protos

4.1.9 Artifacts

Figure 4.24 on the next page presents a process in which one announces items onthe agenda and then holds a meeting. Data Object ‘Items on Agenda’ modelsa list that contains all items on the agenda. The directional Associations,and enabled attributes RequiredForStart and ProducedAtCompletion (shownin the Text Annotation attached to the Data Object), indicate that this list iscreated during Task ‘Announce Items on Agenda’ and required for Task ‘HoldMeeting’. The Text Annotation attached to Task ‘Announce Items on Agenda’shows the general use of such an Artifact. In this case, it is used to indicatethe period of time that should be reserved for the discussion of the items onthe agenda. All Objects discussed above are contained within Group ‘OrganiseMeeting’ for documentation of analysis purposes.

Figure 4.25 on the facing page shows how the process in Figure 4.24 can bemodelled in Protos. Group ‘Organise Meeging’ maps to the Textbox GraphicsObject, which has the same graphical appearance as a Rectangular GraphicsObject, but allows text to added.

Data Object ‘Items on Agenda’ is mapped to a Document Object that is con-tained in the Data Area of the Process Model in Protos. Moreover, this Doc-ument is added to the Data Tab of the properties dialog of both Activity‘Announce Items on Agenda’ and Activity ‘Hold Meeting’, as shown in Figure4.26. In other words, it is added to all Activities it is associated to in BPMN.Attribute ‘ProducedAtCompletion’ of the Data Object is mapped by enabling

4.2. SEMANTICAL ISSUES 55

Figure 4.24: Artifacts in BPMN

(a) Process Area (b) Data Area

Figure 4.25: Artifacts in Protos

the Created property of the Document in the Data Tab of Activity ‘AnnounceItems on Agenda’, as shown in Figure 4.26(a), because a directed Associationin Figure 4.24 shows that the list of items is available upon completion of theActivity. Attribute ‘RequiredForStart’ is mapped by enabling the Mandatoryproperty of the Document in the Data Tab of Activity ‘Hold Meeting’, as shownin Figure 4.26(b), because a directed Association in Figure 4.24 shows that thelist of items is used during the meeting.

The Text Annotation in Figure 4.24 is mapped to the Text Field Graphics Ob-ject that is positioned below Activity ‘Announce Items on Agenda’ in Figure4.25. The Association that connects the Text Annotation to Activity ‘An-nounce Items on Agenda’ is mapped by adding this Activity to the Objectproperty of the Text Field, as shown in Figure 4.27 on the next page.

4.2 Semantical Issues

As discussed in Section 2.1.3 on page 5, BPMN lacks a formal foundation andcontains several ambiguities, thus causing semantical problems. In this sectionthree semantical issues will be discussed with respect to multiple Start Events,the Inclusive Gateway, and compensation and exception handling.

Note that the BPMN specification refers several times to an Annex D for a listof open issues for BPMN. However, upon inquiry with Stephen A. White, the


(a) Activity ‘Announce Items on Agenda’ (b) Activity ‘Hold Meeting’

Figure 4.26: Data Tabs in Properties dialogs of Activities

Figure 4.27: Properties dialogs of Text Field Graphics Object

author of the specification, it appeared that these references are an error sincethe OMG does not put a list of outstanding issues within a specification. Acurrent list of BPMN issues is available on the website of the OMG:http://www.omg.org/issues/bpmn-ftf.open.html

4.2.1 Multiple Start Events

The BPMN specification states that: ‘There MAY be multiple Start Events fora given Process level. Each Start Event is an independent event. That is, aProcess Instance SHALL be generated when the Start Event is triggered’ [26,p. 36]. This statement suggests that the occurrence of a single Start Event isenough for a process instance to be created. However, it is left aside whetherany other Start Event may, must, or may not occur as a part of the executionof that process instance [7].

http://www.omg.org/issues/bpmn-ftf.open.html

4.2. SEMANTICAL ISSUES 57

Moreover, the specifications states that: ‘If there is a dependency for morethan one Event to happen before a Process can start [. . . ] then the StartEvents must flow to the same activity within that Process. The attributesof the activity would specify when the activity could begin. If the attributesspecify that the activity must wait for all inputs, then all Start Events willhave to be triggered before the Process begins’ [26, p. 36–37]. This statementsuggests that although the occurrence of a single Start Event causes a processinstance to be created, it may be necessary to wait for the other Start Eventsto be triggered as well [7]. However, the specification lacks any attribute tomodel that an Activity must wait until more than one of its inputs are enabled.Note that an Activity in BPMN functions on the input side as a Simple Mergeworkflow pattern [16], which means that each enablement of an input resultsin the instantiation of that Activity.

Finally, the specification mentions that a correlation mechanism, possibly im-plemented through Event attributes, will be required to property link the oc-currence of a Start Event to a particular process instance. Such a correlationmechanism is currently an open issue.

4.2.2 OR-join

The BPMN specification states that an Inclusive Gateway, which is also knownas an OR-join, ‘will wait for (synchronize) all Tokens that have been producedupstream’ and that the ‘Process flow SHALL continue when the signals (To-kens) arrive from all of the incoming Sequence Flow that are expecting a signalbased on the upstream structure of the Process’ [26, pp. 80–81]. However, thenotion of ‘upstream’ is open to more than one interpretation. In particular, thesemantics of an OR-join is unclear when it is part of a loop in a process model,in which case the OR-join is ‘upstream’ with respect to itself [7]. This opensthe door to so-called vicious circles, a phenomenon that occurs when two ormore OR-joins are in a feedback loop and each OR-join waits for one or moreof the other OR-joins to complete first [10, 1].

As discussed in Sections 4.1.4 on page 45 and 4.1.5 on page 47, an InclusiveGateway in BPMN maps to an Activity in Protos for which the IncomingConnections property is set to ‘or join’. Note that this mapping passes overthe details of the troublesome semantics of an OR-join. Chapter 6 discusses thelack of a formal semantics for OR-joins in more detail. Moreover, it presentsa pattern-matching approach that illustrates that the structure of a processmodel provides a promising starting point for modelling particular OR-joinsin a behaviourally equivalent way, exclusively with the help of other modellingconstructs.

4.2.3 Exception and Compensation Handling

Exception handling and compensation handling are powerful concepts in BPMN.However, some aspects of these concept are not completely specified. An EventContext is an Activity, either a Task or a Sub-Process, which has an Interme-diate Event attached to its boundary. The BPMN specification states that:


‘The Event Context will only respond if it is active (running) at the time ofthe Trigger [of the Intermediate Event]. If the activity has completed, thenthe Trigger may occur with no response’ [26, pp. 130–131]. This indicates thatit is not fully specified when an Event Context is active and when a Triggermay occur with no response after the Activity has completed. However, forcompensation handling it seems clear that an Event Context has to be activeafter an Activity has completed, because the specification states that: ‘Onlyactivities that have been completed can be compensated’ [26, p. 134]

It is also unclear how the process continues its execution after an exception ora compensation has been handled. The specification states that ‘when dealingwith Exceptions and Compensation, the traceability requirement is [. . . ] re-laxed’, which suggests that the merging of Exception Flow into Normal Flowis usually omitted. Moreover, the specification is not clear about whether thismay explicitly be drawn.

In [7], another lack of clarity is discussed with respect to an IntermediateEvent attached to the boundary of a Parallel Multi-Instance Sub-Process. Thespecification gives no decisive answer to whether an exception thrown by aninstance of such a Sub-Process should interrupt only the instance in questionor all instances of that Sub-Process.

4.3 Interesting Themes

This section presents two interesting themes related to the mapping fromBPMN to Protos. First the influence on the mapping of the fixed expres-sion language for Protos is discussed. Then the extensibility of Protos andBPMN with user-defined or modeler-defined concepts is discussed.

4.3.1 Expression Language

An expression language determines the syntax and semantics of expressions,e.g. conditions on arcs. In BPMN the ExpressionLanguage attribute of a BPDspecifies the language that is used for expressions, including the ConditionEx-pression of a Sequence Flow, the LoopCondition of a Standard Loop Activity,and the RuleExpression of a Rule Event.

Protos uses a proprietary expression language that cannot be altered. Ex-pressions like the Condition of a Connection or the Waiting Period of a TimeTrigger need to conform to this expression language. When a BPMN modeluses the expression language of Protos, the mapping of expressions is ratherstraightforward. In any other case, a nontrivial translation is required in orderto property map a BPMN model to a Protos model, or the other way around.

4.3.2 Extensibility

As discussed in Appendix E, a number of attributes in BPMN do not directlymap to any property in Protos. However, Protos allows user-defined properties


to be added to a specific Object type. These additional properties are calledExtra Information. Figure 4.28 shows the dialog in which Extra Informationitems can be added to Activity Objects.4 Similar dialogs are available for theother Object types in Protos.

Figure 4.28: Defining Extra Information in Protos; here seven user-definedproperties are added to activities at the language level

The Extra Information dialog in Figure 4.28 contains seven user-defined ExtraInformation items that are defined for Activities. Each row represents a singleExtra Information item consisting of a Type, a Name, and an optional Unit.The capital against the yellow background on the left of a row indicates thetype of the Extra Information item, i.e., Text (T), Number (N), Float (F),Hyperlink (H), Object (O), E-mail (E), or Option (P). For instance, the thirdrow shown in Figure 4.28 represents an Extra Information item called ‘Cost’,which is a float expressed in pounds. The buttons on the right can be usedto add more Extra Information items. The Tips Tab of the dialog offers thepossibility to display some of the Extra Information items as so-called Tips onthe corners of Objects. An example will be given in the remainder.

Figure 4.29(a) on the following page shows the Extra Tab of the propertiesdialog of Activity ‘Place Order’. Note that this tab contains a number of fieldsthat correspond to the Extra Information items that are defined in the ExtraInformation dialog in Figure 4.28. These fields are used to assign values toExtra Information items, e.g., the Extra Information item ‘Cost’ of type floatis set to 20.7 pounds. Figure 4.29(b) shows the graphical representation ofActivity ‘Place Order’ in case the Extra Information item ‘Cost’ is set as Tipon the top left corner of Activity Objects.

A Process, an Activity, and a Data Object Artifact in BPMN have a Propertiesattribute that is similar to the Extra Information in Protos. Furthermore,

4Note that this Figure is based on an example in the Protos Personal 8.0 User Manual,2006.


(a) Entering Extra Information (b) Displaying Tips

Figure 4.29: Entering Extra Information and displaying Tips in Protos usingthe user-defined properties shown in Figure 4.28

BPMN was developed to be extensible by modelers and modelling tools. Thisextensibility allows modelers to adapt Flow Objects to a certain extent andto add new types of Artifacts. In order to preserve the basic look-and-feel ofFlow Objects, a footprint for Events, Activities, and Gateways is defined thatshould not be altered, as shown in Figure 4.30. BPMN-defined markers can beincluded within these basic shapes to help identify the type of the Flow Object.In addition, the footprints are designed to be open to allow specialised markersto convey modeler-defined information.

(a) Event (b) Activity (c) Gateway

Figure 4.30: Footprints of the basic Flow Elements

BPMN provides the concept of Artifacts to open the door to additional mod-elling concepts that are not a part of the basic set of Flow Objects. Artifactscan be linked to the existing Flow Objects through Associations.

Chapter 5

Proof of Concept

The results presented in this thesis thus far have largely been a paper exercise.Chapter 2 presented a BPMN analysis consisting of a critical evaluation of itsspecification and tools. Chapters 3 and 4 presented the mapping from Protosto BPMN and back. The next stage is a proof-of-concept implementation forthese mappings.

The proof of concept is an implementation of the mappings between Protosand BPMN that serves several purposes. Firstly, it demonstrates the feasibil-ity and viability of the mappings presented in earlier chapters. Secondly, itallows one to get acquainted with the mappings by means of experiments. Oneis able to create a model in Protos and look at the corresponding model inBPMN almost instantly, and vice-versa. By doing so, structural, behavioural,and conceptual similarities and differences between Protos and BPMN becomevisible with relative ease. Thirdly, it provides a tangible way of communicatingthe potential of BPMN support within Protos.

5.1 Approach

Protos 8.1 has a main file format that is based upon the proprietary ProcessAnalysing Language (PAL). In addition, it has an XML export file format. Theproof of concept is based on a third-party BPMN modeler that supports theBPMN standard to a large extent. JViews BPMN Modeler 1.0 from ILOG isselected for this purpose, because it is freeware and it has a rather straightfor-ward XML file format. The tools evaluation in Section 2.2 on page 8 presentsmore information about this modeler.

The proof of concept consists of two transformations implemented using theXSL. XSL includes XSL Transformations (XSLT) for transforming XML docu-ments, XPath for navigating in XML documents, and XSL-Formatting Objects(XSL-FO) for formatting XML documents. Only the first two will be used inthe proof of concept. Figure 5.1 on the next page illustrates the two transfor-mations. The top transformation transforms a Protos model, which is exportedto the Protos XML file format, to the ILOG XML file format. The bottom onetransforms a BPD, which is developed in ILOG and stored in the ILOG XML

61

62 CHAPTER 5. PROOF OF CONCEPT

file format, to the Protos PAL file format. The latter transformation producesa PAL file instead of an XML file, because an import for the Protos XML fileformat is currently not available.

Figure 5.1: Proof of concept consisting of two XSL transformations

The XSL transformations are developed with the help of Altova XMLSpy2007.1 In addition to the commercial XSLT engine in XMLSpy, an open-source, command-line XSLT processor from Saxon, i.e., Saxon-B 8.9 for theJava platform, is used for executing the XSL transformations.2

Suppose that the files protos.xml and ilog.xml contain an exported Pro-tos model and a BPMN model developed in ILOG, respectively, and that thefiles protos2ilog.xslt and ilog2protos.xslt contain the XSL transforma-tions. Then the following command transforms the exported Protos modelprotos.xml into an ILOG model that is stored in file result.xml:

java -jar saxon8.jar protos.xml protos2ilog.xslt > result.xml

and the following command transforms ILOG model ilog.xml into a Protosmodel that is stored in file result.pal:

java -jar saxon8.jar ilog.xml ilog2protos.xslt > result.pal

5.2 Implementation

The implementation of the proof of concept will be illustrated using use cases inthe following four subsections. Each subsection starts with the introduction ofa process model for a use case. Then this process model is automatically trans-formed from Protos to BPMN and back, or from BPMN to Protos and back.By doing so, several characteristics of the proof-of-concept implementation willbe demonstrated.

1Altova XMLSpy 2007 is an XML editor and XML development environment for mod-elling, editing, debugging, and transforming XML technologies. An evaluation version isavailable at: http://www.altova.com/download.html

2Saxon-B 8.9 is available at: http://saxon.sourceforge.net/

5.2. IMPLEMENTATION 63

5.2.1 Exclusive Decision and Termination

Figure 5.2 presents a process in ILOG about the evaluation of reports. When areport is received, an evaluation is performed by an internal panel. The reportwill either be approved, rejected, or sent to an external panel for anotherevaluation. In the latter case, an external panel also performs an evaluation ofthe report and then either approves or rejects the report.

Figure 5.2: Exclusive Decision and Termination in ILOG

Figure 5.3 on the next page shows the result after transforming the modelin Figure 5.2 to Protos. Figure 5.3(a) presents the main (i.e., top-level) pro-cess, while Figure 5.3(b) presents Sub-Process ‘External Panel’. Message StartEvent ‘Receive Report’ is transformed to a Mail Trigger in Protos.

An Activity or a Sub-Process in Protos has the properties ‘Start Process Model’and ‘Start Sub-Process’ to indicate that it is either instantiated when the en-closing Sub-Process is instantiated or when the complete Process Model isinstantiated. When an Activity in BPMN has only Start Events as input orno inputs at all, it maps to an Activity or a Sub-Process in Protos that hasits ‘Start Sub-Process’ property enabled if it is contained in a Sub-Process,or its ‘Start Process Model’ property enabled if it belongs to the Main Pro-cess. Therefore, the ‘Start Process Model’ property of Activity ‘Internal ReportEvaluation’ (indicated by two solid green squares) and the ‘Start Sub-Process’property (indicated a single solid green square) of Activity ‘External ReportEvaluation’ are enabled, as shown in Figure 5.3.

An Activity or a Sub-Process in Protos also has the properties ‘End ProcessModel’ and ‘End Sub-Process’ to indicate that after its execution the completeprocess model or the enclosing sub process will be terminated. BPMN usesTerminate End Events for this purpose, but the specification is unclear aboutwhether such an Event that is used in a Sub-Process will terminate the completeprocess model or only that sub process. Here it is assumed that the latter isthe case. Therefore, Terminate End Event ‘Internal Abortion’ is translated byenabling the ‘End Process Model’ property (indicated by two solid red squares)


(a) Main Process

(b) Sub-Process ‘External Panel’

Figure 5.3: Result after automatically transforming the model in Figure 5.2 toProtos

of Activity ‘Internal Report Rejection’ and Terminate End Event ‘ExternalAbortion’ is translated by enabling the ‘End Sub-Process’ property (indicatedby a single solid red square) of Activity ‘External Report Rejection’. In otherwords, an Activity with a Terminate End Event as output is translated to asingle Task or Sub-Process in Protos that has its ‘End Process Model’ or ‘EndSub-Process’ property enabled, depending on whether the enclosing process isthe top-level process or not. Note that the End Events ‘Externally Approved’and ‘Internally Approved’ are omitted in Protos.

Task ‘Internal Report Evaluation’ and Data-Based Exclusive Gateway ‘Ap-proved?’ in Figure 5.2 are transformed into Activity ‘Internal Report Evalua-tion’ in Figure 5.3(a). The routing behaviour of the Gateway is captured bysetting the Outgoing Connections property of the Activity to ‘xor split’ on theSimulation Tab of the properties dialog, as shown in Figure 5.4 on the facingpage. For a Parallel Gateway or an Inclusive Gateway, this property would beset to ‘and split’ or ‘or split’, respectively. Unfortunately, this property andthe Incoming Connections property are only available for Activities in Protos.Moreover, these properties have no graphical representation, which hampersthe readability of a Proces Model.

Task ‘External Report Evaluation’ has two exclusive outgoing Sequence Flows.It is transformed into an Activity for which the Outgoing Connections propertyis set to ‘or split’ instead of ‘xor split, because it is nontrivial to detect whethera set of Sequence Flow has mutually exclusive conditions. Figure 5.5 on thenext page shows the result of transforming the Protos model in Figure 5.3 backto Protos.

Note that there are a number of differences in comparison with the originalmodel shown in Figure 5.2 on the preceding page. First, an Inclusive Gateway


Figure 5.4: Setting the Outgoing Connections property of Activity ‘InternalReport Evaluation’ to ‘xor split’ in Protos

Figure 5.5: Result after automatically transforming the model in Figure 5.3back to ILOG

is introduced to represent the ‘or split’ value of the Outgoing Connectionsproperty of Activity ‘External Report Evaluation’. Second, the name of theData-Based Exclusive Gateway was lost in translation, and therefore set tothe name of the preceding Activity prefixed with ‘Split’, i.e., ‘Split InternalReport Evaluation’. Third, the End Events ‘End Main Process’ and ‘EndExternal Report Panel’ are introduced, because each Activity should have atleast one outgoing Sequence Flow in case one or more Start Events are used inBPMN. Fourth, the names of the Terminate Intermediate Events were also lostin translation and therefore set to the name of the preceding Activity prefixedwith ‘Terminate’.



Figure 5.6 presents a process in Protos in which a patient arrives at a hospitalcompletely shaken with a compound fracture. A doctor first calms the patient,then requests an X-ray and a CT-scan, and finally diagnoses the patient whenthe scans are ready. The moments of rest between these actions are modelledusing Status Objects ‘Patient Calmed’ and ‘Wait for Scans’. A single Trigger‘Scans Ready’ is used to model the readiness of both scans.

Figure 5.6: Wait for a single event in Protos

Figure 5.7 shows the result after transforming the model in Figure 5.6 to ILOG.Note that the transformation automatically inserts Start Event ‘Start MainProcess’ and an End Event ‘End Main Process’. The three Activities aretransformed into Tasks. Since BPMN lacks a notion of states, a Status Objectbetween two Objects is usually replaced by a single connection between thoseObjects. For example, Status ‘Patient Calmed’ disappears during the transfor-mation. An exception is made for a Status that is used in combination with aTrigger to model a moment of rest until a certain event occurs. Consequently,Status ‘Wait for Scans’ disappears and its position is taken by the counterpartof Trigger ‘Scans Ready’, that is, a Message Intermediate Event.

Figure 5.7: Result after automatically transforming the model in Figure 5.6 toILOG

Figure 5.8 presents the same process in Protos as in Figure 5.6, with the ex-ception of two separate Triggers instead of a single one to model the readinessof both scans.

Figure 5.8: Wait for multiple events in Protos

Figure 5.9 on the facing page shows the result after transforming the model inFigure 5.8 to ILOG. It is tempting to transform Status ‘Wait for Scans’ and


Triggers ‘X-Ray Ready’ and ‘CT-Scan Ready’ into a Multiple IntermediateEvent that is positioned beween Activities ‘Request X-Ray and CT-Scan’ and‘Make a Diagnosis’. Note that this would be similar to the situation in Figure5.7 with the exception that the Message Intermediate Event is replaced by aMultiple Intermediate Event (see Figure B.2 on page 124 in Appendix B fora graphical representation) which contains two Message Intermediate Eventsthat each model the readiness of a single scan. However, this would be amodelling error, because the BPMN specification states that only one of themwill be required to trigger the Event and to pass the thread of control to thesubsequent branch. In other words, the readiness of either the X-ray or the CT-scan would then be sufficient to diagnose the patient. A correct transformationwould be to synchronise the Message Intermediate Events ‘X-Ray Ready’ and‘CT-Scan Ready’ with the help of a Parallel Gateway, as shown in Figure 5.9.

In case a modeler prefers to make the relation between requesting scans and thereadiness of those scans more explicit, an additional Parallel Gateway could bemodelled between Activity ‘Request X-Ray and CT-Scan’ and the two Inter-mediate Events. However, in order to cover for situations in Protos in which anActivity or Sub-Process has – next to a Status and one or more Trigger inputs– additional inputs from other Activities or Sub-Processes, all these inputs aretransformed into inputs of the (synchronising) Parallel Gateway.

Figure 5.9: Result after automatically transforming the model in Figure 5.8 toILOG

Figure 5.10 on the following page shows the result of transforming the ILOGmodels in Figures 5.7 and 5.9 back to Protos. The model in Figure 5.6 slightlydeviates from the one in Figure 5.10(a). Firstly, Status ‘Patient Calmed’ hasdisappeared, because BPMN has no notion of a state. Secondly, the nameof Status ‘Wait for Scans’ is changed into ‘Wait for Scans Ready’ (the nameTrigger ‘Scans Ready’ prefixed with ‘Wait for’), because the original namewas lost in the transformation from Protos to ILOG. The model in Figure 5.8deviates from the one in Figure 5.10(b) by the disappearance of both StatusObjects. Status ‘Patient Calmed’ disappeared for the same reasons as in Figure5.10(a) and Status ‘Scans Ready’ disappeared because the transformation onlyrecognises a ‘Wait for Event’ pattern when an Intermediate Event is the onlyinput for an Activity. However, the semantics of the model remain unchanged.


(a) Result for Figure 5.6

(b) Result for Figure 5.8

Figure 5.10: Result after automatically transforming the models in Figure 5.6and Figure 5.8 back to Protos

5.2.3 Deferred Choice

A deferred choice postpones the moment of choice in a process until some eventoccurs. Figure 5.11 on the next page presents a process in Protos in which achild called Bob prepares for a trip to a tennis summer camp and then goes tothis camp either by bus, together with a friend called John who has a drivinglicence, by taxi, or with his father who drops him off. Bob will take the busif it arrives within the foreseeable future. He will travel together with Johnif John is around and willing to. His father will take him if he comes homefrom work in time and his car is returned, e.g., from the garage for its periodicmotor vehicle test or by any other family member who has borrowed the car.The model leaves aside when Bob will take a taxi. The arrival of the bus ismodelled using a Time Trigger and the arrival of the father and the availabilityof his car are modelled using a Mail Trigger. The willingness of John to takeBob to his tennis camp is modelled using a Role that is set as the Executor ofActivity ‘Travel with Friend’. This Role is visualised in Figure 5.11 with thehelp of a Tip3 at the top-left corner of the Activity.

Figure 5.12 on the facing page shows the result after transforming the model inFigure 5.11 to ILOG. Since a Status with multiple outputs in Protos indicates adeferred choice, that is, the occurrence of events is used to decide which choiceis taken, this is always transformed to an Event-Based Exclusive Gateway inBPMN. Any input of such a Status simply becomes an input of this Gateway.The transformation of the output branches of the Status requires some cre-ativity. When an output is an Activity or a Sub-Process that has exactly oneTrigger input besides the Status input, the transformation is rather straight-forward. For example, Activity ‘Travel by Bus’ and Time Trigger ‘Arrival ofbus’ in Figure 5.11 are transformed into a Timer Intermediate Event and an

3Protos offers Tips to show Extra Information properties of the four corners of an Object.


Figure 5.11: Deferred choice in Protos

Activity as shown in Figure 5.12.

Figure 5.12: Result after automatically transforming the model in Figure 5.11to ILOG

When a Status output is an Activity or a Sub-Process that has no other inputsand a Role or Role Group is assigned to it as Executor, a Message IntermediateEvent is introduced that borrows its name from the Role or Role Group. ThisEvent makes it explicit that the Executor of the Activity or Sub-Process decideswhether this branch will be selected. See for example the transformation ofActivity ‘Travel with Friend’ to which John is assigned as executor.

When a Status output is an Activity or a Sub-Process that has no other inputsand no Role or Role Group assigned to it as Executor, a Message IntermediateEvent is introduced, because any output of an Event-Based Gateway shouldbe an Intermediate Event or a so-called Receive Task. A Receive Task is notpossible, because the incoming Sequence Flows of Task ‘Travel by Car’ need tobe synchronised using a Parallel Gateway in front of the Task and a Gatewayis not allowed as an output of an Intermediate Event. Moreover, a ReceiveTask cannot properly be mapped to Protos. The introduced Event borrows its


name from the Activity or Sub-Process prefixed with ‘Select’, to indicate thatan implicit event in a Protos model that decides whether an output branch ofa Status will be selected, is explicitly modelled with the help of this Event. Seefor example the transformation of Activity ‘Travel by Taxi’.

Following a similar line of reasoning, a Message Intermediate Event that bor-rows its name from the Activity or Sub-Process prefixed with ‘Select’ is alsointroduced for a Status output that has any other combination of inputs. How-ever, the semantics of the model will be altered by this transformation if theoutput Activity of Sub-Process has AND-join or OR-join behaviour. In thesecases, the choice whether to select this branch should not be taken before itis clear that it will result in the execution of the subsequent Activity or Sub-Process. See for example the transformation of Activity ‘Travel by Car’ withAND-join behaviour and the two Mail Triggers ‘Father Comes Home’ and ’Caris Returned‘. The choice to travel by car should not be taken before the fatherof Bob comes home and the car returns from the garage. In other words, itshould still be possible to select another means of transport until that point intime.

Figure 5.13 shows the result of transforming the ILOG model in Figure 5.12back to Protos. This transformation is rather straightforward, because eachIntermediate Event is transformed to a Trigger and each Task to an Activity.The synchronisation behaviour of Parallel Gateway ‘Join Travel by Car’ ismodelled in Protos using the (default) AND-join behaviour of Activity ‘Travelby Car’. When comparing the original Protos model in Figure 5.11 with themodel in Figure 5.13, it is interesting to see that several Triggers are added.Firstly, any Intermediate Event that is added in BPMN to model the executorof an Activity or a Sub-Process in Protos, will appear as a Trigger instead ofa Role or Role Group when it is transformed back. See for example Trigger‘John’. Secondly, any Intermediate Event that is added in BPMN to explicitlymodel an implicit event that determines whether to select a branch, appearsas an additional Trigger in Protos. See for example Triggers ‘Select Travel byTaxi’ and ‘Select Travel by Car’.

Figure 5.13: Result after automatically transforming the model in Figure 5.12back to Protos


5.2.4 Link Events

Figure 5.14 presents a process in ILOG in which one configures a product, thenpossibly designs a test plan and tests the product using manual and automatictests, and finally packages the product. Note that it is left aside what happenswhen one of the tests fails, because the only purpose of this case is to illustratethe correspondence between Link Events in BPMN and Connections and Off-Page Connectors in Protos. Moreover, no Start Event or End Event is modelledin the top-level process to illustrate that this is allowed as long as they are bothomitted.

Figure 5.14: Link Events in ILOG

Data-Based Exclusive Gateway ‘Test?’ models the decision whether to test aconfigured product before it will be packaged. When no tests are required,the process ‘jumps’ to Data Based Exclusive Gateway ‘Ready to be Packaged’,with the help of a pair of Link Intermediate Events that share the name ‘NoTests Required’. It shows the use of Link Events in the same process as ‘Go ToObjects’ in BPMN, that is, the flow is directed from a Source Link Event (leftone in Figure 5.14) to a Target Link Event (right one in Figure 5.14). Thisprovides a mechanism for reducing the length of Sequence Flow lines withoutaffecting the behaviour of the process.

When tests are required, Parallel Gateway ‘Tests Required’ shown in Figure5.14 directs the flow to Sub-Processes ‘Manual Tests’ and ‘Automatic Tests’.The former starts by designing a test plan and then running some manualtests and triggering the latter process to perform two automatic test cases.Link End Event ‘Run Automatic Tests’ in the former Sub-Process triggersLink Start Event ‘Run Automatic Tests’ in the latter Sub-Process. In otherwords, the automatic tests will only be performed after the test plan has beendesigned. This illustrated the use of Link Events in BPMN as ‘Go To Objects’in different processes.

Figure 5.15 on the next page shows the result after transforming the model inFigure 5.14 to Protos. The result consists of three processes: the main (i.e.,top-level) process, Sub-Process ‘Manual Tests’, and Sub-Process ‘AutomaticTests’. As explained in Section 5.2.1, a Data-Based Exclusive Gateway or aParallel Gateway that has an Activity as only input, is transformed into a single


Activity or Sub-Process in Protos. Therefore, the outputs of Gateway ‘Test?’shown in Figure 5.14 become the outputs of Activity ‘Configure Product’ shownin Figure 5.15, and the exclusive split behaviour of the Gateway is capturedby setting the Outgoing Connections property of this Activity to ‘xor split’ onthe Simulation Tab of the properties dialog.4 Exclusive Data-Based Gateway‘Ready to be Packaged’ has only one output and is therefore transformed into aStatus. A Status is most suited to model XOR-join behaviour, a.k.a. merging,in Protos. One exception, when an Exclusive Data-Based Gateway has anotherExclusive Data-Based Gateway as (only) output, it is transformed into anActivity with exclusive join behaviour that is used for routing purposes only,because Protos does not allow Status Objects to be connected.

(a) Main Process

(b) Sub-Process ‘Manual Tests’ (c) Sub-Process ‘Automatic Tests’

Figure 5.15: Result after automatically transforming the model in Figure 5.14to Protos

Since Parallel Gateway ‘Tests Required’ does not have an Activity as onlyinput, it is transformed into an Activity that is used for routing purposes only,as shown in Figure 5.15. The parallel split behaviour of the Gateway is capturedby setting the Outgoing Connections property of this Activity to ‘and split’.Similarly, Parallel Gateway ‘Tests Done’ is transformed into an Activity thatis used for routing purposes only, which Incoming Connections property is setto ‘and join’ to capture the synchronisation behaviour of the Gateway.

BPMN uses the term ‘Off-Page Connectors’ for Link Events that are used toshow how a Sequence Flow extends across a page break and the term ‘Go ToObjects’ for Link Events, possible in different processes, that are used as amechanism to reduce the length of a Sequence Flow line. An Off-Page Connec-tor in Protos is a Connection between two Objects in different (sub) processes.A pair consisting of a Source Link Event and a Target Link Event in BPMNis transformed into a Connection in Protos if both Events resides in the same

4Note that the default values for the Incoming Connections and Outgoing Connectionsproperties of an Activity in Protos are ‘and split’ and ‘and join’, respectively.

5.3. CONCLUSIONS 73

process, or into an Off-Page Connector, otherwise. Therefore, the pair consist-ing of Intermediate Link Events in Figure 5.14 that share the name ‘No TestsRequired’ is transformed into a Connection between Activity ‘Configure Prod-uct’ and Status ‘Ready to be Packaged, and the pair consisting of End LinkEvent and a Start Link Event in different processes that share the name ‘RunAutomatic Tests’ is transformed into two Off-Page Connectors between Activ-ity ‘Design Test Plan’ and both outputs of the Start Event, that is, Activity‘Run First Test Case’ and ‘Run Second Test Case’, as shown in Figures 5.15(b)and 5.15(c). Note that the labels of the Connection and Off-Page Connectorsare set to the names of the corresponding Link Events, i.e., ‘No Tests Required’and ‘Run Automatic Tests’. Moreover, the labels of the Off-Page Connectorsare postfixed with a number to distinguish them from each other.

Figure 5.16 shows the result of transforming the Protos model shown in Figure5.15 back to ILOG. Note that there are some interesting differences in com-parison with the original model shown in Figure 5.14 on page 71. First, theStart Event ‘Start Process Model’ and End Event ‘End Process Model’ areadded. Second, the Tasks ‘Tests Required’ and ‘Tests Done’ are added as aresult of the the mapping of Gateways to Protos, as discussed above. Third,the Off-Page Connections ‘Run Automatic Test1’ and ‘Run Automatic Test2’are transformed (without changing the behaviour) into two separate pairs ofLink Events.

Figure 5.16: Result after automatically transforming the model in Figure 5.15back to ILOG

5.3 Conclusions

A proof-of-concept implementation of the mappings between Protos and BPMNhas been presented with the help of JViews BPMN Modeler 1.0, which is a free-ware, third-party BPMN modeler that supports the BPMN standard to a largeextent. The proof of concept consists of two transformations implemented inXSL. The first one transforms a Protos model, which is exported to the ProtosXML file format, to the ILOG XML file format. The second transformation


transforms a BPMN model, which is stored in the ILOG XML file format, tothe Protos PAL file format.

The proof of concept has proven to be a practical and suitable means for dis-covering ambiguities, inconsistencies, and inaccuracies during the developmentof the mappings. The proof of concept demonstrates the feasibility and via-bility of the mappings, it allows one to acquaint oneself with the mappings bymeans of experiments, and it provides a tangible way of communicating thepotential of BPMN support within Protos.

Chapter 6

Reducible OR-joins

So far, the focus of this thesis has been on a mapping Protos to BPMN andback. Both languages have in common that they allow for OR-joins. How-ever, OR-joins are rather problematic when implementing workflows. First ofall, there are all kinds of semantical problems. Second, any reasonable imple-mentation of the OR-join is computational expensive as it requires repeatedstate-space explorations. Therefore, this chapter attempts to remove OR-joinswithout changing the behaviour. The results apply to Protos and BPMN, butalso to other languages with OR-joins, such as Event-driven Process Chains(EPCs) and Yet Another Workflow Language (YAWL).

6.1 Problem Statement and Approach

Research on workflow patterns [9, 16] shows that the support for and inter-pretation of various control-flow constructs – like sequence, choice, parallelismand synchronisation – varies substantially across workflow systems. One of themost tricky patterns relates to the OR-join that is used to model ‘wait-and-see’behaviour for synchronisation. Different approaches to approximately capturethe intuitive semantics of the OR-join have in common that synchronisation isonly to be performed for active paths [30].

In general, it appears to be complicated to fully capture the semantics of theOR-join. When defining the OR-join it is problematic to formalise a desiredintuitive semantics and from a computational perspective it is hard to deter-mine when an OR-join is enabled [30]. The non-local semantics of the OR-joinrequire a synchronisation depending on an analysis of all possible future exe-cution paths and vicious circles. The latter phenomenon occurs when two ormore OR-joins are in a feedback loop and each OR-join waits for one or moreof the other OR-joins to complete first [10, 1].

In [11], several contributions aiming at the formalisation of the OR-join se-mantics in the context of Event-driven Process Chains (EPCs) are discussed.However, none of these contributions captures the semantics of the OR-joinwithout imposing syntactical restrictions, permitting deadlocks, exhibiting un-expected behaviour, or having any other imperfections.

75

76 CHAPTER 6. REDUCIBLE OR-JOINS

Many systems and languages apply a pragmatic approach and implement ad-hoc solutions to deal with the lack of formal semantics of the OR-join. Theapproach discussed here exploits the structure of parts of a process model toremove OR-joins by mapping them onto modelling constructs without changingthe behaviour. The approach makes use of extended workflow nets (EWF-nets) [27], which can be used as an abstraction for all kinds of process models,including models represented in Protos, BPMN, EPCs, YAWL, etc.

Figure 6.1 illustrates the approach in the context of BPMN. As shown in Figure6.1(a), a BPMN model that contains one or more OR-joins is used as a start-ing point. This BPMN model is transformed into a behaviourally equivalentEWF-net that is used as an abstraction, as shown in Figure 6.1(b). A patternmatching approach is then used to reduce as many OR-joins in the EWF-net aspossible. Figure 6.1(c) shows an example of a pattern expressed in a graphicalnotation that will be introduced in the remainder. Such a pattern is used todiscover and select a particular sub net in the EWF-net, as shown by the blueshaded nodes in Figure 6.1(d). The structure of such a sub net reveals howan OR-join can be reduced. In this example, OR-join Task J is reduced to anXOR-join task, as shown in Figure 6.1(e). Finally, when no pattern can bediscovered in the EWF-net anymore, the altered EWF-net abstraction of theoriginal BPMN model is transformed back into a BPMN model that containsless OR-joins, as presented in Figure 6.1(f).

(a) For instance, a BPMN model is transformed . . . (b) . . . into an EWF-net abstraction . . .

(c) . . . and patterns are then used . . . (d) . . . to discover particular subnets . . .

(e) . . . that enable OR-join reductions . . . (f) . . . that are carried through in the BPMN model

Figure 6.1: Illustration of the approach in the context of BPMN

The remainder of this chapter is organised as follows. Section 6.2 presents pre-

6.2. PRELIMINARIES: EWF-NETS AND R-NETS 77

liminaries regarding EWF-nets, a variation on EWF-nets called R-nets, and agraphical notation for pattern matching over R-nets. Section 6.3 defines basicpatterns and reduction patterns for identifying OR-joins that can be removedfrom an R-net without changing the behaviour. Section 6.4 introduces reduc-tion rules for removing such OR-joins. Section 6.5 defines auxiliary patternsfor identifying possibilities to support and enable additional reduction rules.Section 6.6 introduces auxiliary rules for exploiting such possibilities. Section6.7 presents a pseudo-code algorithm for typically removing lots of OR-joinsbased on the reduction rules and auxiliary rules. Appendix F illustrates thisalgorithm with the help of an example. Section 6.8 points out directions forfurther research. Finally, Section 6.9 rounds off with a conclusion.

6.2 Preliminaries: EWF-nets and R-nets

In this section some preliminaries are given. Firstly, EWF-nets are introducedas a starting point for creating abstractions of all kinds of process models.Secondly, valid EWF-nets are introduced, which are EWF-nets that satisfy anumber of properties. Thirdly, R-nets are introduced in order to be able toreplace a particular subnet in a valid EWF-net by a single task. Finally, agraphical notation for the benefit of pattern matching over R-nets is presented.

6.2.1 EWF-nets

An adapted version of a YAWL extended workflow net (EWF-net) as describedin [27] will be used as a starting point for creating abstractions of all kinds ofprocess models, including core subsets of models represented in Protos, BPMN,EPCs, YAWL, etc.

Definition 1 (EWF-net). An extended workflow net (EWF-net) N is a tuple(C,i,o,T,F,split,join) such that:

– C is the set of conditions– i ∈ C is the unique input condition– o ∈ C is the unique output condition– T is the set of tasks– F ⊆ (C \ {o} × T ) ∪ (T × C \ {i}) ∪ (T × T ) is the flow relation– every node in the graph (C ∪ T, F ) is on a directed path from i to o– split: T → {AND, XOR,OR} specifies the split behaviour of each task– join: T → {AND, XOR,OR} specifies the join behaviour of each task

Figure 6.2 on the next page shows the basic elements of the EWF lexicon: aconnection, a condition, and a task with possible split and join behaviours. Thetuple (C, T, F ) corresponds to a classical Petri net [13] where C (the set of con-ditions) corresponds to places, T (the set of tasks) corresponds to transitions,and F is the flow relation. Elements of C ∪ T are called nodes. Two specialconditions are introduced by analogy with the class of workflow nets [2]: theunique input condition i and the unique output condition o. Moreover, the


flow relation is extended to allow for direct connections between tasks. Mul-tiple connections between nodes are not considered. The functions split andjoin specify for every task whether it has AND/XOR/OR behaviour [27].

Figure 6.2: Visual representation of EWF elements

The preset and postset of a node n, denoted by •n and n•, respectively, containall nodes that have a directed connection to or from n, that is, •n = {n′ ∈C ∪ T | (n′, n) ∈ F} and n• = {n′ ∈ C ∪ T | (n, n′) ∈ F}. Furthermore, thesenotations are overloaded in order to deal with a set P ⊆ C ∪ T of nodes, i.e.,•P = {n | ∃n′∈P n ∈ •n′} and P• = {n | ∃n′∈P n ∈ n′•}.

Whenever an EWF-net N is introduced, it is assumed that C, i, o, T, F, split,and join are defined as N = (C, i ,o, T, F, split, join). Superscripts or sub-scripts are used if ambiguity is possible, i.e., N•n, n

N•, CN , iN ,oN , TN , FN , splitN ,and joinN , refer to elements of the EWF-net N.

6.2.2 Valid EWF-nets

In this section a number of properties for EWF-net are defined. First of all,the notion of an explicit EWF-net is introduced to denote the EWF-net that isobtained when an explicit condition c(t1,t2) is added between two tasks t1 andt2 if there is a directed connection from t1 to t2 [31]. By doing so, it will bemore convenient to define desirable properties on an EWF-net. The extendedset of conditions is denoted as Cext and the extended set of flow relations isdenoted as F ext. Moreover, a universe E of all explicit EWF-nets is introduced.

Definition 2 (E, Explicit EWF-net). E is the universe of all explicit EWF-nets. Let N = (C, i,o, T, F, split, join) be an EWF-net, the corresponding ex-plicit EWF-net is defined as a tuple (Cext, i,o, T, F ext, split, join) such that:

– Cext = C ∪ {c(t1,t2) | (t1, t2) ∈ F ∩ (T × T )}– F ext = (F \ (T × T )) ∪ {(t1, c(t1,t2)) | (t1, t2) ∈ F ∩ (T × T )}∪{(c(t1,t2), t2) | (t1, t2) ∈ F ∩ (T × T )}

In the remainder of this section, it is assumed that all EWF-nets have explicitconditions. Note that through Definition 2 all EWF-nets can be transformedinto an EWF-net with explicit conditions.

A marking M is a distribution of tokens over conditions, i.e., M ∈ C → N.The marking of an EWF-net denotes a state and an EWF-net can move fromone state to another by executing enabled tasks. An explicit definition of thetransition relation is given in [4]. Notation M1

t→ M2 describes that task t isenabled in marking M1 and that the execution of t in M1 leads to marking M2.M1

∗→ Mn describes that marking Mn is reachable from a marking M1, i.e.,there is a sequence of zero or more tasks t1, t2, . . . , tn−1 such that M1

t1→ M2t2→


. . .tn−1→ Mn. A tuple (N, M) denotes an EWF-net N with an initial marking

M . For example, (N,i) is an EWF-net N that initially contains a single tokenlocated in input condition i [4]. Note that there is an overloading of notation:symbol i is used to denote condition i as well as the marking with only onetoken in condition i . The same holds for output condition o.

The notions of a safe EWF-net and a sound EWF-net are introduced for thepurpose of defining a valid EWF-net, which is an explicit EWF-net that is bothsafe and sound.

Definition 3 (Safe EWF-net). Let N = (C, i,o, T, F, split, join) be an ex-plicit EWF-net. N is safe if and only if for every reachable marking frommarking i and each condition c ∈ C the maximum number of tokens in c equalszero or one, i.e., ∀M (i ∗→ M) ⇒ (∀c∈C M(c) ≤ 1).

Definition 4 (Sound EWF-net). Let N = (C, i,o, T, F, split, join) be anexplicit EWF-net. N is sound if and only if:

(i) Marking o is reachable from every marking M that is reachable from mark-ing i: ∀M (i ∗−→ M) ⇒ (M ∗−→ o)

(ii) Marking o is the only marking reachable from marking i with at least onetoken in condition o: ∀M (i ∗−→ M ∧M ≥ o) ⇒ (M = o)

(iii) There are no dead tasks: ∀t∈T ∃M,M ′ i∗−→ M

t−→ M ′

Definition 5 (Valid EWF-net). Let N be an explicit EWF-net. N is validif and only if it is safe and sound.

6.2.3 R-nets

A reduce net (R-net) and a universe R containing all R-nets are introduced inorder to be able to replace a particular subnet by a single task. The notions offolding, folded subnet, and fold task are used to refer to the replacement of asubnet, the replaced subnet, and the task that replaces a subnet, respectively.These notions will be discussed in more detail in Section 6.6.3 on page 97. AnR-net is an extended version of an EWF-net, because it allows the input andoutput to be arbitrary nodes instead of conditions only and it has a partialfunction map that maps each fold task onto the corresponding folded R-net.

Definition 6 (R, R-net). R is the universe of all reduce nets (R-nets). AnR-net is a tuple (C, T, i,o, F, split, join, map) such that:

– C is the set of conditions– T is the set of tasks– i ∈ C ∪ T is the unique input node– o ∈ C ∪ T is the unique output node– F ⊆ (C \ {o}×T )∪ (T ×C \ {i})∪ (T \ {o}×T \ {i}) is the flow relation– every node in the graph (C ∪ T, F ) is on a directed path from i to o– split: T → {AND, XOR,OR} specifies the split behaviour of each task


– join: T → {AND, XOR,OR} specifies the join behaviour of each task– map: T 9 R is a partial function which maps each fold task onto an

R-net, i.e., dom(map) is the set of fold tasks.1

Function EWF2R(N) transforms an EWF-net N into an R-net without foldtasks, that is, the domain of the map function is empty.

Definition 7 (EWF2R). Let N = (C, i,o, T, F, split, join) be an EWF-net.Function EWF2R transforms N into an R-net, i.e., EWF2R(N) = (C, T, i,o, F,split, join, map) such that dom(map) = ∅.

Function R2EWF(N) transforms an R-net N into an EWF-net under the re-striction that the R-net has no fold tasks and both its input node and outputnode are conditions.

Definition 8 (R2EWF). Let N = (C, T, i,o, F, split, join,map) be an R-netwithout fold tasks and both the input node and the output node a condition,i.e., dom(map) = ∅ and i,o ∈ C. Function R2EWF transforms N into anEWF-net, i.e., R2EWF(N) = (C, i,o, T, F, split, join).

6.2.4 Graphical Notation for Pattern Matching over R-nets

In the following sections, a pattern matching approach is presented that usespatterns, i.e., subnet with particular properties, and rules for removing OR-joins2 from an R-net without changing the behaviour. In this section, thebasic EWF lexicon shown in Figure 6.2 on page 78 is extended for the benefitof obtaining a graphical notation to succinctly represent patterns in an R-net.Table 6.1 presents the additions to the lexicon.

Element Semantics

Zero or more connections

One or more connections

Two or more connections

Two or more branches that originate from the samenode

Continued on next page1Function dom() returns the domain of a (partial) function. Note that t ∈ dom(map)

is a task that has a decomposition, while t ∈ T \ dom(map) is a task that is atomic, i.e.,without some decomposition.

2An R-net allows OR-join tasks with a single incoming connection. In the remainder,‘reducing an OR-join task’ means ‘reducing an OR-join task with at least two incomingconnections’.


Element Semantics

A task with any type of split and join behaviour3

An example of a subnet description that is allowed tobe substituted by any matching substitution subnet, asdefined in the remainder

Table 6.1: Extended EWF lexicon

Two examples using the graphical notation presented in Table 6.1 are shown inFigure 6.3. Figure 6.3(a) represents a condition with one incoming connectionand one or more outgoing connections. The example in Figure 6.3(b) representsa task with any type of join behaviour, compulsory XOR-split behaviour, zeroor more incoming connections, a set of zero or more outgoing connections, andanother disjoint set of two or more outgoing connections.4

(a) (b)

Figure 6.3: Examples illustrating the extended EWF lexicon

A third example is shown in Figure 6.4 on the next page and this exampleillustrates the construction of a subnet description. A subnet description is agraphical notation that describes all allowed subnets between two nodes in an R-net by means of imposing restrictions on the type of nodes and connections thatare allowed in such a subnet. Any subnet that matches a subnet description willbe called a substitution subnet. The notions of a condition description, a splitdescription, a join description, and a boundary description will be introducedin order to impose restrictions on the types of nodes that are allowed to occurin a substitution subnet.

A condition description is a graphical notation that describes allowed condi-tions depending on the number of incoming and outgoing connections. Figure6.4(a) shows an example of a condition description which describes that anycondition with one set of one or more incoming connections, one set of one ormore outgoing connections, and another disjoint set of zero or more outgoingconnections is allowed.

3Note that this extends the semantics for a task as given in Figure 6.2 on page 78.4Note that an incoming connection set does not have to be disjoint from an outgoing

connection set.


(a) A conditiondescription . . .

(b) . . . a joindescription . . .

(c) . . . another joindescription . . .

(d) . . . a splitdescription . . .

(e) . . . another splitdescription . . .

(f) . . . and a boundary description . . . (g) . . . together form a subnet description

Figure 6.4: Construction of a subnet description

A join description is a graphical notation that describes allowed join behavioursof tasks depending on the number of incoming connections. Figures 6.4(b) and6.4(c) show two examples of join descriptions. The former allows any joinbehaviour when there is exactly one incoming connection. The latter allowsXOR-join behaviour when there are one or more incoming connections.

A split description is a graphical notation that describes allowed split be-haviours of tasks depending on the number of outgoing connections. Figures6.4(d) and 6.4(e) show two examples of split descriptions. The former al-lows any split behaviour when there is one set of one outgoing connection andanother disjoint set of zero or more outgoing connections. The latter allowsXOR-split behaviour when there is one set of one or more outgoing connectionsand another disjoint set of zero or more outgoing connections.

A boundary description is a graphical notation that imposes restrictions on theallowed sources for incoming connections and allowed targets for outgoing con-nections of nodes in a substitution subnet. The shape of a boundary descriptionis an octagon to which two or more sets of connections are attached. Thesesets represent the connections between the nodes in a substitution subnet andthe two nodes between which the substitution subnet is defined. Figure 6.4(f)shows an example of a boundary description to which two sets of connectionsare attached. The left set indicates that there are two or more connections thatoriginate from one of the nodes between which a substitution subnet is definedand target at any of the nodes within the substitution subnet. The right setindicates that there are two or more connections that originate from any ofthe nodes within a substitution subnet and target at the other node betweenwhich the substitution subnet is defined.

Figure 6.4(g) joins together the example descriptions in Figures 6.4(a) to 6.4(f)into a subnet description. A subnet matches a subnet description if each con-dition in the subnet is allowed by at least one condition description in theboundary description, and each task in the subnet is allowed by at least one


split description and at least one join description in the boundary description.Moreover, each node in the subnet has to be on a directed path between thetwo nodes between which the subnet description is defined. Finally, there aresome restrictions on the allowed sources and targets of connections attached acondition description, join description, or split description. A connection thatcrosses the border of the enclosing boundary description is attached to a nodeoutside a substitution subnet. A connection that does not cross the borderof the enclosing boundary description is either attached to a node within asubstitution subnet or to one of the two nodes between which the substitutionsubnet is defined. In the latter case, the connection is contained in one of thesets of connections that is attached to the boundary description.

Figure 6.5 presents an example that illustrates how a subnet description be-tween two nodes can be substituted by a substitution sub net, i.e., a subnetthat matches the subnet description. Figure 6.5(b) shows a correct substitu-tion. Figure 6.5(a) allows zero or more connections to target at the left nodeand zero or more connections to originate from the right node, while thesenumbers are fixed in Figure 6.5(b) on two and one, respectively. Since morethan one connection targets at the left node, its join behaviour is fixed too.The split behaviour of the right node is irrelevant, because the semantics areidentical when there is only one outgoing connection.

(a)

(b) (c)

Figure 6.5: Illustration of a subnet description between two nodes (top) thatis correctly (bottom left) and incorrectly (bottom right) substituted by a sub-stitution subnet

Figure 6.5(c) shows an incorrect substitution. Condition c has an incomingconnection, which is indicated by a thick arrow in Figure 6.5(c), that originatesfrom outside the substitution subnet. This is not allowed by the conditiondescription in Figure 6.5(a), because the condition description has no incomingconnection (set) that crosses the border of the boundary description. Task t


has AND-split behaviour and two outgoing connections, which are indicatedby thick arrows in Figure 6.5(c), that target at nodes within the substitutionsubnet. This is not allowed by any of the two split descriptions in Figure6.5(a). The right split description allows XOR-split behaviour only. The leftsplit description allows only AND-split behaviour in case the task has only oneoutgoing connection that targets at a node within the substitution subnet.

Figure 6.6 illustrates that different subnet descriptions might describe the sameset of subnets. The four subnet descriptions presented in Figures 6.6(a)–(d),which are defined between two tasks, are equivalent with respect to the setof allowed substitution subnets. The bottom condition description shown inFigure 6.6(a) is superfluous, because each node in a substitution subnet hasto be on a directed path between the two nodes between which the subnet de-scription is defined and this condition description has no incoming connections.This means that the subnet descriptions presented in Figures 6.6(a) and 6.6(b)are equivalent.

(a) This subnet description . . . (b) . . . is equivalent to this one . . .

(c) . . . and to this one . . . (d) . . . and to this one . . .

(e) . . . and matches this subnet . . . (f) . . . or this subnet

Figure 6.6: Examples illustrating equivalent subnet descriptions

The boundary descriptions of the subnet descriptions presented in Figures6.6(a)–(d) have exactly one incoming connection and one outgoing connec-tion, which implies that any node within a substitution subnet has at mostone incoming connection that originates from, and one outgoing connectionthat targets at, one of the two nodes between which the subnet descriptionis defined. Moreover, a substitution subnet of the sub net descriptions shownin Figures 6.6(a)–(d) comprises only conditions and connections, because theboundary descriptions contain only conditions descriptions and no split or joindescriptions. Since an R-net excludes direct connections between conditions(and direct connections between tasks), the subnets shown in Figures 6.6(e)–(f) are the only two subnets that match Figures 6.6(a)–(d). The substitutionsubnets in these subnets are indicated by thick lines. The substitution subnetshown in Figure 6.6(e) contains a single condition that has one incoming andone outgoing connection. The substitution subnet presented in Figure 6.6(f)comprises a single connection without any nodes. Although the subnet descrip-tions presented in Figures 6.6(a)–(d) are equivalent, the one shown in Figure

6.3. BASIC AND REDUCTION PATTERNS 85

6.6(d) is preferred from the viewpoint of comprehensibility.

6.3 Basic and Reduction Patterns

The graphical notation for pattern matching over R-nets is used to define threetypes of patterns: basic patterns, reduction patterns, and auxiliary patterns. Abasic pattern forms the basis for reduction patterns as well as auxiliary patterns.A reduction pattern aims at identifying OR-joins that can be removed from anR-net without changing the behaviour. An auxiliary pattern aims at identifyingpossibilities to support and enable additional reduction patterns. The basicpatterns and reduction patterns are defined in this section. The next sectionuses the reduction patterns to introduce some reduction rules for removingOR-joins. The auxiliary patterns and rules are defined in Sections 6.5 and 6.6.Finally, a pseudo-code algorithm for typically removing lots of OR-joins basedon the reduction rules and auxiliary rules is presented in Section 6.7.

Before presenting the basic patterns and reduction patterns, the general notionof a pattern is introduced. A pattern is a means for identifying recurringsubnets with particular properties in an R-net. A pattern is a nonempty setof nodes including an input node and an output node such that every node inthe pattern is on a directed path, which consists of nodes in the pattern only,from the input node to the output node. Note that a pattern is allowed to becomposed of only one node that is both the input node and the output node.

Definition 9 (Pattern). Let N = (C,T,i,o,F,split,join,map) be an R-net. Pis a pattern of N if and only if:

(i) P ⊆ C ∪ T(ii) there exists an input node iP ∈ P and an output node oP ∈ P such that

every node n ∈ P is on a directed path, consisting of nodes in P only,from iP to op, i.e., (iP , n) ∈ (F ∩ (P × P ))∗ ∧ (n, oP ) ∈ (F ∩ (P × P ))∗5

According to Definition 9 and requirement (i) of Definition 4 on page 79, therewill always be a directed path from the input node iP to the output node oP

in a pattern P .

Two properties of a pattern are introduced. A pattern is a minimal pattern ifit does not enclose another pattern of the same type. A pattern is a maximalpattern if it is not enclosed by another pattern of the same type.

Definition 10 (Minimal/maximal pattern). Let N = (C,T,i,o,F,split,join,map) be an R-net and P a pattern of N.

– P is a minimal pattern if and only if there is no other pattern P ′ of thesame type such that P ′ ⊂ P

– P is a maximal pattern if and only if there is no other pattern P ′ of thesame type such that P ⊂ P ′

5F ∗ denotes the reflexive transitive closure of a flow relation F .


Several shorthand notations for a pattern are used in the remainder for read-ability purposes. The set of conditions and the set of tasks of a pattern aredenoted as PC and PT , respectively. A pattern without its input node, itsoutput node, or both its input and output node is denoted as

−−•

P,•−−

P, or−−P , re-

spectively. Note that the presence or absence of a bullet at the end of theoverline of P indicates the presence or absence of the input or output node.

Definition 11 (Pattern shorthand notations). Let N = (C, T, i,o, F, split,join, map) be an R-net and P a pattern of N. The following shorthand notationsare introduced:

– PC = P ∩ C– PT = P ∩ T

–−−•

P = P \ {iP }–

•−−

P = P \ {oP }–

−−P = P \ {iP , oP }

As already stated, a basic pattern forms the basis for reduction patterns (aswell as auxiliary patterns) and a reduction pattern aims at identifying OR-joinsthat can be removed from an R-net. Figure 6.7 on the facing page presentsthe graphical representation of the basic patterns (on the left) and reductionpatterns (on the right).6 A basic pattern and a reduction pattern next toeach other in Figure 6.7 are equal except for additional restriction imposedon outgoing connections of the input node or on incoming connections of theoutput node of the reduction pattern.

Note that the name of a basic pattern starts with ‘BASIC-’ and the name ofa reduction pattern with ‘REDUCE-’. Moreover, the names of the patternsreflect the type of input node and output node by using indications ‘XOR’,‘OR’, and ‘AND’. Indication ‘XOR’ for an input node means that it is eithera condition or an XOR-split task, where ‘OR’ and ‘AND’ mean that it is anOR-split task or an AND-split task, respectively. The same goes for an outputnode except that indications for output tasks indicate join behaviour instead ofsplit behaviour. For example, the name of a BASIC-XOR-OR-pattern indicatesthat the input node is either a condition or an XOR-split task and that theoutput node is an OR-join task. Indication ‘XOR’ is used for conditions as wellas for XOR-split tasks and XOR-join tasks, because these nodes have similarexclusive behaviour when one abstracts from the moment that a routing choiceis taken.

A BASIC-OR-OR-pattern (see Figure 6.7(a)) has two or more sequence branches– that is, branches composed of zero or more connected nodes in which eachnode has exactly one incoming and one outgoing connection – between theinput node and the output node. A REDUCE-OR-OR-pattern (see Figure6.7(b)) is a BASIC-OR-OR-pattern satisfying the additional requirement thateach outgoing connection of the input node targets at a node within the pat-

6Note that none of the reduction patterns captures the OR-join with a single incomingconnection. It would be trivial but unnecessary to reduce such an OR-join, because itssemantics equals the semantics of an XOR-join or an AND-join with one incoming connection.

6.3. BASIC AND REDUCTION PATTERNS 87

(a) BASIC-OR-OR-pattern (b) REDUCE-OR-OR-pattern

(c) BASIC-XOR-OR-pattern (variant 1) (d) REDUCE-XOR-OR-pattern (variant 1)

(e) BASIC-XOR-OR-pattern (variant 2) (f) REDUCE-XOR-OR-pattern (variant 2)

(g) BASIC-AND-OR-pattern (h) REDUCE-AND-OR-pattern

Figure 6.7: Graphical representation of the basic patterns (on the left) and thereduction patterns (on the right)

tern and each incoming connection of the output node originates from a nodewithin the pattern.

A BASIC-XOR-OR-pattern, which comes in two variants (see Figures 6.7(c)and 6.7(e)), ensures that at any time at most one token will be present ina substitution subnet of the subnet description between the input and outputnode. A BASIC-AND-OR-pattern (see Figure 6.7(g)) ensures that all brancheswill be executed in a substitution subnet of the subnet description between theinput and output node. The next section explains these last two patterns inmore detail. A REDUCE-XOR-OR-pattern, which also comes in two variants(see Figures 6.7(d) and 6.7(f)), corresponds to a BASIC-XOR-OR-pattern asa REDUCE-AND-OR-pattern (see Figure 6.7(h)) corresponds to a BASIC-AND-OR-pattern in the sense that each incoming connection of the outputnode originates from a node within the pattern.

Note that any join behaviour for an input task and any split behaviour for anoutput task is allowed for basic patterns and reduction patterns, i.e., there are3×3 = 9 or 1×3 = 3 possible input-output combinations depending on whetherthe input is a task or a condition. Definition 12 presents formal definitions ofthe basic patterns and reduction patterns.


Definition 12 (Basic and reduction patterns). Let N = (C, T, i,o, F, split,join, map) be an R-net and P a pattern of N.

– P is a BASIC-OR-OR-pattern if and only if:(i) iP , oP ∈ PT ∧ split(iP ) = join(oP ) = OR7

(ii) |iP • ∩−−•

P | > 1 ∧ |•−−

P ∩ •oP | > 1(iii) ∀

n∈−−P| • n| = |n • | = 1

(iii) iP 6∈−−P • ∧oP 6∈ •

−−P 8

– P is a REDUCE-OR-OR-pattern if and only if:(i) P is a BASIC-OR-OR-pattern

(ii) iP • ⊆−−•

P ∧ •oP ⊆•−−

P

– P is a BASIC-XOR-OR-pattern if and only if:9

(i) iP ∈ PC ∨ (iP ∈ PT ∧ split(iP ) = XOR)(ii) oP ∈ PT ∧ join(oP ) = OR

(iii) |iP • ∩−−•

P | > 1 ∧ |•−−

P ∩ •oP | > 1(iv) •

−−P ⊆ P

(v) ∀t∈

−−P T

(| • t| = 1 ∨ join(t) = XOR)

(vi) ∀t∈

−−P T

(|t • ∩P | = 1 ∨ split(t) = XOR)

– P is a REDUCE-XOR-OR-pattern if and only if:(i) P is a BASIC-XOR-OR-pattern

(ii) •op ⊆•−−

P

– P is a BASIC-AND-OR-pattern if and only if:(i) iP ∈ PT ∧ split(iP ) = AND(ii) oP ∈ PT ∧ join(oP ) = OR

(iii) |iP • ∩−−•

P | > 1 ∧ |•−−

P ∩ •oP | > 1(iv) •

−−P ⊆ P

(v) ∀c∈

−−P C

(| • c| = |c • | = 1)

(vi) ∀t∈

−−P T

(| • t| = 1 ∨ join(t) = AND)

(vii) ∀t∈

−−P T

(|t • | = 1 ∨ split(t) = AND)

– P is a REDUCE-AND-OR-pattern if and only if:(i) P is a BASIC-AND-OR-pattern

(ii) •op ⊆•−−

P

6.4 Reduction Rules

The reduction patterns defined in the previous section are used to define re-duction rules aiming at removing OR-joins without changing the behaviour.These reduction rules are valid for R-nets that originate from valid EWF-nets.

7This is a slightly sloppy notation since functions split and join are only defined foriP , oP ∈ P T , which is only required for the current conjunction. The same style will also beused in the remainder for readability purposes.

8This excludes the possibility that any node in−−P is contained in a loop that starts from

and ends at iP , or in a loop that starts from and ends at oP .9This definition covers both variants of a BASIC-XOR-OR-pattern.

6.4. REDUCTION RULES 89

This, in order to benefit from the safeness and soundness properties of validEWF-nets (see Definition 3 and 4 on page 79).

The reduction rules abstract from the data perspective and in particular,branching conditions of XOR-split and OR-split tasks are not taken into ac-count [27]. Consequently, choices implemented by an XOR-split or OR-splittask are considered to be non-deterministic. However, it is easy to extend theapproach such that data-based conditions are taken into account.

Reduction rules containing subnet descriptions are only valid when identicalsubstitution subnets are selected for corresponding subnet descriptions in theleft-hand and right-hand side of that rule.

6.4.1 REDUCE-OR-OR

Figure 6.8 illustrates how a REDUCE-OR-OR-pattern as defined in the previ-ous section offers the possibility to select and remove an OR-join in combinationwith a corresponding OR-split, without changing the behaviour.

Figure 6.8: Graphical representation of the REDUCE-OR-OR-rule

A key observation is that the corresponding OR-split input task and OR-joinoutput task in a REDUCE-OR-OR-pattern execute in turn, because of thesafeness requirement defined in Definition 3 on page 79. Suppose, for example,that the input task executes twice before the output task executes. It wouldthen be possible to reach an invalid marking in which a condition simultane-ously contains more than one token.

The semantics of an OR-split prescribes that upon execution one or more of theoutgoing branches are enabled. Another way to look at these semantics, is thatfor each branch it is decided whether or not it becomes enabled or bypassed.The REDUCE-OR-OR-rule shown in Figure 6.8 reflects this point of view, sincethe XOR-split and XOR-join task pairs around each branch decide whetheror not a branch is enabled or bypassed, while the AND-split input task andAND-join output task ensure that for each branch such a decision is taken.Although connection conditions are abstracted from, it is worth mentioningthat each outgoing connection condition and the negation of that conditionof the OR-split task could be copied to one of the fresh XOR-split tasks toimplement the decision to enable or bypass a branch.

Function reduce-or-or(N,P), where N is an R-net and P a REDUCE-OR-OR-pattern, formalises the REDUCE-OR-OR-rule shown in Figure 6.8.

Definition 13 (reduce-or-or). Let N = (C,T,i,o,F,split,join,map) be an R-net and P a REDUCE-OR-OR-pattern of N. Function reduce-or-or replaces


the OR-split behaviour of task iP and the OR-join behaviour of task oP in N byAND behaviour, and adds pairs consisting of an XOR-split task and an XOR-join task around each sequence of nodes between node iP and node oP , i.e.,reduce-or-or(N,P) = (C, T ′, i,o, F ′, split′, join′,map)10 such that:

– T ′ = T ∪ {t(iP ,n) | n ∈ iP •} ∪ {t(n,oP ) | n ∈ •oP }11– F ′ = (F \ (({iP } × iP •) ∪ (•oP × {oP }))) ∪⋃

n1∈iP •∧n2∈•oP∧(n1,n2)∈(F∩(

−−P×

−−P ))∗

({(iP , t(iP ,n1))} ∪ {(t(n2,oP ), oP )} ∪ {(t(iP ,n1), n1)} ∪

{(n2, t(n2,oP ))} ∪ {(t(iP ,n1), t(n2,oP ))})12

– dom(split′) = T ′ and split′(t) =

split(t) t ∈ T \ {iP }AND t = iPXOR13 t ∈ T ′ \ T

– dom(join′) = T ′ and join′(t) =

join(t) t ∈ T \ {oP }AND t = oP

XOR14 t ∈ T ′ \ T

The REDUCE-OR-OR-rule decreases the number of OR-joins (and OR-splits)in an R-net by one. Therefore, it can only be applied a finite number of timesunder the assumption that no other rules can increase the number of OR-joinswithout limitation.

6.4.2 REDUCE-XOR-OR

Figure 6.9 illustrates how both variants of a REDUCE-XOR-OR-pattern of-fer the possibility to select an OR-join that can be reduced to an XOR-join,without changing the behaviour.

Figure 6.9: Graphical representation of the two variants of the REDUCE-XOR-OR-rule

10Function map remains as it is, since none of the fresh tasks is a fold task.11Note that t(iP ,n) and t(n,oP ) are fresh identifiers of the added pairs consisting of an

XOR-split task and an XOR-join task.12(F ∩ (

−−P ×

−−P ))∗ is the reflexive transitive closure of F restricted to the nodes in the

pattern without input and output node. Nodes n1 and n2 are the first and last node of asequential branch between iP and oP .

13Note that an arbitrary split behaviour can be selected for {t(n,oP ) | n ∈ •oP }, becausethe semantics for tasks with a single outgoing connection are equal.

14Note that an arbitrary join behaviour can be selected for t ∈ {t(iP ,n) | n ∈ iP •}, becausethe semantics for tasks with a single incoming connection are equal.

6.4. REDUCTION RULES 91

In general there are only two ways to increase the number of tokens in a sub-stitution subnet that matches a subnet description, that is, by means of anAND-split or OR-split task inside the substitution subnet that has two ormore connections that target at nodes in the substitution subnet, or by meansof one or more connections that originate from nodes outside the substitutionsubnet and target at nodes in the substitution subnet. The subnet descriptionin a REDUCE-XOR-OR-pattern controls both cases. The former cannot hap-pen because these types of split tasks are not allowed in a substitution subnetand the latter can only happen when all these incoming connections originatefrom input node iP .

It is easy to see that this input node of a REDUCE-XOR-OR-pattern can onlyexecute when no token is yet contained in the substitution subnet, because ofthe safeness requirement as defined in Definition 3 on page 79. After all, ifthe input node would be able to execute when the substitution subnet alreadycontains one or more tokens, it would be possible to reach an invalid markingin which a condition simultaneously contains more than one token. Since allincoming connections of OR-join task oP are contained in the substitutionsubnet, it is clear that no marking can be reached that marks more than oneinput condition of oP and that oP can therefore be reduced to an XOR-jointask.

Function reduce-xor-or(N,P), where N is an R-net and P a REDUCE-XOR-OR-pattern, formalises the REDUCE-XOR-OR-rule illustrated by Figure 6.9.

Definition 14 (reduce-xor-or). Let N = (C,T,i,o,F,split,join,map) be anR-net and P a REDUCE-XOR-OR-pattern of N. Function reduce-xor-or re-places the OR-join behaviour of output task oP in N by XOR-join behaviour,i.e., reduce-xor-or(N,P) = (C, T, i,o, F, split, join′,map) such that:

– dom(join′) = T and join′(t) ={

join(t) t ∈ T \ {oP }XOR t = oP

Similar to the REDUCE-OR-OR-rule, the REDUCE-XOR-OR-rule decreasesthe number of OR-joins in an R-net by one. Therefore, it can also only beapplied a finite number of times under the assumption that no other rule canincrease the number of OR-joins without limitation.

6.4.3 REDUCE-AND-OR

Figure 6.10 illustrates how a REDUCE-AND-OR-pattern offers the possibilityto select an OR-join that can be reduced to an AND-join, without changingthe behaviour.

Figure 6.10: Graphical representation of the REDUCE-AND-OR-rule


Each incoming connection of a substitution subnet that matches the subnetdescription in a REDUCE-AND-OR-pattern originates from AND-split taskiP . Moreover, each node in the substitution subnet that has more than oneoutgoing connection to nodes in the substitution subnet, is an AND-split task.OR-join task oP can therefore safely be reduced to an AND-join task, becauseall its input conditions are marked in any enabling marking.

Function reduce-and-or(N,P), where N is an R-net and P a REDUCE-AND-OR-pattern, formalises the REDUCE-AND-OR-rule illustrated by Figure 6.10.

Definition 15 (reduce-and-or). Let N = (C,T,i,o,F,split,join,map) be anR-net and P a REDUCE-AND-OR-pattern of N. Function reduce-and-or re-places the OR-join behaviour of output task oP in N by AND-join behaviour,i.e., reduce-and-or(N,P) = (C, T, i,o, F, split, join′,map) such that:

– dom(join′) = T and join′(t) ={

join(t) t ∈ T \ {oP }AND t = oP

Similar to the REDUCE-OR-OR-rule and the REDUCE-XOR-OR-rule, theREDUCE-AND-OR-rule decreases the number of OR-joins in an R-net byone. Therefore, it can also only be applied a finite number of times underthe assumption that no other rule can increase the number of OR-joins with-out limitation.

6.5 Auxiliary Patterns

In this and the following section, a number of auxiliary patterns and rules aredefined that support the reduction patterns and rules in the previous sections.Figure 6.11 presents the graphical representation of the auxiliary patterns.Note that the name of an auxiliary pattern starts with ‘AUX-’.

(a) AUX-INSERT-OR-SPLIT-pattern (b) AUX-INSERT-JOIN-pattern (variantbased on BASIC-AND-OR-pattern)

(c) AUX-FOLD-pattern (variant withinput condition and output task)

Figure 6.11: Graphical representation of the auxiliary patterns

An AUX-INSERT-OR-SPLIT-pattern (see Figure 6.11(a)) is a BASIC-OR-OR-pattern with the additional restriction that at least one outgoing connection of

6.5. AUXILIARY PATTERNS 93

the input node targets at a node outside the pattern. The AUX-INSERT-OR-SPLIT-rule (as defined in the next section) will be used to relax this restrictionto zero or more by inserting an OR-split task. By doing so, a BASIC-OR-OR-pattern will be created.

An AUX-INSERT-JOIN-pattern is a BASIC-OR-OR-pattern, a BASIC-XOR-OR-pattern, or a BASIC-AND-OR-pattern, with the additional restriction thatat least one incoming connection of the output node originates from a nodeoutside the pattern. The AUX-INSERT-JOIN-rule (as defined in the nextsection) will be used to relax this restriction to zero or more by inserting ajoin task. By doing so, a BASIC-OR-OR-pattern, a BASIC-XOR-OR-pattern,or a BASIC-AND-OR-pattern will be created. Figure 6.11(b) shows the AUX-INSERT-JOIN-pattern that is based on the AUX-AND-OR-pattern.

An AUX-FOLD-pattern behaves, from a black-box point of view, like a singletask with a particular split and join behaviour. Only the input node has in-coming connections that originate from nodes outside the pattern and only theoutput node has outgoing connections that target at nodes outside the pat-tern. Figure 6.11(c) shows an AUX-FOLD-pattern that has an input conditionand an output task with any type of split and join behaviour. However, anycombination of a split and join behaviour for an input node and a split andjoin behaviour for an output node is allowed. As shown in Definition 16, theformal definition of this pattern is more restrictive than the graphical represen-tation, because requirement (i) excludes trivial AUX-FOLD-patterns in whichall nodes have at most one incoming connection that originates from, and atmost one outgoing connection that targets at, a node in the pattern. One ex-ception, an AUX-FOLD-pattern that has a loop in which both iP , oP ∈ P arecontained is allowed.

An AUX-LUCKY-FOLD-pattern is an AUX-FOLD-pattern in which the inputnode has XOR-join behaviour if it has an incoming connection from a nodewithin the pattern and the output node has XOR-split behaviour if it has anoutgoing connection to a node within the pattern. An AUX-NO-OR-FOLD-pattern is more restricted than an AUX-LUCKY-FOLD-pattern, because OR-join tasks are not allowed between the input node and output node of thepattern. As will be explained in Section 6.6.3 on page 97, these last two patternswill be used to temporarily fold a subnet into a single task.

The following definition provides formal specifications of the auxiliary patternsshown in Figure 6.11.

Definition 16 (Auxiliary patterns). Let N = (C,T,i,o,F,split,join, map)be an R-net and P a pattern of N.

– P is an AUX-INSERT-OR-SPLIT-pattern if and only if:(i) P is a BASIC-OR-OR-pattern(ii) iP • 6⊆ P

– P is an AUX-INSERT-JOIN-pattern if and only if:(i) P is a BASIC-OR-OR-pattern, BASIC-XOR-OR-pattern, or BASIC-

AND-OR-pattern(ii) •oP 6⊆ P


– P is an AUX-FOLD-pattern if and only if:(i) ∃n∈P |n • ∩P | > 1 ∨ ∃n∈P |P ∩ •n| > 1 ∨ (oP , iP ) ∈ F

(ii) •−−•

P ⊆ P

(iii)•−−

P• ⊆ P

– P is an AUX-LUCKY-FOLD-pattern if and only if:(i) P is an AUX-FOLD-pattern(ii) iP ∈ PT ⇒ (•iP ∩ P = ∅ ∨ join(iP ) = XOR)(iii) oP ∈ PT ⇒ (oP • ∩ P = ∅ ∨ split(oP ) = XOR)

– P is an AUX-NO-OR-FOLD-pattern if and only if:(i) P is an AUX-LUCKY-FOLD-pattern(ii) ∀

t∈−•P T

(| • t| = 1 ∨ join(t) 6= OR)

6.6 Auxiliary Rules

The auxiliary patterns defined in the previous section are used to define aux-iliary rules for supporting the reduction patterns and rules, without changingthe behaviour. Similarly to the reduction rules, the auxiliary rules are valid forR-nets that originate from valid EWF-nets. This, in order to benefit from thesafeness and soundness properties of valid EWF-nets (see Definition 3 and 4on page 79).

Moreover, the auxiliary rules abstract from the data perspective and in partic-ular, branching conditions of XOR-split and OR-split tasks are not taken intoaccount [27]. Consequently, choices implemented by an XOR-split or OR-splittask are considered to be non-deterministic. However, it is easy to extend theapproach such that data-based conditions are taken into account.

Auxiliary rules containing subnet descriptions are only valid when identicalsubstitution subnets are selected for corresponding subnet descriptions in theleft-hand and right-hand side of that rule.

6.6.1 AUX-INSERT-OR-SPLIT

Figure 6.12 illustrates how an AUX-INSERT-OR-SPLIT-pattern offers the pos-sibility to insert an OR-split task to make an R-net more block-structured. Thebehaviour of the OR-split input task is split into two OR-split tasks with theadvantage that all sequential branches that originate from the fresh OR-splittask ts target at the OR-join output task. By doing so, it might be possible toapply the REDUCE-OR-OR-rule that would not have been possible before.

Figure 6.12: Graphical representation of the AUX-INSERT-OR-SPLIT-rule; afresh OR-split task ts is inserted

6.6. AUXILIARY RULES 95

Function aux-insert-or-split(N,P), where N is an R-net and P an AUX-INSERT-OR-SPLIT-pattern, formalises the AUX-INSERT-OR-SPLIT-rule illustratedby Figure 6.12.

Definition 17 (aux-insert-or-split). Let N = (C,T,i,o,F,split,join,map) bean R-net and P an AUX-INSERT-OR-SPLIT-pattern of N. Function aux-insert-or-split adds a fresh OR-split task ts to N after iP such that all outgoingconnections of iP that target at another node in P become outgoing connectionsof ts and one connection between iP and ts is added, i.e., aux-insert-or-split(N,P) = (C, i,o, T ′, F ′, split′, join′,map)15 such that:

– T ′ = T ∪ {ts} with ts 6∈ T

– F ′ = (F \ ({iP } × (iP • ∩−−•

P ))) ∪ ({ts} × (iP • ∩−−•

P )) ∪ {(iP , ts)}16

– dom(split′) = T ′ and split′(t) ={

split(t) t ∈ TOR t = ts

– dom(join′) = T ′ and join′(t) ={

join(t) t ∈ TAND t = ts

17

After applying the AUX-INSERT-OR-SPLIT-rule, the number of outgoing con-nections of the input node as well as the number of outgoing connections ofthe fresh OR-split task is less than the number of outgoing connections of theinput node before applying the AUX-INSERT-OR-SPLIT-rule. Therefore, theAUX-INSERT-OR-SPLIT-rule can only be applied a finite number of timesunder the assumption that no other rule can introduce fresh OR-split taskswith two or more outgoing connections or add fresh connections to existingOR-split tasks without limitation.

6.6.2 AUX-INSERT-JOIN

Figure 6.13 on the following page illustrates how an AUX-INSERT-JOIN-pattern offers the possibility to insert a join task to make an R-net moreblock-structured. By doing so, the complexity of the OR-join output taskis decreased and it might be possible to apply one or more reduction rules aim-ing at removing OR-joins that could not have been removed without this freshtask. The four variants of the AUX-INSERT-JOIN-rule in Figure 6.13 showthat the join behaviour of the fresh task equals the split behaviour of the inputnode, taking into account that a condition behaves similarly to an XOR-splittask except for the moment at which branching decisions are taken.

The top two variants of the AUX-INSERT-JOIN-rule in Figure 6.13 are basedon the two variants of the BASIC-XOR-OR-pattern18 and indicate that whenat most one out of two or more incoming connections of the OR-join outputtask is enabled in any enabling marking, it is safe to insert an XOR-join task.

15Function map remains as it is, since fresh OR-split tasks ts is not a fold task.16Note that connection (iP , iP ) ∈ F , if present, remains as it is.17Note that an arbitrary join behaviour can be selected for ts, because the semantics for

tasks with a single incoming connection are equal.18That is, a BASIC-XOR-OR-pattern where output task oP has one or more additional

incoming connections.


Figure 6.13: Graphical representation of the four variants of the AUX-INSERT-JOIN-rule; a fresh join task tj is inserted. The top two variants are based onthe BASIC-XOR-OR-pattern, the third variant is based on the BASIC-AND-OR-pattern, and the bottom variant is based on the BASIC-OR-OR-pattern.

The third variant of the AUX-INSERT-JOIN-rule is based on a BASIC-AND-OR-pattern and indicates that when two or more incoming connections of theOR-join output task are simultaneously enabled in any enabling marking, it issafe to insert an AND-join task.

In the bottom variant of the AUX-INSERT-JOIN-rule, the behaviour of theOR-join output task is split into two OR-join tasks with the advantage that allsequential branches that target at fresh OR-join task tj originate from the OR-split input task. Therefore, the fresh OR-join task can be reduced using theREDUCE-OR-OR-rule, possibly after first applying the AUX-INSERT-OR-SPLIT-rule. In other words, a fresh OR-join task tj is inserted to reduce thecomplexity of OR-join output task oP by decreasing the number of incomingconnections, and the OR-join behaviour of tj will be reduced to AND-joinbehaviour afterwards.

Function aux-insert-join(N,P), where N is an R-net and P an AUX-INSERT-JOIN-pattern, formalises the AUX-INSERT-JOIN-rule illustrated by Figure6.13.

Definition 18 (aux-insert-join). Let N = (C,T,i,o,F,split,join,map) be anR-net and P an AUX-INSERT-JOIN-pattern of N. Function aux-insert-joinadds a fresh join task tj to N before oP such that all incoming connections ofoP that originate from another node in P become incoming connections of tjand one connection between tj and oP is added. When iP is a task, the joinbehaviour of tj equals the split behaviour of iP , otherwise tj is an XOR-jointask. That is, aux-insert-join(N, P) = (C, i,o, T ′, F ′, split′, join′,map)19 suchthat:

– T ′ = T ∪ {tj} with tj 6∈ T

19Function map remains as it is, since fresh join tasks tj is not a fold task.


– F ′ = (F \ ((•oP ∩•−−

P )× {oP })) ∪ ((•oP ∩•−−

P )× {tj}) ∪ {(tj , oP )}20

– dom(split′) = T ′ and split′(t) ={

split(t) t ∈ TAND t = tj

21


join(t) t ∈ TXOR t = tj ∧ iP ∈ Csplit(iP ) t = tj ∧ iP ∈ T

After applying the AUX-INSERT-JOIN-rule, the number of incoming connec-tions of the output node as well as the number of incoming connections of thefresh join task tj is less than the number of incoming connections of the out-put node before applying the AUX-INSERT-JOIN-rule. Therefore, the AUX-INSERT-JOIN-rule can only be applied a finite number of times under theassumption that no other rule can introduce fresh join tasks with two or moreincoming connections or add fresh connections to existing OR-join tasks with-out limitation.

6.6.3 AUX-NO-OR-FOLD and AUX-LUCKY-FOLD

From a black-box perspective, some subnets behave like a single task with aparticular split and join behaviour. From the viewpoint of removing as manyOR-joins as possible, it is interesting when such a subnet could temporarilybe replaced by a single fresh task. This will be called folding. By doing so, areduction rule based on a reduction pattern that includes this fresh task mightbecome applicable. Such a reduction rule will be valid, because it is ensuredthat the replaced subnet, called a folded subnet, behaves similarly to the task,called a fold task, that replaced it.

Two auxiliary patterns are used to identify a subnet that could be replacedby a fold task: an AUX-NO-OR-FOLD-pattern and an AUX-LUCKY-FOLD-pattern. The name of the former pattern indicates that it offers to the possibil-ity to select and fold a subnet that contains no OR-join task, with the possibleexception of the input node. The latter pattern serves the same purpose, butit allows all tasks in the pattern to have any type of split and join behaviour.Its name indicates a haphazard attempt to fold a subnet that contains an (irre-ducible) OR-join, in the hope that it enables the reduction of another OR-join.

Figure 6.14 on the next page illustrates with four examples how a subnet couldbe folded into a fold task based on an AUX-LUCKY-FOLD-pattern.22 A freshfold task tf on a right hand side replaces a subnet on the left hand side. Thejoin behaviour of the input node and the split behaviour of the output node arecopied to tf . The four examples show the cases in which the input node andoutput node are both conditions or both tasks for which the join behaviourof the input task equals the split behaviour of the output task. However,

20Note that connection (oP , oP ) ∈ F , if present, remains as it is.21Note that an arbitrary split behaviour can be selected for tj , because the semantics for

tasks with a single outgoing connection are equal.22The attentive reader will notice that the subnet descriptions in Figure 6.14 allow an

AUX-LUCKY-FOLD-pattern to be a sequence of nodes, while Definition 16 on page 93precludes this. This is done for the benefit of readability and does not affect the validity ofthe rule.


the input node is allowed to be a condition as well as a task with any typeof join behaviour, and the output node is, irrespectively of the type of inputnode, allowed to be a condition or a task with any type of split behaviour, i.e.,there are 4 × 4 = 16 possible input-output combinations. Furthermore, theconnections shown with thick arrows that target at the input node or originatefrom the output node are attached to the fold task. All other connections arefolded together with all nodes in the pattern.

Figure 6.14: Graphical representation of the AUX-LUCKY-FOLD-rule; theAUX-LUCKY-FOLD-pattern is replaced by fold task tf

The first two examples in Figure 6.14 are of particular interest because theseexamples starts from the assumption that a task with both XOR-join and XOR-split behaviour behaves similarly to a condition with identical input and outputtasks when one abstracts from the moment that a routing choice is taken. Themoment of choice in case of an XOR-split task occurs when the task completes,while the moment of choice in case of a condition occurs when one of the outputtasks starts its execution. However, it is a reasonable assumption to abstractfrom this, because a subnet will only be temporarily folded into a fold task.Any folded input or output condition will be restored during unfolding.

As shown in Definition 16 on page 93, any AUX-NO-OR-FOLD-pattern isalso an AUX-LUCKY-FOLD-pattern. Therefore, folding based on an AUX-NO-OR-FOLD-pattern works in the same way as folding based on an AUX-LUCKY-FOLD-pattern.

Function Pattern2R-net(N,P), where N is an R-net and P a pattern, extractsa subnet corresponding to P from an R-net. That is, it composes an R-netconsisting of all nodes in the pattern supplemented with all connections in Nbetween those nodes.

Definition 19 (Pattern2R-net). Let N = (C,T,i,o,F,split,join,map) be anR-net and P a pattern of N. Function Pattern2R-net(N,P) returns an R-net composed of all nodes in P supplemented with all connections betweenthose nodes, i.e., Pattern2R-net(N,P) = (C ′, T ′, i′,o′, F ′, split′, join′,map′)such that:

– C ′ = PC


– T ′ = PT

– i′ = iP– o′ = oP

– F ′ = F ∩ (P × P )– dom(split′) = dom(join′) = T ′ and ∀t∈T ′(split′(t) = split(t)∧ join′(t) =

join(t))– dom(map′) = dom(map) ∩ T ′ and ∀t∈dom(map′) map′(t) = map(t)

Function aux-fold(N,P), where N is an R-net and P an AUX-LUCKY-FOLD-pattern or an AUX-NO-OR-FOLD-pattern, formalises the AUX-LUCKY-FOLD-rule (shown in Figure 6.14) and the AUX-NO-OR-FOLD-rule. It replaces asubnet corresponding to P by a fresh fold task tf and links the folded subnetto this fold task with the help of function mapN .

Definition 20 (aux-fold). Let N = (C, T, i,o, F, split, join,map) be an R-net and P an AUX-NO-OR-FOLD-pattern or an AUX-LUCKY-FOLD-patternof N. Function aux-fold replaces P in N by a fresh fold task tf , i.e., aux-fold(N,P) = (C ′, T ′, i,o, F ′, split′, join′,map′) such that:

– C ′ = C \ PC

– T ′ = (T \ PT ) ∪ {tf}– F ′ = (F ∩ ((C ′∪T ′)× (C ′∪T ′)))∪ ((•iP \P )×{tf})∪ ({tf}× (oP •\P ))

– dom(split′) = T ′ and split′(t) =

XOR t = tf ∧ oP ∈ PC

split(oP ) t = tf ∧ oP ∈ PT

split(t) t ∈ T ′ \ {tf}


XOR t = tf ∧ iP ∈ PC

join(iP ) t = tf ∧ iP ∈ PT

join(t) t ∈ T ′ \ {tf}– dom(map′) = (dom(map) ∩ T ′) ∪ {tf}

and map′(t) ={

Pattern2R-net(N,P) t = tfmap(t) t ∈ dom(map) ∩ T ′

Function aux-unfold(N, tf ), which is the inverse function of aux-fold, replacesa fold task tf in an R-net N by the subnet that is linked to this fold taskusing the function mapN . When the input and output nodes are tasks, thejoin behaviour of tf is copied to the input node and the split behaviour of tf iscopied to the output node of the folded R-net. By doing so, any change to thesplit or join behaviour of tf caused by a reduction or auxiliary rule is preserved.Currently, such a change can only be caused by a reduction rule. For futurework, it is important to stress that an XOR-split or XOR-join behaviour of afold task could not be changed when it corresponds to a folded subnet that hasa condition as input or output node.

Definition 21 (aux-unfold). Let N = (C, T, i,o, F, split, join,map) be anR-net, tf ∈ dom(map) a fold task of N, and map(tf ) = (C ′, T ′, i′,o′, F ′, split′,join′,map′) the folded R-net corresponding to tf . Function aux-unfold replacestf in N by map(tf ), i.e., aux-unfold(N, tf ) = (C ′′, T ′′, i,o, F ′′, split′′, join′′,map′′) such that:


– C ′′ = C ∪ C ′

– T ′′ = (T ∪ T ′) \ {tf}– F ′′ = ((F ∪ F ′) ∩ ((C ′′ ∪ T ′′)× (C ′′ ∪ T ′′))) ∪ (•tf × {i′}) ∪ ({o′} × tf•)

– dom(split′′) = T ′′ and split′′(t) =

split(t) t ∈ T \ {tf}split′(t) t ∈ T ′ \ {o′}split(tf ) t ∈ T ′ ∩ {o′}

23

– dom(join′′) = T ′′ and join′′(t) =

join(t) t ∈ T \ {tf}join′(t) t ∈ T ′ \ {i′}join(tf ) t ∈ T ′ ∩ {i′}

– dom(map′′) = (dom(map) \ {tf}) ∪ dom(map′)

and map′′(t) ={

map(t) t ∈ dom(map) \ {tf}map′(t) t ∈ dom(map′)

6.7 Algorithm

Finally, after the introduction of the reduction rules and auxiliary rules, it istime to presents a pseudo-code algorithm that typically removes lots of OR-joins from a valid EWF-net. The algorithm first transforms an EWF-net intoan R-net. Then the algorithm iteratively selects a reduction pattern or anauxiliary pattern in the R-net and applies the corresponding rule to it. Whenno reduction rule or auxiliary rule can be applied anymore, the adapted R-netis completely unfolded, transformed back into a valid EWF-net, and finallyoutputted. Appendix F illustrates the algorithm using a larger example.

The order in which rules are applied is important, because it directly affects thecharacteristics of the resulting net. The philosophy behind the prioritisationof the rules in the algorithm is to remove as many OR-joins as possible, whileinserting as little fresh tasks as possible. A fresh task should only be insertedwhen it potentially contributes to the removal of an OR-join in one of thefollowing steps of the algorithm.

Obviously, top priority is given to the three reduction rules, i.e., the REDUCE-OR-OR-rule, REDUCE-XOR-OR-rule, and REDUCE-AND-OR-rule. The or-der in which these reduction rules are applied is irrelevant, because they aremutual exclusive. The next priority is given to the AUX-NO-OR-FOLD-rulethat folds a maximal AUX-NO-OR-FOLD-pattern into a fresh fold task. Thisauxiliary rule has a higher priority than the other auxiliary rules, because itsupports the reduction rules without inserting any fresh tasks or folding anyOR-join.24 Note that it would be a waste of effort to fold an AUX-NO-OR-FOLD-pattern when it is not maximal, because a smaller version of the enclos-ing pattern would still be present and waiting to be folded after the applyingthe rule.

If none of the above rules applies, the AUX-INSERT-OR-SPLIT-rule and AUX-INSERT-JOIN-rule are applied. Currently, the algorithm does not preclude thepossibility that a fresh task is inserted without a clear purpose, i.e., a fresh task

23The join behaviour of an input task and the split behaviour of an output task is copiedback from tf , since it may have been changed.

24Note that the input node of this pattern might be an OR-join. However, this OR-joinbehaviour is then copied to the fold task, so that it can still be removed.

6.7. ALGORITHM 101

might be inserted without contributing to the removal of an OR-join in oneof the following steps of the algorithm. However, the number of insertions islimited by applying these rules to maximal AUX-INSERT-OR-SPLIT-patternsand AUX-INSERT-JOIN-patterns only.

The AUX-LUCKY-FOLD-rule has the lowest priority. It is used as a last resortand folds a minimal AUX-LUCKY-FOLD-pattern into a fresh fold task. Thename of this rule indicates that a haphazard attempt is made to fold a subnetthat contains one or more (currently) irreducible OR-joins, in the hope thatit contributes to the removal of another OR-join in one of the following stepsof the algorithm. An AUX-LUCKY-FOLD-pattern is only folded when it isminimal. This, in order to reduce the possibility that an OR-join is foldedand cannot be removed anymore. Although the order in which such a patternis selected could be crucial, the algorithm selects one in a non-deterministicmanner.

Definition 22 (Algorithm). Let N = (C,i,o,T,F,split,join) be a valid EWF-net.

1. X ::= EWF2R(N)2. while ∃t∈TX

join(t) = OR and any of the following rules can be applied(a) if ∃P (P = REDUCE-OR-OR-pattern)25

then X ::= reduce-or-or(X,P)(b) else if ∃P (P = REDUCE-XOR-OR-pattern)

then X ::= reduce-xor-or(X,P)(c) else if ∃P (P = REDUCE-AND-OR-pattern)

then X ::= reduce-and-or(X,P)(d) else if ∃P (P = maximal AUX-NO-OR-FOLD-pattern)

then X ::= aux-fold(X,P)(e) else if ∃P (P = maximal AUX-INSERT-OR-SPLIT-pattern)

then X ::= aux-insert-or-split(X,P)(f) else if ∃P (P = maximal AUX-INSERT-JOIN-pattern)

then X ::= aux-insert-join(X,P)(g) else if ∃P (P = minimal AUX-LUCKY-FOLD-pattern)

then X ::= aux-fold(X,P)3. while dom(mapX) 6= ∅4. choose tP ∈ dom(mapX)26

5. X ::= aux-unfold(X, tP )6. output R2EWF(X)

To make a reasonable case that the algorithm terminates, it will be demon-strated that each rule can only be applied a finite number of times.

The AUX-INSERT-JOIN-rule introduces a fresh join task in front of an OR-join output task. An important observation is that after applying the rule,the number of incoming connections of the output node as well as the numberof incoming connections of the fresh task is less than the number of incomingconnections of the output node before applying the rule. Since this rule requires

25This is short for selecting an arbitrary REDUCE-OR-OR-pattern P, if such a P exists.26Construct choose arbitrarily selects an item from a set.


the existence of a pattern with an OR-join output node that has at least twoincoming connections and no other rule introduces an additional OR-join task,it can only be applied a finite number of times.27 A similar line of reasoningcan be constructed for the AUX-INSERT-OR-SPLIT-rule.

The three reduction rules for removing OR-joins decrease the number of OR-join tasks in an R-net. The only rule that might insert a fresh OR-join task isthe AUX-INSERT-OR-SPLIT-rule. As discussed above, this auxiliary rule canonly be applied a finite number of times. Therefore, the reduction rules canalso only be applied a finite number of times.

Finally, the AUX-NO-OR-FOLD-rule and the AUX-LUCKY-FOLD-rule re-place a nonempty subnet, which is not a sequence (see Section 6.5 on page 92),by a single task and therefore decrease the sum of the number of connectionsand the number of nodes. If the replaced subnet comprises a single task thathas a direct connection to itself, only the number of connections decreases. Inall other cases, the number of connections as well as the number of nodes de-creases. Since it has already been shown that all other rules that insert nodesor conditions can only be applied a finite number of times, this implies thatthese two rules can also only be applied a finite number of times.

6.8 Possible Extensions

Particular OR-joins in an R-net will still be irreducible with the help of thealgorithm presented in the previous section. Some of these OR-joins mightsimply be irreducible by nature, while others could be reduced by introducingadditional patterns and rules. To point out directions for further research, theinitial impetus to more generic versions of some of the already defined patternsand rules will now be given.

6.8.1 Generic BASIC-XOR-OR and REDUCE-XOR-OR

Figures 6.15(a) and 6.15(b) on the next page repeat the two variants of theREDUCE-XOR-OR-pattern as introduced in Section 6.3 on page 85. Figure6.15(c) presents a more generic version that replaces both of these patterns. Itis more generic because it allows one or more, mutually exclusive input nodesiP1, iP2, . . . that are either a condition or an XOR-split task. Note that Figure6.15(c) shows these two types of input nodes, but that any number (indicatedby the two black dots between the input nodes) and combination of these twotypes of input nodes is allowed.

The generic REDUCE-XOR-OR-pattern offers the possibility to select an OR-join that can be reduced to an XOR-join, because it has particular structuralproperties. It contains three sets of mutually exclusive nodes, that is, the setof input nodes iP1, iP2, . . . , the set of conditions c1, c2, c3, . . . , and the set of

27Note that the AUX-NO-OR-FOLD-rule or the AUX-LUCKY-FOLD-rule might inserta fold task with OR-join behaviour. However, this will not increase the number of OR-joinsin an R-net, because it will always be accompanied by the folding of one or more OR-jointasks in the folded sub net.

6.8. POSSIBLE EXTENSIONS 103

(a) REDUCE-XOR-OR-pattern (variant 1) (b) REDUCE-XOR-OR-pattern (variant 2)

(c) Generic REDUCE-XOR-OR-pattern

Figure 6.15: Generic REDUCE-XOR-OR-pattern

input conditions •oP of the OR-join output task. Note that the set of condi-tions c1, c2, c3, . . . comprises one or more conditions, but that Figure 6.15(c)shows this set using three conditions with black dots in between for reasonsof comprehensibility. The mutual exclusivity of the conditions in •oP impliesthat no marking can be reached that marks more that one input condition ofoP and that oP can therefore be reduced to an XOR-join task.

As shown in Figure 6.15(c), the generic REDUCE-XOR-OR-pattern containsmultiple subnet descriptions that are similar to the ones used in the originalpatterns in Figures 6.15(a) and 6.15(b), with the exception of the connectionsets attached to the boundary descriptions. As discussed in Section 6.4.2 onpage 90, a substitution subnet of such a subnet description has the structuralproperty that at most one condition within it can be marked at any pointin time. This means that any input node and subsequent subnet descriptionof the generic REDUCE-XOR-OR-pattern models a nondeterministic choiceto mark at most one of the conditions c1, c2, c3, . . . , because such a subnetdescription has at least one outgoing connection to each of these conditions.Because of the safeness requirement as defined in Definition 3 on page 79, theinput nodes iP1, iP2, . . . as well as the conditions c1, c2, c3, . . . are thereforemutually exclusive. Otherwise, it would be possible that more than one tokenends up in any of the conditions c1, c2, c3, . . .

A similar line of reasoning applies to the subnet description between conditionsc1, c2, c3, . . . and output node oP of the generic REDUCE-XOR-OR-patternshown in Figure 6.15(c). The mutual exclusivity of conditions c1, c2, c3, . . .in combination with the structural property of the subnet description that atmost one condition within it can be marked at any point in time, ensures thatthe input conditions of the OR-join output task, i.e., •oP , are also mutuallyexclusive and therefore that oP can be reduced to an XOR-join task.

From another perspective, the generic REDUCE-XOR-OR-patterns allows mul-


tiple input nodes as long as there is a nonempty set of mutually exclusive con-ditions in the pattern such that a directed path exists from any of the inputnodes to any of the mutually exclusive conditions and then to the output node.Apart from this additional restriction, the conditions c1, c2, c3, . . . are similarto any other condition in the pattern. Therefore, the conditions c1, c2, c3, . . .are subject to the same connection restrictions – that is, one or more incomingconnections from, and one or more outgoing connections to nodes in the pat-tern, and zero or more outgoing connections to nodes outside the pattern – asdefined by the condition descriptions in any of the similar subnet descriptionsin the pattern.

The generic REDUCE-XOR-OR-pattern requires an extension of Definition 9on page 85 in order to allow a pattern to have more than one input node.Furthermore, it also requires an extension of the definition of a subnet descrip-tion in order to allow a subnet description to be defined between more thantwo nodes. However, this is not formalised since the purpose of this section ismerely to start a discussion.

As shown in Figure 6.16, a generic version for both variants of the BASIC-XOR-OR-pattern, which are used in the definition of an AUX-INSERT-JOIN-pattern, could be introduced analogously. Note that a BASIC-XOR-OR-patterndiffers from a REDUCE-XOR-OR-pattern by allowing the OR-join output taskto have additional incoming connections from outside the pattern. This isalso the only difference between the generic BASIC-XOR-OR-pattern and thegeneric REDUCE-XOR-OR-pattern.

Figure 6.16: Generic BASIC-XOR-OR-pattern

It is rather straightforward to adapt the rules to support the more generic pat-terns. Figures 6.17 and 6.18 on the next page illustrate the adapted REDUCE-XOR-OR-rule and AUX-INSERT-JOIN-rule.


Figure 6.17: Removing an OR-join using the generic REDUCE-XOR-OR-rule

Figure 6.18: Insertion of a fresh join task tj using the generic BASIC-XOR-OR-rule


6.8.2 Generic BASIC-AND-OR and REDUCE-AND-OR

Similar to the previous section, the initial impetus to more generic versionsof the BASIC-AND-OR-pattern and the REDUCE-AND-OR-pattern are dis-cussed to point out concrete ideas for further research. Figure 6.19(a) presentsthe REDUCE-AND-OR-pattern as introduced in Section 6.3 on page 85 andFigure 6.19(b) shows the generic REDUCE-AND-OR-pattern. The latter pat-tern is more generic, because it allows one or more, mutually exclusive AND-split input tasks.

(a) REDUCE-AND-OR-pattern

(b) Generic REDUCE-AND-OR-pattern

Figure 6.19: Generic REDUCE-AND-OR-pattern

The generic REDUCE-AND-OR-pattern offers the possibility to select an OR-join that can be reduced to an AND-join, because it has particular struc-tural properties. As shown in Figure 6.19(b), the generic REDUCE-AND-OR-pattern contains multiple subnet descriptions that are similar to the ones usedin the original pattern in Figure 6.19(a), with the exception of the connectionsets attached to the boundary descriptions. As discussed in Section 6.4.3 onpage 91, a substitution subnet of such a subnet description has the structuralproperty that either all or none of the branches will be executed. This meansthat the execution of any AND-split input task of the generic REDUCE-AND-OR-pattern eventually causes all the conditions c1, c2, c3, . . . to be marked –possibly simultaneously –, because the subsequent subnet description of aninput task has exactly one outgoing connection to each of these conditions.Because of the safeness requirement as defined in Definition 3 on page 79,the input tasks iP1, iP2, . . . are therefore mutually exclusive. Otherwise, itwould be possible that more than one token ends up in any of the conditionsc1, c2, c3, . . . . Note that the set of conditions c1, c2, c3, . . . comprises one ormore conditions, but that Figure 6.19(b) shows this set using three conditionswith black dots in between for reasons of comprehensibility.

A similar line of reasoning applies to the subnet description between conditionsc1, c2, c3, . . . and output node oP of the generic REDUCE-AND-OR-patternshown in Figure 6.19(b). The structural property of the subnet description that


all branches will be executed when all conditions c1, c2, c3, . . . are (eventually)marked, ensures that the input conditions of the OR-join output task, i.e., •oP ,are marked in any enabling marking and therefore that oP can be reduced toan AND-join task.

From another perspective, the generic REDUCE-AND-OR-patterns allows mul-tiple AND-split input tasks as long as there is a nonempty set of conditions inthe pattern such that a directed path exists from any of the input tasks to anyof the conditions c1, c2, c3, . . . and then to the output node.

As discussed in the previous section, the definitions of a pattern and a subnetdescription need to be extended in order to allow a pattern to have more thanone input node and to allow a subnet description to be defined between morethan two nodes. Again, this is not formalised since the purpose of this sectionis merely to start a discussion.

As shown in Figure 6.20, a generic version of the BASIC-AND-OR-pattern,which is used in the definition of an AUX-INSERT-JOIN pattern, could beintroduced analogously. Note that a BASIC-AND-OR-pattern differs froma REDUCE-AND-OR-pattern by allowing the OR-join output task to haveadditional incoming connections from outside the pattern. This is also theonly difference between the generic BASIC-AND-OR-pattern and the genericREDUCE-AND-OR-pattern.

Figure 6.20: Generic BASIC-AND-OR-pattern

It is rather straightforward to adapt the rules to support the more genericpatterns. Figures 6.21 and 6.22 on the following page illustrate the adaptedREDUCE-AND-OR-rule and AUX-INSERT-JOIN-rule.


Figure 6.21: Removing an OR-join using the generic REDUCE-AND-OR-rule

Figure 6.22: Insertion of a fresh join task tj using the generic BASIC-AND-OR-rule

6.9. CONCLUSIONS 109

6.9 Conclusions

Various modelling languages and notations use OR-joins. However, OR-joinsare rather problematic when implementing workflows. First of all, there are allkinds of semantical problems. Second, any reasonable implementation of theOR-join is computational expensive as it requires repeated state-space explo-rations.

In this chapter, a contribution to the troublesome semantics of the OR-join hasbeen made by presenting a approach that illustrates that the structure of a pro-cess model provides a promising starting point for removing OR-joins withoutchanging the behaviour of the model. First, so-called EWF-nets and R-netshave been defined as an abstraction mechanism, for making the approach appli-cable to a wide range of process models in all kinds of languages and notations,including Protos, BPMN, EPCs, and YAWL. Second, a graphical notation forpattern matching over R-nets has been introduced. Third, reduction patternsand rules have been presented for removing OR-joins without changing the be-haviour. Fourth, auxiliary patterns and rules have been presented that supportand enable the reduction patterns for rules. Finally, a pseudo-code algorithmthat typically removes lots of OR-joins based on the reduction rules and aux-iliary rules has been presented. Figure 6.23 on the next page illustrates theapplicability of the algorithm to BPMN. Note that any changes to the structureof the BPMN model are printed in bold face. Appendix F contains a detaileddiscussion of this example.

Particular OR-joins are still irreducible using the current set of reduction andauxiliary rules. Some of these OR-joins might simply be irreducible by nature,while others could be reduced by extending the pattern matching approach.To point out directions for further research, the initial impetus to more genericversions of some of the currently defined patterns and rules has been given.Since all patterns and rules are defined for valid R-nets only, further researchwill also be needed to find out whether a similar approach can be applied toless restrictive models. For example, one could try to define patterns and rulesfor models that are not safe or sound.


Figure 6.23: Illustration of the applicability of the reduction approach toBPMN, i.e., the bottom BPMN model results from applying the reductionand auxiliary rules to the top BPMN model.

Chapter 7

Conclusions andRecommendations

In finally completing the thesis at hand, the current chapter summarises themain conclusions. In addition, a number of recommendations about the appli-cability and practical usefulness of these conclusions are presented.

7.1 Conclusions

The conclusions are divided into three parts. First, some conclusions withrespect to the BPMN evaluation are drawn. Second, the conclusions about themapping from Protos to BPMN and back are presented. Finally, a number ofconclusions about the reducible OR-joins are discussed.

BPMN Evaluation

Over the last few years, the BPMN specification has become a standard graph-ical notation for capturing business processes – especially in the early stages ofsystem development – that is readily recognisable and comprehensible by allbusiness stakeholders. Moreover, BPMN provides a means to visualise variousXML languages primarily designed and optimised for the execution of businessprocesses.

BPMN includes little or no support for the modelling of organisational struc-tures, resources, functional breakdowns, data, strategy, and business rules.From an ontological point of view, BPMN lacks a representation for states,history, and system structure. The BPMN specification relates to a number ofother specifications, including BPEL4WS, XPDL, BPDM, and UML ActivityDiagrams. A partial example mapping from BPMN to BPEL4WS plays an im-portant part in the BPMN specification. Although often presumed otherwise,the construction of complete mapping from BPMN to BPEL4WS is anythingbut trivial.

111

112 CHAPTER 7. CONCLUSIONS AND RECOMMENDATIONS

Currently, the BPMN specification is subject to multiple interpretations, be-cause it lacks a formal semantics and a file format. It appears that the develop-ers within the OMG are in disagreement about whether the ultimate purposefor BPMN should be just a diagram notation or a standard notation with richand precise semantics for executable process design. Although some scientificattempts are made to formalise the semantics of BPMN, it is reasonable toconclude that a complete formalisation for BPMN will take some time (if atall possible).

An extensive tools evaluation has been conducted. The greater part of theevaluated tools embeds support for the BPMN standard in a larger modellingenvironment that is not freeware and uses a proprietary XML file format tostore models. The BPMN specification is taken rather seriously by the vendorsin the BPM marketplace, because sixteen out of the twenty-three tools conformto the specification for more than 70%, ten tools for at least 90%, and two toolsprovide complete support.

Mapping from Protos to BPMN and back

The feasibility and profitability of supporting BPMN in future versions of Pro-tos has been shown with the help of two mappings. The mapping from Protosto BPMN shows that the control flow perspective in Protos can for the greaterpart be successfully translated to BPMN, with the exception of Buffers, anumber of Trigger types, and some other minor issues. The data and resourcecapabilities of Protos can be mapped only to a small degree. The mapping fromBPMN to Protos shows that the majority of BPMN concepts can be mappedto Protos. A Protos model corresponds to a Private (internal) business processin BPMN, which implies that BPMN concepts like swimlanes, message flows,and transactions can only partially be represented in Protos. Moreover, someextensions to Protos are required to properly represent BPMN concepts likecompensation and exception handling.

A proof of concept consisting of two XSL transformations between Protos andILOG JViews BPMN Modeler has been implemented. It demonstrates the fea-sibility and viability of the mapping from Protos to BPMN and back. More-over, the proof-of-concept implementation allows one to get acquainted withthe mappings by means of experiments and provides a tangible way of commu-nicating the potential of BPMN for Protos.

Reducible OR-joins

Various modelling languages and notations use OR-joins. However, OR-joinsare rather problematic when implementing workflows. First of all, there areall kinds of semantical problems. Second, any reasonable implementation ofthe OR-join is computational expensive as it requires repeated state-space ex-plorations. In this thesis, a contribution to the troublesome semantics of theOR-join has been made by presenting a approach that illustrates that thestructure of a process model provides a promising starting point for removingOR-joins without changing the behaviour of the model. First, so-called EWF-

7.2. RECOMMENDATIONS 113

nets and R-nets have been defined as an abstraction mechanism, for making theapproach applicable to a wide range of process models in all kinds of languagesand notations, including Protos, BPMN, EPCs, YAWL, etc. Second, a graph-ical notation for pattern matching over R-nets has been introduced. Third,reduction patterns and rules have been presented for removing OR-joins with-out changing the behaviour. Fourth, auxiliary patterns and rules have beenpresented that support and enable the reduction patterns for rules. Finally,a pseudo-code algorithm that typically removes lots of OR-joins based on thereduction rules and auxiliary rules has been presented.

7.2 Recommendations

Based on the main conclusions, a number of recommendations about the ap-plicability and practical usefulness of these conclusions are presented:

1. Incorporate BPMN into Protos The mapping from Protos for BPMNand back presents a tangible and convincing proof for the potential ofBPMN for Protos. Moreover, the proof-of-concept implementation demon-strates the feasibility and viability of implementing support for a largesubset of BPMN in Protos. It is therefore recommended that BPMN isincorporated into Protos.

2. Harmonise Protos semantics The mapping from Protos to BPMNand vice-versa required the introduction of a more formal semantics forProtos. Another more formal, and possibly deviating, semantics for Pro-tos has been called into being to enable Protos Active. It is recommendedthat these and other semantics for Protos are harmonised into a single,coherent semantics.

3. Preserve the strengths of Protos The largely unrestricted and infor-mal character of Protos has proven to be one of its key strengths, becauseit allows modelers to model complex business processes without worryingabout too much detail. Therefore, the establishment of a more formalsemantics for Protos, among others for the purpose of BPMN and ProtosActivate, should not be pursued at the expense of the user-friendliness ofProtos.

4. Apply OR-join Research The contribution to the troublesome seman-tics of OR-joins is generic and applicable to various modeling languagesand notations. It is therefore interesting for Pallas Athena to explore itspotential in the context of Protos, Protos Activate, and FLOWer.

Appendix A

Protos in a Nutshell

In this appendix a succinct introduction to Protos is given. This introductionis based on the Protos 8.0 User Manual 2006.

A.1 Triggers

A Trigger Object models an event that may occur during the course of a process.As shown in Figure A.1(a) , Protos differentiates between Triggers of type Time,Telephone, Mail, File, Software, Human, E-business, and E-mail. Moreover,Protos allows for Cyclic Triggers to indicate that the occurrence of an eventtakes place in consecutive cycles, i.e., over several periods, one after another.Figure A.1(b) shows an example of a Cyclic Time Trigger, where the blue arrowon the Trigger Object indicates the cyclic behaviour.

(a) Trigger types (b) Cyclic Time Trigger

Figure A.1: Trigger Objects in Protos

A.2 Statuses

A Status Object models a state or a moment of ‘rest’ in a process betweenActivities, Sub-Processes, and Triggers.1 The graphical representation for aStatus Object is shown in Figure A.2 on the next page.

Figure A.3 on the following page illustrates the split and join behaviour of aStatus in Protos. First, a Status with a single incoming connection and multiple

1Note that a Status Object corresponds to a place in a Petri net.

115

116 APPENDIX A. PROTOS IN A NUTSHELL

Figure A.2: Status Object in Protos

outgoing connections represents a Deferred Choice workflow pattern [16], i.e.,exactly one of the outgoing connections is chosen based on the occurrence ofsome events. Second, a Status with multiple incoming connections and a singleoutgoing connection represents a Simple Merge workflow pattern [16], i.e., theoutgoing connection is enabled for each enablement of an incoming connection.Finally, a Status with multiple incoming and multiple outgoing connectionsrepresents a Simple Merge workflow pattern on this input side and either aDeferred Choice or a Milestone workflow pattern on the output side. In aMilestore pattern, an Activity is only enabled if the process is in a particularstate (modelled by a Status in Protos). See Section 3.3.1 on page 36 for moredetails.

(a) Deferred Choice (b) Simple Merge (c) Simple Merge on input side; DeferredChoice or Milestone on output side

Figure A.3: Behaviour of a Status in Protos

A.3 Activities and Sub-Processes

An Activity Object models an atomic amount of work which forms a single stepin a process. As shown in Figure A.4, Protos differentiates between Activitiesof type Basic, Logistics, Authorise, Communication, and Check. In addition,an Activity has several other properties. Figure A.5 on the next page shows thegraphical representation of some of these properties applied to a Basic Activity.In this thesis, it is assumed that one or two green squares on an Activity objectindicate that the activity is instantiated upon instantiation of the enclosingSub-Process or complete process model, respectively. Moreover, one or twored squares on an Activity object indicate that the activity terminates theenclosing Sub-Process or the complete process model, respectively.

Figure A.4: Activity Objects in Protos

A Multiple Activity Object has a three-dimensional icon to indicate that itmay be carried out several times, possibly simultaneously. A User Initiative

A.3. ACTIVITIES AND SUB-PROCESSES 117

Activity Object has a blue square to indicate that an end user is required toperform that activity. A Batch Activity Object has a black square to indicatethat it is carried out for a large number of cases in a single cycle. A SelectiveBatch Activity Object has an additional gray square to indicate that the batchshould be processed according to a specific sequence.

Figure A.5: Properties for Activity Objects in Protos

A Sub-Process Object models a part of a process that serves a logical groupingof Activities, Triggers, Statuses, and other Sub-Processes. Figure A.6(a) showsthe graphical representation of a Sub-Process. As shown in Figure A.6(b), theproperties for a Sub-Process are analogous to the ones for an Activity.

(a) Sub-process (b) Sub-process types

Figure A.6: Sub-Process Objects in Protos

Figure A.7 illustrates the default split and join behaviour of an Activity ora Sub-Process in Protos. First, an Activity or a Sub-Process with a singleincoming connection and multiple outgoing connections represents a ParallelSplit workflow pattern [16], i.e., all outgoing connections are enabled in par-allel upon completion. Second, an Activity or a Sub-Process with multipleincoming connections and a single outgoing connection represents a Synchroni-sation workflow pattern [16], i.e., the Activity or Sub-Process is enabled if allincoming connections are enabled. Finally, an Activity or a Sub-Process withmultiple incoming and multiple outgoing connections represents a combinationof these patterns.

(a) Parallel Split (b) Synchronisation (c) Synchronisation on input side;Parallel Split on output side

Figure A.7: Default behaviour of an Activity or a Sub-Process in Protos

The simulations properties2 of an Activity can be used to define other split andjoin behaviours for that Activity. Note that a Sub-Process has no simulation

2Note that these properties are an extension to standard Protos.


properties. Figure A.8 shows the Incoming Connections and Outgoing Connec-tions properties on the Simulation Tab of an Activity Object. The IncomingConnections property can be set to ‘and join’ (default), ‘xor join’, or ‘or join’.The Outgoing Connections property can be set to ‘and split’ (default), ‘xorsplit’, or ‘or split’.

Figure A.8: Incoming Connections and Outgoing Connections properties on theSimulation Tab are used to define other behaviour for an Activity in Protos

A.4 Buffers

A Buffer Object models a storage place for information that is used in a process,e.g. Archives. The graphical representation for a Buffer Object is shown inFigure A.9.

Figure A.9: Buffer Object in Protos

A.5 Connections

A Connection is used to specify the order in which Activities and Sub-Processesneed to be performed. An Off-Page Connector is an indirect Connection be-tween two Objects that are located in different Sub-Processes. A Buffer Con-nection is used to add or remove work at hand to or from a storage place.Figures A.10 on the facing page shows the graphical representation of theseConnections. The graphical representation of an Off-Page Connector is similar

A.6. DOCUMENTS AND DATA 119

to a Connection except that it consists of two parts in different Sub-Processeswhere the black squares indicate the relation between these parts.

(a) Connection (b) Off-Page Connector (c) Buffer Connection

Figure A.10: Connections and Buffer Connections in Protos

A Trigger Connection is used to connect a Trigger Object to another Trigger,Activity, Sub-Process, or Status Object. Protos has three different types ofTrigger Connections that target at a Trigger Object, that is, to Set, TurnOff, or Restart a Trigger. Protos also has three different types of TriggerConnections that originate from a Trigger Object, that is, to Start, Restart,or Cancel an Object when the event occurs that is modelled by the TriggerObject. Figures A.11 and A.12 show the graphical representations of all theseTrigger Connection stypes.

(a) Set (b) Turn Off (c) Restart

Figure A.11: Trigger Connections that target at a Trigger Object in Protos

(a) Start (b) Restart (c) Cancel

Figure A.12: Trigger Connections that originate from a Trigger Object in Pro-tos

A.6 Documents and Data

A Folder Object, as shown in Figure A.13(a) on the following page, models acollection of Documents. A Document Object models a document that is in-volved in a process. As shown in Figure A.13(b), Protos differentiates betweenDocuments of type Paper, Email, File, and Fax. Furthermore, Protos providesthe opportunity to model whether a Document is received or sent. An InternalDocument is used internally, while an In, Out, In/Out, or Out/In Documentis received, sent, or both. Figure A.13(c) shows the graphical representationsof these Documents.

A Data Element Object models the smallest unit of information in a process. Asshown in Figure A.14(a), Protos differentiates between Data Elements of typeNumber, Date, Yes/No, General, Text, and Decimal Number. A Data GroupObject, as shown in Figure A.14(b), models a collection of Data Elements.


(a) Folder (b) Document types (c) Properties for Documents

Figure A.13: Document Objects in Protos

(a) Data Element types (b) Data Group

Figure A.14: Folder, Data Element, and Data Group Objects in Protos

A.7 Applications

An Application Object models software package of a system that is used in theprocess, e.g. a word processor. As shown in Figure A.15, Protos allows anApplication to be automatic or not, that is, it starts either automatically orrequires an end user to start it.

(a) Application (b) Automatic Application

Figure A.15: Application Objects in Protos

A.8 Roles

A Role Object models who is allowed to carry out an Activity, is responsiblefor it, or is involved in it, e.g. an assessor. A Role Group Object is used for thesame purposes, but it consists of a collection of Role Objects, e.g. an assessorgroup. A Team Object models how work is distributed in a process, e.g. apostal code team. Figure A.16 presents the visual representation of a RoleObject, a Role Group Object, and a Team Object.

(a) Role types (b) Role Group (c) Team

Figure A.16: Role, Role Group, and Team Objects in Protos

A.9. PROTOS PROCESS MODELER 121

Protos differentiates between Internal Roles and External Roles, i.e., this indi-cates whether the person carrying out the role forms part of the organisation(s)in which the modelled process takes place. An Internal Role Object has a bluecap as its icon, while the icon for an External Role is a red cap. The icon ofa Role Group Object has two caps in it where the colours of the caps providean indication for the composition of the group: two blue caps indicate InternalRoles only, two red caps indicate External Roles only, and one blue and onered cap indicates a combination of Internal Roles and External Roles.

Moreover, Protos allows for connections between Roles and Role Groups tomodel hierarchical relationships between persons that carry out a specific role.Figure A.17 shows an example in which a claims manager is at the highest levelof the hierarchy and an administrative assistant at the lowest level.

Figure A.17: Hierarchical Relationships between Roles or Role Groups in Pro-tos

A.9 Protos Process Modeler

Figure A.18 on the next page puts the Objects in the preceding paragraphsin the context of the Protos Process Modeler by showing a number of screencaptures. The top most window is the main window of the modeler containingfive areas, i.e., the Process, Data, Roles, Role Groups, and Teams Area. TheProces Area describes the workflow of a Process Model using Trigger, Activity,Sub-Process, Buffer, and Connection Objects. Information and Applicationsinvolved in executing an Activity or a Sub-Process in the Process Model aremodelled in the Data Area with the help of Folder, Document, Data Group,and Data Element Objects. The Roles and Role Group Areas allow the creationof the Roles and Role Group to connect Executors, those who have responsi-bilities, and those who are involved, to a Process Model. The Objects Paletteis displayed in the lower-right corner of the main window.

The right window presents the Executor Analysis in the form of Swimlanes,which shows the relationships between Roles or Role Groups and Activities orSub-Processes in the Process Model. Similarly, Protos offers a ResponsibilityAnalysis, Team Analysis, Data Analysis, and Applications Analysis. The leftwindow presents a Data Analysis in tabular form, which shows the relation-ships between Data and Activities or Sub-Processes. Protos provides differentexports, e.g., an HTML export and an RTF export.

122A

PP

EN

DIX

A.

PR

OT

OS

INA

NU

TSH

ELL

Figure A.18: Protos Process Modeler

Appendix B

BPMN in a Nutshell

In this appendix a succinct introduction to the Business Process ModelingNotation (BPMN) standard is given. This introduction is based on the OMGFinal Adopted BPMN Specification [26] and an introductory paper by StephenA. White [24], the author of this specification.

BPMN defines a Business Process Diagram (BPD) based on flowcharting tech-niques and graphically shows a business process model consisting of a networkof graphical objects. A BPD contains up to four categories of elements: FlowObjects, Connecting Objects, Swimlanes, and Artifacts. BPMN distinguishesbetween a Core Element Set that contains only the elements that define thebasic look-and-feel and a Complete Element Set that extends the Core ElementSet in order to be able to handle more advanced modelling situations.

B.1 Flow Objects

BPMN defines three types of Flow Objects: Events, Gateways, and Activities.

B.1.1 Events

An Event is something that happens during the course of a business process.It affects the flow of the process and usually has a cause (trigger) or an impact(result). The Core Element Set in BPMN contains only three types of Events:Start Events, Intermediate Events, and End Events. Figure B.1 on the followingpage shows the visual representation of these Events within Sequence Flow (seeSection B.4 on page 128).

A Process may have zero or more Start Events and End Events, but an EndEvent must be present if a Start Event is used, and vice-versa. A Start Eventhas no incoming Sequence Flow. A Start Event with multiple outgoing Se-quence Flow, see Figure B.1(a), models an AND-split, i.e., it corresponds tothe Parallel Split workflow pattern [16]. An Intermediate Event has at mostone incoming and one outgoing Sequence Flow. An Intermediate Events setsa delay or breaks to wait for a message, or models compensation or exception

123

124 APPENDIX B. BPMN IN A NUTSHELL

(a) Start Event (b) Intermediate Event (c) End Event

Figure B.1: Events within Sequence Flow in BPMN

flow when attached to the boundary of an Activity. Exception and compensa-tion handling is discussed in Section B.4 on page 128. An End Events has oneor more incoming Sequence Flows and no outgoing Sequence Flows. All tokensthat are generated within a Process must be consumed by an End Event (ifpresent) before the Process has been completed.

The Complete Element Set in BPMN introduces several types of triggers andresults for Events that are indicated by icons within the basic shape for anEvent, as shown in Figure B.2. Note that some triggers and results are notallowed in combination with a particular Start, Intermediate, or End Event.

Figure B.2: Event triggers and results in BPMN

B.1.2 Gateways

A Gateway is used to control the divergence and convergence of Sequence Flow.Figure B.3 on the facing page shows the graphical representation of a Gatewayin the Core Element Set.

The Complete Element Set introduces several types of Gateways that are in-dicated by icons within the basic shape for a Gateway. An Exclusive Gateway,a.k.a. a combination of an XOR-join and an XOR-split, merges all incomingSequence Flows and selects exactly one of a set outgoing Sequence Flows, asdefined in the remainder, is chosen. There are two types of Exclusive Gate-

B.1. FLOW OBJECTS 125

Figure B.3: Gateway in BPMN

ways: Data-Based and Event-Based.1 The former selects exactly one outgoingSequence Flow based on data in the process, while the latter makes this choicebased on Events that could occur at that point in the process. An ParallelGateway, a.k.a. a combination of an AND-join and an AND-split, synchronisesall incoming Sequence Flows and creates parallel outgoing Sequence Flows. AnInclusive Gateway, a.k.a. a combination of an OR-join and an OR-split, syn-chronises all incoming Sequence Flows that could become enabled and selectsone or more of the outgoing Sequence Flows in parallel. Finally, the merg-ing and branching behaviour of a Complex Gateway is defined by expressions.Figure B.4 shows the graphical representations of all Gateways types.

(a) Exclusive Data-Based Gateway

(b) Exclusive Event-Based Gateway

(c) ParallelGateway

(d) InclusiveGateway

(e) ComplexGateway

Figure B.4: Gateway types in BPMN

B.1.3 Activities

An Activity is a generic term in BPMN for work that has to be performed. AnActivity is either a Task or a Sub-Process. A Task is an atomic amount of work,while an Sub-Process is a non-atomic amount of work that is broken down into afiner level of detail using a separate process. Furthermore, a distinction is madebetween a Collapsed Sub-Process and an Expanded Sub-Process. The formerhides the details of the Sub-Process, while the latter shows the details withinits boundaries. As shown in Figure B.5 on the following page, the graphicalrepresentation of an Activity is a rounded-corner rectangle, where a CollapsedSub-Process is distinguished from a Task by a plus sign in the bottom centerof the shape.

The Complete Element Set introduces several types of Activities. A Compen-sation Activity models an amount of work that compensates for already per-formed work when a failure occurs. A Loop Activity reflects the programmingconstructs of while and until. It has a boolean expression that is evaluatedeach cycle of the loop, either before (while) or after (until) the Activity isperformed. A Multiple-Instance Activity reflects the programming construct‘for each’. That is, a numeric expression is evaluated only once before the

1Note that this distinction is irrelevant if an Exclusive Gateway is not used to model adecision, i.e., if it has at most one outgoing Sequence Flow. However, the XORType attributehas to be defined according to the BPMN specification.


(a) Task (b) Collapsed Sub-Process (c) Expanded Sub-Process

Figure B.5: Activities in BPMN

Activity is performed and the result of the expression specifies the number oftimes the Activity will be repeated. The previous three types of Activitiesapply to both Tasks and Sub-Process, while the following two apply only toSub-Processes. An Ad-Hoc Sub-Process is a group of Activities that has nopre-defined sequence relationships. The sequence and number (i.e., zero ormore) of performances for the Activities is determined by the performers only.A Transaction Sub-Process is supported by a particular protocol that ensuresthat all parties involved have agreement that the Sub-Process should be com-pleted or cancelled. Figure B.6 shows the graphical representations of all thesetypes, that is, the ones that apply to both Tasks and Sub-Processes are shownas a (Collapsed) Sub-Process.

(a) Compensation (b) Loop (c) Multiple Instances (d) Ad Hoc (e) Transaction

Figure B.6: Sub-Proces types in BPMN

Figure B.7(a) on the facing page presents two equivalent representations forthe Simple Merge workflow pattern [16] in BPMN. This indicates that eachenablement of an incoming Sequence Flow of an Activity will cause the Activityto be instantiated. Figure B.7(a) presents two equivalent representations forthe Parallel Split workflow pattern [16]. This indicates that all (unconditional)Sequence Flows of an Activity are enabled upon completion.

B.2 Swimlanes

Swimlanes consist of Pools and Lanes. A Pool represents a participant in aprocess, which can be a specific business entity (e.g., a company) or a moregeneral business role (e.g., a buyer, seller, or manufacturer). A Lane is a sub-partition within a Pool and is used to organise and categorise Activities in aPool. Although the meaning of a Lane is up to the modeler, Lanes are oftenused for such things as internal roles (e.g., a manager or an associate), systems

B.3. ARTIFACTS 127

(a) Two representations for the Simple Merge workflow pattern

(b) Two representations for the Parallel Split workflow pattern

Figure B.7: Activities within Sequence Flow in BPMN

(e.g., an enterprise application), or an internal department (e.g., a service deskor a sales department). Figure B.8 shows the graphical representation of Poolsand Lanes: the top Pool models a financial institution, the bottom Pool modelsa supplier, and the two Lanes within the bottom Pool model the internal salesand distribution departments of the supplier.

Figure B.8: Pools and Lanes in BPMN2

B.3 Artifacts

Artifacts provide additional information about a process without directly ef-fecting on the Sequence Flow or Message Flow (as defined in the remainder)of the process. There are three types of Artifacts. A Group is a box around agroup of elements for documentation of analysis purposes. A Data Object pro-vides information about what an Activity requires to be preformed or what an

2Note that this figure is based on Figure 9.31 on page 89 in [26].


Activity produces. A Text Annotation is a textual description used by a mod-eler to provide additional information to the reader of the diagram. Figure B.9shows the graphical representations of these Artifacts.

(a) Group (b) Data Object (c) Text Annotation

Figure B.9: Artifacts in BPMN

Figure B.9 illustrates how Groups, Data Objects, and Text Annotations canbe used in BPMN.

Figure B.10: Application of Artifacts in BPMN

B.4 Connecting Objects

Flow Objects in a BPD are connected using Connecting Objects. The CoreElement Set distinguishes three types of Connection Objects: Sequence Flow,Message Flow, and (un)directional Associations. Figure B.11 shows the graph-ical representation of these Connecting Objects.

(a) Sequence Flow (b) Message Flow (c) Association (d) Directional Association

Figure B.11: Connecting Objects in BPMN

Sequence Flow is used to show the order in which activities will be performed ina process, e.g., Task ‘Pack Goods’ will be performed before Task ‘Ship Goods’in Figure B.8. Message Flow is used to show the flow of messages betweenparticipants, i.e., Pools. See for example the Message Flows between Task‘Credit Card Authorisation’ and Task ‘Authorise Payment’ shown in FigureB.8. An Association, either directional or not, is used to associate information

B.5. EXAMPLE BUSINESS PROCESS 129

with Flow Objects, e.g., directional associations are used to show that DataObject ‘Items on Agenda’ is produced by Task ‘Announce Items on Agenda’and used by Task ‘Hold Meeting’ in Figure B.10.

The Complete Element Set introduces some more specific Connection Objects.A Conditional Sequence Flow, indicated by a diamond marker, has a conditionthat is evaluated at runtime to determine whether or not the Sequence Flowwill be traversed. When a Conditional Sequence Flow is attached to a Gateway,the diamond marker is omitted. A Default Sequence Flow, indicated by a slashmarker, is used in combination with one or more Conditional Sequence Flowsto model a path that should be traversed when all conditions of the otherConditional Sequence Flows evaluate to false. Figure B.12 shows the graphicalrepresentation of these Connecting Objects.

(a) Conditional Sequence Flow (b) Default Sequence Flow

Figure B.12: Sequence Flow types in BPMN

As shown in Figure B.13(a) , a Compensation Association is a combination of aCompensation Intermediate Event on the boundary of an Activity, a directionalassociation, and a Compensation Activity. Compensation Task ‘Credit Buyer’will be performed when Task ‘Charge Buyer’ fails. Similarly, combinationsof a Sequence Flow and various types of Intermediate Events are used forexception handling. For example, Task ‘Review Status of Discussion’ shown inFigure B.13(b) will be performed when seven days have been passed after Task‘Moderate Email’ Discussion has started.

(a) Compensation Flow (b) Exception Flow

Figure B.13: Compensation and exception handling in BPMN3

B.5 Example Business Process

In order to obtain an overall picture of the various Objects presented in thisappendix, Figure B.14 on the following page shows an example of a businessprocess modelled using BPMN.

3Note that these figures are based on Figure 10.53 on page 131 and Figure 10.58 on page134 in [26].

130A

PP

EN

DIX

B.

BP

MN

INA

NU

TSH

ELL

Figure B.14: Example of a business process modelled using BPMN. Note that this process is based on Figure 12.1 on page 205 in [26].

Appendix C

Tools Evaluation Results

As discussed in Section 2.2 on page 8, a thorough evaluation of business processmodelling tools has been performed at the end of 2006 with respect to confor-mance to the BPMN standard. This appendix elaborates on the results of thetools evaluation. First a detailed evaluation results per tool will be discussed,then a succinct tabular overview of the evaluation results will be presented,and finally the tools will be ranked based on the aggregated evaluation results.

C.1 Results per Tool

In this section, for each of the twenty-three evaluated tools a screen capture,a description, the extent of BPMN conformance, the supported file formats,and its availability will be presented. Note that the tools are presented inalphabetical order based on the company name.

131

132 APPENDIX C. TOOLS EVALUATION RESULTS

BEA AquaLogic� BPM Designer 5.7

Figure C.1: BEA AquaLogic� BPM Designer 5.7

Description BEA AquaLogic� BPM Designer 5.7 is part of the BEA Aqua-Logic BPM Suite and includes a BPMN Theme.

BPMN Conformance Sequence Flow, Conditional Flow, Text Annotations,Link Events, and Compensation Activities are not completely within thegraphical conformance rules and therefore only largely supported, i.e., asequence arrowhead should be at the end of the line, a Conditional Flowshould have a diamond marker, a Text Annotation should be an openrectangle, the border of a Link Event should differentiate between Start,Intermediate, and End Events, and a Compensation Activity should havea compensation marker. Message Flow, Exception Flow, IntermediateEvents, and Compensation Associations strongly deviate from the graph-ical conformance rules and therefore only weakly supported, i.e., Inter-mediate Events for Exception Flow should be attached to the bound-ary of an Activity and not halfway the arrow. Moreover, IntermediateEvent can only limitedly be used in Normal Flow and Message Flow andCompensation Associations should be dashed. Transitions are also onlyweakly supported, because so-called Groups (not to be confused withGroups in BPMN) are used to represent part of this notion. The follow-ing BPD elements are not supported: Associations, Pools, Data Objects,and Groups; Events of type Timer, Error, Cancel, Rule, Multiple, andTerminate; Expanded, Reference, and Ad-Hoc Sub-Processes; ActivityLooping, and Multiple Instances Activities; Exclusive Event-Based, In-clusive, and Complex Gateways; and Default Flow.

File Format Models are stored in XML with a misleading .xpdl extension,i.e., XPDL is not supported. The following file types are claimed im-port formats: XPDL, BPEL, IDS Scheer Aris, Microsoft Visio XML, andRational Rose State/Activity Models.

Availability A 90-days evaluation copy can be downloaded after registrationfrom the BEA website:http://commerce.bea.com/products/aqualogic/bpm/albpm.jsp?DL=www -AL Bus-Int icon

http://commerce.bea.com/products/aqualogic/bpm/albpm.jsp?DL=www_AL_Bus-Int_icon

http://commerce.bea.com/products/aqualogic/bpm/albpm.jsp?DL=www_AL_Bus-Int_icon

C.1. RESULTS PER TOOL 133

Borland Togetherr 2006 Release 2 for Eclipse

Figure C.2: Borland Togetherr 2006 Release 2 for Eclipse

Description Borland Togetherr 2006 Release 2 for Eclipse supports valida-tion of BPMN diagrams against the BPMN standard.

BPMN Conformance All BPD elements are fully supported.

File Format Models are stored in a proprietary XML file format. Moreover,models can amongst others be exported to BPEL4WS, XMI, and imagefile formats.

Availability A 15-days evaluation copy can be downloaded after registrationfrom the Borland website:http://www.borland.com/downloads/download together.html

http://www.borland.com/downloads/download_together.html


Casewiser Corporate Modeler� 10

Figure C.3: Casewiser Corporate Modeler� 10

Description Casewiser Corporate Modeler� 10 provides support for the BPMNstandard by means of an extension.

BPMN Conformance Message Flow, Text Annotations, Compensation Ac-tivities, and Default Flow are not completely within the graphical confor-mance rules and therefore only largely supported, i.e., a message arrow-head should be an open triangle, a Text Annotation should be an openrectangle, a Compensation Activity should have a compensation marker,and a Default Flow marker should be a backslash. The arrows of Com-pensation Associations, which should be dashed, strongly deviate fromthe graphical conformance rules and are therefore only weakly supported.Exclusive Data-Based and Inclusive Gateways cannot be used for mergingand are therefore only weakly supported. The following BPD elementsare not supported: Expanded, Reference, Transaction, and Ad-Hoc Sub-Processes; Activity Looping, and Multiple Instances Activities.

File Format Models are either stored in a proprietary XML file format or asa Bitmap or SVG. Moreover, models can be exported to Microsoft Visio.

Availability An evaluation copy is available from the Casewise website:http://www.casewise.com/SupportAndDownloads/Downloads/ Evaluation-Versions/CorporateModelerSuiteEvaluationVersion.htmThe evaluation version of the BPMN extension is available from:http://www.casewise.com/SupportAndDownloads/Downloads/Extensions/BPMN Extension.htm

http://www.casewise.com/SupportAndDownloads/Downloads/EvaluationVersions/CorporateModelerSuiteEvaluationVersion.htm

http://www.casewise.com/SupportAndDownloads/Downloads/EvaluationVersions/CorporateModelerSuiteEvaluationVersion.htm

http://www.casewise.com/SupportAndDownloads/Downloads/Extensions/BPMN_Extension.htm

http://www.casewise.com/SupportAndDownloads/Downloads/Extensions/BPMN_Extension.htm


Corelr iGrafxr Process� 2006

Figure C.4: Corelr iGrafxr Process� 2006

Description Corelr iGrafxr Process� 2006 supports process diagramming,simulation, analysis, and reporting.

BPMN Conformance The following BPD elements are not supported: TextAnnotations; Link and Multiple Events; Reference Sub-Processes; andComplex Gateways.

File Format Models can be stored in a number of proprietary file formatand published as web page, Microsoft Word document, and MicrosoftPowerpoint presentation.

Availability A 30-days evaluation copy can be downloaded after registrationfrom the iGrafx website:http://www.igrafx.com/downloads/index.html#evals

http://www.igrafx.com/downloads/index.html#evals


Deloitte IndustryPrint Process Modeler 4.0

Figure C.5: Deloitte IndustryPrint Process Modeler 4.0

Description Deloitte IndustryPrint Process Modeler 4.0 is a BPMN editorfor internal use only.

BPMN Conformance Compensation Activities lack a compensation markerand are therefore not completely within the graphical conformance rulesand only largely supported. The arrows of Compensation Associations,which should be dashed, strongly deviate from the graphical conformancerules and are therefore only weakly supported. The following BPD ele-ments are not supported: Message Flow, Pools, and Groups1; Expanded,Reference, Independent, Transaction, and Ad-Hoc Sub-Processes; Ac-tivity Looping and Multiple Instance Activities; Inclusive and ComplexGateways; and Conditional and Default Flow.

File Format BPMN models are stored in a proprietary XML file format or asimage. Model can also be exported to Microsoft Word, Microsoft Visio,Microsoft Excel, and Aris.

Availability This modeler is not publicly available.

1Groups will be supported in the next version.


ILOGr JViews� BPMN Modeler 1.0

Figure C.6: ILOGr JViews� BPMN Modeler 1.0

Description ILOGr JViews� BPMN Modeler 1.0 is a BPMN editor devel-oped by ILOG to promote its Java Toolkit ILOG JViews Diagrammer,which can be used to extend the editor with new features.

BPMN Conformance The following BPD elements are not supported: DataObjects and Groups; and Reference, Independent, and Transaction Sub-Processes. Moreover, Conditional Flow is only largely supported, becausethe diamond marker should not be shown if the source element is a Gate-way.

File Format Models are stored in a proprietary XML file format.

Availability Freely available from the ILOG website:http://www.ilog.com/products/jviews/diagrammer/bpmnmodeler/index.cfm

http://www.ilog.com/products/jviews/diagrammer/bpmnmodeler/index.cfm


Intalio|BPMS Designer� 4.0

Figure C.7: Intalio|BPMS Designer� 4.0

Description Intalio|BPMS Designer� 4.0 is an Eclipse-based BPMN Designer.

BPMN Conformance The arrows of Sequence Flow, Message Flow, andCompensation Associations are not completely within the graphical con-formance rules and therefore only largely supported. A Start Event isnot allowed to be of type Timer and is therefore only weakly supported.Compensation Activities are also weakly supported, because only Sub-Processes – that is, not Tasks – are allowed to be used for compensationand the compensation marker is missing. The following BPD elementsare not supported: Data Objects and Groups; Events of type Cancel,Link, and Multiple; Reference, Transaction, and Ad-Hoc Sub-Processes;Multiple Instances Activities; and Complex Gateways.

File Format Models are stored in a proprietary file format. Moreover, modelscan be exported to various image formats.

Availability Freely available after registration from the Intallio website:http://bpms.intalio.com/component/option,com remository/Itemid,48/

http://bpms.intalio.com/component/option,com_remository/Itemid,48/


Intellior AG AENEIS 5 - Professional

Figure C.8: Intellior AG AENEIS 5 - Professional

Description Intellior AG AENEIS 5 comes in four editions: Basic, Standard,Professional, and Enterprise.

BPMN Conformance Collapsed Sub-Processes lack a Sub-Process markerand are therefore not completely within the graphical conformance rulesand only largely supported. Message Flow and Intermediate Events arenot allowed to be attached to the boundary of an Activity and are there-fore only weakly supported. Exception Flow and Compensation Associ-ations, which are attached to the boundary of an Activity without Inter-mediate Event, completely violate the graphical conformance rules andare therefore only weakly supported. Moreover, the arrows of Compen-sation Associations should be dashed. The following BPD elements arenot supported: Groups; and Expanded, Reference, and Transaction Sub-Processes.

File Format Models can be exported to a proprietary XML format.

Availability A 1-month evaluation copy can be downloaded after registrationfrom the Intellior AG website: http://www.intellior.ag/?id=356

http://www.intellior.ag/?id=356


ITpearls Process Modeler 4

Figure C.9: ITpearls Process Modeler 4

Description ITpearls Process Modeler 4 is an extension for Microsoft Visio,which comes in a Business and a Professional Edition.

BPMN Conformance The following BPD elements are not supported: Trans-action and Ad-Hoc Sub-Processes; and Activity Looping and MultipleInstances Activities.

File Format Models are stored in the Microsoft Visio file format. Moreover,an export to BPEL 1.1 and XPDL 1.0 is supported.

Availability An evaluation copy can be downloaded after registration fromthe ITpearls website (note that all entered text is garbled upon saving inthis copy): http://www.itp-commerce.com/processmodeler

http://www.itp-commerce.com/processmodeler


Kaisha-Tec ActiveModeler Avantage 1.0

Figure C.10: Kaisha-Tec ActiveModeler Avantage 1.0

Description Kaisha-Tec ActiveModeler Avantage 1.0 is a recently releasedfree BPMN modeler of Kaisha-Tec.

BPMN Conformance Message Flow and Groups are not completely withinthe graphical conformance rules and therefore only largely supported, i.e.,a message arrowhead should be an open triangle and a Group should havea dashed border with alternating dots and short lines. A CompensationAssociation is only weakly supported, because the arrow points in thewrong direction. Multiple Events are not supported. All other BDPelements are fully supported.

File Format A proprietary XML file format is used to store models. It isclaimed that XPDL 2.0 will be supported by a plug-in in the future.

Availability Freely available from the Kaisha-Tec website:http://www.activemodeler.com/amavantage started.html

http://www.activemodeler.com/amavantage_started.html


M1 Global Convergence Studio 1.5

Figure C.11: M1 Global Convergence Studio 1.5

Description M1 Global Convergence Studio 1.5 is contained in the M1 GlobalBusiness Convergence Suite, which will be replaced by an open sourceversion called Star|Pound in the near future.

BPMN Conformance Conditional Flow and Terminate Events are not com-pletely within the graphical conformance rules and therefore only largelysupported, i.e., the conditional diamond marker is missing and an incor-rect terminate marker is used. Pools and Lanes are only weakly sup-ported, though a concept called Queues, which represent groupings ofwork, is used instead. Start and End Events are also only weakly sup-ported, because only one Start Event is allowed per Process and bothStart and End Events can only be of type None. The following BPD ele-ments are not supported: Message Flow and Data Objects; Events of typeMessage, Cancel, Compensation, Rule, and Multiple; Expanded, Trans-action and Ad-Hoc Sub-Processes; Compensation and Exclusive Event-Based Gateways; and Compensation Associations.


Availability An evaluation copy can be downloaded after registration fromthe M1 Global website: http://www.m1global.org/downloads.html

http://www.m1global.org/downloads.html


MEGA International MEGA Suite� 2005

Figure C.12: MEGA International MEGA Suite� 2005

Description An educational version of MEGA International MEGA Suite� 2005is available, purely for educational or research-oriented purposes.

BPMN Conformance Exclusive Data-Based Gateways and Text Annota-tions are not completely within the graphical conformance rules andtherefore only largely supported, i.e., an Exclusive Data-Based Gatewaycan only be shown without marker, and a Text Annotation should bean open rectangle with a solid black line. Events, Exception Flow, andTransactions violate many semantical and graphical conformance rulesand are therefore only weakly supported. Timer Events also strongly de-viate from the graphical conformance rules and are therefore only weaklysupported, i.e., a different timer symbol is used without a surroundingIntermediate Event. The following BPD elements are not supported:Data Objects and Groups; Events of type Message, Error, Cancel, Com-pensation, Rule, Link, Multiple, and Terminate; Reference and Ad-HocSub-Processes; Compensation and Multiple Instances Activities; Exclu-sive Event-Based, Inclusive, and Complex Gateways; and CompensationAssociations.

File Format A proprietary XML file format is used to store models. More-over, models can be exported to amongst others BPEL and RationalRose.

Availability A 30-days evaluation copy can be downloaded after registrationfrom the website:http://www.mega.com/index.asp/l/en/c/product/p/evaluation-request

http://www.mega.com/index.asp/l/en/c/product/p/evaluation-request


No Magic MagicDraw UML 12.0 EAP beta

Figure C.13: No Magic MagicDraw UML 12.0 EAP beta

Description No Magic MagicDraw UML 12.0 EAP beta is a visual UML mod-eling and CASE tool with amongst others BPMN support and Eclipseintegration.

BPMN Conformance All BDP elements are fully supported.

File Format Models are stored in a proprietary XML file format. Moreover,models can be exported to BPEL 1.1, XMI, and various image formats.

Availability An 5-days evaluation copy can be downloaded after registrationfrom the MagicDraw website: http://www.magicdraw.com/

http://www.magicdraw.com/


Orbus Software iServer BPMN Stencil 1.0.9

Figure C.14: Orbus Software iServer BPMN Stencil 1.0.9

Description Orbus Software iServer BPMN Stencil 1.0.9 provides support forthe BPMN standard by means of a Microsoft Visio add-in.

BPMN Conformance All BPD shapes are fully supported in the free stencil,except for Reference and Independent Sub-Processes.

File Format Models are stored in the Microsoft Visio file format. Moreover,models can be exported to an SQL-based repository, BPEL 1.1, andXPDL 1.0 in the full version.

Availability Freely available after registration from the Orbus Software web-site: http://www.orbussoftware.com/register.aspx?downloads=trueThe full (paid) version of iServer BPMN also supports BPMN attributes.

http://www.orbussoftware.com/register.aspx?downloads=true


Savvionr Process Modeler 6.8

Figure C.15: Savvionr Process Modeler 6.8

Description Savvionr Process Modeler 6.8 is part of the Savvionr Business-Manager� .

BPMN Conformance Inclusive and Parallel Gateways are only weakly sup-ported, because Inclusive Gateways can only be used for merging and theBPMN marker for Complex Gateways is improperly applied to the Paral-lel Gateway when used for forking. The following BPD elements are notsupported: Message Flow, Pools, and Data Objects; Intermediate Eventsand all Event types; Expanded, Reference, Transaction and Ad-Hoc Sub-Processes; Compensation, Activity Looping, and Multiple Instances Ac-tivities; Exclusive Event-Based and Complex Gateways; and ConditionalFlow, Default Flow, Exception Flow, and Compensation Associations.

File Format Models are stored in a proprietary XML format. Moreover, mod-els can be stored as JPEG.

Availability An evaluation copy can be downloaded after registration fromthe Savvion website: http://www.savvion.com/forms1/process modeler.php

http://www.savvion.com/forms1/process_modeler.php


Seagull Software LegaSuite BPM Studio 6.0

Figure C.16: Seagull Software LegaSuite BPM Studio 6.0

Description Seagull Software LegaSuite BPM Studio 6.0 is based on Java.

BPMN Conformance Collapsed Sub-Processes lack a Sub-Process markerand are therefore not completely within the graphical conformance rulesand only largely supported. Parallel Gateways, which are drawn as avertical bars, completely violate the graphical conformance rules and aretherefore only weakly supported. The following BPD elements are notsupported: Message Flow, Associations, Pools, Data Objects, Groups,and Text Annotations; Intermediate Events; all Event types except forTimer; Expanded, Reference, Transaction, and Ad-Hoc Sub-Processes;Compensation, Activity Looping, and Multiple Instances Activities; Ex-clusive Event-Based, Inclusive, and Complex Gateways; and ConditionalFlow, Default Flow, Exception Flow, and Compensation Associations.

File Format A proprietary XML file format is used to store models.

Availability An 45-days evaluation copy can be downloaded after registrationfrom the Seagull Software website:http://www.seagullsoftware.com/products/legasuite.html

http://www.seagullsoftware.com/products/legasuite.html


Select Business Solutions Select Architect 7.0

Figure C.17: Select Business Solutions Select Architect 7.0

Description Select Business Solutions Select Architect 7.0 is a part of SelectSolution Factory 7.0.

BPMN Conformance The borders of Groups and Text Annotations are notcompletely within the graphical conformance rules and therefore onlylargely supported. Collapsed, Expanded, and Independent Sub-Processare also only largely supported, because Embedded Sub-Processes canonly be viewed in an expanded view and Independent Sub-Process onlyin a collapsed view. Reference Sub-Processes are not supported. Allother BDP elements are fully supported.

File Format Models are stored in a proprietary XML file format. Moreover,models can be exported to XMI 2.1 and reported in HTML.

Availability An 30-days evaluation copy can be downloaded after registrationfrom the Select Business Solutions website:http://www.selectbs.com/forms/products/select-solution-factory-download-form.htm

http://www.selectbs.com/forms/products/select-solution-factory-download-form.htm

http://www.selectbs.com/forms/products/select-solution-factory-download-form.htm


Soyatec eBPMN Designer 1.0

Figure C.18: Soyatec eBPMN Designer 1.0

Description Soyatec eBPMN Designer 1.0 is based on the Eclipse Rich ClientPlatform (RCP), developed on top of the Eclipse Graphical ModelingFramework (GMF).

BPMN Conformance All BDP elements are fully supported except for Groups.The modeler has a minor imperfection since the tooltips for Rule and LinkIntermediate Events have mistakenly be interchanged in the palette thatappears when the mouse is paused above a diagram.


Availability Freely available from the Soyatec website:http://www.soyatec.com/ebpmn/download.html


Sparx Systems Enterprise Architect 6.5

Figure C.19: Sparx Systems Enterprise Architect 6.5

Description Sparx Systems Enterprise Architect 6.5 provides support for theBPMN standard by means of an add-in, i.e., the Model Driven Generator(MDG) Technology for BPMN 1.3

BPMN Conformance Pools, Lanes, Groups, Expanded Sub-Processes, andExclusive Data-Based Gateways are not completely within the graphicalconformance rules and therefore only largely supported, i.e., Pools andLanes have an open border, Expanded Sub-Processes have a solid border,and Exclusive Data-Based Gateways can only be shown without marker.All other BDP elements are fully supported.

File Format Models are stored in a proprietary file format. Moreover, modelscan be stored as image.

Availability A 30-days evaluation copy can be downloaded after registrationfrom the Sparx Systems website: http://www.sparxsystems.com/The MDG Technology for BPMN v1.3 add-in is freely available on thewebsite: http://www.sparxsystems.com/products/mdg bpmn.html

http://www.sparxsystems.com/

http://www.sparxsystems.com/products/mdg_bpmn.html


Sybaser PowerDesignerr 12.0

Figure C.20: Sybaser PowerDesignerr 12.0

Description Sybaser PowerDesignerr 12.0 provides support for amongst oth-ers the BPMN and UML standards.

BPMN Conformance Text Annotations, Compensation Activities, and De-fault Flow are not completely within the graphical conformance rulesand therefore only largely supported, i.e., a Text Annotation should bean open rectangle, a Compensation Activity should have a compensa-tion marker, and Conditional Flow should have a slash marker. Poolsare only weakly supported, because only one Pool is allowed. ExceptionFlow and Compensation Associations are also only weakly supported,because only Intermediate Events of type Error, Timer, and Compensa-tion can be attached to the boundary of an Activity and these events are,moreover, drawn against the border line instead of upon it. The followingBPD elements are also not supported: Groups; Transactions and Ad-HocSub-Processes; and Multiple Instances Activities.

File Format Models are stored in a proprietary XML file format. Moreover,models can be exported to XMI and various image file formats.

Availability A 15-days evaluation copy can be downloaded after registrationfrom the Sybase website:http://response.sybase.com/forms/PowerDesigner12 Eval DWLD

http://response.sybase.com/forms/PowerDesigner12_Eval_DWLD


Telelogicr System Architectr 10.4

Figure C.21: Telelogicr System Architectr 10.4

Description Telelogicr System Architectr 10.4 provides support for amongstothers BPMN and UML modelling notations.

BPMN Conformance Terminate End Events, Transactions, Complex Gate-ways, Conditional Flow, and Default Flow are not completely within thegraphical conformance rules and therefore only largely supported, i.e.,Terminate End Events have an incorrect terminate marker, Transactionslack a double border (but the required attributes are present), the asteriskmarker and border of a Complex Gateway overlap, the diamond markerof Conditional Flow is used when connected to a Gateway, and the back-slash marker of Default Flow marker is missing. Intermediate Events,Compensation Associations, Exception Flow are only weakly supported,because Intermediate Event are not allowed attached to the boundary ofan Activity. However, it is allowed to attach Start Events to the bound-ary of an Activity to create so-called Initiating or Terminating Events,which is not conform the BPMN standard.


Availability An evaluation copy can be downloaded after registration (andcontact by telephone) from the Telelogic website:http://www.telelogic.com/Products/systemarchitect/evaluations.cfm

http://www.telelogic.com/Products/systemarchitect/evaluations.cfm


TIBCO Business Studio� 1.1

Figure C.22: TIBCO Business Studio� 1.1

Description TIBCO Business Studio� 1.1 is an Eclipse-based environmentthat supports the BPMN and XPDL 1.0 standards.

BPMN Conformance Event-Based Exclusive, Inclusive, and Complex Gate-ways lack a marker and are therefore not completely within the graphicalconformance rules and only largely supported. Pools are only weakly sup-ported, because only one Pool is allowed. No Intermediate Events andno Event types are supported, except for a Timer Intermediate Event at-tached to the boundary of an Activity as Exception Flow. The followingBPD elements are also not supported: Message Flow, Data Objects, andGroups; Expanded and Transaction Sub-Processes; and CompensationAssociations.

File Format Processes are stored in XPDL 1.0. An import/export function-ality to the Aris toolkit of IDS Scheer is provided.

Availability Freely available from the TIBCO website:http://www.tibco.com/devnet/business studio/download bs.html

http://www.tibco.com/devnet/business_studio/download_bs.html


Visual Paradigm Business Process Visual Architect 2.0

Figure C.23: Visual Paradigm Business Process Visual Architect 2.0

Description Visual Paradigm Business Process Visual Architect 2.0 supportssyntax checking according to BPMN standard.

BPMN Conformance The diamond marker of Conditional Flow is not com-pletely within the graphical conformance rules and therefore only largelysupported. All other BDP elements are fully supported.

File Format Models can be stored in a binary proprietary file format. More-over, models can be exported to a proprietary XML file format and savedas image.

Availability A 30-days evaluation copy can be downloaded after registrationfrom the Visual Paradigm website:http://www.visual-paradigm.com/download/download.jsp?product=bpva

http://www.visual-paradigm.com/download/download.jsp?product=bpva

C.2. OVERVIEW OF THE RESULTS 155

C.2 Overview of the Results

This section presents an overview of the evaluation results. Note that theauthor tried to make a fair comparison between the tools, but is not responsiblefor any errors or misinterpretations. Moreover, the weights of the different partsof the evaluation are rather arbitrary. The only goal is to give some insightinto the true support of the BPMN standard.

Table C.1 presents four ranking symbols that are used to indicate whether aparticular BPMN element is fully, largely, weakly, or not supported. In orderto be able to rank the tools in the next section, points are assigned to thesesymbols as well.

Symbol Points Semantics+ 4 Element is fully supported∧ 3 Element is largely supported∨ 1 Element is weakly supported– 0 Element is not supported

Table C.1: Ranking symbols and points

Tables C.2 to C.4 on pages 156 to 158 provide a succinct overview of the extentto which the twenty-three evaluated tools are within the conformance rules ofthe BPMN standard. Note that the evaluation results are grouped accordingto the elements sets defined in Section 2.2.2 on page 10. The first element setcomprises the Core Element Set, which contains only the elements that definethe basic look-and-feel of BPMN. The Complete Element Set is subdivided intofour sets that contain the various Event types, Activity types, Gateway types,and Connecting Objects, respectively.

The ranking symbols in a single column of a table enable a quick comparisonof the conformance to a particular BPMN element across the different tools.At a single glance the similarities and dissimilarities with respect to BPMNconformance become perceptible.


Core Element Set

Tool Eve

nt

Act

ivity

Gat

eway

Seq

uen

ceFlo

w

Mes

sage

Flo

w

Ass

oci

atio

n

Pool

Lan

e

Dat

aO

bje

ct

Gro

up

Tex

tA

nnot

atio

n

BEA + + + ∧ ∨ – – + – – ∧Borland + + + + + + + + + + +Casewise + + + + ∧ + + + + + ∧Corel + + + + + + + + + + –Deloitte + + + + – + – + + – +ILOG + + + + + + + + – – +Intalio + + + ∧ ∧ + + + – – +Intellior + + + + ∨ + + + + – +ITPearls + + + + + + + + + + +Kaisha-Tec + + + + ∧ + + + + ∧ +M1 Global + + + + – + ∨ ∨ – + +Mega Int. ∨ + + + + + + + – – ∧No Magic + + + + + + + + + + +Orbus + + + + + + + + + + +Savvion + + + + – + – + – + +Seagull + + + + – – – + – – –Select + + + + + + + + + ∧ ∧Soyatec + + + + + + + + + – +Sparx + + + + + + ∧ ∧ + ∧ +Sybase + + + + + + ∨ + + – ∧Telelogic + + + + + + + + + + +TIBCO + + + + – + ∨ + – – +Visual P. + + + + + + + + + + +

Table C.2: Overview of the conformance to the Core Element Set

C.2. OVERVIEW OF THE RESULTS 157

Event DimensionFlow Type

Tool Sta

rt

Inte

rmed

iate

End

Mes

sage

Tim

er

Err

or

Can

cel

Com

pen

sati

on

Rule

Lin

k

Multip

le

Ter

min

ate

BEA + ∨ + + – – – + – ∧ – –Borland + + + + + + + + + + + +Casewise + + + + + + + + + + + +Corel + + + + + + + + + – – +Deloitte + + + + + + + + + + + +ILOG + + + + + + + + + + + +Intalio + + + + ∨ + – + + – – +Intellior + ∨ + + + + + + + + + +ITpearls + + + + + + + + + + + +Kaisha-Tec + + + + + + + + + + – +M1 Global ∨ + ∨ – + + – – – + – ∧Mega Int. ∨ ∨ ∨ – + – – – – – – –No Magic + + + + + + + + + + + +Orbus + + + + + + + + + + + +Savvion + – + – – – – – – – – –Seagull + – + – + – – – – – – –Select + + + + + + + + + + + +Soyatec + + + + + + + + + + + +Sparx + + + + + + + + + + + +Sybase + + + + + + + + + + + +Telelogic + ∨ + + + + + + + + + ∧TIBCO + ∨ + – ∨ – – – – – – –Visual P. + + + + + + + + + + + +

Table C.3: Overview of the conformance to the Events types in the CompleteElement Set


Activity2

ConnectingSub-Process Activity Gateway Object

Tool Col

lapse

d

Expan

ded

Ref

eren

ce

Indep

enden

t

Tra

nsa

ctio

n

Ad-H

oc

Com

pen

sati

on

Act

ivity

Loop

ing

Mult

iple

Inst

ance

s

Dat

a-B

ased

Excl

usi

ve

Eve

nt-

Bas

edExcl

usi

ve

Incl

usi

ve

Com

ple

x

Par

alle

l

Con

dit

ional

Flo

w

Def

ault

Flo

w

Exce

pti

onFlo

w

Com

pen

sati

onA

ssoci

atio

n

BEA + – – + ∨ – ∧ – – + – – – + ∨ – ∨ ∨Borland + + + + + + + + + + + + + + + + + +Casewise + – – + – – ∧ – – ∨ + ∨ + + + ∧ + ∨Corel + + – + + + + + + + + + – + + + + +Deloitte + – – – – – ∧ – – + + – – + – – + ∨ILOG + + – – – + + + + + + + + + ∧ + + +Intalio + + – + – – ∧ + – + + + – + + + + ∧Intellior ∧ – – + – + + + + + + + + + + + ∨ ∨ITpearls + + + + – – + – – + + + + + + + + +Kaisha-Tec + + + + + + + + + + + + + + + + + ∨M1 Global + – + + – – – + – + – + + + ∧ + + –Mega Int. + + – + ∨ – – + – ∧ – – – + + + ∨ –No Magic + + + + + + + + + + + + + + + + + +Orbus + + – – + + + + + + + + + + + + + +Savvion + – – + – – – – – + – ∨ – ∨ – – – –Seagull ∧ – – + – – – – – + – – – ∨ – – – –Select ∧ ∧ – ∧ + + + + + + + + + + + + + +Soyatec + + + + + + + + + + + + + + + + + +Sparx + ∧ + + + + + + + ∧ + + + + + + + +Sybase + + + + – – ∧ + – + + + + + + ∧ ∨ ∨Telelogic + + + + ∧ + + + + + + + ∧ + ∧ ∧ ∨ ∨TIBCO + – + + – + + + + + ∧ ∧ ∧ + + + + –Visual P. + + + + + + + + + + + + + + ∧ + + +

Table C.4: Overview of the conformance to the Activity types, Gateway types,and Connecting Objects in the Complete Element Set

2Note that an Activity is either a Sub-Process or a Task in BPMN. The left six columnsapply to Sub-Processes only. The right tree columns apply to Sub-Processes as well as Tasks.Together the nine columns represent the Activity types mentioned in Table 2.2 on page 11.

C.3. TOOLS RANKING 159

C.3 Tools Ranking

For the benefit of mutual comparison, Table C.5 presents an overview of theextent to which the evaluated tools conform to the BPMN standard. Note thatthis table corresponds exactly to Table 2.3 on page 12. A conformance percent-age for each of the five element sets is presented. In addition, the rightmostcolumn shows overall scores that are based on the conformance percentages ofthe separate element sets. The twenty-three tools are ranked based on theiroverall scores.

Tool Cor

eEle

men

tSet

Eve

nt

Types

Act

ivity

Types

Gat

eway

Types

Con

nec

ting

Obje

cts

Ove

rall

Together 2006 100 100 100 100 100 100MagicDraw UML 12.0 EAP beta 100 100 100 100 100 100Business Process Visual Architect 2.0 100 100 100 100 94 99eBPMN Designer 1.0 91 100 100 100 100 98Enterprise Architect 6.5 93 100 97 95 100 97iServer BPMN Stencil 1.0.9 100 100 78 100 100 96Select Architect 7.0 95 100 81 100 100 95ActiveModeler Avantage 1.0 95 94 100 100 81 94Process Modeler 4 100 100 56 100 100 91iGrafx Process 2006 91 89 89 80 100 90JViews BPMN Modeler 1.0 82 100 67 100 94 88System Architect 10.4 100 86 97 95 50 86AG AENEIS 5 84 88 64 100 63 80PowerDesigner 12.0 82 100 64 100 56 80BPMS Designer 4.0 77 79 53 80 94 77Corporate Modeler 10 95 100 31 70 75 74Business Studio 1.1 66 39 78 85 75 69Convergence Studio 1.5 68 46 44 80 69 61IndustryPrint Process Modeler 4.0 73 100 19 60 31 57Mega Suite 73 18 47 35 56 46AquaLogic BPM Designer 5.7 52 53 33 40 19 39Process Modeler 6.8 73 33 22 30 0 32LegaSuite BPM Studio 6.0 45 39 19 25 0 26

Table C.5: Overview of the BPMN conformance per tool (%)3

3Note that this table is based on a thorough evaluation at the end of 2006. The authortried to make a fair comparison, but is not responsible for any errors or misinterpretations.Moreover, the weights of the different parts of the evaluation are rather arbitrary. The onlygoal is to give some insight into the true support of the BPMN standard.


The underlying aggregation method will now be presented. The ranking sym-bols used to present the evaluation results in Tables C.2 to C.4 are translatedto points, according to Table C.1 on page 155. Even weights have been givento the elements in an element set, with the exception of the element set com-prising Event types. Since supporting the different Flow types (i.e., Start,Intermediate, and Event) is of greater importance that supporting the differ-ent Event types (i.e., Message, Timer, Error, etc.), weight have been assignedin the proportion of three to one.

A conformance score per element set is calculated based on the assigned pointsand weights. The overall conformance score equals the average of these separateconformance scores per element set. The calculations of the conformance per-centages for LegaSuite BPM Studio 6.0 of Seagull Software in the bottom rowof Table C.5 will be used as an example to illustrate the aggregation method.

The Core Element Set is divided into 11 elements (of equal weight) of whichonly 5 ones are fully supported (4 points), that is, Events, Activities, Gateways,and Lanes. Therefore, the conformance percentage with respect to the CoreElement Set equals (5× 4)÷ (11× 4)× 100% ≈ 45% in the second column ofTable 2.3. Note that 5 × 4 represents the number of points scored and that11× 4 represents the maximal number of points that could have been scored.

From the 3 Event Types (weight 3) and 9 Event Triggers/Results (weight 1) inthe Complete Element Set are only 2 Event types – i.e., Start and End – and1 Event Trigger/Result – i.e., Timer – fully supported (4 points). The otherones are not supported. Therefore, the conformance percentage with respectto Events in the Complete Element Set equals (2× 4× 3+1× 4× 1)÷ (3× 4×3 + 9× 4× 1)× 100% ≈ 39% in the third column of Table 2.3. Note that, forexample, 2× 4× 3 represents the score for fully (4 points) supporting 2 Eventtypes, which have weight 3.

From the 9 Activity Types (of equal weight) in the Complete Element Set isonly a Collapsed Sub-Process largely supported (3 points) and an IndependentSub-Process fully supported (4 points). The other ones are not supported.Therefore, the conformance percentage with respect to Activities in the Com-plete Element Set equals (1× 3 + 1× 4)÷ (9× 4)× 100% ≈ 19% in the fourthcolumn of Table 2.3.

From the 5 Gateway Types (of equal weight) in the Complete Element Setis only an Event-Based Exclusive Gateway weakly supported (1 point) and aParallel Gateway largely supported (4 points). The other ones are not sup-ported. Therefore, the conformance percentage with respect to Gateways inthe Complete Element Set equals (1 × 1 + 1 × 4) ÷ (5 × 4) × 100% ≈ 25% inthe fifth column of Table 2.3. Since none of the Connection Types in the Com-plete Element Set are supported, the conformance percentage with respect toConnecting Objects in the Complete Element Set equals 0% in the sixth col-umn of Table 2.3. Note that this does not imply that no Connection Object issupported at all, because normal Sequence Flow is not included in this elementset.

The overall conformance percentage for LegaSuite BPM Studio 6.0 in the right-most column of Table 2.3 equals the average of the percentages in the precedingfive columns, that is, (45% + 39% + 19% + 25% + 0%)÷ 5 = 26%.

Appendix D

Detailed Mappings from Protosto BPMN

Supplementary to the mapping from Protos to BPMN presented in Chapter 3,this appendix covers a detailed mapping from object properties in Protos toobject attributes in BPMN. Note that the property mappings presented in thisappendix are not beyond discussion. That is, alternative mappings might bepossible.

Standard Protos extended with simulation parameters to represent the splitand join behaviour of Activities, see for example Section 3.1.4 on page 24, isused as a starting point for the mapping to BPMN. The data and resourcecapabilities of Protos are not mapped to BPMN, with the exception of thedata contained in the Trigger Contents Tab of a Trigger (see Table D.3 onpage 165), the data contained in the Data Tab of an Activity or a Sub-Process(see Table D.4 on page 168), and the Role or Role Group when used in themapping for a deferred choice (see Section 3.1.5 on page 27).

D.1 Process Model Mappings

A Process Model in Protos is a container for process information, i.e., the MainProcess and all its Sub-Processes as well as information about resources anddata. Figure D.1 on the next page shows the properties dialog of a ProcessModel.

A Process Model in Protos maps to a private (internal) business process inBPMN, i.e., it maps to a BPD with a single Pool. Table D.1 presents themappings for the properties of a Process Model.

Process ModelProperty

Mapping to BPMN

Name This maps to the Name attribute of the BPD.Process Owner This maps to the Author attribute of the BPD.

Continued on next page

161

162 APPENDIX D. DETAILED MAPPINGS FROM PROTOS TO BPMN

Process ModelProperty

Mapping to BPMN

Identification This maps to the Id attribute of the BPD.Description This maps to the Documentation attribute of the

BPD.Instructions This could either be appended to the Documentation

attribute of the BPD or mapped to a modeler-definedattribute using the Properties attribute if one wantsto separate it from the Description property (above).

History This is a list of all (checked-in) versions of the ProcessModel. Figure D.1(b) shows a history consisting oftwo versions. Since a BPD contains no history, theproperties of the current version can be mapped only,as defined in the next four rows.

User This is the name of a user on a computer. It does notmap to any object or attribute in BPMN, but it couldbe mapped the Author attribute of the BPD in casethe Process Owner property (above) is left blank.

Date This maps to the CreationDate attribute of the BPD.Version This maps to the Version attribute of the BPD.Status This property does not map to any object or attribute

in BPMN.Extra This maps to the Properties attribute of a BPD.

Table D.1: Process Model property mappings to BPMN

(a) General (b) History

Figure D.1: Process Model properties

D.2. MAIN PROCESS MAPPINGS 163

D.2 Main Process Mappings

The Main Process in Protos is the top-level process that may be composedof several other Sub-Processes. Figure D.2 shows the properties dialog of theMain Process in Protos.

Figure D.2: Main Process properties

As discussed before, a Process Model maps to a BPD that has a single Pool.The Main Process in the Process Model maps to a single Lane within thatPool. Table D.2 presents the mappings for the properties of the Main Process.

Main ProcessProperty

Mapping to BPMN

Name This maps to the Name attribute of the Process ofthe only Lane within the BPD.

Description This maps to the Documentation attribute of the Pro-cess of the only Lane within the BPD.

Instructions This could either be appended to the Documentationattribute of the Process of the only Lane within theBPD, or mapped to a modeler-defined attribute usingthe Properties attribute if one wants to separate itfrom the Description property (above).

Extra This maps to the Properties attribute of the Processof the only Lane within the BPD.

Table D.2: Main Process property mappings to BPMN


D.3 Trigger Mappings

A Trigger Object models an event that may occur during the coarse of a process.Figure D.3 shows the graphical representation of a Trigger Object and thecorresponding properties dialog in Protos. In this case, it is a Time Triggerwhich Name property is set to ‘End of Review Period’. Figure A.1 on page 115in Appendix A presents the graphical representation of other types of Triggers.

(a) Trigger Object (b) Trigger properties

Figure D.3: The graphical representation and properties of a Trigger Object

A Trigger maps to an Event in BPMN, as explained in Section 3.1.3 on page 22.Table D.3 presents the mappings for the properties of a Trigger.

Trigger Property Mapping to BPMNName This maps to the Name attribute of the Event.Waiting Period,Cyclic

These properties only map to attributes of the Eventwhen used in combination with a Time Trigger. Inthis case, the Waiting Period property maps eitherto the TimeDate or the TimeCycle attribute of theTimer Event. It maps to the former if the Cyclic prop-erty is disabled, or to the latter if the Cyclic propertyis enabled. A translation is required, because Pro-tos uses a format that contains the number of days,hours, and minutes separated by colons. For example,‘01:02:03’ represents 1 day, 2 hours, and 3 minutes.


D.4. ACTIVITY AND SUB-PROCESS MAPPINGS 165

Trigger Property Mapping to BPMNType This property maps to the Trigger attribute of a Start

Event or an Intermediate Event, or to the Result at-tribute of an End Event. A Time Trigger maps to aTimer Event in BPMN and Trigger types Telephone,Mail, File, Software, Human, E-Business, and Emailapproximately map to a Message Event. To prop-erly map these last Trigger types, one could includemodeler-defined icons within the open center of anEvent.

Description This maps to the Documentation attribute of theEvent.

Instructions This could either be appended to the Documentationattribute of the Event or mapped to a modeler-definedattribute using the Properties attribute if one wantsto separate it from the Description property (above).

Trigger Contents This maps approximately to Data Objects (Artifacts)that are attached to the Event using Associations.

Applications This property does not map to any object or attributein BPMN. Note that Service, Receive, Send, and UserTasks (by analogy with invoke, receive, reply con-structs in BPEL4WS [26]) have an Implementationattribute that resembles the Applications property,but there is no suitable mapping for these Tasks toProtos.

Involved This property does not map to any objects or at-tributes, because BPMN has no notion of resources.

Extra This maps to the Properties attribute of the Event.

Table D.3: Trigger property mappings to BPMN

D.4 Activity and Sub-Process Mappings

An Activity Object models an atomic amount of work that forms a single stepin a process. A Sub-Process Object models a part of a process that serves asa logical grouping of Activities, Triggers, Statuses, and other Sub-Processes.

Figure D.4(a) on the following page shows the graphical representation of anActivity Object (top figure) and a Sub-Process Object (bottom figure). In thiscase, it is a Basic Activity which Name property is set to ‘Quality Control’ anda Sub-Process which Name property is set to ‘Process Notification’. Figure A.4on page 116 in Appendix A shows the graphical representation of other types ofActivities. Figure D.4(b) on the following page presents the properties dialogof an Activity. An Activity has the same properties as a Sub-Process, exceptfor the Type, Executor and Team properties that apply to Activities only.


(a) Activity Object (top) andSub-Process Object (bottom)

(b) Activity properties

Figure D.4: The graphical representation and properties of an Activity Objector a Sub-Process Object

An Activity or a Sub-Process in Protos maps to an Activity in BPMN forwhich the ActivityType attribute is set to ‘Task’ or ‘Sub-Process’, respectively,as explained in Section 3.1.1 on page 17. Table D.4 presents the mappings forthe properties of an Activity or a Sub-Process.

Activity or Sub-Process Property

Mapping to BPMN

Name This maps to the Name attribute of the Activity.Executor, Respon-sible, Team

These properties do not map to any attributes inBPMN, because BPMN has no notion of resources.Note that the properties Executor and Team applyto an Activity only.

Type This property applies to Activities only and it doesnot map to any object or attribute in BPMN. How-ever, Activities in BPMN have an open center that al-lows modeler-defined icons to be included within theshape to help identify the type of the Activity.


D.4. ACTIVITY AND SUB-PROCESS MAPPINGS 167


Mapping to BPMN

Multiple Protos uses this property to model a standardloop (reflects the programming constructs while anduntil) as well as to model a multi-instance loop (re-flects the programming construct for each). There-fore, it maps to the LoopType attribute of an Activitythat is either set to Standard or MultiInstance. Notethat BPMN has several other attributes to model aloop in more detail, like the LoopCondition and MI -Condition attributes.

Start Sub-Process,Start Process Model

Protos uses this property to model the start of a Sub-Process or a complete Process Model. The start of aprocess in BPMN is either defined using Start Eventsor, in the absence of any Start Event, by all Flow Ob-jects that have no incoming Sequence Flow. Whena Start Event is used, all other Flow Objects shouldhave at least one incoming Sequence Flow, with theexception of Compensation Activities. Furthermore,BPMN contains, unlike Protos, a Receive Task (byanalogy with a receive construct in BPEL4WS) thathas an Instantiate attribute to instantiate the enclos-ing process upon receival of a certain message. Fi-nally, an Exclusive Event-Based Gateway has a simi-lar Instantiate attribute.

End Sub-Process,End Process Model

Protos uses this property to model the termination ofa Sub-Process or a complete Process Model. BPMNuses a Terminate End Event for this purpose, but thespecification is unclear about whether such an Eventwill only terminate the enclosing Process or the com-plete Process. Following Protos, both properties mapto a Sequence Flow that targets at a Terminate EndEvent. See Section 3.1.8 on page 30 for an example.

User Initiative This partly maps to a User Task in BPMN, which isanalogous to an invoke construct in BPEL4WS. How-ever, a User Task involves the exchange of messages,which cannot be modelled in Protos.

Batch, Selective,Size, WaitingPeriod

These properties do not map to any objects or at-tributes, because BPMN has no notion of batch pro-cessing. However, a Standard Loop Activity could beused to model something similar to batch processing.

Description This maps to the Documentation attribute of the Ac-tivity.

Instructions This could either be appended to the Documentationattribute of the Activity or mapped to a modeler-defined attribute using the Properties attribute if onewants to separate it from the Description property.




Mapping to BPMN

Data This property approximately maps to the InputSetsattribute of the Activity. Such an InputSet modelsthe data that needs to be available for the Activity tobe performed. Therefore, all Data Objects for whichthe Mandatory property is enabled in the Data Tab(of the properties dialog) of an Activity or a Sub-Process map to a single InputSet that contains oneArtifact for each such Data Object. Moreover, theseArtifacts may be displayed and attached to the Ac-tivity using Associations.

Applications This property does not map to any objects or at-tributes in BPMN. Note that Service, Receive, Send,and User Tasks (by analogy with invoke, receive, replyconstructs in BPEL4WS) have an Implementation at-tribute that resembles the Applications property, butthere is no suitable mapping for these Tasks to Protos.

Involved This property does not map to any objects or at-tributes, because BPMN has no notion of resources.

Extra This maps to the Properties attribute of the Activity.IncomingConnections (on theSimulation Tab)

Protos uses this simulation property to indicate thejoin behaviour of the Activity: ‘and-join’, ‘xor-join’,or ‘or-join’. This property is mapped to a Gateway infront of the Activity, as discussed in Section 3.1.4 onpage 24. Note that simulation properties are an ex-tension to standard Protos. Moreover, this simulationproperty is only available for Activities.

OutgoingConnections (on theSimulation Tab)

Protos uses this simulation property to indicate thesplit behaviour of the Activity: ‘and-split’, ‘xor-split’,or ‘or-split’. This property is mapped to a Gatewayafter the Activity, as discussed in Section 3.1.4 onpage 24. Note that simulation properties are an ex-tension to standard Protos. Moreover, this simulationproperty is only available for Activities.

Table D.4: Activity and Sub-Process property mappings to BPMN

D.5. STATUS MAPPINGS 169

D.5 Status Mappings

A Status Object models a moment of ‘rest’ in a process. Figure D.5 showsthe graphical representation of a Status Object and the corresponding prop-erties dialog in Protos. In this case, the Name property is set to ‘NotificationReceived’.

(a) Status Object (b) Status properties

Figure D.5: The graphical representation and properties of a Status Object

Since BPMN has no a notion of states, a Status with a one input and one outputmaps to a Sequence Flow that connects the Objects between which the Statusis modelled, as shown in Section 3.1.1 on page 17. A Status with multipleinputs and one output maps to a Data-Based Exclusive Gateway, as explainedin Section 3.1.4 on page 24. A Status with one input and multiple outputs mapsto an Event-Based Exclusive Gateway, as discussed in Section 3.1.5 on page 27.In some cases, a status with multiple inputs and multiple outputs maps to anEvent-Based Exclusive Gateway. However, a mapping to BPMN is difficult,if not impossible, in case such a Status represents a milestone. Section 3.3.1on page 36 elaborates on the difficulties of representing a milestone in BPMN.Table D.5 presents the mappings for the properties of a Status that is eithermapped to a Sequence Flow or a Gateway.

Status Property Mapping to BPMNName This maps to the Name attribute of the Sequence

Flow or the Gateway.Description This maps to the Documentation attribute of the Se-

quence Flow or the Gateway.Continued on next page


Status Property Mapping to BPMNInstructions This could either be appended to the Documenta-

tion attribute of the Sequence Flow or the Gateway,or mapped to a modeler-defined attribute using theProperties attribute if one wants to separate it fromthe Description property (above).

Extra This maps to the Properties attribute of the SequenceFlow or the Gateway.

Table D.5: Status property mappings to BPMN

D.6 Connection and Trigger Connection Mappings

A Connection is used to show the order that Activities and Sub-Processes willbe performed. A Trigger Connection connects a Trigger Object to anotherTrigger, Activity, Sub-Process, or Status Object. Figure D.6(a) shows thegraphical representation of a Trigger Connection Object (top arc) and a Con-nection Object (bottom arc) in Protos. In this case, the type attribute of theTrigger Connection is set to Start. Figures A.11 and A.12 on page 119 inAppendix A show the graphical representation of other types of Trigger Con-nections. Figure D.6(b) presents the properties dialog of a Trigger Connection.A Connection has the same properties as a Trigger Connection, except for theType property that applies to a Trigger Connection only.

(a) Trigger Connection (top) andConnection Object (bottom)

(b) Trigger Connection properties

Figure D.6: The graphical representation and properties of a (Trigger) Con-nection Object

D.6. CONNECTION AND TRIGGER CONNECTION MAPPINGS 171

Both a Trigger Connection of type Set or Start and a Connection map to aSequence Flow in BPMN. Table D.6 presents the mappings for the propertiesof a Connection or a Trigger Connection.

(Trigger) Con-nection Property

Mapping to BPMN

From This maps to the Source attribute of the SequenceFlow.

To This maps to the Target attribute of the SequenceFlow.

Name This maps to the Name attribute of the SequenceFlow.

Type This property applies to Trigger Connections only. Itdoes not map to any object or attribute in BPMN. ATrigger Connection of type Set or Start – the defaultvalues for a Trigger Connection that targets at, ororiginates from, a Trigger, respectively – maps to aSequence Flow. A Trigger Connection of type TurnOff, Restart, or Cancel – which is defined for a TriggerConnection between two Trigger Objects only – doesnot map to any Connecting Object in BPMN.

Condition This maps to the ConditionExpression attribute ofthe Sequence Flow. An expression translation will berequired if the expression language (set in the Expres-sionLanguage attribute of a BPD) differs from the oneused by Protos.

Description This maps to the Documentation attribute of the Se-quence Flow.

Instructions This could either be appended to the Documenta-tion attribute of the Sequence Flow or mapped toa modeler-defined attribute using the Properties at-tribute if one wants to separate it from the Descrip-tion property (above).

Extra This maps to the Properties attribute of the SequenceFlow.

Table D.6: Connection and Trigger Connection property mappings to BPMN

Appendix E

Detailed Mapping from BPMNto Protos

Supplementary to the mapping from BPMN to Protos presented in Chapter4, this appendix covers a detailed mapping from object attributes in BPMNto object properties in Protos. Note that the attribute mappings presented inthis appendix are not beyond discussion. That is, alternative mappings mightbe possible.

BPMN is mapped onto standard Protos extended with simulation parame-ters, see for example Section 4.1.4 on page 45, to represent the split and joinbehaviour of Activities. Extra Information, as discussed in Section 4.3.2 onpage 58, will not be used to represent just any missing attribute representa-tion in Protos. Therefore, it will only be used as a mapping for the Propertiesattribute in BPMN, which was designed for the the same purposes.

E.1 Business Process Diagram Mappings

A private (internal) business process, i.e., a process that resides within a BPDthat has only one Pool, maps to a Process Model in Protos. Table E.1 presentsthe mappings for the attributes of such a BPD.

Business ProcessDiagram Attribute

Mapping to Protos

Id This maps to the Identification property of theProcess Model.

Name This maps to the Name property of the ProcessModel.

Version This maps to the Version property of the currentversion, i.e., the last version in the History, of theProcess Model.


173

174 APPENDIX E. DETAILED MAPPING FROM BPMN TO PROTOS

Business ProcessDiagram Attribute

Mapping to Protos

Author This maps to the Process Owner property of theProcess Model.

Language This does not map to any property in Protos.ExpressionLanguage Protos has its own expression language that can-

not be altered. If a BPD uses another expressionlanguage, all expressions need to be translated.

QueryLanguage This does not map to any property in Protos.Moreover, the specification introduces this at-tribute without mentioning a word about the useof queries in a BPD.

CreationDate This maps to the Date property of the currentversion, i.e., the last version in the History, ofthe Process Model.

ModificationDate This does not map to any property in Protos.Pools This is a list of Pools. Each Pool maps to a

Protos Model.Documentation This maps to the Description property of the

Process Model.

Table E.1: Business Process Diagram attribute mappings to Protos

E.2 Process Mappings

A BPMN Process consists of a set of activities that are performed within anorganisation or across organisations. It maps to a Main Process in Protos ifit is the top-level Process in a Pool or to a Sub-Process otherwise. Table E.2shows the mappings for the attributes of a Process.

Process Attribute Mapping to ProtosId This maps to a hidden identifier property of the

Main Process or the Sub-Process that resides inthe PAL-file of the Process Model.

Name This maps to the Name property of the MainProcess or the Sub-Process.

ProcessType A Private ProcessType maps to a Process Modelin Protos. An Abstract or Collaboration Pro-cessType containing more than one Pool cannotbe mapped to a single Process Model in Protos.Moreover, Protos has no notion of an AbstractProcess.


E.3. COMMON GRAPHICAL OBJECT MAPPINGS 175

Process Attribute Mapping to ProtosStatus This attribute does not map to any property in

Protos.GraphicalElements This is a list of all the graphical elements con-

tained within a Process. Each of these elementswill have their own mapping, as defined in thesections below.

Assignments This attribute does not map to any property inProtos.

Properties This maps to Extra Information properties of theMain Process or the Sub-Process.

Categories This attribute does not map to any property inProtos.

AdHoc,AdHocOrdering,AdHocCompletion-Condition

These attributes do not map to any properties orobjects in BPMN, because Protos has no notionof Ad-Hoc Sub-Processes.

SuppressJoinFailure,EnableInstance-Compensation

These attributes do not map to any properties inProtos, because they are included for the map-ping to BPEL4WS [26].

Documentation This maps to the Description property of theMain Process or the Sub-Process.

Table E.2: Process attribute mappings to Protos

E.3 Common Graphical Object Mappings

A Graphical Object is either a Flow Object, a Swimlane, an Artifact, or aConnecting Object. Each of these object types will have its own attributemappings, as defined in the sections below. Table E.3 shows the mappings forthe common attributes of a Graphical Object.

Common GraphicalObject Attribute

Mapping to Protos

Id This maps to a hidden identifier property of anObject that resides in the PAL-file of the ProcessModel.

Categories This attribute does not map to any property inProtos.

Documentation This maps to the Description property of an Ob-ject.

Table E.3: Common Graphical Object attribute mappings to Protos


E.4 Common Flow Object Mappings

A Flow Object is either an Event, an Activity, or a Gateway. Each of theseobject types will have its own attribute mappings, as defined in the sectionsbelow. Table E.4 shows the mappings for the common attributes of a FlowObject.

Common FlowObject Attribute

Mapping to Protos

Name This maps to a Name property of an Object.Assignments This attribute does not map to any objects or

properties in Protos.Pool, Lanes These attributes do not map to any objects or

properties, because Protos has no notion of Poolsand Lanes.

Table E.4: Common Flow Object attribute mappings to Protos

E.5 Event Mappings

An Event is something that happens during the course of a business process.It affects the flow of the process and usually has a cause (Trigger) or an impact(Result). Figure E.1 on page 178 shows the graphical representation of typesof Start Events (left column), Intermediate Events (middle column), and EndEvents (right column).

An Event in BPMN maps to a Trigger in Protos. Table E.5 shows the mappingsfor the attributes of an Event.

Event Attribute Mapping to ProtosEventType This attribute distinguishes between a Start

Events, an Intermediate Event, and an EndEvent. It does not map to any property of theTrigger, because Protos does not make this dis-tinction. However, Protos uses the Start Sub-Process property and the Start Process Modelproperty of an Activity to indicate the start of aProcess, as discussed in Section 3.1.1 on page 17.


E.5. EVENT MAPPINGS 177

Event Attribute Mapping to ProtosTrigger, Result The Trigger attribute applies to a Start Event

and an Intermediate Event, while the Result at-tribute applies to an End Event. A None StartEvent or a None End Event is omitted in Pro-tos and a None Intermediate Event maps to aStatus, as explained in Section 4.1.1 on page 39.A Message Event approximately maps to a MailEvent. A Timer Event maps to a Time Trigger.A pair of Link Events maps either to a Connec-tion or an Off-Page Connection. A TerminateEnd Event maps either to the End Sub-Processproperty or the End Process Model propertyof an Activity, as discussed in Section 3.1.8 onpage 30. Note that the BPMN specification isunclear about whether a Terminate End Eventwill only terminate the enclosing Process or thecomplete Process. A Multiple Event maps toseparate Triggers. Error, Cancel, Compensation,and Rule Events do not map to any Triggers inProtos. More details are discussed below.

Message,Implementation

These attributes apply to a Message Event only.A Message Event approximately maps to MailTrigger. Since Protos does not allow to modelthe contents, participants, or technology of aMail Trigger, the Message attribute and the Im-plementation attribute do not map to any prop-erties of the Mail Trigger.

TimeDate, TimeCycle These attributes apply to a Timer Event onlyand should not be used simultaneously. Theseattributes map to the Waiting Period of theTime Trigger. A translation is required, be-cause Protos uses a format for the Waiting Pe-riod property that contains the number of days,hours, and minutes separated by colons. For ex-ample, 01:02:03 represents 1 day, 2 hours, and3 minutes. Moreover, the TimeDate attributemaps to a disabled Cyclic property, while theTimeCycle attribute maps to an enabled Cyclicproperty.

ErrorCode This attribute applies to an Error Event only.It does not map to any objects or properties,because Protos has no notion of throwing andcatching errors.

Activity This attribute applies to a Compensation Eventonly. It does not map to any objects or proper-ties, because Protos has no notion of compensa-tion.



Event Attribute Mapping to ProtosRuleName,RuleExpression

These attributes apply to a Rule Event only.These attributes do not map to any objects or at-tributes, because Protos has no notion of eventsbased on rules.

LinkId, ProcessRef These attributes apply to a Link Event only anddo not directly map to any properties in Protos.A pair consisting of a Source Link and a TargetLink in the same process maps to Connection.Such a pair connecting different processes mapsto an Off-Page Connector.

Triggers This attribute applies to a Multiple Event only.Each Trigger maps separately as defined above,because a Trigger in Protos has has only one type(i.e., Type property). Since only one Trigger ofa Multiple Event is required to trigger the event,the corresponding Triggers in Protos should bemerged using a Status, or an Activity for whichthe Incoming Connections property set to ‘xorjoin’.

Table E.5: Event attribute mappings to Protos

Figure E.1: The graphical representation of Events

E.6. ACTIVITY MAPPINGS 179

E.6 Activity Mappings

An Activity is either a Task or a Sub-Process and represents work that has tobe performed. Figure E.2 presents the graphical representation of a Task, aCollapsed Sub-Process, and an Expanded Sub-Process.

(a) Task (b) Collapsed Sub-Process (c) Expanded Sub-Process

Figure E.2: The graphical representation of Activities

Figure E.3 shows the graphical representation of the various Sub-Process types,that is, a Compensation Sub-Process, a Standard Loop Sub-Process, a MultipleInstances Sub-Process, an Ad Hoc Sub-Process, and a Transaction Sub-Process.The first three types apply also to Tasks.

(a) Compensation (b) Loop (c) Multiple Instances (d) Ad Hoc (e) Transaction

Figure E.3: The graphical representation of Sub-Processes types

An Activity, i.e., a Task or a Sub-Process, in BPMN maps to an Activityor a Sub-Process in Protos. Table E.6 shows the mappings for the commonattributes of an Activity.

Common ActivityAttribute

Mapping to Protos

ActivityType This attribute distinguishes between a Sub-Process and a Task. The attribute mappings fora Sub-Process and a Task are defined below.

Status This attribute does not map to any property inProtos.

Properties This attribute maps to the Extra Informationproperties of the Activity or the Sub-Process.




Mapping to Protos

InputSets, Inputs These attributes are used to define sets of inputData Objects of which one needs to be availablefor the Activity to be performed (after it hasbeen instantiated by the appropriate signal ar-riving from an incoming Sequence Flow). TheseData Objects may also be displayed in the BPDand may be attached to the Activity through anAssociation. Only one set of input Data Objectscan be mapped to Protos. Each input Data Ob-ject in this set maps to a Document that is addedto the Data Tab (of the properties dialog) of theActivity or the Sub-Process in Protos. Moreover,the Mandatory property for such a Document inthe Data Tab should be set.

OutputSets, Outputs These attributes are used to define sets of out-put Data Objects of which one is produced atthe completion of the Activity. These Data Ob-jects may also be displayed in the BPD and maybe attached to the Activity through an Associa-tion. Only one set of output Data Objects canbe mapped to Protos. Each output Data Objectin this set maps to a Document that is addedto the Data Tab (of the properties dialog) of theActivity or the Sub-Process in Protos. More-over, the Created property for such a Documentin the Data Tab should be set.

IORules This attribute defines relationships between In-putSets and OutputSets. It does not map toany properties, because only one InputSet andone OutputSet can be mapped to Protos (seeabove).

StartQuantity This attribute defines the number of tokens thatwill be generated upon completion of the Activ-ity or the Sub-Process. It does not map to anyobject or property, because Protos only allowsone Connection (in the same direction) betweentwo Objects and at most one ‘token’ is generatedfor each outgoing Connection.

LoopType This attribute distinguishes between a StandardLoop Activity (reflects the programming con-structs while and until) and a Multi-InstanceLoop Activity (reflects the programming con-struct for each). Since Protos does not makethis distinction, this attribute approximatelymaps to an enabled Multiple property of the Ac-tivity or the Sub-Process.


E.6. ACTIVITY MAPPINGS 181


Mapping to Protos

LoopCondition,LoopCounter,LoopMaximum,TestTime

These attributes apply to a Standard Loop Ac-tivity only and do not map to any properties ofthe Task or the Sub-Process.

MI Condition, Loop-Counter, MI Ordering,MI FlowCondition,ComplexMI Flow-Condition

These attributes apply to a Multi-Instance LoopActivity only and do not map to any propertiesof the Task or the Sub-Process.

Table E.6: Common Activity attribute mappings to Protos

Sub-Process Mappings

A Sub-Process is a non-atomic amount of work that is broken down into a finerlevel of detail using a separate process. An Embedded Sub-Process in BPMNmaps to a Sub-Process in Protos. An Independent Sub-Process or a ReferenceSubProcess maps to a Linked Model. Table E.7 shows the mappings for theattributes of a Sub-Process.

Sub-ProcessAttribute

Mapping to Protos

SubProcessType This distinguishes between an Embedded Sub-Process, an Independent Sub-Process, and a Ref-erence Sub-Process. The first one maps to a Sub-Process in Protos, while the last two map to aLink Model.

IsATransaction,TransactionId,TransactionProtocol,TransactionMethod

These attributes do no map to any properties ofthe Sub-Process, because Protos has no notionof transactions.

GraphicalElements This attribute applies to an Embedded Sub-Process only and contains a list of all the graph-ical elements contained within the Sub-Process.Each of these elements will have their own map-ping, as defined in this appendix.

AdHoc, AdHocOrdering,AdHocCompletionCon-dition

These attributes apply to an Embedded Sub-Process only. These attributes do not map toany property of the Sub-Process. However, itwould be sufficient to add similar properties toa Sub-Process in Protos in order to support Ad-Hoc Sub-Processes.



Sub-ProcessAttribute

Mapping to Protos

DiagramRef, ProcessRef These attributes apply to an Independent Sub-Process only and map to the identifier propertyof the Link Model that is hidden in the PAL-fileof the Process Model.

InputPropertyMaps,OutputPropertyMaps

These attributes apply to an Independent Sub-Process only. These attributes map approxi-mately to the data assignments contained in theData Assignment Tab of the properties dialogof a Link Model, if the Properties can be repre-sented by Data Objects, e.g. a Document Ob-ject, in Protos.

SubProcessRef This attribute applies to a Reference Sub-Process only. It maps to the identifier propertyof the Link Model that is hidden in the PAL-fileof the Process Model.

Table E.7: Sub-Process attribute mappings to Protos

Task Mappings

A Task is an atomic amount of work that maps to an Activity in Protos. TableE.8 shows the mappings for the attributes of a Task.

Task Attribute Mapping to ProtosTaskType This attribute distinguishes between several

Task types. TaskType None maps to an Activityin Protos. TaskType Reference maps to a LinkModel that contains only one Activity. All otherTask types, i.e., Service, Receive, Send, User,Script, and Manual do not map to any Objectin Protos. For the time being, these Task typescould simply be mapped to Protos Activities.

Table E.8: Task attribute mappings to Protos

E.7 Gateway Mappings

A Gateway controls the divergence and convergence of Sequence Flow. Fig-ure E.4 on the next page shows the graphical representation of a Gateway.

E.7. GATEWAY MAPPINGS 183

(a) Exclusive Data-Based Gateway

(b) Exclusive Event-Based Gateway

(c) ParallelGateway

(d) InclusiveGateway

(e) ComplexGateway

Figure E.4: The graphical representation of Gateways

Figure E.5 illustrates that a Parallel Gateway, an Exclusive Data-Based Gate-way (shown in the figure), or an Inclusive Gateway with a single incoming Se-quence Flow that originates from a Task that has no other outgoing SequenceFlows, maps to an Activity in Protos for which the Outgoing Connections prop-erty (as shown in Figure A.8 on page 118) is set to ‘and split’,‘xor split’, or ‘orsplit’, respectively.

(a) (b)

Figure E.5: Mapping of a Task and a subsequent Gateway in BPMN (on theleft) to a single Activity in Protos (on the right)

Figure E.6 illustrates that a Parallel Gateway or an Inclusive Gateway (shownin the figure) with a single outgoing Sequence Flow that targets at a Task thathas no other incoming Sequence Flows, maps to an Activity in Protos for whichthe Incoming Connections property (as shown in Figure A.8 on page 118) isset to ‘and join’ or ‘or join’, respectively.

(a) (b)

Figure E.6: Mapping of a Gateway and a subsequent Task in BPMN (on theleft) to a single Activity in Protos (on the right)

As shown in Figure E.6, an Exclusive Gateway with one outgoing SequenceFlow that targets at a Task that has no other incoming Sequence Flows, prefer-ably maps to a Status and a subsequent Activity in Protos. Note that such aGateway could also be mapped to an Activity for which the Incoming Connec-tions property is set to ‘xor join’.

In all other cases, an Exclusive Data-Based Gateway, a Parallel Gateway, or anInclusive Gateway maps to a fresh Activity in Protos for which the IncomingConnections or Outgoing Connections property is set accordingly. Note that


(a) (b)

Figure E.7: Mapping of an Exclusive Gateway and a subsequent Task in BPMN(on the left) to a single Activity in Protos (on the right)

a Sub-Process in Protos has no Incoming Connections and Outgoing Connec-tions properties. Therefore, the mappings above with BPMN Sub-Processessubstituted for Tasks, apply to Parallel Gateways only, because their split andjoin behaviour is similar to the default behaviour of a Sub-Process in Protos.Hence, fresh Tasks are used to represent the other Gateways.

As shown in Section 4.1.3 on page 44, an Exclusive Event-Based Gateway mapsto a Status in Protos and the output Intermediate Events of such a Gatewaymap to Triggers that determine which outgoing Connection of the Status willbe chosen. A Complex Gateway does not directly map to any Object in Protos,because of the IncomingCondition and OutgoingCondition attributes discussedbelow.

Gateway Attribute Mapping to ProtosGates,Outgoing-SequenceFlow,Assignments

The first two attributes contain a list of all theoutgoing Sequence Flows. Each of these ele-ments will have their own mapping, as definedin the Section E.10. The Assignments attributedoes not map to any property in Protos.

DefaultGate,OutgoingSequenceFlow,Assignments

This applies to an Exclusive Gateway or an In-clusive Gateway only. The first two attributescontain an outgoing Default Sequence Flow thatmaps as defined in the Section E.10. The Assign-ments attribute does not map to any property inProtos.

XORType This applies to an Exclusive Gateway only. Thisattribute distinguishes between a Data-BasedExclusive Gateway and an Event-Based Exclu-sive Gateway. It does not map to any property,because these elements map to different objectsin Protos, which makes these attributes irrele-vant.

MarkerVisible This applies to a Data-Based Exclusive Gatewayonly. This attribute does not map to any prop-erty in Protos (type is never shown).


E.8. SWIMLANE MAPPINGS 185

Gateway Attribute Mapping to ProtosIncomingCondition,OutgoingCondition

This applies to a Complex Gateway only. Theseattributes do not directly map to any propertyor object in Protos. In certain cases it might bepossible to map a Complex Gateway to Protos,but that requires at least an interpretation ofthese two attributes and the expression language(i.e., ExpressionLanguage atribute) of the BPD.

Table E.9: Gateway attribute mappings to Protos

E.8 Swimlane Mappings

Swimlanes consist of Pools and Lanes. A Pool represents a participant in aprocess and a Lane is a sub-partition within a Pool that is used to organise andcategorise Activities in a Pool. Figure E.8 shows the graphical representation ofa Swimlane that models a Supplier and contains a Lane for a Sales departmentand another Lane for a Distribution department.

Figure E.8: The graphical representation of Swimlanes

Protos has no notion of Pools and Lanes. As discussed in Section E.1 onpage 173, a private (internal) business process in BPMN, i.e., a process thatresides within a BPD that has only one Pool, maps to a Process Model inProtos. Tables E.10 and E.11 show the mappings for the attributes of thissingle Pool and the Lanes that are contained in it.

Pool Attribute Mapping to ProtosName This attribute does not map to any property or

object in Protos.Process If this Pool maps to a Process Model in Pro-

tos, then this attribute refers to the Process thatmaps to the Main Process in that Process Model.



Pool Attribute Mapping to ProtosParticipant If this Pool maps to a Process Model in Pro-

tos, then this attribute maps to a Role or RoleGroup in Protos. Note that Protos uses Roles,Role Groups, and Teams to model resources, i.e.,participants.

Lanes Protos has no notion of Lanes, but a Rectangu-lar Graphics Object or a Text Graphics Objectcould be used to mimic a Lane.

BoundaryVisible This attribute does not map to any element orproperty in Protos. However, a BPD with a sin-gle Pool for which this attribute is set to False isvery similar to a Protos Model, except for data,resources, etc.

Table E.10: Pool attribute mappings to Protos

Lane Attribute Mapping to ProtosName, ParentPool,ParentLane

These attributes do not map to any elements orproperties in Protos.

Table E.11: Lane attribute mappings to Protos

E.9 Artifact Mappings

An Artifact provides additional information about a process without directlyaffecting the process. A Data Object provides information about what anActivity requires to be performed or what an Activity produces. A Text An-notation provides information to the reader of the diagram. A Group is a boxaround a group of elements for documentation of analysis purposes. FigureE.9 shows the graphical representation of these Artifacts: a Data Object thatmodels an Issue List, a Text Annotation that communicates to the reader thatone should allow one week for the discussion of the issues, and a Group.

(a) Data Object (b) Text Annotation (c) Group

Figure E.9: The graphical representation of Artifacts

E.9. ARTIFACT MAPPINGS 187

Table E.12 shows the mappings for the common attributes of an Artifact.

Common ArtifactAttribute

Mapping to Protos

ArtifactType This attribute does not map to any element orattribute in Protos, because it is only used to de-termine the type of the Artifact, i.e., Data Ob-ject, Text Annotation, or Group, and each Arti-facts type maps to a different Objects in Protosas shown below.

Pool, Lane These attributes do not map to any element orproperty, because Protos has no notion of Swim-lanes.

Table E.12: Common Artifact attribute mappings to Protos

A Data Object maps to a Document Object in Protos. As will be discussedin Section E.10, such a Document should be contained in the Data Tab (ofthe properties dialog) of an Activity or a Sub-Process to which it is connectedthrough an Association. Note that a Data Object could be contained in aninput or output set of Data Objects for an Activity, as explained in SectionE.6. Table E.13 shows the mappings for the other attributes of a Data Object.

Data ObjectAttribute

Mapping to Protos

Name This maps to the Name property of the Docu-ment.

State The attribute does not map to any property ofthe Document.

Properties This maps to the Extra Information propertiesof a Document and may be used to add modeler-defined attributes.

RequiredForStart This maps to the Mandatory property which canbe set when the Document is added to the DataTab of an associated Activity or Sub-Process.

ProducedAtCompletion This maps to the Created property which canbe set when the Document is added to the DataTab of an associated Activity or Sub-Process.

Table E.13: Data Object attribute mappings to Protos


A Text Annotation maps to a Text Field Graphics Object in Protos. TableE.14 shows the mappings for the other attributes of a Text Annotation.

Text Annotation At-tribute

Mapping to Protos

Text The maps to the text shown in the Text FieldGraphics Object.

Table E.14: Text Annotation attribute mappings to Protos

A Group approximately maps to a Rectangular Graphics Object or a TextboxGraphics Object in Protos. The graphical representation of a Textbox GraphicsObject is similar to a Rectangular Graphics Object, but it allows text to beadded. Table E.15 shows the mappings for the other attributes of a Group.

Group Attribute Mapping to ProtosName It a Group is mapped to a Text Field Graph-

ics Object, then this attribute maps to the textinside this Textbox. If a Group is mapped toa Rectangular Graphics Object, then this at-tribute does not map to any property of thatRectangular Graphics Object.

Table E.15: Group attribute mappings to Protos

E.10 Connecting Object Mappings

BPMN defines various Connecting Objects. A Sequence Flow, which might beConditional or Default, is used to show the order in which activities will beperformed in a process. A Message Flow is used to show the flow of messagesbetween participants. An Association, either directional or not, is used toassociate information with Flow Objects. Figure E.10 on the facing page showsthe graphical representation of these Connection Objects.

As discussed in Section E.1 on page 173, a private (internal) business process,that is, a process that resides within a single Pool, maps to a Process Modelin Protos. Since a Message Flow models the exchange of messages betweenParticipants in different Pools, it does not adequately map to any object inProtos. Note that the author makes a subjective choice here; some may ar-gue that Triggers in different Process Models in Protos could be used for thispurpose.

E.10. CONNECTING OBJECT MAPPINGS 189

(a) Sequence Flow (b) Conditional Sequence Flow (c) Default Sequence Flow

(d) Message Flow (e) Association (f) Directional Association

Figure E.10: The graphical representation of Connecting Objects

An Association does not directly map to any object in Protos. An Associationthat is used to attach a Text Annotation to a Flow Object, non-graphicallymaps to the Object property of a Text Field Graphical Object. Protos usesthis property to associate a Text Field Graphical Object to an Activity, a Sub-Process, or a Trigger. As shown in Section E.9, a Data Object maps to aDocument in Protos. An Association that associates a Data Object to a Taskor a Sub-Process maps to Protos by adding the Document to the Data Tab(in the properties dialog) of the associated Activity or Sub-Process. Note thatsuch a Data Object in BPMN could be contained in an input or output set ofData Objects for that Activity, as discussed in Section E.6 on page 179.

A Sequence Flow maps to a Connection in Protos. Table E.16 presents themappings for the attributes of a Sequence Flow.

Sequence FlowAttribute

Mapping to Protos

Name This maps to the Name property of the Connec-tion.

Source This maps to the From property of the Connec-tion.

Target This maps to the To property of the Connection.ConditionType This attribute indicates whether a Sequence

Flow is Conditional or Default. See the Condi-tionExpression attribute below for a mapping ofConditional Sequence Flow. Protos has no sepa-rate default Connection, but a Default SequenceFlow maps to a Connection for which the Condi-tionExpression property is set to the negation ofthe conjunction of the conditions (see the Condi-tionExpression attribute below) of all other out-going Sequence Flows.

ConditionExpression This applies to a Conditional Sequence Flowonly. This attribute maps to the Condition prop-erty of the Connection. A translation will berequired if the expression language used by Pro-tos differ from the one set in the ExpressionLan-guage attribute of the BPD.



Sequence FlowAttribute

Mapping to Protos

Quantity This attribute defines the number of tokens thatwill be generated. It does not map to any objector property, because Protos only allows one Con-nection (in the same direction) between two Ob-jects and at most one ‘token’ is generated uponcompletion of the Object that is the source (seethe Source attribute above) of the Connection.

Table E.16: Sequence Flow attribute mappings to Protos

Appendix F

Example Reducible OR-joins

This appendix illustrates the algorithm for reducing OR-joins presented inChapter 6 with the help of a larger example. In order to show the relationwith BPMN, the Business Process Diagram (BPD) in Figure F.1 on the nextpage is used as an starting point. A valid EWF-net abstraction of this processmodel is presented in Figure F.2 on page 193.

As Definition 22 on page 101 shows, the algorithm first transforms the EWF-netinto an R-net. Then the algorithm repetitively selects a reduction or auxiliarypattern and applies the corresponding rule to it. For readability purposes, theselection of a pattern will be visualised by shading the nodes that belong tothe pattern and the result of applying a rule will be visualised by thickeningthe border and writing the label in italics of altered or inserted tasks.

191

192A

PP

EN

DIX

F.

EX

AM

PLE

RE

DU

CIB

LE

OR

-JO

INS

Figure F.1: The BPD that is used as a starting point

193

The algorithm first looks for REDUCE-OR-OR-patterns. Since such a pat-tern is not present, the algorithm then looks for REDUCE-XOR-OR-patterns.Such a pattern is also not present and the algorithm subsequently looks forREDUCE-AND-OR-patterns. Such a pattern is present, hence the REDUCE-AND-OR-pattern with AND-split input task t7 and OR-join output task t25is selected in Figure F.2. The interesting thing is that this pattern allowsAND-split task t9 to have a connection to condition c18 outside the pattern.

Figure F.2: The R-net that is used as an abstraction of the BPD. Moreover, aREDUCE-AND-OR-pattern is selected.

194 APPENDIX F. EXAMPLE REDUCIBLE OR-JOINS

Figure F.3 shows how OR-join task t25 is reduced to an AND-join task basedon the selected REDUCE-AND-OR-pattern. As shown in Definition 22, inthe absence of REDUCE-OR-OR-patterns, REDUCE-XOR-OR-patterns, andREDUCE-AND-OR-patterns, the algorithm looks for maximal AUX-NO-OR-FOLD-patterns. Such a pattern is present, hence the AUX-NO-OR-FOLD-pattern with AND-split input task t7 and AND-join output task t28 is selectedin Figure F.3.

Figure F.3: OR-join task t25 is reduced to an AND-join task. Moreover, anAUX-NO-OR-FOLD-pattern is selected.

195

Figure F.4 shows how fold task tf1 replaces the selected subnet identified bythe AUX-NO-OR-FOLD-pattern. As shown in Definition 22, in the absenceof REDUCE-OR-OR-patterns, REDUCE-XOR-OR-patterns, and REDUCE-AND-OR-patterns, the algorithm looks once again for maximal AUX-NO-OR-FOLD-patterns. Such a pattern is present, hence the AUX-NO-OR-FOLD-pattern with input condition c14 and XOR-join and XOR-split output task t24is selected in Figure F.4.

The interesting things are the input condition and the loop contained in theselected AUX-NO-OR-FOLD-pattern. Input condition c14 will result in a foldtask with XOR-join behaviour. This input condition will be restored when theR-net is unfolded at the end of the algorithm. The loop will be folded togetherwith all other nodes and connections between these nodes in the selected AUX-NO-OR-FOLD-pattern.

Figure F.4: R-net showing the result of folding the selected subnet into foldtask tf1. Moreover, an AUX-NO-OR-FOLD-pattern is selected.


Figure F.5 shows how fold task tf2 replaces the selected subnet identified bythe AUX-NO-OR-FOLD-pattern. Note that the XOR-join behaviour of tf2

represents the join behaviour of the folded input condition c14.

According to Definition 22, a maximal AUX-INSERT-JOIN-patterns is thenext pattern that the algorithm identifies. Hence, this AUX-INSERT-JOIN-pattern, which is based on a BASIC-XOR-OR-pattern, with input conditionc4 and OR-join output task t27 is selected in Figure F.5. The algorithm selectsmaximal AUX-INSERT-JOIN-patterns only to limit the number of insertionsof fresh tasks. Therefore, the smaller AUX-INSERT-JOIN-pattern with XOR-split input task t4 and OR-join output task t27 will not be selected.

Figure F.5: R-net showing the result of folding the selected subnet into foldtask tf2. Moreover, an AUX-INSERT-JOIN-pattern based on a BASIC-XOR-OR-pattern (variant 1) is selected.

197

Figure F.6 shows how XOR-join task tj1 is inserted before OR-join task t27based on the AUX-INSERT-JOIN-pattern. Task tj1 has XOR-join behaviour,because the selected AUX-INSERT-JOIN-pattern is based on the XOR-OR-pattern.

According to Definition 22, the algorithm then selects a maximal AUX-NO-OR-FOLD-pattern with input condition c4 and the just-inserted XOR-join outputtask tj1, as shown in Figure F.6.

Figure F.6: XOR-join task tj1 is inserted. Moreover, an AUX-NO-OR-FOLD-pattern is selected.

Figure F.7 on the following page shows how fold task tf3 replaces the subnetidentified by the AUX-NO-OR-FOLD-pattern. According to Definition 22,the algorithm looks for minimal AUX-LUCKY-FOLD-patterns when no otherpattern can be found. Such a pattern is present, hence this AUX-LUCKY-FOLD-pattern with input condition c3 and OR-join output task t21 is selectedin Figure F.7. Consequently, OR-join task t21 will be folded, because it cancurrently not be reduced.

The algorithm selects minimal AUX-LUCKY-FOLD-patterns only to preventOR-join tasks from being folded unnecessarily, that is, it might be possible toreduce such an OR-join after a minimal AUX-LUCKY-FOLD-pattern has beenfolded.


Figure F.7: R-net showing the result of folding the selected subnet into foldtask tf3. Moreover, an AUX-LUCKY-FOLD-pattern is selected.

Figure F.8 shows how fold task tf4 replaces the subnet identified by the selectedAUX-LUCKY-FOLD-pattern. According to Definition 22, an AUX-INSERT-OR-SPLIT-pattern is the following pattern that the algorithm encounters. Forthat reason, the AUX-INSERT-OR-SPLIT-pattern, which is based on an OR-OR-pattern, with OR-split input task t1 and OR-join output task t27 is selectedin Figure F.8.

Figure F.8: R-net showing the result of folding the selected subnet into foldtask tf4. Moreover, an AUX-INSERT-OR-SPLIT-pattern is selected.

199

Figure F.9 shows how OR-split task ts1 is inserted after OR-split task t1 basedon the selected AUX-INSERT-OR-SPLIT-pattern. The algorithm then selectsa REDUCE-OR-OR-pattern with the just-inserted OR-split input task ts1 andOR-join output task t27, as shown in Figure F.9.

Figure F.9: Insertion of OR-split task ts1. Moveover, a REDUCE-OR-OR-pattern is selected.

Figure F.10 shows how, based on the selected REDUCE-OR-OR-pattern, OR-split task ts1 and OR-join task t27 are reduced to tasks with AND-behaviourand that pairs of an XOR-split task and an XOR-join task are added aroundeach branch between these tasks to either enable of skip a branch. Moreover, itshows that the algorithm subsequently selects the AUX-NO-OR-FOLD-patternwith the just-introduced AND-split input task ts1 and AND-join output taskt27.

Figure F.10: OR-behaviour of split task ts1 and join task t27 are reducedto AND-behaviour and XOR-split and XOR-join tasks are inserted to enableor bypass branches between ts1 and t27. Moreover, an AUX-NO-OR-FOLD-pattern is selected.


Figure F.11 shows how fold task tf5 replaces the subnet identified by the AUX-NO-OR-FOLD-pattern. Furthermore, it shows the selection of the REDUCE-OR-OR-pattern with OR-split input task t1 and OR-join output task t29.

Figure F.11: R-net showing the result of folding the subnet into fold task tf5.Moveover, a REDUCE-OR-OR-pattern is selected.

Figure F.12 shows how, based on the selected REDUCE-OR-OR-pattern, OR-split task t1 and OR-join task t29 are reduced to tasks with AND-behaviourand that pairs of an XOR-split task and an XOR-join task are added aroundeach branch between these tasks to either enable of skip a branch.

Figure F.12: OR behaviour of split task t1 and join task t29 are reduced toAND behaviour and insertion of XOR-split and XOR-join tasks to enable orbypass branches between t1 and t29.

As shown in Definition 22, the algorithm unfolds the R-net when none of thereduction or auxiliary patterns is present in the R-net or when all OR-joinsin the R-net are either removed or folded. The latter is the case, hence thealgorithm unfolds the R-net.

Figure F.13 on page 202 shows the resulting R-net after unfolding all foldedtasks. Any altered or inserted task is emphasised by thickening its border andwriting its label in italics. To sum up: OR-split task t1 is reduced to an AND-split task; OR-join tasks t25, t27, and t29 are reduced to an AND-join task;AND-split task ts1 is added; XOR-split tasks t(t1,c2), t(t1,tf5), t(ts1,tf4), t(ts1,tf3),and t(ts1,c5) are added; and XOR-join tasks tj1, t(c27,t29), t(c34,t29), t(c28,t27),t(tf3,t27), and t(c35,t27) are added. Note that OR-join task t21 remains.

According to Definition 22, the algorithm concludes by transforming the R-netback into an EWF-net and outputting this EWF-net. Remember that a BPDwas used as a starting point for this example and that the EWF-net was usedas an abstraction of this BPD. Figure F.14 on page 203 presents the result aftertransforming this abstract EWF-net back into a BPD.

In conclusion, all OR-joins in the example BPD are removed except for OR-jointask t21. As a matter of fact, it turns out that the generic REDUCE-AND-OR-rule, as discussed at the end of Chapter 6 in the context of further research, is

201

capable of reducing this OR-join. Figure 6.21 on page 108 shows this reductionrule. When applied to the R-net in Figure F.7 on page 198, it would selectthe subnet with AND-split input tasks t2 and t3 and OR-join output task t21.Therefore, even this OR-join could be removed after formalising the genericREDUCE-AND-OR-rule.

202A

PP

EN

DIX

F.

EX

AM

PLE

RE

DU

CIB

LE

OR

-JO

INS

Figure F.13: Resulting R-net after unfolding

203

Figure F.14: Resulting BPD

Bibliography

[1] W.M.P. van der Aalst, J. Desel, and E. Kindler. On the Semantics of EPCs:A Vicious Circle. In M. Nttgens and F.J. Rump, editors, Proceedings ofthe EPK 2002: Business Process Management using EPCs, 2002.

[2] W.M.P. van der Aalst and K.M. van Hee. Workflow Management: Models,Methods, and Systems. MIT press, Cambridge, MA, 2004.

[3] W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske. BusinessProcess Management: A Survey. In W.M.P. van der Aalst, A.H.M. terHofstede, and M. Weske, editors, International Conference on BusinessProcess Management (BPM 2003), volume 2678, pages 1–12, 2003.

[4] W.M.P. van der Aalst and K.B. Lassen. Translating Workflow Nets toBPEL. BPM Center Report BPM-05-16, BPMcenter.org, 2005.

[5] W.M.P. van der Aalst, M. Weske, and D. Grunbauer. Case Handling:A New Paradigm for Business Process Support. Data and KnowledgeEngineering, 53(2):129–162, 2005.

[6] A. Alves, A. Arkin, and S. Askary et al. Web Services Business ProcessExecution Language Version 2.0. Public review draft, OASIS, August2006.

[7] R.M. Dijkman, M. Dumas, and C. Ouyang. Formal Semantics and Auto-mated Analysis of BPMN Process Models. Preprint # 7115, QueenslandUniversity of Technology, April 2007.

[8] M. Dumas, A. Grosskopf, T. Hettel, and M.T. Wynn. Semantics of BPMNProcess Models with OR-joins. Preprint # 7261, Queensland Universityof Technology, April 2007.

[9] B. Kiepuszewski. Expressiveness and Suitability of Languages for ControlFlow Modeling in Workflows. PhD thesis, Faculty of Information Tech-nology Queensland University of Technology, Brisbane, Australia, 2003.Available via http://www.workflowpatterns.com.

[10] E. Kindler. On the semantics of EPCs: A framework for resolving thevicious circle. Technical Report, Reihe Informatik tr-ri-03-243, ComputerScience Department, University of Paderborn, Paderborn, Germany, Au-gust 2003.

205

206 BIBLIOGRAPHY

[11] J. Mendling. Detection and Prediction of Errors in EPC Business Pro-cess Models. PhD thesis, Vienna University of Economics and BusinessAdministration, Vienna, Austria, May 2007.

[12] M. Netjes, H.A. Reijers, and W.M.P. van der Aalst. FileNet’s BPM life-cycle support. BPM Center Report BPM-06-07, BPMcenter.org, 2006.

[13] M. Nielsen and V. Sassone. Petri nets and other models of concurrency.In W. Reisig and G. Rozenberg, editors, Advances in Petri Nets, Lectureson Petri Nets I: Basic Models, volume 1491 of LNCS, pages 587–642.Springer, 1998.

[14] N. Palmer. Understanding the BPMN-XPDL-BPEL Value Chain. Busi-ness Integration Journal, 2006.

[15] J. Recker, M. Indulska, M. Rosemann, and P. Green. Do Process ModellingTechniques Get Better? A Comparative Ontological Analysis of BPMN.In B. Campbell, J. Underwood, D. Bunker (eds.): Proceedings of the 16thAustralasian Conference on Information Systems. Australasian Chapterof the Association for Information Systems, Sydney, Australia, November2005.

[16] N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and N. Mulyar.Workflow Control-Flow Patterns: A Revised View. BPM Center ReportBPM-06-22, BPMcenter.org, 2006.

[17] G. Shanks, E. Tansley, and R. Weber. Using Ontology to Validate Con-ceptual Models. Communications of ACM, 46(10):85–89, 2003.

[18] R. Shapiro and M. Martin. Process Definition Interface – XML ProcessDefinition Language (XPDL) Version 2.0. WFMC-TC-1025 FINAL, TheWorkflow Management Coalition, October 2005.

[19] B. Silver. The Two Faces of BPMN.http://www.brsilver.com/wordpress/2006/07/03/the-two-faces-of-bpmn/, July 2007. accessed 8 July 2007.

[20] K. Swenson. The BPMN-XPDL-BPEL value chain.http://kswenson.wordpress.com/2006/05/26/bpmn-xpdl-and-bpel/,May 2006. accessed 28 March 2007.

[21] Y. Wand and R. Weber. An Ontological Model of an Information System.IEEE Transactions on Software Engineering, 16(11):1282–1292, 1990.

[22] Y. Wand and R. Weber. On the Ontological Expressiveness of InformationSystems Analysis and Design Grammars. Journal of Information Systems,3, 1993.

[23] Y. Wand and R. Weber. On the Deep Structure of Information Systems.Journal of Information Systems, 5:203–223, 1995.

[24] S.A. White. Introduction to BPMN. Technical report, 2004.

207

[25] S.A. White. Process Modeling Notations and Workflow Patterns. In L. Fis-cher, editor, Workflow Handbook 2004, pages 265–294. Future StrategiesInc., Lighthouse Point, Florida, USA, 2004.

[26] S.A. White et al. Business Process Modeling Notation Specification. FinalAdopted Specification, OMG, February 2006.

[27] W.M.P. van der Aalst and A.H.M. ter Hofstede. YAWL: Yet AnotherWorkflow Language. BPM Center Report BPM-05-01, BPMcenter.org,2005.

[28] P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, andN. Russell. Pattern-Based Analysis of the Control-Flow Perspective ofUML Activity Diagrams. In L. Delcambre, C. Kop, H.C. Mayr, J. My-lopoulos, and O. Pastor, editors, 24nd International Conference on Con-ceptual Modeling (ER 2005), volume 3716, pages 63–78, 2005.

[29] P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, andN. Russell. On the Suitability of BPMN for Business Process Modelling. InS. Dustdar, J.L. Faideiro, and A. Sheth, editors, International Conferenceon Business Process Management (BPM 2006), volume 4102 of LectureNotes in Computer Science, pages 161–176, Berlin, 2006.

[30] M.T. Wynn. Semantics, Verification, and Implementation of Workflowswith Cancellation Regions and OR-joins. PhD thesis, Faculty of Informa-tion Technology Queensland University of Technology Brisbane, Australia,June 2006.

[31] M.T. Wynn, D. Edmond, W.M.P. van der Aalst, and A.H.M. ter Hof-stede. Achieving a General, Formal and Decidable Approach to theOR-join in Workflow using Reset nets. In Proceedings of the 26th In-ternational Conference On Application and Theory of Petri Nets andOther Models of Concurrency, Miami, Florida, June 2005. Springer Verlag.http://www.yawl.fit.qut.edu.au/documentation/.

From Protos to BPMN and back - TU/e · A mapping from Protos to BPMN and back is developed to...

Documents

Transcript of From Protos to BPMN and back - TU/e · A mapping from Protos to BPMN and back is developed to...