dmn check
1.3.1
Esta é uma ferramenta para a validação de arquivos de notação do modelo de decisão (DMN). Ele realiza várias análises estáticas para detectar inconsistências e bugs em seus modelos de decisão.
Você pode usar dmn-check de seis maneiras.
Atualmente, o DMN verifica, entre outros, o seguinte:
Na seção Valitações, você encontra uma lista completa com descrições detalhadas do que elas fazem.
A maioria das propriedades e invariantes validados pelo dmn-check são descritos informalmente na especificação DMN. Caso você tenha dúvidas sobre as validações, pode valer a pena passar a especificação.
Este plug -in requer Java 17 ou posterior e Apache Maven 3 ou posterior. Algumas análises são adaptadas à implementação do Camunda DMN e podem não funcionar para diferentes implementações de DMN.
dmn-check pode ser usada como um plug-in normal do Maven dentro de seus projetos pom.xml ou como um programa independente.
O exemplo a seguir mostra a configuração básica do 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>
Usando essa configuração, o plug -in pesquisará todas as pastas do projeto atual para arquivos com a extensão .dmn e aplicará todos os validadores disponíveis. É possível fornecer um conjunto de caminhos de pesquisa, além de ignorar certos arquivos e especificar os validadores que devem ser executados. O exemplo a seguir mostra como você pode usar essas opções restringindo o caminho de pesquisa às pastas src/ e model/ , além de ignorar test.dmn de arquivo.dmn. A configuração especifica ainda que apenas o ShadowedRuleValidator deve ser executado. Para especificar validadores, você deve usar o nome totalmente qualificado.
<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>
Além disso, o parâmetro failOnWarning (padrão é falso) pode ser definido para falhar em uma execução do MAVEN se houver erros de validação com severidade de aviso.
<configuration>
<failOnWarning>true</failOnWarning>
</configuration>
Para usar dmn-check sem ou fora de um projeto Maven, você pode invocar-o da seguinte maneira
mvn de.redsix:dmn-check-maven-plugin:check-dmn
Este plug -in requer Java 11 ou posterior e Gradle 6.5 ou posterior. Algumas análises são adaptadas à implementação do Camunda DMN e podem não funcionar para diferentes implementações de DMN.
O DMNMGR é um kit de ferramentas que exalta a implementação do Camunda DMN e fornece ferramentas para desenvolver aplicativos baseados em DMN em equipes multifuncionais. Ele é enviado com uma integração dmn-check e visualiza os avisos e erros na representação gráfica do modelo DMN. Você precisa instalar o DMNMGR-Client e o DMNMGR-Server para usá-lo.
Uma imagem do docker que contém dmn-check está disponível no registro do contêiner do GitHub e você pode puxar a versão mais recente executando
docker pull ghcr.io/red6/dmn-check:latest
Se você deseja usar docker run para executar dmn-check você deve montar o diretório que contém os arquivos DMN no contêiner e definir o caminho de pesquisa adequadamente, por exemplo
docker run -v ~/dmn-files:/dmn-files ghcr.io/red6/dmn-check:latest --searchPath=/dmn-files
Se você deseja usar a imagem do Docker em um pipeline do GitLab, precisará substituir o ponto de entrada e ligar diretamente para dmn-check . No exemplo a seguir de um pipeline GitLab, especificamos o projeto de classe do projeto, para tornar possível a validação da 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)
As subseções a seguir descrevem as validações disponíveis em detalhes. As tabelas de decisão do DMN usadas nesta seção são derivadas de um exemplo no Camunda.org.
Considere a seguinte tabela de decisão do DMN com política de sucesso UNIQUE :
| Temporada ᴵᴺᴾᵁᵀ | Quantos convidados ᴵᴺᴾᵁᵀ | Prato ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Cair" | <= 8 | "Sparerribs" |
| 2 | "Inverno" | <= 8 | "Assado" |
| 3 | "Primavera" | [5..8] | "Bife" |
| 4 | "Inverno" | <= 8 | "Assado" |
É bastante óbvio que a regra número dois é uma duplicata da regra número quatro. Isso não é permitido pela política de sucesso UNIQUE e, portanto, um erro.
Definição : Uma regra é uma duplicata de outra regra se e somente se todas as entradas e saídas dessas regras forem idênticas.
dmn-check relatará regras duplicadas para todas as tabelas de decisão, exceto para aqueles com COLLECT de políticas de hit.
Regras conflitantes são um pouco semelhantes às regras duplicadas. Considere o exemplo a seguir com a política de sucesso UNIQUE :
| Temporada ᴵᴺᴾᵁᵀ | Quantos convidados ᴵᴺᴾᵁᵀ | Prato ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Cair" | <= 8 | "Sparerribs" |
| 2 | "Inverno" | <= 8 | "Assado" |
| 3 | "Primavera" | [5..8] | "Bife" |
| 4 | "Inverno" | <= 8 | "Ensopado" |
Olhamos novamente uma regra dois e quatro. Desta vez, todas as suas entradas são idênticas, mas diferem na saída. Isso é indiscutivelmente pior do que uma regra duplicada, pois pode produzir resultados diferentes, dependendo da ordem de avaliação da tabela de decisão. Supondo que o tempo de execução não detecte essas inconsistências.
Definição : a regra r está em conflito com a regra s se e somente se todas as entradas das regras r e s forem idênticas e se elas diferirem no arrendamento uma saída.
dmn-check reportará regras duplicadas para todas as tabelas de decisão, exceto para aqueles com políticas de hits COLLECT e RULE_ORDER .
Algumas regras impedem que outras sejam consideradas. Dê uma olhada no exemplo a seguir com a política de sucesso FIRST :
| Temporada ᴵᴺᴾᵁᵀ | Quantos convidados ᴵᴺᴾᵁᵀ | Prato ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Cair" | <= 8 | "Sparerribs" |
| 2 | "Inverno" | <= 8 | "Assado" |
| 3 | - | - | "Ensopado" |
| 4 | "Primavera" | [5..8] | "Bife" |
Este exemplo não contém regras duplicadas nem regras conflitantes. No entanto, todas as entradas da regra três estão vazias (representadas com um traço neste exemplo). Como as entradas vazias correspondem a tudo e, como assumimos que a política de hit FIRST regra quatro nunca corresponderá à regra três correspondências para todas as entradas possíveis. Portanto, o ensopado é servido aos convidados de 5 a 8 na primavera. Supondo que cada regra serve a um propósito, as regras sombrias são sempre um erro, pois nunca serão correspondidas.
Definição : Regra r Shadows Regra s se e somente se as entradas da regra r corresponderem pelo menos para todos os valores para os quais as entradas da s correspondem.
dmn-check reportará regras duplicadas para todas as tabelas de decisão, exceto para aqueles com políticas de hits COLLECT e RULE_ORDER .
O DMN oferece uma rica linguagem de expressão chamada linguagem de expressão (sensação) suficientemente amigável que pode ser usada para descrever as condições para as entradas de entrada. No entanto, como na maioria das linguagens de expressão, nem todas as expressões sintaticamente possíveis são válidas (têm semântico). dmn-check integra um verificador de tipo para a linguagem de expressão de sensação que garante que uma tabela de decisão contenha apenas expressões talhadas.
Um exemplo de uma expressão mal-tipada é [1..true] que descreveria o intervalo entre 1 e true que é (no arrendamento na sensação) não uma expressão válida. Em contraste, [1..9] é bem-sucedido e descreve os números de 1 a 9.
| Sensação de sensação | Tipo |
|---|---|
| verdadeiro | booleano |
| [1..3] | Inteiro |
| [1 .. "String"] | ✘ |
| 1, 2, verdadeiro | ✘ |
| > 5 | Inteiro |
| > Verdadeiro | ✘ |
Obviamente, a declaração de tipo também é validada.
A tomada de decisão geralmente envolve um conjunto fixo de valores (por exemplo, uma lista de moedas suportadas) e, portanto, esses valores são usados nas tabelas de decisão da DMN. Esses valores são frequentemente implementados na forma de enum java. dmn-check também para especificar o nome da classe totalmente qualificado de uma enumeração na declaração de tipo da coluna de entrada / saída e verifica os valores na tabela de decisão do DMN contra a implementação da enum.
Por padrão, dmn-check usa as dependências do projeto para resolver as enumes. Como isso não é possível no modo independente do Maven, você pode especificar o caminho de classe usado para resolver as enumistas
mvn de.redsix:dmn-check-maven-plugin:check-dmn -Dclasspath=foo.jar,bar.jar
O padrão DMN também fornece uma maneira de conectar tabelas de decisões entre si e modelar entradas e fontes de conhecimento. Os gráficos resultantes são chamados de gráficos de requisitos de decisão (DRG).
dmn-check verifica se um gráfico de requisitos de decisão
No exemplo a seguir, Dish da mesa de decisão tem Season e How many guests como insumos, mas em vez da Season de entrada há uma Lunar phase entrada conectada à tabela de decisão.
Gráfico TD;
x (fase lunar)-> prato;
y (quantos convidados)-> prato;
Prato-> bebidas;
Z (convidados com crianças)-> Bebidas;
O padrão DMN permite a agregação de valores para a coleta de políticas de hit. Por exemplo, você pode calcular a soma de todas as linhas correspondentes em uma tabela de decisão. Você pode usar esse recurso para calcular uma pontuação de crédito.
Garantimos que essas agregações sejam aplicadas apenas a colunas com um tipo numérico. Além disso, validamos que as agregações são usadas apenas quando a coleta de políticas de HIT é usada.
Normalmente, você não precisa se preocupar muito com IDs e nomes dos elementos DMN. No entanto, durante as atualizações e a refatoração, pode acontecer que um ID ou um nome seja perdido. Esses erros geralmente ficam despercebidos por um longo tempo. Dependendo do cenário, os IDs ou nomes ausentes podem quebrar seu modelo de decisão ou tornar complicados a análise de erros.
dmn-check valida que os seguintes elementos DMN sempre têm um ID e um nome:
ItemDefinition s ItemDefinition S são DMNs de expressar enumeração. Na definição de uma ItemDefinition você declara quais valores são permitidos. Atualmente, apenas validamos se as expressões de uma ItemDefintion estiver bem tocada.
Quando começamos a trabalhar no dmn-check não éramos ferramentas de análise para arquivos DMN que atendiam às nossas necessidades e trabalham em nosso ambiente com sabor de Camunda. Desde então, a DMN se tornou mais popular e outras ferramentas começaram a fornecer alguns recursos de análise também. Se você quiser saber como dmn-check se compara a outras ferramentas, pode ler uma comparação no GCD.
Ülari Laurson e Fabrizio Maria Maggi estenderam o kit de ferramentas de edição dmn-js de Camunda com recursos de análise e o publicaram em github.com/ulaurson/dmn-js. A ferramenta é capaz de detectar sintaxe e digitar erros e identificar regras sobrepostas e ausentes. Também é capaz de simplificar as tabelas de decisão mesclando regras. No papel de demonstração LM16, eles descrevem a ferramenta. Mais detalhes sobre as análises realizadas pela ferramenta são publicadas no CDL+16.
CDL+16 Calvanese, D., Dumas, M., Laurson, ü., Maggi, FM, Montali, M., Teinemaa, I.: Semântica e análise das tabelas de decisão da DMN. Em Anais da 14ª Conferência Internacional sobre Gerenciamento de Processos de Negócios (BPM) 2016
LM16 Laurson, ü. e Maggi, FM, 2016, setembro. Uma ferramenta para a análise das tabelas de decisão do DMN. Em BPM (demos) (pp. 56-60).
BW-A Batoulis, K. e Weske, M., uma ferramenta para verificar a solidez dos processos de negócios com reconhecimento de decisão.
BW-B Batoulis, K. e Weske, M., Desambiguação das tabelas de decisão da DMN.
FMTV18 Figl, K., Mendling, J., Tokdemir, G. e Vanthienen, J., 2018. O que sabemos e o que não sabemos sobre DMN. Arquiteturas de Sistemas de Modelagem e Informação da Enterprise, 13, pp.2-1.
Silver16 Silver, B., 2016. Análise da tabela de decisão em DMN.
HDSV17 Hasic, F., De Smedt, J. e Vanthienen, J., 2017. Rumo a avaliar a complexidade teórica do modelo de decisão e notação (DMN). Modelagem de Sistemas de Empresa, Processo de Negócios e Sistemas de Informação. Springer International Publishing.
GCD Grohé, C., Corea, C. e Delfmann P, 2021. Capacidades de verificação DMN 1.0: Uma análise do suporte atual da ferramenta. Fórum de Gerenciamento de Processos de Negócios, Fórum BPM 2021, Roma, Itália.
Valencia-Parra, A., Parody, L., Varela-Vaca, A., Caballero, I. e Gómez-López M., 2020. DMN4DQ: Quando a qualidade dos dados atende a DMN. Jornal 'Sistemas de Suporte à Decisão'.
