Sistema de alertas para la Empresa GEOCUBA Villa Clara

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas. Facultad Matemática, Física y Computación Licenciatura en Ciencia de la Computación. TÍTULO: SISTEMA DE ALERTAS PARA LA EMPRESA GEOCUBA VILLA CLARA. Autor: Dianelis Portal Castillo Tutores: MSc. Inti Yulien González MSc. Reinerio Benítez. “Año 54 de la Revolución” Santa Clara, 2012.

(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 de Seminario.

(3) Pensamiento. El que ama la instrucción ama la sabiduría Proverbios 12:1.

(4) Dedicatoria. A mis padres que con su presencia y ejemplo supieron conducirme por el camino correcto. A todos en mi familia por su infinito cariño, confianza y apoyo que me han sido imprescindibles en el camino de mi formación profesional..

(5) Agradecimientos. A mis padres por ser los mejores del mundo y ante todo ser los mejores amigos que he podido tener. A mis abuelos. A todas mis tías y tíos por mimarme y ayudarme tanto. A mi hermana. A Inti, por la salvación constante, por el consejo y la ayuda. A Claudia y Marilyn por la ayuda prestada en tantos momentos. A mis amigos. A todos los que de alguna forma pusieron su granito de arena e hicieron posible que este proyecto se hiciera realidad. ¡Muchas Gracias!.

(6) Resumen. RESUMEN Los sistemas de alertas responden a la necesidad de optimizar el procesamiento de la información, constituyen una combinación de programas, procedimientos y datos. En este trabajo se desarrolla un sistema de alertas, que se encarga del envío de las mismas a través de correos electrónicos, basado en la información contenida en diversas bases de datos existentes en diferentes gestores.. El sistema se implementa utilizando Java como lenguaje de. programación y los gestores de bases de datos PostgreSQL y MySQL. Se realiza el análisis, diseño e implementación del sistema de alertas de acuerdo a las necesidades de los usuarios..

(7) Abstract. ABSTRACT The systems of alerts respond to the necessity of optimizing the examination of the information, they constitute a combination of software, procedures and data. In this work a system of alerts is developed, that takes charge to send the alerts through electronic mail, based on the information contained in diverse existent databases in different managers. The system is implemented using Java as programming language and the managers of databases PostgreSQL and MySQL. Analysis, design and implementation of the system are made according to the necessities of the users..

(8) Tabla de contenidos. Tabla de contenidos INTRODUCCIÓN ................................................................................................ 1 1 CONSIDERACIONES GENERALES SOBRE SISTEMAS DE ALERTAS. ..... 5 1.1 Sistema de alertas ........................................................................................................................... 5 1.2 Sistemas de alertas basados en bases de datos ....................................................................... 6 1.3 Diferentes usos de los sistemas de alertas ................................................................................. 6 1.4 Beneficios de los sistemas de alertas .......................................................................................... 8 1.5 Antecedentes y ejemplos de algunos sistemas de alertas utilizados en el mundo. .............. 9 1.6 Antecedentes y ejemplos de sistemas de alertas existentes en Cuba. ............................... 13 1.7 Breve descripción de las tecnologías utilizadas en la conformación del sistema de alerta en cuestión. ........................................................................................................................................... 15 1.7.1 El lenguaje Java ......................................................................................................................... 15 1.7.2 Conectividad a base de datos desde Java ................................................................................. 16 1.7.3 Gestores de bases de datos ......................................................................................................... 16 1.7.3.1 Las principales características de MySQL .................................................................. 17 1.7.3.2 Las principales características de PostgreSQL......................................................... 17 1.7.4 JavaMail .................................................................................................................................... 18 Conclusiones parciales ....................................................................................................................... 19. 2 ESTRUCTURA Y DISEÑO DEL SISTEMA. ................................................. 20 2.1 Características generales que debe tener el software ............................................................ 20 2.2 Modelación del sistema ................................................................................................................ 20 2.2.1 Diagramas y descripción de casos de uso del sistema................................................................ 21 2.2.1.1 Diagrama de casos de uso ............................................................................................ 22 2.2.1.2 Diagrama de clases ....................................................................................................... 23 2.2.1.3 Diagrama de despliegue ................................................................................................ 24 2.2.1.4 Diagrama de actividades del sistema. ................................................................................. 25 2.3 Bases de datos del sistema ......................................................................................................... 27 2.3.1 Descripción de las tablas: ....................................................................................................... 28 2.4 Implementación del software ....................................................................................................... 31 2.4.1 Configuración de los diversos servidores para las conexiones. ................................................. 31 2.4.2 Configuración y modificación de alertas. .................................................................................. 32 2.4.3 Configuración del correo para el envío de las alertas. .............................................................. 33 2.5 Funcionamiento del sistema ........................................................................................................ 37 Conclusiones parciales ....................................................................................................................... 37. 3 MANUAL DE USUARIO ................................................................................ 39 3.1 Requisitos para la explotación ..................................................................................................... 39 3.2 Modo de Trabajo ............................................................................................................................ 40 3.2.1 Agregar servidores al sistema para la conexión a las bases de datos ....................................... 40 3.2.2 Editar y eliminar los servidores existentes en el sistema ........................................................... 41 3.2.3 Configuración del correo para el envío de las alertas. .............................................................. 42 3.2.4 Crear y configurar alertas ........................................................................................................... 43 3.2.5 Modificar y eliminar alertas existentes. ..................................................................................... 46 3.2.6 Cierre de la aplicación ............................................................................................................... 48 Conclusiones parciales ....................................................................................................................... 49. CONCLUSIONES GENERALES....................................................................... 50 RECOMENDACIONES ..................................................................................... 51 BIBLIOGRAFÍA ................................................................................................. 52.

(9) Introducción. INTRODUCCIÓN Uno de los principales paradigma del área informática de cualquier empresa lo constituye. el almacenamiento de grandes volúmenes de datos. La empresa. GEOCUBA, perteneciente al MINFAR, división territorial Villa Clara-Sancti Spíritus, en el municipio de Santa Clara, Villa Clara requiere de un sistema de alertas.. Planteamiento del problema. En la empresa GEOCUBA se tramita un alto volumen de información, y se quiere contar con un sistema informático para el envío de alertas. por correo.. En años recientes se han creado diversas bases de datos en las cuales se almacenan toda la información. que ellos necesitan. Existe la necesidad de. gestionar parte de la información existente en estas bases de datos, por esto es imprescindible la creación de un sistema informático para instalarlo en los sistemas informáticos existentes en la empresa.. En otro tiempo, el análisis de la información de la empresa GEOCUBA se realizaba semanalmente con poca información sobre la operativa diaria de la empresa. El resto de la información de la empresa se encontraba poco documentada por lo que existía poco control de la misma. Como resultado, la dirección de la entidad en muchas ocasiones desconocía las dificultades existentes a tiempo: vencimiento y renovación de contratos, vencimiento y actualización de certificados médicos, control de las licencias por maternidad, y en muchos casos, ya era tarde para rectificar cualquier situación existente con estos.. Lógicamente, apoyados en las nuevas tecnologías, la entidad GEOCUBA desea la creación. de. un sistema de alertas con el propósito de detectar. señales que permitan identificar dificultades y tomar así las decisiones “a tiempo”. Se desea crear un módulo genérico donde se planifiquen todas las 1.

(10) Introducción. alertas para los sistemas informáticos que cumpla con los requisitos de cada persona que trabaje con él.. Objetivo General •. Desarrollar un sistema de alertas, que se encargue del envío de las mismas a través de correos electrónicos, basado en la información existente en diversas bases de datos.. Objetivos específicos •. Diseñar el sistema que permita integrar diferentes gestores de bases de datos.. •. Diseñar e implementar un módulo que permita la creación de alertas.. •. Implementar el envío de correos del sistema.. Preguntas de investigación: ¿En qué momento el sistema debe notificar al usuario respecto al vencimiento de los términos? ¿En qué forma?. ¿Es posible garantizar un alto nivel de seguridad para el sistema? ¿Cómo lograr el mayor nivel de seguridad para el mismo?. Hipótesis Si se diseña e implementa un sistema destinado al control y la gestión de indicadores entonces, se incrementará la eficiencia y fluidez en el proceso y el uso de esta información especializada de la empresa GEOCUBA. Para llevar a cabo los objetivos específicos, se han diseñado un grupo de tareas: . Las entrevistas a directivos y especialistas del centro, para conocer la organización e identificar los principales procesos que se desarrollan para dar solución al trabajo.. 2.

(11) Introducción. . La selección adecuada de las herramientas de programación.. . La elección de las metodologías a seguir y por tanto, la utilización de los lenguajes de programación más efectivos que cumplan con las exigencias planteadas.. . El análisis, diseño y creación de la interfaz gráfica de la aplicación, la cual debe ser lo más amigable posible al usuario y siempre pensando en el cliente final, para facilitar su desempeño con la misma.. Justificación de la investigación La implementación del sistema de gestión de datos para GEOCUBA aportaría valiosa información a los usuarios del sistema. La información generada por el procesamiento. del. sistema. sería. más. fácil. de. estudiar. permitiendo. investigaciones más profunda y análisis más detallados. Por otro lado se logra el control unificado de los datos existentes en la empresa que podría servir de ayuda a los usuarios en la tarea de búsqueda de los conocimientos implícitos en las bases de datos.. Descripción de Capítulos: Capítulo 1: Consideraciones generales sobre sistemas de alertas. Este capítulo recoge aspectos generales sobre los sistemas de alertas, hace una descripción de sus usos y beneficios, además de dar a conocer las características de diferentes casos de sistemas de alertas existentes en la actualidad. Capítulo 2: Estructura y diseño del sistema. En el capítulo dos se exponen las etapas de análisis, diseño e implementación del sistema de alertas en cuestión explicando todo el proceso de modelado del negocio, casos de uso, modelo de la base de datos y diagramas de despliegue. 3.

(12) Introducción. Capítulo 3: Manual de usuario.. En este capítulo se realiza una guía o manual de usuario en la que se detallan los pasos a seguir por los usuarios, para que estos aprendan a utilizar el sistema.. 4.

(13) Capítulo 1: Consideraciones generales sobre sistemas de alertas. 1 CONSIDERACIONES GENERALES SOBRE SISTEMAS DE ALERTAS. Este capítulo recoge aspectos generales sobre los sistemas de alertas, así como lo necesario a considerar para su correcto funcionamiento. Se exploran los diferentes tipos de sistemas de alertas existentes en el mundo y en nuestro país, así como los beneficios que trae su uso. 1.1 Sistema de alertas Una alerta es un aviso oportuno sobre la ocurrencia de un hecho de interés. Entonces definimos sistema de alertas como un sistema de información especializado que permite a sus usuarios obtener de manera oportuna, ágil e inmediata información referente a un evento de su interés. Los sistemas de alertas responden a la necesidad de optimizar el procesamiento de la información, constituyen una combinación de programas, procedimientos, datos y equipamiento utilizados en este proceso, pueden funcionar de manera independiente o semiindependiente del control humano e interactúan y son controlados por una o más computadoras.(G Coutin, 2006) Los sistemas de alertas pueden clasificarse en sistemas en línea (on line), sistemas en tiempo real, sistemas de apoyo a decisiones, sistemas basados en el conocimiento y generalmente son combinaciones de estos. Todos comparten elementos comunes relativos al hardware (procesadores, discos, impresoras, terminales, etc.), al software (sistemas operativos, sistemas de base de datos, programas de control de telecomunicaciones y otros), a las personas (operadores del sistema, proveedores de material de entrada y consumidores de las salidas), a los datos (información que el sistema recuerda durante un período) y a los procedimientos (políticas formales e instrucciones de operación del sistema). Otra característica es que permiten la introducción o la recepción de datos de forma remota ya que los usuarios del sistema normalmente interactúan con la computadora desde terminales que pueden estar localizadas 5.

(14) Capítulo 1: Consideraciones generales sobre sistemas de alertas. a cientos de kilómetros de distancia, además los datos almacenados usualmente se organizan de modo de que los componentes individuales de información puedan ser recuperados o modificados en forma rápida y sin tener que acceder necesariamente a otros componentes de información del sistema. (G Coutin, 2006) 1.2 Sistemas de alertas basados en bases de datos Los sistemas para emisión de alertas a partir del análisis de bases de datos fueron desarrollados desde finales del siglo pasado para la detección e intervención urgente en situaciones de emergencia, para desarrollar las estrategias de investigación y establecer las medidas de control necesarias, proporcionando información oportuna y retroalimentación periódica. Estos sistemas requieren para su funcionamiento de la colaboración de numerosos expertos que utilizan la información recogida en diferentes bases de datos y tras un análisis generan condiciones de alerta, con lo cual contribuyen al perfeccionamiento de la respuesta. (Razetti, 2006) La rapidez en la detección constituye la característica más importante para el funcionamiento de estos sistemas y muchos de ellos funcionan en tiempo real, a la vez que se recibe la información de las diversas fuentes se preparan los mecanismos para un alerta casi inmediata. (Valencia R, 2003 ) 1.3 Diferentes usos de los sistemas de alertas Sistemas de alertas de riesgos de la banca con el propósito de detectar señales que permitan identificar empresas con dificultades y tomar así las decisiones oportunas “a tiempo”. Este tipo de sistema es útil cuando una empresa quiere evitar. la. quiebra. o. la. caída. de. sus. acciones. en. la. bolsa. de. comercio.(Confederación colombiana de Cámaras de Comercio). Para prevenir el uso de productos cosméticos y sanitarios que hallan desencadenado reacciones adversas sobre sus consumidores: la red de alertas. 6.

(15) Capítulo 1: Consideraciones generales sobre sistemas de alertas. transmite información urgente en relación a la calidad y seguridad de los productos sanitarios y cosméticos con el fin de proteger la salud de los pacientes, ciudadanos o usuarios. La información puede ser de alertas y notas informativas dependiendo del riesgo que suponga el producto implicado. (Dirección General de Atención Primaria de la Consejería de Sanidad). Como método de detección de errores de medicación: los errores de medicación son los tipos más frecuentes de errores y de los que se dispone de más información, especialmente de aquellos que suceden en el ámbito hospitalario. En el ámbito hospitalario se utilizan distintos métodos para detectar los errores de medicación, ninguno ellos (intervenciones farmacéuticas en la validación, notificación voluntaria en la dispensación, observación en la administración, etc.) es capaz de detectar todos los incidentes posibles dada la complejidad del sistema de utilización de medicamentos. (M.D Santos-Rubio, 2011) Los sistemas de alertas también son utilizados para el monitoreo a distancia de pacientes con marcapasos (MP), desfibriladores automáticos (DA), los sistemas de resincronización cardíaca (SRC), grabadoras de asa cerrada y productos de monitoreo hemodinámico, Una vez que se han capturado los datos desde el dispositivo implantado, éstos se cargan a través del transmisor que tiene una línea telefónica analógica estándar o a través de teléfonos celulares de forma inalámbrica, a una central segura donde se procesan los datos. Las alertas de sucesos son avisados al paciente a través de una señal acústica o vibraciones. En algunos sistemas estas alertas se utilizan para instruir al paciente e iniciar una transferencia manual de datos desde el transmisor a una base central de datos. Dependiendo del estado clínico del paciente y la urgencia los datos procesados pueden desencadenar una alerta rápida para el médico a través de un e–mail, mensajes de texto, fax o una llamada telefónica, mientras que el informe de los detalles se publicaran simultáneamente en un sitio Web seguro, para ser visualizado por el médico tratante u otro revisor médico autorizado.(H Burn 2009) 7.

(16) Capítulo 1: Consideraciones generales sobre sistemas de alertas. Para minimizar el daño ocasionado por sismos y tsunamis: generan un espacio de información que pueda inducir a la generación de una estrategia para le prevención y reducción de riesgos. Una alerta clara, recibida a tiempo, unida al conocimiento de qué esperar y cómo reaccionar en cada caso, puede significar para las personas y sus comunidades la diferencia entre la vida y la muerte.(Área de Desarrollo e Innovación Tecnológica). Sistema de alerta por movimientos en masa inducidos por lluvia para el valle de Aburrá, Colombia: en el valle de Aburrá las complejas condiciones físicas del territorio, sumadas a los altos índices de vulnerabilidad, han propiciado escenarios con un alto potencial de pérdidas humanas y económicas ante la ocurrencia de fenómenos de origen natural tales como movimientos en masa, los cuales representan el 35 % de los eventos que ocurren en el valle y el 77 % de las víctimas mortales. Debido a esta grave problemática, desde el año 2008 se ha venido utilizando un sistema de alerta por movimientos en masa inducidos por lluvia soportado en umbrales de lluvia empíricos. Este sistema proporciona un rápido medio para monitorear y comunicar información sobre amenazas a una comunidad vulnerable, por lo que se usa para proteger vidas, señalando con anterioridad la posibilidad de un evento, lo que proporciona tiempo para tomar acciones que pueden reducir las condiciones de riesgo. (Edier Aristizábal, 2010) 1.4 Beneficios de los sistemas de alertas El sistema de alertas se convierte en una importante herramienta de seguimiento y monitoreo para la toma de decisiones a tiempo. Teniendo en cuenta los tipos de alertas que los usuarios creen, las alertas los mantendrán siempre informados sobre la ocurrencia de hechos de su interés. En la detección de errores de medicación: los sistemas de alertas incorporan en los sistemas informáticos herramientas específicas para detectar y prevenir errores de medicación y acontecimientos adversos por medicamentos. Los más 8.

(17) Capítulo 1: Consideraciones generales sobre sistemas de alertas. utilizados están integrados en los programas de prescripción electrónica asistida y en los sistemas de dispensación en dosis unitarias. El requisito indispensable es disponer del perfil de la medicación del paciente, aunque las versiones más avanzadas combinan los datos de tratamiento con los datos antropométricos y de laboratorio.(M.D Santos-Rubio, 2011) En el monitoreo a distancia de pacientes con marcapasos (MP), desfibriladores automáticos. (DA),. los. sistemas. grabadoras de asa cerrada y. de. resincronización. cardíaca. (SRC),. productos de monitoreo hemodinámico, los. sistemas de alerta permiten la detección precoz de las arritmias, alteraciones en la función del dispositivo, o cambios en el estado clínico del paciente, durante el seguimiento, ayudan en la programación individual de los horarios para optimizar el manejo de los pacientes con arritmias frecuentes o complicaciones técnicas, y reducir el costo y la carga de trabajo impuestas por los pacientes sin complicaciones y con condición clínica estable, aceptación de los pacientes, con el más alto nivel de confiabilidad de que el dispositivo implantado funciona correctamente, con la ventaja de un menor número de visitas al hospital.(JC Nielsen 2008) 1.5 Antecedentes y ejemplos de algunos sistemas de alertas utilizados en el mundo. Uno de los primeros sistemas de alerta fue desarrollado por la Agencia de Proyectos de Investigación para la Defensa de los Estados Unidos en 1993, el sistema Leaders (Ligthweight Epidemiology Advanced Detection & Emergency Response System), al cual en años posteriores se le añadieron aplicaciones para extenderlo al sector civil. Este sistema utiliza información de los registros hospitalarios de varios hospitales de emergencia seleccionados y rastrea el reporte de síntomas inusuales. Fue utilizado con mucho éxito para la vigilancia de eventos anormales durante la discusión de la Copa del SuperBowl en el año 2001. En el futuro se le pretende incorporar bases de datos con. 9.

(18) Capítulo 1: Consideraciones generales sobre sistemas de alertas. información de laboratorio, farmacias y servicios de radiología, así como hacer su interfaz de usuario más amigable para facilitar su uso. (Kolbasuk) RODS (Real Time Outbreak and Disease Surveillance): La primera versión de este sistema fue creado por investigadores norteamericanos de la Universidad de Pittsburg en 1999, con la finalidad de mejorar las capacidades de respuesta de las autoridades sanitarias frente a una amenaza muy específica: el Bacillus anthracis. Este sistema recolecta información de las. principales causas de. admisión en los servicios de urgencia de hospitales seleccionados y en tiempo real clasifica estas causas en categorías de síndromes y alerta cuando existen anomalías que pueden ser. brotes epidémicos. La arquitectura de RODS. consiste en seis áreas funcionales: recolección de datos, clasificación del síndrome, almacén de datos, el encapsulamiento de la base de datos, detección de brotes e interfaz de usuario que permite visualizar los datos en forma de gráficos y mapa. El lenguaje de programación utilizado fue Java. (JU Espino, 2004) Para los Juegos Olímpicos de Invierno del 2002, en Salt Lake City, Utah, el sistema fue modificado incorporándosele la integración a otras bases de datos como reportes de laboratorio, órdenes de exámenes microbiológicos, llamadas a los centros de control toxicológico y reportes de servicios de radiología. Su utilización fue muy exitosa, se monitorearon 114 000 eventos agudos entre el 8 de febrero y el 31 de marzo del 2002 y no se detectaron brotes epidémicos significativos.(PH Gesteland, 2003). ALERT (Advanced Logic for Event Detection in Real Time): Se basa en la información recogida de variables “señales”: órdenes. de cultivo de líquido. cerebro espinal, hemocultivos, coprocultivos y radiografías de tórax positivas a neumonía. También recoge el número de pacientes que se atienden en algunos servicios de emergencia seleccionados, qué padecimientos presentan, cuáles son los diagnósticos y con esta información se les categoriza en una escala de gravedad del 1 al 5. Los resultados se pueden presentar con alrededor de 100. 10.

(19) Capítulo 1: Consideraciones generales sobre sistemas de alertas. gráficos diferentes y están disponibles en 24 horas. Este sistema también se probó antes del comienzo de los Juegos Olímpicos de Invierno de Salt Lake City y permitió alertar sobre un brote sustancial de influenza para el cual las autoridades sanitarias pudieron tomar las medidas pertinentes con anterioridad a las competencias.(Sample, 2002). GPHIN (Global Public Health Intelligence Network) Red de Información Mundial en Salud Pública: Es un sistema de “alerta temprana, seguro, basado en Internet que busca reportes preliminares significativos de problemas de salud, en “tiempo real”, 24 horas al día, los 7 días de la semana. Este sistema único y multilingüe busca y provee información importante no verificada acerca de brotes de enfermedades y otros eventos en salud pública, monitoreando los medios de comunicación a escala mundial en seis idiomas, árabe, chino, inglés, francés, ruso y español. Este proceso automático incluye la filtración y categorización de la información por importancia que finalmente es completado por análisis humano. Fue creado en Canadá y es utilizado por la OMS (Organización Mundial de la Salud) desde 1997. ((RIMSP).). Virgil: Este proyecto de Vigilancia de la Resistencia Viral fue presentado por el Centro de Investigaciones del Instituto Nacional de Investigaciones Médicas Científicas (INSERM) de Francia en Junio del 2004, producto de la colaboración de investigadores y académicos de toda Europa y constituye una red de información dirigida a combatir las. nuevas pandemias con tecnologías que. pueden monitorear la drogo-resistencia de las cepas virales existentes y la susceptibilidad de las nuevas cepas emergentes y desencadenar alertas. Este proyecto comenzó con la vigilancia de la hepatitis viral y la influenza y tiene el propósito de extenderse a otras infecciones virales. (Larkin, 2004). NDRM: (Nacional Retail Data Monitor): Es un sistema automatizado que desde diciembre del año 2002 en Estados Unidos, analiza las ventas diarias de. 11.

(20) Capítulo 1: Consideraciones generales sobre sistemas de alertas. medicamentos sin prescripción en tiendas pertenecientes a varias cadenas de establecimientos minoristas de casi todo el país (más de 18 000 tiendas en 47 estados). Este sistema recibe diariamente los reportes de ventas y es capaz de detectar comportamientos anormales en menos de 24 horas, lo cual les permite a los epidemiólogos recibir información muy oportuna. Su diseño comprende áreas para el almacenamiento y agregación de los datos, algoritmos para monitorear patrones anormales de ventas y una interfase de. usuario que. permite apreciar gráficos y mapas de ventas de los principales productos por tiendas y por regiones. El sistema utiliza una base de datos relacional tipo Oracle para almacenar la información y como gestor de la base de datos el MySQL Server. (MM Wagner, 2004). DengueNet: Sistema de alertas en tiempo real basado en Internet creado por la OMS para la vigilancia global del dengue y el dengue hemorrágico en mayo de 2003, permite fomentar y fortalecer la capacidad de los sistemas de salud para la vigilancia, la prevención, control y tratamiento. Las principales características de este sistema de vigilancia son: servicio protegido por. contraseña que. permite la introducción de datos a distancia, inclusión de subdivisiones por estado o provincia de los países, para los que se introducen o se calculan indicadores, dispositivo dinámico de consulta y preguntas, con el análisis y la presentación de los datos en gráficos, tablas, textos y utilización de herramientas SIG para elaborar mapas. Dispone de series de datos recopilados desde 1955. Actualmente se han incorporado más de 80 países de las Américas, Sudeste Asiático y Pacífico Occidental. (surveillance.). PANDA (Population-wide Anomaly Detection and Assessment): Este sistema utiliza un algoritmo bayesiano para monitorear dos bases de datos, la de las ventas de medicamentos sin prescripción y la de principales diagnósticos de los servicios de emergencia. Fue creado en Pittsburg, Estados Unidos en el 2004. Puede procesar alertas en tiempo real. (WK Wong, 2005). 12.

(21) Capítulo 1: Consideraciones generales sobre sistemas de alertas. FormSUS. (Notificación de brotes y emergencias en Salud Pública): Se trata un sistema de alertas en línea de uso público, desarrollado en Brasil desde el año 2003 para la creación de formularios para diversos tipos de información en el sector salud, con la finalidad de agilizar, estructurar y mejorar la calidad del proceso de recolección y diseminación de datos en Internet, también incluye formularios de notificación de enfermedades y brotes epidémicos asociados a bases de datos que pueden ser consultadas diariamente. (Brasil) 1.6 Antecedentes y ejemplos de sistemas de alertas existentes en Cuba. Cuba ha asumido el reto de informatizar su sociedad y hacer un óptimo uso de las nuevas tecnologías, por ello la informática y las telecomunicaciones constituyeron desde el inicio la plataforma tecnológica para el procesamiento, análisis e interpretación de datos e información que dan origen a productos y servicios de vigilancia.. SAVT: El Sistema de Alerta de la Vigilancia de la Tuberculosis, este sistema fue uno de los primeros confeccionados en el país por investigadores del Instituto de Medicina Tropical "Pedro Kourí" en 1994. Utilizó el lenguaje de alto nivel Clipper 87 debido a las facilidades que brindaba para el manejo de bases de datos y las facilidades gráficas de su biblioteca DGE. Todo ello sobre el sistema operativo MS-DOS.. La configuración mínima necesaria. para la. implementación era una microcomputadora IBM o compatible con ella, con 640 Kb de memoria interna, una torre de disco flexible, un disco duro de 10 Mb, un monitor a color y una impresora de carro corto. (A Mach, 1995). VIGILA:. Software. para. la. vigilancia. epidemiológica. de. enfermedades. transmisibles que permite registro y mantenimiento de datos con. sencillez,. creado en 1998 en el Instituto de Medicina Tropical "Pedro Kourí". Permite pronosticar y detectar con una alta sensibilidad la aparición de situaciones epidémicas, convirtiéndose en un instrumento para la alerta y la acción; puede. 13.

(22) Capítulo 1: Consideraciones generales sobre sistemas de alertas. elaborar reportes y gráficos para interpretar datos y comparar los eventos de salud entre los territorios de la región que se vigila, con la incorporación de técnicas de análisis geográfico; permite observar varias enfermedades de manera simultánea y transferir reportes, gráficos, mapas y pronósticos resultantes del trabajo hacia otras aplicaciones del entorno operativo Windows. Su aplicación ha demostrado su valor como instrumento de alerta. (R Martínez, 1999) Vigired: Este sistema de alerta creado en la UATS del municipio de San Cristóbal, provincia de Pinar del Río en el 2005, garantiza la inmediatez de la información al actualizar simultáneamente la base de datos, cada vez que se introduce nueva información, está diseñado en formato Web y puede ser solicitado y consultado desde cualquier. lugar y/o momento. Permite. estandarización de la información en el territorio donde se aplique, la síntesis de la misma y su registro para consultas posteriores. El sistema está desarrollado con los lenguajes de programación de distribución libre básicamente HTML, JAVA-SCRIPT y PHP. Como gestor de la base de datos se utilizó el MySQL Server. (Lorenzo, 2001). WINEDOS: Sistema de alertas para el análisis de las bases de datos de las enfermedades de declaración obligatoria desarrollado en la provincia Las Tunas, en el año 2000. Fue programado en Microsoft Access 97 para Windows 95. Posee varios módulos en un ambiente de menú de fácil aceptación y flexibilidad para el usuario. La aplicación entre sus funciones tiene captar datos preliminares, importar datos que se oficialicen en los departamentos de estadísticas, captar poblaciones para el cálculo de las tasas, generar canales por diferentes tipos de métodos de cálculos, tablas o reportes de salida con tasas, proporciones y el diagnóstico de una epidemia por municipios y provincia, con frecuencia semanal. (Pérez, 2006 ). 14.

(23) Capítulo 1: Consideraciones generales sobre sistemas de alertas. 1.7 Breve descripción de las tecnologías utilizadas en la conformación del sistema de alerta en cuestión. Se ha escogido Java que es un lenguaje de programación de alto nivel de última generación que se basa en el paradigma orientado a objetos. Por sus características, es un lenguaje que permite disminuir el tiempo de desarrollo y a la vez aumentar la manejabilidad del código. (Eckel, 2000) 1.7.1 El lenguaje Java Java es un lenguaje de programación de propósito general, basado en clases y orientado a objeto. Java es un lenguaje de alto nivel, ya que no proporciona ninguna información acerca de la máquina sobre la cual se ejecutará el programa. Como lenguaje de programación para computadores, Java se introdujo a finales de 1995. El principal objetivo del lenguaje Java es llegar a ser el “nexo universal” que conecte a los usuarios con la información, esté ésta situada en el ordenador local, en un servidor de Web, en una base de datos o en cualquier otro lugar.. La compañía Sun describe el lenguaje Java como. “simple, orientado a objetos, distribuido, interpretado, robusto, seguro, de arquitectura neutra, portable, de altas prestaciones, multitarea y dinámico”. Además de una serie de halagos por parte de Sun hacia su propia criatura, el hecho es que todo ello describe bastante bien el lenguaje Java.(Javier García de Jalón and Alfonso Brazález, 1999) Como otros lenguajes de programación que le precedieron Java es una mezcla de los mejores elementos de su rica herencia combinados con los conceptos innovadores que requiere su entorno único. Java fue diseñado con el objetivo de que su aprendizaje y utilización resultaran sencillos para el programador profesional, para satisfacer los requerimientos del mundo real de crear programas interactivos, para ello Java proporciona la programación multihilo que. permite. la. escritura. de. programas. que. hagan. varias. cosas. simultáneamente.(Schildt, 2001). 15.

(24) Capítulo 1: Consideraciones generales sobre sistemas de alertas. 1.7.2 Conectividad a base de datos desde Java Una base de datos no es más que un conjunto de datos que pertenecen al mismo contexto y almacenados para su posterior uso. Existe software que permiten almacenar para luego acceder a los datos de forma rápida y estructurada de una base de datos, los cuales son denominados sistemas gestores de bases de datos, abreviado (SGBD). Una de las principales aplicaciones de cualquier lenguaje moderno es la posibilidad de utilizar datos pertenecientes a un sistema de base de datos. La dificultad del manejo de archivos y las facilidades de manejo de datos que ofrecen los sistemas gestores de base de datos son los causantes de esta necesidad. En el mercado hay gran cantidad de bases de datos y cada una de ellas se maneja de un modo diferente. Esto está en contra del planteamiento fundamental de Java que intenta que la programación sea independiente de la plataforma. La idea de Sun era desarrollar una sola API para el acceso a bases de datos, esta interfaz se conoce como JDBC (Java DataBase Connectivity). Los requisitos eran: . JDBC sería una API a nivel SQL.. . JDBC debía ser similar a las API existentes (en especial a la ya entonces famosa ODBC de Microsoft).. . JDBC debía ser simple.. La comunicación fundamental entre las aplicaciones y JDBC se realiza a través de instrucciones SQL. Una vez instalado, configurado y. puesto en. funcionamiento nuestro sistema gestor de bases de datos favorito si queremos que las bases de datos creadas por el sean accesibles desde los programas Java, necesitamos el controlador JDBC de ese sistema. 1.7.3 Gestores de bases de datos En la actualidad existen diversos y variados gestores de base de datos y dentro de los más utilizados actualmente se encuentran: PostgreSQL y MySQL, en la aplicación se hace uso de los mencionados por ser estos los que se encuentran en uso en la entidad. 16.

(25) Capítulo 1: Consideraciones generales sobre sistemas de alertas. 1.7.3.1 Las principales características de MySQL MySQL es uno de los gestores de sistemas de base de datos de código abierto más populares disponible actualmente. Es un sistema de gestión de base de datos. relacional,. multihilo. y. multiusuario.. Proporciona. sistemas. de. almacenamientos transaccionales y no transaccionales. Un sistema de reserva de memoria muy rápido basado en hilos. Tablas hash en memoria, que son usadas como tablas temporales. Las funciones SQL están implementadas usando una librería altamente optimizada y deben ser tan rápidas como sea posible. MySQL tiene un sistema de privilegios y contraseñas que es muy flexible y seguro, y que permite verificación basada en el host. Las contraseñas son seguras porque todo el tráfico de contraseñas está encriptado cuando se conecta con un servidor. Soporte a grandes bases de datos. (Dubois, 2002). 1.7.3.2 Las principales características de PostgreSQL Se considera ampliamente que PostgreSQL es el manejador de base de datos de código. abierto más avanzado en el mundo.. Postgres fue desarrollado. originalmente en el Departamento de Ciencias de Computación de la Universidad de Berkeley. Fue pionero de muchos de los conceptos referentes a objetos que ahora están disponibles en algunas bases de datos comerciales. Proporciona soporte a lenguaje SQL92/SQL93, integridad en transacciones y capacidad para extensión de tipos. PostgreSQL es de código abierto por lo que usted es libre modificar PostgreSQL para adaptarlo a sus necesidades particulares. PostgreSQL soporta la integridad referencial que se usa para asegurar la validez de los datos de una base de datos Hoy, PostgreSQL es desarrollado por un grupo internacional de defensores de software de códigoabierto conocido como PostgreSQL Global Development Group. (John Worsley, 2001 ). 17.

(26) Capítulo 1: Consideraciones generales sobre sistemas de alertas. 1.7.4 JavaMail El API JavaMail es un paquete opcional (extensión estándard) para leer, componer, y enviar mensajes electrónicos. Este paquete es usado para crear programas del tipo MUA (Mail User Agent), similares a Eudora, Pine, y Microsoft Outlook. Su propósito principal no es transportar, enviar, o reenviar mensajes como sendmail u otros programas del tipo MTA (Mail Transfer Agent). En otras palabras, los usuarios interactúan con los programas para leer y escribir emails. Los programas MUA tratan con los programas MTA para el envío real. El API JavaMail está diseñado para proporcionar acceso independiente del protocolo para enviar y recibir mensajes. Antes de mirar dentro de las especificaciones del API JavaMail, echemos un vistazo a los protocolos usados con el API. Básicamente son cuatro: SMTP POP IMAP MIME Entender lo básico de cada protocolo ayudará a entender mejor cómo usar el API JavaMail. Aunque el API sea independiente del protocolo, no podemos evitar las limitaciones de los protocolos subyacentes. SMTP El protocolo Simple Mail Transfer Protocol (SMTP) está definido por la RFC 821. Define el mecanismo para enviar e-mail. En el contexto del API JavaMail, nuestro programa basado en JavaMail comunicará con el servidor SMTP de nuestro proveedor de servicios (ISP). Este servidor SMTP dejará el mensaje en el servidor SMTP del recipiente(s) para que sea recogido por los usuarios a través de POP o IMAP. Es nuestra responsabilidad del usuario asegurar que el servidor SMTP se configure correctamente. No hay nada en el API JavaMail sobre tareas como la configuración de un servidor para retransmitir mensajes o para agregar y para quitar cuentas del e-mail. POP 18.

(27) Capítulo 1: Consideraciones generales sobre sistemas de alertas. POP viene de Post Office Protocol. Actualmante en la versión 3, también conocido como POP3, la RFC 1939 define este protocolo. POP es el mecanismo que la mayoría de la gente usa en Internet para conseguir su correo. Define el soporte de un sólo buzón de entrada por cada usuario. IMAP IMAP es un protocolo más avanzado para recibir mensajes. Definido en la RFC 2060, IMAP viene de Internet Message Access Protocol, y está actualmente en la versión 4, también conocida como IMAP4. Para usar el IMAP, nuestro servidor de correo debe soportar este protocolo MIME MIME viene de Multipurpose Internet Mail Extensions. No es un protocolo de transferencia de e-mail. En su lugar, define el contenido de lo que se está transfiriendo: el formato de los mensajes, adjuntos, etc.. Conclusiones parciales  Los sistemas de alertas tienen un gran uso en la actualidad generalmente ligado al trabajo con bases de datos.  Requieren de la integración de datos de muy diversas fuentes y su desarrollo puede garantizar el pronóstico oportuno de diversas situaciones.  Actualmente se encuentra el uso de los sistemas de alertas ligado a diferentes ramas de la ciencia y la técnica en especial al campo de la salud.. 19.

(28) Capítulo 2: Estructura y diseño del sistema. 2 ESTRUCTURA Y DISEÑO DEL SISTEMA. En el presente capítulo se realizará una reseña más detallada sobre el análisis, diseño e implementación del sistema. Se explicaran los métodos principales utilizados en la solución y se ilustrará a través de los diagramas pertinentes el funcionamiento del sistema. 2.1 Características generales que debe tener el software Luego de estudiar los objetivos que deben cumplirse con la realización del software se hace una reseña de estos.  El software debe ser capaz de conectarse a diferentes gestores de bases de datos (MySQL y PostgreSQL).  Debe implementar un módulo que permita la creación de los tipos de alertas necesarios.  Debe ser capaz de enviar las alertas por correo e implementar la seguridad necesaria en el acceso a las bases de datos.. 2.2 Modelación del sistema A partir de este punto se comienza a modelar el sistema que se va a construir. Para ello se identifican sus requisitos funcionales y se modelan estos en términos de casos de uso del sistema. El análisis y diseño de sistemas es una guía que permite estructurar el proceso de desarrollo de proyectos de software. Para ello, es necesario desarrollar una profunda investigación del problema: ver en qué consiste y qué debe hacerse, así como determinar los objetivos, requerimientos y fines del sistema objeto de análisis. Para desarrollar una aplicación de software, también es preciso contar con descripciones detalladas, alto nivel de la solución lógica y saber cómo satisface los requerimientos y las restricciones del conflicto, de manera que otras personas ajenas al proyecto puedan comprender su objetivo en poco tiempo. Estas etapas son de gran importancia en el ciclo de vida del. 20.

(29) Capítulo 2: Estructura y diseño del sistema. proyecto, pues este procedimiento permite reducir al mínimo el riesgo de fracaso de nuevos planes.. 2.2.1 Diagramas y descripción de casos de uso del sistema Los modelos de casos de uso proporcionan un medio sistemático e intuitivo de capturar requisitos funcionales del sistema basándose en los requerimientos de los usuarios. Ellos dirigen todo el proceso de desarrollo de un software ya que constituyen el punto de partida para llevar a cabo la mayoría de las actividades: el análisis, diseño y prueba del software (I JACOBSON, 2000). Este modelo se realiza identificando cada actor del sistema como los posibles usuarios para los cuales está realizado el mismo. Los diagramas de casos de uso también delinean gráficamente el comportamiento del sistema. Representan como el sistema es usado desde la perspectiva del actor. Muestran con un alto nivel de detalle cómo va a ser utilizado el sistema por los actores, además contiene interacciones y relaciones entre casos de uso o actores.(Rational Software, 2003) Los casos de uso permiten definir los límites y las relaciones entre el sistema y el entorno. Son descripciones de la funcionalidad de la aplicación independientes de la implementación, ellos cubren la carencia existente en métodos previos (G Booch, 2005) en cuanto a la determinación de requisitos, dividen el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo y están basados en el lenguaje natural, es decir, es accesible por los usuarios.. La herramienta Geocuba está destinada a un solo tipo de actor, que es una persona. en la empresa. con privilegios administrativos que pueda acceder a. cualquier servidor de bases de datos que desee. Esta persona debe tener el conocimiento necesario para crear correctamente cualquier tipo de consultas a las bases de datos para la correcta creación de las alertas. Dicho especialista se ha nombrado Administrador en el diagrama de la Figura 2.1.. 21.

(30) Capítulo 2: Estructura y diseño del sistema. 2.2.1.1 Diagrama de casos de uso. Figura 2.1 Casos de uso del actor Administrador. En la tabla 2.1 se describen los casos de uso del actor Administrador.. Casos de uso. Descripción. Gestionar servidor en el. En este caso de uso se incluyen las acciones de :. sistema. o Agregar servidor al sistema o Editar servidor en el sistema o Eliminar servidor del sistema El administrador al entrar al sistema puede proceder a la creación de un nuevo servidor para la conexión al mismo, también puede editar un servidor existente en el sistema si algunos de los parámetros ya no es válido y también eliminarlo si ya no se va a necesitar.. Casos de uso. Descripción. 22.

(31) Capítulo 2: Estructura y diseño del sistema. Crear base de datos de. En el sistema el administrador antes de proceder a la. alertas donde se. creación de cualquier alerta debe crear la base de. almacenaran las alertas y los datos donde estarán las tablas que almacenarán las servidores.. alertas y los servidores.. Gestionar alertas en el. En este caso de uso se contemplan las acciones de:. sistema.. o Crear una nueva alerta o Editar alerta existente en el sistema o Eliminar alerta del sistema En el sistema el administrador tiene la posibilidad de configurar una alerta para su posterior envío por correo, también puede editar alguna alerta del sistema si la configuración anterior no es la que se desee y también eliminar una alerta del sistema si ya no se necesita.. Configurar el envío de. Luego de la creación de las alertas y antes del envío. alertas por correo. de cualquiera, se debe proceder con la configuración del correo para el correcto envío de las alertas.. Tabla 2.1 Descripción de los casos de uso del usuario Administrador. 2.2.1.2 Diagrama de clases Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. El diagrama de clase describe los tipos de objetos que hay en un sistema y las diversas clases de relaciones estáticas (asociaciones, subtipos) que existen entre ellos. También muestran los atributos y operaciones de una clase y las restricciones a que se ven sujetos, según la forma en que se conecten los objetos. En la Figura 2.2 se ilustran las clases principales del prototipo de software con sus atributos y métodos más relevantes mediante un diagrama de clases en UML. En el mismo, solo se hace mención a las clases más importantes de la herramienta, así como en algunas de estas clases se obviaron algunos atributos y métodos de 23.

(32) Capítulo 2: Estructura y diseño del sistema. menor relevancia, para así hacer el diagrama menos extenso y facilitarle al lector la comprensión de dicho diagrama.. Figura 2.2 Diagrama de clases del sistema. 2.2.1.3 Diagrama de despliegue Según (I JACOBSON, 2000) el modelo de despliegue es un modelo de objetos que describe la distribución física del sistema en términos de cómo se distribuye la funcionalidad entre los nodos de cómputo. Estos nodos se comunican mediante el protocolo TCP/IP de Internet e Intranet. Se utiliza como entrada fundamental en las actividades de diseño e implementación debido a que la distribución del sistema tiene una influencia principal en su diseño”. Se puede observar lo siguiente sobre el modelo de despliegue: • Cada nodo representa un recurso de cómputo, normalmente un procesador o un dispositivo hardware similar. 24.

(33) Capítulo 2: Estructura y diseño del sistema. • Los nodos poseen relaciones que representan medios de comunicación entre ellos, tales como Internet, intranets, bus y similares.  El modelo de despliegue puede describir diferentes configuraciones de red, incluidas las configuraciones para prueba y para simulación. • La funcionalidad (los procesos) de un nodo se definen por los componentes que se distribuyen sobre ese nodo. • El modelo de despliegue en sí mismo representa una correspondencia entre la arquitectura software y la arquitectura del sistema (el hardware).. Figura 2.3 Diagrama de despliegue del sistema. 2.2.1.4 Diagrama de actividades del sistema. El diagrama de actividad muestra el flujo de actividad a actividad; los diagramas de actividad tratan la vista dinámica de un sistema. Un caso especial de diagrama de estados en el cual todos o casi todos los estados son estados de acción y en el cual todas o casi todas las transiciones son disparadas por la terminación de las acciones en los estados origen(G Booch, 2005). A continuación se presenta los diagramas de actividades para los casos de uso 25.

(34) Capítulo 2: Estructura y diseño del sistema. “Gestionar alertas en el sistema” con su caso de uso incluido “Crear alerta” y “Editar alerta”, con el objetivo de modelar los procesos de acuerdo a las actividades que se realizan en cada uno de ellos.. Figura 2.4 Diagrama de actividad del caso de uso “Crear alerta”. 26.

(35) Capítulo 2: Estructura y diseño del sistema. Figura 2.5 Diagrama de actividad del caso de uso “Editar alerta”. 2.3 Bases de datos del sistema El sistema para el almacenamiento de las alertas creadas y. los servidores. agregados tiene implementada la creación de una base de datos llamada alertas que contiene tres tablas: alertas, servidores y consultas. Figura 2.6. 27.

(36) Capítulo 2: Estructura y diseño del sistema. Figura 2.6 Tablas de la base de datos.. 2.3.1 Descripción de las tablas: Nombre de la tabla: Servidores Descripción: en esta tabla se almacenaran todos los servidores que se adicionen al sistema. Atributo. Tipo. Descripción. Host. text. Dirección del servidor al cual queremos acceder.. Puerto. int. Numero de puerto a utilizar para la conexión.. Usuario. text. Nombre de usuario que se utilizara para la conexión.. Password. text. Contraseña del usuario. Tipo. text. Tipo de servidor al cual me estoy conectando (Postgres o Mysql). Id. float. Identificador de los servidores (llave primaria). 28.

(37) Capítulo 2: Estructura y diseño del sistema. Nombre de la tabla: Alertas Descripción: en esta tabla se almacenaran las alertas creadas en el sistema y que sean de tipo fecha. Atributo Tipo_de_alertas. Tipo text. Descripción Clasificación de las alertas.. Asunto. text. Asunto del correo a enviar.. Mensaje. text. Cuerpo del correo que debe enviarse.. Login. text. Login de la persona que recibirá el correo.. Cantidad_días. int. Número de días a tener en cuenta por el sistema para el envío de la alerta (antes o después).. Servidor. text. Descripción completa del servidor en que fue creada la tabla.. Base_de_Datos. text. Base de datos que contiene la tabla a partir de la cual se creó la alerta.. Tabla. text. Tabla que contiene la columna a partir de la cual se creó la alerta.. Columna. text. Columna a partir de la cual es generada la alerta. Id. float. Identificador de las 29.

(38) Capítulo 2: Estructura y diseño del sistema. alertas(llave primaria) Tipo_Servidor. text. Tipo de servidor al cual me estoy conectando (Postgres o Mysql). Id_Servidor. float. Identificador del servidor(llave foránea). Nombre de la tabla: Consultas Descripción: en esta tabla es sistema almacenará las alertas de consultas que se hagan relacionando tablas de una misma base de datos. Atributo Tipo_de_alertas. Tipo text. Descripción Clasificación de las alertas.. Asunto. text. Asunto del correo a enviar.. Mensaje. text. Cuerpo del correo que debe enviarse.. Login. text. Login de la persona que recibirá el correo.. Servidor. text. Descripción completa del servidor en que fue creada la tabla.. Base_de_Datos. text. Base de datos que contiene la tabla a partir de la cual se creó la alerta.. Consulta. text. Consulta SQL que se ejecuta para la creación de la alerta. 30.

(39) Capítulo 2: Estructura y diseño del sistema. Id. float. Identificador de las alertas(llave primaria). Tipo_servidor. text. Tipo de servidor al cual me estoy conectando (PostgreSQL o MySQL). Id_Servidor. Identificador del servidor(llave foránea). 2.4 Implementación del software Para la implementación del software se tendrá en cuenta:  Los requisitos que debe cumplir el producto final.  La correcta creación de las clases y métodos necesarios para el desarrollo del software. También es necesario aclarar que para el correcto desarrollo de un sistema de alertas basado en bases de datos se deben utilizar con precisión y calidad las facilidades que nos brinde el lenguaje que será utilizado con consultas SQL. Para ello se utilizó el API JDBC (Java Database Connectivity) que brinda un conjunto de interfaces y clases para acceder a cualquier motor de base de datos que lo implemente. JDBC se abstrae de los detalles específicos del gestor, permitiendo así conectarse prácticamente de la misma manera a cualquier base de datos, por esto el sistema logra realizar una rápida conexión a los diversos gestores utilizados. 2.4.1 Configuración de los diversos servidores para las conexiones. El software al necesitar acceder a diversas bases de datos que pueden encontrarse en diferentes gestores debe permitir la configuración del acceso a estos servidores. Para ello fue creada la clase AlertDataSource que contiene los métodos necesarios para recopilar la información necesaria de cada servidor que se agregue al sistema: host, puerto, usuario, password y a qué tipo de servidor se conecta. Esta clase también contiene los métodos que, una vez seleccionado un 31.

(40) Capítulo 2: Estructura y diseño del sistema. servidor permite la conexión a todas las bases de datos existentes en el mismo. El método getTreeModel() se encarga de mostrar las bases de datos del servidor agregado de forma jerárquica utilizando para esto una consulta ResultSet para así obtener los metadatos de la conexión y conformar el árbol donde se muestran los datos. 2.4.2 Configuración y modificación de alertas. En el sistema antes de proceder con la creación de alertas se debe haber creado la base de datos a la que pertenecerán las tablas de almacenamiento de alertas y servidores. Para la creación de las alertas al acceder a un servidor los datos son mostrados de forma jerárquica y mediante estos se procede a la creación de las alertas. Para crear la alertas de tipo fecha se utiliza la clase DateFieldTreeNode que hereda de FieldTreeNode que se encarga, cada vez que se seleccione un objeto que sea una columna de cierta base de datos identificar si es de tipo fecha o no y a partir de ahí establecer los datos para la creación de una alerta. Para el almacenamiento de alertas de tipo fecha se utiliza el método insertar_alerta de la clase Commands que se encarga de enviar las alertas a la tabla correspondiente luego de su configuración. Luego se utiliza el método Check_Alerts de la clase Commands cada vez que se inicie el sistema para la comprobación de alertas y si alguna llego a su término se procede con el envío.. Figura 2.7 Diagrama del proceso realizado durante la creación de una alerta.. 32.

(41) Capítulo 2: Estructura y diseño del sistema. 2.4.3 Configuración del correo para el envío de las alertas. El sistema solo soporta el envío de correos con el uso del protocolo SMTP. La configuración del correo para el envío de alertas el sistema la realiza a. través. de la clase MailServerConfiguration la cual contiene los métodos necesarios para guardar la configuración del correo: el servidor, el puerto y define si serán utilizadas las TLS (Transport Layer Security). Luego la clase EMailSender es la que se encarga del envío del correo a través del servidor smtp utilizado. Para todas esta acciones se hace uso de la API javamail en su versión 1.4.5. Veremos las clases principales que componen el API: Session, Message, Address, Authenticator, Transport, Store, y Folder. Todas estas clases se encuentran en el paquete del nivel superior del API JavaMail: javax.mail, aunque frecuentemente nos veremos utilizando clases del paquete javax.mail.internet. Session La clase Session define una sesión de correo básica. Es a través de sesión que todas las demás funcionan. El objeto Session. se aprovecha de un objeto. java.util.Properties para obtener información como el servidor de correo, el nombre de usuario,la contraseña, y otra información que puede compartirse a lo largo de toda la aplicación. Message Una vez que tenemos nuestro objeto Session, es hora de empezar a crear un mensaje para enviar. Esto se hace con un objeto Message. Siendo una clase abstracta, debemos trabajar con una subcalse, en la mayoría de los casos será javax.mail.internet.MimeMessage.. Un MimeMessage es un mensaje de e-mail. que entiende los tipos MIME, definidos en las distintas RFCs. Las cabeceras de mensajes están restringidas a caracteres US-ASCII, aunque en ciertos campos de cabecera se pueden codificar caracteres no ASCII. Una vez que tenemos nuestro. 33.

(42) Capítulo 2: Estructura y diseño del sistema. mensaje, podemos configurar sus diferentes partes, como Message implementa el interface Part (con MimeMessage implementando MimePart). Address Una vez que hemos creado la Session y el Message, y también hemos rellenado el mensaje con contenido, es hora de poner dirección a nuestra carta con un objeto Address. Como Message, Address es una clase abstracta. Usaremos la clase javax.mail.internet.InternetAddress. Transport La parte final del envío de un mensaje es usar la clase Transport. Esta clase utiliza el lenguaje específico del protocolo para enviar mensajes (normalmente SMTP). Es una clase abstracta y funciona como Session. Store y folder Obtener los mensajes empieza de forma similar a enviar mensajes, con una Session. Sin embargo, después de obtener la sesión, conectamos a un Store, probablemente con un nombre de usuario y una password. Como con Transport, le decimos al Store qué protocolo utilizar. Después de conectar al Store, podemos obtener un Folder, que debe estar abierto antes de poder leer los mensajes que hay en su interior. La clase EMailSender que como se ha dicho anteriormente es la que se encarga del envío de los correos del sistema entre otros contiene dos métodos importantes encargados del envío de los correos:  El método ConnectWithMailServer, que recibe por parámetro una configuración de correo, es el encargado de conectar con el servidor de correo que se le predeterminó para el envío de las alertas.  El método Send, que recibe por parámetro el login de la persona a la que debe ser enviado el correo, el asunto, el mensaje y la configuración del correo de la persona que recibirá el correo. 34.

(43) Capítulo 2: Estructura y diseño del sistema. A continuación se muestra el código de ambos métodos: public static void ConnectWithMailServer(MailServerConfiguration conf) { try { if (transport != null) { return; } Properties props = new Properties(); props.put("mail.smtp.port", conf.getPort()); props.put("mail.smtp.host", conf.getServer()); if (conf.isUseTLS()) { props.put("mail.smtp.ssl.checkserveridentity", "false"); props.put("mail.smtp.ssl.trust", "*"); props.put("mail.smtp.auth", "true"); props.put("mail.smtp.starttls.enable", "true"); } props.put("mail.smtp.debug", "true"); Authenticator auth = new SmtpAuthenticator(conf); session = Session.getDefaultInstance(props, auth); transport = session.getTransport("smtp"); session.setDebug(true); } catch (NoSuchProviderException ex) { Logger.getLogger(EMailSender.class.getName()).log(Level.SEVERE, null, ex); } }. public static void CloseConnection(){. 35.

(44) Capítulo 2: Estructura y diseño del sistema. try { transport.close(); transport = null; } catch (MessagingException ex) { Logger.getLogger(EMailSender.class.getName()).log(Level.SEVERE, null, ex); } finally { transport = null; } } public. static. boolean. Send(String. to,. String. subject,. String. text,. MailServerConfiguration conf) { try { if (transport == null) return false; /* * Construct the message and send it. */ Message msg = new MimeMessage(session); msg.setFrom(new InternetAddress(conf.getUser())); msg.setRecipients(Message.RecipientType.TO, InternetAddress.parse(to, false));. msg.setSubject(subject); msg.setText(text); msg.setHeader("X-Mailer", "mailsend"); msg.setSentDate(new Date()); msg.saveChanges(); // send the thing off transport.send(msg);. 36.

(45) Capítulo 2: Estructura y diseño del sistema. return true; } catch (Exception ex) { return false; } } 2.5 Funcionamiento del sistema El sistema cuenta con un método llamado Java_in_Taskbar que se encarga de que al minimizar o cerrar la aplicación se siga ejecutando y pueda restablecerse, el icono de la aplicación pasa a la barra de tareas donde pude cliquearse con el botón secundario del mouse y. pueda escogerse la opción que el usuario desee.. Para ello se utilizaron las facilidades que brinda la clase SystemTray del paquete Awt de Java. De esta clase se utilizaron varios métodos los principales son:  El método boolean isSupported() que devuelve true si la plataforma donde se está ejecutando la aplicación soporta el uso de SystemTray.  El método SystemTray getSystemTray() que si es permitido el uso de SystemTray en la plataforma donde se esta ejecutando la aplicación asigna a la ventana principal de la aplicación el funcionamiento descrito anteriormente. Conclusiones parciales En este capítulo se analizaron las características principales en cuanto al análisis, diseño e implementación del software en cuestión. Se realizó la modelación del negocio para comprender la estructura y la dinámica del mismo, con el objetivo de conocer sus requerimientos funcionales, llegando de esta forma a la descripción de los casos de uso más importantes. De lo anteriormente explicado se puede concluir que:. 37.

(46) Capítulo 2: Estructura y diseño del sistema.  En la etapa de análisis del sistema se utiliza el lenguaje de modelado UML para modelar, construir y documentar los elementos esenciales que conforman al mismo, además se muestra el modelo de datos de la base de datos que utiliza el sistema para el almacenamiento de las alertas creadas y los servidores agregados a él.  Se desarrolla la fase de diseño que muestra una idea completa de lo que será realmente el software.  Durante la etapa de implementación se logra que el sistema sea un producto de software flexible, fácil de utilizar y mantener.. 38.

(47) Capítulo 3: Manual de usuario. 3 MANUAL DE USUARIO Una parte importante dentro del proceso de desarrollo de un software. lo. constituye la elaboración del manual del usuario, que es la guía de pasos a seguir por el usuario para interactuar con el sistema, coincidiendo con lo dicho por (A Rodolfo), “... es necesario que se detallen todas y cada una de las características que tienen los programas y la forma de acceder e introducir información.” A. través de este capítulo. se. realiza un. recorrido por el. funcionamiento de la aplicación final, con el objetivo de darle conocer al usuario las principales funcionalidades con las que la misma cuenta. 3.1 Requisitos para la explotación Si bien el sistema Geocuba no requiere grandes recursos en cuanto a hardware, si se hace imprescindible la instalación previa de la máquina virtual de Java, después de logrado esto la aplicación deberá funcionar, en la casi la totalidad de las computadoras, y su aspecto será como el que se aprecia en Figura 3.1. Figura 3.1 Ventana principal de la aplicación.. 39.

(48) Capítulo 3: Manual de usuario. 3.2 Modo de Trabajo Con el software Geocuba se podrán realizar varios tipos de tareas fundamentales: . Agregar servidores al sistema para la conexión a las bases de datos.. . Editar y eliminar los servidores existentes en el sistema.. . Configuración del correo para el envío de las alertas.. . Crear y configurar alertas.. . Modificar y eliminar alertas existentes.. 3.2.1 Agregar servidores al sistema para la conexión a las bases de datos Al entrar al sistema el administrador tendrá que agregar un nuevo servidor para proceder a la creación de la base de datos alertas que será donde se almacenarán todas las alertas creadas posteriormente en el sistema. Para la creación de este servidor se debe tener en cuenta su host, el puerto, el tipo de servidor que será y el usuario y contraseña válidas para la conexión. Los servidores creados se mostraran en la ventana principal del programa y se podrán ocultar o mostrar según el usuario lo desee. En la figura se muestra la ventana donde se debe introducir los datos para agregar un. servidor al. programa. Esta ventana se hará visible siempre que se presione en el botón “Agregar” de la barra de tareas de la ventana principal de la aplicación.. 40.

(49) Capítulo 3: Manual de usuario. Figura 3.2 Ventana para la gestión de servidores en el sistema.. 3.2.2 Editar y eliminar los servidores existentes en el sistema Un servidor que pierda utilidad para el usuario no tiene por qué seguir almacenado y mostrándose en el sistema el usuario cuando lo desee puede proceder a su eliminación o edición según estime. Para proceder a la edición solo se tiene que seleccionar un servidor de la lista y presionar el botón “Eliminar”.. Figura 3.3 Eliminación de servidores.. 41.

(50) Capítulo 3: Manual de usuario. Luego la lista será mostrada sin el servidor. Para la edición de un servidor se debe señalar el servidor en la lista y presionar el botón editar y será mostrada la ventana donde se procede a la edición del servidor que es la misma que se muestra al presionar “Agregar”. solo que esta. vez la ventana se mostrará con los datos del servidor que se desea editar.. Figura 3.4 Edición de servidores.. 3.2.3 Configuración del correo para el envío de las alertas. Es recomendable que el usuario del sistema antes de proceder a la creación de cualquier alerta configure el correo, este correo será del remitente de la alerta.. 42.

(51) Capítulo 3: Manual de usuario. Figura 3.5 Configuración del correo.. 3.2.4 Crear y configurar alertas Para crear alertas se debe seleccionar un servidor de la lista y luego escoger el tipo de alertas que se desee crear:. Figura 3.6 Elección de los tipos de alertas que se pueden crear.. Para fechas límites se muestra la ventana donde debemos proceder con la creación de la alerta. En el árbol mostrado se debe seleccionar una de las bases 43.