Workflow Modelling and Analysis Based on the Construction of Task Models

We describe the structure of a workflow as a graph whose vertices represent tasks and the arcs are associated to workflow transitions in this paper. To each task an input/output logic operator is associated. Furthermore, we associate a Boolean term to each transition present in the workflow. We still identify the structure of workflows and describe their dynamism through the construction of new task models. This construction is very simple and intuitive since it is based on the analysis of all tasks present on the workflow that allows us to describe the dynamism of the workflow very easily. So, our approach has the advantage of being very intuitive, which is an important highlight of our work. We also introduce the concept of logical termination of workflows and provide conditions under which this property is valid. Finally, we provide a counter-example which shows that a conjecture presented in a previous article is false.


Introduction
A workflow is an abstraction of a business process that consists on the execution of a set of tasks to complete a process (e.g., hiring process, loan application, and sales order processing). Tasks represent unities of work to be executed that can be processed by a combination of resources, such as a computer program, an external system, or human activity.
Recall that a business process is a collection of interconnected tasks that takes one or more kinds of input and creates an output that is of value to the customers. The construction of process models is very often a difficult accomplishment for humans since their design can be logically incorrect and enclose errors. So the development of tools to support the design of business processes is indispensable and needs to be based on a solid theory. We believe that our technique is appropriate to model workflows.
Workflows have been successfully deployed to various domains, such as bioinformatics, healthcare, the telecommunication industry, the military, insurance, school administration, mobile computing, systems management, multidata bases, Internet, application development, object technology, operating systems, and transaction management.
In the present paper, we use Graph Theory and Propositional Logic to describe the structure of workflows. It is important to point out that a workflow describes all of the tasks needed to achieve each step in a business process. Documents, information, work orders, reports, and so forth are passed from one task to another for action, according to a set of rules defined by the workflow. Employees or automated applications are the entities that carry out the execution of tasks.
In particular we model workflows as trilogic acyclic directed graphs. The use of trilogic graphs to represent workflows was selected since most business process languages support three types of connectors: AND, OR, and XOR. It is important to emphasize that the inclusion of workflows with OR vertices is a significant advantage of our approach.
Furthermore, our approach is based on the execution of all tasks present on the workflow. This analysis has the advantage of being simple and very intuitive. On the other hand, we can create new models based on the existing ones.
Besides our formal framework allows checking the logical termination of workflows. The logical termination is an important property for workflows because it is indispensable to know if a workflow, such as the hiring process, will 2 The Scientific World Journal eventually finish. Analyzing the termination of workflows is an important assignment since research and commercial products, such as METEOR and TIBCO, have no support for verification. Errors made at design-time are not detected and result in very costly failures at run-time.
The use of Propositional Logic has the advantage of transforming a workflow into a set of Event-Action (EA) models. Specialized EA models can be easily created to represent new advanced workflow patterns. Afterwards, Propositional Logic and Inference can be carried out on the EA models to analyze properties of workflow models.
It is important to point out that, in the last decade, the rapid increase of business process modelling and management through the adoption of Workflow Management Systems has originated the need for frameworks that can be used to provide a formal technique for defining and analyzing workflows [1][2][3]. Important advancements have been accomplished in the development of theoretical foundations to allow workflow modeling, verification, and analysis. Several formal methods have been proposed, such as State and Activity Charts [4], Event-Condition-Action rules [5,6], Petri Nets [7][8][9][10][11], Temporal Logic [12], Markov chains [13], Process and Event Algebras [14,15], and Six Sigma Techniques [16,17]. Nevertheless more research is required and specially focused on the use of Graph Theory. Based on this need, we develop our formalism that uses a natural combination of Graph Theory and Propositional Logic to model workflows. Besides, our formalism provides a formal framework based on trilogic acyclic directed graphs that facilitate modeling and analyzing workflows. Finally, our formal framework allows checking the logical termination of workflows.
An important highlight of this paper is the emphasis on the tasks present in the workflow, which allows us to identify easily the dynamism present in the workflow. Finally, we describe the logical termination in a very intuitive form and we present conditions under which this property is valid.
We still provide a counter-example which shows that a conjecture presented in a previous article is false.

