Semantic Preserving, Notational and Transformational Challenges in Transfiguring BPMN models into Petri Nets Karnika Shivhare1 , Rushikesh K. Joshi1 1 Department of Computer Science and Engineering, Indian Institute of Technology Bombay, Mumbai - 400 076, India. 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 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 difference 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 different process behavior is analysed instead dressed for precise transformation of BPMN models. of the modeled process behavior. This difference refers to Visualised and Analysed behavior gap between the two models. In order to precisely transform the behavior 2. Behavioral Semantic Gaps of visual models into formal models, and ensure that Semantic gaps are the discrepancies or inconsistencies the correct model is being analyzed, the need is to have in the meaning or interpretations. They are presented accuracy in transformation rules. in the context of process modeling in [1] [2]. We define 3. Semantic Preservation Pitfalls International Workshop on Petri Nets and Software Engineering 2023, PNSE’23 BPMN is a standard specification for high-level visual $ karnika@cse.iitb.ac.in (Karnika); rkj@cse.iitb.ac.in modeling notation, and offers a variety of semantically (Rushikesh K.) € https://www.cse.iitb.ac.in/~karnika/ (Karnika); diverse options in terms of syntax. Existing transforma- https://www.cse.iitb.ac.in/~rkj/ (Rushikesh K.) tional rules translate the syntactic definitions of high  0000-0001-6490-0380 (Karnika); 0000-0002-2712-1406 level models but miss out the semantic translations be- (Rushikesh K.) cause the semantics remain abstracted in the visual mod- © 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). els as part of language schemas etc. CEUR Workshop Proceedings (CEUR-WS.org) Figure 1: Transformations to preserve semantics of (a) Default Flow for Diverging Exclusive Gateway, (b) Control Flow Behavior Including Runtime Exception in a Gateway, (c) and (d) Faults in Invoked Services by Service Task Handling the Defaults. BPMN 2.0 [9] provisions two transformations differ 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 in- However, 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 intro- attribute 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 different from the event BPMN element(s) responsible for initialization. Nonethe- exceptions 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 incor- in 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 no- analysis. 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 encapsula- that 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- Buffer Semantics. Process-oriented languages re- tions 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, life- cycles, instantiations, associations, etc. BPMN models the definition of inclusive OR gateway [7] [8]. Moreover, utilise semantic buffering mechanisms for management the richness of notations with heavy rule based inter- of 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 chal- volved 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 The paper uncovers the hidden hurdles that exist as ab- they may get scattered. Furthermore, inaccurate transfor- sence of preservation of semantics in existing transfor- mation rules may introduce race conditions across PNs. mation rules for BPMN elements. It also presents chal- Transformation rules need to accurately map the control lenges faced by modellers during actual transformations flow of the process to ensure that neither extra racing is for analysis of BPMN models. By shedding light on hid- introduced nor required racing is eliminated. den and overlooked hurdles with an exemplar view and two classes of behavioral semantic gaps, the paper intents 4. Transformational Challenges to ensure more accurate transformations for analysis of BPMN models in practice. 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. References These are high level challenges encountered by the end [1] H. Leopold, J. Mendling, O. Günther, Learning from users during actual transformation phase. quality issues of bpmn models from industry, IEEE Incompleteness. BPMN [9] consists of more than Software 33 (2016) 26–33. eighty five elements in its toolset [4] [3]. Currently, trans- [2] K. Shivhare, R. K. Joshi, Process line diagrams (plds): formational exhaustiveness is still a need. For example, An approach for modular process modeling, in: spectrum of tasks, gateways, events, activities, task mark- Proc. of the 16th Innovations in Software Engineer- ers, etc. have not been sufficiently dealt with. Further- ing Conference, ACM, 2023. more, these elements show different behaviors as their [3] I. Compagnucci, F. Corradini, F. Fornari, B. Re, configurational attributes are varied during modeling Trends on the usage of BPMN 2.0 from publicly stage of processes. These dynamic configurations yield available repositories, LNBIP, Springer, 2021. multifold increment in the count of configurations that [4] M. z. Muehlen, J. Recker, How much language is need to be transformed into PNs. enough? theoretical and practical use of the busi- Inconsistency. There are several formal languages ness process modeling notation, in: Advanced In- used for transformation of BPMN models. Also, transla- formation Systems Engineering, Springer, 2008. tors follow different transformation conventions which [5] S. Anna, Towards a taxonomy of business process are not standardized, which pose challenges while com- and its anomalies, Int. Journal of Computer Science bining ideas from different transformation schemes. and Network Security 21 (2021) 230–240. Moreover, multiple transformation rules are provided for [6] A. Suchenia, T. Potempa, A. Ligęza, K. Jobczyk, same element which may result in ambiguous choices. K. Kluza, Selected Approaches Towards Taxonomy Inaccuracy. Modelers face obstacles while mapping of Business Process Anomalies, Springer Interna- the modeled process behaviors because of inaccuracies tional Publishing, 2017. in the usage of transformation rules. For example, inac- [7] F. Corradini, C. Muzi, B. Re, L. Rossi, F. Tiezzi, curacies may get typically incorporated upon varying Global vs. Local Semantics of BPMN 2.0 OR-Join, relative positions of the elements in the model. 2018, pp. 321–336. Reusability. Transformation rules become non- [8] F. Corradini, C. Muzi, B. Re, L. Rossi, F. Tiezzi, Bpmn reusable as the use of the BPMN element being trans- 2.0 or-join semantics: Global and local characteri- formed changes. This is caused due to incompleteness sation, Information Systems 105 (2022). in exhaustiveness of transformation rules. For example, [9] O. M. Group, Business process model and notation BPMN’s event to task transformation is easily assumed (bpmn) (2014). as place-transition in PNs, but as the number of outgo- [10] A. G. Lazaropoulos, Business education and train- ing arcs increase, the mapping becomes inaccurate as it ing during the enterprises’ digital transformation: produces XOR relationship rather than AND relationship. Notation alignment and equivalence rules among Notational Impediments. BPMN 2.0 [9] defines ele- the enterprises’ business process models, Regional ments, but the definitions contain ambiguities such as in Economic Development Research (2021) 51–70.