EQUIPO DE TRABAJO

6.1.1

RLS and stable ILS

Updating of variables by environment. Because in the RLS events are pro- cessed immediately, the valuation of a guard at the time the event occurs and

6.1· Differences between the two semantics 79 A WAIT−1 WAIT−2 [else] [ok] A updates ok WAIT−3 WAIT−4 e

Figure 6.1 Example for issue “Updating of variables by environment”

at the time the event is processed is the same. In the ILS and stable ILS, after an event has occurred and before the event is processed, the environment may change the valuation of a guard. The same activity diagram can therefore behave differently in the requirements-level and implementation-level semantics.

For example, suppose that in Figure 6.1 the system is in configuration [A,WAIT- 3] and activity node A terminates and e occurs at the same time. Moreover, A has set ok to true. Then under the RLS, the only possible next configuration is [WAIT-1,WAIT-4]. In the ILS, one event at a time is processed. Suppose e is processed before the activity termination event. While e is being processed, the environment may set ok to false. Since A has terminated, the variable ok is no longer locked in the database system. So in that case, under the ILS configuration [WAIT-2,WAIT-4] is entered. This configuration cannot be reached under the RLS in this particular example.

We solve this difference in behaviour between RLS and stable ILS by forbidding the environment to update case attributes (control data). Note that this difference occurs in every activity diagram in which activities update variables that occur in some guard conditions of the activity diagram. It is therefore not feasible to define constraints on activity diagrams: those would rule out almost every activity diagram.

C1 The environment does not update case attributes (control data). (env)

Locking of variables. Before a relevant hyperedge can be taken, its guard needs to be evaluated. A guard cannot be evaluated if it refers to some variable v that is currently being updated in some activity. In that case, we say v is locked . If the guard refers to a variable that is locked, the activity diagram may behave differently under RLS and ILS.

For example, in Figure 6.2, variable ok is tested in edge e1 that is in a thread parallel with activities A and B that both update ok. Since A and B both update ok, they are interfering. Edge e1 can only be taken if variable ok is not locked, in other words, if A and B are not active.

80 Chapter 6· Relation between the two formal semantics A A updates ok WAIT−2 WAIT−3 e1:e[ok] B B updates ok WAIT−4 f WAIT−1

Figure 6.2 Example for issue “Locking of variables”

and e and f occur. Under the RLS, the only possible next configuration is [WAIT- 1,WAIT-3,B]. Since activity A is not running anymore, edge e1 is always taken in this particular case. Under the ILS, suppose f is processed before e. Then node B is entered and activity B becomes active before e1 is taken. If B is active, however, variable ok becomes locked. Thus, edge e1 cannot be taken anymore. So, then the next configuration under the ILS is [WAIT-1,WAIT-2,B]; this configuration is not reachable under the RLS for this particular input.

The difference between RLS and ILS in this particular example is due to the parallel event processing in the RLS and the single-event processing in the ILS. Due to single-event processing, in the ILS a variable can become locked after one (external) event has been responded to, whereas under the RLS the variable becomes locked after all (external) events have been responded to.

We avoid this difference by putting the following constraint on activity dia- grams.

C2 If the guard of some hyperedge h refers to a variable that is up- dated in some activity A and node A is not source of h, then hyperedge h is not in parallel with node A, i.e., there does not exist a configuration C such that settobag(source(h)∪ {A})  C.

(act)

This constraint cannot be checked on the syntax of activity diagrams. Instead, it presupposes a semantics of activity diagrams. So we would have to check the constraint in both the RLS and ILS. But the purpose of this whole exercise is to avoid using both semantics, in particular the ILS semantics!

Fortunately, we can use the Petri net token-game semantics on hypergraphs, defined on page 75, to compute all the configurations that are possible in theory.

6.1· Differences between the two semantics 81 (Then the labels of the hyperedges are not interpreted.) Some of these configu- rations may not exist under the RLS or ILS. But every configuration existing in both RLS and ILS can be computed using the Petri net token-game semantics. If the check using the token-game semantics fails, the constraint may still hold un- der both RLS and ILS, because the violating configuration perhaps does not exist under these semantics. Thus, verification of the constraint using the token-game semantics is sufficient but not necessary.

Sometimes, by visual inspection of the syntax one can analyse whether or not the activity diagram satisfies the constraint. For example, in Figure 1.1 (Fig- ure 3.6) it is immediately clear that the hyperedges leaving node WAIT-1 and WAIT-2 are only enabled once both activities Check stock and Check customer have completed. So, this activity diagram satisfies above constraint.

Finally, note that if the activity diagram satisfies this constraint, the guard of a relevant hyperedge can always be evaluated, because the variables it refers to are never locked.

