Y
A W L
Chapter 2
The Language: Rationale
and Fundamentals
(Part II)
Nick Russell
Arthur ter Hofstede
a university for the
real world
R
© 2009, www.yawlfoundation.org
Y
Outline Part II
Y
• The BPM Landscape
• Conceptual Foundations
– the Workflow Patterns Initiative
• Control-flow patterns
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
2
Business Process Management (BPM)
Y
“Supporting business processes
using methods, techniques, and
software to design, enact, control,
and analyze operational processes
involving humans, organizations,
applications, documents and other
sources of information”
W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske. Business Process
Management: A Survey. In W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske,
editors, International Conference on Business Process Management (BPM 2003),
volume 2678 of Lecture Notes in Computer Science, pages 1–12. Springer-Verlag,
Berlin, 2003.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
3
Setting the scene – BPM: what and why?
Y
• Genesis in the fields of office information systems
and workflow technology
• Support for coordination of humans and
applications in performing business activities
• Explicit representation of control flow and data
dependencies, and resourcing strategies
• Benefits:
– Improved efficiency (time, cost)
– Compliance
– Improved responsiveness
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
4
Evolution of BPM technology
Application
Application
Y
Client Device
Client Device
Client Device
User Interface
User Interface
User Interface
User Interface
User Interface
Application
Application
Application
Application Logic
Application Logic
Application Logic
Application Logic
Service ServiceService
Business Rules
Business Rules
Business Rules
Business Rules
Control Flow
Control Flow
Control Flow
Rules Engine
Business Rules
Data
Workflow
BPMS
Control Flow
Control Flow
Resourcing
Resourcing
Database System Database System Database System Database System
1960s
Data
Data
1970s
1980s
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
Data
1990s
A W L
Data
2000s
5
Gartner top 10 strategic technologies 2008
•
•
•
•
•
•
•
•
•
•
Green IT
Unified communications
Business process modeling
Metadata management
Virtualization 2.0
Mashup & composite apps
Web platform & WOA (software as a service)
Computing fabric
Real world web
Social software
Y





