Information systems rely on decision knowledge during their execution. A recently introduced standard, the Decision Model and Notation (DMN), has been adopted in both industry and academia as a suitable method for modelling decision knowledge. However, this decision knowledge is not static and may undergo changes after system deployment. DMN change patterns have not yet been studied in the literature. This paper lls this gap by presenting an initial set of DMN change patterns. The patterns presented in this paper will not only facilitate the understanding of decision change management, but can also be capitalised on for, among other things, adapting decision management systems to be more exible, consistency checking of decision models, and developing modelling tools that facilitate those changes.
Decision Model and Notation (DMN) is a recently
introduced decision modelling standard that has
enjoyed signi cant interest in literature [
Although it is obvious that the reasoning of decisions can change over time to adapt to changing requirements, all current works approach DMN from a static perspective, i.e., no attention has been given to changing or adaptable decision models. In this paper we approach this research gap by identifying a rst set of change patterns that can be applied to DMN decision models. These ndings can aid in developing and implementing dynamic decision management tools and systems that meet the requirements of exible and changing decision knowledge.
This paper is structured as follows. Section 2 constitutes a related work section. In Section 3 runtime evolution of decision models is explained, while possible decision model change patterns are discussed in Section 4. Section 5 deals with future research. Finally, Section 6 concludes the paper. 2
Most works around DMN have focused on the
integration of process and decision models from a
modelling point of view e.g., [
Muscle activity
Decision node (top-level decision)
COPD severeness Heart rhythm
Respiration
Decision node (subdecision) Skin temperature
Information requirement Input data node EMG data
ECG data
Respiratory data
Skin sensor data in a sound way. 4
To accommodate decision model changes, designers
should be able to evolve the decision models after
deployment. A number of changes can occur in the
decision model. The core elements of a decision model
are depicted in Figure 1, i.e. the input data and the
decision nodes within a DRD, connected via
information requirements arrows. The logic encapsulated in a
decision node is usually modelled with decision tables,
such as shown in Figure 2. To determine the change
patterns, we investigate the changes that can
manifest themselves on the core DMN elements, provided
in the meta-model of the DMN speci cation [1], at
different levels of granularity. First, we assess the change
patterns within a single decision rule, i.e., changing
the inputs and outcomes of a single rule or row in the
decision table. Next, we look at change patterns for
a decision rule in its entirety, i.e., adding or deleting
decision rules from a decision table. These change
patterns all pertain to a single node of the DRD, i.e., a
single decision table, according to the DMN decision
table meta-model [1]. Finally, we investigate change
patterns on the topological structure of the DRD itself,
respectively the addition and deletion of decision nodes
and data input nodes. The change patterns are derived
from the formalisation of core decision model elements
in [
Change patterns within decision rules We indicate a change pattern with . For changes within decision rules, we can distinguish three elements in the decision table that can undergo changes: the inputs, the outputs, and the logic mapping the inputs to the outputs, i.e. the decision rules:
1: Excluding a decision input indicates
deleting an existing input variable from a decision
table. However, simply deleting an input variable
can render the decision table to be incomplete and
incorrect. As such, the table may need to undergo
refactoring in order to render a decision table that
is complete and correct [
2: Including a decision input indicates adding a new input variable to a decision table. Similar to 1, the table may need to undergo refactoring after this change pattern is applied 3. 4. 5. 1. 2.
4: Including a decision output indicates an addition of a new output to the output set of a decision table.
5: A decision logic change indicates a change in relating the existing input symbols to the existing output symbols within the decision table, i.e., the mapping from inputs to outputs. 4.2
Change patterns on decision rules in their entirety Next to changes within decision rules, we can view decision rules as an atomic entity and perform changes on the decision rule in its entirety:
6: Excluding a decision rule if a decision rule is deemed irrelevant at a certain point in time. The decision rule can be deleted in its entirety from a decision table. Notice that by deleting decision rules, the decision table may not be complete anymore. To avoid this, either the decision table should be completed by ensuring that all input values are mapped to existing decision outcomes, or the system should be redesigned to capture the possibility of no decision outcome being returned.
7: Including a decision rule if a new decision rule is deemed relevant at a certain point in time. The decision rule can be added in its entirety to an existing decision table.
9: Including a decision node to the set of decision nodes corresponds to adding a new decision table, and thus, adding multiple decision rules encapsulated in the decision node. Hence, this change pattern is in essence an aggregation of multiple include decision rule changes ( 7). Note that adding a decision node also adds the necessary incoming and outgoing information requirements arrows. 4.4
Change patterns on the input data nodes in the DRD This subsection deals with the deletion or addition of input data nodes in the decision requirements diagram.
10: Including an input data node to the set of data input nodes also adds its necessary input requirement arrows and connects it to the relevant decision nodes in the DRD. Notice that this change pattern on the DRD level corresponds to adding a new input variable to the decision table that requires the newly added data input node. Hence, this change pattern is equivalent to 2.
11: Excluding an input data node from the set of data input nodes also deletes all its input requirement arrows. Notice that this change pattern on the DRD level corresponds to deleting an input variable from the decision table that required the input data node. Hence, this change pattern is again equivalent to 1.
Note that adopting a change pattern on a DMN decision model can lead to within-model inconsistencies and that additional change patterns may need to
In future work, we will investigate how a change in the decision model can require the triggering of other changes in order to safeguard within-model consistency. Additionally, we will investigate how changing decision models impacts other systems and models that rely on the logic encapsulated in the decision models. More speci cally, we will examine how the proposed change patterns in uence process and decision model consistency in an integrated process and decision model environment. Changing the underlying decisions of a process can lead to change patterns in the process model as well if the sound interaction between the process and decision model is to be ensured.
Furthermore, exible decision models are of
particular interest to Internet-of-Things (IoT) process
settings [
Finally, we will look into developing a tool that provides possibilities for DMN model evolution with automated model consistency checking and repair, while maintaining the link with the Camunda execution engine. 6
This paper presents an initial set of decision model change patterns for the evolution of DMN decision models. We recognise that the adaptation of a DMN decision model can lead to within-model inconsistencies and that additional change patterns may need to be propagated throughout the entire decision model to safeguard within-model consistency. [1] OMG. Decision Model and Notation (DMN) 1.2, 2018. [3] Faruk Hasic and Jan Vanthienen. From decision knowledge to e-government expert systems: the case of income taxation for foreign artists in belgium. Knowledge and Information Systems, Oct 2019. [4] Faruk Hasic and Jan Vanthienen. Complexity metrics for dmn decision models. Computer Standards & Interfaces, 65:15 { 37, 2019. [5] Marjolein Deryck, Faruk Hasic, Jan Vanthienen, and Joost Vennekens. A case-based inquiry into the decision model and notation (dmn) and the knowledge base (kb) paradigm. In Christoph Benzmuller, Francesco Ricca, Xavier Parent, and Dumitru Roman, editors, Rules and Reasoning, pages 248{263, Cham, 2018. Springer International Publishing. [6] Faruk Hasic, Johannes De Smedt, and Jan Vanthienen. Redesigning processes for decisionawareness: Strategies for integrated modelling. In International Conference on the Quality of Information and Communications Technology, 2018. [7] Faruk Hasic, Johannes De Smedt, and Jan Vanthienen. Developing a modelling and mining framework for integrated processes and decisions. In Christophe Debruyne, Herve Panetto, Georg Weichhart, Peter Bollen, Ioana Ciuciu, MariaEsther Vidal, and Robert Meersman, editors, On the Move to Meaningful Internet Systems. OTM 2017 Workshops, pages 259{269, Cham, 2018.
Springer International Publishing. [8] Thierry Biard, Jean-Pierre Bourey, and Michel Bigand. Dmn (decision model and notation): De la modelisation a l'automatisation des decisions.
In INFORSID 2017, 2017. [9] Kimon Batoulis, Anne Baumgra , Nico Herzberg, and Mathias Weske. Enabling dynamic decision making in business processes with dmn. In International Conference on Business Process Management, pages 418{431. Springer, 2015. [10] Julio Campos, Pedro Richetti, Fernanda Araujo Baia~o, and Flavia Maria Santoro. Discovering business rules in knowledge-intensive processes