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時。期刊“決策支持系統”。
