Consistencia entre las reglas de negocio de restricción en LPT SQL

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas Facultad de Matemática Física Computación. Departamento de Ciencia de la Computación. Trabajo de Diploma. Título: Consistencia entre las reglas de negocio de restricción en LPTSQL. Autor: Claudia Beatriz Darias Alvarez Tutor: Dra.C. Martha Beatriz Boggiano Castillo. Santa Clara 2017.

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

(3) DEDICATORIA. A mis abuelos, A mis padres, A mi hermana y cuñado, A mi sobrino, A mi novio, Y a todos mis amigos..

(4) AGRADECIMIENTOS. A mi familia A mis amigos los Ninjas y a Francisco A mi tutora Dra. C. Martha Beatriz Boggiano Castillo A todos los profesores que me formaron y enseñaron. A todos los que de una u otra forma han contribuido a la terminación de esta tesis..

(5) RESUMEN En la actualidad el perfeccionamiento de los Sistemas de información se centra en el análisis de requisitos de la organización, representados como reglas de negocios. Existen diversas clasificaciones de las reglas. Las categorías de la clasificación desde la perspectiva de los datos permite gestionar reglas asociadas a los datos del negocio. Con este enfoque la herramienta LPTSQL v 1.4 convierte dichas reglas al Lenguaje de Patrones Técnico (LPT) y las traduce a recursos de bases de datos. La versión 1.4 satisface este requerimiento pero no abarca el análisis de la consistencia de las reglas de negocio y su posible repercusión en los datos Este trabajo analiza los aspectos que conforman la consistencia de reglas y aumenta la calidad de la herramienta LPT-SQL v 1.4. Se formula un algoritmo basado en las estructuras de árbol que se obtienen de la gramática del lenguaje LPT, que chequea la consistencia cada vez que se adicione o modifique una regla de restricción, introduciendo una mejora a la herramienta a partir de un intérprete de reglas. Se utiliza la herramienta transformada sobre un caso de estudio que pone a prueba la utilización de la misma que antes de salvar las reglas de negocio verifica la consistencia entre reglas de restricción para sistemas de información transaccionales..

(6) ABSTRACT Nowdays the improvement of Information Systems focuses on the analysis of requirements of the organization, represented as business rules. There are several classifications of rules. The classification categories from the data perspective allows to manage rules associated with business data. With this approach the LPT-SQL v 1.4 tool converts those rules to the Technical Pattern Language (LPT) and translates it to database resources. Version 1.4 satisfies this requirement but does not cover the analysis of the consistency of the business rules and their possible repercussion on the data. This work analyzes the aspects that make up the consistency of rules and increases the quality of the LPT-SQL v 1.4 tool. An algorithm is formulated based on the tree structures that are obtained from the grammar of the LPT language that checks the consistency each time a restriction rule is added or modified, introducing an improvement to the tool from a rule interpreter. The transformed tool is used on a case study that tests the use of the same one that verifies the consistency between restriction rules for transactional systems of information before saving the business rules..

(7) ÍNDICE DICTAMEN ........................................................................................................................................................... DEDICATORIA....................................................................................................................................................... AGRADECIMIENTOS ............................................................................................................................................. RESUMEN ............................................................................................................................................................ ABSTRACT ............................................................................................................................................................ ÍNDICE ................................................................................................................................................................. INTRODUCCIÓN ................................................................................................................................................. 1 CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS ................... 5 1.1 REGLAS DE NEGOCIO DESDE LA PERSPECTIVA DE LOS DATOS ............................................................................... 5 1.1.1 Categorías de la reglas de negocio desde la perspectiva de los datos .................................................... 6 1.1.2 Niveles de expresión ................................................................................................................................ 6 1.1.3 Patrones de las reglas de negocio desde la perspectiva de los datos ...................................................... 7 1.2 LENGUAJE DE PATRONES TÉCNICO: LPT ........................................................................................................ 9 1.2.1 La notación punto, elementos individuales y múltiples ........................................................................... 9 1.2.2 Operadores lógicos, aritméticos, de comparación y de conjunto en LPT ............................................... 10 1.3 LPT-SQL: HERRAMIENTA PARA LA GENERACIÓN AUTOMÁTICA DE REGLAS DE NEGOCIO ........................................... 11 1.3.1 Arquitectura de LPT-SQL ........................................................................................................................ 11 1.3.2 Recursos generados por LPT-SQL para la implementación de las reglas ............................................... 14 1.3.3 Ventajas y desventajas de LPT-SQL ........................................................................................................ 15 1.4 CONSISTENCIA DE REGLAS DE NEGOCIOS ...................................................................................................... 16 CONSISTENCIA DE REGLAS DE NEGOCIOS DESDE LA VISIÓN DE DIFERENTES AUTORES ....................................... 17 1.4.1 1.4.2. Diferentes estrategias para garantizar la consistencia de reglas de negocios ...................................... 19 Métodos de verificación para consistencia de reglas de negocios ........................................................ 24 CONCLUSIONES PARCIALES DEL CAPÍTULO ................................................................................................................. 30 CAPÍTULO 2: FORMALIZACIÓN DE UN ALGORITMO PARA LA CONSISTENCIA DE REGLAS DE NEGOCIO ................32 2.1 VERIFICACIÓN DE REGLAS DE NEGOCIO ............................................................................................................ 32 2.1.1 Características del conjunto de reglas de restricción a verificar en el algoritmo .................................. 32 2.1.2 Patrones identificados para analizar la consistencia de reglas ............................................................. 33 2.1.3 Análisis de consistencia para las reglas de negocio de restricción ........................................................ 33 2.1.3.1 Consecuencias para el sistema a causa de la generación de reglas de negocios inconsistentes .35 2.1.3.2 Chequeo de consistencia en el conjunto de reglas de negocio ..................................................... 37 2.2 ALGORITMO FORMAL ................................................................................................................................. 43 2.2.1 Descripción ............................................................................................................................................ 43 2.2.2 Algoritmo para el análisis de reglas de negocio .................................................................................... 44 2.2.3 Seudocódigo del algoritmo para la verificación de reglas de negocio .................................................. 45 CONCLUSIONES PARCIALES DEL CAPITULO ................................................................................................................. 49 CAPÍTULO 3: IMPLEMENTACIÓN AUTOMÁTICA EN LPT-SQL DE LA CONSISTENCIA DE REGLAS DE RESTRICCIÓN ..50.

