Gestión de reglas de negocio: Motor de Reglas Drools vs LPT SQL

Texto completo

(1)Universidad Central ―Marta Abreu‖ de Las Villas Facultad Matemática, Física y Computación Licenciatura en Ciencia de la Computación. Trabajo de Diploma Gestión de reglas de negocio: Motor de Reglas Drools vs LPT-SQL Autor: Aylen García de la Paz Tutor: MSc. Martha Beatriz Boggiano Castillo. “Año 56 de la Revolución” Santa Clara 2014.

(2) Dictamen. Dictamen. Hago constar que el presente trabajo fue realizado en la Universidad Central ―Marta Abreu‖ de Las Villas como parte de la culminación de los estudios de la especialidad de Ciencia de la Computación, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. Firma del Autor. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del tutor. Firma del jefe del Laboratorio.

(3) Pensamiento. Pensamiento. “A veces sentimos que lo que hacemos es tan solo una gota en el mar, pero el mar sería menos si le faltara una gota” Madre Teresa de Calcuta.

(4) Dedicatoria. Dedicatoria. A mis padres por permitirme existir y por estar en los buenos y malos momentos. A mi hermano Alain por ser mi fuente de inspiración y mi guía..

(5) Agradecimientos. Agradecimientos. Agradezco a todas aquellas personas que han colaborado con mi formación. A mis padres y a mi hermano, por impulsarme a ser cada día mejor. A mi tutora Mathica por ayudarme en la realización de esta tesis. Por el apoyo brindado y tener confianza en mí. A Daynier por su amor y paciencia. A mi tía Raquel por su apoyo incondicional y a toda mi familia. A mis suegros por sus acciones y buenos deseos. A todos aquellos profesores y compañeros de estudio, que durante mi vida estudiantil me han ayudado a convertirme en lo que soy. En fin, a todos los que han contribuido a convertir este sueño en una realidad..

(6) Resumen. Resumen Los sistemas gestores de reglas de negocio como Drools, basado en motores de reglas de inferencia es una de las formas más populares de implementar las reglas del tipo IF… THEN usando el enfoque de reglas de negocio; sin embargo estos sistemas exhiben desventajas en el trabajo con abundantes datos y frecuentes accesos a las bases de datos. No necesariamente todas las reglas tienen que ser implementadas con estos sistemas, las reglas categorizadas desde la perspectiva de los datos, que están asociadas al comportamiento de los mismos, y almacenadas en bases de datos relacionales pueden ser implementadas de manera sencilla con la herramienta LPT-SQL. En este trabajo se usan estas dos herramientas Drools y LPT-SQL para implementar un conjunto de reglas de negocio del sistema de información para la planificación de menús en comedores universitarios, de modo que se evidencia cómo realizar el trabajo con cada herramienta y se realiza una comparación entre ellas en cuanto a requerimientos de instalación, tipos de reglas con las que trabajan, uso del repositorio, expresiones de reglas en nivel técnico, rendimiento y documentación. Como resultado se demostró que la herramienta LPT-SQL brinda facilidades para un especialista técnico del negocio en el tratamiento de reglas desde la perspectiva de los datos para sistemas de bases de datos operacionales..

(7) Abstract. Abstract Business Rules Management Systems like Drools, based on Inference Rules Engines are one of the most popular ways of implementing IF... THEN style rules using the business rules approach. These systems, however, show disadvantages when confronted with large amount of data and frequent database accesses. All the rules need not to be implemented on these systems. Rules categorized from the perspective of data which are associated to the behavior of that data and stored in relational databases may be implemented easily by means of the tool LPT-SQL. In this work we use both Drools and LPT-SQL in order to implement a set of business rules of the information system for menu planning in canteens, so it can be established how to work with each tool in order to make a comparison between them. The comparison is established attending to installation requirements, types of rules, use of the repository, rule expressions in technical level, performance and documentation. As a result it was demonstrated that the tool LPT-SQL offers facilities for a technical business specialist in the treatment of rules from the perspective of data for operational database systems..

(8) Tabla de contenidos. Tabla de Contenidos Introducción ...................................................................................................................... 1 Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio. ............................................................................................................................. 7 1.1 Enfoque de Reglas de Negocio ................................................................................ 7 1.2 Formas de expresión de las Reglas de Negocio ....................................................... 9 1.3 Implementación de Reglas de Negocio ................................................................... 9 1.3.1 Motores de Reglas de Negocio ......................................................................... 9 1.3.2 Mecanismos de base de datos. ........................................................................ 14 1.4 Sistema de Gestión de Reglas de Negocio ............................................................. 17 1.4.1 Componentes Básicos de un BRMS ............................................................... 18 1.4.2 Ventajas y Desventajas ................................................................................... 20. 1.5 Jboss Rules (Drools) .............................................................................................. 21 1.5.1 Arquitectura .................................................................................................... 22 1.5.2 Lenguajes de Definición de Reglas de Negocios............................................ 25 1.5.3 Caracterización de las principales bibliotecas ................................................ 27 1.6 La herramienta de Software: LPT-SQL ................................................................. 28 1.6.1 Arquitectura .................................................................................................... 28 1.6.2 Reglas desde una Perspectiva de Datos .......................................................... 30 1.6.3 Lenguaje de Patrones Técnicos....................................................................... 33 1.6.4 Repositorio de reglas ...................................................................................... 36 1.6.5 Extracción del Catálogo de la Base de Datos ................................................. 40 1.6.6 Ventajas y Desventajas ................................................................................... 41 1.7 Conclusiones Parciales .......................................................................................... 42.

(9) Tabla de contenidos. Capítulo 2. Implementación de reglas de negocio para el sistema de información de planificación del menú en comedores UCLV. ................................................................ 44 2.1 Caso de Estudio: Planificación del Menú en Comedores UCLV .......................... 44 2.2 Uso de Drools para implementar las reglas de negocio ......................................... 46 2.2.1 Archivo DroolsTest.java ................................................................................. 47 2.2.2 Archivo Sample.drl ......................................................................................... 50 2.2.3 Archivo MenuD.java ...................................................................................... 52 2.2.4 Archivo Plato.java .......................................................................................... 53 2.3 Uso del LPT-SQL para la implementación de las reglas de negocio .................... 54 2.4 Conclusiones Parciales .......................................................................................... 58 Capítulo 3. Comparación entre el motor de reglas Drools y la herramienta LPT-SQL. 61 3.1 Requerimientos del sistema ................................................................................... 61 3.2 Instalación .............................................................................................................. 61 3.3 Uso de modelo de objeto ....................................................................................... 64 3.4 Tipo de reglas......................................................................................................... 64 3.5 Reglas a nivel técnico ............................................................................................ 65 3.6 Repositorio ............................................................................................................. 65 3.7 Rendimiento ........................................................................................................... 67 3.8 Documentación ...................................................................................................... 68. 3.9 Tabla comparativa.................................................................................................. 68 3.10 Conclusiones Parciales ........................................................................................ 70 Conclusiones y Recomendaciones .................................................................................. 71 Referencias...................................................................................................................... 72 Anexos ............................................................................................................................ 75 Anexo 1 ........................................................................................................................ 75.

