investigaciÓn para la adopciÓn y uso de los...

INVESTIGACIÓN PARA LA ADOPCIÓN Y USO DE LOS MOTORES DE REGLAS DE NEGOCIO

CARLOS ALBERTO MEJÍA CASTELO 1080457

UNIVERSIDAD SAN BUENAVENTURA FACULTAD DE INGENIERIA DE SISTEMAS

AREA DE SISTEMAS E INFORMÁTICA SANTIAGO DE CALI

2011

INVESTIGACIÓN PARA LA ADOPCIÓN Y USO DE LOS MOTORES DE REGLAS DE NEGOCIO

CARLOS ALBERTO MEJÍA CASTELO 1080457

Monografía para optar al título de Ingeniera de Sistemas

Director DANNY ANDRÉS SALCEDO

Especialista en procesos para desarrollo de software.

UNIVERSIDAD SAN BUENAVENTURA FACULTAD DE INGENIERIA DE SISTEMAS

AREA DE SISTEMAS E INFORMÁTICA SANTIAGO DE CALI

2011

NOTA DE ACEPTACIÓN

------------------------------------------------------------- ------------------------------------------------------------- -------------------------------------------------------------

-------------------------------------------------- Presidente del Jurado

--------------------------------------------------

Jurado

--------------------------------------------------

Jurado Santiago de Cali, Junio 13 de 2011

A mi novia, por su interminable apoyo, ayuda y paciencia en este proceso. A mis padres y mi hermano por su apoyo incondicional. A mis profesores por sus enseñanzas y acompañamiento durante este proceso de aprendizaje. A Dios por darme la oportunidad de vivir esta experiencia y culminarla de la mejor manera. A todos mil gracias.

Carlos Alberto Mejía Castelo

AGRADECIMIENTOS Quiero dar gracias a la universidad de San Buenaventura por la formación que me brindó durante estos años de estudio, al ingeniero Luis Merchán por su acompañamiento en este proyecto a mi director de proyecto Danny Andrés Salcedo al apoyarnos durante la realización del mismo. También quiero agradecer a los profesores Diego Gómez, Johan Bejarano y Christian Arias por su apoyo y los conocimientos brindados en mi vida estudiantil, a mis padres por su apoyo incondicional, a mi amigos y compañeros que hicieron de mi aprendizaje un camino más amigable, camino en el cual no solo aprendí en la academia, aprendí de ellos, de la vida, y forjé un plan que me transformará en la persona que deseo ser.

CONTENIDO Pág.

1. HISTORIA DEL ENFOQUE EN REGLAS DE NEGOCIO ........................................ 7

2. PLANTEAMIENTO DEL PROBLEMA ......................................................................... 9

3. OBJETIVO GENERAL ................................................................................................. 10

3.1. OBJETIVOS ESPECIFICOS ................................................................................ 10

4. DESARROLLO DEL PROYECTO ............................................................................. 11

4.1. REGLAS DE NEGOCIO ....................................................................................... 11

4.2. RULES Y BPM ...................................................................................................... 17

4.3. MOTOR DE REGLAS DE NEGOCIO [6] .......................................................... 23

4.4. ANÁLISIS DE MOTORES DE REGLAS DE NEGOCIO ............................... 37

4.5. TABLA COMPARATIVA DE MOTORES DE REGLAS DE NEGOCIO ...... 48

5. DESCRIPCIÓN DE LA HERRAMIENTA SELECCIONADA ............................... 51

5.1 ESCRITURA DE REGLAS DE NEGOCIO. .................................................... 55

5.2. TRADUCCIÓN DE REGLAS DE NEGOCIO A REGLAS TÉCNICAS. ...... 58

5.3. EL FORMATO DE TRADUCCIÓN. .................................................................. 59

6. CREACIÓN DE ARCHIVOS DSL CON JBOSS RULES. ..................................... 61

7. CONCLUSIONES ......................................................................................................... 63

8. ANEXOS ......................................................................................................................... 64

9. BIBLIOGRAFÍA ............................................................................................................. 70

1 |

GLOSARIO

Regla de negocio: Una Regla de Negocio es una declaración que define o limita algún aspecto del negocio. Sistema de información: Conjunto de componentes que interactúan entre sí, para lograr un objetivo común: Satisfacer las necesidades de información de una organización Stakeholders: Son grupos con poder real o potencial para influir en las decisiones gerenciales Motor de reglas de negocio: El motor de reglas de negocio es un componente de software que, a partir de una información inicial y un conjunto de reglas, decide que reglas deben aplicarse a una determinada colección de información, ejecuta las reglas requeridas, y aplica y evalúa los cambios que esta ejecución tiene sobre la información suministrada. Regla de negocio: Exposición o declaración, que define o regula, algún aspecto del negocio. Busca controlar o incluir el comportamiento de los negocios. JBoss Rules: Es un sistema de producción de reglas que provee un motor de reglas de negocio open source que implementa una versión mejorada del algoritmo RETE Drools: Nombre original del proyecto que se conoce como Jboss Rules. Variable: es un espacio de memoria reservado para almacenar un valor que corresponde a un tipo de dato soportado por el lenguaje de programación. Una variable es representada y usada a través de una etiqueta (un nombre) que le asigna un programador o que ya viene predefinida. Objeto: Es una representación detallada y particular de algo de la realidad. Todo objeto tiene un identidad o nombre, estado (características definidas generalmente en variables) y comportamiento (sus funciones o procedimientos). Capa de lógica de negocio: Es un término informal para referirse a la capa intermedia que maneja el intercambio de información entre la Vista y el Modelo; es el controlador. Capa de presentación: Esta capa es la que presenta el sistema al usuario, puesto que esta permite la comunicación de la información y también la captura de la información suministrada por el usuario en un mínimo de proceso.

2 |

Capa de acceso a datos: Esta capa es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio. Desarrollador de Software: Es un rol que se dedica a una o más facetas del proceso de desarrollo de software. Este se encarga de implementar algoritmos mediante un lenguaje de programación. Compilador: Los compiladores son programas o herramientas que transforman código fuente de alto nivel (escrito de forma comprensible para el ser humano), a código de bajo nivel (código a nivel de maquina) que puede ser ejecutado por la CPU. Repositorio: Tecnología de información que permite mantener, organizar y acceder a una colección de recursos, generalmente almacenados en un sistema de computadores. Dependiendo de cómo se use el termino, un repositorio puede ser directamente accesible a usuarios, o puede ser un lugar del que diferentes bases de datos, archivos o documentos son obtenidos para distribución o relocalización en una red. Subversion: Es un sistema de control de versiones, que lleva registro de los cambios realizados a archivos y directorios, facilitando la recuperación de datos; proporciona además un registro histórico de los cambios que se han realizado a través del tiempo.. Versionamiento: Es la gestión de los diversos cambios que se realizan sobre los elementos de un producto o configuración del mismo. Estos facilitan la administración de las distintas versiones de cada desarrollo realizado. Algoritmo: Son implementados en forma de sentencias en algún lenguaje de programación. De esta manera, la forma de escribir los algoritmos depende del lenguaje de programación, y del paradigma usado. Estos son los algoritmos que pueden ser interpretados por una computadora y así ser ejecutados. Cuello de botella: Embotellamiento de paquetes de datos (información) que circulan por una conexión causando demoras en la comunicación. Recursividad: En el cuerpo de sentencias del subalgoritmo se invoca al propio subalgoritmo para resolver “una versión más pequeña” del problema original.

3 |

Algoritmo Rete: Es un algoritmo de reconocimiento de patrones eficiente para implementar un sistema de producción de reglas. Fue creado por el Dr. Charles L. Forgy en la Carnegie Mellon University.

4 |

Siglas BRMS: Business rule management system IDE: Integrated Development Environment BPM: Business Process Management BPMS: Business Process Management System

5 |

RESUMEN

Esta investigación y prueba de concepto tiene como objetivo presentar una revisión del estado del arte de las tecnologías relacionadas con los Motores de reglas, entrar a revisar los distintos conceptos que rodean estas tecnologías, porque son necesarios y más importante, como usarlos y aplicarlos a los sistemas empresariales del mañana. Las condiciones de participación de las empresas, en las diferentes actividades que ejercen, están en constante cambio, las normas y las funciones cambian a lo largo del ciclo de vida de un sistema de información empresarial, a veces estos cambios ocurren varias veces en un día, es por esto, que el negocio debe adaptarse a estos cambios en tiempo real, y por supuesto debe adaptarse también su software, este proceso de adaptabilidad, se ve severamente optimizado al implementar la tecnología de los motores de reglas de negocio. En la actualidad existen varios motores de reglas, que brindan un servicio a las necesidades del negocio, estos deben ser capaces de adaptar la lógica de las aplicaciones del negocio a los constantes cambios para permitir flexibilidad a las organizaciones y así tener un mayor aprovechamiento de las oportunidades. Palabras clave: Motores de Reglas, negocio, lógica, flexibilidad, adaptación.

6 |

SUMMARY

The objective of this investigation and proof of concept, is presenting a revision of the state of the art of the technologies related to the business rules engines, to revise the different concepts surrounding these technologies, why are they needed, and most importantly, how to use them and apply them to the business systems of tomorrow. The conditions of the different activities in which the enterprises participate, are constantly changing, norms and functions change through the whole life cycle of an enterprise information system, sometimes these changes occur several times in a single day, and because of this, the business must adapt to these changes in real time, and of course, their software must be able to adapt in the same rate, this process of adaptability is severely optimized when the technology of business rules engine is implemented. Today, various business rules engines exist, which provide a service to the business needs, they are capable of adapting the business application‟s' logic to the constant changes, allowing more flexibility to the organizations and a better use of the different opportunities. Keywords: Business rule engines, business, logic, flexibility, adaptability.

