<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Folding Partially Ordered Runs</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Robin Bergenthum</string-name>
          <email>robin.bergenthum@fernuni-hagen.de</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Sebastian Mauser</string-name>
          <email>sebastian.mauser@fernuni-hagen.de</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Department of Software Engineering</institution>
          ,
          <addr-line>FernUniversita ̈t in Hagen</addr-line>
        </aff>
      </contrib-group>
      <fpage>52</fpage>
      <lpage>62</lpage>
      <abstract>
        <p>In this paper we present a folding algorithm to construct a process model from a specification given by a set of scenarios. Each scenario is formalized as a partially ordered set of activities of the process. As a process model we consider Event-driven Process Chains which are well established in the domain of business process modeling. Assuming that a specification describes valid behavior of the process to be modeled, the crucial requirement is to get a process model which in any case is able to execute all input scenarios.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1 Introduction</title>
      <p>Business process modeling and management has attracted increasing attention in recent
years. The usual approach to process model construction is that a domain expert
edits a formal process model. Simulation tools generate single scenarios of that process
model which can also be viewed as formal objects. Then, the expert checks whether the
scenarios of the model correspond to possible scenarios of the intended process. In the
negative case, he changes the process model and iteratively repeats the simulation.</p>
      <p>
        In the papers [
        <xref ref-type="bibr" rid="ref1 ref2">1, 2</xref>
        ] a proceeding in the opposite direction has been suggested. It is
assumed that the domain experts know some or all scenarios of a process to be modeled
better than the process itself. Actually, experts might also know parts of the process
model including parts of its branching structure, but in this case scenarios can be
derived from this partially known process model. Experience shows that in various
application areas processes are specified in terms of example scenarios (an evidence is the
commonly used sequence diagrams in UML to specify scenarios).
      </p>
      <p>
        In a first step of the approach from [
        <xref ref-type="bibr" rid="ref1 ref2">1, 2</xref>
        ], the scenarios of a process are specified
by domain experts. Then, these scenarios have to be formalized yielding formal runs.
Formalization on the instance level of single scenarios is an intuitive task. In our setting,
the scenarios are formalized in terms of labeled partial orders (LPOs) representing
occurrences of process activities and their mutual order relation. Under the name instance
Event-driven Process Chains (iEPCs), a similar concept is also applied in the
industrial ARIS PPM tool [
        <xref ref-type="bibr" rid="ref3 ref4">3, 4</xref>
        ]. As in the case of iEPCs, we do not allow auto-concurrency,
i.e. we assume that the scenario descriptions of the domain experts do not contain two
concurrent occurrences of the same activity.
      </p>
      <p>
        In a second step, a process model is automatically generated from the given
formal runs. For this step, in previous work [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ] it was suggested to build on synthesis
algorithms generating Petri nets exactly having the behavior given by a set of LPOs.
Although using an exact synthesis algorithm as the starting point for this step has
several advantages such as reliable results, there are also several problems w.r.t. practical
applicability. Namely, a precise reproduction is mostly not desired in practice due to
incomplete information, the performance of synthesis is low and the resulting nets are
sometimes difficult to understand.
      </p>
      <p>
        In the related field of process mining [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ], simplified construction algorithms are
successful. Against this background, in this paper we develop a simplified
construction algorithm for the automatic generation of a process model from a set of example
scenarios given by LPOs. We here use Event-driven Process Chains (EPCs) to model
processes. The idea of our approach is to fold the scenarios to one EPC model similar as
in [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] (the approach has also similarities to [
        <xref ref-type="bibr" rid="ref5 ref6">6, 5</xref>
        ]). The resulting EPC represents all the
direct dependencies given by the LPOs. The folding algorithm is efficient and
generates intuitive models. Still, it has the important property that all the explicitly specified
example LPOs are executable scenarios of the generated EPC.
      </p>
      <p>To formally define the folding algorithm and to prove the latter important result, we
