2. Descripción del sistema 3

Transcripción

1 Índice general 1. Introducción 1 2. Descripción del sistema Descripción de subsistemas Subsistema Servidor de Control Central (SCC) Subsistema Unidad de Control y Monitorización Móvil (UCMM) Subsistema Unidad de Control y Monitorización No Móvil (UCMNM) 7 3. Tecnologías implicadas Tecnologías de comunicación Wifi GPRS y UMTS Software de prueba de comunicaciones: Ethereal Lenguajes de programación y software asociado Java: J2SE y J2EE J2SE J2EE Software para el desarrollo de aplicaciones J2SE y J2EE Software para la instalación de las aplicaciones Software adicional J2ME Software para el desarrollo de aplicaciones J2ME Software para la instalación de las aplicaciones Software adicional Lenguaje de modelado: UML I

2 II ÍNDICE GENERAL 3.4. Plataformas Hardware y Sistemas Operativos Dispositivos móviles Computadoras Subsistema Servidor de Control Central Arquitectura Interfaz Servidor/NI Funciones Arquitectura Interfaz Servidor/UCMM Interfaz Servidor/UCMNM Servidor Diseño software Diseño software del Interfaz Servidor/NI Diseño software del Interfaz Servidor/NI Http Diseño del Interfaz Servidor/NI TCP-UDP Diseño software del Interfaz Servidor/UCMNM Justificación: estudio previo Justificación: decisión Desarrollo Diseño del Interfaz Servidor/UCMM Comunicaciones Diseño software Diseño software del Servidor Justificación Desarrollo Resumen Funcionamiento del Servidor de Control Central (SCC) Algoritmo de funcionamiento: diagramas de actividad UML Comunicación SCC/NI Comunicación SCC/UCMM

3 ÍNDICE GENERAL III Comunicación SCC/UCMNM Funcionamiento software: diagramas de secuencia UML Comunicación SCC/NI Comunicación SCC/UCMM Comunicación SCC/UCMNM Unidad de Control y Monitorización Móvil Arquitectura Diseño software Diseño software del Interfaz UCMM/SCC Comunicaciones Diseño software Diseño software del Sistema de Control y Monitorización (SCM) Diseño software del módulo Interfaz UCMM/usuario Funcionamiento Algoritmo de funcionamiento: diagramas de actividad UML Actividad: establecer conexión con SCC Actividad: recoger envíos del SCC Actividad: procesar envío del SCC Funcionamiento software: diagramas de secuencia UML Establecimiento de conexión con el SCC Recepción de envíos provenientes del SCC Envío de comando de control al SCC Unidad de Control y Monitorización No Móvil Arquitectura Diseño software Diseño software del módulo Interfaz UCMNM/SCC Justificación Desarrollo Diseño software del Sistema de Control y Monitorización (SCM). 100

4 IV ÍNDICE GENERAL Diseño software del módulo Interfaz UCMNM/usuario Funcionamiento Algoritmo de funcionamiento: diagramas de actividad UML Actividad: recoger envíos del SCC Actividad: envío de comando de control al SCC Funcionamiento software: diagramas de secuencia UML Establecimiento de comunicación con el SCC Recepción de envíos provenientes del SCC Envío de comando de control al SCC Manual de instalación y usuario Manual de instalación Instalación del Servidor de Control Central (SCC) Instalación de la Unidad de Control y Monitorización Móvil (UCMM) Instalación de la Unidad de Control y Monitorización No Móvil (UCMNM) Manual de usuario Manual de usuario del Servidor de Control Central (SCC) Manual de usuario de la Unidad de Control y Monitorización Móvil (UCMM) Manual de usuario de la Unidad de Control y Monitorización No Móvil (UCMNM) Pruebas realizadas Pruebas de funcionalidad Subsistema Servidor de Control Central (SCC) Subsistema Unidad de Monitorización Móvil (UCMM) Subsistema Unidad de Monitorización No Móvil (UCMNM) Pruebas de integración Entre los subsistemas Servidor Central (SCC) y Nodo Inteligente (NI) de la iban Entre los subsistemas Servidor Central (SCC) y Unidad de monitorización Móvil (UCMM)

5 ÍNDICE GENERAL V Entre los subsistemas Servidor Central (SCC) y Unidad de Control y Monitorización No Móvil (UCMNM) Pruebas de integración del sistema completo Medidas Retardo de la respuesta del sistema Jitter en el Servidor de Control Central (SCC) Análisis del funcionamiento software del Servidor de Control Central (SCC) Conclusiones y líneas futuras Conclusiones Líneas futuras A. Protocolo de comunicación entre NI y SCC 159 A.1. Comandos de control A.2. Datos de monitorización A.3. Indicaciones y respuestas a comandos de control A.4. Identificación de paciente A.5. Puerto UDP B. Formato de las tramas del sensor pulsioxímetro 163

6 VI ÍNDICE GENERAL

7 Índice de figuras 2.1. Sistema Completo Arquitectura J2EE [8] Arquitectura de J2ME [14] Arquitectura del SCC Diagrama de clases UML del Interfaz Servidor/NI Http Diagrama de clases UML del Interfaz Servidor/UCMM Diagrama de clases UML del Servidor Diagrama de clases UML del nivel de aplicación del subsistema Servidor Diagrama de clases UML del nivel de paciente del subsistema Servidor Diagrama de clases UML del nivel de sensor del subsistema Servidor Diagrama de clases UML del nivel de sensor, para el sensor pulsioxímetro Diagrama de clases UML del nivel de sensor, para el GPS Diagrama de actividad UML de la recepción en el SCC de un paquete del NI Diagrama de actividad UML del procesamiento de un paquete de identificación del NI Diagrama de actividad UML del procesamiento de un paquete Diagrama de actividad UML: apertura de conexión de datos de la UCMM Diagrama de actividad UML: apertura de conexión de comandos de la UCMM Diagrama de actividad UML: recepción de comando de control de la UCMNM Diagrama de secuencia UML: recepción, por Http, de un envío del NI Diagrama de secuencia UML: establecimiento de comunicaciones SCC/NI en modo TCP-UDP. Recepción de paquetes del NI en el SCC Diagrama de secuencia UML: recepción de comando de la UCMM Diagrama de secuencia UML: transmisión de paquete de datos a las UCMM. 71 VII

8 VIII ÍNDICE DE FIGURAS Diagrama de secuencia UML: recepción de comando de control de la UCMNM Diagrama de secuencia UML: envío a la UCMNM Arquitectura del subsistema UCMM Diagrama de clases UML: arquitectura MVC de la UCMM Diagrama de clases UML: Interfaz UCMM/SCC Diagrama de clases UML: módulo SCM Diagrama de clases: Interfaz UCMM/usuario Diagrama de clases UML: clase VistaSensor Diagrama de clases UML: clase VistaComando Diagrama de actividad UML: funcionamiento de la UCMM Diagrama de actividad UML: funcionamiento de la UCMM (continuación a la figura 5.8) Diagrama de actividad UML: establecer conexión con el SCC Diagrama de actividad UML: recoger envíos del SCC Diagrama de actividad UML: procesar envío del SCC Diagrama de secuencia UML: establecimiento de conexión con el SCC Diagrama de secuencia UML: leer paquetes enviados por el SCC Diagrama de secuencia UML: procesar paquetes del SCC Diagrama de secuencia UML: envío de comando al SCC Arquitectura del subsistema UCMNM Diagrama de clases del Interfaz UCMNM/SCC Diagrama de clases del módulo Interfaz UCMNM/usuario (la clase AppletMonitorPacientes mostrada aparece también en la figura 6.2) Aspecto del applet Interfaz de monitorización de paciente. Pestaña de sensor pulsioxímetro activa Interfaz de monitorización de paciente. Pestaña de posición activa Diagrama de caso de uso UML: obtener lista de pacientes Diagrama de caso de uso UML: comenzar a monitorizar Diagrama de actividad UML: recepción de envíos del SCC Diagrama de actividad UML: envío de comando de control al SCC

9 ÍNDICE DE FIGURAS IX Diagrama de secuencia UML: obtener lista de pacientes registrados Diagrama de secuencia UML: registro de la UCMNM en el SCC Diagrama de secuencia UML: recepción de envío del SCC Diagrama de secuencia UML: envío de comando de control al SCC Ventana del software de instalación Nokia PC Suite Pantalla de bienvenida Pantalla de selección de paciente Pantalla de conexión Pantalla de selección de acción Pantalla de selección de sensor o GPS Parte superior de la primera pantalla de monitorización del sensor pulsioxímetro, en su modo 2 de funcionamiento Parte inferior de la primera pantalla de monitorización del sensor pulsioxímetro, en su modo 2 de funcionamiento Pletismograma: segunda pantalla de monitorización del sensor pulsioxímetro, en su modo 2 de funcionamiento Pantalla de monitorización del sensor pulsioxímetro, en su modo 2 de funcionamiento Pantalla de posición geográfica del paciente Pantalla de selección de comando Pantalla del comando de control para cambiar el modo de funcionamiento de un sensor Pantalla del parámetro médico al que se va a establecer un umbral Pantalla de introducción de los valores numéricos del umbral de un parámetro médico Pantalla del comando para el establecimiento del tiempo de muestreo entre envíos al NI de un sensor Interfaz gráfica de la UCMNM Ventana de monitorización de paciente (pestaña de sensor activa) Ventana de monitorización de paciente (pestaña de posición geográfica activa) Pestaña activa con comando para establecimiento del tiempo de monitorización Pestaña activa con comando de establecimiento de umbral

10 X ÍNDICE DE FIGURAS Pestaña activa con comando de reinicio Valores de jitter con periodo de 1 segundo Histograma del jitter con periodo de 1 segundo Valores de jitter con periodo de 10 segundos Histograma del jitter con periodo de 10 segundos Utilización de memoria y threads activos Objeto de mayor tamaño Thread procesador de paquetes del NI Threads de procesado de paquetes de datos en el modo TCP-UDP Threads de procesado de paquetes de control en el modo TCP-UDP Método que procesa en el SCC los paquetes del NI Método que procesa las peticiones Http efectuadas al SCC A.1. Paquete de comando de control A.2. Paquete de datos de monitorización A.3. Paquete de indicación o respuesta A.4. Paquete de identificación de paciente A.5. Paquete con puerto UDP

11 Índice de tablas 8.1. Definición de eventos y abreviaturas correspondientes Medidas temporales en la UCMNM de la respuesta a eventos del sistema Medidas temporales en la UCMM de la respuesta a eventos del sistema XI

12 XII ÍNDICE DE TABLAS

13 Capítulo 1 Introducción La Telemedicina es un área de la ciencia que estudia el desarrollo de herramientas que permitan, a personal médico, realizar parte del trabajo de observación de pacientes, diagnóstico e incluso intervención y tratamiento, de forma remota. Llevando a cabo las citadas tareas a distancia, se pueden reducir costes económicos y agilizar los servicios médicos. Otros servicios remotos englobados en la Telemedicina son los de acceso a archivos digitales con resultados de análisis y la educación de alumnos de enfermería y medicina [29]. Aprovechando los avances de las tecnologías hardware y de comunicación, la Telemedicina abre nuevos campos de investigación como por ejemplo, el denominado M-Health [30], cuyo nombre proviene de los conceptos móvil (Mobile) y salud (Health). La filosofía de M- Health se basa en combinar la adquisición de bioseñales mediante sensores con tecnologías inalámbricas y de comunicaciones móviles para, de forma remota, proveer de información sobre un paciente al personal médico. Esta interacción redunda en una mayor libertad de movimientos del paciente y, por tanto, en una mejora de la comodidad. En el área de las tecnologías de redes, las aplicaciones web, cuyo uso está ampliamente asentado en todos los ámbitos, podrían extenderse al campo del M-Health y la Telemedicina en general. Así mismo, un uso alternativo de la red móvil y de Wifi representan para ambas un complemento imprescindible. El presente proyecto Desarrollo de una Aplicación de Telemedicina para el Acceso Remoto a Bioseñales desde Dispositivos Móviles se encuadra en el marco de la Telemedicina y el M- Health. En éste se pretende conseguir una buena aproximación a las metas de dichas áreas de la ciencia, articulando para ello las tecnologías de comunicación móvil y comunicación web. El Proyecto aborda el diseño, desarrollo e implementación de un Sistema de Telemedicina que se propone los siguientes objetivos: Permitir a personal médico acceder, de forma remota, a los parámetros médicos o bioseñales muestreadas por los sensores inalámbricos que tenga conectados un paciente. 1

14 2 CAPÍTULO 1. INTRODUCCIÓN Ofrecer al personal médico el acceso, de forma remota, a la información sobre la posición geográfica del paciente cuando éste abandone el recinto hospitalario o entorno controlado genérico, y se encuentre en un entorno exterior urbano. Permitir al personal médico controlar de forma remota los sensores que tenga conectados el paciente. Dar al personal médico la posibilidad de desplazarse geográficamente mientras hace uso del sistema. Emplear, para el desarrollo y funcionamiento del sistema, tecnologías de comunicación web y comunicación móvil. A continuación se expone la organización de esta memoria: tras la presente introducción, el capítulo 3 comenta e introduce las tecnologías involucradas. Por otro lado, la descripción del Sistema en el capítulo 2 presenta a alto nivel su arquitectura, objetivo y funciones. Una vez expuesta la arquitectura del Sistema y las tecnologías empleadas para su desarrollo, los capítulos 4, 5 y 6 se centran en cada uno de los subsistemas que lo conforman. En ellos se explica e ilustra tanto el diseño como su implementación, con una exposición que profundiza de manera progresiva en la arquitectura y diseño del subsistema. Adicionalmente, con el objetivo de proveer al usuario del sistema de una guía de usuario e instalación, se ha redactado el capítulo 7. El correcto funcionamiento del sistema ha sido verificado mediante múltiples pruebas que han quedado registradas y explicadas en el capítulo 8. Las conclusiones a las que se ha llegado acerca del diseño y funcionamiento del sistema se enumeran en el capítulo 9. En éste, se proponen las posibles líneas futuras de ampliación del sistema. Por último, al final de este documento se incluyen la bibliografía utilizada y algunos apéndices.

15 Capítulo 2 Descripción del sistema El presente proyecto se centra en la implementación de un subconjunto del Sistema de referencia Monitorización Inteligente de Pacientes Mediante Tecnologías Inalámbricas, presentado en [2]. Los objetivos del Sistema de referencia son: 1. Muestrear parámetros médicos o bioseñales en pacientes mediante sensores inalámbricos. 2. Acceder remotamente a las bioseñales muestreadas, en tiempo cuasi real. 3. Monitorizar la posición geográfica del paciente. 4. Controlar el proceso de monitorización de forma remota. El proyecto aquí presentado asume parte de estos objetivos, concretamente los 2, 3 y 4. En la figura 2.1 se muestra la arquitectura del sistema completo Monitorización Inteligente de Pacientes Mediante Tecnologías Inalámbricas, que está integrado por los siguientes componentes: Red de área corporal inteligente (iban, intelligent Body Area Network): transportada por cada paciente, recoge la información de posición geográfica y parámetros médicos o bioseñales muestreados por los sensores inalámbricos de dicho paciente, y la transmite al Servidor de Control Central. Está integrada por un GPS, sensores médicos inalámbricos y un nodo inteligente(ni) que actúa de pasarela entre los anteriores, y el Servidor de Control Central. Servidor de Control Central (SCC): recoje la información enviada por las redes de área corporal (iban) que portan cada uno de los pacientes que van a ser monitorizados por el sistema. Pone esa información a disposición de las unidades de control y monitorización; asimismo, actúa de pasarela entre las mencionadas unidades y las iban. 3