7 |

1. HISTORIA DEL ENFOQUE EN REGLAS DE NEGOCIO

En enfoque de reglas de negocio evoluciono principalmente de 3 fuentes, inteligencia artificial (Sistemas expertos), modelamiento de datos, y reingeniería de procesos de negocio. Los sistemas expertos fueron una de las tecnologías que dio origen a las reglas de negocio, un sistema experto es software que intenta encontrar la respuesta a una pregunta o resolver un problema en la cual se necesitaría a uno o más expertos, estas soluciones se conocen como objetivos. Los sistemas expertos son sub campos de la inteligencia artificial. A través de los años 80, varias compañías fueron formadas para desarrollar sistemas expertos, sin embargo, a medida que el mercado empezó a saturarse, empezaron a explorar problemas de reglas de negocio. Muchos sistemas de gestión de reglas de negocio comenzaron como sistemas expertos; un sistema experto aplica una base de conocimiento a hechos que provienen de diversas fuentes para lograr un objetivo. Los sistemas expertos usan un concepto conocido como “inferencia” para derivar soluciones a un problema, la definición clásica de inferencia de la inteligencia artificial es “De unos hechos, otros pueden ser inferidos”. La minería de datos es otra tecnología que aunque de forma más indirecta, impulsa el origen de las reglas de negocio. Este campo de la inteligencia artificial, es un método para extraer patrones de los datos, en los años 90 una división de Innovations Software Technology, empezó a explorar representaciones graficas de los resultados del análisis de la minería de datos, los científicos encontraron que la lógica compleja, podía ser estructurada gráficamente en una forma que los analistas del negocio podrían entender con facilidad. Basados en esta experiencia, se entendió que una aproximación grafica simplifica las aplicaciones de reglas de negocio más prácticas, cuando los analistas del negocio o los no programadores necesitan entender y administrar una solución. A medida que las bases de datos basadas en SQL se volvieron prominentes a finales de los años 80 y principios de los años 90, creció el interés en las reglas de negocio por parte de la comunidad de modelamiento de datos, este interés vino de las prácticas en el modelamiento y diseño de requerimientos. Muchas

8 |

bases de datos corporativas incluyeron tablas de datos, que servirían de forma cruda como tablas de decisión. Identificada esta necesidad por las reglas de negocio, se fundó el Business Rules Group (Grupo de reglas de negocio), miembros de este grupo incluían a miembros prominentes de la comunidad de modelamiento de datos, en enfoque inicial del grupo, estaba en las reglas de negocio que podían ser implementadas directamente en la tecnología de información, estas incluían reglas que serían definidas formalmente en especificaciones y en el código de los sistemas de información. Más tarde el grupo se enfocó en el aspecto de las reglas de negocio en lugar de las reglas implementadas, esto llevo al nacimiento de los estándares SVBR y BMM de OMG. Los practicantes del business rules group, usaron su experiencia en el modelamiento de datos, para crear los primeros enfoques a las reglas de negocio, el modelamiento de datos involucraba modelamiento lógico que después se transformaría en un modelo físico, una aproximación idéntica fue aplicada a las reglas de negocio, miembros de este grupo escribieron libros en los que presentaban una ontología para las reglas de negocio, así como una visión del rol de estas en la empresa. En el 2006, el libro “Business Process Management: The Third Wave”[2] fue publicado, este libro marco un punto importante en el reconocimiento de las reglas de negocio, y más aún, en la importancia que estas tiene en los sistemas BPM, el libro contiene la siguiente cita “Muchas corporaciones administran sus reglas de negocio en un sistema de administración de reglas de negocio separado”, esta fase comenzó el concepto de que BPM en conjunción con las reglas de negocio, ofrecía una aproximación ágil a la integración del flujo de trabajo y los procesos. En el 2007, Tom Debevoise escribió el libro “Business Process Management with a Business Rules Approach”[3], el cual presentaba métodos para la administración de procesos de negocio, reglas de negocio e inteligencia de negocio. Hoy en día se considera que BPM, reglas de negocio e inteligencia de negocio, están en un camino convergente, no solo eso, sino que además, la combinación de estos tiene un impacto superior en el negocio que cuando se utilizan por separado.

9 |

2. PLANTEAMIENTO DEL PROBLEMA

El vertiginoso crecimiento de los negocios y el acelerado mundo en que vivimos nos hace sentir la necesidad de ser cada vez más competitivos, flexibles y oportunos cuando se trata de dar ventajas a los negocios, es por eso que el mundo de los negocios hoy exige tecnología que sea capaz de adaptarse a los constantes cambios y permitir ser los primeros en capitalizar las oportunidades, es allí donde la flexibilidad de los sistemas juega un papel fundamental y más aún la oportunidad de poder administrar las reglas de negocio sin solidificarlas en código. Es allí donde este trabajo pretende entregar una guía para el entendimiento y apropiación de las tecnologías de Motores de Reglas, las cuales permiten la externalización de las reglas de negocio dándole flexibilidad a las empresas, compañías, etc. Brindando una herramienta poderosa para tener mayor aprovechamiento de los sistemas de información garantizando su adaptabilidad a los entornos constantemente cambiantes y generando valor para ser cada vez más competitivos.

10 |

3. OBJETIVO GENERAL Conceptualizar el uso de los motores de reglas de negocio, a través de la

investigación de tecnologías y técnicas de desarrollo, lograr entender el camino

de sistematizar y centralizar la lógica de negocio de las aplicaciones

empresariales, por medio de reglas de negocio actualizables en tiempo real y

escritas en lenguaje natural.

3.1. OBJETIVOS ESPECIFICOS Conceptualizar acerca de los motores de reglas. Dar a conocer la arquitectura de referencia de un motor de reglas.

Conocer los fundamentos de los algoritmos utilizados.

Realizar pruebas de concepto de una herramienta para realizar la gestión de

reglas.

11 |

4. DESARROLLO DEL PROYECTO

4.1. REGLAS DE NEGOCIO

Desde el punto de vista del negocio, las reglas de negocio involucran el comportamiento de la gente en el sistema del negocio, una regla de negocio es un indicador que existe una obligación concerniendo a la conducta, acción, práctica o procedimiento dentro de una actividad particular o escenario.

Visto de una forma más sencilla, una regla de negocio es cualquier conocimiento que puede ser expresado en el siguiente formato:

Cuando “algo” es verdad, Entonces haga “esto”.

Todas las compañías y organizaciones tienen reglas de negocio, estas están detalladas en reglamentos, procedimientos, en la mente del experto del negocio e incluso en código de aplicaciones existentes.

El termino reglas de negocio se utiliza para denotar que no son técnicas, también podrían ser llamadas “reglas medicas”, “reglas financieras”, “reglas de seguros”, etc. Esto depende de la organización en la que se crearán y utilizaran las reglas. [4]

Desde el punto de vista de los sistemas de información, una regla de negocio pertenece a los hechos del sistema (que son guardados como datos) y a las restricciones en los cambios de los valores de estos.

Las reglas de negocio deberían ser escritas de la forma más clara posible, en cualquier lenguaje humano que sea elegido, esto no solo simplifica el proceso de la escritura de reglas, también facilita que personas que no escribieron las reglas, puedan analizarlas y evaluarlas.

Ya que las reglas de negocio son una expresión de conocimiento, deben ser escritas por quien tiene ese conocimiento, ya sea el gerente, el administrador, o el director de cartera, de esta forma se reducen a gran medida la posibilidad de errores y fallos en la definición de reglas. [4]

12 |

4.1.1. ¿Cuál es la motivación para las reglas de negocio?

En Las compañías se encuentran todo tipo de reglas de negocio. Que satisfacen requerimientos a los cuales se les debe dar cumplimiento y son emitidas por Instituciones reguladoras, unidades de negocio, compradores, competidores y en general las condiciones de mercado, todos generan reglas de negocio en cambio constante.

El traducir el conocimiento en reglas de negocio, significa el no depender de la presencia del experto para poder realizar las operaciones de la organización, también significa que los procesos dispendiosos de estas operaciones pueden automatizarse y así el experto dispondrá de más tiempo para realizar actividades diferentes como estudiar mejoras al proceso.

Las reglas de negocio influencian y guían el comportamiento de la gente (perspectiva de negocio) e influencia la información que se almacena en un sistema de información, así como restringe la modificación de esta información (perspectiva de sistemas de información). [26]

La motivación del negocio de mejorar la administración de las reglas de negocio es la de incrementar el control y el conocimiento en la organización, acerca del cómo, porque, cuando, donde y por quien, las reglas son forzadas.

El tener mayor conocimiento, entendimiento y control sobre las reglas de negocio puede responder preguntas de los stakeholders como por ejemplo el cumplimiento de la organización con regulaciones, el riesgo que la compañía enfrenta cuando los empleados dejan la compañía, la habilidad de rápidamente cambiar las políticas de negocio o implementar nuevas regulaciones, entre otras.

4.1.2. Clasificaciones de reglas de negocio

Desde el punto de vista del negocio, una regla de negocio puede provenir de distintos tipos de expresiones y acciones como son una restricción, una pauta, un cálculo, una inferencia o una acción, esto nos lleva a la siguiente clasificación. Ver la Tabla 1.

13 |

Tipo de frase Ejemplo

Restricción Todo pedido debe contener al menos un producto.

Pauta Las órdenes de envío deberían generarse inmediatamente después de recibir el pago de los pedidos

Cálculo La facturación anual de un cliente se calcula como la suma de todas las facturas emitidas a ese cliente antes del 31 de marzo del año en cuestión.

Inferencia Los clientes con una facturación en el último año superior a 5.000.000 serán considerados como clientes preferentes.

Acción Los clientes recibirán una notificación en el mismo momento en que su pedido haya comenzado a procesarse.