(8) 3.1 MODIFICACIONES A LA HERRAMIENTA LPT-SQL ............................................................................................... 50 3.1.1 Vista arquitectónica del Traductor LPT-SQL .......................................................................................... 50 3.1.1.1 Diagrama de paquetes .................................................................................................................. 51 3.1.1.2 Diagrama de clases ....................................................................................................................... 52 3.1.2 Modificaciones de la Clase Principal de LPT-SQL ................................................................................... 54 3.2 RECURSOS Y MÉTODOS IMPLEMENTADOS PARA EL ANÁLISIS DE LA CONSISTENCIA ....................................................... 57 3.2.1 Documento de entrada .......................................................................................................................... 57 3.2.2 Métodos principales implementados .................................................................................................... 59 3.3 DESCRIPCIÓN DEL CASO DE ESTUDIO ............................................................................................................... 59 3.4 APLICACIÓN DEL ALGORITMO AL CASO DE ESTUDIO ............................................................................................ 59 CONCLUSIONES PARCIALES DEL CAPÍTULO ................................................................................................................. 69 CONCLUSIONES GENERALES .............................................................................................................................. 70 RECOMENDACIONES ......................................................................................................................................... 71 REFERENCIAS BIBLIOGRÁFICAS .......................................................................................................................... 72 ANEXOS ............................................................................................................................................................ 75.

(9) INTRODUCCIÓN. INTRODUCCIÓN La necesidad de gestionar grandes volúmenes de información devino en el surgimiento de los sistemas de información (SI). Se potencia con ellos coleccionar y recuperar el conjunto de datos de interés que generan información del mundo real, la administración adecuada, la toma de decisiones y el alcance de los objetivos empresariales. Los sistemas de información empresariales, están orientados a automatizar la operación de una organización. La operación de toda organización cuenta con condicionantes, políticas o restricciones que ayudan al sistema de información a ejecutar alguna operación de manera correcta, de acuerdo a la exigencia del negocio. En este sentido, en (Boggiano Castillo, 2014)se retoman las consideraciones del manifiesto publicado en (Group, 2003) sobre las denominadas reglas del negocio (RN), al considerarlas ciudadanas de primera clase de los Sistemas de Información, esenciales para los requerimientos de estos, así como para el orden y disciplina de las operaciones de la organización (Jorge Becerril, 2000). Según el padre de las reglas de negocio Ronald G. Ross (Ross, 2010, Ross, 2013),una RN es una regla que está bajo jurisdicción del negocio, lo cual significa que puede ser creada, revisada y eliminada cuando el negocio lo estime conveniente. 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 (Leonardi et al., 1998).Varios son los beneficios que pueden derivarse de su uso. Es común que ocurran rápidos y constantes cambios en los ambientes de negocio. Es una necesidad que los especialistas reduzcan el impacto negativo de adaptar los SI a la inestabilidad empresarial. Una tendencia que aborda dicha problemática es la conocida por enfoque de reglas de negocio BRA (Business Rules Approach). La idea principal de este enfoque consiste en una técnica de dominio del negocio basada en reglas explícitas que son escritas y expresadas en lenguaje claro, cercano al natural independientemente de las aplicaciones que las hacen cumplir (Zimbrão et al., 2003). La automatización de reglas de negocio surge en la década del 80 por sistemas expertos con el fin de asegurar una ventaja competitiva en el mercado, que enfatizan la tendencia de disponer de 1.

(10) INTRODUCCIÓN. un repositorio de reglas en el que se almacena el conocimiento de la organización. Se evidencia entonces los que se conocen hoy como Sistemas de Gestión de Reglas de Negocio (SGRN) como una buena solución empresarial inteligente basada en BRA. Los Sistemas de Gestión de reglas de negocio se centran en facilitar la definición, implementación, ejecución, monitoreo y mantenimiento de la variedad y complejidad de las reglas, de manera que permita su utilización para determinar las acciones tácticas que tienen lugar en las aplicaciones y sistemas. Sin embargo en el libro (Morgan, 2002)se apoya la posibilidad de que algunos tipos de reglas se pueden implementar de manera más simple o mejor fuera de los SGRN. A pesar de ser una herramienta muy utilizada en los últimos tiempos, presenta según(Boggiano Castillo, 2014), desventajas significativas: . La adopción de uno de los motores de reglas de inferencia, comercializados actualmente, requiere una gran inversión de tiempo.. . La obligación en algunos casos a complejizar la implementación de reglas que pudieran programarse de manera más sencilla.. La tendencia a manipular las reglas de negocio provoca el surgimiento de diferentes herramientas con este fin. Atendiendo a cómo se representan, implementan y ejecutan las reglas de negocios, las herramientas se clasifica en: herramientas independientes de los gestores de bases de datos, basadas en servicios y los sistemas basados en reglas(Boggiano Castillo, 2014). La tecnología que se utiliza corresponde a aquella en que las reglas se implementan en la BD, pero los recursos son generados automáticamente y manejadas por herramientas que no son gestores de bases de datos, específicamente la herramienta de software LPT-SQL que a partir de reglas de negocio plantea una forma de trabajar los SI vinculados a los datos del mismo. La herramienta LPT-SQL constituye un traductor de reglas de negocio que permite generar automáticamente la implementación de reglas o políticas del negocio especificadas en lenguaje LPT, considerando la perspectiva del comportamiento de los datos del negocio utilizando un repositorio para almacenarlas y un compilador para generarlas. La concepción del LPT y su traducción al SQL (Boggiano Castillo, 2014) no tiene en cuenta las inconsistencia de las reglas generadas por los cambios en los datos del negocio, lo cual provoca la necesidad de evaluar. El presente trabajo continúa con la investigación iniciada en (Boggiano Castillo, 2014) para la implementación de reglas de negocio desde la perspectiva de los datos en bases de datos 2.

(11) INTRODUCCIÓN. relacionales. Los resultados teóricos obtenidos en dicha investigación se han implementado sin concebir la consistencia o coherencia de las reglas. Para las reglas de restricción se proponen indicadores para su consistencia desde la perspectiva de los datos, que no se habían desarrollado. Los planteamientos anteriores conducen al siguiente problema científico: ¿Qué aspectos permiten calificar las reglas de restricción como reglas consistentes teniendo en cuenta el comportamiento de los datos para bases de datos relacionales? Teniendo en cuenta lo anteriormente planteado, el presente trabajo está dirigido hacia el cumplimiento del siguiente objetivo general: Confeccionar un algoritmo que permita analizar la consistencia entre reglas de negocio de restricción sobre bases de datos relacionales, a partir de los elementos del patrón de las reglas implicadas, para garantizar la validez de las consultas de inserción y actualización sobre los datos. Para cumplir este objetivo general se formularon los siguientes objetivos específicos: 1. Identificar las limitaciones de consistencia que tienen las reglas de restricción desde la perspectiva de datos. 2. Establecer los aspectos a considerar para lograr la consistencia de las reglas de restricción. 3. Implementar modificaciones para LPT-SQL para garantizar la consistencia entre las reglas de restricción. Para abordar este problema se formularon las siguientes preguntas de investigación: 1. ¿Qué limitaciones de consistencia tienen las reglas de restricción desde la perspectiva de datos? 2. ¿Qué aspectos deben considerarse para garantizar la consistencia de las reglas de restricción? 3. ¿Cómo implementar modificaciones para LPT-SQL para garantizar la consistencia entre las reglas de restricción? Justificación de la investigación. 3.

