Uso del LPT SQL para la generación automática de reglas de negocio en la implementación del sistema de información para planificar menús en comedores universitarios: SIMCO v1 1

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. Uso del LPT-SQL para la generación automática de reglas de negocio en la implementación del sistema de información para planificar menús en comedores universitarios: SIMCO v1.1. Autor: Yaisel Nuñez Arcia. Tutor: M.Sc. Martha Beatriz Boggiano Castillo. Laboratorio del Centro de Estudios de Informática 2014 “Año 56 de la Revolución”.

(2) Dictamen. Dictamen con derechos de autor para MFC. 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 Ciencias 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 Seminario____________.

(3) Pensamiento. Pensamiento. "Hay tres maneras de adquirir sabiduría: primero, por la reflexión, que es la más noble; segundo, por imitación, que es la más sencilla; y tercero, por la experiencia, que es la más amarga" Confucio.

(4) Dedicatoria. Dedicatoria. A mi familia por su apoyo es todo este tiempo principalmente a mi hermana y mi cuñado, a mi mamá y a mis abuelos, a mi tía y mi prima y por último y no menos importante a mi tío..

(5) Agradecimientos. Agradecimientos. A todas aquellas personas que han contribuido de una forma u otra al resultado final de este trabajo de diploma, muy especial a mi familia que siempre me apoyó de muchas maneras y todos estuvieron siempre muy preocupados de cómo iba mi trabajo. A mi tutora Martha Beatriz por su apoyo permanente en todo momento, porque cada vez que la ocupé siempre me atendió y me ayudó en todo lo que pudo. A todas mis amistades por sus grandes iniciativas, ayuda y apoyo incondicional..

(6) Resumen. Resumen Contar con un sistema de información (Kamada and Mendes) para la planificación de menús de comedores que satisfaga las expectativas del cliente superando las dificultades de la versión anterior, surge al mismo tiempo que la necesidad de contar con un modo sólido de validación, en el contexto del tema de investigación sobre generación automática de reglas de negocio, del conjunto de categorías de reglas de negocio desde la perspectiva de los datos y sus patrones de reglas en lenguaje natural estructurado, nivel técnico (lenguaje de patrones técnicos) LPT, y su traducción automática a recursos de bases de datos; se presenta como un modo de trabajo encaminado a automatizar las reglas asociadas al comportamiento de los datos. Para validar los resultados acerca del uso de las categorías de reglas desde la perspectiva de los datos y sus niveles de expresión se utiliza el estudio de caso como método de validación, para el sistema de planificación de menús de comedores de la UCLV, a través del planteamiento de los aspectos que guían la aplicación del mismo. Se detallan además aspectos relacionados con el diseño e implementación del sistema basado en la arquitectura modelo-vista-controlador, y finalmente se describen las pruebas de aceptación realizadas por casos de uso. Esta investigación tiene un valor práctico porque evidencia cómo se puede utilizar la herramienta LPT-SQL en la implementación automática de las reglas de negocio en una BD operacional de un SI.. i.

(7) Abstract. Abstract Having an information system (IS) for menu planning in canteens that meets customer expectations overcoming the difficulties of the previous version, while arises the need for a robust validation mode, in the context of research topic on automatic generation of business rules, the set of categories of business rules from the perspective of data and patterns in structured natural language rules, technical level (technical pattern language) LPT, and automatic translation to resources databases; is presented as a way of work lead to automate rules associated with the behavior of the data. To validate the results on the use of the categories of rules from the perspective of the data and their expression levels, a case study is used as a validation for the menu planning system in UCLV canteens, through approach aspects that guide the implementation. Issues related to the design and implementation of the system based on the model-viewcontroller architecture is detailed. And finally acceptance tests performed by use cases are described in detail. This research has practical value because it demonstrates how LPT-SQL tool can be used in the automatic implementation of business rules in an operational DB of an IS.. ii.

(8) Índice. Tabla de contenido INTRODUCCIÓN ............................................................................................................. 1 CAPÍTULO 1. “CARACTERIZACIÓN DE LAS REGLAS DE NEGOCIO Y LA HERRAMIENTA LPT-SQL” ............................................................................................. 7 1.1 DEFINICIONES DE REGLAS DE NEGOCIO ............................................................................................... 7 1.1.1 Tipos básicos de reglas de negocio ............................................................................................ 7 1.1.2 Reglas de negocio ejecutables .................................................................................................... 8 1.1.3 Interfaz para la definición de reglas ........................................................................................ 10 1.1.4 Implementación de reglas de negocio ...................................................................................... 12 1.1.5 Metodología para la implementación de reglas de negocio ..................................................... 12 1.2 REGLAS DE NEGOCIO DESDE LA PERSPECTIVA DE LOS DATOS............................................................ 13 1.2.1 Categorías de reglas ................................................................................................................ 14 1.2.2 Niveles de expresión ................................................................................................................. 14 1.2.3 Patrones de reglas .................................................................................................................... 15 1.2.3.1 Elementos que conforman los patrones ............................................................................................. 15 1.2.3.2 Patrones ............................................................................................................................................. 16. 1.3 IMPLEMENTACIÓN DE UN SI EN EL CONTEXTO DE REGLAS DE NEGOCIO ............................................ 17 1.3.1 Ciclo de vida de un sistema de información ............................................................................. 17 1.3.2 SI con enfoque de reglas de negocio ........................................................................................ 18 1.3.3 Requerimientos del negocio y del SI ........................................................................................ 20 1.4 USO DE LA HERRAMIENTA LPT-SQL ................................................................................................ 22 1.4.1 Herramienta LPT-SQL ............................................................................................................. 22 1.4.2 Repositorio de reglas de negocio ............................................................................................. 23 1.4.3 Operadores del LPT ................................................................................................................. 24 1.4.4 Uso de la herramienta LPT-SQL en diferentes contextos de negocio ...................................... 25 1.5 CONCLUSIONES PARCIALES ............................................................................................................... 26. CAPÍTULO 2. “IMPLEMENTACIÓN DE REGLAS DE NEGOCIO CON LPT-SQL PARA EL ANÁLISIS DEL SISTEMA: UN ESTUDIO DE CASO” ................................. 28 2.1 ESTUDIO DE CASO COMO HERRAMIENTA DE VALIDACIÓN: USO DEL LPT-SQL PARA LA GENERACIÓN DE REGLAS DE NEGOCIO EN EL SISTEMA ................................................................................................... 28. 2.1.1 Transcripción del caso a investigar ......................................................................................... 29. iii.

