P R E S E N T E D B Y B A R B A R A W E B E R
U N I V . O F I N N S B R U C K
Enabling Flexibility in Process-aware Information Systems
Challenges, Methods, Technologies
Content
Part 1 – Process-aware Information Systems Part 2 – Flexibility Issues Part 3– Flexibility Support for Pre-specified Process Models Pre-specified process models and flexibility-by-design Process configuration Flexible process execution and handling of anticipated exceptions Handling unforeseen exceptions Process Evolution Process Monitoring, Mining & Analysis
2
Content
Part 4– Loosely-specified Process Models Loosely-specified process models Constraint-based process models
3
B A R B A R A W E B E R U N I V . O F I N N S B R U C K
Business Processes and Workflows Process-aware Information Systems
4
A Retail Process
Mendling 2006
Welcome customer
Offer Clothes
Bill Clothes
Hand over clothes
5
Business Process Lifecycle
Evaluation
Design &Analysis
Configuration
Enactment
Design: Business Process Identification and
Modeling
Analysis:ValidationSimulationVerification
Configuration:System SelectionImplementation
Test and Deployment
Enactment: OperationMonitoring
Maintenance
Evaluation:Process Mining
Business Activity Monitoring
Administration and
Stakeholders
Fig 1.5. Business process lifecycle
M. W
eske
: Bus
ines
s P
roce
ss M
anag
emen
t, ©
Spr
inge
r-V
erla
g B
erlin
Hei
delb
erg
2007
6
Value to shareholders and competitiveness
Stakeholders
Process modeling
Process execution
Knowledge
Efficiency
IT agility
Compliance & consistency
Process monitoring Business insight
BPM adoption maturity
Transformation
Workers, supervisors, and managers CIO CFO CXO CEO
Lower Higher Higher
Lower
Customers and partners Forester 2007 BPM Market Overview
Process Optimization
BPM Value Proposition
7
Process-aware Information System
Users
... Anwendungen / Application Server
Instance 4 Instance 3
Instance 2 Instance 1
Instance 6 Instance 5
Instance 11 Instance 10
Instance 9 Instance 8
Instance 7
Instance 14 Instance 13
Instance 12
Process-aware Information System (PAIS)
Process Execution Engine
Msg Queuing Time Mgmt Authorization
Late Modeling Web Clnt API Validatíon
Dyn. Change API Modeling API Admin. API
Exceptions Audit Trail ...
Process Engineer
Process Composer
Create Process Schema Modify Process Schema Check Process Schema …
Process Repository
Process Models
Application Components
8
+ x
Simple Process Model
Process Model S
Activity
XOR-Split/Join
AND-Split/Join
Patient Admission
Anamnesis & Clinical Examination
Non Operative Therapy
Sonography
MRT
X-ray
Initial Treatment & Operation Planning
Non Operative Therapy 1
Operative Treatment
Discharge & Documentation
clinicalSuspicionOf CruciateRupture = „Yes“
cruciateRupture = „Yes“ and operationIndicated = „Yes“
x
x x
x
+ +
9
Business Function 1
... Business
Function 2 Business
Function 3 Business
Function 4 Business
Function n
...
business functions
Function Perspective
EXECUTABLE PROCESS MODEL
control flow: order & execution constraints
Behavior Perspective
data objects & data flow
Information Perspective
time constraints (e.g., activity deadlines)
Time Perspective
organizational model (actors, roles,
organizational units)
Organization Perspective
activity implementations & application services
Operational Perspective
Proc
ess
Pers
pect
ives
10
Built-time versus Run-time - Process Type versus Process Instance Level -
11
+ x
Business Process – System Perspective
Enabled
Process Schema S
Completed Skipped
Execution Trace: σ1 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „X-ray“>
Execution Trace: σ2 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „Non Operative Therapy“>
Process Instance I1 Process Instance I2
Activity
XOR-Split/Join
AND-Split/Join
Activity States:
Patient Admission
Anamnesis & Clinical Examination
Non Operative Therapy
Sonography
MRT
X-ray
Initial Treatment & Operation Planning
Non Operative Therapy 1
Operative Treatment
Discharge & Documentation
clinicalSuspicionOf CruciateRupture = „Yes“
cruciateRupture = „Yes“ and operationIndicated = „Yes“
x
x x
x
+ +
+ + x
x x x
+ + x
x x x
12
Activity Lifecycle
Inactive Enabled Running Completed
Skipped Suspended Failed
enable start complete
fail skip disable
skip
suspend resume
13
Offered Allocated Started Completed
Withdrawn
User Perspective and Work item Lifecycle
Joe Peter
MRT MRT
Process Instance I5
Patient Admission
Anamnesis & Clinical Examination
Non Operative Therapy
Sonography
MRT
X-ray
Initial Treatment & Operation Planning
Non Operative Therapy 1
Operative Treatment
Discharge & Documentation x
x x
x
+ +
Offered Allocated Started Completed
Withdrawn
14
User Perspective
Joe Peter
MRT MRT
Process Instance I5
Patient Admission
Anamnesis & Clinical Examination
Non Operative Therapy
Sonography
MRT
X-ray
Initial Treatment & Operation Planning
Non Operative Therapy 1
Operative Treatment
Discharge & Documentation x
x x
x
+ +
Let‘s do the MRT
Offered Allocated Started Completed
Withdrawn
Offered Allocated Started Completed
Withdrawn
15
User Perspective
Joe Peter Process Instance I5
Patient Admission
Anamnesis & Clinical Examination
Non Operative Therapy
Sonography
MRT
X-ray
Initial Treatment & Operation Planning
Non Operative Therapy 1
Operative Treatment
Discharge & Documentation x
x x
x
+ +
Offered Allocated Started Completed
Withdrawn
Offered Allocated Started Completed
Withdrawn
16
User Perspective
Joe Peter Process Instance I5
Patient Admission
Anamnesis & Clinical Examination
Non Operative Therapy
Sonography
MRT
X-ray
Initial Treatment & Operation Planning
Non Operative Therapy 1
Operative Treatment
Discharge & Documentation x
x x
x
+ +
Offered Allocated Started Completed
Withdrawn
Offered Allocated Started Completed
Withdrawn
17
User Perspective
Joe Peter Process Instance I5
Patient Admission
Anamnesis & Clinical Examination
Non Operative Therapy
Sonography
MRT
X-ray
Initial Treatment & Operation Planning
Non Operative Therapy 1
Operative Treatment
Discharge & Documentation x
x x
x
+ +
Initial Initial
18
B A R B A R A W E B E R U N I V . O F I N N S B R U C K
Business Processes and Workflows Flexibility Issues
19
Process Spectrum
Process Spectrum From fully predictable and highly repetitive to Fully unpredictable and non repetitive
20
Processes on the right side of the spectrum are mostly knowledge-intensive
Unpredictability Course of action depends on situation-specific parameters
Non-repeatability Two process instances hardly look the same
Emergence Future course of action depends on knowledge gained
through activity execution
Knowledge-intensive Processes
21
Flexibility Needs
22
Variability is typical for many domains and requires that processes are handled differently depending on the particular context
Drivers Product and service variability Differences in regulations Different customer groups Temporal differences
Variability
23
Knowledge-intensive processes cannot be fully pre-specified, but require loose specifications
Drivers Unpredictability Non-Repeatability Emergence
Looseness
24
Ability to adapt the process and its structure to temporary events
Drivers Special Situations Exceptions
Anticipation of Adaptation Planned Unanticipated
Adaptation
25
Ability of the implemented process to change when the business process evolves
Drivers
Evolution
External Internal Changing Business Context
Changing Technological Context
Changing Legal Context
Organizational Learning
Real-world Process PAIS
Design Errors
Technical Problems
Poor Internal Quality
represented in
provide feedback to
26
Extent of Evolution Incremental Continuous Process Improvement
Revolutionary Business Process Reengineering
Duration Temporary Permanent
Evolution
27
Swiftness Deferred Ongoing instances are not affected
Immediate Ongoing instances are affected
Visibility Observable Behavior Internal Structure
Evolution
28
Flexibility Issues along the Process Lifecycle
Instance I1
A
D
B
x x E C
Instance I1
A
D
B
x x E C
Schema S‘:
A
D
B
x x C
Traditional Process Lifecycle Support
Cre
ate
Inst
ance
s
Process Execution
Process engineer / Process administrator
Process participant
Arbeitsliste Tätigkeit 1 Tätigkeit 2 Tätigkeit 3 Tätigkeit 4
Schema S:
A
D
B
x x E C
Instance I1
A
D
B
x x E C
Execution Log
Process Monitoring
Need for Process Adaptation (Support for Planned and Unplanned Exceptions /
Special Cases)
Need for Process Evolution
Need for Variability Support
Need for Looseness of Process Specifications
[WRW+09] 29
Flexibility Needs and Technological Requirements
Flexibility Need
Dimension Technological Requirement
Variability Configuration Looseness Loosely-specified processes Adaptation Planned
Unplanned Exception Handling Ad-hoc Changes
Evolution Deferred Evolution Immediate Evolution Poor Internal Quality Organizational Learning
Versioning Process Instance Migration Refactoring Monitoring, Analysis and Mining
30
B A R B A R A W E B E R U N I V . O F I N N S B R U C K
Business Processes and Workflows Pre-specified Process Models and Flexibility by Design
31
Basic Control Flow Concepts – Activities
Atomic Activities
Complex Activities
Automated Web services, Java applications, database function
Human Electronic forms
Refer to sub-process models
32
Basic Control Flow Concepts
Control Connectors (i.e., Gateways) (X)OR-Split / (X)OR-Join AND-Split / AND-Join
Control Flow Edges Sequence Flow Default Path
Transition Conditions
33
34
Sequence Flow Default Path
Transition Conditions
AND Gateway Atomic Activity
Basic Control Flow Concepts - Example
XOR Gateway
Basic Data Flow Concepts
Data objects + Data edges Data objects can be linked to activities via data edges
Read access Write access
referenced by transition conditions attached to outgoing messages
35
36
Data Object Data Edge – Read Access
Data Edge – Write Access
End Message with Data Obejct
Invoice
Transition Condition references
SparePartsList
Basic Data Flow Concepts - Example
Process Fragments Single Entry
Single Exit regions
Single activities: R2, R3, R4 Nested:
R2, R3, R4, R5 and R12 are contained in R1 Disjoint:
R6 and R7 37
Process Fragments Single Entry
Single Exit regions
Single activities: R2, R3, R4 Nested:
R2, R3, R4, R5 and R12 are contained in R1 Disjoint:
R6 and R7
Process Fragment
38
Process Structure Tree
Decomposition of process model into process structure tree
[VVK09] 39
Control Flow Patterns
Sequence Parallel-Spit (AND-Split) Synchronization (AND-Join) Exclusive Choice (XOR-Split) Simple Merge (XOR-Join) Structured Loop
40 [RHA+06, AHK+03, Wes07]
Activity Lifecycle
41
Inactive Enabled Running Completed
Skipped Suspended Failed
enable start complete
fail skip disable
skip
suspend resume
Sequence
42
AND-Split
43
AND-Join
44
XOR-Split
45
XOR-Join
46
Structured Loop
47
Deferred Choice
48
Interleaved Routing
49
Expressiveness and Flexibility by Design
50
Flexibility by Design (M
issi
ng) E
xpre
ssiv
enes
s an
d
Flex
ibili
ty b
y D
esig
n
51
Events Related to the Execution of Activities or Transition Conditions
52
Examples for Events Explanation
start(A) Activity A started
complete(A:d1=v1) Activity A completed writing data object d1 with value v1
start(cond1) Evaluation of transition condition cond1 started
complete(cond1:true) Transition condition cond1 evaluated to true
start(cond2) Evaluation of transition condition cond2started
complete(cond2:false) Transition condition cond2 evaluated to false
start(B) Activity B started
53
d5
Enabled
B) Execution Traces
Completed Skipped
σ1 = < start(1), complete(1:d1=v1), start(2), complete(2:d2=v2), start(3), complete(3,d3=v3;d4=v4), start(cond1), complete(cond1:true), start(cond2), complete(cond2:true)>
σ2 = < start(1), complete(1:d1=v5) >
Process Instance I1
Process Instance I2
Process Instance I3
Process Instance I4
Activity States:
A) Process Model Process Model S
1 2
4
+ +
C) Process Instances
1: Enter Repair Order 2: Determine Defect 3: Check Availability of Spare Parts 4: Order Spare Parts 5: Repair Car 6: Provide Replacement Car 7: Create Invoice 8: Notify Customer
Running
3 8
7 + +
x x 5
6 x x
cond1
cond2 + + + +
x x
x x
+ + + +
x x
x x
+ + + +
x x
x x
d1
d2 d3
d4
d1: Repair Order d2: Repair Service Request d3: Spare Parts List d4: Estimated Duration d5: Invoice
σ3 = < start(1), complete(1:d1=v6), start(2), complete(2:d2=v7), start(3), complete(3,d3=v8;d4=v9), start(cond1), complete(cond1:false), start(cond2), complete(cond2:false), start(5), complete(5), start(7), start(8), complete(7:d5=v10), complete(8)>
+ + + +
x x
x x
σ4 = < start(1), complete(1:d1=v11), start(2), complete(2:d2=v12), start(3), complete(3,d3=v13;d4=v14), start(cond1), complete(cond1:true), start(cond2), complete(cond2:false), start(4), complete(4) >
Exam
ples
– E
xecu
tion
Trac
es
Verification of Process Models
Soundness Option to Complete Proper Completion No dead activities
Data Flow Correctness No missing data No dead activities No lost updates
[WVA+09]
[RAS09]
54
Example: Option to Complete
55
Option to Complete A process instance, once started, can always complete.
Example: Proper Completion
56
Proper Completion When a process instance completes there exists no related activity of this instance which is still running or enabled.
Example: Dead Activity
57
No dead activities A process model does not contain any dead activity, i.e., for each activity there exists at least one completed trace producible on that model and containing this activity.
Example: Missing Data
58
Missing Data The data flow schema of a process model might cause missing data at run-time if a data object exists which can be read during run-time without having been written by any preceding activity or provided by the outside environment (i.e., by a start message).
Data Flow Errors: Unnecessary Data
59
Unnecessary Data A data object written by an activity of process model is called unnecessary if it is not read by any subsequent activity or transition condition or passed to the outside environment via an end message.
Data Flow Errors: Lost Updates
60
Lost Updates The data flow schema of a process model might cause lost data at run-time if a data object, which is written by an activity, is updated by a subsequent activity, but without reading the data object in between.
Well-stuctured versus Unstructured
A well-structured or block-structured process model is composed of blocks (Single-Entry Single-Exit fragments), which can be nested, but must not overlap
Blocks can be single activities, sequences, parallel branchings, alternative branchings, loop blocks or the entire process model
Unstructured models require advanced verification techniques
Unstructured models are more difficult to understand and are a considerable source of errors
61
Unstructured vs. well-structured Process Model
62
62
References
• [AHK+03] 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.
• [RHA+06] 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.
• [TAS09] Nikola Trcka, Wil M. P. van der Aalst, Natalia Sidorova: Data-Flow Anti-patterns: Discovering Data-Flow Errors in Workflows. CAiSE 2009: 425-439
• [VVK09] Jussi Vanhatalo, Hagen Völzer, Jana Koehler: The refined process structure tree. Data Knowl. Eng. 68(9): 793-818 (2009)
• [Wes07] Mathias Weske: Business Process Management: Concepts, Languages, Architectures, Springer 2007.
• [WVA+09] Wynn, M.T., Verbeek, H.M.W., Aalst, W.M.P. van der, Hofstede, A.H.M. ter and Edmond, D. (2009). Business process verification : finally a reality! Business Process Management Journal, 15(1), 74-92.
63
B A R B A R A W E B E R U N I V . O F I N N S B R U C K
Business Processes and Workflows Configurable Process Models
64
Motivation – Change Management Process
3b) Stm. 3c) Stm.
4) Integration of Stm.
3a) Stm. Develop- ment (Dev.)
5) Permission
Project Leader
2) Request for Statements (Stm.)
Production- Planning (PP)
Pilot
6) Realization
7) Completion
1) Change request Applier
x Decision Board
x Dev.
Responsible
< <
Responsible
Standard Process variant I: Quality issues affected
Process variant II: Low risk/costs; long to realize
3b) Stm. 3c) Stm.
4) Integration of Stm.
3a) Stm. Dev.
5) Permission
Project Leader
2) Request for Statements (Stm.)
PP Pilot
6) Realization
7) Completion
1) Change request Applier
x Decision Board
x Dev.
Responsible <
<
Responsible
3d) Stm.
Process variant III: Low risk/ costs; fast to realize; affects quality issues
d)
3b) Stm. 3c) Stm
4) Integration of Stm.
3a) Stm. Dev.
5) Permission
Project Leader
2) Request for Statements (Stm.)
PP Pilot
6b) Undo Realization
7) Completion
1) Change request Applier
x
Decision Board
x
Responsible
< <
Responsible
< 6) Realization
Dev.
3b) Stm. 3c) Stm.
4) Integration of Stm.
3a) Stm. Dev.
5) Permission
Project Leader
2) Request for Statements (Stm.)
PP Pilot
6b) Undo Realization
7) Completion
1) Change request Applier
x
Decision Board
x
Responsible
< <
Responsible
3d) Stm.
<
6) Realization Dev.
Quality Department (QDept.)
Dev. Dev.
QDept.
65
Reception
Example: Vehicle Repair Process
Standardized Process
Repair Diagnosis Hand Over
Reception Repair Diagnosis Hand Over Final Check
Maintain
Variant 3: Fast Run and Security Critical Repair
Variant 2: Security Critical Repair Repair Hand Over
Maintain
Reception Repair Diagnosis Hand Over Final Check
Variant 1: Fast Run
Diagnosis
Reception
Motivation – Vehicle Repair Process
Conclusion: Many processes with different variants, depending on the process context.
66
Fzg. Annahme
Reparatur Diagnose
d) Variant 3: Fast Run and security-critical Repair
Fzg. Übergabe
Prüfung Fzg. Annahme
Reparatur Diagnose
c) Variant 2: Security-critical Repair
Wartung
Prüfung Fzg. Annahme
Reparatur Diagnose Dauer = 2 Dauer = 2
b) Variant 1: Fast Run
Fzg. Übergabe
a) Standardized Process
Reception Repair Diagnosis Hand Over
Maintain
Multi-Model Solution
Single-Model Solution
Reception Hand Over
Diagnosis
Maintain
Diagnosis Shortened
Final Check
Variant 2 or Variant 3
Standard or Variant 1
Variant 1 or Variant 3
Standard or Variant 2
Repair
Variant 1 or Variant 3
Standard or Variant 2 or Variant 3 Standard or
Variant 2
Conclusion: Both approaches can be supported by commercial BPM tools, but do not enable transparent and explicit management of process variants
Configuring Process Variants in Existing BPM Tools
67
Motivation – Handling Medical Examinations 68
(c) 2012 Barbara Weber, Manfred Reichert
Variety of related variants
• Same business
objective • Commonalities
• Differences due
to varying application context
Two Main Approaches
Behaviour-based Approaches for Capturing Process
Variability
Structural Approaches for Capturing Process Variability
69 (c) 2012 Barbara Weber, Manfred Reichert
Two Main Approaches
Behaviour-based Approaches for Capturing Process
Variability
Structural Approaches for Capturing Process Variability
70 (c) 2012 Barbara Weber, Manfred Reichert
Configurable Nodes
Main idea: configurable nodes Extension of an existing process modeling language by adding
configurable elements E.g., C-EPC, E-YAWL
Configurable nodes represent variation points and can be associated with configuration alternatives
Possible combinations of configuration alternatives can be restriceted through constraints
71 (c) 2012 Barbara Weber, Manfred Reichert
Configurable Activities
Included (ON) Excluded (OFF) Conditional (OPT)
72 (c) 2012 Barbara Weber, Manfred Reichert
Configurable Control Connectors
Configurable OR Configurable XOR Configurable AND
73
Can be configured to a connector
equally restrictive or less restrictive
(c) 2012 Barbara Weber, Manfred Reichert
Configurable Control Connectors
Configurable OR Configurable XOR Configurable AND
74
Can be configured to a connector
equally restrictive or less restrictive
(c) 2012 Barbara Weber, Manfred Reichert
Configuration Requirements and Guidelines
Requirements Define constraints
over the configuration alternatives that can be chosen
Guidelines Do not prescribe
mandatory constraints, but serve as recommendations
75
a
(c) 2012 Barbara Weber, Manfred Reichert
Configurable Model: Handling Medical Examinations
76 (c) 2012 Barbara Weber, Manfred Reichert
Configurable Model: Handling Medical Examinations
77 (c) 2012 Barbara Weber, Manfred Reichert
Hiding and Blocking
Capturing variability in a language-independent way
(1) Represent process model as a labeled transition system (LTS)
(2) Apply hiding and blocking operators for configuring LTL-based reference process models
78 (c) 2012 Barbara Weber, Manfred Reichert
Expressing Process Behavior through Labeled Transition Sytems
79 (c) 2012 Barbara Weber, Manfred Reichert
Hiding and Blocking
Blocking: enables encapsulation – execution of an atomic activity (event is disabled)
Hiding: enables abstraction – execution of an event becomes non-observable (activity is replaced by silent activity)
80 (c) 2012 Barbara Weber, Manfred Reichert
Hiding and Blocking Example
(c) 2010 Barbara Weber 81
Two Main Approaches
Behavior-based Approaches for Capturing Process
Variability
Structural Approaches for Capturing Process Variability
82 (c) 2012 Barbara Weber, Manfred Reichert
Deriving Variants through Structurally Changing a Base Process Model
83 (c) 2012 Barbara Weber, Manfred Reichert
Representing a Process Family
Through a configurable base process model Policy 1: Standard Process Policy 2: Most frequently used process Policy 3: Superset of all process variants Policy 4: Intersection of all process variants
and a related set of pre-specified changes Adjustment points Change options (i.e., a grouping of change operations)
84 (c) 2012 Barbara Weber, Manfred Reichert
Examples of Change Operations
85 (c) 2012 Barbara Weber, Manfred Reichert
Exa
mpl
e of
Bas
e Pr
oces
s +
Opt
ions
86 (c) 2012 Barbara Weber, Manfred Reichert
Constraining Allowed Combinations of Change Operations
Implications Mutual exclusion Hierarchy
87 (c) 2012 Barbara Weber, Manfred Reichert
Context Model
88 (c) 2012 Barbara Weber, Manfred Reichert
Context-specific selection of change operations Context variables
The Whole Approach
(1) Select relevant options All change options whose context rules evaluate to true are selected
(2) Ensure compliance of the selected options with option constraints Compliance with option constraints has to be checked
(3) Determine the order in which options shall be applied (4) Configuring the base process by applying the selected
options and their change operations to it
89 (c) 2012 Barbara Weber, Manfred Reichert
(c) 2010 Barbara Weber 90
Questionnaire-driven Process Configuration
(1) Questionnaire Model
(2) Using Questionnaire Models for Configuring a Reference Process Model (a) Linking Domain Facts and Configurable Activities
(b) Linking Domain Facts and Configurable Connectors
91 (c) 2012 Barbara Weber, Manfred Reichert
Questionnaire Model
(c) 2010 Barbara Weber
92
Linking Domain Facts and Configurable Activities
93 (c) 2012 Barbara Weber, Manfred Reichert
Linking Domain Facts and Configurable Connectors
94 (c) 2012 Barbara Weber, Manfred Reichert
Feature Diagram
95 (c) 2012 Barbara Weber, Manfred Reichert
References
• [GAV+08] Florian Gottschalk, Wil M. P. van der Aalst, Monique H. Jansen-Vullers, Marcello La Rosa: Configurable Workflow Models. Int. J. Cooperative Inf. Syst. 17(2): 177-221 (2008)
[HBR10] Alena Hallerbach, Thomas Bauer, Manfred Reichert: Capturing variability in business process models: the Provop approach. Journal of Software Maintenance 22(6-7): 519-546 (2010)
[HBR09] Alena Hallerbach, Thomas Bauer, Manfred Reichert: Guaranteeing Soundness of Configurable Process Variants in Provop. CEC 2009: 98-105
[HBR08] Alena Hallerbach, Thomas Bauer, Manfred Reichert: Managing Process Variants in the Process Life Cycle. ICEIS (3-2) 2008: 154-161
• [Ros09] M. La Rosa: Managing Variability in Process-Aware Information Systems, PhD Thesis, Queensland University of Technology, Brisbane, Australia. April 2009.
• [RDH09] M. La Rosa, M. Dumas, A.H.M. ter Hofstede: Modelling Business Process Variability for Design-Time Configuration. In J. Cardoso, W.M.P. van der Aalst (editors), Handbook of Research on Business Process Modeling, IDEA Group – Information Science Reference, 2009.
• [RLS+07] M. La Rosa, J. Lux, S. Seidel, M. Dumas and A.H.M. ter Hofstede: Questionnaire-driven Configuration of Reference Process Models. In Proc. CAiSE 2007, Trondheim, Norway. LNCS Vol. 4495, pp. 424–438, Springer, 2007.
• [RoAa07] Michael Rosemann, Wil M. P. van der Aalst: A configurable reference modelling language. Inf. Syst. 32 (1): 1-23 (2007)
96
B A R B A R A W E B E R U N I V . O F I N N S B R U C K
Business Processes and Workflows Exception and Compensation Handling
97
Process Adaptations
Planned Unplanned
Exception Handling Ad-hoc Changes
98
Exception Handling in PAIS
Activity Failure
Sources for Exceptions
Technical Semantical
Deadline Expiry
Resource Unavailability
Inconsistence real-world / PAIS
Constraint Violations
Upon detection of a particular exception
a suitable handler is chosen
Trying Alternatives
Ordered Unordered
Exception Handler
Add Behavior
Deferred Fixing
Immediate Fixing
Retry Exception-driven Rework
Cancelling Behavior
Reject Compensate Resource Patterns
Delegate Escalate …
99
Exception Handling
Simple Handler
Exception Handling
Scopes
100
Exception Handling Patterns - Ordered Alternatives -
101 [LCB+10]
Exception Handling Patterns - Unordered Alternatives -
102
Exception Handling Patterns - Immediate Fixing -
103
Exception Handling Patterns - Deferred Fixing -
104
Exception Handling Patterns - Retry -
105
Exception Handling Patterns - Reject -
106
Exception Handling Patterns - Compensate -
107
Resource Patterns
Exception Handling Patterns (like Deferred Fixing, Reject etc.) focus on behavioral changes
Many exceptions (e.g., resource unavailability or deadline expiry) require changes regarding resource perspective like delegation, escalation or reallocation
108 [RHE+04]
Resource Patterns
109
Selected Resource Patterns
110
Flexible Handling of Work Items
Application of Exception Handling patterns often requires changes to the lifecycle of work items.
Work items may have to be Skipped Redone Done ahead of time Canceled Suspended/Resumed
111 [RAH+06]
Flexible Handling of Work items
112
Flexible Handling of Workitems
113
A B C D
System Log Bc Cc Ac
Commit Commit Commit
normal processing
Abort!
Rollback
Abort Transaction (Rollback Work)
Compensation of C
Compensation of B
Compensation of A ready!
The SAGAS concept
Compensation Information
[GaSa87]
114
Compensation Handling - Sagas
114
Compensation Spheres
115
Compensation Spheres
116
process
scope
scope
scope
scope scope
scope
scope
Scopes provide a context which influences the execution behavior of its enclosed activities
Isolated scopes provide control of concurrent access to shared resources
scope
Local declarations: partner links, message exchanges, variables, correlation sets
Local handlers: event handlers, fault handlers, a termination handler, and a compensation handler
Compensation handler to undo persisted effects of already
completed activities
Termination handler to deal with forced scope termination
(external faults)
primary activity
scope
117
Compensation and Fault Handling in BPEL (1)
117
process
scope
invoke
invoke
invoke
fault handler
compensate compensation
handler
compensate
compensation handler
compensation handler
invoke
invoke
1. Do some work (successfully invoke two services)
2. Invoke another service (throws fault)
3. The fault triggers the process-level fault handler
4. Compensate previous work
5. Propagate compensation
6. Undo work (in reverse order)
This example shows the default compensation behavior supported by BPEL; i.e., a completed scope is com-pensated by invoking the compensation handlers of its constituting activities in reverse order. How-ver, a more specific compensation handler for a scope may be provided as well (e.g., only com-pensating some of the already completed activities or invoking a specific process dealing with the exception).
118
Compensation and Fault Handling in BPEL (2)
118
Exlets
119 [AHA+07]
References
[AHA+07] Michael Adams, Arthur H. M. ter Hofstede, Wil M. P. van der Aalst, David Edmond: Dynamic, Extensible and Context-Aware Exception Handling for Workflows. OTM Conferences (1) 2007: 95-112
[LCO+10]Barbara Staudt Lerner, Stefan Christov, Leon J. Osterweil, Reda Bendraou, Udo Kannengiesser, Alexander E. Wise: Exception Handling Patterns for Process Modeling. IEEE Trans. Software Eng. 36(2): 162-183 (2010)
[MoSa87] Hector Garcia-Molina, Kenneth Salem: Sagas. SIGMOD Conference 1987: 249-259 [NAH06] N. Russell, W.M.P. van der Aalst, and A.H.M. ter Hofstede. Exception Handling Patterns in
Process-Aware Information Systems. BPM Center Report BPM-06-04 , BPMcenter.org, 2006. [RHE+04] N. Russell, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst. Workflow Resource
Patterns. BETA Working Paper Series, WP 127, Eindhoven University of Technology, Eindhoven, 2004.
B A R B A R A W E B E R U N I V . O F I N N S B R U C K
Business Processes and Workflows Handling Unforeseen Exceptions
121
Process Adaptations
Planned Unplanned
Exception Handling Ad-hoc Changes
122
User View on an Ad-hoc Process Change
Explanation Operation Risks
X-Ray
Check Anesthesiology
Examination
End
Start Examinations
U Wallace, Edgar
U Miller, Anne
U Smith, Karl
U Jones, Isabelle
Exception – We need an additional lab test !
Lab Test
Explanation Operation Risks
X-Ray
Check Anesthesiology
Examination
123
123
Behavioral Changes Require Structural Process Model Adaptations
124
Behavioral Changes Require Adaptations of the Process Instance State
125
Behavioral Changes Require Adaptations of the Process Instance State
126
Behavioral Changes Must not Violate Process Model Soundness and Proper Instance Execution
127
No Proper Completion
ensured. End node can be reached while B is still enabled
Data flow error caused by
missing data
x
+ + x x x
Process Instance Level
Execution Trace: σ1 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „X-ray“>
Execution Trace: σ2 = < „Patient Admission“>
Process Instance I1
Process Instance I2
x
x x x + +
Process Type Level
Process Schema S
Activity
XOR-Split/Join
AND-Split/Join
Patient Admission x Anamnesis &
Clinical Examination
Non Operative Therapy
Sonography
MRT
X-ray
Initial Treatment & Operation Planning
Non Operative Therapy 1
Operative Treatment
Discharge & Documentation
+ + x x
x
x
+
clinicalSuspicionOf CruciateRupture = „Yes“
cruciateRupture = „Yes“ and operationIndicated = „Yes“
Ad-hoc Changes of a Process Instance Must Not Affect any Other Process Instances
128
128
Change Primitives Add node Remove node Add edge Remove edge Move edge
High-Level Change Operations Combines a set of change primitives Referred to as Adaptation Patterns in the following
Structurally Adapting Pre-Specified Process Models
129
129
Adaptation Patterns
130 [WRR08]
Adaptation Patterns versus Change Primitives
131
Adaptation Patterns versus Change Primitives
Change Primitives Process Adaptation Patterns
Operate on single elements of process schema
Provide high-level change operations
Correctness has to be checked after adaptation
Correctness-by-construction
No Assumption regarding structure of process schema
Process schema needs to be block-structured
132
Dynamic Change Bug
133
134
Correctness of Process Instance Changes
Ensuring Dynamic Correctness
Need for general correctness criterion
State Compliance
invoice make invoice
Schema S‘:
A B
C
D E F
send invoice
Schema S:
A B
C
D
E F
activated step
May the depicted schema change be propagated to the process instance?
[ReDa98, RRW08a, RRD04a, RRD04b]
134
135
Correctness of Process Instance Changes
Ensuring Dynamic Correctness
invoice make invoice
Schema S‘:
A B
C
D E F
send invoice
Schema S:
A B
C
D
E F
activated step
<A> , <B> , <D> Trace reproducible on new schema?
More complicated: loop backs
Further challenges: - How to efficiently check for compliance? - How to efficiently migrate process instances? [RRD04a, RRD04b]
135
x
+ + x x x
Execution Trace: σ3 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „MRT“, „X-ray“, „Sonography“>
Process Instance I3
Process Instance Level
Process Type Level
Process Schema S
Activity
XOR-Split/Join
AND-Split/Join
Patient Admission x Anamnesis &
Clinical Examination
Non Operative Therapy
Sonography
MRT
X-ray
Initial Treatment & Operation Planning
Non Operative Therapy 1
Operative Treatment
Discharge & Documentation
+ + x x
x
x
+
clinicalSuspicionOf CruciateRupture = „Yes“
cruciateRupture = „Yes“ and operationIndicated = „Yes“
I3 is not state compliant with change
Delete (I3, MRT)
136
Correctness of Process Instance Changes
[ReDa98]
136
User Assistance & Change Reuse (1)
The ProCycle (= ADEPT + CBRFlow) Approach for Assisting Users in Defining and Reusing Changes:
Annotate ad-hoc changes with information about the reasons for their introduction
Support users in retrieving past ad-hoc changes applied in similar context
Assist users in reusing a past ad-hoc change when coping with an exceptional situation
137
[RWR+05, WRW+09, WRR+05, WRW06, WWB04]
137
Patient Admission
Anamnesis & Clinical Examination
Non Operative Therapy
Sonography
MRT
X-ray
Initial Treatment & Operation Planning
Non Operative Therapy 1
Operative Treatment
Discharge & Documentation
Process Instance I1 Delete(I1,MRT)
pdc1 = The treatment of cruciate ruptures routinely includes a magnetic resonance tomography (MRT), an X-ray and a sonography. However, for a particular patient the MRT may have to be skipped as the respective patient has a cardiac pacemaker. solc1 = <Delete(SI,MRT)> qaSetc1= {(Does the patient have a cardiac pacemaker?, patient.problemList.hasPacemaker = ‘Yes‘)}
freqc1 = 1
Cas
e c 1
Memorization of instance deviations including their application context
Application Context Model
+
x x
+ x x
138
User Assistance & Change Reuse (2)
138
List of Question with Possible Answers
Answer Questions with Answer Expressions
Process participant
Arbeitsliste Tätigkeit 1 Tätigkeit 2 Tätigkeit 3 Tätigkeit 4
Exception for Instance I
Create List of Questions with Possible Answers
Calculate Similarity and Rank Cases
Add answered questions to query qu
Answer Question
Semi-automated retrieval of similar instance deviations using conversational case-based reasoning
Initiate Case Retrieval
Show Ranked Cases +
CCBR Component
139
User Assistance & Change Reuse (3)
139
qaSetc1 = {(Does the patient have a cardiac pacemaker?, Patient.problemList.hasPacemaker = 'Yes')}
List of Questions with Possible Answers Question Possible Answers
Does the patient have a cardiac pacemaker? {Patient.problemList.hasPacemaker = ‚Yes‘, OTHERANSWER}
Does the patient have fluid in the knee? {‚A significant amount‘, OTHERANSWER}
Does the patient have an acute effusion of the knee? {‚Yes‘, OTHERANSWER}
qaSetc2 = {(Does the patient have fluid in the knee?, 'A significant amount'),
(Does the patient have an acute effusion of the knee?, 'Yes')} Case c1
Case c2
Query qu
Question Given Answer Does the patient have a cardiac pacemaker? OTHERANSWER
List of Retrieved Cases for Query qu Case Appl. Context Similarity
c2 50%
c1 0%
Retrieving similar instance deviations based on the actual context
1||
),(),(*21),( +
−=
c
cc
qaSetqaSetqudiffqaSetqusamecqusim
Query qu‘
Question Given Answer Does the patient have a cardiac pacemaker? OTHERANSWER
Does the patient have fluid in the knee? ‚A significant amount‘
List of Retrieved Cases for Query qu‘ Case Appl. Context Similarity
c2 75%
c1 0%
140
User Assistance & Change Reuse (4)
140
Execution Trace: Patient Admission, Anamnesis & Clinical Examination, X-Ray, MRT
List of Retrieved Cases Case Similarity
c2 75% c2 does not have any effect, but is adjustable
c1 0% c1 is not case compliant and not adjustable
Retrieving similar instance deviations based on the actual context + status
Patient Admission x Anamnesis &
Clinical Examination
Non Operative Therapy
Sonography
MRT
X-ray
Initial Treatment & Operation Planning
Non Operative Therapy 1
Operative Treatment
Discharge & Documentation
+ + x
Process Instance I1
Are the instance deviations of these cases compliant with the process instance to be modified?
Is change Δc1
= <Delete(SI,MRT)>
applicable?
NO
Is change Δc2=<Insert(SI, Follow-Up Examination,
Non Operative Therapy, XOR-Join1), Insert(SI, Puncture, Follow-Up
Examination, XOR-Join1>
applicable? YES, but no effect
x
x
141
User Assistance & Change Reuse (5)
141
References
[ReDa98] Manfred Reichert, Peter Dadam: ADEPTflex-Supporting Dynamic Changes of Workflows Without Losing Control. J. Intell. Inf. Syst. 10(2): 93-129 (1998)
[RRD04a] Stefanie Rinderle, Manfred Reichert, Peter Dadam: Correctness criteria for dynamic changes in workflow systems - a survey. Data Knowl. Eng. 50(1): 9-34 (2004)
[RRD04b] Stefanie Rinderle, Manfred Reichert, Peter Dadam: Flexible Support of Team Processes by Adaptive Workflow Systems. Distributed and Parallel Databases 16(1): 91-116 (2004)
[RRW08] Stefanie Rinderle-Ma, Manfred Reichert, Barbara Weber: Relaxed Compliance Notions in Adaptive Process Management Systems. ER 2008: 232-247
[RWR+05] Stefanie Rinderle, Barbara Weber, Manfred Reichert, Werner Wild: Integrating Process Learning and Process Evolution - A Semantics Based Approach. Business Process Management 2005: 252-267
142
References
[WRR05] Barbara Weber, Stefanie Rinderle, Werner Wild, Manfred Reichert: CCBR-
Driven Business Process Evolution. ICCBR 2005: 610-624 [WRR08] Barbara Weber, Manfred Reichert, Stefanie Rinderle-Ma: Change
patterns and change support features - Enhancing flexibility in process-aware information systems. Data Knowl. Eng. 66(3): 438-466 (2008)
[WRW+09] Barbara Weber, Manfred Reichert, Werner Wild and Stefanie Rinderle-Ma: Providing Integrated Life Cycle Support in Process-Aware Information Systems. In: International Journal of Cooperative Information Systems 18 (2009) 1, pp. 115-165.
[WRW06] Barbara Weber, Manfred Reichert, Werner Wild: Case-Base Maintenance for CCBR-Based Process Evolution. ECCBR 2006: 106-120
Barbara Weber, Werner Wild, Ruth Breu: CBRFlow: Enabling Adaptive Workflow Management Through Conversational Case-Based Reasoning. ECCBR 2004: 434-448
143
Business Processes and Workflows Process Monitoring, Mining & Analysis
B A R B A R A W E B E R U N I V . O F I N N S B R U C K
144
(c) 2010 Barbara Weber
145
Activity Event User Timestamp
Patient Admission Start Garry 2007/09/08 15:30
Patient Admission Complete Garry 2007/09/08 15:45
Anamnesis & Clinical Examination
Start Helen 2007/09/09 11:00
Anamnesis & Clinical Examination
Complete Helen 2007/09/09 11:45
X-Ray Start Paula 2007/09/09 13:00
Sonography Start Sandy 2007/09/09 13:20
X-Ray Complete Paula 2007/09/09 14:00
Sonography Complete Sandy 2007/09/09 14:30
Non Operative Therapy 1
Start Peter 2007/09/10 09:00
Non Operative Therapy 1
Complete Peter 2007/10/10 09:45
Follow-up Examination Start Helen 2007/10/12 11:07
Follow-up Examination Complete Helen 2007/10/12 11:20
Puncture Start Helen 2007/10/12 11:21
x
+ + x x x
c.) Execution Log - Process Instance 4711
Process Instance 4711
a.) Process Model
Process Model S
6
1 2
10 4 5
7
8 9
3
x
+ + x x x
b.) Process Instances
1: Patient Admission 2: Anamnesis & Clinical Examination 3: Non Operative Therapy 4: x-Ray 5: MRT 6: Sonography
7: Non Operative Therapy 1 8: Initial Treatment & Operation Planning 9: Operative Therapy 10: Discharge & Documentation
clinicalSuspicionOf CruciateRupture = „Yes“
cruciateRupture = „Yes“ and operationIndicated = „Yes“
Enabled Completed Skipped Activity States:
Insert(S, Follow-up Examination, Non Operative Therapy, XOR-Join 1) Insert(S, Puncture, Follow-up Examination, XOR-Join 1)
Delete (S,MRT)
XOR-Join1
XOR-Join1
d.) Change Log - Process Instance 4711 Change TX
Applied Changes User Timestamp
001 Delete (S, MRT) Paula 2007/09/09 12:50
002 Insert(S, Follow-up Examination, Non Operative Therapy, XOR-Join 1)
Helen 2007/10/10 09:00
002 Insert(S, Puncture, Follow-up Examination, XOR-Join 1)
Helen 2007/10/10 09:00
Exe
cuti
on a
nd C
hang
e Lo
gs
- Res
tori
ng S
truc
ture
and
Sta
te o
f Pro
cess
Ins
tanc
es -
146
Process Instance 4711 2007/09/09 10:30
6
1 2
10
4
5
7
8 9
3
x
+ + x x x
XOR-Join1
146
Execution and Change Logs - Restoring Structure and State of Process Instances -
Activity Event User Timestamp
Patient Admission Start Garry 2007/09/08 15:30
Patient Admission Complete Garry 2007/09/08 15:45
Execution Log - Process Instance 4711, Log Entries before 2007/09/09 10:30
Process Instance 4711 2007/09/09 12:51
6
1 2
10
4
5
7
8 9
3
x
+ + x x x
XOR-Join1
147
147
Process Instance 4711 2007/09/09 10:30
6
1 2
10
4
5
7
8 9
3
x
+ + x x x
XOR-Join1
Execution and Change Logs - Restoring Structure and State of Process Instances -
Activity Event User Timestamp
Patient Admission Start Garry 2007/09/08 15:30
Patient Admission Complete Garry 2007/09/08 15:45
Change TX
Applied Changes User Timestamp
001 Delete (S, MRT) Paula 2007/09/09 12:50
Execution Log: Log Entries between 2007/09/09 10:30 and 2007/09/09 12:45
Change Log: Log Entries between 2007/09/09 10:30 and 2007/09/09 12:45
Activity Event User Timestamp
X-Ray Start Paula 2007/09/09 13:00
Sonography Start Sandy 2007/09/09 13:20
X-Ray Complete Paula 2007/09/09 14:00
Sonography Complete Sandy 2007/09/09 14:30
Non Operative Therapy 1
Start Peter 2007/09/10 09:00
Non Operative Therapy 1
Complete Peter 2007/10/10 09:45
Execution Log: Log Entries between 2007/09/09 12:45 and 2007/10/10 09:46
Process Instance 4711 2007/09/09 12:51
6
1 2
10
4
5
7
8 9
3
x
+ + x x x
XOR-Join1
148
Execution and Change Logs - Restoring Structure and State of Process Instances -
Change Log: Log Entries between 2007/09/09 10:30 and 2007/09/09 12:45
Process Instance 4711 2007/10/10 09:46
6
1 2
10
4
5
7
8 9
3
x
+ + x x x
11 12
11: Follow-up Examination 12: Puncture
XOR-Join1
Change TX
Applied Changes User Timestamp
002 Insert(S, Follow-up Examination, Non Operative Therapy, XOR-Join 1)
Helen 2007/10/10 09:00
002 Insert(S, Puncture, Follow-up Examination, XOR-Join 1)
Helen 2007/10/10 09:00
Design-time (a-priori) and run-time (a-posteriori) questions
processdesign
implementation/configuration
processenactment
diagnosis
Run-time Design-time
- process mining - verification - validation - performance analysis
149
Process mining can be used for: Process discovery (What is the process?) Conformance Testing (Are we doing what was specified?) Log verification (Is there any undesired behavior?)
process mining
Start
Register order
Prepareshipment
Ship goods
(Re)send bill
Receive paymentContactcustomer
Archive order
End
Process Mining
150
informationsystem
operationalprocess
processmodels
eventlogs
models
processdiscovery
conformancetesting
records
configures
supports/controls
(un)desiredproperties
log-based verification
refers to
What can Process Mining be used for?
151
MXML Format
152
Process Discovery – Reversing the Process
153
1) basic performance metrics
2) process model Start
Register order
Prepareshipment
Ship goods
(Re)send bill
Receive paymentContactcustomer
Archive order
End
3) organizational model 4) social network
5) performance characteristics
If …then …
153 [ARS05, ARV+10, AWM04, GGM+07, GGP+06, HeKa04, LRW10, MWA07, Sch04, WWA+10]
154
A) Original Process Model
Original Process Model S
6
1 2
10 4 5
7
8 9
3
x
+ + x x x
1: Patient Admission 2: Anamnesis & Clinical Examination 3: Non Operative Therapy 4: x-Ray 5: MRT 6: Sonography
7: Non Operative Therapy 1 8: Initial Treatment & Operation Planning 9: Operative Therapy 10: Discharge & Documentation
clinicalSuspicionOf CruciateRupture = „Yes“
cruciateRupture = „Yes“ and operationIndicated = „Yes“
XOR-Join1
B) Discovered Process Model
Activities FollowUpExamination and Puncture are not part of the original model, but appear in 132 traces
Activity MRT is executed less frequently than X-Ray and Sonography, i.e., it has been deleted for some of the instances
Proc
ess
Dis
cove
ry
- Heu
rist
ic M
iner
-
[WeAa03]
Conformance Testing
Registerorder
Prepareshipment
Shipgoods
Receivepayment
(Re)sendbill
Contactcustomer
Archiveorder
Materialis released
TO itemconfirmed
withoutdifferences
Warehouse/Stores
Transferorderitem
is confirmed
Paymentmust
be effected
PurchaseRequisition
Requirementfor materialhas arisen
Requisitionreleased
for schedulingagreement
schedule/SA release
InvoiceVerification
Purchaserequisitionreleased
for purchaseorder
Inbounddeliveryentered
Goodsreceived
Goodsreceiptposted
GoodsReceipt
Purchaseorder
created
Purchasing
Invoicereceived
Conformance Testing - Example -
156
Log based verification
Can there any undesired properties be observed in the log? 157 [ABD07]
Lecture Workflow Management by Will van der Aalst (Univ. of Eindhoven), http://www.workflowcourse.com
Some slides of the process mining part are based on
References
[ABD07] Wil M. P. van der Aalst, H. T. de Beer, Boudewijn F. van Dongen: Process Mining and Verification of Properties: An Approach Based on Temporal Logic. OTM Conferences (1) 2005: 130-147
[ADH+03] W.M.P. van der Aalst, B.F. van Dongen, J. Herbst, L. Maruster, G. Schimm, and A.J.M.M. Weijters. Workflow Mining: A Survey of Issues and Approaches. Data and Knowledge Engineering , 47(2):237-267, 2003.
[ARS05] Wil M. P. van der Aalst, Hajo A. Reijers, Minseok Song: Discovering Social Networks from Event Logs. Computer Supported Cooperative Work 14(6): 549-593 (2005)
[ARV+10] Wil M. P. van der Aalst, Vladimir Rubin, H. M. W. Verbeek, Boudewijn F. van Dongen, Ekkart Kindler, Christian W. Günther: Process mining: a two-step approach to balance between underfitting and overfitting. Software and System Modeling 9(1): 87-111 (2010)
[AWM04] W.M.P. van der Aalst, A.J.M.M. Weijters, and L. Maruster. Workflow Mining: Discovering Process Models from Event Logs. IEEE Transactions on Knowledge and Data Engineering 16(9):1128-1142, 2004.
References
[GGM+07] Gianluigi Greco, Antonella Guzzo, Giuseppe Manco, Domenico
Saccà: Mining unconnected patterns in workflows. Inf. Syst. 32(5): 685-712 (2007)
[GGP06] Gianluigi Greco, Antonella Guzzo, Luigi Pontieri, Domenico Saccà: Discovering Expressive Process Models by Clustering Log Traces. IEEE Trans. Knowl. Data Eng. 18(8): 1010-1027 (2006)
[HeKa04] Joachim Herbst and Dimitris Karagiannis: Workflow Mining with InWoLvE. Computers and Industry 53(3): 245-264 (2004).
[LRW10] Chen Li, Manfred Reichert, Andreas Wombacher: The Minadept Clustering Approach for Discovering Reference Process Models Out of Process Variants. Int. J. Cooperative Inf. Syst. 19(3-4): 159-203 (2010)
[MWA07] Ana Karla A. de Medeiros, A. J. M. M. Weijters, Wil M. P. van der Aalst: Genetic process mining: an experimental evaluation. Data Min. Knowl. Discov. 14(2): 245-304 (2007)
References
[PiGo04] S. Pinter and M. Golani: Discovering workflow models from activities' lifespans. Computers and Industry 53(3): 283-296 (2004).
[RoAa08] Anne Rozinat, Wil M. P. van der Aalst: Conformance checking of processes based on monitoring real behavior. Inf. Syst. 33(1): 64-95 (2008)
[Sch04] Guido Schimm: Mining exact models of concurrent workflows. Computers and Industry 53(3): 265-281 (2004).
[WeAa03] A.J.M.M. Weijters and W.M.P. van der Aalst. Rediscovering Workflow Models from Event-Based Data using Little Thumb. Integrated Computer-Aided Engineering, 10(2):151-162, 2003.
[WWA+10] Lijie Wen, Jianmin Wang, Wil M. P. van der Aalst, Biqing Huang, Jiaguang Sun: Mining process models with prime invisible tasks. Data Knowl. Eng. 69(10): 999-1021 (2010)
Business Processes and Workflows Process Evolution
B A R B A R A W E B E R U N I V . O F I N N S B R U C K
162
Drivers
Evolution
External Internal Changing Business Context
Changing Technological Context
Changing Legal Context
Organizational Learning
Real-world Process PAIS
Design Errors
Technical Problems
Poor Internal Quality
represented in
provide feedback to
163
Schema Evolution 164
164
Change Support Features Schema Evolution, Version Control and Instance Migration
Schema Evolution Changes at the process type level
How to deal with running instances when adapting the original process schema? Scenario 1: No version control Scenario 2: Co-existence of instances of old / new schema Scenario 3: Change propagation and instance migration
165
165
Schema is overwritten and instances are migrated
A B D
C
+ + E F X
Y
A B D
C
+ + E F X
Y
Type change overwrites schema S
Process Schema S’
Schema Evolution
Process Schema S
Process Instance I1
Change is propagated to
all running process instances
Process Instance I2
Process Instance I1
Process Instance I2
Insert X between A and B Insert Y between C and AND-Join1
AND-Split1 AND-Join1
A B D
C
+ + E F
A B D
C
+ + E F
A B D
C
+ + E F
A B D
C
+ + E F X
Y
AND-Split1 AND-Join1
Inconsistent state
Scenario 1 - No Version Control 166
166
Co-existence of instances of different schema versions
Scenario 2 - Version Control
A B D
C
+ + E F X
Y
Type change results into a new version of schema S
Process Schema S’
Schema Evolution
Process Schema S
Process Instance I1
Process Instance I2
Process Instance I4
Process Instance I5
Old instances remain with schema S Instances created from S (before schema evolution) Instances created from S’ (after schema evolution)
AND-Split1 AND-Join1
A B D
C
+ + E F A B D
C
+ + E F X
Y
A B D
C
+ + E F
A B D
C
+ + E F A B
D
C
+ + E F X
Y
Insert X between A and B Insert Y between C and AND-Join1
AND-Split1 AND-Join1
167
167
Compliant instances are migrated to the new schema
Scenario 3 – Instance Migration
Type change results into a new version of schema S
Process Schema S‘
Schema Evolution
Process Schema S
Process Instance I1
Propagation of compliant
process instances to schema S’
(incl. state adaptations)
Process Instance I2
Process Instance I1
Migration of compliant process instances to S’
AND-Split1 AND-Join1
A B D
C
+ + E F A B D
C
+ + E F X
Y
A B D
C
+ + E F
A B D
C
+ + E F Process Instance I2 not compliant with S’
A B D
C
+ + E F X
Y
Insert X between A and B Insert Y between C and AND-Join1
AND-Split1 AND-Join1
168
[RRD04a] 168
Process Model Refactoring
(1) Identify refactoring opportunities
(2) Determine which refactoring should be applied
(3) Ensure that the applied refactoring preserves model behavior
(4) Apply the refactoring
(5) Assess the effect of the refactoring on the quality characteristics of the process model repository
169
Catalogue of Process Model Smells
PMS5: Lazy Process Model
PMS8: Frequently Occurring Variant Change
[WeRe08, WRR+xx] 170
Process Model Smells: Example
PMS3: Redundant Process Fragment
171
Process Model Smells: Example
PMS1: : Non Intension Revealing Naming of Activity
172
Process Model Smells: Example
PMS4: Large Process Model
173
Catalogue of Process Model Refactorings
RF5: Replace Process Fragment by Reference
RF8: Remove Redundancies
RF9: Generalize Variant Change
RF11: Pull up Instance Change
174
175
Process Model Smells: Example
(c) 2010-2011 Barbara Weber, Manfred Reichert
PMS3: Redundant Process Fragment RF5: Replace Process Fragment by
Reference
Process Model Smells: Example
PMS1: : Non Intension Revealing Naming of Activity
176
Process Model Smells: Example
PMS4: Large Process Model
177
Process Model After Refactoring
178
Instance I1
A
D
B
x x E C
Instance I1
A
D
B
x x E C
Schema S‘:
A
D
B
x x C
Traditional Process Lifecycle Support
Cre
ate
Inst
ance
s
Process Execution
Process engineer / Process administrator
Process participant
Arbeitsliste Tätigkeit 1 Tätigkeit 2 Tätigkeit 3 Tätigkeit 4
Integrated Lifecycle Support for Adaptive and Dynamic Processes (1)
Schema S:
A
D
B
x x E C
Instance I1
A
D
B
x x E C
Execution Log
Process Monitoring
179
179
Instance I1
A
D
B
x x E C
Instance I1
A
D
B
x x E C
Schema S‘:
A
D
B
x x C
Lifecycle Support in adaptive PAISs
Cre
ate
Inst
ance
s
Process Execution
Process engineer / Process administrator
Process Monitoring
Change Log
Instance-specific Change
Exception: Delete (I1, E)
Process participant
Arbeitsliste Tätigkeit 1 Tätigkeit 2 Tätigkeit 3 Tätigkeit 4
Cha
nge
Prop
agat
ion
Schema S:
A
D
B
x x E C
Instance I1
A
D
B
x x E C
Execution Log
180
Integrated Lifecycle Support for Adaptive and Dynamic Processes (2)
180
Instance I1
A
D
B
x x E C
Instance I1
A
D
B
x x E C
Schema S‘:
A
D
B
x x C
Revised lifecycle for dynamic processes – The ProCycle Approach
Cre
ate
Inst
ance
s
Process Execution
Process engineer / Process administrator
Process Monitoring
Change Log
Instance-specific Change
Exception: Delete (I1, E)
Process participant
Arbeitsliste Tätigkeit 1 Tätigkeit 2 Tätigkeit 3 Tätigkeit 4
Cha
nge
Prop
agat
ion
Memorization and Change Reuse
Case Base
Derive Process Type Change
Schema S:
A
D
B
x x E C
Instance I1
A
D
B
x x E C
Execution Log
Migrate Case Base
Integrated Lifecycle Support for Adaptive and Dynamic Processes (3)
181 [WRW+09]
References
• [RRD04a] Stefanie Rinderle, Manfred Reichert, Peter Dadam: Correctness criteria for dynamic changes in workflow systems - a survey. Data Knowl. Eng. 50(1): 9-34 (2004)
• [WeRe08] B. Weber and M. Reichert: Refactoring Process Models in Large Process Repositories In Proc. CAiSE'08 (2008), pp. 124-139
• [WRR+11] B. Weber and M. Reichert and H. Reijers and J. Mendling: Refactoring Large Process Model Repositories Computers and Industry 62(2011) 5, pp. 467-486.
• [WRW+09] Weber B., Reichert M., Wild W. and Rinderle-Ma S.: Providing Integrated Life Cycle Support in Process-Aware Information Systems. In: International Journal of Cooperative Information Systems 18 (2009) 1, pp. 115-165.
182
B A R B A R A W E B E R U N I V . O F I N N S B R U C K
Business Processes and Workflows Loosely Specified Processes
183
Process Spectrum
Process Spectrum From fully predictable and highly repetitive to Fully unpredictable and non repetitive
184
Processes on the right side of the spectrum are mostly knowledge-intensive
Unpredictability Course of action depends on situation-specific parameters
Non-repeatability Two process instances hardly look the same
Emergence Future course of action depends on knowledge gained
through activity execution
Knowledge-intensive Processes
185
Loosely specified Processes
To deal with unpredictability, non repeatability and emergence loosely specified processes keep (parts) of the process unspecified during build-time
Loosely specified processes are characterized by decision deferral Decision on how the process exactly looks like are deferred to the
run-time
186
Taxonomy of Decision Deferral
187
Decision Deferral Patterns
188
Late Selection Pattern
189
Late Selection – The Worklets Approach
190 [AHE+06]
Late Selection – Static Process-based Composition
191 [CPE+08, AVM+04, CaSh01, Kli00]
Late Modeling
192
Late Modeling – Pockets of Flexibility
193 [SSO01, SSO05]
Late Modeling – Interleaved Routing
194 [RHA+06]
Late Modeling – Dynamic Process-based Composition
195 [SuWe03, ZNB+08]
Ad-hoc Composition - Declare
196 [AaPe06, PSS+07]
Iterative Refinement - Alaska
197 [WZP+09]
Iterative Refinement – Hierarchical Task Networks
198 [ELM+01]
References
[AaPe06] van der Aalst, W., Pesic, M.: DecSerFlow: Towards a Truly Declarative Service Flow Language. Tech. Rep., BPMcenter.org (2006) [AHE+06] Adams, M., ter Hofstede, A., Edmond, D., van der Aalst, W.: A Service-Oriented Implementation of Dynamic Flexibility in Workflows. In: Proc. Coopis’06 (2006) [AVM+04] R. Aggarwal, Kunal Vernal, John Miller and William Milnor : Constraint-driven Web Service Composition in METEOR-S: In Proc. SCC‘04, pp. 23-30. [CaSa01] Fabio Casati, Ming-Chien Shan: Dynamic and adaptive composition of e-services. Inf. Syst. 26(3): 143-163 (2001) [CPE+08] Gerardo Canfora, Massimiliano Di Penta, Raffaele Esposito, Maria Luisa Villani: A framework for QoS-aware binding and re-binding of composite web services. Journal of Systems and Software 81(10): 1754-1769 (2008) van Elst; Andreas Lauer; Heiko Maus; Sven Schwarz; Michael Sintek, A.A.A.B.L.: Frodo: A framework for distributed organizational memories. milestone 1: Requirements analysis and system architecture. Dfki document (2001). URL http://www.dfki.unikl.de/dfkidok/publications/D/01/01/abstract.html [Kli00] Justus Klingemann: Controlled Flexibility in Workflow Management. CAiSE 2000: 126-141
199
References
[PSS+07] Pesic, M., Schonenberg, M., Sidorova, N., van der Aalst, W.: Constraint-Based Workflow Models: Change Made Easy. In: Proc. CoopIS’07, pp. 77–94 (2007) [RHA+06] 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. [SSO01] Sadiq, S., Sadiq, W., Orlowska, M.: Pockets of flexibility in workflow specifications. In: Proc. ER’01, pp. 513–526 (2001) [SSO05] Sadiq, S., Sadiq, W., Orlowska, M.: A Framework for Constraint Specification and Validation in Flexible Workflows. Information Systems 30(5), 349 – 378 (2005) [SuWe03] Hilmar Schuschel, Mathias Weske: Integrated Workflow Planning and Coordination. DEXA 2003: 771-781 [ZNB+08] Liangzhao Zeng, Anne H. H. Ngu, Boualem Benatallah, Rodion M. Podorozhny, Hui Lei: Dynamic composition and optimization of Web services. Distributed and Parallel Databases 24(1-3): 45-72 (2008)
200
B A R B A R A W E B E R U N I V . O F I N N S B R U C K
Business Processes and Workflows Declarative Processes
201
Declarative Processes
Declarative approaches allow for Late Composition of business processes and are thus highly flexible
Advantages commonly attributed to declarative processes Support for partial workflows (Wainer et al. 2004 [WBB04])
Allow users to defer decisions to run-time (Weber et al. 2008 [WeRR08])
Absence of over-specification (Pesic et al. 2007 [PSSA07])
More maneuvering room for end users (Pesic et al. 2007 [PSSA07]),
202
202
Declarative Processes
Instead of describing exactly how a business process should be executed, declarative processes describe the activities to be executed and constraints prohibiting undesired behavior (e.g., selection
constraints, ordering constraints, resource constraints)
203
203 [PSSA07]
Modeling Declarative Processes
B A B C
D E F
Declarative Process Model S
A B NOT CO-EXISTENCE A and B are mutually exclusive
A RESPONSE If A is executed, B needs to executed afterwards
Execution trace producible on S: σ1 = < A, A, D, E, A> σ2 = < B, C, F, E, B> σ3 = < B, E, F> Execution trace not producible on S: σ4 = < A, C, E, A> σ5 = < B, D, C> σ6 = < A, D, B, F, E>
A B
C F
C1
C2
Activities A
Constraints C
Legend
C2 C2 C1
204
Modeling Declarative Processes
5 Major Categories Selection Constraints Relation Constraints Branching Constraints Negation Constraints Choice Constraints
205
Activity a must occur at least n times in every trace
existence(a, n) a
n..*
Activity a must occur at most n times in every trace
at_most(a, n) a
0..n
Activity a must occur exactly n times in every trace
exactly(a, n) a n
Example: existence(A,1) Supported traces, e.g.: <A>,<A,A,A> Unsupported trace, e.g.: <>
Example: at_most(A,3) Supported traces, e.g.: <>,<A>,<A,A>,<A,A,A> Unsupported trace, e.g.: <A,A,A,A>
Example: exactly(A,2) Supported trace, e.g.: <A,A> Unsupported traces, e.g.,: <A>,<A,A,A>
Activity a must be the first executed activity in every trace init(a)
a init
Example: init(A) Supported trace, e.g.: <A,C,D,B> Unsupported trace, e.g.: <D,C,B,A> SE
LEC
TIO
N C
ON
STR
AIN
TS
b a
b a
If a is executed, b needs to be executed afterwards (but not necessarily directly after)
response(a, b) Example: response(A,B) Supported traces, e.g.: <A,B>,<A,A,A,B>,<B> Unsupported trace, e.g.: <A>
Activity b needs to be preceded by activity a
precedence(a, b) Example: precedence(A,B) Supported traces, e.g.: <A,B>,<A,B,B,B>,<A> Unsupported trace, e.g.: <B>
If a is executed, b needs to be executed afterwards (but not necessarily directly after); activity b needs to be preceded by activity a
succession(a, b) Example: succession(A,B) Supported traces, e.g.: <A,B>,<A,A,A,B>,<A,B,B,B> Unsupported traces, e.g.: <A>,<B>
b a If activity a is executed, activity b needs to be executed either before or after a
respondedExistence(a, b) Example: respondedExistence(A,B) Supported traces, e.g.: <A,B>,<B,A>,<A,B,A>,<B> Unsupported trace, e.g.: <A>
b a
RELATION CONSTRAINTS
b1 a
If a is executed, at least one activity from set {b1,..,bn} has to be executed afterwards (but not necessarily directly after)
response(a, {b1,..,bn}) Example: response(D,{E,F}) Supported traces, e.g.: <D,E>,<D,F>,<F>,<D,E,F> Unsupported trace, e.g.: <D>
bn
If one activity from set {a1,..,am} is executed, at least one activity from set {b1,..,bn} has to executed afterwards. To execute an activity from set {b1,..,bn}, at least one activity from set {a1,..,nm} has to be executed before. succession ({a1,..,am},
{b1,..,bn})
Example: succession({D},{E,F}) Supported traces, e.g.: <D,F>,<E,F>,<D,E,F> Unsupported traces, e.g.: <D>,<E>,<F>
a1
am
…
… b1
bn
…
BRANCHING CONSTRAINTS
Activity a and b cannot co-occur in any trace
neg_coexistence(a, b)
b a
a b
Example: neg_coexistence(A,B) Supported traces, e.g.: <A>,<B> Unsupported traces, e.g.: <A,B>,<B,A>
If activity a is executed, activity b must not be executed afterwards anymore
neg_response(a, b) Example: neg_response(A,B) Supported traces, e.g.: <A>,<B>,<B,A> Unsupported trace, e.g.: <A,B>
NEGATION CONSTRAINTS
At least m distinct activities out of n activities from set {a1,…,an}, m ≤ n must be executed
a1
a2
an
…
m of n
Example: choice(2-of-3, {A,B,C}) Supported traces, e.g.: <A,B>,<B,C>,<A,C>,<A,B,C> Unsupported traces, e.g.: <A>,<B,B>
choice(m-of-n, {a1,..,an})
Exactly m distinct activities out of n activities from set {a1,…,an}, m ≤ n must be executed
a1
a2
an
…
m of n
Example: choice(2-of-3, {A,B,C}) Supported traces, e.g.: <A,B>,<B,C>,<A,C> Unsupported traces, e.g.: <A>,<B,B>,<A,B,C>
exact_choice(m-of-n, {a1,..,an})
CHOICE CONSTRAINTS
Enabled Activities
B A B C
D E F
Declarative Process Model S A B NOT CO-EXISTENCE
A and B are mutually exclusive
A RESPONSE If A is executed, B needs to executed afterwards
A B
C F
C1
C2
Activities A
Constraints C Partial Trace Set of Enabled Activities
< > {A, B, C, D, E, F}
<A> {A, C, D, E, F} B is not included since partial trace <A, B> violates constraint C1
<A, C> {A, C, D, E, F} B is not included since partial trace <A, B> violates constraint C1
211
A B C D E F
Execution Termination
Tim
elin
e
Process Instantiation
Process Termination
A B C
D E F
Declarative Process Model S
A B
C F
C1
C2
Activities A
Constraints C
Activities A, B, C, D, E, F and G are enabled
Instance I can terminate, i.e., no
termination constraints violated
212
A B C D E F
Execution Termination
Tim
elin
e
Process Instantiation
Process Termination
A B C
D E F
Declarative Process Model S
A B
C F
C1
C2
Activities A
Constraints C
A A started A completed
As A is executed B cannot be executed
any longer
No termination constraint violations, i.e., I can terminate
213
A B C D E F
Execution Termination
Tim
elin
e
Process Instantiation
Process Termination
A B C
D E F
Declarative Process Model S
A B
C F
C1
C2
Activities A
Constraints C
A A started A completed
C started C completed C
Constraint violations, i.e., I cannot terminate
214
A B C D E F
Execution Termination
Tim
elin
e
Process Instantiation
Process Termination
A B C
D E F
Declarative Process Model S
A B
C F
C1
C2
Activities A
Constraints C
A A started A completed
C started C completed C
E started E completed E
Constraint violations, i.e., I cannot terminate
215
A B C D E F
Execution Termination
Tim
elin
e
Process Instantiation
Process Termination
A B C
D E F
Declarative Process Model S
A B
C F
C1
C2
Activities A
Constraints C
A A started A completed
C started C completed C
E started E completed E
F started F completed F
No constraint violations, i.e., I can
terminate
216
Overriding of Constraints
A B C D E F
Execution Termination
Tim
elin
e
Process Instantiation
Process Termination
A B C
D E F
Declarative Process Model S
A B
C F
C1
C2
Activities A
Constraints C
A A started A completed
C started C completed C
E started E completed E
!
Warning “F not executed after C”
!
Soft constraints can be ignored during
process execution
Users terminating process instance I are
informed about constraint violation
217
218
1
Declarative Process Model S
B
A B NOT CO-EXISTENCE A and B are mutually exclusive
A RESPONSE If A is executed, B needs to executed afterwards
Execution trace Instance I1: σ1 = < A, C>
S [ΔS>S ‘ with ΔS = <addConstraint(exactly_1(A)), addConstraint(respondedExistence(D,E))>
EXACTLY_1 A must be executed exactly once A
σ1 is producible on S‘
Migrate
Execution Trace Instance I2: σ2 = < A, C, A, F>
Execution Trace Instance I3: σ3 = < A, D, F>
σ2 not producible on S‘
σ3 is producible on S‘
Migrate
Don‘t Migrate
A B
C D
E F
A B
C F
C1
C2
Activities A Constraints C
Declarative Process Model S‘
A B
C D
F
A B
C F
C1
C2
Activities A Constraints C
E
D
1 A C3
E C4
Legend
B A RESPONDED EXISTENCE If A is executed, B needs to executed either before or after A
Ad-hoc changes and Schema Evolution
219
1
Declarative Process Model S
B
A B NOT CO-EXISTENCE A and B are mutually exclusive
A RESPONSE If A is executed, B needs to executed afterwards
Execution trace Instance I1: σ1 = < A, C>
S [ΔS>S ‘ with ΔS = <addConstraint(exactly_1(A)), addConstraint(respondedExistence(D,E))>
EXACTLY_1 A must be executed exactly once A
σ1 is producible on S‘
Migrate
Execution Trace Instance I2: σ2 = < A, C, A, F>
Execution Trace Instance I3: σ3 = < A, D, F>
σ2 not producible on S‘
σ3 is producible on S‘
Migrate
Don‘t Migrate
A B
C D
E F
A B
C F
C1
C2
Activities A Constraints C
Declarative Process Model S‘
A B
C D
F
A B
C F
C1
C2
Activities A Constraints C
E
D
1 A C3
E C4
Legend
B A RESPONDED EXISTENCE If A is executed, B needs to executed either before or after A
Ad-hoc changes and Schema Evolution
Changed regulations require a
modification.
Modification may refer to a single instance (ad-hoc
change) or all process instances (schema
evolution)
Changes are only applied to instances which are compliant with change
The Declare System
van der Aalst, Pesic and Schonenberg 2009 [APS09]
Composing Declarative Processes with Declare
Executing Declarative Processes with Declare
220
220
Late Composition in Alaska Simulator (1)
A B
C
D
E
F
Declarative Process Model
Calendar
Process Instance I1
New Process Instance I1 is created
A C
D E F
Available Actions B
A
User can partially model the process
instance
Current Problems
221
221
Late Composition in Alaska Simulator (2)
A B
C
D
E
F
Declarative Process Model
Calendar
Process Instance I1
A C
D E F
Available Actions B
A
Process Instance is incrementally
validated
C
Current Problems
F must be executed
222
222
A B
C
D
E
F
Declarative Process Model
Calendar
Process Instance I1
A C
D E F
Available Actions B
C
Current Problems
F
User resolves problems A
223
Late Composition in Alaska Simulator (3)
223
A B
C
D
E
F
Declarative Process Model
Calendar
Process Instance I1
A C
D E F
Available Actions B
A
C
Current Problems
F
User starts execution of Instance I1
224
Late Composition in Alaska Simulator (4)
224
A B
C
D
E
F
Declarative Process Model
Calendar
Process Instance I1
A C
D
E F
Available Actions B
A
C
Current Problems
F
Instance I1 can be altered at all times
E
D
225
Late Composition in Alaska Simulator (5)
225
A B
C
D
E
F
Declarative Process Model
Calendar
Process Instance I1
A C
D
E F
Available Actions B
A
C
Current Problems
F
Execution of Instance I1 is proceeded
E
D
226
Late Composition in Alaska Simulator (5)
226
The Alaska Simulator
Is an interactive planning tool providing support for late composition
Uses journey as a metaphor for business processes
Actions, accommodations and routes correspond to
activities
Selection, ordering and resource constraints are relevant in both settings
Information on benefits (i.e., business value), cost and duration are essential for
decision making
Effectively handling uncertainty is
fundamental in both domains
http:\\alaskasimulator.org
Weber, Zugal, Pinggera and Wild 2009 [WZP+09]
Both the planning of a journey and the
execution of a business process is oriented
towards a goal
227
227
Declarative workflows provide a lot of flexibility to the end user, but on the other hand require adequate user support
Schonenberg, Weber, Aalst and van Dongen 2008 [SWD+08]
Process-aware Information System (PAIS)
Process Engine
Recommendation Service
Partial case, enabled activities
Recommendation result (ordered enabled activities)
Event Log logs
uses
Optimization Goal
Plugin
Plugin
Plugin
Assistance and Support for Declarative Workflows 228
228
References
[AaPe06] W.M.P. van der Aalst and M. Pesic : DecSerFlow: Towards a Truly Declarative Service Flow Language. In WS-FM 2006, 2006, pp 1-23.
[APS09] Wil M. P. van der Aalst, Maja Pesic, Helen Schonenberg: Declarative workflows: Balancing between flexibility and support. Computer Science - R&D 23(2): 99-113 (2009)
[PSS+07] Pesic, M., Schonenberg, M., Sidorova, N., van der Aalst, W.: Constraint-Based Workflow Models: Change Made Easy. In: Proc. CoopIS’07, pp. 77–94 (2007)
[SWD+08] Helen Schonenberg, Barbara Weber, Boudewijn F. van Dongen, Wil M. P. van der Aalst: Supporting Flexible Processes through Recommendations Based on History. BPM 2008: 51-66
[WRR08] Barbara Weber, Manfred Reichert, Stefanie Rinderle-Ma: Change patterns and change support features - Enhancing flexibility in process-aware information systems. Data Knowl. Eng. 66(3): 438-466 (2008)
229
References
[WBB04] Jacques Wainer, Fábio de Lima Bezerra, Paulo Barthelmess: Tucupi: a flexible workflow system based on overridable constraints. SAC 2004: 498-502
[WRZ+09] Barbara Weber, Hajo A. Reijers, Stefan Zugal, Werner Wild: The Declarative Approach to Business Process Execution: An Empirical Test. CAiSE 2009: 470-485
230
--- Coming soon ---
Enabling Flexibility in Process-aware
Information Systems Challenges, Methods, Technologies
Springer 2012
by
Manfred Reichert and Barbara Weber