Repositorio Institucional de Documentos

UNIVERSIDAD DE ZARAGOZA CENTRO POLIT´ ECNICO SUPERIOR PROYECTO FIN DE CARRERA Ingenier´ıa de Telecomunicaci´on DESARROLLO DE UN GESTOR SNMPv3 CON INTERFAZ WEB PARA LA GESTI´ ON DE INFORMACI´ ON T´ ECNICA EN ESCENARIOS DE TELEMONITORIZACI´ ON DOMICILIARIA Ver´onica Garc´ıa Latorre Director: Nelia Lasierra Beamonte Ponente: ´ Alvaro Alesanco Iglesias Dpto. de Ingenier´ıa Electr´onica y Comunicaciones Marzo de 2012 Agradecimientos En primer lugar, quiero agradecer a ´ Alvaro la oportunidad que me ha brindado para realizar este proyecto fin de carrera. Sin duda, lo m´as interesante que he aprendido en la carrera, lo he aprendido en sus clases. Tambi´en quiero agradecer a Nelia por su apoyo incondicional, su tiempo, su esfuerzo, su paciencia, su eficiencia, por haberme ayudado cuando estaba atascada, por haberme motivado cuando m´as lo necesitaba... Sin su ayuda, no lo habr´ıa conseguido. Siempre estar´e muy agradecida. A mis padres y hermanos, les dedico este proyecto fin de carrera como agradecimiento al apoyo recibido durante estos a˜nos de estudio, al sacrificio que han tenido que realizar para hacer posible que yo haya llegado hasta aqu´ı, por vuestro cari˜no y por todo lo que hab´eis hecho por mi... Gracias. A mis compa˜neros a lo largo de la carrera, por todos los buenos momentos que hemos pasado juntos. No los quiero nombrar para evitar olvidarme de alguno pero, en especial, me gustar´ıa agradecer a Nacho por haber sido mi gran compa˜nero de pr´acticas y por saber c´omo ponerme las pilas. A Andreas, por todo el tiempo que has pasado ayud´andome. A Pedro,Yas yRub´en, porque no todos los d´ıas se conoce gente como vosotros. A mis compa˜neros de trabajo, Jos´e yRub´en, por todas las horas que os he estado contando mis problemas con el proyecto y me hab´eis escuchado. Gracias tambi´en a los que me amenizan la hora de la comida. AAdam, porque t´u me has aguantado m´as que nadie. A todos los que me prestaron su tiempo para poder realizar las evaluaciones. En especial a Mar´ıa yCris, porque no ten´eis mucho y a´un as´ı, vinisteis tan pronto como os avis´e. Y, por ´ultimo, a Laura, mi sobrina, que aunque todav´ıa es muy joven para darse cuenta, basta un minuto con ella para sacarme una sonrisa. DESARROLLO DE UN GESTOR SNMPv3 CON INTERFAZ WEB PARA LA GESTI´ ON DE INFORMACI ´ ON T´ ECNICA EN ESCENARIOS DE TELEMONITORIZACI´ ON DOMICILIARIA RESUMEN En este proyecto fin de carrera se ha desarrollado un gestor SNMPv3 (Simple Network Management Protocol) con interfaz web para la gesti´on t´ecnica de dispositivos en escenarios de telemonitorizaci´on domiciliaria. Para ello, este gestor se adapta al agente desarrollado en (1), el cual implementa una MIB (Management Information Base) que permite, adem´as de gestionar datos de la informaci´on t´ecnica de los dispositivos m´edicos que est´an conectados, gestionar los datos del dispositivo concentrador que se encarga de recogerlos, as´ı como de definir y configurar alarmas y eventos. Para facilitar la configuraci´on de las tablas SNMP y el acceso a la visualizaci´on de resultados, este proyecto desarrolla un interfaz gr´afico amigable e intuitivo, proporcionando una gesti´on transparente a la utilizaci´on de la arquitectura SNMP implementado en Java, con Servlets y JSP con el uso de algunos frameworks como Struts2 o Tiles y realizando conexiones seguras utilizando el protocolo TLSv1 sobre HTTP. El agente desarrollado en (1) permite tanto la gesti´on de los datos como la configuraci´on de alarmas y eventos que, una vez configuradas, enviar´an mensajes as´ıncronos al gestor. Para la visualizaci´on de esos datos, la aplicaci´on cuenta con herramientas adicionales que los representan gr´aficamente. En cuanto a los mensajes as´ıncronos, la aplicaci´on incorpora una herramienta para la captura y visualizaci´on de dichos mensajes. Por ´ultimo, se han realizado evaluaciones sobre usuarios de diferentes perfiles para testear si se han alcanzado los objetivos previstos para este proyecto y conocer los puntos en los que se puede mejorar. Los resultados obtenidos han sido muy satisfactorios. ´ Indice general 1 Introducci´on y Objetivos 1 1.1 Introducci´on............................... 1 1.2 Estadodelarte ............................. 3 1.3 Propuesta ................................ 5 1.4 Objetivos ................................ 7 1.5 Organizaci´on de la memoria . . . . . . . . . . . . . . . . . . . . . . 8 2 Arquitectura del Sistema 11 2.1 Descripci´on General . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Estructura Aplicaci´on Web . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.1 Tecnolog´ıa Web y Framework Struts2 . . . . . . . . . . . . . 14 2.2.2 Dise˜no de las p´aginas . . . . . . . . . . . . . . . . . . . . . . 16 2.3 Comunicaci´on SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3.1 Arquitectura de gesti´on de redes SNMPv3 . . . . . . . . . . 18 2.3.2 Comunicaci´on con el AgenteMD . . . . . . . . . . . . . . . . 20 3 Desarrollo Tecnol´ogico I: Visualizaci´on 23 3.1 AccesoalSistema............................ 23 i ii ´ INDICE GENERAL 3.2 GestorSNMP.............................. 25 3.3 Visualizaci´on .............................. 27 3.3.1 Visualizaci´on datos CE . . . . . . . . . . . . . . . . . . . . . 27 3.3.2 Visualizaci´on datos MDs . . . . . . . . . . . . . . . . . . . . 30 3.3.3 Visualizaci´on Gr´afica Hist´orico de datos . . . . . . . . . . . 31 4 Desarrollo Tecnol´ogico II: Gesti´on de Alarmas 35 4.1 Gestor de Alarmas con SNMP . . . . . . . . . . . . . . . . . . . . . 35 4.2 Gesti´ondeAlarmas........................... 37 5 Evaluaci´on del Sistema 45 5.1 Objetivo de la evaluaci´on . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2 Metodolog´ıa............................... 45 5.3 Resultados................................ 47 6 Conclusiones y L´ıneas Futuras 51 6.1 Conclusiones............................... 51 6.2 L´ıneasfuturas.............................. 53 Bibliograf´ıa 55 A Informaci´on Framework Struts2 57 A.1 Arquitectura Struts2 . . . . . . . . . . . . . . . . . . . . . . . . . . 57 A.2 Caracter´ısticas Struts2 . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.3 Struts2vsStruts1............................ 59 B Descripci´on detallada objetos MIB MD 65 ´ INDICE GENERAL iii B.1 Grupo ComputeEngineControlInfo . . . . . . . . . . . . . . . . . . 65 B.2 Grupo MedicalDeviceInfo . . . . . . . . . . . . . . . . . . . . . . . 68 B.2.1 MedicalDeviceControlTable . . . . . . . . . . . . . . . . . . 68 B.2.2 MedicalDeviceDataTable . . . . . . . . . . . . . . . . . . . . 69 B.2.3 MedicalDeviceStateTable . . . . . . . . . . . . . . . . . . . . 70 B.2.4 SpecificErrorsTable . . . . . . . . . . . . . . . . . . . . . . . 71 B.3 GrupoAlarmTable ........................... 72 B.4 GrupoEventTables........................... 74 B.4.1 ConfigurationEventTable . . . . . . . . . . . . . . . . . . . . 74 B.4.2 LogTable ............................ 75 B.5 GrupoManagerTable.......................... 76 B.6 Definici´on de los Traps . . . . . . . . . . . . . . . . . . . . . . . . . 77 C Estructura de la aplicaci´on 79 C.1 CarpetaGestor ............................. 80 D Gu´ıa de Instalaci´on 83 D.1 Preparar el entorno Java . . . . . . . . . . . . . . . . . . . . . . . . 83 D.2 Instalaci´on de MySQL . . . . . . . . . . . . . . . . . . . . . . . . . 84 D.2.1 Tablauser............................ 84 D.2.2 Tabla user computeengine . . . . . . . . . . . . . . . . . . . 85 D.2.3 Tabla computeEngine . . . . . . . . . . . . . . . . . . . . . . 85 D.2.4 Tablatraps ........................... 86 D.3 GestorSNMPTrap........................... 86 x´ INDICE DE FIGURAS G.1 Diagrama de Gantt del Proyecto Fin de Carrera . . . . . . . . . . . 112 ´ Indice de tablas 3.1 Comparaci´on del tiempo y el tr´afico enviados seg´un el n´umero de objetospedidos ............................. 26 5.1 Respuesta a algunas preguntas de la evaluaci´on general . . . . . . . 49 xiii Cap´ıtulo 1 Introducci´on y Objetivos 1.1 Introducci´on Actualmente vivimos en una sociedad con un progresivo aumento de la esperanza de vida de su poblaci´on. De manera que, al aumentar el n´umero de personas con edad superior a 60 a˜nos, tambi´en lo hace el n´umero de pacientes cr´onicos que requieren atenci´on sanitaria peri´odica. Estas revisiones peri´odicas repercuten en los gastos en materiales m´edicos y en los desbordamientos en los centros de salud impulsando la necesidad de dise˜nar y desarrollar nuevos servicios de telemedicina que disminuyan los gastos y mejoren la calidad de vida de estos pacientes. Dentro de la telemedicina, el desarrollo de sistemas de telemonitorizaci´on es, a dia de hoy, un ambito de gran inter´es ya que permite al personal sanitario realizar el seguimiento de los pacientes sin necesidad de que ´estos vayan a los centros de salud. Desde el punto de vista sanitario, se evita, en cierta medida, los desbordamientos que los pacientes cr´onicos ocasionan: se reducen listas de espera, se disminuye el gasto sanitario que conllevan y se facilita la accesibilidad al hist´orico de datos. Desde el punto de vista del paciente, no requiere desplazamientos ya que el control se realiza desde el hogar de los pacientes e implica un mayor control de su enfermedad debido a que las mediciones se realizan con mayor frecuencia, lo que se traduce en un aumento en su calidad de vida. 1 21.1. Introducci´on En la figura 1.1 se muestra un esquema de un sistema general de telemonitorizaci´on de pacientes. Como se puede observar, este se compone de diferentes entidades: 1. El Hogar del Paciente, donde se encuentra el paciente cr´onico, los dispositivos m´edicos y el CE (Compute Engine). Un CE es un dispositivo concentrador de datos utilizado en casa de los pacientes para recoger la informaci´on de los MDs (Medical Devices) y enviarlos posteriormente al centro correspondiente. 2. El Centro Remoto, lugar donde se almacenaran los datos enviados por el CE y donde se encuentra el personal m´edico (gestor cl´ınico) encargado de controlar la evoluci´on de los datos cl´ınicos, es decir, las medidas que realiza el paciente desde su hogar, para detectar posibles cambios an´omalos en los mismos. Hogar del Paciente Dispositivos Médicos Compute Engine Centro Remoto Gestor Técnico Monitoring Server Gestor Clínico Figura 1.1: Esquema de un Sistema General de Telemonitorizaci´on de pacientes. Por otro lado, tan importante es recoger y transferir los datos cl´ınicos como asegurarse de que los datos se adquieran y env´ıen correctamente. La gesti´on t´ecnica es, por tanto, un ´ambito de gran inter´es en este tipo de escenarios. Una soluci´on interesante para abordar esta problem´atica la encontramos en (1) (2). Esta soluci´on se basa en la implementaci´on de un agente SNMP(Simple Network Management Protocol) en casa del paciente el cual env´ıa a un centro remoto los datos recogidos acerca del funcionamiento del CE y los MDs. Adem´as de ser una de las pocas soluciones que a d´ıa de hoy abordan esta problem´atica, la soluci´on propuesta Cap´ıtulo 1. Introducci´on y Objetivos 3 permite proporcionar seguridad y eficiencia en la transferencia de informaci´on al hacer uso de la arquitectura de gesti´on de redes SNMP. A pesar de que SNMP es un protocolo simple, las herramientas de gesti´on que existen en la actualidad no son sencillas de manejar y precisan que el gestor externo tenga conocimientos del funcionamiento de esta arquitectura. Por ello, y puesto que la gesti´on de estos escenarios podr´ıa ser de inter´es del personal m´edico, surge la necesidad de implementar una interfaz amigable que permita el control de los datos recibidos sin necesidad de conocer el protocolo. Como soluci´on a este problema, este proyecto fin de carrera implementa una extensi´on a la soluci´on presentada en (2) proponiendo el dise˜no y desarrollo de una aplicaci´on Web con un gestor SNMP versi´on 3 integrado que permita la gesti´on t´ecnica de los datos enviados por el agente. De esta forma, el gestor SNMP integrado en la aplicaci´on establecer´a comunicaciones SNMP con el agente instalado en casa del paciente permitiendo que tanto la visualizaci´on de estos datos como las actividades de gesti´on que ´este permite se realicen a trav´es de un interfaz amigable y facil de utilizar. 1.2 Estado del arte SNMP es una arquitectura de gesti´on de redes, para la gesti´on de redes TCP/IP (implementada por la mayoria de fabricantes) que garantiza seguridad y eficiencia en las comunicaciones. Por ello, existen actualmente numerosas herramientas (gestores SNMP) que permiten la comunicaci´on con agentes de la arquitectura y por tanto la gesti´on de dispositivos y redes mediante la misma. De manera general, estas herramientas que permiten el acceso a diferentes agentes y por tanto visualizaci´on de las MIBs (Management Information Base) que implementan se denominan MIB-Browser. Uno de los m´as populares es el de MG-Soft cuyo interfaz se muestra en la figura 1.2. Est´a aplicaci´on de MG-Soft requiere instalaci´on y permite visualizar la jerarqu´ıa de diferentes MIBs en forma de 41.2. Estado del arte ´arbol con informaci´on adicional sobre cada nodo. El primer paso para utilizar esta herramienta es conectarse al agente al que se quiera preguntar la informaci´on. Para ello, es necesario conocer la direcci´on IP del dispositivo y el tipo de autenticaci´on que requiere. Una vez conectado al dispositivo, se podr´a pedir o manipular toda la informaci´on que se desee al mismo tiempo que se recibir´an mensajes as´ıncronos que sean enviados desde el dispositivo. Para pedir o manipular esa informaci´on hay que conocer los mensajes que se pueden enviar y c´omo est´a llegando la informaci´on pedida para poder interpretarla correctamente. En la parte izquierda de la figura 1.2, se observa una MIB en forma de ´arbol, tal y como la muestra MG-Soft. En la parte derecha, se observa el formato en que MG-Soft devuelve la informaci´on pedida. Figura 1.2: Vistas del programa MG-Soft. Existen otras herramientas como CACTI que permiten de forma m´as din´amica y sencilla la gesti´on de redes mediante SNMP. CACTI hace uso de herramientas RRDTools (Round Robin Database Tool) para recoger y almacenar los datos gestionados de manera peri´odica y as´ı ofrecer un hist´orico de la informaci´on gestionada que puede mostrarse de forma gr´afica. Estos gr´aficos pueden ser configurados por el usuario. Los dispositivos a telemonitorizar tambi´en necesitan ser a˜nadidos as´ı como el gestor tiene que autenticarse al pedir informaci´on sobre los mismos. Estas herramientas son ´utiles para el manejo de la informaci´on recibida mediante SNMP pero requieren conocimientos sobre el mismo. Para el caso de Cap´ıtulo 1. Introducci´on y Objetivos 5 telemonitorizaci´on domiciliaria, se necesita crear una interfaz que se pueda manejar de manera sencilla por cualquier persona que no tenga un perfil t´ecnico. Esto facilita que, en un momento dado, un m´edico pueda acceder a conocer datos t´ecnicos de los dispositivos sin conocer c´omo se organizan en una estructura de MIB o qu´e mensajes deben enviarse para visualizar los datos. Por este motivo, para dar mayor flexibilidad a la aplicaci´on, como se demuestra en (3), en este proyecto fin de carrera se ha desarrollado una aplicaci´on web que ayude a la visualizaci´on y gestion de los datos disponibles en el agente de telemonitorizaci´on propuesto en (2). Con esta aplicaci´on, cualquier gestor t´ecnico ser´a capaz de interpretar los datos y gestionar las alarmas que considere oportunas desde cualquier dispositivo con conexi´on a Internet y sin necesidad de instalar ning´un software ni adquirir conocimientos adicionales. 1.3 Propuesta En este proyecto se propone el desarrollo de una aplicaci´on Web integrada con un gestor SNMPv3 para la gesti´on de informaci´on t´ecnica en escenarios de telemonitorizaci´on domiciliaria. De esta forma se permite el acceso a la gesti´on remota desde cualquier dispositivo con acceso a Internet y se evita la instalaci´on de cualquier herramienta software adicional. Un esquema de la aplicaci´on se muestra en la figura 1.3, donde se puede observar como el gestor SNMP Web se puede conectar simult´aneamente a varios agentes para obtener informaci´on sobre los mismos o los dispositivos m´edicos asociados. Como se observa en la figura, esta aplicaci´on tiene dos partes distinguidas. Por un lado, la aplicaci´on integra un gestor que se encarga de la comunicaci´on con el agente por medio del protocolo SNMP versi´on 3. De esta forma, recibe los datos recogidos por los dispositivos de manera segura y eficiente. Adem´as, esta parte tambi´en ser´a la encargada de enviar los mensajes necesarios para configurar nuevas alarmas o recoger los mensajes as´ıncronos enviados por el agente. 61.3. Propuesta Comunicación SNMPv3 Compute Engine Compute Engine Compute Engine Gestor Técnico Gestor SNMP Web DB Figura 1.3: Esquema General de la Arquitectura de la Aplicaci´on de Gesti´on Propuesta. Concretamente, el gestor propuesto va a adaptarse al agente desarrollado en (1). Este agente implementa la MIB MD (MIB Medical Devices). Esta MIB permite, adem´as de gestionar informaci´on t´ecnica de los dispositivos m´edicos que est´an conectados a ´el, gestionar datos del CE, as´ı como definir y configurar alarmas y eventos. Por otro lado, se propone desarrollar una aplicaci´on Web que proporcione un interfaz gr´afico amigable e intuitivo para el gestor y que facilite, por lo tanto, la configuraci´on de tablas SNMP y el acceso a la visualizaci´on de resultados. As´ı, a trav´es de la aplicaci´on Web se proporciona una gesti´on transparente a la utilizaci´on de la arquitectura SNMP con los beneficios en la configuraci´on que ello conlleva. A trav´es del gestor Web se podr´a acceder de forma sencilla a la informaci´on relativa al funcionamiento de un dispositivo m´edico que un paciente tiene en su casa, as´ı como a la informaci´on propia del dispositivo concentrador de datos. Puesto que estos agentes desarrollados van a permitir la configuraci´on de alarmas (relativas al funcionamiento de los dispositivos que ´este controla) y posterior env´ıo de mensajes as´ıncronos enviados por un agente al gestor, la aplicaci´on propuesta incorpora adem´as herramientas para la captura y visualizaci´on de dichos mensajes as´ı como para recoger y registrar las incidencias t´ecnicas comunicadas por cada uno de los dispositivos. Cap´ıtulo 2. Arquitectura del Sistema 13 Por ´ultimo, en la figura 2.2, se muestran las comunicaciones que establecen los dos bloques del sistema. El bloque del gestor SNMP se comunica con el agente mediante mensajes SNMP que se explicar´an con m´as detalle en los pr´oximos apartados mientras que el de la aplicaci´on Web mantiene la comunicaci´on con el navegador Web mediante peticiones HTTP. Communication SNMPv3 Request (Set, Get, GetBulk) Response Trap HttpRequest HttpResponse Compute Engine Gestor Web SNMP Gestor Técnico Figura 2.2: Comunicaciones establecidas en los distintos bloques. 2.2 Estructura Aplicaci´on Web Una aplicaci´on Web es una aplicaci´on a la que se puede acceder a trav´es de Internet mediante un navegador. Esta aplicaci´on puede ser utilizada por miles de usuarios pero s´olo est´a en un servidor, lo que facilita el mantenimiento y su actualizaci´on, permitiendo ver los cambios a todos los usuarios instant´aneamente al mismo tiempo que no requiere instalar ning´un programa para su visualizaci´on. Para el desarrollo de la aplicaci´on Web, se ha seleccionado un entorno Java con la utilizaci´on de Servlets y p´aginas JSP (Java Server Pages) y basado en la arquitectura MVC (Model View Controler). Se ha escogido Java por ser una tecnolog´ıa Web vers´atil y eficiente, con multitud de herramientas OpenSource para satisfacer todas las necesidades y compatibilidad con JavaScript y AJAX. Adem´as, para su implementaci´on se han seleccionado los Frameworks Struts2, Tiles e Hibernate y se utiliza el servidor Apache Tomcat 6.0 y una base de datos MySQL 5.0. 14 2.2. Estructura Aplicaci´on Web 2.2.1 Tecnolog´ıa Web y Framework Struts2 El patr´on Modelo Vista Controlador est´a dise˜nado para separar la l´ogica de negocio, los datos y la interfaz del usuario en tres partes. Esta separaci´on permite una gran interactividad con los usuarios, por lo que su uso es recomendable en aplicaciones Web. En la siguiente figura, se muestra el patr´on Modelo Vista Controlador implementado para una aplicaci´on Web. CONTROLADOR MODELOVISTA PETICIÓN RESPUESTA MVC APLICACIÓN DB Figura 2.3: Arquitectura Modelo Vista Controlador. Las tres partes en las que se divide este patr´on son: 1. Modelo: El Modelo es el responsable de acceder a la capa de almacenamiento de datos, manipularlos y definir la l´ogica de negocio. No tiene conocimiento espec´ıfico del Controlador o de la Vista, ni referencias a ellos. 2. Vista: La Vista representa la interfaz de usuario, obtiene los datos del Modelo y se los muestra al usuario. Se encarga de enviar la respuesta generada a partir de la petici´on que recibe el Controlador. Tiene que ser f´acil para interactuar ya que es la capa de la aplicaci´on que ve el usuario. La Vista tiene una referencia al Modelo y un registro de su Controlador asociado. 3. Controlador: El Controlador es el encargado de traducir las interacciones que el usuario realiza a trav´es de la Vista en peticiones que ser´an tratadas por el Modelo o por la Vista. Struts2 (4) es un Framework para el desarrollo de aplicaciones Web. Est´a basado en la arquitectura MVC obteniendo como resultado un Framework con Cap´ıtulo 2. Arquitectura del Sistema 15 todas las caracter´ısticas necesarias para facilitar el desarrollo de aplicaciones Web en Java con JSP (Java Server Page), Servlet y c´odigo b´asico Java. Su configuraci´on se realiza en un fichero llamado struts.xml. En este fichero, se indica la clase Action y los Interceptores que se tienen que ejecutar adem´as de la vista que se mostrar´a en funci´on del resultado obtenido. Por ´ultimo, para poder usarlo en nuestra aplicaci´on, hay que indicarlo en el fichero de configuraci´on de la aplicaci´on: web.xml. Algunas de las caracter´ısticas del Framework que llevaron a la elecci´on del mismo son las siguientes: uso de buenas pr´acticas, simplicidad de dise˜no, f´acil extensibilidad e integraci´on con otros componentes. Estas y otras ventajas se detallan en el Anexo A. Struts2 es la versi´on mejorada del Framework Struts1 cuyas mejoras, entre otras, son (se detallan en A.3): uso de cualquier clase Java como clase Action, no necesidad de seguridad en los Threads, elimina la dependencia con el Servlet o permite el testeo de los Actions. Aplicación Web Controlador ModeloVista Action Interceptor Session Filter Dispatcher HTTPS DB Gestor SNMP SNMP SNMP Trap JSP HTTPS Gestor Técnico Figura 2.4: Funcionamiento General Aplicaci´on Web. El esquema general de la aplicaci´on Web se muestra en la figura 2.4. El controlador est´a compuesto por el FilterDispatcher, los Interceptores y los Actions. El FilterDispatcher es un ServletFilter cuyo principal objetivo es interpretar todas las peticiones entrantes y determinar qu´e Action y qu´e Interceptores deber´ıan 16 2.2. Estructura Aplicaci´on Web ejecutarse. Los Interceptores son clases Java que se ejecutan siempre antes y despu´es del Action invocado. En nuestra aplicaci´on, las peticiones tienen que pasar por un Interceptor que comprueba si el usuario tiene una sesi´on abierta. Una vez ejecutados los Interceptores, la petici´on llega al Action correspondiente. La clase Action es una clase Java encargada de ejecutar la l´ogica de negocio y proporcionar un resultado seg´un los datos obtenidos. Durante la ejecuci´on del Action, ´este puede recurrir al modelo que contiene la base de datos. El resultado del Action indica la p´agina JSP (perteneciente a la vista) que se mostrar´a. Una p´agina JSP es una p´agina HTML con hojas de estilo CSS (Cascading Style Sheets) que permite integrar Java en ella para poder hacer din´amico su contenido. En el Anexo A se detalla el Framework. Adem´as de todas estas ventajas, Struts2 proporciona una librer´ıa de etiquetas, taglib, que facilita las tareas de validaci´on e internacionalizaci´on. Esta librer´ıa permite definir las variables en ficheros .properties para la implementaci´on de la aplicaci´on en varios idiomas. Para el acceso a la base de datos MySQL se ha seleccionado utilizar el Framework Hibernate (8). Hibernate se utiliza para el mapeo de los objetos relacionales de Java. Permite guardar/extraer los datos que utiliza una aplicaci´on directamente sobre la base de datos. Proporciona un Framework que mapea tablas de una base de datos en clases Java, copiando el contenido directamente sobre la clase. Tambi´en copia el contenido de una clase Java en la base de datos. En este caso, dependiendo de la definici´on de la clase, podr´ıa guardarse la informaci´on en una o varias tablas. 2.2.2 Dise˜no de las p´aginas En el dise˜no de p´aginas Web, entra un concepto muy importante llamado Usabilidad (5) (6). La usabilidad es la disciplina que estudia la forma de dise˜nar p´aginas Web para que los usuarios puedan interactuar con ellas de la forma m´as f´acil, c´omoda e intuitiva posible. Cap´ıtulo 2. Arquitectura del Sistema 17 Algunas de las principales reglas que se han tenido en cuenta para hacer esta aplicaci´on Web son: 1. Simple. Las vistas de la aplicaci´on Web est´an separadas por dos tipos de acciones que se pueden realizar en el gestor: la visualizaci´on de datos y la gesti´on de alarmas y eventos. La navegaci´on entre las distintas p´aginas se realiza de manera muy intuitiva. Cada hiperv´ınculo expresa con claridad a d´onde va dirigido. Adem´as, se incorpora Ayuda en todas las vistas. 2. Lenguaje com´un. Los textos est´an escritos en un lenguaje cercano al usuario, sin usar vocabulario t´ecnico. Son sencillos y claros de entender. 3. Legible. El texto tiene un tama˜no y un color adecuado. Adem´as est´a espaciado para que no resulte cargante para el usuario. 4. No scroll. Estudios han demostrado que muchos usuarios no se molestan en hacer scroll para descubrir el resto de la p´agina. Por este motivo, se han ajustado las p´aginas, en la medida de lo posible, para mostrar todo el contenido sin tener que utilizar la barra de desplazamiento horizontal. 5. Consistente. Las distintas zonas de navegaci´on y contenidos est´an aproximadamente en el mismo lugar en todas las vistas. En cuanto a herramientas que facilitan el dise˜no de las p´aginas, se ha utilizado Tiles (7). Tiles es un Framework que hace mucho m´as f´acil la creaci´on de las diferentes vistas de una aplicaci´on Web ya que separa las distintas partes de las vistas para que puedan ser reutilizadas tantas veces como se necesiten. La idea del Framework para el ejemplo concreto de nuestra aplicaci´on se muestra en la siguiente figura. Podemos observar que cada una de las vistas de nuestra p´agina se compone de Header, Menu, Body y Footer. Esta estructura se mantiene para todas las vista, variando ´unicamente el Body entre unas y otras. 18 2.3. Comunicaci´on SNMPv3 FOOTER MENU BODY HEADER Figura 2.5: Ejemplo separaci´on por Tiles en una de las vistas de la Aplicaci´on Web. 2.3 Comunicaci´on SNMPv3 SNMP es la arquitectura m´as popular para la gesti´on de redes TCP/IP y los dispositivos conectados a las mismas. Permite a los administradores un alto mantenimiento de la red, encontrar los problemas que puedan surgir en la misma y resolverlos. La versi´on 3 del protocolo es la m´as reciente e incorpora mejoras en cuanto a seguridad con respecto a las versiones anteriores. Con esta versi´on, se asegura la integridad del mensaje mediante el cifrado del mismo. Para conseguirlo, SNMPv3 define dos bloques: USM (10) (User-based Security Model) y VACM (11) (Viewbased Access Control Model). USM define la estrutura de usuarios e informaci´on necesaria para el cifrado y autenticaci´on. Esto se realiza proporcionando claves secretas, para la autenticaci´on mediante los protocolos MD5 o SHA y para el cifrado mediante los algoritmos DES-CBC o AES-128. VACM describe los privilegios que tiene cada usuario USM y se encarga de comprobar si el usuario tiene permitido el acceso a la lectura/escritura de determinados objetos. 2.3.1 Arquitectura de gesti´on de redes SNMPv3 Para la utilizaci´on del protocolo SNMP se necesitan dos componentes: el agente y el gestor. El agente es un programa instalado en un dispositivo que va a recoger informaci´on ´util para permitir su gesti´on. El gestor es una aplicaci´on encargada de Cap´ıtulo 2. Arquitectura del Sistema 19 interrogar a un agente para pedir informaci´on del mismo as´ı como de modificarla seg´un sus necesidades. La informaci´on que contiene el agente se almacena en unas bases de datos denominadas MIBs. Una MIB est´a organizada en forma de ´arbol y presenta de manera jer´arquica los objetos y valores que pueden ser gestionados por el agente. Est´a definida a trav´es del lenguaje SMI (12) (Structure of management Information). Cada uno de los objetos est´a identificado por una secuencia de n´umeros separados por puntos, cada uno de los cuales se corresponde a un salto de nivel en el ´arbol que compone la MIB. Esta secuencia de n´umeros es denominada OID (Object Identifier). Se distinguen dos tipos de MIBs: p´ublicas y privadas. Las p´ublicas son aquellas que est´an definidas mediante est´andares y se caracterizan por proporcionar informaci´on general de cualquier sistema de comunicaciones. La MIB p´ublica m´as conocida es la MIB-II (originalmente definida en RFC1213 (9)). Esta MIB esta soportada por todos los agentes SNMP y contiene informaci´on sobre el dispositivo telemonitorizado como puede ser su tr´afico o el uso de su CPU pero no contiene informaci´on a alto nivel como puede ser su sistema operativo. Las MIB privadas son aquellas definidas por los fabricantes para gestionar sus dispositivos. Con respecto a la comunicaci´on entre el agente y el gestor, los tipos de mensajes SNMP son los siguientes: •GET: petici´on por el valor espec´ıfico de un objeto en la MIB del agente. •GETNEXT: petici´on por el valor del siguiente objeto en la MIB del agente. •GETBULK: petici´on por una serie de valores de objetos que son consecutivos en la MIB. El n´umero de valores que se pide viene determinado por max-repetitions. Tambi´en se pueden pedir variables sin repetir mediante el campo non-repeaters. Esta petici´on disminuye considerablemente el n´umero de mensajes que se tienen que intercambiar un gestor y un agente para la obtenci´on de los mismos datos. 20 2.3. Comunicaci´on SNMPv3 •SET: utilizado para cambiar un valor de un objeto en la MIB del agente, en el caso de que el objeto tenga habilitada la lectura y escritura de su valor. Para todos estos mensajes, el agente responder´a con un mensaje RESPONSE indicando el valor por el que se ha preguntado o si ha habido alg´un tipo de error. Por otro lado, un agente SNMP tambi´en puede mandar un mensaje sin ser por petici´on del gestor si se ha producido alg´un suceso excepcional. En ese caso, el agente mandara un mensaje de tipo TRAP con las variables que se hayan definido para ese tipo de evento. 2.3.2 Comunicaci´on con el AgenteMD La MIB situada en el AgenteMD est´a compuesta por 5 grupos separados seg´un la informaci´on que contienen (la informaci´on est´a en Anexo B): 1. ComputeEngineControlInfo. Contiene informaci´on relacionada con los recursos propios del CE. 2. MedicalDeviceInfo. Este grupo est´a compuesto por cuatro tablas: (a) MedicalDeviceControlTable. Registra la informaci´on acerca de caracter´ısticas t´ecnicas de los MDs: fabricante, modelo, etc. (b) MedicalDeviceDataTable. Contiene un hist´orico de la informaci´on de los MDs que var´ıa en el tiempo: nivel de bater´ıa, horas de bater´ıa, etc. (c) MedicalDeviceStateTable. Almacena un hist´orico de la informaci´on correspondiente a los cambios de estado de los MDs: operativo, desconectado, etc. (d) SpecificErrosTable. Registra un hist´orico de la informaci´on correspondiente a los errores recibidos en el funcionamiento de los MDs. 3. AlarmTable. Esta tabla permite configurar alarmas relativas al funcionamien- to de los dispositivos MDs y del CE. Cap´ıtulo 2. Arquitectura del Sistema 21 4. EventTable. Est´a compuesto por dos tablas: (a) ConfigEventTable. En esta tabla se configuran los eventos que se realizar´an al activarse una alarma. (b) LogTable. En esta tabla encontramos los Logs registrados al activarse alguna alarma. 5. ManagerTable. Contiene la informaci´on correspondiente a los gestores asociados al agente. SNMPv3 Trap Hogar del Paciente Dispositivos Médicos Compute Engine Aplicación Web Controlador ModeloVista Action Interceptor Session Filter Dispatcher DB Gestor SNMP SNMP SNMP Trap JSP Figura 2.6: Funcionamiento General Gestor SNMP. En la figura 2.6, podemos observar el esquema general de las comunicaciones de nuestro gestor con el AgenteMD. En concreto, el gestor SNMP Web se comunica con el agente MD mediante los mensajes GET cuando son pocos los datos a pedir o se requieren objetos aislados de diferentes tablas o mensajes GETBULK cuando se desean pedir varios objetos consecutivos. Cap´ıtulo 3. Desarrollo Tecnol´ogico I: Visualizaci´on 29 (ver figura 3.9). El resto de informaci´on que se visualiza en esta vista son todos los datos contenidos en el grupo ComputeEngineControlInfo. En este grupo, se almacena informaci´on de los recursos propios del CE, como son la CPU o el ancho de banda. Los elementos de la tabla que contienen estos recursos, se muestran mediante barras de colores en funci´on de su saturaci´on para alertar visualmente cuando un recurso podr´ıa estar m´as saturado de lo deseado. Los colores van desde el verde, que representa una carga m´ınima, pasando por el amarillo y el naranja hasta llegar al rojo que representa una carga cr´ıtica. En la parte inferior de la p´agina, se observan cuatro botones. El primero de ellos es para volver a la ´ultima p´agina visitada. Este bot´on se mantiene en todas las vistas aproximadamente en el mismo lugar. El bot´on Actualizar sirve para pedir una actualizaci´on tanto de los datos t´ecnicos como de los posibles cambios de estados de todos los MDs asociados. Config.Alarma permite configurar una alarma asociada al CE. Este punto se explicar´a en el pr´oximo cap´ıtulo. Y, por ´ultimo, el bot´on Ver Dispositivos conduce a la p´agina que se ve en la figura 3.8. medicalDeviceDataTable medicalDeviceDataEntry idMDData idCapture supplyType remainderBattery errors ownerMD dateTimeData batteryLevel medicalDeviceStateTable medicalDeviceStateEntry idMDState idState deviceState dateTimeState Figura 3.8: Vista del estado actual de los MDs asociados al CE. 30 3.3. Visualizaci´on 3.3.2 Visualizaci´on datos MDs En la vista de la figura 3.8, se puede observar todos los MDs asociados al CE con la ´ultima informaci´on b´asica recibida sobre ellos. Esta informaci´on contiene las horas de bater´ıa que le quedan, el estado en el que se encuentra y si ha habido errores en la ´ultima captura. El objetivo de esta vista es mostrar la informaci´on m´as relevante de todos los dispositivos de manera mucho m´as efectiva ya que solo se piden las ´ultimas entradas de los objetos de la MIB MD marcados en la figura en lugar de tener que recorrer toda la tabla. Una de las ventajas que aporta esta vista es poder comparar gr´aficamente los dispostivos entre s´ı y ver si alguno de ellos requiere m´as prioridad. Adem´as, esta vista incluye dos botones por cada MD. El primero de ellos es Info. General que muestra la informaci´on est´atica asociada al dispositivo contenida en la tabla medicalDevicesControlTable. Al pulsar sobre el bot´on Datos t´ecnicos se accede a visualizar los datos t´ecnicos de la ´ultima captura asociada al MD seleccionado tal y como se muestra en la figura 3.9. medicalDeviceDataTable medicalDeviceDataEntry idMDData idCapture supplyType remainderBattery errors ownerMD dateTimeData batteryLevel medicalDeviceStateTable medicalDeviceStateEntry idMDState idState deviceState dateTimeState specificErrorsTable specificErrorsEntry idMDError idError deviceWorking sensorConnection sensorJamming signalFailures sensorWorking Figura 3.9: Visualizaci´on datos asociados al MD. Cap´ıtulo 3. Desarrollo Tecnol´ogico I: Visualizaci´on 31 En la figura 3.9, vemos la informaci´on correspondiente a la ´ultima captura de datos t´ecnicos recibida y el estado actual del MD seleccionado. En la parte de la izquierda se muestra el tipo de MD que estamos visualizando. En la parte central, se muestran los datos que contiene la entrada m´as actual en las tablas medicalDevicesDataTable,medicalDevicesStateTable y el objeto de la tabla SpecificErrorsTable que ha producido el error en caso de haber. En la parte de la derecha, hay un conjunto de checkboxs para realizar una de las siguientes acciones: visualizar el hist´orico de datos en forma de tabla, visualizar el hist´orico de datos de forma gr´afica o configurar una alarma asociada a ese MD y un elemento concreto. Una vez seleccionados los checkboxs correspondientes a la acci´on que se desea realizar, se pulsa el bot´on Go! situado en la parte inferior del body. Esta vista tambi´en cuenta con otro bot´on, Info. General, que muestra la informaci´on est´atica asociada al MD que tambi´en es accesible desde otras p´aginas. Para acceder a la informaci´on que se est´a mostrando en la vista, utilizando otro software, habr´ıa que recorrer tres tablas completas y se obtendr´ıa la informaci´on de una forma complicada de interpretar. Al utilizar esta vista para poder ver la informaci´on, se muestra s´olo la informaci´on correspondiente a la ´ultima captura de los datos t´ecnicos, con el motivo del error correspondiente registrado en la tabla de error en caso de haber y el estado actual del MD y se tiene libertad para visualizar el hist´orico de datos como se desee o de realizar otras acciones sobre los datos. 3.3.3 Visualizaci´on Gr´afica Hist´orico de datos En la figura 3.10, se muestra un ejemplo de la visualizaci´on del hist´orico de datos t´ecnicos y estados del MD en forma de tabla. La estructura del body se divide en dos tablas, la tabla situada arriba corresponde a las capturas de datos t´ecnicos y la situada abajo corresponde a los cambios de estado del MD. El resto de columnas, depende del n´umero de elementos que se hayan seleccionado en la vista anterior. Esta vista permite ver la evoluci´on de los datos a trav´es del tiempo de manera visual y f´acil de entender. 32 3.3. Visualizaci´on Figura 3.10: Visualizaci´on del hist´orico de datos t´ecnicos y estados del MD en forma de tabla. En la figura 3.11, se muestra un ejemplo de la visualizaci´on del hist´orico de datos t´ecnicos y estados del MD de forma gr´afica. Para ello se ha utilizado la librer´ıa JFreeChart (15). Esta librer´ıa permite mostrar los datos mediante diversos gr´aficos. Seg´un los elementos seleccionados, los gr´aficos mostrados variar´an. Si s´olo se selecciona un ´unico elemento, se mostrar´a un gr´afico total con todos los datos y gr´aficos diarios. Si se seleccionan dos o m´as elementos, todos los gr´aficos ser´an totales. En concreto, se han seleccionado tres tipos de gr´aficos. Para los elementos cuyos valores son num´ericos (horas de bater´ıa y porcentaje de bater´ıa), se ha seleccionado un gr´afico XYPlot que muestra la evoluci´on de los valores en funci´on del tiempo. Para los datos cuyos valores son conjuntos de caracteres, se utiliza un gr´afico de tipo Pie para los datos totales que permite visualizar r´apidamente el porcentaje de tiempo que el objeto ha mantenido cada valor y un diagrama de barras para la visualizaci´on de datos diarios que permite visualizar el porcentaje de tiempo que el objeto ha mantenido cada valor diariamente. Se ha a˜nadido la opci´on de ver los datos gr´aficamente porque los gr´aficos son m´as amenos para seguir que las tablas de datos. Adem´as, el uso de gr´aficos para representar los datos facilita la interpretaci´on de la informaci´on de manera m´as r´apida y eficiente. Por ejemplo, mirando el gr´afico de Errores, se puede ver instantaneamente si se est´an Cap´ıtulo 3. Desarrollo Tecnol´ogico I: Visualizaci´on 33 produciendo muchos errores y los motivos de los mismos; o, mirando el gr´afico Horas de bater´ıa se puede ver cuando el dispositivo est´a cerca de quedarse sin bater´ıa. Figura 3.11: Visualizaci´on gr´afica del hist´orico de datos t´ecnicos y estados del MD. Cap´ıtulo 4 Desarrollo Tecnol´ogico II: Gesti´on de Alarmas 4.1 Gestor de Alarmas con SNMP El agente MD permite la configuraci´on de alarmas y eventos sobre los objetos de la MIB relativos al funcionamiento del CE y los MDs a trav´es de la tabla alarmTable yconfigurationEventTable. Para realizar la configuraci´on de alarmas, se necesita a˜nadir entradas en la tabla de alarmas (y en la tabla de eventos, si fuese necesario) con los par´ametros que se quieren controlar. alarmTable alarmEntry idDevice idAlarm oidVariable alarmValue idEventUp idEventDown thresholdUp idEventAlarmValue ownerAlarm statusAlarm thresholdDown (a) Tabla de Alarmas de la MIB MD. configurationEventTable configurationEventEntry idEvent eventType trapType statusEvent ownerEvent eventTables (b) Tabla de Eventos de la MIB MD. Figura 4.1: Tablas de configuraci´on de alarmas y eventos. 35 36 4.1. Gestor de Alarmas con SNMP La tabla de alarmas se muestra en la figura 4.1(a). Para crear una entrada en dicha tabla, hay que seguir la filosof´ıa RMON, es decir, hay que enviar una petici´on al agenteMD con la creaci´on de la entrada. Este procedimiento se puede ver en la figura 4.2. Una vez creada la entrada, el resto de objetos, deben ser rellenados por el gestor mediante mensajes de tipo SET. Al terminar,la alarma se activa. Gestor Agente SET(statusAlarm, 2) RESPONSE SET RESPONSE SET RESPONSE SET(statusAlarm, 1) RESPONSE 2. Si es correcto, el agente MD rellena idDevice e idCaptura ... 1. Creación entrada (statusAlarm = 2) 3. Se mandan mensajes SET para rellerar el resto de campos 4. El agente MD responde indicando si todo ha ido bien. 5. Activación de la entrada (statusAlarm = 1) 6. Si todo es correcto, la entrada será válida Figura 4.2: Comunicaci´on Gestor-Agente para a˜nadir Alarma. La tabla de eventos se muestra en la figura 4.1(b). Para crear una entrada en esta tabla, hay que seguir el mismo procedimiento que para la tabla de alarmas. El primero paso a realizar es enviar una petici´on para la creaci´on de la entrada, poniendo el valor de statusEvent a 2(create). El objeto eventType indica el tipo de evento que se lanzar´a cuando alguna de las alarmas con este evento asociado sea activada. Los valores que puede tomar son: mandar un trap, crear una entrada en la tabla de logs o ambas. El objeto trapType contiene el tipo de Trap que se enviar´a en caso de que el tipo de evento elegido sea enviar un trap. Los posibles valores son: SystemOvercharged, WrongDeviceWorking, SpecificError, NewMD y Warning. Una vez rellenados todos los campos de la entrada en la tabla, hay que activarla. Cap´ıtulo 4. Desarrollo Tecnol´ogico II: Gesti´on de Alarmas 37 Estas dos son las tablas que hay que configurar para poder gestionar las alarmas. Al igual que en el cap´ıtulo anterior, el gestor SNMP enviar´a un conjunto de mensajes GET/GETBULK para visualizar la tabla de logs, alarmas, etc. Uno de los tipos de eventos que se puede configurar es el env´ıo de traps. Los traps son mensajes as´ıncronos que el agenteMD va a enviar al gestor cuando se active alguna alarma cuyo evento sea este o el agenteMD tenga programado el env´ıo del mismo. Estos mensajes se env´ıan al gestor por el puerto 162. Para capturarlos, el gestor SNMP se mantiene escuchando en ese puerto. Cuando llega un trap, el gestor SNMP extrae la informaci´on necesaria y la almacena en una base de datos. La tabla que hay en esta base de datos registra la direcci´on IP del agenteMD que ha enviado el trap, el identificador del dispositivo asociado, el identificador de la captura que ha hecho activar la alarma, la fecha en la que se ha activado y el tipo de trap que se ha enviado. 4.2 Gesti´on de Alarmas Para gestionar y visualizar las alarmas y eventos de la MIB, hay que acceder a la pesta˜na Alarmas. Esta pesta˜na da lugar a la vista de la figura 4.3. En ella, aparecen cuatro figuras: ´ Ultimos Eventos,Visualizar tabla de logs,Visualizar Alarmas Configuradas yConfigurar Alarmas. Con esta organizaci´on, quedan claramente separados los sucesos recibidos (traps recogidos por un lado y logs registrados por el otro) de la visualizaci´on y configuraci´on de las alarmas y eventos que los lanzan. Pulsando sobre el bot´on de Configurar Alarmas, se llega a la figura 4.4. Desde esta p´agina se configuran las alarmas. Esta p´agina es una parte muy importante de la aplicaci´on ya que permite al gestor la configuraci´on de las alarmas que quiera de manera transparente e intuitiva, separando los distintos eventos por grupos y utilizando herramientas para deshabilitar las opciones que no ser´ıan necesarias. Es accesible desde la p´agina de la figura anterior, desde los datos del CE o desde los datos de alguno de los MDs asociados ya que una alarma puede estar asociada a cualquiera de los MDs o al propio CE. En la parte superior del cuerpo 38 4.2. Gesti´on de Alarmas Figura 4.3: Vista de la pesta˜na Alarmas. de la p´agina, hay dos desplegables, Dispositivo yRecurso.Dispositivo contiene todos los tipos de MDs asociados y el CE y Recurso contiene todos los OIDs a los que se les puede asociar una alarma, como por ejemplo, uso del CPU, estado del dispositivo, etc. El desplegable Dispositivo vendr´a con el valor preseleccionado si se accede a la vista desde los datos del CE o del MD mientras que Recurso solo vendr´a preseleccionado si se accede desde los datos del MD (el recurso se selecciona mediante los checkbox que se han visto en la figura 3.9 del cap´ıtulo anterior). Figura 4.4: Vista Configurar Alarmas. Cap´ıtulo 5 Evaluaci´on del Sistema 5.1 Objetivo de la evaluaci´on Uno de los objetivos de este proyecto es facilitar la visualizaci´on de los datos t´ecnicos de los dispositivos que permitir´an la telemonitorizaci´on de los pacientes. Como se ha visto anteriormente, la recolecci´on de esos datos se hace mediante un agente SNMP instalado en un CE que los guarda en una MIB. Esta MIB es dif´ıcil de interpretar con los programas existentes en la actualidad sin tener conocimientos sobre el tema. Es importante asegurarse de que cualquier usuario sea capaz de utilizar la herramienta y conseguir visualizar/configurar lo que necesite sin tener ning´un conocimiento de la tecnolog´ıa que est´a implementando. Tambi´en es importante saber el grado de satisfacci´on del personal con el sistema, si lo encuentra ´util o si tienen sugerencias. Por estos motivos, y para recoger pruebas que ayuden a mejorar su desarrollo, se hace la evaluaci´on con pruebas reales. 5.2 Metodolog´ıa Esta evaluaci´on se ha dividido en dos fases para las que se han utilizado diferentes cuestionarios (Anexo F) que recogen las respuestas de los usuarios que han participado en este proceso de evaluaci´on. Estas fases son: 45 46 5.2. Metodolog´ıa •Fase I: Evaluaci´on Guiada. Este cuestionario se compone de 10 preguntas que piden al usuario realizar una serie de acciones, desde algo sencillo como ver los CEs asociados hasta algo m´as complicado como configurar una alarma. Viendo lo f´acil o dif´ıcil que distintos tipos de usuarios encuentran la aplicaci´on, nos da una idea de c´omo podr´ıa ser aceptada al ser implementada. Tambi´en nos permite conocer si la estructura de la aplicaci´on es la adecuada, es decir, si los distintos tipos de acciones que se pueden realizar sobre ella est´an separadas e indicadas correctamente o cu´ales son los puntos que no parecen estar tan claros. Para la realizaci´on de esta encuesta, el usuario est´a conectado a la aplicaci´on intentando realizar las consultas o gestiones que se le van pidiendo mientras se cronometra el tiempo empleado para cada una de ellas. •Fase II: Evaluaci´on General. Este cuestionario contiene 15 preguntas que se realizar´an despu´es de haber utilizado la aplicaci´on. Su finalidad es obtener m´as informaci´on acerca de la opini´on del usuario, especialmente qu´e les ha parecido la experiencia y qu´e podr´ıa ser mejorado. Es una encuesta muy importante tanto para valorar el estado actual de la p´agina como para ver fallos en su funcionamiento o recibir sugerencias e ideas sobre las partes de la aplicaci´on que podr´ıan ser cambiadas mejorando el uso por el usuario. Para la realizaci´on de la evaluaci´on, se han escogido personas de tres perfiles diferentes: •Perfil T´ecnico. La aplicaci´on est´a orientada al control de los datos t´ecnicos de los dispositivos m´edicos, por lo que, este perfil es obligatorio en la evaluaci´on. Los usuarios que gestionen est´a informaci´on deber´an tener este perfil. Esta evaluaci´on la han realizado dos hombres y una mujer de edades comprendidas entre 24 y 28 a˜nos. •Perfil Cl´ınico. En este momento, el proyecto est´a implementado para controlar los datos t´ecnicos de los dispositivos m´edicos pero se puede ampliar en un futuro para la gesti´on de los datos cl´ınicos. Por este motivo, es Cap´ıtulo 5. Evaluaci´on del Sistema 47 importante que personas con perfil cl´ınico puedan entender la aplicaci´on sin problemas y aportar ideas o mejoras que ayudar´an al dise˜no de la parte cl´ınica. Este grupo est´a compuesto por dos mujeres y un hombre de edades comprendidas entre 24 y 25 a˜nos. •Otros. Se ha realizado tambi´en la evaluaci´on sobre un grupo formado por personas pertenecientes a perfiles diferentes al t´ecnico o al cl´ınico para asegurar que cualquier tipo de usuario sin conocimientos ni t´ecnicos ni cl´ınicos pueda usar la aplicaci´on para el fin de la misma. Para este perfil, se han seleccionado tres personas, un hombre y dos mujeres con edades comprendidas entre los 45 y los 57 a˜nos. 5.3 Resultados En la primera fase, la evaluaci´on guiada, se ha ido pidiendo al usuario que realice una serie de acciones controlando el tiempo que ha tardado en conseguirlo. En la figura 5.1, se puede ver el tiempo medio que ha tardado cada uno de los perfiles en realizar cada una de las acciones que son las siguientes: 1. Acceder a la gesti´on de dispositivos. 2. Visualizar la informaci´on de un CE. 3. Decir el n´umero de dispositivos asociados y sus tipos. 4. Ver los ´ultimos datos t´ecnicos registrados. 5. Visualizar el hist´orico de los datos de forma gr´afica. 6. Configurar una alarma. 7. Acceder al registro de las alarmas configuradas. 8. Ver en detalle los datos de un evento asociado a una alarma. 9. Visualizar la tabla de logs. 10. Acceder a los ´ultimos eventos recibidos. 48 5.3. Resultados 200.0 Técnico Clínico 150 0 Clínico Otros 150 . 0 o (s) 100.0 Tiemp o 50.0 00 0 . 0 12345678910 Pregunta Figura 5.1: Tiempo medio empleado por perfiles en cada una de las preguntas de la evaluaci´on guiada. Cabe destacar que estos tiempos han sido controlados en la primera vez que los usuarios han utilizado el sistema. Como es de esperar, estos tiempo se ver´an reducidos notablemente conforme los usuarios aprendan d´onde mirar y c´omo utilizarlo debidamente. Las primeras cinco acciones se corresponden a visualizar los datos del CE o del MD (cap´ıtulo 3) y las siguientes a configurar alarmas o visualizar los datos provenientes de ellas. Es m´as que evidente que la acci´on m´as dif´ıcil para todos los perfiles ha sido la n´umero 6. En ella se ped´ıa que el usuario configurase una alarma mientras que en el resto s´olo se ped´ıa visualizar datos. En esta acci´on, s´olo el 44,4 % de los usuarios ha consultado la ayuda a pesar de no entender exactamente los datos que ten´ıan que introducir. El 22,2 % ha intentando configurar una alarma con menos datos de los necesarios mientras que el 33,3 % ha intentando rellenar todos los campos que aparec´ıan en la pantalla. La segunda acci´on que ha requerido m´as tiempo en ser realizada ha sido la 9 que corresponde a visualizar la tabla de logs. Dos de los tres miembros del perfil cl´ınico han comentado que desconoc´ıan el significado de la palabra log y, por lo tanto, no sab´ıan con qu´e asociarlo. Cap´ıtulo 5. Evaluaci´on del Sistema 49 Como conclusiones sobre este cuestionario, se ha observado que los enlaces realizados mediante im´agenes resultan m´as intuitivos que los que llevan alg´un texto o c´odigo y que la informaci´on contenida en Ayuda apenas es consultada. En la segunda fase, la evaluaci´on general, se ha dejado a los usuarios un formulario para rellenar con sus opiniones y sugerencias del sistema. Algunas de estas opiniones, se muestran en la siguiente tabla, indicando el porcentaje de usuarios que han contestado S´ I y el que ha contestado NO. El 100 % de los usuarios opina que la aplicaci´on es intuitiva y f´acil de manejar adem´as de no haber sufrido ning´un error durante la prueba anterior. El 11,11 % de los usuarios considera que el aviso que indica la llegada de nuevos eventos no es suficiente. Sin embargo, la mayor´ıa de los usuarios ha aportado ideas para mejorarlo: cambiar el tama˜no, color, a˜nadir efectos de sonido, etc. Un usuario ha comentado la posibilidad de incluir diferentes tipos de avisos seg´un la importancia del evento recibido. Pregunta S´ I NO ¿El sistema es f´acil de usar? 100 % 0 % ¿Es intuitivo? 100 % 0 % ¿Se est´an produciendo fallos en el funcionamiento del sistema? 0 % 100 % ¿La informaci´on proporcionada es suficiente para el seguimiento del correcto funcionamiento de los dispositivos? 100 % 0 % ¿Cree que el aviso de llegada de nuevos eventos es suficiente? 88,89 % 11,11 % ¿Aconsejar´ıa la adopci´on de un sistema de estas caracter´ısticas en un entorno de salud de forma permanente? 100 % 0 % Tabla 5.1: Respuesta a algunas preguntas de la evaluaci´on general Respecto a las dificultades encontradas, el 44,4 % de los usuarios no ha comentado ninguna mientras que el 66,6 % de los usuarios del perfil cl´ınico y el 33,3 % de otro perfil han encontrado dificultades para entender algunas palabras t´ecnicas. El 11,11 % de los usuarios ha confesado haber tenido dificultades a la hora de configurar alarmas. Cap´ıtulo 6 Conclusiones y L´ıneas Futuras 6.1 Conclusiones En este proyecto se ha implementado un gestor SNMPv3 con un interfaz Web para la gesti´on de dispositivos m´edicos en entornos de atenci´on domiciliaria. Para centralizar la informaci´on obtenida por los dispositivos, se utiliza el agente SNMP desarrollado en (1). El software disponible para pedir la informaci´on recogida mediante esta tecnolog´ıa requiere conocimientos sobre la misma siendo complicado de utilizar e interpretar. Por este motivo, se ha desarrollado un gestor Web propio que se encargue tanto de pedir los datos deseados, mostr´andolos de manera que sea f´acil de interpretar para el usuario, como de facilitar la configuraci´on de alarmas y eventos en la medida de lo posible y avisar de manera llamativa la llegada de nuevos eventos. De esta manera, la gesti´on de dispositivos y sus CEs se realiza de manera transparente e intuitiva por cualquier usuario sin necesidad de tener conocimientos espec´ıficos desde cualquier ordenador con conexi´on a Internet haciendo accesible la telemonitorizaci´on de los datos t´ecnicos de estos dispositivos sin requerir personal cualificado para ello. La tecnolog´ıa Web utilizada para realizarlo se basa en Servlets, Java y JSP. En concreto, se utiliza el Framework Struts2 que ofrece un potente marco de programaci´on basado en el modelo MVC. Este patr´on de arquitectura separa las partes de la aplicaci´on en l´ogica de negocio, interfaz gr´afica y datos, lo que hace 51 52 6.1. Conclusiones m´as f´acil el manejo de aplicaciones grandes y sus dise˜nos m´as claros. Lo que esto significa es que se ha creado una aplicaci´on que va a ser f´acil de ampliar en un futuro, ya que modificar cualquiera de las partes no va a afectar las otras dos. Adem´as, se utiliza el Framework Tiles que separa las vistas de la aplicaci´on por partes para poder reutilizar las partes comunes, lo que se traduce en poder crear nuevas vistas de manera sencilla. Los datos de los usuarios que tienen acceso al sistema, de sus agentes asociados y de los datos de conexi´on necesaria de los mismos as´ı como el registro de los traps recibidos se almacenan en una base de datos MySQL colocada en el mismo servidor donde se encuentra la aplicaci´on Web. Para la conexi´on a esta base de datos desde la aplicaci´on se utiliza el Framework Hibernate que permite mapear las tablas de la base de datos con clases Java. Para mostrar los datos t´ecnicos se han incluido herramientas como JFreeChart que permiten visualizarlos de forma gr´afica. La visualizaci´on gr´afica de los datos permitir´a interpretar la informaci´on de una manera m´as r´apida y eficiente. Por ejemplo, gr´aficamente se puede apreciar muy bien si un dispositivo est´a teniendo muchos errores ya que su gr´afico tendr´a mucho el color correspondiente o se podr´a apreciar instant´aneamente cuando se est´a quedando sin bater´ıa, etc. Tambi´en se han creado funciones JavaScript para facilitar la elecci´on de opciones en las distintas p´aginas y asegurar que el usuario que no va a intentar seleccionar acciones que no tienen sentido. La comunicaci´on que establece el gestor con el agente MD se realiza mediante el protocolo SNMP que se ha implementado en Java, en la parte correspondiente a la l´ogica de negocio de la aplicaci´on web usando la librer´ıa SNMP4j. Dependiendo de las acciones que se quieran realizar, los mensajes enviados variar´an. Para la captura de los traps recibidos, se ha desarrollado una aplicaci´on que se mantiene escuchando en el puerto 162 y registra todos los eventos recibidos. Si el usuario est´a conectado al sistema en el momento en el que llega un evento, aparece un icono parpadeante en la esquina superior derecha que avisa su llegada. Esto es Cap´ıtulo 6. Conclusiones y L´ıneas Futuras 53 posible con una funci´on AJAX que comprueba la existencia de nuevos eventos peri´odicamente. AJAX no refresca la p´agina para mostrar datos nuevos sobre la vista, por lo que el usuario no percibir´a cuando la funci´on est´a comprobando los eventos hasta que llegue alguno y la se˜nal de aviso aparezca. Al no refrescar la p´agina, se reduce el tr´afico al servidor y se evitan las molest´ıas que podr´ıa ocasionar un refresco de p´agina que perder´ıa los datos introducidos. Por ´ultimo, se ha realizado una evaluaci´on mediante dos cuestionarios para comprobar si los usuarios son capaces de utilizar todas las funciones del sistema sin ning´un problema y recoger opiniones y sugerencias que permitan mejorar el sistema en un futuro. 6.2 L´ıneas futuras Algunas posibles l´ıneas futuras para este proyecto ser´ıan: - Dise˜nar un gestor para la gesti´on cl´ınica de los dispositivos, para posteriormente, a˜nadirlo a esta aplicaci´on. - Implementarse en fase de pruebas mientras se sigue evaluando para poder mejorar los fallos que pueda surgir. - Modificar el agente para permitir la gesti´on de m´as tipos de dispositivos y, posteriormente, ampliar la aplicaci´on. Anexo A. Informaci´on Framework Struts2 61 5. Recolecci´on par´ametros de entrada (a) Struts1.- Utiliza ActionForms para captura los par´ametros de entrada. Al igual que los Actions, todos los ActionForms tienen que extender de una clase base. JavaBeans no pueden ser usados como ActionForms, por lo que los desarrolladores crean clases redundantes para capturar los par´ametros. (b) Struts2.- Utiliza las propiedades del Action como los par´ametros de entrada, eliminando la necesidad de un segundo objeto de entrada. En este caso, las propiedades tambi´en pueden ser clases. 6. Expresiones de Lenguaje (a) Struts1.- Est´a integrado con JSTL que tiene los objetos b´asicos. (b) Struts2.- Tambi´en puede utilizar JSTL pero el Framework tiene integrado un sistema m´as flexible, el OGNL. 7. Uni´on valores dentro de las vistas (a) Struts1.- Utiliza los mecanismos tradicionales de JSP para unir los objetos dentro de la p´agina de contexto. (b) Struts2.-Usa la tecnolog´ıa ”ValueStack”para que la que vista pueda acceder a los valores usando taglibs. 8. Tipo de conversaci´on (a) Struts1.- Todas las propiedades del ActionForm son, normalmente, cadenas. Para la conversi´on, se utiliza Commons-Beanutils. (b) Struts2.-Utiliza OGNL para la conversi´on. Adem´as incluye conversores a tipos primitivos o para algunos tipos de objetos m´as comunes. 9. Validaci´on (a) Struts1.- Soporta validaci´on manual por medio del m´etodo validate() del ActionForm o extendiendo de Commons Validator. 62 A.3. Struts2 vs Struts1 (b) Struts2.- Tambi´en soporta la validaci´on por medio del m´etodo validate() y por medio del Framework Xwork Validator. Este framework permite diferentes tipos de validaciones seg´un el contexto en el que se encuentren. 10. Control de la ejecuci´on del Action (a) Struts1.- Permite distintas peticiones para cada m´odulo pero todas los Actions del mismo m´odulo comparten el mismo ciclo de vida. (b) Struts2.- Permite crear diferentes ciclos de vida por Action. Anexo A. Informaci´on Framework Struts2 63 ACTION CONTEXT CLEAN UP OTHER FILTERS FILTER DISPATCHER ACTION PROXY ACTION INVOCATION CONFIGURATION MANAGER STRUTS.XML ACTION TEMPLATE (JSP) RESULT INTERCEPTOR 1 INTERCEPTOR 2 INTERCEPTOR 3 INTERCEPTOR 3 INTERCEPTOR 2 INTERCEPTOR 1 TAG SUBSYSTEM (HTML, Forms, etc.) ACTION MAPPER Figura A.1: Arquitectura Framework Struts2. Anexo B Descripci´on detallada objetos MIB MD La MIB dise˜nada en (1) es una MIB privada dise˜nada dentro del grupo zaragozaNetworkManagementResearchGroup, creado en la Universidad de Zaragoza para contener MIBs creadas por sus grupos de investigaci´on. La MIB MD, llamada MedicalDevicesManager, tiene el ´ındice 4 dentro de este grupo, por lo que el OID para acceder a sus datos es: 1.(iso). 3(org). 6(dod). 1(internet). 4(private). 1(enterprises). 28308(zaragozaNetWorkManagementResearchGroup). 4(medicalDevicesManager). En la figura B.1 se observa la estructura jer´arquica de la MIB. En la figura B.1 se observa la estructura de la MIB. Est´a compuesta por cinco grupos que se detallan a continuaci´on. B.1 Grupo ComputeEngineControlInfo En la figura B.2, se muestra este grupo. En este grupo se almacena desde la informaci´on est´atica asociada al CE como los recursos utilizados por el mismo. Tambi´en se incluye en este grupo la direcci´on d´onde se encuentra el CE y dos variables que permiten al gestor pedir actualizaciones de la informaci´on t´ecnica y estados de los dispositivos. Los par´ametros de este grupo se muestran a continuaci´on: 65 66 B.1. Grupo ComputeEngineControlInfo medicalDeviceControlTable medicalDeviceManagement zaragozaNetworkManagementResearchGroup computeEngineControlInfo medicalDeviceInfo medicalDeviceDataTable medicalDeviceStateTable specificErrorsTable alarmsTable medicalDeviceInfo configurationEventTable logTable managerTable systemOvercharged wrongDeviceWorking specificError warning newMD medicalDeviceManagerTraps Figura B.1: Estructura MIB MD. -IdComputeEngine. Identificador del CE. -DeviceType. Tipo de dispositivo que es el CE. -WorkingState. Indica el estado de funcionamiento del CE. Este estado puede ser operativo o da˜nado. -CommunicationState. Este par´ametro indica si el CE est´a mandando informaci´on, recibiendo informaci´on o en estado idle. -AsociatedMDs. N´umero de MDs registrados en este CE. -BandwidthUse. Porcentaje del ancho de banda utilizado por el CE sobre el total disponible. Este par´ametro permite evitar problemas de congesti´on. -CpuUse. Porcentaje del uso del procesador por parte del CE. Su control permite evitar sobrecargar de procesos el CE y por tanto ralentizarlo. -HardDiskMemoryUse. Porcentaje de disco duro utilizado por el CE. El Anexo B. Descripci´on detallada objetos MIB MD 67 idComputeEngine deviceType workingState associatedMDs bandwidthUse cpuUse hardDiskMemoryUse virtualMemoryUse communicationState computeEngineControlInfo physicalMemoryUse userContactInformation hostIPAddress updateRequestStateMDs updateRequestTechnicalDataMDs dateTimeControl Figura B.2: Estructura Grupo ComputeEngineControlInfo MIB MD. control de esta variable nos permite conocer la cantidad de espacio libre en el disco duro y evitar quedarnos sin espacio para almacenamiento. -VirtualMemoryUse. Porcentaje de memoria virtual utilizada por el CE. Su control permite evitar la falta de memoria virtual. -PhysicalMemoryUse. Porcentaje de memoria f´ısica, o memoria RAM, utilizada por el CE. Su control permite evitar la falta de memoria f´ısica y por tanto el ralentizamiento del procesador. -UserContactInformation. Especifica la direcci´on donde se encuentra el CE. -HostIPAddress. Direcci´on IP del CE. -UpdateRequestStateMDs. Esta variable sirve para pedir actualizaciones del estado de todos los dispositivos registrados en el CE. -UpdateRequestTechnicalDataMDs. Esta variable sirve para pedir actualizaciones de la informaci´on t´ecnica de todos los dispositivos registrados en el CE. 68 B.2. Grupo MedicalDeviceInfo -dateTimeControl. Fecha en la que fue realizada la ´ultima actualizaci´on de los recursos propios del CE. B.2 Grupo MedicalDeviceInfo Este grupo contiene toda la informaci´on relativa a los MDs asociados al CE. Esta informaci´on se divide a su vez en cuatro tablas: datos de control, datos t´ecnicos, cambios de estado de los MDs y errores que hayan surgido durante las capturas. B.2.1 MedicalDeviceControlTable medicalDeviceControlTable medicalDeviceControlEntry idMDControl manufacturer model mdType protocolType configurationType updateRequestState updateRequestTechnicalData systemId medicalDeviceInfo deviceDate Figura B.3: Estructura MedicalDeviceControlTable MIB MD. En la figura B.3, se muestra la tabla de control de los MDs. Est´a tabla guarda l informaci´on est´atica de los MDs. Tiene una entrada por cada MD asociado que se registra la primera vez que el MD se conecta al CE. Los par´ametros de esta tabla se describen a continuaci´on: -IdMDControl. Identificador que se le asigna a cada MD dentro de la MIB. -Manufacturer. Fabricante del MD. -Model. Modelo del MD dentro de la gama del fabricante. Anexo B. Descripci´on detallada objetos MIB MD 69 -SystemId. Identificador del MD proporcionado por el fabricante. -MDType. Tipo de MD que se ha registrado. Hay 4 tipos: term´ometro, b´ascula, medidor de presi´on arterial o pulsiox´ımetro. -ProtocolType. Tipo de protocolo utilizado en la comunicaci´on entre MD y manager. En este caso ser´a por defecto el protocolo X.73. -ConfigurationType. Tipo de configuraci´on con la que est´a trabajando el MD. Puede ser est´andar o extendida. -UpdateRequestState. Este par´ametro se utiliza para pedir actualizaciones del estado de ´este dispositivo en concreto. -UpdateRequestTechnicalData. Este par´ametro se utiliza para pedir actualizaciones del estado de ´este dispositivo en concreto. -DeviceDate. Fecha en la que se registr´o este MD. B.2.2 MedicalDeviceDataTable medicalDeviceDataTable medicalDeviceDataEntry idMDData idCapture supplyType remainderBattery errors ownerMD dateTimeData batteryLevel Figura B.4: Estructura MedicalDeviceDataTable MIB MD. En la figura B.4, se muestra la estructura de la tabla de datos t´ecnicos de los MDs. Como su propio nombre indica, registra los datos t´ecnicos recibidos de los MDs asociados. Esta tabla se indexa por el identificador del MD y de la captura. Puede haber un m´aximo de 20 capturas por MD. Los objetos de esta tabla se describen a continuaci´on: 70 B.2. Grupo MedicalDeviceInfo -IdMDData. Identificador del MD al que corresponde la captura. -IdCapture. Identificador de la captura. -SupplyType. Ttipo de alimentaci´on que est´a utilizando el MD. Puede variar entre bater´ıa o conexi´on a la red el´ectrica. -BatteryLevel. Porcentaje de bater´ıa que le queda al MD. -RemainderBattery. N´umero estimado de horas que puede funcionar el MD con la bater´ıa que le queda. -Errors. Muestra si ha habido alg´un error en el MD al tomar esta medida. Su valor es OK si no ha habido problema, y Error si lo ha habido. -OwnerMD. Persona que ha realizado la medida. -DateTimeData. Fecha en la que se realiz´o esta entrada en la tabla. B.2.3 MedicalDeviceStateTable medicalDeviceStateTable medicalDeviceStateEntry idMDState idState deviceState dateTimeState Figura B.5: Estructura MedicalDeviceStateTable MIB MD. En la figura B.5, se puede observar esta tabla. La tabla medicalDeviceSstateTable muestra los cambios de estados que se han recibido de los MDs asociados al CE. Al igual que la tabla anterior, tambi´en puede contener un m´aximo de 20 cambios de estado por cada MD asociado. La descripci´on de los objetos que se pueden observar en esta tabla es la siguiente: -IdMDState. Identificador del MD al que corresponde el estado que se registra en esta entrada. Anexo B. Descripci´on detallada objetos MIB MD 77 -Permission. Indica los privilegios del gestor dentro de la MIB. -NextFreeIndex. Indica el siguiente ´ındice libre. -StatusManager. Estado de creaci´on del gestor. Si el valor es 1 (valid), implica que la entrada est´a creada y completada. Si el valor es 3 (underCreation), implica que la entrada a´un est´a por completar. Los valores 2(creation) y 4 (drop) sirven para crear y borrar la entrada, respectivamente. B.6 Definici´on de los Traps systemOvercharged wrongDeviceWorking specificError warning newMD medicalDeviceManagerTraps Figura B.11: Definici´on de Traps MIB MD. Un trap es un mensaje as´ıncrono que env´ıa el agente al gestor asociado para informar de alg´un cambio importante en el mismo. Los traps definidos en esta MIB se muestran en la figura B.11. Hay cinco tipos: -SystemOvercharged. Ser´a enviado cuando alguno de los recursos del CE se encuentre saturado. Las variables que se adjuntan son el ancho de banda, uso de CPU y uso de memoria, adem´as de incluir la fecha a la que se detect´o la sobrecarga. -WrongDeviceWorking. Si alguna medida proveniendo de los MDs asociados no est´a dentro del rango definido como normal, se env´ıa este trap. Justo a este mensaje, se env´ıa el identificador del dispositivo, el identificador de la factura y la fecha a la que ocurri´o. -SpecificError. Este trap est´a asociado a la table con el mismo nombre. Incluye todos los par´ametros de la misma. 78 B.6. Definici´on de los Traps -NewMD. Cada vez que un MD nuevo se registra al CE, se env´ıa este trap. Para m´as detalle, se adjunta la entrada que ha creado en la tabla MDControl. -Warning. Este trap es gen´erico y est´a definido para cubrir el resto de recursos que no tiene Trap asociado. Al ser enviado, incluye el recurso y el valor que ha hecho activarse a la alarma. Anexo C Estructura de la aplicaci´on La aplicaci´on se ubica en la carpeta Webapps del servidor Apache Tomcat 6.0 en una carpeta llamada Gestor que se muestra en la figura C.1. gestor charts css images js layout META-INF pages WEB-INF classes struts.xml hibernate.cfg lib tiles.xml web.xml actions graphics MIB snmpv3 tables util variables Figura C.1: Estructura de Carpetas de la Aplicaci´on. 79 80 C.1. Carpeta Gestor C.1 Carpeta Gestor Esta carpeta contiene otras carpetas que se explican a continuaci´on: -charts.- Contiene los archivos que se encargan de preparar los gr´aficos para representarlos. -css.- Contiene las hojas de estilo .css que definen la aplicaci´on. -images.- Guarda todas las im´agenes que se utilizan a lo largo de todas las vistas. -js.- Almacena librer´ıas JavaScript complementarios a las funciones creadas para la aplicaci´on. -layout.- Define los Layout de Tiles, es decir, las bases de las cuales todas las vistas van a heredar. -META-INF.- Tiene los archivos de persistencia. -pages.- Contiene todas las p´aginas JSP que constituyen la vista del sistema. -WEB-INF.- Contiene toda la informaci´on de configuraci´on necesaria para la aplicaci´on Web. En su interior, se guarda el fichero de configuraci´on web.xml, que act´ua de controlador principal, determinando como asignar a los Servlets, si se necesita autentaci´on, etc. Adem´as de este fichero, se encuentra tambi´en el fichero tiles.xml que indica el body JSP que se utilizar´a para cada vista. Esta carpeta tambi´en tiene a su vez otras dos carpetas: lib y classes. La carpeta lib almacena todas las librer´ıas necesarias para el correcto funcionamiento de la aplicaci´on. classes contiene todas las clases Java que se han implementado adem´as de los archivos de configuraci´on de Struts2 e Hibernate y los ficheros .properties. El fichero de configuraci´on de Struts2, struts.xml, indica los Interceptores, Actions y a qu´e p´agina habr´a que dirigirse en cada momento. El fichero de configuraci´on de Hibernate, hibernate.cfg contiene la informaci´on necesaria para conectarse a la base de datos indicando Anexo C. Estructura de la aplicaci´on 81 tambi´en d´onde se encuentran las clases Java a las que se tiene que mapear. Los ficheros .properties guardan los textos de todas las etiquetas en Ingles y en Espa˜nol. Esta carpeta separa su contenido en distintos paquetes seg´un el tipo de acciones que realizan las clases Java que hay en su interior. Estas carpetas son: •actions.- Contiene las clases Action de Struts2 que realizar´an las operaciones oportunas para decidir la respuesta mostrada. •graphics.- Almacena las clases que ayudar´an a la creaci´on de los gr´aficos de datos. •MIB.- Conjunto de clases que tienen la estructura de la MIB para facilitar el manejo de los datos recibidos. •snmpv3.- Estas clases env´ıan los mensajes SNMP al agenteMD adecuados en cada momento. •tables.- Clases Java a las que se mapea la base de datos que usa la aplicaci´on. •util.- Define m´etodos para la conexi´on a la base de datos mediante HIbernate. •Variables.- Conjunto de m´etodos auxiliares que se utilizan para mostrar los datos provenientes de la MIB en el idioma correcto. Anexo D Gu´ıa de Instalaci´on En este Anexo se va a explicar los pasos a seguir para instalar correctamente la aplicaci´on. Hay que tener en cuenta que esta aplicaci´on se comunica con un agenteMD, cuyos datos de conexi´on se almacenan en la base de datos, por lo que esta aplicaci´on no funcionar´a correctamente si los datos son incorrectos o el agente no es accesible desde el lugar donde est´a colocada la aplicaci´on. D.1 Preparar el entorno Java Para el desarrollo de esta aplicaci´on se ha utilizado el JDK 1.6 (Java Development Kit). El primer paso para configurar el entorno es descargarse el kit desde la p´agina de Oracle (17). Una vez descargado, se instala y se define su variable de entorno JAVA HOME. Para ello, hay que ir a: Inicio →Panel de Control →Sistema →Configuraci´on Avanzada del sistema →Variables de Entorno .. . Una vez en la ventana de Variables de Entorno, se crea una nueva con los siguientes datos: Nombre de la variable: JAVA HOME Valor de la variable: Directorio donde se ha instalado el JDK (Ejemplo: C:\Program Files\Java\jdk1.6.0 21) 83 84 D.2. Instalaci´on de MySQL Adem´as de crear esta nueva variable de entorno, hay que modificar una existente llamada PATH, a˜nadiendo al final (sin eliminar los valores existentes) este valor ; %JAVA HOME %\bin. D.2 Instalaci´on de MySQL Descargar XAMPP (18) e instalarlo. Una vez instalado, hay que Iniciar el servidor Apache y MySQL pulsando el bot´on Start. Cuando ambos servidores est´en funcionando, hay que acceder desde el navegador a http://localhost/phpmyadmin y crear una nueva base de datos llamada usuarios. Tambi´en hay que crear un usuario con todos los privilegios, desde la pesta˜na de Privilegios →Agregar un nuevo usuario. Los datos del usuario a crear son los siguientes: Nombre de usuario: veronica Servidor: % Contrase˜na: vero2108 Despu´es de crear el usuario adecuado, se ejecuta hibernate.exe que es un programa ejecutable que crea las tablas necesarias y a˜nade dos usuarios para las pruebas: admin ymanager y los agentesMD asociados. Las tablas creadas son cuatro: D.2.1 Tabla user Esta tabla contiene los usuarios que tienen al acceso al sistema. La estructura de esta tabla es la siguiente: -userId.- Identificador del usuario generado autom´aticamente por Hibernate. -username.- Nombre del usuario para el acceso al sistema. -password.- Contrase˜na del acceso al sistema del usuario. Anexo D. Gu´ıa de Instalaci´on 85 -category.- Indica la categor´ıa del usuario: root, manager o doctor. -fullName.- Nombre completo del usuario. -email.- Correo electr´onico del usuario. -phoneNumber.- Tel´efono de contacto del usuario. D.2.2 Tabla user computeengine Es una tabla relacional creada por Hibernate para almacen los CEs asociados a los usuarios registrados en la tabla user. -user userID.- C´odigo del usuario de la tabla user. -computeEngines idComputeEngine.- C´odigo del CE de la tabla computeEngines. D.2.3 Tabla computeEngine Esta tabla guarda la informaci´on necesaria para la conexi´on con los agentesMD. Los campos necesarios para ellos, son: -idComputeEngine.- C´odigo del CE generado autom´aticamente por Hibernate. -username.- Nombre de usuario asociado al CE. -idCEMIB.- C´odigo de la MIB para la aplicaci´on Web. -ipUser.- Direcci´on IP para la conexi´on con el agenteMD. -port.- Puerto con el que hay que comunicarse. -securityName.- Nombre de seguridad para la conexi´on. -securityLevel.- Nivel de seguridad requerido. 86 D.3. Gestor SNMP Trap -authPassword.- Contrase˜na de autenticaci´on, si es necesaria. -privPassword.- Contrase˜na privacidad para la conexi´on. D.2.4 Tabla traps Esta tabla registra todas los traps que se reciben de los agente. La estructura es la siguiente: -idTrap.- Identificador del Trap generado autom´aticamente por Hibernate. -IPAgente.- Direcci´on IP del agente que ha enviado el trap. -idDevice.- Identificador del MD asociado a la alarma activada. -idCaptura.- Identificador de la captura que ha producido el env´ıo del trap. -trapType.- Tipo de trap recibido. -dateTime.- Fecha en la que se recibi´o el trap. -nuevo.- Indica si el trap se ha visualizado o no. D.3 Gestor SNMP Trap El gestor necesita escuchar constantemente en el puerto 162. Para ello, hay que liberar cualquier aplicaci´on que pueda estar usando ese puerto siguiendo los siguientes pasos: •Ir al fichero C:\WINDOWS\System32\drivers\etc\services para cambiar la aplicaci´on snmptrap a un puerto diferente. Por ejemplo, el puerto 163. •Hay que asegurarse de que no haya ninguna aplicaci´on utilizando el puerto 162. Para ello, ejecutamos netstat -a desde l´ınea de comandos y, si hay alguna aplicaci´on que lo utilice, se busca en el Administrador de tareas →Terminar tarea correspondiente. Anexo E Gu´ıa de Usuario E.1 Estructura de las p´aginas La estructura de las p´aginas es muy sencilla manteniendo concordancia entre las distintas vistas y destacando en la parte superior las principales secciones que tiene: •Inicio. Muestra la p´agina de bienvenida, donde se pueden ver los ´ultimos eventos recibidos y cambiar la configuraci´on personal. •Dispositivos. En esta pesta˜na, se podr´a acceder a la informaci´on relacionada con los dispositivos m´edicos y sus dispositivos concentradores de datos. •Alarmas. Permite configurar las alarmas y visualizar los datos relacionados con ellas: alarmas configuradas, eventos asociados, tabla de logs o eventos recibidos. •Usuarios. Esta pesta˜na est´a solo disponible para los usuarios de tipo administrador. Permite buscar, agregar o eliminar usuarios. Adem´as, de estas pesta˜nas, a lo largo de todas las vistas, en la parte superior derecha de la p´agina aparecen las siguientes opciones: •Ayuda. Al pulsarse, muestra un popup con informaci´on sobre el contenido de la p´agina y las acciones que se pueden realizar en ella. 93 94 E.2. P´agina de Inicio •In English. Permite cambiar de idioma. •Cerrar Sesi´on. Finaliza la sesi´on iniciada por el usuario. E.2 P´agina de Inicio La p´agina de inicio es la mostrada en la figura E.1. Desde esta secci´on, se puede ver los ´ultimos eventos recibidos o cambiar opciones de la configuraci´on personal del usuario que tiene iniciada la sesi´on. Los ´ultimos eventos mostrados en esta p´agina son aquellos que se han recibido mientras el usuario ha estado desconectado o no se han visualizado todav´ıa. Las opciones de configuraci´on personal son: •Visualizar/Editar datos personales. Est´a opci´on permite modificar al usuario los datos personales que tiene registrados en el sistema: nombre de usuario, contrase˜na, nombre completo, tel´efono y email. •Cambiar contrase˜na. Con esta opci´on se puede cambiar la contrase˜na de acceso al sistema. Figura E.1: P´agina Inicio del sistema. Anexo E. Gu´ıa de Usuario 95 E.3 Gesti´on Dispositivos E.3.1 Datos asociados al dispositivo concentrador. Desde la pesta˜na Dispositivos se pueden ver todos los hogares que se tienen asociados a su usuario. Para acceder a la informaci´on de control de alg´un dispositivo concentrador o a los dispositivos m´edicos que ´este controla, hay que pulsar encima de la imagen correspondiente. Los datos del dispositivo concentrador se representan en la figura E.2. Figura E.2: Recursos del dispositivo concentrador de datos. Desde esta p´agina, se puede ver el lugar desde el cual se est´an haciendo las mediciones, el tipo de dispositivo que est´a recogiendo los datos (cuyos datos t´ecnicos se est´an visualizando) y los tipos de dispositivos m´edicos que tiene asociados. Desde aqu´ı, se pueden ir a varios sitios dependiendo del bot´on/imagen que se pulse, adem´as de volver a la p´agina anterior: •Im´agenes de los dispostivos. Al pulsar alguna de las im´agenes de los dispositivos que se encuentran en la parte superior de la p´agina, se mostrar´an los ´ultimos datos t´ecnicos recogidos (tipo de bater´ıa, porcentaje de bater´ıa, estado, etc) sobre ese dispositivo. 96 E.3. Gesti´on Dispositivos •Ver Dispositivos. A trav´es de este enlace, se obtiene la informaci´on m´as relevante sobre los ´ultimos datos t´ecnicos recibidos de todos los dispositivos asociados. Esta informaci´on es: horas de bater´ıa, errores en la medida y estado. Se muestra en la figura E.3. •Actualizar. Al pulsar este bot´on se enviar´a una petici´on para actualizar los datos t´ecnicos y el estado de todos los dispositivos asociados adem´as de actualizar los datos del dispositivo concentrador de datos. •Config.Alarma. A trav´es de este bot´on, se accede a otra p´agina para configurar alarmas asociadas a alguno de los recursos del dispositivo concentrador de datos. Figura E.3: Datos t´ecnicos relevantes de todos los dispositivos. Anexo E. Gu´ıa de Usuario 97 E.3.2 Datos t´ecnicos de los dispositivos m´edicos El acceso m´as directo para visualizar los datos t´ecnicos asociados a un dispositivo es a trav´es de las im´agenes de los dispositivos que hay en la p´agina anterior (figura E.2) pudiendo tambi´en acceder a los datos t´ecnicos de un dispositivo m´edico en concreto despu´es de haber visualizado la informaci´on m´as relevante sobre los ´ultimos datos t´ecnicos (bot´on Ver Dispositivos, figura E.3). Estos datos se muestran en la figura E.4. Figura E.4: Datos t´ecnicos de los dispositivos m´edicos. Desde esta p´agina se pueden realizar varias acciones: •Columna Hist. + Bot´on GO!.Esta columna se utiliza para visualizar el hist´orico de los datos t´ecnicos asociados al dispositivo actual en forma de tabla. Se pueden seleccionan tantas columnas como se desee mostr´andose solo los datos seleccionados. •Columna Graf. + Bot´on GO!.Marcando est´a columna y pulsando posteriormente el bot´on GO!, se visualiza el hist´orico de los datos t´ecnicos de forma gr´afica. Al igual que en la columna anterior, se pueden marcar tantas columnas como se desee mostr´andose solo los datos seleccionados. 98 E.3. Gesti´on Dispositivos •Columna Alarm. + Bot´on GO!.Esta columna solo permite seleccionar un recurso. Una vez seleccionado, al pulsar el bot´on GO!, lleva a otra p´agina para configurar una alarma asociada al dispositivo y recurso seleccionado. •Info. General. Al pulsar este bot´on, se mostrar´an los datos est´aticos asociados al dispositivo que se est´a visualizando. Esto son datos son: fabricante, c´odigo de fabricante, protocolo de comunicaci´on, etc. E.3.3 Informaci´on General dispositivos m´edicos A esta informaci´on se accede mediante el bot´on Info. General que se encuentra en las p´aginas que contienen los datos t´ecnicos. La informaci´on que se presenta en la figura E.5 son los datos est´aticos del dispositivo seleccionado. Esta p´agina permite visualizar los ´ultimos datos recibidos de ese dispositivo pulsando el bot´on Datos T´ecnicos. Figura E.5: Informaci´on General de los dispositivos m´edicos. Anexo E. Gu´ıa de Usuario 99 E.4 Alarmas Esta pesta˜na se muestra en la figura E.6 que contiene cuatro opciones: •´ Ultimos eventos. A trav´es de este enlace se pueden visualizar los ´ultimos eventos recibidos. •Visualizar tabla de logs. Al pulsar sobre esta imagen se muestra el registro de logs. •Visualizar alarmas configuradas. En este enlace se encuentran todos las alarmas configuradas en el hogar que se est´a mirando. •Configurar Alarma. Al pulsar esta imagen aparece otra p´agina para la configuraci´on de alarmas. Figura E.6: Vista pesta˜na Alarmas. E.4.1 ´ Ultimos eventos recibidos Para visualizar los ´ultimos eventos recibidos se puede acceder desde la pantalla de Inicio, desde la pesta˜na de Alarmas pulsando sobre el el enlace ´ Ultimos eventos o pulsando sobre el icono de advertencia que aparece cuando llegan eventos nuevos. La informaci´on que se puede ver en esa p´agina es la mostra en la figura E.7: 100 E.4. Alarmas Figura E.7: ´ Ultimos eventos recibidos. •Imagen New.Indica que el evento de esa fila no ha sido visto anteriormente. Adem´as de esta imagen, las filas que contengan informaci´on sobre nuevos eventos, est´an sombreadas. •Direcci´on IP. Muestra la direcci´on IP desde la que se ha recibido el evento. •C´od.Dispositivo. Esta columna permite visualizar el tipo de dispositivo que ha enviado el mensaje. Pulsando sobre la imagen, se accede a la informaci´on general del dispositivo. •C´od.Captura. Indica el c´odigo correspondiente a la captura que ha activado la alarma. Pulsando sobre el n´umero, se puede ver los datos t´ecnicos correspondientes a dicha captura. •Hora Trap. Muestra la fecha en la que fue recibido el mensaje. •Descripci´on. Describe el tipo de mensaje recibido. E.4.1.1 Aviso nuevos eventos Cuando un icono tri´angular parpadeante como el de la figura E.8 aparezca en la parte superior derecha de la p´agina, significa que un evento nuevo ha llegado. Anexo E. Gu´ıa de Usuario 101 Para poder visualizar los datos de los eventos nuevos en detalle, basta con pulsar sobre el icono. Figura E.8: Aviso llegada de eventos nuevos. E.4.2 Visualizar tabla de logs Para visualizar la tabla de logs, basta con pulsar sobre el icono correspondiente en la pesta˜na de Alarmas. La p´agina que se ver´a es la mostrada en la figura E.9 donde se tiene: Figura E.9: Logs registrados. 102 E.4. Alarmas •C´od.Evento. Este c´odigo representa el evento que ha creado el registro en la tabla de logs. Al pulsar sobre el c´odigo, se muestra la informaci´on detallada sobre dicho evento. •C´od.Alarma. Indica el c´odigo de la alarma que ha sido activada y cuyo evento asociado ha creado el registro. Al pulsar sobre el c´odigo, se accede a la informaci´on detallada sobre dicha alarma. •Descripci´on. Comenta el motivo por el que se ha activado la alarma. Puede ser: valor inv´alido, alarma activada por umbral superior o inferior y alarma activada por valor. E.4.3 Visualizar alarmas configuradas Para acceder a esta secci´on, hay que pulsar sobre la imagen correspondiente en la pesta˜na de Alarmas. Una vez se haya pulsado la imagen, se acceder´a a otra p´agina donde se dividen las alarmas configuradas en tres grupos seg´un los eventos que tengan asociados ser´an: 1. Alarmas por valor: Estas alarmas son aquellas que se activan cuando el recurso asociado a la alarma alcanza un determinado valor. 2. Alarmas activada por umbral superior: Las alarmas que se ven al pulsar este icono son aquellas que son activadas cuando el recurso asociado supera un determinado umbral. 3. Alarmas activadas por umbral inferior: Estas alarmas son aquellas que se activan cuando el recurso asociado supera un determinado umbral inferiormente. Para visualizar el tipo de alarmas deseado, se pulsa sobre el icono correspondiente y se obtiene una p´agina como la de la figura E.10. En ella, los datos representados son: Anexo F. Cuestionarios Evaluaci´on 109 FASE II: EVALUACI ´ ON GENERAL CUESTIONARIO DE EVALUACI´ ON DEL SERVICIO DE TELEMONITORIZACI´ ON DOMICILIARA Fecha: Edad: Perfil: Sexo: 2M2H Evaluaci´on general del Sistema 1. ¿El sistema es f´acil de usar? 2S´ı 2No 2. ¿Es intuitivo? 2S´ı 2No 3. ¿Se est´an produciendo fallos en el funcionamiento del sistema? 2S´ı 2No 4. ¿Con qu´e frecuencia? 5. ¿En cu´antas ocasiones no ha sido posible visualizar los datos deseados? 6. ¿La informaci´on proporcionada es suficiente para el seguimiento del correcto funcionamiento de los dispositivos? 2S´ı 2No 7. ¿Cu´al es el grado de satisfacci´on en la configuraci´on de alarmas? 2Muy Satisfecho 2Satisfecho 2Normal 2Insatisfecho 2Muy insatisfecho 8. ¿Cree que el aviso de llegada de nuevos eventos es suficiente? 2S´ı 2No 9. ¿Qu´e otros avisos a˜nadir´ıa? 110 10. ¿En qu´e ocasiones considera que es ´util el sistema? 11. Enumere las principales dificultades encotradas. 12. ¿Aconsejar´ıa la adopci´on de un sistema de estas caracter´ısticas en un entorno de salud de forma permanente? 2S´ı 2No 13. ¿Por qu´e? 14. ¿Cu´al es el grado de satisfacci´on general con el uso del sistema? 2Muy Satisfecho 2Satisfecho 2Normal 2Insatisfecho 2Muy insatisfecho 15. Sugerencias: Anexo G Diagrama de Gantt A continuaci´on se presentan las tareas que aparecen en el diagrama de Gantt para este Proyecto Fin de Carrera mostrado en la figura G.1: 1. Documentaci´on de tecnolog´ıa Web. 2. Documentaci´on arquitectura SNMP. 3. Documentaci´on sobre el estado del arte. 4. Estudio MIB MD. 5. Creaci´on estructura Web. 6. Dise˜no interfaz web. 7. Implementaci´on del bloque de comunicaciones SNMP. 8. Integraci´on de ambas herramientas y desarrollo de todas las vistas del sistema. 9. Internacionalizaci´on de la aplicaci´on. 10. Integraci´on herramientas para visualizaci´on gr´afica de datos. 11. Implementaci´on de herramientas para captura de mensajes as´ıncronos. 12. Evaluaci´on del sistema. 111 112 13. Redacci´on de la memoria. ID 2010 2011 2012 Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan 1 2 3 4 5 6 7 8 9 10 11 12 13 Figura G.1: Diagrama de Gantt del Proyecto Fin de Carrera