<figure><img src="image_1.png" /></figure>

HAL
open science

# A novel approach to process discovery with enhanced loop handling (extended version)

Ali Nour Eldin, Benjamin Dalmas, Walid Gaaloul

► To cite this version:

Ali Nour Eldin, Benjamin Dalmas, Walid Gaaloul. A novel approach to process discovery with enhanced loop handling (extended version). 2026. hal-05480181

HAL Id: hal-05480181

https://hal.science/hal-05480181v1

Preprint submitted on 27 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# A Novel Approach to Process Discovery with Enhanced Loop Handling
(Extended version)

Ali Nour Eldin¹,², Benjamin Dalmas², and Walid Gaaloul¹

¹ Telecom SudParis, Institut Polytechnique de Paris, France

`{firstname.last_name}@telecom-sudparis.eu`

² Bonitasoft, France

`{firstname.last-name}@bonitasoft.com`

**Abstract.** Automated process discovery from event logs is a key component of process mining, allowing companies to acquire meaningful insights into their business processes. Despite significant research, present methods struggle to balance important quality dimensions: fitness, precision, generalization, and complexity, but is limited when dealing with complex loop structures. This paper introduces Bonita Miner, a novel approach to process model discovery that generates behaviorally accurate Business Process Model and Notation (BPMN) diagrams. Bonita Miner incorporates an advanced filtering mechanism for Directly Follows Graphs (DFGs) alongside innovative algorithms designed to capture concurrency, splits, and loops, effectively addressing limitations of balancing as much as possible these four metrics, either there exists a loop, which challenge in existing works. Our approach produces models that are simpler and more reflective of the behavior of real-world processes, including complex loop dynamics. Empirical evaluations using real-world event logs demonstrate that Bonita Miner outperforms existing methods in fitness, precision, and generalization, while maintaining low model complexity.

**Keywords:** Process Mining · Automated Process Discovery · Event Log · BPMN · Loop Handling · Concurrency.

## 1 Introduction

Process discovery [4] is one of the most prominent process mining techniques. It enables the automatic discovery of a process model that captures and explains the behavior recorded in event logs. The process model is typically represented in Petri nets [15], but other formats are also possible (e.g., in the standard Business Process Model and Notation - BPMN [9]). A discovered process model must accurately reflect the behavior observed in or inferred from the event log. Specifically, the process model should (i) parse the traces contained within the log, (ii) parse traces not present in the log but likely to belong to the process that generated the log, and (iii) refrain from parsing traces unrelated to the process. These properties are known as fitness, generalization, and precision, respectively.
Furthermore, the model should be as simple as possible, a characteristic often quantified through complexity measures [8].

Despite extensive research [4,16], achieving a balance across the four key quality dimensions — fitness, precision, generalization, and complexity — remains a challenge. When applied to real-life event logs, most automated process discovery techniques, such as the Heuristics Miner [17] and its derivatives, often produce large, spaghetti-like models that are behaviorally incorrect (e.g., prone to deadlocks). Another state-of-the-art technique, the Inductive Miner [12], tends to generate block-structured models that are behaviorally sound with high fitness but exhibit low precision. Additionally, the SplitMiner approach [5] is capable of producing accurate and simple process models; however, these models become complex and unsound in the presence of loops, complicating the observed behavior in the event log and reducing the accuracy and structure of the results.

We provide a basic example to illustrate a limitation addressed by existing methods, shown in Figure 1. Consider an event log for the BPMN model represented in Figure 1b, where there exists a loop that includes the parallel blocks *b* and *c*. Current state-of-the-art algorithms are unable to accurately discover this BPMN pattern with a loop over parallel blocks. Instead, they produce a model like the one shown in Figure 1a, where these algorithms incorrectly represent *b* and *c* with individual self-loops. This misrepresentation significantly impacts the model's accuracy, reducing its usability for real-world process analysis.

<figure><img src="image_3.png" /><figcaption>Fig. 1: A simple example of the limitation of existing works.</figcaption></figure>

To address this limitation and bridge the identified gap, this paper introduce Bonita Miner, a novel process discovery method to generate simpler process models while still achieving a balance among fitness, precision, and generalization. The approach leverages a novel Depth-First Algorithm (DFA) for constructing splits and joins, coupled with advanced filtering of the directly-follows graph (DFG) derived from event logs. These constructs effectively capture concurrency, choices, causal relationships, and even loops within the DFG. The DFA reduces model complexity while maintaining a balance among evaluation metrics, making the method suitable for processes of varying complexity, including those with loops. We also treat the loops as blocks (with one or multiple sources and one or multiple targets).
We empirically demonstrate that Bonita Miner surpasses three state-of-the-art baselines by evaluating its performance on BPIC real-life and synthetic loops event logs using eight comprehensive metrics that measure the four key quality dimensions, even in the presence of complex loop structures.

The remainder of the paper is structured as follows. Section 2 reviews the existing process discovery methods. Section 3 introduces the Bonita Miner method, followed by Sections 4 and 5, which detail the proposed approach. Section 6 discusses the empirical evaluation of Bonita Miner, and finally, Section 7 concludes the paper and outlines potential directions for future research.

## 2 Related work

The section provides an overview of existing automated process discovery methods and discusses their limitations.

The $\alpha$-algorithm [2] is a simple automated process discovery method based on the concept of DFG. While appealing due to its simplicity, the $\alpha$-algorithm is not applicable to real-life event logs since it assumes the log to be complete and is too sensitive to infrequent behavior. The Heuristics Miner [18] addresses these limitations and consistently performs better in terms of accuracy on incomplete and noisy logs. To handle noise, the Heuristics Miner relies on a relative frequency metric between pairs of event labels. However, while this technique demonstrates higher fitness, it faces the challenge of lower precision.

Structured process models are generally more understandable than unstructured ones [10,11]. Moreover, structured models are sound, provided that the gateways at the entry and exit of each block match. Given these advantages, several algorithms have been designed to discover structured process models, represented for example as process trees. The Inductive Miner [13] uses a divide-and-conquer approach to discover process structured models, achieving high fitness. However, it tends to over-generalize the behavior observed in the log whenever the process model to be discovered is unstructured, generating undesired flower models[?].

The Structured Miner [3] addresses this limitation by relaxing the requirement of always producing a structured process model, in favor of achieving higher accuracy. Split Miner [5] is another method that addresses the balance between fitness, precision, and generalization. It focuses on filtering directly-follows graphs and discovering split gateways to produce simple, accurate, and deadlock-free process models. However, Split Miner is limited in handling loops effectively, which can lead to challenges in processes with loop-intensive behavior.

To reduce these challenges, an improved approach is proposed, which enhances the handling of loops while maintaining a balance across other quality dimensions. This approach ensures better adaptability to loop-intensive scenarios, thereby improving model quality and applicability.
# 3 Approach Overview

As mentioned in the introduction, the goal of the algorithm introduced in this paper is to ensure the balancing of key metrics even in the presence of loops. For example, it successfully identifies the pattern represented in the BPMN model of Figure 1b, achieving a model accuracy of 1. The proposed approach decomposes the process discovery task in two main steps, as shown in Figure 2.

**Graph filtering and analysis:** taking an event log as input, this step first transforms it into a graph. Then, by analyzing both the graph and the event log, concurrent activities, choices, and part of the loops are removed from the graph. The benefits of processing these behaviors separately from the graph is twofold: it enables (i) handling complex loops (e.g., from one or multiple sources to one or multiple targets) and (ii) generating the BPMN model with a single-shot approach, with existing methods that require multiple iterations over the process model to achieve correct semantics, particularly for handling complex behaviors such as nested splits and joins.

<figure><img src="image_4.png" /><figcaption>Fig. 2: Bonita Miner Overview</figcaption></figure>

**Model Generation:** after filtering the graph to remove loops and concurrency, the next step involves ordering all paths in the graph using a depth-first algorithm. This approach ensures that joins are introduced alongside splits, constructing blocks of split/join gateways without enforcing strict block-structuredness. The resulting model is a BPMN diagram<fnref n="3" />, where elements, including gateways (and nested gateways), are iteratively added based on insights from the earlier analysis. This step enables the construction of the BPMN diagram without loops in a single iteration, eliminating the need for post-processing or replacing gateways to achieve correct model semantics. Loops are constructed separately, employing a strategy that reduces complexity while maintaining a balance in quality metrics. This approach contrasts with existing methods, which typically handle loops alongside other tasks, resulting in increased complexity.

<footnote n="3">³ This approach is not limited to BPMN; the same steps can also be applied to generate a Petri net.</footnote>
These steps enable the construction of a simplified model with low complex-
ity, while achieving a high balance of fitness, precision, and generalization.

4 Preliminary

In this section, we give some definitions related to event logs and process models
that will be used in the subsequent sections.

A process model is a set of connected entities that formally represent process
behavior. Since we use BPMN as the modeling language, entities can include
flow objects (activities, events, and gateways), swimlanes (pools and lanes), ar-
tifacts (e.g., data objects, text annotations, or groups), and connecting objects
(sequence flows, message flows, and associations). In this work, we limit the
scope to entities shared among different languages, specifically flow objects rep-
resented by *activities*, *start/end events*, and *gateways* (including parallel and
exclusive gateways), and connecting objects represented by *sequence flows*.

**Definition 1 (Event Log).** Given a set of events $\mathcal{E}$, an event log $\mathcal{L}$ is a multiset of traces as $\mathcal{T}$, where a trace $t \in \mathcal{T}$ is a sequence of events $t = \langle e_1, e_2, \dots, e_n \rangle$, with $e_i \in \mathcal{E}$, $1 \le i \le n$. Additionally, each event has a label $l \in \mathcal{L}$ and it refers to a task/activity executed within a process, we retrieve the label of an event with the function $\lambda : \mathcal{E} \to \mathcal{L}$, using the notation $\lambda(e) = e^l$.

For the remaining, we assume all the traces of an event log have the same start
event and the same end event. This is guaranteed by a simple preprocessing of
the event log, to be compliant with the third of the 7PMG in [14], i.e., “use one
start event for each trigger and one end event for each outcome”.

Given the set of labels $\mathcal{L} = \{s, a, b, c, d, e, f, h, i, j, k, l, end\}$, a possible log is:
$$
\mathcal{L} = \{ \langle s, a, b, end \rangle^{10}, \langle s, a, c, e, f, h, d, i, j, k, l, end \rangle^{10}, \langle s, a, c, e, f, h, d, j, i, k, l, end \rangle^{10}, \dots \}
$$
this log contains more than 10 distinct traces, each of them recorded 10 times.