16 4 CAPÍTULO 2. DESCRIPCIÓN DEL SISTEMA Unidades de control y monitorización (Unidad de Control y Monitorización Móvil o UCMM, y Unidad de Control y Monitorización No Móvil o UCMNM): proveen al usuario de una interfaz gráfica desde la que puede monitorizar remotamente la posición geográfica del paciente y los parámetros médicos o bioseñales muestrados por sus sensores, así como controlar el proceso de monitorización. La unidad UCMM permite además al usuario desplazarse geográficamente mientras hace uso del sistema. Como indica la figura 2.1, los subsistemas que pertenecen al ámbito de este Proyecto son: Servidor de Control Central (SCC). Unidad de Control y Monitorización Móvil (UCMM). Unidad de Control y Monitorización No Móvil (UCMNM). El resto de componentes se han desarrollado en el proyecto Pasarela Bluetooth/GPRS para dispositivos móviles, realizado por Antonio Ángel Botella Galindo. El funcionamiento del sistema de monitorización de pacientes es el siguiente: cada paciente lleva consigo uno o varios sensores médicos inalámbricos que muestrean bioseñales, así como un GPS. Los sensores y el GPS envían la información muestreada y de posición al subsistema NI (Nodo Inteligente), que es portado también por el paciente. El sistema formado por sensores, GPS y NI se conoce genéricamente como iban (red de área corporal inteligente). Los sensores inalámbricos y el GPS se comunican con el NI mediante Bluetooth. La información recogida por todos los NI es retransmitida al subsistema SCC (Servidor de Control Central). Los NI se comunican con el SCC mediante GPRS o a través de Internet mediante conexión con Wi-Fi a un punto de acceso. Una vez en el SCC, las bioseñales muestreadas por los sensores y la información de posición están disponibles para que el personal médico usuario del sistema acceda a ellas a través de dos tipos de unidades: UCMM (Unidad de Control y Monitorización Móvil), si el usuario accede mediante terminal móvil, o UCMNM (Unidad de Control y Monitorización No Móvil), si el usuario hace uso del sistema desde un PC. Las UCMNM se comunican con el SCC a través de Internet, mientras que las UCMM se comunican con el SCC mediante GPRS, o a través de Internet mediante conexión con Wi-Fi a un punto de acceso. Una somera descripción de cada subsistema desarrollado en el presente proyecto y de su funcionamiento se aborda en el apartado 2.1.

17 Figura 2.1: Sistema Completo 5

18 6 CAPÍTULO 2. DESCRIPCIÓN DEL SISTEMA 2.1. Descripción de subsistemas Subsistema Servidor de Control Central (SCC) El objetivo principal del SCC es centralizar la información de los pacientes y actuar de pasarela entre el personal médico que quiere acceder remotamente a los datos de paciente, y las iban que recopilan la información del estado y localización de los pacientes. Entre sus funciones cabe destacar: Recogida de la información (parámetros médicos o bioseñales y localización) enviada por todas las iban de los pacientes. Opcionalmente, grabación en fichero de la información recibida y del resultado de su procesamiento. Retransmisión de la información procedente de las iban a las unidades de monitorización (UCMM y UCMNM). Actuación como pasarela entre las unidades de monitorización y los nodos inteligentes (NI) de las iban: el SCC reenvía a los NI los comandos de control que el personal médico ordena remotamente a una iban desde las unidades de monitorización. Verificación de la correcta y coherente configuración de los comandos de control y filtrado de los mismos Subsistema Unidad de Control y Monitorización Móvil (UCMM) Los objetivos que la unidad UCMM debe satisfacer son: Presentar al usuario de la UCMM la información que estén muestreando los sensores de un paciente concreto que se elija, en tiempo casi real. Mostrar al usuario la información de localización del paciente que seleccione, en tiempo cuasi real. Permitir al usuario la configuración remota de parámetros de una iban. Hacer posible que el usuario pueda controlar remotamente un sensor determinado. Permitir al usuario el control remoto del GPS. Transmitir al Servidor de Control Centrol (SCC) los comandos de control correspondientes a las peticiones de configuración y control solicitadas por el usuario.

19 2.1. DESCRIPCIÓN DE SUBSISTEMAS 7 Cumplir los objetivos anteriores, añadiendo el propósito de que el usuario pueda desplazarse geográficamente mientras hace uso del sistema. Para el cumplimiento de los objetivos anteriores, las funciones que la UCMM debe llevar a cabo son: Establecimiento de comunicación con el SCC. Descodificación y representación en una interfaz de usuario (IU) de la información muestreada por un sensor elegido, información que llega a la UCMM desde el Servidor Central (SCC). Representación en una IU de la información de localización del paciente escogido que llega a la UCMM desde el Servidor Central (SCC). Lectura desde una IU de los comandos de control introducidos por el usuario para configurar o controlar la iban, el GPS o un sensor determinado. Envío al SCC de los comandos de control generados a partir de las peticiones del usuario, para que sean retransmitidos al nodo inteligente(ni) de la iban Subsistema Unidad de Control y Monitorización No Móvil (UCMNM) Los objetivos de la unidad UCMNM son idénticos a los de la UCMM (véase apartado 2.1.2), salvo en la posibilidad de que el usuario pueda desplazarse geográficamente mientras hace uso del sistema. Las funciones que la UCMNM ha de efectuar no son exactamente las mismas que las propias de la UCMM, pero sí análogas. Véanse a continuación: Establecimiento de comunicación con el SCC. Representación en una interfaz de usuario (IU) de la información muestreada por todos los sensores de una iban de paciente. Esta información llega a la UCMM, ya descodificada, desde el Servidor Central (SCC). Representación en una IU de la información de localización de los pacientes escogidos, información que llega a la UCMM desde el Servidor Central (SCC). Lectura desde una IU de los comandos de control introducidos por el usuario para configurar o controlar la iban, el GPS o un sensor determinado. Envío al SCC de los comandos de control generados a partir de las peticiones del usuario, para que sean retransmitidos al nodo inteligente(ni) de la iban.

20 8 CAPÍTULO 2. DESCRIPCIÓN DEL SISTEMA

21 Capítulo 3 Tecnologías implicadas 3.1. Tecnologías de comunicación Wifi Es un conjunto de estándares para redes inalámbricas; en la actualidad hay tres tipos, basados cada uno de ellos en un estándar IEEE : IEEE b, IEEE g y IEEE a. En este Proyecto, el personal médico puede monitorizar remotamente a un paciente desde una computadora o desde un dispositivo móvil. Por esta necesidad de comunicación remota, es conveniente que el dispositivo móvil tenga acceso a Internet no sólo a través de la red móvil, sino también por otro medio como el que puede proporcionar Wifi (Wireless Fidelity), aunque éste fuera diseñado inicialmente con la finalidad de ser usado en redes locales inalámbricas. De los tres tipos de Wifi existentes, el perteneciente al punto de acceso a Internet utilizado en el proyecto está basado en el estándar IEEE g. Opera en la banda de los 2.4 GHz con una velocidad de 108 Mbps ([16]). La cobertura de esta tecnología inalámbrica dependerá del estándar elegido, la antena empleada, etc. Como ejemplo, un router de uso doméstico Wifi basado en el estándar b o g con una antena stock (helicoidal broadside [19]) puede tener un alcance de 45 metros en interior y 90 metros en exterior. El alcance varía también con la frecuencia de la banda. En la banda de los 2.4 GHz presenta mejor alcance que en la de 5 GHz, y menor alcance que la más antigua de 900 MHz. El alcance en exterior con mejores antenas puede llegar a ser de varios kilómetros, incrementándose en el caso de visión directa [18] GPRS y UMTS Con la finalidad de que personal médico pueda monitorizar a un paciente desde cualquier lugar, incluso aunque no haya cobertura Wifi, los terminales de monitorización móviles 9

22 10 CAPÍTULO 3. TECNOLOGÍAS IMPLICADAS deben disponer al menos de GPRS, o incluso ser dispositivos UMTS. GPRS (General Packet Radio Service), generación 2.5 de telefonía móvil, es una modificación de GSM (Global System for Mobile communications): en GSM, la forma de transmitir los datos era por conmutación de circuitos; precisaba que el circuito estuviese reservado permanentemente durante la comunicación, incluso aunque ésta estuviese ociosa. En GPRS la forma de enviar la información es mediante conmutación de paquetes. Se usa en redes GSM y ofrece velocidades de 40 Kbps en recepción, y 20 Kbps de transmisión [17]. UMTS (Universal Mobile Telecommunications System) es la tecnología sucesora de GSM, empleada por los móviles de tercera generación. Mejora GSM tanto en el posible número de usuarios como en la velocidad, que puede llegar a ser de 2Mbps. Utiliza comunicación terrestre basada en el interfaz radio W-CDMA (acceso múltiple de banda ancha por división de código) y soporta división de tiempo y frecuencia dúplex [32] Software de prueba de comunicaciones: Ethereal Ethereal es un software analizador de protocolos de red. Se emplea en desarrollar protocolos, encontrar fallos de comunicación y como herramienta para labores didácticas. Permite capturar en tiempo real los paquetes que circulan por una red y mostrarlos en una interfaz gráfica. Asimismo posee múltiples opciones de organización y filtrado de información. Con Ethereal (actualmente denominado WireShark) se pueden examinar datos de una red o los guardados en disco de alguna captura anterior. Ethreal es software libre y se ejecuta sobre Unix, Mac OS X y Microsoft Windows Lenguajes de programación y software asociado Java: J2SE y J2EE El éxito y la enorme difusión del lenguaje de programación Java, desarrollado por Sun Microsystems, es en la actualidad un hecho indiscutible. Java es hoy por hoy el lenguaje escogido para desarrollar aplicaciones basadas en redes y software de dispositivos, incluidos los inalámbricos, que se comunican a través de ellas [3]. Para cubrir las distintas necesidades de los usuarios, Sun ha creado tres diferentes versiones de Java: J2SE, J2EE y J2ME. A continuación se introduce a cada una de ellas con una somera descripción [3]. J2SE (Java 2 Platform, Standard Edition): representa el lenguaje Java estándar, sus herramientas y sus bibliotecas - que también se conocen como API (Application Programming Interface, interfaces de programación de aplicaciones)-.

23 3.2. LENGUAJES DE PROGRAMACIÓN Y SOFTWARE ASOCIADO 11 J2EE (Java 2 Platform, Enterprise Edition): orientada hacia el entorno empresarial, que por sus requisitos se enfoca hacia el desarrollo de aplicaciones de red distribuidas, de gran escala, y de acceso vía web. J2ME (Java 2 Platform, Micro Edition): destinada al desarrollo de aplicaciones para dispositivos electrónicos con capacidades computacionales, gráficas y de memoria limitadas, como teléfonos móviles, PDA y electrodomésticos inteligentes. La descripción de tecnología J2ME se continúa en el apartado A continuación, en los apartados y se profundiza sobre las ediciones J2SE y J2EE J2SE J2SE representa al lenguaje Java convencional, sus bibliotecas y sus herramientas. Java es a la vez un lenguaje de programación, y una plataforma: Como lenguaje de programación, es un lenguaje de alto nivel con las siguientes características: simple, orientado a objetos, distribuido, multihebra, dinámico, generador de código independiente del Sistema Operativo, robusto y seguro. En Java todo el código fuente se escribe, mediante un editor, en ficheros de texto con la extensión.java. Esos ficheros fuente son entonces compilados por el compilador javac, que produce como resultado ficheros con la extensión.class. Un fichero.class no contiene código nativo del procesador; en su lugar, contiene códigos de bytes (bytecodes) que son el lenguaje máquina de la Máquina Virtual Java (Java Virtual Machine, JVM). A partir de esos códigos de bytes se puede ejecutar la aplicación con alguna herramienta, p.e con un entorno de programación (denominados IDE, Integrated Development Environment) que empleará una instancia de la Máquina Virtual Java [20]. Como plataforma (una plataforma es un entorno hardware o software en el que se ejecuta un programa), es un plataforma exclusivamente software que se ejecuta por encima de otras hardware. La plataforma Java tiene dos componentes [20]: La Máquina Virtual Java (JVM), que ya ha sido mencionada. La Interfaz de Programación de Aplicaciones Java (Java Application Programming Interface o API ): Colección de componentes software que proveen de múltiples funcionalidades. Se agrupa en librerías, también conocidas como paquetes Java (packages)

24 12 CAPÍTULO 3. TECNOLOGÍAS IMPLICADAS J2EE J2EE proporciona herramientas para el diseño, desarrollo, ensamblado e instalación, basado en componentes, de aplicaciones del mundo empresarial, con el objetivo de reducir costes y tiempo de diseño. Estas aplicaciones suelen ser aplicaciones de red distribuidas, a gran escala y de acceso vía web. La plataforma J2EE emplea un modelo cliente-servidor distribuido y multinivel para aplicaciones empresariales. La lógica de programación se divide en componentes que pueden instalarse en diferentes máquinas, dependiendo del entorno al que pertenezcan: un componente J2EE es una unidad funcional software que se ensambla en una aplicación J2EE junto con sus propias clases y ficheros, y que se comunica con otros componentes J2EE. Es conveniente aclarar que la diferencia entre componentes J2EE y las clases Java radica en que los componentes J2EE son ensamblados en un aplicación y finalmente ejecutados y gestionados por un servidor J2EE [8]. Como se ha dicho, J2EE usa un modelo cliente-servidor multinivel. Véanse sus distintos niveles en la figura 3.1. Los niveles ordenados según la máquina a la que pertenezcan, con sus posibles componentes, son los listados a continuación: En la máquina del cliente: un único nivel, el Nivel de Cliente, cuyos componentes son: applets y Aplicaciones Cliente. En la máquina del servidor (llamado Servidor J2EE): dos niveles, que son los siguientes: Nivel Web (Web Tier). Sus componentes son: servlets y JSP (Java Server Pages). Para comprender en detalle estos componentes, véanse los apartados y Nivel de Negocios (Business Tier). Sus componentes son EJB (Enterprise Java Beans). Los EJB encapsulan lógica de programación y pueden instalarse en diferentes máquinas para ser accedidos remotamente. En la máquina del servidor de información (llamado Servidor de Base de Datos): un nivel, el Nivel de Información de Sistema (EIS Tier), compuesto por una o varias bases de datos. J2EE es un plataforma muy extensa que ofrece múltiples herramientas no mencionadas hasta ahora, cuya descripción escapa al propósito de este proyecto. A continuación se profundiza en el conocimiento de dos tecnologías que sí han sido especialmente importantes en la implementación del mismo: applets y servlets.

25 3.2. LENGUAJES DE PROGRAMACIÓN Y SOFTWARE ASOCIADO Applets En el Nivel de Cliente, se puede hacer una clasificación más genérica de los Clientes J2EE, que pueden ser de dos tipos [8]: Aplicaciones Cliente: una Aplicación Cliente también se ejecuta en la máquina cliente y provee a los usuarios de un modo de manejo tareas en el que se requiera una interfaz de usuario más compleja de la que puede ofrecer un lenguaje de marcado. Clientes web: un cliente web consta de dos partes: 1. Páginas web dinámicas que contienen varios tipos de lenguaje de marcado (HTML, XML, etc...), generadas por el Servidor J2EE. 2. Un navegador web que interpreta las páginas recibidas desde el servidor. Los clientes web son también llamados clientes ligeros (thin clients) porque generalmente no efectúan peticiones a bases de datos, ni ejecutan lógica complicada; tales operaciones complejas son delegadas al Servidor J2EE. El applet es un caso de Cliente web. Una página web recibida desde el Servidor J2EE puede incluir un applet embebido, que se trata de una pequeña aplicación cliente programada en Java la cual se ejecuta en la máquina virtual instalada en el navegador web. Los otros casos de este tipo de clientes reciben una página web creada desde servlets o JSP en el Servidor J2EE Servlets Las vistas de nivel superior sobre redes en Java pueden ser servlets, o bien JavaServer Pages (JSP), siendo ambos componentes del Nivel Web de J2EE. Tanto servlets como JSP proporcionan al programador una abstracción de la gestión de la concurrencia. Esta gestión de la concurrencia, que se hace de forma transparente para el programador, es una de las características de J2EE que han motivado su uso para el desarrollo de este Proyecto. Un requisito inherente a este Proyecto es la escalabilidad: un número de pacientes elevado y creciente no debe deteriorar la funcionalidad del Sistema: cada invocación a un servlet o a una JSP es manejada por una hebra o thread en el Servidor J2EE, garantizándose así el cumplimiento de requisitos de eficiencia y escalabilidad Software para el desarrollo de aplicaciones J2SE y J2EE Se ha precisado de herramientas para compilar, ejecutar, monitorizar, depurar y documentar las aplicaciones. Las herramientas empleadas se exponen a continuación.

