Chapter 6 Declarative Workflow

Transcription

1 Chapter 6 Declarative Workflow Maja Pesic, Helen Schonenberg, and Wil van der Aalst 6.1 Introduction During the design of any information system, it is important to balance between flexibility and support. This is of particular importance when designing process-aware information systems. On the one hand, users want to have support from the system to conduct their daily activities in a more efficient and effective manner. On the other hand, the same users want to have flexibility, that is, the freedom to do whatever they want and without being bothered by the system. Sometimes it is impossible to provide both flexibility and support because of conflicting requirements. The continuous struggle between flexibility and support is illustrated by Fig The right-hand-side of Fig. 6.1 shows the part of the spectrum covered by classical workflow management systems. These systems focus on processes that are repeatedly executed in some predefined manner and are driven by procedural languages. Note that in procedural workflow models there may be alternative paths controlled by (X)OR-splits/joins. However, the basic idea is that the completion of one task triggers other tasks. The YAWL nets described in earlier chapters provide such a procedural language. Although the YAWL language is highly expressive, its token-based semantics is most suitable for repetitive processes with tight control. The left-hand-side of Fig. 6.1 shows the other end of the spectrum. Here processes are less repetitive and the emphasis is on flexibility and user empowerment. Here it is difficult to envision all possible paths and the process is driven by user decisions rather than system decisions. Groupware systems (e.g., enhanced electronic mail, group conferencing systems, etc.) support such processes and focus on supporting human collaboration and co-decision. Groupware systems do not offer support when it comes to ordering and coordination of tasks. Instead, the high degree of flexibility of these systems allows users to control the ordering and coordination of tasks while executing the process (i.e., on the fly ). The trade-off between flexibility and support is an important issue in workflow technology. Despite the many interesting theoretical results and the availability of M. Pesic Eindhoven University of Technology, Eindhoven, the Netherlands m.pesic@tue.nl A.H.M. ter Hofstede et al. (eds.), Modern Business Process Automation, DOI / , c Springer-Verlag Berlin Heidelberg

2 176 M. Pesic high low groupware flexibility support procedural workflow management systems control users system Fig. 6.1 Flexibility vs. support, adapted from [79] innovative research prototypes, few of the research ideas have been adopted in commercial systems. This is the reason why there is a question mark in the middle of Fig This chapter presents a completely new way of looking at workflow support. Instead of a procedural language, we describe a declarative language based on constraints. The basic idea is that anything is allowed and possible unless explicitly forbidden. To implement this idea we use a temporal logic: Linear Temporal Logic (LTL). Although LTL has been around for decades, it has never been made accessible for workflow design. Therefore, we provide a graphical notation and a set of supporting tools. This nicely complements the core engine and design environment of YAWL. Before elaborating on our constraint-based approach, it is important to stress that this is not a silver bullet. In reality, both flexibility and support are needed when it comes to the computer-facilitated execution of processes and the various paradigms offer different advantages. On the one hand, flexibility is needed for unpredictable processes, where users can quickly react to exceptional situations and execute the process in the most appropriate manner. On the other hand, support is needed when it comes to processes that are repeatedly executed in the same manner, in situations that are too complex for humans to handle and where human mistakes must be minimized. For example, the processing of insurance claims, customer orders, tax declarations, etc. can benefit from a high degree of support because cases are repeatedly executed in a similar manner. Thus, an optimal balance between flexibility and support is needed in order to be able to facilitate processes of various kinds. Moreover, in a large process there may be parts that require more flexibility and parts that require more support. Therefore, procedural and flexible workflows should not exclude each other. Instead, arbitrary decompositions of process models developed

3 6 Declarative Workflow 177 A B Z... Fig. 6.2 Decomposing processes using various modeling languages in procedural and declarative languages should be possible. These decompositions can be achieved by the seamless integration of different process engines based on different paradigms. Figure 6.2 illustrates how various processes can be combined in arbitrary decompositions. Instead of being executed as a simple (manual or automatic) unit of work, a task can be decomposed into a process modeled in an arbitrary language. The declarative language based on constraints presented in this chapter can be seen as one of the modeling languages in Fig. 6.2, while the YAWL nets, and worklets (cf. Chap. 11) can be seen as another alternative. The basic language used by YAWL provides excellent support for procedural workflow modeling as it supports most of the workflow patterns (cf. Chap. 2). However, in this chapter we focus on adding flexibility to workflow models. A workflow model specifies the order in which tasks can be executed, that is, possible execution alternatives. An execution alternative is a unique ordering of tasks. More execution alternatives mean more flexibility. There are several ways to increase the flexibility of workflow management systems: 1. Flexibility by design is the ability to specify alternative execution alternatives (task orderings) in the workflow model, such that users can select the most appropriate alternative at runtime for each workflow instance. 2. Flexibility by underspecification is the ability to leave parts of a workflow model unspecified. These parts are later specified during the execution of workflow instances. In this way, parts of the execution alternatives are left unspecified in the workflow model, and are specified later during the execution. 3. Flexibility by change is the ability to modify a workflow model at runtime, such that one or several of the currently running workflow instances are migrated to the new model. Change enables adding one or more execution alternatives during execution of workflow instances. 4. Flexibility by deviation is the ability to deviate at runtime from the execution alternatives specified in the workflow model, without changing the workflow model. Deviation enables users to ignore execution alternatives prescribed by the workflow model by executing an alternative not prescribed in the model. Flexibility of workflow management systems can be increased by using declarative languages for workflow specification. This chapter describes how an optimal balance between flexibility and support can be achieved with declarative workflow management systems that use constraint workflow models. This chapter shows how

