step. The only hyperedges that might be inconsistent represent different branches of a decision. Every decision in the example is deterministic. Hence, no two edges that might be inconsistent are enabled at the same time. Therefore, for each bag of input events in this configuration, the calculated step is unique.
An example of a configuration in which, given a certain input, more than one step is possible, is configuration [WAIT-3,WAIT-4]. If the input is [after(2 weeks), receive payment], there are two possible steps, one entering node Send reminder and the other one entering node Handle payment. The WFS chooses arbitrarily one of these steps and takes it.
5.3
Requirements-level semantics
In the requirements-level semantics, we use the variables C , I , and LVar as discrete variables for the Clocked Transition System (see Section 5.1):
Disc ={ C , I } ∪ LVar
where, as before, C is the configuration, I is the current bag of input events, and LVar is the set of local variables of the activity diagram.
We now explain how we model temporal events in the semantics. In UML, there are two kinds of temporal events, after and when events. after events are dealt with by timers in ClockReservoir , whereas when events are dealt with by the master clock MC . Remember that in Chapter 3, we parametrised each after(texp) expression with the hyperedge h it belongs to: after(texp, h). For each after(texp,h) expression, a timer is started as soon as h becomes relevant; texp time units after the timer was started a timeout is generated.
So, given a timer t belonging to expression after(texp,h), the deadline of t is texp. Thus, we can associate with each timer a deadline, denoted by function deadline : ClockReservoir−→1. In order to make sure that there is no confusion
between two hyperedges with a similar after(texp) constraint, a timer always be- longs to at most one hyperedge. Function hedge : ClockReservoirHyperEdges
associates with every timer its unique hyperedge.
Due to unboundedness of a node, there does not have to exist an upper bound on the number of times a hyperedge is relevant at the same time. For example, in Figure 5.2 node WAIT is unbounded: there is no bound on the maximum number of
A
WAIT after(1 minute) B
62 Chapter 5· Two formal semantics of activity diagrams its active instances. So, the hyperedge leaving WAIT can be relevant unboundedly often. Therefore, infinitely many timers are needed to generate all the relevant timeouts. Hence, we assume that for every hyperedge enough timers, i.e. possibly unboundedly many, are available.
Temporal when events occur modulo a certain period. Thus, each when event w specifies a set of points in time at which the event occurs. Denote this set by deadlines(w ). The set of all when events also specifies a set of points, namely the union of all the individual sets. Denote this set by deadlines(WhenEvents).
We now specify the transition relation −→ for the CTS in the requirements- level semantics. The transition relation consists of seven transition relations. We first give a brief explanation of each relation; then we will formalise each relation.
• relation −→time represents the passage of time: timers are increased;
• relation −→event represents the occurrence of some events;
• relation −→retrieve lvar represents the retrieval of the current values of the
local variables. Retrieval is needed for evaluating guard conditions;
• relation −→unstable tests whether the current valuation is unstable. A valu-
ation is unstable if there are some enabled hyperedges or the bag of input events is filled with some events;
• relation −→stable tests whether the current valuation is stable. If the valua-
tion is stable, some new events can occur;
• relation −→step represents that a step is computed and taken according to
the step semantics outlined in Section 5.2. The configuration and the bag of input events are updated;
• relation −→end represents the termination of the case.
In a requirements-level run, transitions must occur in a certain order. Fig- ure 5.3 specifies the order of the transition relations in the requirements-level semantics. In the figure, a node represents a valuation. The initial valuation of an activity diagram is unstable by definition: a step is taken in order to leave this initial state and enter a stable state.
There is a loop of transitions −→step and −→unstable in Figure 5.3. So, more
than one step can be taken in response to some event occurrences. To be precise, if some event occurs, the system state becomes unstable. The system then reacts by taking a step and entering a new state. If this state is unstable, then another step is taken. A maximal sequence of steps is called a superstep. The superstep begins and ends in a stable state and all the intermediary states of the superstep are unstable. As explained on page 50, the superstep can diverge; then the superstep never ends in a stable state but keeps on taking steps and entering unstable states. There may be more than one step possible in an unstable state; then one of these possible steps is chosen and taken.
5.3· Requirements-level semantics 63
time event retrieve_lvar
unstable step stable end unstable end
Figure 5.3 Execution cycle in requirements-level semantics
Ideally, each workflow should terminate, i.e., reach the state in which the only possible transition is −→end. But there are some workflows which fail to do so,
either because they diverge, or because they deadlock. The verification approach presented in Chapter 10 allows, among others, to detect such failures.
We now formally define each of these seven relations.
Relation −→time defines the passage of time. Timers are increased by some
real number ∆. They cannot be increased beyond their deadline, because timeout events must be generated on time.
σ −→timeσ df ⇔ ∃ ∆ ∈ R • ∆ > 0 ∧ σ =σ[ & t∈RTt/σ(t)+∆, MC /σ(MC )+∆] ∧ ∀ l ∈ deadlines(WhenEvents) • σ(MC ) < l ⇒ σ(MC )+∆ ≤ l ∧ ∀ t ∈ σ(RT) • σ(t) < deadline(hedge(t)) ⇒ σ(t)+∆ ≤ deadline(hedge(t))
Valuation σ[x/val] assigns to variable x value val and to every other variable y, y = x, the value σ(y). Symbol & denotes a bulk update:
σ[&x∈Xx/valx]
df
= σ[x1/val1, . ., xn/valn]
where n = #X .
The defined constraints upon clocks use a guard condition, modelled with the implication (⇒), for the following reason. If a clock reaches its deadline, time can no longer pass, because a timeout must be generated. But afterwards, in a later time transition, if the clock has reached its deadline and has not been switched off, it should be able to increase beyond any bound. The consequent of the guard condition does not allow such an increase. That is why an implication is used.
64 Chapter 5· Two formal semantics of activity diagrams
WAIT−1 WAIT−2
after(1 minute)[false]
Figure 5.4 Example in which timer cannot be switched off after timeout
Consider for example the activity diagram in Figure 5.4. Suppose the system enters configuration [WAIT-1]. After 1 minute, time can no longer progress for the corresponding timer and a timeout is generated (by relation −→event specified
below). In the example, the edge leaving WAIT-1 can never be taken, because its guard condition is false. Thus, node WAIT-1 cannot be left. The defined constraint on clocks, including MC , in −→time allows the timer to keep on running even after
it has reached its deadline. Thus, the constraint prevents that time stands still in case some timers have reached their deadlines but are not switched off.
Relation −→event defines that events occur. The only component that changes
is I , the bag of input events. The non-occurrence of events is excluded: no change is not a change. The occurrence of events must satisfy some additional constraints, that we will discuss below. Line by line, the definition says that a bag E of event occurrences is allowed if and only if:
• the bag is not empty;
• a broadcast event can only occur once;
• only activity nodes that are in the current configuration can terminate; • if the master clock MC has reached the deadline of a when event, the when
event is generated;
• if n after timers are the same, i.e. reach their deadline simultaneously, then n after events should be raised. Two timers are the same if and only if they belong to the same hyperedge h and have the same value, so they are started at the same time. Note that by definition, timers that belong to the same hyperedge have the same deadline.
σ −→eventσ
df
⇔ ∃ E : bag Events • σ =σ[I /E]
∧ E = [ ]
∧ ∀ e ∈ Events • sendtype(e) = bc ⇒ Ee ≤ 1 ∧ ∀ t ∈ TerminationEvents • σ(I )t ≤ σ(C )term(t)
∧ ∀ we ∈ WhenEvents • σ(MC )∈deadlines(we) ⇔ weE
∧ ∀ t ∈ σ(RT) • σ(t) = deadline(t) ⇒
E event(hedge(t)) = #same(t, σ) where same(t, σ) = { t∈ σ(RT) | hedge(t) = hedge(t)
5.3· Requirements-level semantics 65 Before the step can be computed, the valuation of the local variables in the database must be known. The valuation of these variables may have changed, be- cause some activities have terminated (recorded in I ), or because the environment has updated some variables. Relation −→retrieve lvar specifies that the new values
of the local variables are retrieved. The valuation of variables that are observed or updated in some running activity does not change.
σ −→retrieve lvarσ df ⇔ σ(C ) = σ(C ) ∧ σ(I ) = σ(I ) ∧ σ(MC ) = σ(MC ) ∧ ∀ t ∈ RT • σ(t) = σ(t )
∧ ∀ a∈AN • aσ(C )terminated (σ(C ), σ(I )) ⇒
∀ v∈LVar • v∈Obs(a)∪Upd(a) ⇒ σ(v) = σ(v )
where, given a configuration C and input I , the function terminated returns the bag of terminated activity nodes of C .
terminated (C, I ) = { a → n ∈ AN ×1| ∃ e ∈ TerminationEvents •
aC ∧ eI ∧ a = term(e) ∧ n = I e }
where as before bB is true iff b is member of bag B .
A valuationσ is stable iff there are no enabled hyperedges and the bag of input events is empty:
σ |= stable df
⇔ enabledσ(σ(C ), σ(I )) = ∧ σ(I ) = [ ]
Transitions −→unstableand −→stable test whether a valuation is unstable or stable.
Both transitions have lower priority than transition −→end, defined below.
σ −→unstableσ ⇔ σ = σdf ∧ σ |= stable ∧ σ −−→/ endσ
σ −→stableσ ⇔ σ = σdf ∧ σ |= stable ∧ σ −−→/ endσ
Predicate −→end tests whether an activity diagram has ended.
σ −→endσ ⇔df σ = σ
∧ σ(I ) = [ ]
∧ ∀ n ∈ Nodes • n σ(C ) ⇒ n ∈ FN
Note that if σ −→endσ then σ |= stable, because final nodes have no outgoing
hyperedges.
We next define the step transition relation −→step. A step is computed as
described in Section 5.2. Line by line, the −→step definition says that a step is
done betweenσ and σ iff:
66 Chapter 5· Two formal semantics of activity diagrams • the variables that are contained in the guards of the hyperedges in S are not being updated in some non-terminated activity (otherwise an inconsistent value could be read);
• there is a set T of timers that can be turned on;
• σ is then updated into σ by computing the next configuration if step S
is taken (using the function nextconfig defined in Section 5.2), putting the generated events in I , initialising the new timers T , and updating RT by removing the timers that have become irrelevant (set OffTimers) and adding the new timers T .
σ −→stepσ
df
⇔ ∃ S : bag HyperEdges • isStepσ(σ(C ), σ(I ), S)
∧ ∀ a ∈ AN • a Cterminated (σ(C ), σ(I )) ⇒ Upd (a)∩ ( hS var (guard (h)) ) = ∧ ∃ T ⊆ ClockReservoir • NewTimers(σ(C ), S, σ(RT), T) ∧ σ=σ[C /nextconfig(σ(C ), S), I/settobag(generated(S)), &t∈Tt/0, RT/(σ(RT) \ OffTimers(σ(C ), S, σ(RT)) ∪ T)] where var (g) denotes the variables guard g tests, given a bag of hyperedges, func- tion generated returns the set of generated events. The function is defined recur- sively.
generated ([ ]) =df
generated ([ h ]∪ H ) =df sendactions(h)∪ generated(H )
We next define function OffTimers and predicate NewTimers. Function Off- Timers returns all timers in RT that can be switched off because their corre- sponding hyperedges are irrelevant in the next configuration, even though these were relevant in the current configuration. Predicate NewTimers is true iff all timers in T are off but can be turned on, i.e. they are not in RT , and moreover for every instance of an hyperedge that becomes relevant there is a timer in T . The definition of NewTimers requires that for every hyperedge there are always enough new timers, i.e. non-running so not in RT , available. That is why we require that for every hyperedge h there are unboundedly many timers belonging to h available in ClockReservoir .
OffTimers(C, S, RT) =df { t ∈ RT | hedge(t)oldrel}
5.4· Implementation-level semantics 67