first provide formal definitions in the next section, in particular we introduce the notion
of an LPO executable w.r.t. an EPC. Then, in Section 3 we introduce and discuss the
folding algorithm generating an EPC from a set of LPOs. Finally, Section 4 concludes
the paper.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Partially Ordered Runs of EPCs</title>
      <p>
        EPCs are an intuitive modeling language for business processes [
        <xref ref-type="bibr" rid="ref7 ref8">7, 8</xref>
        ]. Since the
language was initially not intended for formal specifications, the formal definitions of
EPCs in literature show some differences. We here give a short and simple definition of
an EPC.
      </p>
      <p>Definition 1. An EPC-structure is a five-tuple epc = (A, E , Cxor, Cand, D) where A is
a finite set of activities (also called functions), E is a finite set of events, Cxor resp. Cand
are finite sets of XOR- resp. AND-connectors and D ⊆ (A ∪ E ∪ Cxor ∪ Cand) × (A ∪
E ∪ Cxor ∪ Cand) is a set of directed edges connecting activities, events and connectors.
An EPC-structure is an Event-driven Process Chain (EPC) if:
(i) Events have at most one incoming and one outgoing edge.
(ii) Activities have precisely one incoming and one outgoing edge.
(iii) Connectors have either one incoming edge and multiple outgoing edges, or multiple
incoming edges and one outgoing edge.</p>
      <p>Activities, events and connectors are also called nodes of an EPC. Given a node n,
the set of edges •n := {(n , n) ∈ D | n ∈ A ∪ E ∪ Cxor ∪ Cand} is called preset of n
and the set of edges n• := {(n, n ) ∈ D | n ∈ A ∪ E ∪ Cxor ∪ Cand} is called postset
of n. Furthermore, an event having an empty preset is called initial event.</p>
      <p>An example of an EPC is shown in Figure 1. Activities are illustrated by rounded
rectangles, events by hexagons and connectors by circles.</p>
      <p>For simplicity, this definition of an EPC does not regard OR-connectors, since they
are not necessary for our considerations later on. Moreover, syntactically it is not as
restrictive as other definitions found in the literature. The main differences are described
in the following remark. However, these differences are not relevant for semantical
issues.</p>
      <p>Remark 1. We omit the stylistic requirements for EPCs that in every path activities and
events alternate, that an XOR-split must not succeed an event and that there should be
no cycle of control flow that consists of connectors only.</p>
      <p>
        In the following, we define a partial order semantics for EPCs. We introduce such
semantics analogously as in the case of Petri nets, see e.g. [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ].
      </p>
      <p>
        First, we define an occurrence rule for nodes of an EPC. Thereby, we consider the
notion of a marking representing a state of an EPC analogously as in [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] by assigning
tokens resp. process folders to the edges of the EPC. A problem is that the semantics of
XOR-joins (and OR-joins) of EPCs is not clear [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ]. In the literature there are different
occurrence rules for XOR-joins. In this paper, we consider the simple “Petri net
semantics” as given in [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] where an XOR-join can fire if one of its incoming edges contains
a process folder. In this way, the exclusiveness of an XOR-operator is not regarded.
However, an appropriate approach for considering the exclusiveness meaning of XOR
requires difficult non-local behavioral definitions [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] and there is not yet a standard
approach for solving this problem.
      </p>
      <p>Based on our occurrence rule for single nodes we then define a step occurrence rule
for sets of nodes. Since each edge has exactly one successor node, there are no conflicts
between nodes regarding the consumption of tokens. Consequently, a set of nodes is
concurrently executable if each node of the set is executable. Using this step occurrence
rule we further define the notion of an executable sequence of sets of nodes which we
then restrict to activities by applying an appropriate projection.</p>
      <p>
        Finally, we define the executability of an LPO as in the case of Petri nets (see [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ])
by requiring that each step sequence allowed by the LPO, i.e. being a sequentialization
of the LPO, is executable w.r.t. the given EPC.
      </p>
      <p>A marking of an EPC is formally defined as follows.</p>
      <p>Definition 2. Given an EPC epc = (A, E , Cxor, Cand, D), a marking of epc is a
