WFS behaves, edges in an activity diagram (hyperedges in an activity hypergraph) are transitions by the WFS. A WFS is a reactive system. The statechart semantics represents reactive behaviour of a system more accurately than the Petri net token- game semantics. We therefore take the statechart semantics as starting point of our semantics.
After having defined our formal semantics in Chapter 5, we will study in Chap- ter 8 whether and how Petri nets can be used to simulate our reactive semantics of activity diagrams.
4.3
Issues in reactive semantics
In the statechart semantics, or rather any reactive semantics, the system takes a hyperedge, i.e., makes a transition to another state, in response to some input events. There are several issues that have to be decided upon in defining a se- mantics for reactive systems. We label each choice that we make with a checked symbol¨.
First of all, can more than one event occur at the same time? We make two observations. First, although the chance of two events occurring simultaneously is rather small, it is not equal to zero. Second, the reactive system (WFS) will respond to events by inspecting the contents of the queue. If no two events can occur simultaneously, the rate at which events occur in the environment must be slower that the rate at which the WFS reads input events (sampling rate). We do not want to impose such a restriction upon the environment and therefore do not make such an assumption.
¨ Events can occur simultaneously.
From this choice, it follows that two event occurrences are either simultaneous, or some time elapses between them.
Second, can an event trigger one or more than one hyperedge at the same time? We allow an event in general to be either broadcast, triggering arbitrarily many hyperedges, or point-to-point, triggering at most one hyperedge (see Sec- tion 2.4). As explained in Section 3.2, however, some events have a fixed sendtype, for example activity termination events. It does not make sense to broadcast an activity termination event of activity A, leaving arbitrarily many activity nodes that enable A, since only one instance of A has terminated and therefore only one activity node should be left. If an event can both be broadcast and point-to-point, we use the broadcast interpretation as default (see Table 3.1 on page 33).
¨ Events can be either broadcast or point-to-point.
From these two choices, it follows that more than one hyperedge can be taken at the same time. Two hyperedges h and h can be taken at the same time either
46 Chapter 4· Design choices in semantics of activity diagrams because their trigger events occur at the same time, or they have the same trigger event which is broadcast. The collection of hyperedges that is taken at the same time is called a step in statechart terminology [90, 150].
Third, during execution of the system, the event queue is filled with events. The system reads the events from the event queue and reacts to them. There should however be some removal policy. If an event is not removed after it is processed, it would continue to have an effect, which is undesirable. Since the result of the event occurrences is the taking of some hyperedges (a step), the events should be removed after these hyperedges have been taken.
¨ An event is removed after the step in which it is processed has been taken.
Fourth, there are some obvious constraints that steps must satisfy. For exam- ple, every hyperedge in the step must be triggered by one of the input events, and no two hyperedges can leave the same node instance at the same time. In the next chapter, we will formalise these constraints. One not so obvious, but very important constraint is that a step is maximal. This constraint is satisfied by every statechart semantics. Not imposing this constraint would imply that some hyper- edges that are enabled would not have to be part of the step, so would not have to be taken. Since an event is removed from the input after the subsequent step has been taken, this would mean that some input events would not cause all their effects, although, according to the workflow model, they should have these effect (enabled hyperedges should be taken). In other words, then the WFS would not react fully to these input events. That is why we require that a step be maximal.
¨ Steps are maximal.
Fifth, events can be processed either immediately upon arrival or at fixed points in time, that is, at ticks of the clock, for example once every hour. The former is called an event-driven model whereas the latter is called a time-driven model. In Statemate both response regimes are supported: there the event-driven model is called an asynchronous time model, since it is asynchronous with respect to the system clock, whereas the time-driven is called a synchronous time model, since it is synchronous with ticks of the system clock. In previous work [62, 63, 64], we used the terms ‘clock-asynchronous’ and ‘clock-synchronous’ semantics. The terminology we use here is borrowed from control theory [17].
For workflow modelling, the event-driven model is more appropriate. The time-driven model is useful for embedded systems.
¨ Events are processed when they arrive (event-driven model).
Sixth, it must be decided what should happen if an event occurs that has no effect in the current state of the system. In statecharts, as in control theory in general, the assumption is made that input events cannot be blocked. Instead, the system should be able to respond to every possible event occurrence. If no effect is
4.3· Issues in reactive semantics 47 WAIT−1 WAIT−2 WAIT−3 WAIT−4 WAIT−5 e1:e/f e2:e e3:f
Figure 4.2 Event generation
specified, nothing happens. We adopt this assumption too. UML statecharts also adopt this assumption, but in addition allow for the deferring of an event that has no effect in the current state. As soon as the system reaches a state in which the event is not deferred, the event is responded to. We come back to the deferring of events in Chapter 7.
The alternative assumption is to block an unexpected event reception until the system is ready to respond to it. This latter choice is made in process algebra [97, 127], but it puts a constraint upon the environment. We do not want to put such a constraint upon the environment.
¨ Event receptions cannot be blocked.
Finally, we discuss what happens when events are generated. There are two different ways of interpreting event generation. The first one is to let the generated events have an effect in the current step (chosen in the fixpoint statechart seman- tics of Pnueli and Shalev [140]), the second one is to let the generated events have an effect in the next step (chosen in theStatemate statechart semantics [90]). To illustrate the difference between these two options, suppose in Figure 4.2 the current configuration is [WAIT-1,WAIT-2] and event e occurs. If edge e1 is taken, then according to the fixpoint semantics event f is immediately available and con- sequently edge e3 can be taken simultaneously with edge e1. Whereas in the Statemate semantics, event f can only be sensed after the step in which it is generated is taken, so after edge e1 is taken. Consequently, if the current config- uration is [WAIT-1,WAIT-2], and event e occurs, in the fixpoint semantics either step [e1,e2] or [e1,e3] is taken, but in the Statemate semantics, step [e1,e2] is taken. Step [e1,e3] is counterintuitive here, since it seems that event e is ignored in node WAIT-2. So there are circumstances in which the fixpoint semantics com- putes a counterintuitive step (this was first pointed out by Leveson et al. [117] using a similar example, but they mistakenly attribute the fixpoint semantics to Statemate). That is why in practice the Statemate approach is taken, even in the UML. We adopt the Statemate interpretation for event generation as well, since it is also adopted by UML.
48 Chapter 4· Design choices in semantics of activity diagrams
¨Events can occur simultaneously.
¨Events can be either broadcast or point-to-point.
¨An event is removed after the step in which it is processed has been taken. ¨Steps are maximal.
¨Events are processed when they arrive (event-driven model). ¨Event receptions cannot be blocked.
¨Generated events are sensed in the next step.
Table 4.1 General choices made in our reactive activity diagram semantics
As an aside, note in this interpretation too, there are anomalies. One may for example get infinite loops of event generation that trigger each other, as pointed out by Leveson et al. [117]; see Figure 4.3 and the corresponding discussion on page 50.
Table 4.1 summarises the general choices that we made. The first six assump- tions are made in every statechart semantics, including Statemate and UML. (Statemate supports both an event-driven (asynchronous time) and time-driven (synchronous time) model [90].) Some of the choices are also made in other formal methods, like process algebra, but none of them makes the same choices. The last choice is made by bothStatemate [90] and UML [150]. The fixpoint semantics of Pnueli and Shalev [140], in which the alternative property is adopted, is widely studied by theoretical computer scientists, but we do not know of any practical application of this semantics. There is no tool that implements it.
Although we have made these choices, we have left open a lot of other issues. Many different semantics can be defined that satisfy the properties listed above. In this thesis we will define two semantics, which are completely different from each other, even though both satisfy all the properties listed in Table 4.1. We introduce these two semantics in the next section.