Semantic Preserving, Notational and Transformational Challenges in Transfiguring BPMN models into Petri Nets

Abstract

The paper identifies several issues and problems in converting BPMN models into formal Petri Net models. The conversion of BPMN models into Petri nets has been attempted for about a decade, but the richness and diversity in the BPMN's toolset continues to demand research attention towards completeness and accuracy in conversion of BPMN elements into equivalent and modular and hence comprehensible Petri net constructs. The paper discusses two classes of modeling gaps, and presents hidden and overlooked hurdles that cause inaccurate transformation of BPMN models. These hurdles encompass challenges encountered by modelers during actual transformation, impediments arising due to notations, and pitfalls faced while designing transformation strategies in order to accurately accommodate semantics.

Keywords

• eol>Business Processes
• BPMN
• Petri Nets
• Processes Modeling
• Model Transformation

1. Introduction

these gaps at two edges of mapping levels in lifespan of processes, specifically at modeling and analysis phase.

Business Process Model and Notation (BPMN), a standard Intended and Modeled Behavior Gaps. Semantic specification for high level business process modeling, gap between intended process behavior and modeled is generally coupled with Petri Nets (PNs) for purposes behavior refers to the diference between the desired of formal analysis, verification, etc. of BPMN process behavior of a process and its actual representation in models. BPMN can handle the visual modeling segment a high level visual model. These gaps have also been for the processes, and Petri nets can be utilised for their elaborated, analysed for root cause and attempted for formal analysis and verification. However, we observe reduction by Karnika and Joshi [ 2 ]. Such class of semantic incompleteness, inconsistencies and ambiguities in trans- gaps exist due to notational defects of high level visual formation rules in the current literature. We elucidate modeling languages such as non-compactness [ 2 ] [ 3 ] them as Transformational Challenges. They include Nota- [ 4 ], notational complexity [ 5 ] [ 4 ], redundancy [ 1 ] [ 6 ] [ 5 ] tional Impediments, such as ambiguous descriptions of a [ 2 ], ambiguousness [ 7 ] [ 8 ]. These defects form notational few BPMN elements, transformational inadequacy for re- impediments during development of transformation rules dundant BPMN notations, etc. Furthermore, we present for translating visual models into formal models. Semantics Preservation Pitfalls, that occur on account of Visualised and Analysed-Model Gaps. Sometimes, semantics, and need to be addressed for preserving fea- modeled process behavior is not accurately transformed tures of process-oriented visual modeling notations. This into the analysis models. This inaccuracy leads to a state paper brings out these challenges that need to be ad- where some diferent process behavior is analysed instead dressed for precise transformation of BPMN models. of the modeled process behavior. This diference refers to Visualised and Analysed behavior gap between the 2. Behavioral Semantic Gaps two models. In order to precisely transform the behavior of visual models into formal models, and ensure that the correct model is being analyzed, the need is to have accuracy in transformation rules.

Semantic gaps are the discrepancies or inconsistencies in the meaning or interpretations. They are presented in the context of process modeling in [ 1 ] [ 2 ]. We define

3. Semantic Preservation Pitfalls

Handling the Defaults. BPMN 2.0 [ 9 ] provisions two transformations difer in consideration of position at Default flow as separate notation in visual classification which fault generation is expected in control flow trace. of sequence flows and as options in gateway constructs. Multiple Instantiation. BPMN permits multiple inHowever, former is semantically defined as Sequence- stantiation through multiple start events, multiple-start Flows rather than a separate visual notation, and has event, etc., and manages these contexts using mechanism selfsame XML schema definition similar to that of a con- of correlations. However, existing transformation rules ventional sequence flow, whereas, latter aids modelers miss out these details. to optionally define default for gateways. This provision Asynchronous Tasks and Rendezvous. Models is semantically ingrained as part of XML definition of need careful transformation to preserve the asynchrony the gateways, and syntactically available as an elemental in the model, and also to ensure that new one is not introattribute in the syntaxes of BPMN gateways. Existing duced. Likewise, there are synchronization issues, such translation strategies are inaccurate in sense of handling as in joins. Moreover, while designing for asynchrony these defaults and their semantics. Figure 1(a) illustrates and synchronization, instances need to be isolated from a mapping to incorporate the semantic details for default each other, and a token from one instance should not be path from diverging exclusive gateway. visible in another instance.

Runtime Exceptions refer to unexpected events or Initialization. BPMN 2.0 [ 9 ] allows initialization to conditions that occur during the execution of a process be managed by various means such as timers, conditions, instance. BPMN defines runtime exceptions at semantic etc. Management of initialization for control flow of the levels, rather than defining them as modeling elements. process is abstracted at the semantic level, irrespective of These runtime exceptions are diferent from the event BPMN element(s) responsible for initialization. Nonetheexceptions of BPMN 2.0 toolset. For example, a runtime less, these semantic abstractions are not abstracted at exception is indicated if there is no default path defined the analysis stage, and transformation rules should incorin a gateway and none of the conditions are satisfied. porate these semantic level initialization abstractions to BPMN identifies runtime exceptions at semantic level. tokenize the PN for formal analysis and to avoid possible Other examples of semantically defined runtime excep- mismatches and semantic gaps defined in Section 2. tions are unavailability of OutputSets, non-compliance of Handling Encapsulation. Processes in BPMN are InputSet and OutputSet with the associated IORule, etc. visually encapsulated as swim-pools and swimlanes, and Existing translation strategies overlook semantics and, use variations to represent types of encapsulation, such ergo, lead to incorrect representation of a process during as black boxes for private processes. Preserving the noanalysis. Figure 1(b) illustrates an example PN that show- tion of encapsulation while defining transformations is a cases generation of runtime exception when none of the hidden challenge because, at an outset, it appears to be conditions are met in absence of default path definition ignorable. The encapsulation detail is either commonly in a gateway. overpassed or translated conveniently as a swim-pool

