Semantics and Verification of UML Activity Diagrams for Workflow ...

✬
✩
Semantics and Verification of
UML Activity Diagrams for
Workflow Modelling
Rik Eshuis
CRP Henri Tudor|LIASIT
rik.eshuis@tudor.lu
www.cs.utwente.nl/∼eshuis
January 6, 2003
✫
1
✪

✬
✩
Example UML activity diagram
questionnaire
received
Process
questionnaire
Register
Send
questionnaire
Evaluate
WAIT−1
[else]
after(2 weeks)
WAIT−2
WAIT−4
Archive
WAIT−3
[in(WAIT−2)]
[processing required]
Process
complaint
Check
Processing
[ok]
[else]
✫
2
✪

✬
✩
Workflow models
• no or little support for analysis of functional requirements
• no standard notation
UML activity diagrams
• useful for specifying workflow models, but:
• currently no formal semantics
• OMG semantics of UML activity diagrams is not intended for
workflow modelling
✫
3
✪

✬
✩
Goal
• define formal execution semantics for UML activity diagrams
• intended for workflow modelling
• use formal semantics to verify functional requirements
using model checking
✫
4
✪

✬
✩
Contents
• Background: workflow modelling and activity diagram syntax
• Semantics
• Verification
✫
5
✪

✬
✩
Workflow
• =operational business processes.
• Managed by workflow management system.
• Often specified by bubble-and-arrow notations.
• Petri nets have been proposed as formal counterpart of this.
• UML activity diagrams are a good alternative, once given a
formal semantics.
✫
6
✪

✬
Environment of WF system
✩
Workflow Specification
Database Specification
Workflow
Management System
(WFMS)
Database
Management System
(DBMS)
WFMS + Wf spec = WFS
DBMS + DB spec = DBS
Workflow System
(WFS)
local variables
Database System
(DBS)
activity
terminates
enable
activity
Create, Read,
Update, Delete
Application software
✫
User
7
✪

✬
✩
Architecture of WF system
event
Workflow System
event
Queue
event
time
Clock Manager Clock
time
Router
enable new activity
begin transaction
end transaction
control data
✫
8
✪

✬
Syntax of UML activity diagrams
✩
Points to initial state
Final state
Activity
state
Wait
state
Takes time
Non−interruptable
Finishes with termination event
May change case attributes
Takes time
Interruptable
Finished by event:
external, condition change, temporal.
Case attributes not changed:
[g]
[else]
XOR split
XOR join
AND split
AND join
✫
9
✪

✬
✩
Semantics
Requirements on formal execution semantics
• accurate, i.e. match workflow behaviour
• analysable, i.e. “small” finite state space
General assumptions for semantics
• workflow model prescribes behaviour of WFS
• WFS is reactive system
• WFS coordinates activities, but does not perform them
✫
10
✪

✬
Existing execution semantics
✩
e[c]/a
Statechart
Petri net
• Reactive step semantics of statecharts:
– state = waiting for event
– transition = responding to event (ECA rule)
• Token-game semantics of Petri nets:
– State (marking) = allocation of resources to places
– Transition = (exclusive) use of resources
• In a Petri net:
– Enabled transitions need not be taken,
– Behaviour is active rather than reactive.
✫
11
✪

✬
✩
Two semantics
We take the statechart semantics as starting point.
Requirements-level
WFS is black box
WFS reacts immediately to input
events
WFS routes instantaneously
WFS processes events in parallel
Implementation-level
WFS is white box
Requirements-level satisfies perfect synchrony:
time(event occurrence) = time(system reaction)
WFS does not react immediately
to input events
WFS does not route instantaneously
WFS processes events one by
one
✫
12
✪

✬
Semantics: Kripke structure (Clocked
Transition System)
✩
(Var,→,σ 0 ) with
• Var set of variables
• σ → σ ′ transition relation, with σ a valuation of Var
• σ 0 initial state
State of Kripke structure represents state of WFS. It consists of:
• Configuration: bag of active activity diagram nodes.
• Set of current event occurrences.
• Valuation of case variables.
• Current values of timers.
✫
13
✪