(10) Lista de Figuras. Lista de Figuras Figura 1.1 Principales componentes de un BRMS (Fernández, 2010) ............................ 19 Figura 1.2 Arquitectura de Drools (Castelo, 2011a) ....................................................... 24 Figura 1.3 Sintaxis de una regla en un fichero .drl ......................................................... 27 Figura 1.4 Arquitectura de la administración de reglas de negocio en bases de datos relacionales (Paz, 2011) .................................................................................................. 29 Figura 1.5 Relación entre clases ..................................................................................... 34 Figura 1.6 Esquema XSD del repositorio de reglas ......................................................... 37 Figura 1.7 Parte del esquema XSD del repositorio de reglas referente a la representación formal de las reglas ............................................................................... 37 Figura 1.8 Parte del esquema XSD del repositorio de generación ................................. 38 Figura 1.9 Fragmento o sección del repositorio de reglas en XML ................................ 39 Figura 1.10 Parte del repositorio de generación en XML ............................................... 39 Figura 1.11 Parte del repositorio de reglas .................................................................... 40 Figura 1.12 Sección de la estructura del repositorio del catálogo ................................. 41 Figura 2.1 Bibliotecas a importar en el proyecto de NetBeans ...................................... 47 Figura 2.2 Inicialización de la memoria de trabajo y asignación del fichero de reglas .. 48 Figura 2.3 Inserción de los pedidos en la memoria de trabajo y ejecución de las reglas49 Figura 2.4 Regla “Verificar cantidad de platos en el menu” ........................................... 50 Figura 2.5 Regla “Menu con solo un potaje” .................................................................. 50 Figura 2.6 “Un menu no puede tener un ave y un pescado” ......................................... 51 Figura 2.7 Regla “Insertar menu” ................................................................................... 52 Figura 2.8 Clase MenuD.java .......................................................................................... 53 Figura 2.9 Clase Plato.java .............................................................................................. 54 Figura 2.10 Ventana principal de la aplicación ............................................................... 55 Figura 2.11 Creación de un repositorio de reglas desde el LPT-SQL .............................. 55 Figura 2.12 Establecer conexión con la base de datos desde el LPT-SQL....................... 56.

(11) Lista de Figuras. Figura 2.13 Escritura de la regla de negocio en lenguaje técnico y natural en el LPT-SQL ........................................................................................................................................ 57 Figura 2.14 Compilación de la reglas de negocio desde el LPT-SQL ............................... 57 Figura 2.15 Generación de la reglas de negocio desde el LPT-SQL ................................ 58 Figura 3.1 Carpeta de la herramienta LPT-SQL ............................................................... 63.

(12) Lista de Tablas. Lista de Tablas Tabla 1.1 Elementos variables de los patrones .............................................................. 33 Tabla 1.2 Operadores de conjunto definidos para el LPT............................................... 36 Tabla 2.1 Archivos de Drools y su respectiva función .................................................... 47 Tabla 2.2 Descripción del método readKnowledgeBase ................................................ 48 Tabla 2.3 Descripción del método verificarMenu .......................................................... 49 Tabla 3.1 Tabla comparativa entre el motor de reglas de inferencia Drools y la herramienta LPT-SQL ...................................................................................................... 69.

(13) Introducción. INTRODUCCIÓN El desarrollo de sistemas de información está necesariamente vinculado a las reglas de negocio. Estas definen el correcto funcionamiento de una organización y constituyen las bases para la toma de decisiones. Generalmente se encuentran descritas en manuales de políticas, que los directivos del negocio deben conocer para desarrollar su gestión cotidiana, y los desarrolladores de sistemas de información, para implementarlas y chequearlas de manera automática. Las reglas de negocio con el transcurso del tiempo suelen cambiar debido al dinamismo empresarial. Este problema provoca que se compren o reprogramen constantemente funcionalidades o módulos enteros para responder a las nuevas y siempre cambiantes necesidades empresariales, aumentando los costes de mantenimiento en gran medida. Según (Fernández and Soto, 2006) los sistemas de gestión flujo de trabajo y de reglas de negocio o BRMS (por sus siglas en inglés Business Rules Management System) son cruciales para resolver dicho problema pues todo proceso de negocio no trivial necesita tomar decisiones complejas. Las herramientas de flujo de trabajo automatizan los procesos de negocio, involucrando tanto actividades manuales como automáticas. Los sistemas de flujo de trabajo son el primer ejemplo de un cambio claro en la orientación de la construcción de sistemas informáticos, pasando de los datos a los procesos provocando la necesidad de rediseñar los procesos de negocio para optimizar el funcionamiento de la organización. Un motor de flujo de trabajo es una herramienta capaz de proporcionar un ambiente en línea para inicializar, ejecutar, secuenciar y controlar instancias de una definición de proceso, administrar las tareas que ejecuta cada participante y llamar aplicaciones externas de ser necesario. En principio, tiene las funciones básicas para supervisar la ejecución de cada proceso y permite llevar un control sobre ellos. A pesar de las ventajas que presentan los motores de reglas, cabe destacar que también ellos presentan una serie de desventajas ya que para su utilización es necesario el uso de máquinas con alto poder de procesamiento, no se justifica su uso en aplicaciones donde 1.

(14) Introducción. las reglas son de carácter técnico y no tienen mayor variación en el tiempo, además cuando la cantidad de reglas es baja, un motor de reglas de negocio es menos eficiente que el uso de un lenguaje procedural (Chisholm, 2004). Es una necesidad creciente en el mundo de la computación de los negocios, que los cambios en las políticas del negocio sean reflejados en sus sistemas de información de manera menos costosa y eficiente, a través de una mayor independencia entre la inserción de las implementaciones de las reglas y los programadores de los sistemas de información, de modo que un cambio en las reglas no implica contratar servicios de mantenimiento de los sistemas (Boggiano Castillo, 2007). Entre los temas de investigación en los que trabaja el laboratorio de Bases de Datos del Centro de Estudios Informáticos es la generación automática de reglas de negocio en bases de datos relacionales. Como resultado de esta investigación se ha obtenido una solución mediante el editor LPT-SQL que permite insertar automáticamente las reglas en la base de datos del negocio, utilizando un repositorio para almacenarlas, un compilador para traducirlas al SQL y un generador de reglas que produce las implementaciones en gestores de bases de datos. Relacionados con esta herramienta se han obtenido los siguientes trabajos: ―Aplicación de Reglas de Negocio‖ (Pérez Alonso, 2008), ―Solución al problema de la cardinalidad en la generación automática de reglas de negocio‖ (Toledo, 2009), ―Información del catálogo para generar reglas de negocio‖(Díaz Fleites, 2010), ―Traductor LPT-SQL para reglas de negocio en bases de datos relacionales‖ (Calderón Solís, 2011), ―Extensión del Traductor LPT-SQL‖ (Pérez Pedraza, 2012) y más reciente ―LPT-SQL v1.3: Herramienta para la generación automática de reglas de negocio en bases de datos relacionales‖ (Méndez, 2013). LPT-SQL recibe como entrada reglas de negocio vistas desde una perspectiva de datos, que se le ha llamado ―cercana a los datos‖ en (Calderón Solís, 2011) y actualmente es nombrada por sus creadores (Laboratorio de Bases de Datos del Centro de Estudios de Informática) como reglas ―desde la perspectiva de datos‖ (Boggiano-Castillo et al., 2011). Para expresar estas reglas de negocio en un nivel de expresión técnico (Morgan, 2002) se ha creado un lenguaje llamado LPT ( Lenguaje de Patrones Técnicos).. 2.