Starting from a log, we construct a DFG in which each arc is annotated with
a frequency, based on the following definitions.

**Definition 2 (Directly-Follows Graph).** *Given an event log* $\mathcal{L}$, *its directly*
*follows graph is defined as a directed graph DFG = (V, E)*, *where:*

- $V$ represents a finite set of vertices, each corresponding to an activity or start/end event, and having a unique label $l \in \mathcal{L}$.

- $E \subseteq V \times V$ represents a set of directed edges, where each edge $(u, v) \in E$ signifies that $v$ can be executed right after the completion of $u$, theoretically $\forall(\lambda(a) = u \text{ and } \lambda(b) = v), \exists t = \langle e_1, e_2, \dots, e_n \rangle \in \mathcal{T} \text{ where } a = e_i \text{ and } b = e_{i+1}.$

- $v_s \in V$ is the starting vertex, iff $\nexists (v, v_s) \in E$.

- $v_e \in V$ is an ending vertex, iff $\nexists (v_e, v) \in E$.

- For $e = (u, v) \in E$, we use the notations $e.source = u$ and $e.target = v$.
- For $v \in V$, the direct successors of $v$ is $\text{Succ}_{\text{DFG}}(v) = \{u \in V \mid (v, u) \in E\}$ and the direct predecessors of $v$ is $\text{Pred}_{\text{DFG}}(v) = \{u \in V \mid (u, v) \in S\}$. When it is clear from context, the subscript DFG is omitted.

- For $(u, v) \in E$, we denote $\|u \to v\| = \sum |(u, v)|$ that represent the frequency of the edge from $u$ to $v$, where $\forall (\lambda(a) = u \text{ and } \lambda(b) = v), \exists t = \langle e_1, e_2, \dots, e_n \rangle \in \mathcal{T}$ where $a = e_i$ and $b = e_{i+1}$.

- For $(u, v) \in E$, we denote by short loop $u \circled v$ where $\exists (\lambda(a) = u \text{ and } \lambda(b) = v), \exists t = \langle e_1, e_2, \dots, a, b, \dots, b, a, \dots, e_n \rangle \in \mathcal{T}$.

Let $\text{DFG} = (V, E)$ be a DFG. We define paths, cycles and branching relations are as follows:

**Definition 3 (Path).** A path from $u \in V$ to $v \in V$, denoted as $P_{u,v} = \langle (v_1, v_2), \dots, (v_{n-1}, v_n) \rangle$, is the sequence of unique edges leading from $u$ to $v$ where $\forall 1 \le i, j \le n-1, i \ne j, n \ge 2$, $(v_i, v_{i+1}) \in E$, $v_1 = u, v_n = v$, and $\nexists (v_i, v_{i+1}) = (v_j, v_{j+1})$. We denote by:

- $P_{u,v}^v = \{v_1, \dots, v_n\}$: the set of the path vertices.

- $P_{u,v}^s = (v_1, v_2)$: the first edge of the path.

- $P_{u,v}^e = (v_{n-1}, v_n)$: the last edge of the path.

- $P_{u,v}$: the possibly empty set of all paths from $u$ to $v$.

**Definition 4 (Cycle).** A cycle $C_u$ is a path $P_{u,u} = \langle (u, v_1), \dots, (v_n, u) \rangle$ that starts and ends with $u$ such that $\forall 1 \le i \le n, v_i \ne u$. We denote by $C_u$ the possibly empty set of all cycles of $u$.

**Definition 5 (BPMN Process Model).** A BPMN process model is defined as $M = (N, G, S)$, where:

- $N = V$ is the set of vertices in DFG.

- $G$ is a finite set of gateways. A gateway $g \in G$ can be parallel, represented by $+$ or exclusive represented by $\times$. We denote by $\text{type}(g) \in \{\times, +\}$ the function that returns the type of $g$.

- $S \subseteq (N \times G) \cup (G \times N)$ is a set of directed sequence flows. For each $s = (u, v) \in S$, we use the notations $s.source = u$, and $s.target = v$.

- For $u \in N \cup G$, the direct successors of $u$ is $\text{Succ}_M(u) = \{v \in N \cup G \mid (u, v) \in S\}$ and the direct predecessors is $\text{Pred}_M(u) = \{v \in N \cup G \mid (v, u) \in S\}$. When it is clear from context, subscript $M$ is omitted.

- For $u \in N \cup G$, the transitive successors of $u$ is $\text{TSucc}(u) = \{v \in N \mid \exists g_1, \dots, g_k \in G, (u, g_1), (g_k, v), (g_i, g_{i+1}) \in S\}$ and the transitive predecessors of $u$ is $\text{TPred}(u) = \{v \in N \mid \exists g_1, \dots, g_k \in G, (v, g_1), (g_k, u), (g_i, g_{i+1}) \in S\}$. For $u \in N$, $\text{TSucc}(u) = \text{Succ}_G(u)$ and $\text{TPred}(u) = \text{Pred}_G(u)$.

# 5 Bonita Miner

In this section, we illustrate the details of our approach. We begin by running the example in Section 5.1, followed by filtering the concurrent activities in Section 5.2. Next, we identify the loops in Section 5.3. We then delve deeper into
identifying the activities that represent transitivity after the gateways, including
the identification of loop blocks in Section 5.4. This is followed by the construc-
tion of split and join patterns in the model in Section 5.5, and finally, the loop
construction in the BPMN in Section 5.6.

**5.1 Running Example**

Figure 3 represents a BPMN process model. After activity (a), there are nested gateways: an XOR gateway connected to activity (b) and an AND gateway that connects to two activities, (c) and (d). Additionally, there are two nested join gateways before activity (h). Moreover, there is a loop on a parallel block encompassing activities (e) and (f). Since these patterns are present in the example, this model serves as a running example to illustrate the steps of the algorithm.

<figure><img src="image_5.png" /><figcaption>Fig. 3: The running example is used to explain the Bonita Miner workflow</figcaption></figure>

**5.2 Concurrency discovery**

Identifying concurrency and filtering it effectively is crucial for simplifying the
DFG. With a simplified DFG, we can extract branching relations and the de-
pendent relations between activities. Additionally, concurrency discovery helps
construct AND gateways (including both simple and nested gateways) during
one-step generation. An event log is the input of our algorithm, and it can be
converted into a DFG (Definition 5), as illustrated in Figure 4. To enhance the
readability of the DFG, we add two arrows on each relation to represent the
existence of two connections between a pair of activities. For example, $c \leftrightarrow d$
indicates that there exists a relation $c \to d$ as well as a relation $d \to c$. For
the sake of clarity, we represent only a subset of these relations (we remove the
parallelism that arises from the activities (e), (f), (h), (i), (j), and (k)). All the
red relations in the DFG represent parallelism. The first step is to detect all
concurrent relations, formally defined in Definition 6.
<figure><img src="image_6.png" /><figcaption>Fig. 4: Part of the DFG of the event log of the running example</figcaption></figure>

**Definition 6 (Concurrent Relation).** Let an event log $\mathcal{L}$, a set of traces $\mathcal{T}$, and a directed graph DFG = (V, E) be given. We postulate that a and b are concurrent if and only if the following two conditions hold:

1. $\exists e, e' \in E$ such that $a, b \in V$ and $(a, b) = e$ and $(b, a) = e'$

2. $\exists t \in \mathcal{T}$ such that $\exists a, b \in t$

After identifying all concurrent relations, we remove them except for those representing short loops, as we are focusing on parallelism in this step. This step is very important for filtering the graph and subsequently identifying the gateway type in the next step. In the following definitions and sections, we use the term DFG to refer to a filtered graph that excludes concurrency relations (see Figure 5).

Branching parallel relations are those derived from concurrency relations that share the same predecessor. This characteristic helps in detecting parallel split gateways (AND gateways), particularly by identifying the activities that will transitively follow a gateway. For example, {$c, d$} in the filtered DFG shares the same predecessor (a); hence, it is added to the set of branching parallel relations. However, other relations, such as {$c, e$}, are not included because they do not have the same predecessor. As a result, the branching parallel relations are: {$c, d$}, {$i, j$}, {$e, f$}.

Formally, the branching parallel relations is defined as follow:

**Definition 7 (Branching Parallel Relations).** Let DFG' = (V', E') be the filtered DFG, where concurrency relations have been removed except for short loops. The set of branching parallel relations is denoted as:

$$BP = \{\{a, b\} \mid a, b \text{ are concurrent and } \text{Pred}_{\text{DFG}'}(a) = \text{Pred}_{\text{DFG}'}(b)\}.$$

## 5.3 Loop filtering

Although loops contribute to increased complexity and reduced readability in a process model, we treat loops in our approach as blocks, which may have one or
multiple sources and one or multiple targets. This treatment and construction of loops as blocks help to reduce complexity significantly. This step involves removing the loops from the DFG by detecting and filtering the dependency relations in E that break the cycles which results in an acyclic DFG. For example, given the DFG in Figure 5, there are four cycles $C_{e1} = \langle (e, e) \rangle$, $C_{e2} = \langle (e, f), (f, e) \rangle$, $C_{f1} = \langle (f, f) \rangle$ and $C_{f2} = \langle (f, e), (e, f) \rangle$.

<figure><img src="image_7.png" /><figcaption>Fig. 5: DFG, after filtering the parallelism, of the running example with cycles</figcaption></figure>

Breaking cycles involves removing specific edges, known as *looping edges*, which are the last edges in the paths that create the looping behavior. For example, given the cycle $C_{e2} = \langle (e, f), (f, e) \rangle$, the edge $(f, e)$ creates the loop. It is characterized by the property that, following the path from the graph's start to the edge's source vertex, no other vertices in the cycle are revisited before reaching this edge. In this example, the looping edges are $(e, e)$, $(f, e)$, $(f, f)$, and $(e, f)$. Thus, all the looping edges are removed to break the loops.

The DFG in Figure 6 provides another example. The cycles in this example are $C_a^1 = \langle (a, b), (b, c), (c, a) \rangle$, $C_c^1 = \langle (c, a), (a, b), (b, c) \rangle$, and $C_b^1 = \langle (b, c), (c, a), (a, b) \rangle$. To break the loop, following the path from the graph's start to the edge's source vertex of the cycles, the looping edge is characterized by the property that no other vertices in the cycle are revisited before reaching this edge. Applying the path condition in Definition 8, only $C_a^1$ is valid. Therefore, $L = \{(c, a)\}$.

<figure><img src="image_8.png" /><figcaption>Fig. 6: An example of a long loop.</figcaption></figure>

These are formalized in Definition 8 as follows:

