Estudio sobre editores de reglas de negocio

Texto completo

(1)Universidad Central Marta Abreu de Las Villas Facultad Matemática, Física y Computación Licenciatura en Ciencias de la Computación. Título: “Estudio sobre editores de Reglas de Negocio” Autor: Ariel Cabezas Rodríguez Tutor: Msc. María Elena Martínez del Busto. Laboratorio de Centro de Estudios de Informática 2010. 1.

(2) Agradecimientos. A mis padres, por confiar en mí y enseñarme a ser el hombre que soy hoy. A mi madre, por su eterna dedicación y confianza, a mi padre por educarme con su ejemplo. A mi hermano, que siempre ser un modelo para mí, a su esfuerzo y dedicación. A mis amigos, por apoyarme siempre, por estas ahí cuando los he necesitado. A mi novia, por hacerme el hombre más feliz de la tierra, la única mujer que se ha ganado mi amor, por ser tan paciente y comprensiva. Por amarme tanto. A mi tutora y profesores por saber inculcarme día a día la virtud de la perseverancia y por hacerme comprender que la educación es la contrapuesta de la necedad y el más preciado don que un hombre puede recibir. En fin a toda mi familia que de una forma u otra hizo posible que este sueño se haya hecho realidad.. 2.

(3) Pensamiento. "No busques ser alguien de éxito sino busca ser alguien valioso: lo demás llegará naturalmente.". 3. Albert Einstein.

(4) Resumen. En los últimos años se han realizado estudios sobre el enfoque de reglas de negocio y el desarrollo de herramientas para su edición. En el presente trabajo se realiza un estudio de los Sistemas de Administración de Reglas de Negocio (BRMS) que se encuentran en el mercado. Dentro de este estudio se analizaran las principales características de estos software, enfocándose en los mecanismos de edición con el objetivo de identificar estándares o características deseables en este tipo de herramienta. Se analizaran además las facilidades que brinda el editor UCRules, creado por el grupo de investigación de Bases de Datos, dirigido a facilitar la interacción. con el especialista del negocio mediante el uso de patrones para una. clasificación semántica de las reglas.. 4.

(5) Abstract. 5.

(6) Índice. Tabla de Contenido Introducción ..................................................................................................................... 8 Capítulo 1. “Enfoque de Reglas de Negocios” .............................................................. 10 1.1 Reglas de Negocios............................................................................................. 10 1.1.1 Propiedades .................................................................................................. 11 1.2 Problemas que presentan en el tratamiento de las reglas de negocio ................ 12 1.3 Implementación de Reglas de Negocio ............................................................... 13 1.3.1 Métodos Modernos de Implementación ........................................................ 14 1.3.1.1 Herramientas independientes de bases de datos ................................... 15 1.3.1.2 Herramientas basadas en servidores ..................................................... 16 1.3.1.3 Sistemas basados en reglas................................................................... 16 1.4 Sistemas Administradores de Reglas de Negocio (BRMS) ................................. 18 1.4.1 Metodología de los Sistemas Administradores de Reglas de Negocio ......... 19 Capítulo 2. “Comparación entre los distintos Sistemas Administradores de Reglas de Negocio” ........................................................................................................................ 22 2.1 Biz Talk Server ................................................................................................... 22 2.1.1 Business Rule Engine(BRE) ......................................................................... 22 2.1.2 Business Rule Composer .............................................................................. 23 2.1.3 Definir el vocabulario ..................................................................................... 24 2.1.4 Definir la política y reglas .............................................................................. 26 2.1.5 Definir la lógica de la regla de negocio ......................................................... 28 2.1.6 Probando y Desplegando de Reglas de Negocio en BTS ............................. 29 2.1.7 Arquitectura de Reglas de Negocio en BTS .................................................. 30 2.2 OpenRules ........................................................................................................... 30 2.2.1 EXCEL como editor de Reglas de Negocio................................................... 31 2.2.2 Categorías de Reglas de Negocio en OpenRules......................................... 32 2.3 Drools .................................................................................................................. 34 2.3.1 Principales características del Drools ........................................................... 35 6.

(7) Índice. 2.3.2 Drools Guvnor ............................................................................................... 35 2.4 ILOG JRules ........................................................................................................ 38 2.5 Conclusiones parciales ........................................................................................ 40 Capítulo 3. “UCRules, editor de reglas de negocio” ...................................................... 42 3.1 Arquitectura del Editor ......................................................................................... 42 3.1.1 Repositorio de reglas de negocio .................................................................. 43 3.1.2 Uso de patrones para la edición de reglas .................................................... 44 3.2 Editor de reglas de negocio, primera versión ...................................................... 44 3.2.1 Patrón de reglas utilizados para la herramienta ............................................ 45 3.2.2 Descripción de la herramienta....................................................................... 45 3.3 Editor de reglas de negocio, segunda versión ..................................................... 47 3.3.1 Modelo de hechos ......................................................................................... 47 3.3.2 Reglas de negocio y el modelo de hechos .................................................... 49 3.3.3 Casos de Uso................................................................................................ 51 3.3.4 Uso de patrones semánticos ......................................................................... 52 3.3.5 Repositorio de reglas utilizando un documento XML .................................... 54 3.3.6 Descripción de la herramienta, segunda versión .......................................... 56 3.3.7 Detalles de la implementación ...................................................................... 57 Conclusiones ................................................................................................................. 59 Recomendaciones......................................................................................................... 60 Referencias Bibliográficas ............................................................................................. 61. 7.

(8) Introducción. Introducción La constante variabilidad que sufre los Sistemas de Información afectan no solo al negocio, sino a las aplicaciones que lo conforman, por eso surge la necesidad de cambio, adaptabilidad y extensión de las aplicaciones para poner en función las nuevas condiciones. Para cubrir la necesidad existente en el Sistema de Información de Trasplante Renal, impulso la idea de crear un Sistema de Administración de Reglas de Negocio especifico para este dominio, que cumpla con estándares actuales de este tipo de software. En una primera etapa se implementará un Editor de Reglas, el cual permitirá a los usuarios, que son los expertos del negocio, introducir y probar las reglas que controlaran el Sistema de Información. Justificación de la Investigación Tanto investigadores como ejecutores, están convencidos de que las RN demandan un tratamiento especial durante el Desarrollo de Sistemas de Información (Petrounias and Loucopoulos 1994; Ross 1997; Youdeowei 1997; Date 2000; Bajec and Krisper 2005). Sin embargo se presentan muchos problemas para identificarlas y modelarlas. Problema de la Investigación Al implementar una herramienta que permita editar reglas de negocio en un lenguaje cercano al natural se deben considerar criterios sobre otras herramientas que realizan esta función de forma general o parcial. Hipótesis de la Investigación Se pueden identificar características deseables, ya implementadas en otros sistemas para el procesamiento de reglas de negocio, para valorar la posibilidad de implementarlas en la herramienta para la edición creada por el grupo de investigación de bases de datos. Preguntas de la Investigación ¿Se pueden estudiar varios software para el procesamiento de reglas de negocio e identificar sus características en cuanto a la edición de las reglas? 8.

(9) Introducción. ¿Son estas características implementables en la herramienta para la edición de reglas creadas en el grupo de investigación? ¿Cuáles de las características deseables en una herramienta para la edición de reglas posee UCRules? Objetivo general Realizar un estudio comparativo sobre diferentes herramientas para el procesamiento de reglas de negocio y UCRules, creado en el grupo de trabajo de bases de datos, de acuerdo a determinadas características deseables en este tipo de software. Objetivos específicos 1. Identificar entre los software disponibles en el mercado aquellos que pueden y merecen ser estudiados para tomarse como patrón de referencia en esta investigación. 2. Realizar un análisis comparativo entre las herramientas seleccionadas para el estudio, según los intereses de la investigación con relación a la edición de reglas de negocio, 3. Documentar la herramienta UCRules, para la edición de reglas de negocio creada por el grupo de investigación de bases de datos.. 9.

