Formal Model of Business Processes Integrated with Business Rules

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.


Introduction
Business Process Management (BPM) (Dumas et al. 2013;Weske 2012) is a holistic approach for improving organization's workflow in order to align processes with client needs.It focuses on reengineering of processes to obtain optimization 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 produces 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.
Although processes provide a universal method of describing 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; however, rules can be to a certain degree complementary to processes.BR provide a declarative specification of domain knowledge, 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.
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 2 presents an overview of related works concerning process model formalization.Section 3 provides 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. In order to apply this model to a specific rule solution, the SKEspecific 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.

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.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.

Formalization of Business Process Models
In 2002, Sivaraman and Kamath (2002) used Petri 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 andGibbons (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 (2009Lam ( , 2012) ) formally defined the token-based semantics of BPMN models in terms of Linear Temporal Logic (LTL).This allows for verification and reasoning on BPMN models, especially for checking such properties 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 termination condition.Smirnov et al. (2012) introduced simple formalization for defining action patterns in business process model repositories.Action patterns capture different relations among actions often observed within process model collections.The formalization used in Smirnov et al. (2012) allowed the authors extract various types of action patterns from industrial process model collections.Bȃdicȃ et al. (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ȃdicȃ and Bȃdicȃ 2011).

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.

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 A BPMN 2.0 process model is a tuple P = (O, F, ), where: where F ⊂ is a subset of attributes that are used in sequence flows.
Moreover, the set of flow objects is divided into sets: -A is the set of activities such that A = T ∪ S, T ∩ S = ∅, where T is the set of tasks and S is the set of sub-processes, τ 1 , τ 2 , τ 3 , . . .∈ T and s 1 , s 2 , s 3 , . . .∈ S, -E is the set of events, e 1 , e 2 , e 3 , . . .∈ E -G is the set of gateways, g 1 , g 2 , g 3 , . . .
The set of all the possible BPMN 2.0 process models will be denoted P, e.g.P 1 , P 2 , P 3 , . . .∈ P.
Moreover, T x will denote the set of tasks of the same 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 (T Service ) it determines the service technology, in the case of Send tasks (T Send ) or Receive tasks (T Receive ), it specifies the technology that will be used to send or receive messages respectively, and in the case of Business Rule tasks (T Business 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 A sub-process interpretation is a triple: where: type(s) determines the type of the sub-process s, type(s) ∈ {Sub-process, Embedded, CallActivity, Transaction, Event}, -P s ∈ P is 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},3 such attributes are defined same as for tasks (see Definition 2).
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.Moreover, E x will denote the set of events with the same trigger x: will denote the set of events of the same type x: Different types of events have different event definition attributes specified, e.g.: - 4 The 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 It is also important to note that not every trigger(e) is allowed for any type(e) of event -Table 1 presents the possible combinations.
In the case of this formalization, the condition attribute for e ∈ E Conditional is especially important.It defines an expression stored in body attribute and expressed in the language 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 -F in g and F out g are sets of sequence flows (input and output flows respectively), 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: 5 The 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). - Some types of gateways can have several additional attributes specified, such as: Sequence Flows are used for connecting flow objects o ∈ O in the process.
Definition 6 A sequence flow interpretation is a tuple: where: Two boolean attributes: conditional and default determine the conditional or default type of the flow.A conditional flow has to specify the condition and a default flow has no condition, i.e. conditional(f A subset of conditional sequence flows will be denoted A condition 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 f sequence flow: eval(condition(f )) ∈ {true, false}.If condition 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.

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 A Rule Base is a tuple K = (A, R, T), where: -A is the set of all attributes used in the rule base, -R is the set of all rules, r 1 , r 2 , r 3 , . . .∈ R, and a single rule r i contains its conditional part denoted as cond(r i ).8 -T is the set of all decision components, t 1 , 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 ⊂ 2 R ).
Moreover, it is assumed that each rule base specifies a language(r)9 in 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 A General Business Logic Model is a tuple M = (P, K, map), where: -K is a rule base containing rules (as defined in Definition 7), -P is a BPMN 2.0 process model (as defined in Definition 1), map is a map function defined as follows: 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 ∈ F Conditional (see Fig. 1) the following requirements have to be fullfiled in M: -All BPMN conditional sequence flows in P have the condition in the form of a conditional part of a rule from the K rule base assigned, formalized, i.e. the following holds: ∧ (language(f ) = language(r)).
-All condition attributes A r ⊂ A required by the rule r should be available in the P model, i.e.: Conditional Event Conditional Event e ∈ E Conditional 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 P have the condition in the form of a conditional part of a rule from the K rule base assigned, i.e.: ∧ (language(e) = language(r)).
-All condition attributes A r ⊂ A required by the rule r should be available in the P model, i.e.: ∀ r∈R (∃ e∈E map(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: 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 P have the decision component from the K rule base assigned, i.e.: -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.: -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.: 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: In the case of exclusive (G × ), inclusive (G • ) and complex (G * ) diverging gateways (see Fig. 6), there is a need for the model M to 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.: ∧ (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.: -In the case of exclusive gateways, the evaluated conditions have to be exclusive, i.e.: 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 P specify the rule of passing tokens, i.e.: ∧(language(g) = language(r)), where activationCondition(g) = {body(g), language(g)}.
-All condition attributes A r ⊂ A required by the rule r should be available in the process model, i.e.: 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 M to 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.: 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 M to 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 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: -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:

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.: 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 the model for specific rule representation, e.g. the XTT2 representation from the SKE approach, which will be presented in the following sections.

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 (2010bNalepa ( , 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 ALSV(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), A denotes the set of all attributes used to describe the system.Each attribute a i ∈ A, i = 1 . . .n has a set of admissible values that it takes (a domain) denoted as D i .Any domain is assumed to be a finite set.
where a i is an attribute, -x i is the value of the attribute (it can be a single element of the domain or a subset of the domain), -is an operator from the set of operators for attributes, 13 such that ∈ {=, =, :=, ∈, / ∈, ⊆, ⊇, ∼, ∼}.
The ALSV(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 r i (here called also rule) is a triple of the form: where cond i ⊆ E is a conditional part of a rule consisting of legal atomic formulae in terms of ALSV(FD), -dec i ⊆ E is a decision part of a rule consisting of legal atomic formulae in terms of ALSV(FD).
The set of all rules will be denoted as R, and r 1 , r 2 , . . .∈ R. A rule schema for a given rule r i (called also rule template) is a pair schema(r i ) = (A cond i , A dec i ), where A cond i and A dec i are 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(FD) 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 13 The 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: The set of decision components is denoted as T , t 1 , t 2 , ... ∈ T .An XTT2 table schema (also called a schema of the component or table header) is denoted as schema(t).

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: M SKE = (P, K SKE , map), where: SKE-specific rule base, where: -T X is a set of the XTT2 decision components, -R is a set of the XTT2 rules, such as: and the conditional cond(r i ) part of a rule is defined as follows: where r i = (E cond i , E dec i , ACT i ), -A is a set of the attributes used in the XTT2 rule base, i.e.:14 • map is a mapping function between the elements of the P process model and the elements of the K SKE rule base.
The K SKE rule base specifies the value of language, such as: ∀ r i ∈R language(r) = "XTT2".Moreover, the infer(t) method is defined as follows: infer(t) = A dec t .This stems from the fact that in the SKE-specific Business Logic Model, every decision component t ∈ T X is an XTT2 decision table.Thus, the result of the inference is the set of decision attributes of this decision table. 15n the following paragraphs, the integration details are specified. 16onditional Sequence Flow For the Conditional Sequence Flows f ∈ F Conditional the following hold: -All BPMN conditional sequence flows in P have the condition in the form of a conditional part of a rule from the K SKE rule base assigned, formalized, the following holds: -Values of the condition attributes required by the rule are mapped to the values of corresponding attributes in the rule base: 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 P have the condition in the form of a conditional part of a rule from the K SKE rule base assigned, i.e.: Business Rule Task For the BPMN Business Rule tasks, the following formulas have to be fullfiled: -All BPMN BR tasks in P have the decision component from the K SKE rule base assigned: -All the input attributes required by the HEART rule engine 17 for a rule set specified by the decision component should be available in the process model, i.e.: -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.: Diverging (Exclusive, Inclusive/Multi-choice and Complex) Gateways For the Diverging (Exclusive, Inclusive/Multichoice and Complex) Gateways the following hold: -All BPMN sequence flows (apart from the default ones) outgoing from a diverging gateway have the condition 17 HEART 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 K SKE rule base assigned, i.e.: -In the case of exclusive gateways, the evaluated conditions have to be exclusive, i.e.: 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.: 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.

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).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 M P LI SKE model is as follows (the abbreviations for the names are presented in Table 2): M P LI SKE = (P P LI , K P LI SKE , map P LI ), where: 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 K P LI SKE rule base.In such a case, the Business Rule tasks have to be associated with the decision tables from the T X set containing the proper XTT2 rules.
Below, the specification of decision tables is presented (it provides decision table schemas which have to be complemented with XTT2 rules).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(t BR5 ).
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).
Fig. 13 The design and verification process of the rule model In the model, this decision table is represented as follows: 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 Prosecco (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 system 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 decision logic.We user our integrated model to design these 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 execution of the rule components to our dedicated embedded rule engine (HeaRTDroid).

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 important 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 supported by the HiBuProBuRul Project funded from NCN (National Science 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.

Fig. 5
Fig. 5 Business rule task (a standard and a call activity task)

Fig. 9
Fig. 9 Gateway preceded by a subprocess

Table 1
Possible combinations of trigger(e) and type(e) 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 A gateway interpretation is a tuple: g = (F in g , F out g , type(g), g ) where: o 1 , o 2 are respectively source and target elements, -

Table 4
Comparison of the selected cases