Sistema de bases de datos para el control de pacientes en el área de nefrología guiado por reglas de negocio

Texto completo

(1)Ministerio de Educación Superior Universidad Central “Marta Abreu” de Las Villas Facultad de Matemática, Física y Computación. TRABAJO DE DIPLOMA. “Sistema de Bases de Datos para el control de pacientes en el área de Nefrología guiado por reglas de negocio”. AUTORES: Annieris Rodríguez Velazco Rafael Jesús Varona Ulloa TUTORES: MSc. María Elena Martínez del Busto MSc. Eladio Cuellar Vega CONSULTANTE: Lic. Jorge Alberto González Mena SANTA CLARA - 2010 “Año 52 de la Revolución”.

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

(3) Dedicatoria. Esta tesis la dedicamos a nuestras familias, que nos han brindado todo el amor del mundo y el apoyo necesario para realizar este sueño que no es solo nuestro, sino de todos.. A mi madre adorada, que siempre ha confiado en mí, que ha sido madre y amiga, que disfruta mis victorias y sufre mis derrotas, que es mi ejemplo y mi bien más preciado, el ángel que dios me ha dado. A mis abuelos, por su preocupación constante, sus deseos de vivir y por hacerme la nieta más feliz del mundo. A mis dos padres por encontrar, en su aparente seriedad, la ternura infinita para hacerme sentir cada día su niñita querida. Annieris A mi madre que ha luchado para que nada me falte, que confía en mí sobre todas las cosas, a la que debo todo cuanto soy. A mi abuela Mima por su apoyo incondicional y todo su cariño. A mi hermano al que quiero servir de inspiración para que un día nos llene a todos de felicidad con un título. A mi padrastro Fernando por convertirse en un padre para mí y por todo el cariño que nos ha brindado a mí y a mi hermano. A mi papá Rafael. Rafael.

(4) Agradecimientos. Queremos agradecer a nuestras familias por su dedicación y su amor. A nuestros amigos y a sus familias porque se han robado un pedacito de nuestro corazón y sin esforzarse se convirtieron en un gran tesoro para nosotros. A nuestros profesores por todas sus enseñanzas y por servirnos de ejemplo. A mi mamá que se ha sacrificado mucho para que mis sueños se hagan realidad. A mi papá que quiero con el alma. A mi padrastro Pancho, mis hermanos y demás familia, que es mía también. A mis abuelos que me miran con orgullo. A mis tíos y primos por estar presentes siempre que los necesité. A mis vecinos Idania, Padilla y Yeny por apoyarme en momentos difíciles. A la familia de mi novio por acogerme como una hija y ayudarme a pasar los duros días en que mi madre no se encontraba a mi lado. A mi novio por estar siempre a mi lado, por comprenderme y enseñarme a crecer. A mi profesor Jesús F. Manzano por enseñarme que con esfuerzo los sueños se realizan. Annieris A mi madre por su dedicación y sacrificio constante para facilitarme las cosas. A mi abuela por complacerme en todo. A mi hermano porque me reta a superarme cada día. A mi padrastro Fernando porque con él he aprendido a crecer. A mi papá Rafael, que aunque no viva conmigo lo recuerdo siempre. A mis tíos y primos que me apoyaron en todo. Rafael Agradecimientos especiales: A nuestra tutora María Elena, por ser un ejemplo de educadora y de buena amiga, por compartir su dulzura con estos niños que tanto la quieren, y a nuestro tutor Eladio. A Jorgito y a su esposa Milka, porque sin su ayuda no estaríamos hoy aquí.. A todas estas personas y a muchas más le estaremos eternamente agradecidos..

(5) Resumen. Resumen Los problemas con el tratamiento informal de las restricciones en los Sistemas de Información han permitido considerar como factor de esencial importancia la forma en que se manejan los requisitos, tratados en muchas investigaciones mediante el enfoque de reglas de negocio. El presente trabajo aborda el Desarrollo de un Sistema de Información (DSI) para el área de trasplante renal del Hospital Docente “Arnaldo Milián Castro” de Villa Clara, guiado por Reglas de Negocio (RN). Expone además una taxonomía de clasificación que permite recomendar la ubicación de las reglas en una arquitectura de tres capas e indica mediante ejemplos formas de implementación en el sistema. Para el DSI se utiliza una aplicación Web con arquitectura cliente/servidor de tres capas y la plataforma de software libre CakePHP que permite la separación entre los datos, la lógica del negocio y la presentación, lo que facilita los procesos de diseño e implementación, así como el mantenimiento del sistema..

(6) Abstract. Problems with informal treatment of restrictions in information systems have enabled regard as an essential factor the way requirements are managed, treated in various researches by focusing on business rules. This paper addresses the Development of Information Systems (DSI) for the area of renal transplantation Training Hospital "Arnaldo Milian Castro" in Villa Clara, led by Business Rules (RN). It also exposes a taxonomy of classification which permits recommend the location of the rules in a three-tier architecture and shows giving example the forms of implementing the system. For the DSI should use a Web application with client-server three-tier architecture and the CakePHP of the free software platform that allows the separation between data, business logic and the presentation, which facilitates the design and implementation processes as well as the system maintenance..

(7) Tabla de Contenidos. Tabla de contenido Tabla de Ilustraciones .............................................................................................................................. 1 Introducción ............................................................................................................................................ 1 Antecedentes del trabajo .................................................................................................................... 2 Hipótesis de la investigación ................................................................................................................ 3 Objetivo general .................................................................................................................................. 3 Objetivos específicos ........................................................................................................................... 3 Valor práctico ...................................................................................................................................... 4 Viabilidad ............................................................................................................................................ 4 Estructura de la tesis ........................................................................................................................... 5 CAPITULO 1: “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema” .................................................................................................................................................. 7 1.1.. Antecedentes ........................................................................................................................... 7. 1.2.. Reglas de Negocio .................................................................................................................... 7. 1.2.1.. Características y propiedades ........................................................................................... 8. 1.2.2.. Formulación de las reglas de negocio ............................................................................... 9. 1.3.. Sistemas de Información con enfoque de Reglas de Negocio .................................................. 11. 1.4.. Clasificación de Reglas de Negocio ......................................................................................... 12. 1.4.1.. Clasificación semántica ................................................................................................... 12. 1.4.2.. Clasificación cercana a la implementación ...................................................................... 18. 1.4.3.. Convergencia de la clasificación semántica y la cercana a la implementación ................. 19. 1.5.. Consideraciones para la implementación de reglas de negocio............................................... 26. 1.5.1.. Gestores de bases de datos y la implementación de reglas de negocio ........................... 27. 1.5.2.. Arquitectura de sistemas y la implementación de reglas de negocio ............................... 28. 1.5.3.. Formas de implementación ............................................................................................ 33. 1.6.. Conclusiones parciales del capítulo ........................................................................................ 37. CAPITULO 2: “Las Reglas de Negocio en la arquitectura del sistema” ..................................................... 38 2.1.. Criterios para ubicar las reglas de negocio en la arquitectura del Sistema de Información ...... 38.