(15) Introducción. Planteamiento del Problema El uso de motores de reglas de negocio es una tendencia actual para el desarrollo de Sistemas de Información garantizando que las reglas sean captadas por los especialistas del negocio, almacenadas en un repositorio e implementadas. automáticamente. independientes de los demás recursos del sistema, haciendo efectivo el enfoque de reglas de negocios. Estos motores obligan a trabajar con reglas del tipo IF…THEN y presentan algunas desventajas en su utilización. La herramienta LPT-SQL permite la implementación automática de un conjunto de reglas de negocio desde la perspectiva de los datos, y se asume que su uso es en determinados casos más ventajoso que los motores de reglas; debido a esto se hace indispensable reconocer las fortalezas que puede tener esta herramienta; por lo tanto se considera útil estudiar más a fondo la manera en que trabajan los motores de reglas y establecer una comparación entre ellas. Por los motivos explicados anteriormente se proponen los siguientes objetivos: Objetivo General Implementar reglas de negocio del sistema de información para el control del menú en comedores UCLV usando el motor de reglas de inferencia Drools, con vistas a reconocer ventajas y desventajas de su utilización en comparación con el uso de la herramienta LPT-SQL. Objetivos Específicos 1. Identificar un conjunto de reglas de negocio usadas actualmente en la planificación del menú en comedores UCLV. 2. Implementar el conjunto de reglas de negocio acerca de la gestión del menú de comedores en el motor de reglas de inferencia Drools para integrarlas a una versión del sistema de información. 3. Comparar el modo de trabajo del motor de reglas de inferencia Drools con respecto a la herramienta LPT-SQL.. 3.

(16) Introducción. Preguntas de Investigación 1. ¿Cómo implementar en el motor de reglas de inferencia Drools un subconjunto de reglas de negocio usadas actualmente en la planificación del menú en comedores UCLV? 2. ¿Cuáles criterios se tienen en cuenta para comparar este motor de reglas con la herramienta LPT-SQL? 3. ¿Cuáles son los resultados de comparar el motor de reglas con la herramienta LPTSQL, en qué casos es más útil LPT-SQL? Justificación de la Investigación Es común trabajar con el enfoque de reglas de negocio como bases en el desarrollo de los sistemas de información y una manera muy popular de implementarlos es usar los llamados motores de reglas. La gran parte de estos motores se basan en la escritura de regla IF…THEN , sin embargo se han estudiado reglas que pueden ser expresadas de manera más directa de otras maneras; según (Morgan, 2002), existen algunos tipos de reglas, nombradas como reglas desde la perspectiva de los datos, que son aquellas reglas directamente asociadas a operaciones sobre los datos. Lo anterior se une a las desventajas que aparecen en la literatura sobre los motores de reglas, y permiten que en este trabajo se pretenda conocer las fortalezas que puede tener la herramienta LPT-SQL mediante un proceso de comparación. Logrando así, demostrar en qué casos puede ser más factible el uso de esta herramienta. Descripción de Capítulos: En el primer capítulo se presentan los referentes teóricos que se consideran relevantes acerca del enfoque de reglas de negocio, se analizan distintas formas de expresión de estas y algunas maneras que se han utilizado para implementarlas. Se efectúa una caracterización de los componentes básicos de un BRMS y las ventajas y desventajas de los mismos. Por último, se realiza un análisis general acerca de las herramientas LPTSQL y Drools. 4.

(17) Introducción. En el segundo capítulo se describe la implementación de las reglas de negocio utilizadas en la versión 1.0 del Sistema de Información para planificar el menú en comedores UCLV en el motor de reglas Drools. Además, se detalla el uso de la herramienta LPT-SQL para la implementación de una de estas reglas. En el tercer capítulo se compara el motor de reglas de inferencia Drools y la herramienta LPT-SQL en función de una serie de aspectos, a manera de resumir las posibilidades y limitaciones de cada una.. 5.

(18) Capítulo 1: CARACTERÍSTICAS GENERALES SOBRE LPT-SQL Y SISTEMAS DE GESTIÓN DE REGLAS DE NEGOCIO.. 6.

(19) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. Capítulo 1. CARACTERÍSTICAS GENERALES SOBRE LPT-SQL Y SISTEMAS DE GESTIÓN DE REGLAS DE NEGOCIO. En este capítulo se presenta un conjunto de consideraciones que aparecen en la literatura especializada sobre el enfoque de reglas de negocio, así como formalismos para expresar las reglas de negocio y algunas maneras para su implementación. Se efectúa una caracterización de los componentes básicos de un BRMS y las ventajas y desventajas de los mismos. Por último, se realiza un análisis de manera general de las herramientas LPT-SQL y Drools, especificando en cada uno de los casos, los aspectos y conceptos fundamentales que servirán como base teórica para la investigación.. 1.1 Enfoque de Reglas de Negocio El enfoque de reglas de negocio o BRA (por sus siglas en inglés Business Rule Approach), se presenta como una forma efectiva de identificar el núcleo de los requerimientos del negocio (Gottesdiener, 1997). Se refiere al mundo real, cuya fuerza impulsora es la práctica de negocios, no la tecnología. Esto provino de la visión de profesionales dedicados con muchos años de la experiencia en los procesos y desafíos del software comercial, que su objetivo era ofrecer a compañías el mejor enfoque posible para el desarrollo de soluciones comerciales que implican sistemas automatizados (BRCommunity.com, 2008). "Las reglas de negocio", literalmente, es lo que se utiliza para hacer funcionar un negocio. En sentido general, las reglas de negocio son las que orientan un negocio en la gestión de las operaciones del día a día. En el mundo de hoy, cada proceso de negocio organizado tiene reglas de negocio. El BRA es un enfoque que permite el manejo de las reglas de negocio independiente de las aplicaciones que las hacen cumplir, el término ha sido utilizado por diferentes autores. Según (Morgan, 2002), plantea que: ―Básicamente, una regla de negocio es una declaración compacta sobre un aspecto del negocio. Es una restricción en el sentido que una regla de negocio decide lo que debe o no debe hacerse en cada caso. En cualquier 7.

(20) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. punto particular, debe ser posible determinar que la condición que implicó la restricción es verdad en un sentido lógico; si no, tomar la acción necesaria.‖ En (SCOTT, 2011), se presenta una regla de negocio como aquello que define o limita un aspecto del negocio con el objeto de establecer una estructura o un grado de influencia que condiciona el comportamiento de los actores del negocio. A menudo las reglas de negocios están focalizadas en el control, en la forma de realizar los cálculos, otras permiten establecer las políticas, y así se tienen en cualquier actividad del negocio, que requiera que la gente actúe de una forma pre-establecida. Según (Ross, 2012), una regla de negocio es una proposición tomada para ser verdad, en otras palabras, un hecho. Los hechos se basan en los conceptos expresados por los términos y los términos expresan conceptos empresariales. Por lo cual las reglas de negocio pertenecen a las poblaciones de los hechos y por tanto a los modelos de hechos. En el estudio de las reglas de negocio se aprecia cómo con el enfoque centrado en datos de Date (DATE, 2000), se defiende la idea de que con las reglas de negocio se asegura que los hechos representados en bases de datos no pueden ser corruptos por actualizaciones que violen las reglas, ya que cuando se realiza una actualización se ejecuta la regla y se chequea, si es violada, la actualización es abortada. El Grupo de Reglas de Negocio o BRG (por sus siglas en inglés Business Rule Group), surge con el propósito de proveer una visión global del enfoque de reglas en el desarrollo de software. Este grupo de trabajo, publica un conjunto de principios que deberían tenerse en cuenta a la hora de trabajar con reglas de negocio, destacando su independencia respecto al resto de elementos que constituyen el modelo del negocio y los modelos tecnológicos en que se apoya dicho modelo de negocio. En el Anexo 1 se incluye la versión en español de este manifiesto, tomada de (Group, 2003). Este manifiesto ayuda a comprender y a tratar adecuadamente las reglas de negocio a la hora de construir sistemas basados en este paradigma. De manera general podemos definir una regla de negocio como ―una directiva, destinada a influenciar o guiar el comportamiento del negocio, que apoya una determinada política de negocio‖ (Group, 2009). 8.