Tabla1: Clasificación de las reglas de negocio.

Desde el punto de vista de los analistas de negocio es posible distinguir entre:

Reglas operativas. Son aquellas que pueden ser violadas por algún agente del negocio

Reglas estructurales. Son reglas que permiten definir cómo se organiza o estructura el negocio y que nunca pueden ser violadas de forma directa.

14 |

Tipo de frase

Ilustración 1: Clasificación de reglas de negocio según Gerd Wagner (OMG,2007)[5]

15 |

4.1.3. ¿Qué es la verificación de reglas?

La verificación es el proceso que apunta por la detección de inconsistencia, incompletitud o redundancia en un conjunto de reglas de negocio sin considerar el significado de las reglas, esto significa que no le importa acerca de si la regla es correcta o no.

Aun si se puede probar que las reglas son lógicamente consistentes y completas, las reglas podrían llevar a resultados incorrectos pero lo harán en una manera consistente.

La validación de reglas es un paso en el proceso de establecer reglas de alta calidad, como puede una organización estar segura de que sus reglas son consistentes, completas y precisas cuando las reglas son sujetas al cambio, se aplican en un ambiente cambiante y tienen diferentes fuentes? [26]

4.1.4. ¿Qué es validación de reglas?

Validación es el proceso que apunta por la detección de resultados incorrectos o comportamiento indeseado.

La forma más simple de validar reglas es simplemente pasar las reglas cambiadas a otro miembro de la organización. En un contexto de tecnologías de información, la validación frecuentemente se hace probando la aplicación y verificando los resultados, o comparando los resultados con previos resultados que se creen están correctos. [26]

Las reglas validadas o casos de negocio son aprobados por miembros de la organización responsable por las reglas.

Inconsistencia: Es una condición en un conjunto de reglas de negocio que ocurre cuando 2 o más reglas llevan a comportamientos o resultados conflictivos.

Incompletitud: Es una condición en un conjunto de reglas que ocurre cuando existe un caso de negocio que lleva a un resultado o comportamiento indefinido.

Redundancia: Es una condición en un conjunto de reglas de negocio que ocurre cuando existe una regla de negocio que no tiene contribución significativa al posible comportamiento o posibles resultados.

Anomalía: Es un término más general para inconsistencia, Incompletitud o redundancia.

16 |

Un conjunto de reglas tiene una alta calidad cuando:

o Cada caso distinto de negocio lleva a solo un comportamiento o resultado posible.

o Cada posible caso de negocio lleva a algún resultado o comportamiento.

o Cada regla, aplicada en cualquier caso de negocio, tiene una contribución significativa o comportamiento.

Reglas de negocio informales: Son declaraciones en lenguaje natural.

Reglas de negocio formales: Son declaraciones en lenguaje matemático o lógico.

17 |

4.2. RULES Y BPM La creciente importancia de las reglas de negocio en la gestión de la empresa, se ha puesto de manifiesto con la difusión de los nuevos sistemas BPM, sistemas que aunque por si mismos presentan un nuevo paradigma de enfoque hacia las operaciones del negocio, son notablemente mejorados si las reglas del negocio no se encuentran embebidas dentro de los procedimientos operativos, sino que se presentan como un componente independiente, pero con un íntimo contacto con los procesos. Antes de hablar de la relación de los BPMS y los BRMS, se proveerá con una breve definición de lo que es un BPM. BPM o Business Process Management, es una forma de estudiar, identificar, cambiar y monitorear los procesos de negocio, comprende las técnicas, métodos estructurados, y medios, para modelar las operaciones tanto automáticas como no automáticas de la organización, y de esta forma incrementar la eficiencia de la misma. BPM involucra de forma intencional y colaborativa, una definición soportada en tecnología, tecnología que permite el monitorear de extremo a extremo el trabajo que la organización realiza para crear valor para sus clientes y para permitir a la organización cumplir con sus objetivos de negocio de una forma más ágil. [6] Un término clave de la definición anterior, es tecnología, se han creado sistemas que permiten a las organizaciones administrar sus procesos de negocio, estas tecnologías involucran generalmente herramientas para diseñar y modelar de forma visual los procesos de negocio; simular y probar procesos de negocio, automatizar, controlar y medir los procesos de negocio, así como también proveer retroalimentación y generar reportes en el desempeño de los procesos. Estas funciones han sido combinadas en suites de administración de procesos de negocio, que proveen una plataforma integrada completa de BPM, conocida como BPMS. Muchas organizaciones tienen un gran número de sistemas legados, típicamente diseñados para soportar funciones específicas del negocio, ya que un objetivo de BPM el controlar los procesos de extremo a extremo, los BPMS deben proveer medios de integración con los sistemas legados a través de la organización, para no solo controlar el trabajo, sino también para obtener información y medir el desempeño, en este nivel se emplean diferentes tecnologías como los servicios web, entre otros.

18 |

4.2.1. Relación entre reglas de negocio y BPM Parte de cualquier proceso de automatización y administración del negocio, es tener un método para definir e implementar los puntos de decisión importantes dentro de cualquier proceso, adicionalmente a definir estos puntos de decisión, el analista del negocio o el desarrollador, debe crear un flujo de negocio de alto nivel y definir como las transacciones y el trabajo, progresan de una etapa a la siguiente; la definición de los puntos de decisión se realiza mediante la construcción de reglas de negocio, la definición del flujo de trabajo en un proceso se realiza mediante un sistema BPM Al tener las reglas de negocio en un bloque independiente de los procedimientos operativos, se pueden mantener procesos prácticamente sin cambios, esto se debe a que la mayor parte de los cambios se derivan de las variaciones del entorno empresarial, que es justamente lo que debe quedar definido en las reglas de negocio. Con este enfoque, los cambios se introducen en las reglas de negocio, y los procesos, sin ser modificados en su estructura, quedan automáticamente adaptados a las nuevas situaciones. Cuando se construye un modelo de un proceso en un sistema BPM, este conservará su estructura ya sea de forma permanente o por un periodo de tiempo prolongado, esto es porque los procedimientos que lleva implícitos pueden ser complejos y su concepción está hecha para que sirva de estructura de funcionamiento lo más permanente en inalterable posible. Sin embargo, existen aspectos del funcionamiento de una empresa, que por su naturaleza son variables, es decir, requieren modificaciones frecuentes para adaptarse a las necesidades siempre cambiantes, creadas por el entorno económico. Es en este punto es donde surge la importancia y el poder de las reglas de negocio, dentro del modelo de un proceso, o una clase de proceso, se deben identificar dos partes, una considerada permanente, y otra cambiante, todo aquello que se considera estructural y que engloba los flujos de corriente que determina el workflow, se modela en el diagrama de procesos, mientras que todo lo que se conceptualiza como norma de funcionamiento que puede cambiar con frecuencia, se construye en las reglas de negocio. Cuando se ejecuta un determinado proceso, el motor de procesos lo ejecutará siguiendo los flujos descritos en el diagrama, e irá a consultar las reglas de negocio que estén relacionadas con dichos flujos en los momentos en los que el funcionamiento del proceso esté regulado por dichas reglas de negocio. [6]

19 |

4.2.2. Reglas de negocio e Inteligencia de Negocios [6]

Los sistemas de reglas de negocio e inteligencia de negocio a menudo se utilizan a distintos niveles dentro de la organización. Por un lado, las reglas de negocio asociadas a los procesos de la organización y por otro lado la inteligencia de negocios orientada a la comprensión de los datos transaccionales. Sin embargo, actualmente se ha dado una combinación de ambas logrando beneficios que no se tenían considerados hasta el momento. Al trabajar unidas ambas tecnologías se pueden agregar nuevas capacidades a la inteligencia de negocios tradicional. Así, utilizando inteligencia de negocios basada en un BRMS, podrían modificarse las políticas para cambiar la asociación de determinadas reglas y contarse con mejores elementos para analizar el negocio. Un BRMS aporta una capacidad muy importante que no posee tradicionalmente la inteligencia de negocios. Cuando el motor de reglas toma una decisión, éste conoce claramente en qué se basó para tomarla, lo que añade importante información al historial de las decisiones tomadas en la empresa, información que favorece el análisis de futuras decisiones. Esta integración permite a las empresas ver cómo son en realidad tomadas las decisiones y no cómo ellos creen que son tomadas.

4.2.3. BUSINESS RULES MANAGEMENT SYSTEM (BRMS)

Un Sistema de Gestión de Reglas de Negocio (BRMS) es aquel que permite definir, mantener, reutilizar, depurar y evaluar reglas de negocio. Por evaluar se entiende determinar qué reglas son aplicables en cada caso, ejecutando las acciones adecuadas.

Un BRMS se compone de tres elementos básicos: un motor de reglas, encargado de ejecutar las reglas de negocio, un sistema de gestión de la configuración, encargado de almacenar las reglas de negocio utilizadas y una interfaz de acceso para los usuarios que permita la gestión y edición de las reglas de negocio.

Existen distintos tipos de reglas de negocio, quedando bajo el control de los BRMS únicamente aquellas que se representan a través de una expresión de tipo 'si – entonces', ejecutables en un motor de reglas. Así, los disparadores o las restricciones de una base de datos son también reglas de negocio, pero no quedan bajo el control de los BRMS existentes en la actualidad.

20 |

Los principales componentes y funcionalidades que comparten la mayoría los BRMS son los siguientes:

1. Un repositorio para la gestión de la configuración: Este repositorio permitirá almacenar distintas versiones de las reglas de negocio, llevando un control de los cambios que se han producido en el contenido de la regla y los usuarios que los han efectuado.

2. Un motor de reglas: Capaz de ejecutar y gestionar las reglas de negocio de forma eficiente y adecuada, el motor almacena una serie de hechos que codifican el conocimiento que tiene de un problema.

