# TransformingBPMN Processes toSBVR Process Rules with
## 3 Transformation of BPMN Processes to SBVR Process Rules
### Extracting Process Rules from Multiple Cascading Gateways
```
Input:BPMN element \(el\): \(type(el)\in\)Task, Event, SubProcess\(A_{N}^{el}\) \(\leftarrow\) activity node neighbourhood for el \(S_{inc}^{el}\leftarrow\{source(SF_{inc})|source(SF_{inc})\text{ is gateway and target}(SF_{inc})=el\}\) if\(S_{inc}^{el}=\varnothing\): Run extract \(T_{i}\) rule; Return\(\varnothing\) FinalRules\(\leftarrow\varnothing\) For \(SF\in SF_{inc}^{el}\): \(\mathcal{G}_{N}^{el}\) \(\leftarrow\)\(G_{N}\) for gateway in \(source(SF)\) createPartialRule\((G_{N}^{el})\) \(\leftarrow\) FinalRules\(\cup\)\(concat\big{(}extractRule\big{(}A_{N}^{el}\big{)}\), \(C_{N}^{el}\cdot R_{part}\big{)}\) End for Output: a set of extracted rules FinalRules. ```  
**Algorithm 1**extractComplexRules  
The procedure _createPartialRule_ is based on the detection of the so-called _boundary gateway_. We define a gateway as a _boundary_ if it does not contain any incoming sequence flows with other gateways as their sources (\(\mathcal{G}_{Ninc}\) is empty). For boundary gateways, rules \(T_{2}\), \(T_{3}\), \(T_{4}\), and \(T_{5}\) can be directly applied to extract partial rules that are further combined recursively. The pseudocode for this procedure is provided in Algorithm 2. The developed approach is capable of processing chains composed of a virtually unlimited number of sub-sequential gateways. However, one should consider good modeling practices stating that modeling decisions via multiple cascading gateways should be avoided as this results in over-complex process rules, which in turn may result in poor readability and understandability of the presented business process logic by humans. To illustrate the presented algorithms, we will use the example from Section 5. Let us consider the following process rule:  
It is obligatory that order request _is rejected_after provider _analyzes_ orderand (provider _evaluates_ extra conditionsif order _has_ extra conditions) and if order _cannot be fulfilled_. The formation of this rule starts from the event _order request is rejected_. This element has an incoming sequence flow and a gateway element at the start of the chain under consideration (i.e., the source element), therefore we can identify the instance gateway neighborhood. Yet, this is not a boundary gateway as it has a sequence flow incoming from another preceding gateway. In turn, that preceding gateway is connected with the tasks _analyze order_ and _evaluate extra conditions_ acting as source elements for the connecting sequence flows. Hence, we move to this gateway as it has no directly connecting preceding gateways and mark it as a boundary gateway. As mentioned, this gateway has two incoming task elements, namely, _analyze order_ and _evaluate extra conditions_. These tasks are used to create partial antecedent conditions provider _analyzes_ order and (provider _evaluates_ extra conditionsif order _has_ extra conditions) with the latter \"if...\" formulation taken from the guard condition of the sequence flow incoming to the task _evaluate extra conditions_. Finally, we append the guard condition _order cannot be fulfilled_ from the sequence flow connecting to the event _order request is rejected_ with the gateway element that represents the condition required to trigger this event. Internally, these elements are assigned to the gateway neighborhood structures, which are then used to form our process rule.