Formal Model of Business Processes Integrated with Business Rules

Abstract

Business Processes describe the ways in which operations are carried out in order to accomplish the intended objectives of organizations. A process can be depicted using a modeling notation, such as Business Process Model and Notation. Process model can also describe operational aspects of every task; but in a properly designed model, the detailed aspects of low-level logic should be delegated to external services, especially to a Business Rule Engine. Business Rules support the specification of knowledge in a declarative manner and can be successfully used for specification of details for process tasks and events. However, there is no unified model of process integrated with rules that ensures data types consistency. Thus, the paper presents a formal description of the integration of Business Processes with Business Rules. We provide a general model for such integration as well as the model applied to a specific rule representation from the Semantic Knowledge Engineering approach.

Full text

https://doi.org/10.1007/s10796-018-9826-y
Formal Model of Business Processes Integrated with Business Rules
Krzysztof Kluza1·Grzegorz J. Nalepa1
©The Author(s) 2018. This article is an open access publication
Abstract
Business Processes describe the ways in which operations are carried out in order to accomplish the intended objectives of
organizations. A process can be depicted using a modeling notation, such as Business Process Model and Notation. Process
model can also describe operational aspects of every task; but in a properly designed model, the detailed aspects of low-level
logic should be delegated to external services, especially to a Business Rule Engine. Business Rules support the specification
of knowledge in a declarative manner and can be successfully used for specification of details for process tasks and events.
However, there is no unified model of process integrated with rules that ensures data types consistency. Thus, the paper
presents a formal description of the integration of Business Processes with Business Rules. We provide a general model for
such integration as well as the model applied to a specific rule representation from the Semantic Knowledge Engineering
approach.
Keywords Business process modeling ·Business rules ·Process with rules integration
1 Introduction
Business Process Management (BPM) (Dumas et al. 2013;
Weske 2012) is a holistic approach for improving organiza-
tion’s workflow in order to align processes with client needs.
It focuses on reengineering of processes to obtain optimiza-
tion of procedures, increase efficiency and effectiveness by
the constant process improvement.
According to this approach, a Business Process (BP) can
be simply defined as a collection of related tasks which pro-
duces a specific service or product for a customer (Lindsay
et al. 2003). Models of BPs are intended to be a bridge
between technical and business people. They are simple and
visualizations make them much easier to understand than
using a textual description. Thus, modeling is an essential
part of BPM.
The research presented in this paper is supported by the
HiBuProBuRul Project funded from NCN (National Science
Centre) resources for science (no. DEC-2011/03/N/ST6/00909).
Krzysztof Kluza
kluza@agh.edu.pl
Grzegorz J. Nalepa
gjn@agh.edu.pl
1AGH University of Science and Technology,
al. A. Mickiewicza 30, 30-059 Krakow, Poland
Although processes provide a universal method of de scribi ng
operational aspects of business, detailed aspects of process logic
should be described on different abstraction level. Business
Rules (BR) can be successfully used to specify process
low-level logic (Charfi and Mezini 2004; Knolmayer et al.
2000). What is important, the BR approach supports the
specification of knowledge in a declarative manner.
There is a difference in abstraction levels of BP and BR; how-
ever, rules can be to a certain degree complementary to proces-
ses. BR provide a declarative specification of domain knowl-
edge, which can be encoded into a process model (Kluza et al.
2012). On the other hand, a process can be used as a procedural
specification of the workflow, including the inference control.
The use of BR in BP design helps to simplify complex
decision modeling. It was also empirically proven that
the effect of linked rules improved business process
model understanding (better time efficiency in interpreting
business operations, less mental effort, improved accuracy
of understanding) (Wang et al. 2017). Although rules should
describe business knowledge in a formalized way that can
be further automated (Nalepa and Lige
¸
za 2005), there is no
common understanding how process and rule models should
be structured in order to be integrated (Hohwiller et al.
2011). There is also no formalized model that combines
processes with rules and ensures data types consistency, i.e.
data types used in rules should be available in processes
that use these rules. This is the main challenge we wish to
address in our work.
Information Systems Frontiers (2019) 21:1167–1185
Published online: 19 February 2018
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

As a solution, to the above mentioned challenge, we
propose a model for describing integration of BP with BR.
Our starting point are some existing representation methods
for processes and rules, specifically Business Process Model
and Notation (BPMN) (OMG 2011a) for BP models, and
eXtended Tabular Trees version 2 (XTT2) (Nalepa et al.
2011c) which is a formalized rule representation developed
as a part of the Semantic Knowledge Engineering (SKE)
approach (Nalepa 2011). We extend these models, and on
top of them provide a formalized general business logic
model that incorporates rules in the process models. The
model uses the abstract rule representation, so it can be
refined by adjusting it to the specific rule representation.
In the paper, we use XTT2 for this purpose, as it is a fully
formalized rule representation. In our case, the proposed
model deals with the integration of processes with rules
to provide a coherent formal description of the integrated
model.
Usually, the goal of formal model description is its formal
verification. In our case, the proposed model deals with the
integration of processes with rules to provide a coherent
formal description of the integrated model. Although we
do not consider the formal verification of such a model,
as we take advantage of the existing representations, the
formal verification of each part of the integrated model
(process or rules) is possible. Because of using the XTT2
rule representation, it is possible to use the existing methods
for formal verification of rules (Lige
¸
za 1999), especially
for formal verification of decision components, such as
inconsistency, completeness, subsumption or equivalence
(Nalepa et al. 2011a). In the case of process model itself,
one can use the existing verification methods (Wynn et al.
2009), specifically the methods that can take into account
the task logic (Szpyrka et al. 2011).
The paper is organized as follows. Section 2presents
an overview of related works concerning process model
formalization. Section 3provides a formal description of
a BPMN process model. It introduces the notation and its
formal representation. This formalized process model is
then integrated with rules, and this integration is specified
as the General Business Logic Model in Section 4.Inorder
to apply this model to a specific rule solution, the SKE-
specific Business Logic Model is presented in Section 5.As
an evaluation, a case example described using the proposed
model is presented in Section 6. The paper is concluded in
Section 7.
2 Related Works
There are several attempts to the formalization of Business
Process models. These formalizations differ with respect to
the goal with which the model semantics is specified.
2.1 Formalization of Business Process Models
Ouyang et al. (2006a,b) introduced a formal description of
BPMN process model for the purpose of their translation
to Business Process Execution Language (BPEL), in
order to execute process models. They also defined the
concept of well-structured components for the purpose
of the execution. Dijkman et al. (2007) defined the
formal semantics of BPMN process model in order to
use formal analysis. The main goal of their formalization
was to define the execution semantics to enable soundness
checking. In Dijkman and Gorp (2011), they formalized
execution semantics of BPMN through translation to Graph
Rewrite Rules. Such formalization can support simulation,
animation and execution of BPMN 2.0 models. It can help
in conformance testing of implementations of the workflow
engines that use the notation for modeling and executing
processes.
In 2002, Sivaraman and Kamath (2002)usedPetri
nets for modeling Business Processes. However, it was
before the BPMN notation was introduced. In fact, the
translation from BPMN to Petri nets is not straightforward.
Changizi et al. (2010) formalized BP model through
translation to channel-based coordination language Reo.
Such transformations allows for verification of models
with the help of verification and model checking tools
available for the Reo language, such as mCRL2 model
checker. Speck et al. (2011) formalized Event-driven
Process Chain (EPC) diagrams using Computational Tree
Logic (CTL). With CTL, it is possible to formulate rules
about different paths in processes and use that for checking
the existence of a specific element type in the process, for
unknown elements or elements with only partially known
properties. Wong and Gibbons (2008,2011) defined BPMN
model semantics in terms of the Z model for syntax and
Communicating Sequential Processes (CSP) for behavioral
semantics. This allows for checking the consistency of
models at different levels of abstraction as well as other
properties that must apply to the process, such as domain
specific properties, deadlock-freeness or proper completion.
Lam (2009,2012) formally defined the token-based
semantics of BPMN models in terms of Linear Tempo-
ral Logic (LTL). This allows for verification and reasoning
on BPMN models, especially for checking such proper-
ties as liveness or reachability. Lige
¸
za (2011) defined a
declarative model for well-defined BPMN diagrams, which
allows for specification of correct components and correct
dataflow, especially checking model consistency or termina-
tion condition. Smirnov et al. (2012) introduced simple for-
malization for defining action patterns in business process
model repositories. Action patterns capture different rela-
tions among actions often observed within process model
collections. The formalization used in Smirnov et al. (2012)
Inf Syst Front (2019) 21:1167–1185
1168
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

