Change Patterns for Decision Model and Notation (DMN) Model Evolution Faruk Hasić and Estefanı́a Serral Research Centre for Information Systems Engineering (LIRIS) KU Leuven, Brussels, Belgium {estefania.serralasensio, faruk.hasic}@kuleuven.be which depicts the requirements of decisions and the dependencies between elements involved in the deci- Abstract sion model. Second, the decision logic level, which presents ways to specify the underlying decision logic. Information systems rely on decision knowl- The DMN standard employs rectangles to depict de- edge during their execution. A recently intro- cisions and sub-decisions, and ovals to represent data duced standard, the Decision Model and No- input. The decision logic level is usually represented in tation (DMN), has been adopted in both in- the form of decision tables. An example of a DRD di- dustry and academia as a suitable method for agram deciding on the severity of Chronic Obstructive modelling decision knowledge. However, this Pulmonary Disease (COPD) in a patient is provided in decision knowledge is not static and may un- Figure 1, while Figure 2 depicts the top-level decision dergo changes after system deployment. DMN logic in the form of a decision table. change patterns have not yet been studied in the literature. This paper fills this gap by pre- Although it is obvious that the reasoning of deci- senting an initial set of DMN change patterns. sions can change over time to adapt to changing re- The patterns presented in this paper will not quirements, all current works approach DMN from a only facilitate the understanding of decision static perspective, i.e., no attention has been given to change management, but can also be capi- changing or adaptable decision models. In this paper talised on for, among other things, adapting we approach this research gap by identifying a first decision management systems to be more flex- set of change patterns that can be applied to DMN ible, consistency checking of decision models, decision models. These findings can aid in developing and developing modelling tools that facilitate and implementing dynamic decision management tools those changes. and systems that meet the requirements of flexible and changing decision knowledge. Index terms— Decision Model and Notation This paper is structured as follows. Section 2 con- (DMN), Model Evolution, Change Patterns stitutes a related work section. In Section 3 runtime evolution of decision models is explained, while pos- 1 Introduction sible decision model change patterns are discussed in Decision Model and Notation (DMN) is a recently Section 4. Section 5 deals with future research. Fi- introduced decision modelling standard that has en- nally, Section 6 concludes the paper. joyed significant interest in literature [1, 2, 3, 4, 5]. DMN consists of two levels that are to be used in con- 2 Related Work junction. First, the decision requirement level repre- sented by the Decision Requirement Diagram (DRD) Most works around DMN have focused on the inte- gration of process and decision models from a mod- Copyright © by the paper’s authors. Use permitted under Cre- elling point of view e.g., [2, 6, 7, 8, 9]. Others focus ative Commons License Attribution 4.0 International (CC BY 4.0). on the automatic discovery of decision model from en- In: D. Di Nucci, C. De Roover (eds.): Proceedings of the 18th riched process event logs [10, 11]. Furthermore, litera- Belgium-Netherlands Software Evolution Workshop, Brussels, ture provides a set of tools for modelling DMN models Belgium, 28-11-2019, published at http://ceur-ws.org [12, 13, 14]. 1 Decision node (top-level decision) Decision node (subdecision) COPD severeness Muscle activity Skin temperature Information Heart rhythm Respiration requirement Input data node EMG data ECG data Respiratory data Skin sensor data Figure 1: A DMN model for COPD severeness. Figure 2: A decision table for COPD severeness. The ability of a knowledge-based system to effi- Decision models can be specified according to the ciently deal with decision rule changes is considered a DMN standard. The models are saved in a file reposi- key property in literature [15, 16, 17, 18, 19, 20, 21, 22]. tory as an Extensible Markup Language (XML) file, This way, business rigidity is avoided and the ability adhering to the XML Metadata Interchange (XMI) to transform the underlying business rules to new re- standard [24], as specified by DMN 1.2 [1]. Execu- alities is facilitated. However, existing DMN decision tion engines are capable of interpreting XML files of model literature addresses decision modelling from a decision models from the file repository, and conse- static perspective where decision models are built and quently executing the corresponding decisions. Such used, without any form of model evolution. Change an engine is provided by Camunda [25]. The engine patterns are often used to define the possible evolu- executes the decisions and consequently the software tion of models. These change patterns rely on the services related to the decisions. The engine logs the elementary edit operations that can be applied on the executions for possible future analyses. model elements, i.e., insertion and deletion, as well The connection between the aforementioned com- as substitution, which in essence is a combination of ponents is shown in Figure 3. The arrows between the insertion and deletion [23]. Furthermore, change pat- components represent information flows. Namely, the terns can help facilitate the understanding of model decision models are fed into the file repository, which change management as they provide a guide for imple- is then fed to the execution engine for enactment. The menting changes to models while maintaining model engine executes the decisions and logs the execution. consistency. Nonetheless, change patterns for decision Changing the decision model at runtime will re- models were not yet addressed in the literature. sult in a new XML specification of the model, i.e., a new model variant. Deploying a new model vari- 3 Runtime Decision Evolution ant for interpretation affects all future instances, as In this section we explain how decision models are used they will follow the newest model variant. Old run- at runtime. An overview of decision model execution ning instances will continue to run according to the old is given in Figure 3. In what follows, we take a closer model specification as a result of the variant version- look at the elements of the architecture and their in- ing mechanism of the engine. This is a straightforward terrelations. approach to assure that old instances continue to run 2 in a sound way. 3. ∆Π3: Excluding a decision output indicates the deletion of an existing output from the output 4 Towards Decision Model Change set of a decision table. Patterns 4. ∆Π4: Including a decision output indicates To accommodate decision model changes, designers an addition of a new output to the output set of should be able to evolve the decision models after de- a decision table. ployment. A number of changes can occur in the de- 5. ∆Π5: A decision logic change indicates a cision model. The core elements of a decision model change in relating the existing input symbols to are depicted in Figure 1, i.e. the input data and the the existing output symbols within the decision decision nodes within a DRD, connected via informa- table, i.e., the mapping from inputs to outputs. tion requirements arrows. The logic encapsulated in a decision node is usually modelled with decision tables, 4.2 Change patterns on decision rules in their such as shown in Figure 2. To determine the change entirety patterns, we investigate the changes that can mani- fest themselves on the core DMN elements, provided Next to changes within decision rules, we can view in the meta-model of the DMN specification [1], at dif- decision rules as an atomic entity and perform changes ferent levels of granularity. First, we assess the change on the decision rule in its entirety: patterns within a single decision rule, i.e., changing 1. ∆Π6: Excluding a decision rule if a decision the inputs and outcomes of a single rule or row in the rule is deemed irrelevant at a certain point in time. decision table. Next, we look at change patterns for The decision rule can be deleted in its entirety a decision rule in its entirety, i.e., adding or deleting from a decision table. Notice that by deleting decision rules from a decision table. These change pat- decision rules, the decision table may not be com- terns all pertain to a single node of the DRD, i.e., a plete anymore. To avoid this, either the decision single decision table, according to the DMN decision table should be completed by ensuring that all table meta-model [1]. Finally, we investigate change input values are mapped to existing decision out- patterns on the topological structure of the DRD itself, comes, or the system should be redesigned to cap- respectively the addition and deletion of decision nodes ture the possibility of no decision outcome being and data input nodes. The change patterns are derived returned. from the formalisation of core decision model elements in [2] and the elementary edit operations that can be 2. ∆Π7: Including a decision rule if a new de- applied on the elements, i.e., insertion and deletion, cision rule is deemed relevant at a certain point as well as substitution, which in essence is a combina- in time. The decision rule can be added in its tion of insertion and deletion [23]. Table 1 provides entirety to an existing decision table. an overview of the change patterns directly relating to core DMN elements. Table 1: Overview of decision model change patterns. Decision table change patterns 4.1 Change patterns within decision rules Changes within decision rules ∆Π1 Decision input exclusion. We indicate a change pattern with ∆Π. For changes ∆Π2 Decision input inclusion. within decision rules, we can distinguish three ele- ∆Π3 Decision output inclusion. ∆Π4 Decision output exclusion. ments in the decision table that can undergo changes: ∆Π5 Decision rule logic change. the inputs, the outputs, and the logic mapping the Changes on decision rules inputs to the outputs, i.e. the decision rules: ∆Π6 Decision rule exclusion. ∆Π7 Decision rule inclusion. 1. ∆Π1: Excluding a decision input indicates Decision requirements diagram change patterns deleting an existing input variable from a decision Decision node changes ∆Π8 Decision node exclusion. table. However, simply deleting an input variable ∆Π9 Decision node inclusion. can render the decision table to be incomplete and Input data node changes incorrect. As such, the table may need to undergo ∆Π10 Input data node inclusion. refactoring in order to render a decision table that ∆Π11 Input data node exclusion. is complete and correct [26]. 4.3 Change patterns on the decision nodes in 2. ∆Π2: Including a decision input indicates the DRD adding a new input variable to a decision table. Similar to ∆Π1, the table may need to undergo This subsection deals with the deletion or addition of refactoring after this change pattern is applied decision nodes in the decision requirements diagram. 3 File repository Log Modelling Execution environment engine Figure 3: An overview of decision model execution. 1. ∆Π8: Excluding a decision node from the be propagated throughout the entire decision model DRD corresponds to deleting all decision rules to safeguard within-model consistency. For instance, from a decision node. Hence, this change pat- deleting an input data node will also require delet- tern is an aggregation of multiple exclude decision ing the inputs in the decision tables that require the rule changes (∆Π6). Note that deleting a decision deleted input data node. node also deletes all its incoming and outgoing in- formation requirements arrows. 5 Future Work 2. ∆Π9: Including a decision node to the set of In future work, we will investigate how a change in decision nodes corresponds to adding a new de- the decision model can require the triggering of other cision table, and thus, adding multiple decision changes in order to safeguard within-model consis- rules encapsulated in the decision node. Hence, tency. Additionally, we will investigate how chang- this change pattern is in essence an aggregation ing decision models impacts other systems and mod- of multiple include decision rule changes (∆Π7). els that rely on the logic encapsulated in the decision Note that adding a decision node also adds the models. More specifically, we will examine how the necessary incoming and outgoing information re- proposed change patterns influence process and deci- quirements arrows. sion model consistency in an integrated process and decision model environment. Changing the underly- 4.4 Change patterns on the input data nodes ing decisions of a process can lead to change patterns in the DRD in the process model as well if the sound interaction This subsection deals with the deletion or addition of between the process and decision model is to be en- input data nodes in the decision requirements diagram. sured. Furthermore, flexible decision models are of partic- 1. ∆Π10: Including an input data node to the ular interest to Internet-of-Things (IoT) process set- set of data input nodes also adds its necessary tings [27], as IoT process are inherently subject to input requirement arrows and connects it to the a dynamic and changeable environment. Therefore, relevant decision nodes in the DRD. Notice that we will investigate how these change patterns mani- this change pattern on the DRD level corresponds fest themselves in decision-intensive IoT processes. to adding a new input variable to the decision Finally, we will look into developing a tool that pro- table that requires the newly added data input vides possibilities for DMN model evolution with au- node. Hence, this change pattern is equivalent to tomated model consistency checking and repair, while ∆Π2. maintaining the link with the Camunda execution en- 2. ∆Π11: Excluding an input data node from gine. the set of data input nodes also deletes all its in- put requirement arrows. Notice that this change 6 Conclusion pattern on the DRD level corresponds to deleting an input variable from the decision table that re- This paper presents an initial set of decision model quired the input data node. Hence, this change change patterns for the evolution of DMN decision pattern is again equivalent to ∆Π1. models. We recognise that the adaptation of a DMN decision model can lead to within-model inconsisten- Note that adopting a change pattern on a DMN cies and that additional change patterns may need to decision model can lead to within-model inconsisten- be propagated throughout the entire decision model to cies and that additional change patterns may need to safeguard within-model consistency. 4 References through decision mining: an experimental study. In International Conference on Business Process [1] OMG. Decision Model and Notation (DMN) 1.2, Management, pages 556–567. Springer, 2017. 2018. [11] Johannes De Smedt, Faruk Hasić, Seppe K.L.M [2] Faruk Hasić, Johannes De Smedt, and Jan Van- vanden Broucke, and Jan Vanthienen. Holistic thienen. Augmenting processes with decision in- discovery of decision models from process execu- telligence: Principles for integrated modelling. tion data. Knowledge-Based Systems, 183:104866, Decision Support Systems, 107:1 – 12, 2018. 2019. [3] Faruk Hasić and Jan Vanthienen. From decision [12] Carl Corea and Patrick Delfmann. A tool to mon- knowledge to e-government expert systems: the itor consistent decision-making in business pro- case of income taxation for foreign artists in bel- cess execution. Proceedings of the Dissertation gium. Knowledge and Information Systems, Oct Award, Demonstration, and Industrial Track at 2019. BPM, pages 9–14, 2018. [4] Faruk Hasić and Jan Vanthienen. Complexity [13] Knut Hinkelmann, Kyriakos Kritikos, Sabrina metrics for dmn decision models. Computer Stan- Kurjakovic, Benjamin Lammel, and Robert dards & Interfaces, 65:15 – 37, 2019. Woitsch. A modelling environment for business [5] Marjolein Deryck, Faruk Hasić, Jan Vanthienen, process as a service. In International Conference and Joost Vennekens. A case-based inquiry into on Advanced Information Systems Engineering, the decision model and notation (dmn) and the pages 181–192. Springer, 2016. knowledge base (kb) paradigm. In Christoph [14] Knut Hinkelmann, Arianna Pierfranceschi, and Benzmüller, Francesco Ricca, Xavier Parent, and Emanuele Laurenzi. The knowledge work Dumitru Roman, editors, Rules and Reasoning, designer-modelling process logic and business pages 248–263, Cham, 2018. Springer Interna- logic. In Modellierung (Workshops), pages 135– tional Publishing. 140, 2016. [6] Faruk Hasić, Johannes De Smedt, and Jan Van- [15] Zohra Bellahsene. Schema evolution in data ware- thienen. Redesigning processes for decision- houses. Knowledge and Information Systems, awareness: Strategies for integrated modelling. In 4(3):283–304, 2002. International Conference on the Quality of Infor- mation and Communications Technology, 2018. [16] Natalya F Noy and Michel Klein. Ontology evolution: Not the same as schema evolution. [7] Faruk Hasić, Johannes De Smedt, and Jan Van- Knowledge and information systems, 6(4):428– thienen. Developing a modelling and mining 440, 2004. framework for integrated processes and decisions. In Christophe Debruyne, Hervé Panetto, Georg [17] Wan MN Wan Kadir and Pericles Loucopoulos. Weichhart, Peter Bollen, Ioana Ciuciu, Maria- Linking and propagating business rule changes to Esther Vidal, and Robert Meersman, editors, On is design. In Information Systems Development, the Move to Meaningful Internet Systems. OTM pages 253–264. Springer, 2005. 2017 Workshops, pages 259–269, Cham, 2018. [18] Jérôme Boyer and Hafedh Mili. Agile business Springer International Publishing. rule development. In Agile Business Rule Devel- [8] Thierry Biard, Jean-Pierre Bourey, and Michel opment, pages 49–71. Springer, 2011. Bigand. Dmn (decision model and notation): De [19] Flavio Corradini, Alberto Polzonetti, and la modélisation à l’automatisation des décisions. Oliviero Riganelli. Business rules in e-government In INFORSID 2017, 2017. applications. arXiv preprint arXiv:1802.08484, 2018. [9] Kimon Batoulis, Anne Baumgraß, Nico Herzberg, and Mathias Weske. Enabling dynamic decision [20] Gordon Blair, Nelly Bencomo, and Robert B making in business processes with dmn. In In- France. Models@ run. time. Computer, ternational Conference on Business Process Man- 42(10):22–27, 2009. agement, pages 418–431. Springer, 2015. [21] Michael Szvetits and Uwe Zdun. Systematic liter- [10] Júlio Campos, Pedro Richetti, Fernanda Araújo ature review of the objectives, techniques, kinds, Baião, and Flávia Maria Santoro. Discovering and architectures of models at runtime. Software business rules in knowledge-intensive processes & Systems Modeling, 15(1):31–69, 2016. 5 [22] Sihem Loukil, Slim Kallel, and Mohamed Jmaiel. An approach based on runtime models for devel- oping dynamically adaptive systems. Future Gen- eration Computer Systems, 68:365–375, 2017. [23] Andreas Wombacher and Maarten Rozie. Eval- uation of workflow similarity measures in service discovery. Service Oriented Electronic Commerce, 80:51–71, 2006. [24] OMG. Xml metadata interchange (XMI) 2.5.1, 2015. [25] Camunda. Process engine. https://docs.camunda.org/manual/7.8/user- guide/process-engine/, 2018. Accessed: 2018-11- 16. [26] Diego Calvanese, Marlon Dumas, Ülari Laurson, Fabrizio M Maggi, Marco Montali, and Irene Teinemaa. Semantics, analysis and simplifica- tion of dmn decision tables. Information Systems, 2018. [27] Faruk Hasić and Estefanı́a Serral Asensio. Exe- cuting IoT processes in BPMN 2.0: Current sup- port and remaining challenges. IEEE RCIS 2019 proceedings, 2019. 6