function m : D → N = {0, 1, 2, . . .}. A pair (epc, m) where epc is an EPC and m is a
marking is called marked EPC.</p>
      <p>A directed edge d ∈ D is called marked if m(d) &gt; 0, marked by one if m(d) = 1
and unmarked if m(d) = 0.</p>
      <p>The initial marking m0 of an EPC is defined as follows:
(i) The postsets of all initial events are marked by one and
(ii) all other edges are unmarked.</p>
      <p>The occurrence rule for nodes of EPCs is given by the following definition.
Definition 3. Given a marked EPC epc = (A, E , Cxor, Cand, D, m), a node n ∈ A ∪
E ∪ Cxor ∪ Cand is executable if one of the following statements holds.
(i) | • n| = 1 and the unique edge d ∈ •n is marked or
(ii) | • n| &gt; 1, n ∈ Cand and each edge d ∈ •n is marked or
(iii) | • n| &gt; 1, n ∈ Cxor and at least one edge d ∈ •n is marked.</p>
      <p>If a node is executable, it can be fired changing the marking of the EPC. Firing a
node n ∈ Cxor leads to the marking m defined by:</p>
      <p>When firing a node n ∈ Cxor, a marked edge ein ∈ •n and an edge eout ∈ n• have
to be fixed. Then, firing n w.r.t. ein and eout leads to the marking m defined by:
⎧ m(d) − 1, d ∈ •n
m (d) = ⎨ m(d) + 1, d ∈ n•
⎩ m(d) else
⎧ m(d) − 1, d = ein
m (d) = ⎨ m(d) + 1, d = eout</p>
      <p>⎩ m(d) else
Each different choice of ein and eout yields another marking m .</p>
      <p>If a node n is executable in a marking m and firing n leads to a marking m , we
shortly write m →n m .</p>
      <sec id="sec-2-1">
        <title>Next, we further extend the occurrence rule to sets of nodes.</title>
        <p>Definition 4. A set of nodes N is concurrently executable in a marking m if each node
n ∈ N is executable in m.</p>
        <p>In this case, a follower marking m is given by firing the set of nodes in any order.
If a set of nodes N is executable in a marking m and firing N leads to a marking m ,
we write m →N m .</p>
        <p>A sequence of sets of nodes σ = N1N2 . . . Nn is executable in a marking m, if there
are markings m1, m2, . . . mn such that m N1 m1 N→2 . . . N→n mn.</p>
        <p>→</p>
        <p>Given an executable sequence of sets of nodes σ = N1N2 . . . Nn and its projection
onto activities σA∅ = N1 ∩ A . . . Nn ∩ A, the sequence of sets of activities which arises
from σA∅ when omitting all empty sets is called activity step sequence σA of σ.</p>
        <p>A sequence of sets of activities σ is executable in a marking m if there exists an
executable sequence of sets of nodes σ such that σ = σA.</p>
        <p>For instance, in the initial marking of the EPC in Figure 1 the sequence of sets of
nodes {ST }, {Event}, {A}, {XOR}, {AN D}, {Event, XOR}, {Event}, {B, D},
{Event}, {C, XOR} is executable (for simplicity we omit names for connectors and
events). Therefore, the corresponding activity step sequence {ST }, {A}, {B, D}, {C}
is executable. We use the following notions for partially ordered runs.
Definition 5. Given a set of activities A, a (finite) labeled partial order (LPO) is a
triple lpo = (V, &lt;, l), where V is a finite set of vertices, &lt; is an irreflexive and transitive
binary relation over V and l : V → A is a labeling function. The Hasse diagram
underlying an LPO lpo = (V, &lt;, l) is defined by the labeled directed graph hlpo =
(V, &lt;h, l) where &lt;h= {(v, v ) | v &lt; v ∧ ∃v : v &lt; v &lt; v } is the set of skeleton
edges.</p>
        <p>We here only consider LPOs without autoconcurrency i.e. v, v ∈ V, v = v , v &lt;
v , v &lt; v ⇒ l(v) = l(v ).</p>
        <p>Given an LPO lpo = (V, &lt;, l), an LPO lpo = (V, &lt; , l) with &lt;⊆&lt; is called
