Behavior-based Decomposition of BPMN 2.0 Control Flow
Jan Kubovy, Dagmar Auer and Josef K¨ung
Institute for Application Oriented Knowledge Processing, Johannes Kepler University in Linz, Linz, Austria
Keywords:
BPMN, Behavior Patterns, Decomposition, Modeling, Formal Method, ASM.
Abstract:
The Business Process Model and Notation (BPMN) is a well-established industry standard in the area of
Business Process Management (BPM). However, still with the current version 2.0 of BPMN, problems and
contradictions with the underlying semantics of the meta-model can be identified. This paper shows an al-
ternative approach for modeling the BPMN meta-model, using behavior-based decomposition. The focus in
this paper is on control flow. We use Abstract State Machines (ASM) to describe the decomposition of the
merging and splitting behavior of the different BPMN flow node types, such as parallel, exclusive, inclusive
and complex, as defined in the BPMN 2.0 standard, resulting in behavior patterns. Furthermore an example
for the composition of different gateway types is given using these behavior patterns.
1 INTRODUCTION
The Business Process Model and Notation (BPMN)
is a well-established industry standard in the area
of Business Process Management (BPM). Although
BPMN is claiming a formal and clear underlying
semantics some problems and contradictions have
been discovered. Those problems were addressed by
the scientific society using different formal methods,
such as Petri Nets (Dijkman et al., 2007) or Abstract
State Machine (ASM) method (B¨orger and Thalheim,
2008a; B¨orger and S¨orensen, 2011). Much effort
has been put into providing a formal layer, enhanc-
ing the existing informal meta-model for the BPMN
standard. We base our work on the ASM approaches
stated above. The ASM method (B¨orger and St¨ark,
2003) evolved from Evolving Algebras (Gurevich,
1995). We use ASMs to formalize the BPMN meta-
model. Our refinements follow the process execution
conformance (Object Management Group (OMG),
2011, chap. 2.2) and formalize the particular part, we
call behaviors.
The need for a formal technique to model work-
flows has already been considered in approaches
before. E.g., formalizing existing workflow mod-
els by mapping them to well established formalism,
i.e., Petri Nets (van der Aalst, 1998) further evolved
into Yet Another Workflow Language (YAWL) trying
to satisfy the needs of universal organizational the-
ory and standard BPM concepts (van der Aalst and
ter Hofstede, 2003). About the same time BPMN
emerged and became a popular, widely-used standard
in the area of BPM, among others, because of its in-
tuitive graphical notation and mapping to Business
Process Execution Language (BPEL) (Organization
for the Advancement of Structured Information Stan-
dards (OASIS), 2007).
In this paper we will first describe the enabling
token set concept in section 3, which is essential for
activation of flow nodes across instances in one step.
We continue with introducing the behavioral decom-
position in section 4 and show three main behaviors:
the gate behavior in section 4.1, the merge behavior
in section 4.2 and the split behavior in section 4.3.
We will discuss all possible merge and split behavior
types, i.e., parallel, exclusive, inclusive and complex.
Finally, these behaviors are used to define the gate-
way transition rules in section 5. Furthermore, we
give an example of how such a behavior-based ground
model (the blue print of the designed system (B¨orger
and St¨ark, 2003)) can be easily extended by another
element in section 6. Section 7 concludes our results.
2 MOTIVATION
The Business Process Model and Notation (BPMN),
in current version 2.0, (Object Management Group
(OMG), 2011) is well established for describing
business processes. With September 2013 BPMN
has become an ISO/EC-Standard (reference number
19510:2013). Still the standard has some ambigu-
ities and inconsistencies. While participating in a
263
Kubovy J., Auer D. and Küng J..
Behavior-based Decomposition of BPMN 2.0 Control Flow.
DOI: 10.5220/0004862302630271
In Proceedings of the 16th International Conference on Enterprise Information Systems (ICEIS-2014), pages 263-271
ISBN: 978-989-758-029-1
Copyright
c
2014 SCITEPRESS (Science and Technology Publications, Lda.)
project with the focus to formally describe the BPMN
standard, we dealt with those inconsistency problems
and improved the meta-model structure to improve
reusability. Those problems appear in both, the ver-
tical refinements on one hand and the horizontal ex-
tensions to BPMN on the other. When formalizing
the BPMN meta-model, duplicates appeared to be the
reason for many of the inconsistencies in the existing
standard. Thus, we try to extract the common behav-
ior patterns, resulting in a revised, more compact, and
graspable meta-model.
This work is based on process diagram as de-
scribed in the BPMN 2.0 specification. This particular
notation is chosen since it is popular between process
designers and modelers and is the most commonly
used graphical representation for business processes
(Kubovy et al., 2012). We believe that the usability of
our outputs will be supported by the fact that the po-
tential reader does not have to work him/her-self into
a completely new process modeling notation.
We start with the BPMN modeling practices,
which contain among others gateway pairing or re-
striction of sequence flows on one flow node side
(Freund et al., 2010). This may improvereadability of
simple diagrams, increase clearness and reduce ambi-
guity of even complex diagrams, but increases com-
plexity of the diagrams in general since the amount of
flow nodes in a process diagram dramatically bursts.
By simplifying the meta-model, we achieve an un-
ambiguous, clear, correct and more graspable meta-
model, which is important for conformance and de-
ployment. But the complexity growth of such process
models may be harder to maintain during develop-
ment and lower sustainability of processes based on
such a meta-model.
One possible solution is to introduce containers
(for the use in graphical notations) or macros (for the
use in formal descriptions). We can demonstrate this,
e.g, by restricting all flow nodes except gateways to
only one incoming and one outgoing sequence flow.
Handling the splitting and merging behavior will then
remain only in one place, the gateway. Still, during
the modeling of a process diagram we will not want
to place a gateway in front or after every flow node
merging or splitting more sequence flows. Thus, con-
tainers may be introduced to model extended model-
ing elements. Such containers will then hold multiple
elements from the meta-model and establish a com-
plex element keeping the model clean from problems,
e.g., duplicate definitions, but enables the advantages
of simple or basic (read small and graspable) model-
ing elements. This way we may concentrate on the
essential purpose of the different flow node types and
compose the complex flow elements, defined in the
Figure 1: A BPMN activity composed using a container
with two simple gateways and one simple activity.
BPMN standard using such simple flow elements. An
example of a BPMN activity as a container using a
simple activity and two simple gateways is depicted in
figure 1). Here we define a Simple Activity limited to
exactly one incoming and one outgoing sequence flow
with no merging nor splitting behavior. The possibil-
ity of multiple incoming or outgoing sequence flows,
as described in the BPMN 2.0 standard, is enabled
with the two gateways in figure 1. The first is a simple
exclusive merge gateway, allowing only to merge the
flow using XOR-Join and the second is simple par-
allel split gateway allowing only to split the flow to
parallel paths. In the BPMN 2.0 standard both, the ac-
tivity and the exclusive gateway, define the exclusive
behavior and this leads to duplication in the standard
and may also lead to duplication in the implementa-
tion of a workflow engine. Similarly for parallel split
behavior of activity and parallel gateway. We identify
such behaviors, which can be extracted and defined
separately. We compose the complex flow elements
using such behaviors. An advantage of this approach
will be demonstrated by example in section 6 by ex-
tending the BPMN 2.0 meta-model with a sole exclu-
sive gateway.
3 ENABLING TOKEN SET
A token set is a set of tokens of the same instance,
from distinct incoming sequence flows of one flow
node. This set may potentially fire the given flow
node. However, this has to be decided by a fire con-
dition we will discuss later in this paper. We use
enablingTokenSets
shown in figure 2 to return sets
of such token sets. In every token set all tokens have
to belong to one instance. No two tokens residing in
the same sequence flow can be present in the same to-
ken set. For example, there will be a flow node with
three incoming sequence flows SF
1
, SF
2
and SF
3
on
which tokens from two different instances, I
A
and I
B
,
will reside. The token distribution is the following:
sequence flow SF
1
contains two tokens of instance I
A
and one token of instance I
B
, sequence flow SF
2
con-
tains one token of each instance and sequence flow
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
264
SF
3
contains two tokens of instance I
B
. The follow-
ing four sets of tokens will be returned: Set 1 will
contain two tokens of instance I
A
from sequence flow
SF
1
and SF
2
. Set 2 will contain one token of instance
I
A
from sequence flow SF
1
. Set 3 will contain three
tokens of instance I
B
from all the three incoming se-
quence flows. And last set 4 will contain one token of
instance I
B
from the sequence flow SF
3
. Each of the
token sets may or may not fire the given flow node,
dependingon the
MergeBehavior
defined later in this
paper. The order of the token sets in the
enabling-
TokenSets
and the order of tokens in one set is irrel-
evant.
derived enabli ngT o k e nSet s ( node ) =
r et u rn re s in
l oc a l s ele ct ed , a ll , s et in
re s := {}
se t := {}
a l l := ( [ t | t i s i n TOKENS holds
sequenceFlowOf ( t ) i s i n incoming (
node ) ])
while a l l != {} do
s el e c te d := undef
i f s et ={} then choose s e le c t ed
i s i n a l l
e ls e choose s e l e c t e d i s i n a l l
with
f o r a l l token i s i n s e t holds
sequenceFlowOf ( token ) !=
sequenceFlowOf ( s e le c t ed )
and instanc eOf ( token ) =
instance O f ( se l e ct e d )
i f s e l e c te d != undef
add s el e c te d to s e t
remove s e l ec t e d from a l l
i f s e l e c te d = undef or a ll = {}
add se t to re s
s et := {}
Figure 2: Derived function for retrieval of enabling token
sets for possible flow node activation.
4 BEHAVIORAL
DECOMPOSITION
For decomposing we use a slightly different approach
than containers discussed in section 2, still targeting
the same issues. We define behavior patterns, similar
to (B¨orger and S¨orensen, 2011), and then reuse such
patterns as building blocks to define the BPMN ele-
ments. This has, among others, the advantage that the
intermediate step of defining simple flow nodes is not
necessary. Furthermore, we can dynamically switch
those building blocks using for example polymorphic
or other suitable techniques. This allows to define one
Figure 3: Parallel gateway decomposition using behavioral
building blocks.
Figure 4: Activity decomposition using behavioral building
blocks.
element instead of multiple container elements form-
ing all possible combinations. E.g., the activity exam-
ple in figure 1 would result in more than one container
if we would also consider activities with no incoming
or outgoing sequence flows or any combinations of
the above. An example of a parallel gateway behav-
ior decomposition is shown in figure 3. Using such
behavioral building blocks will result in figure 4 to
model the discussed BPMN activity. This time we
do use much simpler building elements to compose
the resulting flow node than using containers in fig-
ure 1. The reuse of such building block elements in-
creases and the resulting meta-model definition will
decrease in size and complexity (a behavior is defined
only once). This is the core decomposition idea we
will use in this paper to formally model the BPMN el-
ements. This introduction should sketch the abilities
and advantages of behavioral decomposition. This
also comprises with the requirements capture of a sys-
tem (B¨orger and St¨ark, 2003), which is BPMN in our
case, as we describe the behaviorof each modeled ele-
ment and split it into small parts based on similarities,
observation and best practices (Freund et al., 2010).
For depicting behaviors, we use a square or rect-
angle (half as wide as high) both with sharp corners.
This was chosen not to collide with any BPMN sym-
bols. Inside the squares resides a BPMN symbol iden-
tifying the simple behavior. We use the designation
“simple” for flow elements which deal with only the
core of their purpose. An activity behavior, for exam-
ple, does not deal with multiple incoming or outgo-
ing sequence flows, just with performing an activity -
dealing with the activity life-cycle. Similarly, the sim-
ple gateway behavior just deals with decision making,
e.g., how the flow is merged or split. The quantity of
incoming and outgoing sequence flows is realized by
the input or output behavior as shown in Figure 3 and
4 as join and split behavior. In the next sections we
will show, how this can be implemented.
Behavior-basedDecompositionofBPMN2.0ControlFlow
265
derived canPassThrough ( node , sequenceFlow , behavi or ) =
r et u rn re s in
l e t otherSequenceFlows := outgoing ( node ) \ sequenceFlow in
i f gateCondi ti on ( sequenceFlow ) = ”DEFAULT” then
re s := f o r a l l outSequenceFlow i s i n otherSequenceFlows holds
gateCondi t io n ( outSequenceFlow ) = FALSE
e ls e i f behavior = ”EXCLUSIVE” then
re s := gat eCondi ti on ( sequenceFlow ) = TRUE
and f o r a l l outSequenceFlow i s i n otherSequenceFlows holds (
gateCondi t io n ( outSequenceFlow ) != ”DEFAULT”
and gateC ondit ion ( outSequenceFlow ) = FALSE)
e ls e i f behavior = ”INCLUSIVE” then
re s := gat eCondi ti on ( sequenceFlow ) = TRUE
Figure 5: Derived function determining if a token residing on a given sequence flow can pass through the given flow node.
4.1 Gate Behavior
A gate is a mechanism, which somehow controls the
flow. As in the real world, a gate has a guard watch-
ing the gate and letting in only those who fulfill cer-
tain conditions modeled by the
gateCondition
in
figure 5.
A simple gate can be seen as a condition, which
has to hold in order to let a token pass through. This
mechanism will be further used in controlled flow,
which is realized in the BPMN 2.0 specification us-
ing conditional sequence flows, gateways, but also
other flow nodes, which implicitly allow control of
the sequence flow. Since all flow elements share this
behavior, it is extracted as a building block to allow
reuse further in this paper. To notate this behavior a
small diamond shape is used, shared for both the con-
ditional sequence flows and gateways (Object Man-
agement Group (OMG), 2011).
4.2 Merge Behavior
A flow node may have one or more incoming se-
quence flows. In case of multiple incoming sequence
flows such a flow node needs some kind of merging
behavior. For this the symbols shown in figure 6a
(van der Aalst, 1998) in conjunction with the differ-
ent types - parallel shown in figure 6c, exclusive in
figure 6d, inclusive in figure 6e and complex in figure
6f. For the different merging behavior types, we use
the same symbols as in BPMN 2.0 inside the square
symbolizing a behavior.
A merge behavior in general identifies possible
enablingTokenSets
of a flow node, each able to fire
the given flow node. The given flow node can fire
once or even multiple times in some cases. A token
set in this sense is a combination of tokens residing
on distinct incoming sequence flows of the given flow
(a) merge (b) split (c) parallel
(d) exclusive (e) inclusive (f) complex
Figure 6: The different used behaviors.
node with a distribution possibly able to fire the given
flow node. There are no tokens in one set, which share
the same incoming sequence flow and instance of a
process or sub-process. A set of such sets will be used
further in this paper to handle all possible, even multi-
ple, fires across the process or sub-process instances.
Every time a flow node fires, all
firingTokens
of the
flow node will be consumed. Such
firingTokens
are a union of all tokens in all
enablingTokenSets
,
which can actually fire the given flow node. The
rule
MergeBehavior
shown in figure 7 defines the abstract
behavior pattern for merging multiple sequence flows
of a flow node. This rule returns all relevant instances
of a (sub-)process containing the given flow node, in
which the flow node fired. The size of the set of these
firingInstances
identifies the number of fires and
each item in this set is a process instance, in which
the given flow node fired. Any tokens, which con-
tributed to any of the fires returned by the abstract
derived firingTokens
function, has to be in one of
the instances returned by the
firingInstance
func-
tion and has to be consumed.
Parallel Merge Behavior: firing a flow node if
there is a token on every incoming sequence flow of
that flow node (Object Management Group (OMG),
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
266
ru l e MergeBehavior ( node ) =
r et u rn re s in
f o r a l l token i n f ir ing To ke ns ( node
) do
ConsumeToken ( token )
re s := f i r i n g I n s t a n c e s ( node )
Figure 7: Rule defining the behavior for merging multiple
sequence flows.
2011, Tab. 13.1). The possibility of multiple in-
stances has to be taken into account. This is real-
ized by the mentioned
enablingTokenSets
, where
each token set only contains tokens from the same in-
stance and different incoming sequence flows. The
rule ParallelMergeBehavior
has to check if each
set contains a token for all incoming sequence flows.
It (see figure 8) returns tokens from incoming se-
quence flows if and only if all of the incoming se-
quence flows have a token realized using
enabling-
TokenSets
. Therefore a token will be returned from
firingTokens
if and only if such a token is in a token
set containing a token for each incoming sequence
flow. The quantity of
firingInstances
represents
the minimum quantity of tokens in one of the incom-
ing sequence flows for a certain instance. Using the
enablingTokenSets
it is possible to separate multi-
ple tokens from the same instance.
ru l e Par all el M e rgeB e havior ( node ) =
MergeBehavior ( node ) where
fi ri ngT oke ns ( node ) =
re t u rn r es in
re s := ( [ t | t i s i n tokenSet ,
tokenSet i s i n
enablingT okenS e ts ( node ) holds
f o r a l l sf i s i n incoming ( node )
e x i s t s tokenInSameSet i s i n
tokenIn ( sf )
and tokenInSameSet i s i n
tokenSet ] )
f i r i n g I n s t an c e s ( node ) =
re t u rn r es in
choose s f i s i n incoming ( node ) i n
re s := ( [ i | i i s i n INSTANCES
holds
e x i s t s t i s i n f i ri ngT ok ens (
node )
and sequenceFlowOf ( t ) = s f
and inst anceO f ( t ) = i ] )
Figure 8: Rule defining the behavior for parallel merging of
multiple sequence flows.
Exclusive Merge Behavior: firing a flow node if
there is at least one token on at least one incoming
sequence flow of that flow node (Object Management
Group (OMG), 2011, Tab. 13.2). Taking multiple in-
ru le ExclusiveMergeBehavior ( node ) =
MergeBehavior ( node ) where
fi ri ngT oke ns ( node ) =
r et u rn re s in
re s := { t | t i s i n TOKENS holds
e x i s t s sf i s i n incoming ( node )
t i s i n tokensIn ( sf ) }
f i r i n g I n s t a n ce s ( node ) =
r et u rn re s in
re s := { i | i i s i n INSTANCES
holds
e x i s t s t i s i n f i ri ngT ok ens ( node
)
instance O f ( t ) = i }
Figure 9: Rule defining the behavior for exclusive merging
of multiple sequence flows.
ru le Inc l usi veMerge B ehavi or ( node ) =
MergeBehavior ( node ) where
fi ri ngT oke ns ( node ) =
r et u rn re s in
re s := ( [ t | t i s i n tokenSet ,
tokenSet i s i n
enablingT okenS e ts ( node ) holds
UpstreamToken ( node , incoming ( node
) , tokenSet , in s tanc e Of ( t ) ) ={}
] )
f i r i n g I n s t a n ce s ( node ) =
re s := ( [ i | i i s i n INSTANCES
holds
e x i s t s t okenSe t i s i n ( [ t s | t s
i s i n enablingT okenS e ts ( node )
holds
e x i s t s t i s i n f i ri ngT ok ens (
node )
and t i s i n t s ] )
e x i s t s token i s i n tokenSe t
and inst anceO f ( token ) = i ] )
Figure 10: Rule defining the behavior for inclusive merging
of multiple sequence flows.
stances into account, this behavior will fire the given
flow node for every token residing in any directly
incoming sequence flow in any instance. The
rule
ExclusiveMergeBehavior
shown in figure 9 refines
the
rule MergeBehavior
. This behavior fires the
given flow node for any token that is present on any of
the incoming sequence flows. No matter if only one
or more tokens from the same instance are present on
the directly incoming sequence flows, all will be re-
turned. It may also fire multiple times in the same
instance. Therefore the returned set of instances from
firingInstances
may contain duplicate instances.
Behavior-basedDecompositionofBPMN2.0ControlFlow
267
ru l e ComplexMergeBehavior ( node ) =
MergeBehavior ( node ) where
l e t firingTokensForNode := {} , fi ri ngI nst an c es For No de := in
f o r a l l tokenSet i s i n enabl ingT okenS ets ( node ) do
choose tok i s i n toke nSet do
/ / Waitig f or s t a r t s t a t e :
i f wa i ti n gF or S ta rt ( node , i nst anceOf ( tok ) ) then
i f a ct iv a ti o nC o n di ti o n ( node , i nst ac e Of ( tok ) ) then
ignoreDur ingR e set ( node , i nst a nceOf ( tok ) ) := { sf | s f i s i n incoming ( node )
holds
e x i s t s t i s i n t okenS e t and sequenceFlowOf ( t ) = s f }
wa i ti n gF or S ta rt ( node , in st ac eO f ( tok ) ) := FALSE
f o r a l l t in t okenS et add t to firingTokensForNode
add inst anceO f ( tok ) to f ir ing Ins ta nc es For No de
e ls e / / Waitig fo r r e s e t s t a t e :
l e t r e l ev a nt := ( incoming ( node ) \ ignoreDuri ngRes e t ( node , i nst anceOf ( tok ) ) )
in
i f UpstreamToken ( node , re le va nt , tokenSet , instanceO f ( tok ) ) = {} then
ignoreDur ingR e set ( node ) = undef
wa i ti n gF or S ta rt ( node , i nst anceOf ( tok ) ) := TRUE
f o r a l l t in t okenS et add t to firingTokensForNode
add inst anceO f ( tok ) to f ir ing In s ta nce sF or No de
derived f ir in gT ok ens ( node ) = firingTokensForNode
derived f i r i n g I n st a n ce s ( node ) = fi ri ngI nst an c es For No de
Figure 11: Rule defining the behavior for complex merging of multiple sequence flows.
Inclusive Merge Behavior: firing the flow node
if there is at least one token on at least one in-
coming sequence flow and there are no
Upstream-
Token
s (V¨olzer, 2010) related to that flow node (Ob-
ject Management Group (OMG), 2011, Tab. 13.3).
The
rule InclusiveMergeBehavior
shown in fig-
ure 10 refines the
rule MergeBehavior
and fires
the given flow node if at least one token is present
on any of the directly incoming sequence flows and
there is no token in the process, which “may arrive”
(V¨olzer, 2010). This is defined using the mentioned
UpstreamToken
rule. If no such upstream token ex-
ists, this behavior will fire. It will return the contribut-
ing tokens from all
enablingTokenSets
, which fired
the flow node. All possible instances of those tokens
will be return by the
firingInstances
function.
Complex Merge Behavior: defines two activation
behaviors: first, when the flow node is in
waiting-
ForStart
state, and second, if it is not in that
state. In the first case the flow node gets fired if
the
activationCondition
holds and in the sec-
ond one it is fired if all
Upstream Token
s from
the first phase arrive (Object Management Group
(OMG), 2011, Tab. 13.5), i.e., same as
Inclusive-
MergeBehavior
without
sequenceFlowsToIgnore-
DuringReset
, which are those that fired the flow
node in the
waitingForStart
state. The
rule
ComplexMergeBehavior
shown in figure 11 takes,
compared to other merge behaviors, the mentioned in-
ternal state into account. The internal state is updated
by this rule only. It may be read for the purpose of out-
going sequence flow conditions but not changed any-
more. Firing a flow node using this
ComplexMerge-
Behavior
in the
waitingForStart
state is straight
forward: only the
activationCondition
needs to
be fulfilled. In the “waiting for reset” state, the fir-
ing condition is much the same as in the
Inclusive-
MergeBehavior
shown in figure 10. The slight dif-
ference is that the set of relevant sequence flows ob-
served for a token, which “may arrive”, does not in-
clude the sequence flows, which contributed to the ac-
tivation in the first phase (Object Management Group
(OMG), 2011). The set of
firingTokens
only holds
those, which contribute to fire one of the
firing-
Instances
. All other tokens residing on any of the
directly incoming sequence flows of the flow node
will not be included in that set.
Here we can already see (in case of the “waiting
for reset” state) a reuse of previously defined parts,
which decreases the specification volume and enables
consistency in contrast to the original specification.
4.3 Split Behavior
Flow nodes may also have one or more outgoing se-
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
268
ru l e S pl it Be h avi or ( node , i ns t a n ce ) =
f o r a l l sequenceFlow i s i n
allowedOutgoing ( node )
ProduceToken ( sequenceFlow , i n s t an c e
)
Figure 12: Rule defining the behavior for splitting multiple
sequence flows.
quence flows. Such a flow node then needs some kind
of split behavior. For a splitting behavior the sym-
bols shown in figure 6b (van der Aalst, 1998) in con-
junction with the different types - parallel shown in
figure 6c, exclusive in figure 6d, inclusive in figure 6e
and complex in figure 6f. The
rule SplitBehavior
,
shown in figure 12, defines the abstract behavior
for splitting the flow into multiple sequence flows
of a flow node. This rule produces a token on all
allowedOutgoing
sequence flows for the given flow
node. According to BPMN 2.0 specification, we dis-
tinguish three different split behaviors: parallel, ex-
clusive, and inclusive split behavior.
Parallel Split Behavior: defining all existing di-
rectly
outgoing
sequence flows as
allowed-
Outgoing
sequence flows and producing a token on
each of them. The
rule ParallelSplitBehavior
(see figure 13) refines the
rule SplitBehavior
.
This is used as a default splitting behavior in BPMN
2.0 for any flow node except exclusive, inclusive,
complex and event-based gateways.
ru l e P a r a ll e l S p l it B e h a v io r ( node ,
in s ta nc e ) =
Sp li tB eha vi or ( node , i ns t an ce ) where
allowedOutgoing ( node )=outgoing ( node
)
Figure 13: Rule defining the behavior for parallel splitting
of multiple sequence flows.
Exclusive Split Behavior: determining if a token
canPassThrough
a flow node using a specific out-
going sequence flow and the ”EXCLUSIVE” be-
havior, producing a token on exactly one directly
outgoing
sequence flow, where the
gateCondition
allows such a passage. The
rule Exclusive-
SplitBehavior
shown in figure 14 refines the
rule
SplitBehavior
, which is used in exclusive gate-
ways.
Inclusive Split Behavior: determining if a token
canPassThrough
a flow node using a specific out-
going sequence flow and the ”INCLUSIVE” behav-
ior, producing a token on any subset of
outgoing
se-
quence flows, where the
gateCondition
allows such
a passage. The
rule InclusiveSplitBehavior
ru le E x cl usi veS pl it Beh avi or ( node ,
in s ta nc e ) =
Sp li tB eha vi or ( node , i ns t an c e ) where
allowedOutgoing ( node ) := ( [ s f |
sf i s i n outgoing ( node ) with
canPassThrough ( node , sf , ”EXCLUSIVE
”) ] )
Figure 14: Rule defining the behavior for exclusive splitting
of multiple sequence flows.
ru le I n cl u si v eS p li t Be h av i o r ( node ,
in s ta nc e ) =
Sp li tB eha vi or ( node , i ns t an c e ) where
allowedOutgoing ( node ) := ( [ s f | s f
i s i n outgoing ( node ) with
canPassThrough ( node , sf , ”INCLUSIVE
”) ] )
Figure 15: Rule defining the behavior for inclusive splitting
of multiple sequence flows.
shown in figure 15 refines the
rule SplitBehavior
,
which is used in inclusive and complex gateway.
5 GATEWAY TRANSITIONS
Now the required building blocks for gateways are
available (we discuss here only non-event-based gate-
ways). The
GatewayTransition
can be built along
with all the specific gateway type transition rules.
The
DataBasedGatewayTransition
shown in fig-
ure 16 defines a transition for non-event-based gate-
ways by refining the
WorkflowTransition
(B¨orger
and Thalheim, 2008b; B¨orger and Thalheim, 2008a).
It gathers relevant
enablingTokenSets
. If the con-
crete
MergeBehavior
allows to fire the given flow-
based gateway, it will producetokens on all
allowed-
Outgoing
sequence flows realized by the concrete
SplitBehavior
.
The
ParallelGatewayTransition
shown in fig-
ure 17, the
ExclusiveGatewayTransition
in fig-
ure 18, and the
InclusiveGatewayTransition
in
figure 19 are then simply composing the existing be-
havior patterns. This will be that simple for other
possible flow node transition rules as well, e.g.,
for activities or events. Other flow nodes will of
course refine a different rule than the
DataBased-
GatewayTransition
used for non-event-based gate-
ways where their specific behavior and additional
constrains may be defined.
More difficult is the case of
ComplexGateway-
Transition
shown in figure 20. There is a
specific
ComplexMergeBehavior
but no specific
SplitBehavior
. This is because the complex gate-
Behavior-basedDecompositionofBPMN2.0ControlFlow
269
ru l e DataBasedGatewayTransition ( node )
=
l e t f i r i n g I n s t a n c e s := MergeBehavior
( node ) in
r ul e WorkflowTransition ( node ) where
derived c ont ro lC on di tio n ( node ) =
r et u rn re s in
re s := f i r i n g I n s t a n c e s != {}
derived eventC ondit ion =
r et u rn re s in
re s := t r ue
r ul e C ontr olO p e rat ion ( node ) =
f o r a l l i ns t an ce i s i n
f i r i n g I n s t a n ce s
Sp li tB eha vi or ( node , i ns t an ce ) ;
r ul e EventOperation ( node ) =
skip
Figure 16: Rule DataBasedGatewayTransition.
ru l e Pa ra ll e lG at ewa yTr an sit io n ( node )
=
DataBasedGatewayTransition ( node )
where
r ul e MergeBehavior ( node ) =
Paral lel MergeB ehavi or ( node )
r ul e Sp li tB eha vi or ( node ) =
P a r al l e l S p li t B e h a v io r ( node )
Figure 17: Rule ParallelGatewayTransition.
ru l e Excl usi v e Gat ewayT rans it i on ( node )
=
DataBasedGatewayTransition ( node )
where
r ul e MergeBehavior ( node ) =
ExclusiveMergeBehavior ( node )
r ul e Sp li tB eha vi or ( node ) =
Ex cl us iv eS p li tB eha vio r ( node )
Figure 18: Rule ExclusiveGatewayTransition.
ru l e I nc lus ive Ga tew ayT ra nsi ti on ( node )
=
DataBasedGatewayTransition ( node )
where
r ul e MergeBehavior ( node ) =
Inclusi veMergeB ehavi o r ( node )
r ul e Sp li tB eha vi or ( node ) =
I nc l us i ve S pl i tB e ha v io r ( node )
Figure 19: Rule InclusiveGatewayTransition.
way split behavior is the same as for inclusive gate-
way (Object Management Group (OMG), 2011).
The above described behaviors enclose the formal
description of the meta-model for basic control flow
ru le ComplexGatewayTransition ( node ) =
DataBasedGatewayTransition ( node )
where
r ul e MergeBehavior ( node ) =
ComplexMergeBehavior ( node )
r ul e Sp li tB eha vi or ( node ) =
In c lu s iv e Sp l i tB e ha v i o r ( node )
Figure 20: Rule ComplexGatewayTransition.
definition. In the next section we will demonstrate
on an example, how this ground model can be ex-
tended. This demonstrates an appropriate decomposi-
tion of the meta-model, presented in this paper, which
enables an easy and correct horizontal extension.
6 EXAMPLE FOR EXTENDING
THE GROUND MODEL
We will demonstrate how simple it is to extend the
ground model, sketched in the previous sections of a
different behaviors and flow node types. Let’s look
closer at the exclusive gateway. What should hap-
pen, if there are more than one tokens distributed
on any of the incoming sequence flows. We defined
here that each of these tokens will fire the given gate-
way, resulting in possible multiple fires in one in-
stance and step. This behavior is based on the BPMN
2.0 specification (Object Management Group (OMG),
2011), e.g., the exclusive merging behavior for exclu-
sive gateways and activities. But this might be also
seen as a possible ambiguity. In some cases we might
want to use the exclusive gateway in situations, where
more than one token is present on any distinct incom-
ing sequence flow is not permitted. There is no way
to do that with the currently existing flow nodes and
behaviors defined above. Therefore, we decided to
extend the ground model.
For this purpose, we define a specialized
Merge-
Behavior
for the new sole exclusive gateway. Such
a gateway is allowed to have only one incoming se-
quence flow containing a token. Thus, more than one
incoming sequence flow containing a token is con-
sidered as a violation of the
rule SoleExclusive-
MergeBehavior
shown in figure 21 and will raise
an
AlternativePathViolation
error. On the other
hand multiple tokens in the same incoming sequence
flow will not raise such an error. This is considered as
correct behavior and will fire the given flow node for
each token residing in such a sequence flow.
We do not discuss here if more tokens on the
same incoming sequence flow is a correct interpre-
tation of an exclusive gateway or not. We allow this
ICEIS2014-16thInternationalConferenceonEnterpriseInformationSystems
270
ru l e SoleExclusiveMergebBehavior ( node
)=
c o n s t r a i n t A l t er n at i ve P a th V io l at i o n
=
f o r a l l se t i s i n ena bli n g T okenS et s (
node ) holds
| s et | = 1
ExlusiveMergeBehavior ( node )
Figure 21: Rule SoleExclusiveMergeBehavior.
since more than one tokens can be produced on the
same sequence flow for example by an activity if the
completionQuantity
attribute is greater than 1 (Ob-
ject Management Group (OMG), 2011, Tab. 10.3).
The goal of sole exclusive gateway is to correctly
merge alternative paths - distinct incoming sequence
flows to a given flow node. The aim of this paper is
also not to show this particular behavior as a problem.
The goal of this example is to show that if such
a behavior needs clarification, it can be easily in-
troduced by extending the ground model. We leave
the discussion about correct behavior of an exclusive
gateway to future work.
7 CONCLUSION
We showed an approach of a behavioral decompo-
sition of the BPMN 2.0 control flow concept. The
decomposition of the meta-model is demonstrated on
gateways, since we started with the merge behavior of
incoming sequence flows and split behavior of outgo-
ing sequence flows. The split and merge behaviors,
which are shared across other flow node types too,
such as activities or events, can be simply reused in
their transition rules as discussed in section 5. The
different flow node types can then be defined by com-
posing different behavior patterns as shown for activ-
ities in figure 4. The goal this decomposition is to
define a behavior once in a way it is reusable across
the defined system. This enables that such a model
is better graspable and understandable by the target
audience.
Also such a resulting ground model is easily ex-
tendable with other behaviors. This was shown on a
theoretical extension example in section 6, where the
discussed ground model was extended by a sole exclu-
sive gateway type. We leave the discussion about the
correct behavior of exclusive gateways to some future
work.
ACKNOWLEDGEMENTS
This work was supported in part by the Austrian Sci-
ence Fund (FWF) under grant no. TRP 223-N23.
REFERENCES
B¨orger, E. and S¨orensen, O. (2011). BPMN Core Modeling
Concepts: Inheritance-Based Execution Semantics. In
Embley, D. W. and Thalheim, B., editors, Handbook
of Conceptual Modeling: Theory, Practice and Re-
search Challenges, chapter 9. Springer-Verlag.
B¨orger, E. and St¨ark, R. F. (2003). Abstract State Machines
- A Method for High-Level System Design and Analy-
sis. Springer-Verlag.
B¨orger, E. and Thalheim, B. (2008a). A method for verifi-
able and validatable business process modeling. Ad-
vances in Software Engineering, LNCS, 5316:59–115.
B¨orger, E. and Thalheim, B. (2008b). Modeling Workflows,
Interaction Patterns, Web Services and Business Pro-
cesses: The ASM-Based Approach. In Proceedings
of the 1st international conference on Abstract State
Machines, B and Z, pages 24–38. Springer Berlin /
Heidelberg.
Dijkman, R. M., Dumas, M., and Ouyang, C. (2007). For-
mal Semantics and Analysis of BPMN Process Mod-
els using Petri Nets.
Freund, J., R¨ucker, B., and Heinninger, T. (2010). Praxis-
handbuch BPMN Incl. BPMN 2.0. Carl Hanser Verlag
M¨unchen Wien.
Gurevich, Y. (1995). Evolving Algebras 1993: Lipari
Guide. Specification and Validation Methods, pages
231–243.
Kubovy, J., Geist, V., and Kossak, F. (2012). A Formal
Description of the ITIL Change Management Process
Using Abstract State Machines. 2012 23rd Interna-
tional Workshop on Database and Expert Systems Ap-
plications, 0:65–69.
Object Management Group (OMG) (2011). Busi-
ness Process Model and Notation (BPMN) 2.0.
www.omg.org/spec/BPMN/2.0/.
Organization for the Advancement of Structured Infor-
mation Standards (OASIS) (2007). Web Services
Business Process Execution Language Version 2.0.
https://www.oasis-open.org/standards.
van der Aalst, W. M. and ter Hofstede, A. H. (2003).
YAWL: Yet Another Workflow Language. Informa-
tion Systems, 30:245–275.
van der Aalst, W. M. P. (1998). The Application of Petri
Nets to Workflow Management. Journal of Circuits,
Systems, and Computers, 8(1):21–66.
V¨olzer, H. (2010). A new semantics for the inclusive con-
verging gateway in safe processes. In Proceedings of
the 8th international conference on Business process
management, BPM’10, pages 294–309, Berlin, Hei-
delberg. Springer-Verlag.
Behavior-basedDecompositionofBPMN2.0ControlFlow
271
