Analysis of structural and behavioural properties of case models. Analyse von Struktur und Verhalten von Case-Modellen

Transcription

1 Analysis of structural and behavioural properties of case models Analyse von Struktur und Verhalten von Case-Modellen Patrick Kuhn Prof. Dr. Mathias Weske Dipl.-Inf. Marcin Hewelt MSc. Sankalita Mandal Lehrstuhl für Business Process Technology Datum der Abgabe: 14. Juli 2016

2

3 Ich erkläre hiermit, dass ich die vorliegende Bachelorarbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Potsdam, 14. Juli 2016 Name

4

5 I hereby affirm that I have written this bachelor s thesis independently, without using any sources other than those stated. Potsdam, 14th Juli 2016 Name

6 Abstract In recent years multiple methods to support flexible and knowledge intensive business processes have been proposed. Fragment based case management is an approach, that decomposes a process model into multiple fragments, which are dynamically combined to reach the process goal. However, this dynamic also introduces a high complexity, hence increasing the probability to make mistakes. In this thesis I will present structural and behavioural properties, which can be used to identify those flaws. These properties are validated using an algorithm to directly create the state space of a case model. Zusammenfassung In den letzten Jahren, wurden mehrere Ansätze entwickelt, die eine flexible und wissensintensive Ausführung von Geschäftsprozessen unterstützen. Fragmentbasiertes Case-Management ist ein Ansatz bei dem Prozessmodelle in kleinere Teile, genannt Fragmente, aufgespalten werden. Diese können dynamisch miteinander kombiniert werden um das Prozessziel zu erreichen. Dieser Ansatz erhöht aber auch die Komplexität der Modelle und damit die Wahrscheinlichkeit Fehler bei der Modellierung zu machen. In dieser Arbeit werde ich Eigenschaften vorstellen, die genutzt werden können um diese Fehler zu finden. Ob ein Case-Modell diese Eigenschaften erfüllt, wird mit einem Algorithmus überprüft, der den kompletten Zustandsraum des Modells erzeugt.

7 Contents 1 Introduction 1 2 Formal Foundations Background Fragment Based Case Management Changes in Chimera Semantics Properties to Validate Static Analysis Control Flow Analysis Data Flow Analysis Behavioural analysis Assumptions Petri Net Conversion State Representation Compute Continuations Building the State Graph Usage of the State Graph Preprocessing and Optimisation Future Use 30 6 Conclusion 32 Quellenverzeichnis 33 List of Figures 1 Fragment Receive Application Fragment Check Application Fragment Save Docu Data Classes Termination Condition and Initial State I

8 II 6 Change Status Conflict Set Example Breadth first search on normal graph Breadth first search on reverse graph Make decision activity Simplified docu fragment Transform input and output sets Complete petri net The lifecycle of an activity State representation vector State space generation algorithm State space excerpt Map from data precondition to activity

9 1 Introduction Methods from business process management are well established in monitoring and optimising process execution. In the recent years multiple challenges to traditional business process management emerged. One of the main problems is that the processes get increasingly complex, making it hard to describe them in static process models. Thus, more flexible approaches have been developed to cope with these problems. While classical approaches are mostly build around the activities that have to be completed, the focus of new methods is more on the data relevant for a process. One of the first approaches proposed to overcome the activity centric approach was Adaptive Case Management, which only takes into account the data concerned with the process. The executed activities do not affect the course of a process. New activities can even be added at run-time. A combination of the activity centric and the data centric paradigm is proposed by the fragment based Case Management (fcm) approach. The core idea behind fcm is to decompose a process into parts, called fragments. A single case is made up from a dynamic combination of fragments, which are related to each other via data dependencies. This allows to express complex processes in a straight forward way. However the power of this notation also introduces a high complexity. The person modelling the case model has to consider an interaction between multiple fragments, that can be executed parallel to each other. This increases the probability to introduce mistakes into the process model. Typical errors include deadlocks, lifelocks and inconsistencies between the data model and the fragments. Finding those errors manually can be very time consuming and costly. While there already exists work on the formalisation of the execution semantics of case models in [4], the analysis of case models still remains an open problem. Thus in this thesis, I will present methods to find flaws in fcm models. However it is still unclear, what properties of a case model indicate possible problems. Therefore, before developing techniques for the analysis of a case model, first characteristics of a flawed case model have to be identified. 1

