Creación de motores de reglas de negocio con Drools - Power to the SMEople

Una de las cosas más sorprendentes de trabajar en el desarrollo de software es la capacidad de trabajar en muchas industrias diferentes, especialmente si eres consultor. La mayoría de las habilidades de desarrollo de software que aprende mientras trabaja en una industria son directamente transferibles a cualquier número de otras industrias, empresas, proyectos y nichos.

Me refiero a temas como el diseño de bases de datos, patrones de diseño, diseños de GUI, gestión de eventos, etc. Luego, por supuesto, hay temas específicos de una industria, empresa o proyecto en particular.

La pyme se encuentra con la TI, comienza la transferencia de conocimientos

Aquí es donde entra en juego el experto en la materia (SME). Una SME normalmente estará muy involucrada en la etapa de diseño del proyecto.

La PYME ha estado trabajando dentro de la industria durante un largo período de tiempo, conoce la jerga y comprende la lógica comercial detrás de la codificación. La PYME puede tener cierta comprensión del desarrollo de software, pero esto no es necesario para que el proyecto tenga éxito.

Para muchos proyectos, a menos que el desarrollador de software tenga una gran comprensión de la lógica comercial, será relativamente difícil completar una aplicación de software exitosa. La cantidad de tiempo que debe dedicarse a la transferencia de conocimientos variará ampliamente según la complejidad del proyecto.

Suponiendo que se adopte un enfoque ágil y que una o más pymes estén disponibles durante la fase de desarrollo del proyecto, la transferencia de conocimientos continuará durante todas las etapas del proyecto.

¿Qué pasa si la transferencia completa del conocimiento no es factible?

Según la industria y el proyecto, es posible que una PYME no pueda ofrecer una transferencia de conocimientos completa.

Por ejemplo, imagina que la pyme es un médico con 25 años de experiencia y tienes 6 meses para completar un proyecto. O imagine a la PYME como un biólogo con 40 años de experiencia: tal nivel de conocimiento simplemente no se puede transferir en un marco de tiempo realista para proyectos de desarrollo de software.

Pero, ¿y si el área de conocimiento es dinámica?

Por lo general, el software se lanza según un cronograma establecido según el tiempo o las características. Sin embargo, las reglas comerciales dentro de algunas industrias cambian con mucha más frecuencia.

En muchos casos, puede que no sea factible lanzar software con la frecuencia necesaria para mantenerse al día con los cambios de la industria. Tener la capacidad de externalizar las reglas comerciales dentro de un motor de reglas comerciales puede tener sentido en tales escenarios. La capacidad de un proyecto de software para resistir el cambio contribuirá en gran medida a garantizar su éxito final a largo plazo.

¿Cuándo y dónde tienen sentido los motores de reglas?

Para muchos proyectos de software, es factible que se produzca una transferencia total del conocimiento y que la lógica empresarial se codifique en un lenguaje informático como C# o Java.

Sin embargo, hay un subconjunto de proyectos donde la cantidad de comprensión de un tema específico es tan grande, o las reglas comerciales están sujetas a tantos cambios que tiene más sentido que alguien que no sea programador tenga acceso directo a la lógica comercial. Este es el tema de este tutorial; Con eso en mente, analicemos los motores de reglas en profundidad.

¿Qué es un motor de reglas de negocio?

Un motor de reglas es una herramienta para ejecutar reglas de negocio. Las reglas de negocio se componen de hechos y declaraciones condicionales. Cualquier declaración "si-entonces" que aparece en la lógica comercial tradicional califica como una regla comercial.

Por ejemplo: si un empleado está ausente por enfermedad durante más de 5 días seguidos y no tiene una nota del médico, entonces es necesario que se anote. Si no se ha contactado a un socio comercial durante más de 6 meses y no ha realizado compras durante ese tiempo, entonces puede ser el momento de enviarle un correo electrónico cordial. Si un paciente tiene temperatura corporal alta, problemas de visión y antecedentes familiares de glaucoma, entonces podría ser el momento de solicitar una resonancia magnética adicional u otras pruebas.

¿Cómo redactan las PYME las reglas de negocio?

En lugar de esperar que una PYME aprenda Java, C# u otro lenguaje de programación, TI creará un minilenguaje para que exprese sus reglas comerciales. Los componentes básicos de estas reglas consistirán en hechos que se pueden consultar. Algunos ejemplos de hechos por industria/áreas de práctica son:

