hyperedges.
We now show that this difference in event processing, parallel event versus single event, does not have any impact upon which hyperedges are taken: under the RLS the same internal and completion hyperedges can be taken as under the ILS. By Constraint C6, completion and internal hyperedges do not conflict. Thus, taking an internal hyperedge under the RLS does not disable an enabled comple- tion hyperedge. By Constraint C8, taking an internal hyperedge does not disable another enabled internal hyperedge. By Constraint C5, conflicting completion hyperedges have the same sources. So under the RLS the same completion and internal hyperedges can be taken as under the ILS and the same configuration can be reached as under the ILS.
¾
Note that this theorem does not require Constraint C11, so under the RLS the environment does not need to regenerate events.
6.3
Conclusion
We have shown that for some activity diagrams the requirements-level and imple- mentation-level semantics behave similarly. The major difference between the two semantics is that under the implementation-level semantics an external (non- termination) event can have unexpected extra effects. Therefore, the two semantics only induce similar behaviour if events are not observed. Even though this may seem weak, the theorems are sufficiently powerful to guarantee that the CTSs of both semantics satisfy the same functional requirements, as we will show in Chapter 10. Of course, such common functional requirements do neither refer to events. Since the requirements-level semantics induces a much smaller state space than the implementation-level semantics, such functional requirements can be more efficiently verified under the requirements-level semantics than under the implementation-level semantics. Yet the outcome of verification under the require- ments-level semantics is equivalent to the outcome under the implementation-level semantics.
In this chapter, we have justified a semantics that assumes perfect synchrony by relating it to a semantics that does not make that assumption. In every other approach we know from literature, a semantics that assumes perfect synchrony is justified by putting an assumption upon both the environment and the system: The system should be fast enough in its reaction to current events to be ready before the next events occur. Our justification is more realistic and also more general (allowing more implementations): we allow the environment to be faster than the system. Drawback of our approach is that it is more involved and that it requires some additional constraints on activity diagrams, the implementation-
104 Chapter 6· Relation between the two formal semantics level semantics, and the environment. It is possible to relax some of the constraints, but this will complicate the proofs.
The identified constraints on activity diagrams may serve as guidelines for workflow modellers. If an activity diagram violates the constraints, then likely some construct in the activity diagram might lead to misinterpretation, at least by different WFSs and perhaps also by different persons.
Chapter 7
Advanced activity diagram
constructs
In this chapter we discuss several advanced constructs for activity diagrams that we did not consider in the previous chapters. We will sketch how these constructs can be formalised in our two semantics, but do not provide the formalisations themselves. In the case of object flows and object nodes, we do not sketch a formalisation as this is premature. Instead we provide a list of issues that need to be resolved in formalising object flows.
Section 7.1 sketches how dynamic concurrency can be formalised. Section 7.2 discusses several issues regarding object nodes and object flows. Section 7.3 dis- cusses deferred events. Section 7.4 sketches how an interrupt construct can be formalised.
7.1
Dynamic concurrency
In the UML, an atomic activity node or a compound activity node can have “dy- namic concurrency”. The activity (or activities) of a node with dynamic concur- rency is instantiated multiple times in parallel, denoted by marking the activity node (or compound activity node) with ‘*’. The word ‘dynamic’ indicates that the number of instantiations is determined at run-time. The word ‘concurrency’ indicates that the instantiations execute in parallel. In Figure 7.1 an example of dynamic concurrency within an activity node is given (adapted from Fowler [71]). First, an order is received. Next, the order is filled with each line item on the order. Finally, the order is delivered. The number of instantiations of Fill line item is dynamic (i.e. determined at run-time), since this number depends on the order that is being processed.
106 Chapter 7· Advanced activity diagram constructs We now sketch how dynamic concurrency can be formalised for activity nodes and compound activity nodes.
Activity nodes. We assume a set DN ⊆ AN of atomic activity nodes whose activities are dynamically instantiated. Every activity node a in DN is annotated with a dynamic concurrency expression∗[expr]. We assume ∗[expr] evaluates to a list of elements, so∗[expr] is of type list. If a is entered, for every element e in list [expr ] an activity act (a)e is started. If all started activities are completed,
a terminates. So activity node a now represents the execution of a dynamically determined number of activities, rather than the execution of one single activity.
We do not have to change our definition of configuration and steps, since for both an activity node with dynamic concurrency and an ordinary activity node, the node is part of the configuration and the node terminates. Only the function act needs to be redefined: it is not static anymore, but dynamic: the activities assigned to an activity node that has dynamic concurrency are defined when the dynamic concurrency expression is evaluated, i.e. when the node is entered.
Compound activity nodes. In Section 3.3 we explained how compound activ- ity nodes can be eliminated from an activity diagram by substituting the activity diagram specification of the compound activity node. If the compound activity node contains a dynamic concurrency expression∗[expr], we treat the activity dia- gram specification as a parametrised specification. Assuming∗[expr] evaluates to a list of elements, for each element in the list an instance of the activity diagram specification is executed.
We can model this by adapting the elimination procedure of a compound activ- ity node as follows. We create a copy of the activity diagram specification for each possible element of the list. For every copy, each node of the copy is subscripted with the name of the corresponding element; so, different copies of activity dia- grams have different nodes. We create a new activity diagram specification n, in which all these copies are put in parallel (so they are started at the same time). Only copies present in the list need to be executed: therefore before each copy is started it is decided in n to either start the copy or skip the copy. The decision depends upon the evaluation of∗[expr]. The decision is a simple test whether an element belongs to the list∗[expr] or not: if so, the copy is executed, otherwise it is skipped.
We illustrate the adapted elimination procedure by a simple example. Let compound activity node B in Figure 7.2 have a dynamic concurrency expression dce that evaluates into a list of integers. Let this dynamic concurrency expression depend on some local variable x , where x has type integer, set by activity A. If B is specified as in Figure 7.3, then the activity diagram after elimination of compound node B becomes as depicted in Figure 7.4. Note that there are infinitely many copies made of the activity diagram specifying B, since there are infinitely many integers.
7.1· Dynamic concurrency 107 Receive order Fill line item Deliver order *
Figure 7.1 Example: multitask
B
A
*
Cx: Integer
Figure 7.2 Dynamic concurrency example
D E
Figure 7.3 Specification of node B in Figure 7.2
A D_0 E_0 D_1 E_1 D_n E_n [0 in [[dce]] ] [1 in [[dce]] ] [n in [[dce]] ] WAIT [else] WAIT WAIT C [else] [else] . . . . . . . . . . . .
Figure 7.4 The activity diagram underlying the activity diagrams in Figures 7.2
108 Chapter 7· Advanced activity diagram constructs