Optimized Time Management for Declarative Workflows

Optimized Time Management for Declarative Workflows Irene Barba1, Andreas Lanz2, Barbara Weber3, Manfred Reichert2, and Carmelo Del Valle1 1Departamento de Lenguajes y Sistemas Inform´aticos, University of Seville, Spain { irenebr,carmelo } @us.es 2Institute of Databases and Information Systems, Ulm University, Germany { Andreas.Lanz,Manfred.Reichert } @uni-ulm.de 3Department of Computer Science, University of Innsbruck, Austria [email protected] Abstract. Declarative process models are increasingly used since they fit better with the nature of flexible process-aware information systems and the requirements of the stakeholders involved. When managing business processes, in addition, support for representing time and reasoning about it becomes crucial. Given a declarative process model, users may choose among different ways to execute it, i.e., there exist numerous possible enactment plans, each one presenting specific values for the given objective functions (e.g., overall completion time). This paper suggests a method for generating optimized enactment plans (e.g., plans minimizing overall completion time) from declarative process models with explicit temporal constraints. The latter covers a number of well-known workflow time patterns. The generated plans can be used for different purposes like providing personal schedules to users, facilitating early detection of critical situations, or predicting execution times for process activities. The proposed approach is applied to a range of test models of varying complexity. Although the optimization of process execution is a highly constrained problem, results indicate that our approach produces a satisfactory number of suitable solutions, i.e., solutions optimal in many cases. Keywords: declarative models, temporal constraints, constraint programming, planning, scheduling, clinical guidelines. 1 Introduction Nowadays, there exists a growing interest in aligning information systems (IS) in a process-oriented way and in managing the supported processes effectively. Typically, processes are specified in an imperative way. However, declarative process models have been increasingly used allowing their users to specify what has to be done instead of how [24]. Given a declarative process model, users may choose among numerous ways to execute this model, i.e., there exist many different enactment plans for a given declarative model, each one presenting specific values for relevant objective functions (e.g., overall completion time or costs). REWDLQV &RQVWUDLQW EDVHG$SSURDFK 3HUVRQDO6FKHGXOHU 'HWHFWLRQRIFULWLFDO VLWXDWLRQV 7LPH3UHGLFWLRQ 2SWLPL]HG ([HFXWLRQ3ODQV 2SWLPL]HG ([HFXWLRQ3ODQV 2SWLPL]HG (QDFWPHQW3ODQV 7&RQ'HF5 6SHFLILFDWLRQ 7HPSRUDO &RQVWUDLQWV &RQ'HF5 6SHFLILFDWLRQ 3URFHVV ,QIRUPDWLRQ  Fig. 1. Overview of our approach Moreover, formal specification and operational support of temporal constraints constitute fundamental challenges for any process-aware information system. In [16], we presented a set of workflow time patterns for the systematic evaluation and comparison of workflow metamodelsand tools supporting temporal aspects. These time patterns are based on empirical evidence we gained from several case studies. For supporting users working on declarative workflows with explicit temporal constraints, this paper suggests a method for generating optimized enactment plans. That is, generating plans fixing the start and end times of the activities and resources used from declarative models, while considering resources and temporal constraints. In particular, generated plans aim at optimizing given objectives (e.g., minimizing overall completion time). We built upon the work presented in [3] where we proposed an extension of the declarative language ConDec [24], named ConDec-R. This includes capabilities for reasoning about resources and parallel execution of non-preemptive activities with known duration. Moreover,we proposed an approach for generating optimized enactment plans based on ConDec-R specifications. This paper significantly extends this work by additionally supporting selected time patterns [16], i.e., temporal ConDec-R (TCondec-R) specifications are considered. Hence, higher expressiveness can be achieved and more realistic problems managed. Figure 1 provides an overview of our approach. Taking process information as a starting point, the TConDec-R specification is defined. From this specification, optimized enactment plans can be automatically generated. For this, activities to be executed are selected and ordered (planning problem [14]), considering the control-flow as well as the temporal constraints imposed by the constraint-based specification. Furthermore, as stated, the generation of enactment plans related to a declarative model requires that both the temporal and the resource perspectives are considered (scheduling problem [7]). For planning and scheduling (P&S) the activities in a way optimizing the objective function, a constraint-based approach is used. The generated plans can improve process support and be used for different purposes: (i) providing users with a personal schedule, allowing them to improve their performance regarding activity executions [11], (ii) facilitating early detection of critical situations through early notifications and escalations, and (iii) predicting execution times for future activities, which allows users to make informed decisions [31]. In summary, the main contributions of this paper are: (1) an extension of the approach presented in [3] (i.e., generating optimized enactment plans from ConDec-R specifications) by providing improved expressiveness through complex temporal constraints [16], and (2) the application of the proposed approach to a range of test models of varying complexity. Section 2 introduces an application example that emphasizes the need for our approach. Section 3 gives backgrounds on related research areas. Section 4 details the TConDec-R language and Section 5 shows how optimized plans can be generated. Section 6 deals with the evaluation, while Section 7 presents a critical discussion. Section 8 summarizes related work and Section 9 concludes the paper. 2 Application Example To motivate the need for our approach we consider computer support for clinical guidelines. Clinical processes require the cooperation of different organizational units and medical disciplines [18]. In this context, clinical guidelines have been suggested for different medical disciplines to assist physicians in deciding about appropriate medical treatment for their patients under specific clinical circumstances [12]. Overall goal is to improve the quality of patient care and to reduce costs. Capturing respective clinical knowledge and incorporating it in clinical guidelines can potentially increase the effectiveness of patient treatment processes [18,22]. In such an environment optimal process supportbecomes crucial. Traditional languages for modelling clinical computerinterpretable guidelines (CIGs) are of imperative nature [23,30], which usually results in complex process models for which all possible treatment scenarios need to be pre-specified. Moreover, imperative languages usually present limited capabilities to provide flexibility for modelling and executing clinical guidelines [22,21,26]. This constitutes a barrier for applying process management to healthcare since the state of patients usually cannot be predicted, and hence the exactly required treatment (or sequence of diagnostic and therapeutic procedures) is not known a-priori. To increase flexibility and to reduce complexity of clinical process models, declarative CIG models [22,21] have been increasingly used to better fit with the nature of process-aware clinical IS and the requirements of the involved stakeholders [20]. In addition, temporal constraints play a fundamental role in the context of clinical guidelines [29,9,2,8]. For example, for most therapeutic procedures, the execution of related activities has to obey temporal constraints concerning activity orders, activity durations, and the temporal time lags between activities. In turn, in other scenarios (e.g., drug administration), activities have to be repeated periodically. Moreover, there are implicit temporal constraints that can be derived from the control-flow of a process model (e.g., synchronization), or from the scheduling constraints of a CIG. CIGs are usually modelled by hypothesizing their application in an environment providing all required resources; guidelines are developed at an abstract level without focusing on a specific execution context [18,20]. This way, executing a CIG model requires that temporal constraints and the resource perspective are considered, i.e., reasoning about resource needs and availability is required. Moreover, given a declarative CIG model, clinical staff may choose among numerous ways to execute such model. The selection of an appropriate enactment plan, however, can be quite challenging since performance goals of the process should be considered and resource capacities be taken into account. As stated, the proposed approach considers declarative models with explicit temporal constraints and resource reasoning, and hence, it is suitable for managing CIGs. However, our approach is not restricted to clinical environments, but can also be applied to other domains where processes are rather flexible and where temporal constraints play an important role (e.g., automotive industry and flight planning [16]). 3 Background To automatically generate optimized enactment plans from constraint-based specifications (cf. Section 3.1), the areas of constraint programming, planning, and scheduling (cf. Section 3.2) are combined in this work. 3.1 Constraint-Based Process Models In our proposalwe use the declarative language ConDec [25,24] as basis for the controlflow specification. We consider ConDec to be a suitable language, since it allows specifying process activities together with the constraints to be satisfied for correct process enactment and for achieving the specified goal. Moreover, ConDec allows specifying a wide set of process models in a simple and flexible way. ConDec-R extends ConDec with estimates and resources [3]. Definition 1. Aconstraint-based process model S=(Acts,CBP,R)consists of a set of activities Acts, a set of constraints CBP, and a set R of available resources. For each activity a ∈Acts, resource constraints can be specified by associating the role of the required resource with that activity. The activities of a constraint-based process model can be executed arbitrarily often if not restricted by any constraint. ConDec templates [24] constitute parameterized graphical representations of high-level constraints between activities which can be divided into the following categories: 1. Existence Constraints: unary relationships concerning the number of times an activity is executed. As example, Exactly(N,A) specifies that Amust be executed exactly Ntimes. 2. Relation Constraints: positive binary relationships used to establish what should be executed. As example, Precedence(A,B) specifies that Bmay only be executed if Ais executed beforehand. 3. Negation Constraints: negative binary relationships used to forbid the execution of activities in specific situations. As example, NotCoexistence(A,B) specifies that if Bis executed Acannot be executed, and vice versa. Usually, several ways to execute constraint-based process models exist, i.e., there are different ways to execute a constraint-based process model while fulfilling all constraints. The different valid execution alternatives, however, can vary greatly in respect to their quality, i.e., in how well different performance objectives can be achieved. Thus, we propose to automatically generate optimized execution plans for a constraint-based model. We accomplish this by applying constraint programming for P&S the process activities (cf. Section 5). 3.2 Scheduling, Planning and Constraint Programming The area of scheduling [7] includes problems for which it becomes necessary to determine an enactment plan for a set of activities related by temporal constraints. Moreover, the execution of activities requires resources, hence these activities may compete for limited resources. In general, the goal in scheduling is to find a feasible plan satisfying both temporal and resource constraints. Usually, several objective functions are considered for optimization, e.g., minimization of completion time. In a wider perspective, in AI planning [14], the activities to be executed are not established a priori, hence it becomes necessary to select them from a set of alternatives and to establish an ordering. Constraint programming(CP) [27] has been successfully used for P&S purpose [28]. To solve a problem through CP, it needs to be modelled as a constraint satisfaction problem (CSP). Definition 2. ACSP P=(V,D,CCSP)is composed out of a set of variables V, a set of domains of values D for all variables, and a set of constraints CCSP between variables, such that each constraint represents a relation between a subset of variables and specifies the allowed combinations of values for these variables. A solution to a CSP consists of assigning values to CSP variables, such that the assignments satisfy all the constraints. Further, in CP, global constraints, i.e., constraints capturing a relation between a non-fixednumber of variables, can be defined to improve the modelling of the problems. Similar to CSPs, constraint optimization problems (COPs, cf. Def. 3) require solutions that optimize certain objective functions. Definition 3. ACOP Po=(V,D,CCSP,o)is a CSP including an objective function o to be optimized. Several mechanisms are available for solving CSPs and COPs, e.g., complete search algorithms, i.e., performing a complete exploration of a search space which is based on all possible combinations of assignments of values to the CSP variables. Regardless of the used search method, the global constraints can be implemented through filtering rules (i.e., rules responsible for removing values which do not belong to any solution) to efficiently handle the constraints in the search for solutions. 4 TConDec-R: Temporal Constraint-Based Process Language To schedule process activities when generating optimized enactment plans, ConDec-R is used (cf. Section 3.1). As motivated, we extend ConDec-R to TConDec-R (cf. Def. 4) by including templates related to selected time patterns[16]:1pattern TP1 (Time Lags between Two Activities) enables the definition of different kinds of time lags between two activities; pattern TP2 (Durations) allows specifying the duration of process elements; pattern TP4 (Fixed Date Element) provides support for specifying a deadline; 1Since events are not specified in the considered constraint-based language, in this approach, unlike in [16], only time patterns over activities are considered. pattern TP5 (Schedule Restricted Element) allows restricting the execution of a particular element by a schedule; pattern TP6 (Time Based Restrictions) allows restricting the number of times a particular process element can be executed within a predefined time frame; pattern TP7 (Validity Period) allows restricting the lifetime of a process element to a given validity period; pattern TP8 (Time Dependent Variability) allows varying control-flow depending on the execution time or time lags between activities/events; pattern TP9 (Cyclic Elements) allows specifying cyclic elements which are performed iteratively considering time lags between cycles; and pattern TP10 (Periodicity) allows specifying periodically recurring process elements according to an explicit periodicity rule (for a description of the complete set of time patterns, see [16]). Moreover, for every TConDec-R temporal template all the relations which are stated in Allen’s interval algebra [1] (i.e., start-start, start-end, end-start, and end-end) can be specified. Definition 4. ATConDec-R process model TCR=(Acts,CT,R)is a constraint-based process model S =(Acts,CBP,R),C BP ⊆CT,inwhichC Tincludes temporal constraints. As example, Fig. 2(a) shows a simple TConDec-R model representing the therapy of a patient: (1) Acts is composed out of two activities: A, which has an estimated duration of 2h and requires a resource with role R0, and B, which has an estimated duration of 4h and requires a resource with role R1; (2) CTis composed out of the following constraints: a) Exactly(3,A), meaning that Amust be executed exactly three times, b) Exactly(2,B), expressing that Bmust be executed exactly twice, c) DailyScheduleStart(A,[8am,10am]), meaning that each execution of Amust be started between 8 am and 10 am (specific case for TP5), d) CyclicStart −Start(B,[12h,48h]), meaning that between the start of two executions of Bthere must be at least 12h and at most 48h (specific case for TP9), and e) PrecedenceEnd −Start(A,B,[2h,4h]), meaning that there must be a time lag of at least 2h and at most 4h between the end of any execution of Aand the start time of the first execution of B(specific case for TP1); and (3) Ris composed out of {[R0,1],[R1,1]}, which means that there is 1 resource with role R0, and 1 resource with role R1. In this example, all activities may be only executed between 8am and 4pm (specific case for TP5). 5 From TConDec-R to Optimized Enactment Plans Activities and constraints are specified in a TConDec-R model. Thereby, several ways to execute this model might exist. Each of these execution alternatives leads to specific values of the objective function, i.e., the overall completion time, to be optimized. To generate optimized execution plans for a specific TConDec-R model, a constraint-based approach for P&S the process activities is proposed. This constraint-based approach includes the modelling of the declarative workflow as COP (cf. Def. 3, Section 5.1), the use of global constraints implemented through filtering rules (cf. Section 5.2), and search algorithms for solving the COP (cf. Section 5.3). 5.1 COP Model for TConDec-R Specifications As first step, the TCondec-R model needs to be represented as CSP. Regarding the CSP model, recurring process activities (repeated activities, cf. Def. 5), which may be executed arbitrarily often if not restricted by any constraint, are modelled as sequence of CSP Variables //For each repeated activity nt(A), nt(B) //For each scheduling activity //1st sched. activity for A st(A1),et(A1),res(A1),sel(A1) //2nd sched. activity for A st(A2),et(A2),res(A2),sel(A2) //3rd sched. activity for A st(A3),et(A3),res(A3),sel(A3) //1st sched. activity for B st(B1),et(B1),res(B1),sel(B1) //2nd sched. activity for B st(B2),et(B2),res(B2),sel(B2) //Function to Optimize OCT CSP Constraints //A specific execution of a repeated activity precedes the next execution of the same activity et(A1) <= st(A2) et(A2) <= st(A3) et(B1) <= st(B2) //nt is directly related to the sel variables of the associated sched. activities sel(A1) == nt(A) >= 1 sel(A2) == nt(A) >= 2 sel(A3) == nt(A) >= 3 sel(B1) == nt(B) >= 1 sel(B2) == nt(B) >= 2 //GLOBAL CONSTRAINST Exactly(3,A) Exactly(2,B) SchedStart(A,[8am,10am]) CyclicStartStart(B,[12,48]) PrecedenceEndStart (A, B,[2h,4h]) SchedEnd(A,[8am,16pm]) SchedStart(B,[8am,16pm]) SchedEnd(B,[8am,16pm]) b. Constraint-based Approach a. TConDec-R Specification Resource Availabilities R0: 1 R1: 1 B 2 75 6 12 11 10 84 2 1 93 Cyclic Start-Start [12h,48h] (TP9) A 3 2h R0 75 6 12 11 10 84 2 1 93 Daily Schedule Start [8am,10am] (TP5) Precedence End-Start [2h,4h](TP1) Control-flow Specification 4h R1 75 6 12 11 10 84 2 1 93 R00 R10 d. Enactment Plan 8 1012 14 8 1012 14 D1 D2 A1A2A3 B1 16 16 B2 //Number of scheduling activities nt(A)=3, nt(B) = 2 //1st sched. activity for A st(A1)=8(D1);et(A1)=10(D1) res(A1)=R00;sel(A1)=1 //2nd sched. activity for A st(A2)=10(D1);et(A2)=12(D1) res(A2)=R00;sel(A2)=1 //3rd sched. activity for A st(A3)=8(D2);et(A3)=10 (D2) res(A3)=R00;sel(A3)=1 //1st sched. activity for B st(B1)=12(D1);et(B1)=16(D1) res(B1)=R10;sel(B1)=1 //2nd sched. activity for B st(B2)=8(D2);et(B2)=12(D2) res(B2)=R10;sel(B2)=1// Function to Optimize OCT= 12(D2) c. CSP Solution Fig. 2. From TConDec-R specification to process enactment plan optional scheduling activities (cf. Def. 6). This is required since each execution of a process activity is consideredas a single activity to be allocated to a specific resource and be temporarily placed in the enactment plan, i.e., stating values for its start and end times. Definition 5. Arepeated activity ra =(dur,role,nt)is a process activity which may be executed several times, i.e., several instances of the same activity may exist in the context of a particular process instance. A repeated activity is described by the estimated duration of the process activity (i.e., dur), the role of the required resource for activity execution (i.e., role), and a CSP variable specifying the number of times the process activity is executed (i.e., nt). For each repeated activity, nt scheduling activities exist, which are added to the CSP problem specification, apart from including a variable nt. Definition 6. Ascheduling activity ai=(st,et,res,sel)represents the i-th execution of a repeated activity a, i.e., a specific process activity instance, where st and et are CSP variables indicating the start/end times of activity execution (each execution of a process activity needs to be temporarily placed in the enactment plan), res is a CSP variable representing the resource used for execution, and sel is a CSP variable indicating whether the activity is selected for execution. Moreover, an additional CSP variable representing the overall completion time (OCT), is included in the CSP model, extending the CSP to a COP (cf. Def. 7). Definition 7. ACOP-TConDec-R problem related to a TConDec-R process model TCR=(Acts,CT,R)(cf. Def. 4) is a COP Po=(V,D,CCSP,o)(cf. Def. 3) where: –The set of variables V is composed out of all CSP variables included in the CSP model plus the CSP variable related to overall completion time (OCT), i.e., V = {nt(a),a∈Acts}∪{st(ai),et(ai),res(ai),sel(ai),i∈[1..nt(a)],a∈Acts}∪OCT. &\FOLF6WDUW6WDUWD>OLOV@LVDGGHG25ERXQGVRIVWDLIRUDQ\LFKDQJHG! IRULQWL L8%QWDL^ 6FKHGXOLQJ$FWLYLW\D DL 6FKHGXOLQJ$FWLYLW\D DL LI/%VWDOL!/%VWD^/%VWD/%VWDOL`/%VWDL! /%VWDLOL LI8%VWD!8%VWDOL^8%VWD8%VWDOL`8%VWDL 8%VWDLOL LI/%VWDOV!/%VWD^/%VWD/%VWDOV`/%VWDL! /%VWDLOV LI8%VWD!8%VWDOV^8%VWD8%VWDOV`8%DL 8%VWDLOV ` Fig. 3. Filtering Rule for the CyclicStartStart Template –The set of constraints CCSP is composed out of the global constraints (implemented by the filtering rules) related to the TConDec-R constraints included inCTtogether with the constraints from the proposed CSP model2, i.e.: •A specific execution of a repeated activity precedes the next execution of the same activity, i.e., ∀i:1≤i<nt(a):et(ai)≤st(ai+1)for each repeated activity a∈Acts. •The nt variable is directly related to the sel variables of the associated scheduling activities, i.e., ∀i:1≤i≤nt(a):sel(ai)=1∧∀i>nt(a):sel(ai)=0for each repeated activity a ∈Acts. •OCT =maxa∈Acts(et(ant(a))). –The set of domains D is composed out of the domains for each variable from V. –The objective function to be optimized is overall completion time, i.e., o =OCT . In this way, the COP model which was proposed for ConDec-R specifications [3] has been extended by including: (1) a new global constraint for each of Allen’s interval algebra relation of each specific case of every supported temporal constraint, i.e., time patterns TP2, TP4, TP5, TP6, TP7, TP8, TP9, and TP10, and (2) a new global constraint for each of Allen’s interval algebra relation of every relation and negation ConDec constraint for allowing the specification of time lags (i.e., time pattern TP1). Moreover, when all process activities may be executed in a specific time frame [li,ls], the constraints DailyScheduleStart(a,[li,ls]) and DailyScheduleEnd(a,[li,ls]) are included for every activity a∈Acts which is not involved in any other schedule constraint (cf. Fig. 2(b)). This is needed since the st and et variables can take any value, e.g., a value corresponding to 4 am, if not restricted by any constraint. Figure 2 also shows the translation from a TConDec-R specification into a CSP so that the CSP variables and constraints are stated as explained in Def. 7 (cf. Fig. 2(b)). 5.2 Filtering Rules For each TConDec-R template our constraint-based proposal includes a related global constraint implemented through a filtering rule. Since we extend ConDec-R3[3] by time patterns, new filtering rules related to these time patterns have been developed, i.e., one 2Resources are implicitly constrained since the solver which is used provides a high-level constraint modelling specific to scheduling which includes the management of shared resources. 3A detailed description of the ConDec-R filtering rules can be found at http://regula.lsi.us.es/MOPlanner/FilteringRules.pdf 'DLO\6FKHGXOH(QGDL>OLOV@LVDGGHG25ERXQGVRIHWDLFKDQJHG! D LI/%HWDLOL^ LQWGD\ /%HWDL LQWQHZ9DOXH GD\OL /%HWDLQHZ9DOXH ` E LI/%HWDL!OV^ LQWGD\ /%HWDL LQWQHZ9DOXH GD\OL /%HWDLQHZ9DOXH ` F LI8%HWDL!OV^ LQWGD\ 8%HWDL LQWQHZ9DOXH GD\OV 8%HWDLQHZ9DOXH ` G LI8%HWDLOL^ LQWGD\ 8%HWDL LQWQHZ9DOXH GD\OV 8%HWDLQHZ9DOXH ` Fig. 4. Filtering Rule for the DailyScheduleEnd Template filtering rule for each new global constraint (cf. Section 5.1). As examples, Fig. 3 and 4 show the filtering rules related to the CyclicStartStart(a,[li,ls]) and DailySchedule− End(a,[li,ls])4global constraints, whereUB(var)and LB(var)represent the upper and lower bounds of the domain of var, respectively. Most of the newly developed filtering rules present a propagation reasoning similar to the one included in the ConDec-R filtering rules, i.e., they basically differ in the consideration of the time lags (see Fig. 3 for an example). However, for the filtering rules related to the schedule templates, it becomes necessary to reason about the day in which the upper and lower bounds of the start and/or end time variables are placed. Specifically, for the filtering rule of Fig. 4, for every activity execution aithe next reasoning is carried out:5a) if the lower bound of et(ai)corresponds to a time of a day dwhich is lower than the time li, then that lower bound is updated to the time li of the day d; b) if the lower bound of et(ai)corresponds to a time of a day dwhich is greater than the time ls, then that lower bound is updated to the time li of the day after d; c) if the upper bound of et(ai)corresponds to a time of adaydwhich is greater than the time ls, then that upper bound is updated to the time ls of the day d; and d) if the upper bound of et(ai)corresponds to a time of a day d which is lower than the time li, then that upper bound is updated to the time ls of the day before d. In this way, the constraints stated in the TConDec-R specification (cf. Def. 4) can be easily included in the CSP model through the related global constraints. Moreover, the related filtering rules increase the efficiency in the search for solutions, since during the search process these filtering rules remove inconsistent values from the domains of the variables. In the CSP model, initial estimates are made for upper and lower bounds of variable domains, and these values are refined during the search process. 5.3 Search Algorithms Once the problem is modelled, several constraint-based mechanisms can be used to obtain the solutions of the COP (cf. Def. 3), i.e., optimized enactment plans (cf. Def. 8). 4Note that since the DailyScheduleEnd(a,[li,ls]) constraint individually affects each activity execution, the filtering mechanism for every scheduling activity is carried out in a separated way to increase the efficiency. In this way, the DailyScheduleEnd(a,[li,ls]) constraint is implemented through the set {DailyScheduleEnd(ai,[li,ls]),i∈[1..nt(a)]}of filtering rules. 5To deal with different time granularities, all the temporal specifications of the TConDec-R model are automatically converted to minutes when generating the CSP. 26. Reichert, M.: What BPM Technology Can Do for Healthcare Process Support. In: Peleg, M., Lavraˇc, N., Combi, C. (eds.) AIME 2011. LNCS, vol. 6747, pp. 2–13. Springer, Heidelberg (2011) 27. Rossi, F., van Beek, P., Walsh, T. (eds.): Handbook of Constraint Programming. Elsevier (2006) 28. Salido, M.A.: Introduction to planning, scheduling and constraint satisfaction. Journal of Intelligent Manufacturing 21(1), 1–4 (2010) 29. Shahar, Y.: A framework for knowledge-based temporal abstraction. Artificial Intelligence 90(1/2), 79–133 (1997) 30. ten Teije, A., Miksch, S., Lucas, P.: Computer-based Medical Guidelines and Protocols: A Primer and Current Trends. IOS Press (2008) 31. van der Aalst, W.M.P., Schonenberg, M.H., Song, M.: Time prediction based on process mining. Information Systems 36(2), 450–475 (2011)