(21) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. 1.2 Formas de expresión de las Reglas de Negocio Los niveles para expresar las reglas son cuatro según (Halle, 2002), cada uno para una audiencia diferente: conversación informal del negocio, versión en lenguaje natural, versión en lenguaje de especificación y versión en lenguaje de implementación. En última instancia las reglas se traducen del lenguaje de especificación al lenguaje de implementación, el cual tiene todo el potencial para ser ejecutado (Heidenreich et al., 2008) (Zimbrão et al., 2003) (Demuth, 2005). Según Morgan (Morgan, 2002) se distinguen tres niveles de expresión de reglas de negocio: informal, con la regla de negocio expresada como sentencia en lenguaje natural, tal y como el cliente del negocio desee; técnico, en que se combina referencias a datos estructurados, operadores y restricciones con el lenguaje natural; y el formal, de implementación, para proporcionar sentencias conforme a una sintaxis definida y proporciona la funcionalidad completa de la regla.. 1.3 Implementación de Reglas de Negocio Según (Morgan, 2002) existen formas muy disímiles de implementar las reglas, incluso pueden existir varias técnicas para implementar una misma regla. Entre ellas se encuentran los motores de reglas y los mecanismos de bases de datos. Drools se clasifica entre los BRMS, cuyo componente principal es un motor de reglas de negocio de inferencia, que utiliza una versión del algoritmo RETE. LPT-SQL permite la generación automática de reglas de negocio, pero a diferencia de Drools, utiliza recursos activos o mecanismos de bases de datos para lograrlo. A continuación se muestran las técnicas utilizadas en cada una de las herramientas:. 1.3.1 Motores de Reglas de Negocio Un motor de reglas de negocio o servidor lógico es un componente diseñado con el único propósito de gestionar reglas, siendo así un sistema que se configura para dar servicio a las necesidades de negocio, a través de la definición de objetos y reglas de negocio. Este no se construye para resolver cualquier problema en particular sino que 9.

(22) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. brinda un conjunto genérico de capacidades para definir, almacenar y aplicar reglas de negocio (Morgan, 2002). Permiten organizar la lógica de negocio de la aplicación, lo que le facilita al usuario definir reglas apoyándose en conocimiento que sabe que va a ser cierto en algún momento, y a partir de aquí, permitir a mecanismos a bajo nivel inferir conclusiones o tomar decisiones (Browne, 2005). Proporcionan, además, una serie de funciones útiles, facilitando el trabajo del desarrollador ya que se rige por flujos que derivan responsabilidades a los distintos cargos de la empresa, repartiendo el trabajo equitativamente y cuantitativamente, así como cuándo, quién y dónde tiene que desempeñar la tarea asignada, proporcionando así una manera conjunta de trabajo para el desarrollo de las aplicaciones. Un motor de reglas de negocio es un componente que, a partir de una información inicial y un conjunto de reglas, detecta qué reglas deben aplicarse en un instante determinado y cuáles son los resultados de esas reglas. Básicamente un motor de reglas de negocio está compuesto de tres elementos: un conjunto de reglas, el espacio de trabajo o conocimiento que tiene y el procesador de reglas. Las reglas son sentencias de la forma IF…THEN, de tal manera que si se cumplen todas las condiciones del IF se ejecutan todas las acciones del THEN. El espacio de trabajo es donde se almacena el conocimiento que el motor utilizará para decidir qué reglas deben activarse. El grado en que se puede decir que un motor de inferencia es una pieza de software que puede ejecutar una regla de negocio que se ha definido en ella, varía según muchos factores, tales como qué tan bien se pueden definir las reglas, la disponibilidad de la información necesaria a las reglas, y la capacidad del software para poner en práctica lo que dicta la norma; proporcionando un aumento de la velocidad de ejecución ya que pueden tomar mucho tiempo para cambiar algunas aplicaciones informáticas. Un motor de reglas proporciona un entorno cómodo, donde pueden compartir un ambiente y un medio de expresión común. También comparten el mecanismo de inferencia, ya sea guiado por datos o por objetivos y puede permitir nuevos negocios y normas que se. 10.

(23) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. aplicarán inmediatamente por lo que aumenta la agilidad de la organización (Chisholm, 2004). Según (Morgan, 2002) las principales funciones de los motores de reglas de negocio típicas son: Características de elasticidad para aumentar la disponibilidad del sistema. Almacenamiento en caché de datos para reducir los tiempos de respuesta. Las características adicionales de seguridad para proteger los sistemas centrales en un entorno global de usuarios. Diversas técnicas, tales como el uso común de recursos, para aumentar la escalabilidad de la aplicación. Conectores listos para interactuar con orígenes de datos específicos. Funciones transaccionales y de bloqueo de registros. 1.3.1.1 Consideraciones para su Aplicación Para la implementación de un motor de reglas a un proyecto de software, es necesario evaluar, si esta tecnología es la apropiada para el alcance del proyecto, y si es justificable el esfuerzo, recursos y tiempo invertidos para lo que realmente se desea desarrollar. Para determinar si el proyecto a desarrollar puede beneficiarse o no de las reglas de negocio, se recomienda tomar en consideración los siguientes puntos (Castelo, 2011b): 1. Las decisiones no sean complejas y el alcance del proyecto implique la toma de un número significativo de decisiones: En este caso se puede considerar el uso de un motor de reglas de negocio. No se justifica cuando las decisiones o reglas son demasiado complejas, debido a que dificulta la escritura de reglas; además si se. 11.

(24) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. proveen pocas condiciones en las decisiones, el esfuerzo de implementar un motor de reglas no se justifica por la simplicidad de estos temas. 2. Variabilidad en las condiciones lógicas del sistema: Si la naturaleza del negocio de las reglas, implica que estas van a cambiar constantemente, se pueden considerar el uso de un motor de reglas; en otro caso, si las reglas o lógica son estáticas y no se provee que cambien o que cambien de una forma regular, no se debe implementar un motor de reglas. 3. ¿El desempeño del sistema de software es un tema crítico para el cliente?: Si se necesita que el software tenga un tiempo de respuesta muy reducido, lo que implique incluso escribir algoritmos optimizados para garantizar dicho tiempo de respuesta, o si por otro lado existe una restricción considerable en cuanta memoria está disponible para el sistema, es posible que un motor de reglas no sea la solución correcta, la implementación de estas tecnologías, debido a la forma en la que estas trabajan, suelen tener un alto consumo de memoria, además, la integración con estos productos involucra pasos adicionales que pueden demorar el tiempo de respuesta de la aplicación. 4. ¿El proyecto tiene los recursos suficientes para cubrir los costos que involucran el implementar un motor de reglas de negocio?: Los costos asociados a la implementación de un motor de reglas son los siguientes: Si el motor de reglas a usar tiene licencia, el costo de la misma. Entrenamiento a desarrolladores y a usuarios finales. Retorno de la inversión, se estima que el retorno de la inversión de implementar un motor de reglas empieza después de un año de desarrollo. Si los costos de implementar un motor de reglas cubren el presupuesto en tiempo y recursos,. y las condiciones anteriores se cumplen, se puede. considerar la implementación de un motor de reglas.. 12.

