Sistema de Información para planificar el menú en comedores UCLV utilizando LPTSQL para generar reglas de negocio

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. Título: Sistema de Información para planificar el menú en comedores UCLV utilizando LPTSQL para generar reglas de negocio Autora: Autora Daimara Sevilla Aguilar. Tutor: Tutor Msc. Martha Beatriz Boggiano Castillo Laboratorio de Centro de Estudios de Informática 2013 “Año 55 de la Revolución”. 1.

(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____________. 2.

(3) Pensamiento. 5fÉÄÉ ÑxÜwâÜt çxá ÑtÜt u|xÇ Ät Ü|Öâxét Öâx áx vÜxt? ç Ät Ä|uxÜàtw Öâx áx vÉÇÖâ|áàt? vÉÇ Ätá ÑÜÉÑ|tá ÅtÇÉáA5 ]Éá° `tÜà• 3.

(4) Dedicatoria. A toda mi familia por su apoyo brindado en todos estos años, en especial a mis abuelos de crianza, a mi mamá y a mi tía.. 4.

(5) Agradecimientos. A mi tutora Martha Beatriz que sin su supervisión no lo hubiera podido lograr. A mi oponente Ariel Calderón y a Ariel Alba que me han ayudado siempre que lo he necesitado. A toda mi familia: a mis padres, a mis hermanos, a mi tía y a mis abuelos; que me dieron fuerza en todo momento para seguir adelante. A mi novio Alejandro que ha sido el mayor apoyo que he tenido y lo mejor que me ha pasado en la vida. A mis amigas y amigos de la universidad. A todas las personas que de una forma u otra me han ayudado.. 5.

(6) Resumen. Resumen Para desarrollar Sistemas de Información (SI) en los que se modele e implemente, con adecuada fidelidad, las políticas del negocio que ayuden a controlar este, es ventajoso aplicar el enfoque de reglas de negocio, y de esta manera garantizar que la inserción y modificación de las reglas se realizarán de manera automática. Una de las maneras para implementar un SI usando reglas de negocio, es a través de un tipo de herramienta independiente de los gestores de datos, pero que genera recursos de bases de datos.. En el Laboratorio de Base de Datos del Centro de Estudios Informáticos (CEI) de la UCLV se trabaja en un proyecto para la generación automática de reglas de negocio en bases de datos relacionales. Como resultado de esto se ha obtenido una herramienta de software, LPT-SQL. El uso de la herramienta por parte de un analista debe disminuir el costo de tiempo y recursos en la implementación de las reglas, ya que se logra automáticamente. El propósito de este trabajo es validar los resultados producidos por la herramienta. Para ello se hace necesario una aplicación cuya interfaz de entrada realice las operaciones de inserción y actualización en una base de datos donde hayan sido implementadas reglas de negocio Como resultado se obtiene un Sistema de Información para control y planificación del menú 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.. 6.

(7) Abstract. Abstract For developinginformation systems(IS)in whichis modeledand implementedwithadequatefidelity, business policiesthat help controlthis; it is advantageous to applythebusiness rulesapproach, andthis. way. to. guaranteethat. the. insertionand. modificationof. the. ruleswill. be. madeautomatically.One wayto implement abusiness rulesusingSIisthrough anindependenttool typedata managers, but generatingdatabaseresources. In theDatabaseLaboratoryof the Centre forInformation Studies(CIS) oftheUCLVworking ona project for theautomatic generation ofbusiness rules inrelationaldatabases.As a resultis obtaineda software tool, LPT-SQL. The useof the toolby ananalyst shouldreduce the costof time and resourcesin. implementingthe. rules,andthat. is. achievedautomatically.. The purposeof this workis to validatethe results produced bythe tool.To do thisit is necessary toan application whoseinput interfaceperforminsert operationsina databasewhere they have beenimplementedbusiness rules. The result isan information systemforplanning and controlof the menu inthe Directorate for FoodofUCLV, to process andhandle allfoodconsumed by itsstudents and workers.. 7.

(8) Índice. Contenido INTRODUCCIÓN ........................................................................................................................ 10 CAPÍTULO I: REGLAS DE NEGOCIO DESDE LA PERSPECTIVA DE DATOS PARA UN SISTEMA DE INFORMACIÓN BASADO EN REGLAS.......................................................... 14 1.1 ENFOQUE DE REGLAS DE NEGOCIO ....................................................................................... 14 1.1.1 Sistemas de Información con enfoque de Reglas de Negocio ..................................... 15 1.2 REGLAS DE NEGOCIO, REQUERIMIENTOS DEL NEGOCIO Y REQUERIMIENTOS DEL. SISTEMA DE. INFORMACIÓN ............................................................................................................................ 16. 1.3 REGLAS DE NEGOCIO DESDE LA PERSPECTIVA DE DATOS...................................................... 18 1.3.1Categorías de reglas ...................................................................................................... 18 1.3.2 Niveles de expresión .................................................................................................... 19 1.3.3 Patrones de reglas ........................................................................................................ 19 1.3.4 Lenguaje de Patrones técnico LPT .............................................................................. 21 1.4 REGLAS DE. NEGOCIO Y DISEÑO DE BASE DE DATOS ............................................................. 22. 1.5 HERRAMIENTAS UTILIZADAS PARA LA CONSTRUCCIÓN DEL SISTEMA ................................... 24 1.5.1 Recursos del PostgreSQL utilizados para el manejo de datos ..................................... 24 1.5.2 Traductor LPTSQL ...................................................................................................... 26 1.6 PROBLEMÁTICA DEL MENÚ COMEDOR ................................................................................ 29 1.7 CONCLUSIONES DEL CAPÍTULO ............................................................................................ 31 CAPÍTULO 2: DISEÑO DEL SISTEMA E IMPLEMENTACIÓN DE LAS REGLAS DE NEGOCIO EN LPT ...................................................................................................................... 33 2.1 ANÁLISIS Y DISEÑO DEL SISTEMA ........................................................................................ 33 2.1.1Términos del negocio y reglas de negocio .................................................................... 33 2.1.2. Diagrama de actores casos de uso ............................................................................... 36 2.1.3 0tros diagramas que componen el modelado del software .......................................... 39. 8.

(9) Índice. 2.2 IMPLEMENTACIÓN DE LAS REGLAS EN EL LTP-SQL Y LOS RECURSOS QUE GENERA EN LA BASE DE DATOS. ........................................................................................................................ 42 2.2.1 Beneficios del uso del LPT-SQL en la implementación del sistema ........................... 50 2.3 CONCLUSIONES. PARCIALES ................................................................................................. 51. CAPÍTULO 3. IMPLEMENTACIÓN Y CARACTERÍSTICAS DEL USO DEL SISTEMA DE INFORMACIÓN PARA EL CONTROL Y PLANIFICACIÓN DEL MENÚ EN COMEDOR UCLV. ........................................................................................................................................... 53 3.1 INTERFAZ VISUAL DEL SISTEMA. .......................................................................................... 53 3.2 ETAPA DE IMPLEMENTACIÓN. .............................................................................................. 54 3.2.1 Principales Bibliotecas Utilizadas................................................................................ 54 3.2.2 Interacción del SI con la BD que contiene implementaciones de RN. ........................ 55 3.3 CARACTERÍSTICAS DEL USO DEL SISTEMA DE INFORMACIÓN PARA EL CONTROL Y PLANIFICACIÓN DEL MENÚ EN COMEDORES UCLV. ................................................................... 56. 3.3.1 Planificar menú ........................................................................................................... 57 3.3.2 Gestión de Platos.......................................................................................................... 60 3.3.3 Gestión de Productos ................................................................................................... 62 3.4 CONCLUSIONES PARCIALES .................................................................................................. 63 CONCLUSIONES ........................................................................................................................ 64 RECOMENDACIONES ............................................................................................................... 65 REFERENCIAS BIBLIOGRAFÍA .............................................................................................. 66 ANEXOS ...................................................................................................................................... 69. 9.

(10) Introducción. Introducción Los Sistemas de Información (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 (los negocios), en la actualidad la carencia de sistemas de información automatizados pueden conducir a realizar el trabajo de manera ineficiente. Cada sistema de información debe reflejar las restricciones que existen en el negocio dado, muchas de estas restricciones se denominan reglas de negocio. Las reglas de negocio reflejan la forma en que las empresas hacen los negocios. Al mismo tiempo actúan como un componente clave en el ciclo de vida de un SI; todo SI está obligado a reflejar las reglas de negocio del negocio que modela. Según (Ross 1997), “los propietarios del negocio tratan las RN de una manera diferente a los desarrolladores”. Para los propietarios, no son más que directivas que tienden a influenciar o guiar el comportamiento del negocio. Mientras que para los desarrolladores, las reglas son vistas como estructuras dispersas en la lógica del programa, que no siempre surgen desde las políticas del negocio. 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 y los programadores de los SI, de modo que un cambio en las reglas no implica contratar servicios de mantenimiento de los sistemas. En nuestro Centro de Estudios Informáticos (CEI) se desarrolla un campo de investigación con respecto a la generación automática dereglas de negocio en los SI y específicamente dentro de las BD. Gracias a los esfuerzos realizados por estudiantes de ciencia de la computación se han obtenido grandiosos trabajos, entre los más recientes se encuentra la tesis de Ariel, (Calderón Solís 2011) como resultado se obtiene eltraductor LPT-SQL para reglas de negocio en bases de datos relacionales y posteriormente se desarrolla la tesis de Rolando(Pedraza 2012), que constituye una extensión de esta herramienta, agregándole nuevas funcionalidades. 10.

(11) Introducción. Para poder diseñar e implementar las reglas en un SI deben ser formalizadas, a través de esta herramienta el trabajo es menos costoso, ya que permite escribir reglas de un conjunto de categorías con perspectiva de datos en Lenguaje de Patrones Técnicos (LPT) y las traduce automáticamente dentro de la Base de Datos del sistema correspondiente. Actualmente se presenta en la UCLV la necesidad de agilizar la programación del menú en los comedores que dan servicio a estudiantes y trabajadores. Ante esta situación con el objetivo de obtener un SI, existe la motivación de enfrentar el trabajo desde la extracción de las RN y la implementación de la BD utilizando la herramienta LPTSQL.. Planteamiento del problema •. La temática Generación automática de reglas de negocio en bases de datos relacionales, desarrollada en el Laboratorio de Bases de datos, ha sido tratada en trabajos de investigación anteriores, estos reportan a la fecha. una herramienta de software. denominada, LPT-SQL, que constituye un traductor de reglas de negocio que permite generar automáticamente las reglas de negocios especificada en lenguaje LPT como recursos de base de datos activas basados código SQL. Todas las funcionalidades son a través de un repositorio de reglas descrito en un documento XML. Actualmente el alcance del uso de la herramienta LPT-SQL se limita a la generación automática de las reglas en una base de datos ya creada, sin tener en cuenta el comportamiento de la interfaz de entrada de un sistema de información (SI) que se encargue de realizar las entradas y actualizaciones de los datos.. Objetivo General •. Crear un sistema de información para la confección universitario. aplicando el traductor LPT-SQL. para. del menú en el comedor demostrar la interacción del. subsistema de entrada de datos con los mecanismos de chequeo de las reglas de negocio generadas automáticamente sobre bases de datos en el gestor PostgreSQL.. 11.

(12) Introducción. Objetivos Específicos 1. Implementar la base de datos a partir del diseño de la misma teniendo en cuenta la lógica del negocio. 2. Usar la herramienta LPT-SQL para la generación automática de las RN clasificadas como “cercanas a los datos” en la BD implementada. 3. Implementar la interfaz de entrada de datos teniendo en cuenta el tratamiento las reglas involucradas en las operaciones sobre los datos.. Preguntas de investigación 1. ¿Qué aspectos deben tenerse en cuenta para implementar la base de datos del negocio? 2. ¿Logran implementarse correctamente las reglas de negocio como recursos de bases de datos usando la herramienta LPT-SQL? 3. ¿Cómo el sistema de información realiza el chequeo de las reglas de negocio durante la entrada de datos?. Justificación •. Los responsables de elaborar el menú necesitan viabilizar su trabajo y mantener memoria digital de este.. •. Se necesita usar la herramienta LPT-SQL en el desarrollo de un Sistema de Información para demostrar su utilidad y propagar su uso.. Hipótesis de investigación •. Es posible crear un sistema de información cuya interfaz de entrada realice las operaciones de inserción en una base de datos donde hayan sido implementadas reglas de negocio automáticamente en forma de recursos de código SQL por la herramienta LPT-SQL.. 12.

(13) Capítulo 1. Capítulo I: “Reglas de negocio desde la perspectiva de datos para un sistema de información basado en reglas”.. 13.

(14) Capítulo 1. Capítulo I: Reglas de negocio desde la perspectiva de para un sistema de información basado en reglas. Este capítulo recoge definiciones de Reglas de Negocios(RRNN)un conjunto de categorías de reglas desde la “perspectiva de datos”, así como los fundamentos para diseñar la base de datos del negocio. Se presentan además diferentes herramientas utilizadas para la construcción del sistema , enfatizando en el uso del LPTSQL.. 1.1 Enfoque de reglas de negocio El enfoque de reglas de negocio (ERN) conocido en inglés BRA, se presenta como una forma efectiva de identificar el núcleo de los requerimientos del negocio.(Gottesdiener 1 9 9 7). "Las reglas de negocio (RRNN)", literalmente, es lo que se utiliza para hacer funcionar un negocio. En sentido general, las reglas de negocio son las que orientan un negocio en la gestión de las operaciones del día a día. En el mundo de hoy, cada proceso de negocio organizado tiene reglas de negocio. El BRA es un enfoque que permite el manejo de las RRNN independiente de las aplicaciones que las hacen cumplir, el término ha sido utilizado por diferentes autores. Según (Morgan, 2002), plantea que: “Básicamente, una regla de negocio es una declaración compacta sobre un aspecto del negocio. Es una restricción en el sentido que una regla de negocio decide lo que debe o no debe hacerse en cada caso. En cualquier punto particular, debe ser posible determinar que la condición que implicó la restricción es verdad en un sentido lógico; si no, tomar la acción necesaria.” En (SCOTT 2011), se presenta una RN como aquello que define o limita un aspecto del negocio con el objeto de establecer una estructura o un grado de influencia que condiciona el comportamiento de los actores del negocio. A menudo las RN están focalizadas en el control, en la forma de realizar los cálculos, otras permiten establecer las políticas, y así se tienen en cualquier actividad del negocio, que requiera que la gente actúe de una forma pre-establecida. Según (Ross 2012), una regla de negocio es una proposición tomada para ser verdad, en otras palabras, un hecho. Los hechos se basan en los conceptos expresados por los términos y los. 14.

(15) Capítulo 1. términos expresan conceptos empresariales. Por lo cual las reglas de negocio pertenecen a las poblaciones de los hechos y por tanto a los modelos de hechos.. En el estudio de las reglas de negocio se aprecia cómo con el enfoque centrado en datos de Date (DATE 2000), se defiende la idea de que con las reglas de negocio se asegura que los hechos representados en bases de datos no pueden ser corruptos por actualizaciones que violen las reglas, ya que cuando se realiza una actualización se ejecuta la regla y se chequea, si es violada, la actualización es abortada. De manera general podemos definir una Regla de Negocio como “una directiva, destinada a influenciar o guiar el comportamiento del negocio, que apoya una determinada política de negocio. (Group 2009) 1.1.1 Sistemas de Información 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 requieren adaptaciones para cumplir con las necesidades reales y cambiantes de los mismos. Por esto es que se deciden usar las RRNN 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. Muchos SI en computadoras profesionales tienen la idea de que las RRN deben ser captadas en 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. 15.

(16) Capítulo 1. Las RRNN son esenciales para el funcionamiento de las empresas (Ross 2003). 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 RN está dirigido a proporcionar a las personas del negocio un control directo sobre el funcionamiento del mismo. Varios son los beneficios que pueden derivarse del uso de RN en las aplicaciones. De todos, según Lowenthal(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 Transparencia: las reglas permiten fácilmente la auditoría que los servicios de software llevan a cabo en sus políticas de negocios correspondientes. 1.2 Reglas de negocio, requerimientos del negocio y requerimientos del. sistema de. información 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. Los requerimientos del negocio son los criterios o condiciones que deben tenerse en cuenta para que el software 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, Kapurubandara et al. 2004) para conformar los requisitos del sistema. Prácticamente el tipo de regla de restricción según este autorpuede involucrar diferentes categorías de. 16.

(17) Capítulo 1. restricciones para una relación binaria entre dos entidades que puede ser determinada por una de las cinco categorías sobre las restricciones, que son las siguientes: Categoría (i) BRC: atributos de una sola entidad; Categoría (ii) BRC: atributos de ambas entidades; Categoría (iii) BRC: atributos de la propia relación; Categoría (iv) BRC: Los atributos de la relación, más atributos de una única entidad; Categoría (v) BRC: atributos de la propia relación y por lo menos un atributo de ambas entidades participantes. Las bases de datos que contienen las entidades empresariales, sus atributos y la topología de la relación entre las entidades son usadas por los analistas para hacer las decisiones del diseño basados en los requerimientos del negocio y sus limitaciones. Los BRC (restricciones y reglas de negocio), expresan también reglas de comportamiento que permiten ayudar a conformar las funcionalidades del sistema. En el diseño de las bases de datos, se debe tener en cuenta que el modelo Entidad Relación (ER), se utiliza para modelar un sistema de base de datos en términos de entidades, atributos y relaciones. Este modelo es suficiente para representar la problemática básica del mundo, como entidades y sus relaciones. Sin embargo, tiene características limitadas para captar y expresar los requisitos del negocio y obstáculos bajo las condiciones y políticas que rigen una relación. Muchas políticas de la lógica del negocio no pueden ser representadas en el diagrama del modelo ER; sin embargo pueden ser expresadas como reglas de negocio, que en última instancia deben ser implementadas en el sistema. Algunas de las restricciones pueden ser expresadas como atributos, en el modelo ER que pasarían a ser atributos de la base de datos resultante. En el proceso de transformación de diagrama ER a diagrama relacional, estas restricciones aparecen sobre atributos del diagrama lógico relacional. En(Calderón Solís 2011) y (Pedraza 2012) se tratan las reglas de negocio que pueden abarcar más de dos relaciones ( tablas) que se interrelacionan en la base de datos. En este trabajo las entidades del negocio del diagrama ER, se presentan como tablas de la base de datos, asimismo se conforman nuevas tablas cuyo origen son las interrelaciones de las entidades correspondientes.. 17.

(18) Capítulo 1. 1.3 Reglas de negocio desde la perspectiva de datos 1.3.1Categorías de reglas Esta clasificación es el fundamento de las investigación “Generación automática de reglas de negocio en bases de datos relacionales”, tiene como precedente el trabajo “Reglas de Negocio en Bases de Datos Relacionales” (Alonso 2010) que están inspiradas en la clasificación de RN que da Tony Morgan en (Morgan 2002), donde expresa que la forma más conveniente de crear sentencias de regla es seleccionar patrones adecuados desde una pequeña lista disponible. Esta clasificación fue modificada posteriormente en el trabajo de (Calderón Solís 2011), en el cual se trabaja el concepto de RN “desde la perspectiva de 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. Ejemplo: Un menú no puede tener más de 15 tipos de platos. Cómputo Su objetivo es calcular un valor determinado en el negocio, y su resultado es numérico. Este patrón comparte grandes semejanzas con el patrón de clasificación(Ross 2010). Ejemplo: La cantidad total de los ingredientes a consumir es calculada como la cantidad normada multiplicada por la cantidad de comensales por la cantidad de raciones. 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.. 18.

(19) Capítulo 1. 1.3.2 Niveles de expresión De acuerdo con (Morgan 2002) 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: 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. 1.3.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 datos”. 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 como los mostrados en la siguiente tabla.. 19.

(20) Capítulo 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. <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.. 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>. 20.

(21) Capítulo 1. 1.3.4 Lenguaje de Patrones técnico LPT El LPT es un lenguaje técnico para expresar reglas de negocios, en función de las tablas ,sus atributos, para bases de datos relacionales, basado en los patrones de reglas definidos en (Alonso 2010). Este lenguaje técnico es simple y su funcionalidad se resume a expresar en nivel técnico, tipos de patrones de reglas de negocio, que serán convertidos a recursos en lenguaje SQL para bases de datos. Se tiene en cuenta que las reglas son formuladas a partir de las relaciones o tablas de la base de datos, las tablas que representan términos del vocabulario del negocio de los que se necesita preservar la información; por tanto se insiste en que los términos en que se formulan las reglas, se corresponden con los nombres y atributos de las tablas. Es importante señalar que existen tablas que no serán referenciadas en las reglas, donde estas constituyen la interrelacion de dos tablas que sí representan términos principales del negocio. Este lenguaje posee una notación específica, operadores lógicos, operadores aritméticos 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, Miranda et al. 2002), le brinda consistencia. Este lenguaje ha sido conformado en el marco del tema de investigación “Generación automática de reglas de negocio en contexto relacional” que se desarrolla en el CEI de nuestra universidad.. 1.3.4.1 Notación punto y tipos de elementos En LPT la notación punto es el estilo que se usa , para establecer el medio de acceso a los atributos de tablas y posibilita la navegación. Esta notación le brinda consistencia al lenguaje. LPT propone una manera muy simple de expresión para restricciones y otras reglas de negocio en función de una base de datos física.(Zimbrão, Miranda et al. 2002) Acceso simple a un atributo: Tabla 1. [Atributo] Camino de navegación entre tablas: Tabla 1. Tabla 2. (…) . Tabla N [. Atributo]. 21.

(22) Capítulo 1. En esta notación es admisible emplear como tabla la palabra reservada sujeto, la cual no pertenece realmente a ninguna tabla específica, su utilización referencia a la tabla que se refiere el <sujeto> de la regla. Esta constante de la notación punto es similar al this de los diferentes lenguajes de programación. Al utilizar la notación punto se tiene como resultado elementos individuales o elementos múltiples. Elementos Individuales. Surgen cuando al utilizar la notación punto se obtiene como resultado un solo elemento, son útiles para el acceso a atributos específicos de una tabla. En el siguiente diagrama:. Menú. 1. M. Plato_consumir. Al expresar: (Plato_consumir .Menú) se referencia un único menú, pues al ser la relación uno a muchos, se obtiene el menú al que pertenecen los platos Elementos Múltiples. Surgen cuando a partir de la notación punto se obtienen como resultado varios elementos, por ejemplo, utilizando esquema anterior, al indicar “Los platos del menú” (Menú.Plato) se conciben varias platos relacionadas con un único menú como muestra la cardinalidad del diagrama. Nótese nuevamente que el orden de la notación es muy importante. La notación punto no es el único modo de obtener elementos individuales pues estos pueden ser el resultado de aplicar operadores de conjuntos a elementos múltiples. En estudio previo (Toledo 2009)se considera la posibilidad de navegar por relaciones entre tablas de cualquier cardinalidad. Para el caso de las interrelaciones(1:M) se obtienen elementos múltiples.. 1.4 Reglas de negocio y diseño de base de datos “El proceso de diseño de una base de datos a partir del conocimiento de las reglas de negocio comienza con la ingeniería de requisitos. Una actividad clave durante este proceso es la creación de un esquema conceptual a partir delas reglas extraídas del negocio, que describe las 22.

(23) Capítulo 1. propiedades que el sistema de información debe tener, y sirve como base para las siguientes fases del diseño”. (García González 2009) EL diseño o modelación conceptual es la etapa en que se crea un esquema conceptual que describe, de manera concreta, los requerimientos de información de los usuarios. El núcleo de los requerimientos del negocio muchas veces es expresado en forma de reglas de negocio. Estas reglas se expresan usando los términos del negocio, que expresan las entidades reconocibles del mismo. Los modelos más comunes para bases de datos tienen un formato de representación para entidades, atributos e interrelaciones entre entidades. Los especialistas en base de datos reconocen el concepto de entidad como el más importante en la modelación, denominado indistintamente entidad u objeto(García González 2009).. Propuesta de aspectos a considerar para diseñar una BD a partir del conocimiento de las reglas de negocio. A partir de la bibliografía revisada sobre diseño e implementación de base de datos y sobre reglas de negocio, teniendo como base las concepciones de estos y también sobre requerimientos del negocio y del sistema, se conciben un conjunto de elementos a tener en cuenta para obtener las relaciones de una base de datos a partir del conocimiento de las RN. 1. Describir la problemática del negocio con el objetivo de diseñar la base de datos. 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 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 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.. 23.

(24) Capítulo 1. 1.5 Herramientas utilizadas para la construcción del sistema 1.5.1 Recursos del PostgreSQL utilizados para el manejo de datos El PostgreSQL es un poderoso sistema manejador de bases de datos, es decir, un sistema diseñado para administrar grandes cantidades de datos, afamado por ser la base de datos de código abierto (Open Source) más avanzada del mundo. PostgreSQL es un sistema de gestión de base de datosrelacionalorientada a objetos y libre. En Postgres la base de datos comprende relaciones. y. se. puede. obtener. información. de. tablas. relacionadas. utilizando. reglas.PostgresSQLofrece diversos recursos para el manejo de datos, en esta investigación, se presentan los posibles recursos a emplear en la implementación de las reglas:. Disparadores (Triggers) Un disparador es una pieza de código ejecutable, que consiste en instrucciones declarativas y procedurales y que se almacenan en el catálogo del Sistema de gestión de bases de datos (SGBD), (González 2010). Son tipos especiales de procedimientos almacenados para la ejecución automática al emitirse una instrucción UPDATE, INSERT o DELETE en una tabla o una vista. Constituyen herramientas eficaces que pueden utilizar los sistemas para exigir automáticamente las reglas de negocio cuando se modifican los datos. Según se plantea en (Healy 2000) utilizar desencadenadores en un manejador de base de datos puede traer como resultado: • Rapidez de desarrollo de las aplicaciones: Porque al estar los disparadores almacenados en las bases de datos relacionales, las acciones llevadas a cabo por ellos no tienen que ser codificadas en cada aplicación. • Ejecución global de las reglas de negocio: Un disparador sólo tiene que ser definido una vez, y entonces puede ser usado por cualquier aplicación que modifique la tabla. • Facilidad de mantenimiento Si una política de negocio cambia, sólo el disparador correspondiente necesita cambiar en lugar de cada programa de la aplicación.. 24.

(25) Capítulo 1. Vistas (View) Una vista es una tabla virtual cuyo contenido está definido por una consulta. Al igual que una tabla real, una vista consta de un conjunto de columnas y filas de datos con un nombre. Suelen utilizarse para centrar, simplificar y personalizar la percepción de la base de datos para cada usuario(Melton and Simon 2002) . Las vistas se pueden utilizar para realizar particiones de datos y para mejorar el rendimiento cuando estos se copian. Además, permiten a los usuarios centrarse en datos de su interés y en tareas específicas de las que son responsables. Algunas de las de las ventajas de utilizar las vistas que se encuentran en (Date 2000)son: •. Las vistas proporcionan seguridad automática para los datos que se necesiten ocultar para determinados usuarios.. “Datos ocultos” se refiere a los datos que no son visibles a través de alguna vista determinada. Existe la seguridad de que estos datos no serán accedidos •. Las vistan pueden ofrecer la independencia lógica de los datos.. Las vistas constituyen el medio por el cual se logra la independencia lógica de los datos en un sistema relacional.. Funciones Al igual que las funciones en los lenguajes de programación, las funciones definidas por el usuario(MSDN 2008) son rutinas que aceptan parámetros, realizan una acción, como un cálculo complejo, y devuelven el resultado de esa acción como un valor. Son múltiples las ventajas de las funciones definidas por el usuario entre las cuales se tienen: •. Permiten una programación modular.. •. Permiten una ejecución más rápida.. •. Pueden reducir el tráfico de red.. 25.

(26) Capítulo 1. 1.5.2Traductor LPT-SQL La herramienta de software denominada, LPT-SQL, constituye. un traductor de reglas de. negocio que permite generar automáticamente la implementación de reglas o políticas del negocio especificada en lenguaje LPT. Estas reglas son traducidascomo recursos de base de datos activas basados en código SQL. Se utilizan los disparadores como recursos del SQL para implementar las reglas del negocio. Todas las funcionalidades son a través de un repositorio de reglas descrito en un documento XML.(Boggiano-Castillo, Garcell et al. 2011), teniendo que existir dicho repositorio. La aplicación, cuya interfaz se muestra en la Figura 1.1, posee dos cajas de texto editables: una para la entrada de la regla en lenguaje natural y otra para la entrada de la regla en lenguaje LPT. En la caja de texto no editable situada en la parte inferior de la ventana se muestra el resultado de la compilación o generación de la regla. Para la edición de las reglas, se consta de una lista con todas las tablas de acuerdo a la información extraída del catálogo que se puede actualizar por el botón Actualizar Lista, y un marco con todos los operadores. Al seleccionar algún elemento de la lista desplegable o algún operador, el elemento seleccionado es situado en la caja de texto de representación de la regla en LPT. También posee los menús Reglas y Configuración. También se tiene en la parte superior de la ventana el número de la regla en cuestión, el estado de la regla (activa o inactiva) y el gestor para el cual se va a generar. El botón Limpiar borra el contenido de la caja de texto editable para la regla en LPT. El botón Compilar compila la regla y guarda en el repositorio de Generación, la información necesaria para generar la regla. El botón Generar, permite generar la regla y almacenarla en el repositorio.. 26.

(27) Capítulo 1. Figura 1.1: Ventana principal de la aplicación. En el menú de reglas que se muestran las siguientes opciones: Nueva Regla: Prepara la aplicación para la adición de una nueva regla y le asigna un identificador a la regla. Adicionar Regla: Adiciona una nueva regla al repositorio de reglas. Actualizar Regla: Actualiza en el repositorio de reglas una regla inactiva. Si la regla está activa, esta opción se deshabilita. Desactivar Regla: Desactiva una regla en el repositorio de reglas y elimina los recursos que fueron implementados en la base de datos Activar Regla: Compila, genera e implementa en la base de datos los recursos obtenidos. El menú de configuración muestra 3 opciones: Conexión e Información del Catálogo: Muestra la ventana para la extracción de información del catálogo que se muestra en la Figura1.2. Nuevo repositorio: Permite crear un nuevo repositorio vacío. Cargar repositorio: Permite cargar un repositorio existente.. 27.

(28) Capítulo 1. Figura 1.2: Interfaz de la herramienta InfoCatálogo (información necesaria para obtener los Metadatos en PostgreSQL).. Repositorio de reglas En el repositorio de Reglas se almacena la regla en sus tres niveles de expresión, de cada regla se tienen los atributos id, tipo de regla, gestor, estado, versión, última fecha y enfoque. En el momento en que es añadida una regla en el repositorio se tiene el id y el estado, además de su expresión en los lenguajes Informal y técnico. El lenguaje formal se obtiene al ser generada la regla, para cada regla se tienenlos recursos de BD correspondiente con nombre y tipo como atributos, en el caso de las funcionesse obtiene además el tipo de retorno. 1.5.2.1 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 28.

(29) Capítulo 1. 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>, colección>). Retorna verdadero si un elemento existe en una colección.. 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.. 1.6 Problemática del Menú Comedor Se desea implementar un Sistema de Información para la planificación del menú_comedor 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.. 29.

(30) Capítulo 1. 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 normas” de cada plato, los productos y las cantidades requeridas de cada producto en aras de elaborar un plato. Para la elaboración del menú se debe tener en cuenta que: •. Los platos se agrupan por categorías y cada plato tiene un nombre o tipo.. •. Cada plato está compuesto por ingredientes fundamentales e ingredientes adicionales y estos a la vez llevan una norma para su elaboración.. •. Los platos deben ser elaborados de acuerdo a la cantidad de existencias que hay en el almacén, debe existir como mínimo la cantidad de ingredientes fundamentales que llevan, de lo contrario no pueden ser preparados.. En la planificación de un menú de desayuno, almuerzo o comida no se deben ofertar más de 15 platos tampoco deben prepararse dos tipos de arroz, dos tipos e potaje o dos tipos de plato fuerte (carne, pescado, ave). Debido a esto se debe tener en cuenta que la elaboración de un plato implica la no elaboración de otro, como un ejemplo de este caso tenemos la harina y el arroz. Un menú puede estar compuesto por dos platos de la misma categoría (solo cuando se trata de embutidos, ensaladas, huevos, viandas, frutas, etc). En estos casos la norma de los ingredientes fundamentales se duplicará. Cualquier tipo de plato puede planificarse con ración doble. Para confeccionar un menú, es necesario realizar los cálculos con las cantidades necesarias por cada producto que lleva un plato y la cantidad de comensales que van a consumir este. La cantidad total de un producto a utilizar , es menor o igual que las existencias que hay en el almacén , así se decidirá por parte del encargado de elaborar el menú, qué tipos de productos se va a utilizar para elaborar el plato y qué cantidad. Se tiene en cuenta que cada plato cuneta de productos fundamentales y opcionales. Los productos fundamentales no deben ser usados por debajo de las especificaciones de la norma del plato.. 30.

(31) Capítulo 1. 1.7 Conclusiones del Capítulo En este capítulo se profundiza el tema de reglas de negocio, haciendo énfasis en la clasificación de Reglas “desde la perspectiva de datos”, de las cuales se ofrece un patrón que las define para su posterior implementación. Se utilizó el lenguaje LPT, para expresar reglas de negocio, lo que constituye un punto de partida para lograr el objetivo principal de este trabajo y se estudian los fundamentos para el diseño e implementación de una base de datos a partir de las reglas de negocio.. 31.

(32) Capítulo 2. Capítulo 2: “Diseño del sistema e implementación de las reglas de negocio en el LPT-SQL”. 32.

(33) Capítulo 2. Capítulo 2: Diseño del sistema e implementación de las reglas negocio en LPT En el presente capítulo se abordan los aspectos relacionados con la arquitectura del sistema, haciendo hincapié en dos de las etapas del desarrollo del software: análisis y diseño. En el primer epígrafe se describen las reglas de negocio a partir de los teminos del negocio y se realiza un análisis del entorno orientado a objetos con UML (Lenguaje Unificado de Modelado) exponiendo los diferentes diagramas que permiten modelar, construir y documentar los elementos esenciales que forman el sistema. En el segundo epígrafes se explica el uso de la herramienta LPT-SQLen la implementacion de las reglas de negocio. 2.1 Análisis y diseño del sistema El análisis y diseño de sistemas es una guía que permite estructurar el proceso de desarrollo de proyectos de software. Se trata básicamente de determinar los objetivos y límites del sistema objeto de análisis, caracterizar su estructura y funcionamiento, marcar las directrices que permitan alcanzar los objetivos propuestos y evaluar sus consecuencias. Según (Pressman 1993) esta etapa es de vital importancia en el ciclo de vida del proyecto, pues este procedimiento permite reducir al mínimo el riesgo de fracaso de nuevos proyectos, ya que la instalación de un sistema sin la adecuada planificación puede conducir a grandes frustraciones y ocasionar que el mismo sea subutilizado, o peor aún, deje de ser utilizado al no cumplir con las expectativas que le dieron origen. 2.1.1Términos del negocio y reglas de negocio A partir de la descripción del negocio, las políticas del mismo y las entrevistas con los clientes del sistema, se descubren los términos del negocio y las reglas, que se utilizan para el diseño de la base de datos y la conformación del conjunto de reglas desde la perspectiva de datos Los términos del negocio que se establecen son: Menú: Un menú del comedor está caracterizado por un tipo de comensal, fecha, tipo de menú: desayuno, almuerzo, comida y cantidad de comensales. Platos: Se refiere a cada plato del catálogo de platos, caracterizado por su categoría, precio. Norma: Se refiere a las cantidades normadas de cada producto que lleva un plato 33.

(34) Capítulo 2. Producto: se refiere a cada producto del registro de productos, caracterizado por un código o identificador, cantidad existente y unidad de medida. Categoría: Se refiere a las categorías por las que se agrupan los platos. Plato a consumir: Los platos a consumir son los platos que constituyen un determinado menú, identificándose por el tipo de plato y la ración a servir Ingredientes a consumir: Constituyen los ingredientes que lleva un plato a consumir, caracterizándose por una cantidad total y una cantidad real. La cantidad total se calcula en base a la cantidad normada, la ración a servir del plato y el número de comensales.. A partir de las términos y politicas se obtuvieron las siguientes reglas de negocio: 1. Un menú no puede tener más de 12 platos. 2. La cantidad total de los ingredientes a consumir es calculada como (cantidad de productos normados)* (cantidad de comensales) * (cantidad de raciones) 3. Un plato a consumir no puede tener la cantidad real de prodoctos mayor que la cantidad de productos existentes. 4. Un menú no puede tener más de un plato de la categoria 'potaje' 5. Un menú no puede tener más de un plato de la categoria 'arroz' 6. Un menú no puede tener un plato de tipo arroz y otro de tipo harina 7. Un menú no puede tener más de un plato de las categorias 'Carne', 'Pescado' o 'Ave'. Teniendo en cuenta los términos del negocio y las reglas extraídas se diseña el diagrama de entidad relación, donde las tablas de la base de datos tributan a las entidades del negocio. En la Figura 2.1.1 se muestra el diagrama de de Entidad Relación de la base de datos.. 34.

(35) Capítulo 2. Figura2.1.1 Diagrama de Entidad Relación de la base de datos.. La base de datos facilita la búsqueda y la navegación dentro del sistema a través de las consultas en lenguaje SQL. Un buen diseño de la base de datos le imprime un carácter flexible a la información. La base de datos de este sistema cuenta con siete tablas correspondientes a las entidades del negocio. Existen tres tablas que van a contener la información necesaria para poder crear los platos que formarían parte de un menú. En la (Figura 2.1.2)se puede ver el diagrama lógico de la base de datos.. 35.

(36) Capítulo 2. Figura 2.1.2 Diagrama lógico relación de la base de datos. 2.1.2. Diagrama de actores casos de uso A partir de la descripción del problema, usando el modelado del negocio, se elabora el diagrama de actores y casos de uso del sistema, como parte del proceso de captura de requisitos, identificándose un actor negocio y luego definiéndose sus casos de uso según los roles en que participe. El diagrama de casos de uso se utiliza para describir el comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Los casos de uso del actor de este sistema se identifican en la (Figura 2.2.1). 36.

(37) Capítulo 2. Figura 2.2.1 Diagrama de actores y casos de uso. 2.1.2.1 Descripción del caso de uso “Planificar menú”. El actor planificador selecciona dentro de “Menú” la opción “Registro menú”, donde se muestra una ventana con los datos de todos los menús y en la opción “Crear menú” se registran todos los datos del menú, luego en “Adicionar platos”, se seleccionan los platos que formarían parte del menú (platos a consumir).. Caso de Uso. Planificar menú. Actores. Planificador. Propósito. Planificar un menú con los platos seleccionados. 37.

(38) Capítulo 2. Elaborar un menú con los platos seleccionados y actualizar. Resumen. las existencias de los productos utilizados en este proceso.. CURSO NORMAL DE LOS EVENTOS QUÉ HACE EL ACTOR. Selecciona. una. fecha. QUÉ HACE EL SISTEMA. en. el Actualiza el encabezado de la tabla registro. calendario, selecciona qué tipo de menú del sistema mostrando los datos menú se está elaborando y el tipo anteriormente seleccionados. de comedor. Introduce. la. cantidad. de Registrar los comensales para cada menú. comensales por cada tipo de comensal. Escoge una categoría de platos.. Muestra los platos asociados a esa categoría.. Escoge un plato.. Muestra los productos normados por cada plato seleccionado.. Escoge las cantidades de cada Actualiza las existencias de cada producto. producto que van a ser utilizadas en este plato. Da clic en el botón “adicionar Guarda el plato con sus productos y el plato”. precio asociado al plato. Da clic en el botón “guardar Guarda el menú. menú” Tabla de eventos para el caso de uso “Planificar menú”.. 38.

(39) Capítulo 2. 2.1.3 0tros diagramas que componen el modelado del software Entre los demás diagramas que componen el modelado del software se encuentran: 1. En el diagrama de actividades se representan los flujos de trabajo paso a paso del proceso y las interacciones de los componentes en el Sistema, lo que es provechoso para entender el comportamiento de alto nivel de la ejecución del sistema, sin profundizar en los detalles internos. (Figura 2.1.3).. 39.

(40) Capítulo 2. Figura 2.2.2: Diagrama de actividades para el caso de uso planificar menú. 2. Diagrama de estados, mediante este diagrama se describe la estructura de un sistema y proporciona al usuario una idea de cómo navegar en el sistema. El sistema se caracteriza por un conjunto de estados válidos para cada caso de uso, los cuales se representan en las (Figuras 2.2.3, 2.2.4, 2.2.5).. Figuras 2.2.3 Diagrama de estados para el caso de uso para Planificar menú. 40.

(41) Capítulo 2. Figuras 2.2.4 Diagrama de estados para el caso de uso para Gestionar platos. Figuras 2.2.5 Diagrama de estados para el caso de uso Gestionar productos.. 3. Diagrama de clases, para describir la relación de clases a partir de las cuales se implementa el sistema, (Figura 2.2.6). 41.

(42) Capítulo 2. Figura 2.2.6 Diagrama de clases. 2.2 Implementación de las reglas en el LTP-SQL y los recursos que genera en la Base de Datos. Para la implementación de las reglas en el LTP-SQL se deben tener en cuenta una serie de pasos. A continuación se describe un ejemplo de implementación de una regla de negocio de tipo restricción. RN#1: Un menú no puede tener más de 12 platos Pasos: 1. Primeramente crear un repositorio de Reglas o cargar uno existente(Figura 2.3.1). 42.

(43) Capítulo 2. Figura 2.3.1 2. Establecer la conexión con la base de datos, (especificar el gestor de base de datos). Se puede ver en la (Figura 2.3.2). Figura 2.3.2. 43.

(44) Capítulo 2. 3. Escribir la regla en lenguaje natural, (momento en que se detecta una posible regla por parte de algún analista del negocio). 4. Escribir la regla en lenguaje técnico, (nivel donde se logra la representación matemática. de la regla y se facilita la traducción al formal). (Figura 2.3.3). Regla en lenguaje Natural Regla en lenguaje Técnico. Figura 2.3.3. 5. Adicionar la regla al repositorio de reglas. 6. Compilar la regla, (nivel donde se logra la traduccion al lenguaje formal).(Figura 2.3.4). 44.

(45) Capítulo 2. Compilación de laregla. Figura 2.3.5 7. Generar la regla, (nivel donde se generan los recursos de base de datos).(Figura 2.3.6). Generación de la regla. Figura 2.3.6 8. Activar la regla, (se insertan estos recursos en la base de datos, es decir se actualiza la regla en la base de datos).(Figura 2.3.7) 45.

(46) Capítulo 2. Base de datos. Disparadores. Funcion es Vista s. Figura 2.3.7 Al compilar y generar las reglas los resultados obtenidos son guardados en el repositorio de reglas, como se muestra a continuación:. 46.

(47) Capítulo 2. Las implementaciones de las RRN, insertadas automáticamente como recursos de la base de datos del menú del comedor, como traducciones de las reglas escritas en LPT a SQL son las siguientes:. 1. Un Menu no puede tener sizeof( sujeto.Plato_consumir.id_plato)>12 CREATE TRIGGER turn1_1 AFTER UPDATE ON public."Plato_consumir" FOR EACH ROW EXECUTE PROCEDURE public.frn1_1(); CREATE VIEW public."vrn1" AS SELECT * FROM public."Menu" sujeto WHERE ( (SELECT COUNT( b."id_plato" ) FROM public."Menu" a , public."Plato_consumir" b WHERE (sujeto."id_menu"=a."id_menu") AND (a."id_menu"=b."id_menu")) > 12 );. 2. La cantidad total de los ingredientes a consumir para cant_producto_total es calculado como sujeto.Norma.cant_producto * sujeto.Plato_consumir. Menu.cant_comenzal * sujeto.Plato_consumir.racion. CREATE OR REPLACE FUNCTION total (id_menu character varying, id_plato character varying, id_producto character varying) RETURNS real AS $$ DECLARE y float; BEGIN y=((((SELECT b."cant_producto" FROM public."Ingredientes_consumir" a , public."Norma" b WHERE. ($1=a."id_menu"). AND. (a."id_producto"=b."id_producto"). ($2=a."id_plato") AND. AND. ($3=a."id_producto"). (a."id_plato"=b."id_plato")). *. AND. (SELECT. c."cant_comensal" FROM public."Ingredientes_consumir" a , public."Plato_consumir" b , public."Menu" c WHERE ($1=a."id_menu") AND ($2=a."id_plato") AND ($3=a."id_producto") AND. (a."id_menu"=b."id_menu"). AND. (a."id_plato"=b."id_plato"). AND. (b."id_menu"=c."id_menu"))) * (SELECT b."racion" FROM public."Ingredientes_consumir" a , public."Plato_consumir". b. WHERE. ($1=a."id_menu"). AND. ($2=a."id_plato"). AND. ($3=a."id_producto") AND (a."id_menu"=b."id_menu") AND (a."id_plato"=b."id_plato")))) ; RETURN y; END;$$ LANGUAGE plpgsql; CREATE. VIEW. VRN2. AS. SELECT. id_menu,. id_plato,. id_producto. FROM. Ingredientes_consumir WHERE ((cant_producto_total <> total ( id_menu, id_plato, id_producto ))or cant_producto_total is NULL) 47.

(48) Capítulo 2. CREATE OR REPLACE FUNCTION PROCRN2() RETURNS trigger AS $$ BEGIN UPDATE Ingredientes_consumir SET cant_producto_total = total ( id_menu, id_plato, id_producto ) WHERE EXISTS (Select id_menu, id_plato, id_producto from VRN2 a where a.id_menu = id_menu AND a. id_plato = id_plato AND a. id_producto = id_producto);RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE TRIGGER TURN2_1 AFTER UPDATE ON Ingredientes_consumir FOR EACH ROW EXECUTE PROCEDURE PROCRN2(); CREATE TRIGGER TIRN2_1 AFTER. INSERT. ON Ingredientes_consumir FOR EACH. ROW EXECUTE PROCEDURE PROCRN2(); CREATE TRIGGER TURN2_2 AFTER UPDATE ON Norma FOR EACH ROW EXECUTE PROCEDURE PROCRN2(); CREATE TRIGGER TURN2_3 AFTER UPDATE ON Plato_consumir FOR EACH ROW EXECUTE PROCEDURE PROCRN2(); CREATE TRIGGER TURN2_4 AFTER UPDATE ON Menu FOR EACH ROW EXECUTE PROCEDURE PROCRN2(); 3. Un plato a consumir no puede tener la cantidad real de prodoctos mayor que la cantidad de productos existentes. CREATE TRIGGER turn3_1 AFTER UPDATE ON public."Ingredientes_consumir" FOR EACH ROW EXECUTE PROCEDURE public.frn3_1(); CREATE VIEW public."vrn3" AS SELECT * FROM public."Plato_consumir" sujeto WHERE ( (SELECT. COUNT(. b."cant_producto_real". public."Ingredientes_consumir" (sujeto."id_plato"=a."id_plato"). b. ). WHERE AND. FROM. public."Plato_consumir". a. ,. (sujeto."id_menu"=a."id_menu"). AND. (a."id_menu"=b."id_menu"). AND. (a."id_plato"=b."id_plato") AND (b."cant_producto_real" > (SELECT MAX( d."cant_existente" ) FROM public."Plato_consumir" a , public."Ingredientes_consumir" b , public."Norma" c , public."Producto". d. (sujeto."id_plato"=a."id_plato") (a."id_plato"=b."id_plato"). WHERE. (sujeto."id_menu"=a."id_menu"). AND AND. AND. (a."id_menu"=b."id_menu"). AND. (b."id_producto"=c."id_producto"). AND. (b."id_plato"=c."id_plato") AND (c."id_producto"=d."id_producto")) ))>0 ) 4. Un menú no puede tener más de un plato de la categoria 'potaje' 48.

(49) Capítulo 2. CREATE TRIGGER turn4_1 AFTER UPDATE ON public."Plato_consumir" FOR EACH ROW EXECUTE PROCEDURE public.frn4_1(); CREATE VIEW public."vrn4" AS SELECT * FROM public."Menu" sujeto WHERE ( (SELECT COUNT( d."id_categoria" ) FROM public."Menu" a , public."Plato_consumir" b , public."Platos" c , public."Categoria" d WHERE (sujeto."id_menu"=a."id_menu") AND (a."id_menu"=b."id_menu"). AND. (b."id_plato"=c."id_plato"). AND. (c."id_categoria"=d."id_categoria") AND (d."id_categoria" = 'potaje' )) > 1 ). 5. Un menú no puede tener más de un plato de la categoria 'arroz' CREATE TRIGGER turn5_1 AFTER UPDATE ON public."Plato_consumir" FOR EACH ROW EXECUTE PROCEDURE public.frn5_1(); CREATE VIEW public."vrn5" AS SELECT * FROM public."Menu" sujeto WHERE ( (SELECT COUNT( d."id_categoria" ) FROM public."Menu" a , public."Plato_consumir" b , public."Platos" c , public."Categoria" d WHERE (sujeto."id_menu"=a."id_menu") AND (a."id_menu"=b."id_menu"). AND. (b."id_plato"=c."id_plato"). AND. (c."id_categoria"=d."id_categoria") AND (d."id_categoria" = 'arroz' )) > 1 ) 6. Un menú no puede tener un plato de tipo arroz y otro de tipo harina CREATE TRIGGER turn6_1 AFTER UPDATE ON public."Plato_consumir" FOR EACH ROW EXECUTE PROCEDURE public.frn6_1(); CREATE VIEW public."vrn6" AS SELECT * FROM public."Menu" sujeto WHERE ( ((SELECT COUNT( b."tipo_plato" ) FROM public."Menu" a , public."Plato_consumir" b WHERE. (sujeto."id_menu"=a."id_menu"). AND. (a."id_menu"=b."id_menu"). AND. (b."tipo_plato" = 'arroz' ))>0 AND (SELECT COUNT( b."tipo_plato" ) FROM public."Menu" a , public."Plato_consumir". b. WHERE. (sujeto."id_menu"=a."id_menu"). AND. (a."id_menu"=b."id_menu") AND (b."tipo_plato" = 'harina' ))>0) ). 7. Un menú no puede tener más de un plato de las categorias carne o pescado o pollo. CREATE TRIGGER turn7_1 AFTER UPDATE ON public."Plato_consumir" FOR EACH ROW EXECUTE PROCEDURE public.frn7_1(); 49.

(50) Capítulo 2. CREATE VIEW public."vrn7" AS SELECT * FROM public."Menu" sujeto WHERE ( (((SELECT COUNT( d."id_categoria" ) FROM public."Menu" a , public."Plato_consumir" b , public."Platos" c , public."Categoria" d WHERE (sujeto."id_menu"=a."id_menu") AND (a."id_menu"=b."id_menu"). AND. (b."id_plato"=c."id_plato"). AND. (c."id_categoria"=d."id_categoria") AND (d."id_categoria" = 'carne' )) > 1 OR (SELECT COUNT( d."id_categoria" ) FROM public."Menu" a , public."Plato_consumir" b , public."Platos" c , public."Categoria" d WHERE (sujeto."id_menu"=a."id_menu") AND (a."id_menu"=b."id_menu"). AND. (b."id_plato"=c."id_plato"). AND. (c."id_categoria"=d."id_categoria") AND (d."id_categoria" = 'pescado' )) > 1) OR (SELECT COUNT( d."id_categoria" ) FROM public."Menu" a , public."Plato_consumir" b , public."Platos" c , public."Categoria" d WHERE (sujeto."id_menu"=a."id_menu") AND (a."id_menu"=b."id_menu"). AND. (b."id_plato"=c."id_plato"). AND. (c."id_categoria"=d."id_categoria") AND (d."id_categoria" = 'pollo' )) > 1) ). 2.2.1 Beneficios del uso del LPT-SQL en la implementación del sistema Uno de los resultados más relevantes que se obtienen con la implementación del software es la integración de la herramienta LPT-SQL con el sistema de información. Esta herramienta está concebida para trabajar con un conjunto de categorías de reglas llamadas reglas “desde la perspectiva de datos”; que son: restricción, cálculo, notificación y clasificación; estas se caracterizan porque ante una operación sobre la base de datos, inserción, actualización o eliminación se chequea que los datos del negocio almacenados cumplen con las reglas que los involucran, esto contribuye a minimizar los errores cuando se introducen datos al sistema El traductor LPT-SQL ahorra el esfuerzo de implementación de políticas de negocio dentro de la base de datos por parte del programador; a partir de la escritura de la regla en lenguaje LPT lenguaje de fácil aprendizaje por un analista, permite que cada regla sea compilada y generada automáticamente como código SQL en forma de recursos de las bases de datos relacionales: vistas, funciones, disparadores. Esta herramienta crea un repositorio de reglas que guarda las reglas del negocio, independientemente de la base de datos y el sistema de información. Los beneficios más importantes del uso esta herramienta para el desarrollo de aplicaciones se obtienen cuando las aplicaciones necesitan ser cambiadas y actualizadas, ya que permite 50.

(51) Capítulo 2. modificar las Reglas, y los Procesos quedan automáticamente adaptados a los cambios de política, de modo que a partir de una modificación de la regla todos los datos relacionados con la misma deben cumplir con la modificación, 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. 2.3 Conclusiones parciales Para implementar el Sistema de Información. para el control y planificación del menú en. comedores UCLV guiado por reglas de negocio, se identificaron las reglas durante la etapa de determinación de requisitos y la modelación de datos y sistema. Se obtuvo el diseño lógico y relacional de la base de datos relacional. Se implementaron las reglasde negocio extraídas y como resultado de ello se generaron automáticamente recursos de base de datos en la BD.. 51.

(52) Capítulo3. Capítulo 3: “Implementación y características del uso del sistema de información para el control y planificación del menú en comedores UCLV.”. 52.