a reactive system. In a reactive system state changes are caused by input events. This means that the WFS must have some interface with the environment to observe the input events. We therefore use an input queue in which events are kept. The case attributes are needed to evaluate the guard conditions on the hyperedges, i.e., they are only used for routing the case. Timeouts are raised by the WFS itself, on the basis of an internal clock.
The second WFS characteristic, coordination, has several implications. First, activities are done by the environment in states of the WFS, i.e, during an activity state the WFS waits for an activity to complete (see Section 2.5). Activities take non-zero time to execute. Second, an activity is specified declaratively, in particular its postcondition. This was explained already in Section 2.5. Third, in a reaction case attributes are not changed. Instead, changing (updating) of case attributes is done by the environment of the WFS. Also, the WFS does not maintain the case attributes, this is done by its environment (usually by a database system).
4.2
Petri net token-game semantics versus state-
chart semantics
We now have to decide how an activity diagram changes state. In other words, we have to define the execution semantics of an activity diagram. Since in an activity diagram a change of state is modelled by an edge (a hyperedge in an activity hypergraph), we look at the semantics of a (hyper)edge in this section. We keep in mind that an activity diagram prescribes how a WFS behaves.
So the question to answer is: When is a hyperedge taken? There are several existing semantics for graphical notations that answer this question differently. The most relevant ones for activity diagrams are Petri nets, since they look like activity diagrams, and statecharts, because they too look like activity diagrams and in addition the current UML semantics of activity diagrams is defined in terms of statecharts, even though this will be changed in the future. Various semantics for Petri nets have been defined, but we focus on the standard token- game semantics used for low-level Petri nets. Timed and stochastic Petri nets have a more complicated semantics that is too complex for our purposes. Statecharts are notorious for their many semantics; in 1994, Von der Beeck [18] listed already over twenty different semantics, without considering object-oriented statechart variants. The introduction of UML has increased the number of semantics of statecharts considerably. All the different statechart semantics agree, however, on the semantics of hyperedges that we sketch below. Introductions to Petri nets and their semantics are by Peterson [136], Reisig [141] and Murata [129]. Introductions to statecharts and their semantics are by Harel [88], Harel and Naamad [90] and Wieringa [157].
44 Chapter 4· Design choices in semantics of activity diagrams
e[c]/a Petri net
Statechart
Figure 4.1 Differences between Petri net token-game and statechart semantics
There are two major differences between the Petri net token-game semantics and statechart semantics of hyperedges2. First, in a Petri net, a hyperedge (transition) is enabled once its input places are in the current marking. In a Petri net, a label on a hyperedge does not influence the enabledness of that hyperedge; the label is not interpreted. So, in Figure 4.1 the hyperedge in the Petri net is enabled iff its input place is filled with a token. In a statechart, a hyperedge (transition) is enabled once the system is in the input states of the hyperedge and both its trigger event occurs and its guard condition is true. The trigger event and guard condition are specified in the label of the hyperedge; the label is interpreted. So, in Figure 4.1 the hyperedge in the statechart is enabled iff its input state is active and event e occurs and the condition c is true.
Second, in a Petri net an enabled hyperedge may be taken, but it does not have to be taken. In a statechart, an enabled hyperedge must be taken, since the event occurrence must be responded to. Consequently, in Figure 4.1 if the hyperedge in the Petri net is enabled, we still do not know whether or not the hyperedge in the Petri net is taken. Whereas if the hyperedge in the statechart is enabled, we do know that it is taken.
These differences in semantics of hyperedges are due to a difference in intended use of the notation. Petri nets, under the token-game semantics, model the re- source usage of closed, active systems. Resources are represented by tokens. The presence of a token in a place gives information about the possibility to perform certain transitions, i.e., to use the resources in a certain way. A closed, active system decides itself when it should do something, i.e., take a transition; there is no environment to provide stimuli to the closed, active system. By contrast, statecharts model open, reactive systems. The environment of an open, reactive system provides the system with input events. The system must react to these events. The current state of a statechart gives information about what will happen if certain events occur. We conclude that the statechart semantics of hyperedges matches the domain of reactive systems best.
Based on this analysis we draw the following conclusion. Since we use an activity
2In both Petri nets and statecharts a hyperedge is called a transition, but we prefer the term
4.3· Issues in reactive semantics 45