sequentialization of lpo.</p>
        <p>Given an LPO lpo = (V, &lt;, l) and a sequentialization lpo = (V, &lt; , l) of lpo
with V = V1 ∪˙ . . . ∪˙ Vn and &lt; = i&lt;j Vi × Vj , the sequence of sets of activities
l(V1) . . . l(Vn) is called step sequence of lpo.</p>
        <p>In Figure 2, Hasse diagrams of three LPOs are shown. An example of a step
sequence of the first LPO is {ST }, {A}, {B, D}, {C}, {F }, {F I}. Finally, we define the
executability of an LPO.</p>
        <p>Definition 6. Given an EPC epc, an LPO lpo is executable w.r.t. epc if all step
sequences of lpo are executable in the initial marking of epc.</p>
        <p>Note that, as in the case of Petri nets, we can also define the executability of an LPO
w.r.t. an EPC by using concepts similar to occurrence nets and process nets of Petri nets.
3</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Folding Algorithm</title>
      <p>In this section, we explain a folding algorithm generating an EPC model epc = (A, E ,
Cxor, Cand, D) of a business process from a set of LPOs L representing scenarios of the
process. Each LPO of L models one possible run of the process, i.e. different LPOs of
L represent alternative scenarios. A vertex of an LPO represents an activity occurrence
where the label refers to the respective activity of the process. The edges of an LPO
describe the precedence relation of the activity occurrences within the respective scenario.
Unordered vertices represent concurrent activity occurrences. For formal purposes, we
assume that each LPO includes a vertex labeled with ST (Start) which is ordered before
all the other vertices and by a vertex labeled with FI (Final) which is ordered behind all
the other vertices (such vertices can always be added to an LPO).</p>
      <p>We now present the steps of the folding algorithm generating an EPC epc from a
set of LPOs L. Directly after the following formal definition of the algorithm which is
rather technical, we provide an illustrative example.</p>
      <p>– The algorithm generates an EPC with only two events, a start and a final event, i.e.</p>
      <p>E = {Start, F inal}. The set of activities of the EPC is given by the labels of the
LPOs, i.e. A = {l(v) | v ∈ V, (V, &lt;, l) ∈ L}.
– For each vertex v ∈ V , (V, &lt;, l) ∈ L we consider the sets of direct predecessor
and successor activities of the vertex, called predecessor-set and successor-set of
the vertex. The predecessor-set is defined as pred(v) = {l(v ) | v &lt;h v}, the
successor-set is defined as succ(v) = {l(v ) | v &lt;h v }.
– Then, for each activity a ∈ A we consider all vertices labeled by this activity and
collect the predecessor-sets of these vertices in one set, called pre-activity-set of the
activity, and the successor-sets of these vertices in another set, called
post-activityset of the activity. The pre-activity-set is defined as prea(a) = {pred(v) = ∅ |
v ∈ V, (V, &lt;, l) ∈ L, l(v) = a}, the post-activity-set is defined as posta(a) =
{succ(v) = ∅ | v ∈ V, (V, &lt;, l) ∈ L, l(v) = a}.
– For each activity a ∈ A we define an EPC-structure epca = ({a}, ∅, Cxaor, Caand, Da)
containing the activity a and connectors determined by the dependencies given
by the pre-activity-set and post-activity-set of a. The EPC-structure epca is called
building block of a.</p>
      <p>• Cxor = {xorpare, xorpaost} ∪ {xorpare,a | a ∈ x, x ∈ prea(a)} ∪ {xorpaost,a |
a
a ∈ x, x ∈ posta(a)}
• Cand = {andpare,x | x ∈ prea(a)} ∪ {andpaost,x | x ∈ posta(a)}</p>
      <p>a