allowed the authors extract various types of action patterns
from industrial process model collections.
B˘
adic˘
aetal.(2003) presented the method for modeling
business processes using Role Activity Diagrams which
share many similarities with BPMN. They used the
formalization that exploits Finite State Process Algebra
(FSP) which is suitable for verification of these models
using Fluent Linear Temporal Logic (FLTL) (B˘
adic˘
aand
B˘
adic˘
a2011).
2.2 Decision Model and Notation and Business
Process Models
On the other hand, there is a new standard for modeling
decisions of organizations – Decision Model and Notation
(DMN) (OMG 2015). The DMN specification shows
examples how to link decisions in business process with
specific elements in the process model. However, it does
not specify the details of this relationship. Moreover, it
emphasizes the independence of the DMN of the business
process and BPMN. The handbook for process and decision
modeling (Debevoise et al. 2014) presents how to separate
decision logic to DMN during modeling, but it does not
specify the formal relationships between the models and
their integration issues.
Janssens et al. (2016) specified five integration scenarios
of decision and processes, which covers the continuum
from processes without decisions (scenario 0) to decisions
without processes (scenario 4). Our approach can be located
somewhere between scenario 1, in which local decisions
ensure separation of control flow and decision logic, and
scenario 2, where decisions are placed directly before
the business activities requiring their output. This paper
systematize the integration possibilities, but it does not
consider the data integration between models.
Batoulis et al. (2015b) proposed a method for extracting
decision logic from process models. They specified three
patterns for control-flow-based decision identification and
provide an algorithm for transforming such decision
logic to DMN model. This is suitable for refactoring
process models in order to separate decision logic from
process models. Bazhenova and Weske (2015) proposed
an approach for deriving decision models from process
models and execution logs. The approach consists of four
steps: decision points identification, decision logic finding,
constructing decision model and adapting process model.
Thus, it requires the event log of a process model. Another
approach which dynamically adapts the decision logic based
on historic and current process execution data in BPM
system during run-time was proposed in Batoulis et al.
(2015a). In this approach, the decisions are automatically
revealed and translated to DMN what improves process
executions regarding such issues as process duration or
costs. Catalkaya et al. (2013) proposed the method for
applying decision theory to process models and extend
the current standard with rule-based XOR-split gateway
(the so called r-gateway). In order to take a decision the
method utilize key performance indicators, such as cost of
performing an activity.
It is important to emphasize that DMN relation to BPMN
is described in the “Annex A: Relation to BPMN” of the
DMN specification (OMG 2015) only in the informative
way. Linking BPMN and DMN Models is described
informally. Thus, no constraints or requirements for data are
imposed.
The formalizations mentioned above were used either for
formal analysis of the model (checking selected properties)
or its execution. In the case of the DMN representation,
there are research directions providing the way of deriving
decision models from process models and describing the
possibility of execution of such models. However, in the
approach presented in this paper, we focus on designing
the integrated models, so the purpose of the model is to
formally describe the integration of the BP model with
rules and to provide the basis for the formal description of
other integration issues. It is partially based on the BPMN
formalization proposed by Ouyang et al. (2006a). Yet we
extend this formalization by incorporating rules into process
models, which is our original contribution.
3 Formal Description of BPMN Process Model
Let us define a BPMN 2.0 process model that describes
the most important artifacts of the BPMN notation.1As
it focuses also on several details that are key elements from
the rule perspective, the process model takes into account
flow objects (activities, events and gateways), sequence
flows between these flow objects, as well as the set of model
attributes.
Definition 1 ABPMN 2.0 process model is a tuple P=
(O,F,), where:
–Ois the set of flow objects, o1,o
2,o
3,...∈O,
–is the set of model attributes, λ1,λ
2,λ
3,...∈,
–F⊂O×O×2Fis the set of sequence flows,
where F⊂is a subset of attributes that are used in
sequence flows.
Moreover, the set of flow objects is divided into sets:
–Ais the set of activities such that A=T∪S,T∩S=
∅,whereTis the set of tasks and Sis the set of
1The model is limited to the most popular elements used in the private
process model diagrams of the BPMN 2.0 notation.
1169
Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

sub-processes, τ1,τ
2,τ
3,... ∈Tand s1,s
2,s
3,... ∈
S,
–Eis the set of events, e1,e
2,e
3,...∈E
–Gis the set of gateways, g1,g
2,g
3,...∈G
such that O=A∪E∪Gand A∩E=A∩G=E∩G=∅.
The set of all the possible BPMN 2.0 process models will
be denoted P,e.g.P1,P2,P3,... ∈P.
Definition 2 Atask interpretation is a pair:
τ=(type(τ ), τ)
where:
•type(τ ) determines the type of the task τ,type(τ ) ∈
{None,User,Manual,Send,Receive,Script,Service,
Business Rule}
•τ⊂is the set of the task attributes, τ=
{id,name,documentation,markers,resources,...,
implementation},2some attributes can take set values,
such as:
–markers ⊂{loop,parallelMI,sequentialMI,
adhoc,compensation},
some of the attributes may contain other attributes, such
as:
–ioSpecification ={dataInputs,dataOutputs}.
2The set of attributes is limited to the most popular ones, for other see
Section 10.2 Activities of the BPMN 2.0 Specification (OMG 2011a).
Moreover, Txwill denote the set of tasks of the same type
x:
Tx={τ∈T:type(τ ) =x}
For simplicity, the value of an attribute can be obtained
using a function, name of which matches the attribute name
attribute(τ ),e.g.id(τ1)denotes the value of the id attribute
for the task τ1.
The tasks of different type use the implementation
attribute to specify the implementation technology, e.g.
“##WebService” for the Web service technology or a URI
identifying any other technology or coordination protocol.
The purpose of the implementation technology is different
for different types of tasks, e.g.: in the case of Service
tasks (TService) it determines the service technology, in
the case of Send tasks (TSend) or Receive tasks (TReceive),
it specifies the technology that will be used to send or
receive messages respectively, and in the case of Business
Rule tasks (TBusiness Rule), it specifies the Business Rules
Engine technology. The ioSpecification attribute is used
for specifying the data inputs and outputs suitable for the
implementation technology. Some types of tasks can also
have several additional attributes (τ) specified.
Definition 3 Asub-process interpretation is a triple:
s=(Ps,type(s), s)
where:
–type(s) determines the type of the sub-process
s,type(s) ∈{Sub-process,Embedded,CallActivity,
Transaction,Event},
–Ps∈Pis a BPMN 2.0 process model nested in the
sub-process s,
–s⊂is the set of the sub-process attributes,
τ={id,name,documentation,markers,...,
triggeredByEvent},3such attributes are defined same
as for tasks (see Definition 2).
3The set of attributes is limited to the most popular ones, for other see
Section 10.2 Activities of the BPMN 2.0 Specification (OMG 2011a).
1170 Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

While activities represent parts of work that are
performed within a Business Process, events are state
changes occurring in the process environment that can
influence the process.
Definition 4 An event interpretation is a pair:
e=(type(e), trigger(e), e)
where:
–type(e) ∈{Start,Intermediate,End},
–trigger(e) determines the trigger of the event e,
trigger(e) ∈{Cancel,Compensation,Conditional,
Error,Escalation,Link,Message,Multiple,None,
ParallelMultiple,Signal,Terminate,Time r },
–e⊂is the set of the event attributes,
e={id,name,documentation,method,
boundary,attachedToRef ,cancelActivity},4
method(e) ∈{catch,throw}.
Moreover, Exwill denote the set of events with the same
trigger x:
Ex={e∈E:trigger(e) =x}
Exwill denote the set of events of the same type x:
Ex={e∈E:type(e) =x}
Different types of events have different event definition
attributes specified, e.g.:
–messageEventDefinition for e∈EMessage,
messageEventDefinition ={messageRef ,
operationRef },
4The set of attributes is limited to the most popular ones, for other see
Section 10.4 Events of the BPMN 2.0 Specification (OMG 2011a).
–timerEventDefinition for e∈ETimer,
timerEventDefinition ={timeCycle,timeDate,
timeDuration},
–conditionalEventDefinition for e∈EConditional,
conditionalEventDefinition ={condition},
It is also important to note that not every trigger(e) is
allowed for any type(e) of event – Table 1presents the
possible combinations.
In the case of this formalization, the condition attribute
for e∈EConditional is especially important. It defines an
expression stored in body attribute and expressed in the lan-
guage language: condition(e) ={body(e), language(e)}.
Gateway elements are used to control the flow of tokens
through sequence flows as they converge and diverge
within a process. Although, according to the BPMN 2.0
specification, a single gateway can have multiple input and
multiple output flows, this formalized model proposed is to
1171
Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Tab le 1 Possible combinations of trigger(e) and type(e)
type(e) Start Intermediate End
trigger(e) method(e) =catch method(e) =catch method(e) =throw method(e) =throw
Cancel 
Compensation  
Conditional 
Error  
Escalation  
Link 
Message  
Multiple  
None 
ParallelMultiple 
Signal  
Terminate 
Timer 
enforce a best practice of a gateway only performing one
of these functions. Thus, a gateway should have either one
input or one output flow and a gateway with multiple input
and output flows should be modeled with two sequential
gateways, the first of which converges and the second
diverges the sequence flows.
Definition 5 Agateway interpretation is a tuple:
g=(Fin
g,Fout
g,type(g), g)
where:
–Fin
gand Fout
gare sets of sequence flows (input
and output flows respectively), Fin
g,Fout
g⊂F,
Fin
g={(oi,o
j,
i,j )∈F:oj=g}and Fout
g=
{(oi,o
j,
i,j )∈F:oi=g},
–type(g) determines the type of the gateway g,type(g) ∈
{Parallel,Exclusive,Inclusive,Complex,Event-
based,ParallelEvent-based},
–g⊂is the set of the gateway attributes,
g={id,name,documentation,gatewayDirection},5
gatewayDirection(g) ∈{converging,diverging}.
Furthermore, the following notational elements will be
used:
–G+={g∈G:type(g) =Parallel},
–G×={g∈G:type(g) =Exclusive},
–G◦={g∈G:type(g) =Inclusive},
–G∗={g∈G:type(g) =Complex},
5The set of attributes is limited to the most popular ones, for other, see
Section 10.5 Gateways of the BPMN 2.0 Specification (OMG 2011a).
–G⊗={g∈G:type(g) =Event-based},
–G⊕={g∈G:type(g) =ParallelEvent-based}.
Some types of gateways can have several additional
attributes specified, such as:
–{instantiate,eventGatewayType}for g∈
G⊗∪G⊕,instantiate(g) ∈{true,false},
eventGatewayType(g) ∈{Parallel,Exclusive},
–{default}for g∈G×∪G◦∪G∗,default(g) ∈Fout ∪
{null}.
Sequence Flows are used for connecting flow objects
o∈Oin the process.
Definition 6 Asequence flow interpretation is a tuple:
fo1,o2=((o1,o
2), o1,o2)
1172 Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