Internal events. Since events are processed in parallel in the RLS, events gen- erated by the system (internal events) may have a different effect under the RLS, compared to the ILS.

For example, consider the activity diagram in Figure 6.3. Suppose the current configuration is [WAIT-1,WAIT-3,WAIT-5] and events e and g happen simultane- ously. Under the RLS, the reaction ends in configuration [WAIT-2,WAIT-4,WAIT- 6]. Edge e1 is taken, because f is generated in the previous step, whereas edge e2 is not taken, because its trigger event h is already removed from the input when the system reaches [WAIT-6]. Under the ILS, however, it is possible that the reaction ends in configuration [WAIT-2,WAIT-4,WAIT-7], namely if e is processed before g and g before f. Then both edge e1 and edge e2 are taken.

We circumvent this difference in behaviour by putting the following constraint on the syntax, which says that events generated in some thread are expected in some other parallel thread. First some terminology: a hyperedge h makes another hyperedge h
(directly) relevant if h’s targets and h
’s sources overlap. A hyperedge h makes another hyperedge h
indirectly relevant, if h makes another hyperedge

WAIT−1 WAIT−2 e/f

WAIT−5 WAIT−6 WAIT−7

e1:f

WAIT−3 WAIT−4 g/h

e2:h

82 Chapter 6· Relation between the two formal semantics h

directly relevant, and h

either makes h
directly relevant or indirectly relevant.

C3 A hyperedge triggered by an internal event i is only made (directly) relevant by another hyperedge that also makes the hyperedge that generates i (in)directly relevant.

(act)

The constraint is sufficient to rule out activity diagrams with different be- haviour w.r.t. internal events. The constraint rules out the activity diagram in Figure 6.3: edge e2 violates the rule. It is made relevant by e1, but e1 does not make (in)directly relevant an edge that generates h.

The in predicate. If the in predicate is used, an activity diagram may behave differently under the RLS and stable ILS. For example, consider the activity dia- gram in Figure 6.4. Suppose that the current configuration is [A,WAIT-2] and A terminates and e occurs simultaneously. Then under the RLS the next configu- ration is always [WAIT-1,WAIT-3]. When e occurs, the current configuration still contains A, so predicate in(A) is true. But under the stable ILS, it is possible that node A’s termination event is processed before e. Then predicate in(A) is false when e is processed. Consequently, configuration [WAIT-1,WAIT-4] is reached. Thus, the RLS and stable ILS behave differently in this example.

We can rule out such activity diagrams by forbidding to use the in constraint.

C4(a) The in predicate is not used. (act)

We also formulate a weaker constraint, however, that will turn out to be useful for showing that it is possible in the stable ILS to mimic the behaviour of the RLS. The observation we make is that by choosing the right order of event processing, the stable ILS can behave similarly to the RLS even when the in predicate is used. For example in Figure 6.4 as described above, if e is processed before A’s termination event, the RLS and ILS behave similarly. For simplicity, we assume that the in predicate is only used in guards of hyperedges triggered by an external event, i.e., not by a completion or internal event. If either h or h
’s trigger event is

A e1:

WAIT−2 e2:e[in(A)] WAIT−3 WAIT−1

WAIT−4 e3:e[!in(A)]

6.1· Differences between the two semantics 83 a completion or internal event, the ILS can no longer influence the order of event processing, because these events have priority of external events (see page 88).

We now formulate a constraint that guarantees that the right order can be chosen. A hyperedge h must be taken before another hyperedge h
, written h≺ h
, iff there is a hyperedge triggered by event (h) and with guard containing in(n), and there is a hyperedge triggered by event (h
) that either leaves n or enters n. If h ≺ h
, taking h
may change the truth value of the guard of h. For example in Figure 6.4, taking e1 the truth values of the guards of e2 and e3 change. So e₂≺ e₁ and e₃≺ e₁.

Now, if there is no cycle in the relation ≺, it is always possible to choose an appropriate order of event-processing in the stable ILS, namely by taking into ac- count the relation≺: if h ≺ h
then event (h) should be processed before event (h
).

C4(b) The in predicate is only used in guards of hyperedges triggered by an external event. There is no cycle in the relation≺.

(act)

Conflicting hyperedges. We say that a hyperedge h conflicts with another hy- peredge h
iff h and h
have some sources in common, i.e., source(h)∩source(h
)=

. Activity diagrams with conflicting hyperedges may have different behaviour

under the RLS and stable ILS. We rule out such activity diagrams by defining constraints on conflicting hyperedges that every activity diagram must satisfy.

First, we define some terminology for hyperedges (cf. Table 3.1 on page 33). • a completion hyperedge is a hyperedge that has no trigger event. A comple-

