This page is intended to help you install and use the
Platform Independent Petri Net Editor (PIPE),
an open source Java&XSLT based Petri net editor and analyzer created by
MSc students at the Imperial College of London.
Download the latest version from the SourceForge site for PIPE (Australians can directly use this downloading mirror site in Sydney). Then unzip the file. This will create a directory named "Pipe". In this directory, the file "readme.txt" will tell you how to run the tool (Mac users can just double click on "bin/RunGui.class"). The documentation is in "bin/Docs/index.htm" (or Resources/Docs/index.htm) and is also accessible via the rightmost menu button in the tool. In the Drawing mode (i.e. the initial mode), the Select mode/button also permits node dragging. There is no Copy/Paste nor Undo functions.
To re-use Petri net examples, use the menu option "File - Example nets"
(or "File - Open" and select a file in the directory "Resources/Example nets").
Animations can be done be directed and step-by-step or, for a real "animation",
a given number of transitions can be randomly fired.
Use the "Save" or "Save As" buttons regularly when you have begun creating or
updating a Petri net because a bug might prevent you to save after some
sequences of modifications.
Petri nets are saved in the XML Petri net standard (PNML). The home page of PIPE
states that "PIPE adheres to the latest PNML" but currently PIPE does not seem to
permit the drawing of hierarchical nets (embedded nets) nor the storage/organization
of Petri nets into modules.
As with all softwares but especially prototype softwares like PIPE, save your
work regularly (e.g. everytime you enter a new transition) and also use different
file names from time to time (e.g. because sometimes, PIPE refuses to save and
display a "Null pointer" error message; the 'Save' function might also not work
for big Petri nets while the 'Save as' function keep working).
To be safe, if PIPE gives you an error message when you enter something (transition,
place or arc), do NOT go ahead and save but stop and reload the last version and
re-enter you last modifications; otherwise, you might save a corrupted version and
have problems later (e.g. when loading that corrupted version).
It is also not a good idea to put spaces into the file names when you save:
spaces are commonly used as separators between "tokens" in information technology,
so for many treatments, catering for spaces within file names often makes things
more difficult or ugly for the programmer and the end user.
PNML is a textual notation but is hardly readable (see the files in the
directory "Resources/Example nets"). A more concise and readable textual notation
is handy because graphical forms
(i) require a tool to be entered or visualized,
(ii) are time-consuming to enter,
(iii) need to be transformed into images before exchanging them via email or
including them into documents, (iv) take a lot of space on a screen and hence
are difficult to compare visually, (v) cannot be handled via text management
tools, e.g. their parts cannot be searched and copy/pasted in a text editor or a
Web browser. Because I have not found such concise and readable textual notation,
I invented one, named it PNLF (for "Petri Net Linear Form") and used it below
and in other documents (hence,
do not expect PIPE or other tools to read this notation in the near future; it is
just a support for communication between you and me, e.g. if you have troubles
with the softwares).
Note: The Conceptual Graph
Linear Form -- with which I have worked for many years (if you are
curious, see for example
this document about
translations between various logical notations) -- was my inspiration for the
syntax of PNLF but the semantics of PNLF is quite different from the semantics of CGLF.
PNLF
has now been used by some other persons/organizations.
Woflan is a workflow verification tool. (If you have "administrator" privileges, it is automatically installed in the Windows system's "Programs and files" directory so you may not easily find it by browsing but you may execute it by entering the name "Woflan" in a "Run" command). Currently, four input formats can be used: those of Woflan (file extension: .tpn), Staffware (file extension: .xfr) and COSA Workflow (file extension: .scr). Unfortunately, the downloadable version of Woflan (i.e. 2.3) does not yet import from PNML (if an xml file is given as input, the translator xml2tpn is called but this translator is not present in the 2.3 version). A PNML to Woflan translator is available online. However, the PNML subset accepted by this translator is different from the PNML subset used by PIPE (the first subset is called EPNML, the second is an early version of PNML or PNK (Petri Net Kernel) which is also often used as reference). To bridge the two, I created an on-line converter from PIPE's PNML to Woflan's PNML which translates "value" tags into "text" tags, removes spaces within names of transitions/places, and removes various graphic-related elements. Click here if you want to access a Woflan's PNML checker. For details about PNML, click here or here.
The following exercises are from the prescribed textbook "Workflow Management: Models, Methods and Systems" (by Wil van der Aalst and Kees Max van Hee).
Table of Contents
Below, a PNLF representation of the solution of this exercise (which is given p 310 of the book) is followed by the image of its modelling with PIPE. Compare the two representations.
In PNLF, a Petri net in the linear/textual form is composed of one of several
statements separated by semi-colons (the last statement ends by a dot).
Places are enclosed within parenthesis and transitions within square brackets.
Each token is represented by "@". Coreference variables (e.g. *r and *ry below) are
used for connecting various occurrences of a same place or transition.
Commas are used for separating different branches of the graph.
Given the following graphical form (which is nearly identical to the one given in
the book), the textual representation does not seem particularly helpful but you
will see in a later document (disclosed Week 8) that the linear form is very
helpful to present and comment the graphical representations of these models in the
IBM WebSphere Business Integration Workbench. See also the last section of this document.
Also note that PIPE can only permit it user to represent implicit AND/OR splits, not explicit AND/OR splits. The page 59 of the book shows the mapping between the two forms (and page 56 explains why using an implicit OR split is sometimes adequate when using an explicit OR split is not). Thus, to represent an OR-split in PIPE, use a place and connect it to two (or more) transitions (the simulation in PIPE works, it just randomly selects one transition). To represent an AND-split, connect a transition to two (or more) places.
[red_yellow *ry] //in PNLF, for readability reasons, all the outputs of
// a node should rather be presented together;
{ <-(c1 *c1 @), // some inputs may also be given
->(red *r @) { ->[*ry], ->[yellow_green *yg] }, //OR-split
->(yellow *y) { ->[*yg], ->[yellow_red *yr] } //OR-split
}; //all the outputs of an OR-split should be presented together
[*yg] //in PNLF, when a variable is re-used, the node type is not given again;
//different nodes can have a same type but a variable is unique to a node
{ //"<-(*r)," not represented here since already represented above
->(*y)->[*yr] { ->(*c1), ->(*r) },
->(green *g)->[green_yellow] { ->(*y), ->(c2)->[*yr] }
}; //note how paths are explored/presented as soon as readability permits it
// (the arcs from/to *yr could have been presented later but this would
// have made the mental synthesis/checking of the graph more difficult)
Note the above layout with the transitions (the black rectangles) below one another.
Such a "vertical layout" makes graphics simpler to understand and gives you plenty of
space: it permits you not to use abbreviations for names (which is rarely a good idea),
nor to overlap names (overlaps force the reader to guess the names, or if she can, move
the nodes to read the names), nor to use too many arcs with several breakpoints (use
direct/simple arcs whenever possible). You should develop your graphs vertically,
NOT horizontally (and hence horizontal scrolling in PIPE is NOT to be used). An HTML
file that includes (without size specifications) a PNG image of your graph (generated
via PIPE's export feature) must be printable on a vertical A4 sheet of paper (landscape
printing is forbidden).
Although places named c1, c2, ... are used in the PNLF representations above and
below because these are the names used in the solutions in the book,
YOU SHOULD NOT USE abbreviations such as c1, c2..., P1, P2, ..., T1, T2, ...,
even with a legend (within an annotation) giving the full names of the places and
transitions. Indeed, this makes the graphics and the results of the analysis
EXTREMELY hard/long to understand and check (by people), and hence are also
inappropriate to support communication between people (using such abbreviations
is nearly as inappropriate as writing in a foreign language and giving a reference
to a translation dictionary for this language). The book may use such abbreviations
either because actual names do not really matter for certain exercices (any symbol
will do), or because it has space constraints.
In your case, intuitive names matter and you have space (e.g. by using modules and
the above cited layout).
This model contains "implicit OR-splits" (p59 in the book): in the linear form, see the strings "){" (for the OR-split after "c6", the "yes" and "no" cases actually form an explicit representation).
(begin @)->[A *a]{->(c1)->[B *b]->(c4)->[F *f]->(end),
->(c2)->[C *c]->(c5)->[*f],
->(c3)->[D *d]->(c6){yes->[E *e]->(c7 *c7),
no->[skip_E]->(*c7)->[*f]}
};
[*a]->(c8){ ->[*d], <-[*e], ->[*b], <-[*b], ->[*c], <-[*c], ->[*f] }.
(busy1 *b1 @)->[clear_track]->(free1)->[claim_track]->(claimed1)->[use_track]->(*b1).
The solution given in the book seems to miss an arc from the place "f4" to a transition "claim_track". I have added it here.
(busy1 @
*b1){ <-[claim_track *ct2]<-(free2 *f2 @), ->[*ct2]->(c2)->[transfer *t12],
->[*t12]{ ->(free1 *f1), ->(busy2 *b2) };
(*b2){ <-[claim_track *ct3]<-(free3 *f3), ->[*ct3]->(c3)->[transfer *t23],
->[*t23]{ ->(*f2), ->(busy3 *b3 @) };
(*b3){ <-[claim_track *ct4]<-(free4 *f4 @), ->[*ct4]->(c4)->[transfer *t34],
->[*t34]{ ->(*f3), ->(busy4 *b4) };
(*b4){ <-[claim_track *ct1]<-(*f1), ->[*ct1]->(c1)->[transfer *t41],
->[*t41]{ ->(*f4), ->(*b1) }.
If you have a problem and want to describe a Petri net or a simulation to me,
do not hesitate to use PNLF. For example, here are three steps in a simulation of
a basic Petri net ('@' representing the token, as in my examples):
step 1: (p1 *p1 @)->[tr1]->(p2)->[tr2]->[*p1].
step 2: (p1 *p1)->[tr1]->(p2 @)->[tr2]->[*p1].
step 3: (p1 *p1)->[tr1]->(p2)->[tr2]->[*p1 @].
Regarding transition "triggers" (p63 of the book), PIPE does not permit
to represent them directly/explicitely but you can use an extra input place to
model them anyway (p64 of the book).
In PNLF you can represent triggers directly as in:
(p1 @)->[tr1 "time signal"]->(p2).
Use "time signal" or "resource initiative" or "external event" or
anything else you think is more precise (just use double quotes
around).
PIPE permits a restricted representation of time in the transitions
(see "rate" and "enable timing" when you right-click on a transition)
but I have not seen differences in the simulations.
You can represent time in PNLF as follow:
[transition_name 18sec].
With PNLF, for other precisions that you would like to include in a
transition or a place, simply use some new syntactic element (e.g.
use single quotes or $ or %, ...) and tell me within a C/Java comment
what your new syntactic element means.
/* This is an example of a C/Java comment */
OR-splits are useful for representing outcomes of decision tasks. For example, consider the following alternative representations:
[review_of_schedule]->(change_required?) { yes->[make_changes],
no->[send_copy]
}.
(client_contacted)
{ ->[positive_review_of_schedule]->(change_required),
->[negative_review_of_schedule]->(change_not_required)
}.
In PIPE, "yes" and "no" are not represented (as illustrated in above
for the exercise 2.2). The second representation does not seem elegant
(and only one token must be in "(client_contacted)" for the OR-split to
happen). It also implies that selection rules have to be associated to
each of the alternative tasks and hence the tasks themselves are
empty (they perform no action and thus cannot be decomposed).
The first representation is also better because it is closer to
how it would
be represented in Websphere:
[review_of_schedule_by_client]->< change_required? >
{ yes->(change_required)->[make_changes],
no->(change_not_required)->[send_copy_to_FD]
}.
To conclude, use the first representation and do not forget to put the
question mark at the end of the name of the place that is the origin of
the OR-split. It is not necessary to put "OR" within an annotation near
the place.
Note the naming conventions used in transitions and places:
- for transitions: verb (or nominal for a process) + object
(+ subject if it is not the system,
e.g. "review_of_schedule_by_client");
- for places: nominal expression, e.g. "schedule_reviewed_by_client".