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

3 Framework for BPMN Execution Model
In this section we instantiate WorkflowTransitionInterpreter to a schema for an execution
model for BPMN diagrams. It is based upon the standard for the Business Process Modeling
Notation (BPMN) as defined in [15]. In some cases we first formulate a general understanding
of the concept in question and then explain how it can be adapted to the specific use as defined
in BPMN. This is not to replace the BPMN standard, but only to provide a companion to it
that explains the intended execution semantics in a rigorous high-level way and points out where
attention has to be paid to the possibility of different interpretations of the standard document, due
to ambiguities or underspecification. We mention here only those parts of the standard document
that directly refer to the semantic behavioral interpretation of the constructs under investigation.
In particular, besides what is explained in Sect. 3.1 we use numerous elements of the metamodel
without further explanations, refering for their definition to the standard document.
3.1 Business Process Diagram Elements
We summarize here some of the elements which are common to every business process diagram:
flow objects of various types residing at nodes connected by arcs, tokens used to represent control
flow, a best practice normal form for such diagrams, etc. In a full formalization one would have to
present these elements as part of a BPMN metamodel.
The graph interpretation graph(process) of a BPMN business process diagram specifies the
nodes of this diagram as standing for three types of so-called flow objects, namely activities, events
and gateways. We represent them as elements of three disjoint sets:
Node = Activity ∪ Event ∪ Gateway
To define the behavioral meaning of each BPMN flow object one may find in a node, we instantiate
in the WorkflowTransition(node) scheme the guard expressions and the submachines
to capture the verbal explanations produced in the standard document for each of the three flow
object types. Each object type needs a specific instantiation type on can roughly describe as follows.
To interpret the elements of the set Event we have to instantiate in particular the event conditions
in the guard and the event operations in the body of WorkflowTransition(node).
The instantiation of EventCond(node) interprets the cause (‘trigger’) of an event happening at
the node; the instantiation of EventOp(node) interpretes the result (‘impact’) of the events
(on producing other events and consuming the given ones) at this node.
The interpretation of the elements of the set Gateway involves instantiating the guard expressions
CtlCond(node) and the submachines CtlOp(node) of WorkflowTransition(node).
Accompanying instantiations of DataCond(node) and DataOp(node) reflect what is needed
in cases where also state information is involved to determine how the gateway controls the
convergence or divergence of the otherwise sequential control flow.
The interpretation of the elements of Activity involves instantiating the guard expressions
DataCond(node) and the submachines DataOp(node) of WorkflowTransition(node). For
so-called non-atomic activities, which involve subprocesses and possibly iterations over them,
we will see a simultaneous instantiation also of the CtlCond(node) guards and of the submachines
CtlOp(node) to determine the next activity.
Thus an instance of WorkflowTransitionInterpreter for BPMN diagrams is defined by
instantiating a) the particular underlying scheduling mechanism (i.e. the functions select Node and
select WorkflowTransition ) and b) WorkflowTransition(node) for each type of node. The result of
such an instantiation yields a BPMN interpreter pattern, which can be instantiated to an interpreter
for a particular business process diagram by further instantiating the WorkflowTransition(node)
scheme for each concrete node of the diagram. This implies instantiations of the diagram related
abstractions used by WorkflowTransition(node), as for example various attribute values. We
deal with such items below as location instances, the way it is known from the object-oriented
programming paradigm.
6