26 14 CAPÍTULO 3. TECNOLOGÍAS IMPLICADAS Entorno de ejecución (JRE) y kit de desarrollo (JDK) de Java Entorno de ejecución (Java Runtime Environment, JRE): Esta herramienta incluye las librerías (API), la JVM y otros componentes para ejecutar applets y aplicaciones escritas en Java. Además, dispone de un plug-in que permite a los applets ejecutarse en los navegadores web más populares. El JRE es, asimismo, el fundamento de las tecnologías J2EE [21]. Kit de desarrollo (Java Development Kit, JDK): Es un superconjunto del JRE ya que lo contiene, añadiendo herramientas como compiladores y depuradores necesarios para desarrollar applets y otro tipo de aplicaciones. Para la edición J2SE de Java, el kit de desarrollo es el J2SDK [21] Entornos de desarrollo (IDE): Eclipse y NetBeans Eclipse es una comunidad dedicada al desarrollo de código abierto cuyos proyectos están enfocados a la construcción de una plataforma de desarrollo software [22]. Eclipse es muy conocido por su IDE (entorno de desarrollo o programación) para Java, y este aspecto ha motivado su utilización en el Proyecto: con Eclipse se pueden desarrollar aplicaciones J2SE, J2EE y J2ME. La versión empleada ha sido Eclipse A continuación se indican algunos aspectos relevantes del manejo de Eclipse: Los elementos de la interfaz de usuario de Eclipse pueden clasificarse en dos tipos: vistas y editores. Por un lado, los editores permiten generalmente realizar una tarea completa; por otro, las vistas proporcionan funciones de apoyo. Para el uso de Eclipse un concepto importante es el de perspectiva : una perspectiva de Eclipse es una agrupación de editores y vistas que dan soporte a una actividad completa del proceso de desarrollo software [23]. En el desarrollo de este Proyecto se ha trabajado con la perspectiva Java. Durante el desarrollo del Proyecto, se migró desde Eclipse a otro IDE diferente: Netbeans. La razón es que este último incorpora una herramienta para el desarrollo de interfaces gráficas. A continuación se presenta una descripción del segundo IDE utilizado para la implementación del Proyecto: Netbeans. El IDE NetBeans es un Entorno de Desarrollo Integrado gratuito, de código abierto, para desarrolladores de software [24]. Su manejo es muy similar al de Eclipse. Como se acaba de apuntar, el motivo de utilizar Netbeans en lugar de Eclipse ha sido que el primero incorpora una herramienta para el desarrollo de interfaces gráficas: Project Matisse, lo que reduce el tiempo de desarrollo y ampliación del sistema. Asimismo, Netbeans está provisto de herramientas para el desarrollo de aplicaciones web, y posee un contenedor de servlets integrado: Tomcat.

27 3.2. LENGUAJES DE PROGRAMACIÓN Y SOFTWARE ASOCIADO Software para la instalación de las aplicaciones Como se ilustra en la figura 3.1, los servlets y las JSP forman el Nivel Web de J2EE. La implementación del Sistema diseñado en este Proyecto incluye la tecnología servlet. Para la instalación de servlets es necesario un contenedor de servlets, cuya funcionalidad es proporcionada por el software Tomcat. El origen de Tomcat es el siguiente: las especificaciones de las tecnologías servlet y JSP han sido (y son) desarrolladas por el Java Community Process, perteneciente a Sun Mycrosistems. A su vez, la Fundación de software Apache ha realizado la implementación de referencia de los estándares servlet y JSP, como parte del extenso Proyecto Jakarta. Al área del Proyecto Jakarta asociada a los servlets y las JSP se le denomina Tomcat. Tomcat es un servidor que ejecuta servlets, por lo que se le conoce como contenedor de servlets o motor de servlets [3]. Los servlets comunican clientes y servidores por medio del protocolo Http. El funcionamiento de Tomcat puede resumirse en los siguientes pasos [3]: 1. El proceso comienza con un cliente que envía una petición 1 Http al servidor (que en este caso es una máquina con Tomcat instalado); esto se produce, por ejemplo, cuando desde un navegador web se invoca una URL. 2. Tomcat recibe la petición. 3. Tomcat transmite la petición al servlet apropiado de entre los que posee instalados. 4. El servlet lleva a cabo el procesamiento de la petición, lo que puede incluir la comunicación con otros componentes J2EE, o la interacción con alguna base de datos. 5. A continuación envía la respuesta con los resultados al cliente, generalmente en un documento HTML. La versión utilizada en el Proyecto ha sido Tomcat Software adicional Para las pruebas realizadas al sistema, se ha precisado de un herramienta para monitorizar el procesamiento y uso de memoria de una aplicación: Netbeans Profiler. Es un módulo agregado (add-on) a Netbeans. 1 Es conveniente aclarar que cuando un cliente se comunica por iniciativa propia con un servidor, a través de Http, se dice que efectúa una petición Http. La información que entonces el servidor envía al cliente se encapsula en lo que se conoce como respuesta Http. Este mecanismo es el paradigma petición-respuesta en el que se basa Http.

28 16 CAPÍTULO 3. TECNOLOGÍAS IMPLICADAS J2ME J2ME es la versión de Java enfocada al desarrollo de aplicaciones para dispositivos electrónicos con capacidades computacionales y gráficas limitadas, como teléfonos móviles, PDA y electrodomésticos inteligentes. Constituye un subconjunto de la edición J2SE: comparte con ella treinta y siete clases [14], a las que añade otras propias. Algunos conceptos importantes de la plataforma J2ME son [13]: Configuración: mínimo número de API para desarrollar aplicaciones de un conjunto muy genérico de dispositivos. Existen dos configuraciones: Connected Limited Device Configuration (CLDC): para dispositivos con capacidades limitadas de memoria y procesamiento. Los requisitos mínimos hardware de CLDC la hacen apropiada para los teléfonos móviles, PDA, etc... El teléfono móvil empleado en el Proyecto tiene Configuración CLDC. Connected Devide Configuration (CDC): para dispositivos con mejores prestaciones. No se profudizará más en ella porque no ha sido utilizada en el Proyecto. Perfil: el perfil, conocido como MIDP (Mobile Information Device Profile), es el nivel superior a la Configuración en la arquitectura J2ME. Se trata de un grupo de API más específicas de un subconjunto de dispositivos, que añade funcionalidades a la Configuración. Véase la figura 3.2, que esquematiza la arquitectura J2ME. MIDlet: una aplicación J2ME desarrollada bajo MIDP se denomina MIDlet. Los MIDlets se empaquetan en ficheros con extensión.jar, que contienen los siguientes elementos: La clase MIDlet. Clases suplementarias. Recursos (archivos de sonido, de imagen,...) El fichero de manifiesto, cuya extensión es.mf, que describe el contenido del.jar. El descriptor (fichero con extensión.jad) que, al igual que el manifiesto, define una serie de atributos del MIDlet. Preverificación: una vez compilado el MIDlet, sus clases son almacenadas mediante códigos de bytes (bytecodes) en un fichero con extensión.class. La preverificación consiste en comprobar que todas las operaciones que lleva a cabo la aplicación están permitidas. Se realiza para descargar de esa tarea a la máquina virtual y permitir así que ésta sea lo más ligera posible. Máquina virtual: según la Configuración empleada, hay dos tipos de máquina virtual:

29 3.2. LENGUAJES DE PROGRAMACIÓN Y SOFTWARE ASOCIADO 17 Figura 3.1: Arquitectura J2EE [8]. Figura 3.2: Arquitectura de J2ME [14].

30 18 CAPÍTULO 3. TECNOLOGÍAS IMPLICADAS KVM: su nombre es Kilo Virtual Machine, porque sólo necesita unos poco Kilobytes para funcionar [14]. Es la máquina virtual para la Configuración CLDC. CVM: Compact Virtual Machine, es la máquina virtual para la Configuración CDC. En los siguientes apartados se expone el software necesario para el desarrollo de un MIDlet o aplicación J2ME Software para el desarrollo de aplicaciones J2ME Kit de desarrollo software (SDK) Como se ha visto en el apartado , para la programación en Java es necesario disponer de un kit de desarrollo o JDK. En J2ME, habrá un JDK para cada familia de dispositivos, por ejemplo los teléfonos móviles. El mencionado JDK contendrá las clases del Perfil (véase la arquitectura J2ME en el apartado 3.2.2) característico de esa familia. Para el teléfono empleado en el Proyecto, un Nokia de la Serie 80 modelo 9500 Communicator, el JDK se denomina Series 80 Platform SDK s for Symbian OS, for Java. Este SDK emula el comportamiento del dispositivo Nokia, y lo consigue porque su emulador está basado en el mismo software del propio dispositivo [26]. Series 80 Platform SDK s for Symbian OS, for Java contiene los siguientes elementos: Emulador del teléfono: con él se puede probar la aplicación J2ME o MIDlet, sin tener que instalarla en el teléfono. API. Documentación. Ejemplos Entornos de desarrollo (IDE) Los IDE usados para el desarrollo de aplicaciones J2ME han sido los mismos que para las aplicaciones J2SE y J2EE: Eclipse y Netbeans. Véase el apartado El segundo IDE empleado en el Proyecto, Netbeans, necesita de un módulo añadido (add-on) para el desarrollo de aplicaciones J2ME: Mobility Pack, que provee de algunas herramientas de desarrollo adicionales Carbide Carbide.j (anteriormente conocido como Nokia Developer s Suite for J2ME) es un instrumento de desarrollo y verificación software para programadores de aplicaciones J2ME en dispositivos Nokia [27]. Provee de herramientas para:

31 3.3. LENGUAJE DE MODELADO: UML 19 Creación de aplicaciones MIDP y Perfil Personal (véase arquitectura J2ME en 3.2.2). Instalación de paquetes. Firma de aplicaciones. Instalación de la aplicación en dispositivo. Manejo, configuración y ejecución de los emuladores de SDK Nokia Software para la instalación de las aplicaciones Nokia PC Suite es el software empleado para instalar en el teléfono las aplicaciones J2ME o MIDlet. Sus principales características son [28]: Transferencia automática y segura de datos entre el teléfono y el PC. Conexión inalámbrica (Bluetooth, infrarrojos) o por cable. Conexión a Internet rápida y sencilla Software adicional Se ha utilizado también una sencilla aplicación software para capturar imágenes de las pantallas del teléfono móvil: ZScreen Capture for Series 80 Version Lenguaje de modelado: UML Java es un lenguaje de programación orientada a objetos (POO). Por su parte, UML (Lenguaje Unificado de Modelado) un lenguaje gráfico que proporciona diferentes diagramas para modelar y representar análisis, requerimientos y diseños orientados a objetos, con el empleo de una notación común [3]. Las notaciones estándar de UML para expresar los diseños y análisis orientados a objetos (A/DOO) los hace independientes del desarrollo. Algunos de los diagramas UML más representativos son: diagrama de casos de uso, de clases, de secuencia, de estados, de actividad, de componentes y de despliegue o instalación. Véase a continuación una escueta introducción a los mismos, disponible en [33]: Diagrama de casos de uso: ilustra una unidad de funcionalidad del sistema. Su objetivo principal es ayudar a visualizar los requerimientos funcionales de un sistema, incluyendo la relación entre procesos y actores (seres humanos que interactúan con el sistema), así como entre diferentes diagramas de casos de uso entre sí. Su representación es un óvalo que contiene el nombre del caso de uso, y el dibujo de una persona unida al óvalo con una flecha.

32 20 CAPÍTULO 3. TECNOLOGÍAS IMPLICADAS Diagrama de clases: muestra cómo las diferentes entidades, modeladas por clases, están relacionadas unas con otras. En este diagrama cada clase está representada por un rectángulo con tres secciones horizontales que contienen el nombre de la clase, sus atributos y sus métodos, respectivamente. Diagrama de secuencia: esquematiza el flujo detallado para un caso de uso específico, o para una parte de éste. El esquema resultante refleja la secuencia de llamadas entre los diferentes objetos. Se lee en dos dimensiones: vertical y horizontal. La vertical detalla el paso de mensajes entre objetos y el orden temporal en el que ocurren. En horizontal, aparecen los objetos a los que son enviados esos mensajes. Diagrama de estados: modela los diferentes estados en los que una clase se puede encontrar, y cómo se producen las transiciones de estado a estado. Diagrama de actividad: muestra el control de flujo del procesamiento de una actividad. Se puede usar para modelar procesos tanto de alto como de bajo nivel; no obstante, al ser menos detallados (por ejemplo en comparación con los diagramas de secuencia) hacen más fácilmente comprensibles los procesos de alto nivel. Su notación es la siguiente: comienza con un círculo del que parte una flecha hacia la primera actividad, representada por un rectángulo con el nombre de la actividad y bordes redondeados. Las siguientes actividades se conectan entre sí directamente mediante flechas, o a través de nodos de decisión que representan el flujo del proceso. Diagrama de componentes: proporciona una vista de las dependencias que el software diseñado tiene de otros componentes software en el sistema, como por ejemplo librerías (API). Diagrama de despliegue o instalación: traza un esquema que enseña cómo el sistema diseñado puede ser físicamente instalado en un entorno hardware. En él se puede observar en qué dispositivos se ejecutan los componentes software del sistema y cómo se comunican entre sí estos dispositivos. Para representar una máquina o dispositivo, este tipo de diagrama usa nodos, cuyo aspecto es el de un cubo tridimensional con el nombre del nodo. En la presente memoria se ha empleado UML con el objetivo de documentar, esquematizar e ilustrar los diseños software realizados. Para ello se ha utilizado un sofware de edición de diagramas UML: Visual Paradigm for UML 6.0. La versión de UML empleada en este proyecto ha sido UML 2.1 [34].

33 3.4. PLATAFORMAS HARDWARE Y SISTEMAS OPERATIVOS Plataformas Hardware y Sistemas Operativos Dispositivos móviles Para la implementación de una unidad de monitorización móvil se cuenta con el teléfono Nokia 9500 Communicator. Sus especificaciones técnicas clave son [15]: Tecnología inalámbrica Bluetooth. Memoria integrada de 80 MB, admite memoria adicional con tarjeta de memoria (MMC). Conectividad de datos de alta velocidad con EGPRS (EDGE). Acceso a LAN inalámbrica. Java MIDP 2.0 y Perfil personal. Conexión USB (Cable de Conexión Nokia DKU-2). Navegador de Internet Opera. Transmisión de datos: Hasta 11 Mbit/s mediante LAN inalámbricas. Hasta 236,8 kbps en redes EDGE. Hasta 53,6 kbps en redes GPRS. Batería: Modelo: BP-5L Capacidad: 1300 mah Tiempo en conversación: hasta 4-6 horas Tiempo en espera con WLAN desactivada: hasta horas WLAN ociosa: hasta horas El Sistema Operativo del teléfono móvil es Symbian 7.0 (plataforma serie 80). El sistema operativo Symbian es producto de la alianza de varias empresas de telefonía móvil, como Nokia, Sony Ericsson, Samsung, Siemens, Arima, Benq, Fujitsu, Lenovo, LG, Motorola, Mitsubishi Electric, Panasonic, Sharp, etc. La mayoría de los móviles con Symbian son de Nokia, son pocos los modelos de otros fabricantes [25].

34 22 CAPÍTULO 3. TECNOLOGÍAS IMPLICADAS Computadoras El desarrollo y prueba del software se ha realizado en una computadora de las siguientes características: Procesador Pentium IV a 3.0 GHz. Memoria RAM DDR400 de 512 MB. Disco duro de 80 GB. El Sistema Operativo instalado en ella ha sido Windows XP Pro SP 2.

35 Capítulo 4 Subsistema Servidor de Control Central 4.1. Arquitectura La arquitectura del subsistema Servidor de Control Central (SCC) que se muestra en el esquema de la figura 4.1 está compuesta por cuatro módulos. El módulo principal, denominado Servidor, y tres módulos de interfaz para la interacción con: Los nodos inteligentes de las iban. Las unidades de monitorización móviles. Las unidades de monitorización no móviles (PC). En los siguientes apartados se describen las funciones y estructura de cada uno de estos módulos Interfaz Servidor/NI Funciones La función del Interfaz Servidor/NI es comunicar el módulo Servidor con los NI. Esto implica: Recibir y entregar al módulo Servidor la información procedente de todos los nodos inteligentes (NI) de las iban, que incluye datos recopilados por los sensores médicos y el dispositivo GPS. Enviar a los NI los comandos de control generados desde las unidades de monitorización (UCMM, UCMNM). 23

