Transforming BPMN Processes to SBVR Process Rules with Deontic Modalities
Abstract
:1. Introduction
2. Related Work
2.1. State of the Art Research
2.2. Concepts’ Definitions, Issues, and Pre-Conditions to Be Considered
3. Transformation of BPMN Processes to SBVR Process Rules
3.1. Transformation Scenario
3.2. Transformation Rules
3.3. Extracting Process Rules from Multiple Cascading Gateways
- activity is an activity node: (type(activity){Task, Event, SubProcess};
- Sact is a set of subjects performing the defined activity;
- SFinc is a set of sequence flows incoming to the activity act, with or without conditions;
- SFout is a set of sequence flows outgoing from the activity, with or without conditions;
- is a set of default sequence flows incoming to the activity;
- is a set of default sequence flows outgoing from the activity.
- gate is a BPMN gateway node;
- type is a type of the defined gateway gate (type{inclusive, exclusive, event-based, parallel});
- is a set of activities incoming to the gateway gate;
- is a set of activities outgoing from the gateway gate;
- is a set of other gateways incoming to the gateway gate;
- is a set of other gateways outgoing from the gateway gate;
- SFinc is a set of incoming to the gateway gate, with or without conditions;
- SFout is a set of outgoing from the gateway gate, with or without conditions;
- is a set of default sequence flows incoming to the gateway gate;
- is a set of default sequence flows outgoing from the gateway gate;
- is a partial rule, recursively extracted at the gateway gate.
Algorithm 1: extractComplexRules |
Input: BPMN element el: type(el) {Task, Event, SubProcess} activity node neighbourhood for el If Run extract T1 rule; Return FinalRules For createPartialRule() End for Output: a set of extracted rules FinalRules. |
Algorithm 2: createPartialRule |
Input: gateway neighborhood GN. If extractSimpleRule(GN) Return GN defaultCond # First process gateways For createPartialRule() create partial antecedent from conditions in if defaultCond defaultCond else End for # Then process activities For create partial antecedent from conditions in if defaultCond defaultCond else End for # Finally, add default conditions If For cond defaultCond End for Output: updated gateway neighborhood GN. |
It is obligatory that order request is rejected after provider analyzesorder and (provider evaluatesextra conditions if order hasextra conditions) and if order cannot be fulfilled.
4. Implementation
- -
- MagicDraw is a CASE system supporting the newest official versions of UML, BPMN, and some other OMG modeling standards. However, it does not natively support any version of SBVR, which is extensively used in our approach. Yet, MagicDraw has Open Java API, enabling the development of custom plug-ins. It also has other advanced capabilities for UML profiling, analysis, and reporting, as well as domain-specific language (DSL) development.
- -
- SBVR modeler plug-in for MagicDraw, which uses a UML profile for SBVR. Both the plug-in and the profile were developed during the VEPSEM project, in which the authors of this paper also took part. In the CASE system, SBVR business vocabulary is graphically represented as a set of so-called fact diagrams. The plug-in also supports the specification of SBVR business rules as formal text-based expressions.
- -
- External SBVR editor VeTIS is a tool developed during another R&D project, VeTIS. The editor supports the development and syntactic validation of SBVR business vocabularies and business rules expressed as well-structured natural language-based textual specifications. It supports various additional properties of SBVR concepts defined in the SBVR standard and is also capable of augmenting business vocabulary entries with complementary information, such as synonyms and definitions for general concepts from WordNet.
- -
- Tool for BPMN process transformation to SBVR process rules is also implemented as a plug-in for the MagicDraw and is entirely developed by the authors of this paper. The tool implements both automatic model-to-text (to be used in the VeTIS editor) and model-to-model transformations, which may be called out selectively from the context menu of the CASE system’s modeling environment. The specified model transformation rules were implemented using the QVT model transformation language [61]. We consider the model transformation component to be of technology readiness level 4 (TRL 4) (the referred technology readiness levels are defined in the HORIZON 2020 documentation and can be accessed at: https://ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020-wp1415-annex-g-trl_en.pdf (accessed on 29 August 2022)), meaning this development was tested in the laboratory environment.
- -
- Model integration plug-in provides model integration capability and QVT transformation engine basis. This plug-in was developed during the VEPSEM project.
- -
- The input and output models (BPMN process model and SBVR business vocabulary and process rules, respectively) are displayed in the model view tab of the CASE tool (Tag 1). The presented models are stored as a single project representing the specified business knowledge of a business domain.
- -
- Tag 2 denotes a toolbar comprising SBVR concepts for creating visual representations of SBVR business vocabularies (fact diagrams).
- -
- In the center, there is the main area for deploying diagrams (Tag 3). The current view displays a fact diagram “Order Registration”.
- -
- On the right side of the CASE tool’s graphical user interface, there is an additional viewer dedicated to exploring SBVR business vocabularies and rulesets (Tag 4).
- -
- At the bottom, there is an optional frame opened to view a BPMN process diagram (Tag 5). Functionally, this frame is similar to the main frame representing the SBVR working environment. In MagicDraw, these two frames can switch places depending on the main focus of a user.
- -
- The pop-up window (Tag 6) displays a condition of the opened BPMN process diagram, specified using so-called SBVR Structured English (SE).
5. Illustrative Example
6. Experimental Evaluation
- -
- 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.
- The processes should use pool/lane elements to define the participants. If this condition is failed, it will not be possible to extract subjects as noun concepts, which take part in the formation of verb concepts and, subsequentially, business rules.
- While we did not consider the semantic and syntactic validity of the labels (in other words, names) of model elements in this research, not naming the elements at all would result in the formation of invalid process rules.
- While there exist several conventions about naming conditions on exclusive and inclusive gateways, the specificity of the formation of SBVR verb concepts requires writing explicit condition formulations directly on the sequence flows leaving a gateway. Technical remark: the conditions can be written in the Name, or the Guard property of a sequence flow as shown in the exemplary process diagram in Figure 5.
7. Threats to Validity
8. Conclusions
Author Contributions
Funding
Conflicts of Interest
References
- Leopold, H.; Mendling, J.; Polyvyanyy, A. Generating Natural Language Texts from Business Process Models. In Advanced Information Systems Engineering, LNCS, Proceedings of the 24th International Conference, CAiSE 2012, Gdansk, Poland, 25–29 June 2012; Springer: Berlin/Heidelberg, Germany, 2012; Volume 7328, pp. 64–79. [Google Scholar] [CrossRef]
- Wipp, W. Natural Language-Based Visualization and Modeling for Updatable Process Views. Bachelor’s Thesis, Faculty of Engineering and Computer Science Institute of Databases and Information Systems, Ulm University, Ulm, Germany, 2013. [Google Scholar]
- Leopold, H.; Mendling, J.; Polyvyanyy, A. Supporting process model validation through natural language generation. IEEE Trans. Softw. Eng. 2014, 40, 818–840. [Google Scholar] [CrossRef]
- Rodrigues, R.A.; Azevedom, L.G.; Revoredo, K. BPMN2TEXT: A Language-Independent Framework to Generate Natural Language Text from BPMN models. iSys-Braz. J. Inf. Syst. 2016, 9, 38–56. [Google Scholar] [CrossRef]
- Ottensooser, A.; Fekete, A.; Reijers, H.A.; Mendling, J.; Menictas, C. Making sense of business process descriptions: An experimental comparison of graphical and textual notations. J. Syst. Softw. 2012, 85, 596–606. [Google Scholar] [CrossRef]
- Figl, K.; Recker, J. Exploring cognitive style and task-specific preferences for process representations. Requir. Eng. 2016, 21, 63–85. [Google Scholar] [CrossRef]
- Object Management Group. MDA Guide Revision 2.0; OMG Document Number: Ormsc/14-06-01; Object Management Group: Needham, MA, USA, 2014. [Google Scholar]
- Object Management Group. Semantics of Business Vocabulary and Business Rules (SBVR) Specification, version 1.4; OMG Document Number: Formal/17-05-05; Object Management Group: Needham, MA, USA, 2017. [Google Scholar]
- Object Management Group. Business Process Model and Notation (BPMN), version 2.0.1; OMG Document Number: Formal/2013-09-02; Object Management Group: Needham, MA, USA, 2013. [Google Scholar]
- Krogstie, J.; McBrien, P.; Owens, R.; Seltveit, A.H. Information systems development using a combination of process and rule based approaches. In Advanced Information Systems Engineering, LNCS, Proceedings of the Third International Conference CAiSE’91, Trondheim, Norway, 13–15 May 1991; Springer: Berlin/Heidelberg, Germany, 1991; Volume 498, pp. 319–335. [Google Scholar] [CrossRef]
- Habich, D.; Richly, S.; Demuth, B.; Gietl, F.; Spilke, J.; Lehner, W.; Assman, U. Joining Business Rules and Business Processes. In Proceedings of the 16th International Conference on Information and Software Technologies (ICIST), Kaunas, Lithuania, 21–23 April 2010; pp. 361–368. [Google Scholar]
- Sapkota, B.; van Sinderen, M. Exploiting rules and processes for increasing flexibility in service composition. In Proceedings of the 14th IEEE International Conference on Enterprise Distributed Object Computing Conference Workshops (EDOCW), Vitoria, Brazil, 25–29 October 2010; pp. 177–185. [Google Scholar] [CrossRef]
- Koehler, J. The Process-Rule Continuum—Can BPMN & SBVR Cope with the Challenge? In Proceedings of the 2011 IEEE 13th Conference on Commerce and Enterprise Computing, Luxembourg-Kirchberg, Luxembourg, 5–7 September 2011; pp. 302–309. [Google Scholar] [CrossRef]
- Milanovic, M.; Gaševic, D.; Rocha, L. Modeling Flexible Business Process with Business Rule Patterns. In Proceedings of the 15th IEEE International Enterprise Distributed Object Computing Conference, Helsinki, Finland, 29 August–2 September 2011; pp. 65–74. [Google Scholar] [CrossRef]
- Nalepa, G.J.; Kluza, K.; Kaczor, K. Proposal of an Inference Engine Architecture for Business Rules and Processes. In Artificial Intelligence and Soft Computing, LNCS, Proceedings of the 12th International Conference, ICAISC 2013, Zakopane, Poland, 9–13 June 2013; Springer: Berlin/Heidelberg, Germany, 2013; pp. 453–464. [Google Scholar] [CrossRef]
- Wang, W.; Indulska, M.; Sadiq, S. A Theoretical Perspective on Integrated Modeling of Business Processes and Rules. In Proceedings of the 28th International Conference on Advanced Information Systems Engineering (CAiSE Forum), Ljubljana, Slovenia, 13–17 June 2016; Springer: Ljubljana, Slovenia, 2016. [Google Scholar]
- Kluza, K.; Nalepa, G.J. A Method for Generation and Design of Business Processes with Business Rules. Inf. Softw. Technol. 2017, 91, 123–141. [Google Scholar] [CrossRef]
- Kluza, K.; Nalepa, G.J. Formal Model of Business Processes Integrated with Business Rules. Inf. Syst. Front. 2018, 21, 1167–1185. [Google Scholar] [CrossRef]
- Rosa, L.S.; Silva, T.S.; Fantinato, M.; Thom, L.H. A visual approach for identification and annotation of business process elements in process descriptions. Comput. Stand. Interfaces 2022, 81, 103601. [Google Scholar] [CrossRef]
- Aysolmaz, B.; Leopold, H.; Reijers, H.A.; Demirörs, O. A semi-automated approach for generating natural language requirements documents based on business process models. Inf. Softw. Technol. 2018, 93, 14–29. [Google Scholar] [CrossRef]
- Vanhatalo, J.; Volzer, H.; Leymann, F. Faster and More Focused Control-Flow Analysis for Business Process Models Through SESE Decomposition. In Service-Oriented Computing—ICSOC 2007, LNCS, Proceedings of the Fifth International Conference, Vienna, Austria, 17–20 September 2007; Springer: Berlin/Heidelberg, Germany, 2007; Volume 4749, pp. 43–55. [Google Scholar] [CrossRef]
- Goncalves, J.C.; Santoro, F.M.; Baiao, F.A. Let Me Tell You a Story—On How to Build Process Models. J. Univers. Comput. Sci. 2011, 17, 276–295. [Google Scholar] [CrossRef]
- Friedrich, F.; Mendling, J.; Puhlmann, F. Process Model Generation from Natural Language Text. In Advanced Information Systems Engineering, LNCS, Proceedings of the 23rd International Conference, CAiSE 2011, London, UK, 20–24 June 2011; Springer: Berlin/Heidelberg, Germany, 2011; Volume 6741, pp. 482–496. [Google Scholar] [CrossRef]
- Vakulenko, S. Extraction of Process Models from Business Process Descriptions. Master’s Thesis, University of Tartu, Tartu, Estonia, 2011. [Google Scholar]
- Van der Aa, H.; Carmona, J.; Leopold, H.; Mendling, J.; Padro, L. Challenges and Opportunities of Applying Natural Language Processing in Business Process Management. In Proceedings of the 27th International Conference on Computational Linguistics, Santa Fe, NM, USA, 20–26 August 2018; pp. 2791–2801. Available online: http://aclweb.org/anthology/C18-1236 (accessed on 10 July 2022).
- Spreeuwenberg, S. Interview with Rob van Haarst, Author of the Recently-published Book “SBVR Made Easy”. Bus. Rules J. 2014, 15. Available online: http://www.brcommunity.com/a2014/b747.html (accessed on 10 July 2022).
- Nijssen, S. SBVR & BPMN as Pillars of Business Engineering. Bus. Rules J. 2008, 9. Available online: http://www.brcommunity.com/a2008/b447.html (accessed on 10 July 2022).
- Zur Muehlen, M.; Indulska, M. Modeling Languages for Business Processes and Business Rules: A Representational Analysis. Inf. Syst. J. 2010, 35, 379–390. [Google Scholar] [CrossRef]
- Eder, R.; Filieri, A.; Kurz, T.; Heistracher, T.J.; Pezzuto, M. Model-transformation-based software Generation Utilizing Natural Language Notations. In Proceedings of the 2nd IEEE International Conference on Digital Ecosystems and Technologies (DEST), Phitsanuloke, Thailand, 26–29 February 2008; pp. 306–312. [Google Scholar] [CrossRef]
- Moschoyiannis, S.; Marinos, A.; Krause, P.J. Generating SQL Queries from SBVR Rules. In Semantic Web Rules, Proceedings of the International Symposium, RuleML 2010, Washington, DC, USA, 21–23 October 2010; Springer: Berlin/Heidelberg, Germany, 2010. [Google Scholar] [CrossRef] [Green Version]
- Karpovic, J.; Ablonskis, L.; Nemuraitė, L.; Paradauskas, B. Experimental investigation of transformations from SBVR business vocabularies and business rules to OWL 2 ontologies. Inf. Technol. Control 2016, 45, 195–207. [Google Scholar] [CrossRef]
- Essebaa, I.; Chantit, S. Tool Support to Automate Transformations from SBVR to UML Use Case Diagram. In Proceedings of the 13th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE), Funchal, Portugal, 23–24 March 2018; pp. 525–532. [Google Scholar] [CrossRef]
- Agrawal, A. Semantics of Business Process Vocabulary and Process Rules. In Proceedings of the 4th India Software Engineering Conference (ISEC), Kerala, India, 24–27 February 2011; pp. 61–68. [Google Scholar] [CrossRef]
- Cheng, R.; Sadiq, S.; Indulska, M. Framework for Business Process and Rule Integration: A Case of BPMN and SBVR. In Business Information Systems, LNBIP, Proceedings of the14th International Conference, BIS 2011, Poznań, Poland, 15–17 June 2011; Springer: Berlin/Heidelberg, Germany, 2011; Volume 87, pp. 13–24. [Google Scholar] [CrossRef]
- Skersys, T.; Tutkute, L.; Butleris, R.; Butkiene, R. Extending BPMN Business Process Model with SBVR Business Vocabulary and Rules. Inf. Technol. Control 2012, 41, 356–367. [Google Scholar] [CrossRef]
- Skersys, T.; Kapocius, K.; Butleris, R.; Danikauskas, T. Extracting Business Vocabularies from Business Process Models: SBVR and BPMN Standards-based Approach. Comput. Sci. Inf. Syst. 2014, 11, 1515–1535. [Google Scholar] [CrossRef]
- Mickeviciute, E.; Butleris, R.; Gudas, S.; Karciauskas, E. Transforming BPMN 2.0 Business Process Model into SBVR Business Vocabulary and Rules. Inf. Technol. Control 2017, 46, 360–371. [Google Scholar] [CrossRef]
- Malik, S.; Bajwa, I.S. A Rule Based Approach for Business Rule Generation from Business Process Models. In Rules on the Web: Research and Applications, LNCS, Proceedings of the 6th International Symposium, RuleML 2012, Montpellier, France, 27–29 August 2012; Springer: Berlin/Heidelberg, Germany, 2012; Volume 7438, pp. 92–99. [Google Scholar] [CrossRef]
- Malik, S.; Bajwa, I.S. Back to Origin: Transformation of Business Process Models to Business Rules. In Business Process Management Workshops, Proceedings of the BPM 2012 International Workshops, LNBIP, Tallinn, Estonia, 3 September 2012; Springer: Berlin/Heidelberg, Germany, 2012; Volume 132, pp. 611–622. [Google Scholar] [CrossRef]
- Al-Ali, H.; Damiani, E.; Al-Qutayri, M.; Abu-Matar, M.; Mizouni, R. Translating BPMN to Business Rules. In Data-Driven Process Discovery and Analysis, Proceedings of the 6th IFIP WG 2.6 International Symposium, SIMPDA 2016, Graz, Austria, 15–16 December 2016; Springer: Cham, Switzerland, 2016; pp. 22–36. [Google Scholar]
- Rachdi, A.; En-Nouaary, A.; Dahchour, M. Analysis of common business rules in BPMN process models using business rule language. In Proceedings of the 11th International Conference on Intelligent Systems: Theories and Applications (SITA), Mohammedia, Morocco, 19–20 October 2016; pp. 1–6. [Google Scholar] [CrossRef]
- Steen, B.; Pires, L.F.; Iacob, M. Automatic generation of optimal business processes from business rules. In Proceedings of the 4th IEEE International Enterprise Distributed Object Computing Conference Workshops, Vitoria, Brazil, 25–29 October 2010; pp. 117–126. [Google Scholar]
- Wu, Z.; Yao, S.; He, G.; Xue, G. Rules Oriented Business Process Modeling. In Proceedings of the Internet Technology and Applications (iTAP), Wuhan, China, 16–18 August 2011; pp. 1–4. [Google Scholar] [CrossRef]
- Tantan, O.C.; Akoka, J. Automated transformation of Business Rules into Business Processes. In Proceedings of the Twenty-Sixth International Conference on Software Engineering and Knowledge Engineering, Vancouver, Canada, 1–3 July 2014; pp. 684–687. [Google Scholar]
- Addamssiri, N.; Kriouile, A.; Boussaa, S.; Gadi, T. MDA Approach: Refinement and Validation of CIM Level Using SBVR. In Proceedings of the Mediterranean Conference on Information & Communication Technologies, Saïdia, Morocco, 7–9 May 2015. [Google Scholar] [CrossRef]
- Kluza, K.; Honkisz, K. From SBVR to BPMN and DMN Models. Proposal of Translation from Rules to Process and Decision Models. In Artificial Intelligence and Soft Computing, LNCS, Proceedings of the 5th International Conference, ICAISC 2016, Zakopane, Poland, 12–16 June 2016; Springer: Cham, Switzerland, 2016; Volume 9693, p. 9693. [Google Scholar] [CrossRef]
- Elkindy, A.I.A. Survey of Business Process Modeling Recommender Systems. Master’s Thesis, Universitat Koblenz-Landau, Mainz, Germany, 2019. Available online: https://kola.opus.hbz-nrw.de/frontdoor/index/index/docId/1895 (accessed on 10 July 2022).
- Sola, D.; van der Aa, H.; Meilicke, C.; Stuckenschmidt, H. Exploiting label semantics for rule-based activity recommendation in business process modeling. Inf. Syst. 2022, 108, 102049. [Google Scholar] [CrossRef]
- Deng, S.; Wang, D.; Li, Y.; Cao, B.; Yin, J.; Wu, Z.; Zhou, M. A Recommendation System to Facilitate Business Process Modeling. IEEE Trans. Cybern. 2017, 47, 1380–1394. [Google Scholar] [CrossRef]
- Gottesdiener, E. Business RULES Show Power, Promise. Appl. Dev. Trends 1977, 4, 36–42. Available online: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.329.8585&rep=rep1&type=pdf (accessed on 10 July 2022).
- Ross, R. The Business Rule Book: Classifying, Defining and Modeling Rules, 2nd ed.; Business Rule Solutions Inc.: Houston, TX, USA, 1997. [Google Scholar]
- Business Rules Group. Defining Business Rules—What Are They Really? Final Report, Revision 1.3, July, 2000 (Formerly Known as the “GUIDE Business Rules Project Report,” 1995). Available online: http://www.businessrulesgroup.org/first_paper/BRG-whatisBR_3ed.pdf (accessed on 10 July 2022).
- Vanthienen, J.; Goedertier, S. How Business Rules Define Business Processes. Bus. Rules J. 2007, 8. Available online: http://www.brcommunity.com/a2007/b336.html (accessed on 10 July 2022).
- Baisley, D.E. A Metamodel for Business Vocabulary and Rules: Object-Oriented Meets Fact-Oriented. Bus. Rules J. 2004, 5. Available online: http://www.brcommunity.com/a2004/b197.html (accessed on 10 July 2022).
- Cabot, J.; Pau, R.; Raventos, R. From UML/OCL to SBVR specifications: A challenging transformation. Inf. Syst. 2010, 35, 417–440. [Google Scholar] [CrossRef]
- Kleiner, M.; Albert, P.; Bezivin, J. Parsing SBVR-Based Controlled Languages. In Model Driven Engineering Languages and Systems, Proceedings of the 12th International Conference, MODELS 2009, LNCS, Denver, CO, USA, 4–9 October 2009; Springer: Berlin/Heidelberg, Germany, 2009; Volume 5795, pp. 122–136. [Google Scholar] [CrossRef]
- Business Rules Group (BRG). The Business Rules Manifesto. 2003. Available online: Businessrulesgroup.org/brmanifesto.htm (accessed on 10 July 2022).
- Skersys, T.; Danenas, P.; Butleris, R. Extracting SBVR business vocabularies and business rules from UML use case diagrams. J. Syst. Softw. 2018, 141, 111–130. [Google Scholar] [CrossRef]
- Czarnecki, K.; Helsen, S. Classification of Model Transformation Approaches. In Proceedings of the 2nd OOPSLA Workshop on Generative Techniques in the Context of the Model Driven Architecture, Twente, The Netherlands, 26–27 June 2003; Volume 45, pp. 1–17. [Google Scholar]
- Mens, T.; van Gorp, P. A Taxonomy of Model Transformation. Electron. Notes Theor. Comput. Sci. 2006, 152, 125–142. [Google Scholar] [CrossRef]
- Object Management Group. Query/View/Transformation (QVT), version 1.1; OMG Document Number: Formal/2011-01-01; Object Management Group: Needham, MA, USA, 2011. [Google Scholar]
- Danenas, P.; Skersys, T.; Butleris, R. Natural language processing-enhanced extraction of SBVR business vocabularies and business rules from UML use case diagrams. Data Knowl. Eng. 2020, 128, 101822. [Google Scholar] [CrossRef]
- Runeson, P.; Höst, M.; Rainer, A.; Regnell, B. Case Study Research in Software Engineering: Guidelines and Examples; John Wiley & Sons: Hoboken, NJ, USA, 2012. [Google Scholar]
Ti | Transformation Rule Definition | |
---|---|---|
T1 | PP11 | Pattern with a sequence flow: |
RP1 | (* RP1 *) “It is obligatory that ”, (vc(end_ev(n)) | vc(intermed_ev(n)) | vc(participant(z), activity(n))), “after”, (vc(start_ev(m)) | vc(intermed_ev(m)) | vc(participant(z), activity(m))), [“and if”, vc(cond(i))], “.”; (* /RP1 *) | |
E.g., | (* Next are examples of process rules acquired from the basic process pattern consisting of two sub-sequential flow objects*) It is obligatory that manager registers order after order is received. It is obligatory that order is completed after ordered production is delivered. It is obligatory that order calculatesorder estimateaftermanager receives registered order and iforder information is correct. | |
T22 | PP2 | Pattern with diverging and | or converging exclusive gateway(s): |
RP2 | (* RP2.div *) (* RULE PATTERN PART FOR A DIVERGING EXCLUSIVE GATEWAY: *) (* Repeat for every diverging sequence flow seq_flow(j) (where j = j,…,jj, n = n,…,nn) *) { (* If sequence flow seq_flow(j) contains condition cond(j) *) (“It is obligatory that ”, (vc(end_ev(n)) | vc(intermed_ev(n)) | vc(participant(z), activity(n)) ), “after”, (vc(start_ev(m)) | vc(intermed_ev(m)) | vc(participant(z), activity(m))), “ and if”, vc(cond(j)), [ “and”, vc(cond(i)) ], “.”;) | (* If sequence flow seq_flow(j) does not contain condition cond(j) *) (“It is permitted that”, (vc(end_ev(n)) | vc(intermed_ev(n)) | vc(participant(z), activity(n))), “after”, (vc(start_ev(m)) | vc(intermed_ev(m)) | vc(participant(z), activity(m))), [ “and if”, vc(cond(i))], “.”;) } (* /RP2.div *) | |
(* RP2.conv *) (* RULE PATTERN PART FOR A CONVERGING EXCLUSIVE GATEWAY: *) (* Next is an RP part for the first converging seq_flow(k) (where k = k, n = n) *) “It is obligatory that ”, (vc(end_ev(t)) | vc(intermed_ev(t)) | vc(participant(z), activity(t))), “after”, (vc(intermed_ev(n)) | vc(participant(z), activity(n))), [“and if”, vc(cond(k)) ], (* Next is an RP part for every next converging seq_flow(k) (where k = k + 1,…,kk, n = n + 1,…,nn) *) {“or”, (vc(intermed_ev(n)) | vc(participant(z), activity(n)), [“and if”, vc(cond(k))]}, “.”; (* /RP2.conv *) | ||
E.g., | (* Next is an example with two process rules acquired from two diverging branches of an exclusive gateway*) It is obligatory that manager assigns platinum order status after order is registered and if customer is_a platinum customer. It is obligatory that manager assigns normal order status after order is registered and if customer is_a first-comer customer. (* Next is an example with a converging exclusive gateway *) It is obligatory that order is rejected after manager rejects order and if customer is_a first-comer customer or order confirmation is past due. | |
T3 3 | PP3 | Pattern with diverging and | or converging inclusive gateway(s): |
RP3 | (* RP3.div *) (* RULE PATTERN PART FOR A DIVERGING INCLUSIVE GATEWAY: *) (* Repeat for every diverging sequence flow seq_flow(j) (where j = j,…,jj, n = n,…,nn) *) { “It is obligatory that ”, ( vc(end_ev(n)) | vc(intermed_ev(n)) | vc(participant(z), activity(n)) ), “after”, (vc(start_ev(m)) | vc(intermed_ev(m)) | vc(participant(z), activity(m))), [ “ and if”, vc(cond(j)) ], [ “and”, vc(cond(i)) ], “.”; } (* /RP3.div *) | |
(* RP3.conv *) (* RULE PATTERN PART FOR A CONVERGING INCLUSIVE GATEWAY: *) “It is obligatory that”, ( vc(end_ev(t)) | vc(intermed_ev(t)) | vc(participant(z), activity(t)) ), “ after”, (* Next is an RP part for the first converging seq_flow(k) (where j = j, k = k, n = n) *) [“(”], (vc(vc(intermed_ev(n)) | vc(participant(z), activity(n))), [“if”, vc(cond(j))], [“and”, vc(cond(k)), “)”], (* Next is an RP part for every next converging seq_flow(k) (where j = j + 1, k = k + 1,…,kk, n = n + 1,…,nn) *) { “and”, [“(”], ( vc(intermed_ev(n)) | vc(participant(z), activity(n))), [“if”, vc(cond(j))], [“and”, vc(cond(k)), “)”] }, “.”; (* /RP3.conv *) | ||
E.g., | (* Next is an example with two process rules acquired from two diverging branches of an inclusive gateway*) It is obligatory that quality worker attaches quality certificate after ordered production is packaged. It is obligatory that expeditor adds extra packaging layer after ordered production is packaged and if ordered production is a fragile production. (* Next is an example with a converging inclusive gateway *) It is obligatory that expeditor delivers ordered production after quality worker attaches quality certificate and (expeditor adds extra packaging layer if ordered production is a fragile production). | |
T4 | PP4 | Pattern with diverging event-based gateway: |
RP4 | (* RP4 *) (* Repeat for every diverging sequence flow seq_flow(j) (where j = j,…,jj) *) { “It is permitted that ”, (vc(end_ev(n)) | vc(intermed_ev(n))), “after”, (vc(start_ev(m)) | vc(intermed_ev(m)) | vc(participant(z), activity(m))), [“ and if”, vc(cond(i))], “.”; } (* /RP4 *) | |
E.g., | (* Next is an example with two process rules acquired from two diverging branches of an even-based gateway *) It is permitted that order confirmation is received after manager sends order confirmation request. It is permitted that order rejection is received after manager sends order confirmation request. | |
T5 | PP5 | Pattern with diverging and | or converging parallel gateway(s): |
RP5 | (* RP5.div *) (* RULE PATTERN PART FOR A DIVERGING PARALLEL GATEWAY: *) (* Repeat for every diverging sequence flow seq_flow(j) (where j = j,…,jj, n = n,…,nn) *) { “It is obligatory that ”, (vc(intermed_ev(n)) | vc(participant(z), activity(n)) ), “ after”, (vc(start_ev(m)) | vc(intermed_ev(m)) | vc(participant(z), activity(m))), [“ and if”, vc(cond(i))], “.”; } (* /RP5.div *) | |
(* RP5.conv *) (* RULE PATTERN PART FOR A CONVERGING PARALLEL GATEWAY: *) “It is obligatory that ”, (vc(end_ev(t)) | vc(intermed_ev(t)) | vc(participant(z), activity(t)) ), “after”, (* Next is an RP part for the first converging seq_flow(k) (where k = k, n = n) *) [“(”], (vc(vc(intermed_ev(n)) | vc(participant(z), activity(n)) ), [“if”, vc(cond(k)), “)”], (* Next is an RP part for every next converging seq_flow(k) (where k = k + 1,…,kk, n = n + 1,…,nn) *) { “and”, [“(”], (vc(intermed_ev(n)) | vc(participant(z), activity(n))), [“if”, vc(cond(k)),“)”]}, “.”; (* /RP5.conv *) | ||
E.g., | (* Next is an example with two process rules acquired from two diverging branches of a parallel gateway *) It is obligatory that quality worker executes quality check after ordered production is produced. It is obligatory that expeditor schedules order delivery date after ordered production is produced. (* Next is an example with a converging parallel gateway *) It is obligatory that order is completed after ordered production is delivered and order invoice is fully covered. | |
T6 | PP6 | Pattern with interrupting | non-interrupting boundary event: |
RP6 | (* RP6 *) “It is permitted that ”, (vc(non-interrupt_ev(k)) | vc(interrupt_ev(k))), “when”, vc(participant(z), activity(i)), “.”; “It is obligatory that”, (vc(end_ev(j)) | vc(intermed_ev(j)) | vc(participant(z), activity(j))), “after (”, (vc(non-interrupt_ev(k)) | vc(interrupt_ev(k))), “ when”, vc(participant(z), activity(i)),“).”; (* ADDITIONAL RULE TO THE RULE PATTERN FOR AN INTERRUPTING BOUNDARY EVENT: *) [ “It is prohibited that”, vc(participant(z), activity(i)), “after”, vc(interrupt_ev(k)), “.”;] (* /RP6 *) | |
E.g., | (* Next is an example with a set of process rules expressing behavior of an interrupting boundary event *) It is permitted that order cancellation is received when manager registers order. It is obligatory that manager cancels order after (order cancellation is received when manager registers order). It is prohibited that manager registers order after order cancellation is received. | |
T7 | PP7 | Pattern with two semantically equivalent variations of using data object with: (a) data association, and (b) association: |
RP7 | (* RP7.out *) (* RULE PATTERN PART FOR AN OUTGOING DATA OBJECT (DATA OUTPUT): *) (* Next is an RP part for the first data object (data output) produced by an activity | event (n = n) *) “It is obligatory that ”, (gc(data_obj(n)) | gc(data_obj_in-state(n))), “is produced”, (* Next is an RP part for every next data object (data output) produced by an activity | event (n = n + 1,…,nn) *) [{“and ”, (gc(data_obj(n)) | gc(data_obj_in-state(n))), “is produced”}], “when”, (vc(start_ev(i)) | vc(intermed_ev(i)) | vc(participant(z), activity(i))), “.”; (* /RP7.out *) | |
(* RP7.in *) (* RULE PATTERN PART FOR AN INCOMMING DATA OBJECT (DATA INPUT): *) (* Next is an RP part for the first data object (data input) required by an activity | event (n = n) *) “It is permitted that ”, (vc(end_ev(j)) | vc(intermed_ev(j)) | vc(participant(z), activity(j))), “ only if ”, (gc(data_obj(n)) | gc(data_obj_in-state(n))), “is provided to ”, gc(participant(z)), (* Next is an RP part for every next data object (data input) required by an activity | event (n = n + 1,…,nn) *) [{“and”, (gc(data_obj(n)) | gc(data_obj_in-state(n))), “is provided to”, gc(participant(z))}], “.”; (* /RP7.in *) | ||
E.g., | (* Next is an example with a produced (outgoing) data object *) It is obligatory that registered order is produced and production request is produced when manager registersorder. (* Next is an example with a required (incoming) data object *) It is permitted that manager calculates order estimate only if registered order is provided to manager. | |
T8 | PP8 | Pattern with two semantically equivalent variations of using data stores with: (a) data association, and (b) association: |
RP8 | (* RP8.out *) (* RULE PATTERN PART FOR PROVIDING DATA TO A DATA STORE: *) (* Next is an RP part for the first data store required by an activity (n = n) *) “It is obligatory that”, gc(data_store(n)), “is provided with data”, (* Next is an RP part for every next data store required by an activity (n = n + 1,…,nn) *) [{“and”, gc(data_store(n)), “is provided with data”}], “when”, vc(participant(z), activity(i)), “.”; (* /RP8.out *) | |
(* RP8.in *) (* RULE PATTERN PART FOR RECEIVING DATA FROM A DATA STORE: *) (*Next is an RP part for the first data store required by a particular activity (n = n) *) “It is permitted that”, vc(participant(z), activity(j)), “only if”, gc(data_store(n)), “is available to”, gc(participant(z)), (* Next is an RP part for every next data store required by a particular activity (n = n + 1,…,nn) *) [{“and”, gc(data_store(n)), “is available to”, gc(participant(z))}], “.”; (* /RP8.in *) | ||
E.g., | (* Next is an example with providing data to a data store *) It is obligatory that completed order reports is provided with data when manager completesorder. (* Next is an example with a data store required to perform an activity *) It is permitted that manager performs quarterly sales assessmentonly ifcompleted order reports is available to manager. | |
T9 | PP9 | Pattern comprised of the variations of “participant as a black-box” and “participant as a white-box” with incoming and outgoing message flows. Each process pattern PP is mapped to two rule patterns RP (one for a sending and one for a receiving end): |
RP9 | (* RP9.Case(a)*) (* Next is the first pattern rule of Case (a) *) “It is permitted that”, gc(participant(y)), “sends”, (“message” | gc(msg)), “to ”, gc(participant(z)), “.”; (* The actual value of <something> in the expression “sends <something> to” depends on whether there is an actual message object attached to a message flow, or not; the same holds true for all other relevant pattern rules of RP9 *) (* Next is the second pattern rule of Case (a) *) “It is permitted that”, gc(participant(z)), “receives ”, (“message” | gc(msg)), “from ”, gc(participant(y)), “.”; (* The actual value of <something> in the expression “receives <something> from” depends on whether there is an actual message object attached to a message flow, or not; the same holds true for all other relevant pattern rules of RP9 *) (* /RP9.Case(a) *) | |
(* RP9.Case(b) *) (* Next is the first pattern rule of Case (b) *) (“It is obligatory that ” | “It is permitted that ”), gc(participant(y)), “sends”, (“message” | gc(msg)), “to”, gc(participant(z)), “when”, (vc(end_ev(i)) | vc(intermed_ev(i)) | vc(participant(y), activity(i))), “.”;(* The deontic formulation depends on the semantics of a specific source node the message flow is connected to (e.g., Send Message Task will imply obligation, while a Manual Task with an outgoing message flow attached to it – permission); the same holds true for the first pattern rule of the Case (d) of RP9 *) (* Next is the second pattern rule of Case (b) *) “It is permitted that ”, gc(participant(z)), “receives”, (“message” | gc(msg)), “from”, gc(participant(y)), “.”; (* /RP9.Case(b) *) | ||
(* RP9.Case(c) *) (* Next is the first pattern rule of Case (c) *) “It is permitted that ”, gc(participant(y)), “sends ”, (“message” | 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 ”, (vc(start_ev(j)) | vc(intermed_ev(j))), “when”, gc(participant(z)), “receives”, (“message” | gc(msg) ), “from”, gc(participant(y))) | (* Next is a rule pattern variation when a receiving node is an activity *) (“It is obligatory that” | “It is permitted that”, gc(participant(z)), “receives”, (“message” | gc(msg)), “from”, gc(participant(y)), “when”, vc(participant(z), activity(j))), “.”; (* The deontic 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 Manual Task with an incoming message flow attached to it – permission); the same holds true for the first pattern rule of the Case (d) of RP9 *) (* /RP9.Case(c) *) | ||
(* RP9.Case(d) *) (* Next is the first pattern rule of Case (d) *) (“It is obligatory that ” | “It is permitted that”), gc(participant(y)), “sends ”, (“message” | gc(msg)), “to”, gc(participant(z)), “when”, (vc(end_ev(i)) | vc(intermed_ev(i)) | vc(participant(y), activity(i))), “.”; (* 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”, vc(start_ev(j)) | vc(intermed_ev(j)), “when”, ( gc(participant(z)), “receives”, (“message” | gc(msg)), “from ”, gc(participant(y))) | (* Next is a rule pattern when a receiving node is an activity *) (“It is obligatory that ” | “It is permitted that”, (gc(participant(z)), “receives”, (“message” | gc(msg)), “from”, gc(participant(y)), “when”, vc(participant(z), activity(j))), “.”; (* /RP9.Case(d) *) | ||
E.g., | (* Next is an example of the first rule of Case (a) *) It is permitted that customer sends order tomanager. (* Next is an example of the second rule of Case (a) *) It is permitted that manager receives order fromcustomer. (* 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 tomanager when 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 customer sends order estimate confirmation tomanager. (* 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 fromcustomer. (* 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 fromcustomer when manager schedules order delivery date. (* Next is an example of the first rule of Case (d) *) It is obligatory that customer sends message tomanagerwhen 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 whenmanager receives message from customer. |
SBVR Concept Type | Extracted SBVR Concepts Representing an Exemplary Business Process |
---|---|
General concept | customer, provider, order, order request, received order, scheduled order, received, scheduled, order estimate, extra conditions, order estimate approval request, order estimate approval, order estimate rejection, order production, delivery date |
Verb concept | customer sends order request to provider, provider receives order request from customer, order is received, order has state received, order has extra conditions, provider analyzes order, provider evaluates extra conditions, order cannot be fulfilled, order request is rejected, provider sends message to customer, customer receives message from provider, provider calculates order estimate, order estimate is sent, provider sends order estimate approval request to customer, customer receives order estimate approval request from provider, customer sends order estimate rejection to provider, provider receives order estimate rejection from customer, customer sends order estimate approval to provider, provider receives order estimate approval from customer, order estimate is unacceptable, order estimate is approved, order request is terminated, provider schedules order production, order has state scheduled, provider schedules order delivery date, order is ready for production |
SBVR Process Rule | Process Rule Pattern |
---|---|
It is permitted that customer sends order request toprovider. It is obligatory that order is received when provider receives order request fromcustomer. | T9 |
It is obligatory that received order is produced when order is received. | T7 |
It is obligatory thatprovider analyzes order after order is received. It is obligatory thatprovider evaluates extra conditions after order is received and if order has extra conditions. | T3 |
It is permitted that provider analyzes order only ifreceived order is provided to provider. It is permitted that provider evaluates extra conditions only ifreceived order is provided to provider. | T7 |
It is obligatory that order request is rejected after provider analyzes order and (provider evaluates extra conditions if order has extra conditions) and if order cannot be fulfilled. It is obligatory that provider calculates order estimate after provider analyzes order and (provider evaluates extra conditions if order has extra conditions) and if not(order cannot be fulfilled). | Cascading gateways |
It is obligatory that provider sends message to customer when order request is rejected. It is permitted that customer receives message from provider. | T9 |
It is obligatory that order estimate is produced when provider calculates order estimate. | T7 |
It is obligatory that order estimate is sent after provider calculatesorder estimate. | T1 |
It is permitted that order estimate is sent only iforder estimate is provided to provider. | T7 |
It is obligatory that provider sends order estimate approval request to customer when order estimate is sent. It is obligatory that customer receives order estimate approval request from provider. | T9 |
It is permitted that order estimate is approved after order estimate is sent. It is permitted that order estimate is unacceptable after order estimate is sent. | T4 |
It is permitted that customer sends order estimate rejection to provider. It is obligatory that order estimateis unacceptable when provider receives order estimate rejection from customer. | T9 |
It is permitted that customer sends order estimate approval to provider. It is obligatory that order estimateis approved when provider receives order estimate aproval from customer. | T9 |
It is obligatory that order request is terminated after order estimateis unacceptable. | T1 |
It is obligatory that provider schedules order production after order estimateis approved. It is obligatory that provider schedules order delivery date after order estimateis approved. | T5 |
It is obligatory that scheduled order is produced when provider schedules order production. | T7 |
It is obligatory that order is ready for production after provider schedules order production and provider schedules order delivery date. | T5 |
Model | T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 | Cascading gtw. |
---|---|---|---|---|---|---|---|---|---|---|
Model 1 | 5 | 3 | 0 | 0 | 2 | 2 | 0 | 0 | 0 | 0 |
Model 2 | 7 | 4 | 0 | 0 | 0 | 0 | 0 | 0 | 10 | 0 |
Model 3 | 2 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 4 | 2 |
Model 4 | 2 | 1 | 0 | 0 | 2 | 0 | 0 | 0 | 4 | 2 |
Model 5 | 5 | 1 | 0 | 0 | 2 | 0 | 0 | 0 | 4 | 2 |
Model 6 | 2 | 2 | 2 | 0 | 3 | 0 | 0 | 0 | 0 | 1 |
Model 7 | 11 | 0 | 0 | 4 | 2 | 0 | 0 | 0 | 12 | 0 |
Model 8 | 4 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Model 9 | 19 | 8 | 0 | 0 | 0 | 0 | 0 | 0 | 24 | 0 |
Model 10 | 4 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 12 | 0 |
Model 11 | 16 | 1 | 0 | 4 | 1 | 0 | 0 | 0 | 0 | 2 |
Model 12 | 4 | 2 | 0 | 0 | 3 | 0 | 0 | 0 | 0 | 0 |
Model 13 | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Model 14 | 5 | 0 | 0 | 4 | 0 | 0 | 0 | 0 | 0 | 0 |
Model 15 | 6 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 2 |
Model 16 | 5 | 2 | 0 | 0 | 3 | 0 | 0 | 0 | 0 | 0 |
Model 17 | 6 | 2 | 0 | 0 | 0 | 0 | 2 | 0 | 0 | 0 |
Model 18 | 15 | 6 | 0 | 0 | 0 | 0 | 5 | 0 | 12 | 0 |
Model 19 | 12 | 6 | 0 | 0 | 0 | 0 | 0 | 0 | 8 | 0 |
Model 20 | 8 | 4 | 0 | 0 | 0 | 0 | 0 | 0 | 16 | 0 |
Model 21 | 5 | 4 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Model 22 | 14 | 6 | 0 | 0 | 0 | 0 | 3 | 0 | 10 | 0 |
Model 23 | 9 | 2 | 0 | 3 | 0 | 2 | 0 | 0 | 0 | 0 |
Model 24 | 7 | 6 | 0 | 0 | 0 | 0 | 4 | 0 | 0 | 0 |
Model 25 | 9 | 3 | 0 | 0 | 0 | 2 | 4 | 0 | 16 | 5 |
Model 26 | 7 | 2 | 0 | 2 | 0 | 0 | 0 | 0 | 10 | 0 |
Model 27 | 4 | 2 | 0 | 0 | 0 | 0 | 1 | 0 | 8 | 0 |
Model 28 | 7 | 2 | 0 | 0 | 3 | 0 | 4 | 0 | 6 | 0 |
Model 29 | 8 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
Model 30 | 4 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 6 | 0 |
Model 31 | 20 | 2 | 0 | 0 | 0 | 0 | 2 | 7 | 10 | 0 |
Model 32 | 6 | 2 | 0 | 0 | 0 | 0 | 4 | 0 | 2 | 0 |
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |
© 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
Skersys, T.; Danenas, P.; Mickeviciute, E.; Butleris, R. Transforming BPMN Processes to SBVR Process Rules with Deontic Modalities. Appl. Sci. 2022, 12, 8976. https://doi.org/10.3390/app12188976
Skersys T, Danenas P, Mickeviciute E, Butleris R. Transforming BPMN Processes to SBVR Process Rules with Deontic Modalities. Applied Sciences. 2022; 12(18):8976. https://doi.org/10.3390/app12188976
Chicago/Turabian StyleSkersys, Tomas, Paulius Danenas, Egle Mickeviciute, and Rimantas Butleris. 2022. "Transforming BPMN Processes to SBVR Process Rules with Deontic Modalities" Applied Sciences 12, no. 18: 8976. https://doi.org/10.3390/app12188976
APA StyleSkersys, T., Danenas, P., Mickeviciute, E., & Butleris, R. (2022). Transforming BPMN Processes to SBVR Process Rules with Deontic Modalities. Applied Sciences, 12(18), 8976. https://doi.org/10.3390/app12188976