(12) INTRODUCCIÓN. Para lograr la implementación de las reglas dentro de las bases de datos, se deben tratar aspectos como las categorías de reglas que se utilizan, cómo se representan, cuáles recursos se usan para su implementación y cuándo se ejecutan. La investigación sobre reglas de negocio sobre la perspectiva de los datos, propone un conjunto de categorías para las reglas de negocio, sus formulismos para representarlas y la manera de automatizar la regla dentro de la base de daros con recursos de bases de datos activas. Cuando las reglas sean implementadas como recursos de bases de datos deben estar libres de anomalías que impidan su ejecución, sin embargo en (Boggiano Castillo, 2014) se ignora el análisis de consistencia entre las reglas de negocio, no se utilizan los principios de la consistencia de las reglas; por esto que emerge la necesidad de considerar la consistencia en los patrones de reglas de negocio desde la perspectiva de los datos, iniciando por las reglas de restricción. Con esta perspectiva la consistencia de las reglas debe analizarse en las reglas expresadas en LPT, para garantizar que una regla en lenguaje formal implementada sobre la base de datos es consistente con las demás. El presente trabajo está estructurado de acuerdo a la siguiente secuencia lógica: introducción, desarrollo en tres capítulos, conclusiones, recomendaciones, bibliografía y anexos. Capítulo I: “Consideraciones teóricas sobre la consistencia en las reglas de negocios desde la perspectiva de datos”. Se abordan aspectos generales sobre reglas de negocio desde la perspectiva de los datos, y la consistencia entre ellas, características fundamentales que se deben chequear en sus modos de implementación, así como la importancia de tratar la consistencia de la herramienta actual LPT-SQL. El Capítulo II: “Formalización de un algoritmo para la consistencia de reglas de negocio”. Se reflejan los aspectos a considerar para el diseño de un sistema consistente, a causa de las situaciones críticas en la BD, al ser actualizadas las reglas de negocio de restricción. El Capítulo III: “Implementación automática en LPT-SQL de la consistencia de reglas de restricción”. Se reflejan los pasos a seguir para la implementación del subsistema de análisis de consistencia dentro de la herramienta LPT-SQL, así como las pruebas realizadas para la verificación de su funcionamiento a partir de un caso de estudio.. 4.

(13) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS En este capítulo se exponen los conceptos fundamentales principales que sustentan este trabajo. A partir de los trabajos precedentes (Alonso, 2008, Alonso, 2010, Paz et al., 2011, Solís, 2011, Sevilla Aguilar, 2013, Boggiano Castillo, 2014, Alba Viego, 2014) se enfoca esta investigación, teniendo como base los conceptos de reglas de negocios, la diversidad de lenguajes de especificación y los tipos de herramientas para su implementación. En Boggiano Castillo, 2014, fueron finalmente definidas y especificadas un conjunto de categorías de reglas desde la perspectiva de los datos Se considera útil explicar estas categorías, sus niveles de expresión, los patrones de especificación, haciendo énfasis en el lenguaje de nivel técnico LPT. Se profundiza acerca de la consistencia entre reglas de negocios, así como algunos métodos empleados por otros autores para garantizarla. Se presenta la arquitectura de la herramienta LPT-SQL, que genera automáticamente estas reglas como recursos de bases de datos. Esta versión no tiene en cuenta el análisis de consistencia. 1.1 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: 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). Como se asegura en (Boggiano Castillo, 2014) las reglas de negocio son vistas por diferentes autores según perspectivas diferentes lo que se refleja en las diferentes clasificaciones de las reglas en como organizarlas y conformar el análisis de requisitos del negocio. Como se refleja en dichas investigaciones precedentes existen reglas directamente relacionadas con los tipos de entidades del negocio y sus correspondientes propiedades, que son datos del negocio; lo que resulta en una clasificación en la que cada clase o categoría esté definida en función de los datos del negocio. Son reglas que están involucradas en las operaciones sobre la base de datos del. 5.

(14) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. negocio. A esta clasificación se ha reconocido como conjunto de categorías de reglas de negocio desde la perspectiva de los datos. 1.1.1 Categorías de la reglas de negocio desde la perspectiva de los datos Las categorías de reglas de negocio desde la perspectiva de los datos, son cuatro y la descripción de cada una es como sigue: - 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. -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 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.1.2 Niveles de expresión Los autores que trabajan las reglas de negocio, conciben diferentes niveles de expresión. Según (Halle, 2002), cada uno para una audiencia diferente: conversación informal del negocio, versión en lenguaje natural, versión en lenguaje de especificación y versión en lenguaje de implementación. En última instancia las reglas se traducen del lenguaje de especificación al lenguaje de implementación, el cual tiene todo el potencial para ser ejecutado. 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.. 6.

(15) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. La investigación utiliza los niveles expuestos por (Morgan, 2002) y recreados en (Boggiano Castillo, 2014), que aporta al nivel informal el término lenguaje natural estructurado, definiendo para el lenguaje de patrones técnico (LPT) el formal, utilizando recursos de bases de datos. 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 necesaria para la implementación 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.1.3 Patrones de las reglas de negocio desde la perspectiva de los datos Los patrones son de gran importancia 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. Los patrones según (Boggiano Castillo, 2014) son: - Patrón de Restricción Este patrón es útil para satisfacer requisitos del negocio, solo con reglas de este tipo puede hacerse cumplir políticas prohibitorias en el sistema del negocio. Su expresión en lenguaje natural estructurado: <determinante><sujeto>(no puede tener <características>) | (puede tener <características> solo si <hechos>) - Patrón de Cómputo Su objetivo es calcular un valor determinado en el negocio, asociado o no a un <sujeto> y su resultado es numérico. Ayuda a definir nuevos datos. Su expresión en lenguaje natural estructurado:. 7.