36 24 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Arquitectura La comunicación entre SCC y NI se puede realizar de dos modos distintos, por ello, el Interfaz Servidor/NI se divide en sendos módulos: Interfaz Servidor/NI Http Interfaz Servidor/NI TCP-UDP Interfaz Servidor/UCMM La función del Interfaz Servidor/UCMM es comunicar el módulo Servidor con las UCMM. Esto implica: Enviar a la UCMM la información que una iban esté obteniendo-iban seleccionada en la propia UCMM-. Recoger y transferir al módulo Servidor los comandos de control enviados desde la UCMM Interfaz Servidor/UCMNM Las funciones de este interfaz son análogas a las del Interfaz Servidor/UCMM. La función del Interfaz Servidor/UCMNM es comunicar el módulo Servidor con las UCMNM. Esto implica: Enviar a la UCMNM la información que una iban esté obteniendo-iban seleccionada en la propia UCMNM-. Recoger y pasar al módulo Servidor los comandos de control enviados desde la UCMNM Servidor Las funciones del módulo Servidor son: Funciones asociadas a la interfaz con el NI: Recibir la información, a través del módulo Interfaz Servidor/NI, de los nodos inteligentes (NI) de todas las redes de área corporal.

37 4.1. ARQUITECTURA 25 Enviar los comandos de control al Interfaz Servidor/NI, para que éste los retransmita al NI destinatario. Recibir, del Interfaz Servidor/NI, las respuestas de los NI a los comandos de control. Estas respuestas forman parte del diálogo que mantienen SCC y NI para gestionar los comandos de control. Este diálogo sigue un protocolo diseñado para este Proyecto, protocolo que se detalla en el apéndice A. Gestionar la información sobre el estado de cada sensor en cuanto al diálogo que mantiene (a través del NI) con el SCC. Este diálogo sigue el protocolo mencionado. Funciones asociadas a la interfaz UCMM y UCMNM: Enviar, a las UCMM que solicitan la monitorización de un paciente, la información que el módulo Servidor ha recibido, añadiendo a esta información el modo de funcionamiento del sensor y cifrándola para su transmisión. Enviar, a las UCMNM que solicitan la monitorización de un paciente, la información que el módulo Servidor ha recibido. Se envía la misma información, pero con las tramas de datos ya descodificadas, y añadiendo tanto identificador del paciente como el modo de funcionamiento del sensor. Recibir los comandos de control generados desde la UCMM y la UCMNM. Funciones de control: Gestionar y registrar la información sobre el modo de funcionamiento de cada sensor. Comprobar la coherencia de la información recibida de los NI, con el modo de funcionamiento del sensor operativo en ese momento. Filtrar los comandos de control, comandos que el personal médico ordena remotamente a un sensor concreto, y que llegan al módulo Servidor desde el Interfaz Servidor/UCMM o desde el Interfaz Servidor/UCMNM. El filtrado consiste en comprobar la coherencia del comando de control y sus parámetros asociados. El comando en sí ha de ser coherente con el tipo de sensor al que va destinado, y el modo de funcionamiento del mismo en el momento de ordenar el comando. Los parámetros asociados han de tener valores dentro de los rangos específicos de cada tipo de comando, para evitar funcionamientos espúreos. Funciones de procesamiento: Descifrar la información recibida de todas las iban.

38 26 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Opcionalmente, grabar en fichero la información recibida y el resultado de su procesamiento. Identificar, a partir de la información recibida de los NI, el paciente a quien corresponde. Conocer, de la información recibida de los NI, a cuál de los sensores del paciente pertenece el dato recibido, o si es información de posición obtenida por el GPS. Extraer y descodificar las tramas de datos que vienen en la información recibida de los NI. Estas tramas son las que contienen la información muestreada por los sensores y la información de posición geográfica del paciente Diseño software El SCC provee de servicios a clientes remotos. Con el fin de que estos clientes puedan conectarse con el servidor remotamente utilizando Internet, que es un medio adecuado y ampliamente difundido para el desarrollo de aplicaciones distribuidas, se ha de diseñar un servidor web adaptado a las necesidades del Sistema. Como se ha anticipado en el capítulo 3, se ha decidido usar Java como lenguaje de programación, aprovechando que posee una versión para el desarrollo de aplicaciones web: J2EE. De hecho, uno de los componentes de la arquitectura de J2EE, el Servidor J2EE [8], se ajusta perfectamente a los requisitos del subsistema SCC. Por ello, se ha diseñado el SCC como un Servidor J2EE Diseño software del Interfaz Servidor/NI Para desarrollar el Interfaz Servidor/NI se ha tenido en cuenta que la interación entre el NI y el SCC es una relación cliente-servidor. Dicha relación cliente-servidor se basa fundamentalmente en la información, recogida por el nodo inteligente(ni) de las iban o cliente, que es retransmitida al SCC o servidor. En este punto es conveniente decir que el protocolo de comunicación entre NI y SCC es específico de este Proyecto. Los paquetes intercambiados entre NI y SCC, cuyo formato se detalla en el apéndice A, son de dos clases: Datos: Datos de posición geográfica y estado del paciente recogidos por la iban, que el NI envía al SCC. Control: Los paquetes de control pueden a su vez clasificarse en:

39 4.2. DISEÑO SOFTWARE 27 Comandos de control: Comando de configuración del modo de funcionamiento de un sensor. Comando de configuración del umbral de un parámetro médico o bioseñal, para la detección de alertas. Comando de establecimiento del tiempo de monitorización entre envíos. Este tiempo es la duración del intervalo en el que se recopilan los datos muestreados por el sensor, antes de ser retransmitidos al SCC. Comando de reinicio de un sensor. Control de la transmisión: Indicación de que el sensor se ha desconectado de la iban. Confirmación positiva a un comando: el comando ha sido ejecutado con éxito. Confirmación negativa a un comando: el sensor se encuentra operativo pero no se ha podido ejecutar el comando con éxito. Respuesta de error a un comando: no se ha podido ejecutar el comando porque el sensor no se encuentra operativo El Interfaz Servidor/NI se divide en dos interfaces, como se introdujo en el apartado , que son: Interfaz Servidor/NI Http. Interfaz Servidor/NI TCP-UDP. El diseño software de ambos se aborda a continuación Diseño software del Interfaz Servidor/NI Http La comunicación entre NI y SCC se lleva a cabo utilizando HTTP Justificación: empleo de servlets El cliente (NI) sube información al servidor (SCC). Éste, independientemente de que realice o no una acción, siempre responde al cliente. Se trata por tanto, de un modelo petición-respuesta. En Java, las vistas de nivel superior sobre las redes se basan en dicho modelo de comunicación petición-respuesta [3]. Las vistas de nivel superior sobre redes en Java pueden ser servlets, o bien JavaServer Pages (JSP). Tanto servlets como JSP abstraen para el programador la gestión de la concurrencia. En el Sistema que este Proyecto desarrolla, el SCC soporta múltiples peticiones concurrentes de

40 28 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL los NI. Esta gestión de la concurrencia, de forma transparente para el programador, es una de las características de J2EE que han motivado su uso para el desarrollo de este Proyecto. Los servlets y las JSP constituyen el nivel Web de J2EE. Otra característica inherente a este Proyecto es la escalabilidad del servidor: un número de pacientes elevado y creciente no debe perjudicar la funcionalidad del sistema. Cada invocación a un servlet o a una JSP es manejada por una hebra o thread en el servidor, garantizando así el cumplimiento de requisitos de eficiencia y escalabilidad. Se han elegido los servlets en lugar de las JSP principalmente por las siguientes razones: Los servlets permiten un nivel de detalle a más bajo nivel que las JSP. Ese nivel de detalle ha sido imprescindible para implementar el protocolo de comunicación (apéndice A) entre los NI y el SCC. De hecho, las JSP se han implementado a partir de los servlets [3]. Normalmente, las JSP se emplean cuando el contenido de lo que se envía al cliente es mayoritariamente texto estático y marcas, y sólo parte del contenido se genera mediante código Java[3]. Este no es el caso de este Proyecto, ya que el módulo Servidor, dentro del SCC, efectúa un extenso procesamiento de los datos recibidos. Dicho procesamiento implica un amplio desarrollo de código Java, lo cual no es coherente con la filosofía de las JSP. Por otro lado, la filosofía de los servlets es devolver al cliente una pequeña porción de texto estático o marcas, incluso algunos servlets no devuelven contenido alguno. En su lugar, realizan procesamiento e invocan a su vez a otros servlets o JSP. Otras ventajas del empleo de servlets son: Se ejecutan en una Máquina Virtual Java (JVM), por tanto son seguros y portables. Los servlets, que son invocados mediante una URL desde un navegador web, operan solamente dentro del dominio del servidor: al contrario que los Java applets, no necesitan soporte Java en el navegador web. Otra ventaja de los servlets es que son portables: tanto para sistemas operativos, por ser tecnología Java, como para servidores web, ya que los servidores web más importantes soportan servlets. Por último los servlets son, junto con las ya descartadas JSP, uno de los posibles componentes de un Servidor J2EE - como ya se ha justificado, el SCC es un Servidor J2EE-.

41 4.2. DISEÑO SOFTWARE Funcionamiento de los servlets Un servlet es un extensión genérica del servidor web, una clase Java que se carga dinámicamente para expandir la funcionalidad del servidor [4]. Al servidor que ejecuta un servlet se le conoce como contenedor de servlets o motor de servlets [3]. Los servlets comunican clientes y servidores a través del protocolo Http. Cuando un cliente envía una petición Http, el contenedor de servlets recibe la petición y la dirige al servlet apropiado. Entonces, para cada petición, se instancia una copia del servlet que se ejecuta en un nuevo thread. El servlet efectúa el procesamiento de la petición, y devuelve al cliente una respuesta, con o sin contenido Desarrollo software del Interfaz Servidor/NI Http El Interfaz Servidor/NI Http se ha desarrollado con un servlet. Para ello, se ha implementado una clase que extiende la clase abstracta HttpServlet. A través de los métodos doget() y dopost(), de HttpServlet, se accede a unos objetos que proporcionan el acceso a los flujos de entrada y salida. Dichos flujos, basados en caracteres o en bytes, permiten al servlet leer datos del cliente y enviarle una respuesta. La opción adecuada para el Proyecto es usar los flujos basados en bytes. El servlet que constituye el Interfaz Servidor/NI Http se ha desarrollado en la clase ServletA, que extiende (indirectamente) HttpServlet. El diagrama UML de clases que contiene a dicha clase puede contemplarse en la figura 4.2. En dicha figura aparecen otras clases e interfaces, que se irán explicando a lo largo de la memoria. Uno de los métodos más importantes de la clase ServletA, clase que implementa el Interfaz Servidor/NI Http, es dopost(). Para comprender el uso de este método, es necesario exponer algunos aspectos del protocolo Http: Hay dos tipos de petición Http: POST y GET. El NI es el cliente que efectúa esa petición Http al SCC, principalmente para subirle la información recogida en su iban. Se he elegido el tipo de petición POST, por las siguientes razones: GET se emplea para pedir datos al servidor. Para hacerlo adjunta unos pocos parámetros que especifican la petición. POST en cambio se emplea para subir datos al servidor. En este Proyecto los clientes son los NI, y su principal función es subir al SCC la información recogida por las iban. Por ello, la petición POST es más adecuada que la petición GET. La petición Http GET está limitada en el tamaño de los datos que puede enviar al servidor. La petición POST no presenta dicha limitación.

42 30 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL La petición Http GET está compuesta por una cadena de caracteres. No podrían enviarse, por tanto, bytes que no tuviesen representación como caracteres ASCII. La petición POST se forma a partir de un flujo de bytes, ya tengan éstos representación como caracteres o no. En consecuencia, en este aspecto también POST es más apropiado que GET. En el código del servlet, para acceder a los datos enviados por el cliente y responderle, se dispone, como ya se ha comentado, de los métodos doget() y dopost(). Ya que la petición Http que realiza el NI al SCC es de tipo POST, el método empleado en el servlet para atenderla es dopost(). La clase ModeloPaciente también forma parte del Interfaz Servidor/NI Http. Posee una referencia a ServletA e invoca sus métodos. La funcionalidad de esta clase se expone con mayor profundidad en el apartado Diseño del Interfaz Servidor/NI TCP-UDP Comunicaciones El segundo modo de comunicación entre NI y SCC es TCP-UDP. En este modo de comunicación, hay que distinguir que: Los paquetes de control intercambiados entre NI y SCC se envían por TCP. Se emplean dos conexiones TCP distintas para los paquetes de control que van del NI al SCC, y para los que van del SCC al NI. El motivo es ahorrar procesamiento al NI, dispositivo de procesamiento limitado. Las dos conexiones son: Una conexión socket TCP de paquetes de control entrantes al SCC, permanente. Una conexión socket TCP de paquetes de control salientes del SCC, temporal. Para cada paquete de control saliente del SCC, se abre un nuevo socket TCP, se envía, y se cierra el socket. El hecho de que sea temporal tiene como objetivo mejorar la eficiencia de procesamiento en el NI. La justificación de este comportamiento compete al ámbito del proyecto Pasarela Bluetooth/GPRS para dispositivos móviles. Los paquetes de datos son enviados por el NI al SCC sobre UDP Diseño software Para diseñar el Interfaz Servidor/NI TCP-UDP se ha partido de un servlet al que se ha extendido su funcionalidad. De este modo el servlet, además de escuchar y atender peticiones Http, va a :

43 4.2. DISEÑO SOFTWARE 31 Escuchar y atender peticiones TCP. Abrir puertos UDP. Para dotar al servlet de esta nueva funcionalidad, se ha implementado la clase DaemonHttp- ServletTCP. El desarrollo de dicha clase se ha realizado a partir de la clase DaemonHttpServlet, disponible en [5]. La clase DaemonHttpServletTCP aparece en el diagrama de clases UML de la figura 4.2. Los principales métodos de DaemonHttpServletTCP, relativos a su funcionalidad como Interfaz Servidor/NI TCP-UDP, son: init(): este método extiende al de HttpServlet. Instancia un servidor de sockets TCP en la hebra DaemonTCP. getsocketport(): proporciona el socket TCP por el que escucha el servidor de sockets TCP. handleclienttcp(): método abstracto para manejar cada nueva conexión TCP abierta. La clase ServletA implementa dicho método. El servlet al que se añade esta funcionalidad, es el mismo con el que se ha implementado el Interfaz Servidor/NI Http, es decir, el servlet ServletA. La clase ServletA extiende a DaemonHttpServletTCP e implementa sus métodos abstractos. Se recuerda que DaemonHttpServletTCP extiende a su vez de HttpServlet (véase diagrama de clases UML en la figura 4.2). Se dispone, por tanto, de un servlet (clase ServletA) que constituye el Interfaz Servidor/NI Http, y a la vez el Interfaz Servidor/NI TCP-UDP. Es interfaz Http porque hereda indirectamente de HttpServlet, e interfaz TCP-UDP porque hereda directamente de DaemonHttpServletTCP. La clase ModeloPaciente también forma parte del Interfaz Servidor/NI TCP-UDP. Una vez establecido el interfaz TCP-UDP, es la clase ModeloPaciente la que se encarga de escuchar y transmitir por los puertos TCP y UDP abiertos. La funcionalidad de esta clase se expone con mayor profundidad en el apartado Diseño software del Interfaz Servidor/UCMNM Justificación: estudio previo Las UCMNM se han diseñado con applets Java, como se detalla en el capítulo 6. Por tanto, el Interfaz Servidor/UCMNM es un interfaz servidor/applet. Existen tres posibilidades para comunicar un servidor y un applet [4]:

