# TransformingBPMN Processes toSBVR Process Rules with
## 6 Experimental Evaluation
In Table 4, the column _Model_ denotes the 32 BPMN process models that were selected for the experiment; columns \(T_{1}\)-\(T_{9}\) represent the transformation rules that were defined in  
\begin{table}
\begin{tabular}{c c c c c c c c c c} \hline \hline
**Model** & \(\mathbf{T_{1}}\) & \(\mathbf{T_{2}}\) & \(\mathbf{T_{3}}\)  
Table 1; each cell on the intersection of a specific source model _Model(i)_ and transformation rule \(T_{j}\) represents the number of BPMN process rules that were acquired from _Model(i)_ after performing \(T_{j}\); the last column of Table 4 represents the results of the extraction of cascading gateways described in Section 3.3. **Discussion. ** The first observation from the acquired results of the automatic extraction of process rules (Table 4) is that, indeed, the experiment did cover a full set of the defined transformation rules and algorithms, meaning we have tested the whole specification. After closely analyzing the results, the main conclusion was that those results fully coincided with the benchmark results acquired from the manual extraction. Such a conclusion was drawn after comparing the process rules from the benchmark and automatic transformation result sets for each of the 32 source models. It should be reminded though that some of the source models were refactored, as described in the Experiment settings, to objectively avoid invalid entries. Previously, our early experimenting with the original, and therefore sometimes invalid, models was causing a certain number of invalid or even absent result entries. Registering and presenting such results in this paper was considered irrelevant as they were objectively influenced by the invalid source models and not by our development itself. However, such a situation confirmed the general observation from our other relevant model transformation research activities that modelers should put considerable effort into following best modeling practices and avoiding over-complex non-compliant models, thereby mitigating the possibility of different model interpretations, poor readability, and other related issues. Yet another important observation was that the results covered the entirety of the specified flow of work defined in the experimental process models, meaning the set of specified transformation rules and algorithms was sufficient for the given scope of the experiment. In addition, several other observations could be considered when talking about other possible applications of our development:  
* An empirical investigation of the acquired sets of process rules showed that those rulesets could provide enough business knowledge to reverse engineer the flows of the initial processes with very little expert assistance, provided the process rules were supported by the underlying business vocabulary enriched with the BPMN concept types. A more in-depth investigation of this subject, however, does not fall within the scope of this paper. * Assuming that the process model is one of the main sources of business knowledge for functional requirements elicitation, one could also consider utilizing the developed SBVR models for the same purpose. In such cases, the SBVR business vocabularies and rules could be used as an alternative, or at least a complementing, textual specification next to business process models and other sources of knowledge. Such an approach would fall in line with the already existing developments that use SBVR as one of the means to express requirements (e.g., [62]). * While some still prefer UML activity diagrams to BPMN process diagrams when modeling business processes, the earlier-discussed motivation behind using the complementing natural language-based SBVR specifications remains the same. Therefore, it would be worth exploring the possibilities of adopting our developed approach for UML as well. We assume that such an adoption would utilize a subset of modified model transformation rules from our current development and the basic model transformation scenario (Figure 1) would remain unchanged.