tion hyperedge is implicitly triggered by completion event under the ILS. completion(h)⇔ event(h) = ⊥df

• an internal hyperedge is a hyperedge that is triggered by an internally gen- erated named event.

internal (h)⇔ event(h) ∈ NamedInternalEventsdf

• an external hyperedge is a hyperedge that is triggered by an external event in the environment of the WFS. Every hyperedge that is not internal and not completion is external (see Table 3.1).

external (h)⇔ ¬ completion(h) ∧ ¬ internal(h)df

Table 6.1 defines the constraints on conflicting hyperedges and Table 6.2 shows what constraints apply to what hyperedges. We motivate each constraint by a small activity diagram that does not satisfy the constraint, shown in Figure 6.5.

Constraint C5 rules out the activity diagram in Figure 6.5(a). In the corre- sponding activity hypergraph, from node WAIT-2 two conflicting hyperedges leave

84 Chapter 6· Relation between the two formal semantics C5 If two completion hyperedges are conflicting, they have the same

sources.

(act) C6 A completion hyperedge is not conflicting with an internal hyper-

edge.

(act) C7 A completion hyperedge is not conflicting with an external hyper-

edge.

(act) C8 An internal hyperedge is not conflicting with another internal hy-

peredge.

(act) C9 An internal hyperedge is not conflicting with an external hyper-

edge.

(act)

Table 6.1 Definition of constraints on conflicting hyperedges

completion internal external

completion C5 C6 C7

internal C6 C8 C9

external C7 C9

Table 6.2 Relation between constraints and hyperedges

and also from node WAIT-4 two conflicting hyperedges leave. In Figure 6.5(a), if in configuration [WAIT-1,WAIT-3] events e and f occur simultaneously, then under the RLS it is possible that activity B is started. Whereas under the stable ILS activity B is never started and activity A is always started. Under the stable ILS, if e is processed before f, then first node WAIT-1 is left and node WAIT-2 is entered. A completion event for WAIT-2 is generated. Since completion events have priority over non-completion events, the enabled edge leaving WAIT-2 and entering WAIT-5 is taken and node WAIT-5 is entered. After event f has been pro- cessed and all completion events, finally configuration [A] is reached. By similar reasoning, it can be shown that if event f is processed before e, also configuration [A] is reached.

Constraint C6 rules out the activity diagram in Figure 6.5(b). In Figure 6.5(b), suppose the current configuration is [A,WAIT-2] and that activity node A termi- nates. Under both the RLS and ILS, a step is taken and the next configuration is [WAIT-1,WAIT-2], and internal event done has been generated. Then under the RLS two steps are possible, one in which the next configuration is [WAIT-4], and another one in which the next configuration is [WAIT-1,WAIT-3]. Whereas under the ILS, only one step is possible, namely the one in which configuration [WAIT-4] is reached, because completion events have priority over non-completion events.

Constraint C7 rules out the activity diagram in Figure 6.5(c). In Figure 6.5(c), suppose the current configuration is [WAIT-1,WAIT-4] and event e and f occur at the same time. Then under the RLS, the next configuration is [WAIT-2,WAIT-5]. The corresponding state is unstable, and next configuration [WAIT-3] is reached.

6.1· Differences between the two semantics 85 WAIT−1 e WAIT−2 WAIT−3 f WAIT−4 WAIT−6 WAIT−1 WAIT−2 e WAIT−5 WAIT−1 /done WAIT−2 WAIT−3 done A WAIT−2 WAIT−3 e WAIT−4 f A B C /e D /f B WAIT−5 _A WAIT−1 WAIT−1 /done WAIT−2 WAIT−3 done WAIT−4 e A WAIT−4 f _WAIT−6 WAIT−3 WAIT−4 WAIT−5 (a) (b) (c) (d) (e)

86 Chapter 6· Relation between the two formal semantics Under the stable ILS, either e or f is processed first. If f is processed before e, configuration [WAIT-1,WAIT-5] is reached. Then a completion event is generated and configuration [WAIT-6] is reached. So, the behaviour of the activity diagram under the ILS is different from its behaviour under the RLS.

Constraint C8 rules out the activity diagram in Figure 6.5(d). In Figure 6.5(d), suppose the current configuration is [A,C,WAIT-2] and activity nodes A and C terminate at the same time. Then under the RLS, internal event f is generated before e is generated. So node WAIT-4 is entered under the RLS. Under the stable ILS, if the termination event of A is processed before the termination event of C, then internal event e is processed before f, since completion events (in this case the completion event of WAIT-1) have priority over non-completion events. So under the stable ILS, it is possible that node WAIT-3 is entered, rather than WAIT-4.