Sobre estos hechos aplica un conjunto de reglas expresadas como sentencias de control condicionales, a veces denominadas „si entonces‟, que permiten inferir nuevos hechos.

3. Integración con las aplicaciones de desarrollo de la organización: Es necesario integrar el proceso de identificación y desarrollo de reglas de negocio en el proceso de desarrollo software contemplado en la organización. Muchos de los BRMS disponibles actualmente proporcionan entornos de desarrollo basados en modelos y que contemplan distintos roles para los usuarios.

Estos entornos pretenden reducir la cantidad de código a generar por los desarrolladores a la hora de introducir las reglas de negocio en los sistemas de información de la organización.

4. Simulación de las reglas: La validación o prueba del comportamiento de una regla de negocio es un paso esencial en el ciclo de desarrollo de la misma, al igual que para cualquier otro componente software.

5. Monitorización y análisis: Las herramientas de monitorización y análisis proporcionan estadísticas de ejecución e informes de utilización de las reglas de negocio. Este componente permite saber qué reglas se ejecutaron durante una transacción determinada, en qué momento y quién las ejecutó, cuál fue el resultado de la ejecución, con qué otros sistemas se interactuó y, en general, toda aquella información útil para el seguimiento del comportamiento de las reglas de negocio.

21 |

6. Gestión y administración: Muchos de los BRMS disponibles en la actualidad incorporan herramientas que permiten desplegar las reglas de negocio en los sistemas de información de la organización, gestionar la seguridad en el acceso a las mismas, sus versiones y efectuar un seguimiento del rendimiento y el estado del BRMS durante su funcionamiento.

7. Reutilización de reglas: La posibilidad de reutilizar las reglas de negocio es una facilidad básica que deberían ofrecer todos los BRMS actuales.

4.2.3. Características de un BRMS

Existe una gran variedad de productos, tanto comerciales como de código abierto, que implementan motores de reglas, todos estos motores comparten un conjunto de características. Ver Ilustración 2

Ilustración 2: Fases en el proceso de operación de un motor de reglas

Implementan un algoritmo de ejecución de reglas eficiente. La mayoría de los motores de reglas actuales incluyen una implementación del algoritmo RETE, el más eficiente conocido actualmente para la verificación de antecedentes y consecuentes de las reglas de negocio.

Incorporan gestión de la configuración. Un factor importante a tener en cuenta a la hora de trabajar con reglas de negocio es la necesidad de disponer de información de versiones existentes de una misma regla, además de conocer los usuarios que modificaron las distintas versiones y que elaboraron aquellas que, en un instante determinado, se encuentran en un entorno de producción.

22 |

Distinguen roles de usuarios. La principal ventaja de los BRMS radica en la posibilidad de modificar la lógica de negocio sin necesidad de recompilar y reconstruir el código de la aplicación que da soporte a dicha lógica de negocio. Esto conduce a la posibilidad de que los analistas de negocio o expertos en el dominio puedan, sin conocimientos técnicos profundos, modificar el comportamiento de una aplicación por sí mismos.

Incluyen herramientas de despliegue. Aparte de permitir la creación y definición de las reglas negocio, es deseable disponer de facilidades para el despliegue de las reglas de negocio. Este componente de despliegue estaría encargado de situar los artefactos que conforman una regla de negocio en el entorno de ejecución adecuado. También estaría al tanto de las dependencias existentes entre el motor de reglas y el resto de componentes de software disponibles en la organización, asegurando que se encuentra en ejecución la versión adecuada para la regla y manteniendo registro del proceso de ejecución.

Incluyen herramientas de validación. Como parte del entorno de edición de las reglas de negocio, la mayoría de los sistemas incluyen la posibilidad de depurar y validar la ejecución de las reglas de negocio creadas. Estas facilidades de depuración suelen integrarse en los entornos de edición para los desarrolladores de las reglas de negocio.

Integración con el proceso de desarrollo. La mayoría de los BRMS suelen incorporar una interfaz basada en un navegador para los expertos de negocio y otra interfaz propia de desarrolladores integrada en algún entorno de desarrollo como puede ser Eclipse en el caso de considerar Java como lenguaje de programación. Por otra parte, el desarrollo de reglas de negocio debe apoyarse en los modelos de objetos existentes en la organización, los cuales, por norma general, deben importarse en el entorno de desarrollo de reglas de negocio.

Se observa un resumen de las características más importantes de un BRMS tomando el siguiente ejemplo. Ver Tabla 2.

23 |

Característica /

Producto

ILOG JRules Blaze Advisor JBoss Rules

Algoritmo de ejecución de reglas

RETE RETE RETE

Gestión de la

Configuración

SI SI Externa (A partir de la versión 4.0)

Roles de usuarios

SI SI SI

Despliegue SI SI NO

Validación SI SI SI

Interfaz en Lenguaje

Natural

A través de DSL A través de DSL A través de DSL

Integración en el

proceso de desarrollo

Costosa, adaptación

específica


específica


específica

Lenguaje para

definición de reglas

Propio, ILOG Rules

Language (IRL)

Propio, Structured Rules Language (SRL)

Propio, Drools Rules

Language, (DRL)

Tabla 2: Resumen de las características más importantes de un BRMS

4.3. MOTOR DE REGLAS DE NEGOCIO [6]

Un motor de reglas de negocio es un sistema de información, que ejecuta reglas de negocio o monitorea actividades de negocio en términos del cumplimiento de las reglas en tiempo de ejecución.

Los motores de reglas de negocio generalmente incluyen características para el desarrollo de reglas de negocio que permiten una definición conveniente y la verificación de las reglas.

24 |

4.3.1. Ventajas de un motor de reglas sobre un sistema de información tradicional.

El motor de reglas indica que hacer, no como hacerlo, esto permite concentrar los esfuerzos en lo que se sabe que es verdad, y permite a la maquina hacer el trabajo pesado de descubrir las “consecuencias” de las diferentes “verdades”.

Separación de lógica y de datos: Las reglas de negocio se almacenan y administran en un ambiente diferente al de la base de datos de la aplicación.

Velocidad y escalabilidad: La ejecución de los motores de reglas de negocio es matemáticamente más rápida que las soluciones tradicionales de if…then

Los motores ofrecen a los expertos de negocio y a los desarrolladores, herramientas para editar y administrar reglas, además ofrecen retroalimentación inmediata a la hora de reproducir un error en la definición de las reglas.

Los sistemas de reglas proveen un sitio para realizar auditoria de cómo y porque una decisión en particular fue tomada.

25 |

4.3.1.1. Partes de un motor de reglas. [4]

Ilustración 3: Partes de un motor de reglas

Editor de reglas:

Es aquí donde se escribirán las reglas de negocio, sea un BRMS, IDE, tabla de decisión o un archivo plano de texto, todos producen un lenguaje de reglas similar, el mecanismo para desplegar estas reglas también es similar.

Compilador de reglas:

Ya que se busca construir reglas usando un lenguaje bastante próximo al lenguaje natural, se necesitó un componente que traduzca estas reglas a una forma que el motor de reglas pueda entender, este componente es el compilador.

26 |

Modelo de hechos:

La información que se maneja en el motor, y el orden de esta, deben estar claramente definidos, la descripción de esta información y el formato en que se almacena se conoce como el modelo de hechos.

Repositorio de reglas:

Las reglas tienen una importancia bastante elevada en este contexto, y gran parte del tiempo será invertido en la escritura de las mismas, se requiere realizar un manejo de esta escritura y modificación de reglas, se requiere manejar versionamiento y asegurar también que las reglas serán almacenadas en un medio seguro, medio en el cual no pueda acceder cualquier usuario. Estas funciones las maneja el repositorio de reglas, este paso también puede ser manejado por otros mecanismos como subversión.

4.3.2. Conceptos de los motores de reglas.[4]

Hechos:

Los hechos se definen como el contenedor en el que se transporta información desde y hacia el motor de reglas de negocio, estos pueden ser objetos planos en Java.

Memoria de trabajo:

En aplicaciones desplegadas en la vida real, un gran número de personas estarán llamando a las mismas reglas de forma simultánea, con el fin de evitar cruces de información, así como otros problemas de concurrencia, a cada usuario se le asigna su propio espacio en memoria, se ve de forma equivalente a como los usuarios en un navegador web accediendo a la misma aplicación, tienen su propia y única sesión.

El espacio en memoria de cada usuario, contiene todo el conocimiento (hechos) que el motor ha recibido sobre el caso, cuando se realizan cambios en los hechos, ya sea de inserción, actualización o eliminación, es la memoria de trabajo la que cambia, así mismo cuando estos cambios a los hechos son realizados por una regla, es la memoria de trabajo la que cambia.

27 |

Concordancia de patrones

Una de las funciones clave de los motores de negocio, es relacionar patrones, es decir, identificar cuáles son las reglas relevantes que deben aplicarse para una situación dada, al usar un motor de reglas, en el momento en que se insertan hechos en la memoria de trabajo, el motor se encarga de encontrar cuales son las reglas relevantes a estos hechos y dejarlas listas para ser ejecutadas

Resolución de conflictos:

Seguido el proceso de encontrar que reglas son relevantes para el conjunto de hechos cargado a la memoria de trabajo, este conjunto de reglas aunque se encuentra listo para ser ejecutado, no significa que todas las reglas sean en verdad ejecutadas, adicionalmente, los motores de reglas ejecutan esencialmente una regla a la vez, así que un paso importante es decidir que regla de las reglas relevantes debe ejecutarse primero y cuales no serán ejecutadas.

La resolución de conflictos solo es necesaria, cuando se han encontrado más de una regla relevante al conjunto de hechos cargado en memoria, el proceso en el que se decide la prioridad de ejecución de las reglas de negocio es el siguiente.