(8) Tabla de Contenidos. 2.1.1.. Adecuar la ubicación de cada tipo de regla de negocio ................................................... 42. 2.2.. Modelo de procesos de negocio para área de nefrología ........................................................ 43. 2.3.. Arquitectura de tres capas para la aplicación.......................................................................... 45. 2.3.1.. Capa servidor o de datos .................................................................................................... 46. 2.3.1.1.. Diseño de la Base de Datos ......................................................................................... 46. 2.3.1.2.. Capa de datos para el sistema de trasplante renal ...................................................... 49. 2.3.2.. Capa intermedia o de negocio ............................................................................................ 51. 2.3.2.1. 2.3.3.. Capa intermedia para el sistema de trasplante renal................................................... 51. Capa cliente o de interfaz de usuario .................................................................................. 54. 2.3.3.1.. Capa cliente para el sistema de trasplante renal ......................................................... 54. 2.4.. Distribución física de las capas de la arquitectura ................................................................... 55. 2.5.. Conclusiones parciales ........................................................................................................... 56. Capítulo III: “Diseño e implementación del Sistema de control de pacientes de trasplante renal” .......... 57 3.1.. Herramientas usadas para la implantación del sistema........................................................... 57. 3.1.1.. Modelo Vista Controlador .............................................................................................. 57. 3.1.2.. MySQL como gestor de bases de datos ........................................................................... 59. 3.2.. Diseño del sistema para control de la sala de trasplante renal ................................................ 60. 3.2.1.. Casos de uso del sistema ................................................................................................ 60. 3.2.2.. Diagrama de actividad .................................................................................................... 61. 3.2.3.. Diagrama de secuencia ................................................................................................... 62. 3.3.. Manual de usuario para el Sistema de información de trasplante renal .................................. 63. 3.3.1.. Entrada al sistema .......................................................................................................... 63. 3.3.2.. Pacientes de atención secundaria ................................................................................... 65. 3.3.3.. Trasplante ...................................................................................................................... 67. 3.3.4.. Complementarios ........................................................................................................... 69. 3.4.. Conclusiones parciales ........................................................................................................... 70. Conclusiones ......................................................................................................................................... 71 Recomendaciones ................................................................................................................................. 72 Referencias Bibliográficas ...................................................................................................................... 73.

(9) Tabla de Contenidos. Anexo 1 ................................................................................................................................................. 75 Anexo 2 ................................................................................................................................................. 82 Anexo 3 ................................................................................................................................................. 88.

(10) Tabla de Ilustraciones. Tabla de Ilustraciones CAPITULO I Figura 1. 1: Definición de Reglas de Negocio (Morgan, 2002). ................................................................ 10 Figura 1. 2: Esquema de convergencia de las clasificaciones. ................................................................. 20 Figura 1. 3 : Esquema de arquitectura Cliente/Servidor clásica. ............................................................. 29 Figura 1. 4 : Arquitectura Cliente/Servidor en tres capas........................................................................ 31 CAPITULO II Figura 2. 1: Ubicación de las reglas de negocio dentro del esquema de tres capas. ................................ 42 Figura 2. 2 Diagrama de Estado para describir el comportamiento de la clase Paciente. ........................ 44 Figura 2. 3: Arquitectura en tres capas................................................................................................... 45 Figura 2. 4: Submodelo para la entidad Paciente ................................................................................... 48 Figura 2. 5: Submodelo de Trasplante Renal .......................................................................................... 49 Figura 2. 6: Representación de una regla de negocio en la capa de datos. .............................................. 50 CAPITULO III Figura 3. 1: Relación entre el modelo, la vista y el controlador. .............................................................. 59 Figura 3. 2: Diagrama de casos de uso del negocio. ................................................................................ 60 Figura 3. 3: Diagrama de actividad para el caso de uso Gestionar consulta de evolución. ....................... 62 Figura 3. 4: Diagrama de secuencia para el caso de uso Ingresar resultados de análisis. ......................... 63 Figura 3. 5: Vista de autentificación ....................................................................................................... 64 Figura 3. 6: Vista de inicio ...................................................................................................................... 65 Figura 3. 7: Listado de los pacientes ....................................................................................................... 66 Figura 3. 8 Vista de edición de los datos del paciente ............................................................................ 67 Figura 3. 9: Listado de los receptores ..................................................................................................... 68 Figura 3. 10: Vista de edición de los datos del receptor .......................................................................... 69 Figura 3. 11: Vista de acciones complementarias ................................................................................... 70. 1.

(11) Introducción. Introducción La Enfermedad Renal Crónica (ERC) incrementa anualmente la cantidad de enfermos en un 10%, por esto se considera un problema epidemiológico que necesita un constante seguimiento. La insuficiencia renal crónica es considerada un problema de salubridad y un reto de gran envergadura para las instituciones de salud pública y los gobiernos. El manejo de la información necesaria para el proceso de Trasplante Renal es voluminoso y de vital importancia. El Trasplante Renal (TR) es una alternativa que permite a los pacientes que presentan la ERC salir de las “listas de espera” que se crean para los casos que necesitan tratamiento urgente. El TR no solo es mejor en el orden biológico, sino que también económicamente es más rentable, comparado por ejemplo con que mantener en los Estados Unidos un paciente con diálisis peritoneal o hemodiálisis cuesta alrededor de 47 000 dólares al año, mientras que con el trasplante sería aproximadamente 17 000 dólares el primer año, luego se abarata más por recibir menos drogas. El TR, pionero en el mundo, comenzó a realizarse en nuestro país el 24 de febrero de 1970, en el Instituto de Nefrología de La Habana. Cuba está colocada a la vanguardia en cuanto al número de trasplantes renales con donantes cadáver en nuestra región y esto ha sido posible gracias a nuestro programa nacional de enfermedad renal crónica. El progreso experimentado por los trasplantes en los últimos 40 años ha sido trascendental. Las nuevas técnicas y terapias inmunosupresoras han hecho posible que esta modalidad de tratamiento sustitutivo se haya generalizado. Los servicios de salud se caracterizan, en general, por un control de la evolución de los pacientes en consultas generales y su continuidad en consultas especializadas en la medida en que los diagnósticos ganan en precisión y los casos así lo requieren. Esta práctica médica, aparentemente sencilla, supone un respaldo informativo que en su fase primaria puede ser bastante estándar, pero que en la medida que los casos pasan a una atención más especializada, requieren un tratamiento diferenciado y difícilmente se pueden abordar soluciones generales; razón por la cual se inicia esta experiencia con el estudio de los servicios de nefrología. 1.