(9) Índice 2.1.2 Preguntas de estudio y proposiciones ...................................................................................... 31 2.1.3 Contexto ................................................................................................................................... 32 2.1.4 Lógica del análisis ................................................................................................................... 34 2.1.5 Discusión .................................................................................................................................. 39 2.2 IMPLEMENTACIÓN DE LA REGLAS DE NEGOCIO EN EL LPT-SQL ....................................................... 39 2.2.1 Pasos para la implementación de las reglas de negocio .......................................................... 40 2.2.2 Implementación de reglas de negocio ...................................................................................... 44 2.2.3 Beneficios del LPT-SQL en la implementación del sistema .................................................... 45 2.3 CONCLUSIONES PARCIALES ............................................................................................................... 46. CAPÍTULO 3. “DISEÑO, IMPLEMENTACIÓN Y PRUEBAS DEL SISTEMA PARA LA PLANIFICACIÓN DE MENÚS EN COMEDORES UNIVERSITARIOS” ..................... 48 3.1 DISEÑO DEL SISTEMA DE INFORMACIÓN ............................................................................................ 48 3.1.1 Modelado del sistema ............................................................................................................... 48 3.1.1.1 Diagrama de actores de casos de uso................................................................................................. 49 3.1.1.2 Otros diagramas ................................................................................................................................ 54. 3.2 INTERFAZ VISUAL DEL SISTEMA DE INFORMACIÓN ............................................................................ 58 3.2.1 Requerimientos de hardware y software básico para el uso del sistema ................................. 58 3.2.2 Implementación del sistema utilizando el MVC ....................................................................... 59 3.3 ASPECTOS GENERALES SOBRE LA IMPLANTACIÓN MEJORANDO LAS DEFICIENCIAS DEL SISTEMA ANTERIOR ................................................................................................................................................ 61. 3.3.1 Limitaciones existentes en la versión anterior del SI ............................................................... 62 3.3.2 Interacción del SI con la BD que contiene implementaciones de reglas de negocio ............... 63 3.4 CARACTERÍSTICAS DEL USO DEL SISTEMA DE INFORMACIÓN PARA EL CONTROL Y PLANIFICACIÓN DEL MENÚ EN COMEDORES UCLV .................................................................................................................. 64. 3.4.1 Gestión de menús ..................................................................................................................... 65 3.4.2 Gestión de platos ...................................................................................................................... 66 3.4.3 Gestión de productos ................................................................................................................ 66 3.5 PRUEBAS DE ACEPTACIÓN O CASO DE PRUEBA .................................................................................. 67 3.6 CONCLUSIONES PARCIALES ............................................................................................................... 69. CONCLUSIONES GENERALES .................................................................................... 70 RECOMENDACIONES .................................................................................................. 71 REFERENCIAS BIBLIOGRÁFICAS .............................................................................. 72 ANEXOS.......................................................................................................................... 74 iv.

(10) Índice ANEXO 1 DIAGRAMA DE ACTIVIDAD PARA EL CASO DE USO “GESTIONAR PLATOS” ................................ 74 ANEXO 2 DIAGRAMA DE ACTIVIDAD PARA EL CASO DE USO “ACTUALIZAR PRODUCTOS” ....................... 75 ANEXO 3 DIAGRAMA DE NAVEGACIÓN PARA EL CASO DE USO “GESTIONAR PLATOS” ............................. 76 ANEXO 4 DIAGRAMA DE NAVEGACIÓN PARA EL CASO DE USO “ACTUALIZAR PRODUCTOS” ................... 76 ANEXO 5 CHEQUEO DE LA REGLA DE NEGOCIO ....................................................................................... 76 ANEXO 6 CASOS DE PRUEBAS DE ACEPTACIÓN ....................................................................................... 78. v.

(11) Índice. Lista de Figuras Figura 1.1 Metodología ABRD (Ibarra and Bazán, 2013). ............................................. 13 Figura 1.2 Ciclo de vida de un SI. ................................................................................... 18 Figura 1.3 Esquema XSD del repositorio de reglas. ........................................................ 23 Figura 1.4 Parte del esquema XSD del repositorio de generación. ................................. 23 Figura 2.1 Diagrama de Entidad-Relación. ..................................................................... 33 Figura 2.2 Diagrama físico de la base de datos. .............................................................. 36 Figura 2.3 Creación de un repositorio de reglas desde el LPT-SQL. .............................. 40 Figura 2.4 Establecer conexión con la base de datos desde el LPT-SQL. ....................... 41 Figura 2.5 Escritura en el LPT-SQL en lenguaje técnico y natural la regla de negocio. . 41 Figura 2.6 Compilación de la reglas de negocio desde el LPT-SQL. .............................. 42 Figura 2.7 Generación de la reglas de negocio desde el LPT-SQL. ............................... 42 Figura 2.8 Activación de la reglas de negocio desde el LPT-SQL. ................................. 43 Figura 2.9 Control desde el PostgreSQL de las reglas de negocio. ................................. 43 Figura 3.1 Diagrama de actores de casos de uso. ............................................................ 49 Figura 3.2 Diagrama de actividad para el caso de uso “Planificar menús”. .................... 55 Figura 3.3 Diagrama de navegación para el caso de uso “Planificar menús” ................. 56 Figura 3.4 Diagrama de despliegue del sistema .............................................................. 57 Figura 3.5 Diagrama de clases del sistema ...................................................................... 57 Figura 3.6 Patrón de diseño Modelo-Vista-Controlador (Reenskaug and Coplien, 2009). ......................................................................................................................................... 59 Figura 3.7 Vista principal del sistema ............................................................................. 61 Figura 3.8 Estrategia de trabajo. ...................................................................................... 63 Figura 3.9 Mensaje después del incumplimiento de una regla de negocio. ..................... 64 Figura 3.10 Reporte para la solicitud de productos al almacén. ...................................... 66 Figura 3.11 Conexión al almacén para la actualización de los productos. ...................... 67 Figura 3.12 Esquema de la caja negra (Rogers, 2005) .................................................... 67. vi.

(12) Índice. Lista de Tablas Tabla 1.1 Operadores de conjunto para el LPT. .............................................................. 25 Tabla 3.1 Descripción del caso der uso “Gestionar platos”. ............................................ 50 Tabla 3.2 Curso normal del los eventos para el caso de uso “Gestionar platos”. ............ 51 Tabla 3.3 Descripción del caso de uso “Planificar menús”. ............................................ 51 Tabla 3.4 Curso normal de los eventos para el caso de uso “Planificar menús”. ............ 53 Tabla 3.5 Descripción del caso de uso “Actualizar productos”. ...................................... 53 Tabla 3.6 Curso normal de los eventos para el caso de uso “Actualizar productos”. ...... 54 Tabla 3.7 Caso de prueba de aceptación para Gestionar platos ....................................... 69. vii.

(13) Introducción. Introducción La gestión de datos y utilización de la información se ha convertido en una cuestión fundamental por el volumen de datos que se necesitan almacenar en instituciones y empresas. El hombre como actor y beneficiado del surgimiento de la computación y todos los adelantos científicos-técnicos desempeña un papel importante en el desarrollo de diferentes métodos y herramientas para automatizar la gestión de la información; se reconoce así que todo sistema de información constituye una ayuda. en la. informatización de las tareas necesarias de una institución. Un sistema de información (SI) es un conjunto de componentes interrelacionados para recolectar, manipular y diseminar datos e información así como para disponer de un mecanismo de retroalimentación útil en el cumplimiento de un objetivo (Stair and Reynolds, 2000). Los SI tratan de reflejar parte del funcionamiento del mundo real con el objetivo de ayudar a las personas a resolver problemas en las empresas e instituciones. Cada sistema de información debe reflejar las restricciones que existen en el negocio dado, estas restricciones reconocidas comúnmente en la actualidad como reglas de negocio, al mismo tiempo estas actúan como un componente clave en el ciclo de vida de un SI (Ponjuán et al., 2004). Las reglas de negocio son conocidas también como sentencias sobre la forma en que la empresa realiza los negocios; reflejan las políticas de negocio, cuyas finalidades son: satisfacer los objetivos del negocio, los clientes, hacer buen uso de los recursos y respetar las leyes o convicciones de la empresa (Leonard et al., 1998). “ Una regla de negocio es una regla que está bajo la jurisdicción de algún negocio” (Ross, 2009). Por lo que las reglas de negocio pueden ser activadas, modificadas o desactivadas atendiendo a las necesidades del negocio en un momento dado ya que reflejan la forma en que las empresas hacen los negocios. Las empresas modernas están adoptando cada vez nuevos modelos de procesos de negocio para mejorar la competitividad en un mercado que espera una reacción rápida a los cambios de acuerdo a las demandas de los clientes. Estas empresas modernas han 1.