(25) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. 1.3.1.2 Expresiones de las reglas La mayor diferencia entre los motores de reglas es en la forma en que expresan las reglas, el enfoque principal utiliza un lenguaje especializado, similar a un lenguaje de programación, pero con algunas diferencias como: Las declaraciones de reglas son declarativas y no procedurales, definen. las. relaciones entre los hechos, no la forma de hacer algo. Las reglas de negocio deben ser atómicas, construidas de manera independiente y distinta, expresadas en lenguaje natural y orientado al negocio. No hay un control de flujo predeterminado; las reglas se activan según el estado actual del problema. El lenguaje que se presenta como principal candidato para este tipo de reglas es Prolog. El uso del motor de reglas ya incluye el lenguaje que se usa para expresar las reglas y generalmente una interfaz interactiva para su construcción (Morgan, 2002). 1.3.1.3 Tipos de motores de reglas de negocio Existen dos tipos fundamentales de motores de reglas negocio, el primer tipo es el de los llamados motores de reglas de producción o inferencia. Los cuales representan el conocimiento en reglas con la estructura: Si condición entonces acción o IF…THEN como son comúnmente conocidos. Basan su mecanismo de inferencia en un encadenamiento hacia delante (forward chaining) o hacia atrás (backward chaining), aunque existen motores de producción en la actualidad que implementan ambos mecanismos. El otro tipo de motores son los conocidos motores de reacción, los cuales detectan o reaccionan ante eventos o el proceso de un conjunto de eventos. Basan su mecanismo de inferencia en un encadenamiento hacia adelante. Por ejemplo un motor de reacción puede alertar ante la poca o ninguna existencia de un artículo o producto en venta en un negocio (Taylor and Raden, 2007). 13.

(26) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. La principal diferencia entre los dos tipos de motores es que el motor de reglas de producción se ejecuta cuando es invocado por una aplicación. Por el contrario el motor de reglas de reacción, se ejecuta automáticamente cuando ocurre un evento. Varios motores de reglas comerciales tienen ambas capacidades, producción y reacción, aunque pueden hacer más énfasis en uno de los dos tipos. La mayoría de los motores de reglas de negocio son primariamente motores de producción, especialmente en áreas en que se deben procesar complejos eventos de negocio. Existe otra categoría en el mercado que puede ser considerado motores de reglas, estas aplicaciones aunque no se comercializan como motores de reglas de negocio más bien son dirigidas a responder las necesidades del negocio como es la contabilidad ya que es importante reconocer los flujos de dinero. Estas aplicaciones de contabilidad están diseñadas para integrarse con las bases de datos y publicar la información sobre la actividad financiera; todo esto es posible mediante un enfoque de reglas de negocio (Chisholm, 2004). 1.3.1.4 Despliegue Existen varias opciones de tecnologías para la construcción de motor de reglas dentro de un sistema operacional. La manera más obvia puede ser poner toda la maquinaria de regla en un solo módulo, de modo que todas las partes puedan cooperar eficazmente. En la práctica, este enfoque simplista no funciona muy bien. Por lo que se utilizan una serie de estrategias ingeniosas para abordar estos problemas potenciales. Estas estrategias incluyen tanto la clonación hacia varios servidores como brindar el motor de reglas como un conjunto de funciones pertenecientes a una biblioteca (Morgan, 2002).. 1.3.2 Mecanismos de base de datos. Las reglas centradas en los datos probablemente se adaptarán más naturalmente dentro de la base de datos donde puedan tener un contacto más directo con los datos. La tecnología de base de datos relacional más popular y utilizada es el modelo relacional.. 14.

(27) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. Todos los gestores relacionales permiten el almacenamiento y recuperación de información, y además brindan mecanismos para el control de las características de los datos. En relación con las reglas de negocio, las más utilizadas son las que giran en el entorno básico de CRUD (crear, leer, actualizar y eliminar) (Morgan, 2002). Se asume que el modelo de negocio y la estructura de base de datos tienen una correspondencia razonablemente buena. No siempre sucede así aunque es deseable para mejorar el rendimiento (Morgan, 2002). A continuación se realiza un análisis de las funciones de bases de datos que pueden ser utilizadas para implementar reglas, utilizadas por los programadores de sistemas y bases de datos. 1.3.2.1 Restricciones (Constraints) CHECK Las restricciones CHECK exigen la integridad del dominio mediante la limitación de los valores que puede aceptar una columna. Se puede crear una restricción CHECK con cualquier expresión lógica (booleana) que devuelva TRUE (verdadero) o FALSE (falso) basándose en operadores lógicos (Oppel and Sheldon, 2008). Ventajas La incorporación de las restricciones en la base de datos evitará cualquier acción que incumpla la regla: no sólo cuando el elemento se crea, sino también si se intenta actualizar en el futuro. Es posible aplicar varias restricciones CHECK a una sola columna y a varias columnas si se crean a nivel de la tabla. Así se pueden comprobar varias condiciones en un mismo sitio (MSDN, 2008). Desventajas La principal desventaja de estas restricciones simples es que no se puede utilizar para condiciones más complicadas que implican varios objetos, lo que equivale a varias tablas en un sistema de base de datos relacional.. 15.

(28) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. 1.3.2.2 Procedimientos Almacenados Los procedimientos almacenados pueden facilitar en gran medida la administración de la base de datos y la visualización de información sobre esta y sus usuarios. Son una colección precompilada de instrucciones SQL e instrucciones de control de flujo opcionales, almacenadas bajo un solo nombre y procesadas como una unidad. Estos se guardan en una base de datos, permitiendo ser ejecutados desde una aplicación. Los procedimientos almacenados pueden contener flujo de programas, lógica y consultas a la base de datos; aceptar parámetros y proporcionar sus resultados, devolver conjuntos individuales o múltiples y retornar valores (Perez Alonso, 2010). Ventajas Ejecución de una serie de instrucciones SQL en un único procedimiento almacenado. Referenciar a otros procedimientos almacenados desde el propio procedimiento almacenado, con lo que se puede simplificar una serie de instrucciones complejas. El procedimiento almacenado se compila en el servidor cuando se crea, por tanto, se ejecuta con mayor rapidez que las instrucciones SQL individuales (MSDN, 2008). 1.3.2.3 Desencadenadores Los desencadenadores son una clase especial definida para la ejecución automática al emitirse una instrucción UPDATE, INSERT o DELETE en una tabla o una vista. Son una herramienta eficaz que pueden utilizar para exigir automáticamente el cumplimiento de las reglas cuando se modifican los datos. Amplían la lógica de comprobación de integridad, valores predeterminados y reglas del estándar SQL, aunque se deben utilizar las restricciones y los valores predeterminados siempre que estos aporten toda la funcionalidad necesaria (Melton and Simon, 2002). Ventajas. 16.

(29) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. Los desencadenadores pueden consultar otras tablas e incluir instrucciones SQL complejas. Son especialmente útiles para exigir reglas o requisitos complejos. También son útiles para exigir la integridad referencial, que conserva las relaciones definidas entre tablas (MSDN, 2008). Los desencadenadores se pueden utilizar para aplicar restricciones dentro de una tabla, a través de tablas, a través de bases de datos, e incluso a través de servidores (Morgan, 2002) Desventajas Los factores desencadenantes son más lentos que otros enfoques como las restricciones simples. También es necesario tener en cuenta el costo de la energía intelectual requerida. 1.3.2.4 Vistas Una vista es una tabla virtual cuyo contenido está definido por una consulta. Al igual que una tabla real, una vista consta de un conjunto de columnas y filas de datos con un nombre. Suelen utilizarse para centrar, simplificar y personalizar la percepción de la base de datos para cada usuario (Melton and Simon, 2002). Ventajas Las vistas se pueden utilizar para realizar particiones de datos y para mejorar el rendimiento cuando estos se copian. Permiten a los usuarios centrarse en datos de su interés y en tareas específicas de las que son responsables. Los datos innecesarios pueden quedar fuera de la vista. Brindan mayor seguridad, dado que los usuarios solo pueden ver los datos definidos en la vista y no los que hay en la tabla subyacente (MSDN, 2008).. 1.4 Sistema de Gestión de Reglas de Negocio Un sistema de administración de reglas de negocio es una herramienta de software utilizado para definir, implementar, ejecutar, monitorear y mantener la variedad y complejidad de la lógica de la decisión que se utiliza en los sistemas operacionales. 17.

