# Business Process Configuration according to Data Dependency Specification
## 4 Conf-BP Framework: A Configurable System to Create Imperative BP
### Automatic Transformation from Declarative to Imperative Model
#### 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 \(t_{ini}^{A^{i}}\) and \(t_{end}^{A^{i}}\) for each activity, has to be translated into an imperative BP model. For the example of Figure 7**b**, the obtained list is: \(\{A_{1}[0,t_{1}]\), \(A_{2}[0,t_{3}]\), \(A_{3}[t_{2},t_{3}]\), \(A_{4}[t_{1},t_{2}]\)}. 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. Figure 7: Flexibility of the BP in terms of the execution time of the Activities. 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 \(t_{ini}^{A_{i}^{i}}\) and \(t_{end}^{A_{i}^{i}}\) 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 _Problem_ is formed by a set of activities \(A_{1},...\), \(A_{8}\), associated with a time interval \(\langle t_{ini}^{A_{i}^{i}},t_{end}^{A_{i}^{i}}\rangle\), 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 problems 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 \(A_{1}\)... \(A_{n}\), the parallel subsets are a set of subset of activities \(ps_{1}\),..., \(ps_{m}\), where there does not exist any activity \(a\in ps_{i}\) and an activity \(b\in ps_{j}\), where \(ps_{i}\
eq ps_{j}\), such that there exists a tuple in the List of Tuples of Relations that \(\langle\)condition, \(a\), \(b\rangle\). A way to obtain the parallel subsets, is creating a parallel subset for each activity (\(ps_{1}\),..., \(ps_{n}\)), if there exist an activity \(a\in ps_{i}\) and another activity \(b\in ps_{j}\), both subsets are merged. This process is repeated until no more sets can be merged.