(14) Introducción notado el conflicto inherente entre la fluidez y agilidad que quieren que sus empresas para llevar a cabo y la rigidez y control en el que sus sistemas funcionan con la utilización de las reglas de negocio. La incompatibilidad entre las empresas ágiles y sistemas rígidos anula los esfuerzos hecho para cambiar el negocio, y rápidamente para capitalizar en oportunidades de negocio. De este modo, se verifica que, si una empresa es agresiva o conservadora en la adopción de los cambios, los cambios son inevitables y de que sucedan de una manera continua e implacable. Por lo tanto, las empresas que no consiguen responder con agilidad a los cambios de las reglas de negocio pierden competitividad (Kamada and Mendes, 2005). Por lo que 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 SI de manera menos costosa y eficiente, a través de una mayor independencia entre la inserción de las implementaciones de las reglas de negocio y los programadores de los SI. Con vistas a lograr esta independencia, en el laboratorio de Bases de Datos (BD) del Centro de Estudios Informáticos (CEI), se ha trabajado en la generación automática de reglas de negocios, desde la perspectiva de los datos en recursos activos de bases de datos; como resultado se ha obtenido la herramienta LPT-SQL para insertar automáticamente las reglas en la base de datos del negocio utilizando un repositorio para almacenarlas y un compilador para generarlas. Se han presentado diferentes trabajos con relación a esta herramienta entre los cuales están: “Traductor LPT-SQL para reglas de negocio en bases de datos relacionales” (Calderón Solís, 2011)que logra una herramienta capaz de generar e insertar reglas de negocio de restricción para los gestores SQL Server y PostgreSQL, “Extensión del Traductor LPT-SQL” (Pérez Pedraza, 2012) y el más reciente trabajo es “LPT-SQL v1.3: Herramienta para la generación automática de reglas de negocio en bases de datos relacionales” (Méndez, 2013) a la cual se le agregan nuevas funcionalidades para un mejor uso. La utilidad de la herramienta LPT-SQL puede ser realmente apreciada si se utiliza con efectividad en el desarrollo de un SI. En nuestro caso se puede usar la herramienta LPTSQL ya que permite escribir reglas de un conjunto de categorías con perspectiva de. 2.

(15) Introducción datos en LPT y las traduce automáticamente dentro de la BD del sistema de información correspondiente. Planteamiento del Problema La planificación de menús en los comedores universitarios de la UCLV es una tarea que parece sencilla, pero en realidad tener el control de la planificación de los menús en función de los productos existentes en el almacén, hacer que los platos de un menú cumplan una serie de restricciones necesarias, recuperar en cualquier momento cuáles son los menús ofrecidos en un intervalo de tiempo y otras tareas; requiere de gran habilidad del personal encargado, de manera que se hace dependiente del especialista en alimentación la tarea del diseño de menús ocupando un costo alto de tiempo. Además ante la necesidad de mostrar los documentos de alta del almacén, menús en un mes, gastos realizados, y otras tareas se hacen engorrosos de controlar; especialmente los productos que se consumen cada día y la organización general de esta actividad vital en los comedores universitarios. Así se genera la necesidad de automatizar de la planificación de los menús en los comedores universitarios que dan servicio a estudiantes y trabajadores para lograr un mejor control de los productos así como una mejor organización en la dirección del comedor. El trabajo “Sistema de Información para planificar el menú en comedores UCLV utilizando LPTSQL para generar reglas de negocio” (Aguilar, 2013) constituyó una primera aproximación para resolver esta problemática; luego de usar esta herramienta se encontraron defectos que impiden su uso eficaz entre los cuales se encuentran: anomalías en el diseño del sistema, salida de información incompleta así como insatisfacciones presentadas por el cliente en cuanto al uso del sistema. Así surge la necesidad de implementar una nueva versión del sistema. para tratar todas las. limitaciones existentes, al mismo tiempo que se presenta la necesidad investigativa, de reevaluar el uso de las categorías de reglas de negocios desde la perspectiva de los datos, el lenguaje LPT y la generación de implementaciones de las reglas como recursos de bases de datos en el desarrollo de un SI. Objetivo General. 3.

(16) Introducción Implementar un sistema de información, utilizando el conjunto de categorías de reglas desde la perspectiva de los datos, el lenguaje técnico LPT y su generación automática usando LPT-SQL, a partir del caso de estudio acerca de la planificación de menús de comedores universitarios. Objetivos Específicos 1. Describir el negocio utilizando las categorías de reglas desde la perspectiva de los datos incluyendo las reglas conocidas por el sistema precedente. 2. Escribir las reglas de negocio en la herramienta LPT-SQL para su generación automática dentro de la BD del negocio. 3. Rediseñar las funcionalidades de entrada/salida del sistema en su versión 1.0 a partir de las insatisfacciones presentadas por cliente. 4. Rediseñar el sistema de información utilizando el patrón arquitectónico modelovista-controlador, para mejorar la implementación de la versión anterior. 5. Implementar el sistema SIMCO v1.1, como un caso de estudio del conjunto de categorías de reglas desde la perspectiva de los datos y la herramienta LPT-SQL, facilitando la entrada de datos y los reportes de salida según las necesidades del cliente. Preguntas de investigación 1. ¿Cómo asegurar la vigencia de las reglas de negocio en el sistema de información; usando la herramienta LPT-SQL para la generación automática de las mismas, utilizando el conjunto de categorías de reglas desde la perspectiva de los datos? 2. ¿Cómo lograr un mejor diseño de las funcionalidades de entrada/salida del sistema para la satisfacción del cliente? 3. ¿Qué aspectos se tendrán en cuenta para lograr un mejor diseño del sistema de información para eliminar las limitaciones existentes en el diseño actual? 4. ¿Cómo implementar una nueva versión del sistema para facilitar las operaciones de entrada de datos y los reportes de salida del sistema, presentándose este como un caso de estudio? Justificación 4.

(17) Introducción •. Implicaciones prácticas:.  Los responsables de elaborar el menú necesitan viabilizar su trabajo y mantener memoria digital de este.  Uso de la herramienta LPT-SQL en el desarrollo del sistemas de información para demostrar su utilidad y propagar su uso. Estructura de la tesis En el capítulo 1 del trabajo se recoge algunos de los aspectos generales de las reglas de negocio, las definiciones de reglas de negocio de autores no estudiados en precedentes de la investigación, sus diferentes categorías y patrones de reglas de negocio desde la perspectiva de datos y las consideraciones planteadas en la investigación precedente para la implementación de un sistema de información utilizando la herramienta LPT-SQL. En el capítulo 2 del trabajo se presenta un análisis al sistema de planificacion de comedores como un estudio de casos del conjunto de categorías de reglas de negocio, el uso del lenguaje LPT y la generación automática de las reglas usando la herramienta LPT-SQL. Se implementa la base de datos utilizando la interfaz del gestor para las tablas e interrelaciones en una primera etapa y una segunda estapa se completa con la implementación de las reglas de negocio utilizando la herramienta LPT-SQL para la generación automática de las mismas En el capítulo 3 se realiza el diseño del sistema de información usando análisis orientado a objetos con UML (Lenguaje Unificado de Modelado) de entorno, exponiendo los diagramas para modelar y contruir el sistema de información; se recogen los aspectos generales a considerar para lograr una buena implementacion del sistema de información utilizando el. patrón arquitectónico. Modelo-Vista-Controlador. para el control y. planificación del menú en comedores universitarios así cómo se expone la forma de trabajar y las posibles acciones que se pueden realizar en él, a partir de los casos de uso diseñados .. 5.