4 178 M. Pesic forbidden optional allowed (a) forbidden, optional and allowed in business processes possible control-flow (b) procedural workflow constraints constraints constraints constraints (c) declarative workflow Fig. 6.3 Declarative vs. procedural workflows the constraint-based approach can provide for all types of flexibility listed in the previous paragraph. A concrete implementation that enables creating decompositions of YAWL (e.g., procedural) and declarative models is presented in Chap. 12 of this book. Figure 6.3 illustrates the difference between procedural and declarative process models. Starting point for the declarative constraint-based approach is the observation that only three types of execution alternatives can exist in a process: (1) forbidden alternatives should never occur in practice, (2) optional alternatives are allowed, but should be avoided in most of the cases, and (3) allowed alternatives can be executed without any concerns. This is illustrated in Fig. 6.3a. Procedural workflow models (e.g., YAWL nets) explicitly specify the ordering of tasks, that is, the control-flow of a workflow. In other words, during the execution of the model, it will be possible to execute a process only as explicitly specified in the control-flow, as shown in Fig. 6.3b. Because of the high level of unpredictability of processes, many allowed and optional executions often cannot be anticipated and explicitly included in the control-flow. Therefore, in traditional systems it is not possible to execute a substantial part of all potentially allowed alternatives, that is, users are unnecessarily limited in their work and, hence, these systems lack flexibility by design. Our declarative constraint-based approach to workflow models makes it possible to execute both allowed and optional alternatives in processes. Instead of explicitly specifying the procedure, constraint workflow models are declarative: they specify constraints, that is, rules that should be followed during the execution, as shown in Fig. 6.3c. Moreover, there are two types of constraints: (1) mandatory constraints focus on the forbidden alternatives, and (2) optional constraints specify the optional ones. Constraint-based models are declarative: anything that does not violate mandatory constraints is possible during execution. The declarative nature of

5 6 Declarative Workflow 179 constraint models allows for a wide range of possible execution alternatives, which enhances flexibility. The remainder of this chapter is organized as follows. First, our constraint-based language for workflow specification is presented in Sect This section also discusses the possibility to verify constraint-based models and the ability to define alternative languages and templates. Section 6.3 shows how declarative workflows can be enacted, that is, how to create a runtime environment for execution. The possibility to change models while they are being executed (i.e., the so-called dynamic change) is described in Sect Section 6.5 concludes the chapter, followed by exercises and chapter notes. 6.2 Constraint-based Workflow Specification A constraint-based workflow is defined by the specification of tasks and constraints. In this section, we first show the formal foundation of a constraint specification language. Then we introduce the concept of constraint templates, that is, reusable constructs linking graphical notations to temporal logic. These templates also allow for branching, that is, a construct can be associated to a variable number of tasks. Then we introduce ConDec as an example language. This language is used in the remainder of this chapter. We conclude this section by showing that such models can be verified LTL-based Constraints Various temporal logics have been proposed in the literature: Computational Tree Logic (CTL), Linear Temporal Logic (LTL), etc. All these logics could be used to specify constraints. In this chapter, we focus on Linear Temporal logic LTL. LTL can be used to define properties of traces, for example, after every occurrence of X eventually Y should occur. In the context of workflow models, traces correspond to sequences of tasks. Every trace represents an executed alternative where the tasks in the trace occur exactly in the order in which they appear. Definition 1 (Trace). Let T denote the universe of task identifiers, that is, the set of all tasks. Trace 2 T is a sequence of tasks, where T is the set of all traces composed of zero or more elements of T.Weuse Dht 1 ;t 2 ;:::;t n i to denote a trace consisting of tasks t 1 ;t 2 ;:::;t n. i denotes the ith element of the trace, that is, i D t i. e 2 denotes 9 1i<jj Πi D e. WeuseC to concatenate two traces into a new trace: he 1 ;e 2 ;:::;e n ichf 1 ;f 2 ;:::;f m idhe 1 ;e 2 ;:::;e n ;f 1 ;f 2 ;:::;f m i. The concept of traces will be used to explain the semantics of LTL. However, we first give the syntax of LTL. LTL provides the classical logic operators (:; ^; _; ), and,), and uses several temporal operators (,,, U,andW) that can be used to specify constraints over the sequencing of workflow tasks. Definition 2 defines the syntax of LTL.