(10) Capítulo 1. Capítulo 1. “Enfoque de Reglas de Negocios” Tras el surgimiento del término “Reglas de Negocio”(Appelton 1984), profesionales de negocios y de sistemas comenzaron a valorar la posibilidad de captarlas en máquinas de procesamiento que pueden hacerlas cumplir y asegurar que los procesos de negocio sean controlados y conducidos de acuerdo a estándares, políticas y procedimientos del negocio(Struck 1999). En la actualidad se llevan a cabo muchos proyectos de investigación que tratan el tema de las Reglas de Negocio (RN), su clasificación, análisis, formulación, articulación y documentación. Los Sistemas de Administración de Reglas de Negocios son software utilizados para definir, ejecutar y monitorear las reglas de negocios. Estos incluyen los repositorios de reglas, así como los motores de reglas y otras herramientas, dentro de las que se encuentran los editores de reglas. Estos sistemas constituyen las principales herramientas para la implementación moderna de las RN en los Sistemas de Información (SI).. 1.1 Reglas de Negocios En muchas ocasiones el término RN se utiliza o interpreta incorrectamente, lo que propicia el surgimiento de determinados conceptos que se convierten en la base para la comprensión, definición y aplicación de nuevos enfoques. Según diferentes autores las RN son definidas como: •. “Una RN pueden considerarse la declaración compacta sobre un aspecto del negocio, usando un lenguaje simple, inequívoco, accesible a todas las partes interesadas: el dueño del negocio, el analista, el arquitecto técnico, desarrolladores, etc.”(Morgan 2002).. •. “Las RN responden a necesidades de una aplicación; considerando que estos modelos reaccionan a eventos que ocurren en el mundo real con un lado tangible de efecto sobre el contenido de la BD, así encapsulan el comportamiento reactivo de las aplicaciones ante cada evento”(Date 2000). 10.

(11) Capítulo 1 •. “Las RN son consideradas directivas que pretenden guiar o influir en el comportamiento del negocio” (BRG 2000; BRG 2001).. •. “Las RN no son más que sentencias explícitas que estipulan una condición que debe hallarse en el ambiente del negocio, con el propósito de extraer información desde el propio ambiente, correspondiéndose con la actividad económica de la organización, y siendo además consistente con las políticas del negocio” (Bajec 2000).. Al considerar estos criterios se puede dar una definición de RN más completa y formal, al decir que (Ross 2008): •. Es una sentencia que define o restringe algunos aspectos del negocio.. •. Establece restricciones a la estructura del negocio, controlando o influyendo en el comportamiento del mismo.. •. No podrán ser fraccionadas o descompuestas en RN más detalladas.. •. En caso de ser reducidas perderían información importante sobre el negocio.. 1.1.1 Propiedades Tomando estas definiciones podemos. afirmar que las RN son los elementos. individuales o atómicos que permiten ser definidos, delimitados y expresados de forma inteligible y que en su conjunto componen el marco estructural, la política, la estrategia y la operatividad de una empresa u organización. Sin embargo, el término queda reservado únicamente para aquellas que revisten un carácter explícito, y son expresadas de manera entendible, registradas, localizables y modificables. Se entiende que las RN son aquellas que cumplen las siguientes propiedades (BRG 2000; Morgan 2002; Ross 2005): •. Atómicas: no pueden ser descompuestas sin que pierdan información.. •. No ambiguas: tienen una interpretación precisa, obvia.. •. Compactas: típicamente son sentencias cortas.. •. Compatibles: usan los mismos términos que en el modelo de negocios.. 11.

(12) Capítulo 1. 1.2 Problemas que presentan en el tratamiento de las reglas de negocio Las RN reciben actualmente una atención especial en la comunidad de especialistas de SI; debido, básicamente, a las facilidades que ofrecen para obtener aplicaciones flexibles y de gran adaptabilidad. Tanto investigadores como ejecutores, están convencidos de que las RN demandan un tratamiento especial durante el Desarrollo de Sistemas de Información. (DSI) (Petrounias and Loucopoulos 1994; Ross 1997;. Youdeowei 1997; Date 2000; Date 2000; Bajec and Krisper 2005), sin embargo se presentan muchos problemas, tales como los descritos a continuación (Bajec, Krisper et al. 2000; Bajec and Krisper 2005): •. No captarlas sistemática y completamente hace que en las RN no se reflejen las condiciones reales del negocio. En consecuencia se desarrollan aplicaciones que no reúnen las necesidades del negocio.. •. No se dispone de documentación donde se encuentren las RN, o sea, ellas no se encuentran en fuentes directas. Las RN están contenidas dentro de esta documentación, pero de forma implícita.. •. Las RN están incluidas en el código de programa, de esta forma no queda claro cuáles son las reglas que gobiernan una aplicación, cuándo ellas se disparan o cómo son implementadas.. •. La lógica del negocio es difícil de mantener teniendo las reglas disueltas en la lógica de la aplicación.. •. Las RN son difíciles de controlar si ellas no encierran en sí un propósito único y común.. Otra gran dificultad con la que tropiezan los desarrolladores es la comunicación entre usuarios del negocio. Los analistas de sistemas no pueden proporcionar soluciones de aplicaciones comunes al negocio si los usuarios de negocio usan términos que varían de significado desde un departamento a otro dentro de la organización. Muchos SI profesionales por computadora mantienen la idea de que las RN deben ser captadas en forma automática, similar a como se hace en los Sistemas Expertos. De esta forma 12.

(13) Capítulo 1. la máquina debe hacer cumplir las reglas, controlando y conduciendo los procesos de negocio de acuerdo a estándares del negocio, políticas y procedimientos (Struck 1999; Struck 1999; Goedertier and Vanthienen 2006).. 1.3 Implementación de Reglas de Negocio Con el objetivo de hacer las aplicaciones más flexibles y adaptables, desarrolladores han usado numerosos y diferentes enfoques por un largo período de tiempo.. Los. métodos más comunes y tradicionales incluyen el uso de los disparadores y de los procedimientos almacenados. La mayoría de las aplicaciones dependen, en mayor o menor grado, de un almacén de datos, que por lo general, se basa en tecnología de base de datos relacional. Los sistemas de uso de base de datos relacionales (RDBMS), ofrecen los llamados “disparadores”, que tiene la habilidad de ejecutar acciones inmediatamente antes o después de que ocurran incidentes particulares. Estos sucesos tienen lugar cuando un registro es insertado, modificado o eliminado de la base de datos. Las acciones que los disparadores ejecutan se escriben en Structured Query Language (SQL) y pueden ser igualmente almacenadas como el cuerpo del disparador o como procedimientos de bases de datos. Las características mencionadas anteriormente, hacen que los disparadores sean apropiados para la implementación de reglas de negocio.. Por ejemplo, cuando. utilizamos el disparador “antes-de-insertar”, el registro puede ser verificado (o revocado en caso de que viole alguna regla de negocio) antes de ser insertado. Dado que la implementación de reglas de negocios reside en la propia base de datos, las modificaciones no dependen de aplicaciones y pueden ser llevadas a cabo sin acceder a la aplicación lógica. Existen numerosas ventajas en lo que se refiere al uso de disparadores para poner en práctica reglas de negocio (Bajec, Krisper et al. 2000): •. Las reglas de negocio no dependen de la aplicación lógica, ya que son almacenadas en la base de datos. 13.