(18) Capítulo 1. Capítulo 1. “CARACTERIZACIÓN DE LAS REGLAS DE NEGOCIO Y LA HERRAMIENTA LPT-SQL”. 6.

(19) Capítulo 1. Capítulo 1. “CARACTERIZACIÓN. DE. LAS. REGLAS DE NEGOCIO Y LA HERRAMIENTA LPT-SQL” En este capítulo se exponen aspectos generales sobre las reglas de negocio y sus diferentes aplicaciones en la actualidad, el enfoque de reglas de negocio desde la visión de Malcolm Chisholm, y se centra la atención en la clasificación de reglas desde la perspectiva de datos, además se resume las consideraciones de trabajos anteriores acerca de cómo implementar un sistema de información utilizando la herramienta LPT-SQL, que serán puestas en práctica y reevaluadas posteriormente.. 1.1 Definiciones de reglas de negocio Existen varias definiciones de reglas de negocio, muchos de ellos muy similares y utilizando casi las mismas palabras claves en su definición. Se podrían considerar dos definiciones de reglas de negocio: una que representa el punto de vista comercial y otro que representa la perspectiva de la tecnología de la información (IT) (Kamada and Mendes, 2005). Desde el punto de vista empresarial, una regla de negocio es una premisa que guía el comportamiento de las empresas, en defensa de una política empresarial que fue formulado con respecto a una oportunidad, una amenaza, una fuerza o una debilidad. Desde el punto de vista informático, una regla de negocio es una declaración que define o restringe un aspecto de la empresa o, en otras palabras, define la estructura del negocio y controla el comportamiento de la empresa. En el contexto del negocio se define una regla de negocio como una declaración de la empresa que define o limita algunos aspectos del negocio, de acuerdo con las políticas del negocio y, por lo tanto, influye en el comportamiento de la empresa (Kamada and Mendes, 2005).. 1.1.1 Tipos básicos de reglas de negocio Hoy en día, las empresas se enfrentan a todo tipo de reglas de negocio. Instituciones reguladoras, unidades de negocio, los clientes, los competidores y las condiciones del 7.

(20) Capítulo 1 mercado que generan reglas de negocio que cambia todo el tiempo, lo que se traduce en más reglas de negocio. Las empresas tratan de apoyar las relaciones bastante individualizadas con un número creciente de clientes y socios de productos y servicios con creciente complejidad. Debido a todo esto según (Kamada and Mendes, 2005) las reglas de negocio se pueden clasificar en varios tipo básicos entre los que parecen los más relevantes: . Reglas estructurales de las empresas: estas prescriben criterios de cómo la empresa opta por organizar (es decir, la estructura) las cosas que trata de expresar una necesidad o una posibilidad. Tales reglas expresan criterios para las decisiones correctas, derivaciones o cálculos empresariales. Por ejemplo, la siguiente regla expresa una necesidad: “El cliente tiene al menos uno de lo siguiente: para alquiler reservaciones, un alquiler en curso o de un alquiler completo en los últimos 5 años”.. . Reglas de negocio operativas: son las que rigen la conducta de las actividades empresariales mediante la expresión de una obligación o prohibición. En contraste con las reglas estructurales, reglas operativas son las que se pueden violar directamente por las personas involucradas en los asuntos de la empresa. Por ejemplo, la siguiente regla expresa una prohibición: "Un cliente que aparece intoxicado no se debe dar la posesión de un vehículo de alquiler".. Existe una gran variedad de RN. De acuerdo a su diversidad y complejidad los autores tienden a agruparlas y clasificarlas siguiendo diferentes puntos de vista. En el análisis de las diferentes clasificaciones se revela similitud entre algunas de estas y la complementación de unas y otras. En el marco de este tema se han identificado diversas clasificaciones, entre las que podemos citar las de Solivares, Lowenthal y Morgan enunciadas en (Pérez Alonso, 2008), las de Weiden, Ashwell y Solivares tratadas en (Alonso, 2010) y las de Ross, Ioana Matei y Coti Colop estudiadas en (Pérez Pedraza, 2012).. 1.1.2 Reglas de negocio ejecutables Los diseñadores de aplicaciones han tenido diversos enfoques para la definición de las reglas de negocio, pero estas a menudo han involucrado a programadores programando 8.

(21) Capítulo 1 la lógica de un programa. En algunos casos se ha esperado que analistas, consultantes o incluso los usuarios de negocios escriban la lógica del procedimiento para definir las reglas de negocio Este enfoque de diseño significa que la definición de regla no es diferente de la implementación de regla de negocio (Chisholm, 2004). La definición de una regla es realmente la definición de una forma ejecutable de la regla en alguna forma de lenguaje de programación, el cual puede ser un lenguaje de negocio o un lenguaje scripting desarrollado para los motores de reglas. Este enfoque de "un paso" que consiste en ir directamente a partir de la comprensión de una regla de negocio del usuario a su forma ejecutable, no tiene inconvenientes si se mira desde la perspectiva de un programador. Esto es, después de todo, lo que los programadores hacen. Sin embargo, tiene significativas desventajas de casi todas las otras perspectivas que se pueda imaginar. Por lo tanto el enfoque "de un paso" pasa de ir del entendimiento del usuario de una regla de negocio a su realización en la forma ejecutable no es suficientemente bueno para cualquier motor de reglas de negocio en el mundo de hoy. Lo que se requiere es que el motor de reglas capture la definición de cada regla de negocio y la lógica del programa ejecute esta regla (Chisholm, 2004). La definición de una regla de negocio se encuentra en metadatos estructurados que describen la regla, más que esto, si la regla se refiere a otros objetos de automatización de reglas; los metadatos sobre estos objetos también deben capturase en la definición de estas regla. Si esto ocurre, las reglas pueden estar relacionadas con otra información que es sostenida sobre éstos objetos en otra parte del repositorio de reglas de negocio. Los principales objetos a los que se refieren las reglas de negocio son a tablas y columnas, ya que éstos contienen los datos de negocio en que las reglas funcionan. Los metadatos acerca de las tablas y columnas se almacenan en la aplicación base de datos de metadatos. Por lo tanto, en un mínimo, las definiciones de reglas de negocio deben ser almacenadas en tablas de repositorio que están relacionadas con las tablas en la aplicación de base de datos en los metadatos Según (Chisholm, 2004) se tiene un enfoque de dos pasos que administra reglas de negocio en un motor de reglas:. 9.

(22) Capítulo 1 . El primer paso: Capturar definiciones de reglas como metadatos en tablas de repositorio de reglas de negocio.. . El segundo paso: Usar las definiciones de reglas para crear una forma ejecutable de cada regla de negocio.. Las definiciones de reglas no son sólo relevantes para los motores de reglas de negocio, también son de importancia vital para muchos aspectos de la gestión de reglas que no tienen nada que ver con la ejecución de la regla. Esto podría incluir la comprensión de qué reglas existen en una organización, quien tiene la responsabilidad de ellas, y qué políticas u otros documentos rectores las originaron. Un repositorio es necesario para cubrir esas necesidades, y el Repositorio de Reglas de Negocio podría ser un punto de partida para dicho repositorio. Sin embargo, también se requiere una gran cantidad de metadatos adicionales, que está más allá del alcance de lo que se necesita para un motor de reglas de negocio. Dicho repositorio también debe estar disponible para muchos otros actores más allá de los que participan en la construcción y el uso de un motor de reglas, tales como analistas de negocios y los analistas de sistemas con funciones en la gestión de reglas. Es posible crear un repositorio que sea distinto de cualquier motor de reglas que puede ser utilizado para esta necesidad adicional de gestión de reglas, y que también puede contener los metadatos necesarios para un motor de reglas. Esto puede ser una clara ventaja para muchas organizaciones (Chisholm, 2004).. 1.1.3 Interfaz para la definición de reglas Según (Chisholm, 2004) hay muchas similitudes entre las diferentes reglas de negocios, y es posible agrupar reglas similares en categorías. Estas categorías se denominan tipos de reglas de negocio. Diferentes personas han creado diferentes categorías de reglas. Por ejemplo, las reglas de cálculo pueden ser consideradas como un tipo de regla. Cualquier tipo de regla de negocio que implique un cálculo se puede considerar una regla de cálculo. Otro tipo de regla, comúnmente discutido, es una derivación. Esto sería cualquier regla de negocio donde un valor es derivado de otros valores. Por ejemplo, el Estado Preferido de Cliente puede ser "Platino" "Oro" o "Plata" y el "Platino" se deriva de la siguiente manera:. 10.

