Esta es una herramienta para la validación de archivos de notación del modelo de decisión (DMN). Realiza varios análisis estáticos para detectar inconsistencias y errores en sus modelos de decisión.
Puede usar dmn-check de seis maneras.
Actualmente, DMN-Check verifica entre otros para lo siguiente:
En las validaciones de la sección, encuentra una lista completa con descripciones detalladas de lo que hacen.
La mayoría de las propiedades e invariantes que son validadas por dmn-check se describen informalmente en la especificación DMN. En caso de que tenga preguntas sobre una validación, puede valer la pena extraer la especificación.
Este complemento requiere Java 17 o posterior y Apache Maven 3 o posterior. Algunos análisis se adaptan a la implementación de Camunda DMN y podrían no funcionar para diferentes implementaciones de DMN.
dmn-check se puede usar como un complemento Maven normal dentro de sus proyectos pom.xml o como un programa independiente.
El siguiente ejemplo muestra la configuración básica del complemento:
<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 esta configuración, el complemento buscará todas las carpetas del proyecto actual para archivos con la extensión .dmn y aplicará todos los validadores disponibles. Es posible proporcionar un conjunto de rutas de búsqueda, así como ignorar ciertos archivos y especificar los validadores que deben ejecutarse. El siguiente ejemplo muestra cómo puede utilizar estas opciones restringiendo la ruta de búsqueda a las carpetas src/ y model/ , así como ignorando el archivo test.dmn . La configuración especifica aún más que solo se debe ejecutar el ShadowedRuleValidator . Para especificar validadores, debe usar el nombre totalmente calificado.
<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>
Además, el parámetro failOnWarning (predeterminado es falso) se puede establecer para fallar una ejecución de Maven si hay errores de validación con gravedad de advertencia.
<configuration>
<failOnWarning>true</failOnWarning>
</configuration>
Para usar dmn-check sin o fuera de un proyecto Maven, puede invocarlo de la siguiente manera
mvn de.redsix:dmn-check-maven-plugin:check-dmn
Este complemento requiere Java 11 o posterior y Gradle 6.5 o posterior. Algunos análisis se adaptan a la implementación de Camunda DMN y podrían no funcionar para diferentes implementaciones de DMN.
DMNMGR es un kit de herramientas que incapera la implementación de Camunda DMN y proporciona herramientas para desarrollar aplicaciones basadas en DMN en equipos interfuncionales. Se envía con una integración dmn-check y visualiza las advertencias y errores en la representación gráfica del modelo DMN. Debe instalar DMNMGR-Client y DMNMGR-Server para usarlo.
Una imagen de Docker que contiene dmn-check está disponible en el Registro de contenedores de GitHub y puede extraer la última versión ejecutando
docker pull ghcr.io/red6/dmn-check:latest
Si desea usar docker run para ejecutar dmn-check debe montar el directorio que contiene los archivos DMN en el contenedor y establecer la ruta de búsqueda adecuadamente, por ejemplo,
docker run -v ~/dmn-files:/dmn-files ghcr.io/red6/dmn-check:latest --searchPath=/dmn-files
Si desea usar la imagen Docker en una tubería GITLAB, debe sobrescribir el punto de entrada y llamar dmn-check directamente. En el siguiente ejemplo de una tubería GITLAB, también especificamos la classpath del proyecto, para hacer posible la validación de 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)
Las siguientes subsecciones describen las validaciones disponibles en detalle. Las tablas de decisión DMN utilizadas en esta sección se derivan de un ejemplo en camunda.org.
Considere la siguiente tabla de decisión DMN con una política de éxito UNIQUE :
| Temporada ᴵᴺᴾᵁᵀ | Cuantos invitados ᴵᴺᴾᵁᵀ | Plato ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Caer" | <= 8 | "Hueso de costilla" |
| 2 | "Invierno" | <= 8 | "RoastBeef" |
| 3 | "Primavera" | [5..8] | "Bife" |
| 4 | "Invierno" | <= 8 | "RoastBeef" |
Es bastante obvio que la regla número dos es un duplicado de la regla número cuatro. Esto no está permitido por la política de éxito UNIQUE y, por lo tanto, un error.
Definición : Una regla es un duplicado de otra regla si y solo si todas las entradas y salidas de esas reglas son idénticas.
dmn-check informará reglas duplicadas para todas las tablas de decisión, excepto aquellos con Hit Policy COLLECT .
Las reglas conflictivas son algo similares a las reglas duplicadas. Considere el siguiente ejemplo con una política de éxito UNIQUE :
| Temporada ᴵᴺᴾᵁᵀ | Cuantos invitados ᴵᴺᴾᵁᵀ | Plato ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Caer" | <= 8 | "Hueso de costilla" |
| 2 | "Invierno" | <= 8 | "RoastBeef" |
| 3 | "Primavera" | [5..8] | "Bife" |
| 4 | "Invierno" | <= 8 | "Guiso" |
Miramos nuevamente una regla dos y cuatro. Esta vez, todas sus entradas son idénticas, pero difieren en la salida. Esto es posiblemente peor que una regla duplicada, ya que puede producir resultados diferentes dependiendo de la orden de evaluación de la tabla de decisiones. Suponiendo que el tiempo de ejecución no detecta esas inconsistencias.
Definición : la regla r está en conflicto con la regla s si y solo si todas las entradas de las reglas r y s son idénticas y si difieren en el arrendamiento de una salida.
dmn-check informará reglas duplicadas para todas las tablas de decisión, excepto aquellos con Policy Policy Policy COLLECT y RULE_ORDER .
Algunas reglas evitan que otras incluso se consideren. Eche un vistazo al siguiente ejemplo con Política HIT FIRST :
| Temporada ᴵᴺᴾᵁᵀ | Cuantos invitados ᴵᴺᴾᵁᵀ | Plato ᴼᵁᵀᴾᵁᵀ | |
|---|---|---|---|
| 1 | "Caer" | <= 8 | "Hueso de costilla" |
| 2 | "Invierno" | <= 8 | "RoastBeef" |
| 3 | - | - | "Guiso" |
| 4 | "Primavera" | [5..8] | "Bife" |
Este ejemplo no contiene reglas duplicadas ni reglas conflictivas. Sin embargo, todas las entradas de la Regla Tres están vacías (representadas con un tablero en este ejemplo). A medida que las entradas vacías coinciden con todo y, dado que asumimos que la política de HIT, la FIRST regla cuatro nunca coincidirá como la regla tres coincidentes para todas las entradas posibles. Por lo tanto, el estofado se sirve a los invitados de 5 a 8 en primavera. Suponiendo que cada regla tenga un propósito, las reglas sombreadas siempre son un error, ya que nunca se combinarán.
Definición : Regla r SOMBRA REGLA s SI Y solo si las entradas de la Regla r coinciden al menos para todos los valores para los cuales las entradas de la Regla s coinciden.
dmn-check informará reglas duplicadas para todas las tablas de decisión, excepto aquellos con Policy Policy Policy COLLECT y RULE_ORDER .
DMN ofrece un lenguaje de expresión rico llamado lenguaje de expresión lo suficientemente amigable (sensación) que puede usarse para describir las condiciones para las entradas de entrada. Sin embargo, como con la mayoría de los lenguajes de expresión, no todas las expresiones sintácticamente posibles son válidas (tienen semántica). dmn-check integra un verificador de tipo para el lenguaje de expresión de Feel que garantiza que una tabla de decisiones contenga solo expresiones bien tipo.
Un ejemplo de una expresión mal titada es [1..true] que describiría el rango entre 1 y true , que es (al arrendamiento de la sensación) no una expresión válida. Por el contrario, [1..9] está bien tipo y describe los números del 1 al 9.
| Sensación de expresión | Tipo |
|---|---|
| verdadero | booleano |
| [1..3] | entero |
| [1 .. "cadena"] | ✘ |
| 1, 2, verdadero | ✘ |
| > 5 | entero |
| > Verdadero | ✘ |
Por supuesto, la declaración de tipo también está validada.
La toma de decisiones a menudo implica un conjunto fijo de valores (por ejemplo, una lista de monedas compatibles) y, por lo tanto, esos valores se utilizan en las tablas de decisión DMN. Esos valores a menudo se implementan en forma de Java enums. dmn-check también para especificar el nombre de clase totalmente calificado de un enum en la Declaración de tipo de la columna de entrada / salida y verifica los valores en la tabla de decisión DMN contra la implementación de Enum.
Por defecto, dmn-check utiliza las dependencias del proyecto para resolver los enums. Como esto no es posible en el modo Maven Standalone, puede especificar el classpath que se usa para resolver los enumss
mvn de.redsix:dmn-check-maven-plugin:check-dmn -Dclasspath=foo.jar,bar.jar
El estándar DMN también proporciona una forma de conectar tablas de decisiones entre sí y modelar entradas y fuentes de conocimiento. Los gráficos resultantes se denominan gráficos de requisitos de decisión (DRG).
dmn-check verifica que un gráfico de requisitos de decisión
En el siguiente ejemplo, Dish de la tabla de decisiones tiene Season y How many guests como insumos, pero en lugar de la Season de entrada hay una Lunar phase entrada conectada a la tabla de decisiones.
gráfico TD;
x (fase lunar)-> plato;
y (cuántos invitados)-> plato;
Plato-> bebidas;
z (invitados con niños)-> bebidas;
El estándar DMN permite la agregación de valores para la recolección de políticas HIT. Por ejemplo, puede calcular la suma de todas las filas coincidentes en una tabla de decisiones. Puede usar esta función para calcular un puntaje de crédito.
Nos aseguramos de que esas agregaciones solo se apliquen a columnas con un tipo numérico. Además, validamos que las agregaciones solo se usan cuando se usa Hit Policy Collect.
Por lo general, no tiene que preocuparse mucho por las identificaciones y los nombres de los elementos DMN. Sin embargo, durante las actualizaciones y la refactorización, puede ocurrir que se pierda una identificación o un nombre. Esos errores generalmente pasan desapercibidos durante mucho tiempo. Dependiendo del escenario, faltar ID o nombres pueden romper su modelo de decisión o hacer que el análisis de errores sea difícil.
dmn-check valida que los siguientes elementos DMN siempre tienen una identificación y un nombre:
ItemDefinition s ItemDefinition s son DMNS de expresar enumeración. En la definición de una ItemDefinition declara qué valores están permitidos. Actualmente, solo validamos si las expresiones de un ItemDefintion están bien tipo.
Cuando comenzamos a trabajar en dmn-check no fuimos de herramientas de análisis para archivos DMN que se adaptaban a nuestras necesidades y trabajaron en nuestro entorno con sabor a Camunda. Desde entonces, DMN se volvió más popular y otras herramientas comenzaron a proporcionar algunas capacidades de análisis también. Si desea saber cómo se compara dmn-check con otras herramientas, puede leer una comparación en GCD.
Ülari Laurson y Fabrizio Maria Maggi extendieron el kit de herramientas de edición dmn-js de Camunda con capacidades de análisis y lo publicaron en github.com/ulaurson/dmn-js. La herramienta puede detectar la sintaxis y escribir errores e identificar reglas superpuestas y faltantes. También es capaz de simplificar las tablas de decisión fusionando reglas. En el documento de demostración LM16 describen la herramienta. Más detalles sobre los análisis realizados por la herramienta se publican en CDL+16.
CDL+16 Calvanese, D., Dumas, M., Laurson, ü., Maggi, FM, Montali, M., Teinemaa, I.: Semántica y análisis de tablas de decisión DMN. En Actas de la 14ª Conferencia Internacional sobre Gestión de Procesos de Negocios (BPM) 2016
LM16 LAURSON, ü. y Maggi, FM, 2016, septiembre. Una herramienta para el análisis de las tablas de decisión DMN. En BPM (demostraciones) (pp. 56-60).
BW-A Batoulis, K. y Weske, M., Una herramienta para verificar la solidez de los procesos comerciales conscientes de la decisión.
BW-B Batoulis, K. y Weske, M., Desambiguación de tablas de decisión DMN.
FMTV18 FIGL, K., Mendling, J., Tokdemir, G. y Vanthienen, J., 2018. Lo que sabemos y lo que no sabemos sobre DMN. Modelado empresarial y arquitecturas de sistemas de información, 13, pp.2-1.
Silver16 Silver, B., 2016. Análisis de la tabla de decisiones en DMN.
HDSV17 HASIC, F., De Smedt, J. y Vanthienen, J., 2017. Hacia la evaluación de la complejidad teórica del modelo de decisión y la notación (DMN). Enterprise, comercio-proceso y modelado de sistemas de información. Springer International Publishing.
GCD Grohé, C., Corea, C. y Delfmann P, 2021. Capacidades de verificación DMN 1.0: un análisis del soporte de herramienta actual. Foro de gestión de procesos de negocios, BPM Forum 2021, Roma, Italia.
Valencia-Parra, A., Parody, L., Varela-Vaca, A., Caballero, I. y Gómez-López M., 2020. DMN4DQ: cuando la calidad de los datos se encuentra con DMN. Revista 'Sistemas de apoyo a la decisión'.