real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
6
BPM tools in active use by practitioners
Y
BPTrends, The State of Business
Process Management 2008
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
7
Scope of BPMS offerings
Y
M. Dumas, W.M.P van der Aalst, A.H.M ter Hofstede, Process-Aware Information Systems: Bridging
People and Software through Process Technology, John Wiley & Sons, 2005
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
8
The BPM lifecycle
Y
diagnosis
Project
Management
Tools
process
design
process
enactment
process
implementation
Business
Process
Modelling
Tools
Workflow
Management
Systems
M. Dumas, W. van der Aalst, A. ter Hofstede, Process-Aware
Information Systems: Bridging People and Software through Process
Technology, John Wiley & Sons, 2005
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
9
Problems in the BPM field
•
•
•
•
•
•
•
•
•
Y
Lack of commonly accepted conceptual foundations
Lack of proper formal foundations (despite the rhetoric …)
No lack of proposed standards …
Tools are typically hard to use, expensive and not easily
integrated
Lack of support for processes that need to change on-thefly
Lack of proper support for exceptions
Limited support for design time analysis (verification and
validation)
Resource perspective does not match real-world needs
Insufficient support for inter-process communication
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
10
Y
Workflow animation
© Wil van der Aalst, Vincent Almering and Herman Wijbenga
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
11
Lack of commonly accepted conceptual
foundations
Y
How do various workflow environments deal with this?
B
A
OR
AND
D
C
• Forbid
• Execute D once, ignore second triggering
• Execute D twice
• Execute D once or twice depending on execution …
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
12
BPMN:
handling of concurrent execution threads
A
real
a university
for the
© 2009,
www.yawlfoundation.org
world
B
R
Y
A W L
Y
C
13
Staffware:
handling of concurrent execution threads
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
14
Workflow Patterns Initiative
Y
• Started in 1999, joint work TU/e and QUT
• Objectives:
– Identification of workflow modelling scenarios and solutions
– Benchmarking
•
•
•
•
Commercial BPM products (MQ/Series Workflow, Staffware, etc)
Open source workflow products (OpenWFE, jBPM, Enhydra Shark)
Proposed standards for web service composition (BPML, BPEL)
Process modelling languages (UML, BPMN)
– Foundation for selecting workflow solutions
• Home Page: www.workflowpatterns.com
• Primary publication:
– W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, A.P. Barros,
“Workflow Patterns”, Distributed and Parallel Databases 14(3):5-51, 2003.
Citations: 1,500+ (Google Scholar); 500+ (Scopus); 300+ (Web of Science)
• Evaluations of commercial offerings, research prototypes, proposed
standards for web service composition, etc
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
15
Workflow Patterns Framework
time
2000
2003
Jun 2005
Resource P:s - 43
Control-flow P:s 20
Oct 2005
Data P:s - 40
W. van der Aalst
A. ter Hofstede
B. Kiepuszewski
A. Barros
N. Russell
W. van der Aalst
A. ter Hofstede
D. Edmond
The ordering of
activities in a
process
Resource definition Data representation
& work distribution and handling in a
in a process
process
CoopIS’2000
DAPD’2003
CAiSE’2005
N. Russell
A. ter Hofstede
D. Edmond
W. van der Aalst
ER’2005
Y
Sep
Jun 2006
2006
revised
Control-flow
Exception P:s
P:s 43
N.
N.Russell
Russell
A.
W.ter
van
Hofstede
der Aalst
W.
A. van
ter Hofstede
der Aalst
N. Mulyar
Exception
handling
- 23 new patterns
in
a process in
- Formalised
CPN notation
TR
CAiSE’2006
These perspectives follow S. Jablonski and C. Bussler’s classification from:
Workflow Management: Modeling Concepts, Architecture, and Implementation. International Thomson Computer Press, 1996
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
16
Workflow Patterns Framework
time
2000
2003
COSA
FLOWer
Eastman
Meteor
Mobile
I-Flow
Staffware
InConcert
Oct 2005
Jun 2005
Resource P:s - 43
Control-flow P:s 20
E
v
a
l
u
a
t
I
o
n
s
Y
Domino Workflow
Visual Workflow
Forte Conductor
MQSeries/Workflow
SAR R/3 Workflow
Verve Workflow
Changengine
XPDL, BPEL4WS, BPML,
WSFL, XLANG, WSCI,
UML AD 1.4 UML AD 2.0, BPMN
Data P:s - 40
Exc
Staffware
WebSphere MQ
FLOWer
COSA
iPlanet
Staffware
MQSeries
FLOWer
COSA
Staf
Web
FLO
COS
iPla
BPEL4WS
UML AD 2.0
BPMN
XPDL, BPEL4WS
UML AD 2.0, BPMN
XPD
BPE
Language Development: YAWL/newYAWL
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
17
Pattern validation: tool evaluation
Y
Identify patterns
Set evaluation
criteria
Select tools to
be assessed
Assess pattern
support
Review findings
with vendors
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
18
Impact of the Workflow Patterns
Y
Systems inspired or directly influenced by the patterns
FLOWer 3.0 of Pallas Athena
Bizagi of Vision Software
Staffware Process Suite
Pectra Technology Inc.’s tool
Lynx Workflow by InsuraPro
Ivolutia Orchestration
OpenWFE (an open source WFMS)
Zebra (an open source WFMS)
Alphaflow (an open source WFMS)
jBPM (a free workflow engine)
Use of the workflow patterns in selecting a WFMS
the Dutch Employee Insurance Administration Office
the Dutch Justice Department
Other
Pattern-based evaluations (e.g. ULTRAflow, OmniFlow, @enterprise, BPMN)
Main patterns papers are all highly cited
Education (used in teaching at 10+ Universities)
Web site: 300+ visits on an average working day
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
19
What is a pattern ?
Y
“Abstraction from
concrete form which
keeps recurring in
specific, non-arbitrary
contexts”
Components
D. Riehle and H. Züllighoven. Understanding and
Using Patterns in Software Development. Theory
and Practice of Object Systems 2(1):3-13, 1996.
In process context:
 Imperative in format
 Not dependent on actual