(16) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. <determinante><resultado> [en <sujeto> [para <atributo>]] es calculado como <algoritmo> - Patrón de Clasificación El patrón de clasificación puede ser visto como una regla de definición que no se refleja en el diseño estructural de la base de datos. Estas reglas reflejan un conocimiento básico del negocio contribuyendo claramente al significado de conceptos, centrándose en la esencia del mismo Su expresión en lenguaje natural estructurado: <determinante> <sujeto>[no] es definido como <clasificación>[(si | a menos que )<característica>] - Patrón de Notificación La finalidad de este patrón es tan sencilla como útil; consiste en informar a los usuarios autorizados del negocio sobre algún conocimiento básico en tiempo real. Su expresión en lenguaje natural estructurado: Notificar <mensaje> si <hecho>. Nótese que se convenían para estos patrones un conjunto de elementos, definidos a continuación. 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. <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. 8.

(17) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. <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 Lenguaje de patrones técnico: LPT El LPT es un lenguaje técnico utilizado para expresar RN en función de las tablas y sus atributos, para bases de datos relacionales, basado en los patrones de reglas definidos en (Alonso, 2010). El LPT es considerado una expresión matemática de los elementos que conforman los patrones de reglas cercanas a los datos, que consta de operadores aritméticos, lógicos, funciones y una notación específica para la navegación entre las entidades y el acceso a sus atributos, lo cual le brinda consistencia según se refiere en (Zimbrão et al., 2003). La estructura del LPT brinda tres facilidades para un especialista técnico del negocio: la compresión relativamente fácil, la simple transformación desde los patrones de reglas en lenguaje natural, así como la escritura simple usando notación punto. Este lenguaje busca un equilibrio entre las funcionalidades similares al OCL y la necesidad de conservar la simplicidad deseada, que cuenta solo variantes indispensables implícitas en su definición y basado en patrones de reglas desde la perspectiva de los datos (Boggiano Castillo, 2014). 1.2.1 La notación punto, elementos individuales y múltiples LPT utiliza la notación punto para establecer el acceso a los atributos de tablas y posibilitar la navegación, lo cual refiere (Zimbrão et al., 2003). Esta notación le brinda consistencia al lenguaje. La especificación completa de la sintaxis y semántica de LPT, así como sus operadores se describen en el Anexo 1―Sintaxis del LPT y ―Semántica del LPT, respectivamente. A continuación se mostrarán algunos elementos esenciales de las mismas, solo con el objetivo de mostrar las funcionalidades principales. Acceso simple a un atributo: Tabla [.Atributo]. Referencia a los valores que toma el Atributo en la Tabla. Si no aparece .Atributo, se referencian implícitamente los valores de los atributos identificadores. Camino de navegación entre tablas:Tabla1.Tabla2. (…) .TablaN [. Atributo]. 9.

(18) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. A Tabla1.Tabla2.Tabla3…TablaN se le llama camino de navegación, porque indica una manera de ir de la Tabla1 a la TablaN. Cuando el camino incluye varias tablas se devuelven uno o más valores del atributo en dependencia de las interrelaciones existentes entre las tablas. Los elementos individuales se obtienen cuando el camino de navegación tiene varias tablas con interrelaciones 1:1 o solamente una tabla, útiles para el acceso a atributos. Los elementos múltiples se obtienen como resultado de un camino de navegación con varias tablas y al menos una interrelación uno-muchos. En esta notación se emplea como palabra reservada sujeto, para referenciar la tabla del <sujeto> de la regla. Esta forma es similar al uso del this de los diferentes lenguajes de programación (Horstmann, 2009). 1.2.2 Operadores lógicos, aritméticos, de comparación y de conjunto en LPT A continuación la Tabla 1.1 muestra los operadores que ofrece LPT para facilitar la construcción de sentencias complejas (Solís, 2011). Tipo. Operadores. Lógicos. OR, AND, NOT, XOR. Aritméticos. +, -, *, /. Comparación. <, >, <=, >=, =, <>. Tabla 1.1Operadores del LPT.. Como se explicó con anterioridad, al utilizar la notación punto es posible la obtención de elementos múltiples. Para la manipulación de colecciones de elementos LPT brinda un grupo de operadores de conjunto que se muestran en la Tabla 1.2.El resultado de aplicar uno de los operadores de conjunto a una colección de elementos es un elemento individual. 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. 10.