(23) Capítulo 1 Si el Cliente ha prestado más de $ 100.000 en los últimos 2 años y no ha estado atrasado en los pagos más de una vez en los pasado 2 años, entonces el Estado Preferido de Cliente recomendable es = "Platino" (Chisholm, 2004). Según el criterio de (Chisholm, 2004) el problema con el inicio desde una perspectiva empresarial, es que no está claro qué tipos de reglas existen desde el principio. Se requiere tanto el análisis como el diseño. El análisis busca entender lo que los usuarios están haciendo y qué vocabulario usan para describir su trabajo. El diseño utiliza esta información para construir pantallas para definir los tipos de reglas de manera que tengan sentido para los usuarios. Lo ideal es que un tipo de regla dada se aplique a diferentes organizaciones que hacen el mismo tipo de trabajo, pero que no pueden ser de interés para todos los negocio. Hay un tipo de regla que existe entre las sociedades de inversión, que algunas empresas llaman "Pay Pro-Rata". El tipo de regla Pay Pro-Rata puede ser utilizada para muchas reglas diferentes en una inversión de asociación. En una asociación de bienes raíces puede ser una regla para asignar los ingresos de hipotecas, otra para asignar los ingresos por comisiones de gestión, otra para asignar ingresos por ventas de edificios, otra para distribuir el ingreso por servicios profesionales, y así sucesivamente (Chisholm, 2004). El enfoque de diseño de una interfaz que se compone de tipos de reglas que son específicos para un negocio subyacente se hacen posibles por el tipo de motor de reglas de negocio que se utilice. El tipo de motor de reglas se basa en la ampliación de una aplicación más general. Los motores de reglas diseñados para generar aplicaciones completas, o que trabajan con cualquier conjunto de datos, no se pueden adoptar fácilmente en este enfoque. Ellos tienden a tener más interfaces de definición de las reglas generales. Es cierto que se requiere un trabajo adicional para analizar, diseñar y construir interfaces para los tipos de reglas específicas para el negocio, pero el resultado es un motor que está estrechamente relacionado con el negocio subyacente, y por lo tanto mucho más fácil para trabajar los usuarios. Este tipo de especialización tiende a necesitar diseños más generales que tienen que lograr la especificidad requerida por exigir más del usuario (Chisholm, 2004).. 11.

(24) Capítulo 1 1.1.4 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. Al considerar cada una de las alternativas para determinar cual funciona mejor en una determinada situación, se debe tener en cuenta: . La viabilidad a largo plazo de su estrategia.. . Rendimiento en tiempo de ejecución.. . El grado de cumplimiento de la regla.. . Flexibilidad.. . La capacidad para mantener las operaciones del negocio.. A continuación se muestran algunas de las técnicas a utilizar enunciadas en (Méndez, 2013): . Lenguajes de programación. . Scripts. . Motor de reglas. . Componentes de reglas. . Mecanismos de base de datos. . Sistemas de flujos de trabajo. . Tablas de consulta. . Las banderas y los códigos mágicos. 1.1.5 Metodología para la implementación de reglas de negocio Luego de haber conocido alguna de las definiciones de reglas de negocio en la actualidad enunciada por varios autores es necesario saber el ciclo de vida de las reglas de negocio en una empresa. Existen diferentes metodologías para la implementación de reglas de negocio; las cuales presentan diferentes etapas. Los sistemas BRMS pueden ser aplicados en diferentes escenarios de implementación, es decir, en un sistema ya implementado donde es necesario realizar una reingeniería con el fin de extraer las reglas (botton-up) o bien un. 12.

(25) Capítulo 1 sistema implementado obteniendo las reglas de negocio realizando relevamientos con los usuarios de negocio (topdown) (Ibarra and Bazán, 2013). Algunas de las actividades y fases de la metodología ABRD (Agile Business Rule Development) como se muestra en la Figura 1.1 son: Rule Discovery: también llamado Business Modeling en la industria, tiene como objetivo desarrollar artefactos simples de modelado como descripciones de reglas de negocio, diagramas de entidad, y los mapas de procesos de negocio. Rule Analysis: el objetivo de la actividad es entender el significado de la regla expresada por la persona de negocios y expertos en la materia y de quitar cualquier ambigüedad y la cuestión semántica o de interpretación. Rule Design: en esta actividad se elaboran diferentes documentos para plasmar las reglas de negocios y comenzar a estrechar la brecha entre el análisis y la implementación de las reglas. Existen herramientas que facilitan el diseño de las reglas. Rule Authoring: es la actividad de creación de las reglas de modo que puedan ser interpretadas por el motor de reglas. Si realizamos una analogía con las metodologías tradicionales sería la actividad de programación de la aplicación. Rule Validation: esta etapa corresponde al test de las reglas en diferentes ambientes y facilidades que presentan las plataformas de BRMS. Rule Deployment: es la actividad de "desplegar" las reglas en los diferentes ambientes definidos por el proyecto.. Figura 1.1 Metodología ABRD (Ibarra and Bazán, 2013).. 1.2 Reglas de negocio desde la perspectiva de los datos Una regla de negocio, básicamente, es una declaración compacta sobre un aspecto del negocio, usando un lenguaje simple, inequívoco, accesible a todas las partes interesadas: 13.

(26) Capítulo 1 el dueño del negocio, el analista, el arquitecto técnico, y así sucesivamente. Las reglas de negocio pueden expresarse de diversas formas, principalmente, según su especificación en el desarrollo de un sistema de información o incluso de acuerdo a la manera en que se introduzcan a este (Morgan, 2002). Según (Morgan, 2002) “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 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.”. 1.2.1 Categorías de reglas En el trabajo de (Calderón Solís, 2011), se trabaja el concepto de reglas de negocio desde la perspectiva de los datos, como aquellas reglas que están involucradas en las operaciones sobre la base de datos del negocio, y presenta la siguiente clasificación en forma de patrones de reglas: . Restricción: Obliga a que se cumplan los requisitos del negocio, contribuyendo a preservar la integridad del mismo.. . 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, 2009).. . Clasificación: Organiza el conocimiento básico del negocio contribuyendo claramente al significado de conceptos, este patrón es conocido también como una regla de definición.. . Notificación: Este patrón informa a los usuarios autorizados del negocio sobre algún conocimiento básico en tiempo real, no restringe estados del negocio, solo lo informa para que se tomen las medidas pertinentes.. 1.2.2 Niveles de expresión Las reglas de negocio pueden expresarse de diversas formas, según su especificación en el desarrollo de un sistema de información o incluso de acuerdo a la manera en que se introduzcan a este. Es necesario señalar que existen varios modos a considerar, pero fundamentalmente, se definen tres niveles de expresión de las reglas de negocio: 14.

