dmn check
1.3.1
これは、決定モデル表記（DMN）ファイルを検証するためのツールです。さまざまな静的分析を実行して、意思決定モデルの不一致とバグを検出します。
dmn-check 6つの方法で使用できます。
現在、DMN-Check Checksは次のことを確認します。
セクションの検証には、それらが何をしているかを詳細に説明した完全なリストがあります。
dmn-checkによって検証されたほとんどのプロパティと不変剤は、DMN仕様で非公式に説明されています。検証について質問がある場合は、仕様をスキムする価値がある場合があります。
このプラグインには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>
この構成を使用して、プラグインは現在のプロジェクトのすべてのフォルダーを、拡張子.dmnを使用したファイルを検索し、利用可能なすべてのバリーターを適用します。代わりに一連の検索パスを提供したり、特定のファイルを無視したり、実行すべきバリデーターを指定することができます。次の例は、フォルダーsrc/および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）パラメーターをMaven実行に失敗させるように設定できます。
<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をインストールする必要があります。
dmn-checkを含むDocker画像はGitHub Containerレジストリから入手でき、実行して最新バージョンを引くことができます
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の例から派生しています。
ヒットポリシーを備えた次のDMN決定表を考えてみUNIQUE 。
| 季節ᴵᴺᴾᵁᵀ | ゲスト数ᴵᴺᴾᵁᵀ | 皿ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "秋" | <= 8 | 「Spareribs」 |
| 2 | "冬" | <= 8 | 「ローストビーフ」 |
| 3 | "春" | [5..8] | "ステーキ" |
| 4 | "冬" | <= 8 | 「ローストビーフ」 |
ルール2がルール番号4の複製であることは明らかです。これは、 UNIQUEヒットポリシーでは許可されておらず、したがってエラーは許可されていません。
定義：ルールは、これらのルールのすべての入力と出力が同一である場合にのみ、別のルールの複製です。
dmn-checkヒットポリシーCOLLECT持つ人を除くすべての決定表の重複ルールを報告します。
矛盾するルールは、複製するルールに多少似ています。ヒットポリシーのUNIQUEな次の例を考えてみましょう。
| 季節ᴵᴺᴾᵁᵀ | ゲスト数ᴵᴺᴾᵁᵀ | 皿ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "秋" | <= 8 | 「Spareribs」 |
| 2 | "冬" | <= 8 | 「ローストビーフ」 |
| 3 | "春" | [5..8] | "ステーキ" |
| 4 | "冬" | <= 8 | "シチュー" |
再びルール2と4を見ます。今回は、すべての入力は同一ですが、出力が異なります。これは、決定表の評価順序に応じて異なる結果を生み出す可能性があるため、重複するルールよりも間違いなく悪いです。ランタイムがこれらの矛盾を検出しないと仮定します。
定義：ルールr 、ルールrとsのすべての入力が同一であり、リースで1つの出力が異なる場合にのみ、ルールsと競合します。
dmn-checkヒットポリシーCOLLECTおよびRULE_ORDER持つ人を除き、すべての決定表の重複ルールを報告します。
いくつかのルールは、他の人が考慮されることさえ妨げています。 FIRSTヒットポリシーで次の例をご覧ください。
| 季節ᴵᴺᴾᵁᵀ | ゲスト数ᴵᴺᴾᵁᵀ | 皿ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "秋" | <= 8 | 「Spareribs」 |
| 2 | "冬" | <= 8 | 「ローストビーフ」 |
| 3 | - | - | "シチュー" |
| 4 | "春" | [5..8] | "ステーキ" |
この例には、重複するルールも矛盾するルールも含まれていません。ただし、ルール3のすべての入力は空です（この例ではダッシュで表されます）。空の入力はすべてに一致し、ヒットポリシーのFIRSTルール4は、可能なすべての入力のルール3マッチとして一致することは決してないと仮定します。したがって、シチューは春に5〜8のゲストに提供されます。各ルールが目的に役立つと仮定すると、影付きのルールは常に一致しないため、常にエラーです。
定義：ルールrシャドウルールsルールrの入力が少なくともルールsの入力が一致するすべての値について一致した場合にのみ。
dmn-checkヒットポリシーCOLLECTおよびRULE_ORDER持つ人を除くすべての決定表の重複ルールを報告します。
DMNは、入力エントリの条件を説明するために使用できるFriendly Opplession Language（Feel）と呼ばれるリッチな表現言語を提供します。ただし、ほとんどの表現言語と同様に、すべての構文的に可能な式が有効であるわけではありません（セマンティックを持っています）。 dmn-check意思決定テーブルに十分なタイプの表現のみが含まれることを保証する感触表現言語のタイプチェッカーを統合します。
不正な式の例は、 [1..true]であり、 1つとtrueの範囲を記述します。対照的に、 [1..9]はよくタイプで、1から9までの数字を説明しています。
| 感触 - 発現 | タイプ |
|---|---|
| 真実 | ブール |
| [1..3] | 整数 |
| [1 .. "String"] | ✘ |
| 1、2、true | ✘ |
| > 5 | 整数 |
| >本当です | ✘ |
もちろん、タイプ宣言も検証されています。
意思決定には、多くの場合、固定された値のセット（サポート通貨のリストなど）が含まれるため、これらの値はDMN決定表で使用されます。これらの値は、多くの場合、Java Enumsの形で実装されます。また、 dmn-check入力 - /出力コラムの型宣言の列挙の完全に適格なクラス名を指定し、列挙の実装に対してDMN決定表の値をチェックします。
デフォルトでは、 dmn-checkプロジェクトの依存関係を使用して酵素を解決します。これはMaven Standaloneモードでは不可能であるため、Enumsの解決に使用されるClassPathを指定できます。
mvn de.redsix:dmn-check-maven-plugin:check-dmn -Dclasspath=foo.jar,bar.jar
DMN標準は、意思決定テーブルを相互に接続し、入力と知識ソースをモデル化する方法も提供します。結果のグラフは、決定要件グラフ（DRG）と呼ばれます。
dmn-check 、決定要件グラフを確認します
次の例では、意思決定テーブルDishはSeasonと入力としてのHow many guestsがありますが、入力Seasonの代わりに、意思決定テーブルに接続された入力Lunar phaseがあります。
グラフTD;
x（月位相） - >皿;
y（ゲスト数） - >皿;
皿 - >飲み物;
Z（子供を持つゲスト） - > Beverages;
DMN標準により、ヒットポリシー収集の値の集約が可能になります。たとえば、決定表のすべての一致する行の合計を計算できます。この機能を使用して、クレジットスコアを計算できます。
これらの集計が数値タイプの列にのみ適用されるようにします。さらに、ヒットポリシー収集が使用される場合にのみ集約が使用されることを検証します。
通常、DMN要素のIDや名前についてあまり気にする必要はありません。ただし、アップグレードとリファクタリング中に、IDまたは名前が失われることが発生する可能性があります。これらのエラーは通常、長い間気付かれないままです。シナリオに応じて、IDまたは名前が欠落している場合は、意思決定モデルを破るか、エラー分析が難しい場合があります。
dmn-check次のDMN要素には常にIDと名前があることを検証します。
ItemDefinitionから許可された値ItemDefinition sは、列挙を表現するためのDMNS方法です。 ItemDefinitionの定義では、許可されている値を宣言します。現在、 ItemDefintionからの式が十分にタイプであるかどうかのみ検証します。
dmn-checkの作業を開始したとき、私たちは私たちのニーズに合ったDMNファイルの分析ツールではありませんでした。それ以来、DMNはより一般的になり、他のツールがいくつかの分析機能も提供し始めました。 dmn-check他のツールとどのように比較されるかを知りたい場合は、GCDの比較を読むことができます。
Ulari LaursonとFabrizio Maria Maggiは、分析機能を使用してCamundaのdmn-js編集ツールキットを拡張し、github.com/ulurson/dmn-jsで公開しました。このツールは、構文とタイプエラーを検出し、重複したルールと欠落しているルールを識別することができます。また、ルールを統合することにより、決定表を簡素化することもできます。デモペーパーLM16では、ツールについて説明しています。ツールによって実行された分析の詳細は、CDL+16で公開されています。
CDL+16 Calvanese、D.、Dumas、M.、Laurson、ü。、Maggi、FM、Montali、M.、Teinemaa、i。：DMN決定表の意味論と分析。第14回ビジネスプロセス管理会議（BPM）2016の議事録
LM16 Laurson、ü。およびマギー、FM、2016年9月。 DMN決定表を分析するためのツール。 BPM（DEMOS）（pp。56-60）。
BW-A Batoulis、K。およびWeske、M.、意思決定に対応するビジネスプロセスの健全性をチェックするためのツール。
BW-B Batoulis、K。およびWeske、M。、DMN決定表の曖昧性を乱します。
Fmtv18 Figl、K.、Mendling、J.、Tokdemir、G。and Vanthienen、J.、2018。私たちが知っていることとDMNについて知らないこと。エンタープライズモデリングおよび情報システムアーキテクチャ、13、pp.2-1。
Silver16 Silver、B.、2016。DMNの決定表分析。
HDSV17 Hasic、F.、de Smedt、J。、およびVanthienen、J.、2017年。決定モデルと表記法（DMN）の理論的複雑さの評価に向けて。エンタープライズ、ビジネスプロセス、情報システムモデリング。 Springer International Publishing。
GCDGrohé 、C.、Corea、C。and Delfmann P、2021。DMN1.0検証機能：現在のツールサポートの分析。ビジネスプロセス管理フォーラム、BPMフォーラム2021、ローマ、イタリア。
Valencia-Parra、A.、Parody、L.、Varela-Vaca、A.、Caballero、I。、およびGómez-LópezM.、2020。DMN4DQ：データ品質がDMNを満たしているとき。ジャーナル「意思決定支援システム」。