(12) Introducción. Se reconoce que el éxito que han tenido los trasplantes de riñón, se debe a dos razones: en primer lugar al desarrollo que sin lugar a dudas han tenido las nuevas técnicas quirúrgicas y a los tratamientos médicos asociados. Si bien es cierto que la razón anteriormente mencionada está asociada a avances en la medicina; la segunda razón está relacionada con la aparición y desarrollo de estructuras organizativas que permiten el control coordinado de todas las fases que intervienen en un protocolo para un proceso de trasplante, el control de los receptores y de la donación de los órganos, acorde a políticas y leyes locales, nacionales e incluso internacionales relacionadas con la donación de órganos. La organización y coordinación de trasplantes es una tarea compleja que requiere varias actividades clínicas donde se involucran numerosas personas y equipos de trabajos; a la vez que constituye un proceso administrativo paralelo a los procesos clínicos. Desde el punto de vista computacional, para la coordinación y realización de dichas actividades se requiere usualmente la aplicación de tecnologías que responden a diferentes paradigmas computacionales, sobre esta base las aplicaciones pueden variar en dependencia del peso que se le otorgue a alguno de ellos; en la actualidad el enfoque conocido por reglas de negocio coloca en un primer plano la captación de las políticas, leyes, etc. que deben hacerse cumplir o simplemente observar durante los procesos que se llevan a cabo. La identificación de todas las regulaciones relacionadas con un servicio y su posterior consideración en sistemas que las hagan cumplir, constituye un nuevo enfoque que eleva el rigor y mejora la calidad de los servicios que se ofrecen.. Antecedentes del trabajo En el hospital docente “Arnaldo Milián Castro”, de Villa Clara, los pacientes que padecen enfermedades renales crónicas son atendidos en una consulta multidisciplinaria denominada Consulta de Enfermedad Renal Crónica Avanzada o Consulta de Progresión, en la que pueden ser reorientados a sus áreas de salud o remitidos a métodos sustitutivos, entre los que se encuentran: hemodiálisis y trasplante renal.. 2.

(13) Introducción. El manejo eficiente de la información referente al Área de Nefrología para el hospital es muy importante debido a que el tiempo resulta un factor crítico y al elevado consumo de recursos, tanto humanos como materiales. Con el propósito de lograr la automatización de las actividades necesarias para el área de nefrología, se realiza en el 2008 el desarrollo de un sistema de información con arquitectura de tres capas y un ambiente Web que cumplen con las reglas de negocio propias de la integridad de los datos para automatizar los procesos relacionados con el área de nefrología. Para dar continuidad a este trabajo se impone la necesidad de identificar, ubicar e implementar las reglas de negocio que se obtienen desde los objetivos de los procesos del área de nefrología.. Hipótesis de la investigación Procesos como la Consulta de Progresión, Hemodiálisis Ambulatoria y Trasplante Renal en el área de nefrología pueden ser automatizados utilizando tecnología Web y el diseño de un Sistema de Bases de Datos regido por reglas de negocio, lo que permite gestionar los requerimientos del sistema y en particular llevar el control total de los pacientes de esta área, así como servir para ampliar el valor docente, científico e investigativo de la información médica que aparecerá en la base de datos. Para dar cumplimiento a la hipótesis de la investigación planteada se proponen los siguientes objetivos:. Objetivo general Implementar un Sistema de Información para el control de pacientes en el tratamiento del trasplante renal guiado por reglas de negocio.. Objetivos específicos 1. Identificar el conjunto de reglas durante la etapa de identificación de requisitos y la modelación de datos y sistema. 2. Estudiar el diseño de la base de datos existente y proponer modificaciones según sea necesario. 3.

(14) Introducción. 3. Caracterizar la implementación de cada tipo de regla, justificando en cada caso su ubicación en la arquitectura del sistema. 4. Implementar un sistema de información para la problemática con una arquitectura de tres capas, ubicando en cada una los diferentes tipos de reglas.. Valor práctico Los procesos de Consulta de Progresión, Hemodiálisis Ambulatoria y Trasplante Renal abarcan un conjunto de escritos, modelos y documentación, que cuando se realizan manualmente requieren de gran cantidad de recursos (humanos, de tiempo y de papel), para lograr mantener la información actualizada, de manera que se pueda localizar cuando se necesite. Con esta aplicación los usuarios finales automatizan la gestión de la información referente a los procesos del área de nefrología, se torna más eficiente y segura la atención al paciente y se brinda a los clientes una interfaz cómoda y de fácil uso que humaniza el trabajo cuando necesiten consultar, modificar o agregar datos. Este sistema de información con servicios mediante la web permitirá al personal médico y paramédico ingresar y analizar información existente en la base de datos desde cualquier sitio de la red hospitalaria, permitiendo realizar consultas con otras provincias. La consulta multidisciplinaria puede incluir la valiosa colaboración de especialistas que se encuentren en otros centros hospitalarios. De esta forma casos complejos pueden ser motivo de estudio por un equipo médico, sin tener que movilizarse hacia el lugar donde se encuentre el paciente. La información almacenada facilita el estudio de casos a investigadores del tema, tanto en pregrado como en estudios de especialidad o postgrado, constituyendo una importante herramienta investigativa y un valioso material de consulta.. Viabilidad Con el desarrollo de las tecnologías cliente/servidor, las tecnologías de bases de datos y los lenguajes de programación, actualmente se pueden enfrentar con éxito los desafíos de desarrollar 4.

(15) Introducción. una aplicación computacional como la del presente trabajo. Tanto MySQL (gestor de base de datos) como PHP (lenguaje de programación) han sido objeto de estudio a lo largo de la carrera, facilita el dominio de los conocimientos y habilidades necesarias para enfrentar esta tarea. Actualmente el hospital “Arnaldo Milián” cuenta con una red local cuya conexión es estable y rápida (hasta 100 Mbps). Esto le permite a los nefrólogos y enfermeras, relacionados con esta labor, una fácil conexión con la red del centro para la gestión automatizada de la información necesaria en el desempeño de su labor como especialistas. El uso de la programación Web, en especial de la herramienta CakePHP, con arquitectura Modelo-Vista-Controlador, permiten separar la parte de la interfaz visual de la lógica del negocio, brindando mayor modularidad y flexibilidad ante posibles cambios futuros o integración con otros sistemas. Conscientes de la importancia social de la aplicación, el hospital ha facilitado los recursos necesarios, tanto materiales como humanos, para la realización de la misma. Se habilitó un servidor de PHP y otro de MySQL, que por demás, son de fácil instalación y uso, se asesoró en todas las cuestiones referentes a conceptos específicos manejados por el centro y se suministró toda la información necesaria referente al tema para realizar el modelado del proceso.. Estructura de la tesis La tesis se estructura en tres capítulos. El primer capítulo se refiere a las Reglas de Negocio, sus antecedentes, características, propiedades y los beneficios de su aplicación dentro de los Sistemas de Información. En el segundo capítulo se abordan dos taxonomías para la clasificación de las RN, una cercana al lenguaje natural y la otra basada en la implementación; se hace un estudio sobre la yuxtaposición entre ambas y se define un criterio a seguir para la ubicación de las reglas en las diferentes capas de la arquitectura del sistema. Cada caso se ejemplifica mediante las reglas identificadas para el caso de estudio. El tercer capítulo describe las herramientas usadas para el diseño y la implementación del sistema de información. Se comentan además aspectos relativos al ambiente y uso del producto de software, obteniéndose un manual de usuario. 5.

(16) Introducción. Al final del documento se incluye un primer anexo con las reglas de negocio encontradas durante la etapa de identificación de requisitos, un segundo anexo que especifica las reglas de negocio que son implementadas en el sistema, la estructura sintáctica de los patrones a los que se ajustan y la gramática para su sintaxis. Finalmente un tercer anexo esquematiza la unificación de las dos taxonomías de clasificación de las reglas de negocio utilizadas en el desarrollo del trabajo: Clasificación de Weiden y Clasificación de Soliveres.. 6.