• Da = {(xorpare, a), (a, xorpaost} ∪ {(andpare,x, xorpare) | x ∈ prea(a)} ∪
{(xorpaost, andpaost,x) | x ∈ posta(a)} ∪ {(xorpre,a , andpare,x) | a ∈ x, x ∈
a
prea(a)} ∪ {(andpost,x, xorpaost,a ) | a ∈ x, x ∈ posta(a)}</p>
      <p>a
– By connecting the appropriate interface-connectors (xorpaost,a with xorpare,a) of
the building blocks we get the EPC-structure epc = (A, ∅, Cxor, Cand, D ) defined
by Cxor = a∈A Cxaor, Cand = a∈A Caand and D = a∈A Da ∪ {(xorpaost,a ,
xorpare,a) | a, a ∈ A, xorpaost,a ∈ Cxaor, xorpare,a ∈ Cxaor}.
– Finally, the EPC epc = (A, E, Cxor, Cand, D) results from removing all connectors
c having exactly one incoming edge (n, c) and exactly one outgoing edge (c, n )
from Cxor. The two edges (n, c) and (c, n ) are also removed from D and an edge
(n, n ) is added to D . Moreover, the connectors xorpSrTe and xorpFoIst are removed
from Cxor. Also their related edges (xorpSrTe, ST ) and (F I, xorpFoIst) are removed
from D and edges (Start, ST ) and (F I, F inal) are added to D .</p>
      <p>As an example, we consider the set of LPOs L illustrated in Figure 2 by their
Hassediagrams. In this example, we have A = {ST, A, B, C, D, E, F, G, F I}. To illustrate
the notion of predecessor- and successor-sets consider the vertex v labeled by A in the
first example LPO. There holds pred(v) = {ST } and succ(v) = {B, D}. As the
preand post-activity-set of the activity A we altogether get prea(A) = {{ST }, {G}} and
posta(A) = {{B, D}, {E, D}, {G}}. The construction of the building block for the
activity A is shown in Figure 3.</p>
      <p>– We first add an XOR-split-connector having an incoming edge coming from A and
|posta(A)| outgoing edges (Figure 3 (a)).
– Each outgoing edge of the XOR-split represents one set x ∈ posta(A) (i.e. one
possible set of successor-activities of A). Such edge is connected with a new
ANDsplit connector having |x| outgoing edges (Figure 3 (b)).
– Each outgoing edge of such AND-split represents a connection to one activity
a ∈ x. For each such a , the respective edges have to be merged to a unique
interface w.r.t. a . Therefore, these edges are connected with a new XOR-join-connector
representing the unique interface. This connector has one outgoing edge for the
connection with the activity a (Figure 3 (c)).
– By proceeding analogously for prea(A) (the role of incoming and outgoing edges
as well as the role of splits and joins switches, see Figure 3 (d)-(f)) we get a building
block for the activity A having a unique outgoing-interface to each activity a ∈
x, x ∈ posta(A) and a unique incoming-interface to each activity a ∈ x, x ∈
prea(A).</p>
      <p>Figure 4 shows the building blocks for all the activities of our example, where
connectors having exactly one incoming edge and exactly one outgoing edge and the
connectors xorpSrTe and xorpFoIst are already removed and replaced as defined by the last step
of the algorithm. The interfaces of the building blocks exactly fit together, i.e. if the
block of activity a has an outgoing-interface to a , then a has an incoming-interface to
a. Therefore, the building blocks are connected along these interfaces yielding the final
EPC shown in Figure 5.
and only if xorpare,a ∈ Cxaor.
xorpare,a ∈ Cxaor.</p>
      <p>Proof. There holds xorpaost,a ∈ Cxaor if and only if there exists x ∈ posta(a) fulfilling
a ∈ x if and only if there exists v ∈ V , (V, &lt;, l) ∈ L, l(v) = a fulfilling a ∈ succ(v)
if and only if there exist v, v ∈ V , (V, &lt;, l) ∈ L, v &lt;h v fulfilling l(v) = a, l(v ) = a
if and only if there exists v ∈ V , (V, &lt;, l) ∈ L, l(v ) = a fulfilling a ∈ pred(v ) if
and only if there exists x ∈ prea(a ) fulfilling a ∈ x if and only if there holds
Lemma 2. The EPC-structure epc = (A, E , Cxor, Cand, D) generated by the previous
algorithm is an EPC according to Definition 1.</p>
      <sec id="sec-3-1">
        <title>Proof. We have to check the requirements (i) - (iii). (i): Start and F inal are the only events of the EPC-structure. By construction, Start has no incoming edge and only one outgoing edge connected with ST . F inal has no outgoing edge and only one incoming edge connected with F I.</title>
        <p>(ii): By construction in epc each activity a ∈ A has exactly one incoming edge
connected with xorpare and one outgoing edge connected with xorpaost. In the last step
of the algorithm, if such edge is removed, it is replaced by another edge, such that (ii)
is preserved.</p>
        <p>(iii): In the last step of the algorithm, property (iii) is ensured by removing from
epc the connectors xorpSrTe and xorpFoIst and all connectors having exactly one incoming
edge and exactly one outgoing edge. It remains to show that each connector of epc
except for xorpSrTe and xorpFoIst either fulfills (iii) or has exactly one incoming edge and
exactly one outgoing edge:
– xorpare (a ∈ A) has exactly one outgoing edge connected with a and it has an
incoming edge connected with andpare,x for each x ∈ prea(a) where prea(a) = ∅
for a = ST .
– xorpaost (a ∈ A) has exactly one incoming edge connected with a and it has an
outgoing edge connected with andpaost,x for each x ∈ posta(a) where posta(a) =
∅ for a = F I.
– andpare,x (a ∈ A, x ∈ prea(a)) has exactly one outgoing edge connected with
xorpare and it has an incoming edge connected with xorpare,a for each a ∈ x
where x = ∅.
– andpaost,x (a ∈ A, x ∈ posta(a)) has exactly one incoming edge connected with
xorpaost and it has an outgoing edge connected with xorpaost,a for each a ∈ x
where x = ∅.
– xorpare,a (a ∈ A, x ∈ prea(a), a ∈ x) by Lemma 2 has exactly one
incoming edge connected with xorpaost,a and it has an outgoing edge connected with
andpare,x for each x ∈ {x ∈ prea(a) | a ∈ x} where {x ∈ prea(a) | a ∈ x} =
∅.
– xorpaost,a (a ∈ A, x ∈ posta(a), a ∈ x) by Lemma 2 has exactly one
outgoing edge connected with xorpare,a and it has an incoming edge connected with
andpaost,x for each x ∈ {x ∈ posta(a) | a ∈ x} where {x ∈ posta(a) | a ∈
x} = ∅.</p>
        <p>
          As it can be seen in the example, the EPC generated by the folding algorithm
represents all the direct dependencies and respects all the independencies given by the
specified LPOs. Therefore, it nicely represents the behavior given by the LPOs. In particular,
it allows the execution of the specified LPOs according to Definition 6. We formally
prove this interesting result in the following lemma. The result means that scenarios
which are explicitly specified by a user are allowed by the generated EPC. This is an
important and reasonable feature, e.g. in our example all three LPOs from Figure 2 are
executable w.r.t. the constructed EPC from Figure 5. Nevertheless, many simplified
algorithms for model construction, e.g. from the area of process mining [
          <xref ref-type="bibr" rid="ref5">5</xref>
          ], do not satisfy
such property.
        </p>
        <p>Lemma 3. Each LPO lpo ∈ L is executable w.r.t. the EPC epc generated by the
previous folding algorithm (according to Definition 6).</p>
        <p>Proof. Given a step sequence σ = A1 . . . An of lpo = (V, &lt;, l) and the corresponding
sequentialisation lpo = (V, &lt; , l) of lpo, we consider the sequence σ of sets of nodes
of epc which is defined as follows:</p>
        <p>Cxor}.