44 32 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL 1. Http: el applet realiza peticiones Http al servidor, y éste le devuelve las correspondientes respuestas. 2. Socket: el applet establece una conexión socket con el servidor. El servidor podría escuchar por un puerto en particular y comunicarse con el applet usando un protocolo prefijado. 3. RMI (Remote Method Invocation): esta tecnología posibilita que un applet invoque métodos de un objeto Java que se esté ejecutando en el servidor. También permite el comportamiento recíproco: que el objeto pueda invocar métodos del applet. En los siguientes apartados se exponen las ventajas e inconvenientes de cada una de estas opciones Análisis de la opción Http Ventajas de la opción Http: Fácil de programar. Funciona incluso para applets ejecutados tras un cortafuegos o firewall. Permite al applet comunicarse con un programa escrito en cualquier lenguaje. Permite comunicación segura. Un applet puede comunicarse con un servidor seguro usando el protocolo encriptado HTTPS (HTTP+SSL). Desventajas de la opción Http: No es posible la comunicación interactiva. Ello es debido a las características inherentes del paradigma petición/respuesta de Http. Es lenta. Su justificación está relacionada con la de la desventaja anterior: hay que restablecer un nuevo canal de comunicación para cada petición y respuesta. Sólo el applet puede iniciar la comunicación. Si se emplea estrictamente el paradigma petición/respuesta de Http, el servidor debe esperar pasivamente a que el applet efectúe una petición para devolverle una respuesta Análisis de la opción socket Ventajas de la opción socket: Permite comunicación permanente y bidireccional. El programa del lado del servidor puede ser más eficiente.

45 4.2. DISEÑO SOFTWARE 33 Desventajas de la opción socket: Falla para applets ejecutados tras cortafuegos. El código del servidor es más complicado. Puede requerir del desarrollo de un protocolo propio. Para este caso el servidor no es Http, y no puede ser convenientemente accedido por un navegador web Análisis de la opción RMI (Remote Method Invocation) Ventajas de la opción RMI: Se trata de un paradigma orientado de objetos, que es por tanto de alto nivel: las peticiones pueden ser hechas como invocaciones a métodos; las respuestas pueden ser recibidas como objetos serializados o incluso como referencias a otros objetos remotos. El servidor puede tomar la iniciativa en la comunicación: puede notificar a los applets la disponibilidad de una información para la que previamente se han registrado. Funciona incluso a través de cortafuegos: la capa de transporte RMI intenta hacer conexiones socket directas, y si fallan porque el applet se encuentra tras un cortafuegos, automáticamente pasa a operar sobre Http. Desventajas de la opción RMI: La gestión es complicada, porque usa clases especiales para cada objeto remoto, y requiere utilizar un registro de nombres del cual los clientes obtienen referencias a los objetos remotos. Algunos navegadores web, en sus versiones antiguas, no lo soportan. Sólo puede ser usado por clientes Java Justificación: decisión La alternativa que se ha elegido es RMI porque, además de ser la opción tecnológicamante más avanzada, flexible y de alto nivel, sus desventajas son superables: Es una técnica complicada, pero para el caso concreto de comunicación applet/servlet es ridículamente simple [4]. Progresivamente, las nuevas versiones de los navegadores web van incluyendo RMI. Aunque sólo puede ser usado por clientes Java, para el sistema propuesto no constituye un problema ya que la UCMNM es un applet Java (véase en capítulo 6).

46 34 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Desarrollo Como ya se ha indicado, se ha decidido usar la tecnología RMI para comunicar la UCMNM con el SCC ( ). A continuación se describe el Interfaz Servidor/UCMNM que los comunica, del lado del módulo Servidor. La comunicación entre un applet y un servlet mediante RMI presenta muchas facilidades [4]. El acceso al módulo Servidor a través de los interfaces diseñados en este Proyecto anteriormente presentados, se lleva a cabo mediante un servlet. Se puede, por tanto, continuar empleando el servlet para acceder al módulo Servidor desde la UCMNM. De este modo se aprovecha la avanzada tecnología RMI y la flexibilidad que ésta proporciona para el caso concreto applet/servlet. El servlet utilizado es el mismo que implementa los módulos Interfaz Servidor/UCMNM e Interfaz Servidor/NI. Se trata del servlet descrito en al que ahora se extiende su funcionalidad para dotarlo de RMI. Para ello debe implementar una interfaz específica. Dicha interfaz declara los métodos que pone a disposición de los clientes remotos, y extiende a la interfaz Remote para que el objeto que lo implementa sea a su vez remoto. Esta interfaz específica es ServidorMonitorizacion. En el diagrama de clases de la figura 4.2 se observa cómo el servlet ServletA implementa la interfaz ServidorMonitorizacion para soportar funcionalidad RMI. Además de implementar la interfaz ServidorMonitorizacion, debe poseer métodos para registrarse como método remoto. Estos métodos los hereda de DaemonHttpServletTCP. Dichos métodos se explican a continuación. Recapitulando, un objeto remoto necesita hacer dos cosas como preparación para la comunicación RMI [4]: 1. Exportarse. Cuando un objeto remoto se exporta, comienza a escuchar en un puerto las peticiones de invocación de métodos entrantes. Esto se ha implementado en el método init(). 2. Registrarse. Cuando un método remoto se registra, le dice a un servidor de registro su nombre y número de puerto, para que los clientes puedan localizarlo y comunicarse con él. Este proceso de registrarse se conoce como binding, y se lleva a cabo en el método bind(). El citado método hace uso de los métodos auxiliares getregistryname() y getregistryport().

47 4.2. DISEÑO SOFTWARE Diseño del Interfaz Servidor/UCMM Comunicaciones Entre SCC y UCMM la comunicación se realiza mediante sockets TCP. Ésta es la opción elegida, de entre las siguientes disponibles: 1. Http. Se ha descartado porque el SCC no podría tomar la iniciativa de la comunicación. El SCC procesa y completa los datos recibidos desde los nodos inteligentes (NI) de las iban, antes de retransmitirlos a las UCMM. Para poder enviarlos a las UCMM por Http, la UCMM debiera funcionar como servidor web. Como se verá en el capítulo 5, la UCMM se ejecuta en un teléfono móvil. Los teléfonos móviles pueden ser clientes web, pero la versión de Java para dispositivos móviles (J2ME) no incluye ningún API para facilitar el desarrollo de servidores web, por lo que se tendría que realizar una implementación completa. Además, esta alternativa sería incompatible con el hecho de que la UCMM sea un cliente ligero. Como tal, representa información y recoge comandos en una interfaz gráfica de usuario (IU). Otro motivo para su descarte relacionado con el anterior, es que en un teléfono móvil la dirección IP otorgada difícilmente permite montar un servidor web. 2. UDP. Descartada por ser un protocolo no fiable. Es conveniente aclarar que uno de los modos de comunicación entre el NI y el SCC emplea UDP para los paquetes de datos, a pesar de que UDP es sólo un protocolo best effort. La razón es que cuando la transmisión del NI al SCC es continua (1 s) no tiene sentido retransmitir datos perdidos. Adicionalmente, para periodos de transmisión superiores a un segundo, se puede elegir otro modo de comunicación fiable, el modo Http. 3. TCP. Es la opción elegida por fiabilidad y disponibilidad. Al igual que en el Interfaz Servidor/NI TCP-UDP (véase apartado ), se han dispuesto dos canales de comunicación separados para paquetes de datos y paquetes de control. A diferencia de aquel, los dos canales son TCP: Un socket TCP permanente desde el que la UCMM recibe los paquetes de datos. Un socket TCP temporal desde el que la UCMM envía los paquetes con comandos de control, y que se cierra tras cada envío. La temporalidad del socket se justifica por eficiencia en procesamiento. Dicha

48 36 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL eficiencia es deseable debido a que la UCMM corre en un teléfono móvil, cuya capacidad de procesamiento es limitada. La decisión se basa en los siguientes puntos: Los comandos de control no son enviados masivamente por el usuario de la UCMM. Un proceso escuchando permanentemente las respuestas a dichos comandos por un socket que la mayor parte del tiempo esté ocioso, significa un derroche de procesamiento. Al ser temporal, y abierto por iniciativa de la UCMM, se descarga a la UCMM del procesamiento relativo a funcionar como servidor de sockets TCP. La responsabilidad de ejercer como servidor TCP recae en el SCC, el cual, siendo ya un servidor web, posee una capacidad de procesamiento mucho mayor que la de un teléfono móvil Diseño software La comnunicación entre SCC y UCMM es lleva a cabo utilizando TCP ( ). Sobre este modo de comunicación, se ha visto en el apartado que es posible extender la funcionalidad de un servlet para que funcione como servidor TCP. Por ello, y teniendo en cuenta que el SCC es servidor y contenedor de servlets, se ha decidido implementar el Interfaz Servidor/UCMM programando un servlet con funciones de servidor TCP. Véase el diagrama de clases UML que contiene al citado servlet, llamado ServletB, en la figura 4.3. El servlet extiende a la clase DaemonHttpServletTCPB para dotarse de la funcionalidad de servidor de sockets TCP. Esta clase es análoga a DaemonHttpServletTCP (apartado ), pero instancia dos servidores TCP (DaemonTCP_B y DaemonTCP_B_Commands, figura 4.3) en lugar de uno, y no está provista de RMI (véase apartado ). La misión de estos dos servidores TCP es: DaemonTCP_B: encargado de establecer una conexión TCP permanente de paquetes de datos, con cada UCMM. Dicha conexión se establece por iniciativa de la UCMM. DaemonTCP_B_Commands: establece conexiones TCP temporales para recoger los paquetes con comandos de control que las UCMM envían al SCC. Las UCMM solicitan a este servidor la apertura, para comando, de un socket TCP; a continuación envían el comando por él, y lo cierran. Los métodos abstractos handledataclienttcp() y handlecommandclienttcp() de dicha clase son implementados por la clase ServletB para gestionar las conexiones de datos y de control.

49 4.2. DISEÑO SOFTWARE 37 La clase ModeloPaciente también forma parte del Interfaz Servidor/UCMM. Esta clase hace uso de otras (EnviadorAUCMM, Comunicador_socketTCP) para la comunicación con la UCMM. Cada conexión permanente de datos con UCMM es modelada por la clase Comunicador_socketTCP. Por otro lado, EnviadorAUCMM es una hebra que envía un paquete a toda una lista de conexiones. Véase más sobre la clase ModeloPaciente en el apartado Diseño software del Servidor El subsistema Servidor del SCC se ha implementado en la clase ServidorMVC Justificación Compartición de objetos entre servlets: solución singleton El SCC recibe información de los NI, UCMM y UCMNM a través de un proceso que escucha en un puerto, o de un servlet. Una vez recibida esa información, se entrega al servidor para su tratamiento. Cada envío a un servlet es atendido por una instancia o copia del servlet, de acuerdo con su filosofía de funcionamiento. Por tanto, múltiples envíos instanciarán a múltiples servlets que accederán concurrentemente a los mismos objetos que componen el Servidor. Para evitar los problemas del acceso compartido, se han de estudiar las posibles soluciones. Hay tres alternativas para compartir información entre servlets [4]: 1. A través de la System Properties List, que se encuentra en la clase java.lang.system. Se trata de una lista de propiedades (java Properties) estándar del sistema, que también puede contener propiedades específicas de una aplicación. Los servlets pueden añadir, cambiar, obtener o eliminar el valor de una determinada propiedad de dicha lista. 2. Mediante un objeto compartido. En nuestro caso el objeto compartido es el conjunto de clases que forma el Servidor. El objeto que se comparte es de una clase singleton (una clase de la que existe una única instancia) de forma que cada servlet obtiene una referencia a esa única instancia. Esta capacidad no está disponible en la lista de propiedades. 3. Mediante herencia. Cada servlet interesado en la colaboración puede extender la misma clase y heredar la misma información. Ello simplifica el código para la colaboración de servlets y limita el acceso a la información compartida a las subclases. La superclase puede mantener una referencia a la información compartida, o puede mantenerla ella misma. Posiblemente la técnica más fácil de colaboración entre servlets es a través de la herencia.