(17) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. CAPITULO 1: “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema” 1.1.. Antecedentes. En el año 1984 Daniel Appelton escribe el artículo “Reglas de negocio: el enlace perdido” (Appelton, 1984), donde se considera, se hace la primera aparición de la frase regla de negocio en el contexto de los Sistemas de Información. Appelton discutió problemas que eran causados por la falta de estandarización de términos de negocios. Su punto de vista consiste en que los analistas del negocio no pueden proporcionar soluciones comunes si los usuarios usaban términos que variaban en significado de un departamento a otro dentro de una misma organización. Luego de la aparición de este trabajo (Appelton, 1984) , tanto profesionales de la computación, como de los SI comienzan a manejar la idea de que si las RN podían ser captadas en máquinas de procesamiento (como lo son las reglas en los sistemas expertos), entonces dichas máquinas podrían hacer cumplir estas reglas y asegurar que los procesos de negocio fuesen controlados y conducidos de acuerdo a los estándares del mismo, sus políticas y procedimientos (Struck, 1999a). Este fue solo el comienzo. Las reglas de negocio siempre han sido controladas por el negocio, pero en las últimas décadas la responsabilidad de administración y control de su cumplimiento ha sido delegada, generalmente, a los desarrolladores de software, los que las han incorporado dentro de los diseños de los sistemas de cómputo.. 1.2.. Reglas de Negocio. Toda aplicación trata de reflejar parte del funcionamiento del mundo real, para automatizar tareas que de otro modo serían llevadas a cabo de forma menos eficiente, o bien no podrían realizarse. Para ello se deben reflejar las restricciones existentes en el negocio, de modo que nunca sea posible llevar a cabo acciones no válidas. A las reglas que debe seguir la aplicación para satisfacer los requerimientos que se obtienen desde los objetivos de negocio de una empresa se les llaman reglas de negocio (business rules).. 7.

(18) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. Las reglas de negocio (RN) son sentencias que restringen o definen algunos aspectos del negocio, asegurando la estructura del negocio, controlando o influyendo en el comportamiento del mismo (Bajec, 2006, Hay et al., 1997); considerándose sentencias que usuarios expertos utilizan para especificar políticas, condiciones y conocimiento en pequeñas y aisladas unidades, dichas sentencias reflejan la forma en que la empresa realiza el negocio y conforman un conjunto que es propio del negocio. Morgan en (Morgan, 2002) plantea que una RN puede considerarse 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. También son vistas como restricciones que definen las condiciones sobre las cuales un proceso es llevado a cabo o las nuevas condiciones que deben existir después que un proceso culmine, conformando así una colección de políticas y restricciones de negocio en una organización.. 1.2.1. Características y propiedades El Manifiesto de Reglas de Negocio (The Business Rules Group, 2003) establece algunos aspectos importantes de las reglas de negocio a tener en cuenta desde el punto de vista de los usuarios: Las reglas de negocio deben expresarse separadamente de los procesos de negocio. Las reglas de negocio deben expresarse en forma declarativa y no buscar formalismos procedurales. Las reglas de negocio deben expresarse en formalismos que sean fácilmente comprensibles por la “gente del negocio”, comprensibles sin conocimientos de programación o de lenguajes de programación. Las RN tienen un carácter explícito y pueden ser y son, expresadas de manera entendible, registradas, localizables y modificables. Se entiende que las RN son aquellas que cumplen las siguientes propiedades (Bajec and Marjan, 2001): Atómicas: no pueden ser descompuestas sin que pierdan información. 8.

(19) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. No ambiguas: tienen solamente una obvia interpretación Compactas: típicamente son sentencias cortas Existen diferentes tipos de RN, entre las formas más simples se encuentran las tradicionales validaciones que son las reglas que restringen valores válidos para los datos que se captan, tal es el caso, por ejemplo, del sexo de un paciente que solo puede ser femenino o masculino; no obstante no es este el tipo de regla de principal interés en el enfoque de reglas de negocio (aunque se tienen en cuenta), sino aquellas que constituyen normas, regulaciones, lineamientos, etc., que son representativas del negocio y sensibles a ser modificadas (Kafle, 2009).. 1.2.2. Formulación de las reglas de negocio El proceso de identificación de las reglas de negocio es iterativo y heurístico. En él, inicialmente, las reglas son solo afirmaciones de política generales. Aún cuando la política fuera formal y específica, comúnmente se describe de manera general e informal, y los expertos son los encargados de traducirlas en sentencias específicas y significativas de qué hacer. Estas sentencias, que son más específicas, aún se consideran divagaciones del negocio, sin disciplina, sentencias que algunas veces son claras y otras ambiguas, y mayormente contienen más de una idea (Halle, 1994). En realidad, estas sentencias pocas veces se originan en una política; por lo general, surgen de las operaciones diarias de la organización (BRG, 2000). Estas sentencias son llamadas divagaciones del negocio y suelen ser, generalmente, el punto de partida de los analistas para derivar sentencias de reglas de negocio más formales.. 9.

(20) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. Modelo de Hechos. Texto de Reglas. Estructura de Regla. Figura 1. 1: Definición de Reglas de Negocio (Morgan, 2002).. Inicialmente, la tarea del analista es descomponer estas divagaciones compuestas hacia reglas de negocio atómicas, que son sentencias específicas y formales de un solo término, hecho, derivación o restricción en el negocio. Entre otras cosas, el analista debe evaluar la estabilidad de la regla como aspecto fundamental del negocio (BRG, 2000). Los aspectos fundamentales pueden ser vistos en la infraestructura de la compañía, mientras que las reglas de negocio más transitorias comúnmente se manifiestan en la práctica del trabajo, como se puede ver en la Figura 1. 1.. Seguidamente, la tarea del diseñador es identificar las sentencias atómicas como la definición de un término, hecho, restricción o derivación. Los términos, hechos y algunas restricciones pueden ser representados directamente en modelos gráficos. Las restricciones restantes y las derivaciones deben ser traducidas en algún formalismo. Esto puede ser tan simple como oraciones en lenguaje natural, o puede ser una expresión más formal, como una especificación en lenguaje lógico o una notación gráfica como la propuesta por Ronald Ross (Ross, 1997b). Independientemente de la forma, el diseñador finalmente identificará la tecnología apropiada e implementará las reglas de negocio en el SI como desarrollador del sistema. 10.

(21) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. 1.3.. Sistemas de Información con enfoque de Reglas de Negocio. En los ambientes de negocio 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 RN como un instrumento para desarrollar aplicaciones flexibles y Sistemas de Bases de Datos modificables con facilidad, de modo que los procesos puedan mantenerse prácticamente sin cambios (excepto los derivados de las mejoras introducidas en su diseño), porque la mayor parte de los cambios se derivan de las variaciones del entorno empresarial (mercado, políticas, estrategia, etc.), que es justamente lo que queda definido en las Reglas de Negocio. 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 por computadoras profesionales tienen la idea de que las RN 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, 1999b, Goedertier and Vanthienen, 2006a). Los beneficios más importantes del uso de tales investigaciones para el desarrollo de aplicaciones se obtienen cuando las aplicaciones necesitan ser cambiadas y actualizadas. En estos casos toda la información es almacenada en un único lugar, el repositorio de reglas, pudiendo hacerse modificaciones fácilmente y los componentes pueden ser automáticamente regenerados. Las RN 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 consientes 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. 11.