(30) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. dentro de una organización o empresa. Esta lógica, que también se conoce como reglas de negocio, incluye las políticas, requisitos e instrucciones condicionales que se utilizan para determinar las acciones tácticas que tienen lugar en las aplicaciones y sistemas. Al separar las reglas de negocio y proporcionar herramientas para su gestión, un BRMS permite a los expertos de negocio definir y mantener las decisiones que orientan el comportamiento de los sistemas, lo que reduce la cantidad de tiempo y esfuerzos necesarios para actualizar los sistemas de producción y el aumento de la capacidad de la organización para responder a los cambios en el entorno empresarial (Graham, 2007). Un BRMS es útil en los siguientes escenarios (Red Hat, 2010): Se necesita administrar un sistema para implementación y modificación de reglas. Múltiples usuarios con diferentes niveles de habilidad necesitan acceder y modificar las reglas. No existe una infraestructura para administrar las reglas. Hay muchas reglas "empresariales" que se deben administrar de manera independiente a las reglas técnicas que serán parte de una aplicación. Los analistas empresariales, expertos en reglas, desarrolladores y administradores de reglas son las personas que principalmente utilizarán el BRMS en su empresa (Red Hat, 2010).. 1.4.1 Componentes Básicos de un BRMS En la ¡Error! No se encuentra el origen de la referencia. se muestra la arquitectura y os principales componentes de un BRMS:. 18.

(31) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. Figura 1.1 Principales componentes de un BRMS (Fernández, 2010). Repositorio de reglas Lugar centralizado donde todas las reglas de negocio son guardadas separadas de la lógica de la aplicación, creando una plataforma de fácil migración y transferencia durante los múltiples desarrollos de sistemas. El repositorio de reglas crea la posibilidad de almacenar diferentes versiones de definición de reglas y guardar la historia de los cambios soportando el control de versiones de las reglas. Motor de reglas El motor de reglas de inferencia es el componente principal del BRMS, 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 que permiten inferir nuevos hechos. La elección del motor adecuado debe basarse en casos de uso que permitan seleccionar la mejor opción, sin limitarse a una simple comprobación de si el motor cumple o no ciertos requisitos técnicos. Herramientas de Gestión 19.

(32) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. Las herramientas de gestión, permiten a diseñadores, técnicos y a expertos de negocio, definir y manejar la lógica de decisión de la organización, a través de un conjunto de herramientas para la definición, administración, despliegue, modificación o eliminación de reglas de negocio. Por lo general es una aplicación Web que brinda una interfaz de usuario que puede ser utilizada para el trabajo con reglas de negocio por personas que no estén familiarizadas con ambientes de desarrollo integrados o IDEs (por sus siglas en inglés Integrated Development Environment) (Group, 2003).. 1.4.2 Ventajas y Desventajas Los BRMS permiten a las aplicaciones basadas en Reglas: Capturar definiciones y reglas que están sujetos a cambios frecuentes. Implementar esos cambios de manera rápida y fácil dentro de una aplicación. Gestionar y escribir reglas en un lenguaje de negocio familiar. Los usuarios expertos pueden actualizar la funcionalidad de acuerdo a sus políticas. Los cambios requeridos por los usuarios pueden ser implementados sin cambios en el código, aislando el cambio y probando sólo la regla que ha sido modificada. El costo de mantenimiento se reduce al no tener que recodificar, reprobar, recompilar y reinstalar el aplicativo por cada cambio menor. Algunas desventajas de los BRMS: Se necesita gran experiencia en la materia requerida para productos de proveedores específicos. Además del análisis orientado a objetos y prácticas de diseño, los desarrolladores técnicos deben saber cómo escribir reglas e integrar el software con los sistemas existentes. Ciclo de desarrollo de largo plazo debido a regir la recolección, integración con los sistemas existentes, las restricciones de seguridad, la migración, el seguimiento de regla y edición de éstas. 20.

(33) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. La reducción del departamento de tecnología informática no es posible debido a la continua introducción de nuevas consideraciones de reglas de negocio o perturbaciones del modelo de objetos. El acoplamiento de una aplicación de proveedor de BRMS para la aplicación empresarial puede ser demasiado estrecho para sustituirlo por otro proveedor de aplicaciones BRMS. Esto puede llevar a problemas de costo con respecto a los beneficios. El lenguaje de reglas de Drools no permite definir reglas complejas, solo permite gestionar reglas sencillas (Bali, 2009). El uso exclusivo del motor para trabajar con reglas de negocio, asume la posición de que sólo las reglas del motor de reglas son las adecuadas y todas las demás pueden ser ignoradas, u obliga a todas las reglas a implementarse en el motor de inferencia. Esto sería un gran error (Morgan, 2002), pues algunas reglas se pueden implementar de manera más simple o mejor fuera de este. El movimiento de grandes volúmenes de datos hacia y desde la base de datos y el cálculo que hace la aplicación de software hace bajo el rendimiento (Gudla and Sachan, 2012).. 1.5 Jboss Rules (Drools) Dentro de los sistemas de gestión de reglas de negocio en Java más populares hoy en día se encuentra Drools. Drools es un BRMS de JBoss con un motor de reglas basado en una adaptación orientada a objetos del algoritmo Rete. Permite expresar de una forma más natural las reglas de negocio interactuando con los objetos de negocio. Provee separación de lógica (reglas) y datos (hechos). Es software libre distribuido según los términos de la licencia Apache. Drools soporta el estándar JSR-94 para su motor de reglas de negocio y framework de empresa para construcción, mantenimiento y refuerzo de políticas de empresa en una organización, aplicación o servicio. Drools usa JCR (JackRabbit) para gestionar el repositorio de reglas, y el estándar JAAS para la autorización y autenticación. También existe un plug-in de Eclipse para facilitar el desarrollo con esta herramienta. 21.

(34) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. 1.5.1 Arquitectura Drools a lo largo de los últimos años se nos ha presentado en varias versiones debido a que se le han ido añadiendo nuevas funcionalidades en cada una de sus versiones. La versión 1.0 empezó con una búsqueda de fuerza bruta lineal, mientras que la versión 2 se basa en el algoritmo Rete el cual mejora el rendimiento de Drools y en un principio las reglas fueron escritas en XML (Bali, 2009). La versión 3 de Drools consistía básicamente en un motor de reglas usando una implementación del algoritmo RETE e introduce el nuevo formato .drl para escribir reglas, la versión 4 comienza la transformación para convertirse en lo que es en la actualidad aunque inicialmente estaba orientado solamente a reglas de negocio. En la versión 5 actual se convierte en un completo BRMS donde. introduce la. plataforma de integración de lógica de negocio que unifica e integra las reglas, flujo de trabajo y procesamiento de evento. La cual presenta una arquitectura modular formada por 5 componentes integrados, aunque cada uno puede ser utilizado por sí solo (Abrahantes, 2013): Guvnor Cuenta con un repositorio centralizado para las bases de conocimiento, con una web rica basada en GUI, editores y herramientas para ayudar en la administración de números grandes de reglas. El repositorio permite mantener un control de versiones de reglas, modelos, funciones de los procesos que se relacionan con estas bases de conocimiento. El acceso se controla y es posible cerrar con llave y restringir los expertos del dominio evitando el acceso a personal no autorizado. Expert: es el motor de reglas de Drools, este es un declarativo, basado en reglas y tiene ambiente de codificación. Esto le permite enfocarse en lo que usted ―quiere hacer‖ y no en el ―cómo hacerlo‖. Flow (jBPM 5): proporciona las capacidades flujo de trabajo a la plataforma Drools. Un proceso comercial o flujo de trabajo describe el orden en que una serie de pasos necesitan ser ejecutados, usando una gráfica de flujo. Esto hace mucho más fácil el 22.