1. Prominencia: Este atributo de las reglas de negocio, permite especificar la importancia de la regla en comparación a las demás, las reglas con una alta prominencia serán ingresadas más cerca del tope superior de la agenda.

2. Recencia: Este atributo se refiere a la cantidad de veces que una regla ha sido ejecutada en el pasado, mientras más veces haya sido usada la regla, más prioridad tendrá esta en la agenda.

3. Complejidad: Una regla con más condiciones en la parte del „cuando‟, tendrá como característica el ser más específica, por lo tanto la probabilidad de que sea relevante a la situación es actual, en conclusión mientras más compleja sea una regla, mas prioridad tendrá en la agenda.

28 |

4. Orden de carga: Si ninguna de las estrategias mencionadas funciona, se toma el caso más sencillo, las reglas que se cargaron primero, son las que se ejecutaran primero.

Cuando se menciona que existe una posibilidad de que no todas las reglas relevantes sean ejecutadas, se refiere al hecho de que cada regla de negocio, está en capacidad de cambiar los hechos, y causar que las demás reglas cargadas en la agenda no sean relevantes a la nueva situación, y por lo tanto no sean ejecutadas, la única regla que tiene un 100% de probabilidades de ser ejecutada es la que obtiene el primer lugar en la agenda.

Mantenimiento de la verdad [4].

La memoria de trabajo está en continuo cambio, ya que las reglas en ejecución pueden cambiar los hechos sobre los cuales se está trabajando, existe la posibilidad de que nuevas reglas se conviertan en reglas relevantes para la nueva situación, además, estas nuevas reglas relevantes que serán agregadas a la agenda y ejecutadas posteriormente, tienen la posibilidad de cambiar los hechos y crear aún más escenarios en que otras reglas de negocio se convierten en relevantes.

Este proceso conocido como mantenimiento de la verdad, garantiza que finalizado un tiempo de ejecución, y asumiendo que las reglas de negocio están completas y verificadas, se obtendrá un conjunto de hechos que representa la verdad, siendo esta la verdad como la entiende el motor de reglas.

Existe claramente la posibilidad de que la ejecución de reglas cree un ciclo de ejecución, causando que la misma regla o el mismo conjunto de reglas se ejecute un sin número de veces dado un conjunto de hechos, esta situación debe controlarse desde el momento en que se escriben las reglas, en primer lugar escribiendo las reglas de la forma más precisa posible, en segundo lugar aplicando atributos a las reglas que indiquen un número máximo de veces que cada regla puede ser ejecutada, o usando el flujo de reglas.

29 |

Algoritmo Rete [1]:

El algoritmo Rete es un algoritmo de reconocimiento de patrones, usado para implementar sistemas de producción de reglas, su principal característica es la alta eficiencia que ofrece, a costo de un elevado consumo en memoria.

El reconocimiento de patrones es el acto por el cual se revisan las reglas frente a los hechos para determinar que reglas pueden ser ejecutadas.

Charles Forgy creo el algoritmo Rete original alrededor del año 1982 como parte de su investigación financiada por DARPA. Comparado frente a otros algoritmos de reconocimiento de patrones, Rete era muy avanzado. Hoy en día, se han hecho varias mejoras a la versión general del algoritmo, adicionalmente, se han creado variaciones de este, que pueden presentar un desempeño diferente dependiendo del ambiente en que son ejecutados.

Típicamente en los motores de reglas comerciales basados en el uso de este algoritmo, se le han hecho modificaciones para optimizar su desempeño dependiendo del mercado objetivo del producto.

La palabra Rete viene del latín, donde representa una red, este algoritmo genera una red que parte de las condiciones de las reglas, cada condición de una regla es un nodo en la red Rete. Ver ilustración 4

Ilustración 4 Estructura del Algoritmo Rete

30 |

La red Rete es un grafo dirigido, acíclico y con un punto de entrada único o raíz. Adicionalmente, la red Rete se construye de diferentes tipos de nodos:

Nodo Rete: Punto de entrada por defecto de la red, cuando se inserta un hecho en memoria, ingresa a la red Rete por este nodo.

Nodo de punto de entrada: Este nodo corresponde a un punto de entrada, es posible tener varios puntos de entrada.

Nodo de tipos de objeto: Este nodo actúa como un filtro de tipos en los hechos, solo pasan a través de los hechos que cumplen con el tipo que este nodo valida, cada rama que sale de un nodo punto de entrada debe entrar a este tipo de nodo.

Nodo alfa: El nodo alfa corresponde al primer nivel de reconocimiento, es el responsable de evaluar una única condición en los hechos, si se tienen múltiples restricciones en un mismo hecho, cada una será evaluada por un nodo alfa diferente.

Nodo terminal: Es el nodo en la red que representa la consecuencia de la regla que debe ser cargada en la agenda, cada regla tiene al menos un nodo terminal.

Nodo beta: Este nodo evalúa restricciones en 2 o más hechos, tiene 2 entradas derecha e izquierda, la izquierda es para tuplas, y la derecha para los hechos, existen varios tipos de nodos beta, como los nodos join, nodos not, nodos exist, entre otros.

Nodo from: Este nodo obtiene hechos fuera de la red Rete y los adiciona a la tupla.

El desempeño del algoritmo Rete es teóricamente independiente del número de reglas.

Cuando un hecho se modifica o se elimina dentro de la memoria de trabajo, muchas reglas pueden volverse candidatas a ser disparadas, o algunas candidatos a ser no validas, una aproximación simple es reevaluar todas las reglas frente a toda la memoria de trabajo cada vez que los hechos son modificados, aunque este método garantiza el éxito, tiene un desempeño sub óptimo.

Existen variaciones del algoritmo Rete que permiten al motor de reglas mantener memoria de los resultados parciales que se obtienen mediante el proceso de reconocimiento. De esta forma la reevaluación de cada condición es innecesaria, debido a que el motor sabe qué condiciones podrían cambiar dependiendo de los hechos que se modifican, y solo son estas condiciones las que son evaluadas.

31 |

4.3.3. Clasificación de motores de reglas:

Los motores de reglas pueden ser clasificados en 3 tipos:

1. Aquellos que usan un algoritmo de inferencia para procesar reglas.

2. Aquellos que usan un algoritmo de dependencia para pre-compilar el código para procesar reglas.

3. Aquellos que integran reglas en ambientes de base de datos por medio de disparadores de base de datos, restricciones o procedimientos almacenados.

4.3.3.1. ¿Qué hace un algoritmo de inferencia? [26]

Un algoritmo de inferencia (algunas veces llamado “estrategia de razonamiento”) es el componente en un motor de inferencia que decide que reglas deberían ser evaluadas y cuando, para resolver un problema en particular.

El motor de interferencia tratara de encontrar un camino óptimo dentro de un conjunto de reglas para resolver un problema o tratar una situación.

Existen 2 estrategias bien conocidas que pueden ser implementadas por un algoritmo de inferencia: “backward chaining” y “forward chaining”, estas estrategias son aplicadas a las reglas del tipo de reglas de producción.

4.3.3.2. ¿Qué es backward chaining? [26]

Un algoritmo de inferencia procesara las reglas en el orden que permita alcanzar un objetivo en una forma óptima (en términos de tiempo y recursos).

Un requerimiento para este tipo de razonamiento es que se sepa desde antes el objetivo del proceso de inferencia, por lo tanto este tipo de procesamiento de reglas es llamado 'goal-driven'.

Un ejemplo de un objetivo en una tarea de evaluación en si una entidad es aprobada o no, las primeras reglas a ser seleccionadas para evaluación en un proceso de backward chaining es la regla que permita decidir si una entidad es aprobada o no, cuando los hechos usados por la condición de esta regla no son conocidos, estos hechos se convertirán en nuevos objetivos y el proceso empieza desde el principio.

32 |

4.3.3.3. Que es forward chaining? [26]

Un algoritmo de inferencia de forward chaining procesara las reglas en orden para concluir lo más posible o deseado, basándose en datos existentes.

Basado en un caso particular o conjunto de datos, el motor de inferencia aplica las reglas para ver qué conclusiones puede derivar, ya que este caso es descrito por datos, este tipo de procesamiento de reglas suele ser llamado 'data driven'.

En este caso las reglas relevantes para cierto caso serán evaluadas. Cuando la aplicación de las reglas resulte en nueva información en el caso, es posible re-evaluar las reglas relevantes.

4.3.4. ¿Cuáles son los beneficios de los motores de reglas de negocio? [26]

Automatizar una regla de negocio en un lenguaje de programación no es un proceso altamente complejo, el beneficio de los motores de reglas se vuelve aparente cuando es necesario automatizar un conjunto de reglas con interdependencia, hay 2 razones para usar motores de reglas en lugar de un lenguaje de programación procedimental:

1. Enfoque en las reglas.

Una razón para usar reglas de negocio es que se quiere concentrar en las reglas y no en la tecnología, los motores de reglas de negocio ofrecen soporte para hacerlo.

2. No nos preocupa el orden.

Una característica de las reglas de negocio es que son declarativas, esto significa que el orden o secuencia en que las reglas son evaluadas, no afecta los resultados, sin embargo, cuando las reglas son implementadas en un lenguaje procedimental tradicional, el programador debe especificar el orden en que las reglas son evaluadas. Un gran beneficio de usar un motor de inferencia es que el programador no se preocupa por este orden; el motor de reglas decide acerca de este orden. Esto evita que los programadores cometan errores al ordenar las reglas y así no causar efectos secundarios indeseados.

33 |

Aunque estos son los 2 beneficios más grandes de los motores de reglas de negocio frente a los lenguajes de programación declarativos, los motores vienen con otros beneficios como:

1. Editores especializados para escribir reglas.

2. Funcionalidad para el cambio de reglas y el fácil despliegue de reglas cambiadas.