✬
✩
Step semantics
• Step = maximal, consistent, non-interfering bag of enabled
hyperedges.
• Step is taken in response to some event occurrences.
• Both semantics use step semantics but in a different way.
✫
14
✪

✬
✩
Requirements-level semantics
• All input events are processed at the same time
• Events generated in a step are responded to in next step.
• Maximal sequence of steps (superstep) is taken.
• In requirements-level semantics, supersteps do not take time.
⇒ while superstep is taken, no external events can occur!
STATEMATE semantics of statecharts
✫
15
✪

✬
✩
Implementation-level semantics
• Imp.level semantics processes events one by one (single event
processing)
• Events generated in a step are responded to in some later step.
• In implemenation-level semantics, steps take time.
⇒ while step is taken, external event can occur!
⇒ need a queue to store events.
UML semantics of statecharts (state machines)
✫
16
✪

✬
✩
Example run in req.-level semantics
Receive order
{Receive
order}
{Check stock,
Check customer}
Check stock
{Make pro−
duction plan,
Check customer}
Check customer
terminates terminates terminates
{Make pro−
duction plan,
Send bill}
initial
state
state 1 state 2
state 3
state 4
insufficient stock
customer ok
being updated
customer ok
being updated
✫
17
✪

✬
Example run in imp.-level semantics
✩
Receive order
terminates
Check stock
terminates
initial
state
{Receive
order}
{routing}
{Check stock,
Check customer}
state 1 state 2
state 3
{routing,
Check customer},
state 4
...
insufficient stock
customer ok
being updated
customer ok
being updated
Check customer
terminates
...
{routing,
Check customer},
state 4
{routing}
state 5
{Make pro−
duction plan,
routing}
state 6
{Make pro−
duction plan,
Send bill}
state 7
✫
customer ok
being updated
✪
18

✬
✩
Comparing requirements-level and
implementation-level semantics
• Req.-level semantics is easier to analyse than imp.-level
semantics
• Imp.-level semantics is more accurate than req.-level semantics
But for certain requirements r, activity diagrams a:
r is satisfied by a under req.-level semantics
⇔
r is satisfied by a under imp.-level semantics
✫
19
✪

✬
✩
Comparing req.-level and imp.-level
semantics (2)
In order to make this work, we had to
• Rule out “ambiguous” activity diagrams
• Put restrictions on imp.level semantics (e.g. FIFO queue)
• Put restrictions on requirements (no next time, restricted until
operator)
✫
20
✪

✬
✩
Example ambiguous activity diagram
Configuration = [WAIT-1,WAIT-4]
Input events: e and f.
e1:e
WAIT−2
WAIT−1
e2:f
WAIT−3
e3:e
WAIT−5
WAIT−4
e4:f
WAIT−6
✫
21
✪

✬
✩
Another ambiguous activity diagram
Configuration = [A,WAIT-2]
Input events: e and termination event of A.
A
e1:
WAIT−1
WAIT−2
e2:e[in(A)]
WAIT−3
e3:e[!in(A)]
WAIT−4
✫
22
✪

✬
✩
Restricted logic
CTL* with restrictions:
• no events (in ILS named events can have extra effects)
• no next time (X)
• restricted until (lhs is not a state formula)
✫
23
✪

✬
✩
In ILS, named events can have extra effects
Configuration = [A]
Input events: e and termination event of A.
e
A WAIT−1 WAIT−2
✫
24
✪

✬
Intermezzo: statecharts vs. Petri nets
✩
(a)
Produce
partial order
Take partial order
from stock
Send partial
shipment
(b)
Produce
partial order
Take partial order
from stock
Send partial
shipment
(c)
Produce
partial order
Take partial order
from stock
Send partial
shipment
Send partial
shipment
✫
25
✪