(19) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. 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 numérica. AVGDIF<colección>. Retorna el promedio de los elementos diferentes de una colección numérica. Tabla 1.2 Operadores de conjunto del LPT. 1.3 LPT-SQL: Herramienta para la generación automática de reglas de negocio La herramienta de software denominada, LPT-SQL, constituye un traductor de reglas de negocio que permite generar automáticamente la implementación de reglas del negocio especificado en lenguaje LPT, en bases de datos relacionales: vistas, funciones, disparadores. Estas reglas son traducidas como recursos de base de datos activos basados en código SQL (específicamente para PostgreSQL o SQL Server para implementar las reglas del negocio, que son almacenadas en un repositorio. El repositorio de reglas es descrito en un documento XML (Boggiano-Castillo et al., 2011) y es vital importancia para el mantenimiento de la consistencia (Alonso, 2008) y el logro de algún grado de independencia de las mismas con los SI. 1.3.1 Arquitectura de LPT-SQL . La herramienta LPT-SQL v1.4 está diseñada para ser utilizada por los especialistas o técnicos del sistema de información en la captura de las reglas de negocio en lenguaje LPT, viabilizando su traducción a lenguaje SQL, permitiendo la generación de las reglas de manera automática como recursos de bases de datos.. . La arquitectura de la herramienta LPT-SQL propuesta en (Boggiano et al., 2012) para la administración de reglas de negocio en bases de datos relacionales es la que se propone en la Figura 1.1.. 11.

(20) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. Figura 1.1 Arquitectura de la administración de reglas de negocio en bases de datos relacionales (Boggiano Castillo, 2014). Los componentes de la arquitectura son los siguientes: Repositorios. . Repositorio de reglas de negocio: Conformado por dos secciones, el repositorio primario de reglas que contiene cada regla en sus tres niveles: natural, técnico y formal. La segunda sección, que contiene las reglas compiladas que se deben generar y almacena la consulta base para la generación de la regla.. . Repositorio del catálogo: Contiene información sobre las tablas de las bases de datos del negocio, información sobre los nombres, atributos, interrelaciones, recursos activos, funciones, procedimientos almacenados y funciones. También almacena información sobre las tablas auxiliares para el control de la modificación.. Base de datos relacional del negocio: Se distinguen tres grupos de componentes: 12.

(21) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS . Tablas principales y sus atributos: Estos han sido nombrados con los términos adecuados del negocio en cada caso.. . Recursos activos: Los Disparadores, funciones, procedimientos almacenados, muchos de los cuales constituyen implementaciones de reglas de negocios de las categorías con perspectiva de los datos.. . Tablas de apoyo al control de versiones: Son tablas que registran con cuáles reglas se inserta cada dato.. Editor de reglas de negocio: Es un módulo que ha de permitir editar las reglas en lenguaje natural estructurado de patrones y lenguaje LPT, reconociendo los datos de los nombres de tablas y atributos. Administrador de reglas: Es el núcleo de esta arquitectura, está compuesto por: . Módulo extractor desde el catálogo: Extrae el catálogo de la base de datos y conforma el repositorio del catálogo.. . Traductor LPT-SQL: Con los datos almacenados en el repositorio primario de reglas, traduce las reglas de LPT a consulta base para la regla y las almacena en el repositorio de generación.. . Generador de reglas: A partir de la información guardada en el repositorio de generación que constituye el núcleo de la regla en el lenguaje formal SQL produce los recursos correspondientes a la implementación de la regla y los recursos (disparadores) que implementa las listas de eventos.. La herramienta cuenta con diferentes casos de uso, en las que el técnico o especialista tiene la posibilidad de realizar operaciones como: crear un nuevo Repositorio de Reglas del Negocio para almacenar las nuevas reglas, así como cargarlo una vez creado. Puede crear y activar una Regla del Negocio introduciendo el lenguaje formal de dicha regla y el lenguaje LPT que puede ser modificada o eliminada si se estima conveniente. Brinda la posibilidad de generar una Regla del Negocio que traduce el lenguaje LPT a lenguaje SQL. Extrae información referente a los catálogos, funciones, vistas, procedimientos y tablas existentes en la base de datos física que se ha conectado con anterioridad para realizar las operaciones sobre los recursos de la misma. Y Selecciona Modo de Interfaz de Usuario de la aplicación (Simple o Avanzada).. 13.

(22) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. 1.3.2 Recursos generados por LPT-SQL para la implementación de las reglas Los sistemas manejadores de bases de datos, es decir, los sistemas diseñados para administrar grandes cantidades de datos e información o sistemas de gestión de bases de datos (SGBD) ofrecen diversos recursos para el manejo de datos. En esta investigación, se presentan los recursos que se deciden emplear para la implementación de las reglas desde la perspectiva de los datos. A continuación se explica cada uno de ellos y su uso en los gestores de bases de datos: 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 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 la actualización de 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:. 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. Vistas (View). 14.

(23) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. 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 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 delas 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. 1.3.3 Ventajas y desventajas de LPT-SQL El traductor LPT-SQL tiene las siguientes ventajas:. 15.

(24) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS . 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.. . Contribuye a minimizar los errores cuando se introducen datos al sistema debido al conjunto de categorías de reglas llamadas reglas desde la perspectiva de datos; 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.. . 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.. . Crea un repositorio de reglas que guarda las reglas del negocio, independientemente de la base de datos y el sistema de información lo que contribuye a una mejor fluidez del chequeo de los datos en la base de datos.. A pesar de ello persisten algunas desventajas: . Permite expandir la generación de reglas solamente a dos sistemas gestores de base de datos: MS SQL Server o PostgreSQL. (Torres Vazquez, 2015).. . No detecta las inconsistencias en una regla de negocio o entre ellas. Este problema se convierte de vital importancia para el funcionamiento correcto de un Sistema de Información que implementa las reglas de negocio desde la perspectiva de los datos, pues el sistema está expuesto al riesgo de permitir que reglas inconsistentes sean implementadas, esto pudiera atentar contra la realización de las funcionalidades que se esperan.. 1.4 Consistencia de reglas de negocios Las reglas de negocio atraviesan por una serie de actividades fundamentales para regular cómo opera un determinado negocio: descubrimiento de las RN, análisis de las RN, diseño de las RN, autoría de las RN, validación de las RN, e implementación de RN (Jérôme Boyer 2011). Los expertos de negocio deben tener disponibles herramientas que les ayuden a verificar la coherencia o consistencia recíproca entre las reglas de negocio, según se especifica en (Group, 2003), solución ineludible del análisis de reglas de negocios. 16.

(25) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. Consistencia de reglas de negocios desde la visión de diferentes autores Un conjunto de reglas de negocio es consistente si juntas, proporcionan una única y coherente descripción (Morgan, 2002). Igualmente si existe, al menos, un conjunto de valores de todos los objetos que produzcan conclusiones no contradictorias (Aliente Zambrano and Ibañez Ortiz, 2008). La comprobación de consistencia es una de las tareas más delicadas y consumidoras de tiempo en las investigaciones de reglas de negocio (Ross, 2013), que posee alta calidad cuando no existe una regla similar o lógicamente equivalente a otra regla. Además si una regla no subsume otra regla o no entra en conflicto con otra (Solutions, 1996-2017). El control de los problemas en un conjunto de reglas de negocios profundiza la revisión de inconsistencias, falta de completitud, redundancias o anomalías (Mejía Castelo, 2011). Por otra parte, las definiciones más citadas en la literatura son de (Balci and Smith, 1986). Los autores de ese documento se basan en la validación y verificación de las reglas, coinciden en que la validación es muy a menudo confundida con la verificación, y proceden a tratar de aclarar los problemas de sus definiciones con las definiciones de estos términos. Afirman que la verificación se refiere a la construcción del sistema correcto, o de otra manera, la comprobación de que un sistema implementa correctamente sus especificaciones. La validación se refiere a construir el sistema correcto, es decir, demostrar que el sistema funciona con un nivel aceptable de precisión. En (Adrion et al., 1982) definen la verificación como la demostración de la coherencia, integridad y corrección del software, y la validación como la determinación de la corrección del programa final o software con respecto a las necesidades y requisitos del usuario incorpora los términos consistencia y la integridad. Otros autores opinan, por ejemplo (Polat and Guvenir, 1991): La verificación de la base de conocimientos, una parte del proceso de validación, incluye la comprobación de la base de conocimientos para su integridad y coherencia para protegerse contra una variedad de errores que pueden surgir durante el proceso de transferencia de conocimientos humanos a un sistema informático. Se observa aquí que definen la verificación como una parte de la validación. (Zlatareva, 1992) afirma que: La verificación consiste en detectar y corregir los errores estructurales y probar la completitud y violar las restricciones semánticas. 17.

(26) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. (Jafar, 1989) describe la verificación como la acción que garantiza la consistencia del sistema. La validación es construir el sistema que responde a los intereses reales de la organización, que es en otras palabras el sistema correcto. Es decir Escribir especificaciones y comprobar el rendimiento para asegurarse de que el sistema hace lo que se supone que debe hacer. El autor también dice que la validación implica la completitud y la conformidad de la producción con los requisitos establecidos. La verificación es el proceso de asegurar que el sistema inteligente 1) se ajusta a las especificaciones, y 2) su base de conocimiento es consistente y completa dentro de sí misma. A la inversa, la inconsistencia puede ser descrita como la presencia de errores tales como conflictos, redundancias, circularidad (particularmente insidiosa), y subsumiciones. Tenga en cuenta, sin embargo, que no hay mención de rendimiento contra el mundo real (experiencia humana) o más bien, la percepción del experto del mundo real. Esto se deja para la validación (Gonzalez and Barr, 2000). En (Mejía Castelo, 2011) se enuncia el concepto de verificación como el proceso dirigido a la detección de inconsistencias: ausencias de completitud o redundancia en un conjunto de reglas de negocio, que podrían llegar a resultados incorrectos o comportamiento indeseado detectados en el proceso de validación. (Ross, 2013) asegura también que la calidad de RN se divide en dos áreas generales: validación y verificación. La validación significa asegurar la corrección de RN con respecto al objetivo empresarial, es en gran parte una cuestión de inspección y se puede lograr utilizando diagramas, pruebas escenarios y análisis individual de cada regla de negocio. La verificación, por otra parte, significa evaluar la aptitud con respecto a la consistencia lógica y consiste en descubrir RN (usualmente dos o más en combinación) que exhiben anomalías. Las inconsistencias típicas en la especificación de verificación de reglas de negocio según (Palacio, 2014) son Redundancia: se produce cuando dos reglas tienen el mismo conjunto de condiciones (con condiciones posiblemente dispuestas en orden) y la misma conclusión. Superposición: ocurre cuando una regla es en parte dentro de otro o cuando dos reglas tienen el misma conclusión y una regla tiene una condición más restrictiva. La regla más restrictiva puede 18.