3. Funcionalidad especializada para la administración de reglas como fechas efectivas, autor y autorización.

Todas estas características reducen el tiempo necesario para desarrollar y desplegar reglas de negocio en un sistema de información.

4.3.4.1. ¿Puedo alcanzar un alto desempeño con un motor de reglas de negocio?

Los motores de reglas de negocio están optimizados para procesar un gran conjunto de reglas en un mínimo tiempo, esta optimización es una de las razones para comprar un motor de inferencia en lugar de construir uno propio.

Pueden existir cuellos de botella de vez en cuando, en esas situaciones, un algoritmo procedimental optimizando la evaluación de reglas usando conocimiento acerca del dominio y estructura de las reglas es la única solución.

Sin embargo, esta solución incrementa los riegos asociados al cambio de reglas y es un proceso que presenta altas dificultades. [26]

34 |

4.3.5. Características de los motores de reglas de negocio. [26]

Características de inferencia:

Mantenimiento de la verdad.

Ejecución paralela de reglas.

Encadenamiento hacia adelante y hacia atrás.

Reglas recursivas

Restricciones

Herencia de reglas

Taxonomía de reglas

Múltiples motores de reglas.

Características de administración de reglas:

Dueños de reglas.

Análisis del impacto del cambio de reglas.

Fechas efectivas para reglas y la opción de evaluar un caso contra reglas viejas.

Chequeo de consistencia de reglas.

Versionamiento de reglas.

Versionamiento de releases.

35 |

4.3.6. Cuando no se debe usar un motor de reglas de negocio. [26]

Un motor de reglas de negocio no debería ser usado si la aplicación a construir no tiene mucha complejidad, muchas aplicaciones suelen ser solamente páginas web que almacenan información en una base de datos. Se debe evaluar si la complejidad de la aplicación requiere el esfuerzo adicional de implementar un motor de reglas de negocio, también se debe tener en consideración cual será el crecimiento de la aplicación y si este crecimiento incrementará la complejidad de la aplicación.

Es importante desarrollar habilidades fuertes en el uso de los motores de negocio antes de construir aplicaciones complejas, que tienen tiempos de entrega cortos, o aplicaciones que son núcleo para la empresa.

Evaluar si el motor de reglas es la tecnología apropiada para el software que será construido, es posible que para alguna aplicación deba usarse un Workflow o realizar acciones en una determinada secuencia.

4.3.7. ¿Cuáles son los beneficios de una administración de reglas de

negocio mejorada? [26] Los beneficios principales de una administración explicita de reglas de negocio son:

El tiempo que se necesita para cambiar las reglas de negocio y de hacer este cambio efectivo en los procesos de negocio o en el sistema de información se ve reducido.

La ganancia en servicios o productos puede incrementarse, al reaccionar más rápido a las demandas de un mercado cambiante.

Incrementar la satisfacción de los clientes debido a una aplicación rápida, consistente y transparente de las reglas de negocio

Incrementar la satisfacción del empleado debido a una comunicación mejorada y eficiente.

36 |

4.3.8. ¿Quiénes son los responsables por las reglas de negocio?

La responsabilidad para la expresión, comunicación y aplicación de las reglas de negocio generalmente no se comunica de forma oficial en la organización. Cuando las reglas de negocio son administradas de forma explícita, cada regla debe ser asociada con una fuente y un dueño. La fuente puede ser la sección de la ley en la que la regla está basada o el inventor, por ejemplo el administrador de mercadeo, esto hace fácil el encontrar a todos los afectados por las reglas cuando la ley cambia o el inventor cambia de idea o de opinión. El dueño es responsable por cambiar, comunicar y distribuir la regla, algunas reglas como las reglas de descuento, pueden pertenecer al departamento de mercadeo, otras reglas al departamento legal. En una organización grande, la responsabilidad por un conjunto de reglas de negocio puede ser un trabajo de tiempo completo.

37 |

4.4. ANÁLISIS DE MOTORES DE REGLAS DE NEGOCIO

4.4.1. Oracle Business Rules:

Oracle Business Rules pertenece a la plataforma SOA de Oracle. Este producto funciona de manera conjunta con el Servidor de Aplicaciones de dicha compañía.

Entorno de Desarrollo

Para facilitar el desarrollo de aplicaciones basadas en reglas, Oracle Business Rules cuenta con las siguientes herramientas: Rule author: permite trabajar con reglas de negocio desde cualquier navegador. En otras palabras, es una interfaz Web con la capacidad de crear nuevas reglas o editar las ya existentes. Rule SDK: Oracle Business Rules SDK es una biblioteca java que permite la administración de distintas características de las reglas de negocio. Un desarrollador puede usar esta librería para escribir las reglas del programa. Rules Engine: Oracle Business Rules Engine (Rules Engine) es una librería java que se encarga de procesar las reglas de acuerdo a los hechos que tiene disponibles en la memoria de trabajo, además define un lenguaje de reglas declarativo, provee un motor de inferencia y herramientas que soportan debug.

Algoritmo

En Oracle Business Rules, el sistema basado en reglas es manejado por los hechos, y con encadenamiento de reglas hacia adelante. Los hechos determinan cuáles reglas pueden ser ejecutadas. Cuando una regla es ejecutada, ésta podría agregar nuevos hechos, y estos nuevos hechos pueden conducir a la ejecución de nuevas reglas. Este proceso se repite hasta obtener una conclusión final. Este proceso se llama ciclo de inferencia

38 |

Compatibilidad y plataformas

El Rule Engine de Oracle Business Rules se puede usar de dos formas:

Jar Embebido: En esta opción, el motor de reglas va embebido

en la aplicación que lo utiliza, por lo tanto se puede utilizar sólo en aplicaciones Java, las cuales a su vez son multiplataforma.

Decision Service: Otra forma es usarlo a través de servicios Web, de esta forma es posible consumir las reglas como un servicio, por lo que el motor puede ser utilizado por aplicaciones desarrolladas en cualquier lenguaje.

Características Generales

Alto rendimiento: Rules Engine implementa algoritmos especializados para los hechos que son definidos en el sistema.

Hilo de ejecución para una arquitectura en paralelo: Rules Engine provee un thread que puede sostener hechos mientras otro es evaluado en la red.

Agilidad: Rules Engine permite cambiar las reglas sin parar los

sistemas en proceso.

4.4.2. Open Rules Es un sistema de administración de reglas de negocio de gran escala, que está formado por un conjunto de herramientas de código abierto que permiten desarrollar aplicaciones basadas en reglas.

Entorno de Desarrollo El repositorio de Open Rules está basado en un conjunto jerárquico de libros y hojas de cálculo, las cuales entre sí, y con un formato claramente definido forman la base de reglas. Para el proceso de desarrollo se integran distintas herramientas de código abierto.

39 |

Algoritmo La ejecución de reglas en Open Rules es muy intuitiva, no asume ningún orden implícito ni aplica algún algoritmo que especifique el orden de ejecución de las reglas, éstas simplemente se ejecutan en el orden especificado en el diseñador de reglas. Todas las reglas son ejecutadas una a una en el orden que fueron ubicadas en las tablas de reglas. Para las tablas de decisión de forma vertical, las reglas son ejecutadas de arriba hacia abajo, mientras que para las tablas de decisión de forma horizontal, las reglas son ejecutadas de izquierda a derecha.

La lógica de ejecución es la siguiente:

“Si todas las condiciones son satisfechas ENTONCES ejecutar todas las acciones”.

Si al menos una condición es violada, todas las otras en la misma regla son ignoradas y no son evaluadas.

La ausencia de un parámetro significa que la condición que utiliza

dicho parámetro es verdadera.

Compatibilidad y plataformas Existen tres formas de desplegar la funcionalidad del motor de reglas: Como un método Java: De esta forma, la funcionalidad queda a disposición de cualquier aplicación que se desarrolle en Java, restringida a este lenguaje. Como una aplicación Web: Open Rules permite a los usuarios de negocio definir sus propias interfaces Web para interactuar con la base de reglas, esto se hace mediante la característica “Web Forms” a través de la cual el usuario define en la misma planilla Excel en la que se detallan las reglas, un formulario desde el cual se obtendrán los parámetros de entrada de ellas. A partir de esta especificación, el motor generará automáticamente un formulario Web JSP. Como un servicio Web: De esta manera se consigue que el motor interactúe con aplicaciones desarrolladas en cualquier lenguaje y por lo tanto se pueda utilizar cualquier plataforma para su funcionamiento.

40 |

Licenciamiento:

Open Rules está disponible para cualquier persona bajo la licencia Open Source “GNU General Public License” (GPLv2).


Rule Validator: Provee validación de reglas y detección de errores Rule Testing: Provee la capacidad de probar las reglas en base a datos proporcionados en planillas de cálculo. Rule Learner y Rule Solver: Ayudan a que el motor tenga una mayor performance, descubriendo patrones regulares de uso de la base de reglas y obteniendo la manera óptima de ejecución de éstas.

4.4.3. NxBRE

NxBRE fue el primer motor de reglas de código abierto orientado a la plataforma .NET de Microsoft. NxBRE tiene dos componentes principales:

Entorno de desarrollo El motor de inferencia utiliza un lenguaje de reglas llamado RuleML el cual es propuesto como el estándar de especificación de reglas para diversos propósitos como la Web semántica, reglas de negocio y reglas transformación de documentos XML entre otros. Este lenguaje se basa en XML por lo que su creación, modificación o eliminación se puede hacer de varias formas:

Microsoft Visio: La distribución de NxBRE incluye una plantilla para Microsoft Visio mediante la cual se puede administrar gráficamente las reglas.

Editores XML: Para la administración de reglas se puede utilizar desde el más básico editor de texto, como Notepad, incluido en Microsoft Windows, hasta editores especializados en XML como XML Spy o el plug-in WTP de Eclipse.