10 An example process model is introduced, to get a better understanding of the possible problems. The model shows an application process. Goal of this process is to either accept or reject the incoming application. The initial state of the process includes an application data object in the status new. The process can be divided into three fragments. The first fragment Receive Application is started as soon as an application is received. This application will then be entered into the system before formal criteria of the application are checked. If those requirements are not fulfilled, the application will be saved and then rejected. Figure 1: Fragment Receive Application Otherwise an intensive examination of the application will be started in fragment Check Application. Parallel to this an internal documentation is created. If the application is from a foreign country multiple additional checks will be carried out. After this is done, a final decision is made, whether the application will be accepted or rejected. 2

11 Figure 2: Fragment Check Application Parallel to the processing of the application, the Save Docu fragment can be executed. First, the created internal documentation is checked for completeness. After that, the management has to get notified that the documentation was created and the documentation has to be saved. Figure 3: Fragment Save Docu The central data object in this process is the application data class, shown in figure 4. There is a predefined object life cycle, describing the allowed state transitions. This can be seen in figure 6. The terminal states of the application data class are rejected and approved, matching the possible endings of the case. The application contains the name and age of the applicant. Additional to the application itself, there is also a Docu data object. 3

12 The process model contains two mistakes. The first error is a possible deadlock of the process. This is causes by the dependency of Make Decision on the Docu data object in state created. Because the Process Docu fragment can always be started parallel to the rest of the case, the state can be changed to saved before the Make decision activity is finished. After this happened there is no way to change the application to either approved or rejected and the case cannot terminate. The second semantic error is that even if the formal requirements are not fulfilled, the Review Application is already enabled. The second fragment could change the status to examined and the process can go on, even though it should end in a rejected application. While this is not as severe as the deadlock it still could lead to severe problems in the execution of the case model. This error could be identified by comparing the process model to the specified life cycle of the Application data class. The transition from registered to rejected is not allowed, indicating a possible violation of the conformance rules. The thesis is structured as follows. First the formal background of case management will be elaborated in section 2. This includes an overview of differences between the formal fragment based case management approach and the semantics of the platform, in which the analysis algorithms have been implemented. Based on this, properties relevant for case models will be identified. Section 3 will cover techniques for static analysis of control and data flow. This is the foundation for the behavioural analysis of a case model in section 4. This section will discuss an approach to analyse a case model, based on constructing the respective state graph. The last section summarises the findings and points out possible use cases for this approach. 4

13 Figure 4: Data Classes Figure 5: Termination Condition and Initial State Figure 6: Change Status 5

14 2 Formal Foundations 2.1 Background Before creating a method to analyse case models, first the underlying formalism has to be defined properly. In this section I will give a brief overview of the core concepts of fcm, with a focus on the definition of the state of a case. The implementation of the analysis algorithms was done in context of the Chimera engine 1. Therefore I will elaborate the differences between the execution engine and the formal definition of fcm Fragment Based Case Management In fcm, a case model consists of a set of fragments, the domain model and a termination condition. Each fragment itself is a process model, closely related to the semantics of BPMN process models [7]. They consist of control flow nodes and data objects. There are three basic types of control flow nodes: activities, events and gateways. Data nodes are used to specify the input and output of activities. Data objects are the representation of data nodes, created at run-time. The data objects are available across fragment borders. For further reference see [6]. Fragments represent parts of the process, which can be combined to achieve a specific goal. This goal is denoted as termination condition. The termination condition defines in which states the case model can be terminated. It can consist of multiple alternative parts. Each of them specifies a set of data classes and the respective states, which allow termination. The domain model describes the data belonging to the case model. There has to be a data class for each data object, which exists in one of the fragments. In addition to that, each data class has a life cycle associated with it, constraining the possible state transitions of the data objects. In terms of the presented example, the case model would consist of the three fragments Receive Application, Review Application and Save Docu. The termination condition consists of two alternative parts. Either the application data class is in state accepted or rejected. Also the Docu data object has to be in status saved. The domain model shown in figure 4 shows two data classes: Application 1 6

15 and Docu. Both of these data classes have multiple attributes. Particularly important for this thesis is the state of a case. The state of a case is defined as tuple pi, in, cs, valq in [4]. I is the set containing all instances of fragments, activities, gateways, events and data objects. The relation in Ă IxI is used for two different purposes. It maps each activity to its respective fragment and each data object to the activity the data object is bound to. Binding in this case means that the activity works on the data object and it is not available for other activities, until the activity it was bound to terminates or is skipped. The cs function maps each data object to the respective state in its object life cycle. The val function assigns a value to each data attribute Changes in Chimera Semantics The analysis algorithms are implemented in context of the Chimera platform. To make the platform more efficient and user friendly, various changes to the original fmc approach have been made. This section lists those changes and their impact on the analysis. Exclusive Gateways In contrast to BPMN, in the Chimera platform the behaviour of XOR gateways resembles the behaviour of event based gateways. All activities which follow the exclusive gateway are presented as enabled to the user (if the data is in the according state). This can also include multiple intermediate gateways. After the user selected one activity all other branches will be discarded. In case of nested XOR gateways, the gateways are evaluated in order of the control flow. To formalise this behaviour the notion of conflict sets is introduced. One example can be seen in figure 7. There are two branches following the gateway, thus the conflict set for this gateway is ttau, tb, Cuu. Definition 1 (Conflict Set) The conflict set of an exclusive gateway is a set of sets of activities representing the different branches that follow the exclusive gateway. 7