products/technologies
 Motivated
 Solution-oriented
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
•
•
•
•
•
Description: what is it?
Synonym(s)
Example(s)
Motivation: why needed?
Context: conditions + CPN
formalisation
• Implementation: how typically
realised?
• Issues: what problems can be
encountered?
• Solutions: how and to what
extent can these problems be
overcome?
• Evaluation criteria
A W L
20
Business process perspectives: ARIS (source: A.W. Scheer,
Y
ARIS – Business Process Modelling, Springer, Berlin, Germany, 2000.)
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
21
Business process perspectives: CIMOSA
(source: F.B. Vernadat, Y
Enterprise Modeling and Integration. Chapman and Hall, London, UK, 1996.)
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
22
Business process perspectives: Zachman Framework
(source: J.A. Zachman. A framework for information systems architecture.
IBM Systems Journal, 26(3):276-292, 1987.)
Y
Source:
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
23
Workflow perspectives: control-flow and data
Y
Control-flow perspective
• Focuses on the representation and execution of
processes in terms of tasks and arcs indicating how the
thread of control is passed between them
• Abstracts from the actual implementation of individual
tasks
Data perspective
• Focuses on the representation and utilisation of data in a
process context
• Considers both internal and external data resources and
the interactions between them
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
24
Workflow perspectives: resource
Y
• Focuses on the manner in which work is offered to,
allocated to and managed by process participants
• Considers both the system and resource perspectives
• Assumes the existence of a process model and related
organisational and work distribution models
• Takes into account differing operational paradigms:
–
–
–
–
richness of process model (esp. allocation directives)
autonomy of resources
alternate routing mechanisms
work management facilities
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
25
Control-flow patterns overview
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
26
Classes of control-flow patterns
• Branching Patterns
capture branching scenarios in
processes.
• Concurrency Patterns
reflect situations where
restrictions are imposed on the
extent of concurrent control-flow
in a process instance
• Synchronisation Patterns
describe synchronization
scenarios arising in processes.
• Trigger Patterns
catalogue the different triggering
mechanisms appearing in a
process context.
• Repetition Patterns
describe various ways in which
repetition may be specified.
• Cancellation and Completion
Patterns
categorise the various
cancellation scenarios that may
be relevant for a workflow
specification.
• Multiple Instances (MI) Patterns
delineate situations with
multiple threads of execution in
a workflow which relate to the
same activity.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
• Termination Patterns
address the issue of when the
execution of a workflow is
considered to be finished.
Y
A W L
27
Branching constructs
Y
AND Split
• Parallel split, initiation of parallel threads
OR Split
• Multi-choice, thread of control is passed to one or more
outgoing branches
XOR Split
• Exclusive choice, thread of control is passed to exactly one of
the outgoing branches
• Deferred choice, thread of control is passed to exactly one of
the outgoing branches. Selection decision is deferred to the
user and/or operating environment.
Thread Split
• Thread split, thread of control is split into multiple concurrent
threads in same branch.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
28
Branching patterns
Y
• Parallel split, initiation of parallel threads
• Multi-choice, thread of control is passed to one or
more outgoing branches
• Exclusive choice, thread of control is passed to exactly
one of the outgoing branches
• Deferred choice, thread of control is passed to exactly
one of the outgoing branches. Selection decision is
deferred to the user and/or operating environment.
• Thread split, thread of control is split into multiple
concurrent threads in same branch.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
29
Parallel split
Y
The divergence of a branch
into two or more parallel
branches each of which
execute concurrently.
Definition CPN:
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
30
Multi-choice
Y
The divergence of a branch
into two or more branches
such that when the incoming
branch is enabled, the thread
of control is immediately
passed to one or more of the
outgoing branches based on
a mechanism that selects
one or more outgoing
branches.
Definition CPN:
context condition: choice
construct has access to
all required resources
when making routing
decision
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
31
Multi-choice
Y
• Straightforward when transition conditions are supported (e.g.
MQSeries/Workflow, Verve, Forte Conductor).
• Otherwise:
– and-split followed by xor-splits exhausting all combinations;
– xor-split followed by and-splits (only needed if combination
contains more than one branch) exhausting all combinations.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
32
Multi-choice: Example
Y
(source: [AHKB03] p.14)
x<5
B
y>7
C
A
A
Solution 1:
AND
XOR
x<5 & y>7
XOR x5 & y7
AND
XOR
x<5
B
A
Solution 2:
x<5 & y7
y>7
y7
x5
B
C
C
B
x5 & y>7
C
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
33
Deferred choice
Y
• Choice made by the environment not the system
• Essential in workflow context
• Not widely supported, though its importance seems to be
increasingly recognised (e.g. BPEL)
• Naturally supported by notations that offer direct support
for the notion of state, e.g. statecharts or Petri nets
vs WCP 4 Exclusive Choice
• Choice made by the system, based on data
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
34
Deferred choice vs Exclusive choice:
definitions
Y
Deferred choice
context condition: only
one instance of the
construct can operate at
any time in a case
Exclusive choice
context condition: choice
construct has access to
all required resources
when making routing
decision
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
35
Deferred choice vs Exclusive choice
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
36
Deferred Choice - UML
Y
Solution in UML 2.0 AD
Signal 1
B
Signal 2
C
A
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
37
Deferred choice - BPMN
Y
Solution in BPMN
b
b (type
receive)
B
A
A
c
C
c (type
receive)
with Event-Based Exclusive Gateway
and Message Events
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
with Event-Based Exclusive Gateway
and Receive Activities
A W L
38
Thread split
Y
At a given point in a process, a
nominated number of execution
threads can be initiated in a
single branch of the same
process instance.
Definition CPN
context condition:
required number of
threads known at
design-time
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
39
Synchronisation patterns: AND-join variants
Y
• Synchronisation, wait for all incoming threads
– context assumption: each incoming branch will signal exactly once
• Generalised AND-Join, wait for all incoming threads
• Structured partial join, wait for some (but not all) incoming
threads
– context assumption: structured workflow
• Blocking partial join, wait for some (but not all) incoming
threads
– context assumptions: workflow is safe, join blocks until remaining
threads arrive
• Cancelling partial join, wait for some incoming threads, cancel
the rest
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
40
Synchronisation patterns: the differences
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
41
Synchronisation vs Generalised AND-Join
Definition CPN
Context condition (Synchronisation)
Once the synchroniser has been
activated (and not reset), it is not
possible for another signal to be
received on the activated branch or
for multiple signals to be received on
any incoming branch.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
Y
A W L
42
Structured partial join
Y
• Triggered by completion of n of the m parallel incoming
branches (where n < m)
• Subsequent threads do not cause triggering
• Partial join resets when all branches have completed
• Context conditions
– Corresponding and-split
– All branches structured (e.g. balanced corresponding splits and
joins)
– Either all branches can be cancelled or none
• Special case where n=1 is sometimes termed the
discriminator
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
43
Structured partial join
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
Y
A W L
44
Structured partial join: operation
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
45
Structured partial join: CPN definition
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
46
Structured partial join: Usage issue
Structured
workflow
imposes serious
usage
restrictions
real
a university
for the
© 2009,
www.yawlfoundation.org
world
Y
blocking and
cancelling pattern
variants
R
Y
A W L
47
Blocking partial join
Y
• Removes the requirement that each incoming branch can
only be enabled once between join resets.
• It allows each incoming branch to be triggered multiple
times although the construct only resets when one
triggering has been received on each input branch
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
48
Cancelling partial join
Y
• Improves the efficiency of the pattern further by
cancelling the other incoming branches to the join
construct once n incoming branches have
completed
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
49
Synchronisation patterns: OR-join variants
Y
• Structured synchronising merge, wait for all enabled branches
– context assumptions: structured workflow, local semantics
• Local synchronising merge, wait for all enabled branches
– context assumption: local semantics
• General synchronising merge, wait for all enabled branches
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
50
Structured synchronising merge: operation
Y
Structured synchronising merge, wait for all enabled branches
context assumptions: structured workflow, local semantics
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
51
Structured synchronising merge
Y
• Convergence of two or more branches (which diverged
earlier in the flow) into a single subsequent branch. The
thread of control is passed to the subsequent branch when
each active incoming branch has been enabled.
• Context conditions:
– Single earlier corresponding multi-choice
– While merge has not fired, this multi-choice cannot be re-enabled
– No cancellation of selective branches after firing multi-choice
• These conditions are such that firing decision can be made
based on local knowledge
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
52
Structured synchronising merge
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
53
Structured synchronising merge:
possible realisations I
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
54
Structured synchronising merge:
possible realisations II
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
55
Local synchronising merge
Y
• This pattern does not require the process model to
be structured, but its usage in the context of loops is
restricted
• A possible realisation is through so-called “deadpath elimination” (see MQSeries, BPEL – note the
implication this has on the types of loops allowed)
• Evaluation of whether this merge is enabled can still
be done locally
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
56
Local synchronising merge: CPN definition
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
57
Local synchronising merge: another solution
Y
Communication between OR-split and OR-join
cf. Rittgen, 1990
active
branches
A
OR
split
real
a university
for the
© 2009,
www.yawlfoundation.org
world
OR
join
R
Y
A W L
Z
58
Local synchronising merge: operation
Y
context conditions: (1) all input places to the construct are
(2) must be able to determine how many incoming
branches to synchronise based on local knowledge
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
59
A (very) complex CF pattern:
General synchronising merge
Y
• Basically: Wait only if you have to
• Problems:
–
–
–
–
How should you treat other OR-joins?
How do you deal with cycles?
How do you treat decomposed tasks?
Is an analysis of the future possible? How complex will it be?
(for a detailed discussion see [WEAH05] and work by Kindler et al)
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
60
Non-local semantics of General Synchronising Merge
("bus driver semantics")
Y
Not only in EPCs but
also in many WFM
systems: Domino
Workflow, Eastman,
MQ Series, etc.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
61
General Synchronising Merge in CPN
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
62
General synchronising merge: operation
Y
context conditions: none!
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
63
Synchronisation patterns: XOR and thread join
Y
XOR-join variants
• Simple merge,wait for one of the incoming branches
– context assumption: only one incoming branch
active
• Multi-merge, wait for one of the incoming branches
Thread join variants
• Thread merge, coalesce specified number of threads
in branch into single thread
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
64
XOR-join variants: Simple & Multi-merge
context condition: the merge
construct will never receive another
execution thread whilst it is merging
a previously received thread onto the
output branch
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
Y
context condition: the merge
construct must be associated with
a preceding multi-choice (OR-split)
A W L
65
BPMN
Several solutions for the most basic patterns
Y
BPMN
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
66
Basic control-flow patterns in UML2.0 AD
Sequence
Parallel Split
Synchronisation
B
B
A
A
C
b) Control flow in UML
[Guard1]
C
d) UML Explicit AND-split
Exclusive Choice
f) UML Explicit AND-join
Simple Merge/Multiple Merge
[Guard1]
A
A
[Guard2]
h) UML Explicit XOR-split
real
A
C
C
a university
for the
© 2009,
www.yawlfoundation.org
world
Multiple Choice
B
B
B
[Guard2]
C
j) UML XOR-join
R
Y
Y
A W L
l) UML OR-split
67
Repetition patterns - 1
Y
• Structured loop, the ability to execute a task or sub-process
repeatedly on the basis of a pre or post test where there is a
single entry/exit point
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
68
Repetition patterns - 2
Y
Describe various ways in which repetition of tasks or subprocesses may be specified.
Arbitrary cycles, cycles in a
process with more than one
entry or exit point
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Recursion, repetition of a task
through self-invocation
Y
A W L
69
Arbitrary Cycles & Expressiveness
•
Not all arbitrary cycles can be converted into structured
ones (e.g. while or repeat loops; for further details see
[KtHB00] and [Kie03]).
•
Block structured offerings such as WebSphere MQ,
FLOWer, SAP Workflow and BPEL are not able to
represent arbitrary process structures.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
70
Multiple instance patterns
Y
Delineate situations with multiple threads of execution in a workflow
which relate to the same activity
MI without Synchronisation, multiple concurrent instances but no
synchronisation requirements
MI with a priori Design Time Knowledge, number of concurrent
instances known at design-time, all must finish
MI with a priori Runtime Knowledge, number of concurrent instances
known at runtime, all must finish
MI without a priori Runtime Knowledge, number of concurrent
instances only known at completion, all must finish
Static Partial Join for MI, number of concurrent instances known at
design-time, specified number must finish, remainder
inconsequential
Cancelling Partial Join for MI, number of concurrent instances known
at design-time, specified number must finish, remainder
cancelled
Dynamic Partial Join for MI, number of concurrent instances only
known at completion, dynamic completion condition
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
71
MI patterns: variation points
Y
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
72
MI without synchronisation
Y
context condition: the number of task instances is fixed at design-time
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
73
MI without synchronisation in CPN
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
74
Multiple instances
without synchronisation
Y
(source: [AHKB03], p. 24)
i:=0
A
i:=0
Task A: Determine
the number of required
instances of B
A
Merge
AND
Merge
B
B
i:=i+1
Workflow B
Workflow A
i:=i+1
XOR
i<NumInst
XOR
i>=NumInst
i<NumInst
i>=NumInst
E
E
Solution for languages supporting multiple
instances
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Sequential simulation
Y
A W L
75
MI without Synchronization
• Solution in UML 2.0 AD
Install
Component
Build
Component
[more components
to be built]
A
B
C
Y
[no more
components
to be built]
• Solution in BPMN
ActivityType: Task
LoopType: MI
MI_Condition: M
MI_Ordering: Parallel
MI_FlowCondition: None
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
76
MI with a priori runtime knowledge
Y
context condition: the number of task instances is fixed at design-time
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
77
MI with a priori runtime knowledge in CPN
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
78
Multiple instances with a priori runtime
knowledge (source: [AHKB03], p. 24)
i:=0
A
i:=0
Task A: Determine
the number of required
instances of B
A
Merge
AND
Y
Merge
B
B
i:=i+1
Workflow B
Workflow A
i:=i+1
XOR
i<NumInst
XOR
i>=NumInst
i<NumInst
i>=NumInst
E
E
Solution for languages supporting multiple
instances
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Sequential simulation
Y
A W L
79
Multiple instances with a priori runtime
knowledge (source: [AHKB03], p. 24)
Task A: Determine
the number of required
instances of B
A
1 instance
XOR
A
3 instances
B
2 instances
B
Y
AND
Bundle
B
B
B
AND
B
E
B
Workflow D
AND
AND
Solution using Bundle construct
Merge
Workflow C
E
Solution for number of instances <= 3
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
80
MI with a Priori Run-Time Knowledge
• Solution in UML 2.0 AD
Specify
Trip
Route
Y
Book
Flight
Print
Itinerary
Book
Hotel
• Solution in BPMN
A
B
C
ActivityType: Task
LoopType: MI
MI_Condition: M
MI_Ordering: Parallel
MI_FlowCondition: All
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
81
MI without a Priori Run-Time Knowledge
•
Creation of a number of concurrently executing
instances of an activity, this number is not known before
invocation of the MI activity. Synchronisation of all
instances created is required.
•
More advanced MI patterns address:
Y
– Creation of new instances on-the-fly
– Threshold for completion (partial join)
– Cancellation of remaining threads in case of a partial join
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
82
MI without a Priori Run-Time
Knowledge: Definition
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
83
MI without a Priori Run-Time Knowledge:
Animation
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
84
Multiple instances without a priori runtime knowledge Y
(source: [AHKB03], p. 28)
Merge
AND
Merge
B
AND
Sub
Task C: Determine
if more instances of B
are needed
C
XOR
Task C: Determine
if more instances of B
are needed
C
E
More instances needed
B
XOR
More instances needed
No more instances needed
No more instances needed
E
Solution for languages supporting multiple
instances
Workflow A
Workflow B
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
85
MI without a Priori Run-Time Knowledge
Y
Workaround in UML 2.0 AD
A updates the
variables ”nr of inst”
& ”no more inst”
NB! In practice this pattern is
implemented by the user.
A updates the
variables ”nr of inst”
& ”no more inst”
A
B
[no more inst ]
{weight = nr of
inst}
C
More inst of B
to be created ?
Solution with object streams and weights
yes
no
A
C
The solutions require advanced
data manipulation and
special attribute settings.
B
[no more inst ]
{weight = nr of inst }
Solution with variables
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
86
MI without a Priori Run-Time Knowledge
Y
Workaround in BPMN
NB! In practice, a modeller has to implement this pattern.
The solution requires advanced data manipulation and special attribute settings.
StartQuantity=
nr_of_inst + 1
B
A
E
C updates
nr_of_inst &
no_more_inst
no_more_inst
C
no_more_inst = FALSE
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
87
Dynamic partial join for MI: operation
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
88
Dynamic partial join for MI
Y
context conditions:
1.initial number of instances is
set at design-time
2.must be possible to evaluate
completion condition
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
89
Concurrency patterns
Y
Reflect situations where restrictions are imposed on the
extent of concurrent control-flow in a process instance
• Sequence, sequential task execution
• Interleaved routing, execution of a set of tasks can occur in any order
but not concurrently
• Interleaved parallel routing, a set of tasks, which have a partial
ordering
amongst them, and execute in order order that satisfies this sequence
but not concurrently
• Critical section, two or more regions in a process model that cannot be
active simultaneously
• Milestone, the execution of a nominated task can only proceed when
the process instance is in a specified state
a university
for the real world
© 2009,
www.yawlfoundation.org
Y A W L
R
90
Sequence
Y
An activity in a workflow
process is enabled after
the completion of a
preceding activity in the
same process.
Definition CPN:
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
91
Interleaved routing: operation
Y
Interleaved routing, execution of a set of tasks can occur in any
order but not concurrently
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
92
Interleaved routing: definition
Y
context condition: tasks initiated and completed sequentially and
cannot be suspended
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
93
Milestone
Y
• In some cases a thread needs to check whether
some other parallel thread has reached a
certain point (but has not moved beyond it)
• As long as this is the case a certain task may
execute
• Hard to realise when a language does not
support the notion of state explicitly
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
94
Milestone (source: [AHKB03], p. 36)
Y
milestone
...
B
...
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
m
C
A
...
A W L
...
95
Milestone (source: [AHKB03], p. 35)
Y
process
questionnaire
milestone
send
questionnaire
c4
c2
c5
time out
archive
c11
c3
c1
register
process
complaint
evaluate
c8
c7
c6
processing
needed
c9
NOK
check
processing
OK
c10
skip
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
96
Milestone
Y
The execution of a nominated task can only proceed when
the process instance is in a specified state
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
97
Milestone in CPN
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
Y
A W L
98
Trigger patterns
Y
Allow for synchronisation with the operating environment
• Persistent trigger, task initiation triggered by external signal.
Triggers are durable and retained if not immediately used
• Transient trigger, task initiation triggered by external signal.
Triggers are emphemeral and are lost if not immediately used
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
99
Cancellation and completion patterns
Y
Categorise the various cancellation scenarios that may be
relevant for a workflow specification
• Cancel task, withdraw a specified task instance
• Cancel case, withdraw all task instances in a case
• Cancel region, withdraw task instances in a specified region of
a process
• Cancel MI task, withdraw all instances of a specified MI task
• Complete MI task, withdraw all remaining instances of a
specified MI task, completed instances are unaffected and the
MI task is deemed to have sucessfully completed
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
100
Cancellation region
•
Generalisation of Cancel activity and Cancel case
•
Region associated with a task
•
This region is emptied of tokens upon completion
of that task.
•
Rarely fully supported (only UML 2.0 ADs through
InterruptibleActivityRegion construct and YAWL)
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
101
Cancel region pattern
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
102
Cancel region: operation
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
103
Termination patterns
Y
Address the issue of when the execution of a
workflow is considered to be finished
• Implicit termination, finish the case when there is no more work
to do
• Explicit termination, finish the case when the thread of control
reaches a specified end node
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
104
UML activity diagram - 1
Y
ActivityFinalNode
What are the termination semantics?
→ explicit termination
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
105
UML activity diagram - 2
Y
FlowFinalNode
What are the termination semantics?
→ implicit termination
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
106
UML activity diagram - 3
Y
What are the termination semantics?
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
107
BPMN – termination semantics 1
Y
Termination semantics?
→ implicit termination
End Event
End Event
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
108
BPMN – termination semantics 2
Y
Termination semantics?
→ explicit termination
Terminate
End Event
Terminate
End Event
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
109
Control-flow perspective:
evaluation
1
Branching
1 Sequence
2 Parallel Split
6 Multiple Choice
4 Exclusive Choice
16 Deferred Choice
42 Thread Split
Synchronisation
3 Synchronization
33 Generalised AND-Join
30 Structured Partial Join
31 Blocking Partial Join
32 Cancelling Partial Join
9 Structured Discriminator
28 Blocking Discriminator
29 Cancelling Discriminator
7 Str. Synchronizing Merge
37 Local Synchronizing Merge
38 General Synchronizing Merge
5 Simple Merge
8 Multiple Merge
41 Thread Merge
Repetition
10 Arbitrary Cycles
21 Structured Loop
22 Recursion
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
2
1 – BPMN 2 – UML AD 3 – BPEL
3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+/-
+
+
+/+/+/+/+/+
+/+
+
+
+
+/+/+
+
+/+
+/+
+
+
+
+
+
+
+/-
+
+
-
+
+
-
+
-
Y
Multiple Instances
12 MI without Synchronization
13 MI with a priori Design Time Knlg
14 MI with a priori Runtime Knlg
15 MI without a priori Runtime Knlg
34 Static Partial Join for MI
35 Cancelling Partial Join for MI
36 Dynamic Partial Join for MI
Concurrency
40 Interleaved Routing
17 Interleaved Parallel Routing
39 Critical Section
18 Milestone
Trigger
23 Transient Trigger
24 Persistent Trigger
Cancellation & Completion
19 Cancel Activity
20 Cancel Case
25 Cancel Region
26 Cancel MI Activity
27 Complete MI Activity
Termination
11 Implicit Termination
43 Explicit Termination
A W L
1
2
3
+
+
+
+/+/-
+
+
+
-
+
+
-
+/+/-
-
+
+/+
-
+
+
+
+
+
+
+/+
-
+
+
+
+
-
+
+
-
+
+
+
+
+
-
Y
110
Epilogue - I
Y
Patterns
 Provide an effective foundation for training workflow designers