(27) Capítulo 1 Informal: este nivel proporciona una sentencia en lenguaje natural, sin un rango limitado de parámetro, tal y como el cliente del negocio desee. Técnico: este nivel combina referencias a datos estructurados, operadores y restricciones con el lenguaje natural, nivel intermedio entre la entrada de la regla y su implementación. Formal: este nivel proporciona sentencias conforme a una sintaxis definida y proporciona la funcionalidad automática de la regla. Durante la escritura de una regla es necesario pasar por cada uno de estos niveles; desde el informal en el momento en que se detecta una posible regla por parte de algún analista del negocio, se pasa al técnico, nivel donde se logra la representación matemática de la regla y se facilita la traducción al formal, a recursos de bases de datos (Morgan, 2002).. 1.2.3 Patrones de reglas Estos patrones son de gran importante para la implementación de las reglas, su uso por una parte restringe el lenguaje informal del usuario y por otra brindan una estructura bien definida que ayuda al tránsito de la regla por los diferentes niveles de expresión, hasta llegar a su implementación. Se ejemplifican los patrones de las reglas desde la perspectiva de los datos en (Aguilar, 2013). Los convenios utilizados para precisar elementos variables de los patrones definidos son los siguientes: . Paréntesis: ( ) Encierran un grupo de ítems.. . Corchetes: [ ] Encierran elementos opcionales.. . Barra Vertical: | Separa términos alternativos.. . Corchetes Angulares: <> encierran términos especiales.. 1.2.3.1 Elementos que conforman los patrones <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. 15.

(28) Capítulo 1 <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 de un atributo o un subconjunto de objetos en una clase existente. <mensaje>: Mensaje de información entre comillas para usuarios autorizados del negocio.. 1.2.3.2 Patrones . Patrón de Restricción. <determinante><sujeto>(no. puede. tener. <características>). |. (puede. tener. <características> solo si <hechos>). . Patrón de Cómputo. <determinante><resultado> [en <sujeto> [para <atributo>] ] es calculado como <algoritmo>. . Patrón de Clasificación. <determinante><sujeto> [no] es definido como <clasificación> [ ( si | a menos que )<característica>]. . Patrón de Notificación. Notificar <mensaje> si <hecho>.. 16.

(29) Capítulo 1 1.3 Implementación de un SI en el contexto de reglas de negocio Un sistema de información (SI) es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su uso posterior, generados para cubrir una necesidad u objetivo. Es cualquier sistema computacional que se utilice para obtener, almacenar, manipular, administrar, controlar, procesar, transmitir o recibir datos, para satisfacer una necesidad de información (Laudon, 2006).. 1.3.1 Ciclo de vida de un sistema de información Según (Laudon, 2006) existen pautas básicas para el desarrollo de un SI para una organización como se muestra en la Figura 1.2 el ciclo de vida de los SI: . Conocimiento de la Organización. Analizar y conocer todos los sistemas que forman parte de la organización, así como los futuros usuarios del SI. Se analiza el proceso de negocio y los procesos transaccionales a los que dará soporte el SI.. . Identificación de problemas y oportunidades. El segundo paso es relevar las situaciones que tiene la organización y de las cuales se puede sacar una ventaja, así como las situaciones desventajosas o limitaciones que hay que sortear o que tomar en cuenta.. . Determinar las necesidades. Se procede a identificar a través de algún método de recolección de información (el que más se ajuste a cada caso) la información relevante para el SI que se propondrá.. . Diagnóstico. En este paso se elabora un informe resaltando los aspectos positivos y negativos de la organización. Este informe formará parte de la propuesta del SI y, también, será tomado en cuenta a la hora del diseño.. . Propuesta. Contando ya con toda la información necesaria acerca de la organización, es posible elaborar una propuesta formal dirigida hacia la organización donde se detalle la presentación del proyecto de desarrollo del SI.. . Diseño del sistema. Una vez aprobado el proyecto, se comienza con la elaboración del diseño lógico del SI; la misma incluye: el diseño del flujo de la información dentro del sistema, los procesos que se realizarán dentro del sistema, 17.

(30) Capítulo 1 el diccionario de datos, los reportes de salida, etc. En este paso es importante seleccionar la plataforma donde se apoyará el SI y el lenguaje de programación a utilizar. . Codificación. Con el algoritmo ya diseñado, se procede a su reescritura en un lenguaje de programación establecido (programación) en la etapa anterior, es decir, en códigos que la máquina pueda interpretar y ejecutar.. . Implementación. Este paso consta de todas las actividades requeridas para la instalación de los equipos informáticos y la instalación de la aplicación (programa) generada en la etapa de Codificación.. . Mantenimiento. Proceso de retroalimentación, a través del cual se puede solicitar la corrección, el mejoramiento o la adaptación del SI ya creado a otro entorno de trabajo o plataforma. Este paso incluye el soporte técnico acordado anteriormente.. Figura 1.2 Ciclo de vida de un SI.. 1.3.2 SI con enfoque de reglas de negocio En los ambientes de negocios ocurren cambios rápidos y constantes con el fin de alcanzar mejoras en el funcionamiento, por lo que las aplicaciones que les dan soporte 18.

(31) Capítulo 1 requieren adaptaciones para cumplir con las necesidades reales y cambiantes de los mismos. Por esto es que se deciden usar las reglas de negocio como un instrumento para desarrollar aplicaciones flexibles y Sistemas de Bases de Datos modificables con facilidad, permitiendo que los procesos puedan mantenerse prácticamente sin cambios (excepto los derivados de las mejoras introducidas en su diseño), ya que la mayor parte de los cambios se derivan de las variaciones del entorno empresarial (mercado, políticas, estrategia, etc.). Con este enfoque, las modificaciones se introducen en las reglas de negocio, y los procesos quedan automáticamente adaptados a los cambios de política (Aguilar, 2013). Muchos SI en computadoras profesionales tienen la idea de que las reglas de negocio deben ser captadas de forma automática. De esta forma 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). Los beneficios más importantes del uso de tales investigaciones para el desarrollo de aplicaciones se obtienen cuando las aplicaciones necesitan ser cambiadas y actualizadas. En estos casos toda la información es almacenada en un único lugar, el repositorio de reglas, pudiendo hacerse modificaciones fácilmente y los componentes pueden ser automáticamente regenerados. Las reglas de negocio son esenciales para el funcionamiento de las empresas (Ross, 2009). La formalización de las reglas de negocio no solo sirve con el objetivo de la automatización, sino también para que las empresas sean conscientes de su propio trabajo. Un negocio oscuro es altamente no estructurado, informal y puede ser ambiguo e inconsistente. El enfoque de reglas de negocio está dirigido a proporcionar a las personas del negocio un control directo sobre el funcionamiento del mismo. Ventajas Varios son los beneficios que pueden derivarse del uso de reglas de negocio en los SI. De todos, según (Lowenthal, 2005) los tres más importantes son los siguientes: . Agilidad: respuesta simple y rápida a los requisitos dinámicos.. . Reducción del Costo: bajo costo para crear o actualizar las partes de aplicaciones que implementan las políticas del negocio 19.