50 38 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Las opciones 2 y 3 son igualmente válidas y no presentan gran diferencia en lo respectivo a dificultad de programación. De modo que, con la intención de incorporar técnicas nuevas, se ha decidido adoptar la solución 2. Una clase singleton presenta las siguientes características: Su constructor es sólo accesible desde la propia clase (tiene visibilidad private). Posee un atributo private static, de la clase misma a la que pertenece, cuyo valor es la única instancia de dicha clase. De este modo, y con un constructor private, ya no será posible crear una nueva instancia de la clase. El citado atributo se llamará genéricamente instance. Para acceder a esa única instancia, la clase provee de un método que puede ser invocado sin instanciar exteriormente la clase (ya que no es posible), que por tanto es public static, y que se llama genéricamente getinstance(). Dicho método devuelve el valor del atributo instance. Véase en el siguiente código de ejemplo. public class ClaseSingleton{ private static ClaseSingleton instance; private ClaseSingleton(){ // constructor privado } // método para obtener la única referencia public static ClaseSingleton getinstance(){ return instance; } } Para implementar la alternativa elegida, los dos servlets de este Proyecto sobreescriben el método init(), que es llamado por el contenedor de servlets una vez durante el ciclo de vida del servlet para inicializarlo. En este método se obtiene una referencia a la clase singleton que representa al Servidor (ServidorMVC). Se asigna dicha referencia a un atributo, y así el servlet puede trabajar con ella Patrón de diseño: MVC El Servidor se ha desarrollado de acuerdo con la arquitectura software Modelo-Vista- Controlador (MVC). A continuación se explica en qué consiste la arquitectura software MVC y se justifica su uso:

51 4.2. DISEÑO SOFTWARE 39 Los patrones de diseño describen estrategias comprobadas para crear sistemas confiables de software orientado a objetos. Este proyecto se adhiere a la arquitectura MVC (Modelo-Vista- Controlador), que utiliza varios patrones de diseño. MVC divide a las responsabilidades del sistema en tres partes [3, 6, 7] : 1. El Modelo, que mantiene los datos, las comunicaciones y la lógica del programa. 2. La Vista, que proporciona una presentación visual. 3. El Controlador, que lleva a cabo las siguientes tareas: Procesa las entradas al sistema, apoyándose en la lógica que provee el Modelo. Manda a la Vista representar y actualizar los resultados. Actúa de pasarela entre el Modelo y la Vista. Diversos manuales de Java, por ejemplo [3], proponen la arquitectura MVC en sus ejemplos. Esto fue la primera razón que condujo a emplearlo en el Proyecto. El segundo motivo fue que la arquitectura J2EE, utilizada para desarrollar el SCC es en sí misma una arquitectura análoga a la MVC. J2EE es un modelo de aplicación distribuida multinivel [8] que además del nivel propio del cliente ([8]), presenta los siguientes niveles: El Nivel de Información de Empresa (Enterprise Information System Tier) de J2EE, que procesa transacciones e incluye sistemas de bases de datos. Presenta por tanto características análogas a las del Modelo en la arquitectura MVC. El Nivel de Negocios (Business Tier) de J2EE recibe datos del cliente, los procesa (si es necesario) y envía el resultado al Nivel de Información de Empresa. O bien recoge datos del Nivel de Información, los procesa (si es necesario) y envía el resultado al cliente. Este nivel sería análogo al Controlador del MVC. El Nivel Web (Web Tier) de J2EE procesa peticiones, construye respuestas y constituye a la vez el interfaz gráfico con el usuario. Por ello, aunque comparta tareas de procesamiento de datos con el nivel de negocios y por tanto no se reduzca a ser sólo una vista, presenta analogías con la Vista de la arquitectura MVC Desarrollo Una vez expuesta la filosofía de la arquitectura software MVC y justificado su uso, se detalla cómo se ha organizado el desarrollo del subsistema Servidor del SCC siguiendo la mencionada arquitectura. Se ha distribuido en distintos niveles:

52 40 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Una arquitectura MVC para el Servidor en su conjunto: nivel de aplicación. Una arquitectura MVC para cada paciente: nivel de paciente. Por cada paciente, una arquitectura MVC para cada sensor registrado: nivel de sensor. Además, bajo cada nivel de sensor se ha dispuesto otro nivel: el del modo de funcionamiento de cada sensor. La clase que contiene a todo el Servidor, y desde de la que se accede a cada nivel es ServidorMVC Arquitectura completa En la figura 4.4 se exponen las clases que componen el Servidor, y cómo estas se ordenan en tres niveles: aplicación, paciente y sensor. Cada nivel sigue la arquitectura MVC, con la siguiente peculiaridad: no poseen ninguna Vista. La razón es que las vistas se ejecutan en las UCMM y UCMNM. Ello confiere gran flexibilidad al sistema, dado que el SCC puede ejecutarse en un servidor desprovisto de componentes gráficos (por ejemplo un PC embebido sin interfaz gráfico). El diagrama UML de la figura 4.4 modela un subsistema Servidor en el que hay P pacientes registrados, y en el que el paciente i posee Si sensores conectados Arquitectura del nivel de aplicación La arquitectura MVC en este nivel es la siguiente: Controlador: implementado por la clase ControlSCC. Modelo: implementado por la clase Modelo. Vista: como ya se ha dicho, el subsistema Servidor carece de Vistas porque éstas se ejecutan en las UCMM y las UCMNM. Las clases que componen los elementos de la arquitectura MVC del nivel de aplicación se muestran en el diagrama de la figura 4.5. Las funciones de cada elemento son las siguientes: Controlador (ControlSCC) : Controla el Modelo. Instancia una arquitectura MVC para cada paciente, formada por un Controlador de paciente y un Modelo de paciente. Un Controlador de paciente es un objeto de la clase CtrlPacienteProyecto.

53 4.2. DISEÑO SOFTWARE 41 Mantiene referencias a todos los objetos CtrlPacienteProyecto. En la figura 4.5 se observa cómo mantiene P referencias. Modelo (Modelo): Almacena la lista de pacientes registrados en el sistema. Cada paciente es modelado por la clase PacienteProyecto. Mantiene referencias a todos los objetos PacienteProyecto. En la figura 4.5 se observa cómo mantiene P referencias. Gestiona el acceso a la lista de pacientes. Gestiona el acceso a la información sobre cada paciente: Nombre del paciente. Identificador del paciente: único para cada paciente. Dos pacientes podrán tener mismo nombre pero nunca igual identificador. Vista: el subsistema Servidor carece de Vistas porque éstas se ejecutan en las UCMM y las UCMNM. En la figura 4.5 se observa la clase CtrlPacienteProyecto, que ya pertenece al siguiente nivel, el de paciente. Se ha incluido en el diagrama para que se comprenda cómo están conectados los tres niveles de la arquitectura MVC (de aplicación, de paciente y de sensor): a través de las clases Controlador Arquitectura del nivel de paciente La arquitectura MVC en este nivel es la siguiente: Controlador: implementado por la clase CtrlPacienteProyecto. Modelo: implementado por la clase ModeloPaciente. Vista: como ya se ha dicho, el subsistema Servidor carece de Vistas porque éstas residen en las UCMM y las UCMNM. Las clases arriba indicadas, que componen los elementos de la arquitectura MVC del nivel de paciente, pueden contemplarse en la figura 4.6. Las funciones de cada elemento son las siguientes: Controlador (CtrlPacienteProyecto): Controla a ModeloPaciente.

54 42 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Lleva a cabo el procesamiento de los paquetes que llegan al SCC, procedentes de los nodos inteligentes (NI), las UCMM y las UCMNM. Tras obtener los resultados del procesamiento, ordena al ModeloPaciente los envíos pertinentes a NI, UCMM o UCMNM. El procesamiento de los datos puede observarse en el apartado 4.3. Instancia una arquitectura MVC para cada sensor, formada por un Controlador de sensor y un Modelo de sensor. Un Controlador de sensor es un objeto de la clase ControladorSensor. CtrlPacienteProyecto. Mantiene referencias a todos los objetos ControladorSensor. En la figura 4.6 se observa cómo el Controlador del paciente i mantiene Si referencias. Modelo (ModeloPaciente): Almacena la lista de sensores registrados en un paciente. Cada sensor es modelado por la clase Sensor. Mantiene referencias a todos los objetos Sensor, los cuales representan los sensores que el paciente tiene conectados. En la figura 4.6 se observa cómo mantiene Si referencias. Gestiona el acceso a la lista de sensores. Gestiona el acceso a la información sobre cada sensor: Identificador de sensor: único para cada sensor. Tipo de sensor. Dos sensores iguales colocados en pacientes distintos tendrán diferente identificador, pero mismo tipo. Colabora en la gestión de las comunicaciones del SCC con los NI, UCMM y UCMNM. Forma parte, por tanto, de los interfaces del SCC: El Interfaz Servidor/NI El Interfaz Servidor/UCMM El Interfaz Servidor/UCMNM En la figura 4.6 se observa la clase ControladorSensor, que ya pertenece al siguiente nivel, el de sensor. Se ha incluido en el diagrama para exponer cómo están conectados los tres niveles de la arquitectura MVC (de aplicación, de paciente y de sensor): a través de las clases Controlador Arquitectura del nivel de sensor La arquitectura MVC en este nivel es la siguiente:

55 4.2. DISEÑO SOFTWARE 43 Controlador: implementado por la clase ControladorSensor. Posee a su vez un controlador propio, implementado por la clase ControlModo. Modelo: implementado por la clase ModeloSensor. Vista: como ya se ha dicho, el subsistema Servidor carece de Vistas porque éstas residen en las UCMM y las UCMNM. Las clases que componen los elementos de la arquitectura MVC del nivel de sensor pueden contemplarse en la figura 4.7. Las funciones de cada elemento son las siguientes: Controlador (ControladorSensor): Controla a ModeloSensor. Gestiona los cambios de modo de funcionamiento de un sensor. Gestiona el estado del SCC en el diálogo que mantiene con el nodo inteligente(ni) de la iban en relación a un sensor concreto. El SCC tendrá un estado para cada sensor del que recibe información. Ese estado se gestiona en ControladorSensor. Los estados principales del diálogo o protocolo entre SCC y NI son: Estado de espera de datos. Estado de espera de confirmación a un comando de control. Procesar los paquetes que llegan al SCC, procedentes de los NI, UCMM y UCMNM. Esta es una tarea que el Controlador de paciente (CtrlPacienteProyecto) delega parcialmente en el Controlador de sensor (ControladorSensor). Éste a su vez delega ciertas tareas en los Controladores de modo (ControlModo), que son controladores específicos para cada modo de funcionamiento del sensor. Esta separación está justificada desde el punto de vista de que cada sensor puede distintos modos de funcionamiento, y para cada modo, un diferente formato de trama. Por ello, una tarea delegada en ControlModo es la descodificación de las tramas de información de los sensores, que se encuentran encapsuladas en los paquetes transmitidos por el nodo inteligente(ni) de la iban. La descodificación tiene como resultado la extracción de valores de los parámetros médicos o bioseñales muestreados por los sensores, que se mostrarán en las Vistas, las cuales se ejecutan en las UCMM y UCMNM. Es conveniente indicar que en el módulo Servidor, la descodificación sólo se realiza para las UCMNM, ya que las UCMM la realizan ellas mismas. Ello se debe a las características inherentes a los interfaces con UCMM, UCMNM, que más adelante se exponen.

56 44 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL En el SCC, las tramas son modeladas y descodificadas por la clase Trama. El Controlador de sensor (ControladorSensor) añade objetos Trama, pertenecientes a un mismo sensor, a un objeto TramaIdentificada que posee atributos para ampliar la información sobre el sensor. Este objeto será enviado a la UCMNM para su representación Modelo: opcionalmente almacena en fichero los datos enviados por los NI. En este proyecto, las iban de paciente poseen un solo sensor (de tipo pulsioxímetro) y un GPS. A nivel de modelado software, el GPS es un sensor más de la iban. En los siguientes apartados se expone la arquitectura MVC a nivel de sensor, del pulsioxímetro y del GPS. Modelado del sensor pulsioxímetro En la figura 4.8 se muestran las clases que componen el nivel de sensor para el sensor pulsioxímetro. El modelo de pulsioxímetro empleado en el Proyecto (véase capítulo??) puede funcionar, de manera controlable, en dos modos distintos. Por ello se han desarrollado dos Controladores de modo: CtrlSPO2M1 : controlador del modo 1 del pulsioxímetro. CtrlSPO2M2 : controlador del modo 2 del pulsioxímetro. Por otro lado, se han modelado las tramas de cada uno de los dos modos de funcionamiento. Las clases que las modelan almacenan la trama en sí, la descodifican, y guardan los resultados en atributos que se corresponden con los parámetros médicos o bioseñales muestreados: Modo 1: las tramas de modo 1 se almacenan y descodifican en objetos de la clase TramaF1. Modo 2: las tramas de modo 2 se almacenan y descodifican en objetos de la clase DataF2 y StatusF2. El formato de las tramas y los parámetros médicos o bioseñales que el pulsioxímetro de este proyecto obtiene se han listado en el apéndice B. Modelado del GPS En la figura 4.9 se muestran las clases que componen el nivel de sensor para el GPS. El GPS se ha modelado a nivel software como un sensor con dos modos de funcionamiento. Ambos modos son idénticos para el SCC, pero presentan diferencias en el NI. El implementar dos Controladores de modo idénticos ha sido un requisito del proyecto Pasarela Bluetooth/GPRS para dispositivos móviles. Las clases que los modelan son:

57 4.2. DISEÑO SOFTWARE 45 ControlM1_GPS : controlador del modo 1 del GPS. ControlM2_GPS : controlador del modo 2 del GPS. La trama de datos es idéntica en los dos modos de funcionamiento. La clase que la modela almacena la trama en sí, la descodifica, y guarda los resultados (latitud, longitud, velocidad, fecha y hora) en atributos. Esta clase es TramaGPS Resumen El SCC se ha desarrollado como un servidor instalado en un contenedor de servlets (Tomcat). Acceden a él los nodos inteligentes(ni) de las iban y las unidades de monitorización (UCMM, UCMNM). Las interfaces entre el SCC y el resto de subsistemas se han desarrollado principalmente con dos servlets: 1. Un sólo servlet implementa las siguientes interfaces: La interfaz entre el NI y el SCC, en modo Http La interfaz entre el NI y el SCC, en modo TCP-UDP. La interfaz entre el SCC y la UCMNM. 2. Otro servlet provee del interfaz entre el SCC y la UCMM. El Servidor, módulo principal del SCC, está diseñado según el patrón de diseño MVC que distribuye las funciones del siguiente modo: Modelo: gestiona las comunicaciones y acceso a datos almacenados. Vista: las vistas no se ejecutan en el SCC, sino en las unidades de monitorización UCMM y UCMNM. Controlador: controla el Modelo y la Vista. Siguiendo una filosofía de diseño granular, en el módulo Servidor hay tres niveles que siguen cada uno de ellos el patrón MVC: Nivel de Aplicación. Nivel de Paciente. Nivel de Sensor. Bajo este nivel, otro: el de los modos de funcionamiento del sensor.

58 46 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL 4.3. Funcionamiento del Servidor de Control Central (SCC) Las tareas que el SCC efectúa se inician con la recepción de información transmitida por el NI, y están relacionadas con la comunicación que se establece entre el SCC y los NI, UCMM, UCMNM. En los siguientes apartados se explican esas tareas, desde dos puntos de vista: Desde el punto de vista algorítmico, sin especificar detalles software. Para ello se emplean diagramas de actividad UML, que son diagramas de flujo los cuales modelan las acciones y el orden en que se van a realizar [3]. Desde el punto de vista software: exponiendo cómo el software desarrollado lleva a cabo las tareas programadas por el algoritmo de funcionamiento. Para ello se emplean diagramas de secuencia UML, que presentan un flujo detallado para un caso de uso específico [9]. Muestran las interacciones entre objetos, enfatizando el modo en que los objetos se envían mensajes en el tiempo [3] Algoritmo de funcionamiento: diagramas de actividad UML Comunicación SCC/NI En el diagrama de la figura 4.10 se exponen las actividades que el SCC lleva a cabo cuando recibe un paquete desde el NI. Todas las actividades que tienen lugar tras recibirlo recorren el esquema completo del SCC. Por ello, la exposición de dichas actividades da a conocer ampliamente el funcionamiento del sistema. El primer paso que el NI efectúa para comunicarse con el SCC es enviarle un paquete de identificación (véase primera actividad del diagrama 4.10). Esta actividad sólo se realiza una vez, a menos que el NI cambie de IP. A pesar de que sólo se efectúa una vez, y no cada vez que el NI tiene que enviar información al SCC, se ha incluido en el diagrama de la figura 4.10 para explicar de manera clara el proceso completo de comunicación SCC/NI. En los siguientes apartados se desgrana cada actividad del diagrama de la figura Actividad: leer y procesar un paquete de identificación del NI La actividad Leer y procesar un paquete de identificación del NI se muestra en el diagrama de la figura 4.11.

59 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) Actividades: leer paquete de datos/control del NI, Enviar comando al NI El diagrama de actividad de la figura 4.10 es el mismo tanto si el SCC y el NI se comunican por Http, como si lo hacen por TCP-UDP. La diferencia radica en cómo se realizan las actividades Leer paquete de datos/control del NI, Enviar comando al NI. Si el modo es Http, dichas actividades se efectúan de la siguiente manera: Leer paquete de datos/control del NI : el paquete va incluido en la petición Http de tipo POST que el NI envía al Interfaz Servidor/NI Http (véase apartado ). Leer el paquete significa, en este caso, que el servlet del Interfaz Servidor/NI Http extraiga el contenido de la petición Http POST, en su método dopost(). Enviar comando al NI : el comando de control va encapsulado en un paquete de control que se incluye en la respuesta Http, respuesta que el contenedor de servlets (Tomcat) envía automáticamente al morir 1 el servlet. Cuando el modo es TCP-UDP, las mencionadas actividades se llevan a cabo así: Leer paquete de datos/control del NI : cuando el NI se identifica en el SCC, éste le asigna un puerto UDP exclusivo, al que el NI podrá enviar los paquetes de datos. La actividad Leer paquete de datos/control del NI consta de dos pasos: 1. Recepción de un paquete por el puerto UDP y almacenamiento en un buffer de paquetes de datos. 2. Extracción del paquete más antiguo de ese buffer. Es conveniente aclarar que los accesos al buffer se efectúan concurrentemente. Enviar comando al NI : el SCC establece con el NI una conexión socket TCP, por la que se transmite el comando (encapsulado en un paquete de control) y a continuación se cierra el socket. Por tanto, se abre y cierra un nuevo socket TCP para cada comando enviado al NI (acerca de la justificación, véase el apartado ) Actividad: procesar el paquete extraído El diagrama de la figura 4.12 sintetiza los pasos que se llevan a cabo en la actividad Procesar el paquete extraído. 1 Se dice que el servlet muere cuando termina el ciclo de vida de la instancia del servlet que ha atendido una petición Http.

60 48 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Actividad: preparar y enviar datos a las UCMM Esta actividad consiste en: Añadir, a los datos extraídos de un paquete de datos del NI, el tipo de sensor y su modo de funcionamiento. El objetivo es proporcionar a la UCMM toda la información que necesite para representar adecuadamente la información recogida por los sensores. A su vez, se le libera de la gestión de información sobre los sensores (tipo de sensor, modo activo, etc..) Enviar estos datos ampliados sobre un paciente en concreto, a las UCMM que estén registradas como observadoras de dicho paciente Actividad: preparar y enviar datos a las UCMNM Esta actividad es análoga a Preparar y enviar datos a las UCMM descrita en el apartado , aunque existen algunas diferencias, que son las siguientes: El destinatario del envío (obviamente). Los datos que se envían a las UCMNM son previamente descodificados. Los de las UCMM, no. Esta diferencia de comportamiento se justifica porque la interfaz con la UCMNM es de más alto nivel: RMI permite el paso de mensajes Java, es decir, el intercambio de objetos. Sin embargo, la UCMM reside en un teléfono móvil y el lenguaje de desarrollo de aplicaciones para el móvil, J2ME, carece de soporte para RMI. En definitiva, la interfaz con las UCMM es de más bajo nivel y sólo permite el manejo de flujos de bytes Comunicación SCC/UCMM El módulo Interfaz Servidor/UCMM distingue comunicaciones de paquetes de datos y de paquetes de control. Cuando una UCMM abre una conexión de datos con el SCC, éste sigue los pasos esquematizados en la figura En cambio, cuando una UCMM abre una conexión de comandos con el SCC, los pasos a seguir son los indicados en el diagrama de actividad de la figura Tal y como se explica en el apartado , el SCC envía a la UCMM paquetes de datos ampliados. A su vez, el SCC recibe comandos de control de la UCMM, destinados a las NI de las iban. Estos comandos son filtrados por la UCMM, que se encarga de verificar que los valores introducidos por el usuario a partir de los que se genera el comando son coherentes, y los transmite al SCC codificados en un formato que no necesita procesamiento adicional para su reenvío al NI.

61 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) Comunicación SCC/UCMNM En el apartado se ven las actividades que el SCC efectúa para enviar información a la UCMNM. En la figura 4.15 se observan las actividades que lleva a cabo cuando recibe un comando de control de la UCMNM. A diferencia del otro tipo de unidad de monitorización (UCMM), en la UCMNM el envío del comando incluye la identificación del paciente, como se verá en los apartados de funcionamiento software Funcionamiento software: diagramas de secuencia UML Mediante la exposición de diagramas de secuencia UML, se ilustran los objetos que llevan a cabo las actividades descritas en el apartado 4.3.1, cómo colaboran entre ellos para realizarlas, y el orden temporal en el que suceden Comunicación SCC/NI Dado que la comunicación entre SCC y NI se puede efectuar a través de Http o TCP-UDP, en los siguientes apartados se presentan diagramas de secuencia distintos para cada uno de los modos Modo Http Para mayor claridad, la exposición de la interacción entre SCC y NI se escinde en dos diagramas: uno para recepción, y otro para transmisión. Recepción Se detalla en el diagrama de la figura 4.16 el funcionamiento del SCC cuando recibe un envío del NI. Este envío puede incluir múltiples paquetes de datos y de control, concatenados. La secuencia de acciones puede sintetizarse como se indica a continuación: 1. El NI realiza una petición Http POST al SCC. 2. El servlet del Interfaz Servidor/NI Http es entonces instanciado por el contenedor de servlets (Tomcat). 3. El contenedor de servlets, de forma transparente, invoca al método dopost() del servlet para atender la petición Http POST. 4. Es entonces cuando el objeto servlet, llamado ServletA, comienza a procesar la petición, tal y como puede verse en la figura 4.16.

