Escribiendo reglas de negocio con motores de reglas

Hace ya algunos años que el paradigma de motores de reglas está aceptado como algo más allá del concepto de inteligencia artificial. Hoy por hoy el mercado entiende a los motores de reglas como una forma de aislar la lógica negocio por fuera del desarrollo de código.

¿Que virtudes guarda el desarrollar las reglas de negocio en un motor de reglas?

En primera instancia los motores de reglas nos permiten pasar de un modelo imperativo de desarrollo a un modelo declarativo, este modelo es más simple en la codificación porque describimos que hacer no como…. en teoría.

¿Por qué los programadores tienen la tendencia a usar mecanismos provistos por el software para ordenar la ejecución de las reglas?, priorizaciones, agrupaciones, banderas (todos elementos para el control de flujo de las reglas). Simplemente porque estamos acostumbrados a programar dando instrucciones a las máquinas de CÓMO actuar.

Independientemente del modo de programación nos encontramos con que los motores de reglas nos ilusionan con que vamos a poder poner al experto delante de una aplicación administradora de reglas y podremos adaptar el negocio sin necesidad de programación. Aquí surgen dos inconvenientes:

1 .- La interfaz entre el sistema y las reglas no se ajusta a los cambios que necesitamos

En la mayoría de los cambios de reglas se requiere nuevos datos o nuevas acciones, si estos no están predefinidos en la invocación al motor de reglas difícilmente podamos hacer inferencia sobre ellos.

2.- La interfaz de usuario para escribir las reglas requiere de conocimientos de programación.

Las tecnologías disponibles hoy en día facilitan pero no resuelven las problemáticas de requerir conocimiento técnico para la escritura de reglas. Se están realizando muchas investigaciones para la interpretación del lenguaje natural, hay investigaciones muy interesantes respecto a la interpretación en dominios específicos, como por ejemplo “Rule extraction in gene–disease relationship discovery” by Wen-Juan Hou and Hsiao-Yuan Chen from Department of Computer Science and Information Engineering, National Taiwan Normal University, Taipei, Taiwan

Ante estos inconvenientes ¿por qué utilizaríamos un motor de reglas?

Esta es mi versión de la respuesta basado en mi experiencia.

Respecto a la dudosa proposición “las reglas las escribe el experto” mi postura es que debemos buscar patrones de uso que nos permitan agrupar las reglas de modo tal que pueda segmentar conjuntos de reglas simples modificables por el experto y otro conjunto de reglas complejas que son modificadas por el desarrollador, un patrón que suelo aplicar y que me ha sido útil en muchos escenarios es el de tener un conjunto de reglas que generan el contexto y un conjunto reducido de reglas que ejecutan las consecuencias. (Separate context inference from validation pattern)

Ejemplo de separación de inferencia y validación

Separate context inference from validation pattern example

Este enfoque nos permite hacer uso de diferentes técnicas que limitarían a un programador pero que facilitan mucho la escritura de reglas (tablas de decisión, lenguajes específicos de dominio, interfaces gráficas de escritura de reglas, traductores automáticos).

Si prestamos atención a la problemática de modificación del código cuándo cambio las reglas el enfoque que más resultado me ha dado es “inserta todo lo que puedas al contexto”, a partir de eso y de la mano de lo hablado en el párrafo anterior es una buena estrategia que exista un conjunto de reglas que inicialmente armen el contexto. La variable a tener en cuenta aquí es: MEMORIA, cuántos elementos podemos mantener con los recursos de hardware disponibles.

Por otro lado el hecho de tener separadas las reglas nos facilitan el mostrarlas y el relacionarlas con la definición formal que tenga la compañía. Mostrarlas desde el punto de vista que es mucho más legible una regla que un segmento de código, por lo que aunque necesitemos un programador al lado un experto puede leer las reglas.

Respecto a la trazabilidad desde la documentación a la regla es más simple enumerar las reglas relacionadas a un documento funcional, proceso, etc que indicar las líneas de código.

 

Conclusión

  • Debemos establecer lineamientos de uso que impidan desarrollar reglas en forma imperativa, debe evitarse a toda costa el uso de priorizaciones (toda intención de uso debe verse como un posible error o una excepción).
  • Podemos tener real acercamiento del experto a las reglas de negocio, en el peor de los casos de la mano de un desarrollador que le dé soporte.
  • Las reglas están aisladas y por ende más fácil de gobernar.
  • Puedo tener traza de la definición a la implementación.

Un tema importante es que estamos dejando de lado la principal fortaleza de los motores de reglas que es su uso como motor de inferencia. Podemos decir en consecuencia que bajo criterios de gobernabilidad, uso y potencialidad el escribir las reglas de negocio de la compañía utilizando motores de reglas no debería generar dudas.

Advertisements