16 Figure 7: Conflict Set Example It is assumed that the sets in the conflict set are disjoint. Formally, let the recursive following relation $ be & txu, if x is an activity rec_cfpxq % ty y P rec_cfpbq for b P Cfpxqu, if x is a gateway Then the conflict set of a gateway g is defined as trec_cfpxqfor x P Cfpgqu Instance semantics changes For efficiency reasons, already terminated instances are no longer part of the set I. Furthermore, activity, gateway and event instances are created when the control flow reaches them, instead of when the case is instantiated. Fragment instances can only affect the case when they have data preconditions. This is currently not supported in the Chimera platform, where fragments are only used as a concept of modelling. As a result, fragment instances are completely left out of the set I. Initial data state The fcm formalism does not allow for initial data objects, present at the case start. However when implementing real world scenarios, this limitation is often impractical. For this reason, Chimera allows multiple starting conditions. A start condition consists of a set of data classes and the states they should be initialised in. In our example case model this would be the Application data class, which gets initialised into the state new. 8

17 To clarify the adjustments of the case definition, we will look at the state of the example case model after executing Enter into system and Check formal requirements. The set of instances I now contains the activity instances for Save application, Prepare examination, Examine intensive and Create internal documentation as well as the data object Application. The activity instances Save application and Prepare examination are in different branches of a conflict set. When one of them is executed the other one is skipped. The cs function at this moment would map from the Application data object to the state registered. The val function would assign values for the name and the age of the application. 2.2 Properties to Validate As the example has shown there can be multiple error sources. Sometimes the errors can be detected by analysing structural properties of a case model. One example would be the violation of the object life cycle constraints. Structural properties can be evaluated on fragment level. Since fragments themselves are BPMN models established criteria can be used for the analysis. The properties considered in this thesis are structural soundness and object life cycle conformance. However, the analysis of structural mistakes is limited, since the combination of fragments is not taken into account. To find more advanced errors, analysis of the behaviour of the complete case and the interaction of the various fragments is necessary. Properties used to check normal process models have to be adapted to fit the new case management approach. The probably best know criteria for verification of process models is soundness. Soundness was defined in [9] on the basis of workflow nets. Workflow nets are Petri nets that fulfil the structural soundness condition. Definition 2 (Petri net) A Petri net is defined as a triple N pp, T, F q where P and T are disjoint finite set of places and transitions and F P pp ˆ T q Y pt ˆ P q is a set of flow relations Definition 3 (Structural Soundness) A Petri net is structural sound if: 1. There is exactly one start and end position, which are the only places with no incoming/outgoing transitions. 9

18 2. Each activity is on a path from start to end Definition 4 (Soundness) A workflow net is sound if the following conditions hold: 1. The terminal state is reachable from each state 2. If the final state is reached there is no other token in the net 3. Each transition can be activated. To apply soundness to case models, some of the conditions have to be adapted. In contrast to workflow nets, there can be multiple states fulfilling the termination condition in a fcm model. This would violate the first condition. To solve this, either an artificial terminal state, which can be reached from the other terminal states can be added or the condition is reformulated to an terminal state is reachable from each state. The condition that each transition can be activated is expressed as: every control node can be enabled. There is no straightforward way to translate the criteria of not having another token in the net at termination. The closest alternative definition would be to require that no control node is enabled or running when the termination condition is met. However this will most likely not be true since fragments can always be restarted. For this reason this criteria is dropped in the following analysis. However, soundness is too rigid in many cases. Thus, there is a less strict criteria called weak soundness [11]. The difference between soundness and weak soundness is that in weak soundness the terminal state does not have to be reachable from every state. Rather there has to be only one execution path from the initial state to a terminal state. Definition 5 (Weak Soundness) A workflow net is weak sound if the following conditions hold: 1. There is a path from the initial state to the terminal state 2. If the final state is reached there is no other token in the net 3. Each transition can be activated. 10

