dmn check
1.3.1
Это инструмент для проверки файлов нотации модели принятия решений (DMN). Он выполняет различные статические анализы для обнаружения несоответствий и ошибок в ваших моделях решений.
Вы можете использовать dmn-check шестью способами.
В настоящее время DMN-проверка проверяет среди других:
В разделе проверки вы найдете полный список с подробными описаниями того, что они делают.
Большинство свойств и инвариантов, которые подтверждены dmn-check неформально описаны в спецификации DMN. В случае, если у вас есть вопросы по поводу проверки, это может стоить сброс спецификации.
Этот плагин требует Java 17 или более поздней версии и Apache Maven 3 или более поздней версии. Некоторые анализы адаптированы к реализации Camunda DMN и могут не работать для различных реализаций DMN.
dmn-check может использоваться либо в качестве обычного плагина Maven внутри ваших проектов pom.xml , либо в качестве автономной программы.
В следующем примере показана основная конфигурация плагина:
<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>
Чтобы использовать dmn-check без или за пределами проекта Maven, вы можете вызвать его следующим образом
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, чтобы использовать его.
Изображение Docker, содержащее dmn-check доступно в реестре контейнеров GitHub, и вы можете вытащить последнюю версию, выполнив
docker pull ghcr.io/red6/dmn-check:latest
Если вы хотите использовать docker run для выполнения dmn-check вам нужно установить каталог, содержащий файлы DMN в контейнер, и правильно установить путь поиска, например, EG
docker run -v ~/dmn-files:/dmn-files ghcr.io/red6/dmn-check:latest --searchPath=/dmn-files
Если вы хотите использовать изображение Docker в трубопроводе Gitlab, вам нужно перезаписать точку записи и напрямую вызовать dmn-check . В следующем примере трубопровода Gitlab мы также указываем и Project ClassPath, чтобы сделать валидацию 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)
В следующих подразделах подробно описываются доступные проверки. Таблицы решений DMN, используемые в этом разделе, получены из примера на camunda.org.
Рассмотрим следующую таблицу решений DMN с помощью политики HIT UNIQUE :
| Сезон ᴵᴺᴾᵁᵀ | Сколько гостей ᴵᴺᴾᵁᵀ | Блюдо ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Падать" | <= 8 | "Spareribs" |
| 2 | "Зима" | <= 8 | "RoastBeef" |
| 3 | "Весна" | [5..8] | "Стейк" |
| 4 | "Зима" | <= 8 | "RoastBeef" |
Совершенно очевидно, что правило номер два - дубликат правила № четыре. Это не разрешено UNIQUE политикой попадания и, следовательно, ошибкой.
Определение : правило - это дубликат другого правила, если и только тогда, когда все входы и выходы этих правил идентичны.
dmn-check сообщит о дублирующих правилах для всех таблиц принятия решений, за исключением тех, у кого есть хитовая политика COLLECT
Конфликтующие правила несколько похожи на дубликаты правил. Рассмотрим следующий пример с UNIQUE политикой HIT:
| Сезон ᴵᴺᴾᵁᵀ | Сколько гостей ᴵᴺᴾᵁᵀ | Блюдо ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Падать" | <= 8 | "Spareribs" |
| 2 | "Зима" | <= 8 | "RoastBeef" |
| 3 | "Весна" | [5..8] | "Стейк" |
| 4 | "Зима" | <= 8 | "Тушить" |
Мы снова смотрим правилом два и четыре. На этот раз все их входы идентичны, но они отличаются по выходу. Это, возможно, хуже, чем дубликат правила, поскольку оно может дать разные результаты в зависимости от порядок оценки таблицы решений. Предполагая, что время выполнения не обнаруживает эти несоответствия.
Определение : Правило r находится в конфликте с правилом s , если и только если все входы правил r и s идентичны, и если они отличаются при аренде.
dmn-check сообщит о дублирующих правилах для всех таблиц принятия решений, за исключением тех, у кого есть Hit Policy COLLECT и RULE_ORDER .
Некоторые правила не позволяют другим даже рассматриваться. FIRST посмотрите на следующий пример с Hit Policy:
| Сезон ᴵᴺᴾᵁᵀ | Сколько гостей ᴵᴺᴾᵁᵀ | Блюдо ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Падать" | <= 8 | "Spareribs" |
| 2 | "Зима" | <= 8 | "RoastBeef" |
| 3 | - | - | "Тушить" |
| 4 | "Весна" | [5..8] | "Стейк" |
Этот пример не содержит дубликатов правил и не противоречивых правил. Тем не менее, все входные данные третьего являются пустыми (представлены с помощью черты в этом примере). Поскольку пустые входы соответствуют всем, и, поскольку мы предполагаем, что HIT Policy FIRST Four Four никогда не будет совпадать, как правило, три соответствуют всем возможным входным данным. Поэтому тушеное мясо подается гостям от 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 .. "строка"] | ✘ |
| 1, 2, правда | ✘ |
| > 5 | целое число |
| > правда | ✘ |
Конечно, объявление типа также подтверждено.
Принятие решений часто включает в себя фиксированный набор значений (например, список поддерживаемых валют), и поэтому эти значения используются в таблицах решений DMN. Эти значения часто реализуются в форме перечисления Java. dmn-check также для указания полностью квалифицированного имени класса Enum в объявлении типа входной колонки и проверяет значения в таблице решений DMN в отношении реализации enum.
По умолчанию 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 позволяет агрегировать значения для сбора политики HIT. Например, вы можете вычислить сумму всех соответствующих рядов в таблице решений. Вы можете использовать эту функцию для расчета кредитного рейтинга.
Мы гарантируем, что эти агрегации применяются только к столбцам с числовым типом. Кроме того, мы подтверждаем, что агрегации используются только тогда, когда используется сбор хитов.
Обычно вам не нужно много заботиться о идентификаторах и именах элементов DMN. Однако во время обновлений и рефакторинга может произойти, что идентификатор или имя потеряно. Эти ошибки обычно остаются незамеченными в течение длительного времени. В зависимости от сценария отсутствующие идентификаторы или имена могут сломать вашу модель принятия решений или сделать анализ ошибок.
dmn-check проверяет, что у следующих элементов DMN всегда есть идентификатор и имя:
ItemDefinition s ItemDefinition s - это способ выражения перечисления. В определении ItemDefinition вы заявляете, какие значения разрешены. В настоящее время мы проверяем, только если выражения из ItemDefintion хорошо
Когда мы начали работать над dmn-check мы не имели инструментов анализа для файлов DMN, которые соответствовали нашим потребностям и работали в нашей среде с ароматием Camunda. С тех пор DMN стал более популярным, а другие инструменты также начали предоставлять некоторые возможности анализа. Если вы хотите знать, как dmn-check сравнивается с другими инструментами, вы можете прочитать сравнение в GCD.
Ülari Laurson и Fabrizio Maria Maggi расширили инструментарий dmn-js Редактирования Camunda с возможностями анализа и опубликовали его по адресу github.com/ulaurson/dmn-js. Инструмент способен обнаружить синтаксис и ошибки типа и идентифицировать перекрывающиеся и отсутствующие правила. Он также может упростить таблицы решений, объединяя правила. В демо -бумаге LM16 они описывают инструмент. Более подробная информация об анализах, выполненных инструментом, опубликованы в CDL+16.
CDL+16 Calvanese, D., Dumas, M., Laurson, ü., Maggi, FM, Montali, M., Teinemaa, I.: Семантика и анализ таблиц решений DMN. В материалах 14 -й Международной конференции по управлению бизнес -процессами (BPM) 2016
LM16 Laurson, ü. и Maggi, FM, 2016, сентябрь. Инструмент для анализа таблиц решений DMN. В BPM (Demos) (стр. 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, стр.2-1.
Silver16 Silver, B., 2016. Анализ таблиц решений в DMN.
HDSV17 Hasic, F., De Smedt, J. and Vanthienen, J., 2017. Для оценки теоретической сложности модели и обозначения принятия решений (DMN). Моделирование предприятий, бизнес-процесса и информационных систем. Springer International Publishing.
GCD Grohé, C., Corea, C. и Delfmann P, 2021. Возможности проверки DMN 1.0: анализ современной поддержки инструментов. Форум управления бизнес -процессами, BPM Forum 2021, Рим, Италия.
Валенсия-Парра А., Пародия Л., Варела-Вака А., Кабальеро И. и Гомес-Лопес М., 2020. DMN4DQ: Когда качество данных соответствует DMN. Журнал «Системы поддержки принятия решений».