Workflow Modelling and Analysis
This section is devoted to the presentation of our main results. In particular, we start this section by providing the formal definition of a workflow. In other words, we furnish the formal structure of a business process. Notice that this workflow structure can be also found in [18][19][20][21]. It is also important to point out that this type of graphs has an input/output logic operator associated with each vertex. Further, we analyze each model present on the workflow and give special emphasis to the execution of all tasks present in a workflow. Besides, we will create new models based on the existing ones. Finally, we will describe conditions under which a workflow logical terminates. In conclusion, our approach allows us to provide a complete description of workflows.
We use the symbol to reference the label of a transition; that is, references transition , ∈ . The elements are called Boolean terms and form the set .
Given ∈ , the incoming transitions for task are the tuples of the form ( , ), ∈ , and the outgoing transitions are the tuples of the form ( , ), ∈ .
The incoming/outgoing condition of task is the Boolean expression . . , ∈ and 1 , . . . , are the incoming/outgoing transitions of task . The terms 1 , . . . , are connected with the logic operator ≻ , ≺, respectively. If task has only one incoming/ outgoing transition we assume that the condition does not have logic operator.
An Event-Action (EA) model for task is an implication of the form : , where and are the incoming and outgoing conditions of task , respectively. An EA model has the behavior with two distinct modes: when is evaluated to true, is also evaluated to true; when is evaluated to false, is always false. And the EA model : is true if both , are true; otherwise it is false. We say that the EA model : is positive if its Boolean value is true; otherwise it is said to be negative.
We denote by the set of all EA models present in WG.
Task is said to be executed if the EA model : is positive. In this case, task has attributed the Boolean value true.

