# Generating Block-Structured Parallel Process Models by Demonstration
## 4 Results  
Our experimental analysis was performed on a sample of 100 real examples obtained by arbitrary manual search of the Internet and selecting publicly available models of business processes (or models similar to them), which fulfill our conditions of block-structured models of parallel processes [7]. Note that the models were found by searching the Web for the keywords: block-structured parallel process, parallel business process, activity diagram, BPMN diagrams, etc.The considered examples can be found at [26]. Some characteristics that reflect the network structure and size of the analyzed examples are given in Tables 2 and 3 in [7]. These characteristics are expressed by the total number of activities in the network and a number of branches in the network. As with block-structured parallel processes, there is one input and one output, and it can be presented by the structure of a tree [7], with \"branch\" meaning a direct route from the entrance to the exit of the network. In the example presented in Figure 1, there are three branches with activities:  
* B1-B2-B3-B8-B9,
* B4-B5-B8-B9 and
* B6-B7-B9. The experimental analysis consisted of multiple different executions of process activities given at [26], tracking the results obtained by these executions, and making conclusions based on the results obtained. In the case of multiple different executions of the considered parallel process, it was noticed that after the set of performed scenarios, the candidate model no longer changed. This, in fact, means that the last obtained candidate model, in addition to the performed scenarios of process execution, also supported the scenarios that could eventually be performed by the observed process. This way, the last obtained candidate model becomes the final model of the process. It was of particular interest to consider after how many scenarios could the final model be achieved, and on what this depends. Namely, multiple different executions of the same  
Figure 14: Footprint relation after the two performed scenarios shown in Figure 8.  
process indicate that the final model of the observed process does not always occur after the same number of scenarios played. The obtained results showed that the number of execution scenarios necessary for obtaining the final model depends, quite expectedly, on the order of activities in the first scenario, given the structure of the network. We came to the conclusion that the necessary number of scenarios played depends on whether all activities belonging to one branch are successively performed. In this regard, we adopted two different strategies according to which we performed the processes from the sample and followed the results obtained:  
Strategy 1. (Depth-first) In the first performed scenario, the execution order of activities is such that all the activities of one branch are executed first, then, all the activities of the other branch that are parallel to the previous one, and so on, until all activities from all parallel branches are executed. Strategy 2. (Breath-first) In the first performed scenario, the order of execution of activities is such that activities from different parallel branches are alternately executed. **Strategy 1**  
By applying Strategy 1, the results obtained from the experimental analysis showed that in 99 examples (out of the total of 100 examples), the final model was always obtained after only two different performed scenarios (marked in green). This means that the first appearance of the repeated scenario (marked in red) was an indication that the obtained candidate model was actually the final model as well. In only one case, it was necessary to proceed with the procedure given in the description of the demonstration flow after the first appearance of the repeated scenario in order to achieve the final model.