6 180 M. Pesic Definition 2 (LTL syntax). Each atomic proposition p is an LTL formula. Using various operators, more complex expressions can be constructed. If ˆ and are LTL formulas, then :ˆ; ˆ _ ; ˆ,andˆU are also LTL formulas. The semantics of these constructs are given in Definition 3. Moreover, the following operators are so-called derived LTL operators. These operators can be expressed in terms of the basic operators. ˆ ^ :.:ˆ _: / ˆ ) :ˆ _ ˆ,.ˆ ) / ^. ) ˆ/ true ˆ _:ˆ false :true ˆ trueuˆ ˆ : :ˆ ˆW.ˆU / _ ˆ LTL formulas can be used to express that (1) ˆ should hold at the next element of the trace (ˆ), (2) ˆ should hold eventually ( ˆ), (3) ˆ should always hold ( ˆ), (4) ˆ should hold until eventually holds (ˆU ), and (5) ˆ should hold until holds, but is not required to hold eventually ( W ˆ). The formal semantics of the basic temporal operators are given in Definition 3. Definition 3 (LTL semantics). Let p be an atomic proposition, D h 1 ; 2 ; 3 ;:::i be a trace. Then p, 1 =p :ˆ, not ˆ ˆ _, ˆ or ˆ,h 2 ; 3 ;:::i ˆ ˆU,9 1i Œh i ; ic1 ; ic2 ;:::i ^8 1j<i Œh j ; j C1 ;:::i ˆ Note that the semantics of the other operators are provided in an indirect manner, for example, ˆ is semantically equivalent to trueuˆ, etc. Figure 6.4 shows some example traces to clarify some of the constructs. Note that LTL is typically defined on infinite traces, but all results for infinite sequences can be mapped onto finite sequences. p p p p p p p p p p σ [1] σ [2] σ [3] σ [4] σ [5] σ [6] σ [7] σ [8] σ [9] σ [1] σ [2] σ [3] σ [4] σ [5] σ [6] σ [7] σ [8] σ[9] (a) always - [] p (b) eventually - <> p p p p p p p p q q q σ [1] σ [2] σ [3] σ [4] σ [5] σ [6] σ [7] σ [8] σ [9] σ [1] σ [2] σ [3] σ [4] σ [5] σ [6] σ [7] σ [8] σ[9] (c) next - O p (d) until - p U q Fig. 6.4 Semantics of some LTL operators

7 6 Declarative Workflow 181 Table 6.1 Formal specification of constraints with LTL LTL formula for Automaton representing Semantics constraint c T c!bill bill s0 bill s1 Task bill must be executed at least once!bill Š.bill/ U s0 s1 Task bill cannot be executed until task is executed The set of possible execution traces satisfying an LTL constraint is defined as follows. Definition 4 (Constraint satisfying traces T c ). Let constraint c be an LTL formula. Then the set of traces satisfying c is defined as T c Df 2 T j cg. In the field of model checking, LTL is extensively used to check whether a system satisfies properties specified by LTL formulae. Using the results from this field, it is possible to generate a nondeterministic finite state automaton that represents exactly all traces that satisfy the LTL formula. For a constraint c, specifiedbyanltlformula, the set of all traces satisfying c (T c ) is exactly the language produced by the automaton generated for this formula using the algorithm of D. Giannakopoulou and K. Havelund. Table 6.1 shows two examples illustrating the general idea. It is not important to understand how the automata are generated; however, to understand our approach it is important to understand that for any LTL constraint a corresponding automaton can be generated. This automaton will be used to enforce constraints, detect violations, and to check the consistency of a specification. Section 6.3 describes how the LTL-based automata can be used for declarative workflow execution. The next example gives the LTL constraints for a process involving tasks such as shipment (i.e., Create Shipment Information Document), bill (i.e., Create Bill of Lading), and (i.e., Arrange Pickup ). In this example, the number of constraints is small and it is not difficult to determine whether a trace satisfies the given constraints, or not. For larger models this is less intuitive. Therefore, the next subsection proposes constraint templates as a graphical way to represent LTL formulas. Example 1 (Constraint satisfying traces). Consider the two constraints described in Table 6.1 for the execution of tasks bill and ; (c 1 ) bill and (c 2 ) Š.bill/ U. Examples of traces satisfying constraints c 1 and c 2 are h; billi c 1 ^ c 2 and h; ; billi c 1 ^ c 2. Traces not satisfying constraints c 1 and c 2 are " c 1 ^ c 2, hi c 1 ^ c 2,andhbill; i c 1 ^ c 2. Note that " c 2.

8 182 M. Pesic Constraint Templates Procedural workflow languages such as YAWL provide constructs such as ANDsplit, AND-join, cancelation region, etc. These constructs aim at supporting frequently needed workflow patterns. For our declarative approach, we also aim at supporting frequently needed patterns to model relationships (constraints) between tasks. However, we aim at different types of patterns, that is, declarative constructs aiming at more flexibility. In principle, LTL offers everything needed to support such patterns. However, because LTL formulas can be difficult to understand by nonexperts, we provide a graphical representation of constraints that hides the associated LTL formulas from users of declarative workflow, in the form of constraint templates. Each template has (1) a name, (2) an LTL formula, and (3) a graphical representation. A constraint inherits the name, graphical representation, and the LTL formula from its template. Figure 6.5 depicts some example constraint templates. The template parameters are depicted by boxes. Templates can be used to create actual constraints for a specific process. In actual constraints, tasks replace template parameters, both in the graphical representation and the associated LTL formula. The existence template is graphically represented with the annotation 1:: above the task. This indicates that A is executed at least once in each instance. The template init.a/can be used to specify that task A must be the first executed task in an instance. Templates response, precedence, andsuccession consider the ordering of tasks. Template response requires that every time task A executes, task B has to be executed afterwards. Note that this is a very relaxed interpretation of the notion of response, because B does not have to execute straight after A, and another A can be existence(a) A init(a) init A alternate precedence(a, B) A B response(a, B) A B not co-existence(a, B) A B precedence(a, B) A B 1 of 4 (A,B,C,D) A 1 of 4 D succession(a, B) A B Where existence.a/ A init.a/ A response.a; B/.A ) B/ precedence.a; B/.:B/WA succession.a; B/ response.a; B/ ^ precedence.a; B/ not co-existence.a; B/ :. A^ B/ 1of 4.A; B; C; D/ A _ B _ C _ D B C Fig. 6.5 Constraint templates

