BPMN and Beyond Business process modelling notation, workflow ...

WorkflowTransition(node) represents an abstract state machine, in fact a scheme (sometimes
also called a pattern) for a set of concrete machines that can be obtained by further specifying
the guards and the submachines for each given node. In the next section we illustrate such
an instantiation process to define the behavior of BPMN gateways by ASM rules taken from the
high-level BPMN interpreter defined in [13].
5 Instantiating WorkflowTransition for BPMN Gateways
In this section we instantiate WorkflowTransition for BPMN gateways, nodes standing for
one of the three types of BPMN flow objects. The other two types are event and activity nodes,
whose behavior can be described by similar instantiations, see [13] for the details. We start with
the rule for so-called complex gateway nodes, from which the behavior of the other BPMN gateway
constructs can be defined as special cases.
5.1 ComplexGateTransition
Gateways are used to describe the convergence (also called merging) and/or divergence (also called
splitting) of control flow, in the sense that tokens can ‘be merged together on input and/or split
apart on output’ [15, p.68]. For both control flow operations one has to determine the set of
incoming respectively outgoing arcs they are applied to at the given node. The particular choices
depend on the node, so that we represent them by two abstract selection functions, namely to
select Consume the incoming arcs where tokens are consumed,
select Produce the outgoing arcs where tokens are produced.
Both selection functions come with constraints: select Consume is required to select upon each
invocation a non-empty set of enabled incoming arcs, whose firingTokens are to be consumed in
one transition. 5 select Produce is constrained to select upon each invocation a non-empty subset
of outgoing arcs o satisfying an associated OutCond(o). On these arcs complxGateTokens are
produced, whose particular form may depend on the firingTokens. We skip that in addition, as
(part of) DataOp(node), multiple assignments may be ‘performed when the Gate is selected’ [15,
Table 9.30 p.86] (read: when the associated rule is fired).
ComplexGateTransition(node) =
let
I = select Consume (node)
O = select Produce (node)
in WorkflowTransition(node, I , O)
where
CtlCond(node, I ) = (I ≠ ∅ and forall in ∈ I Enabled(in))
CtlOp(node, I , O) =
if O ≠ ∅ and O ⊆ {o ∈ outArc(node) | OutCond(o)} then
ProduceAll({(complxGateToken(firingToken(I ), o), o) | o ∈ O})
ConsumeAll({(t i , in i ) | 1 ≤ i ≤ n}) where
[t 1 , . . . , t n ] = firingToken(I ), [in 1 , . . . , in n ] = I
5 A function firingToken(A) is used to express a structural relation between the consumed incoming and
the produced outgoing tokens, as described in [15, p.35]. It is assumed to select for each element a of
an ordered set A of incoming arcs some of its token(a) to be Consumed. For the sake of exposition
we make the usual assumption that inQty(in) = 1, so that we can use the following sequence notation:
firingToken([a 1 , . . . , a n ]) = [t 1 , . . . , t n ] denotes that t i is the token selected to be fired on arc a i .
7