**Definition 8 (Looping edge).** Let $C_u$ be a cycle of $u \in V$. The looping edge $e^{loop}$ is an edge $e \in C_u^E$ such that $P_{v_s, C_u^S \cdot source}^V \cap (C_u^V \setminus \{C_u^S \cdot source\}) = \emptyset$.
After filtering all the looping edges, an acyclic DFG, denoted as $DFG_A$, is obtained and used in the next step to discover the split and join gateways. The result after extract looping edge is the removal of the red edges from the Graph in the Figures 5 and 6.

## 5.4 Synthesis of Control Flow Elements

In the following subsections, we illustrate the analysis of choices, concurrency, and loops to develop a specific format that aids in the construction phase of the BPMN. This format is designed to detect gateway types, especially in the presence of nested gateways, and to preprocess loops by constructing blocks before adding them to the BPMN.

**Exclusive & Concurrency Relations Analysis** In this step, we extract all the choices between the activities, where the choices can be represented as branching without the existence of parallelism (Definition 7). For example, in Figure 4, after (a), there are three activities: (b), (c), and (d). Since (c) and (d) are in parallel, we can deduce that (b) and (c), as well as (b) and (d), are in choice due to the transitivity of an XOR gateway. These are formalized in Definition 9 as follows:

**Definition 9 (Branching Exclusive Relations).** Let BP be the set of Branching Parallel relation. The $BE_u$ is a set of exclusive branching after $u \in V$, where $\forall\{a, b\} \in BE_u, \exists(u, a) \in E$ and $(u, b) \in E$ where $a \neq b$ and $\{a, b\} \notin BP$.

We denote $BE = \bigcup_{v \in V} BE_v$ to represent all the branching choice in the $DFG_A$.

After extracting the branching exclusive relations, we analyze these relations to explore transitivity after a gateway between the activities and merge certain branching relations. This helps our algorithm detect the nesting gateways in our main algorithms. The following Algorithm 1 represents the process of merging these relations. Before starting, we arrange the subsets of $BE$ into a list based on the most frequent vertices in the subsets. This step is crucial to account for all possible relations, especially in cases involving multiple nested gateways (e.g., an XOR gateway followed by an AND gateway, which is then followed by another XOR gateway). Starting with the most frequent vertices ensures that all gateways are detected effectively.

For example, from the $DFG_A$ in Figure 5, $BE = \{{\{b, c\}, \{b, d\}\}}$. Since $b$ is the command vertex (line 6) and all the vertices $b, c$, and $d$ share the same successor $a$ (line 7), the result is $\# = \{{\{b, c, d\}}\}$. We denote $\#(v_1, v_2)$ is the smaller subset that contains $v_1 \in V$ and $v_2 \in V$.

Similar to the Merge Exclusive (Algorithm 1), the Merge Parallel is based on the Branching Parallel Relations (Definition 7). The same algorithm is then applied to merge the parallel relations, and we denote the result by $||$. After applying the algorithm, $|| = \{{\{c, d\}, \{i, j\}, \{e, f\}}\}$. We denote $||(v_1, v_2)$ is the smaller subset that contains $v_1 \in V$ and $v_2 \in V$, and $||(v)$ to represent all the subset that contain $v$.
<caption>**Algorithm 1** Merge Exclusive</caption>

1: **Input:** Acyclic DFG $DFG_A$, Branching Exclusive Relation $BE$
2: **Output:** Merged Exclusive denoted by #
3: create a empty set #
4: **for all** $b \in BE$ **do**
5: &nbsp;&nbsp;&nbsp;&nbsp;**for all** $b' \in BE \setminus \{b_1\}$ **do**
6: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**if** $b \cap b' \neq \emptyset$ **then**
7: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**if** $Succ(b.source) \cap Succ(b.target) \cap Succ(b'.source) \cap Succ(b'.target) \neq \emptyset$ **then**
8: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\# $\leftarrow \# \cup \{\{b.source, b.target, b'.source, b'.target\}\}$
9: &nbsp;&nbsp;&nbsp;&nbsp;**BE** $\leftarrow$ **BE** $\setminus \{b\}$

**Loop Structures Analysis** After extracting loops (as described in Definition 8), we preprocess the loops to form blocks of loops, which helps reduce unnecessary gateways and relations used to represent the loops. To achieve this, two merge algorithms are applied to combine the loops based on their sources and targets. These algorithms assist in identifying the start and end points of the block where the loop should be constructed.

The "Merge Loop by sources" algorithm 2 is designed to merge loops based on an acyclic dependency graph based on their structure and relationships, and based on the looping edge defined in 8. This merge groups loops that share the same source and whose targets have common successors (line 7-9). In the example, the looping edge $L = \{(f, f), (e, e), (f, e), (e, f)\}$, and the result from this algorithm is $ML_s = \{(f, \{f, e\}), (e, \{e, f\})\}$, which is the input of the second algorithm 3.

<caption>**Algorithm 2** Merge Loop by sources</caption>

