Process mining algorithms are unable to retain the modularity details of the processes, which are inherent as part of implementations of process, but get missed out during mining. We propose to mine processes in form of Process Line Diagrams (PLDs) in order to retain modularity as part of process mining itself.
Process Line Diagram (PLD) [
Modularity of processes refers to inherent structuring
of processes into logical modules or components. Existing
process mining algorithms focus on extracting the
executional structures of processes from their trace logs. These
algorithms utilize diferent modeling approaches for
representation of extracted processes. For example, BPMN
miners [
Our idea centers on the extraction of modular structures from process trace sets, aiming to retain implementationfriendly modularity into the mining process. We utilize Process Line Diagrams (PLDs) as a means of capturing and visualizing the modular structure of processes extracted from trace logs.
We consider an exemplar Petri Net (PN) shown in Figure 2 to demonstrate step-wise construction of corresponding
PLD. Considering the traceset T= {a.c.t.x.z, a.c.t.y.z, a.c.t.z.x,
a.c.t.z.y, b.c.t.x.z, b.c.t.y.z, b.c.t.z.x, b.c.t.z.y, c.a.t.x.z, c.a.t.z.x,
c.a.t.y.z, c.a.t.z.y, c.b.t.x.z, c.b.t.z.x, c.b.t.y.z, c.b.t.z.y}, we
illustrate mining of process using Figure 1, to obtain PLD shown
in Figure 3. Process mining algorithms, such as alpha
mining [
xor_merge: {’t’= {’a’, ’b’}} and_fork: {’t’= {’z’}, {’x’, ’y’}, ’start’= {’c’}, {’a’, ’b’}} and_join: {’t’= {’c’}, {’a’, ’b’}} Absence of a transition in records of any of the relationships ((1) through (4)) can be assumed as an empty set for that transition. It represents the state of transition being not involved in that relationship. For example, there are no XOR splits from transitions a, b, c, x, y and z in this example, and thus they do not hold their records in xor_split shown in (1).
Construction of a process line diagram for the process begins with construction of a role from unnamed marking point, start (hidden). Presence of _ () in (3), constructs multicast event as shown in Figure 1(a), subsequently followed by two corresponding event catches into two new roles as shown in Figure 1(b), because _ () forks transition start into {c} and {a, b}. We name the multicast event and its corresponding event catches as a combination of two forks i.e. here abc. One of these event catches, representing the forking from start into {c}, is immediately followed by construction of transition c due to absence of XOR merge and AND join at transition c. It is shown in Figure 1(c). Transition c is involved in _() = {}, {, } representing and_join at transition t. Ergo, a throw event t is constructed next to transition c as shown in Figure 1(d). An event catch t to correspond to this event throw t is constructed in a new role as shown in Figure 1(e), because merge(s)/join(s) exist at transition t and a role for transition t is not created yet. This newly created role is responsible for connecting all joins and merges incoming into transition t before its actual execution. It holds synchronisation conditions imposed for actual execution of transition t to occur. The mining process subsequently continues for the event catch abc for the second fork, which originates from start and forks into {, }. Existence of multiple (here, two) transitions in this fork, represents XOR split into transitions that are present in _() = {, }. Ergo, the event catch (abc) of second fork is followed by a selection guard as shown in Figure 1(f). The guard is split into two XOR split paths, which represent paths corresponding to multiplicity (transitions in the fork) i.e. a and b in this fork. One of these xor split paths, corresponding to transition a, is followed by immediate construction of transition a due to absence of XOR merge and AND join at transition a. It is illustrated in Figure 1(g).
It can be observed using (2) and (4) that transition a is involved in _() = {, } and _() = {}, {, } i.e. XOR merge and AND join taking place at transition t. Consequently, an event throw t is constructed next to transition a as shown in Figure 1(h). Notably, despite involvement of transition a in both XOR merge and AND join, event throw t is constructed only once. A corresponding event catch t is constructed to continue the role that holds all joins and merges for transition t, which occur before its actual execution, as presented in Figure 1(i). Likewise, Figure 1(j) illustrates construction of the other XOR split path, corresponding to transition b. Transition b is constructed, and followed by construction of a subsequent event throw due to (2) and (4). It can be observed that a new event catch is not constructed, because an XOR merge requires a single event catch and it has already been created during construction of previous XOR split path. As shown in Figure 1(k), the transition t is constructed for its actual execution, after all the merges and joins synchronising its execution through event catches on its role are constructed.
The mining approach iterates to continue the flow of process construction. The AND fork, originating from transition t, _ () = {}, {, }, is constructed using multicast event xyz as shown in Figure 1(l), and its corresponding event catches xyz in two new roles to represent forkings into {z} and {x,y} are then constructed as shown in Figure 3. This construction for AND fork relationship from transition t into z,y and x is similar to that from start into c, a and b. Thus, the remainder of process mining continues in similar manner to obtain PLD shown in Figure 3, with event catches xyz followed by construction of transition z, and construction of selection guard depicting XOR split into transitions y and x, which are subsequently constructed respectively on splits from the selection guard. These roles and split paths end in absence of further relations from transition z, y and x respectively.
In contrast to traditional PN and allied extractor mining
algorithms, which generate complex, non-modular outputs, the
paper presented an idea that can retain inherent modularity
inside a process during process mining. The paper explores
extraction of processes in the form of Process Line Diagrams
(PLDs), as compared to other process mining algorithms that
mine processes as BPMN, Petri Nets, heuristic nets, process
trees, Directly follows graphs, finite automatons, etc., which
do not attempt to preserve modularity details. The paper
utilizes the implementation-friendly modular modeling
approach of PLDs for representation of extracted processes. It
is illustrated through an exemplar Petri Net converted into
PLD. An automated evaluation system for process line
diagrams for testing volumes of logs is the next step in direction
of PLD modeling and mining. PLD mining algorithms can
be developed to utilize the entire toolset of process line
diagrams in mined processes, and incorporate patterns given
in [