• Recursos Humanos: salario, cargo, gerente, años en la empresa
• Médico: temperatura, presión arterial, medicación actual
• Financiero: precio actual de las acciones, precio más alto/más bajo de 52 semanas, relación P/E, fecha de la próxima publicación de ganancias

Esencialmente, la información necesaria para tomar decisiones comerciales debe estar disponible para la PYME de manera ágil.

¿Cómo son estas reglas?

Para el resto de este tutorial del motor de reglas, usaré Drools, un motor de reglas basado en Java de código abierto, que se puede encontrar en www.drools.org y es un proyecto de JBoss. En Drools, las reglas se escriben como código Java y tienen la siguiente estructura:

Las declaraciones de importación van aquí:

 rule “Name of rule” when “The if” part of the business logic goes here. then The “then” part of the business logic goes here. end

Babeos y memoria de trabajo

Drools emplea un concepto llamado memoria de trabajo.

El código de la aplicación será responsable de cargar los hechos apropiados en la memoria de trabajo para que las PYME puedan escribir reglas que consulten estos hechos. Solo los hechos relevantes para la lógica comercial de la aplicación deben cargarse en la memoria de trabajo para mantener el motor de reglas funcionando a la máxima velocidad.

Por ejemplo, si una aplicación determina si se aprueba un préstamo para un cliente, los hechos relevantes incluirían el salario, las calificaciones crediticias y los préstamos pendientes. Los datos no relevantes incluirían el día de la semana o el género.

Evaluación de reglas

Después de que Drools Working Memory se ha cargado con reglas y hechos, las reglas se evalúan de acuerdo con la parte "entonces" de su regla. Si la parte "entonces" se evalúa como verdadera, se ejecutará la parte "cuándo" de la regla.

Por lo general, todas las reglas se evalúan a la vez, aunque las reglas se pueden agrupar y evaluar por grupo. La parte "entonces" de la regla puede cambiar el contenido de la memoria de trabajo. Cuando esto ocurra, Drools reevaluará todas las reglas para ver si alguna regla ahora se evalúa como verdadera. Si es así, se ejecutarán sus partes "cuando".

Esta naturaleza recursiva de las evaluaciones de reglas puede ser una bendición o una maldición, por lo que las reglas deben crearse con esta arquitectura en mente.

El lado "si" de una regla de babas

En Drools, los hechos están representados por objetos. Se puede consultar la existencia o inexistencia de un tipo de objeto. Además, los atributos del objeto también se pueden consultar.

Aquí están algunos ejemplos:

Determinar si un empleado gana más de 100.000.

 Employee(salary > 100000)

Determine si un paciente tiene un nivel de colesterol superior a 200 y está tomando Lipitor.

 Patient(cholesterol > 200, medications.contains(“lipitor”))

Determine si el precio de una acción está dentro del 1% de su máximo anual.

 Stock(price >= (yearHigh * .99))

Combinación de consultas

Al escribir una lógica empresarial compleja, las reglas empresariales pueden combinar consultas utilizando operadores booleanos AND, OR y NOT y anidando mediante paréntesis.

Por ejemplo:

Determine si hay un gerente que gana menos de $75 000 o un director que gana menos de $100 000.

 Employee(position.Equals(“Manager”),salary<75000) OR Employee(position.Equals(“Directory”),salary<100000)

Uso de varios tipos de objetos

Todos los ejemplos hasta ahora se han basado en un solo tipo de objeto, como Empleado o Paciente. Sin embargo, Drools permite que las consultas se basen en múltiples tipos de objetos.

Por ejemplo:

Determinar si el cliente tiene un salario superior a $50,000 y no se ha declarado en bancarrota.

 Customer(salary>50000) AND not exists Bankruptcy()

El lado "entonces" de una regla

El lado "entonces" de una regla determina lo que sucederá cuando haya al menos un resultado en la parte "cuándo" de la regla.

En Drools, cualquier cosa que se pueda escribir en Java se puede escribir en la parte "entonces" de la regla. Sin embargo, para que las reglas sean más reutilizables, generalmente es una buena idea no colocar ninguna E/S, código de control de flujo o código de ejecución general dentro de una regla.