Constraint C9 rules out the activity diagram in Figure 6.5(e). In Figure 6.5(e), suppose the current configuration is [A,WAIT-2] and activity node A terminates at the same time as e occurs. Under the RLS, the next configuration is always [WAIT-1,WAIT-4]. Under the stable ILS, suppose activity node A’s termination event is processed before e. On page 88 we explain that internal events must have priority over external events in the (stable) ILS. So, under the stable ILS the next configuration can be [WAIT-1,WAIT-3]. This configuration is unreachable under the RLS in this case.

Duplicate conflicts. In an activity diagram, the same conflict between some hyperedges may have be to be resolved twice at the same moment. Then there are two groups of inconsistent, i.e. conflicting, hyperedges and the hyperedges in each group have similar trigger events. Figure 6.6 shows an example. Formulated more precisely, an activity diagram has a duplicate conflict , if there are two different groups G₁,G₂ of hyperedges such that:

• all the hyperedges in the two groups can be enabled at the same time; • hyperedges within a group are inconsistent (conflicting);

• hyperedges between the groups are consistent (non-conflicting);

• the enabling trigger events and guard conditions of the hyperedges in G1

also enable the hyperedges in G₂.

For example, the activity diagram in Figure 6.6 has duplicate conflicts, since nodes WAIT-1 and WAIT-4 are in parallel and the two hyperedges with trigger e (f) belong to different groups (group{e1,e2} and group {e3,e4}).

The behaviour of activity diagrams that have duplicate conflicts is different under the RLS and ILS due to difference between parallel (RLS) and single-event processing (ILS). For example, in Figure 6.6, suppose in configuration [WAIT- 1,WAIT-4] events e and f occur at the same time. Under the RLS, a possible step

6.1· Differences between the two semantics 87 WAIT−1 WAIT−2 WAIT−3 WAIT−5 WAIT−6 WAIT−4 e1:e e2:f e3:e e4:f

Figure 6.6 An example of a duplicate conflict

is [e1,e4]. This step is impossible under the ILS, due to the single-event processing. If e is processed first, the only possible step is [e1,e3]. If f is processed first, the only possible step is [e2,e4]. Note however that both these steps are also possible under the RLS.

Assuming absence of duplicate conflicts in an activity diagram, we prove that single-event processing does not impact the computation of steps: the union of the steps that are computed for each event separately (ILS), equals a step that is computed when all events are considered at the same time in parallel (RLS).

Theorem 6.1 Assume an activity diagram does not have duplicate conflicts.

Take an arbitrary configuration C and input I = [ e₁, . ., en].

Let S be a step such that isStep(C, I , S). For each input event eI , step Se

is defined as Se= S ∩ Enabled(C , [ e ]).

Then S =_e

I

Se, and for all eI , isStep(C, [ e ], Se) holds.

Proof. Straightforward checking of definition of step. ¾

If an activity diagram did have duplicate conflicts, we would not be able to prove such a theorem. We gave a counterexample above that we explain now in more detail. In Figure 6.6 if C = [WAIT-1, WAIT-4] and I = [ e, f ] then a possible step S = [e1, e4]. Denote by S_e = S ∩ Enabled(C , [ e ]) = [e1]. But step S_e does not satisfy isStep([h₁], C , S_e), because e3 is not part of S_e.

C10 The activity diagram does not have duplicate conflicts. (act)

Events have extra effects. Due to single-event processing, in the (stable) ILS events can have unexpected extra effects. Consider for example the activity dia- gram in Figure 6.7. Suppose in configuration [A] that activity node A terminates and event e occurs simultaneously. Then under the ILS, it is possible that config- uration [WAIT-2] is reached, namely if A’s termination event is processed before e.

88 Chapter 6· Relation between the two formal semantics

A WAIT−1 WAIT−2

e

Figure 6.7 Event e has extra effect

But under the RLS, node WAIT-2 is never reached in this particular case. So under the ILS event e has an extra effect. We conclude that although under the ILS the same hyperedges as under the RLS are taken in response to some event occurrences, under the ILS sometimes some extra hyperedges are taken.

To take these extra hyperedges under the RLS, some events must be regen- erated. This puts a constraint upon the environment: it should be cooperative, i.e., regenerate some external events if needed. Note that an activity termination event does not have this problem, as such an event always triggers an edge that is already relevant when the event occurs.

C11 The environment is cooperative. (env)

Extra effects of an event cannot be avoided by imposing constraints upon activity diagrams. Such constraints would rule out almost every activity diagram that has a named event in it; for example the one in Figure 6.7.

Constraint C11 shows the inequivalence of RLS and ILS. We will only use it to prove one theorem (Theorem 6.2(ii)), and then drop it. Then we will prove a