Tao Xiaojun, Zhu Min
(Centro de Computación de la Escuela de Ciencia y Tecnología de la Información, Universidad Normal del Este de China, Shanghai 200062)
Girando en torno al uso de motores de reglas Este documento analiza y propone un conjunto de modelos de desarrollo que deben seguirse al utilizar eficazmente la tecnología de motores de reglas para desarrollar sistemas de aplicaciones de servicios empresariales, incluido el diseño de un modelo de servicios empresariales basado en motores de reglas; este artículo propone un En el proceso, se proporcionan los pasos y métodos específicos para utilizar la tecnología del motor de reglas para implementar aplicaciones de servicios empresariales.
Palabras clave: motor de reglas JSR-94 Algoritmo Rete babea
Uso del motor de reglas para construir un modelo de servicio empresarial
Zhu Min Tao Xiaojun
(Centro de Computación de la Universidad Normal del Este de China, Shanghai, 200062)
Resumen: este artículo estudiará y propondrá un modelo basado en el pensamiento del motor de reglas, que puede usarse para construir servicios empresariales y utilizar tecnología de motor de reglas. eficaz y fácilmente. Este modelo incluye un modelo de servicio empresarial basado en un motor de reglas, así como los pasos y procesos para desarrollar servicios empresariales utilizando tecnología de motor de reglas.
Palabras clave: Motor de reglas JSR-94 Algoritmo Rete saliva
1. Introducción
El motor de reglas es un sistema de software que se utiliza para gestionar e implementar reglas comerciales automáticamente. Su función principal es almacenar, clasificar y administrar reglas, verificar la coherencia de las reglas e inferir otras reglas a través de reglas, reglas de contacto y aplicaciones para implementar estas reglas. Las reglas se refieren principalmente a lógica empresarial o empresarial, regulaciones legales, políticas empresariales, etc. . El concepto de un motor de reglas es separar las reglas comerciales de la lógica de aplicación del software. En el modelo tradicional de desarrollo de aplicaciones de servicios empresariales, la lógica empresarial se fija directamente en el código de la aplicación, lo que hace que el mantenimiento de la aplicación sea complejo y costoso. Los cambios en las reglas y procesos comerciales siempre conducen a modificaciones frecuentes de las aplicaciones, especialmente cuando se enfrentan a los desafíos de los modelos y procesos comerciales dinámicos. Las aplicaciones desarrolladas en modelos tradicionales a menudo enfrentan modificaciones integrales y costosas. Incluso el diseño ha cambiado. Para resolver este problema, es necesario adoptar un nuevo modelo de desarrollo para separar la lógica empresarial de la capa de código. El uso del motor de reglas proporciona un marco de desarrollo de sistemas que separa el procesamiento comercial del procesamiento de reglas comerciales y administra y mantiene las reglas comerciales de manera unificada. Este artículo analiza el modelo de desarrollo de aplicaciones de servicios empresariales basado en motor de reglas, incluido el modelo de servicio empresarial basado en motor de reglas y los pasos y métodos de desarrollo básicos.
2. Modelo de servicio empresarial basado en motor de reglas
Diseñar un modelo de sistema claro y eficaz es un requisito previo para el buen funcionamiento del sistema de servicio empresarial. La Figura 1 utiliza un motor de reglas y su patrón que cumple con el estándar JSR-94 para diseñar una arquitectura de aplicación de servicio empresarial simple.
Figura 1
La "Figura 1" describe el sistema de servicios empresariales dividido en tres partes:
Sistema de recopilación de datos/aplicaciones: captura y almacena todos los datos de las aplicaciones. presentado por el programa y es usuario del servicio empresarial. Su función principal es presentar solicitudes comerciales y procesar juicios comerciales.
Servicio empresarial: ejecute o ejecute la lógica de reglas comerciales a través de un servidor web invocable o una llamada API al motor de reglas seleccionado y genere información y datos de retroalimentación. Al mismo tiempo, también proporciona funciones para mantener de manera fácil y efectiva la lógica de las reglas comerciales.
Servicios de soporte: proporcionan datos relevantes enviados por los usuarios de servicios comerciales, es decir, datos relevantes o interfaces de aplicaciones o servicios requeridas por el motor de reglas para ejecutar o calcular reglas comerciales.
3. Pasos y métodos del modelo de desarrollo de servicios empresariales basado en motor de reglas.
En el modelo de desarrollo de servicios empresariales basado en motores de reglas, los principios más importantes son: (1) Separar el flujo de trabajo de las reglas comerciales (2) Descripción formal de las reglas comerciales; En este modelo de desarrollo, estos dos principios se aplican en todas partes. El propósito de separar el flujo de trabajo y las reglas comerciales es extraer reglas clave de juicio comercial y respuestas a eventos comerciales y colocarlas en la parte pública del sistema (servicios comerciales) para diferentes flujos de trabajo de aplicaciones. Y fácil de mantener y gestionar. Este es el requisito previo para el buen desarrollo del sistema en este modo.
El propósito de describir formalmente las reglas de negocios es describir y representar las reglas de negocios en una forma que pueda ser procesada por el motor de reglas, de modo que las reglas de negocios puedan calcularse y las aplicaciones puedan acceder a estas reglas a través de la capa de servicio de acuerdo con el protocolo definido. .
Los métodos y principios del modelo de desarrollo mencionado y analizado a continuación giran en torno a los dos principios anteriores.
3.1 Utilice tablas de decisión para extraer reglas
En el modelo de desarrollo de servicios empresariales basado en motores de reglas, el primer problema a resolver es aclarar las reglas y los juicios comerciales correspondientes en las aplicaciones empresariales. . El conjunto de elementos condicionales en los asuntos comerciales constituye reglas, y las reglas determinan el juicio y la retroalimentación. El método de la tabla de decisiones se puede utilizar para extraer inicialmente reglas y juicios correspondientes en negocios empresariales dispersos.
Regla 1
Regla 2
......
Regla 1
Condición 1
Valor de relación
Condición 2
......
Condición j
Decisión No. 1
Retroalimentación o no
Decisión 2
......
Decisión k
Tabla 1
La "Tabla 1" proporciona el formato general de la tabla de decisiones. Con referencia al modelo que se muestra en la Figura 1, las condiciones se convertirán en campos de datos en el sistema y los valores de las condiciones serán los datos correspondientes. Este es un objeto que respalda la gestión y el mantenimiento empresarial, y también es un objeto a capturar. y presentado por el sistema de solicitud/recopilación de datos. Un conjunto de varias condiciones y sus valores constituye una regla, que es el objeto de la gestión y el mantenimiento de los servicios comerciales y también es la base para el procesamiento del motor de reglas. El juicio es un negocio.
A continuación se toma la decisión de la empresa sobre el bono de ventas del personal de ventas para el mes como ejemplo para ilustrar mejor el uso de la tabla de decisiones:
A
B
C
D
E
F
G
1
Regla 1
Regla 2
Regla 3
Regla 4
Regla 5
Regla 6
2
Lograr objetivos
Normal
Normal
Normal
Y
Y
Y
Tres
Ventas
Mes anterior
gt =10k
lt10k
=10k
Cuatro
Advertencia
Y
Normal
Normal
Normal
Y
Normal
Cinco
Amortización
0
1
2
2
2
3
Tabla 2
"Lograr el objetivo" en la Tabla 2 indica la condición de "alcanzar el objetivo de ventas"; "volumen de ventas" se refiere a la condición "volumen de ventas" se refiere al juicio; de "comisión"; "advertencia" significa juzgar "dar una advertencia"; "volumen anterior" se refiere a los datos de "ventas del último mes".
En la "Tabla 2", la columna A describe las condiciones involucradas en la aplicación y los juicios después del procesamiento del sistema, y se combina con los valores de varias condiciones o juicios en las celdas de la misma fila para de B a la columna G, y cada columna de las columnas B a G son reglas separadas por tablas de decisión, y las reglas se describen en forma de conjuntos de valores de condición y valores de retroalimentación de juicio. Por ejemplo, la regla comercial descrita en la Regla 2 es: si no se logra el objetivo de ventas y el volumen de ventas es mayor que el mes anterior, no se emitirá ninguna advertencia y la tasa de comisión se determinará como 1. La regla comercial descrita en la Regla 5 es: si se logra el objetivo de ventas y el volumen de ventas es menor o igual al mes anterior, se dará una advertencia y la tasa de comisión se determinará como 1. En aplicaciones prácticas, se puede generar una tabla de decisiones resumiendo las reglas comerciales escritas o no escritas de la empresa cuando sea necesario, como cuando las reglas comerciales no están claras.
Separar las reglas de negocio es el requisito previo para desarrollar aplicaciones empresariales basadas en motores de reglas. Es el primer paso, necesario y más importante en el modelo de desarrollo de servicios empresariales basado en motores de reglas.
Si utiliza el método de tabla de decisiones proporcionado en este artículo, podrá separar más fácilmente la lógica empresarial y las reglas comerciales, describir las reglas de manera más clara y precisa e integrarse estrechamente con el modelo de servicio empresarial basado en el motor de reglas para brindar un sólido soporte para los problemas. resolviendo en pasos de desarrollo posteriores.
3.2 Analizar y resolver conflictos de reglas.
Después de separar y extraer reglas, se deben considerar los conflictos entre reglas. El conflicto mencionado aquí se refiere principalmente a la ambigüedad de juicio causada por la intersección de los rangos de valores de las mismas condiciones entre reglas. Si los conflictos entre reglas no se resuelven, los resultados del juicio serán inciertos y el motor de reglas no podrá procesar correctamente. Podemos detectar conflictos entre reglas utilizando una cuadrícula de decisiones. El método específico consiste en colocar las reglas al frente de la cuadrícula en secuencia. Cada celda de la cuadrícula representa la intersección de las reglas correspondientes y se utiliza para registrar si el valor de retroalimentación es ambiguo cuando la regla de intersección o el conjunto de reglas es verdadero. La base para juzgar si una regla entra en conflicto es la intersección de los rangos de condiciones contenidos en las reglas de intersección y el valor de retroalimentación de cada juicio. El proceso específico se muestra en la Figura 2:
Figura 2
Tomando las reglas obtenidas en 2.1 como ejemplo, el análisis de la cuadrícula de decisiones se utiliza para determinar el conflicto entre la retroalimentación de amortización y las reglas. Los resultados se muestran en la Tabla 3.
Regla 1
Regla 2
Regla 3
Regla 4
Regla 5
Regla 6
Regla 1
Equipo de red
Y
Normal
Normal
Normal
Normal
Regla 2
Y
Equipo de red
Y[2]
Normal
Normal
Normal
Regla 3
Normal
Y[2 ]
Computadora de red
Normal
Normal
Normal
Regla 4
Normal
Normal
Normal
Equipo de red
Y[1]
Normal
Regla 5
Normal
Normal
Normal
Y[1]
Equipo de red
Y
Regla 6
Normal
Normal
Normal
Normal
Y
Equipo de red
Tabla 3
La "Tabla 3" describe claramente los conflictos entre varias reglas, donde Y indica que la regla puede Si ambos son verdaderos y entran en conflicto al mismo tiempo, el siguiente "[]" indica el nombre del juicio, el número de serie del juicio o la descripción del juicio del conflicto específico n indica que las reglas no entran en conflicto o no pueden ocurrir al mismo tiempo;
Después de aclarar la relación de conflicto entre reglas, es natural considerar cómo resolver el conflicto. Este artículo propone tres métodos para resolver conflictos de reglas: (1) modo de prioridad; (2) modo de cola; (3) modo común
Modo de prioridad: establezca el orden de prioridad de las reglas. Se utiliza la retroalimentación de juicio de la regla con mayor prioridad. Favorece el mantenimiento de la estabilidad a largo plazo de los resultados del procesamiento empresarial y es adecuado para aplicaciones empresariales con reglas claras de procesamiento empresarial.
Modo de cola: principio de primero en entrar, primero en salir, es decir, principio de primero en entrar, primero en salir. Si se produce un conflicto de reglas durante el procesamiento por lotes centralizado dentro de un período de tiempo, se utilizará la retroalimentación de juicio de la primera regla (utilizada para el último o primer procesamiento). Es útil para garantizar la coherencia de los resultados del procesamiento por lotes unificados y es adecuado para aplicaciones empresariales con picos de negocio.
Modo común: registra y hace referencia a la frecuencia de uso de las reglas en el procesamiento empresarial (la frecuencia cuando la regla es verdadera) y utiliza comentarios de las reglas con mayor o menor frecuencia cuando las reglas entran en conflicto, lo cual es beneficioso. Las reglas de aplicación flexibles para el desarrollo empresarial basadas en son adecuadas para aplicaciones empresariales con un desarrollo empresarial cambiante.
En los servicios de aplicaciones empresariales, las soluciones de resolución de conflictos de reglas anteriores se pueden utilizar solas o en combinación para formar un mecanismo de resolución de conflictos de reglas para aplicaciones empresariales.
Si no hay una resolución de conflictos de reglas, el motor de reglas generales utilizará el principio de último en entrar, primero en salir (LIFO, último en entrar, primero en salir) para resolver los conflictos de reglas, pero un conjunto de mecanismos de resolución de conflictos de reglas es fundamental para una solución exitosa. Aplicación empresarial desarrollada en base al motor de reglas. Dijo que era esencial.
3.3 Reglas de descripción formal
Después de resolver el problema de conflicto de los conjuntos de reglas, el siguiente paso del modelo de desarrollo de servicios empresariales basado en el motor de reglas es describir formalmente las reglas para facilitar la codificación. y cálculos. Los motores de reglas actuales se basan generalmente en el algoritmo Rete (algoritmo de red) propuesto por el Dr. Charles L. Forgy en 1979. La idea básica del algoritmo Rete es organizar una red de reconocimiento eficaz. Filtrar datos a medida que viajan a través de la red. El método específico del algoritmo rete es establecer primero un nodo raíz como entrada para que los objetos de datos ingresen a la red discriminante, establecer nodos de prueba para formar la red discriminante de acuerdo con las condiciones contenidas en las reglas y construir varios nodos terminales en la red discriminante. parte inferior de la red para describir las reglas correspondientes. Una vez que el objeto de datos ingresa a la red de autenticación, pasa a través de los nodos de ruta. Finalmente, cuando se alcanza un determinado punto final, se activa la regla descrita por este punto final. Según las características del algoritmo Rete, las reglas deben dividirse en LHS (lado izquierdo) y RHS (lado derecho). El LHS consta de la parte condicional de la regla, que determina la generación de nodos de prueba en la red de identificación, y el RHS consta de la parte de decisión de la regla, que determina la generación de puntos finales en la red de identificación.
Tomando las reglas obtenidas en 2.1 como ejemplo, la tabla de decisión obtenida en el paso de extracción de reglas se puede utilizar para resolver el problema. Para cada regla, los valores de condición de su columna constituyen su LHS y sus valores de retroalimentación de decisión constituyen su RHS. Por lo tanto, cada regla se puede describir formalmente como:
La descripción formal de las reglas allana el camino para el posterior proceso de codificación de reglas en el modelo de desarrollo de servicios empresariales basado en el motor de reglas.
3.4 Diseño de procesos de negocio
Al igual que los patrones de diseño habituales, el modelo de desarrollo de servicios empresariales basado en motores de reglas también incluye y se centra en el diseño de procesos de negocio de servicios empresariales. Debido a la separación de los procesos comerciales y las reglas comerciales, el diseño de los procesos comerciales se simplifica enormemente y la carga de los procesos comerciales se reduce considerablemente. Los principios de diseño de los procesos de negocio deben seguir el modelo de servicio descrito en la "Figura 1". El método de diseño adopta el mismo método UML que el patrón de diseño anterior y no se discutirá en detalle en este artículo. Tomando el ejemplo propuesto en 2.1 como ejemplo, se proporciona el diagrama de actividad del proceso de negocio correspondiente para ilustrar intuitivamente el grado de simplificación del diseño del proceso de negocio después de la separación de los procesos de negocio y las reglas de negocio.
Figura 3
Se puede ver claramente en la "Figura 3" que el proceso de negocio ya no contiene lógica de negocio. Cuando cambia la lógica empresarial, no es necesario cambiar el proceso empresarial.
3.5 Codificación de reglas comerciales y codificación de procesos comerciales
El paso de codificación no es solo el proceso de implementación del servicio empresarial, sino también el proceso de implementación del código del programa en resumen. En este proceso es necesario seguir el diseño y resultados de los pasos anteriores y desarrollarse en torno al modelo de servicio descrito en la "Figura 1". Tomando como ejemplo el ejemplo propuesto en 2.1, se selecciona el lenguaje Java y el motor de reglas "Drools" para implementar la codificación. Este artículo solo brinda las clases que deben implementarse y sus breves descripciones.
Implementación de la parte de la aplicación
SellApplication.class captura datos, envía solicitudes de juicio comercial, recibe comentarios e implementa procesos comerciales.
SalesPerson.class es un objeto de datos que registra datos del vendedor.
FeedBack.class registra datos de juicio y retroalimentación.
Implementación de la parte del servicio de soporte
AchieveTargetService.class es responsable de brindarle al personal de ventas el estado de logro del objetivo de ventas.
SaleVolume.class es responsable de proporcionar las ventas mensuales y del mes anterior del personal de ventas.
Implementación de la parte de servicio empresarial
La clase de servicio de amortización acepta solicitudes de juicio empresarial, llama al servicio del motor de reglas y retroalimenta los juicios.
Codificación de reglas
Tome la regla 1 en la "Tabla 1" como ejemplo. Su código de motor de reglas "Drools" correspondiente es el siguiente.
Regla "regla1"
Significado-100 //Establecimiento de prioridad
Cuándo //LHS
Vendedor (achieveTarget = = false, SaleVolume lt= 100000)
$sa: SellApplication()
$fb: Feedback()
Entonces //RHS
FB . set warn(true);
FB . set amortización(" 0 ");
sa . >
4. Conclusión
El modelo de desarrollo de servicios empresariales basado en la arquitectura del motor de reglas propuesto en este artículo combina estrechamente la idea del motor de reglas. Los pasos y métodos propuestos pueden ayudar a los desarrolladores a separar los procesos comerciales y las reglas comerciales en el proceso de desarrollo de servicios de aplicaciones empresariales, aclarar las reglas comerciales, hacer que estas reglas comerciales sean descriptivas y utilizables y, finalmente, implementar sus funciones en los servicios de aplicaciones. Aunque la aplicación de los motores de reglas aún no es extensa y profunda, sus conceptos y teorías son relativamente maduros y tienen ventajas obvias para las aplicaciones de servicios empresariales, especialmente en modelos de negocios dinámicos. En el proceso de desarrollo real de los servicios de aplicaciones empresariales, la introducción de modelos de desarrollo de servicios empresariales basados en la arquitectura del motor de reglas hará que las aplicaciones de servicios empresariales sean más fáciles de mantener y flexibles, y tendrán valor de promoción.
Referencia:
Malcolm Chisholm. Cómo construir un motor de reglas de negocio[M]. Estados Unidos: Morgan Kaufman
[2]Iain Graham. Gestión de reglas de negocio y arquitectura orientada a servicios[M]. Estados Unidos: Wiley, 2007.01
[3] (EE.UU.) Traducido por Gamma y otros, traducido por Li Yingjun y otros [M] Beijing: Machinery Industry Press, 2005.06
[4] (Americano) Traducido por Dida et al., traducido por Li Hongdong et al., Pattern Classification (2.ª edición) [M]. Beijing: Machinery Industry Press, 2003.09