Remark 3. Given an EA model :
, if is false, then task disables all its outgoing transitions. Consequently is also false.
Notice that the workflow starts its execution by enabling transition ⊔ , that is, by asserting ⊔ to be true. In other words, the workflow starts its execution by executing task 1 .
Notice that is true if transition is enabled; otherwise is false. Transitions can be enabled by a user or by an external event. If the EA model : is negative, then both , are false. In this case, all the transitions of are disabled. The output logic operator of task 2 ( 2 ≺) is XOR (⊕), while the input logic operator of task 9 (≻ 9 ) is an AND (•).
The incoming transition for task 2 is 1 = ( 1 , 2 ) and its outgoing transitions are 3 = ( 2 , 4 ) and 4 = ( 2 , 5 ). Hence the incoming condition for task 2 is 1 , while its outgoing condition is 3 Task 2 is executed if the EA model 2 : 1 3 ⊕ 4 is positive, that is, if 1 is true and only one of the Boolean terms 3 , 4 is true.
Notice that the workflow from Figure 1 corresponds to the following real situation. Indeed, it can represent the tasks necessary to be executed for a person driving a new car. Let us assume that tasks , ∈ {1, . . . , 9} have the following meanings: 1 : deciding to purchase a new car to own use; 2 : payment of the car; 3 : getting the drivers license; 4 : deciding to pay by credit; 5 : deciding to pay without credit; 6 : getting rental credit; 7 : getting bank credit; 8 : purchasing of the car; 9 : driving the new car.
Clearly, the decision of purchasing a new car to own use implies to pay the car and to get the drivers license. The payment of the car implies the execution of only one of the situations to pay by credit or to pay without credit. And to get credit implies to get a rental credit or a bank credit. It is clear that the purchase of the car depends on the execution of only one of the tasks: decide to pay without credit, get rental credit, and get bank credit.
Hence, the possibility to drive a new car depends on the purchase of the car and in obtaining the drivers license. In other words, the execution of task 9 depends on the execution of both tasks 3 , 8 . Proof. Let us assume that is true. Let : be the EA model associated to task . If task is not executed, then the EA model : is negative. Since the EA model is negative, all outgoing transitions of task are disabled; in particular is disabled, that is, is false, wich is a contradiction. Hence task is executed. Remark 7. Let us consider the Boolean term where = ( , ) ∈ , , ∈ . If is true, task is not necessarily executed. For example, in the workflow from Figure 2, let us assume that ⊔ = true, 1 = true, 2 = false, 3 = true, 4 = true, 5 = true, 6 = true, 7 = true, 8 = true, and ⊓ = false. Hence, for this assignment the EA model 7 : 6 ⊕ 8 ⊓ is negative, which means that task 7 is not executed. Nevertheless, 8 = ( 6 , 7 ) and 8 is true.
Next we introduce the concept of logical termination. This is a very important structural property, since its analysis will allow to verify if a workflow will eventually finish, according to the initial specifications.
Definition 8. Let WG = ( , , , ) be a workflow. One says that WG logically terminates if task is executed whenever task 1 is executed.
In the following result we establish a necessary and sufficient condition for the logical termination.  Proof. Let us assume that WG logically terminates; that is, task is executed whenever task 1 is executed. This means that the EA model : ⊓ is positive whenever the EA model 1 : ⊔ 1 is positive. Bearing in mind that WG starts its execution by executing task 1 , then the EA model 1 : ⊔ 1 is positive. Hence the EA model : ⊓ is also positive. Consequently, ⊔ , 1 , , and ⊓ are true. Thus, ⊓ is true whenever ⊔ is true.
Conversely, let us assume that ⊓ is true whenever ⊔ is true. Let us assume that task 1 is executed. This means that the EA model 1 : ⊔ 1 is positive. Bearing in mind that ⊓ is true, according to the behavior of the EA models, necessarily is true. Hence the EA model : ⊓ is positive, which means that task is executed. So we can conclude that task is executed whenever task 1 is executed, which means that WG logically terminates.
Example 10. It is not hard to check that, in the workflow from Figure 1, ⊓ is true whenever ⊔ is true. Thus, the workflow logically terminates.
Next we address our study on the dynamism present in a workflow. Obviously the dynamism is associated with the sequential execution of its tasks. In the workflow from Figure 1 the execution of task 1 implies the execution of both tasks 2 , 3 ; the execution of task 2 implies the execution of only one of the tasks 4 , 5 ; the execution of task 4 implies the execution of only one of the tasks 6 , 7 ; the execution of only one of the tasks 5 , 6 , and 7 implies the execution of task 8 . Finally, the execution of both tasks 3 , 8 implies the execution of task 9 . Hence, we can state the execution of task 1 implies the execution of 2 • 3 ; the execution of task 2 implies the execution of 4 ⊕ 5 ; the execution of task 4 implies the execution of 6 ⊕ 7 ; the execution of 5 ⊕ 6 ⊕ 7 implies the execution of task 8 ; the execution of 3 • 8 implies the execution of task 9 . Notice that when we consider 2 • 3 , the operator • is the output logic operator of task 1 , while when we consider 5 ⊕ 6 ⊕ 7 , ⊕ is the input logic operator of task 8 .
These remarks led us to introduce the following concept.
Remark 13. Since every task has associated a Boolean value, according to its execution, it is also natural to attribute a Boolean value to the compound tasks of WG. The natural attribution is the following. Given any compound task of WG, Usually we represent a compound task model by → , where is called the incoming task and is called the outgoing task. We say that a compound task model → is positive if both incoming and outgoing tasks are positive, that is, if both tasks , are executed. In particular, the implication of the form → is called a simple task model. Clearly, it is positive if both tasks , are executed.
The set of all simple and compound task models present in WG is called the set of task models of WG and is denoted by TM.
The task models have the behavior with two distinct modes: if its incoming task is true, necessarily its outgoing task is true; if the incoming task is false, the outgoing task is false. In other words, if → is a compound task model, then is executed if and only if is executed.
Notice that, in a compound task model → , at least one of the tasks , is compound.
Example 15. In the workflow from Figure 1, the set of its task models is TM From now on, we use the symbol ↔ with the following meaning: ↔ means that the compound statements and are logically equivalent.
According to simple rules of Logic and taking into account the behavior of the task models, we can infer the following result. And the establishment of this result allows us to identify new task models present in the workflow.
In what follows we establish some properties that will allow us to create new task models based on the existing ones. Proof. The proof is trivial.
(a) If both task models Proof. (a) Let us assume that both task models (2) and (3) belong to TM. Notice that if either (2) or (3) is negative, since ↔ , then necessarily both task models (2) and (3) are negative. So, we just need to verify the result when both task models (2) and (3) are positive.
Let us assume that both tasks models (2) and (3) are positive. Since (2) is positive, necessarily both , are true. In other words, some of the tasks from , are executed allowing that , are executed. Bearing in mind that ↔ , then is true. So according to the behavior of the task models, necessarily is true. Hence we can state that is executed, whenever is executed. Therefore the model → still holds in WG. Now, in order to prove (b) and (c), we start with the following argument. Bearing in mind that ↔ , according to the behavior of the task models, we can consider that → still holds in WG. Since → and → holds in WG, according to Proposition 16 (5), obtaining the new model → , which means that → still holds in WG. (e) Bearing in mind that → holds in WG, and consequently , have the same Boolean value, we can replace by in (5), obtaining the new model → , which means that → still holds in WG.
The previous results allow us to identify new task models based on the existing ones, as it is described below.
Definition 18. Let WG = ( , , , ) be a workflow. An extended task model is a model obtained by applying a finite sequence of some of the properties established in Proposition 16 and Theorem 17. One adopts the notation TM to represent the set of all extended task models of WG.
Notice we adopt the same notation of the task models to represent the extended task models. Furthermore, the extended task models verify the same properties of the task models. In particular, given an extended task model → , necessarily both , have the same Boolean value.
Naturally when we consider the set of all task models and extended task models presented in WG, we obtain all possible models that can be generated by the task models of the workflow. This set of task models will be designated by the closure of TM. In certain sense, we can state that the set of all task models from WG is a set of generators of all possible models of WG.
Definition 20. Let WG = ( , , , ) be a workflow. One defines the closure of TM as the set of all task models and extended task models in WG. This set is denoted by TM * . In other words, TM * = TM ∪ TM . Example 21. As we saw in Example 15 in the workflow from Figure 1, Notice the workflow from Figure 1 logically terminates and 1 → 9 ∈ TM * . Furthermore, we studied many other examples of workflows that logically terminates and simultaneously 1 → ∈ TM * . The analysis of these different cases led us to formulate the following conjecture.
After the analysis of many cases, we start believing that the conjecture was true. Nevertheless it is false, as the following example proves. Let us consider the following workflow.
Example 23. It is not hard to check that the workflow from Figure 3 logically terminates; nevertheless the condition 1 → ∈ TM * is not valid.
Indeed the condition of the Conjecture 22 is not necessary. However it is sufficient, as we prove in the following result.
Proof. Let us assume that 1 → ∈ TM * . Case 1. Suppose that 1 → ∈ TM. This means that WG has the following structure: In this case, 1 = . Since WG starts its execution by executing task 1 we can conclude that task is executed whenever task 1 is executed, which means that WG logically terminates.
Case 2. Suppose that 1 → ∈ TM * \TM = TM . So, 1 → was obtained by applying some of the results established in Proposition 16 and Theorem 17. Since 1 → ∈ TM * and the workflow starts its execution by executing task 1 , that is, by asserting 1 to be true, according to the behavior of the extended models, necessarily is still asserted to be true. This means that task is executed. Hence, task is executed whenever task 1 is executed. Thus WG logically terminates.

Conclusions
In this paper we develop a formalism to describe and analyse the structure of workflows, based on graphs and Propositional Logic. Indeed, we describe the structure of a workflow as a graph whose vertices represent tasks and the arcs are associated to workflow transitions. To each task an input/output logic operator is associated and this logic operator can be the logical AND (•), the OR (⊗), or the XORexclusive-or-(⊕). Furthermore, we associate a Boolean term to each transition present in the workflow.
It is important to point out that our main emphasis is the analysis of a workflow through the study of its task models which allows us to describe the dynamism of the workflow in a very simple and intuitive way.
Another relevant aspect of our approach is the introduction of the concept of compound tasks. This concept allows us to identify new task models based on the existing ones. Through these new task models we are able to describe the dynamism present in a workflow in a very simple way. Clearly, the study of the dynamism of a workflow is equivalent to analyse the sequential execution of its tasks.
We still analyze the concept of logical termination and we provide necessary and sufficient conditions under which this property is valid.
Finally, given a workflow WG we provide a counterexample which shows that the conjecture of 1 → ∈ TM * being a necessary and sufficient condition under which WG logically terminates is false. In fact, the condition is necessary; nevertheless it is not sufficient.