9 6 Declarative Workflow 183 executed between the first A and the subsequent B. The template precedence specifies that task B can be executed only after task A is executed. Just like in the response template, other tasks can be executed between tasks A and B. The combination of the response and precedence templates defines a bi-directional execution order of two tasks and is called succession. In this template, both response and precedence relations have to hold between the tasks A and B. Template alternate precedence strengthens the precedence template: tasks A and B have to alternate. The not coexistence template specifies that tasks A to B cannot both be executed in the same instance. The 1of4template specifies that at least one of the three tasks A, B, C, and D has to be executed, but all four tasks can be executed an arbitrary number of times as long as one of them occurs at least once Branching of Templates The behavior of models containing multiple constraints is given by the conjunction of all constraints. In some cases it might be necessary to specify the disjunction of constraints. This can be done by assigning more than two tasks to one parameter in a template. When a template parameter is replaced by more than one task in a constraint, then we say that this parameter branches. An example of a branched precedence constraint is shown in Fig. 6.6, where parameter A has been replaced by the task bill and parameter B is branched on tasks and. In case of branching, the parameter is replaced (1) by multiple arcs to all branched tasks in the graphical representation and (2) by a disjunction of branched tasks in the LTL formula. The semantics of branching can vary from template to template, depending on the LTL formula of the template. For example, the branched constraint in Fig. 6.6 specifies that each occurrence of bill must be preceded by at least one occurrence of the task or the task. Note that it is possible to branch all parameters, one parameter, or none of the parameters. The number of possible branches in constraints is unlimited. For example, it is possible to branch the parameter B in the response template to N alternatives, as shown in Fig Another way of branching templates are choice templates, which can be used to specify that one must choose between tasks. An example of such a template is the 1of4template (see Fig. 6.5), which is used to specify that at least one of the four given tasks has to be executed An Example Language: ConDec As explained before, we use LTL as a basis to define constraint templates. The template is defined by specifying the corresponding LTL formula and graphical representation. This makes it easy to create various languages, as any collection of constraint templates forms a language. In this chapter, the focus is on the

10 184 M. Pesic ConDec language. ConDec provides more than 20 constraint templates, among which are the ones depicted in Fig ConDec templates are structured into three groups: (1) Existence templates specify how many times or when a task can be executed, for example, init and existence templates; (2) relation templates define some relation between two (or more) tasks, for example, response, precedence, and succession; (3)negation templates define a negative relation between tasks, for example, not coexistence; and (4) choice templates define a choice between tasks, for example, 1of4. Figure 6.7 depicts the relation between constraint templates, constraints, and models for ConDec. At the template abstraction level, templates are defined on a predefined number of abstract parameters (e.g., parameter A and B). When a constraint is specified, the abstract parameter is replaced by a concrete one, for example, in Fig. 6.7 the left precedence constraint concretizes abstract parameter A from the precedence template with concrete parameter bill. A plain constraint is a concretization of the predefined parameters of a constraint template (cf. Fig. 6.6). Each constraint can easily be extended to deal with more parameters than defined by its template by the means of branching. Every ConDec template involves a specific number of tasks. For example, templates existence(a), precedence(a,b), and1 of 4(A,B,C,D) involve one, two, and four tasks, respectively. When a constraint is created based on a template, the constraint will involve as many real tasks as predefined in the template. Templates can be reused to specify different constraints, as shown for the precedence template in Fig Finally, constraints from the ConDec constraint templates can be used to specify ConDec models. GRAPHICAL LTL FORMULA TEMPLATE A B (! A) W B PLAIN CONSTRAINT bill (! bill) W BRANCHED CONSTRAINT bill (! bill) W ( \/ deliver) A1 BRANCHED CONSTRAINT TO MULTIPLE TASKS A2... B (! B) W (A1 \/ A2 \/ \/ AN) AN Fig. 6.6 Branching the response template

11 6 Declarative Workflow 185 TEMPLATES name LTL graphical existence <> A A CONSTRAINTS graphical semantics <> Arrange Delivery Arrange Delivery <> Create Bill of Lading Create Bill of Lading MODELS Arrange Pickup Arrange Delivery Create Shipment Information Document Arrange Delivery Arrange Pickup precedence Create Bill of lading Truck Load Less Than Truck Load Fig. 6.7 ConDec templates, constraints and models Example 2 (Carrier examples in ConDec). Consider, for example, the two highlighted constraints in different models shown in Fig First, model Truck Load contains the constraint specifying that Task Arrange Delivery must be executed at least once. Second, the Less Than Truck Load model contains a constraint specifying that Task Create Bill of Lading must be executed at least once. The first constraint can be specified with formula Arrange Delivery and the second one with a similar formula Create Bill of Lading. Both constraints use the same (existence) template, their LTL specifications are similar: A, but the constraints are specified on different tasks. Instead of having to individually specify formulas for every constraint, constraint templates provide a way to reuse formulas Constraint Workflow Models Constraint workflow models consist of tasks and constraints. Moreover, there are two types of constraints: mandatory constraints represent rules that must be followed during execution, while optional constraints can be. Definition 5 (Constraint model cm). Let T be the universe of all tasks and C be the set of all constraints. A constraint model cm is defined as a triple cm D.T; C M ; C O /,where: T T is a set of tasks in the model C M C is a set of mandatory constraints, where every element c 2 C M is a well-formed LTL formula over T

