Verifying the manipulation of data objects according to business process and data models

Verifying the manipulation of data objects according to business process and data models José Miguel Pérez-Álvarez1 · María Teresa Gómez-López1 · Rik Eshuis2 · Marco Montali3 · Rafael M. Gasca1 Abstract Business processes read and write data objects, usually stored in databases. Although data models and activity-oriented business process models originate from different paradigms, they need to work together properly. The data object states are transformed during each process instance by the activities of the process model. It is therefore necessary to verify whether the states of the data objects are correct according to the process model, and to discover the states of the stored data objects. This implies determining the relation between the data objects stored in the database, the data objects involved in the process, and the activities that within the business process that create the data objects and modify their states. In order to verify the business process annotated with data states and to reduce the existing gap between data model and business process model, we propose a methodology that includes enlarging the capability to describe data states in business processes; verifying the completeness and consistency of the data states described in accordance with their relation to the business process model; and discovering the states of the data objects stored in the database according to the business process model where they are managed. The methodology is supported by a framework that enables a natural-like language to be employed to describe the states, to apply the necessary algorithms to verify the consistency and completeness of the model, and to determine the states of the stored data objects according to the model described. To validate our proposal, an extension of ActivitiTM has been implemented and applied to a real example as an illustration of its applicability. Keywords Business processes · Integration of data and processes · Data object state · Object-relational mapping · Data state verification 1 Introduction Business processes (BPs) and their continuous improvement are fundamental to the operation of companies. For a wide range of enterprises, business process analytics, validation, and verification are a key endeavour [1]. The automation of processes offers an opportunity to BJosé Miguel Pérez-Álvarez [email protected] Extended author information available on the last page of the article gain visibility and control over both the execution of processes and the analysis of their underlying data. Process data in general are stored and manipulated through various systems, applications, and services, and sometimes shared among several processes and information systems. In this light, it becomes crucial to simultaneously tackle both the business processes and their related data [2]. This gives rise to integrated models for processes and data which in turn opens up the possibility for their analysis and verification [3,4]. Notably, these integrated models can also be distributed in Big Data environments [5]. Intensive research on data-aware processes has brought forward non-conventional, data- and artefact-centric models of business processes [6]. At the same time, in spite of the lack of data awareness of conventional, activity-centric process notations such as BPMN [7], conventional business process management systems (BPMS) all support the enrichment of such notations with various types of volatile and persistent data. In fact, when the complexity and quantity of such data are high, contemporary organisations tend to incorporate a commercial BPMS to support the operation of processes and the management of their corresponding data. The benefits of employing a BPMS are several [8], and include: (1) the possibility of choreographing various processes a variety of technologies; (2) the elicitation of domain knowledge using graphical languages; (3) the support by a business modeller to reduce overheads, resulting in less time and/or fewer resources being used to achieve an end result; (4) the possibility of more effectively detecting process inconsistencies, and handling their optimisation; and (5) the possibility to use several tools and technologies that enable business intelligence on top of the process data. Virtually every contemporary BPMS provides a way to consistently store the data produced and manipulated during the execution of processes, typically relying on relational databases. In this context, a database can be understood as a repository of business data objects that might be created and modified during process executions. A number of the stored data objects represent the values involved in past and current business process executions, which had been included in the database previous to the incorporation of the BPMS. The values of the stored data represent the states of the business objects obtained from the process execution, regardless of whether this process was performed by means of the activities of a BPMS, third-party applications, or direct human updates performed through the information system. Consequently, there are two main challenges arising from the necessity of combining data objects and business processes. On the one hand, data models and activity-centric business process models are usually modelled separately, or integrated within contemporary BPMS using ad hoc mechanisms [9]. On the other hand, the BPMS may use data that is not created and manipulated by its enacted processes, but that was created before and exists independently from the BPMS itself [10]. This brings about the necessity to explicitly incorporate data objects and their states into the business process model, thereby reducing the existing gap between the states of the stored business data objects, and how they are modelled, accessed, and modified in the process model. The capacity to annotate the business processes with the states of the data object was included in BPMN 2.0 [11], but a substantial linkage is required between the data and process dimensions going far beyond that which is supported by the standard. A conceptual alignment between persistently stored data objects and business processes can also help detect deviations between the expected and realised behaviours, and to understand whether the enacted processes are aligned with the intended processes. In this work, we tackle the problem of verifying the overall correctness of data objects and their lifecycle, according to how process models evolve the states of such business objects. To verify the correct evolution of the data objects through the workflow, a (DSL) domainspecific language has been defined to describe the data states in various parts of the process. The consistency and completeness of the described data states and the business process model are analysed to ascertain whether the possible evolution of a data object during an instance can create or update an object erroneously. Inordertosupportthebusinessprocessmodelannotatedwithdataobjectsanditsautomatic verification, our proposal provides a set of definitions of properties related to consistency and completeness in the context. Furthermore, a methodology has been defined, supported by a framework that defines the steps to model the annotated business process, incorporate the data stored from a legacy database, and to ensure the correctness of the model (i.e. data model and process model). The framework incorporates a constraint programming solver to evaluate the consistency and completeness of the model that is being integrated into a commercial BPMS tool. In order to facilitate the understanding of our proposal, the rest of the paper is organised as follows: Sect. 2introduces the definitions regarding process models and data states; Sect. 3 introduces the proposed definitions regarding consistency, completeness, and data object correctness; Sect. 4depicts the algorithms needed to verify the data states in the process model and the validation of the stored object in a relational repository; Sect. 5explains the methodology and the proposed framework for the verification of the correctness according to the presented definitions, and the details about a domain-specific language (DSL) that facilitates the description of the data states; Sect. 6analyses an overview of related work found in the literature; Sect. 7marks the limitations and the scope of our proposal; and finally, conclusions are drawn and future work is depicted in Sect. 8. 2 Data state model and verification The understanding of the relationships existing between business processes and business data remains deficient [3], since these two models are disconnected and described using different languages and software tools. Since these two perspectives are not well-integrated in the existing process management systems, the verification of their combination remains a challenge. The necessity to combine data perspective and business process workflow during a verification process is not a new issue and has been analysed by Sun et al. [12]. This decoupling necessitates verification of the correctness of the combinations of the two models, because the problem of data verification cannot be reduced to the simple analysis how single and isolated values traverse a workflow that the existing isolation between stored data and the business process models that manage them is a recognised problem in the research community [4]. Significant proposals have been published in recent years on this issue, including those involving the use of data as the centre of the process model, known as artefact-centric business process models [13–15]. However the problem to be addressed is that activities and data have to coexist in the same business process, while sharing and using information produced in other activities, or even in other processes [16], and the data states must be consistent with the workflow process that manages them. Various modelling paradigms are combined: Business Process Modelling,Conceptual Data Model,andData Object Life cycle Modelling. In order to understand the difficulty in verifying the correctness between business processes annotated with the states of the data objects combined together, the following subsections formalise the different parts of the problem using a motivating example. The example given to clarify the proposal is related to the paperwork of the presentation of a thesis described in the current regulations of the University of Seville as published in [17]. The university uses made-to-measure software that stores the information about students in a relational database, but no description is provided Student Department Apply thesis project Send project documents Finish thesis document Send Thesis documents Present Thesis [approved presentaon] Study the thesis project Inform student of project evaluaon [denied project] [approved project] Deposit the document Analyse the evaluaon commiee Hold a department meeng Inform student of thesis Evaluaon [thesis denied] Request the documentaon Payment of fees Fig. 1 Thesis paperwork process example regarding how the object evolves during the process and the relation with the state of thesis development. Since different paradigms must be combined, various formal languages are analysed in this paper. 2.1 Business process modelling BPMN 2.0 [11] is a standard notation that provides an understandable language for all business users (i.e. business analysts, technical developers, and business people who manage and monitor those processes). Thus, BPMN creates a standardised bridge for the gap between the design and implementation of the business process. The process described using BPMN, shown in Fig. 1, is a simplification of the real process regarding the presentation of a thesis, but the example includes all the components necessary for the difficulties to be understood. The business process model example includes the activities developed by Students and Departments. The process begins with the application of a thesis project by a Student, after which, the project documents are sent to the Department, which studies the documentation, and informs the Student about the evaluation. If the thesis project is rejected, then the Student should start the process again from the beginning, otherwise the Student should finish the documents and send them to the Department.In a parallel way, the evaluation committee evaluates the documentation, while the fees are paid and the deposit is completed. After having completed both activities, a department meeting is held to evaluate all the theses which have been prepared in the department since the last department meeting. The Student is then informed about the result of the evaluation and, if the presentation of the thesis is approved, the Student may present the thesis. In order to complete the process, the Student formalises the necessary documentation to obtain the Ph.D. title. In order to facilitate explanations regarding data states and model verifications, we use the definition of a process model in BPMN 2.0 as a process graph. This facilitates the explanation and development of how to traverse business processes and the data states associated with these processes in order to verify the model correctness. The construction of the process graph is based on the annotated graph presented in [18], and includes certain differences as explained in [19], and is enlarged with the data states associated as input and/or output of each activity node. Definition 1 (Process Graph) A process graph is a labelled directed graph G = N, E,composed of nodes (N) and edges (E). N is the disjoint union of {n0} (start node), N+ (end nodes), NT (task nodes), NPS (parallel splits), NPJ (parallel joins), NORS (or splits), NORJ (or joins), NXS (xor splits), and NXJ (xor joins). For n∈N,IN(n)/OUT(n) denotes the set of incoming and outgoing edges of n, respectively. Each task node ncan have an associated data state that represents the states of the data object before and after this task is executed, S(n)IN and S(n)OUT (States IN and States OUT). In order to determine that a business process workflow model described by a process graph is correct, it is required that: 1. For each split node n,|IN(n)|=1and|OUT(n)|>1; 2. For each join node n, |IN(n)|>1and|OUT(n)|=1; 3. For each n∈NT,|IN(n)|=1and|OUT(n)|=1; 4. For n0,|IN(n)|=0and|OUT(n)|=1, and vice versa for n∈N+; 5. Each node n∈Nis on a path from the start to an end node; 6. If |IN(n)|=1, then IN(n) is identified with its single element, and similarly for OUT(n); 7. Every split is closed (joined) in a join or an end node; 8. The outgoing edges of n∈{NXS ∪NORS} have to be labelled with a condition to describe when this branch is executed; 9. One and only one of the labels for the outgoing edges of a node ∈NXS can be labelled as default, or none of them; 10. For each n∈NT,|S(n)IN|≥0and|S(n)OUT |≥0; 11. For each njand nj+1∈NT,if|OUT(nj))|=1and|IN( nj+1)|=1thenS(nj)OUT = S(nj+1)IN; 2.2 Conceptual data model Variousmodelscanbeusedforthe descriptionofdatamodels.Sincerelationalmodels contain several details about data types and the primary and foreign key relations, we propose the use of conceptual modelling [20] using unified modelling language (UML) [21] (depicted in Fig. 2) to enclose the implementation details. The conceptual model presented in the example describes information regarding the thesis projects, theses, students, Ph.D.s (i.e. supervisors of each thesis, the members of the evaluation committee for each thesis, the substitution committee for the presentation), and the meetings held by the department. The thesis project of a student is the first part of a possible thesis, which is approved for its presentation in a department meeting. Both thesis and thesis project are evaluated and supervised by Ph.D. personnel of the University. 2.3 Data object life cycle modelling BPMN was not originally designed for data modelling, although BPMN 2.0 does include elements that enable the annotation of the process with the involved Data Object elements. The Data Objects can include the State of Data Objects at various points in a process [11]. An activity in a process is able to Consume a Data Object, which implies that the activity might be executed when the Data Object is in a particular state (working as a pre-condition). When the activity is executed, the object might transit to a new state (an object in a new state is Produced), and thereby work as a post-condition. Figure 3represents an example of accessing the data objects related to Activity A. An edge from a data object to an activity describes a read access to an instance of the data object (e.g. Data object X), when the state of the pre-condition is fulfilled. Likewise, an edge from an activity to a data object describes a write access (e.g. Data object W), which either creates a data object instance if it does not Fig. 2 Conceptual model of the example Activity A [new] Data Object W [State Z] Data Object X III [State Y] Data Object W [State U] Activity B Data Object W [State K] Fig. 3 Example of annotation of business process model already exist (labelled with [new] as proposed in [22]), or updates the instance if it already exists. A data flow edge connecting a data object with a sequence flow indicates that the data object is flowing through that connection, and gives the state of the flowing data object (e.g. Data Object W in State U in Fig. 3). Data objects can be modelled as a single object or as a collection of objects (marked by three parallel bars, |||). Only the execution of an activity can imply the creation of a new object, although it is possible to represent different states of an object depending on the executed branch. For example, after the execution of the activity A, an XOR-split is executed, where the data object W in state U flows through the upper branch, or it follows through the lower branch in state K . In order to include the evolution of data states during the process execution, it is necessary to annotate the BPMN model with the object data states, which are supported by BPMN 2.0. The process annotated with the data objects (Thesis and Thesis Project) and their states is shown in Fig. 4. In order to verify the annotated BP Model and the conceptual model, it is necessary to enrich the description capacity of the data object states, and not only use a label that determines the state as analysed in [23]. Each class belonging to the conceptual model is formed of a set of attributes, and a set of allowed values for each attribute. The states are Student Department Apply thesis project Send project documents Finish thesis document Send Thesis documents Present thesis [approved presentation] Study the thesis project Inform studient of project evaluation [denied project] [approved project] Deposit the document Analyse the evaluation committee Hold a department meeting Inform student of thesis evaluation [thesis denied] [new] Thesis [requested Project] Thesis [requested Project] Thesis [evaluated] Thesis [denied Project] Thesis [finished Project] Thesis [approved Project] Thesis [presentation Approved] Thesis [presented] Thesis [presentation Approved] Thesis [denied] Thesis [evaluatedBy Department] Thesis [finished Project] Thesis [endDeposit] Thesis [evaluatedBy Comision] Thesis III [analysed] Thesis [closed] Request the documentation Payment of fees s Thesis [FeesPaid] Fig. 4 Thesis process with data description possible combinations of these values at in different moments of the process instance that must be described. Definition 2 (Class State) Let Cbe a class of the conceptual model with its attributes AC, where each attribute a∈AChas a domain Da.Astate s of Cis defined as a set of tuples of values formed by the attribute of C(AC), in the domain Da. Every possible tuple of s can be sometimes described in a more compact way by means of a constraint Consts.This constraint describes the possible values of the tuples related to the attributes involved in the state description (AConst), where AConst ⊆AC. Constraints in the representation of the states can to be stored in constraint databases [24,25]. The grammar to express constraints corresponds with a propositional formula that consists of atoms and, in addition, the logical operators AND, OR, and NOT [26]. These operators can create a Boolean combination of constraints that relate numerical variables [27], as defined below. In order to illustrate the semantics of the constraints, the constraints that describe the states “requested project” and “approved project” are shown below. However, as shown in Sect. 5.1.2, in order to prevent the users from directly defining constraints, a natural-like language has been also included, to facilitate the description of the data object states. Requested project: NOT title = null AND NOT sendDate = null AND NOT abstract = null AND evaluationDate = null AND reasonOfRejection = null AND supervisor = null Approved project: NOT title = null AND NOT sendDate = null AND NOT abstract = null AND NOT evaluationDate = null AND reasonOfRejection = null numSupervisors > 0 AND numSupervisors < 3 3 Verification of annotated business process models with data states The states of the business data objects can be associated with various activities depending on the workflow of the process model, as explained in Sect. 2.3. In order to verify the correctness of the business process control flow and the data states, we define two properties (i.e. consistency and completeness), analysed in Sects. 3.1 and 3.2. From the point of view of the data objects, it is necessary to analyse the data correctness and ascertain both the state of each data object and whether they satisfy any of the states annotated in the process model, as explained in Sect. 3.3. 3.1 Verification of model correctness Beforeexplainingtheaforementioneddefinitions,certainotherdefinitionsmustbeintroduced regardingthepossiblerelationsallowedbetweenthedata statesandthe activitiesofthemodel. Weusetheconventionthateachstateisrelatedwithonlyoneclass,anddelegatethepossibility of modelling the attributes of different classes in one single state to future work. Depending on the association of the data state with the activities, and the association between the activities themselves, we differentiate between the following relationships between each pair of states: –Two states are exclusive if the constraints that represent each state are not consistent with each other, and therefore an object cannot satisfy the constraints of both states at the same time. This situation occurs if both states are associated with input or output data of activities that have a sequential or exclusive relation (associated with different branches of an XOR gateway). This means that these activities or branches cannot be executed in parallel. For instance, in the example of Fig. 4,[requested]and [evaluated]of Thesis Project and [approved]and [denied]of Thesis are mutually exclusive. –Two states are parallel if the constraints that represent each state are consistent with each other, and therefore an object can satisfy the constraints of both states at the same time. It implies that they are associated with input or output data of the activities that can be executed at the same time. For instance, in the example, [evaluatedByCommission]and [endDeposit]of Thesis are parallel. –One state is a substate of another state (super-state) if an object that satisfies the constraints of the super-state also satisfies the constraint of the substate. The substates are associatedwithoutput data of activities, while thesuper-state isassociatedwith input data of the subsequent activity, and there are no activities between the substates and the superstates. For instance, [analysed]of Thesis is a super-state of both substates [endDeposit] and [evaluatedByCommission]. Based on the concepts above, the definitions for their formalisation are: Definition 3 (Exclusive, Parallel, Substate, Super-State) Let s1and s2be two states that belong to the same class C. State s1is exclusive to s2if there is no tuple tof values of the attributes of class Cthat satisfies the constraint Consts1∧Consts2. State s1is parallel to s2if there is a tuple tof values of the attributes of class Cthat satisfies Consts1∧Consts2. State s1is a substate of s2if the set of tuples that satisfy s1are included in the set of tuples that satisfy s2. If s1is a substate of s2,thens2is called the super-state of s1. Definition 4 (Consistent) Let S(C)be a set of states defined for the class C.SetS(C)is consistent with respect to a process graph N,E(Definition 1), if and only if: – For every pair of task nodes na,nb∈Nof the process graph, where na,nbare either executed sequentially or exclusively (but not in parallel), ∀st1,st2∈{S(na)IN ∪S(na)OUT ∪ S(nb)IN ∪S(nb)OUT },st1and st2are exclusive states. – For every pair of nodes na,nb∈Nof the process graph, where OUT(na)=NPJ i and OUT(nb)=NPJ i(the activities located just before an AND-join), S(na)OUT and S(nb)OUT are parallel states. In an equivalent way, where IN(na)=NPS iand IN(nb)=NPS i(the activities located just after an AND-split), S(na)IN and S(nb)IN are parallel states. – For every pair of nodes na,nb∈Nof the process graph, where OUT(na)=NPi and IN(nb)=NPi(the AND-join or AND-Split is located between two activities), S(na)OUT is a substate of S(nb)IN and S(nb)IN is a super-state of S(na)OUT . 3.2 Verification of the model completeness A data object of the database can take any possible combination of values, which means that the values of their attributes may be very different. If not every combination of attributes is satisfied by a states, then a data object could be in an unknown state. To ascertain if the annotated business process can produce this situation, it is necessary to analyse the property of completeness, as explained below. Definition 5 (Complete) Let S(C)be a set of states defined on class C.SetS(C)is complete if and only if, for each possible tuple of values for the attributes AC, there is at least one state whose constraint is satisfied. 3.3 Verification of data object correctness If an annotated business process is Complete, then it is possible to guarantee that every stored data object satisfies a state. In the opposite way, it is necessary to analyse every data object to ascertain whether it is correct or not. Definition 6 (Correct Data Object) Let cbe an instantiated object of the class C, whereby c is correct if and only if csatisfies at least one state constraint. If csatisfies more than one state, then all of these states must be parallel. When the constraint associated with a state is satisfied for the values of the attributes of a data object, the state of the data object is known. 4.4 Verification of completeness property The completeness of a data object model is satisfied if every possible value of the attributes of a Class corresponds with at least one modelled state. This prevents the existence of a business data object in the database that does not correspond to a modelled state, or to satisfy a constraint that describes an incorrect behaviour. It implies that ∀tuple tof values of a class C,∃a state of Cwhose constraint is satisfied by t. The CSP created to verify the completeness incorporates the negation (¬)ofthe modelled state constraints. If a solution is found for the CSP, it means that the model is not complete since there exists a tuple where no state is satisfiable. For the example, the CSP has the form: ¬Constrequested Project ∧¬Constevaluated ∧¬Constdenied Project ∧¬Constapproved Project ∧¬Const f inished Project ∧¬Constevaluated ByCommision ∧¬Constend Deposit ∧ ¬Constanalysed ∧¬Constevaluated ∧¬Const f eesPaid ∧¬Constapproved Presentation ∧¬Constdenied Presentation ∧¬Constpresented ∧¬Constclose If a solution is found for the CSP, then the model is not consistent for the completeness property. CompletenessStateVerification Algorithm (Algorithm 5) creates and solves the CSP needed to ascertain whether the data model description is complete. The algorithm creates a CSP with an AND Boolean relation (∧) of every constraint of the states of the model for each class (line 2). The input and output constraints are included with a negation (¬) (line 5). If a solution is found, then the model is not complete, according to the completeness consistency property. Algorithm 5 Algorithm to Analyse the property of completeness 1: function CompletenessStateVerification(Graph g) 2: List<Node>allnodes = g.getAllNodes(); List of every node 3: Constraint c = new Constraint(); 4: for n in allnodes do 5: c.and(¬g.getInState(n) ∧¬g.getOutState(n)); 6: end for 7: Solver s = new Solver(c); 8: s.solve(); 9: if s.hasSolution() then 10: Print("The model is NOT correct according to the Completeness Consistency Property"); 11: else 12: Print("The model is correct according to the Completeness Consistency Property"); 13: end if 14: end function 4.5 Data object correctness: discovering the States of stored data objects Although the model of a business process is correct according to its business data states, it is necessary to analyse whether the objects stored in the database are correct with respect to the designed process model. This implies ascertaining whether every stored object is in one of the described states, or, in an equivalent way, whether there is an object that is not in any state. This situation could arise since the objects can follow legacy models or business rules of the past, which are not supported by the current business process model. This analysis ensures that Process Datos database Task A Task B 1 2 3 states …. …. check check Annotated process verification Discovery of Object States associations 5 4 Fig. 5 Steps of the methodology every object is correct or detects the incorrect objects. As mentioned earlier, an object can be in more than one state (parallel states), and hence Algorithm CorrectnessObjectVerification (6) ascertains whether the objects are in at least one state, and either reports the states of the object, or returns NONE otherwise (lines 6 and 7). Algorithm 6 Algorithm to Analyse the property of correctness of the stored Objects 1: function CorrectnessObjectVerification(<Type>DataObject) 2: Iterator iter = session.createQuery("from" + DataObject).iterate(); 3: for iter.hasNext() do 4: <Type>t=(<Type>) iter.next(); 5: t.calculateState(); Method of Figure 6 6: if t.getState()==NONE then 7: Print("The object " + t + " is not in a correct state."); 8: else 9: Print("The object " + t + " has the State " + t.getState()); 10: end if 11: end for 12: end function 5 Methodology and framework for annotated business Process verification and discovery of object states The proposed methodology has been developed with a framework whose implementation details are explained in the following subsections. The methodology devises the steps shown in Fig. 5, which include: 1. To describe the business data objects involved in the business process in accordance with the conceptual model of the database Since the relational model is highly detailed and is difficult to understand and query by non-expert users, we propose the use of a conceptual model managed by means of an object-relational mapping (ORM) to facilitate the description and management of the business data objects. This conceptual model is also employed to describe the data states according to the attributes and associations of the model. This step must be developed by an IT expert since technical knowledge is necessary. 2. To describe the state of each business data object in terms of the value of its attributes In order to bring the experts and the state descriptions closer, it is necessary to provide a natural language to describe why one business data object is in one state or another. Knowledge of the different states of the business object is held by the business experts. Therefore, we have implemented a domain-specific language (sold out in following Subsections) within the business process modeller (ActivitiTM in our proposal) to facilitate the business expert task concerning the data state description. 3. To allocate the data state description in the business process model The importance of our proposal lies in its capacity to combine the data state and the workflow of the model. The third step is based on the location of the data states related to the activities executed at each moment. This enables the specification of which data objects are read, and which states are obtained after an activity execution to be incorporated into the workflow. This step can be developed by a business expert since no technical knowledge is necessary. 4. To verify the model correctness The states of the objects associated with the activities of the model need to be consistent with respect to the workflow. The possible states that an object can satisfy, and where it is read or written must be analysed. Algorithms 4and 5are used in this step to analyse the process model correctness in an automatic way. 5. To discover the stored business objects The model is created to work with the stored business objects. Algorithm 6is used to verify whether every business object satisfies any state. This is an automatic task developed by our system using the ORM framework to be iterated in the objects of the database. 5.1 Framework to support the methodology In order to validate our proposal, a tool that supports the methodology has been developed by usingaset of mature technologies.Notethat this is just oneof manypossible implementations and others with different technologies are also possible. The parts that must be supported include: the data store that contains the involved data objects; the editor to describe the states in a friendly language; the connection between the commercial business process and the stored objects; the implementation of the algorithms to verify the correctness of the model; and the setting for the analysis of every stored object to ascertain the state of each object. An Eclipse (RCP) Rich Client Platform application has been developed to include all these elements in the same environment. 5.1.1 Business data model description: object-relational mapping to represent business data objects Facilitating the state description also implies managing the information represented by means of the conceptual model. It is the object-relational mapping (ORM) that is employed to manage the relational model by means of the conceptual model that represents it. Table 1DSL transformations for the class state grammar {ClassName}{ public class {ClassName}{} static final int {State1}=0 ... @PostLoad @PostUpdate private void calculateState() [{State1}] if(java code transformation) //Boolean combinations of comparisons state = {State1}; ... ... [{StateN}] if(java code transformation) //Boolean combinations of comparisons state = {StateN}; ... ... }} Although most software applications use relational databases to store their data, objectoriented language is employed to manage the information. This implies the mapping from the primary and foreign key relations to an object-oriented paradigm and vice versa. In our case, this introduced the needed for the use of a conceptual model instead of the relational model, whichtendsto be solvedusing dataaccessobject (DAO) patterns. Common dataaccess object (DAO) implementations are provided by object-relational mapping (ORM). ORM [29]isa programming technique for the conversion of data between systems of incompatible types in object-oriented programming languages. The use of ORM brings major benefits, such as database independence, low coupling between business and persistence, and fast software development.HowORM can beused in thiscontextand howtheexampleshould beannotated is detailed in [23]. 5.1.2 Business data state description: a natural-like language to describe the data object states In order to describe the Class State following the grammar presented above, we have created a domain-specific language (DSL) to help the business expert in the description of the data states. The proposed DSL follows the grammar below: list−Of−Classes := Class list−Of−Classes |Class Class := ’{’ClassName’}’{’list−Of−States’}’ list−Of−States := State list−Of−States |State State := ’#’[StateName]Constraint Several examples of how the sentences of the language are transformed automatically into Java code are shown in Table 1.TheConstraint term of the grammar corresponds to the Constraint grammar described in Definition 2(Class State). However, in order to provide a natural-like language, a set of natural expressions are created to refer to the tokens PREDICATE and FUNCTION-SYMBOL, as described in Table 2. Table 2 DSL pattern transformation for the Constraint Grammar Token DSL pattern Java code pattern Example = null {attribute} IS EMPTY get{Attribute}()==null presentationDate is empty <> null {attribute} IS NOT EMPTY get{Attribute}()!=null presentationDate is not empty Count THE NUMBER OF {attributeSet} get{AttributeSet}().size() the number of eva- =IS {number} =={number} luation comittee is 5 Count THE NUMBER OF {attributeSet} get{AttributeSet}().size() the number of eva- <> IS DIFFERENT TO {number} !={number} luation committee is different to 5 ={attribute} IS EQUAL TO get{Attribute}() Mark is equal {value} =={value} to ’FAIL’ <> {attribute} IS DIFFERENT TO get{Attribute}()!={value} Qualification is {value} different to ’PASS’ <{attribute} IS LESS THAN get{Attribute}()<{value} DepositDate is {value} less than currentDay ≤{attribute} IS LESS THAN OR get{Attribute}()<={value} DepositDate is less than EQUAL TO {value} or equal to currentDay >{attribute} IS GREATER THAN get{Attribute}()>{value} EvaluationDate is {value} greater than sendDay ≥{attribute} IS GREATER THAN get{Attribute}()>={value} EvaluationDate is OR EQUAL TO {value} greater than or equal to sendDay null null null Thesis{ #[RequestedProject] Title is not empty AND sentDate is not empty AND Abstract is not empty AND Evaluaonme is empty AND reasonOfRejecon is empty AND the number of supervisors is 1 or the number of supersivors is 2 #[ApprovedProject] Title is not empty and sentDate is not empty AND Abstract is not empty AND Evaluaonme is not empty AND ReasonOfRejecon is empty #[DeniedProject] Title is not empty and sentDate is not empty AND Abstract is not empty AND Evaluaonme is not empty AND ReasonOfRejecon is not empty } @Enty public class Thesis{ stac fin al int REQUESTEDP ROJECT = 0; ….. @PostLoad @PostUpdate private void calculateState(){ if(getTitle()!=null && getsentDate()!=null && getAbstract()!=null && getEvaluaonme()==null && getReasonOfRejecon()==null && (getSupervisors().size==1 || getSupervisors().size==2)){ state=CREATED; } if(getTitle()!=null && getsentDate()!=null && getAbstract()!=null && getEvaluaonme()!=null && getReasonOfRejecon()==null){ state=APPROVEDPROJECT; } if(getTitle()!=null && getsentDate()!=null && getAbstract()!=null && getEvaluaonme()!=null && getReasonOfRejecon()!=null){ state=DENIEDPROJECT; } } Fig. 6 Example of mapping between the DSL and Java code As mentioned earlier, it is not always possible to link the state of the data object as a string within a column of the corresponding table in the legacy database. Moreover, the state is a characteristic of the object, and it is not mandatory to be stored as one of the stored attributes. For this reason, the state is presented as the attribute @Transient of the mapping classes. The attributes annotated with @Transient represent those that are part of the entity but are not required to be persistent, since they do not belong to the database. When the object is loaded with the information of the database or updated by means of the setting methods, the state needs to be updated in terms of the values of the remaining attributes. In Hibernate, there exist call-back methods that should be prefixed by annotations that dictate when these methods have to be executed. Since the change of the state occurs when the object is loaded or updated, @PostUpdate and @PostLoad annotations are used. Those two annotations represent, respectively, that the method calculateState() must be invoked for an entity after a constructor or that the update operation is executed. How the states are represented in the Java code and how the annotation the classes of the ORM framework are annotated are detailed in [23]. 5.1.3 DSL transformation into Java code The transformation of this description into executable code is also necessary to enable the automatic evaluation of the model and the validation of every object of the database to find the states at each moment. In Fig. 6, a transformation is shown from a description of the states of the Thesis class (RequestedProject, ApprovedProject, DeniedProject...), to the Java code included automatically into the ORM classes. When an object is loaded or updated, the state of the data object is updated, and therefore the activity that is being executed for each data object can be ascertained. The DSL patterns can be combined by means of Boolean connectors (AND, OR, NOT) to create states with greater complexity. Project Business Data States Description BPMN annotatted with data states Elements to create the BPMN Fig. 7 ActivitiTM extension view for BP annotation 5.2 Annotate the business process model with data states: implementation of a tool to support the proposal In order to integrate every part of the model into a same environment, an implementation has been developed as an extension of ActivitiTM [30]. ActivitiTM is a light-weight workflow and Business Process Management Platform targeted at business people, developers, and system administrations. This is an open-source distribution that offers the business expert a friendly interface to model the process using BPMN elements. Since the data state description and management is not included in Activiti, an extension of Eclipse IDE-based Activiti Designer has been developed to support new graphical elements. Our implemented ActivitiTM framework supports the development of the five steps presented in the methodology. This extension enables modellers to work in two different views: for Information Technology (IT) experts, and for Business Experts (BE). IT experts can include and describe the database connection and the ORM classes to carry out Step 1. The view for the BEs enables, Steps 2 and 3 to be carried out easily. The ORM classes annotated with @BusinessData are involved in the verification and validation processes (Steps 4 and 5). As mentioned earlier, in order to facilitate the description of the states by the BE, we have developed a DSL using xText [31], which is an open-source framework for the development of programming languages and domain-specific languages. To develop this analysis, Java reflection API has been used. Figure 7 shows the components involved in the workflow creation, data states description, and the Hibernate project to incorporate the relational database. Once the states are defined and managed entities have been annotated, xTend is used to derive an aspect for the calculation of the state of managed entities, according to the states defined by the BE with the grammar. Having completed the process modelling, the BE must include the data object states in the model by using the new graphical elements developed to annotate the BPMN (as shown Fig. 8 ActivitiTM extension view for process validation in Fig. 7). Since the ActivitiTM tool is developed by using Graphiti (https://eclipse.org/ graphiti/), then the new elements for the annotation and validation have also been extended by using this framework. 5.3 Verification of the model and data state discovery The verification algorithms presented in previous sections create the aforementioned CSPs, and they are solved by using ChocoTM solver [32], although it is able to be adapted to another solver [33]. The code of Algorithm 6, included automatically in the HibernateTM class for each modelled business data object, analyses every object with the iterator and informs whether any object has no state. This extension includes the classes that contain the code for the verification of model and the data states, as is envisioned in Fig. 8. A set of videos, where the five steps are presented for the example, can be found in http:// www.idea.us.es/data-object-verification/. In summary, the advantages of the implemented tool include: 1. The data object description has been included in ActivitiTM commercial tool, as a BPMN 2.0 extension. 2. The ORM code derived from the data object, described in the first step, has been automatically created to facilitate the tasks of the Information Technology experts. 3. The DSL has been included in the framework using aspect-oriented programming to validate the syntax and semantics of the data states during the business process design. 4. The necessary formalisations for the verification have been included. The automatic verification has been designed by means of a set of algorithms that use the constraint programming paradigm. All these algorithms have been included in the extension of ActivitiTM. 5. The automatic validation has been implemented and included in the extension of ActivitiTM. Table 3Evaluation times Model correctness Number of constraints Number of variables Evaluation time (ms) Consistency Exclusive 379 620 234 Parallel 224 372 3 Substate 141 239 11 5.4 Evaluation time The analysis of the completeness and correctness of the data stored, according to the business process model, can present major difficulties. This involves an off-line analysis, since a swift evaluation is not essential. In this section, the evaluation times of the completeness and consistency of the process model and data, and the state discovery of the data objects are shown. We have used the real example presented in Fig. 4, which has been described for the personnel of the University of Seville according to the normative procedures. The relational database employed to store the objects is that of MySQL. The analysis times for correctness (completeness and consistency) are shown in Table 3.As can be observed, three types of analysis haven been carried out: model consistency (exclusive, parallel, and substate analysis), model completeness and objects correctness. Regarding the model correctness, we have considered it interesting to include the size is of the constraint satisfaction problems created and solved. This size is described by means of the number of constraints that form the CSP and the number of variables. In the case of the analysis of the correctness of the stored objects (Thesis and Thesis Project), the average evaluation time for Thesis objects is 1.58ms, while the average of evaluation time for Thesis Project objects in 1.67 ms. All the measures are presented in milliseconds and have been obtained by using a 2.2 GHz Intel Core i7 processor and 8 GB 1600 MHz DDR3 RAM. 6 Related work Much research in BPM has been devoted to the verification of control flow in process models [34–36] in order to detect logical errors before the models are deployed in a workflow engine. This research has been extended to deal with the analysis of process models that contain both control flow and data flow [12,37,38]. The aim of such analysis is to detect logical errors resulting from inconsistencies between control flow and data flow. The errors identified are at a conceptual level; implementation issues are disregarded in these studies. Moreover, the process models use variables rather than data object states. Consequently, the data is represented implicitly, using pre- and post-conditions. Process models expressed in industrial languages, such as BPMN [7] and UML activity diagrams [39], can use object states. Such process models can contain different states for the same object. These different states implicitly specify the life cycle of that object. The life cycle can be explicitly specified with state machines [39]. Reggio et al. [40]defineamore precise version of UML activity diagrams with object states and they empirically validate the level of comprehension. However, these authors fail to consider data persistence, and hence no integration with databases is discussed. Several papers study how to derive process models from existing object life cycles [41,42], while other papers study how to derive object life cycles from such process models [43– 45]. Meyer and Weske [16,46] discuss the relations between object life cycles and process models. None of these papers consider verification aspects. Instead, they study consistency and transformation between a process model and an object life cycle model that both specify behaviour of the same object. Furthermore, these papers remain at the conceptual level and fail to discuss data persistence and, therefore, the relation with databases. Cruz et al. [47] define an approach to derive a data model from a BPMN model. The data model does not address different states of the same objects. Moreover, data persistence is not addressed. While none of these papers considers data persistence, a recent paper [22] proposes an extension of BPMN data objects to facilitate an integration with SQL databases. These authors add annotations to data object states to manage data dependencies and differentiate between instances. These annotations are sometimes very low-level representations (e.g. primary key and foreign key) that have significance only at the database level, not at the conceptual business level. Therefore these annotations are difficult to understand for business stakeholders. Moreover, each state of a data object in the BPMN model is represented by a simple string, which has limited semantic value. In order to increase the semantic value in our proposal, the states are represented by constraints. More importantly, Meyer et al. [22] advocate a top-down design approach, where data persistence is handled in the last stage. Our approach is, in fact, bottom-up, since the data object definitions are derived from the legacy database, which already exists before the process model has been specified. In a similar top-down fashion, [48] proposes a specific view as a solution for the problem of accessing data of business processes. The data access object (DAO) repository view offers a fast and efficient management of DAOs. In follow-up work [49], the authors have proposed using data access services (DAS) instead of DAOs for the data access. Although these studies are very interesting, their objectives are related to the design of an efficient solution for managing data into processes, whereas we study how to integrate legacy databases in processes; therefore data management is already handled by the legacy databases. In [17], the necessity of including the data stored in the persistent layer is detected and modelled, but the solution is not object-oriented, and it does not support the model and data verification. The stored data verification is studied in [27], and the detection of possible faults and the diagnosis of the incorrect data are developed at run-time. The main difference with the current proposal is that the model and data verification is not performed, and the necessity to include the legacy databases in the validation process is omitted. Since the incorporation of data aspects in process models has drawn great interest in research, several advanced modelling techniques have been proposed to describe processes anddatainanintegratedfashion[50]. Important examples include artefacts-centric BPM [51,52] and data-driven BPM [53]. The verification of artefacts-centric models has been studied in the previous work [14,54,55]. The orientations towards the artefacts-centric proposal fail in the disconnection between the activities of the BPMN and the change of states described in the artefacts, since these proposals advocate different modelling techniques to that of BPMN. However, these modelling approaches have yet to be adopted widely in industry, in contrast to BPMN. Our proposal leverages the use of BPMN for the specification of processes supported by legacy databases. Sun et al. [56] propose a formal approach for the integration of artefacts-centric process models with databases. These authors focus on specifying data mappings between models at both levels and on analysing different properties. The main difference with our approach is that we verify the data state according to the workflow structure, while their approach is based on the comparison between different instances.