41 |

Human Readable Format: Consiste en una transformación XSLT mediante la cual se transforma las bases de reglas de formato RuleML a un formato más comprensible y manejable por usuarios no especializados.

Algoritmo Flow Engine: utiliza XML para mantener el control del flujo de ejecución del

proceso. Proporciona todas las sentencias de ejecución conocidas como if/then/else,

while, foreach, etc. Todo esto en un contexto de objetos de negocio y resultados.

Inference Engine: Es un motor de inferencia de encadenamiento hacia

delante que soporta conceptos como hechos, consultas, prioridad de reglas y exclusión mutua. Este alienta la separación de roles entre los expertos que diseñan las reglas de negocio y el personal de informática que une éstas con los objetos de negocio.

Compatibilidad y plataformas

NxBRE está diseñado para la plataforma .NET de Microsoft, por lo tanto, su ejecución de manera nativa está limitada a las plataformas en las que exista máquina virtual para .NET. Actualmente existe dicha compatibilidad para sistemas Windows mediante Microsoft .NET Framework y en sistemas Linux con el Proyecto MONO. Adicionalmente está la posibilidad de exponer el motor como un Servicio Web, con lo cual las aplicaciones clientes del motor pueden ser escritos en cualquier lenguaje y correr sobre cualquier plataforma.

Licenciamiento NxBRE está licenciado bajo los términos de la LGPL (Lesser General Public License), la cual permite su uso en aplicaciones comerciales.


NxBRE, a diferencia de otros motores analizados, dispone de dos formas distintas de ejecución de reglas, el motor de inferencia que es capaz de obtener conclusiones a partir de hechos y reglas, y el motor de flujo que permite realizar acciones a través de sentencias de control conocidas. Este motor de reglas está basado en JxBRE, el cual está construido para plataformas Java.

42 |

4.4.4. JBoss Rules

JBoss Rules, anteriormente conocido como Drools, sirve para implementar la lógica de evaluación y decisión junto a conjuntos de datos y hechos de gran tamaño.


El entorno de desarrollo para las reglas del negocio usado por Jboss Rules es Eclipse, al cual, para permitir la administración de las reglas, debe instalarse un “plugin”, el que añade los elementos necesarios para la creación y modificación de las reglas del negocio.

Algoritmo

El motor de reglas de Jboss Rules basa su ejecución en el algoritmo rete, optimizado para sistemas orientados a objetos, este algoritmo basa su ejecución en el método de encadenamiento hacia delante.

Compatibilidad y plataforma Jboss Rules permite el despliegue en múltiples plataformas, ya que es una solución Java, permitiendo crear y ejecutar las mismas reglas en entornos Java, .NET u otros. Además incorpora la posibilidad de trabajar con servicios Web, permitiendo la conexión y traspaso de información al motor de reglas desde cualquier plataforma o ambiente de desarrollo.

Licenciamiento

Jboss Rules es un motor de reglas Open Source.

Características Generales: Jboss Rules incluye un administrador Web de reglas (BRMS), que lo hace disponible desde cualquier computador vía HTTP, permitiendo la comunicación entre los administradores del negocio y los que manejan la tecnología de la informática, dando a los primeros control en la creación de la lógica del negocio (reglas de negocio).

43 |

4.4.5. Blaze Advisor

Blaze Advisor es una solución completa y avanzada para la gestión de reglas, que abarca todo el proceso de creación, implantación y mantenimiento de las aplicaciones basadas en reglas, especialmente en aquellas de carácter transaccional y operativo. Este software ofrece un entorno de desarrollo para crear modelos de reglas, así como para probarlas y realizar simulaciones, antes de generar automáticamente un código para su despliegue en las aplicaciones de producción. Los componentes de Blaze Advisor son:


Las reglas se definen utilizando el entorno de desarrollo integrado (IDE) de Blaze Advisor, que es un entorno completo para la creación, modificación y comprobación de reglas, además de especificación de plantillas para la creación de reglas, las cuales permite a usuarios sin conocimiento técnico la creación y modificación de las reglas.

Algoritmo Basa su ejecución en el algoritmo rete, permite la ejecución escalable de reglas e integra las base de datos y otras fuentes de información para el uso de evaluación de las reglas

Compatibilidad y Plataforma: Un elemento diferenciador es el despliegue en múltiples plataformas, ya que es una solución Java que permite crear y ejecutar las mismas reglas en entornos Java, .NET y COBOL.

Licenciamiento Blaze Adivisor pertenece a la corporación con fines de lucro Fair Isaac, su licencia es de tipo comercial.

44 |


Gestor de desarrollo, introduce reglas nuevas en los sistemas de producción sin requerir tiempo de inactividad.

Almacén de reglas, almacena las reglas y gestiona los cambios en ellas.

Aplicación de mantenimiento de reglas. Permite al personal sin formación técnica revisar y actualizar las reglas sin necesidad de programación.

4.4.6. BizTalk Server

BizTalk Server es una plataforma para la integración de procesos de negocio. Lo que se consigue con BizTalk es integrar procesos de sistemas heterogéneos u homogéneos de forma que puedan comunicarse con facilidad. BizTalk Server provee un ambiente de trabajo (framework) utilizado en la implementación y ejecución de las reglas de negocio. Business Rule Framework (BRF) se interpreta como un conjunto de librerías que proveen la funcionalidad necesaria para la creación, evaluación y ejecución de cada una de las reglas de negocio establecidas previamente por el proceso. A su vez, el BRF se compone de:

Entorno de Desarrollo.

El Business Rule Composer es el entorno de desarrollo de Biztalk Server, que puede ser utilizado por desarrolladores, analistas del negocio y/o administradores de los procesos de negocio, durante el proceso de creación e implementación. Esta herramienta es usada para autorizar, crear, desplegar y definir reglas de negocio, a su vez se compone de las siguientes vistas:

Policy Explorer: se administran las políticas y reglas. Por medio de esta vista se pueden crear, modificar y eliminar políticas y reglas, además de probarlas y publicarlas en la base de datos.

Facts Explorer: se administran los hechos utilizados por las reglas como vocabularios, esquemas XML, bases de datos y clases de .Net.

Action Editor: se utiliza para ver y editar las acciones que se deben

ejecutar cuando una regla es válida.

45 |

Algoritmo: El motor de reglas de negocio implementa el mecanismo de evaluación, basado en el algoritmo Rete, para las reglas de negocio. En su arquitectura interna, el motor está compuesto por tres componentes:

Ruleset executor: es el responsable de evaluar y ejecutar las reglas del

negocio.

Ruleset translator: toma el objeto de la regla del negocio de entrada y lo

traduce en una presentación ejecutable.

Rule set tracking interceptor: toma la salida generada en la ejecución de

la regla del negocio, y la envía a las herramientas de monitoreo.

Licenciamiento Su licencia es de carácter comercial, perteneciente a Microsoft.

Compatibilidad y plataforma

Biz Talk Server puede ser desplegado en plataforma Windows solamente.

Características Generales Una de las principales características del BRE es que está diseñado para que las reglas de negocio puedan ser invocadas desde procesos de integración en BTS o desde aplicaciones desarrolladas en .Net.

4.4.7. IBM ILog JRules

IBM Websphere ILog JRules es un motor de reglas basado en java de la compañía ILog propiedad de IBM, JRules provee un ambiente de desarrollo grafico de reglas, con un editor y un debugger para hacer rastreo de lógica, así como la detección de errores e inconsistencias. JRules incluye un servidor de ejecución, que integra JRules a un servidor J2EE Los productos incluyen WebSphere ILOG JRules, IBM ILOG CPLEX, IBM ILOG JViews y IBM ILOG LogicNet Plus XE.

46 |

Entorno de Desarrollo. JRules usa IBM WebSphere ILOG Rule Studio, un entorno de desarrollo basado en eclipse, que incluye autocorrección en la edición de reglas, detección de conflictos y redundancia, herramientas y asistentes de configuración para crear marcos de trabajo de prueba, así como control de integración de código fuente.

Algoritmo: JRules permite decidir diferentes modos de ejecución, por defecto, la ejecución está asignada al modo de ejecución RETE plus (Algoritmo RETE), los diferentes modos de ejecución de JRules son los siguientes: Rete Plus: Modo por defecto, usa el algoritmo RETE para el encadenamiento de reglas. Secuencial: Permite la ejecución de muchas reglas, pero bajo número de hechos. Fastpath: Ejecución de reglas que implementan una estructura de decisión, permite el uso de un alto número de hechos, según ILOG aunque este modo requiera mayor tiempo en compilación es más rápido en tiempo de ejecución.

Licenciamiento

Su licencia es de carácter comercial, perteneciente a IBM

Compatibilidad y plataforma

ILog JRules es compatible con varias plataformas, incluyendo C++, C#, .Net, Java, AJAX, Adobe Flex y Adobe AIR.


ILOG JRules provee herramientas y lenguajes de reglas para permitir a desarrolladores, analistas y administradores de políticas desplegar y administrar las reglas de negocio. Se incluye además un repositorio para almacenar las reglas definidas y librerías Java para definir y expandir la ejecución de reglas y el ambiente de ejecución de las mismas.

47 |

Algunas características principales son:

RuleFlow: Orquestar la ejecución de paquetes de reglas usando UML

Editor de tablas de decisión: Creación y mantenimiento de reglas en forma de tablas de decisión.

Validacion de reglas: Checkeo automático de sintaxis de reglas

Query: Búsqueda y actualización de elementos del repositorio.

Web Rule Editor: Creación, lectura y actualización de reglas mediante un navegador web

Profiler: Evalúa el desempeño en tiempo de ejecución de un conjunto de reglas.

48 |