62 50 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL En la citada figura se observa cómo para procesar un paquete, los controladores de los distintos niveles colaboran: El Controlador de paciente: CtrlPacienteProyecto. El Controlador de sensor: ControladorSensor. El Controlador de modo: ControlModo. Envío El SCC envía al NI los comandos de control que los usuarios hayan invocado desde las UCMM, UCMNM. En este caso, la secuencia de acciones es: 1. El método enviarni_http() de ModeloPaciente deposita en un buffer de paquetes de control, los comandos recibidos por el SCC. 2. El método responderconcomando() de ServletA-véase figura recoge un paquete del buffer, y lo envia al NI tal y como se explica en el siguiente paso. 3. Cuando el servlet muere, el contenedor de servlets envía automáticamente una respuesta Http al NI. El modo de enviar información desde el SCC al NI, en modo Http, es adjuntando dicha información en la respuesta Http. Lo que se adjunta es un paquete con un comando de control. Esto es lo que ServletA efectúa cuando invoca su método responderconcomando()-véase figura Modo TCP-UDP La interacción entre SCC y NI, al igual que se ha hecho para el modo Http, se describe mediante dos diagramas de secuencia independientes para transmisión y recepción. Recepción La recepción de paquetes de control se efectúa por un socket TCP, dedicado para cada NI, y la recepción de paquetes de datos se efectúa por un puerto UDP, también exclusivo de cada NI. El proceso de apertura de las comunicaciones, y recepción de paquetes en el SCC que se muestra en la figura 4.17, consta de los siguientes pasos: 1. El NI se identifica en el SCC. Antes de enviar paquetes de datos, el NI ha de identificarse en el SCC. Esto es necesario para que el SCC asocie al NI con un paciente de los que están registrados. Con ese fin, el NI abre una conexión socket TCP en el SCC por la que envía un paquete de control de identificación. Este socket TCP se emplea en lo sucesivo para la recepción en el SCC de paquetes de control.

63 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) El SCC le comunica al NI el puerto UDP a utilizar para el envío de paquetes de datos. Una vez establecidos los canales de comunicación SCC/NI, el SCC ya está listo para recibir datos del NI. Es conveniente aclarar que el procesamiento de los datos enviados por el NI es independiente del modo de comunicación. De hecho, el diagrama de la figura 4.17 finaliza con una invocación al método procesarpaqueteni() en el que se llevan a cabo las mismas acciones que en el modo Http, acciones que pueden verse en la figura 4.16 tras las invocación del citado método. 3. Recepción de paquetes de datos. Envío El SCC envía al NI los comandos de control que los usuarios hayan invocado desde las UCMM, UCMNM. El envío se efectúa en el método enviarni_sockets() de ModeloPaciente. En él, el SCC abre una nueva conexión socket TCP con el NI, le envía el paquete de control con el comando, y cierra la conexión Comunicación SCC/UCMM A continuación, se describe la interacción entre SCC y UCMM, diferenciando entre recepción y transmisión: Recepción El SCC recibe de las UCMM los comandos de control que el usuario selecciona a través de la interfaz gráfica, encapsulados en paquetes de control. Para cada comando de control generado por la UCMM, ésta lleva a cabo las siguientes acciones: 1. Abrir una conexión socket TCP. 2. Enviar un paquete de control en el que se identifica el paciente al que va destinado al comando. 3. Enviar el comando. 4. Cerrar la conexión. En la figura 4.18 se muestra la recepción en el SCC de un comando de control de la UCMM.

64 52 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Envío En la figura 4.16 se ve cómo, al llegar un paquete de datos del NI al SCC, se siguen los siguientes pasos: 1. Se le completa la información que contiene, y se ordena su reenvío a las UCMM. Esta tareas las realizan los métodos formarpqtesdatosucmm() y enviardatosalasucmm(). Véase la figura expuesta anteriormente El Controlador de paciente (CtrlPacienteProyecto), que posee una lista de las conexiones con las UCMM que se han registrado como observadoras del paciente, ordena al Modelo de paciente (ModeloPaciente) que envíe a todas ellas el paquete de datos ampliado. 3. ModeloPaciente realiza el envío en su método enviardatosalasucmm(), el cual instancia un proceso llamado EnviadorAUCMM que envía el paquete de datos ampliado a toda la lista de conexiones con UCMM. Véase figura 4.19.

65 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) 53 Figura 4.1: Arquitectura del SCC

66 54 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Figura 4.2: Diagrama de clases UML del Interfaz Servidor/NI Http

67 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) 55 Figura 4.3: Diagrama de clases UML del Interfaz Servidor/UCMM

68 56 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Figura 4.4: Diagrama de clases UML del Servidor Figura 4.5: Diagrama de clases UML del nivel de aplicación del subsistema Servidor

69 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) 57 Figura 4.6: Diagrama de clases UML del nivel de paciente del subsistema Servidor

70 58 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Figura 4.7: Diagrama de clases UML del nivel de sensor del subsistema Servidor

71 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) 59 Figura 4.8: Diagrama de clases UML del nivel de sensor, para el sensor pulsioxímetro.

72 60 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Figura 4.9: Diagrama de clases UML del nivel de sensor, para el GPS.

73 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) 61 Figura 4.10: Diagrama de actividad UML de la recepción en el SCC de un paquete del NI.

74 62 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Figura 4.11: Diagrama de actividad UML del procesamiento de un paquete de identificación del NI.

75 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) 63 Figura 4.12: Diagrama de actividad UML del procesamiento de un paquete.

76 64 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Figura 4.13: Diagrama de actividad UML: apertura de conexión de datos de la UCMM.

77 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) 65 Figura 4.14: Diagrama de actividad UML: apertura de conexión de comandos de la UCMM.

78 66 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Figura 4.15: Diagrama de actividad UML: recepción de comando de control de la UCMNM.

79 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) 67 Figura 4.16: Diagrama de secuencia UML: recepción, por Http, de un envío del NI.

80 68 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Figura 4.17: Diagrama de secuencia UML: establecimiento de comunicaciones SCC/NI en modo TCP-UDP. Recepción de paquetes del NI en el SCC.

81 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) 69 Figura 4.18: Diagrama de secuencia UML: recepción de comando de la UCMM

82 70 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Comunicación SCC/UCMNM El módulo Interfaz Servidor/UCMNM emplea la tecnología RMI. Por tanto, la comunicación entre SCC y NI tiene lugar entre dos objetos remotos cuando un objeto invoca un método del otro, razón por la que también se conoce como paso de mensajes. Recepción El SCC recibe de las UCMNM los comandos de control que el usuario ordena. Estos comandos se corresponden con el mensaje que la UCMNM pasa al SCC. Véase en la figura La UCMNM se modela por la clase AppletMonitorPacientes (capítulo 6), y envía al SCC el comando de control en el mensaje recogercomandodelapplet(). Envío En la figura expuesta con anterioridad 4.16 se ve cómo, al llegar un paquete de datos del NI al SCC, se amplía la información que contiene, y se ordena su reenvío a las UCMNM. Este envío es la simple invocación de un método, el método recogertramaidentificada(), que puede verse en la figura Lo que el SCC envía a la UCMNM es un objeto TramaIdentificada, cuyos atributos son los parámetros ya descodificados de las tramas de sensor, e información extra añadida por el SCC, para facilitar el procesamiento en la UCMNM. El objetivo es que la UCMNM sólo tenga que representar la información, sin preocuparse de la descodificación. La clase TramaIdentificada se representó en la figura 4.7.

83 4.3. FUNCIONAMIENTO DEL SERVIDOR DE CONTROL CENTRAL (SCC) 71 Figura 4.19: Diagrama de secuencia UML: transmisión de paquete de datos a las UCMM. Figura 4.20: Diagrama de secuencia UML: recepción de comando de control de la UCMNM.

84 72 CAPÍTULO 4. SUBSISTEMA SERVIDOR DE CONTROL CENTRAL Figura 4.21: Diagrama de secuencia UML: envío a la UCMNM.

85 Capítulo 5 Unidad de Control y Monitorización Móvil La información de los sensores y del GPS recogida por el nodo inteligente(ni) de la iban es enviada al subsistema SCC (Servidor de Control Central). Una vez en el SCC, las bioseñales muestreadas por los sensores y la información de posición están disponibles para que el personal médico, usuario del sistema, acceda a ellas a través de dos tipos de unidades. Una de estas unidades es la UCMM (Unidad de Control y Monitorización Móvil): gracias a ella, desde un terminal móvil el usuario puede monitorizar la información de bioseñales y posición de un paciente, así como controlar los dispositivos que recogen dicha información. La UCMNM es un dispositivo móvil con el software de una aplicación de monitorización y control instalado Arquitectura La arquitectura del subsistema UCMM (Unidad de Control y Monitorización Móvil), que se muestra en el esquema de la figura 5.1, consta de un módulo principal denominado Sistema de Control y Monitorización (SCM) y de dos módulos de interfaz, uno para la comunicación con el Servidor Central (Interfaz UCMM/SCC) y otro para la interacción con el usuario (Interfaz UCMM/usuario). Las funciones de cada uno de los módulos que constituyen la UCMM son: Interfaz UCMM/SCC: Establecer comunicación con el SCC. Actuar de pasarela entre el SCC y el módulo SCM de la UCMM. Enviar al SCC los comandos de control que el usuario de la UCMM selecciona a través de la interfaz de usuario, para que sean ejecutados en el sensor elegido. 73

86 74 CAPÍTULO 5. UNIDAD DE CONTROL Y MONITORIZACIÓN MÓVIL Sistema de Control y Monitorización (SCM): Controlar el módulo Interfaz UCMM/SCC. Controlar el módulo Interfaz UCMM/usuario. Actuar de pasarela entre ambos interfaces. Gestionar la información recibida desde el SCC contenida tanto en paquetes de datos como de control. Los pasos realizados en cada caso, son: Paquetes de datos. Descodificación de las tramas de información correspondientes al sensor seleccionado por el usuario. En cada paquete de datos, el SCC incluye el modo de funcionamiento del sensor. De esta forma se descarga a la UCMM del seguimiento y gestión de los modos de operación, permitiéndole ser un cliente ligero. Paquetes de control. De los posibles paquetes de control que el NI envía al SCC, sólo el de desconexión de sensor es reenviado a la UCMM. El resto de paquetes de control que informan al SCC sobre la ejecución de los comandos de control no se retransmiten a a la UCMM. La razón es que el Servidor Central (SCC) mantiene comunicaciones con un número previsiblemente elevado de unidades de monitorización UCMM y UCMNM, que pueden abrir y cerrar esas comunicaciones tantas veces como deseen sus usuarios. Por consiguiente, si se quisiera informar a las unidades de monitorización de la evolución en la ejecución de los comandos de control, el SCC tendría que hacer un seguimiento exhaustivo de cada sesión abierta por éstas, requiriéndose además un protocolo más elaborado para la comunicación entre SCC y UCMM, UCMNM. Ambos aspectos no se han llevado a cabo porque no es objetivo del Proyecto tal gestión de errores, y por una cuestión de limitación temporal del desarrollo. Constituyen, en cualquier caso, una posible ampliación futura. Generar el paquete de control asociado a los comandos solicitados por el usuario. Interfaz UCMM/usuario: Representar en una IU (interfaz de usuario) la información muestreada por el sensor elegido. Esta información llega a la UCMM desde el SCC, y es previamante tratada por el módulo SCM. Representar en una IU la información de localización del paciente escogido, información que llega a la UCMM desde el SCC.

87 5.2. DISEÑO SOFTWARE 75 Recoger desde una IU los comandos de control, comandos que el usuario ordena para un determinado sensor. Entregar los comandos de control, ordenados por el usuario, al módulo SCM Diseño software La UCMNM es un dispositivo móvil con el software de la aplicación de monitorización y control instalado. El diseño de dicho software se aborda en este apartado. Como se explicó en el apartado 2.1.2), uno de los objetivos de la UCMM consiste en que el usuario pueda desplazarse geográficamente mientras hace uso del sistema. Con este fin, el software de la UCMM se ha desarrollado en J2ME, versión de Java orientada a los dispositivos móviles [12]. Como se ha visto en el capítulo de tecnologías, las aplicaciones implementadas en J2ME se denominan MIDlets [13]. La aplicación software instalada en teléfono móvil que constituye la UCMM es un MIDlet. Atendiendo a las mismas razones expuestas en el apartado , para desarrollar el MIDlet se ha seguido la arquitectura software MVC. La arquitectura MVC del MIDlet puede observarse en la figura 5.2. La figura 5.2 muestra las clases Java que representan a Modelo, Controlador y Vista, respectivamente Diseño software del Interfaz UCMM/SCC Comunicaciones Como se expuso en el apartado , entre SCC y UCMM la comunicación se realiza mediante sockets TCP. Se han dispuesto dos canales de comunicación separados para paquetes de datos y paquetes de control; los dos canales son TCP: Un socket TCP permanente, desde el que la UCMM recibe los paquetes, tanto de datos como de control. Un socket TCP temporal, desde el que la UCMM envía los paquetes de control correspondientes a órdenes del usuario. Es un socket temporal porque se cierra tras el envío de cada comando de control. La temporalidad del socket se justifica en el apartado