where:
–(o1,o
2)∈O×Oand o1,o2are respectively source and
target elements,
–o1,o2⊂Fis the set of sequence flow
attributes, o1,o2={id,name,documentation,
default,conditional,condition},6condition =
{body,language}.
Two boolean attributes: conditional and default deter-
mine the conditional or default type of the flow. A condi-
tional flow has to specify the condition and a default flow
has no condition, i.e.
–conditional(f ) =true ⇒condition(f ) = null,
–default(f ) =true ⇒condition(f ) =null.
A subset of conditional sequence flows will be denoted
FConditional,i.e.FConditional ={f∈F:conditional(f ) =
true},
Acondition attribute defines an expression indicating
that the token will be passed down the sequence flow
only if the expression evaluates to true. An expression
body is basically specified using natural-language text.
However, it can be interpreted as a formal expression by
a process execution engine; in such case, BPMN provides
an additional language attribute that specifies a language in
which the logic of the expression is captured.
In the presented BPMN model, the evaluation of
the value can be obtained using a fuction eval(value),
e.g. for the condition attribute of the fsequence flow:
eval(condition(f )) ∈{true,false}.Ifcondition is not
explicitly defined for a particular sequence flow f, then it is
implicitly always evaluated to true, i.e.: condition(f ) =
null ⇒eval(condition(f )) ≡true.
6The set of attributes is limited to the most popular ones, for other, see
Section 10.5 Gateways of the BPMN 2.0 Specification (OMG 2011a).
In this section, we presented a formalized model of
BPMN business process. This model will be used in the
following section for defining a model that combines
business processes with business rules.
4 General Business Logic Model
In this section we define a General Business Logic Model,
which specifies business logic as the knowledge stored in
the form of processes integrated with rules. The model
follows the ideas from the BPMN formalization proposed
by Ouyang et al. (2006a). However, we extend the process
model by incorporating rules into process models. Such
integrated models are called business logic models. As the
model uses the abstract rule representation, it is general and
can be refined into a specific one by adjusting it to the
specific rule representation.
The model uses the process model presented in the
previous section and integrates it with rules.7As rules
constitute a part of a rule base, it is defined as follows.
Definition 7 ARule Base is a tuple K=(A,R,T), where:
–Ais the set of all attributes used in the rule base,
–Ris the set of all rules, r1,r
2,r
3,... ∈R, and a single
rule ricontains its conditional part denoted as cond(ri).8
–Tis the set of all decision components, t1,t
2,t
3,... ∈
T, which can be rule sets or more sophisticated
structures (rule sets represented as decision tables, trees,
etc.) that organize rules in the rule base (T⊂2R).
Moreover, it is assumed that each rule base specifies a
language(r)9in which the rules are specified and provides
additional methods that can be used to obtain pieces of
information from the rule base, such as eval(r )10 for
evaluating a conditional part of the rule, and infer(t)11 for
obtaining a result of inference on a specified rule set.
Definition 8 AGeneral Business Logic Model is a tuple
M=(P,K,map), where:
–Kis a rule base containing rules (as defined in
Definition 7),
7The proposed model focuses on selected details that are important
from the rule perspective.
8It isassumed that various rule bases can contain different kinds of rules
(see categories of rules presented in Wagner et al. 2005). Regardless
of the kind, in every rule it is possible to isolate their conditional part.
In some cases, a rule may consist only of a conditional part.
9language(r) denotes language(K).
10eval(r) denotes eval(cond(r )) and eval(r) ∈{true,false}.
11infer(r ) denotes infer({r})
1173
Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Fig. 1 Conditional sequence flow
–Pis a BPMN 2.0 process model (as defined in
Definition 1),
–map is a map function defined as follows:
map(x) =⎧
⎨
⎩
FConditional →Rfor x∈FConditional
EConditional →Rfor x∈EConditional
TBusinessRule →Tfor x∈TBusinessRule
In the following paragraphs, the mapping details for
the specific BPMN elements and more complex BPMN
constructs are presented.
Conditional Sequence Flow For a Conditional Sequence
Flow f∈FConditional (see Fig. 1) the following require-
ments have to be fullfiled in M:
– All BPMN conditional sequence flows in Phave the
condition in the form of a conditional part of a rule from
the Krule base assigned, formalized, i.e. the following
holds:
∀f∈FConditional ∃r∈R(map(f ) =r) ∧(body(f )=cond(r ))
∧(language(f ) =language(r)).
– All condition attributes Ar⊂Arequired by the rule r
should be available in the Pmodel, i.e.:
∀r∈R(∃f∈Fmap(f ) =r) ⇒(∀λ∈cond(r) λ∈F).
Conditional Event Conditional Event e∈EConditional
denotes that a particular condition specified by a rule
condition is fulfilled. For Conditional Event, the following
requirements have to be fullfiled in M:
– All BPMN conditional events in Phave the condition
in the form of a conditional part of a rule from the K
rule base assigned, i.e.:
∀e∈EConditional ∃r∈R(map(e) =r) ∧(body(e) =cond(r))
∧(language(e) =language(r)).
– All condition attributes Ar⊂Arequired by the rule r
should be available in the Pmodel, i.e.:
∀r∈R(∃e∈Emap(e) =r) ⇒(∀λ∈cond(r ) λ∈e).
A Conditional Event can be used in BPMN in several
structures in order to support different situations based on
the evaluation of the condition expression in the process
instance, such as:
Fig. 2 Conditional (start and intermediate) events
– Simple Start and Intermediate Conditional Event can be
used as conditional trigers providing the ability to triger
the flow of a token. The notation for conditional start
and intermediate events are presented in Fig. 2.
– Non-interruptive and Interruptive Boundary Condi-
tional Events attached to a Task or a Subprocess can
be used for interrupting a task or subprocess. The nota-
tion for conditional non-interruptive and interrputive
boundary events are presented in Fig. 3.
– Event Subprocess with Conditional Start Event can
be used for interrupting the process and initiating
a subprocess that is not a part of the regular
control flow starting from the conditional start event.
The notation for conditional non-interruptive and
interrputive boundary events are presented in Fig. 4.
Business Rule Task Business Rule (BR) Tasks allow for
specification of the task logic using rules and delegating
work to a Business Rules Engine in order to receive
calculated or inferred data. The notation for BR task is
presented in Fig. 5.
For the BPMN Business Rule tasks, the following
formulas have to be fullfiled in M:
– All BPMN BR tasks in Phave the decision component
from the Krule base assigned, i.e.:
∀τ∈TBusinessRule ∃t∈Tmap(τ ) =t.
– All the input attributes required by the Business
Rules Engine for a rule set specified by the decision
component should be available in the process model,
i.e.:
∀τ∈TBusinessRule
t∈T
map(τ ) =t
∀r∈t∀λ∈cond(r) λ∈dataInputs(τ ).
Fig. 3 Conditional (non-interruptive and interrputive) boundary events
1174 Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Fig. 4 Event subprocesses with conditional start event
– All the output attributes from the result of inference
on a specified rule set from the Business Rules Engine
should be available as the output of BR task in the
process, i.e.:
∀τ∈TBusinessRule
t∈T
map(τ ) =t
∀r∈t∀λ∈infer(r) λ∈dataOutputs(τ )
Diverging (Exclusive, Inclusive/Multi-choice and Complex)
Gateways Gateways provide mechanisms for diverging a
branch into two or more branches, and passing token from
the incoming branch to one or more outgoing branches
according to the type of a gateway.
For further formulae, the following sets are defined:
Gcond
div ={g∈G×∪G◦∪G∗:gatewayDirection(g)=diverging},
Fout,cond
g,div ={f∈Fout
g:g∈Gcond
div ∧default(f ) = true},
Fout,cond
g,default ={f∈Fout
g:g∈Gcond
div ∧default(f ) =true}.
In the case of exclusive (G×), inclusive (G◦)andcomplex
(G∗) diverging gateways (see Fig. 6), there is a need for the
model Mto satisfy the following requirements:
– All BPMN sequence flows (apart from the default ones)
outgoing from a diverging gateway have the condition
in the form of a conditional part of a rule from the K
rule base assigned, i.e.:
∀f∈Fout,cond
g,div
∃r∈R(map(f ) =r) ∧(body(f ) =cond(r))
∧(language(f ) =language(r)).
– In the case of exclusive, inclusive and complex
diverging gateways, they can have maximum one
outgoing default sequence flow, i.e.:
∀g∈Gcond
div |Fout,cond
g,default|≤1.
Fig. 5 Business rule task (a standard and a call activity task)
– In the case of exclusive gateways, the evaluated
conditions have to be exclusive, i.e.:
∀f1,f2∈Fout
g,div ∀g∈G×(∃r1,r2∈Rmap(f1)=r1∧map(f2)
=r2)⇒(eval(r1)= eval(r2)).
Converging Complex Gateway In the case of converging
exclusive, inclusive and parallel gateways, their semantics
is defined by the BPMN 2.0 specification and they do not
require any rule-based description. However, a Converging
Complex Gateway (see Fig. 7) requires an additional
activationCondition expression which describes the precise
behavior (defines the rule of passing tokens).
Thus, for BPMN Converging Complex Gateways the
following requirements have to be fullfiled in M:
– All BPMN Converging Complex Gateways in Pspecify
the rule of passing tokens, i.e.:
∀g∈G∗∃r∈R(map(g) =r) ∧(body(g) =cond(r))
∧(language(g) =language(r)),
where activationCondition(g) =
{body(g), language(g)}.
– All condition attributes Ar⊂Arequired by the rule r
should be available in the process model, i.e.:
∀r∈R(∃g∈G∗map(g) =r) ⇒(∀λ∈cond(r ) λ∈g).
Gateway Preceded by a BR Task A special case of the two
aboved examples occurs when a gateway is preceded by the
BR task (Fig. 8). In the such case, there is a need for the
model Mto satisfy the requirements specified for Business
Rule Tasks and for Gateways, as well as the following
additional requirement:
– All BPMN sequence flows (apart from the default
sequence flows) outgoing from a diverging gateway
preceded by the BR task have the conditions based on
the output attributes of the BR task, i.e.:
∀τ∈TBusinessRule
t∈T
map(τ ) =t
∀g∈Gcond
div (τ,g,λ
τg)∈F
⇒∀f∈Fout
g∀λ∈body(f ) λ∈infer(t ).
Gateway Preceded by a Subprocess Another special case of
using a gateway is a gateway preceded by a subprocess in
which a decision is made (see Fig. 9). In such the case,
there is a need for the model Mto satisfy the requirements
specified for Diverging Gateways, as well as the following
additional requirements:
– All BPMN sequence flows (apart from the default
sequence flows) outgoing from a diverging gateway
1175
Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Fig. 6 Exclusive, inclusive
(multi-choice) and complex
diverging gateways
preceded by a subprocess have the conditions based on
the attributes set by the preceded subprocess:
∀s∈S∀g∈Gcond
div (s,g,λ
s,g)∈F
⇒∀f∈Fout
g∀λ∈body(f ) λ∈dataOutputs(s).
– The number of sequence flows outgoing from a
diverging gateway should be greater than or equal to
the number of Message or None end events in the
subprocess, i.e.:
Let: Es
End ={e∈Os:e∈ENone
End ∨e∈EMessage
End },
where Ps=(Os,Fs,
s).
∀s∈S∀g∈Gcond
div ((s,g,λ
s,g)∈F)⇒(|Fout
g|>=
|Es
End|).
Event-Based Gateway The use of Event-based (Exclusive)
Gateway extends the use of Conditional Events (see
Fig. 10). Thus, in this case, there is a need for the model M
to satisfy the requirements specified for Conditional Events,
as well as the following additional requirements:
– All conditions in the Conditional Events that occur
after the Event-based (Exclusive) Gateway should be
exclusive,12 i.e.:
∀e1,e
1∈EConditional
r1,r
1∈R
map(e1)=r1
map(e2)=r2
∀g∈G⊗((g, e1,λ
g,e1),
(g, e2,λ
g,e2)∈F)
⇒¬(eval(r1)∧eval(r2)).
Other BPMN Constructs Although other BPMN elements or
constructs are not directly associated with rules from the
rule base, they can be described by rules. However, such
a representation of rules is not formally defined in the model
presented here.
In this section, a simple model of the integration of
the BP model with rules was proposed. Moreover, this
formal description provides the basis for refinement of
12In fact, the exclusive relation here applies only to evaluation to true
values. Thus, both conditions can be not fullfiled at the same time.
the model for specific rule representation, e.g. the XTT2
representation from the SKE approach, which will be
presented in the following sections.
5 SKE-Specific Business Logic Model
5.1 Semantic Knowledge Engineering Rules
Semantic Knowledge Engineering (SKE) (Nalepa 2011)is
an approach that provides a coherent formal framework for
eXtended Tabular Trees version 2 (XTT2) (Nalepa et al.
2011b), which is a rule-based knowledge representation
language. The formalization of the XTT2 method based on
the ALSV(FD) logic was presented by Nalepa and Lige
¸
za in
Nalepa (2010b,2011). The goal of this section is to introduce
the SKE-specific Business Logic Model, based on the General
Business Logic Model presented in the previous section.
In order to formally define an XTT2 rule, the formal
definitions for Attributive Logic with Set Values over
Finite Domains (ALSV(FD)) are needed. ALSV(FD) is
an extended version of Set Attributive Logic (SAL) (Lige
¸
za
2006) oriented toward Finite Domains. It was discussed in
(Nalepa 2010b). The expressive power of the AL SV(FD)
formalism is increased through the introduction of new
relational symbols. For simplicity, there are no objects
specified in an explicit way. In ALSV (FD), Adenotes
the set of all attributes used to describe the system. Each
attribute ai∈A,i=1...n has a set of admissible values
that it takes (a domain) denoted as Di. Any domain is
assumed to be a finite set.
Fig. 7 Converging complex gateway
1176 Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Fig. 8 Gateway after BR task
Definition 9 An ALSV(FD) triple ε(also called a legal
atomic formula in terms of the ALSV( FD) logic) is a triple
of the form:
ε=(ai,,x
i)
where
–aiis an attribute,
–xiis the value of the attribute (it can be a single element
of the domain or a subset of the domain),
–isan operator from the set of operators for attributes,13
such that ∈{=,=,:=,∈,/∈,⊆,⊇,∼,∼}.
The AL SV( FD) triples constitute the basic components
of the XTT2 rules. A set consisting of the ALSV( FD)
triples will be denoted by E,i.e.ε1,ε
2,...∈E.
Definition 10 An XTT2 rule ri(here called also rule) is
a triple of the form:
ri=(condi,dec
i)
where
–condi⊆Eis a conditional part of a rule consisting of
legal atomic formulae in terms of ALSV(FD ),
–deci⊆Eis a decision part of a rule consisting of legal
atomic formulae in terms of AL SV( FD).
The set of all rules will be denoted as R,andr1,r
2,...∈
R. A rule schema for a given rule ri(called also rule
template) is a pair schema(ri)=(Acond
i,A
dec
i),where
Acond
iand Adec
iare sets of all the attributes occurring in the
conditional and decision part of the rule respectively.
From a logical point of view, the order of the ALSV(F D)
atomic formulae in both the conditional and decision parts
of the rule is unimportant. Having the structure of a single
rule defined, the structure of the XTT2 rule base can be
defined. The rule base is composed of tables grouping
rules having the same lists of attributes (rule schemas).
Rule schemas are used to identify rules working in the
same situation (operational context). Such a set of rules can
13The assignment operator (:=) allows for assigning a new value to an
attribute.
form a decision component in the form of a decision table.
A common schema can also be considered as a table header.
Definition 11 An XTT2 decision component t(also called
an XTT2 table) is a sequence of rules having the same rule
schema:
t=(r1,r
2,...,r
n)
The set of decision components is denoted as T,
t1,t
2,... ∈T. An XTT2 table schema (also called a schema
of the component or table header) is denoted as schema(t).
1177
Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Fig. 9 Gateway preceded by a
subprocess
5.2 Integrated Model
The SKE-specific Business Logic Model is a special case
of the General Business Logic Model that describes the
integration of the BPMN process models with the SKE
rules.
Definition 12 SKE-specific Business Logic Model is a
tuple: MSKE =(P,KSKE,map), where:
•KSKE =(ASKE,RSK E,TSKE )=(A,R,T
X)is an
SKE-specific rule base, where:
–TXis a set of the XTT2 decision components,
–Ris a set of the XT T2 rules, such as:
R={ri∈t:t∈TX},
∀ri∈Rschema(ri)=schema(t ),
and the conditional cond(ri)part of a rule is
defined as follows:
cond(ri)=Econd
i,
where ri=(Econd
i,E
dec
i,ACT
i),
–Ais a set of the attributes used in the XTT2
rule base, i.e.:14
A={ai:∃
ri∈Rai∈Acond
i∨ai∈Adec
i}.
•Pis a BPMN 2.0 process model,
•map is a mapping function between the elements of the
Pprocess model and the elements of the KSKE rule
base.
The KSKE rule base specifies the value of language,
such as: ∀ri∈Rlanguage(r) =“XTT2”. Moreover, the
infer(t ) method is defined as follows: infer(t ) =Adec
t.This
stems from the fact that in the SKE-specific Business Logic
Model, every decision component t∈TXis an XTT2
14Note that every rule in the XTT2 representation belongs to a
particular decision table. Thus, there is no rule which would not be an
element of a decision table. However, it is possible that a decision table
can consist of a single rule.
decision table. Thus, the result of the inference is the set of
decision attributes of this decision table.15
In the following paragraphs, the integration details are
specified.16
Conditional Sequence Flow For the Conditional Sequence
Flows f∈FConditional the following hold:
– All BPMN conditional sequence flows in Phave the
condition in the form of a conditional part of a rule from
the KSKE rule base assigned, formalized, the following
holds:
∀f∈FConditional ∃ri∈R(map(f ) =ri)∧(body(f ) =Econd
i)
∧(language(f ) =“XTT2”).
– Values of the condition attributes required by the rule
are mapped to the values of corresponding attributes in
the rule base:
∀f∈FConditional
ri∈R
map(f ) =ri
∀λ∈body(f ) ∃ai∈Econd
iλ(f ) ∈Di∧λ(f ) =ai.
In the case of the data associated to the process model,
we do not precise the data type (dynamic typing). However,
our model implies the requirement of similar data type by
checking if the value belongs to the domain of the attribute
specified in rules.
Conditional Event For the Conditional Events the following
hold:
– All BPMN conditional events in Phave the condition in
the form of a conditional part of a rule from the KSKE
rule base assigned, i.e.:
∀e∈EConditional ∃ri∈R(map(e) =ri)∧(body(e)=Econd
i)
∧(language(e) =“XTT2”).
15More precisely: attributes and their values that are set by a particular
rule. An XT T2 decision table is a first hit table (OMG 2011b), so it
returns the output of a single rule (the first hit).
16If for a particular element, there are no additional requirements or
conditions to specify, the formulae from General Business Logic can
be used.
1178 Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Fig. 10 Even-based exclusive
gateways (non-instantiating and
instantiating)
– Values of the condition attributes required by the rule
are mapped to the values of corresponding attributes in
the rule base:
∀e∈EConditional
ri∈R
map(e) =ri
∀λ∈body(e) ∃ai∈Econd
iλ(e) ∈Di∧λ(e) =ai.
Business Rule Task For the BPMN Business Rule tasks, the
following formulas have to be fullfiled:
– All BPMN BR tasks in Phave the decision component
from the KSKE rule base assigned:
∀τ∈TBusinessRule ∃t∈TXmap(τ ) =t.
– All the input attributes required by the HEART rule
engine17 for a rule set specified by the decision
component should be available in the process model,
i.e.:
∀τ∈TBusinessRule
t∈TX
map(τ ) =t
∀ai∈Acond
t∃λ∈dataInputs(τ ) λ(τ ) ∈Di∧λ(τ ) =ai.
– All the output attributes from the result of inference on
a specified rule set from the HEART rule engine should
be available as the output of BR task in the process, i.e.:
∀τ∈TBusinessRule
t∈TX
map(τ ) =t
∀λ∈dataOutputs(τ) ∃ai∈Adec
tλ(τ ) ∈Di∧λ(τ ) =ai.
Diverging (Exclusive, Inclusive/Multi-choice and Complex)
Gateways For the Diverging (Exclusive, Inclusive/Multi-
choice and Complex) Gateways the following hold:
– All BPMN sequence flows (apart from the default ones)
outgoing from a diverging gateway have the condition
17HEART is an inference engine that is used in the SKE approach. For
more information see Nalepa (2010a).
in the form of a conditional part of a rule from the KSKE
rule base assigned, i.e.:
∀f∈Fout,cond
g,div
∃r∈R(map(f ) =ri)∧(body(f ) =Econd
i)
∧(language(f ) =“XTT2”).
– In the case of exclusive gateways, the evaluated
conditions have to be exclusive, i.e.:
∀f1,f2∈Fout
g,div ∀g∈G×(∃r1,r2∈Rmap(f1)=r1∧map(f2)=r2)
⇒(eval(r1)= eval(r2)).
Gateway Preceded by a BR Task For the Gateways preceded
by a BR task the following hold:
– All BPMN sequence flows (apart from the default
sequence flows) outgoing from a diverging gateway
preceded by the BR task have the conditions based on
the output attributes of the BR task, i.e.:
∀τ∈TBusinessRule
t∈T
map(τ ) =t
∀g∈Gcond
div (τ,g,λ
τg)∈F
⇒∀f∈Fout
g∀λ∈body(f ) ∃ai∈Adec
tλ(τ ) ∈Di∧λ(τ ) =ai.
The whole specification of the BP Model Integrated with
the XTT2 Rules with constraints defining the connections
between process elements and rules was presented in the
PhD thesis of the first author (Kluza 2015). This simple
notation will be used in the following section for description
of the case study example.
6 Case Example Described Using the Model
In order to evaluate the proposed model, we used selected
use case examples which show its feasibility and efficiency.
The described models are executable18 in the provided
runtime environment (Nalepa et al. 2013). Full discussion
of all the evaluated models was provided in Kluza (2015).
18The models consist of the BPMN 2.0 elements from the Common
Executable Conformance Sub-Class (OMG 2011a).
1179
Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Tab le 2 The names of the tasks in the example
Index Name of the task (task labels)
BR1 Determine client class
BR2 Calculate base charge
BR3 Calculate driver discount base
BR4 Calculate car discount base
BR5 Calculate other discount base
BR6 Calculate driver discount
BR7 Calculate car discount
BR8 Calculate other discount
BR9 Calculate payment
U1 Enter car capacity information
U2 Enter Bonus Malus information
U3 Enter Premium information
U4 Display payment result
To demonstrate the application our model, and its
benefits, in this section we discuss one selected case. In
our opinion it is an illustrative example of a system that
benefits for the integration of process and rules. On a high
level, the whole decision making process can be modeled
using the the BPMN process model. The lower level logic is
then described with specific business rules using the XTT2
notation.
The Polish Liability Insurance (PLI) case study, was
developed as one of the benchmark cases for the SKE
approach for rule-based systems (Nalepa 2011). This is
a case, in which the price for the liability insurance for
protecting against third party insurance claims is to be
calculated. The price is calculated based on various reasons,
which can be obtained from the insurance domain expert.
The main factors in calculating the liability insurance
premium are data about the vehicle: the car engine capacity,
the car age, seats, and a technical examination. Additionally,
the impact on the insurance price have the driver’s age,
the period of holding the license, the number of accidents
in the last year, and the previous class of insurance. In
the calculation, the insurance premium can be increased or
decreased because of number of payment installments, other
insurances, continuity of insurance or the number of cars
insured.
An excerpt of the most relevant formulas of the MPLI
SKE
model is as follows (the abbreviations for the names are
presented in Table 2):
MPLI
SKE =(PPLI,KPLI
SKE,mapPLI), where:
PPLI =(O,F,),
O=A∪E∪G,
A=TBusiness Rule ∪TUser,
TBusiness Rule ={τBR1,τ
BR2,τ
BR3,τ
BR4,τ
BR5,τBR6,
τBR7,τ
BR8,τ
BR9},
TUser ={τU1,τU2,τU3,τU4},
E={eStart,e
End},
|G|=4.
The process model, presented in Fig. 11, consists of: 4
User tasks, 9 Business Rule tasks, start and end events, as
well as 4 parallel gateways. This model can be integrated
with rules from the KPLI
SKE rule base. In such a case, the
Business Rule tasks have to be associated with the decision
tables from the TXset containing the proper XTT2 rules.
Below, the specification of decision tables is presented
(it provides decision table schemas which have to be
complemented with XT T2 rules).
KPLI
SKE =(A,R,T
X), where:
TX={tBR1,t
BR2,t
BR3,t
BR4,t
BR5,t
BR6,t
BR7,t
BR8,t
BR9},
schema(tBR1)=({acci dentN o, client Class },
{client Class }),
schema(tBR2)=({car Capacity},{bas eCharge}),
schema(tBR3)=({clientClass},{driverDiscount Base}),
schema(tBR4)=({car Age},{carDiscountBase}),
schema(tBR5)=({ins tall mentN o, insur anceCont,
insuranceCarsNo},{otherDiscountB ase}),
schema(tBR6)=({d river Age, dri verLicenceAge,
driverDiscountBase},{driverDiscount}),
schema(tBR7)=({sea tsN o, technical , antiq ueCar,
carDiscountBase},{car Discount}),
schema(tBR8)=({insuranceH istory,
other Insur ance, otherD iscountB ase},{otherDiscount}),
schema(tBR9)=({baseCharge, driverDiscount,
carD iscount, ot herDis count },{payment}).
Determine
client class
Calculate
base charge
Calculate
driver discount
base
Calculate
car discount
base
Calculate
other discount
base
Calculate
payment
Enter car
capacity
Enter
Bonus Malus
information
Enter Premium
information
Display
payment result
Calculate
driver discount
Calculate
car discount
Calculate
other discount
Fig. 11 The BPMN model for the PLI case study
1180 Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Fig. 12 The BPMN model for the PLI case study with forms and rules
mapPLI ={(τBR1,t
BR1), (τBR2,t
BR2), (τBR3,t
BR3),
(τBR4,t
BR4), (τBR5,t
BR5),(τBR6,t
BR6),(τBR7,t
BR7),
(τBR8,t
BR8),(τBR9,t
BR9)}.
The SKE-specific Business Logic Model for the PLI case
study, is presented in Fig. 12. One can observe that the BR
tasks in the process are connected with decision tables (for
clarity in Fig. 12 only decision table schemas are presented,
e.g. the “Calculate other discount base” Business Rule task
in the process model is connected with the decision table
schema: schema(tBR5).
The decision table filled in with suitable rules is
presented in Table 3). All decision tables with rules with the
corresponding executable HMR representation can be found
in the PhD thesis of the first author (Kluza 2015).
Tab le 3 “Calculate other
discount base” XTT2 decision
table
(?) installmentNo (?) insuranceCont (?) insuranceCarsNo (−>) otherDiscountBase
111 −10
101 0
11>=1−20
10>=1−10
211 0
201 10
21>=1−10
20>=10
1181
Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Fig. 13 The design and
verification process of the rule
model
In the model, this decision table is represented as follows:
tBR5=(r1,r
2,...,r
8)
r1=({(installmentNo,=,1), (i nsura nceCont , =,1),
(ins uranc eCar sN o, =,1)},
{(otherDiscountBase,:=,−10)}),
r2=({(installmentNo,=,1), (i nsura nceCont , =,0),
(ins uranc eCar sN o, =,1)},
{(otherDiscountBase,:=,0)}),
...
r8=({(installmentNo,=,2), (i nsura nceCont , =,0),
(ins uranc eCar sN o, >=,1)},{(otherDiscountBase,:=,0)}).
The objective of this discussion was the demonstration
how the proposed approach can support the business
analysts in designing process models integrated with rules.
In our work we assume that there is a general formalized
model of business logic. It based on the widely accepted
BPMN notation, and it incorporates rule models that
specify low level logic. We use the XTT2 rules, which are
formalized, but also provide a visual notation for decision
tables. Therefore the main benefits of our proposal include:
a) a single coherent formalization of the complete model
composed of processes and rules,
b) support for a fully visual design, as our rules in decision
tables can be designed using tools for SKE method,
finally
c) the XTT2 rules can be verified in the dedicated
environment (Nalepa et al. 2011a) that uses the HalVA
rule analysis framework for verification.
Using the XTT2 approach, the logical verification of
decision tables (including completeness, determinism,
redundancy, subsumption or equivalence checks) is possible
(Nalepa et al. 2011a). However, the verification issues
are out of scope for this paper. The visual design and
verification of the XTT2 model is shown in Fig. 13,using
the HQed editor for XTT2.
In order to show the feasibility and efficiency of the
proposed approach, we have selected the non trivial use
case examples that describe a business process and provide
sufficient data for formulating rules. As the part of the
research project,19 9 benchmark cases were selected (see
Table 4). Some of them are well-known benchmark case
studies, such as: the Polish Liability Insurance case study –
PLI (developed as a benchmark case for the SKE approach
for rule-based systems (Nalepa 2011)), EUrent Company –
EUrent (provided as a part of SBVR specification (OMG
2006)), and the UServ Financial Services case – UServ
(a benchmark case study from Business Rules Forum20).
The main goal of the evaluation was to demonstrate that the
proposed approach can support the design of process models
integrated with rules.
The presented approach was also used in the Pros-
ecco (Processes Semantics Collaboration for Companies)
project21 finding industrial application. The project aimed
at addressing the needs and constraints of small and
medium enterprizes (SME) by providing methods that
would improve BPM systems by simplification of the sys-
tem design and configuration, targeting the management
quality and competitiveness improvement. In the project a
set of use cases was acquired form the involved SMEs.
These cases were composed of the dominating process part,
but were augmented with rules specifying low level deci-
sion logic. We user our integrated model to design these
19See: http://geist.agh.edu.pl/pub:projects:hibuproburul:start.
20See: http://www.businessrulesforum.com.
21See: http://prosecco.agh.edu.pl.
1182 Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Tab le 4 Comparison of the selected cases
Case name |A||TUser||TBR ||G||R|
Upsell 5 2 3 0 15
Hello 7 3 3 2 8
Health 8 2 3 2 8
Thermostat 7 2 4 4 18
CashPoint 12 3 5 4 11
Cardio 15 2 7 4 18
EURent 26 6 7 4 31
sPLI 22 4 9 4 61
UServ 42 6 19 17 84
heterogeneous cases. Furthermore, the runtime environment
we provided was able to run these integrated models. In this
case the BP runtime engine (Activity) delegated the execu-
tion of the rule components to our dedicated embedded rule
engine (HeaRTDroid).
7 Conclusions
The main contribution of this paper is a new model for
integration of Business Processes with Business Rules.
This model is based on existing representation methods
for processes (the BPMN notation) and rules (the XTT2
representation). The model is fully formalized. It uses
and extends existing formalizations of BPMN, as well as
our previous formalization of XTT2 rules. Furthermore,
the model supports the business analysts in the design of
process models integrated with rules.
In the paper we provided motivation for our work,
as well as positioned it the area of related works. We
presented demonstration of the application of the model
on a selected use case. The evaluation demonstrated that
the presented model provides adequate formal means for
describing a process model integrated with rules. In our
opinion important benefits of our proposal include: a
uniform formalization of processes and rules, support for a
visual design of integrated model, as well as opportunities
for their formal verification. Moreover, from rule-based
systems point of view, such a model can be treated as a
structured rule base that provides explicit inference flow
determined by the process control flow.
The presented model can be used for a clear logical
description of a process model, especially for specification
of integration issues and ensuring data types consistency. It
was used in specification of the algorithm for generation of
the integrated models from the ARD diagrams (Kluza et al.
2015). In fact, it constitutes the base for our method for
generation and design of Business Processes with Business
Rules presented in Kluza and Nalepa (2017). As in the
provided model, the method uses the integrated model of
the existing representations for processes and rules, such
as the BPMN notation for process models, and the XTT2
representation for rules.
Moreover, the presented XTT2 rules can be formally
verified using the dedicated rule analysis framework
(Nalepa et al. 2011a). In the case of the process model, it is
possible to use some of the existing verification methods for
processes.
The model can also be used as a specification of
constraints for execution purposes. As the BPMN models
are executable in process engines and rules in the XTT2
representation can be executed in the HEART rule engine,
such integrated models can be executed in the hybrid
runtime environment (Nalepa et al. 2013).
As in the DMN specification linking BPMN and
DMN models is described informally, our future works
will be focused on adjusting our approach to support
the DMN notation. One of the directions is to extend
our model to support DMN decision tables and provide
rules interoperability between these methods (Kaczor
2015). Thus, it will be possible to take advantage of
the formal verification issues available in our approach.
Another research direction concerns the advantages of the
transforming our method of generation models (Kluza and
Nalepa 2017) which is based on the model described in this
paper, in order to support DMN. Especially, this will focus
on transforming our representation to DMN (similarly to the
transformation of PDM (van der Aa et al. 2016)).
Finally, our rule-based representation has several impor-
tant extension which (to the best of our knowledge) are not
available for DMN. The most important regards uncertainty
handling on the rule level. In our future work we plan to
explore the possible introduction of uncertainty handling to
the integrated decision model.
Acknowledgements The research presented in this paper is partially
based on the PhD thesis (Kluza 2015) of the first author and is sup-
ported by the HiBuProBuRul Project funded from NCN (National Sci-
ence Centre) resources for science (no. DEC-2011/03/N/ST6/00909).
Open Access This article is distributed under the terms of the
Creative Commons Attribution 4.0 International License (http://
creativecommons.org/licenses/by/4.0/), which permits unrestricted
use, distribution, and reproduction in any medium, provided you give
appropriate credit to the original author(s) and the source, provide a
link to the Creative Commons license, and indicate if changes were
made.
References
B˘
adic˘
a, A., & B˘
adic˘
a, C. (2011). Formal verification of business
processes as role activity diagrams. In 2011 Federated Conference
on computer science and information systems (FedCSIS) (pp. 277-
280): IEEE.
1183
Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

