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.