(35) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. describir una composición compleja de varias tareas. Los procesos son especialmente útiles describiendo los procesos largos. Drools Flow le permite a los usuarios finales especificar, ejecutar y supervisar su lógica de negocio. Fusion: este módulo le agrega a la plataforma Drools la capacidad de procesamiento complejo de eventos y razonamiento temporal. Planner: perfecciona el uso de los recursos del negocio. Cada organización enfrenta los problemas de la planificación y este proporciona un juego limitado de recursos y servicios (los empleados, recursos, tiempo y dinero) y ayuda a resolver los problemas de la planificación eficazmente, combinando heurísticas de optimización y metaheurísticas para resolver de forma eficaz cualquier problema NP-completo. Solo los módulos Expert y Guvnor pertenecen a la categoría de componentes de un BRMS. El módulo Expert es el motor de reglas de un BRMS, mientras Guvnor es el componente de repositorio de reglas. Los restantes módulos, Flow, Fusion y Planner, hacen de Drools además de un BRMS una plataforma de integración de lógica de negocio. Drools 5 posee también un módulo de aplicación llamado drools-server.war el cual necesita ser ejecutado por un servidor de aplicaciones. Drools Server utiliza múltiples agentes del conocimiento que permite escalar de manera transparente a las aplicaciones, además de tener varios servidores que pueden albergar diferentes sesiones con diferentes cargas, en vez de tener una gran cantidad de sesiones dentro de la misma aplicación. Su configuración se proporciona durante el arranque de los archivos de propiedades, tras el arranque el servidor espera peticiones de los clientes. Cuando se recibe una solicitud, se crea la sesión StatelessKnowledgeSession de ejecución de la regla, después de crear esta sesión se establecen las variables globales, se insertan hechos y se ejecuta las reglas. Cuando las reglas terminan los resultados son enviados al cliente. El servidor puede comunicar con el cliente utilizando formatos XML o JSON. Drools Server necesita ser desplegado en un servidor de aplicaciones y se puede llamar mediante REST y SOAP (Bali, 2009). Drools 5 ofrece un entorno de desarrollo que permite: 23.

(36) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. Definir visualmente las reglas (.drl). Crear DSLs (nuevo lenguaje de reglas) enfocado al negocio concreto: soportando esta sintaxis con autocompletado. Definición de Flujos de forma visual. Depuración de las reglas. Testing de Reglas. Uso de Tablas de decisión. Editor guiado de reglas. En la Figura 1.2 se muestra la arquitectura de Drools, donde el principal elemento es el motor de inferencias el cual evalúa reglas de negocio dados unos datos (hechos) para inferir conclusiones que se reflejan en las acciones a tomar. El proceso de evaluación de hechos vs reglas se denomina ―Pattern Matching‖.. Figura 1.2 Arquitectura de Drools (Castelo, 2011a). Memoria de Producción (Production Memory): representa el espacio donde son almacenadas las reglas. 24.

(37) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. Memoria de Trabajo (Working Memory): representa el espacio donde la evaluación de reglas toma lugar. Allí se realizan aserciones sobre los hechos de forma que son modificados o retirados. Puede verse como una sesión sobre la cual se lanza la evaluación de reglas sobre los objetos java (hechos). Activación: Objeto que se crea cuando los hechos satisfacen las condiciones de una regla. Agenda: Componente que administra la ejecución ordenada de activaciones creadas a partir de la misma aserción sobre mismos hechos mediante una estrategia de solución de conflictos. Hechos (Facts): Datos que se utilizan para evaluar las reglas. Pueden verse como clases java (beans) sobre los cuales se van a aplicar reglas. Cualquier atributo que vaya a ser consultado o modificado por una regla debe tener su respectivo método getter y setter. Deben ser insertados al working memory antes de lanzar (fire) las reglas. Luego de insertados los hechos a la memoria de trabajo, se llama al método fireAllRules() que se encarga de revisar las condiciones sobre los objetos y de ejecutar las acciones correspondientes. Por otro lado la creación de la memoria de trabajo, la inserción de los hechos y el llamado al método de fireAllRules si se hacen desde la aplicación java.. 1.5.2 Lenguajes de Definición de Reglas de Negocios Drools presenta diversas formas para transcribir las reglas: en XML o en lenguajes de definición de dominio propios de Drools (drl y dsl). En las primeras versiones de Drools sólo se podían escribir las reglas en XML (Extensible Markup Language), pero era bastante complicado y dificultaba la evolución del lenguaje de reglas por incompatibilidades entre diferentes versiones. Como evolución se introdujo el lenguaje de reglas de Drools (DRL) con el objetivo de especificar las condiciones, acciones y funciones de las mismas, las cuales se puede expresar con distintos lenguajes, como Java y MVEL, guardándose las reglas en archivos de texto con la extensión .drl.. 25.

(38) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. Con Drools también podemos definir un DSL, que es el lenguaje coloquial del usuario para definir el comportamiento de su sistema de acuerdo al negocio, permitiendo que el usuario pueda modificar su sistema de acuerdo a las necesidades de su negocio, sin demasiada intervención del departamento de desarrollo ni teniendo que lidiar con abstracciones e interfaces. Archivo .dsl Drools permite la traducción de reglas de negocio escritas en lenguaje específico de dominio, a reglas de negocio técnicas que el motor puede interpretar, mediante el uso de componentes llamados Expanders. El concepto es el siguiente (Browne, 2009): Construir un archivo de reglas usando el formato IF…THEN, especificando las condiciones con lenguaje natural específico del dominio del experto, esta vez la escritura de reglas será almacenada en un archivo con extensión dslr. Se crea un archivo llamado expander, con extensión dsl, que contiene la forma en que las diferentes condiciones escritas en lenguaje natural, se traducen a lenguaje técnico de reglas. En el archivo dslr en que se definieron las reglas en lenguaje natural, se crea una anotación indicando el archivo expander que será usado para la traducción. Usando el archivo DSL, Jboss rules encuentra el texto escrito en lenguaje natural y lo reemplaza con el lenguaje técnico de definición de reglas. Una vez el proceso de reemplazo está completo, se obtiene un archivo de reglas técnicas almacenado en memoria, que puede ser interpretado por el motor de reglas. Archivo .drl Un archivo DRL (a menudo con la extensión .drl) es el archivo donde Drools almacena sus reglas, casi de la misma manera que un archivo con la extensión .doc es un archivo de Word, y un archivo con la extensión .xls es un archivo de Excel. Un archivo DRL es simplemente un archivo de texto que puede ser abierto en el Bloc de notas, o con uno de los editores de texto, como el IDE de JBoss (Browne, 2009). La estructura de una regla 26.

(39) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. dentro de este archivo se muestra en la Figura 1.3 donde <name> es el nombre de la regla, <attribute> son los posibles atributos que puede tener la misma los cuales pueden ser no-loop, lock-on-active, salience, agenda-group, auto-focus, ruleflow-group, entre otros; <conditional element> es la sentencia condicional a evaluar por la regla, si se cumple esta sentencia se pasa a realizar una o varias acciones (<conditional element>).. Figura 1.3 Sintaxis de una regla en un fichero .drl. 1.5.3 Caracterización de las principales bibliotecas Para el trabajo con Drools es necesario un conjunto de bibliotecas conocidas como drools-runtime, de ellas las principales son (Bali, 2009): knowledge-api.jar: Esta librería proporciona las interfaces y las fábricas. También ayuda a entender claramente lo que se pretende como una API (siglas de la expresión inglesa Application Programming Interface, interfaz de programación) de usuario y lo que es justo una API del motor. knowledge-internal-api.jar: Proporciona las interfaces internas y las fábricas. drools-core.jar: Este es el núcleo del motor, el componente del runtime. Contiene tanto el motor RETE como el motor LEAPS (saltos). Esta es la única dependencia de tiempo de ejecución necesaria si se está pre-compilando las reglas (o si se está implementando a través de paquetes u objetos de tipo RuleBase). drools-compiler.jar: Contiene los componentes del compilador/constructor para tener la regla fuente, y construir los ejecutables de las reglas bases. Es a menudo una dependencia de tiempo de ejecución de la aplicación, pero no necesariamente si se están pre-compilando las reglas. Esta librería depende del drools-core.jar. 27.