19 3 Static Analysis Flaws in the structural properties of a case model can either be a result of mistakes in the control flow or data flow. To find those mistakes, every fragment will be evaluated separately. While typical validation techniques can not be used for entire case models, each fragment is its own classical process model. This allows the use of already established criteria. For the control flow it is required that it fulfils the structural soundness and the well-formedness property. The data flow is evaluated against the object life cycles specified in the domain model. 3.1 Control Flow Analysis As starting point for further analysis, it has to be ensured that a process model fulfils certain syntactical requirements. Typical violations include nodes that are not correctly connected to the rest of the process model. Moreover there are also properties of a process model that are desirable to make the process more understandable for the modeller. For example the control flow should be used according to best practice in BPMN models. Well-formedness is a characteristic introduced in [4], which covers most of these aspects. In order to be well formed, a fragment has to fulfil the following properties: 1. The first and last node regarding the control flow are unique 2. The last node is an event node 3. The first node is an activity node 4. Activity and event nodes have exactly one predecessor and one successor These syntactic requirements are the basis for analysing semantic control flow flaws. Tasks, which never can contribute to reach the end of a fragment, are one possible indicator for those flaws. To avoid this every node should be on a path from start to end. This characteristic is equal to the previously defined structural soundness. While the syntactic properties can be checked by traversing the graph once, finding out if each node is on a path between start and end is harder to accomplish. This can be seen in figure 8. A simple traversal from start to end would show that each node can be reached from the start. However the nodes D, E, F do not contribute 11

20 Figure 8: Breadth first search on normal graph Figure 9: Breadth first search on reverse graph to the termination of the fragment. To overcome this problem, the graph has to be reversed. Every node is on a path between start and end, if they are reachable via a breadth first search in the normal and reversed graph. 3.2 Data Flow Analysis In this section analysis techniques, based on the data of the case, are discussed. While control flow analysis uncovers modelling errors in the fragments themselves, mistakes in the data usage are a sign of inconsistencies between the guidelines of an organisation and the actually realised processes. On company level, conformance violations can lead to serious security issues. As a result, it is important for the modeller to get feedback when modelling an activity, which is inconsistent with the rules. Those rules often are described as object life cycles. Object life cycles are a well established technique, allowing domain experts to express possible states and state transitions for each data class. Formally an object life cycle is defined as: Definition 6 (Object Life Cycle). An object life cycle L ps, E, s i, S f q consists of a non-empty set of states S, a relation E Ď S ˆ S of state transitions, a start state s i P S and a finite non-empty set of final states S f Ď S. There are additional properties which must be fulfilled in order to be a valid OLC. There can only be one node with no incoming edges and if a node has no outgoing edges it has to be in the set of final nodes. Moreover, it makes sense that from each state it is possible to reach a terminal state. When introducing an artificial final state, which is reachable from the other final states, this can be expressed as 12

21 structural soundness. There are two main metrics to measure the consistency between business process models and object life cycles: life cycle compliance and coverage. Meyer defines a process model to be compliant with a given life cycle, if every state transition in the process has its counterpart in the OLC [8]. Coverage on the other hand, measures if all state transitions of the object life cycle are used by the process model. In case management, data can be manipulated by the activities. To analyse the data modification, first the formal semantics of reading and writing data have to be discussed. Each activity can have multiple incoming and outgoing data nodes. Incoming data nodes represent data dependencies; outgoing data nodes represent written data. It is allowed to have multiple incoming or outgoing data nodes referring to the same data class in different states. Those data nodes represent alternative input conditions or written data objects. The input set of an activity is formally defined in definition 7. The same mechanism can be used to define the output of an activity. Definition 7 (Input set). Let A be an activity and A be the set of incoming data nodes of A. Let class be a function mapping each data node to its data class. Then we define inclasses tclasspnodeq node P Au the set of classes that are used by the activity. The data nodes can be partitioned according to those incoming data classes so that partitioned Ť xpinclassestnode if classpnodeq xu. The input set is then defined as the n-ary Cartesian product of this partitioned set. input Ś XPpartitioned One example can be seen in figure 10. The activity Make decision from the example case model, has three incoming data nodes: Application[examined], Application[checked] and Docu[created]. The partition of this input would be ttdocu[created]u, tapplication[examined], Application[checked]uu. So the input set for this activity is ttdocu[created], Application[checked]u, tdocu[created], Application[examined]uu. The activity can be started if one those input conditions is fulfilled and the activity is control flow enabled. 13