(14) Capítulo 1 •. Las reglas de negocio son almacenadas en el servidor de base de datos. Por lo tanto, no están dispersas entre el número de clientes.. •. Las modificaciones hechas a las reglas de negocios pueden hacerse de forma remota.(El acceso desde un equipo remoto constituye una de las características más importantes de los servidores de bases de datos). •. El lugar donde específicas reglas de negocio son implementadas, en más fácil de hallar, debido a que se conocen las acciones que las iniciaron.. •. Para añadir una nueva regla de negocio no es necesario cambiar la aplicación código.. Sin embargo, este enfoque presenta un problema: depende de las bases de datos. Además, no puede proporcionar fácilmente un soporte de regla para clientes o para aplicaciones estándares que se ocupen de objetos de negocio complejos o de procesos de negocio. A pesar de la similitud que existe entre las expresiones del SQL y del lenguaje natural, el uso de disparadores de bases de datos todavía requiere de un profesional del SQL. En última instancia, este tipo de enfoque hace que el almacén de datos funcione como un motor de procesamiento, una tarea para la cual los motores de bases de datos no están optimizados. 1.3.1 Métodos Modernos de Implementación Los métodos modernos para la implementación de reglas de negocios obedecen al enfoque de este tipo de reglas y las manipulan explícitamente. En este contexto, una regla de negocios representa un meta-elemento importante que necesita ser capturado, formalizado e implementado además de otros elementos que constituyen la arquitectura de la aplicación. Actualmente están disponibles numerosas herramientas de desarrollo basadas en tecnologías orientadas a las reglas de negocio. Sobre la base de cómo se representan, implementan y ejecutan las reglas de negocio, estas pueden ser clasificadas de la siguiente forma(Barne and Kelly 1997): •. Herramientas independientes de bases de datos: las reglas de negocio son implementadas en una base de datos a través de disparadores (triggers) y 14.

(15) Capítulo 1. procedimientos. almacenados.. Sin. embargo,. estas. son. generadas. automáticamente y manejadas por el desarrollador, no por la herramienta en sí. •. Herramientas basadas en servidores: las reglas de negocio, que son creadas por una herramienta de desarrollo, se convierten en servicios de aplicación de nivel medio y se encuentran en un servidor de aplicaciones.. •. Sistemas basados en reglas: en lugar de especificar restricciones en elementos o tablas específicos de datos, un acercamiento lógicamente orientado captura el nivel más alto de la lógica del negocio. y las reglas asociadas a diferentes. situaciones. Durante el tiempo de ejecución, se utilizan motores especiales para procesar las reglas y generar respuestas apropiadas.. 1.3.1.1 Herramientas independientes de bases de datos Como se dijo anteriormente, estas herramientas usan disparadores (triggers) de bases de datos y procedimientos almacenados para implementar reglas de negocio.. Sin. embargo, estas herramientas soportan códigos para disparadores y procedimientos que sean creados automáticamente y manejados dentro de la herramienta. (Bajec 2000) Un buen ejemplo de este tipo de producto es el Vision Software´s Vision Builder, que genera automáticamente los procedimientos. almacenados apropiados y los. disparadores que se encuentran en una base de datos determinada. La importancia de esta aplicación se evidencia a la hora de cambiar o dar mantenimiento a los sistemas. Gracias a la información que se encuentra en el repositorio, pueden hacerse modificaciones fácilmente y los componentes pueden ser regenerados de forma automática. Sin embargo, esto presupone que la aplicación es, y puede ser, 100% generada automáticamente de la información del repositorio. Quien haya trabajado alguna vez con este tipo de herramienta sabe que están basadas en librerías sofisticadas y en sets de planillas de módulos clásicos de aplicación de negocios.. 15.

(16) Capítulo 1. 1.3.1.2 Herramientas basadas en servidores Otra forma de asegurar las reglas de negocios es implementarlas en una forma de servicio de aplicación. Un ejemplo de un producto asociado a este estudio es Usoft´s Developer, que, como herramientas independientes de bases de datos anteriores, asegura que la aplicación se derive automáticamente de reglas de negocio (incluyendo reglas de implementación). No obstante, una vez que las reglas de negocios hayan sido capturadas y almacenadas en el repositorio, no es necesaria una programación adicional para encender o procesar estas reglas. Todo se hace de forma automática por el procesador de reglas de negocio.(Bajec 2000) Esta herramienta también crea la base de datos y otros componentes necesarios de la arquitectura de tres niveles. Las aplicaciones cercanas al cliente invocan objetos, métodos o funciones en un servidor que contiene reglas de negocio.. De esta forma, la aplicación principal y la lógica. relativa a los datos, residen en el servidor de aplicación y no en la propia base de datos. Este tipo de aplicación brinda ventajas adicionales. Los desarrolladores no necesitan preocuparse por el momento en que las reglas deben ser ejecutadas o el orden en el cual deba sucederse este proceso debido a que el procesador de reglas es el encargado de estas tareas. Otra ventaja importante es la independencia tecnológica. Mientras la arquitectura de la aplicación sigue el estándar de la industria de arquitectura de tres niveles, los componentes de la aplicación de negocios permanecen independientes.. 1.3.1.3 Sistemas basados en reglas Estos sistemas están basados en un lenguaje específico basado en reglas y mecanismos específicos (motores de reglas) que se ocupan de la ejecución de las reglas. Los beneficios del lenguaje de procedimiento (procedural) son su predictibilidad y sencillez ante los requerimientos actuales. No obstante, estos son difíciles de manejar. El hecho es que si queremos que nuestra computadora computarice algo, 16.

(17) Capítulo 1. primeramente debemos saber todas las especificaciones y restricciones del problema y luego organizarlas en un juego de bucles y de sentencias condicionales que describan correctamente cómo debe comportarse el ordenador frente a cualquier problema que pueda aparecer. Por supuesto, este no es un trabajo fácil, de lo contrario no existiera escasez de ingenieros informáticos y los costos de mantenimiento serían mucho más bajos. Principalmente a causa de estas dificultades surgió un enfoque alternativo. Un ejemplo de lenguaje de programación que sigue una filosofía diferente, es el lenguaje basado en reglas.. La característica más importante que lo diferencia del lenguaje de. procedimiento (además de que en el lenguaje basado en reglas no hay flujo de control), es que, con un lenguaje basado en reglas, el sistema es el responsable de enlazar las especificaciones y las restricciones con el código ejecutable y software.. no el ingeniero de. A diferencia de los lenguajes de procedimiento, estos lenguajes tienen. lineamientos independientes e integran automáticamente sus partes IF en una sola lógica condicional integrada y eficiente, que se ejecuta directamente por un motor de inferencia. El motor de inferencia es el núcleo de todo sistema basado en reglas. Este monitorea la aplicabilidad de las condiciones de la regla contra la base de datos. En el momento en que la base de datos cambie, ya sea por adición, supresión o modificación de un archivo en ella, todas las reglas serán verificadas y ejecutadas en caso necesario. Los lenguajes basados en reglas han sido utilizados por un largo período de tiempo, desde que se encuentran en el centro de cada sistema basado en conocimientos. Además de ser muy útiles como lenguajes para especificar conocimientos condicionales o declarativos, son también excelentes lenguajes de especificación de reglas de negocio. De hecho, “el interés en las reglas de negocios avivará el amplio uso de sistemas basados en reglas en aplicaciones comerciales”. (John 1997) De acuerdo con sus declaraciones, “los productos de las reglas de negocio que son fácilmente integradas a una variedad de lenguajes, plataformas y sistemas legales, serán las más exitosas”. La habilidad de integración y coexistencia es actualmente la diferencia más importante entre los llamados productos de sistemas expertos de los 17.

(18) Capítulo 1. años ´80 y los productos de reglas contemporáneas.. Esos pueden ser fácilmente. integrados con diferentes lenguajes de programas de procedimientos, varias bases de datos, e incluso con herramientas GUI. Algunos ejemplos de estos productos son: Jboss Rules, Neuron Data´s Elements Expert e ILOG´S ILOG Rules. Son muchas las ventajas que nos proporcionan el uso de los sistemas basados en reglas en lugar de herramientas de uso convencional. Las ventajas más importantes se encuentran en la siguiente lista. Beneficios claves de los sistemas basados en reglas •. Desarrollo incrementado y de rápido prototipo. Las reglas se pueden ejecutar y probar cuando son añadidas al sistema. Los cambios a las reglas no requieren re-compilación.. •. Unidades comprensibles de práctica de negocios. Las reglas en la base de reglas son porciones de la lógica que representan conceptos sencillos, lo cual ayuda a que sean más fáciles de leer y entender.. •. No hay flujo de control. Las reglas pueden comenzar a ejecutar desde cualquier punto en la base de reglas.. •. Consistencia. Comparadas con códigos convencionales, las reglas incompletas, incorrectas, irrelevantes o redundantes son más fáciles de encontrar luego de ser destacadas por el sistema.. •. Habilidad para trabajar con información incompleta o perdida.. En muchas. situaciones de negocio, no siempre es posible suministrar datos completos y verificados. Los sistemas basados en reglas pueden trabajar con estos casos que tienen falta de información -los motores de regla pueden trabajar con valores especiales “unknown” (no es relevante en casos particulares de cálculo) y “not known” (el valor no es conocido).. 1.4 Sistemas Administradores de Reglas de Negocio (BRMS) Los Sistemas Administradores de Reglas de Negocio son aquellos que capturan, ejecutan, administran, conservan las reglas de negocio de determinado Sistema de Información. Dentro de sus componentes encontramos editores, que serán usados para 18.