(22) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. 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.4.. Clasificación de Reglas de Negocio. Debido a su diversidad y complejidad los autores tienden a agrupar las RN y clasificarlas para lograr su mejor procesamiento siguiendo diferentes criterios y puntos de vista. Entre estas se cuenta con las clasificaciones propuestas por Soliveres (Soliveres, 1997), Lowenthal (LOWENTHAL, 2005), Morgan (Morgan, 2002) y Weiden (Weiden et al., 2002), entre otros autores (Martínez del Busto et al., 2007). Tomando en cuenta esto, resulta necesario el análisis de diferentes criterios de clasificación de reglas para viabilizar las etapas de descubrimiento, análisis, modelación e implementación. En los siguientes epígrafes se abordan dos taxonomías de acuerdo a diferentes criterios, utilizadas en el desarrollo de este trabajo.. 1.4.1. Clasificación semántica Es posible clasificar las RN de acuerdo a su semántica según (Goedertier and Vanthienen, 2006b, Weiden et al., 2002) como: restricciones y deducciones o derivaciones, que son aquellas que definen la semántica de las fuentes de datos; y reacciones o procesos que definen la semántica de las fuentes de los procesos. Este esquema de clasificación, extendido por Ross (Ross, 1997a), describe algunos tipos de aseveraciones de acción como: verificación de instancias, verificación de tipos y calculadores. El esquema propuesto (Weiden et al., 2002) puede ser usado para clasificar las RN de acuerdo a sus propiedades semánticas, definiéndose tipos de RN. Estos tipos son agrupados en tres categorías (Weiden, 2000): estructurales, de comportamiento y de administración. Estas categorías representan diferentes visiones del negocio:. 12.

(23) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. Las reglas estructurales son las concernientes a la descripción de aspectos estáticos de un negocio. Las reglas de comportamiento definen las condiciones sobre la ejecución de tareas en el negocio. La categoría de reglas de administración definen las restricciones de alto nivel sobre el negocio. Para todos los tipos de reglas se establecen preguntas típicas, indicando su naturaleza. Estas preguntas pueden ser usadas como punto de partida en la clasificación de un conjunto de reglas. La distinción entre los puntos de vista Estructural y de Comportamiento es bien conocida y sirve como base a muchos métodos de análisis de sistema incluyendo UML. Además, estos dos puntos de vista definen la vista interna del proceso del negocio. El punto de vista Administrativo agrega una vista externa, introduciendo nociones tales como objetivo, valor y recursos necesarios de tareas, actores y procesos del negocio (Weiden, 2000). Este esquema asume que un modelo de procesos inicial del negocio ha sido creado en términos de los procesos y tareas principales. A continuación se describen los patrones de clasificación dados por Morgan y se especifica la estructura lexicológica que se propone para cada caso: Estructura: Describen los aspectos estáticos de un negocio. Estructura de conceptos: Describen los tipos de conceptos y relaciones entre ellos en el dominio. Se utilizan normalmente para describir el vocabulario de términos para la empresa. PATRON 1. ::= <Determinante> <Sujeto> [<negación>] <Opción_Modo> <Característica>. <Sujeto>. ::= <Término_Negocio> | <Hecho>. <Característica>. ::= <Rol_infinitivo> [<Preposición>] [<Determinante>]. ((<Término_Negocio> ((o|y) <Término_Negocio> )* ) | <Hecho>) Persistencia: Determinar el tiempo en que cierta información debería estar disponible en la organización. 13.

(24) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. PATRON 2. ::= <Determinante> <Sujeto> <Opción_Modo> <Característica>. <Sujeto>. ::= <Hecho>. <Característica>. ::= ser (válido | válida) (por <Periodo> | <Intervalo de tiempo>). PATRON 3. ::= <Determinante> <Sujeto> <Opción_Modo> <Característica>. <Sujeto>. ::= <Hecho>. <Característica>. ::= ser (desechada | desechado) después (de | del) (<Periodo> | <Proceso>). Historia: Tiene como objetivo llevar un registro de la historia de un objeto en el dominio. PATRON 4. ::= <Determinante> cambio en <Sujeto> <Opción_Modo> <Característica>. <Sujeto>. ::= <Hecho>. <Característica>. ::= ser almacenado durante el proceso de <Proceso>. Fórmula: Definen formas de cálculo de los objetos del dominio. PATRON 5. ::= <Determinante> <Sujeto> <Característica>. <Sujeto>. ::= <Hecho_Atributo>. <Característica>. ::= es (calculado | calculada) mediante <Expresión>. Conducta: Se refiere a la ejecución de las tareas en la empresa. Gobiernan el comportamiento de los actores en el negocio. Flujo de información: Describen situaciones en las que una tarea tiene necesidades de información de otras tareas para poder ejecutarse.. 14.

(25) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. PATRON 6. ::= <Determinante> <Sujeto> <Característica>. <Sujeto>. ::= <Tarea X>. <Característica>. ::= necesita (de | del) <Información> para ser (desarrollada | desarrollado). {Considerando que Tarea X debe ser diferente de Tarea Y} Pre-Condición: Condiciones que deben cumplirse antes de que una tarea se lleve a cabo. PATRON 7. ::= <Determinante> <Sujeto> [solo] debe realizarse cuando <Determinante> <Característica>. <Sujeto>. ::= <Tarea> | <Proceso> | <Hecho>. <Característica>. ::= <Condición> (y < Condición >)*. Post-Condición: Condición que debe cumplirse después de la ejecución de la tarea. PATRON 8. ::= Después de [<Determinante>] <Sujeto> <Opción_Modo> <Característica>. <Sujeto>. ::= <Tarea> | <Hecho>. <Característica>. ::= <Rol_Infinitivo> <Determinante> <Condición>. Frecuencia: Define la frecuencia con que se ejecuta una tarea. PATRON 9. ::= La frecuencia con que se realiza <Determinante> <Sujeto> <Opcion_Modo> ser <Característica>. <Sujeto>. ::= <Tarea>. <Característica>. ::= <T_Frecuencia>. Duración: Define dentro de que periodo de tiempo debe hacerse una tarea.. 15.

(26) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. PATRON 10 ::= <Determinante> <Sujeto> <Opción_Modo> ser <Característica> <Sujeto>. ::= <Tarea>. <Característica>. ::= (realizada | realizado) en un intervalo <intervalo de tiempo>. Flujo de Control: Definen el control de la ejecución de tareas. PATRON 11 ::= <Determinante> <Sujeto> <Opción_Modo> ser <Característica> <Sujeto>. ::= <Tarea X>. <Característica>. ::= (desarrollada | desarrollado) solo cuando <Determinante> <Tarea Y> (sea (ejecutada | ejecutado) | se haya realizado). {Considerando que Tarea X debe ser diferente de Tarea Y} Conocimiento de la Tarea: Definen el conocimiento necesario para realizar correctamente una tarea. PATRON 12 ::= Para <Determinante> <Sujeto> se <Opción_Modo> <Característica> <Sujeto>. ::=<Tarea>. <Característica>. ::= <Rol_Infinitivo> <Conocimiento>. Administrativas: Utilizadas para garantizar un rendimiento correcto. Define la forma en que la organización debe comportarse. Organización: Describen las políticas de una organización.. 16.