22 Figure 10: Make decision activity Now that the formalism of reading and writing data is specified, the metrics can be applied to the process model. Currently, only the conformance validation is supported. To validate this property the input and output sets of all activities have to be computed. Afterwards all pairs of possible input and output state are created. Those pairs can then be compared to the object life cycle. To be a valid transition, there has to be a edge in the OLC from the input state to the output state. The Reject application activity, which is part of the Receive Application fragment, changes the Application data object from registered to rejected. The described algorithm would identify this violation, which could have led to a further examination of the application, even though it should already be rejected. This allows the modeller to correct the mistake, before the process is executed in practice. 14

23 4 Behavioural analysis While most basic errors can be identified by the static analysis, behavioural anomalies are often harder to spot. In order to identify those behavioural mistakes, the model can be checked for soundness and weak soundness. The method chosen to determine, whether a case model fulfils those properties, is to directly create the state space of the case model. Alternatively, the model could be translated to a Petri net before the state space creation. This would have the advantage that there already exists a lot of work on this topic [10]. However, expressing the state space in terms of case management itself makes it possible to apply it to other aspects than the validation. Those use cases are elaborated in section 5. The direct creation is only applicable under certain conditions stated in section 4.1. The Petri net translation can be used as a preprocessing step, verifying that those assumptions are met. This section is structured as follows. First limiting assumptions for the state space generation are listed. After that, it will described how a case model can be translated to a Petri net, in order to verify those assumptions. The next part will deal with implementation of the state space generation. This is divided into three parts: the representation of the state space, how to compute the next state from a given state, and how to combine those two parts to create the state graph. Afterwards, it will be described how the state graph can be used to validate the properties discussed in 2.2. Furthermore possible optimisations are presented, to make the generation of the state space computationally more efficient, without losing information about the case model. 4.1 Assumptions The central requirement to make state space generation feasible is that there is only a finite number of possible states. There are three possible sources for infinitely many states. 1. The domain of a data attribute can be infinite e.g. Strings 2. There can be infinitely many instances of an activity at the same time 3. There is no upper limit on the amount of data objects in the case 15

24 Decisions based on data attributes are not defined at the moment. This means that attributes have no influence on the control or data flow and can be omitted for the analysis. Since each activity can only be in one fragment, restricting the amount of activity instances is equivalent to fix the number of instances for the same fragment, that can run concurrently to each other. This is guaranteed by only allowing to start a fragment, when there currently is no running instance of it. Boundness of data Controlling whether the amount of data objects has an upper limit is more complicated. This is caused by the data dependencies between the different fragments. Petri nets are the best known model for solving this kind of problems. The core idea of this process is to model each data object as a place in a Petri net and then validate if the amount of tokens on those places is finite for the possible initial states. This problem is known as place boundness problem, describing the question whether the number of tokens at a place p is always smaller than some constant in any reachable state. Karp and Miller introduced an algorithm for computing a finite tree representation (minimal coverability tree) of the potentially infinite state graph [5]. This tree then can be used to decide the boundness problem of a place p. Definition 8 Marked Petri net A marked Petri net is 4-tuple pp, T, F, M 0 q where pp, T, F q is a Petri net and M 0 is the initial marking of the Petri net. A marking is a mapping M : S ą N assigning a number of tokens to each place. Definition 9 k-boundness A place is called k-bound, iff it does not contain more than k tokens in all reachable markings. A marked Petri net is called k-bound if every place is k-bound. 4.2 Petri Net Conversion Problems in the conversion of case models to Petri nets While a conversion formalism mapping BPMN models to Petri nets was described in [2], there is no formal definition of this conversion for the semantics of case 16

25 Figure 11: Simplified docu fragment models. Multiple problems arise from the concepts used in case models. First of all, fragments can be started at any time, run in parallel and be restarted after termination. Moreover the input mechanism presented in section 3.2 has no equivalent construct in Petri nets. Finally the termination of case models differs from the normal process models. To overcome those problems, first the case model is simplified, leaving out parts without influence on the boundness problem. Then activities are represented in a way, that their data input and output can be mapped to a Petri net construct. This makes it possible to create a data layer, which connects the individual fragments. Finally the fragments have to be connected in a way allowing parallel execution and restarting. Simplify case model Before creating a Petri net for the process model, the case model can be simplified by removing parts that do not affect the data of the process model. Activities which do not modify or create new data objects can be stripped from the process model. The control flow has to be adjusted accordingly. After those activities were stripped from the process model, it is possible that there are gateways, which do not have more than one branch. These gateways can be replaced by their only branch or completely omitted. Since it is possible to nest gateways, this process has to be repeated until no further simplifications are possible. An example can be seen in figure