(27) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. ser subsumida por el menos Restrictiva, alegando que siempre que la primera tiene éxito, este último también tiene éxito. Conflicto: sucede cuando dos o más reglas producen resultados contradictorios o su Partes condicionales consisten en el mismo conjunto, pero las Son mutuamente excluyentes. No completitud: ocurre cuando toda la información necesaria para producir una conclusión no existe. Esto puede deberse al conocimiento incierto o pérdida de la pista de la creciente base de conocimientos. Se aplican diferentes estrategias para la validación y verificación de las reglas de negocios enunciadas en (Cintra, 2012) entre las cuales podemos citar las Inglés/Español estructurado, los árboles de decisión y las tablas de decisión; retomadas por (Lorenzo, 2009) en conjunto con las estrategias de la lógica estructurada y los diagramas de transición de estado (redes de Petri). (Najiba et al., 2015) presenta los métodos más conocidos para el tratamiento de anomalías en las reglas de negocio basadas en diferentes estrategias: los meta-lenguaje, las redes de Petri, la programación lógica de la teoría de conjuntos vaga y los motores de no-inferencia, algunos presentan algoritmos para verificar anomalías y otros de resolución. 1.4.1 Diferentes estrategias para garantizar la consistencia de reglas de negocios Lógica estructurada realiza la modelación lógica y descripción de la ejecución de acciones de las reglas del negocio utilizando las diferentes construcciones de la programación estructurada.  si...entonces  caso1...caso2...caso3...o entonces  en cuanto...  hasta que...  de 1 a n Un diagrama de transición de estado o red de Petri (RP) es un grafo dirigido que utiliza dos tipos de nodos: localizaciones y transiciones. Las localizaciones se representan mediante círculos y las transiciones con rectángulos. Los nodos se conectan entre sí mediante arcos dirigidos y no están permitidas las conexiones entre nodos de un mismo tipo (van der Aalst et al., 2003). Una definición más rigurosa es: Una RP es una tripleta (P, T, F), donde: 19.