(32) Capítulo 1 . Transparencia: las reglas permiten fácilmente la auditoría que los servicios de software llevan a cabo en sus políticas de negocios correspondientes.. Desventajas En la mayor parte de los sistemas de hoy en día las reglas de negocio están inmersas en los códigos de los programas, lo que implica varias desventajas: . Falta de claridad en las reglas del negocio, ya que las mismas están “embebidas” entre varios módulos y códigos entendibles sólo por los programadores.. . Cada vez que se cambia una regla es necesario recompilar el código de la aplicación.. . Suele ser dificultoso localizar el lugar exacto donde una regla de negocio se encuentra. . Las reglas no pueden ser gestionadas por la gente del negocio.. . Imposibilidad de compartir las reglas de negocio con otras empresas, ya sean proveedores o clientes.. Estas condiciones complican el quehacer de la empresa, reduciendo su capacidad de reacción ante cambios del mercado y haciendo ineficientes sus procesos. Para solucionar este problema, surge la opción de utilizar sistemas de administración de reglas de negocio, los cuales proveen las herramientas necesarias para manejar eficientemente la cambiante lógica del negocio (Aliante Zambrano and Ibáñez Ortiz, 2008).. 1.3.3 Requerimientos del negocio y del SI En el desarrollo de los SI las reglas de negocio juegan un importante papel durante la adquisición de los requisitos que finalmente reúne el sistema. Según (Walsh, 2012) las reglas de negocio son las declaraciones (o condiciones) que deben darse para que una persona pueda llevar a cabo una acción específica relacionada con el funcionamiento del negocio. El tratamiento explícito de los requerimientos durante el desarrollo de los SI, garantiza la adaptabilidad de los mismos; sin embargo, se presentan muchos problemas para identificar, captar y chequear las reglas de negocio, debido básicamente según (Bajec and Krisper, 2006) a las siguientes razones:. 20.

(33) Capítulo 1 . No siempre se dispone de una vía para captar las reglas de forma continua y completa; además, no siempre son un reflejo del negocio y como consecuencia los SI se alejan de los requerimientos del mismo.. . No hay suficiente documentación acerca de las reglas y sus orígenes, no es posible dar un seguimiento a sus modificaciones y se pierde entonces el sentido de la motivación para el enfoque de las reglas de negocio en los requerimientos de los SI.. . No hay forma de conocer la localización exacta de las reglas de negocio en el código de las aplicaciones; no queda claro qué tipos de reglas gobiernan un SI, cuándo se disparan, ni cómo se implementan.. . No se facilita el mantenimiento de la lógica del negocio en la medida que las reglas se encuentran dispersas a través de la lógica de los SI.. . No se facilita el control de las reglas de negocio ya que no hay un almacenamiento único y común para ellas.. Desde la perspectiva del desarrollo de SI todas las reglas que son dinámicas en su forma natural requieren una atención apropiada, por tanto, representan un problema potencial para las necesidades de mantenimiento del SI. Ello conduce a que no solo las reglas que se derivan desde el negocio forman parte del conjunto de reglas de interés, sino también, otras que emergen en el proceso de desarrollo de SI (Bajec and Krisper, 2006). Los requerimientos del negocio son los criterios o condiciones que deben tenerse en cuenta para que el SI tenga éxito en satisfacer las necesidades del usuario, estos a la vez capturan lo que el usuario debe hacer para implementar y / o darle cumplimiento a una regla de negocio, un requerimiento de negocio no puede ser válido si contradice o rompe una regla de negocio existente (Walsh, 2012). Por lo general se centran en el "qué" y no el "cómo". Mientras que requerimientos del sistema definen lo que se debe hacer para asegurar los requerimientos del negocio, centrándose en el "cómo" asociado con (el "qué"). Los requerimientos del negocio y sus restricciones (BRC) forman un grupo considerado por (Khan et al., 2004) para conformar los requisitos del sistema.. 21.

(34) Capítulo 1 1.4 Uso de la herramienta 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 especificado en lenguaje LPT en bases de datos de negocio utilizando un repositorio para almacenarlas y un compilador para generarlas.. 1.4.1 Herramienta LPT-SQL La herramienta LPT-SQL utiliza el LPT (lenguaje de patrones técnico) que no es más que una expresión matemática de los elementos que conforman los patrones de reglas cercanas a los datos, para ello consta de una notación específica, operadores aritméticos, lógicos y funciones que en conjunto conforman un formalismo capaz de representar reglas de negocio. Su núcleo es la notación punto para la navegación entre las entidades y el acceso a sus atributos, lo cual según se refiere en (Zimbrão et al., 2002) le brinda consistencia Los patrones de reglas de negocio son un punto importante en el planteamiento de las mismas. Surgen con la necesidad de captar las reglas en un lenguaje natural en forma de patrones y sus diferentes tipos cubren los requerimientos del negocio. Pero estos patrones pierden sentido si no pueden ser expresados técnicamente para una futura implementación (Pérez Alonso, 2008). Los fundamentos de este lenguaje aparecen en (Pérez Alonso, 2008) como un lenguaje técnico. Dada la creciente necesidad de aceptar variantes cada vez más complejas en (Calderón Solís, 2011) se define el LPT para expresar reglas de negocio , en función de las tablas, sus atributos, y las interrelaciones para BD relacionales basado en los patrones de reglas pertenecientes a la clasificación denominada desde una perspectiva de datos. Estas reglas son traducidas como recursos de base de datos activos 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.. 22.

(35) Capítulo 1 1.4.2 Repositorio de reglas de negocio El repositorio está formado por una o más reglas como puede verse en la Figura 1.3. Se mantienen los atributos inherentes a cualquier regla, léase id (identificador), estado y última fecha. Se tiene el atributo tipo para identificar el tipo de regla así como la versión, de esta forma se permite que el repositorio acepte varios tipos de reglas (Calderón Solís, 2011).. Figura 1.3 Esquema XSD del repositorio de reglas. Durante el proceso de traducción de las reglas se utiliza otro repositorio que llamaremos repositorio de generación; también con formato XML. La función de este repositorio es almacenar la información necesaria para generar la regla. En la Figura 1.4 se muestra el esquema general de este repositorio.. Figura 1.4 Parte del esquema XSD del repositorio de generación. 23.

(36) Capítulo 1 Como se puede observar, el repositorio de generación está formado igualmente por varias reglas que son identificadas por su id y tipo. Las reglas almacenadas en este repositorio son un subconjunto de las reglas que contiene el repositorio de reglas. De cada regla se almacena una expresión SQL que va a ser el cuerpo de la implementación de la regla y la lista de eventos que se refiere a los eventos que pudieran infringir la regla (Pereira Toledo, 2009). Cada elemento de esta lista tiene como atributo el nombre de una tabla y registra los eventos que de ocurrir sobre esa tabla pueden desencadenar una violación. Los eventos pueden ser: INSERT, UPDATE o DELETE. Después de la extracción de la regla y su compilación, esta debe almacenarse en un repositorio de generación. Después de la generación de la regla y su implementación, se obtiene la representación formal de la regla y se actualiza el repositorio añadiéndole esta representación, de acuerdo a uno de los enfoques analizados, siguiendo el esquema definido previamente (Calderón Solís, 2011).. 1.4.3 Operadores del LPT Los tipos de operadores básicos utilizados por el LPT para construir sentencias complejas son los operadores Lógicos (OR, AND, NOT, XOR), Aritméticos(+,-,*,/) y de Comparación(<,>,<=,>=,=,<>) Al utilizar la notación punto es posible obtener múltiples elementos. Estas colecciones necesitan ser manipuladas para expresar reglas de negocio, por lo que son necesarios operadores de conjuntos del lenguaje. El resultado de aplicar un operador de conjunto a un elemento múltiple es un elemento individual, típicamente un valor. Los operadores de conjunto definidos para el LPT son los siguientes: Operadores. Significado. SIZEOF<colección>. Retorna cuántos elementos contiene la colección de elementos.. EMPTY<colección>. Retorna verdadero si la colección no contiene elementos.. EXISTS(<elemento>,. Retorna verdadero si un elemento existe en una. colección>). colección. 24.