88 76 CAPÍTULO 5. UNIDAD DE CONTROL Y MONITORIZACIÓN MÓVIL Diseño software Dentro de la arquitectura MVC, el Interfaz UCMM/SCC se corresponde con el Modelo. El Modelo se ha desarrollado principalmente en la clase Modelo, representada en la figura 5.2. A continuación, la figura muestra con detalle las clases que componen el Modelo Diseño software del Sistema de Control y Monitorización (SCM) El módulo SCM se corresponde con el Controlador en la arquitectura MVC. Se ha desarrollado de manera granular -en distintos niveles-, análogamente a lo hecho con la arquitectura MVC del subsistema SCC (apartado ): Nivel de aplicación y Nivel de paciente: implementados por la clase ControladorAplicacion. En la UCMM, a diferencia del diseño MVC análogo del subsistema SCC, el nivel de aplicación y de paciente han sido fusionados, ya que la aplicación no permite monitorizar más de un paciente simultáneamente. Nivel de sensor: clase ControladorSensor. Bajo este nivel se ha incluido otro, correspondiente al modo de funcionamiento del sensor: clase ControlModo. El conjunto de clases que componen el módulo SCM pueden observarse en el diagrama de la figura Diseño software del módulo Interfaz UCMM/usuario El módulo Interfaz UCMM/usuario implementa una interfaz gráfica. En la arquitectura MVC, el Interfaz UCMM/usuario se correponde con la Vista, implementada entre otras clases por la clase VistaAplicacion mostrada en la figura 5.2. El resto de clases de la Vista, accesibles desde VistaAplicacion, implementan las posibles pantallas que el usuario contemplará en la interfaz gráfica. Estas pantallas pueden ser: Monitorización de datos recogidos por los sensores: clases VistaSensor. Recogida de parámetros de configuración de un comando de control: clases VistaComando. Menús para manejar o navegar por la aplicación: resto de objetos contenidos por la clase VistaAplicacion.

89 5.3. FUNCIONAMIENTO 77 La figura 5.5 muestra el diagrama de las clases que conforman el Interfaz UCMM/usuario. Las clases VistaSensor y VistaComando de dicho diagrama se han expuesto separadamente en las figuras 5.6 y 5.7. Cabe mencionar que toda pantalla desarrollada extiende de alguna clase de pantalla J2ME: Form, List, Canvas, etc Funcionamiento Las tareas que la UCMM efectúa se inician con la petición del usuario de monitorizar a un paciente y están relacionadas con la comunicación que se establece entre la UCMM y el SCC. En los siguientes apartados se expone el funcionamiento de la UCMM detallando esas tareas, desde dos puntos de vista: Algorítmico, sin entrar en detalles software: para ello se emplean diagramas de actividad UML. Software: exponiendo cómo el software desarrollado lleva a cabo las tareas programadas por el algoritmo de funcionamiento. Para ello se emplean diagramas de secuencia UML Algoritmo de funcionamiento: diagramas de actividad UML La figura 5.8 y su continuación 1 en la 5.9 muestran los pasos que llevan a cabo aplicación y usuario durante el funcionamiento de la UCMM. Los siguientes apartados desglosan algunas de las actividades esquematizadas por las figuras 5.8 y Actividad: establecer conexión con SCC Los pasos englobados en la actividad Establecer conexión con SCC se muestran en el diagrama de la figura Actividad: recoger envíos del SCC La actividad Recoger envíos del SCC se muestra en el diagrama de la figura Por una cuestión de espacio, el diagrama de actividad de la UCMM se ha escindido en dos figuras. Las actividades de la figura 5.9 comienzan donde terminan las de la figura 5.8.

90 78 CAPÍTULO 5. UNIDAD DE CONTROL Y MONITORIZACIÓN MÓVIL Actividad: procesar envío del SCC Las acciones a realizar para llevar a cabo la actividad Procesar envío del SCC se secuencian en el diagrama de la figura Recuérdese que el único paquete de control que se recibe en la UCMM es el de desconexión de sensor. Cuando es procesado, se actualiza la vista de monitorización de sensor para informar al usuario de la desconexión Funcionamiento software: diagramas de secuencia UML Este apartado se centra en la interacción entre la UCMM con el SCC. Mediante la exposición de diagramas de secuencia UML, se podrán observar qué objetos Java llevan a cabo las actividades vistas en el apartado 5.3.1, cómo colaboran entre ellos para realizarlas, y en qué orden temporal Establecimiento de conexión con el SCC Cuando el usuario ha seleccionado desde la interfaz gráfica del dispositivo móvil, el paciente que desea monitorizar y pulsa OK, la UCMM establece comunicación con el SCC. Para ello, el objeto Modelo inicia una conexión TCP con el SCC, tal y como se muestra en la figura Cada vez que se selecciona un paciente distinto, antes de establecer una conexión para éste se cierra la conexión anterior y se liberan los recursos dedicados al manejo de la conexión Recepción de envíos provenientes del SCC Cada UCMM pide al SCC monitorizar un paciente conreto, el solicitado por el usuario. El SCC le envía entonces la información que esté recibiendo de la red de área corporal (iban) del paciente seleccionado. Los siguientes diagramas de secuencia UML sintetizan los pasos que el software diseñado sigue para el tratamiento de la información recibida: 1. Una hebra de ejecución llamada LectorSocket lee de la conexión de datos establecida entre la UCMM y el SCC los paquetes de datos que seguidamente almacena en un buffer. Véase figura Una segunda hebra, ProcesadorPaquetes, recoge los paquetes contenidos en el buffer e inicia su procesamiento. Véase la figura 5.15.

91 5.3. FUNCIONAMIENTO El objeto ControlModo actualiza la pantalla de monitorización del sensor que corresponda. Lo hace independientemente de que esa pantalla se esté mostrando o no, en el interfaz de usuario. Así, en cuanto el usuario elija desde la interfaz de usuario monitorizar un sensor, podrá contemplar de forma inmediata cómo se refresca o actualiza la pantalla Envío de comando de control al SCC El usuario de la unidad de monitorización instalada en teléfono móvil (UCMM) puede enviar comandos para controlar un determinado sensor. Cuando el usuario ha introducido en la IU los parámetros asociados al comando de control y pulsa el botón OK, el objeto ControladorAplicacion, que es el gestor de los eventos de botón del teléfono móvil, recoge este evento y comienza la secuencia de pasos que se exponen en la figura Por último, Modelo envía al SCC el paquete con el comando de control a través de una nueva conexión TCP, y tras el envío la cierra.

92 80 CAPÍTULO 5. UNIDAD DE CONTROL Y MONITORIZACIÓN MÓVIL Figura 5.1: Arquitectura del subsistema UCMM Figura 5.2: Diagrama de clases UML: arquitectura MVC de la UCMM.

93 5.3. FUNCIONAMIENTO 81 Figura 5.3: Diagrama de clases UML: Interfaz UCMM/SCC.

94 82 CAPÍTULO 5. UNIDAD DE CONTROL Y MONITORIZACIÓN MÓVIL Figura 5.4: Diagrama de clases UML: módulo SCM.

95 5.3. FUNCIONAMIENTO 83 Figura 5.5: Diagrama de clases: Interfaz UCMM/usuario.

96 84 CAPÍTULO 5. UNIDAD DE CONTROL Y MONITORIZACIÓN MÓVIL Figura 5.6: Diagrama de clases UML: clase VistaSensor. Figura 5.7: Diagrama de clases UML: clase VistaComando.

97 5.3. FUNCIONAMIENTO 85 Figura 5.8: Diagrama de actividad UML: funcionamiento de la UCMM.

98 86 CAPÍTULO 5. UNIDAD DE CONTROL Y MONITORIZACIÓN MÓVIL Figura 5.9: Diagrama de actividad UML: funcionamiento de la UCMM (continuación a la figura 5.8).

99 5.3. FUNCIONAMIENTO 87 Figura 5.10: Diagrama de actividad UML: establecer conexión con el SCC.

100 88 CAPÍTULO 5. UNIDAD DE CONTROL Y MONITORIZACIÓN MÓVIL Figura 5.11: Diagrama de actividad UML: recoger envíos del SCC.

101 5.3. FUNCIONAMIENTO 89 Figura 5.12: Diagrama de actividad UML: procesar envío del SCC.

102 90 CAPÍTULO 5. UNIDAD DE CONTROL Y MONITORIZACIÓN MÓVIL Figura 5.13: Diagrama de secuencia UML: establecimiento de conexión con el SCC.

103 5.3. FUNCIONAMIENTO 91 Figura 5.14: Diagrama de secuencia UML: leer paquetes enviados por el SCC.

104 92 CAPÍTULO 5. UNIDAD DE CONTROL Y MONITORIZACIÓN MÓVIL Figura 5.15: Diagrama de secuencia UML: procesar paquetes del SCC.

105 5.3. FUNCIONAMIENTO 93 Figura 5.16: Diagrama de secuencia UML: envío de comando al SCC.

106 94 CAPÍTULO 5. UNIDAD DE CONTROL Y MONITORIZACIÓN MÓVIL

107 Capítulo 6 Unidad de Control y Monitorización No Móvil La información de los sensores y el GPS recogida por el NI del paciente es enviada al subsistema SCC (Servidor de Control Central). Una vez en el SCC, las bioseñales muestreadas por los sensores y la información de posición están disponibles para que el personal médico, usuario del sistema, acceda a ellas a través de dos tipos de unidades. La primera de ellas se expone en el capítulo 5. La segunda de estas unidades es la UCMNM (Unidad de Control y Monitorización No Móvil): gracias a ella, desde un ordenador con acceso a Internet el usuario puede monitorizar la información de bioseñales y posición de un paciente, así como controlar los dispositivos que recogen dicha información Arquitectura La arquitectura del subsistema UCMNM (Unidad de Control y Monitorización No Móvil) presentada en el esquema de la figura 6.1 consta de un módulo principal denominado Sistema de Control y Monitorización (SCM), y de dos módulos de interfaz: uno para la comunicación con el Servidor Central (Interfaz UCMNM/SCC) y otro para la interacción con el usuario (Interfaz UCMM/usuario). Las funciones de cada uno de los módulos que integran la UCMNM son: Interfaz UCMNM/SCC: Establecer comunicación con el SCC. Actuar de pasarela entre el SCC y el módulo SCM de la UCMNM. Enviar al SCC los comandos de control que el usuario de la UCMNM seleccione a través de la interfaz de usuario, para que sean ejecutados en el sensor elegido. 95

108 96 CAPÍTULO 6. UNIDAD DE CONTROL Y MONITORIZACIÓN NO MÓVIL Sistema de Control y Monitorización (SCM): Controlar al módulo Interfaz UCMNM/SCC. Controlar al módulo Interfaz UCMNM/usuario. Actuar de pasarela entre ambos interfaces. Gestionar la información recibida desde el SCC, que puede ser de dos tipos: Información de datos muestreados. Las tramas con los datos muestreados por los sensores que el SCC recibe se envían ya descodificadas a la UCMNM. Este comportamiento difiere del realizado por el SCC respecto a la UCMM y se justifica por la naturaleza del Interfaz UCMNM/SCC que se explica en el apartado 6.2. En cada transmisión el SCC no sólo entrega a la UCMNM las tramas generadas por los sensores, sino que además añade el modo de funcionamiento del sensor. De esta forma se descarga a la UCMNM de tareas de procesamiento y gestión de los citados modos, permitiéndole ser un cliente ligero. Información de control. De los posibles paquetes de control que el NI envía al SCC, sólo el de desconexión de sensor es reenviado a la UCMM. El resto de paquetes de control que informan al SCC sobre la ejecución de los comandos de control no se retransmiten a a la UCMM. La razón es que el Servidor Central (SCC) mantiene comunicaciones con un número previsiblemente elevado de unidades de monitorización UCMM y UCMNM, que pueden abrir y cerrar esas comunicaciones tantas veces como deseen sus usuarios. Por consiguiente, si se quisiera informar a las unidades de monitorización de la evolución en la ejecución de los comandos de control, el SCC tendría que hacer un seguimiento exhaustivo de cada sesión abierta por éstas, requiriéndose además un protocolo más elaborado para la comunicación entre SCC y UCMM, UCMNM. Ambos aspectos no se han llevado a cabo porque no es objetivo del Proyecto tal gestión de errores, y por una cuestión de limitación temporal del desarrollo. Constituyen, en cualquier caso, una posible ampliación futura. Interfaz UCMNM/usuario: Representar en una IU (interfaz de usuario) la información muestreada por todos los sensores que el paciente seleccionado por el usuario posea. Esta información llega a la UCMNM desde el SCC, y es previamante tratada por el módulo SCM.

109 6.2. DISEÑO SOFTWARE 97 Representar en una IU la información de localización del paciente escogido, información que llega a la UCMNM desde el SCC. Recoger desde una IU los comandos que el usuario ordena para un determinado sensor. Entregar los comandos de control, ordenados por el usuario, al módulo SCM Diseño software La UCMNM es un cliente del servidor SCC el cual, a su vez, es un Servidor J2EE con funcionalidad extendida. Los clientes J2EE pueden ser de dos tipos [8]: Clientes web, que constan de dos partes: 1. Páginas web dinámicas que contienen varios tipos de lenguaje de marcado (HTML, XML, etc...), generadas por el Servidor J2EE. 2. Un navegador web que interpreta las páginas recibidas desde el servidor. Los clientes web son llamados a veces clientes ligeros (thin clients) porque normalmente no efectúan peticiones a bases de datos, ni ejecutan lógica complicada, de forma que tales operaciones son descargadas al Servidor J2EE. Una página web recibida desde el Servidor J2EE puede incluir un applet embebido, que es un tipo de cliente web. Se trata de una pequeña aplicación cliente programada en Java, que se ejecuta en la máquina virtual del mismo lenguaje instalada en el navegador web. Los otros dos tipos de clientes web son los servlets y las JSP, que a diferencia de los applets, se ejecutan en el Servidor J2EE y por tanto no requieren de la existencia de una máquina virtual Java instalada en el host del cliente. Aplicaciones cliente, que se ejecutan en la máquina cliente y provee a los usuarios de un modo de manejar tareas que requieran una interfaz de usuario más compleja de la que puede ofrecer un lenguaje de marcado. Con los lenguajes de marcado se puede implementar una interfaz de usuario adecuada a la UCMNM, por tanto se ha optado desarrollar la UCMNM como un cliente web. De los posibles clientes web se han descartado los creados por servlets o JSP ya que presentan la siguiente desventaja clave, solucionable en un applet: el refresco de la página HTML en la que se incrusta la vista del cliente web sólo podría realizarse mediante repetidas invocaciones a una misma URL. El applet sin embargo lo realiza en su código que se ejecuta en la máquina cliente. En consecuencia, el cliente web elegido para implementar la UCMNM es un applet.

110 98 CAPÍTULO 6. UNIDAD DE CONTROL Y MONITORIZACIÓN NO MÓVIL Diseño software del módulo Interfaz UCMNM/SCC Justificación Como se ha justificado en el apartado 4.2.2, la interfaz idónea entre el SCC y la UCMNM se basa en la tecnología RMI (Remote Method Invocation): esta tecnología permite a un applet invocar métodos de un objeto Java que se esté ejecutando en el servidor (el SCC, que es un Servidor J2EE), así como comportamiento recíproco: que el objeto pueda invocar métodos del applet Desarrollo A continuación se describe el módulo Interfaz UCMNM/SCC que comunica la UCMNM con el Servidor Central utilizando RMI. A nivel software, el módulo Interfaz UCMNM/SCC se ha modelado con la interfaz Java ClienteSCC -véase figura 6.2-, que extiende a Remote para incluir soporte RMI. La misma figura muestra también la clase con la que se ha desarrollado el applet que modela a la UCMNM, AppletMonitorPacientes, que implementa la interfaz remota Java ClienteSCC, adquiriendo así la funcionalidad del módulo Interfaz UCMNM/SCC. Los métodos del interfaz Java ClienteSCC, implementados por el applet, se ponen a disposición de los objetos remotos, que los invocarán desde el SCC. El SCC, a su vez, pone a disposición del applet otros métodos remotos. De este modo se consigue una comunicación interactiva entre ambos, es decir, entre la UCMNM y el SCC. Para que el applet pueda invocar los métodos del SCC, ha de conocer las siguientes informaciones que se listan junto con el método que permite obtenerlas: Máquina en que el SCC se registró como objeto remoto (esta máquina debe siempre ser la misma desde la que el applet fue descargado). Esto se consigue en el método getregistryhost(). El puerto, del que informa el método getregistryport(). El nombre bajo el que lo hizo, devuelto por el método getregistryname(). Con todo ello, el applet puede obtener una referencia al objeto remoto que modela al SCC para invocar sus métodos, y la obtiene con el método getservidormonitorizacion(). La apariencia del applet, esto es, los componentes gráficos que aparecen en el documento HTML descargado, se establece en el método estableceriu().

111 6.2. DISEÑO SOFTWARE 99 Figura 6.1: Arquitectura del subsistema UCMNM. Figura 6.2: Diagrama de clases del Interfaz UCMNM/SCC.