dmn check
1.3.1
Il s'agit d'un outil pour la validation des fichiers de notation du modèle de décision (DMN). Il effectue diverses analyses statiques pour détecter les incohérences et les bogues dans vos modèles de décision.
Vous pouvez utiliser dmn-check de six manières.
Actuellement, DMN-Check vérifie entre autres pour les éléments suivants:
Dans les validations de la section, vous trouvez une liste complète avec des descriptions détaillées de ce qu'elles font.
La plupart des propriétés et des invariants validés par dmn-check sont décrits de manière informelle dans la spécification DMN. Dans le cas où vous avez des questions sur une validation, il pourrait être utile de parcourir la spécification.
Ce plugin nécessite Java 17 ou version ultérieure et Apache Maven 3 ou version ultérieure. Certaines analyses sont adaptées à l'implémentation de Camunda DMN et pourraient ne pas fonctionner pour différentes implémentations DMN.
dmn-check peut être utilisé soit comme un plugin Maven normal à l'intérieur de vos projets pom.xml ou comme programme autonome.
L'exemple suivant montre la configuration de base du plugin:
<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>
En utilisant cette configuration, le plugin recherchera tous les dossiers du projet actuel pour les fichiers avec l'extension .dmn et appliquera tous les validateurs disponibles. Il est possible de fournir un ensemble de chemins de recherche à la place, ainsi que d'ignorer certains fichiers et de spécifier les validateurs qui doivent être exécutés. L'exemple suivant montre comment vous pouvez utiliser ces options en restreignant le chemin de recherche vers les dossiers src/ et model/ , ainsi qu'en ignorant le fichier test.dmn . La configuration spécifie en outre que seul le ShadowedRuleValidator doit être exécuté. Pour spécifier les validateurs, vous devez utiliser le nom entièrement qualifié.
<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>
De plus, le paramètre failOnWarning (par défaut est faux) peut être défini pour échouer une exécution Maven s'il existe des erreurs de validation avec la gravité de l'avertissement.
<configuration>
<failOnWarning>true</failOnWarning>
</configuration>
Pour utiliser dmn-check sans ou à l'extérieur d'un projet Maven, vous pouvez l'invoquer de la manière suivante
mvn de.redsix:dmn-check-maven-plugin:check-dmn
Ce plugin nécessite Java 11 ou version ultérieure et Gradle 6.5 ou version ultérieure. Certaines analyses sont adaptées à l'implémentation de Camunda DMN et pourraient ne pas fonctionner pour différentes implémentations DMN.
DMNMGR est une boîte à outils inclantation de l'implémentation de Camunda DMN et de la fourniture d'outils pour développer des applications basées sur DMN dans des équipes interfonctionnelles. Il est expédié avec une intégration dmn-check et visualise les avertissements et les erreurs dans la représentation graphique du modèle DMN. Vous devez installer DMNMGR-CLIENT et DMNMGR-Server pour l'utiliser.
Une image Docker contenant dmn-check est disponible dans le registre des conteneurs GitHub et vous pouvez retirer la dernière version en exécutant
docker pull ghcr.io/red6/dmn-check:latest
Si vous souhaitez utiliser docker run pour exécuter dmn-check vous devez monter le répertoire contenant les fichiers DMN dans le conteneur et définir le chemin de recherche de manière appropriée, par exemple
docker run -v ~/dmn-files:/dmn-files ghcr.io/red6/dmn-check:latest --searchPath=/dmn-files
Si vous souhaitez utiliser l'image Docker dans un pipeline GitLab, vous devez écraser le point d'entrée et appeler dmn-check directement. Dans l'exemple suivant d'un pipeline GitLab, nous spécifions également le projet ClassPath, pour rendre la validation de l'énumération possible.
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)
Les sous-sections suivantes décrivent les validations disponibles en détail. Les tableaux de décision DMN utilisés dans cette section sont dérivés d'un exemple sur camunda.org.
Considérez le tableau de décision DMN suivant avec la politique de succès UNIQUE :
| Saison ᴵᴺᴾᵁᵀ | Combien d'invités ᴵᴺᴾᵁᵀ | Plat ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Automne" | <= 8 | "Spareribs" |
| 2 | "Hiver" | <= 8 | "RoastBeef" |
| 3 | "Printemps" | [5..8] | "Steak" |
| 4 | "Hiver" | <= 8 | "RoastBeef" |
Il est assez évident que la règle numéro deux est un double de la règle numéro quatre. Cela n'est pas autorisé par la politique de coup UNIQUE et donc une erreur.
Définition : Une règle est un double d'une autre règle si et seulement si toutes les entrées et sorties de ces règles sont identiques.
dmn-check rapportera des règles en double pour toutes les tables de décision, à l'exception de ceux qui ont COLLECT de la politique de coup.
Les règles contradictoires sont quelque peu similaires aux règles en double. Considérez l'exemple suivant avec la politique de coup UNIQUE :
| Saison ᴵᴺᴾᵁᵀ | Combien d'invités ᴵᴺᴾᵁᵀ | Plat ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Automne" | <= 8 | "Spareribs" |
| 2 | "Hiver" | <= 8 | "RoastBeef" |
| 3 | "Printemps" | [5..8] | "Steak" |
| 4 | "Hiver" | <= 8 | "Ragoût" |
Nous regardons à nouveau une règle deux et quatre. Cette fois, toutes leurs entrées sont identiques, mais elles diffèrent dans la sortie. Ceci est sans doute pire qu'une règle en double, car elle peut produire des résultats différents en fonction de l'ordre d'évaluation du tableau de décision. En supposant que l'exécution ne détecte pas ces incohérences.
Définition : La règle r est en conflit avec la règle s si et seulement si toutes les entrées des règles r et s sont identiques et si elles diffèrent dans la sortie de bail.
dmn-check rapportera des règles en double pour toutes les tables de décision, à l'exception de ceux qui ont une politique de hit COLLECT et RULE_ORDER .
Certaines règles empêchent d'autres d'être considérées. Jetez un œil à l'exemple suivant avec la politique de FIRST :
| Saison ᴵᴺᴾᵁᵀ | Combien d'invités ᴵᴺᴾᵁᵀ | Plat ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Automne" | <= 8 | "Spareribs" |
| 2 | "Hiver" | <= 8 | "RoastBeef" |
| 3 | - | - | "Ragoût" |
| 4 | "Printemps" | [5..8] | "Steak" |
Cet exemple ne contient aucune règle en double et aucune règle contradictoire. Cependant, toutes les entrées de la règle trois sont vides (représentées avec un tableau de bord dans cet exemple). Comme les entrées vides correspondent à tout et, puisque nous supposons que la politique de hit FIRST règle quatre ne correspondra jamais à la règle trois correspondances pour toutes les entrées possibles. Par conséquent, le ragoût est servi aux invités de 5 à 8 au printemps. En supposant que chaque règle sert un objectif, les règles ombragées sont toujours une erreur car elles ne seront jamais appariées.
Définition : Règle r Shadows Règle s Si et seulement si les entrées de la règle r correspondent au moins pour toutes les valeurs pour lesquelles les entrées de la règle s correspondent.
dmn-check rapportera des règles en double pour toutes les tables de décision, à l'exception de ceux qui ont une politique de hit COLLECT et RULE_ORDER .
DMN propose un langage d'expression riche appelé langage (FEE) de l'expression suffisamment convivial qui peut être utilisé pour décrire les conditions des entrées d'entrée. Cependant, comme pour la plupart des langages d'expression, toutes les expressions syntaxiquement possibles ne sont pas valides (ont sémantique). dmn-check intègre un vérificateur de type pour le langage d'expression de la sensation qui garantit qu'un tableau de décision ne contient que des expressions bien types.
Un exemple d'expression mal typé est [1..true] qui décrirait la plage entre 1 et true qui est (à la bail dans la sensation) et non une expression valide. En revanche, [1..9] est bien type et décrit les nombres de 1 à 9.
| Ex-expression | Taper |
|---|---|
| vrai | booléen |
| [1..3] | entier |
| [1 .. "String"] | ✘ |
| 1, 2, vrai | ✘ |
| > 5 | entier |
| > vrai | ✘ |
Bien sûr, la déclaration de type est également validée.
La prise de décision implique souvent un ensemble fixe de valeurs (par exemple, une liste de devises prises en charge) et, par conséquent, ces valeurs sont utilisées dans les tableaux de décision DMN. Ces valeurs sont souvent mises en œuvre sous forme d'énumérations Java. dmn-check également pour spécifier le nom de classe entièrement qualifié d'une énumération dans la déclaration de type de la colonne d'entrée / sortie et vérifie les valeurs de la table de décision DMN par rapport à l'implémentation de l'énum.
Par défaut, dmn-check utilise les dépendances du projet pour résoudre les enums. Comme cela n'est pas possible en mode autonome Maven, vous pouvez spécifier le chemin de classe qui est utilisé pour résoudre les énumérations
mvn de.redsix:dmn-check-maven-plugin:check-dmn -Dclasspath=foo.jar,bar.jar
La norme DMN fournit également un moyen de connecter les tables de décisions entre elles et de modéliser les entrées et les sources de connaissances. Les graphiques résultants sont appelés graphiques de décision de décision (DRG).
dmn-check vérifie qu'un graphique d'exigence de décision
Dans l'exemple suivant, Dish de table de décision a Season et How many guests comme entrées, mais au lieu de la Season des entrées, il y a une Lunar phase d'entrée connectée au tableau de décision.
graphique TD;
x (phase lunaire) -> plat;
y (combien d'invités) -> plat;
Plat -> boissons;
z (invités avec enfants) -> boissons;
La norme DMN permet l'agrégation des valeurs pour la collecte de stratégie de hit. Par exemple, vous pouvez calculer la somme de toutes les lignes correspondantes dans un tableau de décision. Vous pouvez utiliser cette fonctionnalité pour calculer une cote de crédit.
Nous nous assurons que ces agrégations ne sont appliquées qu'aux colonnes avec un type numérique. De plus, nous validons que les agrégations ne sont utilisées que lorsque la collecte de stratégie de hit est utilisée.
Habituellement, vous n'avez pas à vous soucier des ID et des noms des éléments DMN. Cependant, lors des mises à niveau et du refactorisation, il pourrait arriver qu'un identifiant ou un nom soit perdu. Ces erreurs restent généralement inaperçues pendant longtemps. Selon le scénario, les ID ou les noms manquants peuvent briser votre modèle de décision ou rendre l'analyse des erreurs délicate.
dmn-check valide que les éléments DMN suivants ont toujours un ID et un nom:
ItemDefinition S Les éléments ItemDefinition sont le moyen DMNS d'exprimer l'énumération. Dans la définition d'une ItemDefinition vous déclarez quelles valeurs sont autorisées. Actuellement, nous validons uniquement que si les expressions d'une ItemDefintion sont bien typées.
Lorsque nous avons commencé à travailler sur dmn-check nous n'étions pas des outils d'analyse pour les fichiers DMN qui répondaient à nos besoins et fonctionnaient dans notre environnement aromatisé Camunda. Depuis lors, DMN est devenu plus populaire et d'autres outils ont également commencé à fournir des capacités d'analyse. Si vous voulez savoir comment dmn-check se compare à d'autres outils, vous pouvez lire une comparaison dans GCD.
Ülari Laurson et Fabrizio Maria Maggi ont étendu la boîte à outils d'édition dmn-js de Camunda avec des capacités d'analyse et l'ont publiée sur github.com/ulaurson/dmn-js. L'outil est capable de détecter les erreurs de syntaxe et de taper et d'identifier les règles qui se chevauchent et manquantes. Il est également capable de simplifier les tables de décision en fusionnant les règles. Dans le papier de démonstration LM16, ils décrivent l'outil. De plus amples détails sur les analyses effectués par l'outil sont publiés dans CDL + 16.
CDL + 16 Calvanais, D., Dumas, M., Laurson, ü., Maggi, FM, Montali, M., Teinemaa, I.: Sémantique et analyse des tableaux de décision DMN. Dans les actes de la 14e Conférence internationale sur la gestion des processus commerciaux (BPM) 2016
LM16 Laurson, ü. et Maggi, FM, 2016, septembre. Un outil pour l'analyse des tables de décision DMN. En BPM (démos) (pp. 56-60).
BW-A Batoulis, K. et Weske, M., un outil de vérification des processus métier conscients de la décision.
BW-B Batoulis, K. et Weske, M., Disambiguation des tables de décision DMN.
FMTV18 Figl, K., Mendling, J., Tokdemir, G. et Vanthienen, J., 2018. Ce que nous savons et ce que nous ne savons pas sur DMN. Architectures de modélisation et de systèmes d'information d'entreprise, 13, pp.2-1.
Silver16 Silver, B., 2016. Analyse de la table de décision dans DMN.
HDSV17 Hasic, F., De Smedt, J. et Vanthienen, J., 2017. Vers évaluer la complexité théorique du modèle de décision et de la notation (DMN). Entreprise, processus commercial et modélisation des systèmes d'information. Springer International Publishing.
GCD Grohé, C., Corea, C. et Delfmann P, 2021. Capacités de vérification DMN 1.0: une analyse de la prise en charge actuelle des outils. Business Process Management Forum, BPM Forum 2021, Rome, Italie.
Valencia-Parra, A., Parody, L., Varela-Vaca, A., Caballero, I., et Gómez-López M., 2020. DMN4DQ: lorsque la qualité des données rencontre DMN. Journal «Systèmes d'aide à la décision».