(19) Capítulo 1. captar las reglas; motores de reglas, que determinarán cuando una regla debe ponerse en ejecución; repositorio de reglas, que almacenarán las reglas y ayudarán a inferir nuevas reglas de forma automática. Estos sistemas son los elementos principales para la implementación de las RN y su análisis y control dentro de los SI actuales.. 1.4.1 Metodología de los Sistemas Administradores de Reglas de Negocio Los Sistemas Administradores de Reglas de Negocio siguen con una metodología específica que no es más que las etapas de manejo y uso de las RN dentro del SI. •. Descubrimiento. •. Automatización. •. Análisis y Prueba. •. Integración y Ejecución. •. Mantenimiento 1. Descubrimiento. El propósito del descubrimiento de las RN es analizar la información acerca de la organización junto al SI que comienza a ser diseñado y constituye la fuente de información para la derivación de Negocios Oscuros (Business Rumbling), este término representa una pieza no estructurada de información concerniente a aspectos específicos de un negocio. Un Negocios Oscuros (Business Rumbling) es altamente no estructurado, informal y puede ser ambiguo e inconsistente. La documentación de la especificación de requisitos, que incluye información acerca de actividades que ocurren en el negocio, la naturaleza de los datos usados, la cultura de trabajo y la ética de la organización, los miembros claves de la organización, etc., resulta ser la entrada al descubrimiento de las RN. Los Negocios Oscuros (Business Rumbling) pueden también ser deducidos desde las personas del negocio, a través de. técnicas tradicionales de especificación de. requerimientos, tales como entrevistas, cuestionarios, observación del trabajo y monitoreo ad-hoc de los métodos de trabajo. Sin embargo, si la organización mantiene el modelo de negocio, entonces el conjunto inicial de reglas puede ser derivado directamente a partir de la información captada dentro del modelo. 19.

(20) Capítulo 1. 2. Automatización El soporte automatizado de las RN ha sido una de los tópicos de pruebas calientes en la comunidad de los SI en los últimos años. Mientras que resulta evidente la importancia de conocer las reglas que gobiernan el negocio, esto solo no resulta ser de tanta ayuda, y si lo es el tener de forma automatizada esta tremenda fuerza. Actualmente existen potentes tecnologías que soportan el mantenimiento y la implementación de las RN en un SI (Barne and Kelly 1997; Bajec, Krisper et al. 2000; Goedertier 2006) Mientras algunas de las reglas requieren determinaciones explicitas (ejemplo las reglas que son asociadas con los objetivos del negocio y procesos de negocio) muchos otros son inherentes en los diagramas de modelo de negocio. Tales reglas pueden ser automáticamente extraídas desde el modelo de negocios y entrar en su potencial representación en la determinación de requerimientos de un SI particular. 3. Análisis y Prueba: Los Negocios Oscuros (Business Rumbling) son escritos en lenguaje natural y pueden contener más de una regla de negocios simple. A través del análisis de las RN, los Negocios Oscuros (Business Rumbling) son analizados y descompuestos en sentencias de información discreta, atómica y precisa, también llamadas RN (Goedertier 2006). El propósito de la descomposición del Negocios Oscuros (Business Rumbling) en RN incluye la clasificación de las RN. Esta clasificación se basa en un esquema de clasificación de reglas predefinido. El propósito del esquema de clasificación es proporcionar estructuras dentro del cual las RN puedan se fijadas con respecto a la naturaleza de la información que ellas trasmiten. Actualmente existen varias taxonomías capaces de clasificar las RN (Keller, Nuttgens et al. 1992; Halpin 2000; Hamadi and Benatallah 2003; Meredith and Bjorg 2003; Microsoft 2003; Van Der Aalst, Ter Hofstede et al. 2003; Bailey, Bry et al. 2005; Goedertier 2006) Las pruebas realizadas dentro de este proceso de descubrimiento y análisis de las RN permiten a los especialistas del negocio controlar de forma dinámica la calidad del los resultados y las reglas obtenidas. 20.

(21) Capítulo 1. 4. Integración y Ejecución La Integración es una etapa importante donde cada elemento de la regla es validado y verificado, ya que estos constituyen parte específica de la lógica del negocio. En el descubrimiento de las RN la organización es dividida en unidades manejables. No obstante, diferentes áreas de la organización tienen que responder al mismo tipo de eventos de negocio y tienen información similar, necesaria para completar estos eventos; ellas usualmente no comparten el mimo vocabulario, procedimientos y métodos para localizar los recursos para cumplir su misión Es por esta razón que las reglas desde diferentes unidades muchas veces pueden ocasionar conflictos con otras y de esta manera ser inconsistentes. Es por eso que la Integración determina a cuales eventos y términos del negocio está asociada cada regla y elimina los conflictos. La Ejecución es la evaluación de las RN en el SI, donde se ejecutarán las acciones que ellas determinan cuando se cumplan sus condiciones. Es un componente fundamental, ya que traduce la información contenida en las reglas y está en contante espera a que sus condiciones estén creadas para ejecutarse. 5. Mantenimiento: Las RN son muy dinámicos, están en cambio constantemente y de forma natural (ejemplo en respuesta a fuerzas externas tales como regulaciones, acciones por competidores, nuevos descubrimientos científicos, etc.; o por fuerzas internas cuando un objetivo previamente establecido cambia). El propósito del manteniendo de las RN es coordinar estos cambios de forma tal que el sistema pueda reconsiderar sus objetivos de forma consistente y ajustables acordes a las estrategias del negocio. Es importante que las RN sean mantenidas sobre el nivel de la organización y no sobre un SI particular. Las RN pueden tener una implementación importante o varias (en uno o varios SI) pero desde el punto de vista de la organización ellas siempre reflejan el mismo ambiente de negocio. El mantenimiento de las RN incluye algunas actividades fundamentalmente: control de la eficiencia, control de versiones, validación de conflictos y consistencia y el control de impacto.. 21.

(22) Capítulo 2. Capítulo 2. “Comparación. entre. los. distintos. Sistemas. Administradores de Reglas de Negocio” En este capítulo se realizará un estudio de las principales herramientas para el procesamiento de reglas de negocio y sistemas de administración, con el objetivo de valorar sus principales características.. 2.1 Biz Talk Server El Biz Talk Server es un Sistema de Administración de Reglas de Negocio creado por Microsoft para el desarrollo, pruebas, despliegue y ejecución de reglas de negocio necesaria en una aplicación(Microsoft 2009). Anteriormente cada sistema en una organización implementaba sus propias reglas de negocio, ocasionando problemas como la descentralización de las reglas de validación lo que implicaba una incorrecta sincronización en la actualización de nuevas políticas y aumento en el mantenimiento de las aplicaciones cuando una regla cambiaba. En este escenario, BizTalk Server proveen un nuevo ambiente de trabajo (framework) utilizado en la implementación y ejecución de las reglas de negocio(Medina 2007). Business Rule Framework 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: •. Un motor de ejecución (Business Rule Engine o BRE).. •. Una interfaz gráfica (BizTalk Rule Composer).. •. Un asistente para el despliegue de reglas (BizTalk Deployment).. 2.1.1 Business Rule Engine (BRE) BRE implementa el mecanismo de evaluación, basado en el algoritmo Rete, para las reglas de negocio. Este algoritmo se centra en la comparación de valores denominados “facts” (“hechos”) mediante patrones de comparación denominadas “rules” (“reglas”), 22.