26 Figure 12: Transform input and output sets Represent data To represent the data objects shared between the fragments, there will be one place for each state of every data class defined in the domain model. The possible states are either extracted from an object life cycle or from the data nodes in the fragments themselves. The number of tokens in one place corresponds to the number of data objects, which currently are in the state represented by the place. The places are linked to the transitions representing the activities according to the input set logic. Dissolve input and output sets: The natural idea of representing data in a Petri net would be to create one place for each data object and link them to the transitions representing the activities. However if there are two incoming places for a transition, there has to be a token in both places. There is no equivalent construct in Petri nets, which can describe alternative input places. For this reason input and output sets containing more than one possible combination have to be dissolved. This can be done by constructing an exclusive gateway, where each branch represents one possible combination from input and output objects. The resulting gateway will contain inputset outputset many branches. 18

27 One example is shown in figure 12. The Input set of the make decision activity was ttrequest[created], Application[checked]u, trequest[created], Application[examined]uu. The output set contains the Application either in status accepted or denied resulting in the output set ttapplication[accepted]u, tapplication[denied]uu. Since the input and output set respectively consists of two subsets, the resulting gateway will have four branches. Creating the Petri net from the simplified case model To produce the final Petri net, first each process fragment is converted as described in [2]. An initial place for each fragment is introduced and a transition from a case start place to each of those start places. To allow the restarting of fragments a transition is added, which connects the final place to their initial place. For each alternative part of the termination condition, one transition is added connecting the respective states to an terminal place. After the Petri net has been constructed, the markings for which the boundness analysis has to be performed are determined. Each case start condition corresponds to one initial marking. Since there can be multiple case start conditions, the analysis has to be performed for each initial marking. Figure 13 shows the complete Petri net for the example scenario. The split up Make decision activity is named d1 to d4. The most right place is the terminal place, reachable through the two termination condition transitions. One can see that each fragment has an initial place, which contains a token after the case start transition is triggered. The final place of every fragment are connected to the initial place via a tau transition, in order to allow restarting of fragments. There is only one initial marking, since there is one start condition. This marking would consist of a token in the initial place and one token in the Application[new] place. 4.3 State Representation Before generating the state space, it is necessary to find a representation for an individual state. The representation should be as small as possible, since the state space can potentially be very large. In order to achieve this, the state will be represented as a numerical vector. The 19

28 20 Figure 13: Complete petri net

29 vector consists of one value for each activity, event, data object and some types of gateways. It is assumed that the number of data objects instances per data class is limited to one. However the following analysis can be easily extended for a limit that is larger than one. To represent the state of an activity, the activity life cycle has to considered (figure 14). However not every state of the activity life cycle is relevant for the state representation. One example for a state that does not have to be included is the state of being data flow enabled. This can be directly concluded from the state of the data objects. Moreover, whether an activity terminated or was skipped only is reflected in the control flow of the following control flow nodes. This means that the only states that have to be represented are not enabled, control flow enabled, enabled, running and conflict enabled resulting in the translation table 1. Table 1: Activity translation table Not Enabled Control Flow Enabled Enabled Running Conflict Enabled The same mechanism can be used to represent events. In contrast to activities, events cannot have data input. This means that control flow enablement results in the immediate enablement of the event. In order to represent data objects, first all possible states are extracted from the fragments or the OLC, if present. Data objects are represented as number indicating the current state, where zero means that the data object has not yet been created. Table 2 shows the translation table for the data objects in the example process scenario. Additional to this, it is also important to include binding of data objects to activities. Data objects, which are in in the incoming set of a running activity cannot be used by other activities. Thereby it is not important to which activity the data object is bound. Thus it can be stored as an additional vector containing one or zero symbolising bound and not bound. 21

30 init-df df-enabled canceled dfe dfd skip cfe cancel init skip skip begin terminate initialized skipped enabled running finished cfe skip dfd dfe cf-enabled Figure 14: The lifecycle of an activity Table 2: Data object translation table Application Not Existent New Registered Examined Checked Rejected Approved Docu Not Existent Created Saved In contrast to the other categories of control flow nodes, not every type of gateway has to be included in the representation. For example the result of exclusive split gateways is completely covered by the state of the following nodes, because they all get conflict enabled as described in section The same is true for the parallel split, which simply control flow enables all following control flow nodes. While exclusive joins always enable the following control node when reached, parallel join gateways have to remember the number of times they were control flow enabled. The solution implemented in this thesis is not completely equal to the formal definition given in the BPMN standard. For every parallel join gateway the number of times the gateway was control flow enabled is saved. If this number equals the number of incoming branches the gateway gets triggered. To illustrate the state representation figure 15 shows the state vector of the example scenario after executing the activities Enter into system, Check formal 22

