Above, we focused on possible semantics for edges in an activity diagram. We now focus on the semantics of nodes, more precisely the semantics of activity nodes.
We explained in Section 2.5 that the actual execution of activities falls outside the scope of the system being modelled, a WFS, since activities are done by actors. Moreover, we do not model actors; we simply assume that an activity, once it becomes enabled, will terminate sometime in the future. The only relevant aspect of the execution of an activity is that when it terminates, some of the control data may have been changed. This affects the routing of the case.
We therefore specify the effect of an activity declaratively using pre and post- conditions. A precondition is a logical expression that is used by the WFS to decide when the activity may be started. A postcondition is a logical expression that is used by the WFS to decide when the activity has been completed. Both pre and postconditions refer to control data.
Unfortunately, pre and postconditions do not have a standard semantics as pointed out by Bussler [29]. That is, they can be interpreted differently by different WFSs. For example, if in the workflow of Figure 3.10(a) activity A completes and x is 5, then some WFSs will stop the whole workflow, i.e, the workflow of Figure 3.10(a) behaves similar to the workflow of Figure 3.10(b). Other WFSs, however, will wait until x gets a value greater than 10 (Figure 3.10(c)). Yet other WFSs will skip B and proceed with C (Figure 3.10(d)). Similarly, a postcondition has different interpretations too. If a postcondition fails to hold, the WFS can decide that the activity has to be redone, or that the whole workflow is stopped.
Since pre and postconditions have such an unclear semantics, we decide not to model them implicitly as in Figure 3.10(a) but explicitly using guard conditions as in Figures 3.10(b)-(c). Then the semantics of the pre and postcondition follows
3.4· Specifying activities 39 A B C Precondition: x>10 A B C [x>10] [else] A B C when(x>10) A B C [x>10] [else] WAIT [else] [x>10] (a) (b) (c) (d)
Figure 3.10 Workflow with precondition and three possible interpretations
immediately from the workflow specification.
In Section 2.2 we explained that a WFS can prevent interfering activities from being active simultaneously, thus enforcing isolation between activities. In order to do so, the WFS needs to know what activities interfere with each other. The interference information can be defined either explicitly by the workflow designer, or the WFS can derive it automatically from the specification of activities. In this thesis we only consider the last option.
In database theory, a useful criterion for detecting interference between trans- actions is serialisability [56, 152]. Roughly speaking, if two transactions both simultaneously access (observe/update) the same variable and in addition one up- dates the variable, then the two transactions are not serialisable (commutative) and thus they interfere with each other. We take a similar approach and specify for each activity the variables it observes (reads) and the variables it updates. From this information, the WFS can derive whether or not two activities interfere with each other.
Formally, in every activity a ∈ Activities that is controlled by an activity diagram, some local variables may be observed or updated . We denote the observed
40 Chapter 3· Syntax of activity diagrams variables by Obs(a)⊆ LVar, and the updated variables by Upd(a) ⊆ LVar. We require these two sets to be disjoint for each activity. Note however that it is possible to have Obs(a) = Upd (b), if a= b.
Two activities are in conflict or interfere, if one of them observes or updates a local variable that the other one updates. (This definition is similar to the definition of conflict equivalence in database theory [56, 152].)
AB ⇔ (Obs(A)∪ Upd(A)) ∩ Upd(B) =
∨ (Obs(B) ∪ Upd(B)) ∩ Upd(A) =
Note that this particularly implies that we only allow autoconcurrency (two in- stances of the same activity that are active at the same time) if the autoconcurrent activity does not update any variables.
The environment of the organisation may also change or update some variables, denoted Obs(env ) and Upd (env ) where env is a special symbol, env ∈ Activities, representing the environment. The WFS cannot prevent the environment from interfering with an activity that accesses the same variable; such a prevention is the job of the database system.
For our running example (see Figure 1.1 on page 3), we specify that activity Check stock updates variable insufficient stock, that Check customer updates cus- tomer ok, and that Handle payment updates payment ok. The environment does not update any of these variables.
Chapter 4
Design choices in semantics
of activity diagrams
We use UML activity diagrams to specify workflows. As explained in Chapter 2, a workflow specification prescribes how a workflow system should behave. We therefore motivate and define the execution semantics of activity diagrams in terms of WFSs (see Section 2.5). In this chapter we discuss the design choices we make in our semantics for activity diagrams. We give an informal introduction to two semantics that both satisfy the same design choices, but are otherwise completely different. One is a high-level semantics which assumes that a WFS is infinitely fast and reacts immediately to events, whereas the other one is a low-level semantics which does not make this assumption. In the next chapter, we formally define these two semantics. A comparison of both semantics with Petri nets can be found in Chapter 8. A comparison with other related work can be found in Chapter 9.
Section 4.1 explains what (a state of) the mathematical structure looks like. The design choices that we made for the semantics are motivated by the domain of workflow systems as explained in Chapter 2. Section 4.2 looks at how an activity diagram changes states. We study two existing execution semantics, the Petri net token-game semantics and the statechart semantics. Since the statechart semantics fits our purposes best, we take that semantics as a starting point. Section 4.3 lists several issues in the semantics that have to be resolved, and for each issue we show the choice that we make in order to resolve the issue. Section 4.4 informally introduces two semantics that both satisfy these choices but that are otherwise completely different from each other.
4.1
Mathematical structure
From the discussion in Chapter 2, we conclude that workflow systems have the following characteristics.
42 Chapter 4· Design choices in semantics of activity diagrams • A WFS is reactive. A reactive system runs in parallel with its environment and responds (reacts) to input events by creating certain desirable effects in the environment [91, 157]. For a WFS, typical input events are activity termination events, in Figure 1.1 for example that the Receive order activity node terminates. Other events are also possible (cf. Figure 2.4 on page 19). And characteristic desirable effects for a WFS are the enabling of new activity instances.
• A WFS has coordination functionality. A WFS does not execute the activities themselves, but it merely coordinates the execution of the activities by the actors (people or machines)1. For example, in Figure 1.1 (page 3) the WFS does not check a customer itself, but merely tells the relevant actors that one of them can start checking the customer. Case attributes are only changed in activities by actors, not by the WFS.
The semantics of activity diagrams must be able to represent these aspects accurately.
As explained in Chapter 1, every formal semantics is a mapping of a syntactic structure into a mathematical structure. The structure we use in this thesis is that of a run (to be precise, a set of runs). A run (or a trace or scenario) is a sequence of states connected by state changes. A state is a condition of the world, for example: activity Receive order is being executed. A state change is a change in condition of the world, for example: activity Receive order terminates. State changes are instantaneous. Non-instantaneous state changes can always be split into an instantaneous begin and end state change. So time only elapses in a state. Runs are frequently used to give a semantics to reactive systems [90, 122]. They are also used as a semantic domain in model checking [42]. So, runs are suitable to represent the behaviour of workflows and in addition can be used for model checking functional requirements. Moreover, the UML action semantics [12] employs a similar notion as semantic domain.
Since a run is a possible behaviour of a WFS, states of the run are states of the WFS. Keeping in mind the characteristics of a WFS, we define that a state of a run consists of the following components:
• the state of the case (i.e, which nodes in the activity diagram are active, possibly multiple times),
• the queue of input events of the WFS, • the case attributes and their values, and
• the scheduled timeouts and the value of the internal clock.
1Sometimes, there can be confusion if the WFS runs on the same computer as the application
4.2· Petri net token-game semantics versus statechart semantics 43