Faults in Invoked Services. BPMN specification [ 9 ] and swimlane in PNs too [ 10 ]. However, encapsulation defines Service task that invokes services, and mentions pertains to implementation, and traceability of encapsulathat these services may fail and return fault to the invok- tion mapping up to the implementation phase is needed. ing process. Figures 1(c) and 1(d) represent transforma- Bufer Semantics. Process-oriented languages retions of Service task such that they include a control flow quire mechanisms to manage and deal with physical and trace that defines possible faults returned by service. The informational items, their (data) structures, states, lifecycles, instantiations, associations, etc. BPMN models the definition of inclusive OR gateway [ 7 ] [ 8 ]. Moreover, utilise semantic bufering mechanisms for management the richness of notations with heavy rule based interof these items and for bringing the modeling phase closer pretations in terms of attributes, schema, operational to the implementation phase where amount of data in- semantics as part of the BPMN specification pose chalvolved is huge. Transformations need to be meticulously lenges to accuracy in transformation rules. defined in order to precisely capture these aspects.

Other Concerns. Conditions can be mapped into places. However, these condition places may not be 5. Conclusions mapped one-to-one into implementation elements, and they may get scattered. Furthermore, inaccurate transformation rules may introduce race conditions across PNs.

Transformation rules need to accurately map the control lfow of the process to ensure that neither extra racing is introduced nor required racing is eliminated.

The paper uncovers the hidden hurdles that exist as absence of preservation of semantics in existing transformation rules for BPMN elements. It also presents challenges faced by modellers during actual transformations for analysis of BPMN models. By shedding light on hidden and overlooked hurdles with an exemplar view and two classes of behavioral semantic gaps, the paper intents to ensure more accurate transformations for analysis of BPMN models in practice.

4. Transformational Challenges

This section defines the problems faced by an analyst or a modeler while transforming the visual process models from BPMN into Petri nets for purposes of analysis etc. These are high level challenges encountered by the end users during actual transformation phase.

Incompleteness. BPMN [ 9 ] consists of more than eighty five elements in its toolset [ 4 ] [ 3 ]. Currently, transformational exhaustiveness is still a need. For example, spectrum of tasks, gateways, events, activities, task markers, etc. have not been suficiently dealt with. Furthermore, these elements show diferent behaviors as their configurational attributes are varied during modeling stage of processes. These dynamic configurations yield multifold increment in the count of configurations that need to be transformed into PNs.

Inconsistency. There are several formal languages used for transformation of BPMN models. Also, translators follow diferent transformation conventions which are not standardized, which pose challenges while combining ideas from diferent transformation schemes. Moreover, multiple transformation rules are provided for same element which may result in ambiguous choices.

Inaccuracy. Modelers face obstacles while mapping the modeled process behaviors because of inaccuracies in the usage of transformation rules. For example, inaccuracies may get typically incorporated upon varying relative positions of the elements in the model.

Reusability. Transformation rules become nonreusable as the use of the BPMN element being transformed changes. This is caused due to incompleteness in exhaustiveness of transformation rules. For example, BPMN’s event to task transformation is easily assumed as place-transition in PNs, but as the number of outgoing arcs increase, the mapping becomes inaccurate as it produces XOR relationship rather than AND relationship.

Notational Impediments. BPMN 2.0 [ 9 ] defines elements, but the definitions contain ambiguities such as in

References

[1] H. Leopold , J. Mendling , O. Günther , Learning from quality issues of bpmn models from industry , IEEE Software 33 ( 2016 ) 26 - 33 .

[2] K. Shivhare , R. K. Joshi , Process line diagrams (plds): An approach for modular process modeling , in: Proc. of the 16th Innovations in Software Engineering Conference , ACM, 2023 .

[3] I. Compagnucci , F. Corradini , F. Fornari , B. Re, Trends on the usage of BPMN 2.0 from publicly available repositories , LNBIP , Springer, 2021 .

[4] M. z. Muehlen , J. Recker , How much language is enough? theoretical and practical use of the business process modeling notation , in: Advanced Information Systems Engineering , Springer, 2008 .

[5] S. Anna , Towards a taxonomy of business process and its anomalies , Int. Journal of Computer Science and Network Security 21 ( 2021 ) 230 - 240 .

[6] A. Suchenia , T. Potempa , A. Ligęza , K. Jobczyk , K. Kluza , Selected Approaches Towards Taxonomy of Business Process Anomalies , Springer International Publishing, 2017 .

[7] F. Corradini , C. Muzi , B. Re , L. Rossi , F. Tiezzi , Global vs . Local Semantics of BPMN 2.0 OR-Join , 2018 , pp. 321 - 336 .

[8] F. Corradini , C. Muzi , B. Re , L. Rossi , F. Tiezzi , Bpmn 2.0 or-join semantics: Global and local characterisation , Information Systems 105 ( 2022 ).

[9] O. M. Group , Business process model and notation (bpmn) ( 2014 ).

[10] A. G. Lazaropoulos , Business education and training during the enterprises' digital transformation: Notation alignment and equivalence rules among the enterprises' business process models , Regional Economic Development Research ( 2021 ) 51 - 70 .