dmn check
1.3.1
Dies ist ein Instrument zur Validierung von DMN -Dateien (Entscheidungsmodellnotation). Es führt verschiedene statische Analysen durch, um Inkonsistenzen und Fehler in Ihren Entscheidungsmodellen zu erkennen.
Sie können dmn-check auf sechs Arten verwenden.
Derzeit prüft DMN-Check unter anderem unter anderem:
In Abschnitt Validierungen finden Sie eine vollständige Liste mit detaillierten Beschreibungen dessen, was sie tun.
Die meisten Eigenschaften und Invarianten, die durch dmn-check validiert werden, werden in der DMN-Spezifikation informell beschrieben. Falls Sie Fragen zu Validierungen haben, kann es sich lohnt, die Spezifikation zu überfliegen.
Dieses Plugin benötigt Java 17 oder später und Apache Maven 3 oder höher. Einige Analysen sind auf die Camunda DMN -Implementierung zugeschnitten und funktionieren möglicherweise nicht für verschiedene DMN -Implementierungen.
dmn-check kann entweder als normales Maven-Plugin in Ihren Projekten pom.xml oder als eigenständiges Programm verwendet werden.
Das folgende Beispiel zeigt die grundlegende Konfiguration des Plugins:
<plugin>
<groupId>de.redsix</groupId>
<artifactId>dmn-check-maven-plugin</artifactId>
<version>...</version>
<executions>
<execution>
<phase>verify</phase>
<goals>
<goal>check-dmn</goal>
</goals>
</execution>
</executions>
</plugin>
Mit dieser Konfiguration sucht das Plugin alle Ordner des aktuellen Projekts für Dateien mit der Erweiterung .dmn und wendet alle verfügbaren Validatoren an. Es ist möglich, stattdessen eine Reihe von Suchpfaden bereitzustellen, bestimmte Dateien zu ignorieren und die Validatoren anzugeben, die ausgeführt werden sollten. Das folgende Beispiel zeigt, wie Sie diese Optionen nutzen können, indem Sie den Suchpfad auf die Ordner src/ und model/ sowie das ignorieren von Datei test.dmn einschränken. Die Konfiguration gibt ferner an, dass nur der ShadowedRuleValidator ausgeführt werden sollte. Um Validatoren anzugeben, müssen Sie den vollqualifizierten Namen verwenden.
<configuration>
<searchPaths>
<searchPath>src/</searchPath>
<searchPath>model/</searchPath>
</searchPaths>
<excludes>
<exclude>test.dmn</exclude>
</excludes>
<validatorClasses>
<validatorClass>de.redsix.dmncheck.validators.ShadowedRuleValidator</validatorClass>
</validatorClasses>
</configuration>
Zusätzlich kann der Parameter failOnWarning (Standard ist falsch) so eingestellt werden, dass es eine Maven -Ausführung fehlschlägt, wenn Validierungsfehler mit Warnschwere vorliegen.
<configuration>
<failOnWarning>true</failOnWarning>
</configuration>
Um dmn-check ohne oder außerhalb eines Maven-Projekts zu verwenden, können Sie es auf folgende Weise aufrufen
mvn de.redsix:dmn-check-maven-plugin:check-dmn
Dieses Plugin benötigt Java 11 oder später und Gradle 6.5 oder höher. Einige Analysen sind auf die Camunda DMN -Implementierung zugeschnitten und funktionieren möglicherweise nicht für verschiedene DMN -Implementierungen.
DMNMgr ist ein Toolkit, das die Camunda DMN-Implementierung inkopiert und Tools zur Entwicklung von DMN-basierten Anwendungen in funktionsübergreifenden Teams bereitstellt. Es wird mit einer dmn-check Integration geliefert und visualisiert die Warnungen und Fehler in der grafischen Darstellung des DMN-Modells. Sie müssen den DMNMGR-Client und den DMNMGR-Server installieren, um ihn zu verwenden.
Ein Docker-Bild mit dmn-check ist in der GitHub-Containerregistrierung erhältlich. Sie können die neueste Version durch Ausführen abrufen
docker pull ghcr.io/red6/dmn-check:latest
Wenn Sie docker run verwenden möchten, um dmn-check auszuführen
docker run -v ~/dmn-files:/dmn-files ghcr.io/red6/dmn-check:latest --searchPath=/dmn-files
Wenn Sie das Docker-Bild in einer GitLab-Pipeline verwenden möchten, müssen Sie den Einstiegspunkt überschreiben und dmn-check direkt aufrufen. Im folgenden Beispiel einer GitLab -Pipeline geben wir auch den Projektklassenpath an, um die Enum -Validierung zu ermöglichen.
variables:
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
default:
artifacts:
paths:
- ./cp.txt
- .m2/repository
stages:
- analysis
image:
name: ghcr.io/red6/dmn-check:latest
entrypoint: [ "" ]
create-classpath-for-dmn-check:
image: adoptopenjdk/maven-openjdk11
stage: analysis
script: mvn dependency:build-classpath --settings .m2/settings.xml --batch-mode -Dmdep.outputFile=cp.txt
dmn-check:
stage: analysis
needs:
- create-classpath-for-dmn-check
script: |
/opt/java/openjdk/bin/java -cp /app/resources:/app/classes:/app/libs/* de.redsix.dmncheck.cli.Main --projectClasspath=$(< cp.txt)
Die folgenden Unterabschnitte beschreiben die verfügbaren Validierungen im Detail. Die in diesem Abschnitt verwendeten DMN -Entscheidungstabellen stammen aus einem Beispiel auf camunda.org.
Betrachten Sie die folgende DMN -Entscheidungstabelle mit UNIQUE Hit -Richtlinie:
| Jahreszeit ᴵᴺᴾᵁᵀ | Wie viele Gäste ᴵᴺᴾᵁᵀ | Gericht ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Fallen" | <= 8 | "Spareribs" |
| 2 | "Winter" | <= 8 | "Brat-" |
| 3 | "Frühling" | [5..8] | "Steak" |
| 4 | "Winter" | <= 8 | "Brat-" |
Es ist ziemlich offensichtlich, dass Regel Nummer zwei ein Duplikat von Regel Nummer vier ist. Dies ist durch die UNIQUE Hit -Richtlinie und damit durch einen Fehler nicht zulässig.
Definition : Eine Regel ist ein Duplikat einer anderen Regel, wenn alle Eingaben und Ausgänge dieser Regeln identisch sind.
dmn-check meldet doppelte Regeln für alle Entscheidungstabellen mit Ausnahme derjenigen mit Hit- COLLECT .
Widersprüchliche Regeln ähneln den doppelten Regeln etwas. Betrachten Sie das folgende Beispiel mit UNIQUE Hit -Richtlinie:
| Jahreszeit ᴵᴺᴾᵁᵀ | Wie viele Gäste ᴵᴺᴾᵁᵀ | Gericht ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Fallen" | <= 8 | "Spareribs" |
| 2 | "Winter" | <= 8 | "Brat-" |
| 3 | "Frühling" | [5..8] | "Steak" |
| 4 | "Winter" | <= 8 | "Eintopf" |
Wir sehen noch einmal eine Regel zwei und vier. Diesmal sind alle ihre Eingaben identisch, unterscheiden sich jedoch in der Ausgabe. Dies ist wohl schlechter als eine doppelte Regel, da dies je nach Bewertungsreihenfolge der Entscheidungstabelle unterschiedliche Ergebnisse erzielen kann. Angenommen, die Laufzeit erkennt diese Inkonsistenzen nicht.
Definition : Regel r steht im Widerspruch zu den Regels s , wenn und nur dann, wenn alle Eingaben von Regeln r und s identisch sind und sich bei der Lease einen Ausgang unterscheiden.
dmn-check meldet doppelte Regeln für alle Entscheidungstabellen, mit Ausnahme derjenigen mit Hit- COLLECT und RULE_ORDER .
Einige Regeln verhindern, dass andere überhaupt berücksichtigt werden. Schauen Sie sich FIRST das folgende Beispiel mit der Hit -Richtlinie an:
| Jahreszeit ᴵᴺᴾᵁᵀ | Wie viele Gäste ᴵᴺᴾᵁᵀ | Gericht ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Fallen" | <= 8 | "Spareribs" |
| 2 | "Winter" | <= 8 | "Brat-" |
| 3 | - - | - - | "Eintopf" |
| 4 | "Frühling" | [5..8] | "Steak" |
Dieses Beispiel enthält keine doppelten Regeln und keine widersprüchlichen Regeln. Alle Eingaben von Regel drei sind jedoch leer (in diesem Beispiel mit einem Armaturenbrett dargestellt). Wenn leere Eingaben mit allem übereinstimmen und da wir annehmen, dass die Hit -Richtlinie FIRST Regel vier niemals als Regel drei übereinstimmt, übereinstimmt alle möglichen Eingaben. Daher wird der Eintopf den Gästen von 5 bis 8 im Frühjahr serviert. Unter der Annahme, dass jede Regel einen Zweck erfüllt, sind die Schattenregeln immer ein Fehler, da sie niemals übereinstimmt.
Definition : Regel r Shadows Regel s IF und nur wenn die Eingaben der Regel r zumindest für alle Werte übereinstimmen, für die die Eingaben der Regel s übereinstimmen.
dmn-check meldet doppelte Regeln für alle Entscheidungstabellen, mit Ausnahme von Personen mit Hit- COLLECT und RULE_ORDER .
DMN bietet eine reichhaltige Ausdruckssprache, die als freundlich genug Ausdruckssprache (Gefühl) bezeichnet wird, mit der die Bedingungen für die Eingabeinträge beschrieben werden können. Wie bei den meisten Ausdrucksprachen sind jedoch nicht alle syntaktisch möglichen Ausdrücke gültig (semantisch). dmn-check integriert einen Typ-Checker für die Feel-Expressions-Sprache, die sicherstellt, dass eine Entscheidungstabelle nur gut ausdrückte Ausdrücke enthält.
Ein Beispiel für einen schlecht getotischen Ausdruck ist [1..true] , der den Bereich zwischen 1 und true beschreiben würde, der (bei Mietvertrag) kein gültiger Ausdruck ist. Im Gegensatz dazu ist [1..9] gut getetht und beschreibt die Zahlen von 1 bis 9.
| Feel-Expression | Typ |
|---|---|
| WAHR | boolean |
| [1..3] | ganze Zahl |
| [1 .. "String"] | ✘ |
| 1, 2, wahr | ✘ |
| > 5 | ganze Zahl |
| > wahr | ✘ |
Natürlich wird auch die Typdeklaration validiert.
Die Entscheidungsfindung beinhaltet häufig einen festen Satz von Werten (z. B. eine Liste unterstützter Währungen). Daher werden diese Werte in DMN-Entscheidungstabellen verwendet. Diese Werte werden häufig in Form von Java -Enums implementiert. dmn-check auch, um den vollqualifizierten Klassennamen eines Enum in der Typdeklaration der Eingabe- / Ausgabemalumn anzugeben und die Werte in der DMN-Entscheidungstabelle gegen die Enum-Implementierung zu überprüfen.
Standardmäßig verwendet dmn-check die Projektabhängigkeiten, um die Enums zu beheben. Da dies im Maven -Standalone -Modus nicht möglich ist, können Sie den Klassenpfad angeben, der zur Lösung der Enums verwendet wird
mvn de.redsix:dmn-check-maven-plugin:check-dmn -Dclasspath=foo.jar,bar.jar
Der DMN -Standard bietet auch eine Möglichkeit, Entscheidungen Tabellen miteinander zu verbinden und Eingaben und Wissensquellen zu modellieren. Die resultierenden Diagramme werden als Entscheidungsbedarfsdiagramme (DRG) bezeichnet.
dmn-check prüft,
Im folgenden Beispiel hat Decisionstabelle Dish Season und How many guests als Eingaben, aber anstelle der Season gibt es eine Lunar phase die mit der Entscheidungstabelle verbunden ist.
Graph TD;
x (Mondphase)-> Gericht;
y (wie viele Gäste)-> Gericht;
Gericht-> Getränke;
Z (Gäste mit Kindern)-> Getränke;
Der DMN -Standard ermöglicht die Aggregation von Werten für die Erfassung von Hit -Richtlinien. Beispielsweise können Sie die Summe aller übereinstimmenden Zeilen in einer Entscheidungstabelle berechnen. Sie können diese Funktion verwenden, um eine Kreditwürdigkeit zu berechnen.
Wir stellen sicher, dass diese Aggregationen nur auf Spalten mit einem numerischen Typ angewendet werden. Darüber hinaus validieren wir, dass Aggregationen nur verwendet werden, wenn die Sammlung von Hit -Richtlinien verwendet wird.
Normalerweise müssen Sie sich nicht viel um IDs und Namen von DMN -Elementen kümmern. Bei Upgrades und Refactoring kann jedoch passieren, dass eine ID oder ein Name verloren gehen. Diese Fehler bleiben normalerweise lange unbemerkt. Abhängig vom Szenario kann fehlende IDs oder Namen Ihr Entscheidungsmodell brechen oder die Fehleranalyse schwierig machen.
dmn-check bestätigt, dass die folgenden DMN-Elemente immer eine ID und einen Namen haben:
ItemDefinition s ItemDefinition S sind DMNS -Weg, um die Aufzählung auszudrücken. In der Definition einer ItemDefinition erklären Sie, welche Werte zulässig sind. Derzeit validieren wir nur, ob die Ausdrücke aus einer ItemDefintion gut sind.
Als wir anfingen, an dmn-check zu arbeiten, waren wir nicht von Analyse-Tools für DMN-Dateien, die zu unseren Bedürfnissen geeignet sind und in unserer Umgebung mit Camunda Aroma gearbeitet haben. Seitdem wurde DMN populärer und andere Tools bieten einige Analysefunktionen. Wenn Sie wissen möchten, wie dmn-check mit anderen Tools vergleichbar ist, können Sie einen Vergleich in GCD lesen.
Aulari Laurson und Fabrizio Maria Maggi erweiterten das dmn-js -Bearbeitungs-Toolkit von Camunda mit Analysefunktionen und veröffentlichten es unter github.com/ulaurson/dmn-js. Das Tool kann Syntax erkennen und Fehler eingeben und überlappende und fehlende Regeln identifiziert werden. Es ist auch in der Lage, Entscheidungstabellen durch Zusammenführen von Regeln zu vereinfachen. Im Demo -Papier LM16 beschreiben sie das Werkzeug. Weitere Details zu den vom Tool durchgeführten Analysen finden Sie in CDL+16.
CDL+16 Calvanese, D., Dumas, M., Laurson, ü., Maggi, FM, Montali, M., Teinemaa, I.: Semantik und Analyse von DMN -Entscheidungstabellen. In Proceedings der 14. Internationalen Konferenz für Business Process Management (BPM) 2016
LM16 Laurson, ü. und Maggi, FM, 2016, September. Ein Werkzeug zur Analyse von DMN -Entscheidungstabellen. In BPM (Demos) (S. 56-60).
BW-A Batoulis, K. und Weske, M., ein Instrument zur Überprüfung der Klang von Entscheidungsprozessen.
BW-B Batoulis, K. und Weske, M., Disambiguation von DMN-Entscheidungstabellen.
Fmtv18 Figl, K., Mendling, J., Tokdemir, G. und VanThienen, J., 2018. Was wir wissen und was wir über DMN nicht wissen. Architekturen für Unternehmensmodellierung und Informationssysteme, 13, S. 2-1.
Silver16 Silver, B., 2016. Analyse der Entscheidungstabelle in DMN.
HDSV17 HECIC, F., De Smedt, J. und Vanthienen, J., 2017. Um die theoretische Komplexität des Entscheidungsmodells und der Notation (DMN) zu bewerten. Modellierung von Unternehmens-, Geschäftsprozess- und Informationssystemen. Springer International Publishing.
GCD Grohé, C., Corea, C. und Delfmann P, 2021. DMN 1.0 Überprüfungsfunktionen: Eine Analyse der aktuellen Toolunterstützung. Business Process Management Forum, BPM Forum 2021, Rom, Italien.
Valencia-Parra, A., Parody, L., Varela-Vaka, A., Caballero, I. und Gómez-López M., 2020. DMN4DQ: Wenn die Datenqualität auf DMN trifft. Journal 'Entscheidungsunterstützungssysteme'.