(27) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. PATRON 13 ::= <Determinante> <Sujeto> <Opción_Modo> <Característica> <Sujeto>. ::= <Hecho>. <Característica>. ::= <Rol_Infinitivo> [<Determinante>] <T_Negocio> (<T_Creativo> | <Comparación>). Objetivo y Valor: Describen los objetivos dirigidos a una determinada tarea o asociado a un valor. PATRON 14 ::= <Determinante> <Sujeto> tiene como objetivo <Característica> <Sujeto>. ::= <Proceso> | <Tarea>. <Característica>. ::= <Objetivo>. Actitud del Actor: Las habilidades que necesita un actor con el fin de realizar una tarea determinada correctamente. PATRON 15 ::= <Determinante> <Sujeto> que (desarrolla | realiza) <Característica> <Sujeto> ::=<Actor> <Característica> ::= <Determinante> <T_Negocio> <Opción_Modo> <Rol_Infinitivo> (<Habilidad> | Conocimiento>) Responsabilidad del Actor: Definen los tipo de tareas que pueden ser realizadas por un determinado tipo de actor. PATRON 16 ::= <Determinante> <Sujeto> <Opción_Modo> ser responsable de <Característica> <Sujeto>. ::= <Actor>. <Característica>. ::= <Tarea> 17.

(28) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. Recursos: Definen las limitaciones sobre la cantidad y tipo de recurso que se utiliza en el negocio. PATRON 17 ::= Se debe utilizar [<Cuantificador>] <Determinante> <Sujeto> <Característica> <Sujeto> ::= <Recurso> <Característica> ::= <Condición> ( y <Condición>)* Esta taxonomía de clasificación es muy cercana al lenguaje natural, por eso es usada para la identificación y modelación de las Reglas de Negocio en el DSI.. 1.4.2. Clasificación cercana a la implementación La siguiente clasificación se corresponde con la reportada en la Revista Profesional para Programadores (RPP) por Soliveres (Soliveres, 1997). Esta taxonomía de clasificación es representada por cinco categorías que describen las políticas de un negocio y es considerada cercana a la forma de implementación de las Reglas de Negocio en el DSI. A continuación se describe el esquema de clasificación propuesto por Soliveres: Reglas del modelo de datos: Engloba todas aquellas reglas que se encargan de controlar que la información básica almacenada para cada atributo o propiedad de una entidad u objeto es válida. Ejemplo: R1:. El sexo de una persona solo puede ser masculino o femenino.. R2:. La fecha siempre debe ser válida (no existe el 30 de Febrero).. R3:. El salario de un paciente no debe ser negativo.. Reglas de relación: Incluye todas aquellas reglas que controlan las relaciones entre los datos. Por ejemplo: R4:. Un posible receptor debe ser asociado al menos a un donante potencial.. Reglas de derivación: Controlan la obtención de información que se puede calcular a partir de la ya existente. Ejemplo: 18.

(29) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. R5:. La Hidratación del Receptor en Sala de Trasplante es calculada mediante Peso del. Receptor en Kg * (30 o 35 cc). Reglas de restricción: Restringen los datos que el sistema puede contener. Nótese que este grupo de reglas se solapa, en cierto modo, con las reglas del modelo de datos, dado que aquellas también impiden la introducción de datos erróneos, como se vio anteriormente. La diferencia estriba en que las reglas de restricción restringen el valor de los atributos o propiedades de una entidad más allá de las restricciones básicas que sobre las mismas existen. Por ejemplo: R6:. El IMC de un paciente obeso debe ser mayor o igual a 36.. La diferencia fundamental estriba en el hecho de que este tipo de reglas requiere para su verificación del acceso a otros fragmentos de información, algo que no sucede con las reglas del modelo de datos. Reglas de flujo: determinan y limitan cómo fluye la información a través de un sistema, indican qué camino recorre la información y obligan a que se sigan solo los caminos válidos. Por ejemplo: R7:. El tratamiento de padecimientos debe ser desarrollado solo cuando el ingreso del. paciente al protocolo de TR se haya realizado. La clasificación de Reglas de Negocios cercana a la forma de implementación sirve para determinar la ubicación en el DSI en la fase de implementación de la regla.. 1.4.3. Convergencia de la clasificación semántica y la cercana a la implementación Partiendo de que las RN son elaboradas por expertos o analistas del negocio y son implementadas por desarrolladores del sistema, se abordaron dos taxonomías para la clasificación de las RN. La taxonomía que se corresponde con la clasificación semántica se usa a la hora de captar las reglas de negocio, debido a la sencillez y claridad que brinda esta forma de representación para la identificación y clasificación. Esta taxonomía estructurada facilita la modelación y hace que 19.

(30) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. las reglas sean más entendibles por los expertos del negocio, aunque no tengan conocimientos computacionales, por otra parte, la clasificación cercana a la implementación ayuda a que el desarrollador determine la ubicación indicada para cada regla de negocio dentro de la arquitectura, dado que la descripción de cada subtipo brinda una idea cercana al código y al lugar dentro de la arquitectura del sistema donde se implementarán. Puede parecer que esta última taxonomía es suficiente, pero tiene el inconveniente de resultar muy compleja para lograr el control sobre la estructura y consistencia, entre otras propiedades deseables en un conjunto de RN, que en la taxonomía de clasificación propuesta por Weiden si se tiene en cuenta, por este motivo, se usan ambas clasificaciones en la solución del problema. Se hace necesario hacer una unificación entre ambas taxonomías para utilizar las facilidades que nos brindan ambas clasificaciones. Para esto se hacen coincidir los subtipos de la clasificación semántica con la forma en que son implementadas en el SI, véase la Figura 1. 2.. Analista o usuario experto. Desarrollador del sistema. UNIFICACION Clasificación cercana al lenguaje natural. Clasificación cercana a la implementación. Figura 1. 2: Esquema de convergencia de las clasificaciones.. Con el objetivo de realizar una unificación entre la clasificación propuesta por Weiden (Weiden et al., 2002) y Soliveres (Soliveres, 1997) se tiene que: Reglas del modelo de datos: Estructura de conceptos: En este caso se trata del subconjunto de las reglas que debe cumplir el sistema, relacionadas con las tradicionales validaciones que restringen los valores para los datos que se captan y pueden enmarcarse dentro de esta categoría, porque describen los tipos 20.

