4.3.1. Configuration of a BP Model: Creating a COP from the Declarative Model
The relation between the input and output of the activities determines their relational order. For the same declarative model, it is possible to find several configurations of activities that satisfy the requirements and description. To find the best configuration, we propose the use of an intelligent system to find the optimal BP model that maximizes the parallelism of the activities, with the aim of minimizing the execution time. To determine this configuration, we suggest the transformation of the declarative model into a COP, to analyze the possible instant when the activities can start and end their executions, according to data dependency.
Firstly, and before to explain how to create the COP, it is necessary as a previous step to ascertain the data relation, especially when they are included in the IF-THEN constraints of the description of the problem. The definition of Tuple of Condition-Relation in order to introduce this relation is introduced.
Definition 8. A Tuple of Condition-Relation is a tuple formed of , where represents under which condition is executed after . Therefore, the value in the implies that is always executed after , or, in the case when the contains an expression, is executed after if and only if the expression is met.
These tuples are built analyzing the data relations found in the set of and that describe the declarative model. For each constraint where the output of an activity is related to the input of an activity , a tuple is created. If the input-output relation appears in an IF-THEN constraint with a c condition, the tuple will be 〈c, , 〉, and 〈, , 〉 otherwise.
With the list of intervals and the list of tuples of data relations, the following COP is created:
Variables: The possible instants when each activity can be executed, are defined as the tuple of variables , where is the instant of time in which the activity begins, and is the instant of time in which the activity finishes. For each activity , the COP will include a couple of variables . To represent the execution time of the whole process, the variable T is included, that represents the of the last activity executed. If every activities is executed in parallel, T will be the maximum value of , but if every activities are executed sequentially, the value of T will be the summation of every .
Domain: The domain of the and variables is related to the execution time of each activity. If we suppose that each activity spends units of time, then the domain of each variable is:
- -
: 0..
- -
: ..
- -
T: max()..
Constraints: The necessary constraint to model the COP are:
- -
It is mandatory that for every activity , ≤
- -
T has to be the greatest value of t, then T ≥ for every A.
- -
For each element of the list of tuples building by using the data relations, a numerical constraint is included in the COP. Each relation between data input and output in the way 〈c, , 〉 is translated into the constraint ≥ . For example, in the trip planner, the constraint is translated into . Therefore, all the activities could start at the same instant unless there exists a relationship requiring one activity to start after another.
Objective: The optimization function of the COP is the minimization of the total time, it implies to minimize the value of T (minimization(T)).
Table 1 gives a summary of the equivalence of the elements of the formalization and the COP built.
The solving of the COP will obtain a pair of start and end instants of time for each activity that minimizes any instantiation time (
T) for the model. As mentioned earlier, the minimum execution time of an activity is modelled as a
units of time. But it is possible to obtain the same value of (
T), where the execution time is minimized, with different
and
for the same problem. Suppose activities (
,
,
and
) that last a unit of time, where the input data of
depends on the output of
, and the input data of
depends on the output of
.
Figure 7 depicts two possible configurations (a) and (b) that minimize the theoretical execution time (
). However, there exist more variations, since
can be executed in a parallel way with any of the other activities.
Although both options (a) or (b) are optimal according time consuming, the model of
Figure 7b is better than the model of
Figure 7a, since it supports an unexpected delay of
executing, not increasing the total execution time (
).
To make the imperative model more robust to unexpected delays, we propose to modify the proposed COP to find the most paralleled process. To this end, the COP must find the greatest value of for each . It is obtained including the variables as a goal in the COP, and leaving the domain of open during the search. Then, the variables will be instantiated during the propagation phase, while all the possible values of the domains of variables will be obtained as solutions of the COP for each value of . The greatest value of the domain is the most appropriate value to build an imperative robust business process model.
Algorithm 1 describes the creation of the COP from a declarative specification as explained before.
Algorithm 1 Creation of a COP from a Declarative Specification. |
- 1:
Create variable: - 2:
Create variable: - 3:
for each do - 4:
Create a variable: - 5:
Create variable: - 6:
end for - 7:
for each do - 8:
Create constraint: - 9:
Create constraint: - 10:
end for - 11:
for each , where an output of is related to the input of do - 12:
Create constraint: - 13:
end for - 14:
Define goal variables: {} - 15:
Define objective function:
|
4.3.2. Transformation of the COP results into a BP Imperative Model
The list of time intervals, obtained from the COP, with the most appropriate values for
and
for each activity, has to be translated into an imperative BP model. For the example of
Figure 7b, the obtained list is: {
,
,
,
}. There exist various imperative models in business processes, but the most widely used standard language is BPMN [
47]. Although the model in the standard is represented by means of an XML file, to facilitate the understanding of the algorithm that obtains the imperative model, we propose the use of a BPMN-Graph. As explained in [
1], BPMN is a graph-oriented language in which control and action nodes can be connected. Therefore, we propose to model the BPMN using a directed graph as defined in [
51].
The problem is solved in two steps: firstly, the BPMN-Graph is built not specifying the type of gateways, only including which are splits and joins, and; secondly, the uncertain about the gateways is solved analyzing the list of tuples created in function of the IF-THEN constraints of the model, that related the activity execution on function of the value of other variables.
Step 1: Building BPMN-Graph
The proposed BPMN-Graph is a direct graph composed of: (i)
vertices, which represent the activities and the gateways; and (ii)
edges, which represent the sequence flows that join the various vertices. Firstly, the idea of the algorithm is explained by means of a trace, after which the algorithm is detailed. Analyzing the
and
of each activity, it is possible to discover the activities that have parallel or sequential relation between them. The main idea of the algorithm is to detect these relations by building sub-graphs, that will be combined in a sequential or parallel way. An example of the trace of the algorithm is shown in
Figure 8. The initial
is formed by a set of activities
, associated with a time interval
, and a list of tuples that describe the condition about the activities order dependencies. The algorithm divides the problem in function of the
sequential points and the
parallel subsets. Both definitions are introduced:
Definition 9. Sequential point (List of Time Intervals): For a List of Time Intervals, a sequential point is an instant, or set of instants of time at which no activity can be executed. It implies that in a sequential point, only the execution of an activity can start or end, and therefore the problem can be broken into two smaller that can be executed sequentially.
Definition 10. Parallel subsets (List of Time Intervals, List of Tuples of Relations):For a list of Time Intervals associated with the activities … , the parallel subsets are a set of subset of activities , …, , where there does not exist any activity a ∈ and an activity b ∈ , where ≠ , such that there exists a tuple in the List of Tuples of Relations that 〈condition, a, b〉. A way to obtain the parallel subsets, is creating a parallel subset for each activity (, …, ), if there exist an activity a ∈ and another activity b ∈ , both subsets are merged. This process is repeated until no more sets can be merged.
With the aim of facilitating the understanding of the algorithm and our proposal in general, we use the example of
Figure 8, with the list of tuples:
(R1) , ,
(R2) , ,
(R3) , ,
(R4) , ,
(R5) ,
(R6) , ,
(R7) ,
The trace follows the next steps:
Look for sequential points: Firstly, the set of activities should be separated by the sequential points (arrow 1 in
Figure 8). The separation is carried out by detecting those instants of time where there is a sequential point. The intervals that are derived from these sequential points delimit the subset of activities. In the example, the set of activities is separated into two subsets of activities, since there is only one sequential point in
. The first subset
goes from
to
and includes all activities except activity
. On the other hand, the second subset
goes from
to
and only includes activity
.
Solving sequential sub-problems: Each subset of activities is solved as a sub-problem (arrows 2 and 3) and combined sequentially both BPMN-sub-graphs are solved.
Look for parallel subsets: The is separated in three parallel subsets: , and . To obtain these subsets, the idea described in Definition 10 is applied:
- (a)
Create a subset of each activity: {: {}, : {}, : {}, : {}, : {}, : {}, : {}}.
- (b)
Since is related with in , and with in , both subsets are merged. Also, and are related in . The obtained parallel subsets are: {: {, , }, : {}, : {}, : {, }}.
- (c)
Since is related with in , and with in , both subsets are merged. Therefore, the parallel subsets: {: {, , , }, : {}, : {, }} are also obtained.
- (d)
Tuple relations and are not used in the creation of subsets since is not involved in the parallel analysis.
Solving parallel sub-problems: The next step implies to solve each sub-problem (arrows 4, 5 and 6), followed by the search of sequential points.
Combining parallel sub-problems: To solve it is necessary to combine the sub-graphs obtained by solving , and (return of arrow 4, 5 and 6). These BPMN-sub-graphs are combined as various branches joined by a split and join node ( in the example).
Combining sequential sub-problems: The obtained results after a sequential analysis of sub-graphs (returns of arrow 2 and 3) implies joining the results of and . To this end, the result (BPMN-Graph) of and are joined by an edge between the final vertex of and the initial vertex of , which are and respectively.
Algorithm 2 Create a BP model from COP result. |
- 1:
proceduresequentialTreatment(): BPMN-Graph - 2:
: BPMN-Graph to return - 3:
: list of Problems - 4:
: list of BPMN-Graphs - 5:
if () then - 6:
- 7:
else - 8:
separate p by detecting sequential points - 9:
for each do - 10:
- 11:
end for - 12:
end if - 13:
link sequentially - 14:
return - 15:
end procedure - 16:
procedureparallelTreatment(): BPMN-Graph - 17:
: BPMN-Graph to return - 18:
: list of Problems - 19:
: list of BPMN-Graphs - 20:
if () then - 21:
- 22:
else - 23:
separate p by detecting parallel groups - 24:
for each do - 25:
- 26:
end for - 27:
end if - 28:
link by gateways - 29:
return - 30:
end procedure
|
Algorithm 2 details the procedures for the sequential and parallel treatments explained above. Algorithm 2 takes a and transforms it into a BPMN-Graph. Initially, the is treated sequentially with the algorithm , which finds the sequential points following Definition 9. Each of the found, has to be analyzed to identify the parallel subsets of activities with the algorithm (following Definition 10). The parallel treatment of a consists of gathering the activities that are related into subsets and creating new problems from these subsets. The relationships among the activities are given by the tuples of Condition-Relation of the . Each is then solved recursively. To combine the parallel subsets, two gateway vertices are inserted as split and join gateway respectively. Each BPMN-sub-graph will be a branch related by means of the gateway. To combine two sequential BPMN-sub-graphs, only and edge needs to be included between the last node of the first solution and the first node of the second solution. The algorithm draws to a halt when reaching a base case, or when the problem contains only one activity. In both treatments, the solution of a base case is a graph with a unique vertex that represents this activity.
Step 2: Defining The Gateways
Once the graph is created, the correct gateways that diverge the sequence flows have to be selected. In the graph, the gateways are identified by means of studying the tuples of Condition-Relation obtained from the constraints, defined in the declarative specification.
The different types of relations described by means of the tuples of Condition-Relation, and how they affect to the type of gateway are explained below:
Parallel: two activities are executed in a parallel way if there are no conditions that relate the
of both activities (see
Figure 9).
Exclusive: two activities are executed in an exclusive way if the constraints that relate the
of the two activities and the domain of these constraints are complete and do not overlap. For example, as shown in
Figure 10, if the execution of
and
depends on a value of the output data
, but there are no overlaps (
is executed when
is less than 50 and
is executed when
is greater than or equal to 50), then there is an exclusive relationship between them. There is another possibility when only one condition is described, for example only exists the condition (
is executed when
is less than 50), in that case it means that there are two branches for the XOR gateway, but one of them with no activities.
Inclusive: two activities are executed in an inclusive way if there are conditions that relate the
of both activities, and the domain of these conditions are complete and overlapped. For example, as shown in
Figure 11, if the execution of
and
depends on a value of the output data
, but there are overlaps between the domains that satisfy the constraints (
is executed when
is less than 75 and
is executed when
is greater or equal to 25, and hence both coincide when
is greater than 25 and less than 75), then there is an inclusive relationship.
Table 2 gives a summary of the resulting gateways depending on the conditions established by the constraints that relate the data of the activities.
For the example explained in
Figure 8, it is necessary to analyze
and
(see
Figure 12). Since there are no relations between activities
,
, and
, then
is a parallel gateway. On the other hand, the execution of activities
and
depends on the outputs of
. The conditions specified in relations
and
indicate that the domain of the constraints is complete and there are no overlaps, therefore,
is an exclusive gateway.