Como alternativa, la parte "entonces" de una regla se puede utilizar para modificar la memoria de trabajo. Una práctica común es insertar un hecho en la memoria de trabajo cuando una regla se evalúa como verdadera.

Por ejemplo:

 rule “LoanApproved” when Customer(credit>700) && not exist LoanOutstanding() then insert(new LoanApproval()) end

¿Cómo sabemos cuándo una regla se ha evaluado como verdadera?

Después de que se hayan activado todas las reglas, la aplicación necesita saber qué reglas se evaluaron como verdaderas. Si las reglas insertan objetos en la memoria de trabajo cuando se evalúan como verdaderos, se puede escribir código para consultar esos objetos en la memoria de trabajo.

En el ejemplo anterior, después de activar todas las reglas, se puede realizar una consulta para ver si un objeto LoanApproval() está en la memoria de trabajo.

 query "GetLoanApproval " $result: LoanApproval() end

¿Cómo interactúa un motor de reglas comerciales con una aplicación?

Las aplicaciones típicas contienen lógica empresarial, GUI, E/S y flujo de código de control.

Por ejemplo, una aplicación puede procesar una solicitud de usuario como esta:

 GUI ? Flow Control ? I/O ? Business Logic ? I/O ? Flow Control ? GUI

La incorporación de un motor de reglas agrega algunos pasos a este proceso:

 GUI ? Flow Control ? I/O ? Create Rules Engine Session ? Add Facts to Working Memory ? Fire Rules ? Determine which rules have evaluated true ? I/O ? Flow Control ? GUI

¿Cómo trabajan las PYMES con las Reglas?

Creación, edición y eliminación de reglas

Para que las PYME puedan trabajar con reglas, necesitarán una GUI fácil de usar. Algunos motores de reglas comerciales vienen con una interfaz de este tipo.

Por ejemplo, Drools viene con dos GUI que encuentro fáciles de usar. El primero se asemeja a una hoja de cálculo y permite a las pymes crear reglas sin tener que escribir ningún código real. La segunda GUI permite crear una lógica empresarial más compleja.

Si bien estas dos GUI pueden ser útiles para ingresar condiciones simples, no funcionarán a medida que la lógica comercial se vuelva más compleja. En ese caso, tendrá que crear su propia GUI personalizada.

Elementos de la GUI personalizada de SME

Para que las PYMES funcionen de manera efectiva, considere crear una GUI personalizada con las siguientes capacidades:

• Verificador de sintaxis: un botón de "verificación de sintaxis" puede llamar al código de Drools para verificar posibles errores y sus números de línea.
• Arrastrar y soltar: en lugar de pedirle a una PYME que recuerde los objetos y atributos que tiene a su disposición, considere ofrecerles una lista de selección desde la que puedan arrastrar y soltar.
• Interfaz web: una interfaz de cliente ligero estará disponible para las PYME sin problemas de distribución. Esto será útil ya que la GUI necesita funciones adicionales y mantenimiento general.
• Probador de reglas: tener la capacidad de probar reglas individuales sin interactuar con toda la aplicación aumentará en gran medida la productividad de las PYME. Permita que la GUI de SME determine los hechos y luego active las reglas individuales.

¿Dónde deben almacenarse las reglas?

En Drools, normalmente hay dos formas de almacenar reglas. Drools funciona de manera inmediata con reglas basadas en archivos que generalmente tendrán una extensión .drl.

Esto funciona bien cuando el número de reglas es pequeño. A medida que crezca el número de reglas, querrá utilizar una base de datos. Almacenar y recuperar reglas de una base de datos requiere más trabajo, pero debería brindarle una arquitectura mucho más manejable.

Este tutorial del motor de reglas solo ha abordado una porción muy pequeña del lenguaje de reglas de Drools. Para obtener una descripción completa, consulte la documentación de referencia oficial.

La decisión de utilizar un motor de reglas no debe tomarse a la ligera. Si bien un motor de reglas hará que su aplicación sea más extensible para las pymes, también será más complicado de desarrollar, probar e implementar. Para consideraciones adicionales sobre este tema, es posible que desee revisar las siguientes pautas.

Ahora podemos proceder a mostrarle algo un poco más interesante: un ejemplo simple de la vida real de Drools en acción, en un caso de uso que la mayoría de los lectores del blog de Toptal deberían encontrar familiar.

Usando Drools en un escenario de la vida real