31 Figure 15: State representation vector requirements, Prepare Examination and Create internal docu and beginning the Examine Intensive activity. The vector consists of four parts: activities, data objects, data object bindings and parallel joins. If the example process model would contain events, there would be a fifth part. The parallel join in the Check Application fragment is named G1, whereas the parallel join in the Save Docu fragment is named G2. Since Create internal docu already terminated, one of G1s incoming branches was already triggered, hence its value is one. This also created the Docu data object in state created. The Application data object currently is in state registered, but is not available since it is bound to the started Examine intensive activity. 23

32 4.4 Compute Continuations To construct the state graph, a method to compute the next states based on a current state is needed. This can be accomplished by selecting all activities and events, which currently are in a status that allows a transition and compute the state after performing that transition. Here only the transitions for activities are discussed, since events behave equivalent to activities with no incoming data objects, in the scope of the presented abstraction level. One exception are boundary events, which additionally can cancel the activity they are attached to. The result of a transition depends on the state of the activity and its following control node. According to the activity lifecycle (figure 14), there can be four state transitions: begin, terminate, skip and cancel. When beginning an activity (transition from enabled to running) all data objects in the input set of the activity have to be locked. This also means to recompute the state of all activities, that did rely on those data objects. When an activity is terminated the result depends on the following control node. There can only be one following control node, since the fragments are well formed. The node is control flow enabled, if it is an activity or event. In case the following control node is an exclusive gateway or event based gateway all nodes in the respective conflict set get conflict enabled. Parallel split nodes lead to the control flow enablement of all following nodes. Exclusive joins enable the one successor. When a parallel join is reached, its counter is incremented by one. If the counter equals the number of incoming branches it will be reset to zero and the following control node will be control flow enabled. When starting an activity in the state conflict enabled, all activities from the other branches have to be skipped. To accomplish this, first the preceding gateway is determined. Then the conflict set of this gateway is used to skip all activities, which are in a different branch than the started activity. In case of nested exclusive gateways, the gateways are executed in order of the control flow. A special case occurs, when the started activity has a boundary event attached to it. This event can cause the activity to be cancelled. When this happens, the data 24

33 objects bound to that activity are unlocked. The termination of the boundary event is evaluated separated from the skipped activity. 4.5 Building the State Graph After discussing the representation of the state space and how to compute continuations for a state, the state space generation algorithm can be implemented. A data structure to connect the states has to be chosen. Since the connections of the state space are normally sparse an adjacency list is a good way of storing the state graph [1]. An adjacency list is a map from each node to the following nodes. In this case the graph will only contain the indices of the states, rather than the complete state object to minimise space consumption. The pseudo code for the algorithm is shown in figure 16. A hash table is used to efficiently check whether a state was already visited before. The hash function is implemented as the sum of all numerical elements in the vector. Each hash collision requires to compare a state to all states with equal hash. If too many hash collisions occur, a different hash function needs to be developed, however this is out of scope for this thesis. The algorithm has to be executed for each case start condition, because they result in different initial states. An alternative to that solution would be to introduce an artificial initial state, that is connected to the other initial states. In the implementation the first variant was used. 4.6 Usage of the State Graph After the state graph has been constructed, it is used to verify the formulated criteria. Those can easily be expressed as graph problems. For a process to be weak sound, a state fulfilling the termination condition has to be reachable from each possible start state. This can be checked by doing a breadth first search from each start state, which terminates after one terminal state is found. To be sound, every state without outgoing edges has to fulfil the termination condition. For both 25

34 1 input : c a s e s t a r t 2 output : s t a t e graph as adjacency l i s t 3 begin 4 state_ counter = 0 5 graph = new HashMap<I n t e g e r, L i s t <I n t e g e r >() 6 seen = new HashMap<State, I n t e g e r >() 7 i n i t i a l S t a t e = g e t S t a t e F o r C a s e S t a r t ( c a s e S t a r t ) 8 t o V i s i t = new Queue<State >() 9 t o V i s i t. append ( i n i t i a l S t a t e ) 10 seen [ i n i t i a l _ s t a t e ] = state_counter 11 while not t o V i s i t. isempty ( ) 12 new_state = t o V i s i t. pop ( ) 13 current_ state_ index = seen [ new_state ] 14 next_ states = compute_next_states ( new_state ) 15 foreach s t a t e in next_states : 16 i f not s t a t e in seen : 17 counter += 1 18 seen [ s t a t e ] = counter 19 t o V i s i t. append ( s t a t e ) 20 state_index = seen [ s t a t e ] 21 graph [ current_state_index ]. append ( state_index ) 22 end 23 end return graph 26 end Figure 16: State space generation algorithm 26