and developers;
 Present a means of assessing and comparing tool capabilities
and are particularly useful in tool evaluation and selection
exercises (e.g. tender evaluations);
 Offer the basis for vendors to identify functionality gaps and
potential areas for enhancement.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
111
Epilogue - II
•
•
•
•
Y
Patterns range from simple to (very) complex
Patterns typically observed
Comprehensive support lacking
Problems so complex that informal approaches fall
short
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
112
Further details
Y
Key papers
• W.M.P van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P.
Barros. Workflow Patterns. Distributed and Parallel Databases, 14(3),
pages 5-51, July 2003.
• N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and N. Mulyar.
Workflow Control-Flow Patterns: A Revised View. BPM Center Report
BPM-06-22, BPMcenter.org, 2006.
Online references
• www.workflowpatterns.com
• www.BPMcenter.org
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
113
Instruction questions - 1
Y
• Sketch the Petri-net representations of the main control-flow
connectors i.e.
–
–
–
–
–
–
AND-split
OR-split
XOR-split
AND-join
OR-join
XOR-join
• Each of these constructs can be represented by a number of
distinct control-flow patterns. What are the correspondences
between these constructs and the various control-flow
patterns?
• What are the difficulties associated with the use of the OR-join
construct?
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
114
Instruction questions - 2
Y
• Identify the control-flow patterns in the following process
model
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
115
Instruction questions - 3
Y
Model the following process as a YAWL process model
• A travel agency makes travel arrangements for people
• A travel arrangement may include one or more of the following
activities: book flight, book car and book hotel
• These activities occur in parallel
• As they involve dealing with third parties, each of the booking
activities may be either successful or unsuccessful
• When all booking activities requested by a customer have
completed successfully, the payment activity is triggered
• If any of the booking activities are unsuccessful, any further
progress on the booking activities (if any) is cancelled
• The process completes after either a payment or cancellation
activity
What difficulties arise when trying to model this as a Petri net?
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
116
Instruction questions - 4
Y
• Illustrate how the cancel case pattern could be applied
to a process model
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
117
Instruction questions - 5
Y
• The illustration below shows the nominal form of the milestone
pattern. The difficulty with this form is that if the thread of control
has passed place X, then the milestone task will never be enabled.
Modify the model so that the milestone task can still be enabled if the
thread of control has already passed X.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
118
Instruction questions - 6
Y
• Sketch the Petri-net representations for the following
situations. Which pattern do each of them correspond to?
– After the sound alarm task, either the evacuate lab task or the
handle false alarm task commences depending on whether the
value of the heat sensor variable is above 30 degrees
– At the conclusion of the test oil pressure, the pilot decides to
initiate the repressure task or ignore reading and reset task
depending on the oil pressure returned
– When the calculate depth task completes, based on the value
returned for the depth, if it is less than 5 metres, initiate the short
fill task, it is is greater than 5 metres initiate the long fill task, if it
is greater than 10 metres initiate the check valve task
– Run the g23 genome sequence task, then run the g24 genome
sequence and/or the g25 genome sequence task
– Run the measure yeast content task, after this has completed if
the time is before 12:00pm, run the fill main tank task otherwise
run the fill task 2 task
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
119
Instruction questions - 7
Y
• Outline the possible approaches to implementing a 1-out-of-3 join.
What are the advantages and disadvantages of each?
• The Ad-hoc activity construct in BPMN allows a set of nominated
tasks to run in arbitrary order. Each task can execute an arbitrary
number of times (including not at all). Draw the Petri-net to illustrate
the behaviour of this construct where it contains four tasks A, B, C
and D. How does this behaviour compare to the interleaved routing
patterns?
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
120
Instruction questions - 8
Y
The local synchronising merge relies on local semantics
for its operation i.e., the OR-join must be able to
determine when to fire based on the availability of locally
available information
• Why might this approach to OR-join enablement
be popular with tool vendors?
• How might you implement this form of OR-join?
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
121
References I
Y
•
www.workflowpatterns.com
•
W.M.P. van der Aalst. Patterns and XPDL: A Critical Evaluation of the XML Process Definition
Language. QUT Technical report, FIT-TR-2003-06, Queensland University of Technology,
Brisbane, 2003.
•
W.M.P. van der Aalst. Don't go with the flow: Web services composition standards exposed.
Web Services - Been there done that?, Trends & Controversies. IEEE Intelligent Systems
18(1):72-76.
•
Wil M.P. van der Aalst and Kees M. van Hee. Workflow Management: Models, Methods, and
Systems. The MIT Press, 2002.
•
W.M.P van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow
Patterns. Distributed and Parallel Databases, 14(3), pages 5-51, July 2003.
•
W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Advanced
Workflow Patterns. In O. Etzion and P. Scheuermann, editors, 7th International Conference on
Cooperative Information Systems (CoopIS 2000), volume 1901 of Lecture Notes in Computer
Science, pages 18-29. Springer-Verlag, Berlin, 2000.
•
W.M.P. van der Aalst, M. Dumas, and A.H.M. ter Hofstede. Web Service Composition
Languages: Old Wine in New Bottles? In G. Chroust and C. Hofer, editors, Proceedings of the
29th EUROMICRO Conference: New Waves in System Architecture, pages 298-305. IEEE
Computer Society, Los Alamitos, CA, 2003.
•
M. Dumas and A. ter Hofstede. UML Activity Diagrams as a Workflow Specification Language.
In Proceedings of the International Conference on the Unified Modeling Language (UML),
Toronto, Canada, October 2001. Springer Verlag.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
122
References II
Y
•
Marlon Dumas, Wil M.P. van der Aalst, Arthur H.M. ter Hofstede (Editors), Process-Aware
Information Systems: Bridging People and Software Through Process Technology, John
Wiley & Sons, September 2005.
•
B. Kiepuszewski, A.H.M. ter Hofstede, C. Bussler. On Structured Workflow Modelling.
Proceedings CAiSE’2000, Lecture Notes in Computer Science 1789, Stockholm, Sweden,
June 2000.
•
B. Kiepuszewski. Expressiveness and Suitability of Languages for Control Flow Modelling in
Workflows. PhD thesis, Queensland University of Technology, Brisbane, Australia, 2003.
•
B. Kiepuszewski, A.H.M. ter Hofstede and W.M.P. van der Aalst. Fundamentals of Control Flow
in Workflows. Acta Informatica 39(3):143-209, 2003.
•
P. Rittgen. From process model to electronic business process. In D. Avison, E. Christiaanse,
C.U. Ciborra, K. Kautz, J. Pries-Heje, and J. Valor, editors, Proceedings of the European
Conference on Information Systems (ECIS 1999), pages 616–625, Copenhagen, Denmark,
1999. http://www.adm.hb.se/~pri/ecis99.pdf.
•
N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and N. Mulyar. Workflow Control-Flow
Patterns: A Revised View. BPM Center Report BPM-06-22 , BPMcenter.org, 2006.
•
N. Russell, Wil M.P. van der Aalst , A.H.M. ter Hofstede , and Petia Wohed. On the Suitability of
UML 2.0 Activity Diagrams for Business Process Modelling. In M. Stumptner, S. Hartmann,
and Y. Kiyoki, editors, Proceedings of the Third Asia-Pacific Conference on Conceptual
Modelling (APCCM2006), volume 53 of CRPIT, pages 95-104, Hobart, Australia, 2006. ACS.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
123
References III
Y
•
P. Wohed, E. Perjons, M. Dumas, and A. ter Hofstede, Pattern-Based Analysis of EAI
Languages: The Case of the Business Modeling Language. in Proc. of the 5th Int. Conf. on
Enterprise Information Systems (ICEIS), Angers, France, April 2003.
•
P. Wohed, W.M.P. van der Aalst, M. Dumas, and A.H.M. ter Hofstede, Analysis of Web Services
Composition Languages: The Case of BPEL4WS. in I.Y. Song, et al, eds, 22nd Int. Conf. on
Conceptual Modeling (ER 2003), vol. 2813 of LNCS, pp. 200-215, Springer-Verlag, 2003.
•
P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, and N. Russell, Pattern-based
Analysis of the Control-Flow Perspective of UML Activity Diagrams. in L. Delcambre et al.,
eds, Proc. of the 24th Int. Conf. on Conceptual Modeling (ER 2005), vol. 3716 of LNCS, pp. 6378. Springer-Verlag, Berlin, 2005.
•
P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, and N. Russell, On the
Suitability of BPMN for Business Process Modelling. in Proc. of the 4th Int. Conf. on Business
Process Management, Vienna, September 2006.
•
P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, and N. Russell. Pattern-based
Analysis of BPMN - An extensive evaluation of the Control-flow, the Data and the Resource
Perspectives (revised version) . BPM Center Report BPM-06-17 , BPMcenter.org, 2006.
•
M. Wynn, D. Edmond, W.M.P. van der Aalst, A.H.M. ter Hofstede. Achieving a General, Formal
and Decidable Approach to the OR-join in Workflow using Reset nets. Proceedings of
ATPN’2005. Miami, Florida, 2005.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
124
Disclaimer
Y
No legal liability or responsibility is assumed for the accuracy and
completeness of any product-specific information.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
125