– Finally σ = σ1 . . . σn.
– Given a set Ai = {a1 . . . am} and its corresponding set of vertices Vi = {v1 . . . vm}
⊆ V with l(vj ) = aj , we construct a sequence σi of sets of nodes of epc having
– tFhoer fporremd(σvij )==σia{1a,p1r.e.σ.iaa2p,p}rwe.e.d.eσfiianme,pσriaejA,pirσeia=1,p{oxstoσriapa2rj,ep,oaskt |. .1. ≤σiakm,≤pospt,. xorparje,ak
∈ Cxor}{andpare,pred(vj) | andpare,pred(vj) ∈ Cand}{xorparje | xorparje ∈ Cxor}.</p>
        <p>j j
– For sujcc(vj ) = {a1 . . .jas} we define σiaj,post = {xorpaojst | xorpaojst ∈ Cxor}
{andpaost,succ(vj) | andpaost,succ(vj) ∈ Cand}{xorpaojst,ak | 1 ≤ k ≤ s, xorpaojst,ak ∈
By construction σ = σA. To prove the executability of σ = A1 . . . An, it remains to
show that σ = σ1 . . . σn is executable in the initial marking of epc. We sketch the proof
for this statement in the following.</p>
        <p>– First, we show that σ1 is executable in the initial marking. We have A1 = {ST }
and σ1ST,pre = ∅. By construction ST is executable in the initial marking. Then, we
have to check σ1ST,post. By construction, xorpSoTst is executable after ST . Then, if
|succ(vj )| &gt; 1, we can fire andpSoTst,succ(vj). Afterwards, each xorpSoTst,ak fulfilling
ak ∈ succ(vj ) and |{x ∈ posta(ST ) | ak ∈ x}| &gt; 1 is executable.
– Now, we show that, if σ1 . . . σi−1 is executable in the initial marking, then σi is
eaxsebceuftoarbel,e winethceonfoslildoewr etrhemaerxkeicnugt.aGbiilviteyn oAf iσ=iaj{,pre. First, each xorparje,ak
fulfilla1 . . . am} and Vi = {v1 . . . vm}
ing ak ∈ pred(vj ) and |{x ∈ prea(aj ) | ak ∈ x}| &gt; 1 is executable. The
reason is that we have fired the activity ak corresponding to the vertex v &lt;h vj
with l(v) = ak and, when they exist, the connectors xorpaokst, andpaokst,succ(v) and
xorpaokst,aj within the sequence σ1 . . . σi−1. Moreover, the process folder generated
by xorpaokst,aj is not consumed within the sequence σ1 . . . σi−1 by our
construction. Next, if |pred(vj )| &gt; 1, we can fire andparje,pred(vj). Then, xorparje is
executable. After each σaj,pre, the set Ai is executable. Finally, the executability of
σia1,postσia2,post . . . σiaim,post can be shown analogously as in the last paragraph.
We have proven that each step sequence σ of lpo is executable in the initial marking of
epc and thus lpo is executable.</p>
        <p>The only problem of the folding algorithm is that indirect dependencies within the
LPOs are not represented such that the generated EPC might also allow the execution
of additional LPOs, i.e. additional behavior which has not been specified is possible. In
our example from Figure 5, first the sequence A → G cannot only be repeated twice as
specified by the third LPO, but it can be repeated arbitrarily often. Second, it is possible
to finish the process after any number of repetitions of A → G, in particular F I can
be executed after just one execution of A → G. Third, also the first two scenarios can
still be executed after any number of repetitions of A → G.1 That means, due to the
1 Moreover, to avoid a deadlock, the routing of the XOR-split behind D has to be chosen in
accordance to the routing of the XOR-split behind A.
disregard of indirect dependencies the different specified behaviors can be combined
in a certain way. However, this is not only a problem but can also be seen as a positive
aspect. Typical specifications are incomplete. Thus, a real process often allows for more
behavior than given by a specification. Abstracting from indirect dependencies, as it
is done by the folding algorithm, results in a reasonable completion of the specified
example behavior.</p>
        <p>Finally, it remains to mention that the three stylistic requirements for EPCs
mentioned in Remark 1 can easily be ensured by the folding algorithm. First of all, by
construction the EPC generated by the algorithm contains no cycles of connectors only.
Second, the generated EPC has only one starting and one final event. However, we can
easily add (artificial) events in between the activities to guarantee alternating events
and activities. For instance, we can add an event directly before each activity except of
ST , i.e. events are inserted to the edges incoming to activities. In this way, not only
alternation is ensured but the property that XOR-splits must not proceed events is also
preserved. In our example, this approach yields the EPC shown in Figure 1 which now
fulfills all the typical syntactic requirements for EPCs.
4</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Conclusion</title>
      <p>We have presented a folding algorithm to generate a process model in the form of an
EPC from example scenarios given by a set of LPOs. The presented algorithm is very
efficient, more precisely it runs in linear time. It generates an intuitive model by
representing all the direct dependencies specified by the LPOs. We have formally proven that
the generated EPC allows the execution of all the specified LPOs. Moreover, it usually
overapproximates the specification, i.e. additional scenarios which are “similar” to the
specified scenarios are possible which is reasonable due to incomplete specifications.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Desel</surname>
          </string-name>
          , J.:
          <article-title>From Human Knowledge to Process Models</article-title>
          .
          <source>In: UNISCON</source>
          <year>2008</year>
          , LNBIP 5, Springer (
          <year>2008</year>
          )
          <fpage>84</fpage>
          -
          <lpage>95</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Bergenthum</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Desel</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mauser</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lorenz</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          :
          <article-title>Construction of Process Models from Example Runs</article-title>
          . In:
          <string-name>
            <surname>ToPNoC</surname>
            <given-names>II</given-names>
          </string-name>
          , LNCS 5460, Springer (
          <year>2009</year>
          )
          <fpage>243</fpage>
          -
          <lpage>259</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3. Scheer: IDS Scheer:
          <article-title>ARIS Process Performance Manager</article-title>
          . http://www.ids-scheer.com.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Dongen</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Aalst</surname>
          </string-name>
          , W.:
          <string-name>
            <surname>Multi-Phase Process</surname>
          </string-name>
          Mining:
          <article-title>Aggregating Instance Graphs into EPC's and Petri Nets</article-title>
          . In: 2nd Workshop on Applications of Petri Nets to Coordination, Workflow and Business Process Management,
          <source>Petri Nets</source>
          <year>2005</year>
          ,
          <string-name>
            <surname>Miami</surname>
          </string-name>
          (
          <year>2005</year>
          )
          <fpage>35</fpage>
          -
          <lpage>58</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>van der Aalst</surname>
            ,
            <given-names>W.M.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Weijters</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Maruster</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>Workflow Mining: Discovering Process Models from Event Logs</article-title>
          .
          <source>IEEE Trans. Knowl. Data Eng</source>
          .
          <volume>16</volume>
          (
          <issue>9</issue>
          ) (
          <year>2004</year>
          )
          <fpage>1128</fpage>
          -
          <lpage>1142</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Smith</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          :
          <article-title>Zur Bedeutung der Concurrency-Theorie fu¨r den Aufbau hochverteilter Systeme</article-title>
          .
          <source>PhD thesis</source>
          , Universita¨t
          <string-name>
            <surname>Hamburg</surname>
          </string-name>
          (
          <year>1989</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>van der Aalst</surname>
            ,
            <given-names>W.M.P.</given-names>
          </string-name>
          :
          <article-title>Formalization and Verification of Event-driven Process Chains</article-title>
          .
          <source>Information &amp; Software Technology</source>
          <volume>41</volume>
          (
          <issue>10</issue>
          ) (
          <year>1999</year>
          )
          <fpage>639</fpage>
          -
          <lpage>650</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Kindler</surname>
          </string-name>
          , E.:
          <article-title>On the Semantics of EPCs: A Framework for Resolving the Vicious Circle</article-title>
          .
          <source>In: BPM</source>
          <year>2004</year>
          , LNCS 3080, Springer (
          <year>2004</year>
          )
          <fpage>82</fpage>
          -
          <lpage>97</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Kiehn</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>On the Interrelation Between Synchronized and Non-Synchronized Behaviour of Petri Nets</article-title>
          .
          <source>Elektronische Informationsverarbeitung und Kybernetik</source>
          <volume>24</volume>
          (
          <issue>1</issue>
          /2) (
          <year>1988</year>
          )
          <fpage>3</fpage>
          -
          <lpage>18</lpage>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>