이것은 의사 결정 모델 표기법 (DMN) 파일의 검증을위한 도구입니다. 의사 결정 모델에서 불일치와 버그를 감지하기 위해 다양한 정적 분석을 수행합니다.
6 가지 방법으로 dmn-check 사용할 수 있습니다.
현재 DMN-Check는 다음 사항을 확인합니다.
섹션 유효성 검사에서, 당신은 그들이하는 일에 대한 자세한 설명이 포함 된 전체 목록을 찾습니다.
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>
이 구성을 사용하여 플러그인은 현재 프로젝트의 모든 폴더를 Extension .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 이상 및 6.5 이상이 필요합니다. 일부 분석은 Camunda DMN 구현에 맞게 조정되며 다른 DMN 구현에는 효과가 없을 수 있습니다.
DMNMGR은 Camunda DMN 구현을 통해 툴킷으로, 교차 기능 팀에서 DMN 기반 애플리케이션을 개발하는 도구를 제공합니다. dmn-check 통합과 함께 제공되며 DMN 모델의 그래픽 표현에서 경고와 오류를 시각화합니다. dmnmgr-client 및 dmnmgr-server를 설치하려면 사용해야합니다.
dmn-check 포함 된 Docker 이미지는 Github 컨테이너 레지스트리에서 제공되며 실행하여 최신 버전을 가져올 수 있습니다.
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 이미지를 사용하려면 EntryPoint를 덮어 쓰고 dmn-check 직접 호출해야합니다. Gitlab 파이프 라인의 다음 예에서는 Enum 검증을 가능하게하기 위해 Project ClassPath도 지정합니다.
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 Policy UNIQUE 한 다음 DMN 의사 결정 테이블을 고려하십시오.
| 시즌 ᴵᴺᴾᵁᵀ | 얼마나 많은 손님 ᴵᴺᴾᵁᵀ | 접시 ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "떨어지다" | <= 8 | "spareribs" |
| 2 | "겨울" | <= 8 | "로스트 비프" |
| 3 | "봄" | [5..8] | "스테이크" |
| 4 | "겨울" | <= 8 | "로스트 비프" |
규칙 번호 2가 규칙 번호 4의 복제라는 것은 분명합니다. 이것은 UNIQUE 적중 정책과 오류로 인해 허용되지 않습니다.
정의 : 규칙은 해당 규칙의 모든 입력 및 출력이 동일 한 경우에만 다른 규칙의 복제입니다.
dmn-check HIT 정책 COLLECT 있는 사람을 제외한 모든 의사 결정 테이블에 대한 중복 규칙을보고합니다.
충돌하는 규칙은 중복 규칙과 다소 유사합니다. Hit Policy의 다음 예를 고려 UNIQUE .
| 시즌 ᴵᴺᴾᵁᵀ | 얼마나 많은 손님 ᴵᴺᴾᵁᵀ | 접시 ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "떨어지다" | <= 8 | "spareribs" |
| 2 | "겨울" | <= 8 | "로스트 비프" |
| 3 | "봄" | [5..8] | "스테이크" |
| 4 | "겨울" | <= 8 | "스튜" |
우리는 다시 규칙 2와 4를 본다. 이번에는 모든 입력이 동일하지만 출력이 다릅니다. 의사 결정 테이블의 평가 순서에 따라 다른 결과를 생성 할 수 있기 때문에 이것은 중복 규칙보다 더 나쁩니다. 런타임이 그러한 불일치를 감지하지 않는다고 가정합니다.
정의 : 규칙 r r s s 합니다.
dmn-check HIT 정책 COLLECT 및 RULE_ORDER 가진 사람을 제외하고 모든 의사 결정 테이블에 대한 중복 규칙을보고합니다.
일부 규칙은 다른 규칙에 따라 다른 규칙을 고려하지 못하게합니다. Hit Policy의 다음 예제를 FIRST 살펴보십시오.
| 시즌 ᴵᴺᴾᵁᵀ | 얼마나 많은 손님 ᴵᴺᴾᵁᵀ | 접시 ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "떨어지다" | <= 8 | "spareribs" |
| 2 | "겨울" | <= 8 | "로스트 비프" |
| 3 | - | - | "스튜" |
| 4 | "봄" | [5..8] | "스테이크" |
이 예제에는 중복 규칙이없고 충돌하는 규칙이 없습니다. 그러나 규칙 3의 모든 입력은 비어 있습니다 (이 예에서는 대시로 표시). 빈 입력이 모든 것을 일치시키기 때문에 우리는 히트 정책을 가정하기 때문에 FIRST 규칙 4는 가능한 모든 입력에 대해 규칙 3 경기와 일치하지 않습니다. 따라서 스튜는 봄에 5-8의 손님에게 제공됩니다. 각 규칙이 목적을 제공한다고 가정하면 그림자 규칙은 결코 일치하지 않기 때문에 항상 오류입니다.
정의 : 규칙 r 의 입력이 적어도 r 의 입력이 일치하는 모든 값에 대해 일치하는 경우에만 규칙을 s s 표시합니다.
dmn-check HIT 정책 COLLECT 및 RULE_ORDER 를 제외한 모든 의사 결정 테이블에 대한 중복 규칙을보고합니다.
DMN은 입력 항목 조건을 설명하는 데 사용할 수있는 친절한 표현 언어 (느낌)라는 풍부한 표현 언어를 제공합니다. 그러나 대부분의 표현 언어와 마찬가지로 구문 적으로 가능한 모든 표현이 유효하지는 않습니다 (의미 론적). dmn-check 의사 결정 테이블에 잘 표현 된 표현식 만 포함되도록 느낌 표현 언어에 대한 유형 검사기를 통합합니다.
악의적 인 표현의 예는 [1..true] 이며, 이는 유효한 표현이 아닌 1 과 true 사이의 범위를 설명합니다. 대조적으로, [1..9] 잘 정리되어 있으며 1에서 9까지의 숫자를 설명합니다.
| 느낌-표현 | 유형 |
|---|---|
| 진실 | 부울 |
| [1..3] | 정수 |
| [1 .. "문자열"] | ✘ |
| 1, 2, 사실 | ✘ |
| > 5 | 정수 |
| > 진실 | ✘ |
물론 유형 선언도 검증되었습니다.
의사 결정에는 종종 고정 된 값 세트 (예 : 지원 통화 목록)가 포함되므로 해당 값은 DMN 의사 결정 테이블에 사용됩니다. 이러한 값은 종종 자바 열거 형태로 구현됩니다. 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 Season 과 입력으로 How many guests 있지만 입력 Season 대신 의사 결정 테이블에 연결된 입력 Lunar phase 가 있습니다.
그래프 TD;
x (음력 단계)-> 접시;
Y (얼마나 많은 손님)-> 요리;
접시-> 음료;
Z (자녀가있는 손님)-> 음료;
DMN 표준은 적중 정책 수집을위한 값의 집계를 허용합니다. 예를 들어, 의사 결정 테이블에서 모든 일치하는 행의 합을 계산할 수 있습니다. 이 기능을 사용하여 신용 점수를 계산할 수 있습니다.
우리는 이러한 집계가 숫자 유형의 컬럼에만 적용되도록합니다. 또한, 적중 정책 수집이 사용될 때만 집계가 사용되는지 확인합니다.
일반적으로 DMN 요소의 ID 및 이름에 대해 많은 관심을 기울일 필요는 없습니다. 그러나 업그레이드 및 리팩토링 중에 ID 또는 이름이 손실 될 수 있습니다. 이러한 오류는 일반적으로 오랫동안 눈에 띄지 않습니다. 시나리오에 따라 누락 된 ID 또는 이름이 결정 모델을 깨뜨 리거나 오류 분석을 까다로울 수 있습니다.
dmn-check 다음 DMN 요소에 항상 ID와 이름이 있음을 확인합니다.
ItemDefinition 의 허용 값 ItemDefinition S는 열거를 표현하는 DMNS 방법입니다. ItemDefinition 의 정의에서 어떤 값이 허용되는지 선언합니다. 현재, 우리는 ItemDefintion 의 표현이 잘 정리되어 있는지 확인합니다.
우리가 dmn-check 에서 작업하기 시작했을 때 우리는 우리의 요구에 맞는 DMN 파일에 대한 분석 도구가 아니고 Camunda 향이 나는 환경에서 일했습니다. 그 이후로 DMN은 더 인기가 높아지고 다른 도구가 시작되어 일부 분석 기능도 제공됩니다. dmn-check 다른 도구와 어떻게 비교되는지 알고 싶다면 GCD에서 비교를 읽을 수 있습니다.
ülari laurson과 Fabrizio Maria Maggi는 분석 기능을 갖춘 Camunda의 dmn-js 편집 툴킷을 확장하여 github.com/ulaurson/dmn-js에 게시했습니다. 이 도구는 구문 및 유형 오류를 감지하고 중첩 및 누락 규칙을 식별 할 수 있습니다. 또한 규칙을 병합하여 의사 결정 테이블을 단순화 할 수 있습니다. 데모 용지 LM16에서 그들은 도구를 설명합니다. 도구에서 수행 한 분석에 대한 자세한 내용은 CDL+16에 게시되었습니다.
CDL+16 Calvanese, D., Dumas, M., Laurson, ü., Maggi, FM, Montali, M., Teinemaa, I. : DMN 의사 결정 테이블의 의미 및 분석. BPM (Business Process Management에 관한 14 번째 국제 회의) 2016
LM16 Laurson, ü. 및 Maggi, FM, 2016, 9 월. DMN 의사 결정 테이블 분석 도구. BPM (데모) (pp. 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, pp.2-1.
Silver16 Silver, B., 2016. DMN의 의사 결정 테이블 분석.
HDSV17 HASIC, F., DE SMEDT, J. 및 VANTHEINEN, J., 2017. 의사 결정 모델 및 표기법 (DMN)의 이론적 복잡성을 평가합니다. 기업, 비즈니스 프로세스 및 정보 시스템 모델링. Springer International Publishing.
GCD Grohé, C., Corea, C. 및 Delfmann P, 2021. DMN 1.0 검증 기능 : 현재 도구 지원 분석. 비즈니스 프로세스 관리 포럼, BPM 포럼 2021, 이탈리아 로마.
Valencia-Parra, A., Parody, L., Varela-Vaca, A., Caballero, I. 및 Gómez-López M., 2020. DMN4DQ : 데이터 품질이 DMN을 충족 할 때. 저널 '의사 결정 지원 시스템'.