(28) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. •. P es un conjunto finito de localizaciones.. •. T es un conjunto finito de transiciones.. •. F⸦ (P x T). (T x P) es un conjunto de arcos.. Las redes de Petri pueden ser utilizadas para modelar reglas de negocio. Las propiedades estructurales de las permiten a su vez realizar el análisis de validación y verificación del conjunto de reglas que ha sido representado por la red. Esta metodología exige que las reglas se expresen como enunciados de la lógica formal. Posteriormente estos enunciados condicionales deben ser transformados en una representación equivalente en RP. La transformación se basa en una asignación entre las operaciones lógicas de conjunción (Λ), disyunción (V), y la implicación y las nociones de sincronización, concurrencia, elección, etc., de la teoría de RP. Una vez que una base de reglas se transforma en una RP, la solución al problema se convierte en una aplicación directa de herramientas de análisis de la teoría de RP. La validación y verificación de la base de reglas se realiza primero mediante la explotación de las propiedades estructurales de la representación de RP y luego mediante la construcción del gráfico de ocurrencias directamente a partir de la representación de RP (Zaidi and Levis, 1997). Hay que señalar que un par de conceptos mutuamente exclusivos no pueden ser identificados a menos que hayan sido definidos. Con las RP se pueden detectar anomalías de reglas redundantes, subsumidas e inconsistentes por: contradicción directa (caso μ es un conjunto de predicados mutuamente excluyentes), contradicción en la conclusión (caso que se presentan antecedentes iguales que implican conclusiones mutuamente excluyentes y la contradicción en las premisas. También se detectan las reglas circulares y la incompletitud. El inglés o español estructurado resuelve los problemas de ambigüedad del lenguaje al establecer condiciones y acciones, tanto en procedimientos como en decisiones. Este método no hace uso de árboles o tablas; en su lugar utiliza declaraciones para describir el proceso. El proceso no muestra reglas de decisión, las declara (Landinez, 2009). Aún con esta característica, las especificaciones en inglés/español estructurado requieren que el analista primero identifique las condiciones que se presentan en un proceso y las decisiones que se deben tomar cuando esto sucede, junto con las acciones correspondientes. Sin embargo, el método también permite hacer 20.

(29) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. una lista de todos los pasos en el orden que se llevan a cabo. Para ello no se utilizan símbolos y formatos especiales, características de los árboles y las tablas de decisión que para algunos resultan incómodos. Además, es posible describir con rapidez los procedimientos en su totalidad ya que para ello se emplean declaraciones muy similares al español o al inglés. La terminología utilizada en la descripción estructurada de una aplicación consiste, en gran medida, en nombres de datos para los elementos que están definidos en el diccionario de datos desarrollado para el proyecto. El inglés/español estructurado emplea tres tipos básicos de declaraciones para describir un proceso: estructuras de secuencia, estructuras de decisión y estructuras de iteración (Landinez, 2009). El árbol de decisión es un diagrama que representa en forma secuencial de condiciones y acciones; muestra qué condiciones se consideran en primer lugar, cuáles en segundo y así sucesivamente. Permite mostrar la relación que existe entre cada condición y el grupo de acciones permisibles asociado con ella. La raíz del árbol es el punto donde comienza la secuencia de decisión. La rama a seguir depende de las condiciones existentes y de la decisión que debe tomarse. Al avanzar de izquierda a derecha por una rama en particular, se obtiene una serie de toma de decisiones. Después de cada punto de decisión, se encuentra el siguiente conjunto de decisiones a considerar. De esta forma, los nodos del árbol representan condiciones y señalan la necesidad de tomar una determinación relacionada con la existencia de alguna de estas, antes de seleccionar la siguiente trayectoria. La parte que se encuentra a la derecha del árbol indica las acciones que deben realizarse, las que a su vez dependen de la secuencia de condiciones que las proceden (Vaniachine et al., 2005). Los árboles de decisión son normalmente construidos a partir de la descripción de la narrativa de un problema. Se recomienda el uso del árbol de decisión cuando el número de acciones es pequeño y no son posibles todas las combinaciones (Lorenzo, 2009). El desarrollo de árboles de decisión beneficia al analista en dos formas. Primero que todo, la necesidad de describir condiciones y acciones llevan a los analistas a identificar de manera formal las decisiones que actualmente deben tomarse. De esta forma, es difícil para ellos pasar por alto cualquier etapa del proceso de decisión, sin importar que esta dependa de variables cualitativas o cuantitativas (Mass Chaviano, 2010, Ross and Lam, 1999). 21.

(30) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. La tabla de decisión sintetiza procesos en los cuales se dan un conjunto de condiciones y un conjunto de acciones a tomar según el valor que toman las condiciones (Castilla, 2007). Está integrada por: matriz de condiciones, matriz de acciones y matriz de reglas para condiciones y acciones. En la matriz de condiciones se enumeran todas las situaciones que pueden presentarse. Las reglas de condiciones indican qué valor debe asociarse a cada una de las condiciones. En la matriz de acciones se listan el conjunto de todos los pasos que se deben seguir cuando se presentan ciertas condiciones. Las reglas de acciones muestran las acciones específicas del conjunto que deben emprenderse dados los valores que toman las condiciones. Primeramente se pasa a llenar la tabla y al concluir es depurada para encontrar errores en las reglas mediante algunas leyes. En los sistemas basados en tablas pueden presentarse diferentes tipos de anomalías en tablas, propuestas por Jan Vanthienen que se pueden distinguir entre casos de redundancia, ambivalencia, circularidad y deficiencia (Preece and Shinghal, 1994, O'Keefe and O'Leary, 1993). De acuerdo al lugar donde ocurren, se pueden distinguir dos tipos de anomalías: intratabular e inter-tabular. La anomalía intra-tabular se puede ver claramente que ocurre entre los componentes dentro de una misma tabla simple, donde la redundancia se desglosa en entrada de acción redundante, fila de acción inusual y columna insatisfecha, y la ambivalencia en una entrada de acciones ambivalentes. Sin embargo la inter-tabular ocurre durante la interacción entre los componentes de diferentes tablas en las que la redundancia se ve en los pares de columnas o filas duplicadas, y la ambivalencia a nivel de columna o fila. Los metalenguajes son las especificaciones para manipular el conocimiento racional y lingüístico, es decir, un conjunto de convenciones que norman la comunicación en un lenguaje. El metalenguaje es un lenguaje que trata sobre lenguaje(s). Desde la óptica de la matemática y la lógica, un metalenguaje constituye la fundamentación del lenguaje-objeto de los sistemas formales. En sistemas semióticos de base no axiomática como la lengua se ha reconocido también un rol fundacional. Aunque el lenguaje cotidiano podría verse sincrónicamente como un sistema completo, con la mayor parte del léxico adquirido en una etapa relativamente temprana de la vida, la comunicación especializada depende crucialmente de un inventario léxico en constante cambio, con la introducción permanente de términos y conceptos que refleja los cambios en el estado del arte de una disciplina.. 22.

(31) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. Programación lógica de la teoría de conjuntos difusos La teoría difusa (llamada también Lógica Borrosa por otros autores) o Fuzzy Logic se basa en la teoría de los conjuntos difusos introducida por el profesor Lotfi Asker Zadeh en 1965, profesor de Ingeniería Eléctrica y Ciencias de la Computación de la Universidad de California en Berkeley. En el artículo publicado por Zadeh se introdujo por primera vez la palabra “`fuzzy” en la literatura técnica y describe con la teoría matemática de conjuntos clásicos, como se puede trabajar matemáticamente con expresiones imprecisas, tal como lo hace el ser humano (Aizemberg, 1997). La teoría de los conjuntos difusos es una extensión de la teoría de conjuntos clásicos, que relaciona la pertenencia de la clase de un objeto con un cierto grado, sin haber fronteras abruptas entre una clase de objetos y otros; en el caso clásico un elemento puede pertenecer o no a un cierto conjunto. Zadeh sugiere, en 1965, el concepto de conjunto difuso es la inconsistencia del formalismo matemático o lógico que es empleado para describir fenómenos o relaciones mal-definidos, vagos o subjetivos. Un conjunto difuso está definido por una función continua de grados de pertenencia, ya no a la manera clásica donde teníamos sólo dos posibles valores, 0 ó 1, sino que pertenencia está dada sobre el intervalo real [0,1]. Las nociones de inclusión, unión, intersección, complemento y relación pueden ser extendidas a este tipo de conjuntos. La Lógica Difusa es básicamente una lógica con múltiples valores, que permite definir valores en las áreas oscuras entre las evaluaciones convencionales de la lógica precisa: Si / No, Cierto / Falso, Blanco / Negro, etc. Se considera un súper conjunto de la Lógica Booleana. Con la Lógica Difusa, las proposiciones pueden ser representadas con grados de certeza o falsedad. La lógica tradicional de las computadoras opera con ecuaciones muy precisas y dos respuestas: Si o no, uno o cero. Ahora, para aplicaciones de computadores mal definidas o sistemas vagos se emplea la Lógica Difusa (Aizemberg, 1997). La teoría de conjuntos difusos provee una buena herramienta para modelar sistemas imprecisos. Las aplicaciones van desde economía y ciencias sociales hasta inteligencia artificial, desde procesos de control industrial hasta diagnóstico médico computarizado. Como se puede ver el campo de acción es realmente grande. No sólo en el terreno práctico es donde se ha avanzado con los sistemas difusos, hay además un gran espectro de estudios teóricos sobre esta disciplina. 23.

(32) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. A partir de estas estrategias se proponen métodos que propician una eficiente herramienta para comprobar la consistencia de las reglas. 1.4.2 Métodos de verificación para consistencia de reglas de negocios Método EVA basado en metalenguajes El método EVA constituye una herramienta para verificar las anomalías del sistema basada en el conocimiento. Utiliza un meta-lenguaje declarativo (lenguaje de orden superior) para describir las restricciones necesarias para validar la redundancia, consistencia, circularidad, superposición y corrección de una base de conocimientos. Este método se extendió a la lógica no monótona y propone tres tipos de comprobación: estructural, lógica y semántica. Por lo tanto, ofrece la detección más completa (Najiba et al., 2015). Para tratar la redundancia y la superposición se comprueban las reglas de duplicación y subsunción, si el lado izquierdo (LHS) de la primera regla subsume o es la misma que la LHS de la segunda regla, entonces cada vez que una de las reglas puede ser rechazada. Por lo tanto, cualquier acción en el lado derecho (RHS) de la segunda regla que también ocurre en el RHS de la primera regla puede ser eliminada. Si después de la eliminación no quedan acciones en el RHS de R2, entonces R2 puede ser eliminado. Para comprobar los ciclos, el método introduce el metapredicado, define las reglas del ciclo utilizando el término de los predicados básicos, o los términos de los predicados básicos y derivados. Por ejemplo, el predicado "antepasado" puede definirse en términos del predicado básico "padre". Para averiguar inconsistencias lógicas, el método utiliza el meta-predicado -incompatible‖ como una meta para el comprobador de lógica. Inicia el encadenamiento hacia atrás para resolver el objetivo. Si encuentra respuestas para el objetivo, entonces las Bases de Conocimiento son inconsistentes, de lo contrario no es inconsistente. Método PREPARE basado en redes de Petri PREPARE (PREdicate/transition nets andPAtternREcognitionmethod) utiliza redes de predicado/transición para representar el conocimiento. Estas redes son clases especiales de redes de Petri y la verificación se realiza a través de patrones sintácticos de reconocimiento. Las reglas inconsistentes, redundantes, subsumidas, circulares e incompletas en una base de conocimiento. 24.

(33) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. se definen como patrones del modelo de red Predicado/Transición y se detectan a través de un método de reconocimiento de patrones sintáctico. Estas redes son una representación gráfica de la lógica predicada. PREPARE proporciona un enfoque para verificar la corrección de las bases de conocimiento. Comprueba la inconsistencia, redundancia, circularidad y no completitud en una base de conocimientos. Mediante el uso del transformador de componentes, traduce reglas y hechos de una base de conocimientos a una representación neta de Pr/T comprensible por una computadora; Y con el fin de detectar y localizar los límites de los patrones inconsistentes, redundantes, circulares e incompletos; utiliza el componente Escáner y almacena el resultado en una tabla. Después de la detección de las anomalías, el componente Formulador codifica y formula una cadena para cada patrón inconsistente/redundante/circular y guarda los resultados en una segunda tabla (Najiba et al., 2015). Método de conjuntos vague, que utiliza teoría de conjuntos difusos Este método proporciona un algoritmo para detectar y resolver el conflicto de RN a través de la Teoría de Conjunto Difuso que se introduce para medir las relaciones de preferencia entre las reglas de conflicto con la ayuda de las condiciones de post en las reglas SOECAP, y luego un nuevo método de resolución de conflictos presentados. El modelo SOECAP es una extensión del modelo ECA (Evento, Condición, Acción) con los conceptos sujeto-objeto y post-condición. El sujeto y el objeto se introducen para representar el desencadenante y el objeto efectivo de la regla e implican las relaciones lógicas entre los dos tipos de entidades involucradas en la regla. Post-Condición se presenta para presentar la restricción de estado del sistema impuesta por las acciones de la regla, apuntando a los problemas de detección y resolución sobre conflicto de reglas. El algoritmo que se utiliza en este método basado en un conjunto vago se presenta como sigue en la fig. 3, toma como entrada el conjunto de reglas representado por S, y el R representa el conjunto de resoluciones correspondiente a S, A como conjunto de acciones de regla, y la función get-Preferencia se utiliza para calcular el valor de preferencia de la resolución de regla a conflicto regla. R representado como regla, r.o es el objeto de r, y r.p es la postcondición de r.. 25.

(34) CAPÍTULO 1: CONSIDERACIONES TEÓRICAS SOBRE LA CONSISTENCIA EN LAS REGLAS DE NEGOCIOS. Figura 1.2 Algoritmo que utiliza en este método basado en un conjunto difuso. Tomado de (Najiba et al., 2015).. URKCTA Este método utiliza la decisión de grupo, con un algoritmo que tiene un factor de confianza. En el algoritmo, un "factor de confiabilidad" (FC) se refiere al nivel de confiabilidad de las reglas conflictivas o redundantes, mientras que el "factor de certeza" (fC) indica la existencia del conocimiento mismo. Un "índice de confiabilidad de certeza" (ICC) se usa para mostrar tanto la existencia del conocimiento mismo como su fiabilidad. Para reglas conflictivas o redundantes, se sugiere que se elija el conocimiento con un factor de fiabilidad más alto. Para el conocimiento basado en reglas inciertas, el estudio integró la decisión del grupo y los conceptos de inferencia inciertos para presentar URKCTA en el que FC representa la confiabilidad del conocimiento con reglas conflictivas o redundantes; fC representa la certeza de la existencia del conocimiento mismo; Y el ICC indica exhaustivamente la existencia del propio conocimiento y su fiabilidad. El estudio reveló el ICC para reglas conflictivas o redundantes, y mostró exhaustivamente la existencia y confiabilidad de la regla misma para determinar la certeza y confiabilidad del conocimiento citado Método con programación lógica Este método utiliza un lenguaje de descripción de políticas declarativo PDL, en el cual las políticas se formulan como conjuntos de reglas ECA (Evento, Condición, Acción) y presenta un marco para detectar conflictos de acción y encontrar resoluciones a estos conflictos. Los conflictos son capturados como violaciones de restricciones de acción. La semántica de las reglas 26.