(23) Capítulo 2. en un sistema de producción llamado “rule engine” (“motor de reglas”), en este caso el sistema de producción está formado por una o más condiciones y un conjunto de acciones las cuales deben ser ejecutadas cuando las condiciones son verdaderas. De igual forma, los elementos evaluados en una condición son los “hechos”. La arquitectura interna del Motor de Reglas está compuesta por tres componentes: •. Rule Set Executor: es el responsable de evaluar y ejecutar las reglas del negocio.. •. Rule Set 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.. 2.1.2 Business Rule Composer. El Business Rule Composer es el editor para el desarrollo de reglas de negocio que provee 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(Medina 2007). 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 elementos facts (“hechos”) utilizados por las reglas como vocabularios, esquemas xml, bases de datos y clases de .Net.. •. Conditions Editor: se utiliza para ver y editar condiciones que deberán ejecutar las reglas.. •. Action Editor: se utiliza para ver y editar las acciones que se deben ejecutar cuando una regla es válida. 23.

(24) Capítulo 2 •. Properties Windows: se utiliza para visualizar las propiedades.. Véase la Figura 2. 1donde se muestran las vistas del editor.. Figura 2. 1 Vistas del Editor de Reglas del BRS. En el Business Rule Composer se puede definir, versionar y desplegar todas las políticas de negocio y vocabularios utilizados en la implementación de la regla de negocio a la plataforma de BizTalk Server(Medina 2007). Cuando se desarrollan las reglas de negocio, se recomienda seguir los siguientes pasos que se explican a continuación.. 2.1.3 Definir el vocabulario La definición del vocabulario que se utilizará en la implementación de las reglas de negocio es el primer paso, esta definición se puede hacer en el tab de Vocabulary ubicado en la sección Facts Explorer. Al crear el vocabulario nuevos facts son adicionados, estos facts representan la fuente de datos de los términos que van a ser 24.

(25) Capítulo 2. evaluados y están basado en elementos xml, bases de datos o miembros públicos de clases de .Net(Microsoft 2009). Una vez creado y definido el vocabulario, éste debe de ser salvado y publicado para ser utilizado posteriormente por una regla de negocio, véase la Figura 2.2.. Figura 2.2: Tab de Vocabulary ubicado en la sección Facts Explorer.. Adicional al Tab Vocabulary, la sección Facts Explorer contiene tres opciones: Xml Schemas, Databases y .Net Classes. Estas opciones son utilizadas cuando nuevos facts que no han sido previamente publicados en el vocabulario deben ser utilizados en la regla de negocio. Véase la Figura 2. 3.. 25.

(26) Capítulo 2. Figura 2. 3 Tabs de Vocabulary ubicado en la sección Facts Explorer.. 2.1.4 Definir la política y reglas El segundo paso en la implementación de la regla es la definición de la política, para este proceso se utiliza la sección Policy Explorer. En BizTalk Server todas las reglas de negocio están lógicamente agrupadas en políticas, y estas políticas están definidas en base a un concepto del negocio en el contexto de la aplicación que las consumirá. Una vez es definida la política, las reglas que estarán contenidas en ella deberán ser creadas. Cada una de las reglas de negocio definidas deberá evaluar las condiciones establecidas y en base a esta evaluación deberá ejecutar una determinada acción. Véase la Figura 2. 4.. 26.

(27) Capítulo 2. Figura 2. 4 Vista del Policy Explorer.. De igual forma, al definir las reglas de negocio en la política es posible establecer la prioridad en la cual éstas se deben ejecutar. Para lograr esto se debe establecer un nuevo valor a la propiedad Priority (por defecto es 0) de cada regla creada; las reglas serán ejecutadas en orden descendente, es decir, la regla que tenga la prioridad más alta será la primera en ejecutarse y la regla que tenga la prioridad más baja será la última en ejecutarse. Véase la Figura 2. 5.. 27.

(28) Capítulo 2. Figura 2. 5 Vista del Policy Explorer para modificar la prioridad.. 2.1.5 Definir la lógica de la regla de negocio El tercer paso es definir la lógica para cada regla de negocio. En el editor Business Rule Componser cada regla de negocio creada se basa en una condición y una acción para su ejecución. En la condición se definen los operadores lógicos (AND, OR, NOT) que serán aplicados a los predicados, éstos corresponden a funciones u operadores que por defecto BizTalk Server provee o definidos previamente por el usuario y que evaluaran los facts previamente definidos. Establecida la condición, se debe proceder con la definición de la acción que será ejecutada en caso que la condición evaluada sea verdadero. Una acción contempla la ejecución de una funcionalidad en específico provista por BizTalk Server, una funcionalidad previamente definida por el usuario o con la asignación de un valor a un fact previamente definido.. 28.

(29) Capítulo 2. Una vez implementada la lógica de la regla de negocio, el editor Business Rule Composer mostrara la definición gráficamente mostrada en la Figura 2. 6.. Figura 2. 6 Representación grafica de la lógica de la regla de negocio.. 2.1.6 Probando y Desplegando de Reglas de Negocio en BTS Cuando la política esté completa y antes de ser desplegada se recomienda hacer una prueba unitaria sobre la misma para garantizar su funcionalidad, para ello el editor Business Rule Composer ofrece la interfaz para ejecutar esta prueba unitaria. Antes de realizar la prueba es necesario especificar los valores iniciales para todos los facts definidos en el vocabulario y que son utilizados por las reglas definidas, esta especificación se realiza en una interfaz de configuración y contempla archivos XML, librerías de .Net y bases de datos. Una vez que estos valores son previstos, se ejecuta la prueba y el resultado es desplegado en el mismo editor Business Rule Composer. Por último, y luego de una prueba unitaria satisfactoria se procede a desplegar la nueva política. Este. 29.

(30) Capítulo 2. procedimiento también puede realizarse desde el editor y basta con primero publicar la política y luego hacer el despliegue de la misma desde la sección Policy Explorer.. 2.1.7 Arquitectura de Reglas de Negocio en BTS En BTS una regla de negocio se conforma por una o varias condiciones (condition) y a su vez ésta por una o varias acciones (action) siguiendo el formato: IF condition THEN action Una condition es una expresión lógica: verdadero (true) o falso (false), y está formada por predicados (predicates) que son aplicados a facts. Los predicates son una combinación de operadores matemáticos y lógicos, que combinados determinan la condition. Un action es la consecuencia de la evaluación de una condition, es decir, si la condition evaluada es true la action será ejecutada. A su vez, una action puede realizar una operación, modificar el valor de uno o mas facts o introducir/remover facts. Los facts son el principal elemento en la definición de las reglas de negocio ya que intervienen tanto en la evaluación de la condition como en la ejecución de la action. Asimismo, un fact puede ser definido como un documento XML, un objeto de .Net, o un campo dentro de una base de datos. Una o más reglas de negocio al ser implementadas se deben agrupar en una política (policy) de acuerdo al BRF, la cual determina la versión, despliegue y actualizaciones de las reglas de negocio que esta contiene. Otro elemento importante en BTS acerca de las reglas de negocio es el vocabulario (vocabulary). Esto es simplemente una forma de representar los facts en términos del negocio para que estos puedan ser fácilmente interpretados por los participantes en la implementación y ejecución de una regla de negocio.. 2.2 OpenRules OpenRules, Inc. ofrece una metodología, basada en Código Abierto (OpenSource) que brinda un conjunto de herramientas y servicios que posibilitan el trabajo a los analistas del negocio en coordinación con los desarrolladores de software, para crear y mantener. 30.