(37) Capítulo 1 AVG<colección>. Retorna el promedio de una colección numérica.. SUM <colección>. Retorna la suma de una colección numérica.. MÍN <colección>. Retorna el mínimo de una colección numérica.. MÁX <colección>. Retorna el elemento máximo de la colección.. AVGDIF <colección>. Retorna el promedio de los elementos diferentes de una colección numérica.. SIZEOFDIF <colección>. Retorna cuántos elementos diferentes contiene la colección de elementos.. SUMDIF <colección>. Retorna la suma de los elementos diferentes de una colección numérica.. Tabla 1.1 Operadores de conjunto para el LPT.. 1.4.4 Uso de la herramienta LPT-SQL en diferentes contextos de negocio El trabajo a desarrollar se estructuró primeramente en dos etapas. 1ra: Obtener todas las reglas de negocio, que resultan de la interacción con los clientes. 2da: Expresar las reglas de negocio en lenguaje técnico y usarlas como entrada al software LPT-SQL. En la primera fase se realiza una revisión de la implementación física, de modo que se garantice la correspondencia necesaria del diseño físico con los requerimientos de los datos persistentes del sistema de información del control de trasplante renal, además de listar todas las reglas, clasificadas de restricción en el negocio. En la segunda etapa, primeramente se expresan las reglas de negocio en un patrón de lenguaje técnico, y se utiliza la aplicación para generarlas (Boggiano-Castillo et al., 2011). Posteriormente para la implantación del un sistema de información con la utilización del LPT-SQL basándose en lo descrito anteriormente se tienen los siguientes pasos: 1. Describir la problemática del negocio con el objetivo de diseñar la BD y a su vez el SI. 25.

(38) Capítulo 1 2. Descubrir entidades del negocio y las reglas de negocio en el lenguaje del especialista. 3.. Escribir las reglas que pueden clasificarse en las categorías de reglas concebidas desde la perspectiva de los datos con los patrones de reglas adoptados.. 4. Reiterar paso 2 y el paso 3 las veces necesarias para obtener el diseño conceptual de la base de datos para posteriormente manejar el funcionamiento del SI 4.1.. Garantizar para cada entidad del negocio, una tabla de la base datos física.. 4.2.. Los nombres de las tablas y sus atributos deben corresponderse con las entidades y características del negocio que representan.. 5. Escribir las reglas en lenguaje LPT e insertarlas en la BD.. 1.5 Conclusiones parciales Existen varias definiciones de reglas de negocio que son reconocidas actualmente, algunas están bajo el enfoque empresarial, otras categorías de reglas basadas en el sistema de información; en el caso de Chisholm se abordan las reglas desde el análisis y diseño del sistema a partir de los datos. Las categorías de reglas de negocio desde la perspectiva de los datos, en que se basa esta investigación, trata las reglas de negocio asociadas al comportamiento de los datos del negocio, que en última instancia se conciben en un contexto relacional.Cada una de estas categorías está identificada con un patrón de regla, que se expresa en un nivel informal o natural estructurado, entendible por las personas del negocio y del sistema; para un nivel técnico de expresión de las reglas se usa el lenguaje LPT, con facilidades de uso por el personal de la información por el uso intuitivo de la notación punto, a partir de los patrones en lenguaje natural estructurado. La herramienta LPT-SQL permite generar automáticamente las reglas de negocio expresadas en LPT en base de datos activas, utilizando la categoría de reglas desde la perspectiva de los datos, un repositorio para almacenarlas y un. compilador para. generarlas, lo que contribuye a la implementación de SI utilizando RN en el diseño y generación de la BD que utiliza el sistema.. 26.

(39) Capítulo 2. Capítulo 2. “IMPLEMENTACIÓN DE REGLAS DE NEGOCIO CON LPT-SQL PARA EL ANÁLISIS DEL SISTEMA: UN ESTUDIO DE CASO”. 27.

(40) Capítulo 2. Capítulo 2. “IMPLEMENTACIÓN DE REGLAS DE NEGOCIO CON LPT-SQL PARA EL ANÁLISIS DEL SISTEMA: UN ESTUDIO DE CASO” En el presente capitulo se presenta un análisis al sistema de planificación de comedores como un estudio de casos del conjunto de categorías de reglas de negocio desde la pespectiva de los datos, el uso del lenguaje LPT y la generación automática de las reglas usando la herramienta LPT-SQL. En esta sección se implementa la base de datos, que se completa con la implementación de las reglas de negocio a partir de la herramienta LPTSQL para la generación automática de las mismas.. 2.1 Estudio de caso como herramienta de validación: Uso del LPT-SQL para la generación de reglas de negocio en el sistema El estudio de caso es una herramienta de investigación ya analiza temas actuales, fenómenos contemporáneos, que representan algún tipo de problemática de la vida real, desempeña un papel importante en el área de la investigación ya que sirve para obtener un conocimiento más amplio de fenómenos actuales y para generar nuevas teorías, así como para descartar las teorías inadecuadas (Carazo, 2006). El estudio de casos constituye un importante método para la informática en la actualidad (Chen et al., 2010) pues permite estudiar con profundidad una gran cantidad de experiencias diferentes. Para el estudio de casos, cada caso no se ve como una muestra, sino como un experimento (Yin, 2009). Existen evidencias recientes de estudio de casos como método de investigación y validación en la informática (Moreno-Espino et al., 2013). Para presentar un estudio de caso se presenta una problemática que cubre la necesidad de desarrollar un SI, particularmente un sistema de información transaccional, se extraen los términos e identidades del negocio y posteriormente se recolectan las reglas de 28.

(41) Capítulo 2 negocio haciendo énfasis en aquellas desde la perspectiva de los datos a través de la entrevista del analista con los expertos del negocio, antes de diseñar e implementar la base de datos y la interfaz del sistema. Para realizar un estudio de caso se tiene en cuenta un conjunto de pasos presentados a continuación: . Transcripción del caso a investigar: Aquí se redacta el caso o fenómeno a investigar, de la forma más minuciosa y clara posible. Es importante que la transcripción del caso sea objetiva y sin modificaciones (Carazo, 2006).. . Pregunta(s) de estudio y proposiciones: Se realizan las preguntas en las que se enfoca cada caso, como orientación de la investigación en el caso. Se incluyen las proposiciones a verificar en cada caso.. . Contexto: Se presenta el contexto del caso, comparando con otros trabajos de la literatura y se justifica la relevancia del caso. Se expone la unidad de análisis de cada caso según(Moreno-Espino et al., 2013).. . Lógica de análisis: Constituye una explicación de la lógica que relaciona los datos con las proposiciones. En esta sección, la fuente de la información presentada es la observación directa o la observación participativa según la clasificación de (Yin, 2009).. . Discusión: Explica los criterios para interpretar los hallazgos. En cada caso se observa cómo las propuestas conducen a los resultados esperados de una manera que puede ser repetida luego en otras situaciones, se justifican las condiciones que permiten generalizar el uso de las propuestas teniendo en cuenta cómo las condiciones de cada experimento limitan o no esta generalización.. 2.1.1 Transcripción del caso a investigar Se desea implementar un sistema de información para la planificación del menú en los comedores en la Dirección de Alimentación de la UCLV, para procesar y manejar toda la información de los alimentos que consumen sus estudiantes y profesores. Un menú se elabora a partir de un registro oficial de platos. En la realización del proceso de planificación del menú es necesario contar con el “registro de ingredientes. 29.