(31) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. de conceptos y controlan que la información básica almacenada para los atributos de cada concepto sea válida. Un ejemplo de este tipo de regla puede ser: R8:. El número de carné de identidad de una persona (CI) debe cumplir con ciertas. condiciones básicas, como que es de tipo entero con una longitud máxima de 11dígitos. Este tipo de regla responde a las características de ambas clasificaciones, por eso podemos decir que unifican amabas clasificaciones. Para considerarla dentro de la base de datos, cuando agregamos el atributo CI a la tabla, decimos que es de tipo int (11). Reglas de relación: Estructura de conceptos: Se ubican aquí las reglas de negocio del subtipo estructura de conceptos que describen las relaciones entre los conceptos y el dominio. Un ejemplo de este tipo de regla puede ser: R4:. Un posible receptor puede ser asociado al menos a un donante potencial.. Esta regla y otras reglas que aparecen en el Anexo 1 dentro del subtipo Estructura de Conceptos responden a ambas clasificaciones, por eso se considera que unifican. Para implementar este tipo de reglas lo hacemos desde el modelo de la base de datos, teniendo en cuenta la multiplicidad en las relaciones de las entidades. Este es el caso también de las reglas que pertenecen a los subtipos: Objetivo y valor Actitud del actor Responsabilidad del actor que existen en el negocio aunque no son implementadas en nuestro sistema. Reglas de derivación: Fórmula: 21.

(32) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. Se ubican aquí las reglas del subtipo fórmula porque definen formas de cálculos de los objetos del dominio, que utilizan información existente en la base de datos. Un ejemplo de este tipo de regla puede ser: R5:. La hidratación del receptor en sala de trasplante es calculada mediante el peso del. receptor en Kg * (30 o 35 cc). Este tipo de regla se puede enmarcar en ambas clasificaciones, por eso se considera que unifican, para implementarla se puede usar lenguaje PHP y consultas a la base de datos para obtener los valores que se necesitan. Reglas de restricción: Persistencia: Se ubican aquí las reglas del subtipo persistencia porque ellas determinan el tiempo que cierta información debería estar disponible en la organización. Estas reglas constituyen restricciones y por eso se considera que unifican estos subtipos de la clasificación de Weiden y Soliveres, respectivamente. Un ejemplo de este tipo de regla puede ser: R9:. El estado de los pacientes en la unidad de cuidados intensivos debe ser válido por. 48 horas. R10: El resultado de los análisis de los pacientes debe ser desechado después del Trasplante Renal. Este tipo de regla aunque constituyen una restricción en la política del negocio se deja al personal de salud encargado de garantizarla porque en cada institución se hacen valoraciones distintas respecto a la persistencia de la información de los pacientes, por tanto no queda implementada en el sistema. Frecuencia:. 22.

(33) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. Se ubican aquí las reglas del subtipo frecuencia porque definen la frecuencia con que se ejecuta una tarea y con esto establecen una restricción, por eso se considera que unifican ambos subtipos de clasificación. Un ejemplo de este tipo de regla puede ser: R11: La frecuencia con que se realiza EPO-rHU debe ser 3 veces por semana. Este tipo de regla puede implementarse haciendo uso de código PHP y consultas a la base de datos para que una vez por semana se emita un reporte con los pacientes que no tienen realizado el EPO-rHU en tres ocasiones. Duración: Se ubican aquí las reglas del subtipo duración porque estas definen dentro de qué período de tiempo debe hacerse una tarea y como esto constituye una restricción, se considera que unifican ambos subtipos de clasificación de reglas de negocio. Un ejemplo de este tipo de regla puede ser: R12: La operación de Trasplante debe ser realizada en un intervalo de 2 a 4 horas. Este tipo de regla puede ser implementar teniendo en cuenta los valores de los atributos InicioActoQuirurgico y FinActoQuirurgico que aparecen en la tabla Trasplante. Para esto se puede tener una función PHP que consulte a la base de datos para obtener los valores de estos campos y devuelva la duración exacta. Organización: Se ubican aquí las reglas del subtipo organización porque estas definen la política de una organización considerando las restricciones que existen sobre el negocio. Un ejemplo de este tipo de regla puede ser: R13: Un posible receptor de un trasplante renal con donante vivo debe tener una edad mayor o igual a 15 años y menor de 55 años. Este tipo de regla se puede enmarcar en ambos subtipos de clasificación, por eso se considera que unifican y para implementar este caso se puede mostrar un mensaje indicando que ese 23.

(34) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. receptor tiene una edad no válida para recibir órgano de un donante vivo si en trasplante renal se asocia un posible receptor con un donante vivo y la edad del receptor no se corresponde con las normas. Este tipo de regla se puede implementar usando lenguaje PHP y consultas a la base de datos. Recursos: Se ubican aquí las reglas del subtipo recursos porque estas definen las limitaciones o restricciones que se establecen sobre la cantidad y tipo de recurso que se utiliza en el negocio, por eso ambas clasificaciones unifican. Un ejemplo de este tipo de regla puede ser: R14: Se debe utilizar el Riñón Contralateral del Donador Vivo cuando existe un Riñón con Doble Arteria y la Función Renal no tiene Diferencia Significativa. Este tipo de regla aunque existe en el sistema se deja a los médicos encargados de hacerla cumplir cuando tengan que escoger, por ejemplo, el riñón del donante vivo más indicado según las restricciones, y no es implementada en el sistema. Reglas de flujo: Flujo de información: Se ubican aquí las reglas del subtipo flujo de información porque ellas describen situaciones en las que una tarea tiene necesidad de información de otras tareas para poder ejecutarse y eso consiste en indicar el camino que recorre la información y obligarla a seguir el camino válido. Un ejemplo de este tipo de regla puede ser: R15: La inserción en la lista de espera necesita de la clasificación de los pacientes urgentes según su tipo para ser desarrollada. Este tipo de regla puede incluirse en ambos subtipos, por esto ambas clasificaciones unifican. En este caso la regla se puede implementar usando código PHP para mostrar un mensaje que indique que no se puede permitir que se inserte un posible receptor en la lista de espera si no tiene un valor en el campo de clasificación. 24.

(35) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. Pre-Condición: Se ubican aquí las reglas del subtipo pre-condición porque son condiciones que deben cumplirse antes de que una tarea se lleve a cabo y limitan cómo fluye la información a través de un sistema, por esto ambas clasificaciones unifican. Un ejemplo de este tipo de regla puede ser: R16: Un Trasplante Renal solo debe realizarse cuando el VIH del paciente fue negativo. Esta regla puede garantizarse cuando mostramos un alerta antes de que se incluya un paciente que tiene entre sus padecimientos el VIH en la lista de trasplantes. Esto se verifica fácilmente mediante consultas a la base de datos y código PHP. Post-Condición: Se ubican aquí las reglas del subtipo post-condición porque son condiciones que deben cumplirse después de la ejecución de la tarea y limitan cómo fluye la información en el sistema, por esto ambas clasificaciones unifican. Un ejemplo de este tipo de regla puede ser: R17: Después de la evaluación completa del paciente candidato, debe ser realizada la inserción de un paciente en la lista de trasplantes. Flujo de Control: Se ubican aquí las reglas del subtipo flujo de control porque definen el control de la ejecución de tareas. Un ejemplo de este tipo de regla puede ser: R18: La operación de trasplante puede ser desarrollada solo cuando la realización protocolo de compatibilidad sea ejecutada. Este tipo de regla puede clasificarse en ambos subtipos, por eso se considera que unifican. Para garantizarla se puede mostrar un mensaje antes de que se incluya un paciente en la lista de 25.

