View
221
Download
1
Tags:
Embed Size (px)
Citation preview
Constraint-Based Workflow ModelsChange Made Easy!
Maja PesicHelen Schonenberg Natalia SidorovaWil van der Aalst
Eindhoven University of Technology
supportcontrolflexibility
Workflows, what people want ...
Classical trade-off
ad-hocworkflow
groupwareproductionworkflow
casehandling
low
high
flexibility supp
ort
"do whatever you want but get no support"
"support but no flexibility"
Three types of flexibility
• Defer (decide to decide later) –deferred choice– late binding (e.g., worklets)
• Change (decide to change model)–ad-hoc change–evolutionary change
• Deviate (decide to ignore model)–skip–redo–swap
Typical approach: procedural language + change
• Changes: ad-hoc (one instance) and evolutionary (whole process).
• Attempts to combine the best of both worlds.
• Supported by smart/mature systems like ADEPT.
• Problems:– Users cannot model!– Difficult to support.
s1
s2
s3
prepare_shipment
send_goods
send_bill
record_shipment
s4
s5
prepare_shipment
send_goods send_bill
record_shipment
p1
p3p2
p4 p5
p6
dynamic change bug
s1
s2
s3
prepare_shipment
send_goods
send_bill
record_shipment
s4
s5
prepare_shipment
send_goods send_bill
record_shipment
p1
p3p2
p4 p5
p6
s1
s2
s3
prepare_shipment
send_goods
send_bill
record_shipment
s4
s5
prepare_shipment
send_goods send_bill
record_shipment
p1
p3p2
p4 p5
p6
s1
s2
s3
prepare_shipment
send_goods
send_bill
record_shipment
s4
s5
prepare_shipment
send_goods send_bill
record_shipment
p1
p3p2
p4 p5
p6
s1
s2
s3
prepare_shipment
send_goods
send_bill
record_shipment
s4
s5
prepare_shipment
send_goods send_bill
record_shipment
p1
p3p2
p4 p5
p6
s1
s2
s3
prepare_shipment
send_goods
send_bill
record_shipment
s4
s5
prepare_shipment
send_goods send_bill
record_shipment
p1
p3p2
p4 p5
p6
s1
s2
s3
prepare_shipment
send_goods
send_bill
record_shipment
s4
s5
prepare_shipment
send_goods send_bill
record_shipment
p1
p3p2
p4 p5
p6
?
dynamic change bug
An alternative approach based on constraints ...
forbidden behavior
deviations from the prescribed
model
IMPERATIVE MODEL
constraint constraint
constraint constr
aint
Basic idea
A B
Declarative notation(e.g., ConDec, DecSerFlow)
LTL semantics
Example: "existence response"
• OK:– [ ]– [A,B,C,D,E]– [A,A,A,C,D,E,B,B,B]– [B,B,A,A,C,D,E]– [B,C,D,E]
• NOK– [A]– [A,A,C,D,E]
A B
Example: "response"
• OK:– [ ]– [A,B,C,D,E]– [A,A,A,B,C,D,E]– [B,B,A,A,B,C,D,E]– [B,C,D,E]
• NOK– [A]– [B,B,B,B,A,A]
A B
Example: "precedence"
• OK:– [ ]– [A,B,C,D,E]– [A,A,A,C,D,E,B,B,B]– [A,A,C,D,E]
• NOK– [B]– [B,A,C,D,E]
A B
DECLARE
DECLARE
log
user
ProM
recommendation
executionrecommendation
YAWL
imperative processes
sub-process
language exportmodel export
Framework
Designer
Worklist
declarative processes
developmentverificationenactmentadaptation
http://is.tm.tue.nl/staff/mpesic/declare.htmhttp://www.yawl-system.com
Model with constraints
– (C.1) Always start with activity register client data.– (C.2) Activity bill must be executed at least once. – (C.3) Every room service must be billed. – (C.4) Every laundry service must be billed. – (C.5) If the client checks-out- she/he must be charged. – (C.6) Sometimes it is recommended that additional cleaning is also be billed. (---optional---)
C.1
C.2
C.4
C.5
C.3
C.6
• constraints can be:–mandatory
• imposed by DECLARE• can be fulfilled or temporarily violated
–optional• used as warnings for users• can be fulfilled or temporarily violated or
permanently violated
• at the end of the execution all mandatory constraints have to be fulfilled
(a) initial state (b) after "register client data"
(c) after "room service" (d) after "bill"
Change Made Easy ....
Flexibility
Three types of flexibility revisited
• Defer (decide to decide later)
• Change (decide to change model)
• Deviate (decide to ignore model)
Defer (decide to decide later)
Try to model this is your favorite business process modeling tool!
Change (decide to change model)
pray to become
holy
Jane:curse, curse, pray, curse
Mike:pray, become holy, pray
Tracy:become holy, pray
Deviate (decide to ignore model)
soft versus hard constraints(levels/warnings)
optional
Conclusion
• DECLARE supports different types of flexibility in a natural way:– Defer (decide to decide later) – Change (decide to change model)– Deviate (decide to ignore model)
• Avoids problems such as the dynamic change bug and can deal with situations where users will not change models.
• Fully implemented and integrated with ProM and YAWL.
• See vdaalst.com for papers and is.tm.tue.nl/staff/mpesic/declare.htm for software.