B˘
adic˘
a, C., B˘
adic˘
a, A., Litoiu, V. (2003). Role activity diagrams as
finite state processes. In Proceedings of the second international
conference on parallel and distributed computing ISPDC’03,
Ljubljana, Slovenia, October 13–14, 2003 (pp. 15–22).
Batoulis, K., Baumgrass, A., Herzberg, N., Weske, M. (2015a).
Enabling dynamic decision making in business processes with
DMN. In International conference on business process manage-
ment (pp. 418–431): Springer.
Batoulis, K., Meyer, A., Bazhenova, E., Decker, G., Weske,
M. (2015b). Extracting decision logic from process models.
In International conference on advanced information systems
engineering (pp. 349–366): Springer.
Bazhenova, E., & Weske, M. (2015). Deriving decision models from
process models by enhanced decision mining. In International
conference on business process management (pp. 444–457):
Springer.
Catalkaya, S., Knuplesch, D., Chiao, C., Reichert, M. (2013). Enrich-
ing business process models with decision rules. In Interna-
tional conference on business process management (pp. 198–211):
Springer.
Changizi, B., Kokash, N., Arbab, F. (2010). A unified toolset for
business process model formalization. In Proceeding of the 7th
international workshop on formal engineering approaches to
software components and architectures, satellite event of ETAPS,
held on 27th March 2010, Paphos, Cyprus (p. 10).
Charfi, A., & Mezini, M. (2004). Hybrid web service composition:
business processes meet business rules. In Proceedings of the 2nd
international conference on service-oriented computing, ICSOC
’04 (pp. 30–38). New York: ACM.
Debevoise, T., Taylor, J., Sinur, J., Geneva, R. (2014). The MicroGuide
to process and decision modeling in BPMN/DMN: building more
effective processes by integrating process modeling with decision
modeling. CreateSpace Independent Publishing Platform.
Dijkman, R.M., & Gorp, P.V. (2011). Bpmn 2.0 execution semantics
formalized as graph rewrite rules. In Mendling, J., Weidlich,
M.,Weske,M.(Eds.)Proceedings from the business process
modeling notation—second international workshop, BPMN 2010,
Potsdam, Germany, October 13–14, 2010. Lecture notes in
business information processing, (Vol. 67 pp. 16–30): Springer.
Dijkman, R.M., Dumas, M., Ouyang, C. (2007). Formal semantics and
automated analysis of BPMN process models. preprint 7115. Tech.
rep. Queensland University of Technology, Brisbane, Australia.
Dumas, M., La Rosa, M., Mendling, J., Reijers, H.A. (2013).
Fundamentals of business process management. Berlin: Springer.
Hohwiller, J., Schlegel, D., Grieser, G., Hoekstra, Y. (2011).
Integration of BPM and BRM. In Dijkman, R., Hofstetter,
J., Koehler, J. (Eds.) Business process model and notation,
Lecture notes in business information processing,(Vol.95
pp. 136–141). Berlin: Springer. https://doi.org/10.1007/978-3-
642-25160-3 12.
Janssens, L., Bazhenova, E., De Smedt, J., Vanthienen, J., Denecker,
M. (2016). Consistent integration of decision (DMN) and process
(BPMN) models. In Proceedings of the CAiSE’16 forum, at the
28th international conference on advanced information systems
engineering (CAiSE 2016), Ljubljana, Slovenia, June 13–17, 2016
(pp. 121–128).
Kaczor, K. (2015). Practical approach to interoperability in production
rule bases with SUBITO. In Rutkowski, L. et al. (Eds.) Artificial
intelligence and soft computing: 14th international conference,
ICAISC 2015, Lecture notes in artificial intelligence. Zakopane:
Springer. Accepted.
Kluza, K. (2015). Methods for modeling and integration of business
processes with rules. PhD thesis, AGH University of Science and
Technology, Supervisor: Grzegorz J. Nalepa.
Kluza, K., & Nalepa, G.J. (2017). A method for generation and
design of business processes with business rules. Information and
Software Technology,91, 123–141.
Kluza, K., Kaczor, K., Nalepa, G.J. (2012). Enriching business
processes with rules using the Oryx BPMN editor. In Rutkowski,
L. et al. (Eds.) Artificial intelligence and soft computing: 11th
international conference, ICAISC 2012: Zakopane, Poland, April
29–May 3, 2012, Lecture notes in artificial intelligence, (Vol. 7268
pp. 573–581): Springer. http://www.springerlink.com/content/
u654r0m56882np77/.
Kluza, K., Kaczor, K., Nalepa, G.J. (2015). Integration of business
processes with visual decision modeling. Presentation of the hades
toolchain. In Fournier, F., & Mendling, J. (Eds.) Business process
management workshops. BPM 2014 international workshops,
Eindhoven, The Netherlands, September 7–8, 2014, Revised
Papers, Lecture notes in business information processing,
(Vol. 202 pp. 504–515): Springer International Publishing. https
://doi.org/10.1007/978-3-319-15895-2 43.
Knolmayer, G., Endl, R., Pfahrer, M. (2000). Modeling processes and
workflows by business rules. In Business process management,
models, techniques, and empirical studies (pp. 16–29). London:
Springer.
Lam, V.S.W. (2009). Equivalences of BPMN processes. Service
Oriented Computing and Applications,3(3), 189–204.
Lam, V.S.W. (2012). Foundation for equivalences of BPMN models.
Theoretical and Applied Informatics,24(1), 33–66.
Lige
¸
za, A. (1999). Intelligent data and knowledge analysis and veri-
fication; towards a taxonomy of specific problems. In Vermesan,
A., & Coenen, F. (Eds.) Validation and verification of knowl-
edge based systems (pp. 313–325): Springer. https://doi.org/10.
1007/978-1-4757-6916-6 21.
Lige
¸
za, A. (2006). Logical foundations for rule-based systems. Berlin:
Springer.
Lige
¸
za, A. (2011). BPMN – a logical model and property analysis.
Decision Making in Manufacturing and Services,5(1-2), 57–67.
Lindsay, A., Dawns, D., Lunn, K. (2003). Business processes
– attempts to find a definition. Information and Software
Technology,45(15), 1015–1019.
Nalepa, G.J. (2010a). Architecture of the HeaRT hybrid rule
engine. In Rutkowski, L. et al. (Eds.) Artificial intelligence and
soft computing: 10th international conference, ICAISC 2010:
Zakopane, Poland, June 13–17, 2010, Pt. II, Lecture notes in
artificial intelligence, (Vol. 6114 pp. 598–605): Springer.
Nalepa, G.J. (2010b). HeKatE methodology, hybrid engineering of
intelligent systems. International Journal of Applied Mathematics
and Computer Science,20(1), 35–53.
Nalepa, G.J. (2011). Semantic knowledge engineering a rule-based
approach.Krak
´
ow: Wydawnictwa AGH.
Nalepa, G.J., & Lige
¸
za, A. (2005). Software engineering: evolution
and emerging technologies, frontiers in artificial intelligence
and applications. In Conceptual modelling and automated
implementation of rule-based systems, (Vol. 130 pp. 330–340).
Amsterdam: IOS Press.
Nalepa, G., Bobek, S., Lige
¸
za, A., Kaczor, K. (2011a). HalVA
– rule analysis framework for XTT2 rules. In Bassiliades,
N., Governatori, G., Paschke, A. (Eds.) Rule-based reasoning,
programming, and applications, Lecture notes in computer
science, (Vol. 6826 pp. 337–344). Berlin: Springer. http://www.
springerlink.com/content/c276374nh9682jm6/.
Nalepa, G., Lige
¸
za, A., Kaczor, K. (2011b). Overview of knowledge
formalization with XTT2 rules. In Bassiliades, N., Governatori,
G., Paschke, A. (Eds.) Rule-based reasoning, and programming,
and applications, Lecture notes in computer science, (Vol. 6826
pp. 329–336). Berlin: Springer.
1184 Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