(36) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. trasplante cuando falta alguno de los resultados de los análisis que comprenden el protocolo de compatibilidad. Esto se verifica fácilmente a través de consultas a la base de datos y código PHP. Conocimiento de la Tarea: Se ubican aquí las reglas del subtipo conocimiento de la tarea porque definen el conocimiento necesario para realizar correctamente una tarea, haciendo que el camino que recorre la información sea válido y que unifiquen ambas clasificaciones. Un ejemplo de este tipo de regla puede ser: R19: Para la ejecución del trasplante renal a embarazadas se debe tener su voluntad expresada por escrito. Esta tipo de regla se le deja al personal médico encargado de controlarla y no queda implementada en el sistema. Historia: Se ubican aquí las reglas del subtipo historia porque tienen como objetivo llevar un registro de la historia de un objeto en el dominio y con esto indican el camino que recorre la información. Un ejemplo puede ser: R20: Todo cambio en exámenes realizados a un paciente debe ser almacenado durante el proceso de Trasplante Renal. Este tipo de regla puede clasificarse en ambos subtipos de clasificación, y por eso se considera que unifican, para implementarla se puede mostrar un alerta preguntando si se desean guardar los cambios hechos en los valores de los campos asociados a los exámenes de un paciente cuando sale de la ventana activa. Para esto utilizamos código en lenguaje PHP y consultas a la base de datos. Este tipo de regla es fundamental en un sistema como el que se pretende, que almacena toda la información necesaria para el control de los pacientes del área de Nefrología.. 1.5.. Consideraciones para la implementación de reglas de negocio. Las RN pueden ser aplicadas a diferentes capas de la arquitectura: las GUI, WebServer, Aplicaciones, una Capa Intermedia y a las Bases de Datos. Las reglas pueden ser representas por 26.

(37) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. diferentes mecanismos de implementación, simples validaciones en las GUI, complejos chequeos en la capa de aplicación, procedimientos almacenados, y triggers en las bases de datos (Castillo et al., 2009), esta variedad hace necesario hacer la elección de la forma idónea de implementación. En los siguientes epígrafes se abordan algunas de las diferentes formas de implementación y se analizan las características de los gestores de bases de datos y de las arquitecturas para la implementación.. 1.5.1. Gestores de bases de datos y la implementación de reglas de negocio Los Sistemas de Gestión de Bases de Datos (SGBD) son sistemas computacionales que brindan un conjunto de servicios a programadores, administradores de bases de datos y usuarios finales, entre los que se destacan la definición y el control centralizado de los datos, así como el control de la concurrencia y los utilitarios para la manipulación de los datos y el desarrollo de las aplicaciones. Los gestores de base de datos relacionales proporcionan soporte para implementar en ellos reglas de negocio, mediante el uso de claves primarias, integridad referencial, triggers, etc., mientras que sistemas como DBase y otros apenas proporcionan soporte para reglas de negocio. Suponiendo que se tiene la información en un gestor de bases de datos potente, no es necesario preocuparse de llevar a cabo la codificación de numerosas validaciones en nuestras aplicaciones: así, si en la base de datos se crea una regla de integridad referencial que indica que todo pedido pertenece a un cliente, el gestor de base de datos rechazará cualquier intento de almacenar un pedido en el que se nos haya olvidado indicar el mismo. Cualquier aplicación que acceda a esta base de datos se beneficiará de esta y otras validaciones automáticamente, sin tener que añadir nuevas líneas de código. Cuando se utiliza una base de datos menos potente, como DBase, no se está de suerte. Casi todas las reglas de negocio deberán implementarse dentro de los programas que accedan a la base de datos. Si los programas que acceden a la base de datos son varios, garantizar que en todos ellos respeten todas las reglas puede llegar a ser muy difícil y engorroso, especialmente si se desarrollan con distintas herramientas. 27.

(38) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. La necesidad de implementar reglas de negocio dentro de las aplicaciones cliente puede surgir también cuando se utilizan gestores de bases de datos más potentes. En primer lugar, las bases de datos relacionales son cada vez más potentes, pero no todas las reglas de negocio pueden reflejarse en ellas: por ejemplo, las reglas de flujo son bastante difíciles de implementar dentro de la base de datos, y suelen ser las aplicaciones cliente las que controlan que la información siga una ruta válida a través del sistema. Sin embargo, muchas de las reglas de negocio pueden reflejarse adecuadamente a nivel de la base de datos con estos gestores. El problema se agrava si la información del negocio se encuentra en distintas bases de datos, gestionadas por distintos gestores, dígase DB2 y Oracle: si, por ejemplo, en DB2 se almacena la información sobre facturas, etc., y en la base de datos Oracle se almacena información técnica, como reparaciones llevadas a cabo en la maquinaria, ¿cómo se refleja que ciertas facturas corresponden a una reparación, y se garantiza que no se puede relacionar una reparación con una factura inexistente? Evidentemente, aquí no hay manera de establecer una regla de integridad referencial entre tablas almacenadas en dos bases de datos distintas y correspondientes a distintos gestores de base de datos. De nuevo, la solución al problema es implementar el chequeo en cada aplicación cliente, comprobando que exista la factura en la tabla DB2 antes de referenciarla en la tabla de reparaciones Oracle.. 1.5.2. Arquitectura de sistemas y la implementación de reglas de negocio Arquitectura de dos capas: La arquitectura cliente/servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico, como a nivel lógico. Consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora, es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.. 28.

(39) Capítulo 1 “Enfoque de Reglas de Negocio en los Sistemas de Información y la arquitectura del sistema”. La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina, ni es necesariamente un solo programa. Los tipos específicos de servidores incluyen los servidores Web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma. La arquitectura cliente/servidor tradicional es una solución de dos capas. La arquitectura de dos capas consta de tres componentes distribuidos en dos capas: cliente (solicitante de servicios) y servidor (proveedor de servicios), se puede observar en la Figura 1. 3.. Capa Cliente. Capa de servidor. Aplicaciones Cliente. Datos del negocio. Figura 1. 3 : Esquema de arquitectura Cliente/Servidor clásica.. Estas aplicaciones de 2 capas trabajan bien en aplicaciones a escala de departamentos con un modesto número de usuarios, una base de datos sencilla y una red segura y rápida. La principal ventaja que presenta este tipo de aplicaciones es que los datos están centralizados. Esta centralización beneficia a la empresa pues es más fácil compartir los datos, se simplifica la generación de reportes y se proporciona consistencia en el acceso a los datos. A continuación se enumeran las principales desventajas que presentan este tipo de aplicaciones: Difíciles de mantener: Esto viene dado por el hecho de que son difíciles de mantener las reglas de negocio de la lógica de aplicación ya que estas están programadas en cada cliente y esto implica que cualquier cambio tiene que ser redistribuido en todos los clientes. Se compromete la confidencialidad: Al tener programada la lógica de aplicación en el cliente este tiene a su disposición todas las reglas de negocio de la empresa.. 29.