35 properties, the graph is traversed to verify that every control flow node can reach the enabled state at least once. Since most gateways are not part of the state representation, their enablement has to be checked during the computation of the continuations. Figure 17 shows an excerpt of the example process model state space. For the purpose of visualization, the state vector is divided into four parts: activities, data objects, data object binding and join gateways. The top left state occurs after the fragment Receive Application has been completed and the review process is finished, except for the Make decision activity. After the Check docu activity is executed, the process reaches a critical point. It is possible to begin the Save docu activity, leading to the deadlock discussed in the introduction. As soon as this happens, all continuations will ultimately end in the same state. The process is stuck in this state and can never reach a state fulfilling the termination condition. This violates the soundness property and would be detected as non final node without outgoing edges. 4.7 Preprocessing and Optimisation The parallel nature of a case model leads to a potentially very large state space. To analyse complex process models, it is necessary to optimise the running time of the state space creation. There are two main approaches to increase efficiency: simplify the process model or make the state space creation itself more efficient. Leaving out unimportant elements To simplify the model, elements not affecting the result of the analysis can be omitted. One example for this is that not all states of an activity are relevant for the analysis. A running activity can always terminate. This means the transition from enabled to running is not necessary and can be replaced by the immediate termination. The compression is not limited to individual control flow nodes. Sequences of nodes can also be compressed, if they do not modify the data state. The reason for this is that the only way fragments can interact with other fragments is via data dependencies. 27

36 28 Figure 17: State space excerpt

37 Figure 18: Map from data precondition to activity Recompute relevant activities The main computational complexity comes from recomputing the data preconditions for every activity in every state. This is not necessary, as only those activities concerned with the changed data objects can change their state. For example when an activity changes the state of the Application data object from registered to examined, only activities that have Application[examined] or Application[registered] in their input set have to be updated. To find those activities efficiently, a map from a tuple of data class and state to the affected activities is created, during the preprocessing step. The map for the example process is shown in figure

38 5 Future Use There are two main use cases for the state space beside the pure validation of case models. Guided execution Visualization of case future Guided execution There are multiple methods, which can help the user during the execution of a case. One possibility is that the user executes a case model, in which not every path reaches a state, that satisfies the termination condition. Such process models can still be very useful, since the criteria that there are no such paths is often too strict. However entering a state, which does not allow a valid termination, is a big problem to the secure execution of a business process. To avoid this, the user himself would need to check if he enters such a state, for every of his actions. This would require an advanced understanding of the process and can be very error prone in large process models. If the state space of the case model is available, the execution engine could warn the user, if a certain action would lead to such a state. However, possible errors are not the only hints that the engine can give to the user. As case management usually is a very goal oriented process, one important question is how to reach a specific state. This problem can be formulated as a graph problem and solved by breadth or depth first search. This concept can even be further advanced, when taking history into consideration. Using average completion times of activities and time until an event occurred the graph can be extended with weights at the edges, indicating the execution time. With this information the most effective way to achieve a goal can be highlighted by using the Dijkstra algorithm [3] on the state graph. Visualisation of case future In complex models it is often not trivial to see what consequences a certain action has on the course of the case. Using behavioural analysis, it is possible to highlight states reachable within a few steps from the current state. This can for example be used to show the user how to reach a state, in which he can modify a certain data 30

39 object. The state vector is also easy to interpret, in order to highlight the current state in the fragments of the case scenario. 31

40 6 Conclusion This thesis presented multiple approaches to find possible flaws in case models. The lack of these analysis techniques has been identified as one problem of fragment based case management by Hewelt et al. in [4]. Multiple possible flaws of a case model have been identified, based on a example use case. Those problems have been used to determine criteria, which indicate whether a process model contains those mistakes. The identified criteria can be divided into structural properties of a case model and properties of its dynamic behaviour. Structural criteria are evaluated on the fragment models themselves. Since the fragments are modelled in BPMN, well established criteria can be reused. In this thesis we require all fragments to be structural sound and well-formed. It was discussed how to implement this check in context of the execution platform Chimera. The other identified structural property was consistency between the fragment models and the data model. Inconsistencies to the conformance rules in an organisation are critical, because they can be a sign of serious security violations. In fcm it is possible to define possible states and state transitions for each data class as object life cycles. This thesis described the implementation of a method checking each fragment for object life cycle conformance. For the analysis of behavioural properties, soundness and weak soundness were used. To decide whether a case model is (weak) sound, an algorithm to generate the state space was developed. This included a representation for a case state and a method to compute possible continuations for those states. The algorithm was based on the assumption that the state space of the process model is finite. To validate this assumption a conversion of case models to Petri nets was described. Finally multiple other use cases for the use of the state graph have been identified. 32