12 186 M. Pesic C O C is a set of optional constraints, where every element c 2 C O is a wellformed LTL formula over T Note that each mandatory and optional constraint is a well-formed LTL formula over tasks from cm, that is, a constraint cannot involve tasks that are not in the model. During execution, mandatory constraints must be followed. Therefore, the set of traces that satisfy constraint model cm contains all traces that satisfy all mandatory constraints in cm. The conjunction of all mandatory formulas is defined as the mandatory formula of the model. Definition 6 (Mandatory formula f cm ). Let cm 2 U cm be a constraint model where cm D.T; C M ; C O /, then the mandatory formula for model cm is defined as ( true if C M D I f cm D V f 2C M f otherwise: The automaton generated for the mandatory formula (f cm ) of a model cm generates the language T cm, that is, the set of traces that satisfy cm. In the absence of mandatory constraints, all traces over tasks in the model are allowed. Definition 7 (Constraint model satisfying traces). formula for constraint model cm. ( T cm D T if C M D I T f cm otherwise: Let f cm be the mandatory Furthermore, we say a trace 2 T satisfies model cm, if and only if, 2 T cm, and violates cm, if and only if, T cm. Consider, for example, the Carrier subprocess of the Order Fulfillment process model described in Appendix A. In particular, consider the parts (i.e., branches) of the Carrier net for handling the shipments that require the truck load (TL) and less than truck load (LTTL). 1 Figure 6.8a shows the the truck load part, and Fig. 6.8b shows the less than the truck load part of the Carrier net. For the purpose of simplicity, in the remainder of this chapter, we will use shorter names for the relevant tasks: for Arrange Pickup, for Arrange Delivery, bill for Create Bill of Lading and shipment for Create Shipment Information Document. Examples3and4show ConDec models for these two parts of the Carrier net. Example 3 (The ConDec model for the LTTL process (cm LT TL )). In the LTTL branch of the process, the goal is to execute tasks,, andbill in such 1 Note that in the original Carrier net, this branch of the net is called LTL. In this chapter we will use the LTTL abbreviation to avoid confusion with Linear Temporal Logic (LTL).

13 6 Declarative Workflow 187 [Truck-Load (TL)] [Less than Truck-Load (LTL)] Arrange Pickup Arrange Delivery Arrange Delivery Arrange Pickup Arrange Delivery [no information] Create Shipment Infomation Document Arrange Pickup [else: both] [no information] [else] Create Bill of Lading [no information] Arrange Delivery Arrange Pickup Arrange Delivery s (a) The truck load (TL) (b) Less than truck load (LTTL) Fig. 6.8 Two parts of the carrier appointment YAWL subnet of the order fulfillment process a way that task must be executed before the task bill, andtask can be executed either before or after the task bill. While the YAWL net for the Carrier subprocess explicitly specifies all possible orderings of the related tasks, these orderings can be implicitly specified by using ConDec constraints, as shown in Fig. 6.9a. Constraints on tasks and bill specify that each of these tasks must be executed at least once. The precedence constraint specifies that task bill can be executed only after task is executed. The automaton presented in Fig. 6.9b is generated for the mandatory formula of this model, and it represents exactly all traces that satisfy this model. From the initial state (S 0 ), the accepting state (S 5 ) can only be reached if bill and are executed and bill is not executed before. Example 4 (The ConDec model for the TL process (cm TL )). In the TL branch of the process, the goal is to execute tasks,, and shipment in any order.

14 188 M. Pesic precedence (a) ConDec model bill!bill &! &!!bill &! S1!bill &! S2 S4 bill (b) Automaton for mandatory formula f cmlt TL D. / ^. bill/ ^..Š bill/w / represents the set of satisfying traces T cm LTTL bill! S3!bill S5 Fig. 6.9 The LTTL model cm LT TL D (f,,billg,f, bill,.š bill/ Wg, ) shipment Fig The TL model cm TL D (f,,shipmentg,f,, shipmentg, ) While the YAWL net for the Carrier subprocess explicitly specifies all possible ordering of the related tasks, these orderings can be implicitly specified by using ConDec constraints, as shown in Fig. 6.9a. Constraints on tasks and shipment specify that each of these tasks must be executed at least once. Note that Fig does not show the automaton generated for the mandatory formula of this model. This is because the generated automata is too complex (i.e., it has eight states and 20 transitions) to be presented as an illustrative example. Note that both the TL and the LTTL subprocess just contain a small number of constraints, nonetheless there are infinitely many traces that satisfy the constraint model. In fact, both models have infinitely many possible execution alternatives, and so are very flexible by design (cf. Sect. 6.1). The main difference between procedural and declarative languages is that in procedural languages it takes effort (specifying all paths) to extend the behavior of a process, whereas in declarative languages it takes effort (specifying constraints) to limit the behavior of a process. In this sense, declarative languages offer a more convenient way to express flexibility than procedural ones. Consider, for example, the ConDec models for the TL and LTTL parts of the Carrier net. Not only that ConDec models define the possible execution alternatives in a more concise way, but they also allow that tasks are executed multiple times when necessary.

15 6 Declarative Workflow Verification of Constraint Models Verification techniques can be used for detection of possible errors in models. The verification capabilities of YAWL will be described in Chap. 20. Just like for procedural languages having formal semantics, constraint-based model expressed in LTL allow for various kinds of analysis. Certain combinations of constraints can cause errors in constraint models that lead to undesirable effects at execution-time. We distinguish two types of constraint model errors: dead tasks and conflicts. A task in a constraint model is dead if none of the traces satisfying the model contains this task, that is, the task cannot be executed in any instance of the model without violating the specified (mandatory) constraints. Definition 8 (Dead task). Let cm 2 U cm be a constraint model. Task t 2 T is dead in model cm, if and only if 2 T cm W t 2. Example 5 (Dead task). Figure 6.11a shows a ConDec model where tasks and bill are dead. This error is caused by the combination of the two precedence constraints. While one precedence constraint specifies that task bill cannot be executed before task, the other precedence constraint specifies that task cannot be executed before task bill. Therefore, it will never be possible to execute tasks and bill in any instance of the model shown in Fig. 6.11a. Dead tasks can easily be detected by analyzing the automaton generated for the mandatory formula of a ConDec model. A task is dead if none of the transitions in the automaton allow the execution of this task. Figure 6.11b shows the automaton generated for the model in Fig. 6.11a. Indeed, this automaton does not contain transitions that allow for the execution of tasks and bill. A constraint model contains a conflict if there are no traces that can satisfy the model, that is, instances of the model can never become satisfied. Definition 9 (Conflict). Model cm 2 U cm has a conflict if and only if T cm D. Example 6 (Conflict). Figure 6.12a shows a ConDec model containing a conflict. In addition to the constraints described in Example 5, there now is an additional <> (! bill) W precedence bill precedence!bill &! &!!bill &! S5 (! ) W bill (a) a ConDec model (b) Automaton for the model Fig Tasks and bill are dead

16 190 M. Pesic <> (! bill) W precedence precedence bill (! ) W bill (a) a ConDec model <> bill (b) Automaton for the model Fig The ConDec model has a conflict as shown by the empty automaton constraint requiring that task bill should be executed at least once. However, task bill is a dead task (see Figure 6.11), that is, it cannot be executed without violating constraints. So, there are no traces that can satisfy all constraints in this model. Detection of conflicts can also be done using the automaton generated for the mandatory formula of the model. If the automaton is empty (i.e., it has no states), then this model has a conflict, otherwise it is conflict free. Figure 6.12b shows the automaton generated for the model from Fig. 6.12a. The automaton is empty, thus indicating that Fig. 6.12a has a conflict. In the previous examples, dead tasks and conflicts were not caused by the combination of all constraints in the model. Instead, they were caused by a specific group of constraints. Dead tasks and bill in Example 5 are caused by the two precedence constraints and the conflict in Example 6 by the two precedence constraints and the constraint on task bill. The smallest subset of mandatory constraints that causes the error is called the cause of the error. In ConDec models, the cause of error can be found by searching through the powerset of mandatory constraints. For each element (i.e., subset of mandatory constraints) in the powerset, the automaton for the mandatory formula can be analyzed for the presence of dead tasks and conflicts as described in previous paragraphs. Detecting the smallest group of mandatory constraints that causes an error supports the user in developing error-free constraint models. 6.3 Enactment of Constraint Model Instances Thus far, we focused on the modeling and analysis of constraint models. In this section, the focus is on the enactment of these models, that is, the actual execution environment. Section introduces the notion of constraint model instances, Sects and describe how states of constraints and instances can be monitored during the execution, respectively. Enforcing a correct instance execution and completion is discussed in Sects and 6.3.5, respectively.

17 6 Declarative Workflow Constraint Model Instances The execution of constraint models is driven by the constraints. These constraints should ensure the correct execution of instances of the model, that is, it should not be possible to violate mandatory constraints during execution and all mandatory constraints should be satisfied after execution. To ensure the correct execution of an instance, it is necessary to keep track of the execution trace of that instance. Formally, a constraint workflow model instance is defined as follows. Definition 10 (Constraint model instance ci). A constraint model instance ci is defined as a pair ci D.; cm/, where: 2 T is the instance s trace cm 2 U cm is a constraint model We use U ci to denote the set of all constraint instances Monitoring Constraint States The sequence of executed tasks for an instance is kept in its instance trace. Depending on the instance trace, constraints from the model can be satisfied,, 2 and temporarily, which means that the constraint is currently, but can still be satisfied. Consider, for example, the LTTL ConDec model shown in Fig. 6.9 on page 188. Although trace hi violates both constraints, once and bill are executed, all constraints will become satisfied. Hence, both constraints are temporarily. As long as the execution is in progress and more tasks can be executed, we distinguish these three states. Definition 11 (Constraint state ). Let c 2 C be a constraint and 2 T an execution trace. The function W.C T /! fsatisfied; temporarily ; g is defined as: 8 < satisfied.;c/ D : if 2 T c I temporarily if. T c / ^.9 2 T W C 2 T otherwise: The state of a constraint can continuously be monitored via the automaton generated for its LTL formula. Every time a user executes a task, a transition in the automaton is triggered, and the automaton changes state. When the automaton is in an accepting state, then the constraint is satisfied. If the automaton is in a nonaccepting state from which an accepting state is reachable, then the constraint is temporarily. Finally, if the trace cannot be replayed on the automaton at all, then the constraint is and will continue to be for this instance. c /I 2 In Sect , we explain how this state is avoided during execution.

18 192 M. Pesic Monitoring Instance States During execution, the state of an instance is also monitored. The state of an instance depends on the satisfaction of the mandatory constraints in the model. Definition 12 (Instance state!). Let ci 2 U ci be an instance where ci D.; cm/. The function! W U ci!fsatisfied; temporarily ; g of instance ci is defined as: 8 < satisfied!.ci/ D : if 2 T cm I temporarily if. T cm / ^.9 2 T W C 2 T otherwise: cm /I Recall that T cm is the set of all traces that satisfy the conjunction of all mandatory formulas (cf. Definition 6 on page 186). Similar to the monitoring of constraint states, the state of an instance can be monitored using the automaton generated for the mandatory formula of the model. Example 7 (Instance states). Table 6.2 shows how three instances (ci 1 ; ci 2,andci 3 ) of the model shown in Fig. 6.9 on page 188 change state during execution. The instance state is always deduced from the automaton s current state (Fig. 6.9b). As long as the automaton stays in nonaccepting states (i.e., S 0 ;S 1 ;:::;S 4 ), the instance is temporarily (tv). The instance becomes satisfied (s) only when the automaton reaches its accepting state S 5. If the instance trace cannot be replayed in the automaton, the instance is (v). The instance state cannot always be directly induced from the states of its individual constraints. When all mandatory constraints are satisfied, the instance is also satisfied, and if at least one mandatory constraint is, the instance is also. However, in the presence of temporarily constraints and the absence of constraints, a deeper analysis of the constraints is needed to induce the instance state. Consider, for example, the instance of the ConDec model shown in Fig The state of the individual constraints is depicted for execution trace hc;a;bi. Observe that none of the mandatory constraints is. The precedence constraint is satisfied, because task A is executed before task B. Table 6.2 State change for instances of the ConDec model in Fig. 6.9 Instance ci 1 D.; cm/ Instance ci 2 D.; cm/ Instance ci 3 D.ı; cm/ i State!.ci 1 / i State!.ci 2 / ı i State!.ci 3 / initial S 0 tv initial S 0 tv initial S 0 tv S 2 tv S 1 tv S 2 tv S 4 tv S 4 tv bill v bill S 5 s bill S 5 tv S 5 s s Dsatisfied, tv Dtemporarily, v D

19 6 Declarative Workflow 193 satisfied temporarily satisfied <C,A,B> 1 2 A precedence B C Fig An instance of ConDec model with trace hc;a;bi Constraint 1, which specifies that task A must be executed exactly once, is also satisfied. Constraint 2, which specifies that task A must be executed exactly twice, is temporarily, and would become satisfied if task A would be executed once again. However, if task A would be executed once again, then the 1 constraint would become. As it is not possible to satisfy the mandatory constraints, the instance state is. Note that the instance presented in Fig cannot be satisfied because the instance model contains a conflict. Recall from Sect that when the model contains a conflict, then there is no execution that will satisfy the constraints from the model. The cause of the error is the combination of constraints 1 and 2. Verification can be used to detect and correct such errors. In the next section, we explain how instances of correct constraint models can be executed without becoming Enforcing Correct Instance Execution The goal of instance execution is to finish the execution in such a way that the instance is satisfied. In order for an instance to be executed in a correct manner, the execution of tasks that would eventually lead to the state of the instance should be prohibited. This can be done using the automaton generated for the mandatory formula of the instance. During execution, the automaton changes state when tasks are executed. Given the current state in the automaton, tasks that are not implied by labels on transitions from this state are prohibited, and other tasks are allowed. Example 8 (Instance execution). Again, consider the ConDec model shown in Fig. 6.9 on page 188. The automaton represents exactly all traces that satisfy this model. Initially, no tasks have been executed and the automaton is in state S 0. Because of the precedence constraint, only task bill should be prohibited, and other tasks should be allowed to execute. This can be detected in the automaton by the absence of a bill transition from S 0 and the presence of and

20 194 M. Pesic transitions. Naturally, the same approach is applied again to all states, as the automaton changes states due to execution of tasks Enforcing Correct Instance Completion The goal of the execution of a constraint workflow model instance is to satisfy all mandatory constraints, and so the state of the instance should be satisfied at completion. The automaton generated for the mandatory formula of the model is used to monitorthestate oftheinstance. Recall thatthestate ofthe instanceis satisfied if the automaton is in an accepting state. Now the completion of an instance is allowed, if and only if, the generated automaton is in an accepting state. Enforcing the correct execution and completion of instances is done in the following way: (1) The states of all constraints are constantly monitored; (2) The state of the instance is constantly monitored; (3) The correct execution of instance is enforced by prohibiting the execution of tasks that would eventually bring the instance into the state; and (4) The completion of the instance is allowed if and only if the instance state is satisfied. All this can be done using the automaton generated for the mandatory formula of the instance s constraint model. 6.4 Dynamic Instance Change In some cases, it is necessary that the model of the instance changes (i.e., by adding and removing tasks or constraints), although the instance is already executing and the instance trace might not be empty. We refer to such a change as a dynamic instance change. Workflow management systems that support dynamic change are called adaptive systems. For example, ADEPT is a workflow management system that uses powerful mechanisms to support dynamic change of procedural process models by allowing to add, remove, and move tasks at runtime. The constraintbased approach offers a simple method for dynamic change that is based on a single requirement: the instance should not become after the change. Because of the fact that in dynamic instance change the trace of an instance remains the same whereas the model changes, it might happen that the instance state changes according to the new model (cf. Definition 12). For example, it is possible that after adding a mandatory constraint, the instance state changes from satisfied to, which is an undesired state. Therefore, instance change can only be successfully applied if the change does not bring the instance into the state. After a successful change, the instance continues execution with an updated model and the original trace. Automata generated for ConDec models enable easy implementation of dynamic change of ConDec instances: dynamic change of a Con- Dec instance is successful if the instance trace can be replayed on the mandatory automaton of the new model.

21 6 Declarative Workflow 195 Consider, for example, two instances ci 1 D.h; ; billi; cm LT TL / and ci 2 D.h; bill; i; cm LT TL / of the model cm LT TL shown in Fig. 6.9 on page 188. Figure 6.14 shows that ci 1 is satisfied by replaying their traces on the model automaton. Assume now that we attempt to dynamically change the cm LT TL model in both instances by removing the task and the constraint from task, removingtheprecedence constraint, and adding a new precedence constraint between tasks and bill. The new model and its automaton are shown in Fig Figure 6.16 shows that this dynamic change involving is successful for ci 1 and not successful for ci 2. This figure shows how the instance trace is replayed on the automaton. On the one hand, the trace of instance ci 1 can be replayed on the new automaton and, although the instance is temporarily, thisisavalid dynamic change. On the other hand, the trace of instance ci 2 cannot be replayed on the automaton because it is not possible to execute task bill from the state S 0, that is, this change would violate the instance. Therefore, the dynamic change for instance ci 2 is not possible. Note that, even though the task is removed from the model after it was executed (the instance trace contains task ), the dynamic change for instance ci 1 is successful. This is due to the property that a trace that satisfies a model can contain tasks that are not in the model. The only consequence of removing task from the model is the fact that it will not be possible to execute this task again in the future. S1 S4 S1 bill S3 S5 temporarily temporarily temporarily (a) ci 1 D.h; i; cm LT TL / temporarily temporarily temporarily satisfied (b) ci 2 D.h; bill; i; cm LT TL / Fig Replaying traces of two instances of model cm LT TL shown in Fig. 6.9 on page 188 on the model automaton precedence bill (a) The new model!bill &!!bill bill S1 S2 (b) Automaton for the new model Fig Applying a dynamic change to the model cm LT TL shown in Fig. 6.9 on page 188

22 196 M. Pesic S1 bill X temporarily temporarily temporarily temporarily temporarily (a) The change is successful for ci 1 (b) The change is not successful for ci 2 Fig The dynamic change involving the model shown in Fig Conclusions To conclude this chapter, we first reflect on the differences between procedural and declarative languages. Then, we summarize the main capabilities of the approach presented in this chapter by using the flexibility taxonomy given in Sect Neither procedural nor declarative workflows represent a better solution when it comes to automation of business processes. On the one hand, business processes that are repeatedly executed in the same manner can clearly benefit from a procedural workflow specification. For example, for the handling of insurance claims, tax declarations, customer orders, etc., a process where always the same procedure is followed is desirable. On the other hand, some processes must be executed in a way that fits best with frequently changing and personalized circumstances. These processes are better specified in a declarative manner because they need a high degree of flexibility, that is, it is desirable that they can be executed in various manners. For example, many processes from the health care domain need flexibility because they must be adjusted to specific circumstances and patients. Moreover, for processes that are partly highly structured and partly loosely structured, a combination of both approaches can be chosen to specify the overall business process. For example, the declarative ConDec workflows Truck Load and Less than truck Load can be subprocesses of the Carrier net, as shown in Fig Also, when necessary, a YAWL workflow can be a part of a declarative ConDec model. Using the service orientation it is possible to mix various modeling styles. A concrete implementation that enables creating decompositions of YAWL (e.g., procedural) and declarative models is presented in Chap. 12 of this book. This chapter introduced a new way of modeling and enacting workflows. The described approach aims to be more flexible than the existing procedural approaches. Table 6.3 shows that declarative ConDec workflows can be used to support multiple types of flexibility. First, because they can easily include a wide range of execution alternatives, ConDec workflows have a high degree of flexibility by design. For example, the ConDec models shown in Figs and 6.15 all have infinitely many execution alternatives (i.e., the sets of satisfying traces of these models are infinite). Second, decomposing ConDec tasks to sub-workflows (e.g., YAWL workflows) allows for flexibility by underspecification. Moreover, this type of flexibility can be achieved either by explicitly specifying the decomposed sub-workflow in the