(31) Capítulo 2. Aplicaciones Web basadas en reglas (Rules-based Web Application Development), con un alto nivel de complejidad en su lógica y negocio(OpenRules 2009). OpenRules® es un Sistema de Administración de Reglas de Negocio a gran escala. Provee un grupo de componentes de Código Abierto para el desarrollo de Aplicaciones Web basadas en reglas. Usa como base las herramientas más comunes, como el MS Excel, Eclipse IDE, y diferentes Librerías de OpenSource. El OpenRules® está diseñado para facilitar el entendimiento de las personas del negocio con el desarrollo de las reglas y el proceso de mantenimiento que ofrecen los BRMS sin perder la simplicidad. Con el OpenRules se pueden crear simples o complejos sistemas de decisiones que brindan mantenimiento y ejecutan un gran número de reglas de negocio. En conjunto con las más comunes herramientas de trabajo OpenRules crea un Repositorio de Reglas de Negocio, en el cual se almacenaran todas las reglas, ya sean las que estén siendo ejecutadas como las que no formen parte ya del Negocio. OpenRules puede ser integrado, o ser usado solamente con cualquier aplicación J2EE/J2SE o .NET, desde las más pequeñas y sencillas aplicaciones de Java hasta los grandes Sistemas de Comercio Electrónico.. 2.2.1 EXCEL como editor de Reglas de Negocio Los Analistas del negocio usualmente usan del paquete de MS Office, herramientas como el MS ExcelTM o el WordTM para presentar las reglas de negocio. A demás por cuestiones de licencias y propiedades, la mayoría de las empresas ya tienen dentro de sus sistemas estos paquetes y su personal adiestrado en su uso. Por eso, antes de usar cualquier BRMS comercial, en el cual tendrías que incluir toda tu base de regla que ya debes tener dentro de tablas Excel, por qué no usar éste directamente para administrar las reglas de negocio. Después de todo, es un estándar que provee un gran número de ventajas y no obliga al personal conocedor del negocio a dominar un lenguaje de programación. Con el OpenRules, los analistas del negocio pueden crear, modificar y ejecutar reglas de negocio directamente desde el Excel. OpenRules utiliza el bien establecido concepto del Excel Libro de Trabajo (workbook), Hoja de Trabajo (worksheet) y Tablas. Estos se pueden representar y conservar en 31.

(32) Capítulo 2. distintos archivos de Excel. Cada Libro de Trabajo en OpenRules comprende una o más Hojas de Trabajo, que pueden ser usadas para separar la información por categorías. Cada Hoja de Trabajo se compone por una o más tablas. Las Tablas de Decisiones son las más comunes dentro del OpenRules, y son usadas para representar las reglas de negocio(OpenRules 2009). Las Tablas de Decisiones son una representación tabular de las reglas de negocio. Son usadas para describir y analizar las situaciones de decisión, donde un número de condiciones determinan la ejecución de una determinada acción. Ponemos como ejemplo una Tabla de Decisión simple para determinar cuál es saludo apropiado al entrar en un sistema dependiendo del horario. Mostramos el ejemplo en la Figura 2. 7.. Figura 2. 7 Tabla de Decisión.. 2.2.2 Categorías de Reglas de Negocio en OpenRules Como se ha mencionado anteriormente, OpenRules divide para administra las reglas de negocio por categorías usando el mismo sistema jerárquico que tiene el Excel ya implementado con sus Libros de Trabajo (workbook) y Hojas de Trabajo (worksheet). Para analizar esta característica del OpenRules se hace mediante un ejemplo clínico(OpenRules 2009). Se considera crear una ayuda para la prescripción médica una vez diagnosticada la Sinusitis Aguda. En la siguiente Figura 2. 8 se muestran las reglas que controlan el negocio.. 32.

(33) Capítulo 2. Figura 2. 8 Reglas de la prescripción de la Sinusitis Aguda.. Al conocer estas reglas se reconocen dos grupo de ellas, las reglas de medicación y las reglas de dosificación. Con lo cual se crean dos Hojas de Trabajo dentro de un mismo Libro de Trabajo que será SinusitisAguda.xls en el cual se incluirán todos los tratamientos y dosificaciones para dicho padecimiento. Las tablas de decisiones para el primer grupo de reglas quedan conformadas de la siguiente forma. Véase la Figura 2. 9.. Figura 2. 9 Tabla de Decisiones de las reglas de medicación.. El análisis que se tiene sobre las interacciones de las drogas provoca crear otra tabla de decisión, como se muestra en la Figura 2. 10. 33.

(34) Capítulo 2. Figura 2. 10 Tabla de Decisiones de la interacción entre los medicamentos.. Por último, de las reglas de dosificación se crea la tabla de decisión mostrada en la Figura 2. 11.. Figura 2. 11 Tabla de Decisiones para la dosis del medicamento.. 2.3 Drools JBoss Rules, Drools es uno de los más avanzados Sistemas de Administración de Reglas de Negocio, ya que es su última versión no solo incluyen un modulo para el flujo del trabajo (workflow) con el Drools Flow, sino que también adicionan un procesador de eventos con el Drools Fusion, creando una integración mayor en el desarrollo de software. Drools 5.0 se divide en 4 módulos: Guvnor, Expert, Fusion y Flow. El Guvnor es lo que se conoce tradicionalmente como el BRMS(Browne 2009), el cual está basado en una ambiente web. Expert es el tradicional motor de reglas. Fusion es el procesador de eventos, el cual trabajo con los cambios en los datos del sistema. Finalmente el Flow, que es el módulo que controla el flujo de trabajo. Todos estos módulos conforman lo que ellos llaman la Plataforma de Integración de la Lógica del Negocio, de sus siglas en Ingles Business Logic integration Platform (BLiP)(Baili 2009).. 34.

(35) Capítulo 2. 2.3.1 Principales características del Drools •. JBoss Rules ofrece un lenguaje. natural con el DSL (Domain Specific. Language). •. Las reglas están escritas usando un especializado lenguaje de reglas orientado a objetos.. •. Las reglas deben ser escritas por expertos del negocio.. •. Ofrece atributos adicionales a las reglas que le permiten controlar su ejecución dentro del sistema.. •. Ofrece un lenguaje de dominio específico como un mecanismo de plantillas.. •. Las Plantillas facilitan al usuario actualizar y dar mantenimiento a las reglas.. •. Las reglas son administradas dentro de los archivos de reglas.. •. Una o más reglas son incluidas dentro de un mismo archivo.. •. Las Reglas son ensambladas usando un sistema de reglas y divididas por categorías en los archivos de reglas.(JBoss 2009). 2.3.2 Drools Guvnor El modulo Guvnor presenta un ambiente web desde el cual se administra y editan las reglas, al igual que en otros editores de reglas ya vistos, divide y agrupa las mismas en categorías y almacena el conocimiento de estas en tablas de decisiones(JBoss 2009). Dentro del conjunto de reglas, podemos encontrar en esta vista, las reglas según su estado de ejecución; también se tiene implementado un elemento de búsqueda para encontrar una regla determinada(Browne 2009). Véase la Figura 2. 12.. 35.

(36) Capítulo 2. Figura 2. 12 Ambiente web del Guvnor. La Tabla de Decisión es el elemento en el cual se crea y editan las reglas, en el se incluyen las condiciones que deben cumplirse para ser ejecutada cada una de las reglas(JBoss 2009). Véase la Figura 2. 13.. Figura 2. 13 Tabla de Decisión del editor de reglas del Drools.. 36.

(37) Capítulo 2. El módulo incluye un ambiente integrado de prueba, generando valores aleatorios para satisfacer las reglas ya editadas y ver los resultados de su ejecución. Un ejemplo de la ventana de este ambiente se muestra en la Figura 2. 14.. Figura 2. 14 Escenarios de Pruebas.. También estos tipos de pruebas se pueden hacer individuales para cada una de las reglas, permitiendo evaluar valores específicos para cada regla con el cual se miden el correcto funcionamiento de la regla incluida. Véase la Figura 2. 15.. 37.