Toptal, un proveedor líder de talento de desarrollo de software de alto nivel, actualmente utiliza el software de seguimiento de candidatos para guiar a los candidatos a puestos de trabajo a través de varias etapas del proceso de contratación. Aquí hay un diagrama de flujo visual simplificado de este proceso:

Actualmente, la lógica comercial para decidir si un solicitante continuará en el proceso de contratación está codificada en el software. Cada vez que Recursos Humanos necesita cambiar la lógica del negocio, deben involucrar a TI. Les gustaría tener la capacidad de cambiar directamente la forma en que se ejecuta su software.

El software de seguimiento de candidatos se modificará para ejecutar las reglas proporcionadas por RRHH en cada punto de decisión del proceso de contratación. HR tendrá un objeto 'Candidato' que representará a un solicitante de empleo cuyo estado acaba de ser modificado por una entrada inicial, la finalización de un examen en línea o una serie de factores diferentes. El objeto Candidato tendrá campos para representar experiencia, puntajes de exámenes, puntajes de entrevistas, etc.

El siguiente ejemplo presenta un conjunto simplificado de reglas para su consideración. No se ha implementado, es solo un ejemplo simple que consta de cuatro reglas interconectadas:

• Enviado -> Prueba
• Pruebas -> Entrevista
• Entrevista -> Proyecto
• Proyecto -> Contratación

Enviado -> Prueba

En función de las necesidades actuales de los clientes, RR. HH. quisiera redactar una regla que determine si se debe programar a un candidato para la prueba en línea.

 Rule “Schedule For Testing” when $candidate: Candidate(status=='Submitted',yrsExperience >= 10, skill(name=='Java', yrsExperience>=5) or Skill(name=='C#', yrsExperience>=5)) then $candidate.setStatus('Testing'); end

Pruebas -> Entrevista

Después de que el candidato haya realizado el examen en línea, se debe evaluar su puntaje. A HR también le gustaría tener control sobre esta regla. El examen en línea evalúa la capacidad del candidato para comprender la teoría del desarrollo de software, la resolución de problemas y la sintaxis. Recursos humanos desea decidir qué combinación de puntajes permitirá que un candidato sea considerado para una entrevista técnica.

 Rule “Schedule For Interview” when $candidate: Candidate(status=='Testing', testScore(theory>.8 && syntax>.6 && problemSolving>.8); then $candidate.setStatus('Interview'); end

Entrevista -> Proyecto

Una entrevista técnica pondrá a prueba la capacidad de un candidato para hablar sobre su experiencia, responder preguntas de resolución de problemas y pondrá a prueba su capacidad de comunicación en general. Recursos Humanos redactará la regla que determina la calificación para aprobar la entrevista técnica.

 Rule “Schedule For Project” when $candidate: Candidate(status=='Interview', interviewScore(speakExperience>.9 && problemSolving>.8 && communication>.9 ); then $candidate.setStatus('Project'); end

Proyecto -> Contratación

Si un candidato pasó la entrevista técnica, se le dará un proyecto de programación fuera de línea. Enviarán el proyecto y se evaluará por su integridad, arquitectura y GUI.

 Rule “Schedule For Hiring” when $candidate: Candidate(status=='Project', projectScore(completeness>.8 && architecture>.9 && gui>.7 ); then $candidate.setStatus('Hiring'); end

Como puede ver, incluso este ejemplo básico ofrece una serie de posibilidades para recursos humanos y puede optimizar las operaciones. El hecho de que Recursos Humanos pudiera modificar las reglas sin tener que involucrar a TI en el proceso inevitablemente ahorraría tiempo y aceleraría el proceso de selección.

Dado que las reglas se pueden cambiar sobre la marcha, el departamento de recursos humanos también tendría mucha más flexibilidad. Por ejemplo, RRHH podría expandir o restringir el proceso de selección estableciendo diferentes parámetros.

Si hay demasiados candidatos que marcan todas las casillas correctas, el listón podría subir en cuestión de minutos, reduciendo así el número de candidatos. Alternativamente, si el proceso produce pocos o ningún candidato que cumpla con todos los requisitos, Recursos Humanos puede optar por reducir o eliminar algunos de los estándares, cambiando su enfoque a habilidades más relevantes hasta que un número adecuado de candidatos cumpla con el requisito.