(40) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. drools-jsr94.jar: Este es el JSR-94, nombre de la interfaz Java para la estandarización del acceso a motores de reglas a través de lenguajes de programación compatible con la aplicación, es esencialmente una capa sobre el componente drools-compiler. Debido a la naturaleza de la especificación JSR-94, no todas las funciones son fácilmente expuestas a través de esta interfaz. En algunos casos, será más fácil ir directamente a la API del Drools, pero en algunos ambientes la JSR-94 tiene el mandato. drools-decisiontables.jar: Es el componente compilador de las tablas de decisión, que utiliza el componente drools-compiler. Esta librería es compatible con los formatos de entrada de Excel y CSV.. 1.6 La herramienta de Software: LPT-SQL La herramienta de software denominada, LPT-SQL, constituye un traductor de reglas de negocio que permite generar automáticamente la implementación de reglas o políticas del negocio especificada en lenguaje LPT. Estas reglas son traducidas como recursos de base de datos activas basados en código SQL. Se utilizan los disparadores como recursos del SQL para implementar las reglas del negocio. Todas las funcionalidades son a través de un repositorio de reglas descrito en un documento XML (Boggiano-Castillo et al., 2011), teniendo que existir dicho repositorio.. 1.6.1 Arquitectura La arquitectura de la herramienta LPT-SQL propuesta en (Boggiano et al., 2012) para la administración de reglas de negocio en bases de datos relacionales es la que se propone en la Figura 1.4:. 28.

(41) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. Figura 1.4 Arquitectura de la administración de reglas de negocio en bases de datos relacionales (Paz, 2011). Los componentes de la arquitectura son los siguientes: Repositorios.  Repositorio de reglas de negocio: Conformado por dos secciones, el repositorio primario de reglas que contiene cada regla en sus tres niveles: natural, técnico y formal. La segunda sección, que contiene las reglas compiladas que se deben generar y almacena la consulta base para la generación de la regla.  Repositorio del catálogo: Contiene información sobre las tablas de las bases de datos del negocio, información sobre los nombres, atributos, interrelaciones, recursos activos, funciones, procedimientos almacenados y funciones. También almacena información sobre las tablas auxiliares para el control de la modificación. Base de datos relacional del negocio: Se distinguen tres grupos de componentes:. 29.

(42) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio..  Tablas principales y sus atributos:. Estos han sido nombrados con los términos. adecuados del negocio en cada caso.  Recursos activos: Los Disparadores, funciones, procedimientos almacenados, muchos de los cuales constituyen implementaciones de reglas de negocios de las categorías con perspectiva de los datos.  Tablas de apoyo al control de versiones: Son tablas que registran con cuáles reglas se inserta cada dato. Editor de reglas de negocio: Es un módulo que ha de permitir editar las reglas en lenguaje natural estructurado de patrones y lenguaje LPT, reconociendo los datos de los nombres de tablas y atributos. Administrador de reglas: Es el núcleo de esta arquitectura, está compuesto por :  Módulo extractor desde el catálogo: Extrae el catálogo de la base de datos y conforma el repositorio del catálogo.  Traductor LPT-SQL: Con los datos almacenados en el repositorio primario de reglas, traduce las reglas de LPT a consulta base para la regla y las almacena en el repositorio de generación.  Generador de reglas: A partir de la información guardada en el repositorio de. generación que constituye el núcleo de la regla en el lenguaje formal SQL produce los recursos correspondientes a la implementación de la regla y los recursos (disparadores) que implementa las listas de eventos.. 1.6.2 Reglas desde una Perspectiva de Datos Este conjunto de reglas es el fundamento de la investigación ―Generación automática de reglas de negocio en bases de datos relacionales‖. y por consecuente del presente. trabajo, tiene como antecedentes ―Reglas de Negocio en Bases de Datos Relacionales‖ (Pérez Alonso, 2010) que toma como base la clasificación de reglas de negocio de (Morgan, 2002) y más recientemente (Calderón Solís, 2011). Esta clasificación agrupa aquellas reglas que están involucradas en las operaciones sobre la base de datos del negocio las cuales presentan las siguientes características en forma de patrones de reglas. Patrón de Restricción 30.

(43) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. Establece requisitos del negocio que deben ser cumplidos, preservando la integridad. Ejemplo: RN#1: Un estudiante no puede tener una edad > 35 Patrón de Clasificación Organiza el conocimiento básico del negocio contribuyendo claramente al significado de conceptos, centrándose en la esencia del mismo (Ross, 2010). Ejemplo: RN#2: Un estudiante con promedio menor que 3 es definido como desaprobado Patrón de Cómputo Su objetivo es calcular un valor determinado en el negocio, y su resultado es numérico. Este patrón comparte grandes semejanzas con el patrón de clasificación (Ross, 2010). Ejemplo: RN#3: El promedio de un estudiante es calculado como el promedio de las notas de todas sus asignaturas. Patrón de Notificación La finalidad de este patrón es tan sencilla como útil; consiste en informar a los usuarios autorizados del negocio sobre algún conocimiento básico en tiempo real (Pérez Alonso, 2010). Ejemplo: RN#4: Notificar “Equipo incompleto” si existe un equipo que no tiene el mínimo de integrantes. 1.6.2.1 Descripción de los Patrones de Reglas A continuación se describen el formato de los patrones de reglas con perspectiva de los datos. Los elementos variables que conforman este patrón se describen más adelante en la Tabla 1.1. Restricción <determinante> <sujeto> no puede tener <características> 31.

(44) Capítulo 1. Características generales sobre LPT-SQL y sistemas de gestión de reglas de negocio.. <determinante> <sujeto> puede tener <características> solo si <hechos>. Cómputo <determinante><resultado> es calculado como <algoritmo> <determinante><resultado> en <sujeto> es calculado como <algoritmo> <determinante><resultado> en <sujeto>. para <atributo> es calculado como. <algoritmo> Clasificación <determinante> <sujeto> es definido como <clasificación> si<característica> <determinante><sujeto> no es definido como <clasificación> a menos que <característica> Notificación Notificar <mensaje> si <hecho> Elemento. Significado. <determinante> Es el determinante para cada sujeto, por ejemplo: Una, Uno, El, La, Cada, Todos. Según el mejor sentido en la redacción. <sujeto>. Es una entidad en la base de datos del negocio o una clasificación de la misma.. <hecho>. Hechos relativos al estado o comportamiento de la base de datos del negocio, incluyendo o no al sujeto.. <característica> Describe las características del sujeto en el negocio, tanto internas como relacionadas con otras entidades. Pueden incluir hechos con el fin de caracterizar al sujeto. <resultado>. Cualquier valor, no necesariamente numérico, que tiene algún significado en el negocio. El resultado es usualmente el valor del atributo de un objeto del negocio.. <algoritmo>. Definición de una expresión matemática para obtener el valor de un resultado; normalmente expresada utilizando combinaciones de términos del negocio junto a constantes disponibles.. <clasificación>. Definición de un término del negocio. Típicamente define el valor 32.