(38) Capítulo 2. Figura 2. 15 Prueba individual a una regla.. 2.4 ILOG JRules ILOG JRules es un conjunto de clases 100% Java que facilitan la creación de aplicaciones basadas en el uso de RN. Proporciona un medio eficiente para la modificación del comportamiento de las aplicaciones, ideal cuando se requieran cambios del flujo de control en la operativa diaria, sin necesidad de un desarrollo adicional, simplemente cambiando las RN. El principal proveedor de componentes de software empresarial y servicios, presenta ILOG JRules™ 5.1 que soporta las dos plataformas. La última versión de este producto clave en la línea de sistemas para la gestión de RN (BRMS) de ILOG, permite que los responsables de negocio y los profesionales de Tecnología de la Información (TI) colaboren en la creación, ejecución y gestión de las reglas para su despliegue sobre plataformas Java y .NET. En la actualidad, la mayoría de los departamentos TI corporativos en las compañías del Global 2000 tienen entornos .NET y Java, por lo tanto era necesario que los sistemas de gestión de RN (BRMS) soporten estos dos grupos de desarrolladores. ILOG 38.

(39) Capítulo 2. responde a esta demanda con ILOG JRules 5.1, que permite a los desarrolladores desplegar RN almacenadas en el Repositorio de Reglas JRules, tanto en plataforma Java, utilizando el Motor de Reglas nativo Java, como en plataforma Microsoft y .NET, por medio del Motor de Reglas .NET. Los usuarios de JRules ahora también serán capaces de desplegar reglas idénticas para su ejecución desde aplicaciones Java y .NET, por ejemplo, desplegando las reglas en un servidor de aplicaciones J2EE y con un cliente .NET en Windows, lo que facilita el uso compartido de reglas en ambas plataformas. Además, ILOG JRules 5.1 incorpora mejoras en su entorno servidor para la ejecución de las reglas denominado ILOG Business Rule Execution Server, que permite a los desarrolladores utilizar el mismo API para programar tanto en Java 2 Standard Edition, como en Java 2 Enterprise Edition, lo que permite una transición sin problemas desde el prototipo a la puesta en producción. Por otro lado, ILOG Business Rule Execution Server soporta ahora IBM Websphere 6.0, la última versión de la plataforma del servidor de aplicación de IBM, y para los servidores de aplicación líderes de BEA, JBoss, ObjectWeb y Apache Tomcat. Al igual que en cada nueva versión de ILOG JRules, la versión 5.1 incorpora mejoras adicionales en cuanto a su rendimiento y escalabilidad para los despliegues del Servidor de Ejecución de RN por parte de los clientes. ILOG JRules 5.1 también incluye ILOG Business Rule Studio 2.1, certificado por IBM como “Ready for Rational Software” y que permite crear, ejecutar y depurar las reglas dentro de Rational Application Developer 6 (RAD6) y de Rational Software Architect 6 (RSA6) de IBM. Los productos “Ready for Rational Software” siguen las mejores prácticas definidas por IBM y tienen garantizada su fácil integración con la Plataforma de Desarrollo de Software de este proveedor. ILOG Business Rule Studio 2.1 también se integra en Eclipse 3, el más utilizado Entorno de Desarrollo Integrado (IDE) para los desarrolladores en Java.. 39.

(40) Capítulo 2. 2.5 Conclusiones parciales En este capítulo. se han analizado las principales características de diferentes. herramientas para el procesamiento de reglas de negocio; se analizan sus ventajas y características en cuanto a la forma en que editan las reglas. Formas de captar las reglas de negocio: La mayoría de herramientas estudiados proporcionan un conjunto de facilidades para captar las reglas de negocio, pero todas las definen como un conjunto de condiciones a cumplir, y que estas derivaran una o más acciones a ejecutar. El OpenRules al igual que el Drools, conservan la base de reglas en Tablas de Decisiones, agrupándolas en categorías especificas del negocio. Por otra parte, el Biz Talk Server edita las reglas de forma individual, pero las agrupa según la política que determinan en el negocio. Lenguaje de Reglas Una de las características fundamentales a tener en cuenta en estas herramientas es el tipo de lenguaje que usan para editar las RN. El Drools implementa un tipo de lenguaje específico del dominio, el que representa las reglas para un determinado negocio. Por otro lado, el Biz Talk Server determina un vocabulario y en base a este se definen las reglas. Es una generalidad el uso de XML como lenguaje base para crear el repositorio de reglas, que posteriormente sirve para que sean interpretadas. Repositorio de RN En la mayoría de los sistemas de administración de reglas (BRMS) estudiados presentan un componente muy importante, el Repositorio de Reglas. En él se almacenan las RN, tanto las que están en ejecución, como las que ya no forman parte del conjunto de RN por haber sido sustituidas por nuevas entradas. Una ventaja de disponer de estos repositorios de RN es que posibilitan crear plantillas de reglas, reutilizando las reglas existentes al crear otras nuevas. Otra generalidad encontrada es que las reglas se agrupan en categorías, dentro de ellas las reglas son muy similares, solo podrían variar en el atributo que modifiquen en una base de datos, o el valor, o una nueva fórmula para calcular un campo o un atributo determinado en una base de datos. Estas técnicas permiten la reutilización de las reglas antes 40.

(41) Capítulo 2. generadas, lo que ahorra tiempo al momento de editar las reglas y poner a punto el sistema.. 41.

(42) Capítulo 3. Capítulo 3. “UCRules, editor de reglas de negocio” En este capítulo se aborda la descripción del editor de reglas de negocio desarrollado durante la investigación. Se analizan sus principales características de implementación, así como su arquitectura y facilidades que brinda para la edición de las reglas en un lenguaje cercano al del negocio.. 3.1 Arquitectura del Editor El editor de reglas, permite a los expertos del negocio que carecen de formación técnica, manejar y construir las reglas que definen su negocio simplemente utilizando el ratón de su ordenador y una interfaz basada en "seudo siglas”. Estas reglas se incorporan, después, de manera dinámica a la aplicación en ejecución. El editor de reglas está enmarcado dentro de un ambiente donde interactúan varias herramientas. Esta investigación abarca el analizador sintáctico y semántico, actualizando el modelo de hechos y el conjunto de reglas. Dando como resultado final un. documento. XML,. que. sirve. de. entrada. a. herramientas. que. generan. automáticamente las nuevas reglas o aquellas que han sido modificadas, véase la ¡Error! No se encuentra el origen de la referencia... 42.

(43) Capítulo 3. Figura 3. 1 Arquitectura del Editor de Reglas de Negocio.. 3.1.1 Repositorio de reglas de negocio Resulta esencial para el posterior uso de la RN el disponer de un Repositorio de Reglas, el cual no es más que un lugar donde es almacenada la información relativa a las RN (Bajec 2006). El Repositorio de Reglas no forma parte del editor, con mucha frecuencia es un depositito global para las RN de toda la organización. El Repositorio de RN. es un punto en común entre la comunidad de usuarios y. profesionales de Computación. Este punto en común se logra mediante la entrada de RN realizadas por los profesionales de computación y la validación de estas realizada por los usuarios, estos usuarios serían expertos del negocio, está claro que esta entrada y validación de RN se realiza mediante el editor y luego se generan automáticamente en el sistema, el mismo que usan los propios usuarios, véase la Figura 3. 2. 43.

(44) Capítulo 3. Figura 3. 2 Diagrama de intercepción entre usuarios y Profesionales de Computación.. 3.1.2 Uso de patrones para la edición de reglas No existe un estándar de cómo hacer Reglas de Negocio, pero si es posible hacer algunas recomendaciones. Los patrones pueden reflejar la forma de las cosas, los hechos que en la industria o los tipos de problemas que un sistema automatizado pretende negociar (Morgan 2002). Cada una de las versiones sobre las que se ha trabajado se basa en patrones diferentes, ellos se explican en cada caso. 3.2 Editor de reglas de negocio, primera versión En el inicio de la investigación se obtiene una herramienta independiente de la base de datos para la edición de RN. El software permite a los usuarios del negocio la manipulación de un conjunto de reglas previamente creado. Dicha herramienta facilita estructurar cada regla utilizando una forma de expresión semejante a la natural. Se escriben según patrones que permiten realizar validaciones de términos y atributos, los cuales han sido definidos como válidos en el modelo de hechos. Finalmente se obtiene un repositorio de reglas en formato XML que permite la integración con otras 44.