4.5. TABLA COMPARATIVA DE MOTORES DE REGLAS DE NEGOCIO

Nombre Motor

Entorno de desarrollo

Algoritmo Compatibilidad y plataformas

Características generales

Licenciamiento

Oracle Business Rules

Rule Author Rule SDK Rules Engine

Ciclo de inferencia Jar embebido

Decision Service

Alto Rendimiento

Hilo de ejecución para una arquitectura en paralelo

Agilidad

Open Rules

Repositorio basado en un conjunto jerárquico de libros y hojas de cálculo.

Todas las reglas son ejecutadas una a una en el orden que fueron ubicadas en las tablas de reglas

Método Java

Como aplicación web

Como servicio Web

Rule validator

Rule testing

Rule learner

Rule solver

Open Source “GNU General Public License” (GPLv2)

NxBRE Basado en RuleML a su vez basado en XML.

Flow Engine

Inference Engine

.Net de Microsoft 2 formas de ejecución (motor de inferencia y motor de flujo).

LGPL (Lesser General Public

License)

JBoss Rules

Eclipse (plugin)

Algoritmo RETE optimizado para sistemas orientados a objetos.

Multiples plataformas (basado en java)

Servicios Web

Incluye BRMS web.

Open Source

Blaze IDE Algoritmo Multiples Gestor de Licencia

49 |

Advisor integrado de Blaze Advisor

RETE plataformas (basado en java)

desarrollo

Almacén de reglas.

Aplicación de mantenimiento de reglas.

comercial, pertenece a Fair Isaac.

BizTalk Server

Business Rule Composer

Algoritmo RETE

Plataforma Windows.

reglas de negocio invocadas desde procesos de integración en BTS o desde aplicaciones desarrolladas en .Net

Licencia comercial, pertenece a Microsoft.

IBM ILOG

IBM WebSphere ILOG Rule Studio

Algoritmo RETE

Multiplataforma (C++, C#, .Net, Java, AJAX, Adobe Flex, Adobe AIR.)

Características como:

RuleFlow

Editor de tablas de decisión.

Validación de reglas.

Query.

Web Rule Editor

Profiler.

Licencia comercial, pertenece a IBM

50 |

4.5.1. Resumen de las características disponibles en cada motor de reglas estudiado. Ver Tabla 3 [6]

Ad

min

istr

ac

ión

de

reg

las

vía

Web

Ad

min

istr

ac

ión

grá

fic

a d

e r

eg

las

Co

mp

ati

bilid

ad

nati

va

mu

ltip

lata

form

a

Dis

po

nib

ilid

ad

de

So

po

rte

Ma

nejo

de

DS

L

Co

ntr

ol d

e v

ers

ion

es

de r

eg

las

Lo

gin

Usu

ari

os

Pa

qu

ete

de r

eg

las

vía

HT

TP

En

torn

o d

e p

rue

bas d

e r

eg

las

Op

en

So

urc

e

JBoss Rules

X X X X X X X X

X

Oracle Business Rules

X X X X X X X X X

OpenRules

X X X

X

X

NxBRE

X X X

X

Blaze Advisor

X X X X

X

X

BizTalk Server

X X X X X X

X

IBM ILOG X X X X X X X X X

Tabla 3: Resumen de las características disponibles en cada motor de reglas estudiado

51 |

5. DESCRIPCIÓN DE LA HERRAMIENTA SELECCIONADA

Debido a su esquema de licenciamiento, uso del servidor de aplicaciones JBoss, y a la facilidad de adquisición de información, se escoge a JBoss Rules como motor a utilizar en el componente práctico; JBoss Rules es un motor de reglas de negocio open source basado en estándares, rápido y altamente eficiente que facilita ver las reglas del negocio a medida que son codificadas. JBoss Rules también soporta varias formas de ingresos de reglas mediante tablas de decisión y lenguaje, facilitando la rápida modificación de las políticas comerciales. La arquitectura de Jboss Rules se muestra en la Ilustración 5.

Ilustración 5: Arquitectura Jboss Rules El motor de inferencia debe sacar conclusiones desde los hechos y las reglas de producción, dando como resultado acciones. Este proceso es llamado “Patter Matching” el cual se basa en el algoritmo ReteOO. El motor de inferencia controla el proceso completo de aplicar los hechos de las reglas a la memoria de trabajo. Las reglas son almacenadas en la memoria de producción, mientras que los hechos son insertados en la memoria de trabajo donde pueden ser modificados o retractados. IDE: Rule Workbench Jboss Rules permite la administración avanzada de las reglas para los desarrolladores, como se observa en la figura 2, a través del entorno de desarrollo Eclipse de Java, el cual provee funcionalidades mediante la instalación de un plugin, disponible en la página oficial de Jboss , el que añade nuevas características al entorno de desarrollo, como lo muestra la Figura3.

52 |

Figura 1: Jboss Rules en Eclipse Las características que posee son:

Editor textual y grafico de reglas.

Un editor que conoce de la sintaxis DRL, facilitando asistencia al desarrollo.

Wizards que ayudan a: La creación rápida de nuevos proyectos Creación de nuevos recursos, paquetes de reglas Creación de nuevo lenguaje DSL

Editor de DSL

Validador de reglas

53 |

Figura 2: Plugins Eclipse de Jboss Rules El lenguaje de reglas. Archivo de reglas. Un archivo de regla es típicamente un archivo con extensión .drl, que puede contener múltiples reglas, funciones, consultas, así como también declaración de recursos, como imports, atributos y variables globales que son usados por las reglas. La estructura del archivo de reglas es el siguiente:

54 |

Las reglas tienen la siguiente estructura:

Como todo lenguaje de programación, el lenguaje de reglas de Jboss Rules posee palabras reservadas, las cuales no pueden ser ocupadas como nombre de variables. Rule Flow Jboss Rules, a través de “Rule Flow” permite definir el orden en que son evaluadas un grupo de reglas o reglas de un paquete, pudiendo ser de forma secuencial o paralela. Todo esto se lleva a cabo mediante un editor gráfico, semejante a un workflow, donde se dan las condiciones para que se ejecute determinado grupo de reglas.

rule "nombre de la regla" atributos when LHS (lado izquierdo, condición) then RHS (lado derecho, acción) end

package package-name imports globals functions queries

Reglas

55 |

Figura 3: Componente BRMS

BRMS (Business Rule Management System) Este es un componente de Jboss Rules que permite administrar, almacenar, editar, y desplegar las reglas, como se aprecia en la Figura 3. El BRMS es una interfaz Web muy amigable que permite administrar las reglas por usuarios de distintos ambientes, como analistas del negocio, desarrolladores, etc.

5.1 ESCRITURA DE REGLAS DE NEGOCIO.

Cada organización o incluso cada profesión, tiene un lenguaje propio, esto es, términos y expresiones que se usan en algún lenguaje, pero que tienen un significado específico para la profesión en que se usa, un ejemplo claro es la medicina.

Ya que el objetivo de las reglas de negocio es traducir el conocimiento del profesional o experto al sistema, se debe traducir también este lenguaje propio o lenguaje especifico de dominio en la escritura de las reglas, sin embargo, no se debe olvidar que las reglas deben estar escritas en un formato que pueda ser comprendido por la máquina.

Es de esta forma que se identifican 2 formas de escritura de reglas, la primera forma es usando lenguaje técnico para las llamadas reglas técnicas.

56 |

rule "Revisar paciente por ataque cardiaco" when $paciente : Patient(

respirando == false, pulso== false, (cara == azul or cara == blanco) )

then $hospital.llamarPorAsistencia(); $paciente.comenzarPrimerosAuxilios(); end

Este ejemplo muestra una regla escrita en lenguaje tecnico con el formato usado por Jboss Rules, a continuación se presenta la misma regla escrita en forma de regla de negocio:

rule "Revisar paciente por ataque cardiaco" when Existe un paciente

• parece no estar respirando • no tiene pulso, • tiene la cara azul o blanco

then Llamar por asistencia Comenzar primeros auxilios end

Se ven claras diferencias en el lenguaje usado para escribir esta regla, sin embargo, la diferencia radica solamente en la clase de lenguaje escrito, la estructura de la regla permanece intacta y se detalla identificando los siguientes componentes:

Nombre de la regla (rule):

Las reglas de negocio deben ser identificables y diferenciables, esto se hace al asignar a cada regla un nombre usando la palabra reservada rule seguida del nombre de la regla.

57 |

Condiciones (when):

En esta parte de las reglas técnicas, es donde serán escritas las diferentes condiciones que deben cumplirse para que una regla sea disparada, existen diferentes patrones de escritura de condiciones, se pueden escribir cualquier cantidad de condiciones, conectores lógicos entre condiciones y paréntesis y llaves para modificar el orden en que las condiciones son evaluadas, algunos ejemplos son los siguientes:

Ventas(nombre==”compañía alfa” or nombre ==”compañía beta”)

Ejemplo del conector lógico or, en algunos motores de reglas este conector puede omitirse y dejarse como un espacio en blanco.

Ventas(nombre==” compañía alfa” and ventas >100)

Ejemplo del conector lógico and, en ciertos motores puede usarse también como && o una coma (,).

not Cuenta(tipo==Account.Type.SAVINGS)

Ejemplo de la palabra reservada not, representa la no existencia del hecho que se le presenta.

exists Cuenta( tipo== Account.Type.SAVINGS)

Ejemplo de la palabra reservada exists, es la palabra inversa a not.

Estos conectores pueden usarse en combinación para generar reglas con un nivel de complejidad más elevado, también existe la posibilidad de incluir paréntesis y llaves para modificar la prioridad de ciertas condiciones frente a las demás.

Consecuencias (then):

Cuando todas las condiciones en una regla se cumplen, la regla es activada, esto q

investigaciÓn para la adopciÓn y uso de los...

Documents