dmn check
1.3.1
这是验证决策模型符号（DMN）文件的工具。它执行各种静态分析，以检测您的决策模型中的不一致和错误。
您可以通过六种方式使用dmn-check 。
目前，DMN-Check在其他情况下检查以下内容：
在部分验证中，您可以找到一个完整的列表，其中包含有关其工作的详细说明。
DMN规范中非正式地描述了由dmn-check验证的大多数属性和不变性。如果您对验证有疑问，则可能值得浏览规范。
该插件需要Java 17或更高版本，并且Apache Maven 3或更高版本。一些分析是针对Camunda DMN实施量的，可能对不同的DMN实施不起作用。
dmn-check可以用作pom.xml项目中的普通Maven插件，也可以用作独立程序。
以下示例显示了插件的基本配置：
<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>
使用此配置，该插件将搜索当前项目的所有文件夹，以使用Extension .dmn搜索文件，并应用所有可用的验证器。可以提供一组搜索路径，并忽略某些文件并指定应执行的验证器。下面的示例显示了如何通过限制搜索路径到文件夹src/ and model/以及忽略文件test.dmn来使用这些选项。该配置进一步指定仅应执行ShadowedRuleValidator 。要指定验证器，您必须使用完全合格的名称。
<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>
此外，如果有警告严重性有验证错误，则可以将failOnWarning （默认值为false）参数设置为失败。
<configuration>
<failOnWarning>true</failOnWarning>
</configuration>
要使用不带Maven项目或外部的dmn-check ，您可以通过以下方式调用它
mvn de.redsix:dmn-check-maven-plugin:check-dmn
该插件需要Java 11或更高版本，然后Gradle 6.5或更高版本。一些分析是针对Camunda DMN实施量的，可能对不同的DMN实施不起作用。
DMNMGR是一个工具包，无法操纵Camunda DMN实施，并提供了开发基于DMN的跨职能团队应用程序的工具。它通过dmn-check集成运输，并可视化DMN模型图形表示中的警告和错误。您需要安装DMNMGR-CLIENT和DMNMGR-SERVER来使用它。
可以从GitHub容器注册表中获得包含dmn-check的Docker映像，您可以通过执行来提取最新版本
docker pull ghcr.io/red6/dmn-check:latest
如果要使用docker run执行dmn-check则必须将包含DMN文件的目录安装到容器中，并适当设置搜索路径，例如
docker run -v ~/dmn-files:/dmn-files ghcr.io/red6/dmn-check:latest --searchPath=/dmn-files
如果要在GitLab管道中使用Docker映像，则必须覆盖入口点并直接调用dmn-check 。在下面的gitlab管道示例中，我们也指定了项目类路径，以使枚举验证成为可能。
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)
以下小节详细描述了可用验证。本节中使用的DMN决策表源自camunda.org上的示例。
考虑以下具有HIT策略的DMN决策表UNIQUE ：
| 季节 | 多少客人ᴵᴺᴾᵁᵀ | 菜ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | “落下” | <= 8 | “ Spareribs” |
| 2 | “冬天” | <= 8 | “烤面包” |
| 3 | “春天” | [5..8] | “牛排” |
| 4 | “冬天” | <= 8 | “烤面包” |
很明显，规则第二是规则编号四的重复。 UNIQUE命中策略不允许这样做，因此不允许这样做。
定义：一条规则是当这些规则的所有输入和输出都是相同的，并且仅当时是另一个规则的重复。
dmn-check将报告所有决策表的重复规则，除了具有命中策略COLLECT规则。
冲突规则与重复规则有些相似。考虑以下示例具有HIT策略的UNIQUE ：
| 季节 | 多少客人ᴵᴺᴾᵁᵀ | 菜ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | “落下” | <= 8 | “ Spareribs” |
| 2 | “冬天” | <= 8 | “烤面包” |
| 3 | “春天” | [5..8] | “牛排” |
| 4 | “冬天” | <= 8 | “炖” |
我们再次查看规则第二和第四。这次，他们的所有输入都是相同的，但它们的输出有所不同。可以说，这比重复规则还要糟糕，因为它可能会根据决策表的评估顺序产生不同的结果。假设运行时无法检测到这些不一致之处。
定义：规则r与规则s发生冲突时，仅当规则r和s的所有输入都是相同的，并且如果它们在租赁一项输出方面有所不同。
dmn-check将报告所有决策表的重复规则，除了那些策略COLLECT和RULE_ORDER规则。
有些规则阻止其他规则甚至被考虑。 FIRST查看具有命中策略的以下示例：
| 季节 | 多少客人ᴵᴺᴾᵁᵀ | 菜ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | “落下” | <= 8 | “ Spareribs” |
| 2 | “冬天” | <= 8 | “烤面包” |
| 3 | - | - | “炖” |
| 4 | “春天” | [5..8] | “牛排” |
此示例不包含重复规则，也没有冲突的规则。但是，第三条的所有输入都是空的（在此示例中用破折号表示）。当空输入匹配所有内容时，并且由于我们假设命中策略FIRST条将永远不会匹配作为所有可能输入的规则三场匹配。因此，在春季，炖菜是5至8的客人。假设每个规则都有目的，则阴影规则始终是错误，因为它们永远不会匹配。
定义：规则r阴影规则s当规则r的输入至少与规则s匹配的所有值相匹配。
dmn-check将报告所有决策表的重复规则，除了那些具有HIT Policy COLLECT和RULE_ORDER 。
DMN提供了一种称为友好表达语言（感觉）的丰富表达语言，可用于描述输入条目的条件。但是，与大多数表达语言一样，并非所有句法表达式都有效（具有语义）。 dmn-check集成了一种类型的表达语言的检查器，以确保决策表仅包含表达式良好的表达式。
不符合表达的一个示例是[1..true] ，它将描述1和true之间的范围（在感觉时）不是有效的表达。相比之下， [1..9]数量良好，并描述了1到9的数字。
| 感觉表达 | 类型 |
|---|---|
| 真的 | 布尔 |
| [1..3] | 整数 |
| [1 ..“ string”] | ✘ |
| 1、2，是 | ✘ |
| > 5 | 整数 |
| >是 | ✘ |
当然，类型声明也已验证。
决策通常涉及一组固定的值（例如，支持的货币列表），因此这些值在DMN决策表中使用。这些值通常以Java枚举的形式实现。 dmn-check还可以在输入 - /输出列的类型声明中指定枚举的完全合格的类名称，并检查DMN决策表中针对枚举实现的值。
默认情况下， dmn-check使用项目依赖项来解决枚举。由于在Maven独立模式下这是不可能的，因此您可以指定用于解决枚举的类路径
mvn de.redsix:dmn-check-maven-plugin:check-dmn -Dclasspath=foo.jar,bar.jar
DMN标准还提供了一种将决策表连接并建模输入和知识源的方法。所得图称为决策要求图（DRG）。
dmn-check验证决策要求图
在下面的示例中，决策餐厅的Dish和How many guests作为输入，但是没有输入Season Season连接到决策表的输入Lunar phase 。
图TD;
x（月相） - >菜肴；
Y（多少个客人） - >菜肴；
菜 - >饮料；
Z（带孩子的客人） - >饮料；
DMN标准允许汇总HIT策略收集的值。例如，您可以计算决策表中所有匹配行的总和。您可以使用此功能来计算信用评分。
我们确保这些聚合仅应用于具有数字类型的列。此外，我们验证只有在使用HIT策略收集时才使用聚合。
通常，您不必太在乎DMN元素的ID和名称。但是，在升级和重构期间，可能会丢失ID或名称。这些错误通常很长时间以来一直没有注意到。根据方案，缺少ID或名称可能会破坏您的决策模型或使错误分析棘手。
dmn-check验证以下DMN元素始终具有ID和名称：
ItemDefinition s的值ItemDefinition S是表达枚举的DMN。在ItemDefinition的定义中，您声明允许哪些值。目前，我们只能验证ItemDefintion的表达方式。
当我们开始从事dmn-check时，我们不是使用适合我们需求并在Camunda风味环境中工作的DMN文件的分析工具。从那时起，DMN变得越来越流行，其他工具也可以提供一些分析功能。如果您想知道dmn-check与其他工具的比较，则可以在GCD中阅读比较。
ülariLaurson和Fabrizio Maria Maggi通过分析功能扩展了Camunda的dmn-js编辑工具包，并在Github.com/lulaurson/dmn-js上发布了它。该工具能够检测语法和键入错误，并识别重叠和丢失规则。它还能够通过合并规则来简化决策表。在演示纸LM16中，他们描述了该工具。有关该工具执行的分析的更多详细信息在CDL+16中发表。
CDL+16 Calvanese，D.，Dumas，M.，Laurson，ü。，Maggi，FM，Montali，M.，Teinemaa，I。：DMN决策表的语义和分析。在2016年第14届国际业务流程管理会议（BPM）会议录中
LM16 Laurson，ü。和Maggi，FM，2016年9月。用于分析DMN决策表的工具。在BPM（演示）（第56-60页）中。
BW-A Batoulis，K。和Weske，M。，一种用于检查决策意识的业务流程声音的工具。
BW-B Batoulis，K。和Weske，M。，DMN决策表的歧义。
FMTV18 Figl，K.，Mendling，J.，Tokdemir，G。和Vanthienen，J.，2018年。我们所知道的以及我们对DMN不了解的知识。企业建模和信息系统体系结构，第13页，第2-1页。
Silver16 Silver，B.，2016年。DMN中的决策表分析。
HDSV17 HASIC，F。，DE SMEDT，J。和Vanthienen，J。，2017年。旨在评估决策模型和符号的理论复杂性（DMN）。企业，业务过程和信息系统建模。施普林格国际出版社。
GCDGrohé ，C.，Corea，C。和Delfmann P，2021。DMN1.0验证功能：当前工具支持的分析。业务流程管理论坛，BPM论坛2021，意大利罗马。
Valencia-Parra，A.，Parody，L.，Varela-Vaca，A.，Caballero，I。和Gómez-LópezM。，2020年。DMN4DQ：当数据质量符合DMN时。期刊“决策支持系统”。