✬
✩
Intermezzo: statecharts vs. Petri nets
But: statecharts cannot express every form of concurrency due to
constraints on AND/OR hierachy.
A
B
A
B
WAIT−1
WAIT−2
C
D
E
WAIT−3
WAIT−4
WAIT−5
✫
26
✪

✬
✩
Intermezzo: statecharts vs. Petri nets
So: statechart - hierarchy = Petri net ?
No!
Hypergraph
(Petri net,
activity diagram)
Hierarchical
hypergraph
(statechart)
Petri net theory
we
Statemate,
UML
Token game
semantics
Step semantics
✫
27
✪

✬
Verification tool
✩
Toolkit for Conceptual Modeling (TCM) contains about 20 graph
editors, including editors for UML diagrams. See
www.cs.utwente.nl/∼tcm
Workflow modeller
Formal requirement
Formal activity diagram
Path in activity diagram
TCM TCM TCM
Temporal Logic Formula
Transition system
Run
Model checker
✫
28
✪

✬
✩
Example
Workflow of a production company
[insufficient stock]
Receive
order
Make produc−
tion plan
[insufficient
stock]
Check
stock
[else]
Check
customer
[else]
WAIT
WAIT
[customer ok]
[else]
[customer ok]
Send bill
[else]
Fill order
Notify
customer
WAIT
Produce
payment
received
[else]
WAIT
WAIT
Handle
payment
[payment
ok]
Ship
order
✫
29
✪

✬
✩
Desired properties
P1 FGfinal. True
P2 Fin(Make production plan) ⇔ Fin(Produce). False
P3 F(in(Produce) ∨ in(Fill order)) ⇔ Fin(Send bill). True
Checked with NuSMV fair
30
✫
✪

✬
✩
Counter-example of P2 highlighted by TCM
Make produc−
tion plan
[insufficient stock]
WAIT
Receive
order
Check stock
Check
customer
[else]
WAIT
[else]
If the customer check fails, the workflow stops whereas Make
production plan may already have been executed. Repair:
P2’ (F customer ok) ⇒
Fin(Make production plan) ⇔ Fin(Produce). True
✫
31
✪

✬
Reducing the state space
✩
• We do not allow unbounded state nodes (nodes with
unbounded number of instances)
A
B
A
B
C
• We ‘abstract’ from data: Use basic guard expressions such as
x>cthat are logically independent from each other. (Every
basic guard expression is a boolean.)
• Replace dense time by discrete time. Preserves untimed
reachability properties.
✫
32
✪

✬
Strong fairness
✩
• We assume that loops in an activity diagram are eventually
exited. We specify this using strong fairness constraints.
s1 s2 s3
p,!q !p, q !p, !q
strong fairness constraint (p,q)
• This is an assumption on environment!
• NuSMV has been extended with an algorithm by Kesten,
Pnueli and Raviv that evaluates properties only on strongly
fair runs. (now included in NuSMV 2.1)
✫
33
✪

✬
✩
Fighting the state space explosion
• Although state space is now finite, it is still too large to be
verified efficiently.
• Solution: slice activity diagrams, depending upon property
being verified.
• Four reduction rules (e.g. remove irrelevant nodes, variables)
✫
34
✪

✬
✩
Removing irrelevant nodes of example
[insufficient stock]
[insufficient
stock]
[customer ok]
[else]
Check
stock
[else]
WAIT
WAIT
[else]
WAIT
WAIT
Ship
order
Check
customer
[customer ok]
[else]
[payment
ok]
[else]
Handle
payment
Property: FGfinal
✫
35
✪

✬
✩
Conclusion
• WF graphs need a reactive (step) execution semantics.
• Models with a Petri net-like syntax can have a statechart-like
semantics.
• Requirements-level semantics, even though inaccurate, is useful
for analysis.
• WF graph can be used as pretty front-end for model checkers.
• Tool allows verification of large workflow models that have
event-driven behaviour, real-time, data, and loops.
✫
36
✪