dmn check
1.3.1
Ini adalah alat untuk validasi file notasi model keputusan (DMN). Ini melakukan berbagai analisis statis untuk mendeteksi ketidakkonsistenan dan bug dalam model keputusan Anda.
Anda dapat menggunakan dmn-check dalam enam cara.
Saat ini, DMN-cek memeriksa antara lain untuk yang berikut:
Di bagian validasi, Anda menemukan daftar lengkap dengan deskripsi terperinci tentang apa yang mereka lakukan.
Sebagian besar properti dan invarian yang divalidasi oleh dmn-check dijelaskan secara informal dalam spesifikasi DMN. Jika Anda memiliki pertanyaan tentang validasi, mungkin ada baiknya untuk membaca spesifikasi.
Plugin ini membutuhkan Java 17 atau lebih baru dan Apache Maven 3 atau lebih baru. Beberapa analisis disesuaikan dengan implementasi Camunda DMN dan mungkin tidak berfungsi untuk implementasi DMN yang berbeda.
dmn-check dapat digunakan baik sebagai plugin Maven normal di dalam proyek Anda pom.xml atau sebagai program mandiri.
Contoh berikut menunjukkan konfigurasi dasar 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>
Menggunakan konfigurasi ini, plugin akan mencari semua folder dari proyek saat ini untuk file dengan ekstensi .dmn dan menerapkan semua validator yang tersedia. Dimungkinkan untuk menyediakan satu set jalur pencarian sebagai gantinya, serta mengabaikan file tertentu dan menentukan validator yang harus dieksekusi. Contoh berikut menunjukkan bagaimana Anda dapat menggunakan opsi ini dengan membatasi jalur pencarian ke folder src/ dan model/ , serta mengabaikan file test.dmn . Konfigurasi lebih lanjut menentukan bahwa hanya ShadowedRuleValidator yang harus dieksekusi. Untuk menentukan validator, Anda harus menggunakan nama yang sepenuhnya memenuhi syarat.
<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>
Selain itu, parameter failOnWarning (default false) dapat diatur untuk gagal eksekusi Maven jika ada kesalahan validasi dengan keparahan peringatan.
<configuration>
<failOnWarning>true</failOnWarning>
</configuration>
Untuk menggunakan dmn-check tanpa atau di luar proyek Maven, Anda dapat memohonnya dengan cara berikut
mvn de.redsix:dmn-check-maven-plugin:check-dmn
Plugin ini membutuhkan Java 11 atau lebih dan lulusan 6.5 atau lebih baru. Beberapa analisis disesuaikan dengan implementasi Camunda DMN dan mungkin tidak berfungsi untuk implementasi DMN yang berbeda.
DMNMGR adalah toolkit yang tidak mengoperasikan implementasi Camunda DMN dan menyediakan alat untuk mengembangkan aplikasi berbasis DMN dalam tim lintas fungsi. Ini dikirimkan dengan integrasi dmn-check dan memvisualisasikan peringatan dan kesalahan dalam representasi grafis dari model DMN. Anda perlu menginstal DMNMGR-CLIENT dan DMNMGR-Server untuk menggunakannya.
Gambar Docker yang berisi dmn-check tersedia dari Github Container Registry dan Anda dapat menarik versi terbaru dengan mengeksekusi
docker pull ghcr.io/red6/dmn-check:latest
Jika Anda ingin menggunakan docker run untuk mengeksekusi dmn-check Anda harus memasang direktori yang berisi file DMN ke dalam wadah dan mengatur jalur pencarian dengan tepat, misalnya
docker run -v ~/dmn-files:/dmn-files ghcr.io/red6/dmn-check:latest --searchPath=/dmn-files
Jika Anda ingin menggunakan gambar Docker dalam pipa gitlab, Anda harus menimpa entri-titik dan menelepon dmn-check secara langsung. Dalam contoh pipa GitLab berikut, kami juga menentukan proyek Classpath, untuk memungkinkan validasi enum.
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)
Subbagian berikut menjelaskan validasi yang tersedia secara rinci. Tabel keputusan DMN yang digunakan dalam bagian ini berasal dari contoh di camunda.org.
Pertimbangkan tabel keputusan DMN berikut dengan kebijakan HIT UNIQUE :
| Musim ᴵᴺᴾᵁᵀ | Berapa banyak tamu ᴵᴺᴾᵁᵀ | Dish ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Jatuh" | <= 8 | "Spareribs" |
| 2 | "Musim dingin" | <= 8 | "RoastBeef" |
| 3 | "Musim semi" | [5..8] | "Steak" |
| 4 | "Musim dingin" | <= 8 | "RoastBeef" |
Cukup jelas bahwa aturan nomor dua adalah duplikat dari aturan nomor empat. Ini tidak diizinkan oleh kebijakan hit UNIQUE dan dengan demikian kesalahan.
Definisi : Suatu aturan adalah duplikat dari aturan lain jika dan hanya jika semua input dan output dari aturan tersebut identik.
dmn-check akan melaporkan aturan duplikat untuk semua tabel keputusan kecuali untuk mereka yang COLLECT kebijakan hit.
Aturan yang bertentangan agak mirip dengan aturan duplikat. Pertimbangkan contoh berikut dengan Hit Policy UNIQUE :
| Musim ᴵᴺᴾᵁᵀ | Berapa banyak tamu ᴵᴺᴾᵁᵀ | Dish ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Jatuh" | <= 8 | "Spareribs" |
| 2 | "Musim dingin" | <= 8 | "RoastBeef" |
| 3 | "Musim semi" | [5..8] | "Steak" |
| 4 | "Musim dingin" | <= 8 | "Rebusan" |
Kami melihat lagi aturan dua dan empat. Kali ini, semua inputnya identik, tetapi mereka berbeda dalam output. Ini bisa dibilang lebih buruk daripada aturan duplikat, karena dapat menghasilkan hasil yang berbeda tergantung pada urutan evaluasi tabel keputusan. Dengan asumsi bahwa runtime tidak mendeteksi ketidakkonsistenan tersebut.
Definisi : Aturan r bertentangan dengan aturan s jika dan hanya jika semua input aturan r dan s identik dan jika mereka berbeda di sewa satu output.
dmn-check akan melaporkan aturan duplikat untuk semua tabel keputusan, kecuali untuk mereka yang COLLECT kebijakan hit dan RULE_ORDER .
Beberapa aturan mencegah orang lain bahkan dipertimbangkan. Lihat contoh berikut dengan kebijakan hit FIRST :
| Musim ᴵᴺᴾᵁᵀ | Berapa banyak tamu ᴵᴺᴾᵁᵀ | Dish ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Jatuh" | <= 8 | "Spareribs" |
| 2 | "Musim dingin" | <= 8 | "RoastBeef" |
| 3 | - - | - - | "Rebusan" |
| 4 | "Musim semi" | [5..8] | "Steak" |
Contoh ini tidak berisi aturan duplikat dan tidak ada aturan yang bertentangan. Namun, semua input aturan tiga kosong (diwakili dengan tanda hubung dalam contoh ini). Karena input kosong cocok dengan segalanya dan karena kami menganggap Hit Policy FIRST Rule Four tidak akan pernah cocok sebagai aturan tiga pertandingan untuk semua input yang mungkin. Oleh karena itu, rebusan disajikan kepada para tamu 5 hingga 8 di musim semi. Dengan asumsi bahwa setiap aturan melayani suatu tujuan, aturan yang dibayangi selalu merupakan kesalahan karena tidak akan pernah dicocokkan.
Definisi : Aturan r bayang -bayang aturan s jika dan hanya jika input aturan r cocok setidaknya untuk semua nilai yang input s cocok.
dmn-check akan melaporkan aturan duplikat untuk semua tabel keputusan kecuali untuk mereka yang COLLECT kebijakan hit dan RULE_ORDER .
DMN menawarkan bahasa ekspresi yang kaya yang disebut bahasa ekspresi yang cukup ramah (nuansa) yang dapat digunakan untuk menggambarkan kondisi untuk entri input. Namun, seperti halnya sebagian besar bahasa ekspresi, tidak semua ekspresi yang mungkin secara sintaksis valid (memiliki semantik). dmn-check mengintegrasikan tipe pemeriksa untuk bahasa ekspresi rasa yang memastikan bahwa tabel keputusan hanya berisi ekspresi yang diketik dengan baik.
Contoh ekspresi yang tidak diketik adalah [1..true] yang akan menggambarkan kisaran antara 1 dan true yang (sewa sewa) bukan ekspresi yang valid. Sebaliknya, [1..9] diketik dengan baik dan menggambarkan angka-angka dari 1 hingga 9.
| Ekspresi perasaan | Jenis |
|---|---|
| BENAR | Boolean |
| [1..3] | bilangan bulat |
| [1 .. "String"] | ✘ |
| 1, 2, benar | ✘ |
| > 5 | bilangan bulat |
| > Benar | ✘ |
Tentu saja jenis deklarasi juga divalidasi.
Pengambilan keputusan sering melibatkan serangkaian nilai tetap (misalnya daftar mata uang yang didukung) dan oleh karena itu nilai-nilai tersebut digunakan dalam tabel keputusan DMN. Nilai -nilai tersebut sering diimplementasikan dalam bentuk java enums. dmn-check juga untuk menentukan nama kelas yang sepenuhnya memenuhi syarat dari enum dalam deklarasi tipe input- / output-kolom dan memeriksa nilai-nilai dalam tabel keputusan DMN terhadap implementasi enum.
Secara default dmn-check menggunakan dependensi proyek untuk menyelesaikan enum. Karena ini tidak mungkin dalam mode mandiri Maven, Anda dapat menentukan classpath yang digunakan untuk menyelesaikan enum
mvn de.redsix:dmn-check-maven-plugin:check-dmn -Dclasspath=foo.jar,bar.jar
Standar DMN juga menyediakan cara untuk menghubungkan tabel keputusan satu sama lain dan untuk memodelkan input dan sumber pengetahuan. Grafik yang dihasilkan disebut grafik persyaratan keputusan (DRG).
dmn-check memverifikasi bahwa grafik persyaratan keputusan
Dalam contoh berikut, Decision Table Dish memiliki Season dan How many guests sebagai input, tetapi alih -alih Season input ada Lunar phase yang terhubung ke tabel keputusan.
grafik td;
X (fase bulan)-> Dish;
y (berapa banyak tamu)-> Dish;
Dish-> Minuman;
z (tamu dengan anak-anak)-> minuman;
Standar DMN memungkinkan agregasi nilai untuk pengumpulan kebijakan hit. Misalnya, Anda dapat menghitung jumlah semua baris yang cocok dalam tabel keputusan. Anda dapat menggunakan fitur ini untuk menghitung skor kredit.
Kami memastikan bahwa agregasi tersebut hanya diterapkan pada kolom dengan tipe numerik. Selain itu, kami memvalidasi bahwa agregasi hanya digunakan ketika pengumpulan kebijakan hit digunakan.
Biasanya Anda tidak perlu banyak peduli tentang ID dan nama elemen DMN. Namun, selama peningkatan dan refactoring mungkin terjadi bahwa ID atau nama hilang. Kesalahan -kesalahan itu biasanya tetap tidak diperhatikan untuk waktu yang lama. Tergantung pada skenario ID atau nama yang hilang dapat merusak model keputusan Anda atau membuat analisis kesalahan rumit.
dmn-check memvalidasi bahwa elemen DMN berikut selalu memiliki ID dan nama:
ItemDefinition S ItemDefinition S adalah cara DMNS untuk mengekspresikan enumerasi. Dalam definisi ItemDefinition Anda menyatakan nilai mana yang diizinkan. Saat ini, kami hanya memvalidasi jika ekspresi dari ItemDefintion diketik dengan baik.
Ketika kami mulai mengerjakan dmn-check kami tidak memiliki alat analisis untuk file DMN yang sesuai dengan kebutuhan kami dan bekerja di lingkungan rasa Camunda kami. Sejak itu DMN menjadi lebih populer dan alat lain mulai memberikan beberapa kemampuan analisis juga. Jika Anda ingin tahu bagaimana dmn-check dibandingkan dengan alat lain, Anda dapat membaca perbandingan di GCD.
Ülari Laurson dan Fabrizio Maria Maggi memperluas toolkit pengeditan dmn-js dari Camunda dengan kemampuan analisis dan menerbitkannya di github.com/ulaurson/dmn-js. Alat ini dapat mendeteksi sintaks dan mengetik kesalahan dan mengidentifikasi aturan yang tumpang tindih dan hilang. Ini juga dapat menyederhanakan tabel keputusan dengan menggabungkan aturan. Di kertas demo LM16 mereka menggambarkan alat tersebut. Rincian lebih lanjut tentang analisis yang dilakukan oleh alat ini diterbitkan dalam CDL+16.
CDL+16 Calvanese, D., Dumas, M., Laurson, ü., Maggi, FM, Montali, M., Teinemaa, I.: Semantik dan Analisis Tabel Keputusan DMN. Dalam Prosiding Konferensi Internasional ke -14 tentang Manajemen Proses Bisnis (BPM) 2016
LM16 Laurson, ü. dan Maggi, FM, 2016, September. Alat untuk analisis tabel keputusan DMN. Dalam BPM (demo) (hlm. 56-60).
BW-A Batoulis, K. dan Weske, M., alat untuk memeriksa kesehatan proses bisnis yang sadar keputusan.
BW-B Batoulis, K. dan Weske, M., Disambiguasi Tabel Keputusan DMN.
FMTV18 Figl, K., Mendling, J., Tokdemir, G. dan Vanthienen, J., 2018. Apa yang kita ketahui dan apa yang tidak kita ketahui tentang DMN. Pemodelan Perusahaan dan Arsitektur Sistem Informasi, 13, hlm.2-1.
Silver16 Silver, B., 2016. Analisis tabel keputusan di DMN.
HDSV17 Hasic, F., De Smedt, J. dan Vanthienen, J., 2017. Menuju menilai kompleksitas teoritis dari model keputusan dan notasi (DMN). Pemodelan perusahaan, proses bisnis, dan sistem informasi. Penerbitan Springer International.
GCD Grohé, C., Corea, C. dan Delfmann P, 2021. DMN 1.0 Kemampuan Verifikasi: Analisis Dukungan Alat Saat Ini. Forum Manajemen Proses Bisnis, BPM Forum 2021, Roma, Italia.
Valencia-Parra, A., Parody, L., Varela-Vaca, A., Caballero, I., dan Gómez-López M., 2020. DMN4DQ: Ketika kualitas data memenuhi DMN. Jurnal 'Sistem Dukungan Keputusan'.