1: **Input:** Acyclic DFG $DFG_A$, looping edge $L$
2: **Output:** Merged loops $ML_s$
3: create a list $ML_s$
4: **for all** $l \in L$ **do**
5: &nbsp;&nbsp;&nbsp;&nbsp;create a set $targets \leftarrow \{l.target\}$
6: &nbsp;&nbsp;&nbsp;&nbsp;**for all** $l' \in L \setminus \{l\}$ **do**
7: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**if** $l.source == l'.source \land Succ_{DFG_A}(l.target) == Succ_{DFG_A}(l'.target)$ **then**
8: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;targets $\leftarrow$ targets $\cup \{l'.target\}$
9: &nbsp;&nbsp;&nbsp;&nbsp;**L** $\leftarrow$ **L** $\setminus \{l'\}$
10: &nbsp;&nbsp;&nbsp;&nbsp;**ML**$_s$ $\leftarrow$ **ML**$_s$ $\cup$ $(l.source, targets)$
11: &nbsp;&nbsp;&nbsp;&nbsp;**L** $\leftarrow$ **L** $\setminus \{l\}$

The "Merge Loop" by targets algorithm 3 is designed to consolidate loops that have already been grouped based on their sources. The goal is to further merge these loops by examining their targets and associated predecessors. This merge $ML$, is derived from $ML_s$ by combining sources if they have common pre-
decessors (lines 7-9). In the example, the extracted $ML_s = \{(f, \{f, e\}), (e, \{e, f\})\}$, and the result from this algorithm is $ML = \{(\{f, e\}, \{f, e\})\}$. This indicates the existence of a loop for the entire block of $\{e, f\}$.

**Algorithm 3 Merge Loop**

1: **Input:** Acyclic DFG $DFG_A$, Loop merged by sources $ML_s$
2: **Output:** Merged loops $ML$
3: create a list $ML$
4: **for all** $l \in ML$ **do**
5: create a set $sources \leftarrow \{l.source\}$
6: **for all** $l' \in ML_s \setminus \{l\}$ **do**
7: if $l.target == l'.target \land Pred_{DFG_A}(l.source) == Pred_{DFG_A}(l'.source)$
then
8: sources $\leftarrow$ sources $\cup \{l'.source\}$
9: $ML_s \leftarrow ML_s \setminus \{l'\}$
10: $ML \leftarrow ML \cup (sources, l.target)$
11: $ML_s \leftarrow ML_s \setminus \{l\}$

## 5.5 Split & Join Discovery

Accurately discovering split and join gateways while keeping the model simple is challenging. To simplify model generation, we construct blocks of split/join gateways without enforcing the block-structuredness property. Algorithm 4 outlines the high-level steps. It takes as input the acyclic DFG $DFG_A$ and the branching parallel relations $\parallel$ and returns as output a BPMN model $M$.

Initially, we traverse all paths in $DFG_A$ from start to all possible ends, ordering them with a depth-first algorithm based on the longest path. This ensures joins are introduced alongside splits, focusing on identifying the maximum number of gateways by analyzing the longest paths first. The result is a list of ordered edges derived from these paths (Line 5). In our example of Fig. 5 (excluding the red looping edges that have been filtered), the ordered depth-first traversal returns the paths ordered $[P_1, P_2, P_3, P_4, P_5]$ where $P_1 = \langle(s, a), (a, c), (c, e), (e, h), (h, k), (k, l), (l, end)\rangle$, $P_2 = \langle(s, a), (a, c), (c, f), (f, h), (h, k), (k, l), (l, end)\rangle$, $P_3 = \langle(s, a), (a, d), (d, i), (i, k), (k, l), (l, end)\rangle$, $P_4 = \langle(s, a), (a, d), (d, j), (j, k), (k, l), (l, end)\rangle$, and $P_5 = \langle(s, a), (a, b), (b, end)\rangle$. The ordered list of unique edges $E_O$ extracted from these paths, respecting their order, is $E_O = [(s, a), (a, c), \dots, (c, f), (f, h) \dots]$.

All the edges of $P_1$ are added in temporal order in the process model. Lines 9-11 add the source and target elements that are not already added to $M$. From $P_2$, the dependency $(c, f)$ should be added, where $c$ already exists and has a relation. Therefore, the split algorithm is called according to line 13 (detailed in Section 5.5, Figure 7a). This is followed by $(f, h)$, where the join algorithm is invoked as specified in line 15 (detailed in Section 5.5, Figure 8a). From path
<caption>**Algorithm 4 BPMN Construction**</caption>

1: **Input:** Acyclic DFG $DFG_A = (V, E)$, parallel vertices $\parallel$, exclusive vertices $\#$
2: **Output:** Generated BPMN Model $M = (N, G, S)$
3: Initialize $M$
4: Create a gateway reference $GR = null$
5: $E_O = \text{OrderedDF}(DFG_A)$
6: **for all** $e \in E_O$ **do**
7: &nbsp;&nbsp;&nbsp;&nbsp;source $\leftarrow e$.source
8: &nbsp;&nbsp;&nbsp;&nbsp;target $\leftarrow e$.target
9: &nbsp;&nbsp;&nbsp;&nbsp;if $\nexists s', s'' \in S \mid s'.source = source \land s''.target = target$ **then**
10: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$N \leftarrow N \cup \{\text{source, target}\}$
11: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$S \leftarrow S \cup \{(\text{source, target})\}$
12: &nbsp;&nbsp;&nbsp;&nbsp;**else if** $\exists s \in S \mid s.source = source \land target \notin N$ **then**
13: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;call AddSplitGateways(DFG_A, $M$, $\parallel$, $\#$, source, target, GR)
14: &nbsp;&nbsp;&nbsp;&nbsp;**else**
15: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;call AddJoinGateways($M$, source, target, GR)

$P_3$, for $(a, d)$, the split algorithm is called (Figure 7b). This is followed by $(d, i)$, which is added in line 13. Then, the join algorithm is called to add the relation between $(i, k)$. For $P_4$, $(d, j)$ is handled by calling the split algorithm, followed by the join algorithm for $(j, k)$ (Figure 8b). Finally, from $P_5$, $(a, b)$ is added by calling the split algorithm, and $(b, end)$ is added directly (lines 9-11).

**Split Operation** The split operation in Algorithm 5 has two parts. The first adds a simple gateway (Figure 7a). The second, a recursive operation, nests gateways (Figure 7b).

<figure><img src="image_9.png" /><figcaption>Fig. 7: Add split gateways to BPMN.</figcaption></figure>

Figure 7a illustrates the addition of a new simple gateway with the dependency relation $(c, f)$. Since $c$ is an existing source with a relation in the process model $(e)$, the split algorithm is applied. The first step involves checking the successor of $c$, which is $e$ (lines 3-7). If the successor is an activity, a split gateway is added, with $c$ as the incoming connection and $e$ and $f$ as the outgoing connections. To determine the gateway type, the relation between $e$ and $f$ is checked. This relation must exist within the smaller subset of $\#$ and $\parallel$. Based on the results, if the relation is in $\parallel$, the gateway will be $+$; otherwise, it will be
×. If the successor is a gateway, the advanced split algorithm is called to add a nested gateway (lines 9-10).

<caption>**Algorithm 5 AddSplitGateways**</caption>

1: **Input:** Acyclic DFG $DFG_A$, Process Model $M$, parallel vertices $||$, exclusive vertices #, Entity source, Entity target, gateway reference GR
2: $target_M \leftarrow s.target$ | $\exists s = (source, target_M) \in S$
3: **if** type(target_M) $\notin$ G **then**
4: &nbsp;&nbsp;&nbsp;&nbsp; $g_{new} \leftarrow$ Gateway(" + ") if $\exists \{target_M, target\} \in || \land (\#(target_M, target) = \emptyset \text{ or } |||(target_M, target)|| < ||\#(target_M, target)||)$ else Gateway(" $\times$ ")
5: &nbsp;&nbsp;&nbsp;&nbsp; $G \leftarrow G \cup \{g_{new}\}$
6: &nbsp;&nbsp;&nbsp;&nbsp; $S \leftarrow S \setminus \{(source, g_{current})\}$
7: &nbsp;&nbsp;&nbsp;&nbsp; $S \leftarrow S \cup \{(source, g_{new}), (g_{new}, target), (g_{new}, target_M)\}$
8: **else**
9: &nbsp;&nbsp;&nbsp;&nbsp; $s \leftarrow (source, target_M)$
10: **Add Nesting Split Gateway**($DFG_A, M, ||, #, GR, s, source, target$)

The advanced algorithm in Algorithm6 is utilized to add a split gateway after the source, which can result in nested gateways. The algorithm involves three main steps: (i) adding the target as a successor to the existing gateway (lines 4-6), (ii) inserting a new split gateway before the existing gateway (line 7-18), and (iii) adding a new gateway after the existing one using the nesting split algorithm (lines 20-24).

For example, in Figure 7b, the dependency relation is $(a, b)$. The recursive algorithm begins by identifying the successor of $a$, which is the gateway (1). Next, all successors with the transition (3) are searched, resulting in the extracted list $\{c, d\}$. The relationship between the target $b$ and the extracted list $\{c, d\}$ is then analyzed. Since there is no parallelism in $||$ that includes $(b, c)$ or $(b, d)$, it is concluded that $b$ is in an exclusive decision with these activities: $(b, c) \Rightarrow$ exclusive; $(b, d) \Rightarrow$ exclusive. Because this relation is exclusive and not of the same type as (3), a new gateway (7) is added before the existing gateway (lines 13-18).
**Algorithm 6 AddNestingSplitGateway**

1: **Input:** Acyclic DFG $DFG_A$, Process Model $M$, parallel vertices $\parallel$, exclusive vertices #, gateway reference $GR$, gateway type $gatewayType$, current relation $s$, Entity source $source$, Entity target $target$

2: $g_{current} \leftarrow s.target$

3: $succT_N \leftarrow SuccT_M^N(g_{current})$

4: **if** $succT_N \in |||(target) \land type(g_{current}) = “+”** **then**

5: $S \leftarrow S \cup \{(g, target)\}$

6: $GR \leftarrow g_{current}$

7: **else if** $succT_N \in |||(target) \land type(g_{current}) = “\times”$ **then**

8: $g_{new} \leftarrow Gateway(“+”)$

9: $G \leftarrow G \cup \{g_{new}\}$

10: $S \leftarrow S \setminus \{(source, g_{current})\}$

11: $S \leftarrow S \cup \{(source, g_{new}), (g_{new}, g_{current}), (g_{new}, target)\}$

12: $GR \leftarrow g_{new}$

13: **else if** $succ_N \cap |||(target) \leftarrow \emptyset$ **then**

14: $g_{new} \leftarrow Gateway(“\times”)$

15: $G \leftarrow G \cup g_{new}$

16: $S \leftarrow S \setminus \{(source, g_{current})\}$

17: $S \leftarrow S \cup \{(source, g_{new}), (g_{new}, g_{current}), (g_{new}, target)\}$

18: $GR \leftarrow g_{new}$

19: **else**

20: $succ_N \leftarrow Succ_M^N(g_{current})$

21: **for all** $v \in succ_N$ **do**

22: **if** $v \in G$ **then**

23: $s \leftarrow (g_{current}, v)$

24: AddNestingSplitGateway(DFG_A, M, $\parallel$, #, $GR$, $s$, $source$, $target$)

**Join Operation** Similar to the split operation, the join operation presented in Algorithm 7 consists of two main parts: adding a simple join gateway and adding a nested join gateway.

**Algorithm 7 AddJoinGateways**

1: **Input:** Process Model $M$, gateway reference $GR$, Entity source, Entity target

2: $source_M \leftarrow s.source | \exists s = (source_M, target) \in S$

3: **if** $type(source_M) \notin G$ **then**

4: $g_{new} \leftarrow Gateway(type(GR))$

5: $G \leftarrow G \cup \{g_{new}\}$

6: $S \leftarrow S \setminus \{(source, g_{current})\}$

7: $S \leftarrow S \cup \{(source, g_{new}), (source_M, g_{new}), (g_{new}, target)\}$

8: **else**

9: $s \leftarrow (source_M, target)$

10: AddNestingJoinGateway(M, GR, $s$, $source$, $target$)
Figure 8a illustrates the addition of a simple join. In this example, the dependency relation is (*f*, *h*). Since *f* is a source already added and *h* is a target already incorporated into the process model, the join algorithm is applied. The first step involves checking the predecessor of *h*, which is *e* (lines 3-7). As the predecessor is an activity, a join gateway is directly added after *h*. The incoming connections to this gateway are *e* and *f*, and the outgoing connection is *h* (lines 9-10). The type of the gateway matches the last gateway added into the BPMN.

The advanced algorithm in Algorithm 8 adds a join gateway when a gateway already exists before the target, potentially resulting in nested gateways. It involves three main steps: (i) adding the target as the predecessor of the existing gateway (lines 3-5), (ii) adding a new join gateway after the existing gateway (lines 6-31), and (iii) recalling the complex join algorithm to add a new gateway before the existing one (line 32).

In Figure 8b, the dependency relation is (*j*, *k*), with the last added split being (5). The algorithm checks for a backward path from the selected gateway (4) that intersects the split gateway (5). If all predecessors intersect the split gateway, the temporal relation between the gateways is validated. If they are of the same type, a new relation is added from the target to the selected gateway; otherwise, a new gateway is added after the selected gateway. If at least two predecessors have a relation, a new join gateway matching the split gateway’s type is added after these predecessors and before the selected gateway. Otherwise, the nesting join algorithm is applied to all predecessor gateways. In this example, (4) has *h* and *i* as predecessors, with a backward path from *i* to (5). Therefore, a new join gateway of the same type as (5) is added after *i* (lines 23-30).

<figure><img src="image_10.png" /><figcaption>Fig. 8: Add join gateways to BPMN.</figcaption></figure>
<caption>**Algorithm 8 AddNestingJoinGateway**</caption>

1: **Input:** Process Model *M*, gateway reference *GR*, Entity *source*, Entity target *pred*, Entity *target*, current relation *s*
2: *pred*<sub>*M*</sub> ← *Pred*<sub>*M*</sub>(*pred*)
3: **if** ∀*v* ∈ *pred*<sub>*M*</sub>, ∃*P*<sub>*GR*,*v*</sub> **then**
4:     **if** *type*(*pred*) == *type*(*GR*) **then**
5:         *S* ← *S* ∪ {*(*source*, *pred*)}
6:     **else**
7:         *g*<sub>*new*</sub> ← *Gateway*(*type*(*GR*)*)
8:         *G* ← *G* ∪ {**g*<sub>*new*</sub>}
9:         *S* ← *S* \ {*}
10:        *S* ← *S* ∪ {*(*source*, *g*<sub>*new*</sub>), (*pred*, *g*<sub>*new*</sub>), (*g*<sub>*new*</sub>, *s*.target*)}
11:    **else if** ∀*v* ∈ *pred*<sub>*M*</sub>, ∄*P*<sub>*GR*,*v*</sub> **then**
12:        *g*<sub>*new*</sub> ← *Gateway*(*type*(*GR*)*)
13:        *G* ← *G* ∪ {**g*<sub>*new*</sub>}
14:        *S* ← *S* \ {*}
15:        *S* ← *S* ∪ {*(*source*, *g*<sub>*new*</sub>), (*pred*, *g*<sub>*new*</sub>), (*g*<sub>*new*</sub>, *s*.target*)}
16:    **else if** ||∀*v* ∈ *pred*<sub>*M*</sub>, ∃*P*<sub>*GR*,*v*</sub> || ≥ 2 **then**
17:        *g*<sub>*new*</sub> ← *Gateway*(*type*(*GR*)*)
18:        *G* ← *G* ∪ {**g*<sub>*new*</sub>}
19:    **for all** *v* ∈ *pred*<sub>*M*</sub> **do**
20:        *S* ← *S* \ {*(*v*, *pred*)}
21:        *S* ← *S* ∪ {*(*v*, *g*<sub>*new*</sub>*)}
22:        *S* ← {*(*g*<sub>*new*</sub>, *pred*)}
23:    **else**
24:        *pred*<sub>*new*</sub> ← *Pred*<sub>*M*</sub>(*v*)|*v* ∈ *pred*<sub>*M*</sub>
25:        *s* = (*pred*<sub>*new*</sub>, *pred*) ∈ *S*
26:    **if** *type*(*pred*<sub>*new*</sub>) ∈ *G* **then**
27:        *g*<sub>*new*</sub> ← *Gateway*(*type*(*GR*)*)
28:        *G* ← *G* ∪ {**g*<sub>*new*</sub>}
29:        *S* ← *S* \ {*}
30:        *S* ← *S* ∪ {*(*source*, *g*<sub>*new*</sub>), (*pred*<sub>*new*</sub>, *g*<sub>*new*</sub>), (*g*<sub>*new*</sub>, *pred*)}
31:    **else**
32:        call *AddNestingJoinGateway*(*M*, *GR*, *source*, *pred*<sub>*new*</sub>, *target*, *s*)
33:        *GR* ← *null*

5.6 Loop Construction

We start in the loop construction by the block construction. During the gener-
ation of the BPMN, it is not possible to establish all relationships because the
loop relation is removed, resulting in some incomplete blocks. For example, after
removing the entities in red in Figure 9, the result is contracted before adding
the loop. In the loop block construction algorithm (Algorithm 9), the goal is to
complete the loop block (gateway (3)) before adding the loops as described in
algorithm 10.

Since in the example used in the paper, the blocks of e, f are completed where
the source block is gateway (1) and the target block is gateway (2) (cf. Figure
<caption>**Algorithm 9 Loop Block Construction**</caption>

1: **Input:** Acyclic DFG DFG<sub>A</sub>, Process Model M = (N, G, S), Merged loops ML, parallel vertices ||, exclusive vertices #
2: **for all** l = (sources, targets) ∈ ML **do**
3: &nbsp;&nbsp;&nbsp;&nbsp;**if** ||sources|| ≠ 1 ∧ ∃(u, v) ∈ S | (v ∈ N ∧ u ∈ sources) **then**
4: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;g<sub>split</sub> ← LCA<sub>M</sub>(sources)
5: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;G ← G ∪ {g<sub>join</sub>} | type(g<sub>join</sub>) = type(g<sub>split</sub>)
6: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S ← S ∪ {(s, g<sub>join</sub>) | s ∈ sources}
7: &nbsp;&nbsp;&nbsp;&nbsp;**if** ||targets|| ≠ 1 ∧ ∃(v, u) ∈ S | (v ∈ N ∧ u ∈ targets) **then**
8: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;N ← N ∪ {temp}
9: &nbsp;&nbsp;&nbsp;&nbsp;**for all** t ∈ targets **do**
10: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;call AddSplitGateways(DFG<sub>A</sub>, M, ||, #, temp, t, ∅)
11: &nbsp;&nbsp;&nbsp;&nbsp;N ← N \ {temp}

10), we add other example (cf. Figure 9) to well explain the algorithm, where
only one loop exists, which is ({e, f}, {b}). Since there are two sources, {e, f},
it is necessary to validate the completion of their block (line 3). If the block
is completed, no action is required; otherwise, the block should be constructed
based on the split. To accomplish this, by applying the lowest common ancestor
algorithm [6] on the process model, the split gateway can be identified as the
last ancestor e and f (line 4). Subsequently, a new join gateway should be added
with the same type of split (lines 5-6).

Next, the targets are checked to determine if they construct all the blocks.
If more than one target exists, the existence of gateways before the targets is
validated (line 7). If gateways do not exist, a temporary activity is added to
construct this block by adding connections and applying the split operation
from the temporary activity to the targets (line 8-10). Finally, this activity is
removed (line 11), and the process continues to the final algorithms to add loops
to the process model 10.

<figure><img src="image_11.png" /><figcaption>Fig. 9: Complete a loop block and add it to the BPMN model.</figcaption></figure>

The final step involves adding the loop between the source and target blocks
presented in Algorithm 10. A block is considered an activity if there is one
element for the source or target, and it is considered a gateway if there is more
than one source or target. The process iterates through all the Merged Loop
results, leading to four scenarios: (i) If both source and target blocks have a sequence flow to other entities, a new gateway is added after the source block and another before the target block. These two gateways are then connected (line 7). (ii) If the source block has a sequence flow but the target block does not, a new gateway is added after the source block, followed by a connection from the new gateway to the target block (line 9). (iii) If the target block has a sequence flow but the source block does not, a new gateway is added before the target block, followed by a connection from the source block to the gateway (line 12). (iv) If neither the source nor the target block has a sequence flow, a simple connection is created between these blocks (line 14).

<caption>**Algorithm 10 Loop Operation**</caption>

1: **Input:** Process Model *M*, merge loops *ML*
2: **for all** *l* ∈ *ML* **do**
3: &nbsp;&nbsp;&nbsp;&nbsp;sourceBlock ← ⋂ {*Succ*<sub>*M*</sub>(*s*)|*s* ∈ *l*<sub>s</sub>} if |*l*<sub>s</sub>| > 1 else *l*<sub>s</sub>
4: &nbsp;&nbsp;&nbsp;&nbsp;targetBlock ← *LCA*<sub>*M*</sub>(*l*<sub>t</sub>) if |*l*<sub>t</sub>| > 1 else *l*<sub>t</sub>
5: &nbsp;&nbsp;&nbsp;&nbsp;**if** ∃(*sourceBlock*, *s*) ∈ *S* **then**
6: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**if** ∃(*s*, *targetBlock*) ∈ *S* **then**
7: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AddTwoLoopGateways(*sourceBlock*, *targetBlock*)
8: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**else**
9: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AddLoopAfterSourceBlock(*sourceBlock*, *targetBlock*)
10: &nbsp;&nbsp;&nbsp;&nbsp;**else**
11: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**if** ∃(*s*, *targetBlock*) ∈ *S* **then**
12: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AddLoopBeforeTargetBlock(*sourceBlock*, *targetBlock*)
13: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**else**
14: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*S* ← *S* ∪ {*sourceBlock*, *targetBlock*}

In the paper example, Figure 10 represents the loop operation where the
{e, f} block is in a loop, meaning this block is both the source and the target,
with a gateway as both the source and target blocks. The source block is gateway
(2), and the target block is gateway (1). These blocks are connected; therefore,
new gateways are added, one after the source (8) and another before the target
(9), and a connection from (8) to (9) is added (line 14 in the algorithm).

<figure><img src="image_12.png" /><figcaption>Fig. 10: Add a loop to the process model.</figcaption></figure>

In other case (Figure 9), after constructing the loop block (adding the gate-
way (3)), the source block is disconnected, but *b* which is the target block is
connected to other entities. Therefore, a new × gateway (4) is added before *b*, with a connection from (3) to (4) (lines 11-12 in the algorithm).

# 6 Evaluation

We implemented Bonita Miner (hereafter BM) as a standalone Java application <fnref n="4" />. The tool takes as input an event log in XES format and produces a BPMN process model as output. Using this implementation, we conducted an empirical comparison of BM against three existing methods using a set of publicly available logs.

## 6.1 Datasets

We used a collection of real-life event logs, including logs from the annual Business Process Intelligence Challenge (BPIC), as well as other logs such as the Road Traffic Fines Management Process (RTFMP) and the SEPSIS Cases log as presented in Table 1. For the BPIC logs, we applied a filtering method to remove infrequent traces (5%) before applying each of the discovery methods. The dataset is heterogeneous in the number of traces (44 to 150,370), in the number of distinct traces (15 to 2023), in the number of event classes (11 to 55) and in the trace length (2 to 185 events).

<table><thead><tr><th rowspan="2">Model</th><th rowspan="2">Total traces</th><th rowspan="2">Distinct traces</th><th rowspan="2">Total events</th><th rowspan="2">Distinct events</th><th colspan="3">Trace length</th></tr><tr><th>Min</th><th>Avr</th><th>Max</th></tr></thead><tbody><tr><td>BPIC2012<sub>f</sub></td><td>9333</td><td>612</td><td>95348</td><td>23</td><td>3</td><td>10</td><td>55</td></tr><tr><td>BPIC2013<sub>cp<sub>f</sub></sub></td><td>1236</td><td>35</td><td>4343</td><td>4</td><td>2</td><td>3</td><td>13</td></tr><tr><td>BPIC2013<sub>inc<sub>f</sub></sub></td><td>5620</td><td>178</td><td>31740</td><td>4</td><td>2</td><td>5</td><td>18</td></tr><tr><td>BPIC2013<sub>op<sub>f</sub></sub></td><td>693</td><td>30</td><td>1569</td><td>3</td><td>1</td><td>2</td><td>9</td></tr><tr><td>BPIC2015<sub>1<sub>f</sub></sub></td><td>44</td><td>15</td><td>473</td><td>55</td><td>2</td><td>10</td><td>38</td></tr><tr><td>BPIC2015<sub>2<sub>f</sub></sub></td><td>8</td><td>4</td><td>88</td><td>15</td><td>7</td><td>11</td><td>13</td></tr><tr><td>BPIC2015<sub>3<sub>f</sub></sub></td><td>76</td><td>16</td><td>650</td><td>51</td><td>3</td><td>8</td><td>38</td></tr><tr><td>BPIC2015<sub>4<sub>f</sub></sub></td><td>7</td><td>3</td><td>73</td><td>14</td><td>4</td><td>10</td><td>13</td></tr><tr><td>BPIC2015<sub>5<sub>f</sub></sub></td><td>6</td><td>3</td><td>64</td><td>18</td><td>5</td><td>10</td><td>15</td></tr><tr><td>BPIC2017<sub>f</sub></td><td>17602</td><td>2023</td><td>501041</td><td>24</td><td>10</td><td>28</td><td>63</td></tr><tr><td>BPIC2017<sub>o<sub>f</sub></sub></td><td>40754</td><td>6</td><td>184037</td><td>7</td><td>3</td><td>4</td><td>5</td></tr><tr><td>BPIC2020<sub>DD<sub>f</sub></sub></td><td>9899</td><td>8</td><td>51479</td><td>10</td><td>1</td><td>5</td><td>9</td></tr><tr><td>BPIC2020<sub>ID<sub>f</sub></sub></td><td>5989</td><td>293</td><td>65739</td><td>32</td><td>3</td><td>10</td><td>24</td></tr><tr><td>BPIC2020<sub>PL<sub>f</sub></sub></td><td>5972</td><td>385</td><td>65575</td><td>44</td><td>3</td><td>10</td><td>30</td></tr><tr><td>BPIC2020<sub>PTC<sub>f</sub></sub></td><td>1991</td><td>94</td><td>17040</td><td>29</td><td>1</td><td>8</td><td>16</td></tr><tr><td>BPIC2020<sub>RP<sub>f</sub></sub></td><td>6521</td><td>11</td><td>34328</td><td>11</td><td>1</td><td>5</td><td>11</td></tr><tr><td>RTFMP</td><td>150370</td><td>231</td><td>561470</td><td>11</td><td>2</td><td>4</td><td>20</td></tr><tr><td>SEPSIS</td><td>1050</td><td>846</td><td>15214</td><td>16</td><td>3</td><td>14</td><td>185</td></tr></tbody></table>

<footnote n="4">⁴ Available at: https://github.com/anonymous4conferences/BonitaMiner</footnote>
**Table 1 continued from previous page**

Table 1: Statistics of the event logs employed

In addition to these logs, we generated event logs for the BPMN models containing loops, as shown in Figure 11, which are the focus of this paper. These patterns are used for different loop block, like multi source to multi target in BPMN (L1) 11a, or multi source one target in BPMN (L2) 11b, also the representation of the Block loops followed by split like in L3 11c and L4 11d.

<figure><img src="image_13.png" /><figcaption>(a) (L1): BPMN with loop block, the loop is for a block that contains nesting gateways and parallelism.</figcaption></figure>

<figure><img src="image_14.png" /><figcaption>(c) (L3): Loops block on XOR gateway followed by split gateway.</figcaption></figure>

<figure><img src="image_15.png" /><figcaption>(b) (L2): BPMN with loop block, the loop is from different sources to one target that contains nesting gateways and parallelism.</figcaption></figure>

<figure><img src="image_16.png" /><figcaption>(d) (L4): Loops block on AND gateway followed by split gateway.</figcaption></figure>

<caption>Fig. 11: Different Loops Patterns</caption>

## 6.2 Experimental Setup

We selected three state-of-the-art discovery methods as baselines: Inductive Miner (IM), Heuristics Miner (HM), and Split Miner (SM). IM and HM were implemented using the PM4PY library [7].

For the evaluation of default parameters, we assessed the quality of the produced models across various quality dimensions. These included fitness, precision, and F-score as proxies for accuracy, as well as generalization, size, control-flow complexity (CFC), and structuredness (struct.) as proxies for complexity [1], along with execution time in seconds, excluding the time required to load the event log into memory. The size metric represents the number of elements in the process model, such as nodes (tasks, events, gateways) and edges, while CFC measures the structural complexity of the control-flow, considering constructs
like splits and joins (XOR, AND). Each metric was computed on BPMN models, except for fitness, precision, and generalization, which were measured on Petri nets due to the limitations of the measuring tools, which work exclusively on Petri nets. We converted BPMN models to Petri nets using the PM4PY library and also used PM4PY to calculate fitness, precision, and generalization.

All experiments were conducted on a system equipped with an 11th Gen Intel Core i7 processor running at 2.30 GHz, paired with 16 GB of RAM.

## 6.3 Results & Discussion

The evaluation of BM revealed its superior performance across multiple dimensions. The results, summarized in Table 2, show that BM consistently outperformed baseline methods across synthetic and real-life datasets. For instance, BM achieved perfect fitness (1.00) on most synthetic logs (L1–L4), indicating its robustness in reproducing observed behaviors. In real-life logs such as BPIC 2017, BM maintained competitive fitness (0.93) and F-score (0.94), striking a commendable balance between accuracy and simplicity.

<table><thead><tr><th rowspan="2">Log name</th><th rowspan="2">Discovery Method</th><th colspan="3">Distinct traces</th><th rowspan="2">Generalization</th><th colspan="3">Complexity</th><th rowspan="2">Time(s)</th></tr><tr><th>Fitness</th><th>Precision</th><th>F-score</th><th>Size</th><th>CFC</th><th>Struct.</th></tr></thead><tbody><tr><td rowspan="4">L1</td><td>BM</td><td><b>1.00</b></td><td>0.91</td><td><b>0.95</b></td><td><b>0.97</b></td><td><b>15</b></td><td><b>6</b></td><td><b>1.00</b></td><td>0.091</td></tr><tr><td>SM</td><td>0.89</td><td>0.87</td><td>0.88</td><td>0.95</td><td>23</td><td>13</td><td>0.65</td><td><b>0.01</b></td></tr><tr><td>IM</td><td>0.78</td><td><b>1.00</b></td><td>0.88</td><td>0.88</td><td>39</td><td>30</td><td>0.103</td><td>0.19</td></tr><tr><td>HM</td><td><b>1.00</b></td><td>0.6</td><td>0.75</td><td>0.95</td><td>31</td><td>21</td><td>1.00</td><td>0.21</td></tr><tr><td rowspan="4">L2</td><td>BM</td><td><b>1.00</b></td><td>0.96</td><td><b>0.98</b></td><td><b>0.97</b></td><td><b>15</b></td><td><b>6</b></td><td><b>1.0</b></td><td><b>0.05</b></td></tr><tr><td>SM</td><td>0.81</td><td><b>1.00</b></td><td>0.90</td><td>0.95</td><td><b>15</b></td><td>7</td><td>0.80</td><td>0.09</td></tr><tr><td>IM</td><td>0.96</td><td>0.96</td><td>0.96</td><td>0.89</td><td>17</td><td>12</td><td>0.176</td><td>0.24</td></tr><tr><td>HM</td><td><b>1.00</b></td><td>0.96</td><td><b>0.98</b></td><td>0.96</td><td><b>15</b></td><td><b>6</b></td><td><b>1.0</b></td><td>0.24</td></tr><tr><td rowspan="4">L3</td><td>BM</td><td><b>1.00</b></td><td>0.99</td><td><b>0.99</b></td><td><b>0.96</b></td><td><b>12</b></td><td><b>5</b></td><td><b>1.0</b></td><td><b>0.053</b></td></tr><tr><td>SM</td><td>0.82</td><td>0.98</td><td>0.90</td><td>0.95</td><td>15</td><td>7</td><td>1.0</td><td>0.06</td></tr><tr><td>IM</td><td>0.79</td><td><b>1.00</b></td><td>0.88</td><td>0.94</td><td>21</td><td>11</td><td>0.14</td><td>0.16</td></tr><tr><td>HM</td><td><b>1.00</b></td><td>0.84</td><td>0.91</td><td>0.95</td><td>19</td><td>11</td><td>1.00</td><td>0.15</td></tr><tr><td rowspan="4">L4</td><td>BM</td><td><b>1.00</b></td><td>0.99</td><td><b>0.99</b></td><td><b>0.97</b></td><td><b>12</b></td><td><b>4</b></td><td><b>1.0</b></td><td>0.09</td></tr><tr><td>SM</td><td><b>1.00</b></td><td>0.84</td><td>0.91</td><td>0.96</td><td>15</td><td>7</td><td><b>1.0</b></td><td><b>0.06</b></td></tr><tr><td>IM</td><td>0.79</td><td><b>1.00</b></td><td>0.88</td><td>0.95</td><td>21</td><td>10</td><td>0.14</td><td>0.17</td></tr><tr><td>HM</td><td><b>1.00</b></td><td>0.84</td><td>0.91</td><td>0.96</td><td>15</td><td>7</td><td><b>1.00</b></td><td>0.16</td></tr><tr><td rowspan="4">BPIC2012<sub>f</sub></td><td>BM</td><td>0.93</td><td><b>0.82</b></td><td><b>0.87</b></td><td>0.85</td><td><b>48</b></td><td><b>34</b></td><td>0.67</td><td>4.2</td></tr><tr><td>SM</td><td>0.82</td><td><b>0.82</b></td><td>0.82</td><td>0.86</td><td>95</td><td>62</td><td>0.32</td><td><b>1.46</b></td></tr><tr><td>IM</td><td><b>1.00</b></td><td>0.28</td><td>0.44</td><td><b>0.96</b></td><td>86</td><td>58</td><td><b>1.00</b></td><td>3.69</td></tr><tr><td>HM</td><td>0.98</td><td>0.36</td><td>0.52</td><td>0.92</td><td>49</td><td>45</td><td>-</td><td>3.29</td></tr><tr><td rowspan="4">BPIC2013<sub>cpf</sub></td><td>BM</td><td>0.91</td><td>0.88</td><td>0.89</td><td>0.89</td><td><b>12</b></td><td><b>6</b></td><td><b>1.00</b></td><td>0.18</td></tr><tr><td>SM</td><td>0.85</td><td><b>0.94</b></td><td>0.90</td><td>0.88</td><td><b>12</b></td><td><b>6</b></td><td><b>1.00</b></td><td>0.04</td></tr><tr><td>IM</td><td><b>1.00</b></td><td>0.63</td><td>0.77</td><td><b>0.91</b></td><td>18</td><td>11</td><td>1.00</td><td>0.27</td></tr><tr><td>HM</td><td><b>1.00</b></td><td>0.90</td><td><b>0.94</b></td><td>0.89</td><td>11</td><td>6</td><td><b>0.73</b></td><td><b>0.28</b></td></tr><tr><td>BPIC2013<sub>incf</sub></td><td>BM</td><td>0.87</td><td>0.98</td><td>0.92</td><td>0.90</td><td><b>13</b></td><td>11</td><td>-</td><td>0.59</td></tr></tbody></table>
<table><caption>Table 2 continued from previous page</caption><tbody><tr><td></td><td>SM</td><td>0.98</td><td><strong>0.99</strong></td><td><strong>0.98</strong></td><td><strong>0.95</strong></td><td>16</td><td><strong>10</strong></td><td><strong>1.00</strong></td><td><strong>0.08</strong></td></tr><tr><td></td><td>IM</td><td><strong>1.00</strong></td><td>0.61</td><td>0.76</td><td>0.94</td><td>16</td><td><strong>10</strong></td><td><strong>1.00</strong></td><td>1.9</td></tr><tr><td></td><td>HM</td><td><strong>1.00</strong></td><td>0.96</td><td>0.98</td><td>0.94</td><td><strong>13</strong></td><td><strong>10</strong></td><td>0.85</td><td>2.05</td></tr><tr><td rowspan="4">BPIC2013<sub>opf</sub></td><td>BM</td><td>0.98</td><td><strong>0.99</strong></td><td><strong>0.99</strong></td><td><strong>0.93</strong></td><td><strong>11</strong></td><td><strong>7</strong></td><td>0.64</td><td>0.03</td></tr><tr><td>SM</td><td>0.83</td><td>0.96</td><td>0.89</td><td><strong>0.93</strong></td><td>13</td><td><strong>7</strong></td><td><strong>1.00</strong></td><td><strong>0.02</strong></td></tr><tr><td>IM</td><td><strong>1.00</strong></td><td>0.75</td><td>0.86</td><td>0.91</td><td>23</td><td>16</td><td><strong>1.00</strong></td><td>0.13</td></tr><tr><td>HM</td><td><strong>1.00</strong></td><td>0.97</td><td><strong>0.99</strong></td><td>0.90</td><td>11</td><td>9</td><td>0.91</td><td>0.11</td></tr><tr><td rowspan="4">BPIC2015<sub>1f</sub></td><td>BM</td><td>0.82</td><td><strong>0.91</strong></td><td><strong>0.87</strong></td><td>0.5</td><td><strong>90</strong></td><td><strong>34</strong></td><td>0.36</td><td><strong>0.03</strong></td></tr><tr><td>SM</td><td>0.77</td><td>0.85</td><td>0.81</td><td>0.49</td><td>172</td><td>99</td><td>0.23</td><td><strong>0.05</strong></td></tr><tr><td>IM</td><td>0.92</td><td>0.79</td><td>0.85</td><td>0.48</td><td>116</td><td>63</td><td>0.31</td><td>0.16</td></tr><tr><td>HM</td><td><strong>1.00</strong></td><td>0.30</td><td>0.46</td><td><strong>0.56</strong></td><td>121</td><td>58</td><td><strong>1.00</strong></td><td>0.25</td></tr><tr><td rowspan="4">BPIC2015<sub>2f</sub></td><td>BM</td><td>0.92</td><td><strong>0.92</strong></td><td>0.92</td><td>0.52</td><td><strong>28</strong></td><td>12</td><td>-</td><td><strong>0.01</strong></td></tr><tr><td>SM</td><td>0.97</td><td>0.88</td><td>0.92</td><td>0.46</td><td>33</td><td>17</td><td>0.15</td><td>0.04</td></tr><tr><td>IM</td><td><strong>1.00</strong></td><td>0.64</td><td>0.78</td><td><strong>0.54</strong></td><td>30</td><td><strong>11</strong></td><td><strong>1.00</strong></td><td>0.1</td></tr><tr><td>HM</td><td><strong>1.00</strong></td><td>0.88</td><td><strong>0.94</strong></td><td>0.49</td><td>33</td><td>16</td><td>0.15</td><td>0.1</td></tr><tr><td rowspan="4">BPIC2015<sub>3f</sub></td><td>BM</td><td>0.84</td><td><strong>0.92</strong></td><td><strong>0.88</strong></td><td>0.53</td><td><strong>82</strong></td><td><strong>30</strong></td><td>0.28</td><td><strong>0.05</strong></td></tr><tr><td>SM</td><td>0.72</td><td>0.68</td><td>0.70</td><td>0.49</td><td>117</td><td>52</td><td>0.20</td><td>0.15</td></tr><tr><td>IM</td><td><strong>1.00</strong></td><td>0.49</td><td>0.66</td><td><strong>0.56</strong></td><td>102</td><td>46</td><td><strong>1.00</strong></td><td>0.18</td></tr><tr><td>HM</td><td>0.90</td><td>0.86</td><td><strong>0.88</strong></td><td>0.52</td><td>91</td><td>39</td><td>0.25</td><td>0.16</td></tr><tr><td rowspan="4">BPIC2015<sub>4f</sub></td><td>BM</td><td>0.89</td><td><strong>0.92</strong></td><td><strong>0.90</strong></td><td><strong>0.55</strong></td><td><strong>22</strong></td><td><strong>6</strong></td><td><strong>1.00</strong></td><td><strong>0.01</strong></td></tr><tr><td>SM</td><td>0.89</td><td><strong>0.92</strong></td><td><strong>0.90</strong></td><td><strong>0.55</strong></td><td><strong>22</strong></td><td><strong>6</strong></td><td><strong>1.00</strong></td><td>0.02</td></tr><tr><td>IM</td><td><strong>1.00</strong></td><td>0.71</td><td>0.83</td><td>0.53</td><td>26</td><td>8</td><td><strong>1.00</strong></td><td>0.1</td></tr><tr><td>HM</td><td>0.88</td><td><strong>0.92</strong></td><td><strong>0.90</strong></td><td><strong>0.55</strong></td><td><strong>22</strong></td><td><strong>6</strong></td><td><strong>1.00</strong></td><td>0.1</td></tr><tr><td rowspan="4">BPIC2015<sub>5f</sub></td><td>BM</td><td>0.96</td><td><strong>0.89</strong></td><td><strong>0.92</strong></td><td>0.38</td><td><strong>33</strong></td><td><strong>15</strong></td><td>0.67</td><td><strong>0.01</strong></td></tr><tr><td>SM</td><td><strong>1.00</strong></td><td>0.85</td><td><strong>0.92</strong></td><td><strong>0.41</strong></td><td>36</td><td>16</td><td>0.64</td><td>0.04</td></tr><tr><td>IM</td><td><strong>1.00</strong></td><td>0.47</td><td>0.64</td><td><strong>0.41</strong></td><td>36</td><td>16</td><td><strong>1.00</strong></td><td>0.12</td></tr><tr><td>HM</td><td><strong>1.00</strong></td><td>0.85</td><td><strong>0.92</strong></td><td>0.38</td><td>36</td><td>18</td><td>0.61</td><td>0.12</td></tr><tr><td rowspan="4">BPIC2017<sub>f</sub></td><td>BM</td><td>0.93</td><td>0.96</td><td><strong>0.94</strong></td><td>0.80</td><td><strong>54</strong></td><td>50</td><td>0.69</td><td>15.68</td></tr><tr><td>SM</td><td>0.83</td><td><strong>1.00</strong></td><td>0.91</td><td>0.80</td><td>142</td><td>116</td><td>0.23</td><td><strong>0.21</strong></td></tr><tr><td>IM</td><td>0.94</td><td>0.85</td><td>0.89</td><td>0.92</td><td>62</td><td><strong>47</strong></td><td>0.45</td><td>25.24</td></tr><tr><td>HM</td><td><strong>1.00</strong></td><td>0.22</td><td>0.36</td><td><strong>0.94</strong></td><td>91</td><td>69</td><td><strong>1.00</strong></td><td>30.92</td></tr><tr><td rowspan="4">BPIC2017<sub>of</sub></td><td>BM</td><td><strong>1.00</strong></td><td><strong>1.00</strong></td><td><strong>1.00</strong></td><td><strong>0.99</strong></td><td>15</td><td>8</td><td>0.27</td><td>5.2</td></tr><tr><td>SM</td><td><strong>1.00</strong></td><td><strong>1.00</strong></td><td><strong>1.00</strong></td><td><strong>0.99</strong></td><td>15</td><td>8</td><td>0.27</td><td><strong>0.11</strong></td></tr><tr><td>IM</td><td><strong>1.00</strong></td><td>0.80</td><td>0.89</td><td>0.99</td><td><strong>14</strong></td><td><strong>7</strong></td><td><strong>1.00</strong></td><td>11.02</td></tr><tr><td>HM</td><td>0.91</td><td><strong>1.00</strong></td><td>0.95</td><td>0.79</td><td>18</td><td>10</td><td>0.22</td><td>11.79</td></tr><tr><td rowspan="4">BPIC2020<sub>DDf</sub></td><td>BM</td><td><strong>1.00</strong></td><td><strong>0.99</strong></td><td><strong>1.00</strong></td><td><strong>0.97</strong></td><td>19</td><td>10</td><td>0.58</td><td>2.5</td></tr><tr><td>SM</td><td><strong>1.00</strong></td><td><strong>0.99</strong></td><td><strong>1.00</strong></td><td><strong>0.97</strong></td><td>21</td><td>10</td><td>0.57</td><td><strong>0.05</strong></td></tr><tr><td>IM</td><td><strong>1.00</strong></td><td>0.70</td><td>0.82</td><td><strong>0.97</strong></td><td>23</td><td>13</td><td><strong>1.00</strong></td><td>1.9</td></tr><tr><td>HM</td><td>0.91</td><td>0.99</td><td>0.95</td><td>0.90</td><td><strong>18</strong></td><td><strong>8</strong></td><td>0.28</td><td>2.09</td></tr><tr><td rowspan="4">BPIC2020<sub>IDf</sub></td><td>BM</td><td>0.89</td><td>0.93</td><td>0.91</td><td>0.84</td><td><strong>65</strong></td><td><strong>47</strong></td><td>0.19</td><td>2.96</td></tr><tr><td>SM</td><td>0.85</td><td>0.75</td><td>0.79</td><td>0.78</td><td>149</td><td>125</td><td>0.05</td><td><strong>0.37</strong></td></tr><tr><td>IM</td><td><strong>1.00</strong></td><td>0.25</td><td>0.40</td><td><strong>0.93</strong></td><td>112</td><td>76</td><td><strong>1.00</strong></td><td>3.26</td></tr><tr><td>HM</td><td>0.91</td><td>0.94</td><td><strong>0.93</strong></td><td>0.72</td><td>100</td><td>89</td><td>0.10</td><td>3.44</td></tr><tr><td>BPIC2020<sub>PLf</sub></td><td>BM</td><td>0.84</td><td>0.96</td><td>0.89</td><td>0.81</td><td><strong>85</strong></td><td><strong>60</strong></td><td><strong>0.51</strong></td><td>2.99</td></tr></tbody></table>
<table><caption>Table 2 continued from previous page</caption><tbody><tr><td></td><td>SM</td><td>0.75</td><td>0.91</td><td>0.82</td><td>0.79</td><td>229</td><td>195</td><td>0.12</td><td><strong>0.55</strong></td></tr><tr><td></td><td>IM</td><td><strong>1.00</strong></td><td>0.09</td><td>0.17</td><td><strong>0.90</strong></td><td>-</td><td>-</td><td>-</td><td>3.95</td></tr><tr><td></td><td>HM</td><td>0.89</td><td><strong>0.97</strong></td><td><strong>0.93</strong></td><td>0.74</td><td>118</td><td>103</td><td>0.16</td><td>3.39</td></tr><tr><td rowspan="4">BPIC2020<sub>PTC<sub>f</sub></sub></td><td>BM</td><td>0.93</td><td>0.91</td><td><strong>0.92</strong></td><td>0.77</td><td><strong>62</strong></td><td><strong>44</strong></td><td>0.19</td><td>0.96</td></tr><tr><td>SM</td><td>0.78</td><td>0.76</td><td>0.77</td><td>0.72</td><td>163</td><td>128</td><td>0.01</td><td><strong>0.28</strong></td></tr><tr><td>IM</td><td><strong>0.98</strong></td><td>0.11</td><td>0.20</td><td><strong>0.89</strong></td><td>100</td><td>73</td><td><strong>1.00</strong></td><td>0.95</td></tr><tr><td>HM</td><td>0.91</td><td><strong>0.94</strong></td><td><strong>0.92</strong></td><td>0.68</td><td>88</td><td>76</td><td>0.11</td><td>0.9</td></tr><tr><td rowspan="4">BPIC2020<sub>RP<sub>f</sub></sub></td><td>BM</td><td><strong>1.00</strong></td><td><strong>0.99</strong></td><td><strong>0.99</strong></td><td>0.96</td><td>21</td><td>11</td><td>0.48</td><td>1.96</td></tr><tr><td>SM</td><td><strong>1.00</strong></td><td><strong>0.99</strong></td><td><strong>0.99</strong></td><td><strong>0.97</strong></td><td>24</td><td>11</td><td>0.46</td><td>0.05</td></tr><tr><td>IM</td><td><strong>1.00</strong></td><td>0.78</td><td>0.88</td><td><strong>0.97</strong></td><td>24</td><td>15</td><td><strong>1.00</strong></td><td>1.5</td></tr><tr><td>HM</td><td>0.92</td><td><strong>0.99</strong></td><td>0.95</td><td>0.90</td><td><strong>20</strong></td><td><strong>9</strong></td><td>0.10</td><td>1.62</td></tr><tr><td rowspan="4">RTFMP<sub>f</sub></td><td>BM</td><td>0.98</td><td><strong>1.00</strong></td><td><strong>0.98</strong></td><td>0.99</td><td><strong>13</strong></td><td><strong>6</strong></td><td>0.46</td><td>13.26</td></tr><tr><td>SM</td><td>0.88</td><td>0.99</td><td>0.93</td><td><strong>1.00</strong></td><td>21</td><td>10</td><td>0.29</td><td><strong>0.29</strong></td></tr><tr><td>IM</td><td>0.92</td><td><strong>1.00</strong></td><td>0.96</td><td>0.84</td><td>20</td><td>14</td><td>0.15</td><td>24.03</td></tr><tr><td>HM</td><td><strong>1.00</strong></td><td>0.66</td><td>0.80</td><td><strong>1.00</strong></td><td>22</td><td>15</td><td><strong>1.00</strong></td><td>21.64</td></tr><tr><td rowspan="4">SEPSIS<sub>f</sub></td><td>BM</td><td>0.79</td><td><strong>0.99</strong></td><td><strong>0.88</strong></td><td>0.76</td><td><strong>26</strong></td><td><strong>16</strong></td><td>0.41</td><td>0.35</td></tr><tr><td>SM</td><td>0.92</td><td>0.70</td><td>0.79</td><td>0.74</td><td>34</td><td>21</td><td>0.71</td><td><strong>0.02</strong></td></tr><tr><td>IM</td><td>0.90</td><td>0.83</td><td>0.86</td><td>0.72</td><td>47</td><td>39</td><td>0.23</td><td>0.13</td></tr><tr><td>HM</td><td><strong>1.00</strong></td><td>0.60</td><td>0.75</td><td><strong>0.86</strong></td><td>40</td><td>25</td><td><strong>1.00</strong></td><td>0.12</td></tr></tbody></table>

<caption>Table 2: Evaluation results</caption>

The generalization capabilities of BM stand out as a key strength. Across the majority of datasets, BM consistently achieved scores that matched or surpassed those of the baseline methods, demonstrating its ability to generalize beyond observed behaviors without succumbing to overgeneralization. For instance, in the RTFMP log, BM achieved an impressive generalization score of 0.99, while maintaining minimal structural complexity, highlighting its superior adaptability and precision.

Regarding model simplicity, BM frequently outperformed its competitors by generating smaller, more interpretable models with lower structural complexity. A notable example is the SEPSIS log, where BM produced a model with only 26 elements and a CFC of 16, significantly enhancing interpretability compared to SM, IM, and HM. Similarly, in synthetic loops such as L3 and L4, BM maintained high fitness and precision while preserving structural clarity, further showcasing its effectiveness in handling complex loop structures.

In terms of execution time, SM remains the fastest method for real-life event logs. However, BM demonstrates improved efficiency over IM and HM, striking a commendable balance between performance and computational demand.

Overall, the empirical results underscore BM's ability to deliver accurate, interpretable, and generalizable models. While other methods, such as SM and HM, exhibit specific strengths in certain scenarios, BM provides a comprehensive solution, excelling particularly in handling loops and generating well-rounded models across diverse datasets.
# 7 Conclusion & Future Work

This paper introduces Bonita Miner, a novel approach to process discovery that effectively balances key metrics—fitness, precision, generalization, and simplicity—even when dealing with complex loop structures. By leveraging the Depth-First Algorithm (DFA) for split and join gateway construction and advanced filtering of Directly-Follows Graphs (DFG), Bonita Miner simplifies the process model generation while maintaining behavioral accuracy. The proposed method addresses the limitations of existing techniques by producing simpler, more interpretable models that are robust to the intricacies of real-world processes, such as concurrency and loops. Empirical results demonstrate its superiority over state-of-the-art methods, particularly in its ability to generate behaviorally accurate and structurally simpler models.

Future enhancements to Bonita Miner could focus on several areas of development. One area is the optimization of execution time, as reducing the computational overhead for processing large-scale event logs would make the method more practical for industry-scale applications. Another promising direction is the incorporation of automatic deadlock detection and prevention mechanisms. This would not only enhance the robustness of the process models but also ensure their operational soundness in real-world scenarios.

# References

1. van der Aalst, W.M.P.: Process Mining - Data Science in Action, Second Edition. Springer (2016)

2. van der Aalst, W.M.P., Weijters, T., Maruster, L.: Workflow mining: Discovering process models from event logs. IEEE Trans. Knowl. Data Eng. 16(9), 1128-1142 (2004)

3. Augusto, A., Conforti, R., Dumas, M., Rosa, M.L., Bruno, G.: Automated discovery of structured process models: Discover structured vs. discover and structure. In: Conceptual Modeling - 35th International Conference, ER 2016, Gifu, Japan, November 14-17, 2016, Proceedings. Lecture Notes in Computer Science, vol. 9974, pp. 313-329 (2016)

4. Augusto, A., Conforti, R., Dumas, M., Rosa, M.L., Maggi, F.M., Marrella, A., Mecella, M., Soo, A.: Automated discovery of process models from event logs: Review and benchmark. IEEE Trans. Knowl. Data Eng. 31(4), 686-705 (2019)

5. Augusto, A., Conforti, R., Dumas, M., Rosa, M.L., Polyvyanyy, A.: Split miner: automated discovery of accurate and simple business process models from event logs. Knowl. Inf. Syst. 59(2), 251-284 (2019)

6. Bender, M.A., Farach-Colton, M., Pemmasani, G., Skiena, S., Sumazin, P.: Lowest common ancestors in trees and directed acyclic graphs. J. Algorithms 57(2), 75-94 (2005)

7. Berti, A., van Zelst, S., Schuster, D.: Pm4py: A process mining library for python. Software Impacts 17, 100556 (2023)

8. Buijs, J.C.A.M., van Dongen, B.F., van der Aalst, W.M.P.: On the role of fitness, precision, generalization and simplicity in process discovery. In: On the Move to Meaningful Internet Systems: OTM 2012, Confederated International Conferences: CoopIS, DOA-SVI, and ODBASE 2012, Rome, Italy, September 10-14, 2012.
Proceedings, Part I. Lecture Notes in Computer Science, vol. 7565, pp. 305–322.
Springer (2012)

9. Chinosi, M., Trombetta, A.: BPMN: an introduction to the standard. Comput. Stand. Interfaces **34**(1), 124–134 (2012)

10. Dumas, M., García-Bañuelos, L., Polyvyanyy, A.: Unraveling unstructured process models. In: Business Process Modeling Notation - Second International Workshop, BPMN 2010, Potsdam, Germany, October 13-14, 2010. Proceedings. Lecture Notes in Business Information Processing, vol. 67, pp. 1–7. Springer (2010)

11. Dumas, M., Rosa, M.L., Mendling, J., Mäesalu, R., Reijers, H.A., Semenenko, N.: Understanding business process models: The costs and benefits of structuredness. In: Advanced Information Systems Engineering - 24th International Conference, CAiSE 2012, Gdansk, Poland, June 25-29, 2012. Proceedings. Lecture Notes in Computer Science, vol. 7328, pp. 31–46. Springer (2012)

12. Leemans, S.J.J., Fahland, D., van der Aalst, W.M.P.: Discovering block-structured process models from event logs - A constructive approach. In: Application and Theory of Petri Nets and Concurrency - 34th International Conference, PETRI NETS 2013, Milan, Italy, June 24-28, 2013. Proceedings. Lecture Notes in Computer Science, vol. 7927, pp. 311–329. Springer (2013)

13. Leemans, S.J.J., Fahland, D., van der Aalst, W.M.P.: Discovering block-structured process models from event logs containing infrequent behaviour. In: Business Process Management Workshops - BPM 2013 International Workshops, Beijing, China, August 26, 2013, Revised Papers. Lecture Notes in Business Information Processing, vol. 171, pp. 66–78. Springer (2013)

14. Mendling, J., Reijers, H.A., van der Aalst, W.M.P.: Seven process modeling guidelines (7PMG). Inf. Softw. Technol. **52**(2), 127–136 (2010)

15. Weber, M., Kindler, E.: The petri net markup language. In: Petri Net Technology for Communication-Based Systems - Advances in Petri Nets. vol. 2472, pp. 124–144. Springer (2003)

16. Weerdt, J.D., Backer, M.D., Vanthienen, J., Baesens, B.: A multi-dimensional quality assessment of state-of-the-art process discovery algorithms using real-life event logs. Inf. Syst. **37**(7), 654–676 (2012)

17. Weijters, A.J.M.M., Ribeiro, J.T.S.: Flexible heuristics miner (FHM). In: Proceedings of the IEEE Symposium on Computational Intelligence and Data Mining, CIDM 2011, part of the IEEE Symposium Series on Computational Intelligence 2011, April 11-15, 2011, Paris, France. pp. 310–317. IEEE (2011)

18. Weijters, A.J.M.M., Ribeiro, J.T.S.: Flexible heuristics miner (FHM). In: Proceedings of the IEEE Symposium on Computational Intelligence and Data Mining, CIDM 2011, part of the IEEE Symposium Series on Computational Intelligence 2011, April 11-15, 2011, Paris, France. pp. 310–317. IEEE (2011)