<!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>Generating Benchmarks by Random Stepwise Refinement of Petri Nets</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Kees M. van Hee</string-name>
          <email>k.m.v.hee@tue.nl</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Zheng Liu</string-name>
          <email>z.liu3@tue.nl</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Department of Mathematics and Computer Science Eindhoven University of Technology P.</institution>
          <addr-line>O. Box 513, 5600 MB Eindhoven</addr-line>
          ,
          <country country="NL">The Netherlands</country>
        </aff>
      </contrib-group>
      <fpage>403</fpage>
      <lpage>417</lpage>
      <abstract>
        <p>The quality of algorithms is often determined by benchmarking, i.e., testing the algorithm on a predetermined data set. In contrast to traditional benchmarking, with fixed data set, we present a way to generate random sets of test data. In this paper we present random classes of Petri nets and a method to generate finite samples from such a class. The classes may contain infinitely many Petri nets, each net with its own probability to be generated. This generation method is based on stepwise application of construction rules such as refinement rules. Each random class of Petri nets has a probability distribution for each of its characteristics. We illustrate the approach by estimating this distribution for some simple characteristics.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        In computer science research we often lack a method to evaluate the quality of
an algorithm in an analytical way. The quality may concern the efficiency of the
algorithm (how fast is a solution found) or the effectiveness (how good is the
solution found). Although it is sometimes possible to give bounds for the worst
case behavior, it is seldom possible to determine the average-case behavior
analytically. What we normally do is fixing a set of test data as benchmark and
then we test the algorithm on that set, which is called benchmarking. Generally
a benchmark is either pre-defined or generated. Both have disadvantages [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ].
Pre-defined datasets are designed to be representative examples in a
particular domain. Researchers evaluate new algorithms with respect to such a fixed
benchmark, but how good are they if applied to other test data? In order to
increase the quality of benchmarking we will consider methods to generate random
benchmarks, which are samples from an infinite set of tests, each having its own
probability of being selected for a sample. Note that it is impossible to have an
infinite set of tests each having the same probability, so the probabilities of the
tests have to be non-uniform. Due to the fast increasing computing power we
are able to generate samples that are so big that all non-selected tests together
have a probability below some chosen bound. This allows us to obtain statistical
statements of the quality of an algorithm.
      </p>
      <p>
        In this paper we focus on Petri nets and algorithms to compute their
characteristic properties. Hence we define random classes of Petri nets. Such a class
contains Petri nets with some structural property, like free choice nets. There
may be infinite number of nets in one class. Each net in a class has its own
probability of being selected for a benchmark. Petri nets are used to model
complex processes [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ], for example computational processes in a computer
system or business processes within or between enterprises. These models are often
produced by a stepwise refinement process (top-down approach) or by gluing
together existing components (bottom-up approach). The generation method uses
two kinds of construction rules, refinement rules and bridge rules. The
refinement rules were firstly studied by Berthelot in [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] and Murata in [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ] as reduction
rules, in this paper we use them in the inverse direction to expand Petri nets
by refinement. The bridge rules connect a pair of nodes in a Petri net, so we
can use them to glue components. In most cases these construction rules
preserve some property which means that if the initial Petri net has that property,
then all elements of the class have the same property. The generation method
determines, in a random way, (1) which construction rule will be applied in the
current Petri net, (2) to which part of the net and (3)if we continue or stop. So
the construction rules have weights. Rephrasing what we are doing, we define a
graph grammar with weights on the construction rules, such that each graph of
the graph language has a certain probability of occurring.
      </p>
      <p>
        Although our generation method for benchmarks can be applied to all kinds
of algorithms on Petri nets, we use it here to determine characteristics of the
random classes of Petri nets. Simple examples of such characteristics are the
number of nodes, and the average fanin and fanout of nodes. More complicated
ones are the occurrence (or the number) of deadlocks or livelocks. Each
characteristic of a Petri net is expressed by a real number. In some cases we consider
only 0 and 1 and we consider them as ’false’ and ’true’. Since every Petri net in a
class has a certain probability of being selected in a benchmark, we may consider
every characteristic as a random variable having a probability distribution over
the class. For the given examples, we can speak of the expectation and variance
of the number of nodes in a class, or the probability of having a deadlock. We
have developed a software tool in the form of a plugin for ProM (cf [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ]) to
realize our approach.
      </p>
      <p>The rest of this paper is organized as follows. Section 2 introduces the
necessary preliminaries. In Section 3 we represent our construction rules and discuss
our methodology of generating Petri nets. Section 4 presents some
characteristics. The software tool is introduced in Section 5 with characteristic examples.
Related work is discussed in Section 6. Finally Section 7 concludes this paper
and discusses some of our future researches on identifying class parameters.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Preliminaries</title>
      <p>Let S be a set. With |S| we denote the number of elements in S. The empty set,