Nalepa, G.J., Lige
¸
za, A., Kaczor, K. (2011c). Formalization and
modeling of rules using the XTT2 method. International Journal
on Artificial Intelligence Tools,20(6), 1107–1125.
Nalepa, G.J., Kluza, K., Kaczor, K. (2013). Proposal of an inference
engine architecture for business rules and processes. In Rutkowski,
L. et al. (Eds.) Artificial intelligence and soft computing: 12th
international conference, ICAISC 2013: Zakopane, Poland, June
9–13, 2013, Lecture notes in artificial intelligence, (Vol. 7895
pp. 453–464): Springer. http://www.springer.com/computer/ai/
book/978-3- 642-38609- 1.
OMG (2006). Semantics of business vocabulary and business rules
(SBVR). Tech. Rep. dtc/06-03-02, Object Management Group.
OMG (2011a). Business process model and notation (BPMN):
Version 2.0 specification. Tech. Rep. formal/2011-01-03, Object
Management Group.
OMG (2011b). Decision model and notation request for proposal. Tech.
Rep. bmi/2011-03-04, Object Management Group, 140 Kendrick
Street, Building A Suite 300, Needham, MA 02494, USA.
OMG (2015). Decision model and notation (DMN). Version 1.0:
Formal Specification. Tech. rep., Object Management Group
(OMG). http://www.omg.org/spec/DMN/1.0/Beta2/.
Ouyang, C., Wil, M.P., van der Aalst, M.D., ter Hofstede, A.H.
(2006a). Translating BPMN to BPEL. Tech. rep., Faculty of
Information Technology, Queensland University of Technology,
GPO Box 2434, Brisbane QLD 4001, Australia Department of
Technology Management, Eindhoven University of Technolog y,
GPO Box 513, NL-5600 MB, The Netherlands.
Ouyang, C., Dumas, M., ter Hofstede, A.H., van der Aalst, W.M.
(2006b). From BPMN process models to BPEL web services. In
IEEE international conference on web service (ICWS’06).
Sivaraman, E., & Kamath, M. (2002). On the use of Petri nets for
business process modeling. In Proceeding of the 11th annual
industrial engineering research conference.
Smirnov, S., Weidlich, M., Mendling, J., Weske, M. (2012). Action
patterns in business process model repositories. Computers in
Industry,63(2), 98–111.
Speck, A., Feja, S., Witt, S., Pulverm¨
uller, E., Schulz, M. (2011).
Formalizing business process specifications. Computer Science
and Information Systems/ComSIS,8(2), 427–446.
Szpyrka, M., Nalepa, G.J., Lige
¸
za, A., Kluza, K. (2011). Proposal
of formal verification of selected BPMN models with Alvis
modeling language. In Brazier, F.M., Nieuwenhuis, K., Pavlin, G.,
Warnier, M., Badica, C. (Eds.) Intelligent distributed computing
V. Proceedings of the 5th international symposium on intelligent
distributed computing – IDC 2011, Delft, the Netherlands –
October 2011, Studies in computational intelligence, (Vol. 382
pp. 249–255): Springer. http://www.springerlink.com/content/
m181144037q67271/.
van der Aa, H., Leopold, H., Batoulis, K., Weske, M., Reijers, H.A.
(2016). Integrated process and decision modeling for data-driven
processes. In Business process management workshops. BPM
2015 international workshops, Innsbruck, Austria, August 31–
September 3, 2015, Revised Papers, Lecture notes in business
information processing (pp. 405–417): Springer International
Publishing. https://doi.org/10.1007/978-3-319-42887-1 33.
Wagner, G., Giurca, A., Lukichev, S. (2005). R2ML: a general app-
roach for marking up rules. In Bry, F., Fages, F., Marchiori,
M., Ohlbach, H. (Eds.) Principles and practices of semantic web
reasoning, Dagstuhl seminar proceedings (p. 05371).
Wang, W., Indulska, M., Sadiq, S., Weber, B. (2017). Effect of linked
rules on business process model understanding. In International
conference on business process management, (Vol. 10445, pp. 200–
215). Springer.
Weske, M. (2012). Business process management: concepts, lan-
guages, architectures, 2nd edn. Berlin: Springer.
Wong, P.Y.H., & Gibbons, J. (2008). A process semantics for BPMN.
In Liu, S., Maibaum, T.S.E., Araki, K. (Eds.) Proceedings from
the 10th international conference on formal engineering methods,
ICFEM 2008, Kitakyushu-City, Japan, October 27–31, 2008,
Lecture notes in computer science, (Vol. 5256 pp. 355–374):
Springer.
Wong, P.Y.H., & Gibbons, J. (2011). Formalisations and applications
of BPMN. Science of Computer Programming,76(8), 633–650.
Wynn, M., Verbeek, H., Wvd, A., At, H., Edmond, D. (2009).
Business process verification – finally a reality!. Business Process
Management Journal,1(15), 74–92.
Krzysztof Kluza is an assistant professor at the AGH University of
Science and Technology in Krakow. Currently, he is Deputy Dean of
Faculty of Electrical Engineering, Automatics, Computer Science and
Biomedical Engineering at AGH UST. He obtained MSc in Automatics
& Robotics (2009) at AGH UST, MA in Cultural Studies (2010) at
Jagiellonian University in Krakow, and PhD in Computer Science
(2015) at AGH UST. Krzysztof Kluza is also an alumnus of “Top
500 Innovators” Science-Management-Commercialization program
at Stanford University and a Vice President of the Creativity and
Innovation Lab Foundation. He published over 50 papers related to
knowledge and software engineering. His primary scientific interests
focus on business processes and business rules in information systems.
Grzegorz J. Nalepa is an engineer with degrees in computer science -
artificial intelligence, and philosophy. He has been working in the area
of intelligent systems and knowledge engineering for over 15 years. He
formulated the eXtended Tabular Trees rule representation method, as
well as the Semantic Knowledge Engineering approach. He authored a
book “Modeling with Rules using Semantic Knowledge Engineering”
(Springer 2018). He co-edited a book “Synergies Between Knowledge
Engineering and Software Engineering” (Springer 2018). He co-
authored over 150 research papers in international journals and
conferences. He coordinates GEIST - Group for Engineering of
Intelligent Systems and Technologies (http://geist.re), and cooperates
with AGH University and Jagiellonian University in Krakow, Poland.
He is a member of Polish Artificial Intelligence Society (PSSI), IEEE,
Italian Artificial Intelligence Society (AI*IA) and KES. His recent
interests include context-aware systems and affective computing.
1185
Inf Syst Front (2019) 21:1167–1185
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

1.
2.
3.
4.
5.
6.
Terms and Conditions
Springer Nature journal content, brought to you courtesy of Springer Nature Customer Service Center GmbH (“Springer Nature”).
Springer Nature supports a reasonable amount of sharing of research papers by authors, subscribers and authorised users (“Users”), for small-
scale personal, non-commercial use provided that all copyright, trade and service marks and other proprietary notices are maintained. By
accessing, sharing, receiving or otherwise using the Springer Nature journal content you agree to these terms of use (“Terms”). For these
purposes, Springer Nature considers academic use (by researchers and students) to be non-commercial.
These Terms are supplementary and will apply in addition to any applicable website terms and conditions, a relevant site licence or a personal
subscription. These Terms will prevail over any conflict or ambiguity with regards to the relevant terms, a site licence or a personal subscription
(to the extent of the conflict or ambiguity only). For Creative Commons-licensed articles, the terms of the Creative Commons license used will
apply.
We collect and use personal data to provide access to the Springer Nature journal content. We may also use these personal data internally within
ResearchGate and Springer Nature and as agreed share it, in an anonymised way, for purposes of tracking, analysis and reporting. We will not
otherwise disclose your personal data outside the ResearchGate or the Springer Nature group of companies unless we have your permission as
detailed in the Privacy Policy.
While Users may use the Springer Nature journal content for small scale, personal non-commercial use, it is important to note that Users may
not:
use such content for the purpose of providing other users with access on a regular or large scale basis or as a means to circumvent access
control;
use such content where to do so would be considered a criminal or statutory offence in any jurisdiction, or gives rise to civil liability, or is
otherwise unlawful;
falsely or misleadingly imply or suggest endorsement, approval , sponsorship, or association unless explicitly agreed to by Springer Nature in
writing;
use bots or other automated methods to access the content or redirect messages
override any security feature or exclusionary protocol; or
share the content in order to create substitute for Springer Nature products or services or a systematic database of Springer Nature journal
content.
In line with the restriction against commercial use, Springer Nature does not permit the creation of a product or service that creates revenue,
royalties, rent or income from our content or its inclusion as part of a paid for service or for other commercial gain. Springer Nature journal
content cannot be used for inter-library loans and librarians may not upload Springer Nature journal content on a large scale into their, or any
other, institutional repository.
These terms of use are reviewed regularly and may be amended at any time. Springer Nature is not obligated to publish any information or
content on this website and may remove it or features or functionality at our sole discretion, at any time with or without notice. Springer Nature
may revoke this licence to you at any time and remove access to any copies of the Springer Nature journal content which have been saved.
To the fullest extent permitted by law, Springer Nature makes no warranties, representations or guarantees to Users, either express or implied
with respect to the Springer nature journal content and all parties disclaim and waive any implied warranties or warranties imposed by law,
including merchantability or fitness for any particular purpose.
Please note that these rights do not automatically extend to content, data or other material published by Springer Nature that may be licensed
from third parties.
If you would like to use or distribute our Springer Nature journal content to a wider audience or on a regular basis or in any other manner not
expressly permitted by these Terms, please contact Springer Nature at
onlineservice@springernature.com