Abstract
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.
1. 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 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 () models. Specialized models can be easily created to represent new advanced workflow patterns. Afterwards, Propositional Logic and Inference can be carried out on the 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–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–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.
2. 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–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.
Definition 1 (see [18–21]). A workflow is a trilogic acrylic directed graph , where is a finite nonempty set of vertices representing workflow tasks. Each task (i.e., a vertex) has attributed an input logic operator (represented by ) and an output logic operator (represented by ). An input/output logic operator can be the logical AND , the OR , or the XOR—exclusive-or—. The set is a finite nonempty set of arcs representing workflow transitions. The transition is the tuple and transition is the tuple , where the symbols and represent abstract tasks which indicate the entry and ending point of the workflow, respectively. Every transition , corresponds to a tuple of the form , where .
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 , where , and are the incoming/outgoing transitions of task . The terms 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 model for task is an implication of the form , where and are the incoming and outgoing conditions of task , respectively. An model has the behavior with two distinct modes: when is evaluated to , is also evaluated to ; when is evaluated to , is always . And the model is true if both , are true; otherwise it is false. We say that the model is positive if its Boolean value is true; otherwise it is said to be negative.
We denote by the set of all models present in .
Task is said to be executed if the model is positive. In this case, task has attributed the Boolean value true.
Remark 2. Given an expression whose Boolean value is true (resp., false), we simply can represent this fact by , (resp., ).
Remark 3. Given an 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 .
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 model is negative, then both , are false. In this case, all the transitions of are disabled.
Example 4. In Figure 1 we present a workflow , where , , , and , , .
The output logic operator of task is XOR , while the input logic operator of task is an AND .
The incoming transition for task is and its outgoing transitions are and . Hence the incoming condition for task is , while its outgoing condition is .
Task is executed if the model is positive, that is, if is true and only one of the Boolean terms , 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 , have the following meanings: : deciding to purchase a new car to own use; : payment of the car; : getting the drivers license; : deciding to pay by credit; : deciding to pay without credit; : getting rental credit; : getting bank credit; : purchasing of the car; : 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 depends on the execution of both tasks , .
Many other examples can be given. Indeed, too many situations in our life can be described by workflows. For example, the request for a credit card or a loan application is simple examples of workflows.
Proposition 5. Let be a workflow. Let , . If is true, then is necessarily executed.
Proof. Let us assume that is true. Let be the model associated to task . If task is not executed, then the model is negative. Since the 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 6. The condition of Proposition 5 is not sufficient. For example in the workflow from Figure 1, if task is executed, then the model is positive. For , , , and , is executed, but is false.
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 , , , , , , , , , and . Hence, for this assignment the model is negative, which means that task is not executed. Nevertheless, and 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 be a workflow. One says that logically terminates if task is executed whenever task is executed.
In the following result we establish a necessary and sufficient condition for the logical termination.
Theorem 9. Let be a workflow. Then logically terminates if and only if is true whenever is true.
Proof. Let us assume that logically terminates; that is, task is executed whenever task is executed. This means that the model is positive whenever the model is positive. Bearing in mind that starts its execution by executing task , then the model is positive. Hence the model is also positive. Consequently, , , , and are true. Thus, is true whenever is true.
Conversely, let us assume that is true whenever is true. Let us assume that task is executed. This means that the model is positive. Bearing in mind that is true, according to the behavior of the models, necessarily is true. Hence the model is positive, which means that task is executed. So we can conclude that task is executed whenever task is executed, which means that 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 implies the execution of both tasks , ; the execution of task implies the execution of only one of the tasks , ; the execution of task implies the execution of only one of the tasks , ; the execution of only one of the tasks , , and implies the execution of task . Finally, the execution of both tasks , implies the execution of task . Hence, we can state the execution of task implies the execution of ; the execution of task implies the execution of ; the execution of task implies the execution of ; the execution of implies the execution of task ; the execution of implies the execution of task . Notice that when we consider , the operator is the output logic operator of task , while when we consider , is the input logic operator of task .
These remarks led us to introduce the following concept.
Definition 11. Let be a workflow. The compound tasks of are the elements of the following form: , . The set of all compound tasks of is denoted by ; that is,
Example 12. In the workflow from Figure 1, .
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 . The natural attribution is the following. Given any compound task of , .
If , then the Boolean value of is if and only if the Boolean value of all tasks is equal to .
If , then the Boolean value of is if and only if there exists at least one of the tasks whose Boolean value is equal to .
If , then the Boolean value of is if and only if there exists only one of the tasks with Boolean value equal to .
Naturally, we can state that a compound task is executed if and only if its Boolean value is equal to , which means that the compound task is positive. In other words, is executed if and only if, one of the following cases holds:
If , all tasks are executed.
If , at least one of the tasks is executed.
If , only one of the tasks is executed.
In what follows, we introduce a new type of task models that we designate by compound task models.
Definition 14. Let be a workflow. Let , . A compound task model is an implication with one of the following forms:(1);
(2);
(3).
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 is called the set of task models of and is denoted by .
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 .
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.
Proposition 16. Let be a workflow. Suppose that the task models and belong to . Then the model still hods in .
Proof. The proof is trivial.
Theorem 17. Let be a workflow.(a)If both task models belong to , where , then the model still holds in .(b)If both task models and belong to , where , , then the compound task model still holds in .(c)If both task models and belong to , where , , then the compound task model still holds in .(d)If both task models and belong to , where , , then the compound task model still holds in .(e)If both task models and belong to , where , , then the compound task model still holds in .
Proof. (a) Let us assume that both task models (2) and (3) belong to . 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 .
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 . Since and holds in , according to Proposition 16 we can conclude that
still holds in .
(b) Taking into account that belong to , and consequently , have the same Boolean value, we can replace by in (4), obtaining the new model , which means that still holds in .
(c) Taking into account that belong to , and consequently , have the same Boolean value, we can replace by in (4), obtaining the new model , which means that still holds in .
Analogously, in order to prove (d) and (e) we start by making the next statement. Taking into account that , according to the behavior of the compound task models, we can consider that holds in . Since and hold in , according to Proposition 16 we can conclude that
still holds in .
(d) Bearing in mind that holds in , and consequently , have the same Boolean value, we can replace by in (5), obtaining the new model , which means that still holds in .
(e) Bearing in mind that holds in , and consequently , have the same Boolean value, we can replace by in (5), obtaining the new model , which means that still holds in .
The previous results allow us to identify new task models based on the existing ones, as it is described below.
Definition 18. Let 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 to represent the set of all extended task models of .
Example 19. In the workflow from Figure 1, bearing in mind that , , according to Theorem 17 we can conclude that the model still holds in . Therefore, we can state that is an extended task model of .
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 , 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 . In certain sense, we can state that the set of all task models from is a set of generators of all possible models of .
Definition 20. Let be a workflow. One defines the closure of as the set of all task models and extended task models in . This set is denoted by . In other words, .
Example 21. As we saw in Example 15 in the workflow from Figure 1, . Since , according to Theorem 17 we can deduce that . Now bearing in mind that , applying again Theorem 17 we can conclude that . As we can state that . Bearing in mind that , applying once more Theorem 17 we infer that . As , applying again Theorem 17 we conclude that .
Notice the workflow from Figure 1 logically terminates and . Furthermore, we studied many other examples of workflows that logically terminates and simultaneously . The analysis of these different cases led us to formulate the following conjecture.
Conjecture 22 (see [21]). Given a workflow , then logically terminates if and only if .
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 is not valid.
Indeed the condition of the Conjecture 22 is not necessary. However it is sufficient, as we prove in the following result.
Theorem 24. Let be a workflow. If , then logically terminates.
Proof. Let us assume that .
Case 1. Suppose that . This means that has the following structure:
In this case, . Since starts its execution by executing task we can conclude that task is executed whenever task is executed, which means that logically terminates.
Case 2. Suppose that . So, was obtained by applying some of the results established in Proposition 16 and Theorem 17. Since and the workflow starts its execution by executing task , that is, by asserting 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 is executed. Thus logically terminates.
3. 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 XOR—exclusive-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 we provide a counter-example which shows that the conjecture of being a necessary and sufficient condition under which logically terminates is false. In fact, the condition is necessary; nevertheless it is not sufficient.
Conflict of Interests
The author declares that there is no conflict of interests regarding the publication of this paper.