(45) Capítulo 3. herramientas de procesamiento y generación automática de RN (Ibargollin Peréz 2009).. 3.2.1 Patrón de reglas utilizado para la herramienta No existe un estándar de cómo hacer Reglas de Negocio, pero si es posible hacer algunas recomendaciones. Los patrones pueden reflejar la forma de las cosas, los hechos que en la industria o los tipos de problemas que un sistema automatizado pretende negociar (Morgan 2002). La herramienta de edición de RN se apoya en la estructura ofrecida por Morgan (Morgan 2002), de ellos se escoge el Patrón 1:que es un patrón sobre Restricción Básica, por ser el más común de todos y donde se establecen las restricciones sobre un determinado sujeto, además de ser el patrón ya abordado en etapas iniciales de otros trabajos sobre el tema de edición y generación automática de reglas (Pérez Alonso, 2008, Martínez et al., 2007).. Patrón 1: Restricción Básica <determinante> <sujeto> [ no ] (debe |tiene) <característica> [ ( si | a menos que ) <hecho>].. < determinante > < sujeto > (puede < característica > solo si <hecho> ) | ( no puede < característica > ). Ejemplos: R1: Every patient with IRCT diagnostic must be valued in Consultation of Nephrology. R2: A Possible Recipient can be included in the Waiting-list of Transplants only if it was evaluated completely by the Commission of Transplant. 3.2.2 Descripción de la herramienta Este epígrafe muestra el ambiente para la aplicación de software (Ibargollin Peréz 2009). Esta ventana es la principal del sistema, permite comenzar el trabajo desde diferentes momentos (véase la ¡Error! No se encuentra el origen de la referencia.): 45.

(46) Capítulo 3. • Un documento XML generado por el Protégé. • Un documento .cfg previamente creado con la propia herramienta. • Un nuevo documento, que es cuando no hay reglas cargadas en la aplicación. Una vez que se hace una revisión sobre las reglas existentes, se pueden hacer comentarios sobre ellas, se da la opción al usuario de estructurar estas reglas y realizar la validación semántica apoyándose en los sujetos y atributos almacenados por la herramienta. Véase la Figura 3. 3.. Figura 3. 3 Editor de Reglas primera versión.. El editor visualiza el repositorio de reglas al experto, lo que permite chequear el conjunto de reglas disponibles en el repositorio, permitiendo a los usuarios agregar comentarios a cada regla. Eso añade valor agregado al editor por resultar de suma importancia para su uso posterior. Es posible también activar o no cada regla en dependencia de su uso. 46.

(47) Capítulo 3. Se diseña e implementa también un editor que posibilita esta funcionalidad, generando finalmente un documento XML que será utilizado para la integración con otras herramientas. Fundamentalmente la herramienta para la administración del modelo de hechos mediante un menú que permite hacer operaciones tales como: •. Agregar o eliminar una regla.. •. Agregar o eliminar un sujeto.. •. Agregar un atributo a un sujeto o eliminarlo.. •. Agregar o modificar un valor a un atributo.. 3.3 Editor de reglas de negocio, segunda versión El software permite a los usuarios del negocio la creación de un proyecto para la manipulación de un conjunto de reglas que giren alrededor de un mismo modelo de hechos. Esta herramienta facilita la definición de las reglas utilizando una forma de expresión semejante al lenguaje natural. Se escriben según patrones que permiten realizar validaciones de términos y sus interrelaciones, las cuales han sido definidas como válidas en el modelo de hechos. Finalmente se obtiene un repositorio de reglas en formato XML que permite la integración con otras herramientas de procesamiento y generación automática de RN.. 3.3.1 Modelo de hechos Para el buen estado de las RN es esencial tener un vocabulario bien definido y consistente del negocio. Un modelo de hechos estructura el conocimiento básico acerca de las operaciones del negocio desde la perspectiva del mismo. En particular, el modelo se enfoca en la estandarización de la terminología del negocio, para luego establecer un vocabulario de negocio común; por lo que se considera un punto de partida crucial en el modelado (Ross 2000). El modelo de hecho se sostiene sobre los 47.

(48) Capítulo 3. términos. Los términos pueden ser de dos tipos: términos del negocio o comunes. Véase la Figura 3. 4.. Figura 3. 4 Término dentro del modelo de hechos.. Los hechos se definen a través de interrelaciones entre términos, véase la Figura 3. 5.. Figura 3. 5 Composición de un Hecho.. Los hechos se pueden clasificar de acuerdo a su estructura en: hecho atributo, hecho sinónimo, hecho general específico, hecho agregación, hecho rol, hecho asociación; según se muestra en la Figura 3. 6.. 48.

(49) Capítulo 3. Figura 3. 6 Clasificación de un Hecho.. 3.3.2 Reglas de negocio y el modelo de hechos. En la relación de las RN con el modelo de hecho, estas se integran por hechos y se pueden clasificar en: reglas estructurales, de conducta y administrativas (véase Figura 3. 7 y Figura 3. 8), correspondiendo con la clasificación semántica propuesta por Weiden (Weiden, Hermans et al. 2002).. Figura 3. 7 Composición de una Regla en el Modelo de Hechos.. 49.

(50) Capítulo 3. Figura 3. 8 Tipos de reglas de negocio en el Modelo de Hechos.. En esta estructura creada para almacenar las reglas se necesita además una clasificación para un término del negocio, tal que puede ser: actor, proceso, recurso, habilidad, conocimiento, objetivo, condición. Mientras que los términos comunes se clasifican en: determinante, resultado, periodo, frecuencia, Opción_Modo, Creativo, Rol_Infinitivo. También las tareas son clasificadas en: Operacional, Toma de Decisiones y Creativa, a su vez las de Toma de Decisiones son clasificadas como de Clasificación, Diagnostico, Valoración, Supervisado, de Predicción, véase la Figura 3. 9.. 50.

(51) Capítulo 3. Figura 3. 9 Clasificación de tarea.. En la base de datos se representa además cada uno de los tipos de reglas que heredan de cada una de las categorías que a su vez heredan del concepto de regla. Estos tipos de reglas son Estructura de Conceptos, Persistencia, Historia, Fórmula que corresponden a la categoría de reglas Estructural, también Flujo de información, PreCondición, Post-Condición, Frecuencia, Duración, Flujo de Control que corresponden a la categoría de reglas de Conducta, además Organización, Objetivo y Valor, Actitud del Actor, Responsabilidad del Actor, Recursos que corresponde a la Administrativa como se expuso en la clasificación semántica del capítulo anterior.. 3.3.3 Casos de Uso El diagrama de casos de uso refleja las acciones que realiza cada actor en el sistema en este caso se cuenta con tres actores: Administrador, Usuario Especialista y Usuario Común, véase la Figura 3. 10. El usuario administrador es un especialista en computación responsable del sistema, el usuario especialista es un experto del negocio autorizado además de manejar las reglas de modificar la estructura del modelo de hechos y el usuario común es también un experto del negocio con menos privilegios ya que solo puede manejar las reglas. 51.

(52) Capítulo 3. Figura 3. 10 Diagrama de casos de uso.. Descripción de los casos de uso Caso de uso Administrar Usuarios. Descripción Se utiliza este caso de uso para el manejo de los permisos de cada usuario.. Modificar Modelo de Hechos. Se utiliza este caso de uso para modificar el vocabulario del negocio.. Manejar las Reglas. Se utiliza este caso de uso para todo lo referido a crear, modificar y eliminar RN.. 3.3.4 Uso de patrones semánticos Generalmente no se ha aceptado una vía para definir o representar RN ((OMG) 2003), pueden ser usados diferentes lenguajes de modelación tales como: UML, sentencias de inglés/español estructurado, lenguajes de modelación de reglas especializados, código de programas u otros ((OMG) 2002; Vasilecas and Lebedys 2004). Se encuentran muchas formas diferentes de clasificar las RN, “cada tipo puede ser representado de forma diferentes” (Morgan 2002). En principio todas las reglas pueden 52.