Data-Oriented Declarative Language for Optimizing Business Processes

Data-Oriented Declarative Language for Optimizing Business Processes Luisa Parody , María Teresa Gómez-López , and Rafael M. Gasca Abstract There is a signifi cant number of declarative languages to describe business processes. They tend to be used when business processes need to be fl exible and adaptable, being not possible to use an imperative description. Declarative languages in business process have been traditionally used to describe the order of activities, specifi cally the order allowed or prohibited. Unfortunately, none of them is worried about a declarative description of exchanged data between the activities and how they can infl uence the model. In this paper, we analyse the data description capacity of a variety of declarative languages in business processes. Using this analysis, we have detected the necessity to include data exchanged aspects in the declarative descriptions. In order to solve the gap, we propose a Data-Oriented Optimization Declarative LanguagE, called DOODLE, which includes the process requirements referred to data description, and the possibility to include an optimization function about the process output data. Keywords Business Processes • Declarative Language • Data-Oriented Optimization 5.1 Introduction A business process, henceforth referred to as BP, consists of a set of activities that are performed in coordination within an organizational and technical environment. These activities jointly perform a business goal [ 1 ]. In management theory during the last years, a process-oriented perspective has been considered the shell in organizational (re)structuring. Nowadays, organizations still experience diffi culties in applying this process-oriented perspective to the design and maintenance of their information systems. Currently, the deployment of more complex systems has put forth new requirements for fl exible and dynamic specifi cation. Several languages propose an imperative representation of business processes, whose specifi cation allows business experts to describe relationships between activities, and to transform the process into an executable model. Therefore, an imperative description defi nes exactly how activities have to be performed, and how to handle the datafl ow. However, one of the disadvantages of imperative languages comes from the use of unsuitable information for computer systems, since they do not provide fl exible and adaptable business processes. A declarative representation takes into account the business concerns that govern the BP. A BP may be exposed to different environments and subjected to many conditions in which the order of activities, or the data exchanged, cannot always be described at design time or in an easy way. This is the reason why several authors have proposed languages to defi ne BP as declarative models, since sometimes the process cannot be completely defi ned at design time. One of the reasons why it is not possible to create an imperative model at design time, is related to the data that fl ow through the process. Depending on the data instantiated, the creation of one model or another could be better, since, for example, the model will infl uence the selection of the best data input of the activities to satisfy the process requirements. The role of data in declarative languages has not been very relevant, mostly limited to describe the execution or not of an activity, depending on the value of a variable of the data-fl ow. In this paper, we present a new point of view of declarative language focused on data, where we highlight the signifi cance of the information that fl ows through the process and between the activities to reach an optimal model according to the user requirements. Sometimes, the user of an application supported by a business process has to decide about the values to introduce at runtime, for example, the dates in the organization of a trip (booking fl ights, hotel room and renting a car). Frequently, if the user can choose between different dates in order to minimize the price, (s)he needs to search by hand the combinations of dates with the activities this mean searching for fl ights, hotel rooms and car rental. For this example, the model is known, being possible to execute the activities in a parallel manner. However, the process goal is to book a trip, and the objective function is to minimize the price of the trip. Then, in order to achieve the user requirements (to minimize the sum of the prices for the services, for a given set of dates), the best combination of data input for the activities needs to be found. To the best of our knowledge, none of the declarative languages permit the inclusion of data output optimization in this sense. For this reason, we propose a data-oriented decision language, called DOODLE. Although there is already a declarative language called DOODLE, presented by Cruz in [ 2 ], it is a visual and declarative language for object-oriented databases and our proposal is focused on a defi nition of a business process in a declarative way. Since DOODLE is oriented to data perspective, when in this paper we use the term ‘optimize the process’, it means that there is a function to be optimized and where the data-fl ow involved in the process are related with the aim to optimize the data output. To meet this challenge, we have analysed the existing declarative languages and how they have addressed data management, and the features that have not yet been analysed. The rest of the paper is organized as follows: Sect. 5.2 motivates and explains, through an illustrative example, the necessity in some cases to fi nd the data input values to optimize the process execution. Section 5.2 introduces a motivating example where a declarative description oriented to data is necessary. Section 5.3 details the proposed language based on the description of a declarative subprocess that can be combined with an imperative description, such as BPMN. Section 5.4 studies some of the most relevant proposals of declarative languages and their contributions to data management. The motivating example described by means of this language has been included and a comparison with the studied languages is presented. And fi nally, conclusions are drawn and future work is proposed in Sect. 5.5 . 5.2 On-Line Book Store: A Motivating Example In this section, we introduce an example to motivate the necessity to include in declarative languages some aspects related to data that have infl uence in the model. The example is based on a sale and delivery process that has been used in many papers before [ 3 – 5 ] and [ 6 ]. The example is the on-line Book Store (BS), that represents a company that collaborates with two services in order to sell and deliver books (see Fig. 5.1 ). Both services inform the customer about the fi nal price of buying and delivering a number of units of a book. However, it could be cheaper to buy this quantity of books in different packages by obtaining a discount. For example, if there is a discount depending on the number of units for a maximum, or the price of shipping depends on both the weight and volume of the boxes to send. In this case, it is cheaper to send two small boxes (e.g. 8€ each one) than a bigger one (e.g. 25€). Another example is if the customer wants to buy 5 units of a book, the cheapest option could be to buy them in two packages (3 + 2), since there is an offer “buy 3 pay 2”, and although two deliveries are paid, the delivery cost is increased considerably due to the weight and volume. The sale terminates when the books are delivered to the customer and the payment is made. Receive Customer Book Request Order Book Get Payment and Deliver Books Calculate Books Price Calculate Delivery Cost Fig. 5.1 On-line book store example In order to model the business process which support the BS example including the requirement to minimize the fi nal price, neither imperative nor declarative languages can be used. For imperative languages, Fig. 5.2 depicts two possibilities of implementation to satisfy the constraints, which are also included in the fi gure. On the one hand, Fig. 5.2a presents a possible imperative model in BPMN to describe the BS example. The model has several activities to execute the purchase and the delivery for each package, but the problem is that the numBooki variables are unknown, even at runtime, since they are determined to minimize the total cost in each instance. Moreover, the number of activities to buy and deliver the books are unknown at design time. The diffi culty in this case is that the specifi c values of the variables and the number of activities executed to minimize the objective function are unknown at design time. On the other hand, another solution could be that shown in Fig. 5.2b : various executions of the activities can be made by means of a loop, and the values of the numBooki variables will be determined programmatically in a new activity included in the model. The problem with this solution is the signifi cant diffi culty in implementing this activity, being necessary to delegate their programming to a computer science expert, not to a business process expert. In relation to the existing declarative languages, as is analysed in Sect. 5.4 , to the best of our knowledge, the current declarative languages are centred on the declarative description of the order of activities. However, none of them includes data input and output of the activities to optimize the object obtained from the business process. Calculate books price + Calculate Delivery Cost + Calculate books price + Calculate Delivery Cost numBookN, idBook BooksPriceN + DeliveryCostN numBookN, idBook ... Calculate books price Calculate Delivery Cost ++ ab numBook = numBook1 +…+ numBookN TotalPrice = Bookprice1 +…+ BookPriceN + DeliveryPrice1 +… + DeliveryPrice N Minimize (Total Price) numBook numBook1, idBook BooksPrice1 numBook1, idBook DeliveryCost1 Fig. 5.2 Imperative models for the on-line book store example. ( a ) Deployed imperative model. ( b ) Imperative model with implementation of tasks 5.3 DOODLE: Data-Oriented Optimization Declarative LanguagE In order to include the optimization function and the constraints into the business process model, we have defi ned a declarative language called DOODLE (Data- Oriented Optimization Declarative LanguagE). This language combines the imperative description of BPMN with a declarative description of the parts of the process that need more fl exibility (declarative subprocesses). The declarative description includes the data subprocess, data activities, objective function and the numerical constraints that let the designer describe the possible data values in a declarative way. These numerical constrains are defi ned by the following grammar where Variable and Value can be defi ned as Integer, Natural or Float domain: Constraint := Atomic−Constraint BOOL−OP Constraint | Atomic−Constraint | ’¬’Constraint BOOL−OP:= ’∨’ | ’∧’ Atomic−Constraint:= function PREDICATE function function:= Variable FUNCTION−SYMBOL function | Variable | ∑ Variable | Value PREDICATE:= ’=’ | ’<’ | ’≤’ | ’>’ | ’≥’ FUNCTION−SYMBOL:= ’+’ | ’−’ | ’∗’ These constraints make it easier and more precise when handling numeric data (that can be represented as variables) that represent relations between variables. In order to introduce the language, we have divided the description into two parts: (i) the internal description of the components associated with the activities of the declarative subprocess (Table 5.1 ), and (ii) the external description of the declarative subprocess, that implies the relation of the activities with subprocess data input and output also with constraints (Table 5.2 ). The language proposes to describe the order of the activities using imperative or declarative languages, depending on the necessity of the process. For the BS example, a parallel execution is possible, then it can be described imperatively. In order to understand the example better, the language has been used to model the BS problem, as shown in Fig. 5.3 . In order to transform this declarative model into an imperative model that supports any value of input variables of the process (idBook and number Of Books for example), we propose the use of Constraint Programming paradigm (explained in Sect. 5.4.1 ) [ 7 ] and domain local analysis of the variables [ 8 ]. The created model will depend on the knowledge of the relationship between input and output data of the activities, specifi cally, if this relationship Table 5.2 External components of the declarative subprocess Symbol Name Description Parameters SDI1, …, SDIn SDI Subprocess data input (SDI) Data input of the subprocess that describe the user requirement in each process execution List of variables SDO1, …, SDOm SDO Subprocess data input (SDI) Data input of the subprocess that describe the user requirement in each process execution List of variables f: v Objective function An optimization function in terms of a data Minimize or maximize and the objective variable C1, …, Cn ID ID input constraints (IC) Set of constraints that relates the SDI with the DI of each activity of the subprocess Numerical constraints C1, …, Cn ID ID output constraints (OC) Set of constraints that relates the SDO with the DO of each activity of the subprocess Numerical constraints C1, …, Cn Internal constraints Set of constraints that relates the DI and DO of the activities among them Numerical constraints Table 5.1 Internal components associated to the activities of the declarative subprocess Symbol Name Description Parameters DI1, …, DIn DI Data input (DI) of the activity Set of data input of each activity List of variables DO1, …, DOm DO Data output (DO) of the activity Set of data output of each activity List of variables C1, …, Cn <<Pre>> Precondition Set of constraints that represents the values of the DI that satisfy the execution of the activity Numerical constraints C1, …, Cn <<Post>> Postcondition Set of constraints that represents the values of the DO that are satisfi ed after the execution of the activity Numerical constraints A N Repetition of an activity A Representation of the number of times that an activity can be executed. The value can be numeric (e.g. 5), or symbolic (e.g. N) Integer or string can be known with or without executing the activities. For the BS example, the totalPrice can only be known if the activities are executed, although if the pre and post-conditions of the activities could relate input and outputs, the execution of the activities would be not necessary. 5.4 Related Work There are many languages that enable the description of business processes in a declarative way. Generally, the common idea of declarative business process modelling is to model a process as a trajectory in a state space, and declarative constraints are used to defi ne the valid movements in that state space [ 9 ]. Therefore, the differences between declarative process languages can, in part, be understood as a different perception of the meaning of ‘state’. Analysing the different proposals, we have found some characteristics that we consider interesting to be compared. The characteristics are studied in Sect. 5.4.1 and compared in Sect. 5.4.2 . 5.4.1 Declarative Language Characteristics Analysing the different proposals related to declarative languages, the main characteristics that we think should be analysed and compared are: • Formalism for reasoning: The proposals use different formalism for reasoning. Sometimes, although we show the most relevant in each case, they can combine more than one and be improved with made-to-measure algorithms. Only the most relevant have been included in the paper due to space limitations. – Linear Temporal Logic (LTL). As demonstrated by Chomicki [ 10 ], Bacchus and Kabanza [ 11 ] and Pesic and van der Aalst [ 12 ], LTL expressions can be used to represent desirable or undesirable patterns within a history of events. LTL is a modal temporal logic that allows the expression of temporal constraints + idBook, nBooksBuy DI bookPrice DO + numberOfBooks = nBooksBuy ID totalPrice = bookPrice + deliveryCost ID totalPrice SDO minimize: totalPrice idBook, nBooksDeliv DI deliveryCost DO nBook>0 <<Pre>> bookPrice>=0 <<Post>> nBook>0 <<Pre>> deliveryCost>=0 <<Post>> N M nBooksBuy=nBooksDeliv n=m Calculate Books Price Calculate Delivery Cost idBook, numberOfBooks SDI Fig. 5.3 Example of buy books described using DOODLE on infi nite paths within a state space. LTL formula can be evaluated by obtaining the Büchi automaton that is equivalent to the formula and checks whether a path corresponds to the automaton. Unfortunately most LTL checking algorithms assume infi nite paths and construct non-deterministic automata [ 12 ]. Another disadvantage is that LTL does not allow the expression of the effect that results from a particular transition in a state space. For these reasons, it is not evident to express a goal state in LTL nor to construct automata for planning an execution scenario to obtain a goal state [ 11 ] as is needed in an optimization function. – The Event Calculus. In fi rst-order logic there is a formalism that elegantly captures the time-varying nature of facts, the events that have taken place at given time points and the effect of these events refl ecting on the state of the system. This formalism is called the Event Calculus. The Event Calculus, introduced by Kowalski and Sergot [ 13 ], is a logic programming formalism to represent and reason about the effect of events on the state of a system. The Event Calculus is appealing for several reasons, as it builds on a fi rst-order predicate logic framework, for which effi cient reasoning algorithms exist. In addition the Event Calculus not only has the ability to deductively reason about the effects of the occurrence of events (leading to the coming into existence of fl uency or the ceasing to hold), most importantly, it also has the ability to reason abductively. Abductive reasoning over the event calculus has been shown to be equivalent to planning. In particular, abductive reasoning produces a sequence of transitions (denoted by events) that must happen for a particular instance to hold in the future [ 14 – 16 ]. – Constraint Programming (CP). Constraint Programming [ 17 ] is a paradigm that permits the description of the model by means of the variables and the constraints that relate the variables. The model is called a Constraint Satisfaction Problem (CSP), that represents a reasoning framework consisting of variables, domains and constraints. Formally, it is defi ned as a tuple ( X , D , C ), where X = { x 1 , x 2 , …, x n } is a fi nite set of variables, D = { d ( x 1 ), d ( x 2 ), …, d ( x n )} is a set of domains of the values of the variables, and C = { C 1 , C 2 , …, C m } is a set of constraints. Each constraint C i is defi ned as a relation R on a subset of variables V = { x i , x j , …, x l }, called the constraint scope . The relation R may be represented as a subset of the Cartesian Product d ( x i ) x d ( x j ) x … x d ( xl ). A constraint Ci = ( V i , R i ) simultaneously specifi es the possible values of the variables in V in order to satisfy R . Let V k = { x k 1 , x k 2 , …, x kl } be a subset of X , and an l-tuple ( x k 1 , x k 2, …, x kl ) from d ( x k 1 ), d ( x k 2 ), …, d ( x kl ) can therefore be called an instantiation of the variables in V k . An instantiation is a solution if and only if it satisfi es the constraints C . • Imperative and Declarative : This is the capacity of a language to describe imperative and declarative aspects in the same model, since sometimes a part of the process is completely unknown, and other parts are totally known. • Use of the language: The existing proposals that we have analysed are focused on different objectives: Validation of the model for a trace of events, Construction of automatons to generate a possible sequence of activities, or Assistance to the user to decide which is the best activity to execute at runtime. • Data perspective: The possibility to include the values of the data-fl ow variables in the rules that describe the declarative model. • Pre and Post-condition: The inclusion of a description of the system before and after it is instantiated by means of pre and post-conditions. This is a relevant aspect since it allows the modeller to describe the data before and after the process execution, without the inclusion of details about the internal description of the process. • Optimization Function: The possibility to include an optimization function in the declarative description that is taken into account in the model. 5.4.2 Analysis of Declarative Languages Some of the most important declarative languages have been included and compared in this section. • Pocket of fl exibility . This solution is based on constraint specifi cation of the business process workfl ow. The constraint specifi cation framework [ 18 ] represents the workfl ow as a directed graph where there are two types of nodes: activity nodes and coordinator nodes. In the framework, it is possible to combine activities whose relation is known with activities whose relation is unknown (called pocket of fl exibility) that include a set of constraints for concretizing the pocket with a valid composition of work-fl ow fragments. It includes different types of constraints (Serial, Order, Fork, Inclusion, Exclusion, Number of executions for activity or in parallel). The constraints relate the number of times that each activity can be executed and the order and/or mandatory execution of each activity. The proposal defi nes a set of algorithms to fi nd possible discrepancies between the constrains that describe the process and an instance. The implementation is based on a made-to-measure algorithm that uses the graph to represent the constraints. The implementation has been included in the prototype called Chameleon . The data aspect has not been included in this proposal. • DeCo. Irina Rychkova et al. in [ 19 ], [ 4 ] and [ 20 ] presented a declarative BP specifi cation language that enables designers to describe the actions that a business process needs to contain, but not where their specifi c sequence can be postponed to the instance time. They improve the alignment of the BP with the business strategy of an organization by giving a synthesis of a set of business processes (abstracting the control fl ow), while maintaining a rigorous relationship with the detailed process. These specifi cations complement the traditional