e.g., the set without any elements is denoted by ∅. Two sets S and R are disjoint</p>
      <sec id="sec-2-1">
        <title>Petri Nets &amp; Concurrency { 405</title>
        <p>if S ∩ R = ∅. We denote the set of all natural numbers as N = {0, 1, 2, · · ·}. A
sequence σ of length l ∈ N over S is a function σ : {1, · · ·, l} → S. We denote a
sequence by σ =&lt; σ(1), σ(2), ···, σ(l) &gt;, such that ∀i(1 ≤ i &lt; l) : σ(i) ∈ •σ(i+1).</p>
        <p>σ
We write here this as n1 −→ nl. We denote the length of a sequence by |σ|. The
set of all finite sequences over S is denoted as Σ. Let ν, γ ∈ Σ be two sequences.
Concatenation, denoted by σ = ν ◦ γ, is defined as σ : {1, · · ·, |ν| + |γ|} → S, such
that for 1 ≤ i ≤ |ν| : σ(i) = ν(i), and for |ν| + 1 ≤ i ≤ |ν| + |γ| : σ(i) = γ(i − |ν|).
The Parikh vector of a sequence σ, denoted by →−σ, is a bag representing the
number of occurrences of each element in σ. A bag m (multiset) over S is a
function m : S → N. For s ∈ S, m(s) denotes the number of occurrences of s in
m. We denote a bay by square brackets. e.g., in a bag [a, b2, c], element a occurs
once, element b twice, and element c once. All other elements have a multiplicity
of 0. ≺ is the prefix operator, such that σ0 ≺ σ if and only if ∃σ00 : σ = σ0 ◦ σ00 .</p>
        <p>A Petri net is a tuple N = (P, T, F ) where P is the set of places, T is the
set of transitions, P and T are disjoint, and F ⊆ (P × T ) ∪ (T × P ) is the set of
arcs. An element of P ∪ T is called a node. We call an element of P ∪ T ∪ F is
an element of N . A path in N is a sequence σ over the set P ∪ T . Graphically,
we denote places by circles, transitions by squares, and arcs as arrows between
places and transitions. The state of a Petri net, called a marking is a bag over
the places P of N . A marking is graphically represented by placing tokens in
each place. A marked Petri net is a pair (N, m0), where N is a Petri net and
m0 is a marking of N . A transition t ∈ T is enabled in (N, m0), denoted by
t
(N : m0 →−) if •t ≤ m0. An enabled transition in (N, m0) can fire resulting in a
t
new marking m0 = m0 − •t + t•, denoted by (N : m0 →− m0 ).</p>
        <p>A special class of Petri nets are workflow nets. A workflow net is a 5-tuple
W = (P, T, F, i, f ) where (P, T, F ) is a Petri net, i ∈ P is the initial place, such
that •i = ∅, f ∈ P is the final place, such that f • = ∅, in graph of W each node
n ∈ P ∪ T is on a directed path from i to f . If for a workflow net W , we have
∀p ∈ P \ {i, f }, |p • | = | • p| = 1, |i • | = | • f | = 1, the workflow net is a T-net,
also called a marked graph workflow net. If ∀t ∈ T, |t • | = | • t| = 1, then it is
a S-net, also called a state machine workflow net. In a workflow net, two places
p, s ∈ P , if either p• = s• or p • ∩s• = ∅, then this workflow net is a free-choice
workflow net. A firing sequence or a trace is a sequence σ over T such that all
the transitions of σ can fire in that order starting from the initial marking. A
trace for a workflow net is complete if it leads to the final marking with only f
marked.</p>
        <p>
          A workflow net is k sound, for k ∈ N if for each marking m that is reachable
from an initial marking m0 with only k tokens in the initial place i, the final
marking with only k tokens in the final place f can be reached. A workflow net
is generalized sound if it is k-sound for all k ≥ 1 ([
          <xref ref-type="bibr" rid="ref14">14</xref>
          ]). Note that 1-sound is
usually called sound ([
          <xref ref-type="bibr" rid="ref1">1</xref>
          ]). Soundness can be considered as a general sanity check
for workflow nets.
        </p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Net Generation</title>
      <p>In this section we firstly define the construction rules. The rules enable us to
generate all Petri nets, here we focus upon workflow nets. Moreover, we show that
different subclasses of workflow nets can be generated by different construction
rules. Finally, we discuss our method of randomly generating Petri nets.
3.1</p>
      <sec id="sec-3-1">
        <title>Construction Rules</title>
        <p>
          Based upon how they can modify the structure of Petri nets, the construction
rules are divided into two classes, refinement rules and bridge rules. The
refinement rules ([
          <xref ref-type="bibr" rid="ref5">5</xref>
          ], [
          <xref ref-type="bibr" rid="ref8">8</xref>
          ], [
          <xref ref-type="bibr" rid="ref12">12</xref>
          ], and [
          <xref ref-type="bibr" rid="ref18">18</xref>
          ]) were firstly studied by Berthelot and Murata
as abstraction rules to reduce Petri nets, here we use them in the inverse
direction to expand Petri nets. The bridge rules connect a pair of nodes in Petri nets,
so we can use them to glue components. Let N be the original net and R be one
of the construction rules. If we apply R to N then we get the generated net N 0 .
If we use R in the opposite direction, then we can get N again by reducing N 0 .
In such a case we say (N, N 0 ) ∈ ϕR. Based upon such a relationship, we define
the rules as follows.
        </p>
        <p>Refinement rules. Figure 1 is an example of the refinement rules.
Definition 1 (Place refinement rule R1). Let N = (P, T, F ) and N 0 =
(P 0 , T 0 , F 0 ) be two Petri nets. We say (N, N 0 ) ∈ ϕR1 if and only if there exist
places s, r ∈ P 0 , s 6= r and a transition t ∈ T 0 such that: •t = {s}, t• = {r},
s• = {t}, •s 6= ∅, •s 6⊆ •r. The net N satisfies: P = P 0 \ {s}, T = T 0 \ {t},
F = (F 0 ∩ ((P × T ) ∪ (T × P ))) ∪ (•s × t•).</p>
        <sec id="sec-3-1-1">
          <title>Petri Nets &amp; Concurrency { 407</title>
          <p>Definition 2 (Transition refinement rule R2). Let N = (P, T, F ) and N 0 =
(P 0 , T 0 , F 0 ) be two Petri nets. We say (N, N 0 ) ∈ ϕR2 if and only if there exist
a place s ∈ P 0 and transitions t, u ∈ T 0 , t 6= u such that: •s = {u}, s• = {t},
•t = {s}, t• =6 ∅, u• 6⊆ t•. The net N satisfies: P = P 0 \ {s}, T = T 0 \ {u},
F = (F 0 ∩ ((P × T ) ∪ (T × P ))) ∪ (•u × s•).</p>
          <p>Definition 3 (Arc refinement rule R3). Let N = (P, T, F ) and N 0 =
(P 0 , T 0 , F 0 ) be two Petri nets. We say (N, N 0 ) ∈ ϕR3 if and only if there
exist two nodes m, n ∈ P 0 ∪ T 0., TsuhcehntehtaNt: s|a•timsfi|es=: P1,∪mT•==(P{0n∪},T |n)\•{|m=,n1},,
•n = {m}, (•m × n•) ∩ F 0 = ∅ 0
F = (F 0 ∩ ((P × T ) ∪ (T × P ))) ∪ (•m × n•).</p>
          <p>Note that in Figure 1, R3 shows only one instance of the arc refinement rule.
We can also refine any arc with a place as its source node and a transition as its
target node. This case is not shown in Fig 1.</p>
          <p>Definition 4 (Place duplication rule R4). Let N = (P, T, F ) and N 0 =
(P 0 , T 0 , F 0 ) be two Petri nets. We say (N, N 0 ) ∈ ϕR4 if and only if there exist
tPwo= pPlac\es{ss},,rT∈=PT0 ,0 s, F6==r Fsuc∩h (t(hPat×: •T ) ∪ (T × P )).</p>
          <p>s = •r, s• = r•. The net N satisfies:
0 0
Definition 5 (Transition duplication rule R5). Let N = (P, T, F ) and
N 0 = (P 0 , T 0 , F 0 ) be two Petri nets. We say (N, N 0 ) ∈ ϕR5 if and only if there
exist two transitions t, u ∈ T 0 , t 6= u such that: •t = •u, t• = u•. The net
P = P 0 , T = T 0 \ {u}, F = F 0 ∩ ((P × T ) ∪ (T × P )).</p>
          <p>Definition 6 (Loop addition rule R6). Let N = (P, T, F ) and N 0 = (P 0 , T 0 , F 0 )
be two Petri nets. We say (N, N 0 ) ∈ ϕR6 if and only if there exists a place s ∈ P 0
and a transition t ∈ T 0 such that: •t = {s}, t• = {s}. The net N satisfies:
P = P 0 , T = T 0 \ {t}, F = F 0 ∩ ((P × T ) ∪ (T × P )).</p>
          <p>Bridge rules. Figure 2 is an example of the bridge rules.</p>
          <p>Definition 7 (Place bridge rule R7). Let N = (P, T, F ) and N 0 = (P 0 , T 0 , F 0 )
be two Petri nets. We say (N, N 0 ) ∈ ϕR7 if and only if there exist one place
satisfie0sa:nPd =twPo 0tr\a{nss}it,ioTns=uT, t0,∈FT=0 sFu0c∩h (t(hPat:×•Ts)=∪{(uT}×,sP )).
s ∈ P • = {t}. The net N
Definition 8 (Transition bridge rule R8). Let N = (P, T, F ) and N 0 =
(P 0 , T 0 , F 0 ) be two Petri nets. We say (N, N 0 ) ∈ ϕR8 if and only if there exist
one transition t ∈ T 0 and two places s, r ∈ P 0 such that: •t = {s}, t• = {r}.
The net N satisfies: P = P 0 , T = T 0 \ {t}, F = F 0 ∩ ((P × T ) ∪ (T × P )).
Definition 9 (Arc bridge rule R9). Let N = (P, T, F ) and N 0 = (P 0 , T 0 , F 0 )
be two Petri nets. We say (N, N 0 ) ∈ ϕR9 if and only if there exist two nodes
s, r ∈ P 0 ∪ T 0 , such that (s, r) ∈ F 0 . The net N satisfies: P = P 0 , T = T 0 ,
F = F 0 \ {(s, r)}.</p>
          <p>Note that in Figure 2, R9 merely shows one instance of the arc bridge rule.
We can also bridge a place and a transition with an arc. This case is not shown
in Figure 2.</p>
          <p>
            In R8, if s and r are the same place, it becomes R6. Thus the loop addition
rule R6 is a special case of the transition bridge rule R8. All the refinement rules
(R1,...,R6) preserve liveness and boundedness properties of Petri nets (with
respect to a given marking) (proofs can be found in [
            <xref ref-type="bibr" rid="ref12">12</xref>
            ]). Although without formal
proof, it is still easy to observe that all the bridge rules (R7,...,R9) generally do
not preserve those properties. In fact, the bridge rules can break any good
structures. For instance, the transition bridge rule can model the goto structure in
programming languages, and the danger of such a structure is discussed in [
            <xref ref-type="bibr" rid="ref9">9</xref>
            ].
3.2
          </p>
        </sec>
      </sec>
      <sec id="sec-3-2">
        <title>Structural Classes of Generated Nets</title>
        <p>
          In this part we study different classes of the generated Petri nets based on their
structures. We focus on workflow nets and their subclasses, namely, Jackson
nets, state machine workflow nets, marked graph workflow nets, and free-choice
workflow nets. These workflow nets without Jackson nets are defined in Section
2, so firstly we define a Jackson net as follows. For a formal description and
analysis of Jackson nets see [
          <xref ref-type="bibr" rid="ref12">12</xref>
          ].
        </p>
        <p>Definition 10 (Jackson net). A Jackson net is a workflow net that can be
generated, from one single place, by applying the rules R1, R2, R4, R5, and R6
recursively. However, only the rule R1 can be applied in the first step, and no
rules can be applied to the initial place and the final place after the first step.</p>
        <sec id="sec-3-2-1">
          <title>Petri Nets &amp; Concurrency { 409</title>
          <p>In order to generate all workflow nets (starting with two places), it is sufficient
to use the arc refinement rule R3 and the bridge rules R7, R8, R9 only. To prove
that, we give the following definition.</p>
          <p>Definition 11 (Copy of a net). Let N be a workflow net. N 0 is a copy of N
if and only if there is a bijection ϕ such that ϕ(P ) = P 0 , ϕ(T ) = T 0 , ϕ(F ) = F 0
and ∀(x, y) ∈ F : ϕ((x, y)) = (ϕ(x), ϕ(y)).</p>
          <p>A path taken from a Petri net defines a new Petri net, so copying a path can
be treated as copying its corresponding Petri net.</p>
          <p>Lemma 1. Given two nodes, m1, m2 ∈ P ∪ T , and a path σ, such that m1 =
σ(1), m2 = σ(|σ|), and ∀i ∈ dom(σ) : →−σ(i) = 1. Then we can copy σ by firstly
applying a bridge rule on (m1, m2) and afterwards repeating the arc refinement
rule.</p>
          <p>Lemma 2. We have a path σ in a Petri net, if there is some node n such that
→−σ(n) &gt; 1, then there is a path σ0 = σ1 ◦ σ3 if and only if σ = σ1 ◦ σ2 ◦ σ3 and
n −σ→2 n.</p>
          <p>Theorem 1. Let N be a workflow net. Then N can be copied into N 0 by only
using the bridge rules and the arc refinement rule, starting with only two places.
Proof. Initially P 0 = {i0 , f 0 }, T 0 = ∅, F 0 = ∅, i0 = ϕ(i), and f 0 = ϕ(f ). We
select an arbitrary node n from N such that n ∈ P ∪ T and n 6∈ P 0 ∪ T 0 . In N ,
from n we find two paths, n1 −σ→1 n and n −σ→2 n2, such that n1, n2 ∈ P 0 ∪ T 0 and
all other nodes on σ1 and σ2 are not in P 0 ∪ T 0 . This is always possible by the
definition of a workflow net. By Lemma 2 we can reduce σ1 and σ2 by removing
all internal loops along the paths.</p>
          <p>Consider case (1): suppose σ1 and σ2 have no common internal nodes, then
we may apply Lemma 1 by adding the path σ1 ◦ σ2 from n1 to n2, and add
n0 = ϕ(n) to the copy.</p>
          <p>Consider case (2): suppose σ1 and σ2 have common internal nodes, e.g.,
∃i, j : σ1(i) = σ2(j) 6= n, then there is a loop. We then look for the first node m
on σ1 which is also on σ2. Then ∃σ3, σ4, σ5, σ6 : n1 −→ m −σ→4σ3n ∧ n −σ→5 m σ−σ6→6 n2
σ3
where σ1 = σ3 ◦ σ4 and σ2 = σ5 ◦ σ6. Now we have found n1 −→ m and m −→ n2,
and σ3 and σ6 have no internal nodes in common as m is the first common node
on σ1. We replace n with m, then we apply Lemma 1 by adding the path σ3 ◦ σ6
from n1 to n2, and we add node m0 = ϕ(m) to the copy.</p>
          <p>In each step, therefore, we add at least one node. We repeat this procedure
until all the nodes of N are copied into N 0 . Finally, we add all arcs F \ ϕ−1(F 0 )
by arc bridge rule. Now N 0 is a copy of N .
tu</p>
          <p>Now let us consider which rules allow us to generate the subclasses of
workflow nets. Based upon Theorem 1, it is easy to prove that we only need the
transition bridge rule and the arc refinement rule to generate all state machine
workflow nets, and we need the place bridge rule and the arc refinement rule to
generate all marked graph workflow nets. They yield Corollary 1 and Corollary
2. As defined in Definition 10, Jackson nets are generated by the rules R1, R2,
R4, R5, and R6. For a free-choice workflow net, the rules R1, R2, R4, and R5
can always preserve its properties.</p>
          <p>Corollary 1. If N is a state machine workflow net, then N can be copied into
N 0 by only using the transition bridge rule with the arc refinement rule.
Corollary 2. If N is a marked graph workflow net, then N can be copied into
N 0 by only using the place bridge rule with the arc refinement rule.
Theorem 2. The place refinement rule, the transition refinement rule, the place
duplication rule, and the transition duplication rule preserve the free-choice
workflow net property.</p>
          <p>
            [
            <xref ref-type="bibr" rid="ref12">12</xref>
            ] proves that each Jackson net is a sound net. From [
            <xref ref-type="bibr" rid="ref6">6</xref>
            ] we can derive
that each generated state machine workflow net is sound as well. All free-choice
workflow nets are sound. The generated marked graph workflow nets cannot be
sound as the rules applied do not preserve the properties.
3.3
          </p>
        </sec>
      </sec>
      <sec id="sec-3-3">
        <title>Generation of Nets</title>
        <p>Our approach of generating Petri nets has two determinants, construction rules
and probabilities of the rules. We have discussed the necessary rules to generate
different classes of workflow nets. In this part, we focus on the probability-based
rule selection.</p>
        <p>Given two nets N and N 0 , we say that N generates N 0 if and only if N 0 can
be obtained from N by applying zero or more times a rule from our construction
rules. To generate a workflow net we adopt a stepwise refinement technique
starting with one single place. In the first step we apply the place refinement
rule to generate the initial place and the final place. For any subsequent steps,
we select a rule from all the rules whose conditions hold (we say those rules are
enabled ). For the initial and the final places there are some restrictions such
that the place refinement rule, the place duplication rule, the loop addition rule
cannot be applied to the initial and the final places, and for the transition bridge
and the arc bridge rules, the initial place cannot be the target place (i.e., r in
Definition 8 and 9), and the final place cannot be the source place (i.e., s in
Definition 8 and 9). Figure 3 depicts an example of net refinement.</p>
        <p>In order to select a rule from all the enabled rules, we attach a rule weight
to each rule. A rule weight is a random number ranging from 0 (least likely)
to 100 (most likely). Therefore, a rule is randomly selected based on the rule
weight. Similarly, we also attach an element weight (also ranging from 0 to 100)
to each of the elements (each of the places, transitions, and arcs) in a net. Hence
each rule can randomly select an element or a pair of them based on the element
weight to expand a net. Because we always start with an initial net to generate
another net, for all the elements in the initial net, we give each of them a default
element weight. When we apply rules, new elements are added into the net. In</p>
        <sec id="sec-3-3-1">
          <title>Petri Nets &amp; Concurrency { 411</title>
          <p>Fig. 3. An Example of Workflow Net Refinement
order to determine weights of the newly added elements, we define three type
parameters (ranging from 0 to 1) for each element type, namely, place parameter,
transition parameter, and arc parameter. Each rule can have some or all of the
type parameters based on what kinds of elements it can introduce. For instance,
as the place refinement rule can introduce two places, a transition, and two arcs,
the rule has all the type parameters. While, the place bridge rule can add a place
and two arcs, so it only has the place parameter and the arc parameter. All the
refinement rules (R1,...,R6) only refine one element, so the weight of the newly
added elements are determined by the multiplication of the weight of the refined
element and the type parameters. For example, if we refine a place having a
weight of 50, and we let the place parameter be 0.2, the transition parameter be
0.5, and the arc parameter be 0.1, then any newly added place has a weight of
(0.2 x 50 =) 10, any newly added transition has a weight of (0.5 x 50 =) 25, and
any newly added arc has a weight of (0.1 x 50 =) 5. On the other hand, all the
bridge rules bridge a pair of nodes, so the weight of the newly added elements
are determined by the multiplication of the sum of the bridged nodes and the
type parameters. For instance, if we bridge two transitions having a weight of
50 and 70, respectively, then any newly added place has a weight of ((50 + 70)
x 0.2 = ) 24, and any newly added arc has a weight of ((50 + 70) x 0.1) = 12.</p>
          <p>Therefore, such a mechanism makes net generation random. We are currently
considering other mechanisms besides this one as well.
4</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Characteristics of Net</title>
      <p>Characteristics of Petri nets in different classes are decidable with the generated
benchmarks. Such characteristics we consider currently consist of length of the
shortest path (number of transitions in a path is the length of this path), number
of nodes, average number of fanin and fanout of nodes, deadlock and livelock,
and coverage. We use a real number to express each characteristic, in some
cases we use 1 for true and 0 for false. Each Petri net in a class has a certain
probability of being selected in a benchmark, and each characteristic can be
considered as a random variable having a probability distribution over that class.
For instance, with the given samples from a class, we can speak of the expectation
and variance of the number of nodes in the class, or the probability of having a
deadlock. Therefore, we can estimate the characteristics of any new nets from the
same class with ceratin confidence. In this section, we focus on the characteristic
coverage and give two examples to illustrate how it can help in testing.</p>
      <p>We restrict ourselves to a Petri net with an initial node such as a workflow
net. Each transition in the net is attached with a label. The goal of the coverage
test is to find all the transitions with a certain label. The coverage is measured
by trace coverage and transition coverage. We start a path with the initial node,
at each choice point we select one of the enabled transitions at random. As soon
as we find a transition with the label that we look for, we stop and start a new
trace from the initial node again. Therefore, the trace coverage is the number of
traces that we need to find all the transitions with the label, and the transition
coverage is the number of transitions fired to find all the transitions with the
label. We show two applications of how to use the coverage in testing.</p>
      <p>Finding labels. We may attach labels to transitions in a workflow net. In this
application we need to find all the transitions with a special label. We start in the
initial state. A transition is randomly fired when there are two or more enabled
transitions. After a transition has fired, we test whether it has the special label.
If so we remove this label and we start a new trace from the initial state again.
Otherwise we continue until we reach the final state and then we start from
the initial state again. We stop if all the transitions with the label have been
found. The coverage returns the number of traces followed and the number of
transitions fired in order to find all the labeled transitions. Algorithm 1 describes
this application. In this algorithm all transitions have a label either 0 or 1. We
are looking for the transitions with label 1.</p>
      <p>
        As labeling can be associated with different concepts, this algorithm can be
used in model-based software testing as done in [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. In this application we use
a workflow net to model a software system, where each transition represents a
software component. A software component either behaves correctly or has an
error that can only be detected by firing the transition. Only transitions with
an error are labeled.
      </p>
      <p>
        Finding causal pairs. In this example we test how long (measured in coverage)
it takes to cover all the causal pairs, i.e., a possible pair of consecutive transitions,
in a workflow net. For process miners, i.e., the alpha algorithm [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], we need
complete logs, i.e., log with a set of complete traces. This means that we need
so many complete traces that every causal pair has occurred. We can get all
the possible causal pairs for a given net by static analysis, i.e., by using the
technique of reachability graph. Equipped with this result, we use Algorithm 2
to get the coverage for each given sound workflow net. This means that we have
Petri Nets &amp; Concurrency { 413
end
      </p>
      <p>Algorithm 1: Finding Labels
input : a sound N = (P, T, F, i, f )
output: pathCoverage, transitionCoverage
an estimate of the length of a log in order to be complete for random classes of
Petri nets.</p>
      <p>Finally, we show the result of an empirical study we did. We used the tool we
developed (see Section 5) to randomly generated 3000 well-structured workflow
nets. Those nets were used as benchmarks to get the results in Table 1.
5</p>
    </sec>
    <sec id="sec-5">
      <title>Tool Implementation</title>
      <p>
        We realized a supporting tool for our methodology. The tool is developed as a
plugin for the ProM framework [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ] in Java, the distribution can be downloaded
from [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ]. The tool has the following relevant features:
      </p>
      <p>Graphical user interface. Figure 4 is a snapshot of the tool interface.This
graphical user interface is easy to use. For example, it lists all the rules visually
so that it is very intuitive for the user to select a particular rule. The generated
nets can be visualized using the viewer provided by ProM. Testing results are
output in a table for the user.</p>
      <p>Selection of net class. The interface contains all the classes of the workflow
nets that the user can generate. Once a particular class has been selected, all the
rules which are not allowed in such a class are disabled automatically by giving
their probabilities a value of zero.
4
5
end</p>
      <p>Algorithm 2: Finding Causal Pairs
input : a sound N = (P, T, F, i, f ), a set C of all the causal pairs in N
output: pathCoverage, transitionCoverage</p>
      <p>Random weight of rules. The user can change the weight of any enabled rule
using the sliding bar under the rule image, the probability of the rule is calculated
and displayed next to the sliding bar.</p>
      <sec id="sec-5-1">
        <title>Petri Nets &amp; Concurrency { 415</title>
        <p>Specification of sample size and net size. The user can specify the number
of nets to generate and the number of times to apply rules to generate a net.
The sizes of all nets have a poisson distribution, the user only needs to input
the average number, then the tool is able to calculate the size of each individual
net.</p>
        <p>Selection of characteristics. The user can select the characteristics introduced
in Section 4 to investigate the nets.</p>
        <p>Reusability of samples. The tool saves all the generated nets in PNML
format in a dedicated folder on disk. This enables the user to reuse or share any
benchmarks.</p>
        <p>
          [
          <xref ref-type="bibr" rid="ref13">13</xref>
          ] proposed a systematic approach to design software in coloured Petri
nets and transfer the CPN models into Java code, we practised the approach in
the design and implementation of this tool. The tool currently runs on a single
processor thus it is not possible to generate a very large size of benchmarks.
In order to overcome this limit, we are considering to distribute the tool over
multiple processors (e.g., over grid) in the future.
In [
          <xref ref-type="bibr" rid="ref4">4</xref>
          ] the authors proposed a method to generate Petri net benchmarks. They
start with a Petri net containing two places and two transitions with all nodes
connecting to each other, and make use of the refinement rules given by Murata
in [
          <xref ref-type="bibr" rid="ref18">18</xref>
          ]. Whereas in our approach we use not only the Murata rules, but other
rules as well, this makes our rules more extensive and more general. We focus
on generating workflow nets, and start with a much simpler net with only one
single place. They use a weighted random selection of rules to control the number
of transitions and places. Such a probability mechanism is also realized in our
approach, and we investigate more characteristics of nets besides the number of
nodes.
        </p>
        <p>
          In [
          <xref ref-type="bibr" rid="ref3">3</xref>
          ] the authors developed a tool to generate process models in Petri nets
and log of business processes. They use a set of workflow patterns in [
          <xref ref-type="bibr" rid="ref17">17</xref>
          ] and add
probabilities to the patterns. In our approach we do this for graph grammars.
Both can get a probability distribution on the set of graphs.
7
        </p>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>Conclusion</title>
      <p>In this paper, we defined a graph grammar with weights on the construction
rules, such that each graph of the graph language has a ceratin probability
of occurring. We consider graphs in the form of Petri nets, and the generated
Petri nets can be used as benchmarks. By extensive studies, we have a set of
construction rules to generate all Petri nets with different starting nets using a
stepwise refinement approach. Based upon structures, the nets can be classified
into different classes. Each Petri net in a class has a certain probability to be
selected in a benchmark. Moreover, we distribute weights to the rules and all
elements in a net, this makes the generation random. We have determined a
number of characteristics used in the random classes of Petri nets, and we are
able to get probability distributions of each characteristic over the classes. We
focused upon an interesting characteristic called coverage, and presented two
possible applications of it. A tool has been developed in ProM to realize our
methodology.</p>
      <p>In future research, we would like to identify the probability parameters based
upon a concrete set of process models in a statistical way. If we have the
parameter we can do better benchmarking. Also we would like to distribute our tool
over grid so that we can generate a large number of benchmarks.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>W. M. P. van der Aalst.</surname>
          </string-name>
          <article-title>The Application of Petri Nets to Workflow Management</article-title>
          .
          <source>The Journal of Circuits, Systems and Computers</source>
          ,
          <volume>8</volume>
          (
          <issue>1</issue>
          ):
          <fpage>21</fpage>
          -
          <lpage>66</lpage>
          ,
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>W.M.P. van der Aalst</surname>
          </string-name>
          , A.
          <string-name>
            <surname>J.M.M. Weijters</surname>
            , and
            <given-names>L.</given-names>
          </string-name>
          <string-name>
            <surname>Maruster</surname>
          </string-name>
          . Workflow Mining:
          <article-title>Discovering Process Models from Event Logs</article-title>
          .
          <source>IEEE Transactions on Knowledge and Data Engineering</source>
          ,
          <volume>16</volume>
          :
          <year>2004</year>
          ,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3. Process Mining Group at University of Padua. Process Log Generator. http://www.processmining.it/sw/plg,
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <given-names>G.</given-names>
            <surname>Bergmann</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Horvath</surname>
          </string-name>
          ,
          <string-name>
            <surname>I. Rath</surname>
          </string-name>
          , and
          <string-name>
            <given-names>D.</given-names>
            <surname>Varro</surname>
          </string-name>
          .
          <article-title>A Benchmark Evaluation of Incremental Pattern Matching in Graph Transformation</article-title>
          .
          <source>In Proceedings of the 4th International Conference on Graph Transformation, ICGT'08</source>
          , pages
          <fpage>396</fpage>
          -
          <lpage>410</lpage>
          , Leicester, UK,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <given-names>G.</given-names>
            <surname>Berthelot</surname>
          </string-name>
          .
          <article-title>Transformations and Decompositions of Nets</article-title>
          . In Lecture Notes in Computer Science:
          <article-title>Advances in Petri Nets 1986 Part I: Petri Nets, central models and their properties</article-title>
          . / W. Brauer,
          <string-name>
            <given-names>W.</given-names>
            <surname>Reisig</surname>
          </string-name>
          , and G. Rozenberg (Eds.), volume
          <volume>254</volume>
          , pages
          <fpage>360</fpage>
          -
          <lpage>376</lpage>
          . Springer Verlag,
          <year>1987</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <given-names>I. Corro</given-names>
            <surname>Ramos</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Di</surname>
          </string-name>
          <string-name>
            <given-names>Bucchianico</given-names>
            , Hakobyan L., and
            <surname>K.M. van Hee</surname>
          </string-name>
          .
          <source>Synthesis and Reduction of State Machine Workflow Nets. Technical report CS 06-18</source>
          , Edinhoven University of Technology,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <given-names>I. Corro</given-names>
            <surname>Ramos</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Di</surname>
          </string-name>
          <string-name>
            <given-names>Bucchianico</given-names>
            , Hakobyan L., and
            <surname>K.M. van Hee</surname>
          </string-name>
          .
          <source>Model Driven Testing Based On Test History. In Transactions on Petri Nets and Other Models of Concurrency I,</source>
          volume
          <volume>1</volume>
          , pages
          <fpage>134</fpage>
          -
          <lpage>151</lpage>
          ,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <given-names>J.</given-names>
            <surname>Desel</surname>
          </string-name>
          .
          <article-title>Reduction and Design of Well-behaved Concurrent Systems</article-title>
          .
          <source>In Proceedings on Theories of concurrency : unification and extension</source>
          ,
          <source>CONCUR '90</source>
          , pages
          <fpage>166</fpage>
          -
          <lpage>181</lpage>
          , New York, NY, USA,
          <year>1990</year>
          . Springer-Verlag New York, Inc.
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <given-names>E. W.</given-names>
            <surname>Dijkstra</surname>
          </string-name>
          . Go To Statement Considered Harmful.
          <source>Communications of the ACM</source>
          ,
          <volume>11</volume>
          (
          <issue>3</issue>
          ):
          <fpage>147</fpage>
          -
          <lpage>148</lpage>
          ,
          <year>March 1968</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>B. F. van Dongen</surname>
          </string-name>
          ,
          <string-name>
            <surname>A. K. A. de Medeiros</surname>
            ,
            <given-names>H. M. W.</given-names>
          </string-name>
          <string-name>
            <surname>Verbeek</surname>
          </string-name>
          ,
          <string-name>
            <surname>A. J. M. M. Weijters</surname>
            , and
            <given-names>W. M. P. van der Aalst.</given-names>
          </string-name>
          <article-title>The ProM Framework: A New Era in Process Mining Tool Support</article-title>
          .
          <source>In Lecture Notes in Computer Science: Applications and Theory of Petri Nets</source>
          <year>2005</year>
          : 26th International Conference, ICATPN 2005,
          <article-title>Miami</article-title>
          , USA, June 20-25,
          <year>2005</year>
          . / Gianfranco Ciardo,
          <source>Philippe Darondeau (Eds.)</source>
          , volume
          <volume>3536</volume>
          , pages
          <fpage>444</fpage>
          -
          <lpage>454</lpage>
          . Springer Verlag, jun
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <given-names>C.</given-names>
            <surname>Girault</surname>
          </string-name>
          and R. Valk, editors.
          <article-title>Petri Nets for System Engineering: A Guide to Modelling, Verification,</article-title>
          and Applications. Springer-Verlag,
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>K. M. van Hee</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          <string-name>
            <surname>Hidders</surname>
            , G. Houben,
            <given-names>J.</given-names>
          </string-name>
          <string-name>
            <surname>Paredaens</surname>
            , and
            <given-names>P.</given-names>
          </string-name>
          <string-name>
            <surname>Thiran</surname>
          </string-name>
          .
          <article-title>On the Relationship between Workflow Models and Document Types</article-title>
          .
          <source>Information Systems</source>
          ,
          <volume>34</volume>
          (
          <issue>1</issue>
          ):
          <fpage>178</fpage>
          -
          <lpage>208</lpage>
          ,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>K. M. van Hee</surname>
            and
            <given-names>Zheng</given-names>
          </string-name>
          <string-name>
            <surname>Liu</surname>
          </string-name>
          .
          <article-title>From Service-Oriented Architecture via Coloured Petri Nets to Java Code</article-title>
          .
          <source>In Proceedings of the Fifth International Workshop on Modellig of Objects, Compomens and Agents, MOCA'09</source>
          , pages
          <fpage>129</fpage>
          -
          <lpage>149</lpage>
          , Hamburg, Germany,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>K. M. van Hee</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          <string-name>
            <surname>Sidorova</surname>
            , and
            <given-names>M.</given-names>
          </string-name>
          <string-name>
            <surname>Voorhoeve</surname>
          </string-name>
          .
          <article-title>Generalised Soundness of Workflow Nets Is Decidable</article-title>
          .
          <source>In Proceedings of the 25th International Conference, ICATPN'04</source>
          , Bologna, Italy,
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <given-names>A.</given-names>
            <surname>Lim</surname>
          </string-name>
          ,
          <string-name>
            <given-names>W. C.</given-names>
            <surname>Oon</surname>
          </string-name>
          , and
          <string-name>
            <given-names>W. B.</given-names>
            <surname>Zhu</surname>
          </string-name>
          .
          <article-title>Towards Definitive Benchmarking of Algorithm Performance</article-title>
          .
          <source>In Proceedings of the 11th European Conference on Information Systems, ECIS</source>
          <year>2003</year>
          , Naples, Italy,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16. Architecture of Information System Group at indhoven University of Technology. Prom Nightly Builds. http://prom.win.tue.nl/tools/prom/nightly/,
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <given-names>N.</given-names>
            <surname>Russell</surname>
          </string-name>
          ,
          <string-name>
            <surname>A. H. M. ter Hofstede</surname>
          </string-name>
          ,
          <string-name>
            <surname>W. M. P. van der Aalst</surname>
            , and
            <given-names>M.</given-names>
          </string-name>
          <string-name>
            <surname>Mulyar</surname>
            . Workflow Controlflow Patterns:
            <given-names>A Revised</given-names>
          </string-name>
          <string-name>
            <surname>View</surname>
          </string-name>
          .
          <source>Technical report</source>
          ,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18. I. Suzuki and
          <string-name>
            <given-names>T.</given-names>
            <surname>Murata</surname>
          </string-name>
          .
          <article-title>A Method for Stepwise Refinement and Abstraction of Petri Nets</article-title>
          .
          <source>Journal of Computer and System Sciences</source>
          ,
          <volume>27</volume>
          (
          <issue>1</issue>
          ):
          <fpage>51</fpage>
          -
          <lpage>76</lpage>
          ,
          <year>1983</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>