# TransformingBPMN Processes toSBVR Process Rules with
## 3 Transformation of BPMN Processes to SBVR Process Rules
### Transformation Rules
\begin{table}
\begin{tabular}{l l} \hline \hline \multicolumn{1}{c}{\(\mathbf{T_{i}}\)} & \multicolumn{1}{c}{**Transformation Rule Definition**} \\ \hline  & (* RP9.Case(c) *) \\  & (* Next is the first pattern rule of Case (c) *) \\  & (* Its permitted that \", _get(participant(y))_, \"_sends \"_, \"_(\"message\" 1 gc(msg))_, \"to \", _gc(participant(z))_, \".\"_; \\  & (* Next is the second pattern rule of Case (c) *) \\  & (* Next is a rule pattern variation when a receiving node is an event *) \\  & (* It is obligatory that \", _(_default_,_er(_d_))_) 1 _(_ctimetmed_,_e(_y_))_, \"when\", _gc(participant(z))_, \"_receives_\", (\"message\" 1 gc(msg) )_, \\  & _\"from\", gc(participant(y))_ 1 \\  & (* Next is a rule pattern variation when a receiving node is an activity *) \\  & (* It is obligatory that \" 1 \"It is permitted that\", _gc(participant(z))_, \"_receives_\", (\"message\" 1 gc(msg))_, \"_from\", gc(participant(y))_, \\  & **\"when\", _ep(participant(z), activity(j))_, \".\"_; \\  & (* The de condition formulation for both rule variations depends on the semantics of a specific target node the message flow is connected to (e.g., _Receive Message Task_ will always imply obligation, while a _Muntual Task_ with an incoming message flow attached to it - permission); the same holds true for the first pattern rule of the Case (d) of \(R\)P9 *) \\  & (* RP9.Case(c) *) \\  & (* Next is the first pattern rule of Case (d) *) \\  & (* It is obligatory that \" 1 \"It is permitted that\"), _gc(participant(y))_, \"_sends \"_, \"(\"message\" 1 gc(msg))_, \"to\", gc(participant(z))_, \\  & **\"when\", _(_extend_er(i)_)_ 1 _ctimetmed_,_e(_y_)_ 1 _ctimetplant(y)_, _activity(j)_)_, \".\"_; \\  & (* Next is the second pattern rule of Case (d) *) \\  & (* Next is a rule pattern variation when a receiving node is an event *) (\" \\  & It is obligatory that\", _\"_(_extend_er(j)_) 1 _ctimetmed_,_e(_y_)_), \"when\", (_gc(participant(z))_, \"_receives_\", (\"message\" 1 gc(msg))_, \"_from\", gc(mgg)_)_, _”_, gc(participant(y))_)_ \\  & (* Next is a rule pattern when a receiving node is an activity) \\  & (* Next is the obligatory that \" 1 \"It is permitted that\", _gc(participant(z))_, \"_receives_\", (\"message\" 1 gc(msg))_, \"_from\", gc(participant(y))_, \\  & **\"when\", _ev(participant(z))_, _activity(j)_)_, \".\"_; \\  & (* / RP9.Case(d) *) \\ \hline  & (* Next is an example of the first rule of Case (a) *) \\  & It is permitted that **ustomer _sends order to manager.** \\  & (* Next is an example of the second rule of Case (a) *) \\  & It is permitted that **manager _receives_ order _from_ customer.** \\  & (* Next is an example of the first rule of Case (b). The sending node is a send message event, which implies an obligation to act *) \\  & It is obligatory that ** customer _sends order to_ managerwhen order request is sent.** \\  & (* Next is an example of the second rule of Case (b) *) \\  & It is **permitted that **manager _receives_ order _from_ customer.** \\  & (* Next is an example of the first rule of Case (c) *) \\  & It is **permitted that **ustomer _sends order estimate confirmation to manager.** \\  & (* Next is an example of the second rule of Case (c). The receiving node is a receive message event, which implies an obligation for an even to happen when a message is received *) \\  & It is obligatory that **order estimate is confirmed when manager receives order estimate confirmation from customer**. \\  & (* Next is an example of the second rule of Case (c). The receiving node is a manual task, which implies a permission to act *) \\  & It is permitted that **manager _receives_ order estimate confirmation _from_ customerwhen manager _schedules_ order delivery date.** \\  & (* Next is an example of the first rule of Case (d) *) \\  & It is obligatory that **ustomer _sends_ message to manager** when order estimate is confirmed.** \\  & (* Next is an example of the second rule of Case (d). Note that the information about the message being received is stated implicitly, which naturally brings a certain level of ambiguity to the specification, especially when there is a number of messages being sent within a modeled process; therefore, it is advised to avoid implicit messages whenever possible, and this is one of the good practices for modeling processes *) \\  & It is obligatory that **confirmed order estimate is received** when manager _receives message from_ customer. \\ \hline  & \\ \end{tabular}  
* **Note that in patterns \(\mathbf{P_{i}}\)**, most of the listed BMMN concepts are supertypes, meaning that those elements generalize sets of subtypes. For example, in \(\mathbf{P_{i}}\), the identified _activity_ represents a BMMN concept _Activity_, which in BPMN is defined as a _Process_ step, e.g., _Task_, _Sab-Process_; or the _intermediate_event_ representing a BPMN _Intermediate Event_, which in BPMN has an extensive set of subtypes, e.g., _Message Intermediate Event_, _Timer Intermediate Event_. Such pattern modeling decision was made to reduce the representational complexity of \(\mathbf{P_{i}}\) thus avoiding cluttering the visual representation with the excessive level of detail. 2 The pattern \(T_{2}\) also holds several additional variations to handle specific cases of an exclusive gateway, which are not presented in this paper. The specific cases include handling of _default_ sequence flows that hold no condition expressions (those are handled through formulating joins of negations of the conditions of all the other sequence flows diverging from that exclusive gateway) or exclusive gateways with no condition expressions on any of the diverging sequence flows (which is considered a bad modeling practice but still used quite often). 3 The pattern \(T_{3}\) holds two process patterns \(\mathbf{P_{i}}\) resulting in the same rule pattern \(\mathbf{P_{j}}\): (1) the one presented in the paper with a set of _sequence flows_ diverging from an _inclusive gateway_; (2) the second one with a set of two or more _conditioned sequence flows_ diverging from _activity(i)_, which is an alternative to a diverging inclusive gateway. These two cases were merged into one pattern for simplicity reasons.  
\end{table}