PFC Alfredo E SÃ¡ez PÃ©rez de La Lastra

Proyecto Fin de Carrera
Ingeniera de Telecomunicacin
Desarrollo de aplicacin IoMT sobre Raspberry Pi

para monitorizacin de datos biomdicos
Autor: Alfredo Enrique Sez Prez de la Lastra

Tutor: Antonio Jess Sierra Collado
Equation Chapter 1 Section 1
Departamento de Ingeniera Telemtica

Escuela Tcnica Superior de Ingeniera
Universidad de Sevilla
Sevilla, 2016
Proyecto Fin de Carrera
Ingeniera de Telecomunicacin
Desarrollo de aplicacin IoMT sobre Raspberry Pi

para monitorizacin de datos biomdicos
Autor:
Alfredo Enrique Sez Prez de la Lastra
Tutor:
Antonio Jess Sierra Collado
Profesor titular
Departamento de Ingeniera Telemtica

Escuela Tcnica Superior de Ingeniera
Universidad de Sevilla
Sevilla, 2016
NDICE
1 Objetivos ............................................................................................................................................. 11
2 Introduccin ........................................................................................................................................ 13
Recoleccin de datos .................................................................................................................................13
Almacenamiento e intercambio de la informacin procedente de dispositivos clnicos ......................14
Visualizacin de las constantes biomdicas del paciente .......................................................................14
Diagrama de componentes implicados....................................................................................................14
3 Soluciones IoMT alternativas ............................................................................................................... 17
Capsule .......................................................................................................................................................17
Picis Hawkeye.............................................................................................................................................19
OpenICE ......................................................................................................................................................19
Resumen de las soluciones IoMT alternativas .........................................................................................21
4 Anlisis de tecnologas ......................................................................................................................... 23
Hardware de integracin ..........................................................................................................................23
4.1.1 Descripcin .........................................................................................................................................23
4.1.2 Anlisis de alternativas ......................................................................................................................23
Sistema Operativo del Hardware de integracin ....................................................................................25
4.2.1 Descripcin .........................................................................................................................................25
4.2.2.1 SO Linux ......................................................................................................................................26
4.2.2.2 SO Windows ...............................................................................................................................26
4.2.2.3 Otros SO .....................................................................................................................................26
Clster de servidores de mensajes ............................................................................................................26
4.3.1 Descripcin .........................................................................................................................................26
4.3.2.1 Apache Kafka..............................................................................................................................27
4.3.2.2 RabbitMQ ...................................................................................................................................29
Base de datos .............................................................................................................................................30
4.4.1 Descripcin .........................................................................................................................................30
4.4.2.1 Oracle..........................................................................................................................................31
4.4.2.2 MySQL.........................................................................................................................................32
4.4.2.3 SQL Server ..................................................................................................................................32
Entorno de desarrollo para BBDD.............................................................................................................32
4.5.1 Descripcin .........................................................................................................................................32
4.5.2.1 Oracle SQL Developer................................................................................................................33
4.5.2.2 TOAD ...........................................................................................................................................34
Lenguaje de programacin .......................................................................................................................34
4.6.1 Descripcin .........................................................................................................................................34
4.6.2.1 Java .............................................................................................................................................34
4.6.2.2 Python.........................................................................................................................................35
Capa de persistencia ..................................................................................................................................36
4.7.1 Descripcin .........................................................................................................................................36
4.7.2.1 Bajo nivel de abstraccin ..........................................................................................................36
4.7.2.2 ORM: Object-Relational mapping.............................................................................................36
4.7.2.3 Soluciones mixtas ......................................................................................................................38
Gestor de dependencias y construccin del proyecto .............................................................................38
4.8.1 Descripcin ........................................................................................................................................ 38
4.8.2 Anlisis de alternativas...................................................................................................................... 39
4.8.2.1 Ant .............................................................................................................................................. 39
4.8.2.2 Maven ........................................................................................................................................ 39
4.8.2.3 Gradle ......................................................................................................................................... 39
Entorno de desarrollo software ................................................................................................................ 40
4.9.1 Descripcin ........................................................................................................................................ 40
4.9.2 Anlisis de alternativas...................................................................................................................... 40
4.9.2.1 Eclipse......................................................................................................................................... 41
4.9.2.2 IntelliJ IDEA ................................................................................................................................ 44
4.9.2.3 NetBeans .................................................................................................................................... 45
4.9.2.4 JDeveloper ................................................................................................................................. 45
Resumen del anlisis de tecnologas empleadas en el proyecto............................................................ 46
5 Descripcin de la propuesta ................................................................................................................. 47
Arquitectura ............................................................................................................................................... 47
5.1.1 Diseo funcional ................................................................................................................................ 47
5.1.2 Prototipo inicial de la arquitectura del proyecto ............................................................................ 48
5.1.3 Modelo definitivo .............................................................................................................................. 50
Hardware de integracin con biodispositivos ......................................................................................... 53
5.2.1 El estndar HL7 .................................................................................................................................. 53
5.2.2 Protocolos propietarios .................................................................................................................... 54
5.2.3 Adaptacin entre puertos estndares ............................................................................................. 56
Base de datos............................................................................................................................................. 58
5.3.1 Tablespace ......................................................................................................................................... 58
5.3.2 Usuarios / Esquemas ......................................................................................................................... 59
5.3.3 Tablas ................................................................................................................................................. 61
5.3.3.1 Informacin comn a todas las tablas ..................................................................................... 62
5.3.3.2 Esquema HEALTH ...................................................................................................................... 63
5.3.3.3 Esquema DATA_ACQ................................................................................................................. 66
5.3.4 Secuencias.......................................................................................................................................... 71
5.3.5 ndices ................................................................................................................................................ 73
5.3.6 Permisos............................................................................................................................................. 74
Sistema de intercambio de datos: Kafka ................................................................................................. 76
5.4.1 Nodos ................................................................................................................................................. 77
5.4.2 Topics ................................................................................................................................................. 78
5.4.3 DTOs ................................................................................................................................................... 80
5.4.4 Modelo ............................................................................................................................................... 81
5.4.5 Producers ........................................................................................................................................... 82
5.4.6 Consumers ......................................................................................................................................... 85
Componentes software ............................................................................................................................. 88
5.5.1 Estructura del software del proyecto .............................................................................................. 88
5.5.2 MEDIPI Suite ...................................................................................................................................... 92
5.5.3 MEDIPi-DOM ..................................................................................................................................... 94
5.5.3.1 CORE-DOM................................................................................................................................. 96
5.5.3.2 HEALTH-DOM .......................................................................................................................... 103
5.5.3.3 DATACQ-DOM ......................................................................................................................... 107
5.5.4 MEDIPI-CLUSTER ............................................................................................................................. 108
5.5.4.1 CORE-CLUSTER......................................................................................................................... 109
5.5.5 MEDIPI-APP...................................................................................................................................... 113
5.5.5.1 CORE-APP ................................................................................................................................. 116
5.5.5.2 DDA........................................................................................................................................... 120
5.5.5.3 SAVER ....................................................................................................................................... 135
5.5.5.4 CHART....................................................................................................................................... 139
Resumen de la descripcin de la propuesta...........................................................................................145
6 Validacin ...........................................................................................................................................147
Funcionamiento de la solucin ...............................................................................................................147
Resumen de la validacin........................................................................................................................150
7 Planificacin........................................................................................................................................151
Fases de la planificacin ..........................................................................................................................151
Resumen de la planificacin....................................................................................................................153
8 Conclusiones y lneas futuras ..............................................................................................................155
Conclusiones.............................................................................................................................................155
Lneas futuras ...........................................................................................................................................156
Referencias ................................................................................................................................................157
NDICE DE FIGURAS
FIGURA 2-1. PRIMER ESQUEMA GENERAL DEL PROYECTO....................................................................................................14
FIGURA 3-1. ESQUEMA DE SMARTLINX, DE CAPSULE TECH, INC .......................................................................................17
FIGURA 3-2. MODELOS DE LA SERIE SMARTLINX AXON ......................................................................................................18
FIGURA 3-3. SMARTLINX IQ ............................................................................................................................................18
FIGURA 3-4. LOGO DE HAWKEYE, DE LA COMPAA PICIS CLINICAL SOLUTIONS..................................................................19
FIGURA 3-5. INTERFAZ DE USUARIO DE HAWKEYE CON LAS CONSTANTES DE UN PACIENTE. ..................................................19
FIGURA 3-6. ASTM F-2761 VS IMPLEMENTACIN DE OPENICE.........................................................................................20
FIGURA 3-7. INTERFAZ SUPERVISOR DE OPENICE ..............................................................................................................20
FIGURA 3-8. INTERFAZ DISPOSITIVO OPENICE ..................................................................................................................21
FIGURA 4-1. CATLOGO DE SISTEMAS OPERATIVOS PARA LA RASPBERRY PI 2.......................................................................25
FIGURA 4-2. LOGO DE APACHE KAFKA..............................................................................................................................27
FIGURA 4-3. ARQUITECTURA BSICA JAVA ........................................................................................................................27
FIGURA 4-4. CONSUMICIN DE MENSAJES DEL CLSTER .....................................................................................................28
FIGURA 4-5. TOPICS Y PARTICIONES EN KAFKA...................................................................................................................28
FIGURA 4-6. LOGO RABBITMQ .......................................................................................................................................29
FIGURA 4-7. RANKING DE BASES DE DATOS DE DB-ENGINES. ..............................................................................................30
FIGURA 4-8. LOGO ORACLE DATABASE.............................................................................................................................31
FIGURA 4-9. LOGO MYSQL ............................................................................................................................................32
FIGURA 4-10. LOGO SQL SERVER ....................................................................................................................................32
FIGURA 4-11. LOGO SQL DEVELOPER ..............................................................................................................................33
FIGURA 4-12. INTERFAZ GRFICA SQL DEVELOPER ............................................................................................................33
FIGURA 4-13. LOGO DE TOAD........................................................................................................................................34
FIGURA 4-14. LOGO DE JAVA ..........................................................................................................................................34
FIGURA 4-15. PLATAFORMAS JAVA ..................................................................................................................................35
FIGURA 4-16. LOGO DE PYTHON .....................................................................................................................................35
FIGURA 4-17. LOGO DE JDBC .........................................................................................................................................36
FIGURA 4-18. LOGOS DE LAS PRINCIPALES IMPLEMENTACIONES JPA: HIBERNATE, ECLIPSELINK Y OPENJPA ............................37
FIGURA 4-19. LOGO DE QUERYDSL .................................................................................................................................37
FIGURA 4-20. LOGO DE IBATIS ........................................................................................................................................38
FIGURA 4-21. LOGO DE ANT ...........................................................................................................................................39
FIGURA 4-22. LOGO DE MAVEN ......................................................................................................................................39
FIGURA 4-23. LOGO DE GRADLE ......................................................................................................................................39
FIGURA 4-24. COMPARATIVA ENTRE LOS IDES JAVA MS USADOS ......................................................................................41
FIGURA 4-25. ARQUITECTURA DE ECLIPSE. ........................................................................................................................41
FIGURA 4-26. INTERFAZ DE ECLIPSE IDE. ..........................................................................................................................43
FIGURA 4-27. PERSPECTIVAS. ..........................................................................................................................................43
FIGURA 4-28. VISTA DE GESTIN DE PROYECTOS. ..............................................................................................................43
FIGURA 5-1. TIPOS DE CONSTANTES MDICAS, CONTINUAS Y DISCRETAS...............................................................................48
FIGURA 5-2. PRIMER PROTOTIPO DE MEDIPI ...................................................................................................................48
FIGURA 5-3. LEYENDA PRIMER PROTOTIPO DE MEDIPI ......................................................................................................49
FIGURA 5-4. ESQUEMA DEL SISTEMA DE FICHEROS DISTRIBUIDOS HDFS EMPLEADO POR HADOOP. ........................................50
FIGURA 5-5. ESQUEMA GENERAL DE LA ARQUITECTURA .....................................................................................................51
FIGURA 5-6. LEYENDA ESQUEMA GENERAL DE LA ARQUITECTURA ........................................................................................51
FIGURA 5-7. A LA IZQUIERDA, UN SENSOR DE PULSO CARDACO. A LA DERECHA, UN VENTILADOR DE GENERAL ELECTRICS .........53
FIGURA 5-8. LA RASPBERRY PI 2 B OFRECE 4 PUERTOS USB A BAJO COSTE...........................................................................55
FIGURA 5-9. ESQUEMA DE UNA ADAPTACIN RS232 (DB9) A USB....................................................................................57
FIGURA 5-10. ADAPTADOR EMPLEADO EN EL PROYECTO ....................................................................................................57
FIGURA 5-11. TABLESPACE INICIALES DE UNA BASE DE DATOS ORACLE XE 11G R2................................................................58
FIGURA 5-12. PARMETROS DE CONEXIN POR DEFECTO DE LA BASE DE DATOS ...................................................................59
FIGURA 5-13. MODELO DE DATOS ...................................................................................................................................61
FIGURA 5-14. MODELO DE DATOS SOBRE BIODISPOSITIVOS ................................................................................................ 66
FIGURA 5-15. ARQUITECTURA BSICA DE KAFKA ............................................................................................................... 76
FIGURA 5-16. MODELO DEL CLSTER............................................................................................................................... 81
FIGURA 5-17. ESTRUCTURA DE PROYECTOS DOM (DOCUMENT OBJECT MODEL) (BASE DE DATOS) ...................................... 89
FIGURA 5-18. ESTRUCTURA DE PROYECTOS CLUSTER (KAFKA) ............................................................................................ 89
FIGURA 5-19. ESTRUCTURA DE PROYECTOS APP (ELEMENTOS COMUNES DE APLICACIONES MEDIPI) .................................... 89
FIGURA 5-20. ESTRUCTURA DE PROYECTOS MEDIPI. REPRESENTACIN GRFICA................................................................. 90
FIGURA 5-21. ESTRUCTURA DE PROYECTOS MEDIPI. REPRESENTACIN EN CARPETAS .......................................................... 91
FIGURA 5-22. PROYECTO CORE-DOM............................................................................................................................... 96
FIGURA 5-23. PATRN DAO EN MEDIPI ...................................................................................................................... 101
FIGURA 5-24. PROYECTO HEALTH-DOM ......................................................................................................................... 104
FIGURA 5-25. PROYECTO DATACQ-DOM ........................................................................................................................ 107
FIGURA 5-26. PROYECTO CORE-CLUSTER ....................................................................................................................... 110
FIGURA 5-27. PROYECTO CORE-APP .............................................................................................................................. 117
FIGURA 5-28. ESTRUCTURA DE UN PROYECTO DURANTE EL DESARROLLO VS COMPILADO ..................................................... 118
FIGURA 5-29. PROYECTO DDA ..................................................................................................................................... 120
FIGURA 5-30. ESQUEMA DE DDA ................................................................................................................................. 123
FIGURA 5-31. PROTOCOLREADER.................................................................................................................................. 130
FIGURA 5-32. COMMANDLISTENER ............................................................................................................................... 133
FIGURA 5-33. DATASENDERMANAGER .......................................................................................................................... 134
FIGURA 5-34. PROYECTO SAVER.................................................................................................................................. 136
FIGURA 5-35. ESQUEMA DE SAVER .............................................................................................................................. 137
FIGURA 5-36. PROYECTO CHART ................................................................................................................................. 140
FIGURA 5-37. ESQUEMA DE CHART ............................................................................................................................. 141
FIGURA 6-1. RASPBERRY PI 2 MODELO B CONECTADA A UN BIODISPOSITIVO MEDIANTE UN ADAPTADOR USB RS232 ........ 147
FIGURA 6-2. MDULO DDA DESPLEGADO EN LA RASPBERRY ........................................................................................... 147
FIGURA 6-3. ENTORNO DE DESARROLLO SQL CONECTADO CORRECTAMENTE A LA BASE DE DATOS........................................ 148
FIGURA 6-4. NODOS ZOOKEEPER, BROKER 1 Y BROKER 2 ARRANCADOS SOBRE UNA MISMA MQUINA WINDOWS ................ 148
FIGURA 6-5. LOG DE EJECUCIN, EN MODO DEBUG, DE DDA EN LA RASPBERRY ................................................................. 148
FIGURA 6-6. LOG DE UN BROKER KAFKA ........................................................................................................................ 149
FIGURA 6-7. LOG DE SAVER ........................................................................................................................................ 149
FIGURA 6-8. TABLA CONSTANT_INFO CON DATOS INSERTADOS POR SAVER ................................................................. 149
FIGURA 6-9. EJECUCIN DE CHART, EN LA QUE PODEMOS VER DATOS (SIMULADOS) A TIEMPO REAL ..................................... 150
FIGURA 7-1. PLANIFICACIN PLANTEAMIENTO................................................................................................................ 151
FIGURA 7-2. PLANIFICACIN FASE DE ANLISIS................................................................................................................ 151
FIGURA 7-3. PLANIFICACIN PRUEBA DE CONCEPTO ........................................................................................................ 152
FIGURA 7-4. PLANIFICACIN DESARROLLO I.................................................................................................................... 152
FIGURA 7-5. PLANIFICACIN DESARROLLO II................................................................................................................... 153
FIGURA 7-6. PLANIFICACIN POSTDESARROLLO .............................................................................................................. 153
Desarrollo de aplicacin IoMT sobre Raspberry Pi para monitorizacin de datos biomdicos 11
1 OBJETIVOS
E
n la actualidad, la prctica totalidad de los centros sanitarios de pases desarrollados o en vas de desarrollo
cuentan con aplicaciones informticas destinadas a la historia clnica del paciente. Son sistemas enfocados
a sustituir la gestin que se realizaba hasta hace pocos aos de forma manual, generalmente mediante el
mantenimiento de archivos fsicos en los que ubicar los informes del paciente o las notas de los facultativos. Sin
embargo, estas aplicaciones no son capaces de ir un paso ms all de la mera gestin clnica. En los ltimos aos
han aparecido nuevos enfoques que apuestan por la integracin de los dispositivos cotidianos en Internet y la
explotacin de las posibilidades que esto genera. A este concepto se la ha comido como Internet de las cosas,
IoT por sus siglas en ingls (Internet of Things). La aplicacin de esta visin al mbito clnico es poco habitual
en el mercado, de forma que apenas se han explorado sus previsibles beneficios.
Para realizar un proyecto que permita llevar el IoT al mbito mdico se debe partir de que los principales
dispositivos electrnicos vinculados al diagnstico y tratamiento sanitario son aquellos encargados de medir la
informacin biomdica de los pacientes. Por tanto, cualquier apuesta por el desarrollo e implantacin del IoMT
(Internet of Medical Things) debe sustentarse sobre la conexin de dichos dispositivos a la red gracias a
determinadas soluciones hardware y/o software que permitan su comunicacin con otros programas o
aplicaciones.
Partiendo de todo lo anterior, parece razonable aventurar que toda apuesta por el IoMT debe marcarse como
labor fundamental abordar, en mayor o menor grado, los siguientes requisitos:
- El enfoque principal debe girar en torno a los biodispositivos, pues son ellos los que nos permiten hablar
de Internet de las cosas. Para ello se ha de disear una solucin hardware y/o software que permita la
comunicacin entre los dispositivos ya existentes en el mercado y el mayor nmero posible de
aplicaciones software a travs de la red.
- Dichos dispositivos se han de comportar grosso modo como fuente de informacin. Este
comportamiento es anlogo al ya existente en la actualidad, en el que los biodispositivos sirven como
fuente de informacin a los facultativos. Por tanto, la conexin de dichos dispositivos al Internet de las
cosas pasa por disear una herramienta capaz de ofrecer la informacin biomdica del paciente. Para
realizar tal labor se torna imprescindible conocer los protocolos empleados en la exportacin de datos
clnicos.
- Una vez se ofrezca a las aplicaciones de Internet acceder a la informacin medida por los biodispositivos
se deber estudiar la posibilidad de establecer una comunicacin bidireccional, de forma de que dichas
aplicaciones puedan influir en el comportamiento de los biodispositivos.
- Gracias a la IoMT, la informacin biomdica puede estar centralizada y ser fcilmente accesible desde
cualquier dispositivo con acceso a Internet. Ser necesario abordar algn desarrollo en este sentido, con
el fin de ejemplificar los beneficios ms inmediatos de la tecnologa empelada.
- Trabajar con biodispositivos va a estar ligado inherentemente a la gestin de grandes cantidades de
datos, dada la alta frecuencia a la que dichos componentes miden las variables clnicas de los pacientes.
Esto abre la puerta al big data, concepto que hace referencia al almacenamiento y procesado de los
datos recuperados en busca de patrones. La posibilidad de aadir big data a todo proyecto IoMT debe
ser tenida en cuenta desde el primer momento, incluso condicionando las decisiones de diseo si es
necesario.
Por tanto, el presente proyecto plantea una solucin concreta a la necesidad de implantar el concepto IoT en el
mbito sanitario, apostando por tomar como elemento central la recoleccin y centralizacin de la informacin
biomdica proporcionada por los mltiples biodispositivos empleados en el tratamiento sanitario de los
pacientes, permitiendo adems que toda la informacin recuperada est disponible por otras aplicaciones a travs
de Internet. Por tanto, el proyecto abarca la intercomunicacin con los biodispositivos y la articulacin de un
mtodo adecuado para que otras aplicaciones puedan acceder a los datos. Adems, se ha fijado como objetivo
proporcionar alguna funcionalidad adicional que nos permita mostrar las utilidades que la IoMT (Internet of
11
12 Objetivos
Medical Things) puede llegar a ofrecer a los usuarios. Para ello se ha diseado una herramienta de visualizacin
que permita a los facultativos observar en tiempo real todas las constantes de cualquier paciente. De lo expuesto
hasta ahora surgen claramente tres sectores, tres funcionalidades diferentes que conformarn el proyecto
desarrollado:
- Recuperacin de la informacin biomdica
- Almacenamiento e intercambio de dichos datos con cualquier aplicacin
- Visualizacin a tiempo real de la misma.
Como se ha visto en estos objetivos, la introduccin del Internet de las cosas en el mbito mdico nos obliga a
alcanzar una serie de hitos, enfocados fundamentalmente a la comunicacin con los biodispositivos. A lo largo
de esta memoria se detallar la solucin concreta ideada para satisfacerlos, exponiendo en todo momento los
motivos de las decisiones adoptadas.
12
2 INTRODUCCIN
E
l presente proyecto plantea una solucin concreta a la necesidad de implantar el concepto IoT (Internet de
las cosas) en el mbito sanitario, apostando por tomar como elemento central la recoleccin y
centralizacin de la informacin biomdica proporcionada por los mltiples biodispositivos empleados en
el tratamiento sanitario de los pacientes, permitiendo adems que toda la informacin recuperada est disponible
por otras aplicaciones a travs de Internet. Por tanto, el proyecto abarca la intercomunicacin con los
biodispositivos y la articulacin de un mtodo adecuado para que otras aplicaciones puedan acceder a los datos.
Adems, se ha fijado como objetivo proporcionar alguna funcionalidad adicional que nos permita mostrar las
utilidades que la IoMT (Internet of Medical Things) puede llegar a ofrecer a los usuarios. Para ello se ha diseado
una herramienta de visualizacin que permita a los facultativos observar en tiempo real todas las constantes de
cualquier paciente. De lo expuesto hasta ahora surgen claramente tres sectores, tres funcionalidades diferentes
que conformarn el proyecto desarrollado:
- Recuperacin de la informacin biomdica
- Almacenamiento e intercambio de dichos datos con cualquier aplicacin
- Visualizacin a tiempo real de la misma.
Para mostrar esto de la manera ms clara posible, tanto en el proyecto en s como a lo largo de la presente
memoria se har alusin constante a esta clasificacin.
Recoleccin de datos
El primer aspecto a considerar es la recuperacin de las constantes vitales de los pacientes, ncleo central del
proyecto. La primera tarea es conocer las capacidades de exportacin de datos de los dispositivos mdicos
existentes actualmente en el mercado. El principal problema a afrontar en esta seccin es la amplia diversidad:
existen numerossimos productos en el sector (desde empresas especializadas hasta gigantes del mercado como
Philips, General Electric, Siemens, etc.) y hay una evidente falta de estandarizacin tanto a nivel hardware como
software en el terreno de la exportacin de la informacin.
Esto ha ido cambiando con el tiempo, y en la actualidad es cada vez ms habitual encontrarse con biodispositivos
del mercado que ofrecen la posibilidad de exportar los datos mediante el protocolo HL7 (Health Level Seven)
[1]. Sin embargo, y a pesar de este y otros esfuerzos realizados por iniciativas como la Integrating the Healthcare
Enterprise [2], HL7 todava no es un estndar ampliamente usado por las empresas del sector en el mbito de la
exportacin de datos e interoperacin con los biodispositivos, y solo los productos ms modernos lo soportan.
Esto ltimo no es balad; dado el alto coste de estos dispositivos su periodo de renovacin es amplio, lo que
dificulta su implantacin.
Este proyecto constituye la base de un sistema de gestin de informacin biomdica real, por lo que no se debe
ignorar la realidad del mercado: aunque el estndar HL7 es realmente interesante, es prioritario ofrecer una
solucin de recoleccin de datos que satisfaga las necesidades actuales de los centros sanitarios, obligando a
tratar con los diferentes protocolos propietarios de cada empresa. Adems, algunos protocolos propietarios
permiten modificar el funcionamiento del biodispositivo, funcionalidad para la que HL7 no est diseado.
La inmensa mayora de los protocolos propietarios empleados por los biodispositivos del mercado para permitir
la exportacin de la informacin clnica medida emplean una comunicacin cliente servidor (a menudo
entendida como maestro esclavo) a travs de interfaces series (RS232 o USB) o paralelo. Por tanto, el escenario
que se ha de abordar es un conjunto de dispositivos diferentes, que necesitan cada uno un cliente especfico con
el que establecer una comunicacin directa. Para ello, se ha llevado a cabo la tarea de elaborar una solucin que
incluye un componente hardware de integracin. Por tanto, se necesita un hardware especial para cada
dispositivo (mejor dicho, para un conjunto de ellos) sobre el que correr un software capaz de transformar la
informacin a un estndar interno de la suite. Cada hardware contar con una versin del mismo software, que
ser totalmente parametrizable, pudiendo indicrsele con qu conjunto de dispositivos debe comunicarse. Para
13
14 Introduccin
cubrir esta necesidad, se ha realizado el diseo de la arquitectura del software, estableciendo un conjunto de
elementos comunes y patrones de diseo enfocados a facilitar el trabajo con protocolos diferentes.
Almacenamiento e intercambio de la informacin procedente de dispositivos

clnicos
La informacin recuperada deber almacenarse en algn sistema apropiado que permita a otras aplicaciones
acceder a la mima de forma estructurada. Es por este motivo por el que se ha diseado una base de datos SQL
sobre la que gestionar no solo las variables clnicas de los pacientes, sino tambin informacin administrativa de
los pacientes necesaria para dotar de sentido a los biodatos, parametrizacin de las aplicaciones, etc. Sin
embargo, esto no cubre uno de los objetivos centrales del proyecto: permitir a otras aplicaciones de Internet
acceder a los datos de la manera ms cmoda pasible. Con esto en mente, se ha optado por emplear un clster
de servidores de mensajes que facilite el intercambio de informacin entre todos los puntos. Adems, este
sistema es ms adecuado para soportar el gran volumen de datos procesables y la necesidad de trabajar con
informacin a tiempo real.
Visualizacin de las constantes biomdicas del paciente

La ltima parte del proyecto es una aplicacin que permita una visualizacin sencilla de la informacin
biomdica de un paciente concreto a tiempo real, ofreciendo as una interfaz de acceso para todos los pblicos a
las posibilidades del conjunto de aplicaciones desarrolladas.
Diagrama de componentes implicados

Con todo lo anterior se ha introducido la funcin bsica del proyecto: recuperacin, almacenamiento/intercambio
y visualizacin de la informacin biomdica de un paciente. La solucin ideada se compone de elementos
hardware y software, por lo que es necesario entender cules conforman conformar el proyecto y cmo se
relacionan entre s. Para ello, se ha propone implementar el siguiente esquema esquema.
Figura 2-1. Primer esquema general del proyecto
Como se ha comentado ya, en MEDIPi existirn tres sectores diferentes, cada uno encargado de implementar
una funcionalidad determinada: recoleccin, almacenamiento/intercambio y visualizacin. Cada uno de ellos se
corresponde con una aplicacin software diferente, que se deber ejecutar, o no, sobre un hardware concreto:
14
- Software de recoleccin: se ejecutar sobre un hardware de integracin con biodispositivos

especfico, en concreto, una Raspberry Pi 2 Modelo B configurada para actuar como conector del
biodispositivo a otras aplicaciones; es decir, al Internet de las cosas.
- Software de almacenamiento: se podr ejecutar sobre cualquier servidor u ordenador personal. Deber
tener acceso a la base de datos y al clster para poder realizar su funcionalidad.
- Software de visualizacin: correr sobre cualquier ordenador o dispositivo compatible. Recuperar la
informacin de algn sistema de almacenamiento.
En resumen, MEDIPi se compondr de tres aplicaciones software, un hardware de integracin con

biodispositivos, una base de datos y un sistema de intercambio de mensajes formado por un clster de servidores.
Todos estos elementos permiten cubrir las necesidades detectadas a la hora de abordar un proyecto que lleva el
IoT al mbito sanitario, algo prcticamente inexistente en la inmensa mayora de centros sanitarios. Aun as, s
que existen ya en el mercado productos que apuestan por la recuperacin y explotacin de la informacin
procedente de biodispositivos, enfocando su funcionalidad desde una perspectiva similar a la aqu comentada:
recuperacin de datos, almacenamiento/intercambio y visualizacin, lo que permite comprobar la solidez de los
puntos de partida del proyecto.
Todo lo descrito hasta ahora se detallar a lo largo de esta memoria: el prximo captulo se dedicar a analizar
las soluciones existentes en el mercado de los productos IoMT, mientras que el siguiente realizar un estudio de
las tecnologas empleadas en el desarrollo, incluyendo una comparativa con el resto de alternativas. A
continuacin, llegar el turno de llevar a cabo una descripcin detallada del proyecto realizado, comentando
todas las partes implicadas y exponiendo ejemplos concretos de la solucin implementada. Tras esto, se validar
el correcto funcionamiento del proyecto y se dedicar un captulo a la planificacin temporal que se ha seguido
durante el desarrollo del mismo. Para terminar, la memoria se cierra con un apartado enfocado a realizar las
conclusiones del proyecto, exponiendo los aspectos ms importantes, analizando si se han cumplido o no los
objetivos marcados de partida y poniendo sobre la mesa las posibilidades futuras del proyecto.
15
16 Introduccin
16
3 SOLUCIONES IOMT ALTERNATIVAS
E
l conjunto de herramientas y aplicaciones diseadas nos permite ofrecer una serie de funcionalidades que
giran en torno a la informacin biomdica de un paciente. El proyecto no busca solo recuperar la
informacin biomdica, tambin gestiona su almacenamiento e intercambio y visualizacin. Encontrar en
el mercado soluciones con este enfoque no es tarea sencilla, pues nos encontramos ante una funcionalidad poco
extendida, pero es posible reconocer algunos productos comparables con la solucin MEDIPi aqu diseada, de
los cuales destacan tres:
- Capsule SmartLinx
- Picis Hawkeye
- OpenICE
Capsule
Figura 3-1. Esquema de SMARTLINX, de Capsule Tech, Inc
La empresa lder en soluciones de centralizacin e integracin de datos procedentes de biodispositivos mdicos

es, sin lugar a dudas, Capsule. A travs de la marca SmartLinx [3], Capsule ofrece un conjunto variado y slido
de hardware de integracin con los dispositivos mdicos compatible con software especializado en el tratamiento
de la informacin recopilada y con aplicaciones de gestin de historia clnica. La estructura empleada por
Capsule se sustenta en una red propia a la que se conectan todos los dispositivos compatibles. Cuando se trabaje
con protocolos propietarios se deber emplear un mdulo intermedio, que traduzca del protocolo propietario al
interno empleado en la red. Para ello cuenta con varios dispositivos, siendo el ms bsico las distintas revisiones
de la serie SmartLinx Axon [4]. Para el usuario el dispositivo Axon se comporta como una caja negra con
entradas y salidas. Como interfaces de entrada se ofrecen un conjunto de puertos serie a los que conectar los
biodispositivos, mientras que la salida es una mera interfaz ethernet o incluso WiFi que se debe conectar a la red
de Capsule. El componente Axon ser el encargado de recuperar la informacin y adaptarla al protocolo interno
de la compaa.
17
18 Soluciones IoMT alternativas
Figura 3-2. Modelos de la serie SmartLinx Axon
Junto a los productos de la serie Axon Capsule ofrece otras soluciones de integracin similares, que suelen
aportar funcionalidades extras a las ya comentadas. Por ejemplo, la serie SmartLinx Vitals Stream [5] permite
visualizar en su pantalla integrada la informacin recuperada, adems de traducirla y enviarla a la red. En la
citada red de dispositivos que necesita la solucin SmartLinx se encuentra al menos un servidor HL7 (Health
Level Seven) que procese la informacin procedente de aquellos biodispositivos que empleen el estndar de
comunicacin mdica.
Adems de la mera recuperacin de las variables clnicas de los pacientes, Capsule cuenta con el denominado
SmartLinx Client [6], un software que se comunica con el servidor central de la red para gestionar la seleccin,
filtrado, transformacin y adicin de ms informacin a los datos recopilados. Con esta utilidad se pueden
mejorar la calidad de los biodatos de los pacientes, supliendo deficiencias o eliminando aquella informacin
errnea o incoherente. Sin embargo, estas funcionalidades solo se entienden como pasos previos a la utilizacin
de las constantes clnicas del paciente junto al resto de su historia mdica, permitiendo as que sean tiles en el
diagnstico de la situacin del enfermo. Capsule centra sus esfuerzos en la integracin con biodispositivos, ms
que en presentar una solucin de gestin de historia mdica electrnica del paciente (Electronic Medical Record,
EMR). Su modelo de negocio consiste en ofrecer acuerdos con otros proveedores de aplicaciones EMR, que
recibirn los biodatos ya adaptados en formato HL7 o en otro formato acordado. Aun as, Capsule s ha realizado
algunos movimientos en el mbito de las interfaces grficas para usuarios: SmartLinx IQ [7] es una aplicacin
de escritorio que provee a los usuarios mecanismos para realizar anlisis y generar estadsticas a partir de los
datos de los pacientes.
Figura 3-3. SmartLinx IQ
18
Picis Hawkeye
Figura 3-4. Logo de HAWKEYE, de la compaa Picis Clinical Solutions
La solucin Hawkeye [8], de Picis, dice integrar datos procedentes de una gran variedad de dispositivos,
soportando varias interfaces de comunicacin distintas, gracias a una librera con ms de 350 drivers. La
compaa afirma soportar comunicaciones con biodispositivos a travs de cables serie (entendiendo por ello
RS232), USB o a travs de una red TCP/IP (Ethernet o Wifi), por lo que parece contar con un sistema de
integracin propio para establecer las comunicaciones necesarias con protocolos propietarios, aunque luego se
sustente en el estndar HL7. Hawkeye usa interfaces HL7 estndar tanto para recibir informacin del paciente
(clnica y administrativa) como para enviar informacin interna en dicho formato, lo que permite conectar el
sistema con otras soluciones del mercado. Adems, la informacin recuperada es centralizada en su sistema de
historia clnica, de forma que desde un solo ordenador se pueda acceder a las constantes clnicas de todos los
pacientes actuales del hospital, complementando esta funcionalidad con notificaciones, elementos de soporte a
la decisin, etc.
Figura 3-5. Interfaz de usuario de HAWKEYE con las constantes de un paciente.
OpenICE
OpenICE [9] es un software libre desarrollado en Java y soportado por el Medical Device Plug-and-Play (MD
PnP) Interoperability Program [10]. Esta iniciativa pretende fomentar el uso de la informacin procedente de los
biodispositivos mediante la estandarizacin del mayor nmero posible de los elementos implicados en la
recoleccin y procesamiento de la informacin clnica de los pacientes. Por ello, no solo apuestan por el empleo
de estndares relativamente consolidados como HL7, sino tambin por la creacin y consolidacin de otros
como el ASTM F-2761 [11], que define un modelo funcional de categorizacin y establecimiento de relaciones
entre los diferentes elementos claves que componen un entorno de gestin clnica centralizada enfocada en el
paciente. Es decir, este estndar va mucho ms all de HL7, busca definir un modelo concreto de integracin
con biodispositivos clnicos: estructuracin en capas, interfaces determinadas, etc.
19
Figura 3-6. ASTM F-2761 vs implementacin de OpenICE
OpenICE se ha diseado para servir como una posible implementacin libre de este estndar, centrndose no
solo en la arquitectura definida por el mismo, sino tambin desarrollando libreras capaces de entender algunos
de los protocolos propietarios ms empleados en el mercado. Llegado a este punto es fcil comprender las
enormes diferencias entre OpenICE y el resto de alternativas comentadas en el siguiente captulo: hasta ahora se
han tratado soluciones comerciales, que buscaban ofrecer a los centros sanitarios un producto capaz de recuperar
informacin del mayor nmero posible de biodispositivos para poder ser incluidos en una aplicacin EMR
determinada o ser analizados por determinadas soluciones. Sin embargo, OpenICE solamente pretende servir
como punto de apoyo a la expansin de un determinado patrn de trabajo, no estando enfocado a su implantacin
directa en centros sanitarios. Aun as, OpenICE soporta algunas caractersticas comparables con el resto de
competidores.
Figura 3-7. Interfaz Supervisor de OpenICE
La ventana principal de OpenICE es la supervisora, que coincide con el elemento ICE Supervisor del estndar
comentado. En ella se debe tener acceso a la informacin recuperada por cada dispositivo existente en la red,
adems de a un conjunto de funcionalidades extra (aquellas ubicadas en la zona izquierda de la ventana). El
estndar ASTM F-2761 implica que este supervisor ser el enlace con todos los dispositivos, que debern enviar
la informacin que recuperen a travs de la red. Para ello, se necesita un adaptador en cada dispositivo que
20
conozca el protocolo propietario y lo transmita en el protocolo interno de la red. Para solucionar esto, OpenICE
propone arrancar su software en modo consola y seleccionar el dispositivo, de forma que tras establecer la
comunicacin enviar los biodatos a la red mediante un sistema de datos distribuido conocido como DDS [12].
Figura 3-8. Interfaz Dispositivo OpenICE
Desde el supervisor bastar con seleccionar el dispositivo para visualizar sus datos a tiempo real, una
funcionalidad similar a la implementada en el presente proyecto.
Resumen de las soluciones IoMT alternativas

Las tres soluciones detalladas a lo largo del captulo parten de una misma idea: existe la necesidad de recuperar
y poner a disposicin de usuarios y terceras aplicaciones la enorme cantidad de informacin clnica que
proporcionan los dispositivos mdicos implicados en el tratamiento de los pacientes. Sin embargo, a pesar de
que todas tienen un objetivo comn se pueden observar fcilmente enormes diferencias. No solo tenemos que
establecer una separacin entre soluciones propietarias (Capsule y Picis) y open-source (OpenICE), sino que es
imprescindible comprender las diferentes visiones implicadas: OpenICE est orientado a construir una red de
dispositivos con entidad propia mientras que SmartLinx y Hawkeye piensan claramente en integrar sus
soluciones en aplicaciones de historia clnica. Esta visin es menos innovadora, pero facilita la integracin de
las soluciones con las aplicaciones informticas existentes actualmente en centros sanitarios, algo que sin duda
habr sido tenido en cuenta por las compaas desarrolladoras. Parece evidente que OpenICE est mucho ms
cerca que sus competidores de alcanzar los requisitos que se han marcado en este proyecto, ya que comparte un
enfoque parecido. Al ser software libre, es posible realizar una comparativa tecnolgica entre esta solucin y el
proyecto realizado. En general existen elementos comunes, ya que se han empleado tecnologas para el lenguaje
de programacin Java, aunque OpenICE carece de base de datos y apuesta por un sistema de intercambio de
datos mucho menos potente que el empleado en MEDIPi. En cualquier caso, ninguna de las aplicaciones aqu
comentadas abarca al completo el enfoque IoMT (Internet of Medical Things) sobre el que se ha construido el
proyecto.
21
22
4 ANLISIS DE TECNOLOGAS
A
ntes de plantearse abordar en detalle la descripcin del proyecto realizado es imprescindible dedicar un
captulo a realizar un estudio de las diferentes tecnologas que sern necesarias para llevarlo a cabo. Para
cada una de ellas se proceder a elaborar un anlisis comparativo entre las diferentes opciones existentes
en el mercado, estableciendo sus puntos fuertes y dbiles, como paso previo indispensable para elaborar la
justificacin de la opcin empleada en la suite desarrollada.
El proyecto abarca tres funcionalidades claramente diferenciadas: recuperacin de datos, intercambio y
visualizacin de los mimos. Parece evidente que lo ms sencillo es clasificar las tecnologas empleadas de
acuerdo a la funcin que pretenden satisfacer. Sin embargo, algunas de ellas pueden emplearse en ms de un
mbito, algo que ocurre con facilidad en todo proyecto software. Para aclarar todo este se parte de la siguiente
categorizacin:
- Tecnologas exclusivas de comunicacin con biodispositivos: hardware de integracin y sistema
operativo del Hardware de Integracin
- Tecnologas exclusivas de intercambio de la informacin biomdica: clster de servidores de mensajes,
base de datos y entorno de desarrollo para base de datos
- Tecnologas exclusivas de visualizacin: no se considera necesario al emplear las libreras de
visualizacin del lenguaje de programacin comn.
- Tecnologas comunes a todos los sectores: lenguaje de programacin Software, capa de persistencia,
gestor de dependencias y construccin del proyecto y entorno de desarrollo software.
Hardware de integracin
4.1.1 Descripcin
Para abordar la integracin con los biodispositivos se ha optado por un enfoque que nos permita soportar aquellos
dispositivos con protocolos propietarios, al ser la mayora de los existentes en el mercado. Con este objetivo en
mente, es necesario un hardware de integracin al que conectar fsicamente los dispositivos mediante interfaces
serie RS232, USB, paralelo, etc. En el presente apartado se realizar un estudio de los principales ordenadores
de placa reducida (SBC, por sus siglas en ingls), que nos permitirn manejar los datos recibidos de cada
dispositivo diferente, basndonos en los criterios justificados en el anlisis: versatilidad, escalabilidad, presencia
de interfaces estndar, coste y rendimiento
4.1.2 Anlisis de alternativas

En la actualidad, el mercado de los SBCs consta de una gran salud debido a la explosin de popularidad, en
trminos de ventas y de soporte por la comunidad, que primero Arduino y despus las diferentes versiones de la
Raspberry Pi han cosechado. El nmero de opciones disponibles ha aumentado considerablemente, sobretodo
siguiendo el modelo de Raspberry, que ofrece un sistema ms completo que Arduino, no solo enfocado al
desarrollo electrnico. En nuestro caso, nos encontramos ante un proyecto desarrollado en Java, que necesita de
la JVM corriendo sobre el hardware elegido. Conseguir esto sobre Arduino, una placa hardware enfocada a
desarrolladores de microcontroladores, es mucho ms costoso que emplear un SBC, que pretende ofrecer la
misma funcionalidad que ordenadores personales o servidores con un bajo tamao y coste. Es por este motivo
por el que se ha centrado el anlisis en las SBCs existentes en el mercado descartando otro tipo de dispositivos
hardware.
23
24 Anlisis de tecnologas
SBC Procesador Almacenamiento RAM Conectividad Precio
ARM Cortex 4 USB 2.0,

Raspberry Pi 2
A7 900 MHz SD 1 GB HDMI 1.4 y 45$
Model B [13]
quad-core Ethernet
3 USB 2.0,
Intel Atom
Jaguar One [14] 16 GB 1 GB DDR3 HDMI 1.4 y 70$
Z3735G
Ethernet
SD
1 USB 2.0,
ARM A7 4x1.2
Orange Pi [15] 512 MB HDMI y 10$
Ghz
Ethernet
4 USB 2.0,
ODROID-C1+ ARMv7 1.5
SD 1 GB DDR3 HDMI 2.0 y 40$
[16] Ghz quad core
Ethernet
2 USB 2.0,
Hummingboard ARM A9 hasta
SD 2 GB HDMI 2.0 y 70$
[17] Dual Core
Ethernet
ARM A8 1 Ghz 1 USB 2.0,

Beaglebone 512 MB
(TI Sitara 4 GB HDMI 2.0 y 45
Black [18] DDR3
AM3358) Ethernet
HDMI, USB,
Cubieboard5 ARM A7 8 Displayport,
8 GB + SATA 2 GB DDR3 99$
[19] ncleos audio digital,
Wifi, BT 4.2
ARM A7 4 2 USB 2.0,

pcDuino4 [20] ncleos 8 GB 1 GB DDR3 HDMI 2.0 y 49$
(Allwinner H3) Ethernet
En la tabla superior se puede observar una comparativa de las principales caractersticas de los SBCs con mayor
presencia en el mercado. El primer punto a tener en cuenta es que se va a conectar el hardware escogido con los
biodispositivos del paciente mediante interfaces serie o paralelo. Para ello, se partir de puertos USB (los ms
habituales) empleando adaptadores cuando sea necesario. De cara a reducir los costes del proyecto se ha de
optimizar el nmero de placas de integracin, pasando de una primera lgica 1 dispositivo 1 SBC a la de 1
puerto 1 dispositivo. Para ello no solo es necesario un dispositivo hardware con el mayor nmero de puertos
USB posibles, sino tambin con la capacidad suficiente como para ejecutar la solucin de recoleccin de datos
con mltiples lectores de protocolos a la vez. La condicin anterior nos lleva a reducir las opciones a dos: la
Raspberry Pi 2 Model B y el ODroid-C1+, quienes cuentan con unas caractersticas similares: 4 puertos USB,
ARMv7 y 1GB DDR3. ODroid gana en procesador, ofreciendo mayor velocidad de clculo, mientras que se
produce un empate tcnico en el precio. Las caractersticas tcnicas de ambos SBCs proporcionan la capacidad
suficiente como para ejecutar un sistema operativo ligero (un Linux sin entorno grfico) y la aplicacin de
recoleccin de datos diseada con los 4 lectores de protocolos funcionando en paralelo. Por tanto, la decisin
est reida, pero el gran soporte que la comunidad ofrece a Raspberry decanta la balanza a su favor: los sistemas
operativos diseados para Raspberry cuentan con una amplia utilizacin en el mercado, estando
convenientemente pulidos y garantizando una gran disponibilidad. Adems, el rendimiento de estas placas
hardware durante largos periodos de tiempo es ms que solvente, como han podido comprobar miles de usuarios
en los ltimos meses.
24
Sistema Operativo del Hardware de integracin

4.2.1 Descripcin
Una vez se ha elegido a la Raspberry Pi 2 Modelo B como la placa que conformar el hardware de integracin
con biodispositivos el siguiente paso lgico es seleccionar el sistema operativo de la SBC, que deber poder
ejecutar el software de recoleccin de datos diseado en el presente proyecto. Como se ver un poco ms
adelante, el nico requisito que se deriva del software diseado es la necesidad de soportar la Java Virtual
Machine, pues todos los componentes de la suite MEDIPi se han desarrollado bajo el lenguaje de programacin
de Oracle.

Para ejecutar la aplicacin de recuperacin de biodatos del paciente solo necesitaremos un sistema operativo
capaz de correr la mquina virtual de Java con soltura suficiente, garantizndonos el rendimiento y fiabilidad
que requiere una tarea tan crtica como la que se va a realizar en la Raspberry.
Figura 4-1. Catlogo de Sistemas Operativos para la Raspberry Pi 2
La imagen superior corresponde con una captura del apartado dedicado a sistemas operativos de la pgina web
de Raspberry. En la lnea superior, encuadrados en un rectngulo negro, se encuentran los sistemas operativos
con soporte oficial, dejando las filas inferiores para los sistemas operativos de terceras compaas.
El primer paso va a ser eliminar de la lista de candidatos a los sistemas operativos que no sean de propsito
general ni estn enfocados a desarrolladores.
- Noobs: sistema operativo de primer contacto. Ms que un sistema operativo, puede entenderse como
un conjunto de utilidades bsicas que nos permitirn seleccionar el sistema operativo que queremos
instalar de forma sencilla.
25
- OSMC / LibreElec: sistemas operativos enfocados a convertir la Raspberry Pi en centros multimedia.

- PiNet: sistema operativo enfocado a la utilizacin de la Raspberry en mbitos educativos, ofreciendo
utilidades para la gestin de mltiples Raspberrys en una misma red escolar.
- Weather Station: versin de Raspbian para llevar a cabo acciones de estacin climtica.
Una vez descartados los SOs especficos, clasificaremos los restantes en tres grupos:
4.2.2.1 SO Linux
Los Sistemas Operativos Linux dominan las preferencias de los poseedores de los distintos modelos de
Raspberry Pi, gracias a las amplias posibilidades que ofrecen tanto a desarrolladores como a usuarios finales.
Tanto Raspbian [21] como Ubuntu Mate [22] proporcionan un Sistema Operativo Linux completo (incluso con
interfaz grfica), adaptando respectivamente Debian y Ubuntu Mate a la arquitectura ARM v7. Al hablar de
implementaciones cdigo libre de reputados sistemas operativos no solo podemos contar con la tranquilidad de
encontrarnos frente a SOs slidos, sino que tambin tenemos a nuestra disposicin una enorme gama de
utilidades, libreras, paquetes, etc. Por ejemplo, la imagen de Raspbian trae por defecto las ltimas versiones de
Python y Java, buscando facilitar lo mximo posible las tareas al desarrollado. Esto ltimo, unido al soporte
oficial de la Raspberry Foundation, hacen de Raspberry la opcin ms lgica para servidor de base a la aplicacin
de recoleccin de biodatos del proyecto.
Ya solo queda una opcin por comentar: Snappy Ubuntu Core [23] es el producto de la familia Ubuntu enfocado
al IoT (Internet de las cosas). Se trata de un sistema operativo muy joven que parte de un enfoque totalmente
diferente, hasta el punto de romper con algunos puntos habituales hasta ahora en las distribuciones de Canonical.
Se trata sin duda de una opcin interesante, pero no est todava suficientemente madura, por lo que cualquier
problema podra necesitar de un tiempo de resolucin superior al de otras distribuciones Linux.
4.2.2.2 SO Windows
Windows 10 IoT Core [24] es una versin del ncleo de Windows 10 adaptada para el Internet de las Cosas,
pudiendo funcionar tanto en dispositivos con pantalla o sin ella, cargando tan solo el ncleo del sistema y
funcionando con pocos recursos. Este SO est claramente enfocado al mundo de IoT, y ni siquiera cuenta con
soporte para Java, lo que lo hace inviable para nuestro Proyecto.
4.2.2.3 Otros SO
En esta categora clasificamos a RISC OS [25], un sistema operativo con ncleo o kernel propio, distinto a los
kernels habituales como Linux y Windows. Fue desarrollado por Acorn Computers, una compaa britnica que
dej de existir en noviembre del ao 2000, y cuyo cdigo fuente es mantenido por RISC OS Ltd. con una licencia
Open Source.1 Se dise pensando en ordenadores basados en chips ARM.2. Ofrece un rendimiento menor al
de los SO Linux, adems de contar con un soporte mucho ms limitado, motivos por los que se ha descartado
su uso.
Clster de servidores de mensajes

4.3.1 Descripcin
Uno de los aspectos centrales del proyecto es la creacin de un clster que nos permita un intercambio adecuado
de la informacin biomdica de los pacientes entre todos los componentes del proyecto: almacenador de
constantes vitales en base de datos, visualizacin y otros posibles mdulos a construir sobre las bases existentes,
as como aplicaciones de terceros. Para satisfacer esta necesidad, el proyecto abarca la configuracin de un
conjunto de nodos y servidores diseados que conformarn un clster empleado como un bus de informacin,
as como la implementacin y parametrizacin de consumidores y productores para dicha estructura de red. Las
caractersticas que debe soportar el clster del proyecto no escapan de las requeridas habitualmente en esta
tecnologa: alta disponibilidad, redundancia, seguridad, escalabilidad y facilidad para la integracin con el
software diseado.
26
4.3.2.1 Apache Kafka
Figura 4-2. Logo de Apache Kafka
Apache Kafka [26] es un sistema de procesado de mensajes. Los mensajes se publican por los productores
(producers) en colas denominadas topics y se consumen de la cola por los consumidores (consumers) suscritos
a dicha cola. Es una solucin al problema de los productores-consumidores concurrentes. En este problema
existen uno o ms actores (productores) que generan los mensajes que son procesados por uno o ms actores
(consumidores) de manera concurrente.
El sistema de encolado y procesado de mensajes es distribuido y particionado en diferentes instancias
denominadas brokers que conforman el clster de Kafka. Dentro del clster, en cada broker, cada topic o cola
est dividida en particiones en las que los mensajes se almacenan de manera secuencial. Las particiones de un
topic permiten:
- Distribuir la carga de trabajo entre diferentes brokers y consumidores
- Tener tolerancia a errores de los brokers, al poder tener replicadas la misma particin en brokers
distintos (aunque solo una es la activa, pueden tomar el sitio de la activa si sta cae)
Figura 4-3. Arquitectura bsica Java
El productor es quien encola los mensajes en cada particin, que mantiene estos mensajes de manera secuencial
y ordenada. Es el propio productor quien decide en qu particin especfica del topic se almacena el mensaje.
27
De esta manera el balanceado de los mensajes en las diferentes particiones queda en manos del productor, no
del clster, que puede basarse en criterios de balanceado de carga o de lgica de negocio.
El modo en que se distribuyen los mensajes a los consumidores es tambin bastante flexible. Los consumidores
se agrupan en grupos de consumidores. El clster distribuye los mensajes de cada particin a un nico
consumidor del grupo, pero si hubiese ms de un grupo de consumidores lo hara para cada grupo. De esta
manera nos encontramos en una cola clsica con la carga balanceada entre varios consumidores si solo hay un
grupo, y en un modelo de suscripcin si tuvisemos ms de un grupo.
Figura 4-4. Consumicin de mensajes del clster
El nico modo de garantizar que los mensajes se consumen en el orden en que se crean es teniendo una nica
particin por topic y un solo consumidor por grupo. El nico modo de garantizar que los mensajes se consumen
una sola vez es teniendo un nico grupo de consumidores.
El consumidor de cada particin es el que decide el orden en que se procesan los mensajes y los mensajes que
se procesan. El consumidor tiene libertad para moverse en la particin accediendo a los mensajes de manera
indexada (offset desde comienzo) y en sentido y con el criterio que quiera, y es quin lleva constancia de si han
sido consumidos o no. Esto permite que la poltica o lgica de procesado de mensajes sea mucho ms flexible
que la cola tradicional, permitiendo el reprocesado de mensajes, el procesado en cualquier orden o el consumo
de mensajes en la misma particin por diferentes consumidores (si estn en distintos grupos).
Los mensajes se mantienen en la particin, con independencia de si han sido consumidos o no, durante el tiempo
indicado por la poltica de retencin de mensajes. No hay borrado de los mensajes. Esto se debe a una decisin
de diseo muy eficiente, puesto que el acceso al disco secundario es siempre secuencial y no aleatorio, con las
ventajas de rendimiento que supone.
Figura 4-5. Topics y particiones en Kafka
28
En Kafka podemos combinar el modo de almacenaje clsico de los mensajes en las particiones con un modo
mapa, en el que los mensajes cuentan con clave y valor. Como todos los mensajes con la misma clave se
almacenarn siempre en la misma particin de un topic podemos activar la opcin log.cleaner.enable para
mantener en la particin solo el ltimo valor de una clave. A esta operacin se le denomina log compaction
[27] y permite gestionar los topics como si fuesen mapas.
Solo queda comentar un punto de Kafka: pueden existir uno o varios nodos Zookeeper en un clster de Kafka.
Apache ZooKeeper es un servicio de datos en estructura de rbol. El servicio es centralizado, replicado, de alta
disponibilidad y escalable; y garantiza la integridad en accesos concurrentes y el orden de modificacin de los
datos de manera secuencial. El sistema est formado por un conjunto distribuido de instancias denominado
quorum que sirven la misma informacin, en el caso de Kafka, los brokers.
El servicio es centralizado porque solo una de las instancias en ejecucin hace las veces de instancia maestra, es
la nica que puede modificar los datos y que los replica al resto de las instancias. Esto garantiza el orden de los
cambios, la atomicidad transaccional y la integridad concurrente de la informacin. Cuando la instancia maestra
cae, el algoritmo de eleccin de lder, decide qu instancia es la nueva instancia maestra. El acceso de lectura,
sin embargo, puede hacerse a cualquiera de las instancias levantadas del sistema. Esto por un lado garantiza la
disponibilidad, al poder cualquier nodo convertirse en lder, y el rendimiento y la escalabilidad, al permitir poder
aadir todas las instancias que queramos al quorum para repartir la carga. Este diseo lo hace ms adecuado para
situaciones en que la lectura de datos es mucho ms habitual que la escritura (al menos 1:10 segn la
documentacin).
En resumen, Kafka es un solucin tremendamente slida, muy verstil y sencilla para consumir o transformar
informacin, ofreciendo una fiabilidad, escalabilidad y velocidad sin competencia en el mercado, motivos por
los que se ha elegido como sistema de intercambio de mensajes del proyecto.
4.3.2.2 RabbitMQ
Figura 4-6. Logo RabbitMQ
RabbitMQ [28] es un software de negociacin de mensajes de cdigo abierto, y entra dentro de la categora de
middleware de mensajera. Implementa el estndar Advanced Message Queuing Protocol (AMQP). El servidor
RabbitMQ est escrito en Erlang, un lenguaje enfocado a programacin concurrente y distribuida, y utiliza el
framework Open Telecom Platform (OTP) para construir sus capacidades de ejecucin distribuida y
conmutacin ante errores. Este MOM (Message oriented middleware), implementa un tipo de componentes
denominados exchanges, los cuales permiten enlazar colas, topics y otros exchanges entre s. Esta opcin facilita
mucho la labor de disear una jerarqua de colas ms compleja y dinmica. El proyecto RabbitMQ consta de
diferentes partes:
- El servidor de intercambio RabbitMQ en s mismo
- Pasarelas para los protocolos HTTP, XMPP y STOMP.
- Bibliotecas de clientes para Java y el framework .NET. (Bibliotecas similares para otros lenguajes se
encuentran disponibles por parte de otros proveedores).
- El plugin Shovel que se encarga de replicar mensajes desde un corredor de mensajes a otros
Se trata de un producto sin duda ms maduro que Kafka, pero tambin menos optimizado, contando con
rendimiento notablemente inferior. Adems, Kafka es una tecnologa que se encuentra actualmente en plena
fase final de desarrollo por Apache, lo que nos garantiza una empresa fuerte detrs preparada para dar soporte y
mejorar el producto, adems de poner en valor el gran nmero de usuarios que ya ha conseguido antes de lanzar
su primera versin estable.
29
Base de datos
4.4.1 Descripcin
Un elemento clsico en las aplicaciones informticas es la base de datos, lugar donde se persiste la informacin
manejada. El presente proyecto define una suite de aplicaciones, desarrollando para tal efecto una arquitectura
slida que permita la adicin de nuevos mdulos y funcionalidades. Por tanto, el diseo de una base de datos
era inherente al proyecto desde el principio, incluso si no se hubiera detectado su necesidad durante el anlisis
de las aplicaciones que abarca esta memoria.

Para el proyecto se requerir una base de datos relacional, por lo que en este captulo nos centraremos en
comparar los diferentes motores de base de datos relacionales existentes, dividindolos en dos categoras:
- Libres: MySQL, PostgreSQL, Firebird, SQLite. las dos primeras son las ms conocidas y, sin duda, son
vlidas para un proyecto, por complicado que sea.
- Propietarias: Dejando de lado las menos potentes, dBASE (un clsico, pero muy superada),
FileMaker, Interbase, Access tenemos las 2 ms conocidas, Oracle y SQL Server de Microsoft,
adems de IBM DB2, Informix, Progress
Con lo anterior, y con el objetivo de ofrecer un anlisis slido que sirva para elegir la base de datos del proyecto
se va a partir de un estudio del mercado de motores de bases de datos. La investigacin ms completa es la
realizada por DB-Engine [29], quienes miden la popularidad de los distintos motores de base de datos a partir
de las consultas en buscadores de mbito general (Google, Bing, etc.), menciones en webs especializados
(Stackoverflow. DBA Stack Exchange, etc), nmero de ofertas de trabajo en portales como Indeed y encuestas
de uso entre profesionales del sector. Segn los datos de dicho estudio, existe un trio de soluciones que llevan
una amplia ventaja sobre el resto en nmero de usuarios y popularidad. Esta es una caracterstica fundamental,
no solo ndica la posible robustez de una base de datos, sino que implicar un mayor soporte e informacin
tcnica sobre ellas por parte de la comunidad. Por tanto, en el presente anlisis solo contemplaremos esas tres
bases de datos: Oracle, MySQL y SQL Server.
Figura 4-7. Ranking de bases de datos de DB-Engines.
30
4.4.2.1 Oracle
Figura 4-8. Logo Oracle Database
La base de datos de Oracle, conocida como Oracle Database [30], es uno de los motores de bases de datos ms
robustos del mercado, destacando por su baja tasa de errores y su alta fiabilidad. Su principal punto negativo
radica en su condicin de cdigo propietario, permitiendo solo su distribucin bajo licencia comercial. Por el
contrario, cuenta con una amplia gama de puntos positivos. En primer lugar, cuenta con algunas caractersticas
no habituales en la competencia, como recuperacin de transacciones errneas, Grid Computing, Gateways,
FlashBack Table, etc. El otro gran punto a favor de Oracle es el lenguaje PL/SQL. PL/SQL es un lenguaje de
programacin propio de Oracle que permite a los desarrolladores escribir procedimientos almacenados, triggers
e incluso funciones en Java. Gracias al compilador Java y la JVM incluida en las bases de datos, es posible
compilar programas Java directamente en la base de datos o leer una clase utilizando utilidades proporcionadas
por la base de datos. A pesar de tratarse de software propietario, la comunidad entorno a Oracle Database es
especialmente extensa, lo que nos permitir encontrar ayuda de otros usuarios ante prcticamente cualquier
problema que nos pueda surgir. Todas estas caractersticas han hecho a Oracle Database dominar el mercado y
ser escogido como motor de base de datos de este proyecto.
Actualmente Oracle mantiene cinco ediciones de su base de datos, intentando presentar una gama de productos
que se adecue a las necesidades especficas de cada cliente.
- Oracle Database Standard Edition One: Ofrece facilidad de uso, potencia y rendimiento para grupos de
trabajo, a nivel de departamentos y aplicaciones Web. Desde los entornos de un solo servidor para
pequeas empresas a los entornos de sucursales altamente distribuidos.
- Oracle Database Standard Edition: Oracle Database Standard Edition ofrece las funcionalidades de la
edicin Standard Edition One, con el apoyo de mquinas ms grandes y la agrupacin de los servicios
con Oracle Real Application Clusters (Oracle RAC).
- Oracle Database Enterprise Edition: Ofrece el rendimiento, la disponibilidad, la escalabilidad y la
seguridad necesaria para las aplicaciones de misin crtica, tales como el procesamiento de grandes
volmenes de transacciones en lnea (OLTP), almacenes de datos en consultas intensivas y exigentes
aplicaciones de Internet.
- Oracle Database Express Edition: Es una edicin bsica de la base de datos de Oracle. Es rpida de
descargar, fcil de instalar y administrar, y es libre de desarrollar, implementar y distribuir. Es fcil de
actualizar a las otras ediciones de Oracle sin migraciones costosas y complejas. Oracle Database XE se
puede instalar en cualquier mquina tamao con cualquier nmero de CPUs, almacena hasta 11 GB de
datos de usuario, con un mximo de 1 GB de memoria, y con una sola CPU en la mquina host. Existe
un foro en lnea, para dar soporte. Como parece evidente, es la opcin ideal para nuestro proyecto.
Actualmente la ltima versin estable de Oracle Database es la 12, pero no cuenta con una versin
exprs, por lo que emplearemos la ltima disponible: la 11g xe.
- Oracle Database Personal Edition: Soporta los entornos de desarrollo de un solo usuario y el despliegue
que requieren la plena compatibilidad con Oracle Database Standard Edition One, Oracle Database
Standard Edition y Oracle Database Enterprise Edition. Le diferencia la excepcin de la no opcin de
Oracle Real Application Clusters. Personal Edition slo est disponible en los sistemas operativos
Windows y Linux. Tampoco incluye los mdulos de administracin.
31
4.4.2.2 MySQL
Figura 4-9. Logo MySQL
MySQL [31] es la base de datos de cdigo abierto ms popular del mundo, tal y como anuncia orgullosamente
Oracle en su web. MySQL fue inicialmente desarrollado por MySQL AB, que fue adquirida por Sun
Microsystems en 2008, y sta a su vez fue comprada por Oracle Corporation en 2010, la cual ya era duea desde
2005 de Innobase Oy, empresa finlandesa desarrolladora del motor InnoDB para MySQL. MySQL es popular
por su velocidad de procesamiento y por emplear una licencia GLP (General Public Licence). Gracias a su
extensin, tiene conectores para la prctica totalidad de lenguajes importantes (algunos como Ruby o C++ no
cuentan con conector para Oracle Database). En cuento funcionalidad, destaca sobre la mayora de rivales,
aunque quede un poco por debajo en una comparacin con Oracle Database.
4.4.2.3 SQL Server
Figura 4-10. Logo SQL Server
SQL Server [32] es el sistema de gestin de bases de datos relacionales Microsoft que est diseado para el
entorno empresarial. SQL Server se ejecuta en T-SQL (Transact-SQL), un conjunto de extensiones de
programacin de Sybase y Microsoft que aaden varias caractersticas a SQL estndar, incluyendo control de
transacciones, excepcin y manejo de errores, procesamiento fila, as como variables declaradas. SQL Server
fue lanzado en noviembre de 2005 y Microsoft presume de que su entrada en el mercado proporcion una mayor
flexibilidad, escalabilidad, confiabilidad y seguridad a las aplicaciones de base de datos, y permiti que fueran
ms fciles de crear y desplegar, lo que reduce la complejidad en la gestin de bases de datos. Para este proyecto
SQL Server es una solucin demasiado cerrada y engorrosa, frente a la facilidad de instalacin y manejo que
ofrece la Express Edition de Oracle. Adems, se encuentra en clara inferioridad frente a las otras bases de datos
analizadas en este apartado.
Entorno de desarrollo para BBDD

4.5.1 Descripcin
Siempre que se trabaje con una base de datos es necesario un entorno de desarrollo para la misma, una aplicacin
que nos permita ejecutar instrucciones en lenguaje SQL y administrar las funcionalidades de la base de datos.
La eleccin del IDE para base de datos depender enormemente del motor de base de datos escogido en el punto
anterior, pues existen muchas soluciones que solo soportan determinadas bases de datos, aunque exista una
tendencia cada vez mayor a que esto cambie. Para las bases de datos Oracle existen dos entornos de desarrollo
que destacan sobre los dems, por presencia en el mercado y funcionalidad: Oracle SQL Developer y TOAD.
32
4.5.2.1 Oracle SQL Developer
Figura 4-11. Logo SQL Developer
SQL Developer [33] es el entorno de desarrollo para bases de datos de Oracle. Desarrollado en Java, actualmente
ofrece soporte para otras bases de datos distintas a la proa del Oracle, como MySQL o SQL Server. Al ejecutarse
sobre la Java Virtual Machine el programa se encuentra disponible para todos los sistemas operativos soportados
por Java, lo que en la prctica abarca cualquier opcin que pueda hacer el usuario. Es una aplicacin gratuita de
cdigo propietario. Cuenta con una amplia gama de funcionalidades, cubriendo todas las elementales y contando
con alguna funcin avanzada. Se construye en torno a un interfaz principal que permite navegar por un rbol
jerrquico de objetos contenidos en bases de datos y realizar operaciones sencillas sobre ellos. Junto al
explorador se encuentra un rea para ejecutar sentencias SQL y PL/SQL. A travs de esta interfaz grfica no
solo es posible ejecutar sentencias, sino tambin modificar grficamente distintos objetos de la base de datos
(tablas, campos, ndices, etc.) facilitando la tarea a los desarrolladores inexpertos. Otras funciones interesantes
son el modelado E/R (que genera un diagrama de relacin entre clases) y la importacin / exportacin de datos
en mltiples formatos. Adems, cuenta con un Sistema de plugins de forma que los usuarios puedan desarrollar
sus propias funcionalidades.
Figura 4-12. Interfaz grfica SQL Developer
En resumen, SQL Developer es un entorno de desarrollo para base de datos tremendamente intuitivo y fcil de
usar, que no requiere de grandes conocimientos para su utilizacin. Adems, cubre de sobra las funcionalidades
bsicas, proveyendo a los usuarios expertos de otras capacidades ms avanzadas. En nuestro caso, su condicin
de gratuito y su facilidad de uso han sido los puntos clave que han provocado su eleccin en el presente proyecto.
33
4.5.2.2 TOAD
Figura 4-13. Logo de TOAD
TOAD [34] es una herramienta grfica para desarrollo de base de datos creada por Quest Software, actualmente
dentro de la corporacin Dell, Inc. Originalmente se trataba de una aplicacin diseada exclusivamente para
bases de datos de Oracle (de hecho, TOAD son las siglas de Tool for Oracle Application Developers) aunque
actualmente soporta la prctica totalidad de bases de datos incluyendo las dominadoras del mercado (Oracle,
MySQL, PostgreSQL, Microsoft SQL Server, etc.). Se trata de una aplicacin propietaria que se distribuye bajo
dos versiones: una Freeware limitada y una versin de pago completa. Cuenta con una enorme cantidad de
funcionalidades, centradas especialmente en los DBA (Data Base Administrator). Por ejemplo, realizar copias
de una base de datos (exports e import) es tremendamente sencillo desde la interfaz grfica de TOAD, contando
con un simple asistente que te ayuda a travs de todo el proceso. Es, sin duda, la opcin ms completa del
mercado para los desarrolladores de una base de datos de Oracle. Sin embargo, la versin gratuita se queda un
poco corta, ofreciendo prcticamente las mismas funciones que el SQL Developer, lo que no compensa una
interfaz menos intuitiva.
Lenguaje de programacin
4.6.1 Descripcin
Llega el momento de comentar el lenguaje de programacin empleado para todo el proyecto, comparndolo con
otras opciones posibles. En este caso la eleccin est fundamentada en los conocimientos del desarrollador, pues
no es tan fcil cambiar de lenguaje de programacin como optar entre dos entornos de desarrollo. Aun as, se
comentarn las ventajas e inconvenientes de la opcin elegida frente a otros posibles lenguajes que presentan
caractersticas interesantes para el proyecto realizado.
4.6.2.1 Java
Figura 4-14. Logo de Java
Java [35] es un lenguaje de programacin de propsito general, concurrente, orientado a objetos que fue
diseado especficamente para tener tan pocas dependencias de implementacin como fuera posible. Su
intencin es permitir que los desarrolladores de aplicaciones escriban el programa una vez y lo ejecuten en
cualquier dispositivo, por lo que las aplicaciones de Java son generalmente compiladas a bytecode (clase Java)
que puede ejecutarse en cualquier mquina virtual Java (JVM) sin importar la arquitectura de la computadora
subyacente. Fue originalmente desarrollado por James Gosling de Sun Microsystems (la cual fue adquirida por
la compaa Oracle) y publicado en 1995 como un componente fundamental de la plataforma Java de Sun
Microsystems.
34
Se definen tres plataformas Java, en un intento por cubrir distintos entornos de aplicacin. As, las APIs
pertenecen a una plataforma u otra en funcin de su funcionalidad.
- Java ME (Java Platform, Micro Edition): orientada a entornos de recursos limitados, como telfonos
mviles.
- Java SE (Java Platform, Standard Edition): para entornos de gama media y estaciones de trabajo. Aqu
se sita al usuario medio en un PC de escritorio.
- Java EE (Java Platform, Enterprise Edition): orientada a entornos distribuidos empresariales o de
Internet.
Figura 4-15. Plataformas Java
La plataforma Java EE define un estndar para el desarrollo de aplicaciones empresariales multicapa basadas en
componentes. La lgica de la aplicacin se divide en componentes de acuerdo a su funcin, y cada componente
puede ser instalado en una mquina diferente dependiendo de la capa a la que pertenezca. Cada uno de los
componentes de Java EE se ejecuta en un contenedor apropiado. Un contenedor es el entorno de ejecucin para
un componente, que le proporciona acceso a una serie de servicios. Adems de los componentes ya comentados
destaca el Enterprise Bean, encargado de la lgica de negocio. Sirven para automatizar la persistencia, dar
soporte a la implementacin de fachadas del modelo (objetos de sesin, aplicacin, etc.), declarar operaciones
transaccionales y aspectos de seguridad, etc.
La tendencia actual del mercado es relegar a Java al desarrollo back-end (capa de negocio y tratamiento de datos,
empleando otras opciones ms potentes para la capa de presentacin (como las diferentes implementaciones de
Javascript). En el caso que nos ocupa, realizaremos fundamentalmente desarrollo back-end, por lo que Java
parece una opcin tremendamente slida, teniendo en cuenta la robustez del lenguaje y su amplsimo uso.
Cualquier funcionalidad requerida externa requerida durante el desarrollo estar ya implementada por un tercero,
siendo tremendamente sencillo anexarla a nuestro proyecto. Adems, es, sin duda, el lenguaje de programacin
que mejor abarca mltiples escenarios, lo cual no es una caracterstica balad para una suite de productos que
pretende abarcar muchas aplicaciones diferentes.
4.6.2.2 Python
Figura 4-16. Logo de Python
Python [36] es un lenguaje de script desarrollado por Guido van Rossum en el que es posible codificar
empleando programacin lineal, estructurada y orientada a objetos (siendo esta ltima la que mbito de la
programacin en la actualidad). Existen intrpretes de Python en mltiples plataformas: Windows, Linux, Mac
etc. Empresas como Google, Yahoo, Nasa etc. utilizan este lenguaje para sus desarrollos (actualmente el creador
35
de Python Guido Van Rossum trabaja para Google.)

Se puede ejecutar instrucciones de Python desde la lnea de comando o creando archivos con extensin *.py. Al
ser un lenguaje interpretado, la lnea de comandos nos permite conocer el resultado de las lneas codificadas
inmediatamente, favoreciendo mucho la programacin. Python se emplea en mltiples mbitos: aplicaciones
que se ejecutan en un servidor web (equivalentes a lo que se puede hacer con PHP, ASP.Net, JSP, Ruby),
aplicaciones de escritorio con interfaces visuales accediendo a componentes escritos en .Net (Microsoft), Qt,
GTK, MFC, Swing (Java) etc., programas no visuales para cubrir funcionalidades back-end
Es, por tanto, un lenguaje interesante que est creciendo considerablemente en la actualidad. Ya existen soportes
para la prctica totalidad de bases de datos (como por ejemplo Oracle Database) y domina el segmento de
programacin enfocado a domtica, sobretodo sobre SBCs como Raspberry o placas Arduino. Para la
comunicacin con los biodispositivos, ncleo del presente proyecto, Python sera una eleccin ms que
adecuada, pero nos obligara a limitar las funcionalidades en otras aplicaciones posibles o incluso en el diseo
de la suite. Python es una opcin de futuro, que poco a poco comienza a consolidarse y a abordar mltiples
escenarios, pero se considera ms adecuado disear una suite que se espera sirva de base para mltiples
desarrollos en un lenguaje con el mayor nmero de libreras y utilidades externas posibles.
Capa de persistencia
4.7.1 Descripcin
El acceso desde las aplicaciones Java a la base de datos se va a estudiar en dos niveles. En el primero se
comentar la filosofa de trabajo con la base de datos, la API escogida, mientras que en el segundo se abarcar
que implementacin concreta de esa filosofa se ha utilizado en el proyecto.
4.7.2.1 Bajo nivel de abstraccin
Figura 4-17. Logo de JDBC
Java provee una API bsica para establecer las comunicaciones con la base de datos denominada Java Database
Connectivity (JDBC). A travs de algunas sus clases, organizadas en el paquete java.sql, podemos establecer la
comunicacin con la base de datos y ejecutar sentencias SQL, almacenando los resultados de una consulta. Por
tanto, directamente sobre el JDBC podemos realizar las comunicaciones que queramos con la base de datos, sin
necesidad de establecer mayores niveles de abstraccin. Esta poltica tiene claras ventajas: es muy sencilla, solo
requiere conocimiento SQL para trabajar con la base de datos y es la menos pesada y, generalmente, la que
ofrece mayor rendimiento. Por otra parte, implica tener que definir manualmente la consulta / sentencia SQL
que se quiera realizar cada vez, de forma que un desarrollador debe conocer SQL, no independizando los
lenguajes. Adems, un cambio en base de datos implica buscar manualmente las posibles sentencias afectadas.
Est claro que estamos ante una poltica muy simple, lo cual implica algunas ventajas, pero se puede volver
demasiado engorrosa (poco escalable, actualizable, propensa a errores) en un Proyecto como este, en el que
varias aplicaciones diferentes van a querer trabajar con la base de datos. Parece interesante analizar otras
opciones que busquen un mayor nivel de abstraccin, independizndonos definitivamente del lenguaje de base
de datos.
4.7.2.2 ORM: Object-Relational mapping
El mapeo objeto-relacional (Object-Relational mapping, O/RM, ORM, o O/R mapping) es una tcnica de
programacin para mapear datos entre el sistema de tipos utilizado en un lenguaje de programacin orientado a
36
objetos y el utilizado en una base de datos relacional, utilizando un motor de persistencia. En la prctica, esto
implica crear una base de datos orientada a objetos virtual, que el motor ORM es capaz de transformar en la
base de datos relacional. Esto no solo posibilita el uso de las caractersticas propias de la orientacin a objetos
(fundamentalmente herencia y polimorfismo), sino que abstrae al desarrollador del conocimiento de SQL al ser
el motor ORM el encargado de transformar las acciones realizadas sobre los objetos o clases de mapeo en
sentencias sobre las tablas / campos reales en la base de datos. El desarrollador solo tiene que crear el mapeo
entre el objeto Java y el elemento de la base de datos, pudiendo operar con los objetos en su desarrollo y
olvidndose prcticamente del resto del trabajo. Este sistema es, evidentemente, ms complejo que el anterior
pero tambin mucho ms robusto. Por ejemplo, si tenemos una clase Java que mapea los campos de una tabla
modificar el nombre de un campo solo implica modificar el nombre de una variable, pudindonos servir del
compilador para detectar los errores que esto pueda derivar. Adems, ORM abre la puerta a funcionalidades ms
avanzadas, como ya se ha comentado anteriormente.
El uso de ORM se ha vuelto cada vez ms popular en los ltimos aos, sobre todo para proyectos de tamao
medio-grande, facilitando el tratamiento con la base de datos. Todos estos son motivos ms que suficientes para
optar por JPA (Java Persistence API), el estndar ORM de Java.
JPA es la API diseada por Java para cubrir la metodologa ORM. Es, no obstante, una mera interfaz que define
un flujo de trabajo y una metodologa determinada, sirviendo de estndar para los diferentes motores ORM del
mercado. Es decir, JPA nos permite una capa ms de abstraccin: un mapeo objeto-relacional realizado en JPA
podr valer para varios motores ORM diferentes, pudiendo cambiarlos si el desarrollador as lo desea.
4.7.2.2.1 Motor ORM
Figura 4-18. Logos de las principales implementaciones JPA: Hibernate, EclipseLink y OpenJPA
Hibernate [37] es, con mucha distancia, el principal motor ORM empleado en desarrollo Java. De hecho, aunque
Hibernate pueda entenderse como una implementacin de JPA (cosa afirmativa) se trata de un framework
mucho ms amplio y antiguo. JPA est basado en Hibernate, y es un intento de estandarizar la capa de
persistencia frente al boom de los frameworks ORM que provoc la entrada de Hibernate en el mercado. Por
tanto, Hibernate puede usarse tanto bajo JPA como capa de persistencia propia. En esta modalidad Hibernate
soporta la capacidad para trabajar con bases de datos NoSQL, algo que JPA no cubre, cachs multinivel, etc.
Ms all de Hibernate existen otras mltiples implementaciones de JPA, como EclipseLink [38]
(implementacin seleccionada por Oracle como referencia desde JPA 2.0) y OpenJPA [39], de Apache. Aunque
son motores ORM slidos se encuentran a demasiada distancia de Hibernate en cuanto a rendimiento,
funcionalidad y posicin en el mercado.
En nuestro proyecto se ha intentado optar por la estandarizacin, ya que JPA cubre de sobra nuestras
necesidades, colocando a Hibernate como motor JPA dada su robustez y solvencia.
4.7.2.2.2 Lenguaje de consultas
Figura 4-19. Logo de QueryDSL
Parece fcil comprender que JPA nos proveer de un conjunto de utilidades para realizar inserciones,
actualizaciones y eliminaciones de objetos (correspondientes a un registro en una tabla de base de datos), pero
no es tan sencillo imaginar cmo se ejecutan consultas SQL complejas a travs de JPA. Para ello, se ha definido
37
el Java Persistence Query Language (JPQL), un lenguaje de consulta orientado a objetos independiente de la
plataforma, usado para hacer consultas contra las entidades JPA. Es decir, JPQL est inspirado en gran medida
por SQL, y sus consultas se asemejan a las consultas SQL en la sintaxis, pero opera con objetos entidad de JPA
en lugar de hacerlo directamente con las tablas de la base de datos. JPQL define un conjunto de mtodos para
facilitar la construccin de consultas, pero necesita recibir el grueso de la lgica en una cadena de texto, en vez
de utilizar los atributos del objeto empleado, algo muy poco mantenible. Es por esto que han surgido utilidades
para desarrollar consultas empleando directamente atributos Java, facilitando la programacin y la gestin del
cdigo, entre otras funcionalidades. JPA 2.0 introduzco Criteria, una API para consultas type-safe, es decir, a
prueba de errores de tipos gracias a trabajar completamente con instancias y mtodos Java, evitando las cadenas
de texto de JPQL. A Criteria le han surgido algunas alternativas, entre las que destaca especialmente QueryDSL
[40], un framework de cdigo libre que cuenta con soporte para una inmensa cantidad de frameworks de
persistencia, desde JPA hasta bases de datos no relacionales como MongoDB. QueryDSL es mucho ms
intuitivo y fcil de manejar que Criteria y es tan potente que puede emplearse hasta para realizar consultas sobre
colecciones Java, algo que Oracle se ha trasladado al propio lenguaje en Java 8. Para poder ofrecer esta
funcionalidad necesita generar unas clases denominadas QClass, quienes contarn con los mtodos y atributos
necesarios para facilitar la construccin de consultas. Estas clases se autogeneran a partir de las entidades JPA
definidas, gracias a un plugin integrable con Maven y otros gestores de dependencias y construccin del
proyecto.
4.7.2.3 Soluciones mixtas
Figura 4-20. Logo de iBatis
Existen algunos frameworks de persistencia que ofrecen soluciones a medio camino entre la ejecucin directa
de sentencias SQL y los ORM. El caso ms conocido es sin duda iBatis, frecuentemente categorizado dentro de
los ORM. iBatis [41] es una opcin intermedia entre las dos polticas definidas previamente. Esta tecnologa se
sustenta en definir no solo el mapeo entre los elementos de base de datos y las clases Java, sino tambin las
sentencias SQL que se utilizarn. Desde el desarrollo Java se indicar que operacin (consulta, actualizacin,
insercin, etc.) se desea realizar. El hecho de que las operaciones se definan en SQL prcticamente puro y que
haya que describir todas y cada una de ellas ofrece una solucin menos automtica a los desarrolladores, aunque
abre la puerta a optimizar las sentencias SQL, un aspecto siempre criticado de los motores ORM.
Gestor de dependencias y construccin del proyecto

4.8.1 Descripcin
En proyectos Java complejos la gestin de dependencias es una labor fundamental. Al igual que en la mayora
de lenguajes, una correcta gestin de nuestro proyecto implicar conocer qu libreras necesitamos y con qu
versin exacta. Adems, estas libreras contarn a su vez con otras dependencias, pudiendo darse el caso de
acabar incorporando a nuestro proyecto libreras duplicadas que reducen el rendimiento y favorecen la aparicin
de errores. Para optimizar esta labor surgieron los gestores de dependencias, que nos permiten definir en un
fichero de configuracin determinado las dependencias de nuestra aplicacin, bastando incluso con indicar una
referencia completa a la librera para que el gestor se encargue de buscarla, descargarla e importarla a nuestro
proyecto automticamente. Pronto esta funcionalidad se fusion con la evolucin de los programas encargados
de gestionar la vida del proyecto (siendo el ms conocido make de C), quienes iban abarcando cada vez ms
capacidades. De esta manera, es posible parametrizar la compilacin, el empaquetamiento, el tratamiento de
ficheros externos, la ejecucin de pruebas, etc. Toda esta amplia gama de funcionalidades provoc que los
gestores de dependencias y construccin crecieran en popularidad, hasta el punto de que hoy en da sea extrao
encontrar un proyecto de medio tamao que no cuente con los servicios de ninguna de las distintas soluciones
existentes en el mercado.
38
4.8.2.1 Ant
Figura 4-21. Logo de Ant
Ant [42] fue la primera herramienta moderna para la construccin de proyectos Java. Lanzado en el ao 2000,
pretenda ser el equivalente Java de Make, convirtindose en una de las utilidades ms populares del lenguaje
en un corto periodo de tiempo. Su facilidad de uso, y la capacidad de extender sus funcionalidades mediante
plugins, fueron sus principales puntos fuertes. Por otra parte, la configuracin realizada sobre XML se volva
demasiado engorrosa, dificultando en algunas ocasiones la legibilidad del cdigo. Aunque sigue bajo desarrollo
en la actualidad, ha sido suplantado en la mayora de los proyectos por Maven, otra solucin de Apache que
apareci pocos aos despus, partiendo de los conocimientos y las experiencias adquiridas durante el desarrollo
de Ant.
4.8.2.2 Maven
Figura 4-22. Logo de Maven
Maven [43] apareci en 2004, como herramienta sucesora de Ant (ambas desarrolladas por Apache). Continuaba
utilizando XML como formato de configuracin, pero replanteando completamente su estructura y lgica
interna. Mientras que Ant exiga a los desarrolladores codificar todos los pasos que quisieran ejecutar durante la
construccin de su proyecto, Maven defini un ciclo de vida (validate, compile, test, package, verify, install y
deploy). Cada fase se compone a su vez de goals u objetivos, de forma que el ciclo de vida siempre se ejecuta,
siendo tarea del programador vincular acciones con determinados goals. Quizs la principal caracterstica de
Maven, aquella que ha convertido a esta utilidad de Apache en un must have de todo proyecto Java, es su gestin
de dependencias. Basta con identificar adecuadamente una librera en el fichero de configuracin para que
Maven la descargue y la importe al proyecto. Adems, cuenta con una amplia gama de plugins que permiten
abarcar prcticamente cualquier accin imaginable durante la construccin del proyecto. Maven permite filtrado
de ficheros, gestin de ficheros externos (resources), estructuracin de proyectos en varios niveles, ejecucin de
tests, etc. Sin embargo, no todo son ventajas: el enfoque centrado en el ciclo de vida reduce la flexibilidad en el
desarrollo. Adems, usar XML como formato de codificacin de Maven es poco verstil frente a otras opciones
que han ido surgiendo en el mercado.
Maven es, hoy en da, el gestor de construccin de Java ms potente y til. Cuenta con una enorme solvencia
fruto de su amplio uso por los desarrolladores. Poco a poco, otras opciones como Gradle han reducido su
hegemona, pero sigue siendo la opcin ms adecuada para este proyecto al combinar una pequea curva de
aprendizaje, una potente integracin con el IDE escogido y una gran documentacin disponible.
4.8.2.3 Gradle
Figura 4-23. Logo de Gradle
39
Gradle [44] pretende combinar lo mejor de las dos herramientas vistas hasta ahora. Ofrece mayor flexibilidad al
programador, aunque mantiene la estructura de ciclo de vida introducida por Maven. Desde su lanzamiento en
2012 ha sufrido un crecimiento espectacular, llegando a ser escogida por Google como la build tool por defecto
en Android. Inicialmente, Gradle empleaba el sistema de dependencias Ivy, de Apache, aunque hace poco ha
migrado hacia su propio gestor de dependencias. La principal novedad de Gradle es el empleo de un lenguaje
especfico del dominio (DSL) propio, diseado especficamente para la construccin de software. Como
consecuencia de esto, los scripts de configuracin de proyecto de Gradle son generalmente ms cortos y claros
que los de sus competidores, facilitando no solo la programacin sino tambin el mantenimiento del proyecto.
Entorno de desarrollo software

4.9.1 Descripcin
Para el desarrollo de la aplicacin ser imprescindible contar con un entorno de desarrollo integrado (IDE). Se
trata de una herramienta software diseada para facilitar la programacin de aplicaciones, permitiendo la edicin,
ejecucin y depuracin del cdigo fuente (Java en este caso). Tpicamente, un entorno de desarrollo contiene un
editor de cdigo fuente, un compilador/intrprete/montador y un depurador complementados por una serie de
funciones adicionales. Es decir, adems de dar soporte a la fase programacin tambin lo hace a la fase de
pruebas. Por ejemplo, el editor no es un simple editor de texto, sino que reconoce y maneja elementos sintcticos
del lenguaje usado, avisa de errores en la programacin, provee de funciones de autocompletado inteligente de
cdigo, etc. El depurador, por su parte, suele permitir al desarrollador comprobar el efecto de cada lnea de
cdigo en la ejecucin del programa, en vez de presentar la informacin en trminos de lenguaje mquina. En
resumen, la principal utilidad de un entorno de desarrollo es la integracin de todas las herramientas tiles
durante el desarrollo de software en una nica interfaz, promoviendo un marco de trabajo amigable al
programador.
Podemos encontrarnos con entornos de desarrollo integrados con distintas filosofas: existen IDEs especficos
para un lenguaje determinado, frente a los entornos multilenguaje. A pesar de lo que pueda parecer, la diferencia
va ms all de la cantidad de lenguajes soportados. Los entornos de desarrollo integrados centrados en un nico
lenguaje estn fuertemente integrados, de forma que se presentan como una nica herramienta compacta al
programador. Esto puede provocar una falta de flexibilidad, pero les dota de mayor accesibilidad. Por su parte,
los entornos de desarrollo multilenguaje estn construidos como un conjunto de mdulos que interoperan entre
s. Se les conoce como toolkit, pues se presentan como un conjunto de herramientas para la programacin. Como
es evidente, este enfoque provoca una integracin ms dbil, mayor complejidad para el usuario, pero tambin
mayor versatilidad. La principal utilidad de estos IDEs es la capacidad de ver extendida su funcionalidad a travs
de mdulos o plugins. Gracias a ella, los programadores pueden llegar combinar las ms variadas tecnologas
para el desarrollo de su proyecto a travs de un mismo programa, aadiendo los plugins necesarios al IDE por
defecto e incurriendo en una alta personalizacin del entorno de trabajo.
Adems de todo lo anterior, es interesante comentar que los entornos de desarrollo suelen contar con una serie
de funcionalidades habituales como son herramientas de programacin visual, gestin de repositorios para el
trabajo en equipo o editores de estructura.

En los prximos subapartados se analizarn las opciones ms empleadas entre los programadores del mbito
correspondiente al de este proyecto: aplicaciones web en Java. La fuente ms fiable para obtener un estudio
acerca de los IDEs ms usados en el sector. Como nota curiosa, dicha empresa es la responsable de JRebel, un
plugin para IDEs que elimina las fases de build y redespliegue en proyectos Java.
40
Figura 4-24. Comparativa entre los IDEs Java ms usados
Como se puede comprobar en el estudio [45], el mercado se encuentra dominado por tres principales alternativas
estudiadas en el presente captulo: Eclipse, Intellij IDEA y NetBeans. Adems de ellas se echar un vistazo al
JDeveloper de Oracle, por los motivos que se argumentarn ms adelante.
4.9.2.1 Eclipse
Eclipse [46] es un IDE multiplataforma de cdigo abierto, iniciado originalmente por IBM y desarrollado por la
Fundacin Eclipse desde 2001. Puede clasificarse entre los entornos de desarrollo de tipo toolkit, ya que est
compuesto por una estructura base sobre la que pueden instalarse distintos plugins que permiten agregar soporte
para mltiples lenguajes de programacin (java, c, php, etc.), tecnologas (maven, gradle, spring, etc.) o
personalizacin del entorno.
Figura 4-25. Arquitectura de eclipse.
Su arquitectura se compone de los siguientes elementos:
41
Plataforma
Es el ncleo del Eclipse IDE. Se encarga de descubrir al inicio qu complementos estn instalados, creando un
registro de informacin sobre ellos. Para reducir el tiempo de inicio y el uso de los recursos, no carga ningn
complemento hasta que realmente se lo necesita. Se trata del nico componente que no se implementa como un
complemento.
Espacio de trabajo
El espacio de trabajo es el complemento responsable de la administracin de los recursos del usuario. Incluye
todos los proyectos que crea el usuario, los archivos de esos proyectos y los cambios en los archivos y otros
recursos. Tambin es responsable de notificar a otros complementos interesados sobre los cambios en los
recursos, como archivos creados, eliminados o modificados.
Entorno de trabajo o workbench
El entorno de trabajo proporciona a Eclipse una interfaz de usuario. Se crea con la utilizacin de un Kit de
Herramientas Estndar (SWT) [47] una alternativa al Swing/AWT GUI API de Java y la API JFace [48],
quien se emplea sobre el citado SWT para proporcionar componentes de la interfaz grfica.
Equipo
El componente de equipo es responsable de proporcionar soporte para el control de versiones y la gestin de los
repositorios
Ayuda
Componente de ayuda.
Plugins
Como se ha comentado anteriormente, todo en Eclipse son componentes o plugins. Adems de los componentes
bsicos comentados en los apartados anteriores, existen otros plugins imprescindibles para conformar un entorno
de desarrollo adecuado para el programador. Probablemente el plugin ms importante de Eclipse sea JDT [49],
encargado de dar soporte a la programacin en Java. Es responsable de gestionar las vistas de esquemas de
clases, adems de varias funciones de soporte a la programacin como el coloreado de cdigo (realizando para
ello el reconocimiento sintctico de todas aquellas palabras que son reservadas en el lenguaje) o el
autocompletado de cdigo (con sugerencias dependientes del contexto, lo cual permite escribir cdigo ms
rpidamente). A todo esto, hay que sumar que permite configurar el formateo de cdigo, la forma de escribir los
comentarios, generacin de esqueletos de clase automticamente, generacin de mtodos getters y setters de
manera automtica, y un largo etctera de funcionalidades tiles para el desarrollo. Este componente tambin
controla la depuracin de todo cdigo Java a travs del JDT Debug.
Por ltimo, existen una inmensa variedad de plugins que no son imprescindibles para todos los desarrollados,
pero que el programador podr incluir para soportar las tecnologas que necesite para su proyecto concreto,
extendiendo as la funcionalidad del IDE.
Para terminar, conviene hacer un breve repaso de la interfaz grfica del IDE, comentando los elementos ms
bsicos que se han usado durante el desarrollo de la aplicacin.
42
Figura 4-26. Interfaz de Eclipse IDE.
En Eclipse el concepto de trabajo est basado en las perspectivas, que no es otra cosa que una preconfiguracin
de ventanas y editores, relacionadas entre s, y que nos permiten trabajar en un determinado entorno de trabajo
de forma ptima. Por ejemplo, en la imagen superior podemos contemplar la perspectiva Java EE (desarrollo de
aplicaciones web Java) vaca. Abajo, con ms detalle, las perspectivas abiertas
Figura 4-27. Perspectivas.
Por otra parte, el desarrollo sobre Eclipse se basa en los proyectos, que son el conjunto de recursos relacionados
entre s, como puede ser el cdigo fuente, documentacin, ficheros configuracin, rbol de directorios
Figura 4-28. Vista de gestin de proyectos.
El IDE proporcionar asistentes y ayudas para la creacin de proyectos. Por ejemplo, cuando creamos uno, se
abre la perspectiva adecuada al tipo de proyecto que estemos creando, con la coleccin de vistas, editores y
ventanas preconfigurada por defecto.
En el anexo de este documento se detalla la configuracin y pasos bsicos para llevar a cabo el desarrollo de la
aplicacin.
43
En resumen, Eclipse es un entorno de desarrollo integrado altamente verstil, capaz de dar soporte a
prcticamente cualquier tecnologa o lenguaje gracias a su amplia moduralizacin. Irnicamente, su mayor
ventaja tambin es un principal inconveniente: la extensin a travs de plugins permite que un mismo
programador que vaya a realizar varios proyectos convierta a Eclipse en su nico entorno de desarrollo,
simplemente aadiendo o quitando los componentes necesarios para su siguiente desarrollo. Adems, Eclipse
cuenta con la comunidad de usuarios ms extensa, por lo que existen miles de plugins realizados por terceros
que llegan all donde el Proyecto Eclipse no alcance. Sin embargo, su filosofa tan descentralizada convierte a
Eclipse en un IDE ms propenso a bugs, fallos, cuelgues, etc. de lo que debera. Aun as, su comportamiento
sigue siendo, en condiciones normales y con los componentes habituales, lo suficientemente robusto como para
no eclipsar la enorme ventaja existente en su alta capacidad de ampliar funcionalidades. Todo esto lo ha llevado
a ser, claramente, la opcin principal del mercado (sobre todo en Java) y la escogida para el desarrollo de la
aplicacin expuesta en este documento.
4.9.2.2 IntelliJ IDEA
IntelliJ IDEA [50] es un entorno de desarrollo para programacin sobre lenguaje Java creado por la compaa
JetBrains (inicialmente denominada IntelliJ). Se trata de un producto multiplataforma, disponible en Windows,
Mac, Linux y otras plataformas como Solarios, OpenBSD o FreeBSD. Estn disponible dos versiones del
mismo:
- Community Edition: es la versin software libre, licenciada bajo licencia Apache.
- Ultimate Edition: versin propietaria y de pago.
Al igual que el resto de IDEs comentados en el presente apartado, est desarrollado en Java, aunque presenta
ciertas caractersticas que lo convierten en un producto diferenciado del resto. Se trata de un IDE diseado para
soportar solamente lenguaje Java o relacionados (JavaScript, Groovy, etc.), por lo que puede clasificarse como
un entorno de desarrollo centrado en un lenguaje. A pesar de esto, IntelliJ IDEA tambin puede extender sus
capacidades mediante algunos plugins. En ambas versiones est habilitada esta funcionalidad, aunque solo la
versin de pago contiene alguno de los plugins oficiales ms interesantes como Php o node.js. Es importante
destacar que, a pesar de contar con la posibilidad de aadir extensiones, la filosofa de este IDE es
diametralmente distinta a la de Eclipse o NetBeans. Aqu no existe una estructura modular donde la prctica
totalidad de las funciones la ejecutan componentes separables del ncleo, sino que se cuenta con una base slida,
la cual implementa las funciones bsicas para la programacin, ejecucin, depuracin, etc., de tal forma que los
plugins solo dan soporte a ciertas tecnologas asociadas a Java o JavaScript. Existe la posibilidad de que las
nuevas versiones del producto incluyan nuevas funciones o caractersticas en el ncleo, como ocurri con la
implementacin de soporte para Python o Ruby en la edicin Ultimate, los cuales no fueron extendidos como
un plugin independiente. Sin embargo, IntelliJ IDEA permite instalar mdulos de terceros, permitiendo a la
comunidad suplir algunas carencias.
IntelliJ IDEA es un entorno de desarrollo muy interesante, tal y como han acreditado varios estudios [51], donde
suele destacar en el soporte a la programacin Java, ofreciendo mejoras en funciones como el autocompletado
o la refactorizacin de cdigo sobre sus competidores. Adems, es el IDE ms cohesionado de los estudiados,
pero carece del ecosistema de extensiones que tienen NetBeans y, fundamentalmente, Eclipse. Sin duda es un
serio candidato para todo desarrollo con Java, lo que le ha permitido alcanzar mayores cuotas de mercado con
el paso del tiempo hasta el punto de ser escogido por Google como base para el IDE oficial de Android, Android
Studio. Adems, es una opcin ganadora para comenzar a desarrollador, ya que es ms accesible que sus
competidores. A la hora de escoger entre este IDE y Eclipse conviene tener en cuenta que se trata de dos
aplicaciones con filosofas diferentes, por lo que no hay una opcin mejor que la otra. En esta ocasin ha pesado
ms la posibilidad de conocer una plataforma tan verstil como Eclipse, altamente implantada en el mercado
laboral y en la comunidad, que optar por un entorno de desarrollo ms slido. Probablemente, de trabajar en un
proyecto ms complejo hubiera sido ms interesante contar con la solidez de IntelliJ IDEA.
44
4.9.2.3 NetBeans
NetBeans IDE [52] es un IDE multiplataforma de cdigo libre fundado por Sun Microsystems a finales del ao
2000. Actualmente Oracle Corporation (comprador de Sun) sigue siendo la principal impulsora del proyecto.
Al igual que Eclipse puede catalogarse como un entorno de desarrollo de tipo toolkit, ya que est diseado para
dotar a la comunidad de libertad para extender su capacidad gracias a los Mdulos o Add-ons Packs. Como
puede suponerse, ya que comparten filosofas, su arquitectura recuerda a la de Eclipse: la prctica totalidad de
las funcionalidades la realizan mdulos, de tal forma que el usuario podra quitar y aadir estos plugins a su
antojo para personalizar su herramienta de trabajo. Esto se lleva hasta el extremo, por lo que hasta la
funcionalidad Java es realizada por un mdulo. Soporta otros lenguajes tan dispares como C/C++ o PHP, aunque
se utiliza principalmente para Java.
Es interesante destacar que est desarrollado sobre la plataforma NetBeans, un framework diseado para facilitar
la creacin de aplicaciones de escritorio para la API Swing (Java) de Oracle. No es extrao encontrar confusiones
entre la plataforma y el IDE.
Tiene una interesante presencia en el sector empresarial, adems de contar con una potente comunidad de
usuarios. Cuenta con el inconveniente de que su ecosistema de extensiones no es comparable al de Eclipse, lo
que le deja por detrs de dicha alternativa en una categora demasiado similar. Sin embargo, no son pocos los
usuarios que sealan a NetBeans como su IDE favorito, destacando que es ms slido que su competidor. Al
igual que ocurra con IntelliJ IDEA, al no estar desarrollando un proyecto de demasiada envergadura no es
necesario sacrificar las ventajas de Eclipse.
4.9.2.4 JDeveloper
JDeveloper [53] es otro IDE multiplataforma desarrollado por Oracle Corporation desde 1998. Es el nico de
los analizados que no dispone de ninguna versin bajo licenciada de cdigo libre, aunque s es gratuito.
Es un entorno de desarrollo centrado en Java y lenguajes adyacentes (JavaScript, PHP, etc.), por lo que puede
clasificarse entre los entornos centrados en un lenguaje, como era el caso de IntelliJ IDEA. Eso no le impide, al
igual que al programa de JetBrains, contar con la posibilidad de extender sus funciones con plugins o mdulos.
En este caso nos encontramos con la menor gama de extensiones de todos los IDEs reseados. Se debe a que
Oracle JDeveloper est diseado para optimizar su interconexin con otras aplicaciones, frameworks o libreras
de Oracle, lo cual le dota de tremenda utilidad para determinados desarrollos, pero provoca que la comunidad
no busque extender sus caractersticas ms all de las imprescindibles. En el caso concreto del proyecto
presentado en el presente documento, el uso de una base de datos Oracle no es condicin suficiente para justificar
la eleccin de este IDE, pues no aporta ninguna ventaja sobre sus competidores. A pesar de eso se ha considerado
necesario tener una breve introduccin a este producto, ms an si se tiene en cuenta que es el entorno en el que
est programado el SQL Developer de Oracle, el IDE de Base de Datos empleado en la aplicacin.
45
Resumen del anlisis de tecnologas empleadas en el proyecto

En las lneas superiores se ha dedicado el espacio suficiente para analizar todas y cada una de las tecnologas
empleadas en el proyecto, realizando una adecuada comparativa con el resto de opciones existentes en el
mercado y justificando las elecciones realizadas. En general, se han empleado una serie de elementos recurrentes
en las argumentaciones: se ha intentado apostar, en la medida de lo posible, por tecnologas de cdigo abierto,
con una amplia comunidad detrs y con las mayores garantas posibles en fidelidad. Junto a estos puntos se ha
valorado el futuro de todos los elementos implicados, pues se est diseando un proyecto en un mbito
claramente innovador, en el que emplear una tecnologa con pronta fecha de caducidad reducira el impacto que
nuestro trabajo pudiera tener en el mercado o en la comunidad.
La extensin de este captulo y la enorme cantidad de tecnologas comparadas dan cuenta de la complejidad del
proyecto diseado, en el que se han abordado numerosos frentes: desde la creacin de varios mdulos o
componentes software independientes hasta el diseo de una base de datos, desde la parametrizacin de un
clster de servidores de colas de mensajes distribuidas hasta la eleccin de componentes hardware para la
integracin fsica con biodispositivos.
Adems, tal y como se comentaba al inicio, la labor realizada a lo largo de este captulo se considera
imprescindible, pues constituye un elemento bsico sobre el que construir la descripcin detallada del proyecto.
O, en otras palabras, comentar y justificar las tecnologas empleadas en el desarrollo de la aplicacin IoMT es
un requisito irrenunciable que se debe satisfacer antes de abordar los pormenores de la solucin realizada.
46
5 DESCRIPCIN DE LA PROPUESTA
E
n este apartado se va a entrar en detalle de la solucin adoptada, explicando paso a paso las decisiones
tomadas en funcin de las tecnologas escogidas y para cada uno de los tres sectores en los que podemos
dividir el conjunto de aplicaciones y herramientas que componen este proyecto: integracin con
biodispositivos para recuperar la informacin biomdica de los pacientes, almacenamiento e intercambio de
dichos datos y visualizacin de los mismos.
A lo largo del captulo se deber abordar con profundidad la arquitectura diseada para dar cabida a todos los
componentes del proyecto. Una vez comentada la arquitectura, que establece las relaciones entre todos los
elementos, se entrar en detalle de cada uno de estos componentes, empleando la siguiente lgica:
- Primero se abordarn los aspectos exclusivos de la integracin con los biodispositivos.
- En segundo lugar, se tratar la parte de la solucin dedicada al almacenamiento e intercambio de la
informacin.
- Por ltimo, se abordar el software especfico creado para el proyecto. Aunque se ha diseado un
mdulo para cubrir cada una de las funcionalidades, todos cuentan con una serie de elementos comunes
agrupados en pequeos proyectos reutilizables. Dentro de este apartado se ha optado por encarar
primero los mdulos comunes antes de analizar los mdulos principales de integracin,
almacenamiento y visualizacin, por este orden.
Arquitectura
5.1.1 Diseo funcional
Para comprender las decisiones tomadas en el diseo del presente proyecto conviene comenzar citando los
requisitos de partida que se han credo imprescindibles:
- Se realizar un software de recoleccin de datos para recuperar la informacin procedente de los
biodispositivos gracias al hardware de integracin. Dicho software contar con un diseo verstil, que
permita la eleccin de los diferentes protocolos que, en cada caso, se emplearan en la comunicacin con
los biodispositivos.
- Formar parte del presente proyecto una herramienta bsica de visualizacin de la informacin extrada
a travs del software de recuperacin de datos.
- Ser imprescindible almacenar la informacin recuperada en una base de datos.
- El diseo debe ser lo suficientemente robusto como para permitir la ampliacin de funcionalidades en
el futuro. Por ejemplo, parece interesante disear el sistema de forma que se facilite la creacin de un
mdulo de explotacin avanzado de la informacin, que saque estadsticas o genere informes; en la
lnea de lo expuesto en la presentacin del proyecto.
- Se va a trabajar con una informacin de especial importancia, para la que habr que contar con un
sistema que garantice que no se pierda ni se corrompan los datos.
A todo lo anterior hay que sumar un nuevo requisito: el caudal de informacin a tratar es considerable, aunque
no pueda parecerlo a simple vista. Para ello, debemos distinguir entre dos tipos de constantes mdicas con las
que trataremos en el proyecto:
- Datos discretos: medidas concretas realizadas cada cierto tiempo, a baja frecuencia. Por ejemplo, es
habitual expresar la frecuencia cardaca en pulsaciones por minuto, de forma que, por definicin, no
tiene sentido que recibamos esta constante con otra frecuencia. En definitiva, este tipo de datos suelen
47
48 Descripcin de la propuesta
representar datos medios o estadsticos. Para hacer una explicacin grfica accesible, este tipo de
mediciones se corresponden con los valores numricos de los monitores de pacientes que estamos
acostumbrados a ver tanto en los centros de atencin sanitaria como en la ficcin.
- Datos continuos: aqu hablamos de informacin mdica que se mide constantemente, a alta frecuencia.
Se diferencian de las anteriores en que no representan valores medios ni agrupaciones, sino la evolucin
temporal de una determinada caracterstica del paciente. Por ejemplo, un caso conocido es el
electrocardiograma (ECG), que registra la actividad elctrica del corazn. Se trata de una grfica con
una caracterstica forma peridica, con picos de actividad durante los latidos del paciente. Sin embargo,
en ese caso no interesa solo la medicin del nmero de latidos sino observar continuamente la actividad
del corazn para poder analizar si existe alguna anomala en su funcionamiento. Por tanto, aqu nos
encontramos con una seal analgica que debe pasar por un sistema de muestre para ser convertida en
una seal digital explotable.
Esta informacin genera un gran caudal de datos, pues dependiendo de la precisin podemos
encontrarnos con ondas con una frecuencia de muestreo de hasta 500 valores por segundo. Por tanto,
no solo el hardware elegido deber tener capacidad suficiente para procesar varias variables biomdicas
a tiempo real, sino que toda esta informacin tambin debe ser tratada por varias aplicaciones, lo que
condicionar el diseo tcnico del software.
Figura 5-1. Tipos de constantes mdicas, continuas y discretas.
5.1.2 Prototipo inicial de la arquitectura del proyecto

Con todo lo anterior podemos montar un prototipo del proyecto que exprese las relaciones entre todas las partes
y ayude a comprender lo comentado hasta el momento:
Figura 5-2. Primer prototipo de MEDIPi
48
Aplicacin Software Icono Descripcin
Componente software encargado

Device Data Acquisition de establecer la comunicacin con
DDA los biodispositivos y recuperar la
informacin biomdica.
Aplicacin de visualizacin de las

CHART constantes biomdicas de los
pacientes en tiempo real.
Figura 5-3. Leyenda primer prototipo de MEDIPi
En la figura superior tenemos una versin del primer esquema del proyecto. De un vistazo observamos no solo
las relaciones entre los diferentes componentes del software, sino tambin podemos contemplar qu mdulo del
software correr sobre qu componente hardware.
Con todos estos componentes interrelacionados cubriramos los requisitos funcionales que hemos tomado como
base de la construccin de la solucin MEDIPi: el recolector de informacin, corriendo sobre un determinado
hardware de integracin que elegiremos ms adelante y a travs de los puertos, fsicos o no, necesarios segn
cado protocolo, almacenar las constantes biomdicas proporcionadas por los biodispositivos en la base de datos.
Por ltimo, el visor de datos leer de base de datos para representar adecuadamente las grficas de las constantes
recopiladas.
Sin embargo, este prototipo cuenta con varias limitaciones importantes en dos de los puntos marcados en el
anlisis funcional. En primer lugar, hemos considerado fundamental la creacin de una estructura lo
suficientemente slida como para permitir fcilmente la expansin de las funcionalidades existentes y/o la
adicin de nuevos mdulos como podran ser el tratamiento masivo de datos, aplicaciones de gestin de historia
clnica, etc. No en vano estamos hablando de la suite MEDIPi, enfocando desde el inicio el proyecto como un
conjunto de soluciones dedicadas a los diferentes aspectos relacionados con la informacin biomdica de los
usuarios de un sistema sanitario. Este prototipo propone solucionar este problema simplemente construyendo un
sistema de almacenamiento de datos lo suficientemente modularizado como para que los nuevos mdulos
software se cimienten en l, leyendo la informacin all almacenada y realizando con ellas sus labores
especficas. No es una solucin incorrecta, pero s demasiado bsica dadas las caractersticas del contexto en el
que nos ubicamos. Hemos hablado antes de mltiples constantes recuperadas para cada usuario, algunas con
cientos de muestras por segundo. El software y el hardware de integracin tiene capacidad suficiente para tratar
con ellas, pero para que puedan ser explotadas por terceros deberan almacenarse en base de datos en su totalidad,
no solo las de un paciente, si no las de todos. He aqu la principal diferencia: mientras que el hardware y el
software de recoleccin de datos solo tratan informacin recuperada para cada paciente, la base de datos
almacena la de todos. Por tanto, este modelo exige una base de datos inmensa. De partida esto provoca la
necesidad de invertir en un servidor potente, con enorme capacidad de almacenamiento, no solo para la base de
datos, sino para cada lugar en el que se vaya a ejecutar alguno de los mdulos que necesiten acceder a la
informacin biomdica del paciente. Es decir, si uno de los posibles aadidos a los elementos existentes
actualmente a la suite es una aplicacin web esta debera ejecutarse sobre un servidor con capacidad de
procesamiento potente. Pero el problema no es solamente ese: supongamos que queremos abordar un mdulo
de explotacin de datos (big data). Las soluciones existentes, como Hadoop [54], son conscientes de las
limitaciones de procesamiento derivadas de emplear como sistema de entrada una base de datos relacional
clsica. De hecho, en los ltimos tiempos estamos observando el ascenso de las bases de datos NoSQL en este
tipo de trabajos. Aun as, incluso utilizando bases de datos relacionales deben realizarse modificaciones sobre la
estructura clsica: es inabordable emplear un servidor centralizado donde se ubiquen todos los datos, optando
siempre por sistemas de ficheros distribuidos como soporte a esas bases de datos.
49
Figura 5-4. Esquema del sistema de ficheros distribuidos HDFS empleado por Hadoop.
Por tanto, con este prototipo inicial estamos construyendo una arquitectura que, efectivamente, va a permitir la
adicin de mdulos con nuevas funcionalidades, pero conocemos que estamos generando limitaciones de partida
para una de las funcionalidades que, a primera vista, parecen ms interesantes de aadir a la suite.
La primera alternativa a este prototipo es evidente: si el problema radica en la base de datos podemos optar por
cambiarla y emplear un sistema de ficheros distribuidos sobre el que ubicar nuestra base de datos relacional o
NoSQL. Sin embargo, esto implica dificultar enormemente la creacin de la misma, el modelado de datos y su
manteamiento, solamente para evitar limitaciones en una caracterstica que ni siquiera se plantea abordar de
momento.
5.1.3 Modelo definitivo

Hasta ahora hemos llegado a una conclusin: el alto volumen de datos que se debern manejar nos obligan a
replantear la arquitectura del primer prototipo, consiguiendo armonizar la existencia de una base de datos SQL
estndar que no sea excesivamente difcil de manejar por los mdulos bsicos de la suite con una herramienta
que permita a la vez abordar de forma escalable y slida la explotacin de la informacin recolectada. Para
abordar este conflicto debemos replantear la arquitectura, quitando el foco en el punto dbil de la misma: la base
de datos.
En el modelo definitivo, a diferencia del prototipo comentado en el apartado previo, el dispositivo encargado de
realizar el intercambio de informacin entre las distintas aplicaciones se desplaza de la base de datos a una
herramienta que permita la comunicacin de grandes cantidades de datos de forma escalable y asegurando la
integridad de la informacin. Por tanto, en vez de que la aplicacin de recoleccin de datos enve la informacin
a la base de datos y el resto de mdulos lean de ella se emplear un sistema de intercambio alternativo de
informacin en el que escribir el mdulo de recuperacin de informacin y del que leern los mdulos que
as lo deseen. En resumen, gracias a este cambio, la base de datos es solo uno de los componentes que leen de
este sistema de intercambio de informacin, permitiendo que muchos otros tambin lo hagan. Hemos construido
una arquitectura que cumple con la condicin de escalabilidad y evita limitaciones en la explotacin de la
informacin que puedan realizar otros mdulos. Como toda decisin, esta tambin tiene sus puntos dbiles, sus
inconvenientes: hemos aadido ms complejidad a la estructura. Ser tarea fundamental del diseo de dicho
sistema intermedio escoger una herramienta y una configuracin de la misma que reduzcan este problema.
50
Surgen varios aspectos a tratar tras este cambio de arquitectura, que implicarn replantear y remodelar algunas
de las deducciones que se planteaban en el primer prototipo.
Lo primero es partir de que, si ahora vamos a tener un nodo de intercambio, una herramienta para la
comunicacin de la informacin, deber existir por fuerza un programa, un mdulo de la suite MEDIPi que se
encarga de leer de dicha herramienta y de persistir la informacin en base de datos. Aplicando estos cambios
obtenemos un esquema general de la arquitectura definitiva planteada.
Figura 5-5. Esquema general de la arquitectura
Aplicacin Software Icono Descripcin
Componente software encargado

Device Data Acquisition de establecer la comunicacin con
DDA los biodispositivos y recuperar la
Mdulo que persistir la

SAVER informacin recopilada por DDA
en base de datos
Aplicacin de visualizacin de las

CHART constantes biomdicas de los
pacientes en tiempo real.
Figura 5-6. Leyenda esquema general de la arquitectura
A simple vista ya se pueden sacar algunas conclusiones: existe un destacable aumento de complejidad con
respecto al primer prototipo y se ha redefinido el papel de la base de datos en la suite. Ms adelante
comentaremos el primer punto, pero de momento centrmonos en cmo queda finalmente la arquitectura del
proyecto:
51
Componentes de MEDIPi: Modelo definitivo
Sector Hardware Software
Integracin con biodispositivos Raspberry Pi 2 DDA
Almacenamiento y transmisin Base de datos Clster SAVER
Visualizacin PC Cliente CHART
En el prototipo DDA lee y escribe en la base de datos: lee la informacin de configuracin del programa
(incluyendo los datos de los biodispositivos con los que debe integrarse), as como otros parmetros; y escribe
las constantes biomdicas directamente. Ahora el software de recoleccin lee de base de datos igual que antes,
pero escribe toda la informacin recuperada en el sistema de intercambio de datos, representado por la nube en
el esquema general.
Como consecuencia de lo comentado anteriormente, necesitamos un nuevo mdulo software que ejecute la tarea
de recuperar datos de dicho sistema y escribirlos en base de datos. Esa es la labor de MEDIPi Saver,
representado en el esquema en la esquina inferior derecha. Ahora podemos considerar la base de datos como
una copia de seguridad de la informacin intercambiada por el sistema, un lugar en el que almacenamos la
informacin antigua. Esto nos permite realizar algunos cambios en el planteamiento: muchas aplicaciones de la
suite usarn la base de datos, pero esta ya no es el punto central del intercambio de los datos biomdicos. En el
apartado correspondiente al hardware de integracin se realiz un anlisis acerca de dichos datos, estableciendo
una clasificacin bsica entre datos continuos y discretos. Junto a lo anterior, en prrafos previos hemos hecho
hincapi en los problemas que nos producen las seales continuas, de gran peso, comentando la necesidad que
existe en sistema de tratamiento masivo de datos de emplear bases de datos no relacionales (por definicin ms
escalables) e incluso fragmentar el sistema de ficheros sobre el que corre la base de datos. Esta nueva arquitectura
nos permite solucionar todo esto: ahora la base de datos es, desde el punto de las constantes biomdicas, un
elemento de almacenamiento de la informacin antigua, por lo que puede llevarse a cabo un filtrado de dichos
datos. Al fin y al cabo, ahora existe otra manera de acceder a toda la informacin. Saver ser el encargado de
aplicar ese filtrado, que partir de no almacenar las constantes continuas, reduciendo considerablemente el
tamao de la base de datos. Adems, podrn disearse otros filtros que complementen al anterior, dando
empaque a este mdulo del software. Al igual que DDA, Saver necesitar acceder a ciertos parmetros de
configuracin ubicados en la base de datos.
Al igual que el resto de mdulos software de la suite MEDIPi, Chart tambin sufre algunos cambios como
consecuencia de la nueva arquitectura. Ahora no necesita leer de base de datos la informacin biomdica, que
llegar a travs del sistema de intercambio, reduciendo el acceso a la base de datos a la informacin general:
configuracin, datos del paciente, etc.
En general encontramos dos puntos de acceso para los mdulos software presentes o futuros: el sistema de
intercambio (clster Kafka de colas de mensajes) y la base de datos, pudiendo escoger uno u otros segn necesite.
Por ejemplo, una aplicacin de gestin de historia clnica es probable que no necesite los datos a tiempo real de
los pacientes y le baste con lo existente en base de datos, mientras que un sistema de big data probablemente
recupere los datos mediante el sistema de intercambio, siendo probable incluso que emplee una base de datos
propia ms adecuada para sus labores que se pueble a partir de dichos datos. Finalmente hemos concluido una
arquitectura slida y escalable, en la que conviven la base de datos y un sistema de intercambio de datos masivo,
siendo ambos imprescindibles: mientras que el sistema de intercambio de datos masivo permite cumplir
adecuadamente los requisitos funcionales y la existencia de la base de datos es insustituible, pues en algn lugar
debe estar persistida la configuracin de las aplicaciones y la informacin bsica de los usuarios del sistema:
datos del paciente, fechas, constantes, etc.
52
Hardware de integracin con biodispositivos

El primer paso en el planteamiento del proyecto es sin duda realizar el anlisis de cmo debe ser la integracin
fsica con los biodispositivos mdicos. Empezaremos con una clasificacin bsica de los elementos con los que
deber integrarse la solucin desarrollada: podremos diferenciar entre mecanismos de soporte mdico existentes
en el mercado (como monitores cardacos, de presin, ventiladores automticos, bombas de infusin de
medicamentos, etc.) y dispositivos no comerciales, como sensores o soluciones libres empleados en mbitos
acadmicos o divulgativos. El presente proyecto pretende caminar en ambos frentes, ofreciendo una herramienta
lo suficientemente slida como para dar soporte a biodispositivos empresariales usados en las unidades de
atencin mdica de hospitales y a dispositivos ms bsicos y accesibles.
Figura 5-7. A la izquierda, un sensor de pulso cardaco. A la derecha, un ventilador de General Electrics
5.2.1 El estndar HL7

El protocolo HL7, (Health Level Seven) de capa de aplicacin en el modelo OSI, est diseado para intercambiar
todo tipo de informacin mdica como admisiones, traslados, informes, constantes del paciente, etc. Se ubicar
normalmente sobre un protocolo propio de sesin MLLP (Minimum Lower Layer Protocol) [55], aunque es
posible encontrarlo sobre una gran variedad e capas de sesin como ebXML (Electronic Business using
eXtensible Markup Language), SOAP (Simple Object Access Protocol), etc. Sea cual sea el protocolo de sesin,
es poco habitual que no est construido sobre TCP/IP, de forma que los productos que usan HL7 transmiten la
informacin finalmente a travs de un puerto Ethernet o incluso a travs una interfaz WiFi.
Tras este protocolo se encuentra la organizacin HL7 International que, desde 1987, apuesta por dotar a la
comunidad mdica de estndares que permitan la interoperabilidad de datos mundial. Para ello lleva a cabo una
estrategia en mltiples frentes:
- Desarrollar el estndar HL7 buscando una sintaxis coherente y extensible que estructurar informacin
en salud y apoyar los procesos de atencin al paciente, para ser intercambiada entre aplicaciones de
software, conservando al mismo tiempo la semntica de la informacin.
- Colaborar con otras organizaciones desarrolladoras de estndares y organismos nacionales e
internacionales de estandarizacin (por ejemplo, ANSI e ISO), para desarrollar infraestructuras de
dominios de informacin en salud para promover el uso de estndares compatibles.
HL7 define simplemente una estructura, un conjunto de segmentos y de campos que se deben cumplimentar, as
como el contenido de cada uno. Sin embargo, no se indica qu formato exacto debe tener cada campo, por lo
que dos dispositivos que utilicen HL7 tendrn una estructura similar, pero la informacin no ser totalmente
intercambiable. Por ejemplo, un dispositivo puede informar de una constante vital indicando el nombre de la
variable biomdica, mientras que otro puede emplear un cdigo de identificacin; uno puede indicar las unidades
en el sistema internacional, mientras otro use el estndar ISO/IEEE 11073. Incluso es posible encontrar el mismo
dato en diferentes campos segn se haya interpretado la especificacin. Por tanto, HL7 nos ofrece una gran base
para la estandarizacin de la exportacin de datos, pero aun as ser necesario conocer los detalles concretos de
la implementacin que ha hecho cada proveedor.
Para terminar este breve anlisis del protocolo HL7, se va a detallar algunas caractersticas bsicas de su
53
representacin. Los mensajes HL7 se suelen informar de dos maneras totalmente diferentes: XML o ER7. Este
ltimo no es ms que una representacin del valor de cada campo separado por el carcter |, tal y como se puede
ver en el siguiente ejemplo.
MSH|^~\&|CERNER||PriorityHealth||||ORU^R01|Q479004375T431430612|P|2.3|
PID|||001677980||SMITH^CURTIS||19680219|M||||||||||929645156318|123456789|
PD1||||1234567890^LAST^FIRST^M^^^^^NPI|
OBR|1|341856649^HNAM_ORDERID|000002006326002362|648088^Basic Metabolic
Panel|||20061122151600|||||||||1620^Hooker^Robert^L||||||20061122154733|||F|||||
||||||20061122140000|
OBX|1|NM|GLU^Glucose Lvl|59|mg/dL|65-99^65^99|L|||F|||20061122154733|
HL7 tiene evidentes aspectos positivos: toda apuesta por estandarizar la exportacin de biodatos actualmente
pasa s o s por este estndar, no existiendo competidores reales en el mercado. Adems, como se ha comentado
hace unas lneas, HL7 apuesta por abordar la prctica totalidad de informacin clnica de los pacientes, no
quedando reducido al campo de la integracin con biodispositivos. Esto es realmente interesante, aunque pocos
centros sanitarios lo emplean para las constantes mdicas de los enfermos s es mucho ms habitual que sirva
como base en el intercambio de informacin administrativa (altas, traslados, informes, etc.) Sin embargo, los
aspectos negativos que rodean al protocolo no son menores: solo los biodispositivos de los ltimos aos estn
apostando decididamente por implementarlo como mecanismo de exportacin de datos, lo que, unido a la
elevada vida media de dicha maquinaria, provoca que sea realmente difcil encontrar un centro sanitario en el
que una cantidad representativa de sus biodispositivos soporte HL7. Un rpido vistazo al mercado actual
corrobora la afirmacin anterior: los productos alternativos a este proyecto no se centran en implementar un
servidor de HL7, sino que siempre trabajan con protocolos propietarios especficos, pues es el nico modo de
dar soporte a un nmero razonable de dispositivos. A lo anterior hay que sumar dos cuestiones menores: se
pretende que el actual proyecto sea extensible a sensores no comerciales (que no suelen trabajar con HL7) e
incluso que se estudie la posibilidad de influir en el comportamiento del dispositivo, algo que queda totalmente
fuera del planteamiento del estndar.
En un futuro, sera interesante abordar una herramienta que permita recibir y procesar informacin HL7. Como
ya se ha comentado, HL7 no es solamente un estndar para la exportacin de datos biomdicos de los pacientes,
sino que tambin permite el intercambio de otros mensajes administrativos y clnicos. Por tanto, abordar este
modo de integracin con biodispositivos implica disear una arquitectura compatible con los otros usos del
estndar, algo totalmente fuera del alcance de este proyecto. Eso s, parece evidente que estamos ante un gran
cambio de enfoque: basta con un servidor HL7 colocado en la red para recibir los mensajes y procesarlos, sin
necesidad de recurrir a componentes hardware especficos como en el enfoque anterior.
5.2.2 Protocolos propietarios

Una vez comentado por qu se ha descartado una integracin con biodispositivos basada en HL7, se pasa a
analizar el enfoque multiprotocolo. Este enfoque consiste en disear una aplicacin capaz de alternar entre un
conjunto variado de protocolos, generalmente propietarios, cada uno de los cuales se comunicar mediante un
puerto diferente (puertos paralelos, RS232, USB, etc.). Para abordar adecuadamente el diseo de una tarea tan
ambiciosa debemos contar con un hardware de integracin para conectar uno o varios dispositivos, de forma
que el software que corra sobre l traslade la informacin recibida a un formato interno estndar y la enve al
sistema de almacenamiento / intercambio de informacin adecuado. Bajo este prisma es inmediato obtener la
primera caracterstica sobre la que se cimentar el hardware de integracin del proyecto: la versatilidad. Por
tanto, se descarta disear un componente electrnico propio. Un desarrollo especfico obligara a cambiar el
enfoque del proyecto, que no es otro que la integracin del mayor nmero de soluciones tecnolgicas posibles
de forma que los usuarios del mismo, profesionales sanitarios u otros, puedan explotar la informacin biomdica
procesada por los mismos. Dicho enfoque es irrenunciable, ningn cliente optar por implementar una solucin
para centralizar informacin si los elementos soportados son demasiado limitados.
Otra posibilidad sera desarrollar un dispositivo electrnico que disponga de los conectores bsicos del mercado,
por ejemplo, una placa con varios USB, un puerto Ethernet y pines para sensores, pero, evidentemente, ya
54
encontramos placas que realizan perfectamente esta funcin a precios populares.

Junto a la necesidad de un componente hardware lo suficientemente verstil como para cubrir la comunicacin
con diversos productos va unida la escalabilidad del mismo; es decir, la cantidad de dispositivos / protocolos
soportados y su facilidad para que esto aumente en el futuro. Con el enfoque elegido, nos encontraremos en un
escenario en el que nuestro hardware de integracin raramente abandonar la dinmica 1 puerto 1 dispositivo.
Es aqu donde se plantea el asunto de la escalabilidad, intrnsecamente relacionada al punto anterior. Previamente
se ha justificado la preferencia por un dispositivo hardware ya existente en el mercado, dado la poca
especificidad de las conexiones (casi siempre estndares) y la amplia versatilidad necesaria. Ahora a esto
debemos sumarle el mayor nmero posible de conexiones, teniendo en cuenta que cada conexin podra ser
totalmente diferente (puerto serie, paralelo, USB, etc.). Bajo esta concepcin parece convincente plantearse la
necesidad de dotar a nuestro hardware de la mayor cantidad de puertos, del tipo ms estndar posible. Dicho
puerto debera completarse con un adaptador a otro tipo de conexin cuando sea necesario. Esto facilita aumenta
exponencialmente la versatilidad y escalabilidad del software, aunque no cierra totalmente el coste de
implantacin: si en el futuro se pretende dar soporte a un nuevo dispositivo ser necesario incorporar al hardware
el adaptador adecuado, con el consiguiente desembolso. Dado el pequeo precio de los adaptadores existentes
en el mercado entre puertos estndares, se entiende que nos encontramos ante la solucin ptima, encontrando
un punto intermedio adecuado entre los factores que estamos considerando.
Figura 5-8. La Raspberry Pi 2 B ofrece 4 puertos USB a bajo coste
Quedan por cerrar un par de asuntos importantes, generalmente relacionados entre s: coste y rendimiento.
Conviene recordar que pretendemos correr sobre el hardware un programa encargado de comunicarse con varios
dispositivos a la vez, recuperando las constantes biomdicas del paciente, procesndolas y envindolas a una
base de datos para su almacenamiento. En principio, no parece una tarea excesivamente exigente, que requiera
de una velocidad de procesamiento de datos elevada, aunque para analizar adecuadamente este punto debemos
observar con qu velocidad enva informacin los dispositivos mdicos. Dado que planteamos una integracin
verstil que permite la adaptacin del mayor nmero posible de dispositivos, la pregunta debe ser reformulada
para pasar de con qu velocidad recibiremos datos? a cul es la tasa mxima de datos que deberemos soportar?
Antes de acercarnos a las conclusiones de este apartado del anlisis, conviene tener claro la funcin del proyecto:
la idea es recopilar toda la informacin posible del paciente para almacenarla y ser explotada posteriormente. Es
decir, deberemos estar preparados para recuperar toda la informacin disponible, de tal forma que corresponde
a otra solucin, fuera del alcance de este proyecto, decidir cunta cantidad de informacin es realmente necesaria.
Aclaremos a qu nos referimos con la frase anterior: es habitual que en los centros sanitarios los profesionales
de enfermera comprueben las constantes de los pacientes con una periodicidad elevada, cercana a la hora,
excepto en situaciones de crisis. La presente solucin no debe entrar en estas cuestiones, solo procesando datos
de acuerdo a determinados patrones mdicos, sino que debe almacenar toda informacin recibida, siendo tarea
posterior filtrar o explotar como se desee los datos recolectados.
Llegado a este punto es fcil comprender que la capacidad de procesamiento depender de dos variables:
cantidad de constantes y frecuencia con la que se esperan recibir datos de cada una. Evidentemente, la capacidad
de procesamiento de la informacin est ntimamente relacionada con la cantidad de constantes a recibir. Incluso
si contemplamos solo de las denominadas variables discretas, no es lo mismo procesar cinco variables por
minuto que cien por segundo. Por su parte, la frecuencia con la que recibiremos los datos no es problemtica si
hablamos de constantes discretas, pues es raro trabajar con resoluciones inferiores al segundo, mientras que en
55
el caso de las seales continuas la tasa de muestreo suele situarse en las 500-1000 muestras por segundo.
Partiendo de lo anterior, parece adecuado concluir que el principal dato para realizar la correcta caracterizacin
de nuestro sistema es la tasa de muestreo de las seales continuas que debemos procesar a tiempo real. No se
trata de una frecuencia especialmente elevada, por lo que muchas de las placas de bajo coste existentes en el
mercado (Arduino, Raspberry, etc.) deben tener capacidad suficiente para trabajar con ellas siempre que no
hablemos de una cantidad desmesurada de variables continuas. Hasta ahora, esas variables eran solamente las
mostradas en las pantallas de los dispositivos mdicos (fundamentalmente monitores, aunque tambin otros
elementos auxiliares como ventiladores); por lo que nos moveremos sobre la docena de variables en el ms
exigente de los casos.
Con cuatro puertos USB, la Raspberry Pi 2 debe ser capaz de soportar las bioseales de cuatro dispositivos a la
vez. Esta placa hardware cuenta con un procesador cuatro ncleos de 900 MHz, lo que la capacitar de sobre para
actuar como hardware de integracin en nuestro proyecto.
Antes de terminar este punto es necesario abordar el nico objetivo del proyecto relacionado con la integracin
que no se ha comentado hasta el momento: la posibilidad de dotar a las aplicaciones propias, o a programas de
terceros a travs de internet, de la capacidad de influir en el comportamiento de los biodispositivos soportados.
La idea inicial pretenda conocer las posibilidades de interaccin bidireccional con estos dispositivos,
permitiendo a las aplicaciones setear parmetros o cambiar su configuracin, con el objetivo de abrir la puerta a
desarrollar productos ms inteligentes. Si todo lo anterior es realizable, es posible imaginar un escenario en el
que determinada informacin biomdica del paciente pueda provocar un cambio automtico en el
comportamiento de los dispositivos, o incluso permitir a los facultativos un control remoto de los mismos.
Durante el apartado anterior se ha comentado que esta funcionalidad escapa totalmente del mbito del estndar
HL7, siendo solamente posible bajo un enfoque de comunicacin basado en protocolos propietarios, Esto es
cierto, existen protocolos propietarios de comunicacin con biodispositivos que permiten a los ordenadores
modificar su comportamiento, en la lnea de lo comentado en este prrafo. Sin embargo, no existe un patrn
comn, un conjunto de funcionalidades habituales soportadas por los protocolos; es ms, el nmero de
protocolos que ofrecen algo ms que la mera exportacin de datos es insignificante. Por tanto, se concluye que
los dispositivos actuales del mercado no estn enfocados a esta tarea, por lo que no se puede abordar en el
presente proyecto.
5.2.3 Adaptacin entre puertos estndares

Tal y como se ha comentado en el punto anterior, ser necesario complementar nuestro hardware de integracin
con los adaptadores necesarios para otros puertos de entrada estndares. Como el caso ms habitual ser la
utilizacin de un adaptador USB RS232 se ha considerado adecuado realizar un breve comentario sobre esta
parte del proyecto.
56
Figura 5-9. Esquema de una adaptacin RS232 (DB9) a USB
RS232 es una interfaz que designa una norma para el intercambio de una serie de datos binarios entre dos
extremos (1 a 1), mientras que USB es un bus, de tal forma que permite a ms de un dispositivo conectarse a un
puerto USB, provocando que el estndar no solo describa las propiedades fsicas de la interfaz (capa fsica) sino
tambin los protocolos necesarios para transmitir adecuadamente la informacin. Esto no se da en la
comunicacin RS232, donde existe una gran libertad para configurar muchos parmetros de la comunicacin.
Con frecuencia es habitual que las aplicaciones controlen la tasa de bits, nmero de bits de parada, nmero de
bits de datos y otros parmetros, algo impensable en el estndar USB. Por todo esto, la adaptacin entre ambos
puertos no es inmediata, como se puede comprobar en la imagen ubicada encima del presente prrafo.
En lo referente al coste, es habitual encontrar adaptadores DB9 a USB por un precio ubicado entre los 5 y 10
euros.
Figura 5-10. Adaptador empleado en el proyecto
57
Base de datos
Antes de abordar el software de recuperacin de datos es conveniente analizar el modelo de datos empleado,
pues este condiciona numerosos aspectos del programa.
En los captulos anteriores se ha comentado las distintas tecnologas que se pueden usar para implementar una
base de datos, realizando una comparativa entre las mismas y justificando la eleccin de una base de datos Oracle
11g. En dicho punto se realiza una adecuada explicacin de los conceptos ms bsicos necesarios para operar
con una base de datos como la seleccionada. A continuacin, se proceder a comentar la solucin escogida,
detallando el modelo de datos de acuerdo a las caractersticas previamente documentadas.
5.3.1 Tablespace
Como comentamos anteriormente, las bases de datos Oracle tienen una estructura lgica que comienza con el
Tablespace. Se define un Tablespace para controlar la localizacin de los ficheros de datos, especificacin de
mximas cuotas de consumo de disco, disponibilidad de los datos (en lnea o fuera de lnea), backup de datos,
etc. Como se est montando una base de datos pequea y destinada, de momento, solamente a nuestro proyecto,
no tiene sentido establecer una configuracin no nica para estos parmetros. En general, es poco habitual la
existencia de varios Tablespace en bases de datos de tamao medio, pues los gestores de la base de datos suelen
renegar de combinar polticas diferentes siempre que no sea estrictamente necesario. En nuestro caso,
planteamos un modelo de datos de una decena de tablas, por lo que se turna absurdo llegar a tal nivel de
complejidad como para combinar varios Tablespace.
Conviene tener en cuenta que las bases de datos Oracle ya cuentan con varios Tablespace de fbrica, necesarios
para su correcto funcionamiento. En la imagen siguiente, obtenida a travs de la aplicacin web que ofrece
nuestra base de datos Oracle (http://127.0.0.1:8080/apex/), podemos conocerlos y comprobar sus datos bsicos.
Figura 5-11. Tablespace iniciales de una base de datos Oracle XE 11g R2
Se procede a comentar de manera muy genrica la utilidad de cada uno de estos tablespace [56, 57]
- SYSTEM: todas las bases de datos Oracle contienen un tablespace SYSTEM, creado automticamente
con la base de datos. Este tablespace est siempre online cuando la base de datos est abierta. Se trata
de un diccionario de datos, es decir, un repositorio de metadatos que permite almacenar formatos,
significados, relaciones, uso, etc. de cada elemento de la base de datos.
- SYSAUX: es un tablespace auxiliar del tablespace SYSTEM. Algunos componentes de las bases de
datos usan este tablespace como su ubicacin por defecto para almacenar informacin.
- UNDO: al igual que los anteriores, toda instalacin de una base de datos Oracle cuenta con un
tablespace UNDO. Como su propio nombre indica se emplean para almacenar informacin necesaria
para realizar acciones de deshacer. En este tablespace no se pueden crear tablas.
- TEMP: tablespace para el almacenamiento de informacin temporal.
- USERS: tablespace empleado para almacenar informacin bsica de usuarios.
58
Comenzaremos a parametrizar la base de datos del proyecto conectndonos con los parmetros establecidos por
defecto para la base de datos seleccionada.
Figura 5-12. Parmetros de conexin por defecto de la base de datos
En este apartado solo tendremos que crear el tablespace, para lo cual ejecutaremos desde alguno de los entornos
de desarrollo de base de datos del proyecto (SQL Plus o SQL Developer) la instruccin:
CREATE TABLESPACE TS_MEDIPI DATAFILE

'C:/oraclexe/app/oracle/oradata/XE/MEDIPI.dbf' SIZE 500M AUTOEXTEND OFF
LOGGING
ONLINE;
En la que se indican los siguientes parmetros:

- Datafile: se coment en el captulo de tecnologas empleadas la estructura fsica de una base de datos
Oracle XE 11g R2. En resumen, un datafile es el fichero (o ficheros) fsicos en los que se encontrar la
informacin del tablespace. En este caso se emplea una base de datos sobre una mquina con Windows,
por lo que se crea el fichero bajo la estructura generada en la instalacin de la base de datos.
- Tamao: en este caso se ha optado por un tamao base de 500MB. Por motivos de seguridad, se
deshabilita la capacidad de aumento dinmico del tamao del tablespace. Si nos quedamos sin espacio
deberemos redimensionar el tablespace manualmente.
- Logging: con esta opcin quedan registradas las operaciones de DDL e inserciones de datos en tablas
en el sistema de log predeterminado de Oracle.
- Online: es la opcin predeterminada, pues un tablespace debe estar online para poder trabajar
normalmente con l. Se opta por poner offline un tablespace cuando se requieren hacer algunas
operaciones especiales como copias de seguridad ms rpidas, labores de restauracin de datos, mover
un datafile sin cerrar la base de datos, etc.
5.3.2 Usuarios / Esquemas

Conviene recordar algunos aspectos de la relacin entre usuarios y esquemas en el modelo de informacin que
manejan las bases de datos Oracle. Resumiendo, un esquema es una coleccin de objetos de base de datos,
59
incluyendo estructuras lgicas, tales como tablas, vistas, secuencias, procedimientos almacenados, sinnimos,
ndices, clsteres, y la base de datos de enlaces. Un usuario posee un esquema, que se crea automticamente al
crear el usuario. En Oracle, un usuario solo puede tener un esquema, a diferencia de lo que ocurre en otras bases
de datos. De esta forma, la relacin entre usuario y esquema puede simplificarse hasta indicar que son sinnimos.
Realmente esto no es as, un usuario es el propietario de los objetos y el esquema la agrupacin lgica de los
mismos, pero puede considerarse aceptable la simplificacin al haber una relacin 1 a 1. Adems, un usuario
puede acceder a los objetos de esquemas diferentes del propio, si tienen permiso para hacerlo.
En el presente proyecto se ha optado por establecer dos esquemas diferentes para escenificar las dos grandes
categoras que componen el modelo de datos. Funcionalmente, podemos dividir el modelo de datos en dos partes
claramente diferenciadas:
- Informacin general mdica: entran en esta categora todo objeto relacionado exclusivamente con
informacin mdica. Por ejemplo, parece evidente que necesitaremos almacenar informacin del
paciente como nombre, apellidos, DNI, etc.
- Informacin de la integracin: en una categora totalmente distinta podemos encontrar la informacin
puramente enfocada a la integracin. Por ejemplo, habr que crear una tabla con los dispositivos
conocidos, sus parmetros, su asignacin a cada raspberry en caso de que tengamos ms de una
funcionando a la vez, etc.
Como se observa, estamos hablando de una clasificacin meramente funcional, no tcnica. Sin embargo,
recordemos que en las bases de datos Oracle los usuarios tienen asociado un esquema. Si creamos dos esquemas
diferentes, podemos tener dos usuarios distintos para manejar informacin funcionalmente diferente. Por
ejemplo, podramos darle a un profesional sanitario acceso a la base de datos con el usuario del esquema de
informacin mdica, de forma que, ya sea directamente o a travs de una aplicacin concreta, pueda modificar
la informacin all almacenada para aadir pacientes, modificar sus datos, etc. Sin embargo, no podra acceder
a la informacin de la integracin con los dispositivos si configuramos adecuadamente la base de datos. Adems,
un correcto modelado de la base de datos debe tener en cuenta la posible expansin del proyecto. Con esta
clasificacin permitimos que se pueda extender el esquema de informacin mdica para, por ejemplo,
compartirlo con una aplicacin encargada de gestionar la historia clnica de un paciente.
Por tanto, vamos a crear dos usuarios: HEALTH y DATA_ACQ.
CREATE USER HEALTH

IDENTIFIED BY "HEALTH"
DEFAULT TABLESPACE TS_MEDIPI
TEMPORARY TABLESPACE TEMP
PROFILE DEFAULT
ACCOUNT UNLOCK;
GRANT CONNECT TO HEALTH;

GRANT RESOURCE TO HEALTH;
GRANT CREATE DATABASE LINK TO HEALTH;
ALTER USER HEALTH DEFAULT ROLE ALL;
CREATE USER DATA_ACQ

IDENTIFIED BY "DATA_ACQ"
DEFAULT TABLESPACE TS_MEDIPI
TEMPORARY TABLESPACE TEMP
PROFILE DEFAULT
ACCOUNT UNLOCK;
GRANT CONNECT TO DATA_ACQ;

GRANT RESOURCE TO DATA_ACQ;
GRANT CREATE DATABASE LINK TO DATA_ACQ;
ALTER USER DATA_ACQ DEFAULT ROLE ALL;
60
En la creacin de los usuarios le asignamos el tablespace creado anteriormente y le damos los permisos y
caractersticas necesarias para acceder a la base de datos independientemente. La propiedad del usuario
ACCOUNT UNLOCK indica que se permite el login del usuario en la base de datos mediante la contrasea
indicada en la instruccin IDENTIFIED BY. A continuacin, le indicamos que emplee el perfil por defecto.
Los perfiles [57] se emplean para restringir el uso que un usuario puede hacer de la base de datos, en trminos
de cantidad de espacio disponible, tiempo de conexin, etc. En este caso, al tratarse de un modelo de datos
pequeo, no hay necesidad de definir una poltica de perfiles demasiado compleja, con lo que se opta por emplear
el perfil por defecto, que no limita las caractersticas del usuario. Para terminar, es necesario configurar los roles
del usuario: Todos los usuarios que quieran acceder a la BD deben tener el rol CONNECT; aquellos que necesiten
crear segmentos (procedures, triggers, Jobs, etc.) necesitaran el rol RESOURCE. Por ltimo, el permiso CREATE
DATABASE LINK [58] aade la posibilidad de crear un enlace privado a la actual base de datos desde una
segunda base de datos de Oracle, lo que permitira lanzar consultas o realizar modificaciones desde la segunda
base de datos. La ltima sentencia indica los roles por defecto, es decir, los que tendr el usuario
automticamente al logarse en la base de datos.
5.3.3 Tablas
Es el turno de comentar la parte central del modelo de datos: las tablas y los campos que las componen. Hemos
visto anteriormente que nuestra solucin va a contar con dos esquemas: HEALTH y DATA_ACQ, los cuales
se detallan a continuacin.
Figura 5-13. Modelo de datos
En el grfico anterior se ha empleado la siguiente notacin:

- Las elipses representan las tablas del modelo de datos
- Las flechas representan las relaciones entre tablas. Cuando una tabla apunta a otra se est
representando que en la tabla origen existe una referencia a la tabla apuntada mediante una clave externa
Como se observa, las tablas se reparten entre los dos esquemas creados. Dentro de HEALTH ubicamos las
entidades que recopilan informacin general, como por ejemplo informacin del paciente; mientras que en
DATA_ACQ se encuentra todo el modelo de datos de la recoleccin de informacin.
Se puede observar que el nmero de relaciones entre tablas de distintos esquemas es lo ms reducido posible y
61
siempre van de tablas de DATA_ACQ a entidades del esquema HEALTH. Esto no es casualidad, si se desea
implementar otro sistema sobre esta base de datos, como por ejemplo una aplicacin que represente la
informacin del paciente, el esquema HEALTH debera ser completamente independiente, de forma que no sea
necesaria realizar ninguna accin sobre el esquema DATA_ACQ, hasta el punto de poder borrar este esquema.
Emplear esta poltica de separacin de entidades permite una gran modularidad, de forma que nuevas
aplicaciones puedan crear esquemas propios sobre el ncleo HEALTH, ignorando el resto de esquemas.
Adems de lo anterior, se observa que el modelo de base de datos construido cumple con el estndar de
normalizacin 3FN.
5.3.3.1 Informacin comn a todas las tablas
Antes de comenzar, conviene comentar los tipos bsicos de datos de Oracle, para comprender la terminologa
usada posteriormente en la definicin de las tablas:
- NUMBER(X, Y): Tipo numrico. El primer valor representa la precisin (nmero total de dgitos) y el
segundo la escala (nmero de dgitos decimales, es decir, a la derecha del punto decimal). El valor por
defecto es (38,0)
- DATE / TIMESTAMP(X): Tipo fecha. El tipo TIMESTAMP es similar a DATE (el tipo fecha ms
habitual) pero permite introducir fracciones de segundos, indicando entre parntesis el nmero de
dgitos de precisin en las fracciones de segundo. El valor por defecto es 6.
- VARCHAR2(X BYTE): Tipo texto, indicando el tamao mximo en bytes (50 por defecto).
A lo largo del apartado se emplear la clasificacin estndar de tablas en funcin de la informacin almacenada:
- Maestras: Informacin prcticamente fija, que cambia raramente, y generalmente relacionada con un
conjunto de datos maestros del mundo real. Por ejemplo, un catlogo de pases del mundo se almacenar
en una tabla maestra, pues esta informacin no debe cambiar prcticamente nunca. En nuestro caso, la
tabla CONSTANT ser maestra, pues es poco habitual aadir o eliminar variables clnicas como la
frecuencia cardiaca, presin arterial, etc. Si se pretende optimizar el uso de una tabla maestra se
centrarn los esfuerzos en agilizar las consultas, penalizando la insercin de nuevos registros. Las tablas
maestras no deben hacer referencia (mediante una clave externa) a ninguna otra tabla que no sea tambin
maestra.
- Paramtricas: Contienen informacin variable que no suelen cambiar habitualmente. Este tipo de tablas
se suelen emplear para datos del sistema, aunque puede emplearse para informacin del mundo real de
variacin mayor a las maestras. Como se puede deducir, la tabla PARAMETER de nuestro modelo de
datos se emplea para almacenar determinados parmetros del sistema, como podra ser una constante
que indique el nmero de intentos de reconexin que deben realizarse tras una prdida de conexin con
la red.
- Datos: Las tablas de tipo Datos contienen informacin no fija, que vara constantemente, como las
constantes de un paciente. En este tipo de tablas prima la velocidad de insercin / modificacin de
registros. Ser muy habitual que las tablas de datos hagan referencia a las tablas maestras, pero nunca
al revs.
Para homogenizar el modelo de datos y facilitar su uso, se seguirn un conjunto de reglas comunes:
- Clave primaria: La clave primaria de toda tabla se denominar TABLA_ID. Cuando un campo haga
referencia a la clave primaria de otra tabla mantendr el nombre original.
- Fechas: los campos que almacenen una fecha sern de tipo TIMESTAMP.
Adems de todo lo anterior, las tablas creadas para el modelo de datos de MEDIPi comparten un ncleo, un
conjunto de columnas comunes que representan informacin bsica. Estas son:
62
CAMPO TIPO DEFAULT COMENTARIO
DELETED NUMBER(1,0) 0 Indicador de borrado lgico. 1 borrado / 0 no borrado
INSERT_DATE TIMESTAMP(6) SYSDATE Fecha de creacin del registro
UPDATE_DATE TIMESTAMP(6) Fecha de ltima modificacin del registro
VERSION NUMBER(38,0) 0 Versin del registro
5.3.3.2 Esquema HEALTH
5.3.3.2.1 PATIENT
Es la entidad base de todo modelo de base de datos para el mbito sanitario. Esta tabla de datos debe incluir la
informacin bsica del paciente, como el nombre, DNI, etc.
PATIENT_ID NUMBER(38,0) Clave primaria de la tabla
PID VARCHAR2(32 BYTE) Identificador del paciente en el servicio sanitario. Debe

estar siempre informado.
DNI VARCHAR2(32 BYTE) DNI
NAME VARCHAR2(32 BYTE) Nombre
SURNAME1 VARCHAR2(32 BYTE) Primer apellido
SURNAME2 VARCHAR2(32 BYTE) Segundo apellido
SEX NUMBER(1,0) 0 0: Desconocido / 1: Hombre / 2: Mujer / 3: Indeterminado
5.3.3.2.2 EPISODE
Cada vez que un paciente visite un centro sanitario se crea un nuevo episodio, con fecha de ingreso y de fin. En
esta tabla debe haber una clave externa a la tabla PATIENT, para poder relacionar la informacin del episodio
con el paciente al que pertenece. Al igual que PATIENT, se trata de una tabla de datos, que contendr una gran
cantidad de informacin que ir aumentando constantemente.
EPISODE_ID NUMBER(38,0) Clave primaria de la tabla
PATIENT_ID NUMBER(38,0) Referencia al paciente. Este campo no puede ser nulo.
EID VARCHAR2(32 BYTE) Identificador del episodio en el servicio sanitario. Debe

estar siempre informado.
START_DATE TIMESTAMP(6) Fecha de ingreso
63
END_DATE TIMESTAMP(6) Fecha de alta
5.3.3.2.3 CONSTANT
Si se pretende recopilar constantes clnicas del paciente es evidente que necesitamos una tabla maestra de
variables biomdicas, un catlogo de variables que podremos obtener automticamente de la integracin con los
dispositivos.
CONSTANT_ID NUMBER(38,0) Clave primaria de la tabla
TYPE NUMBER(1,0) 0 0: Numrica / 1: Texto
DESCRIPTION VARCHAR2(128 BYTE) Descripcin de la variable clnica
MAX_VALUE NUMBER(38,0) En caso de tratarse de una variable de tipo numrico (las

ms habituales) se indica aqu el valor mximo posible de
la misma.
MIN_VALUE NUMBER(38,0) Valor mnimo posible de una constante numrica
Hemos optado por establecer una clasificacin de variables en funcin de si esperamos recuperar valores
numricos o alfanumricos, ya que el tratamiento de la informacin variar en funcin de esto.
Otra informacin importante que puede pasar desapercibida a primera vista es la almacenada en las columnas
MAX_VALUE y MIN_VALUE. La idea es emplear estos campos para conocer el umbral de valores posibles
de una variable clnica. En numerosas ocasiones ser habitual recibir informacin incorrecta desde los
dispositivos mdicos, no solo datos imprecisos, si no directamente valores fuera de rango. Estos datos, que en el
mbito de la instrumentacin biomdica se conocen como artefactos, no suelen ser filtrados por los propios
dispositivos pues la poltica habitual es mostrar toda la informacin posible dejando su interpretacin a cargo de
los profesionales mdicos. En nuestro caso, una de las funcionalidades que MEDIPi aportar a los usuarios es
un tratamiento bsico de limpieza de datos, rechazando datos claramente errneos, que se salgan del umbral de
valores compatibles con la vida. Como es razonable, solo podremos realizar este tratamiento para aquellas
variables clnicas de tipo numrico.
5.3.3.2.4 CONSTANT_INFO
En los puntos anteriores se ha definido el conjunto de tablas bsicas del modelo de datos general: pacientes,
episodios y variables biomdicas, con lo que ya se tiene informacin suficiente para definir la entidad ms
importante de MEDIPi: la tabla de valores de constantes clnicas, donde se volcar toda la informacin
recuperada desde los dispositivos.
Como es fcil deducir, necesitaremos al menos una referencia al paciente y otra a la maestra de variables. Lo
primero lo haremos con una clave externa a la tabla EPISODE, quedando as asociada la constante a una estancia
concreta del paciente. En general, se debe tender a establecer relaciones lo ms especficas posibles. Por ejemplo,
si se hubiera asociado el resultado de una medicin (p.e. Temperatura) a un paciente en vez de a un episodio
sera ms difcil en un futuro sacar estadsticas o patrones de la informacin recuperada. Siguiendo con el
ejemplo, si un paciente ingresa dos veces, la segunda de ellas con fiebre, es evidente que mantener claramente
los resultados asociados a dos episodios diferentes facilita la explotacin de la informacin. En caso contrario,
al observar que los valores pasan de normales a altos habra que revisar las fechas, pudiendo dar lugar a alguna
confusin.
En la definicin de la tabla CONSTANT se defini una categorizacin muy bsica de constantes, una
64
clasificacin entre variables numricas (la gran mayora) y de tipo texto. Por tanto, debemos preparar nuestro
modelo de datos para almacenar variables cuyo valor sea un texto. Un caso fcil de comprender puede ser el
modo de funcionamiento del biodispositivo, que se suele tratar como un texto. Por tanto, a pesar de guardar
fundamentalmente valores numricos, es necesario definir el campo valor como alfanumrico. Existen otras
alternativas a esta metodologa: podra haberse optado por crear una tabla de valores posibles identificados por
una clave numrica. De esta forma, bastara con informar en el campo valor la clave de esta tabla, pudiendo
mantener la columna VALUE como numrica. Sin embargo, este modelo presenta otras deficiencias: no es
posible introducir cualquier valor, solo los presentes en esta tabla. A no ser que se opte por ir introduciendo todos
los valores nuevos en esa tabla, perdindose las ventajas sobre el texto libre. Por todo esto, y esperando disear
un modelo de datos lo menos restrictivo posible para evitar futuras modificaciones, se ha optado por un campo
VALUE de tipo texto.
CONSTANT_INFO_ID NUMBER(38,0) Clave primaria de la tabla
CONSTANT_ID NUMBER(38,0) Clave externa que hace referencia a la constante informada
EPISODE_ID NUMBER(38,0) Clave externa que hace referencia al episodio

correspondiente del paciente para el que se recopila la
variable.
CONSTANT_DATE TIMESTAMP(6) SYSDATE Fecha de recuperacin de la variable
VALUE VARCHAR2(32 BYTE) Valor de la variable
MANUAL NUMBER(1,0) 0 0: Valor recuperado automticamente / 1: Datos

introducido manualmente.
Es interesante realizar una observacin acerca de la tabla que nos ocupa: a pesar de tratarse de la entidad diseada
para almacenar informacin no solo no pertenece al esquema de adquisicin de datos (DATA_ACQ), sino que
ni siquiera tiene relacin con alguna tabla de dicho esquema. A primera vista resulta chocante, pero es fcilmente
comprensible desde la poltica escogida para el diseo del modelo de datos: cada esquema corresponde a una
funcionalidad concreta y diferenciada, de tal forma que las tablas que componen el esquema DATA_ACQ son
aquellas necesarias en la creacin de una aplicacin para la adquisicin de datos, mientras que bajo HEALTH
agrupamos las tablas que mapean informacin mdica de carcter general. El conjunto de constantes de un
paciente es una informacin mdica que no debe ser exclusiva del software de adquisicin automtica de datos,
hasta el punto de que se podra disear una solucin que permitiera a los profesionales mdicos introducir a
mano valores para la temperatura del paciente, la frecuencia cardiaca, etc. La solucin imaginada en la frase
anterior debera conocer las tablas en las que se recopile la informacin del paciente, su estancia actual, la
maestra de variables clnicas, etc., pero nunca debera ser imprescindible tener en cuenta el conjunto de
protocolos soportados por la recoleccin automtica de informacin, por ejemplo. Por tanto, parece lgico
disear nuestro modelo de datos sacando la entidad de constantes mdicas CONSTANT_INFO al esquema
general. Como toda decisin, este diseo nos genera tambin inconvenientes: si mantuviramos
CONSTANT_INFO dentro del esquema DATA_ACQ probablemente se hubiera optado por aadir una
referencia al menos al dispositivo del que proviene la informacin, permitiendo una gran explotacin de la
informacin a futuro. Bajo nuestra implementacin, necesitaramos combinar informacin de varias tablas para
poder mostrar esa informacin (necesitamos saber, a travs del episodio, la asignacin de dispositivos que tena
el paciente en aquella fecha; pudiendo incluso no obtener un resultado concluyente si haba ms de un dispositivo
asignado en ese instante con capacidad de recuperar esa variable clnica). En resumen, hemos ganado en
modularizacin, pero hemos dificultado la explotacin posterior de la informacin.
65
5.3.3.3 Esquema DATA_ACQ
5.3.3.3.1 MEDIPI_INSTANCE
Nos encontramos ante la tabla central del esquema DATA_ACQ, sobre la que se construye el modelo de datos
de nuestra solucin.
En ella, cada ejecucin del software MEDIPi (por ejemplo, cada Raspberry que corra el software del presente
proyecto) estar representada por un registro, en el que ser informados algunos de los parmetros necesarios
para especificar el funcionamiento de dicha ejecucin. Es fcil imaginar un escenario como el siguiente: un
centro sanitario en el que se desea implantar MEDIPi en una sala con cuatro camas. Para dar cobertura a todos
los pacientes que vayan ocupando las camas, ser necesario imaginar el escenario ms desfavorable: que las
cuatro localizaciones estn ocupadas a la vez. Parece evidente que son necesarias cuatro Raspberrys, cada una
de ellas ejecutando MEDIPi, lo que se corresponde con cuatro registros en la tabla MEDIPI_INSTANCE en
base de datos. En resumen, con esta tabla podremos representar la parametrizacin bsica de cada instancia.
MEDIPI_INSTANCE_ID NUMBER(38,0) Clave primaria de la tabla
INSTANCE_NAME VARCHAR2(64 BYTE) Identificador nico de la instancia de MEDIPi. Ser nico

y no nullable.
IP VARCHAR2(32 BYTE) Direccin IP de la mquina que est ejecutando el software
Se podra haber empleado el campo INSTANCE_NAME como clave primaria, ya que cumple con las dos
condiciones bsicas de toda clave primaria: valores nicos y no nullables. Como se comentar en el apartado
correspondiente a la descripcin del software de MEDIPi, al arrancar la aplicacin se encargar de obtener su
INSTANCE_NAME, con el que se puede identificar el registro correspondiente de la tabla
MEDIPI_INSTANCE. Veremos ms adelante que se ha optado por emplear el nombre del host sobre el que
corre la aplicacin como INSTANCE_NAME. Conocido lo anterior, no hay motivos inmediatos para descartar
la utilizacin de este campo como clave primaria de la tabla. Sin embargo, la utilizacin de una clave numrica
nos proporciona ms ventajas, como veremos en el punto siguiente (Secuencias). Adems, al independizar la
clave de la instancia disponemos de mayor versatilidad a futuro. Si surge la necesidad de ejecutar dos instancias
en la misma mquina solo habr que hacer una pequea revisin en el cdigo no siendo necesario modificar la
estructura de la base de datos. Esto ltimo es fundamental, siempre debe disearse el modelo de una base de
datos de forma lo suficientemente robusta como para evitar sufrir modificaciones por pequeos cambios en el
alcance.
5.3.3.3.2 PROTOCOL
Con la descripcin de la tabla PROTOCOL comenzamos a desgranar el conjunto de tablas que componen el
modelo de datos destinado a caracterizar los distintos dispositivos de los que el software se integrar para
recuperar informacin clnica de un paciente. Antes de continuar, recordemos el modelo diseado:
Figura 5-14. Modelo de datos sobre biodispositivos
66
Se observa que manejamos una estructura relativamente compleja, formada nada menos que por cuatro tablas
destinadas solamente a informar y categorizar los distintos dispositivos. Esta estructura ha sido necesaria para
agrupar adecuadamente los dispositivos desde 2 puntos de vista:
- Protocolos: es imprescindible realizar una asociacin entre el dispositivo con el que nos integraremos y
el protocolo que este implementa, pues es perfectamente posible que dos dispositivos diferentes, de
modelos y fabricantes diferentes, empleen el mismo protocolo.
- Tipos: Para una correcta explotacin posterior de los datos es necesario conocer de qu tipo es cada
dispositivo (Monitor, ventilador, etc.). Esto puede ser fundamental, ya que es habitual que varios
dispositivos puedan recuperar la misma constante, siendo necesario priorizar los valores de aquel tipo
de dispositivo que sea ms preciso en la medicin de dicha variable clnica, ignorando los del otro.
Conociendo ya las condiciones iniciales, que sern fundamentales en la estructura de esta seccin de la base de
datos, abordamos la definicin de la tabla que nos ocupa.
PROTOCOL_ID NUMBER(38,0) Clave primaria de la tabla
CODE VARCHAR2(8 BYTE) Cdigo alfanumrico para identificar unvocamente un

protocolo. No puede ser nulo.
DESCRIPTION VARCHAR2(256 BYTE) Descripcin del protocolo.
INFO VARCHAR2(256 BYTE) Informacin extra, como podra ser datos de

parametrizacin.
Nos encontramos ante una tabla muy sencilla, una simple maestra donde listaremos todos los protocolos
conocidos por MEDIPi. Cuando informemos al software acerca del dispositivo asociado, la aplicacin deber
acceder hasta esta tabla, para poder identificar el protocolo empleado y operar en consecuencia. En esta ocasin
solo se evita emplear CODE como clave primaria por homogeneidad con el resto del modelo de datos y para
disfrutar de las ventajas que se comentarn en el prximo apartado.
5.3.3.3.3 DEVICE_TYPE
Esta tabla lista los distintos tipos de dispositivos disponibles para poder realizar acciones posteriores relacionadas
con la explotacin de la informacin.
DEVICE_TYPE_ID NUMBER(38,0) Clave primaria de la tabla
CODE VARCHAR2(8 BYTE) Cdigo alfanumrico para identificar unvocamente un tipo

de dispositivo. No puede ser nulo.
DESCRIPTION VARCHAR2(128 BYTE) Descripcin del tipo de dispositivo
Como se observa, nos basta con una clave primaria y un campo de descripcin.
67
5.3.3.3.4 DEVICE_MODEL
Esta es, seguramente, la tabla central del conjunto que componen el modelo de datos de dispositivos, con una
importancia superior a la de la tabla DEVICE, pues ser el modelo del dispositivo quien nos permitir reconocer
tanto el tipo del mismo como, sobre todo, el protocolo implementado.
DEVICE_MODEL_ID NUMBER(38,0) Clave primaria de la tabla
DESCRIPTION VARCHAR2(256 BYTE) Descripcin del modelo de dispositivo. No puede ser nulo.
INFO VARCHAR2(256 BYTE) Informacin extra, como podra ser datos de

parametrizacin.
DEVICE_TYPE_ID NUMBER(38,0) Tipo de los dispositivos del presente modelo. Debe estar
siempre informado.
PROTOCOL_ID NUMBER(38,0) Protocolo de comunicacin empleado por los dispositivos

de este modelo. Debe estar siempre informado.
5.3.3.3.5 DEVICE
En la tabla dispositivos incluiremos todos los diferentes dispositivos de los que dispongamos, indicando a qu
modelo pertenecen. Es perfectamente posible disponer de una amplia cantidad de dispositivos del mismo
modelo, teniendo todos ellos caractersticas iguales, por lo que se ha optado por crear la ya comentada tabla
DEVICE_MODEL donde centralizar toda esta informacin. Por tanto, dejamos DEVICE como un mero
catlogo de dispositivos empleados ahora o en el pasado.
DEVICE_ID NUMBER(38,0) Clave primaria de la tabla
SERIAL_NUMBER VARCHAR2(256 BYTE) Nmero de serie del dispositivo. Puede estar nulo, pues en
algunos casos no ser fcil obtenerlo.
DESCRIPTION VARCHAR2(256 BYTE) Descripcin del dispositivo. No nullable
DEVICE_MODEL_ID NUMBER(38,0) Modelo del dispositivo. Debe estar siempre informado.
5.3.3.3.6 ALLOCATION
Ya se han definido las tablas encargadas de modelar los dispositivos y las diferentes Raspberrys que ejecutan el
software, pero no se ha comentado todava como se establece la relacin entre las mismas. Alejndonos
momentneamente del modelado de base de datos, es evidente que ser necesario informar de alguna manera al
software de, al menos, qu protocolos deber implementar para establecer la comunicacin con el dispositivo
de cara a recuperar la informacin de constantes clnicas del paciente. En la mayora de los casos, bastar con
indicar el protocolo, actuando el software en consecuencia. Sin embargo, el estudio de los distintos protocolos
y soluciones de recuperacin automtica de datos nos ha permitido observar que existen casos en los que varios
modelos de un mismo fabricante pueden emplear el mismo protocolo, pero bajo alguna especificacin que el
software debe tener en cuenta de cara a poder realizar una comunicacin adecuada. El caso ms habitual ser el
de los biodispositivos conectados mediante una interfaz serie, donde algunos parmetros fsicos de la
comunicacin como la existencia de bit de paridad, los baudios, etc. pueden variar dependiendo del modelo de
dispositivo. MEDIPi usar una lgica comn, pues el protocolo es el mismo, pero deber conocer de alguna
68
manera estas especificidades. Este es el motivo por el que se aadi una columna INFO a la tabla
DEVICE_MODEL y tambin la razn por la cual se considera imprescindible que la asignacin entre
dispositivos y Raspberrys se realice al menos a nivel de modelo de dispositivo y no de protocolo.
Partiendo de lo anterior, se ha optado por realizar una asociacin a nivel de dispositivo, lo que genera ventajas e
inconvenientes. La principal ventaja es que permite una gran explotacin posterior de la informacin: a partir
del modelo de datos construido se puede recuperar qu dispositivo fue el responsable de cada constante
almacenada. No es una posibilidad despreciable, si descubrimos que un dispositivo ha estado funcionando
incorrectamente podramos eliminar la informacin recuperada por l, o al menos identificarla para ponerla en
cuarentena. Por otra parte, es necesario indicar qu dispositivo concreto es el que est conectado a la raspberry,
lo que requiere identificar de forma unvoca cada dispositivo y mantener correctamente actualizado el catlogo.
Adems de todo lo anterior, falta una asociacin que realizar. Con el modelo de datos diseado hasta el momento
el software no es capaz de llevar a cabo un mapeo entre el dispositivo asignado a una instancia concreta y el
episodio del paciente para el que se estn recuperando las constantes biomdicas va integracin con dispositivos.
Para cumplir este requisito se introduce una clave externa a la tabla episodio desde ALLOCATION, lo que
implica una asociacin a nivel paciente dispositivo instancia, aportando una mayor granularidad que si se
optara por una relacin paciente instancia. En otras palabras, una misma instancia podr tener asignados varios
dispositivos (evidentemente, de modelos, tipo y protocolos diferentes) y cada uno de ellos recuperando
informacin de un paciente distinto.
ALLOCATION_ID NUMBER(38,0) Clave primaria de la tabla
MEDIPI_INSTANCE_ID NUMBER(38,0) Referencia a la instancia del software con la que asociamos

el dispositivo. Debe estar informado
DEVICE_ID NUMBER(38,0) Referencia al dispositivo. Debe estar informado
EPISODE_ID NUMBER(38,0) Referencia al episodio. Debe estar informado.
PORT VARCHAR2(32 BYTE) Puerto de la mquina (Raspberry) a la que se conecta el

dispositivo. Puede ser nulo.
START_DATE TIMESTAMP(6) SYSDATE Fecha de inicio de la asignacin
END_DATE TIMESTAMP(6) Fecha de fin de la asignacin. Valdr nulo cuando todava

est asignado
Junto a los campos mnimos necesarios para realizar la asignacin encontramos tres campos no tan inmediatos.
El primero el puerto a travs del cual se realiza la conexin, pues MEDIPi necesitar conocer a qu puerto estar
conectado el dispositivo para poder comunicarse con l. Con este campo cubrimos varias posibilidades:
podemos escribir en l el puerto fsico (USB, Serie, etc.) si se trata de una comunicacin serie o paralelo, o el
puerto que deber escuchar el software pare recibir informacin a travs de una red IP. Es bastante habitual que
dispositivos del mismo protocolo o modelo tiendan a emplear el mismo puerto para la comunicacin, pudiendo
informarse de ello en el campo de parametrizacin extra que tienen las tablas correspondientes. Se ha indicado
arriba, en la descripcin de los campos de la tabla, que el campo puerto puede no estar informado. En ese caso
se entiende que el puerto est informado en alguno de los campos de informacin comentados. Si no se diera el
caso el software no tendra la configuracin mnima para iniciar la comunicacin.
Adems de todo lo comentado anteriormente se observa que existen dos campos extra: fecha de inicio de la
asignacin y fecha de fin. Con ellos es posible mantener un histrico de asignaciones, indicando para cada
registro cuando comenz y cuando termin la asignacin. Esto ltimo es fundamental para poder recuperar a
posteriori qu dispositivo estaba asignado a qu Raspberry en todo momento.
Antes de pasar a la definicin de la siguiente tabla se realizar un comentario sobre las decisiones meramente
69
tcnicas que se han tomado durante el anlisis y realizacin del modelado de datos. Se ha considerado lo ms
correcto emplear una clave primaria propia para la tabla, en vez de definir una clave compuesta. Dicha clave
compuesta debera estar formada por MEDIPI_INSTANCE_ID, DEVICE_ID y START_DATE. Incluso sera
necesario incluir el campo comn DELETED, pues hablamos de una tabla de asignaciones, que es previsible se
rellene desde una aplicacin, pudindose producir errores que justifiquen la utilizacin del borrado lgica. Nos
encontraramos con una clave tan compleja que prcticamente abarcara la tabla en su totalidad, dificultando las
consultas que se lancen sobre la tabla. Es por este motivo por el que se ha considerado ms adecuado crear una
clave primaria simple.
5.3.3.3.7 PROTOCOL_CONSTANT_MAP
Los distintos protocolos emplean valores propios para identificar a las distintas constantes que manejan, desde
cadenas de texto hasta nmeros identificativos. El software de MEDIPi necesitar conocer en todo momento
qu significa cada uno de ellos de cara a poder realizar el mapeo entre este identificador interno del protocolo y
uno comn a todos y conocido por la aplicacin. Es evidente por tanto que PROTOCOL_CONSTANT_MAP
ser una tabla encargada de establecer las relaciones entre estos valores y la maestra de variables clnicas
conocidas por el sistema CONSTANT. Parece lgico supone que se tratar de una tabla maestra, que se rellenar
durante el desarrollo de la implementacin del protocolo, y que no volver a tocarse salvo para revisiones
puntales.
PROTOCOL_ID NUMBER(38,0) Referencia al protocolo del que pertenece la variable.

Siempre debe estar informado.
CONSTANT_NAME VARCHAR2(128 BYTE) Identificador de la constante biomdica interno empleado

por el protocolo. Debe estar siempre informado y ser
nico dentro de un protocolo.
CONSTANT_ID NUMBER(38,0) Referencia al registro de la maestra de constantes para la

que se est realizando el mapeo. Debe estar informado
Estamos ante la nica tabla del modelo de datos que no cuenta con una clave primaria simple, es decir, no
dispone de su PROTOCOL_CONSTANT_MAP_ID. El motivo es sencillo, estamos ante una tabla de mapeo
para la que, por cada protocolo nos bastar el identificador interno (CONSTANT_NAME) para conocer la
asignacin. Por tanto, se emplear una clave primaria compuesta por PROTOCOL_ID y CONSTANT_NAME.
5.3.3.3.8 PARAMETER
La ltima de las tablas del modelo de datos es la ms sencilla: se trata de una mera tabla paramtrica destinada
a almacenar informacin de configuracin comn a todas las ejecuciones del software MEDIPi. El software
consultar la base de datos para conocer el valor de estos parmetros y actuar segn su valor. La parametrizacin
del software mediante una tabla de base de datos nos permite actualizar dinmicamente sus valores, sin
necesidad de andar parando y arrancando la solucin, como veremos ms adelante.
PARAMETER_ID NUMBER(38,0) Clave primaria de la tabla.
PARAMETER VARCHAR2(64 BYTE) Identificador del parmetro. Debe ser nico y estar siempre
informado.
70
VALUE VARCHAR2(128 BYTE) Valor del parmetro.
DESCRIPTION VARCHAR2(256 BYTE) Descripcin o comentarios del parmetro.
Para terminar el apartado destinado al modelado de tablas se muestran un par de ejemplos de las sentencias SQL
necesarias para crear nuestras tablas en base de datos:
CREATE TABLE DATA_ACQ.ALLOCATION

(
ALLOCATION_ID NUMBER(38,0) PRIMARY KEY,
MEDIPI_INSTANCE_ID NUMBER(38,0) REFERENCES DATA_ACQ.MEDIPI_INSTANCE .
(MEDIPI_INSTANCE_ID) NOT NULL,
DEVICE_ID NUMBER(38,0) REFERENCES DATA_ACQ.DEVICE (DEVICE_ID) .
NOT NULL,
PORT VARCHAR2(32 BYTE),
START_DATE TIMESTAMP(6) DEFAULT SYSDATE NOT NULL,
END_DATE TIMESTAMP(6) ,
DELETED NUMBER(1,0) DEFAULT 0 NOT NULL,
INSERT_DATE TIMESTAMP(6) DEFAULT SYSDATE NOT NULL,
UPDATE_DATE TIMESTAMP(6),
VERSION NUMBER(38,0) DEFAULT 0 NOT NULL
);
CREATE TABLE DATA_ACQ.PROTOCOL_CONSTANT_MAP

(
PROTOCOL_ID NUMBER(38,0),
CONSTANT_NAME VARCHAR2(128 BYTE),
CONSTANT_ID NUMBER(38,0) REFERENCES HEALTH.CONSTANT (CONSTANT_ID) .
NOT NULL,
DELETED NUMBER(1,0) DEFAULT 0 NOT NULL,
INSERT_DATE TIMESTAMP(6) DEFAULT SYSDATE NOT NULL,
UPDATE_DATE TIMESTAMP(6),
VERSION NUMBER(38,0) DEFAULT 0 NOT NULL,
PRIMARY KEY(PROTOCOL_ID, CONSTANT_NAME)
);
A travs de la sentencia CREATE TABLE se especifican las caractersticas de la tabla a crear:

- Se indica ESQUEMA.TABLA
- Cada definicin de un campo sigue la estructura: NOMBRE TIPO OTRA_CONF
- Para indicar una clave primaria se puede optar por aadir la instruccin PRIMARY KEY al final del
campo o colocar una lnea final PRIMARY KEY(campos).
- Se define una clave externa mediante la instruccin REFERENCES
ESQUEMA.TABLA_REFERENCIADA (CAMPO_REFERENCIADO).
5.3.4 Secuencias
Mediante las secuencias [59], Oracle puede proporcionar una lista consecutiva de nmeros unvocos que sirve
para simplificar las tareas de programacin. La primera vez que una consulta llama a una secuencia, se devuelve
un valor predeterminado. En las sucesivas consultas se obtendr un valor incrementado segn el tipo de
incremento especificado. Es decir, una secuencia (sequence) se emplea para generar valores enteros secuenciales
nicos y asignrselos a campos numricos; siendo tremendamente tiles para las claves primarias de las tablas.
Mediante el empleo de secuencias garantizaremos que las claves primaras sean nicas y secuenciales, pudiendo
71
identificar fcilmente el orden en el que se han introducido los registros adems de asegurar la integridad de la
informacin.
Veamos ms detalladamente como funciona una secuencia: Todos los parmetros fundamentales de una
secuencia se indican en su creacin mediante la sentencia CREATE SEQUENCE.
CREATE SEQUENCE NOMBRESECUENCIA

START WITH VALORENTERO
INCREMENT BY VALORENTERO
MAXVALUE VALORENTERO
MINVALUE VALORENTERO
CYCLE | NOCYCLE
CACHE VALORCACHE;
Sobre la instruccin podemos comentar:

- La clusula START WITH indica el valor desde el cual comenzar la generacin de nmeros
secuenciales. Si no se especifica, se inicia con el valor que indique MINVALUE.
- La clusula INCREMENT BY especifica el incremento, es decir, la diferencia entre los nmeros de la
secuencia; debe ser un valor numrico entero positivo o negativo diferente de 0. Si no se indica, por
defecto es 1.
- MAXVALUE define el valor mximo para la secuencia. Si se omite, por defecto es
99999999999999999999999999.
- MINVALUE establece el valor mnimo de la secuencia. Si se omite ser 1.
- La clusula CYCLE indica que, cuando la secuencia llegue a mximo valor (valor de MAXVALUE)
se reinicie, comenzando con el mnimo valor (MINVALUE) nuevamente, es decir, la secuencia vuelve
a utilizar los nmeros. Si se omite, por defecto la secuencia se crea NOCYCLE.
- Con la condicin CACHE se define el nmero de valores que se almacenarn en la cach de Oracle,
aumentando la velocidad en la consulta de la secuencia (reduciendo las lecturas y escrituras que realiza
Oracle en disco). Si se produce algn fallo que provoque el cierre o reinicio de la base de datos los
nmeros cacheados se perdern, de tal forma que en el prximo arranque la secuencia comenzar en el
nmero siguiente al ltimo cacheado.
Si no se especifica ninguna clusula, excepto el nombre de la secuencia, por defecto, comenzar en 1, se
incrementar en 1, el mnimo valor ser 1, el mximo ser 999999999999999999999999999, NOCYCLE y no
estar cacheada.
Para emplear las secuencias se emplean dos instrucciones especiales:

NOMBRESECUENCIA.NEXTVAL;
NOMBRESECUENCIA.CURRVAL;
Con la primera instruccin obtenemos el prximo valor de la secuencia, mientras que la segunda se emplea para
recuperar el valor actual de la misma.
Por tanto, aunque las secuencias sean un objeto de base de datos totalmente independientes de las claves
primarias, en el presente proyecto se utilizarn solamente para facilitar el trabajo con las claves primarias simples
de las tablas.
Veamos un ejemplo de la definicin habitual de una secuencia en nuestro modelo de datos:
CREATE SEQUENCE HEALTH.PATIENT_ID_SEQ
72
START WITH 1
INCREMENT BY 1
MAXVALUE 999999999999999999999999999
MINVALUE 1
NOCYCLE
CACHE 20;
5.3.5 ndices
El ndice [60] de una base de datos es una estructura de datos que mejora la velocidad de las operaciones,
permitiendo un rpido acceso a los registros de una tabla. Al aumentar drsticamente la velocidad de acceso, se
suelen usar sobre aquellos campos sobre los cuales se vayan a realizar bsquedas frecuentes.
El ndice tiene un funcionamiento similar al ndice de un libro, guardando parejas de elementos: el elemento que
se desea indexar y su posicin en la base de datos. Para buscar un elemento que est indexado, slo hay que
buscar en el ndice de dicho elemento para, una vez encontrado, devolver el registro que se encuentre en la
posicin marcada por el ndice. Los ndices son construidos sobre rboles, funciones de clculo u otros mtodos.
Los ndices pueden ser creados usando una o ms columnas, preparando la base de datos tanto para bsquedas
rpidas al azar como para ordenaciones eficientes de los registros.
El espacio en disco requerido para almacenar el ndice es tpicamente menor que el espacio de almacenamiento
de la tabla (puesto que los ndices generalmente contienen solamente los campos clave de acuerdo con los que
la tabla ser ordenada, y excluyen el resto de los detalles de la tabla), lo que da la posibilidad de almacenar en
memoria los ndices de tablas que no cabran en ella. En una base de datos relacional un ndice es una copia de
parte de una tabla
Automticamente Oracle crea ndices nicos tanto para las claves primarias de las tablas como para los campos
diseados como nicos y no nulos, pero ser necesario informar de otros ndices extra que se consideren
necesarios para agilizar las consultas sobre la base de datos.
Eso s, es importante tener en cuenta que los ndices producen una leve ralentizacin en la insercin de registros,
pues es ah donde se informa al ndice de los nuevos registros. Esto nos lleva a una fcil deduccin: las tablas
maestras o paramtricas debern contener tantos ndices como sea necesario, pues apenas se realizarn
inserciones y son tablas constantemente consultadas por los programas. Por otra parte, se debe ser ms cauteloso
con los ndices en las tablas de datos. En general, el empleo de ndices es una poltica altamente beneficiosa para
el rendimiento de las aplicaciones que emplean bases de datos Oracle. Incluso en tablas de datos que reciben
nuevos registros constantemente es necesario contar con los ndices adecuados para que realizar consultas sobre
la misma no lastre la velocidad del software. Por ejemplo, en un centro sanitario las tablas PATIENT o
EPISODE pueden contener decenas de miles de registros pasados unos meses, por lo que realizar una bsqueda
por DNI de un paciente puede tardar segundos si no existe un ndice para ese campo. Aunque dicho ndice
provoque un retraso prcticamente despreciable en la insercin.
De todo lo anterior sacamos que debemos crear ndices para los campos o conjuntos de cambios ms
frecuentemente consultados. En el modelo de base de datos de MEDIPI se han implementado los siguientes
ndices extra, adems de los que Oracle define por defecto:
- PATIENT: SEX. Si se pretende realizar una explotacin posterior de los datos ser habitual intentar
obtener patrones en las constantes biomdicas en funcin del sexo del paciente.
- EPISODE: PATIENT_ID. Es habitual que las claves externas tengan un ndice que permita agilizar las
consultas cuando se crecen informacin de varias tablas. En general, Oracle recomienda seguir esta
regla [61].
- EPISODE: BED_ID.
- EPISODE: START_DATE y END_DATE. Un ndice comn para los dos campos, ya que lo habitual
ser realizar consultas en las que se informen de las condiciones para ambas columnas. Por ejemplo, se
usar para cuando sea necesario consultar los episodios activos en un momento determinado.
73
- ALLOCATION: MEDIPI_INSTANCE_ID. Para facilitar las consultas que cada instancia de software
realizar para conocer sus dispositivos asociados.
- ALLOCATION: DEVICE_ID
- ALLOCATION: START_DATE y END_DATE. Un ndice comn para los dos campos, de forma
similar a los ndices de la tabla EPISODE. Se supone que ser habitual realizar consultas para conocer
la asignacin de dispositivos en un momento concreto.
- DEVICE: DEVICE_MODEL_ID
- DEVICE_MODEL: DEVICE_TYPE_ID.
- DEVICE_MODEL: PROTOCOL_ID
- MEDIPI_INSTANCE: BED_ID
- PROTOCOL_CONSTANT_MAP: CONSTANT_ID
La sentencia que se debe emplear para crear un ndice tiene una estructura sencilla, similar a la explicada para
crear claves externas.
CREATE INDEX PAT_SEX_IX ON HEALTH.PATIENT (SEX);
5.3.6 Permisos
Cuando se crea un objeto (como por ejemplo una tabla o una secuencia) se indica el esquema al que pertenece,
como en el siguiente ejemplo:
CREATE TABLE HEALTH.PATIENT (
El nombre del objeto debe venir precedido por el esquema y un punto. Si no se especifica el esquema se crear
el objeto en el esquema del usuario con el que se est ejecutando la sentencia.
Esta poltica de usuarios / esquemas tiene un inconveniente: por defecto un usuario tiene permisos para modificar
/ crear objetos en su esquema, pero no para alterar o crear objetos en esquemas ajenos. Cuando el software se
arranque debe iniciar su comunicacin con la base de datos, autenticndose contra esta con un usuario. En
nuestro caso usaremos el usuario DATA_ACQ, el ms indicado para el software de integracin con
biodispositivos. Sin embargo, este usuario no va a tener acceso a los objetos del esquema HEALTH, en el que
crearemos algunas tablas bsicas. Esto provocar que, al crear cada objeto, debamos dar permisos al resto de
usuarios si necesitamos que accedan o modifiquen esta informacin.
Para dar permisos a uno o varios usuarios se emplea la instruccin GRANT [62], que ya se emple en el apartado
correspondiente a la definicin de los usuarios / esquemas de la base de datos. Esto se debe a que la instruccin
GRANT se puede emplear para dos fines:
- Dar permisos del sistema: anteriormente vimos que la sentencia GRANT CONNECT TO DATA_ACQ
daba permiso al usuario DATA_ASQ para conectarse a la base de datos.
- Establecer permisos sobre objetos: de manera anloga a la instruccin del punto anterior, podemos
establecer una sentencia que de determinados privilegios a un usuario o un rol.
En la lnea siguiente vemos las dos sentencias que se han empleado en la construccin de nuestra base de datos
para dar los permisos adecuados al usuario DATA_ASQ.
74
GRANT SELECT ON HEALTH.PATIENT_ID_SEQ TO DATA_ACQ;

GRANT SELECT, INSERT, UPDATE, DELETE, REFERENCES ON HEALTH.PATIENT TO DATA_ACQ;
La primera es el GRANT tpico de una secuencia, dando permisos de consulta, mientras que la segunda es el
GRANT que se debe ejecutar para permitir a un usuario realizar las acciones bsicas sobre una tabla (consultar,
insertar, actualizar, borrar registros y crear una clave externa en un objeto que apunte a dicha tabla)
Es bastante habitual encontrarnos con una sentencia como mostradas arribas pero que den privilegios al rol
PUBLIC en vez de especificar un usuario concreto. PUBLIC es un rol especial que poseen todos los usuarios,
de tal forma que basta con darle permiso a ese rol para que todos los usuarios lo tengan. En nuestro caso se
podra haber optado por darle los permisos a este rol especial, pero se cree ms correcto llevar a cabo una poltica
de permisos restrictiva, dando permisos cuando sea necesario y no a todos los usuarios por defecto.
75
Sistema de intercambio de datos: Kafka

La arquitectura software de MEDIPi se sustenta en un sistema de intercambio masivo de informacin biomdica
entre los diferentes mdulos que la componen. Para que cumpla adecuadamente su funcin, es necesario que el
diseo cumpla una serie de caractersticas fundamentales:
- Alta disponibilidad: debe estar siempre operativo. Una cada del mismo supone prdida irrecuperable
de informacin.
- Integridad: el sistema debe ser suficientemente robusto como para evitar no solo prdidas de
informacin, si no tambin que esta se corrompa.
- Velocidad: vamos a trabajar con grandes cantidades de informacin, por lo que el retraso con el que se
mueva la informacin puede ser un punto crtico.
- Escalabilidad: aadir ms capacidad de procesamiento al sistema debe ser lo ms sencillo posible,
permitiendo incluso una adaptacin dinmica, quitando y poniendo elementos segn sea necesario.
Basndonos en todo lo anterior se ha realizado un estudio acerca de las diferentes herramientas que cumplen con
los requisitos citados. En el citado estudio (ubicado en el captulo dedico a las tecnologas empleadas) se ha
justificado la eleccin de Kafka, adems de describir sus componentes y funcionamiento bsico. Partiendo de
ese conocimiento, abordaremos aqu la parametrizacin y configuracin de Kafka dentro del presente proyecto.
Figura 5-15. Arquitectura bsica de Kafka
Resumiendo lo visto anteriormente en detalle, Apache Kafka es un sistema de almacenamiento

publicador/subscriptor distribuido, particionado y replicado. Estas caractersticas, aadidas a que es muy rpido
en lecturas y escrituras lo convierten en una herramienta excelente para comunicar streams de informacin que
se generan a gran velocidad y que deben ser gestionados por uno o varias aplicaciones. Con respecto a la
estructura, Kafka se basa en un conjunto de servidores o nodos fundamentales, denominados Broker que, junto
a un nodo especial que ejecuta el software Apache Zookeeper componen el clster. Sern los brokers quienes
manejen los datos, manteniendo la integridad de los datos. La informacin se estructura en canales o Topics, por
lo que se intercambian mensajes. La arquitectura se completa con los Producers (mandan mensajes al clster) y
los Consumer (leen mensajes del clster).
Para parametrizar Kafka debemos crear por tanto nuestro propio clster, debiendo diferenciar claramente entre
el componente hardware y el software. Es decir, por una parte estarn los servidores fsicos y por otra los
componentes software de Kafka: por ejemplo, es posible que corran varios brokers sobre un mismo servidor.
Nosotros nos centraremos en el componente software, pues se considera que no entra dentro del alcance del
76
presente proyecto elegir los servidores sobre los que deben correr el sistema de intercambio o las aplicaciones
de la suite. Aun as, conviene recalcar que Kafka es una herramienta muy optimizada que no exige un alto coste
de procesamiento, por lo que no ser necesario ningn procesador de especial capacidad. Gracias a lo anterior
podemos seguir manteniendo la coherencia con el argumentario establecido en la eleccin del hardware de
integracin, apostando siempre por reducir el coste de instalacin de MEDIPi al mximo posible.
Para la configuracin partiremos de los binarios de ejecucin existentes en la propia pgina web de Kafka [63],
modificando los ficheros de configuracin adecuadamente.
5.4.1 Nodos
El punto de partida es la creacin de un clster que maneje la informacin biomdica. Hemos comentado que
existen dos tipos de nodos: Zookeeper y Broker.
- Zookeeper: pueden existir uno o varios nodos Zookeeper en un clster de Kafka. Realizan las tareas de
coordinador de los diferentes brokers que compondrn el clster llevando a cabo labores de
sincronizacin, configuracin, registro, agrupacin de nodos, eleccin de nodo/s lder/es, etc. Sus
opciones parametrizacin se modifican en un fichero zookeeper.properties. Al igual que ocurre en el
resto de elementos a comentar del presente apartado, las opciones de configuracin de Zookeeper son
numerosas, por lo que solo nos centraremos en las que se han considerado necesarias para parametrizar
el clster de MEDIPi. En el caso actual, se ha seguido la configuracin bsica recomendada por Apache
[64]:
Parmetro Valor Descripcin
Puerto para la comunicacin con los brokers

clientPort 2181 (valor por defecto)
u otras instancias de ZK
Directorio en el que ZK almacenar la

dataDir /tmp/Zookeeper
informacin temporal, logs, etc.
Tiempo en milisegundos de un tick, unidad

mnima de comunicacin empleada por ZK.
tickTime 2000
Empleada para regular timeouts, keep-
alives, etc.
maxClientCnxns 0 Lmite de conexiones para una misma IP
Para terminar, solo queda arrancar el nodo e indicar la ubicacin del fichero de parametrizacin:
../bin/zookeeper-server-start.sh ../config/zookeeper.properties
- Broker: sern los nodos fundamentales del clster, encargados de almacenar adecuadamente la
informacin y responder a las peticiones de los consumers que le correspondan a cada uno. Como ya se
describi con detalle el funcionamiento de los brokers de Kafka en el apartado correspondiente a las
tecnologas empleadas abordaremos aqu solo la configuracin de los nodos, partiendo de los mismos
criterios expuestos para el Zookeeper y basndonos en las posibilidades de parametrizacin de la
versin de Kafka empleada de acuerdo a la documentacin existente [65]:
77
Clave nica para la identificacin de un brker en el

broker.id 1
clster
Se trata de una lista separada por comas en las que

se informa de los puertos y protocolos que los
listeners PLAINTEXT://:9093
brokers ponen a disposicin de producers y
consumers para el envo de informacin.
Nmero de particiones por defecto para cada topic.

Este valor influye, como ya hemos visto en la teora
num.partitions 2
de Kafka, en la capacidad del clster para balancear
la carga entre nodos
Tiempo mnimo de vida de un fichero de log antes

de ser marcado como eliminable. Se opta por un
valor poco elevado, para evitar que la gran cantidad
log.retention.hours 8 de ocupacin movida por las constantes del
paciente pueda provocar un elevado consumo de
espacio en las mquinas donde se ubiquen los
nodos del clster de MEDIPi
zookeeper.connect localhost:2181 IP del nodo Zookeeper al que se conectar
Al igual que ocurre con los nodos Zookeeper, iniciamos un servidor con la siguiente instruccin
../bin/kafka-server-start.sh ../config/server_0.properties
5.4.2 Topics
En la tecnologa Kafka denominamos Topic a una categora, canal u agrupacin de mensajes para los que se
emplea una parametrizacin comn. Es decir, un topic no es ms que una manera de etiquetar mensajes,
agrupndolos en un mismo canal. Gracias a esta estructuracin, un consumidor puede suscribirse a un topic y
acceder solo a los mensajes o paquetes de informacin ubicados bajo una determinada etiqueta. Sin embargo,
esta separacin no tiene efectos solamente en el mbito lgico o funcional, sino tambin en el tcnico, pues cada
topic puede parametrizarse de manera independiente.
Abordemos en primer lugar los distintos topics que manejaremos en el presente proyecto:
Topic Descripcin
Constantes discretas de los diferentes usuarios de cualquier instancia del

LFConstantInfoTopic
software DDA.
HFConstantInfoTopic Constantes continuas de los pacientes recuperadas por DDA.
Esta divisin es fundamental, pues separamos dos tipos de datos clnicos que tienen caractersticas diferentes.
El gran caudal de datos que generan las seales continuas puede provocar un tratamiento diferenciado de las
seales discretas, tal y como hemos comentado ya en varias ocasiones. En nuestro caso, por ejemplo, se ha
implementado un modelo de base de datos enfocado solo a las variables biomdicas del primer tipo, pues se ha
mostrado como escasamente relevante en un primer nivel clnico las formas de ondas pasadas de los pacientes.
Sin embargo, habr muchos otros mbitos, entre ellos el diagnstico mdico en situaciones especficas o posibles
78
estudios y anlisis complejos en los que sern de gran inters. Por tanto, al establecer esta separacin permitimos
que las aplicaciones de MEDIPi se nutran de uno, otro o ambos segn sea necesario para el desarrollo de su
labor concreta. A lo anterior debemos sumar las ventajas en el tratamiento de datos que esta separacin conlleva:
la cantidad de informacin que se mueve en el topic dedicado a las formas de onda, variables continuas o a
tiempo real (trminos poco precisos como mnimo) es muy superior a la de las constantes discretas, por lo que
si ambos tipos de informacin convivieran en un mismo canal la explotacin de las constantes discretas debera
pasar siempre por un proceso de filtrado, ralentizando el proceso que se pretenda llevar a cabo.
Adems de definir funcionalmente qu tipo de informacin viaja agrupada bajo cada Topic, se ha de detallar la
parametrizacin bsica de cada uno. Se ha comentado al principio del presente apartado que cada topic permite
aplicar una configuracin especfica y en este caso la existencia de dos tipos de informacin con algunas
caractersticas importantes diferenciadoras nos obliga a establecer algunos matices entre sus parametrizaciones.
En este momento describiremos solamente los parmetros a abordar, dejando los valores concretos para
apartados ulteriores.
Parmetro Descripcin
El nmero de particiones especifica en cuntas partes de dividir un topic. Es

importante entender que cada particin se ubicar completamente en un solo servidor,
partitions de forma que la cantidad de particiones impactar en la capacidad de paralelismo. Por
tanto, podemos dividir un topic en ms particiones que nodos existentes, pero no podr
repartirse la carga en ms nodos que nmeros de particiones.
Controla cuantos servidores (nodos brokers) replicarn cada mensaje escrito. Salvo
casos muy bsicos es imprescindible que haya al menos 2 servidores, no solo para que
exista redundancia y tolerancia a fallos, si no para poder manejar transparentemente
los servidores implicados. Es decir, si solo tenemos un nodo cada vez que se necesite
replication-factor
realizar una labor de mantenimiento en este se deber parar, aunque sea
momentneamente todo flujo de datos, mientras que la existencia de varios nodos
permite ir moviendo uno a uno los servidores de un nodo a otro de forma totalmente
transparente y sin interrumpir la comunicacin con consumers y producers.
La configuracin puede volverse mucho ms compleja, permitiendo modificar un amplio abanico de parmetros,
tal y como se especifican en la documentacin oficial [66].
Antes de finalizar comentemos las instrucciones empleadas para el manejo de los topics:
../bin/kafka-topics.sh --create --Zookeeper 127.0.0.1:2181 --replication-
factor 2 --partitions 1 --topic LFConstantInfoTopic
../bin/kafka-topics.sh --alter --Zookeeper 127.0.0.1:2181 --partitions 2
--topic LFConstantInfoTopic
../bin/kafka-topics.sh --delete --Zookeeper 127.0.0.1:2181 --topic
LFConstantInfoTopic
Como observamos, aqu no existe ningn fichero de configuracin como ocurra en los Zookeepers o en los
Brokers, si no que los distintos parmetros y sus valores se comunican en la creacin / edicin del topic
pasndose como argumentos de entrada al binario de Kafka encargado de tales labores. Se observa que la
frmula empleada es la habitual en el trabajo con cualquier programa mediante lnea de comandos: se especifica
el parmetro precedido por un doble guion y, a continuacin, el valor que se quiere indicar.
79
5.4.3 DTOs
Ya prcticamente tenemos definida la totalidad de elementos bsicos que compondrn nuestro clster, a la espera
de tratar un poco ms adelante la configuracin de producers y consumers. Solo nos queda comentar qu
informacin enviaremos y cul ser el mtodo que emplearemos para codificarla.
Con respecto al primer punto, se han definido dos objetos de transferencia de datos (DTO), uno para cada topic,
ya que no se intercambia exactamente la misma informacin por ambos canales.
LFConstantInfo HFConstantInfo
Tipo Atributo Tipo Atributo
Long constantId Long constantId
Long episodeId Long episodeId
Date constantDate Date startDate
String value String[] value
Float period
Boolean manual Boolean manual
Como se observa, hay pocas diferencias entre ambos objetos, ms all del campo periodo para indicar el tiempo
en milisegundos que separan a cada muestra del array de valores. Se ha optado por emplear en el intercambio
de informacin un objeto especfico, pudiendo haberse empleado una instancia de CONSTANT_INFO para el
topic de informacin a baja frecuencia y una versin adaptada del mismo para el HFConstantInfoTopic. La
opcin tomada permite enviar solo la cantidad de informacin realmente necesaria, de forma que el resto de
datos que deben conocerse para poder formar un registro de ConstantInfo pueden deducirse u obtenerse
mediante una consulta a base de datos. Con esta medida se reduce la cantidad de informacin que se intercambia
por el clster, permite a un nodo almacenar ms mensajes con el mismo espacio y, sobretodo, permite a
cualquiera acceder a la informacin sin necesidad de conocer el modelo de datos de MEDIPi. Este ltimo punto
es muy interesante en nuestra bsqueda de gran modularidad: un nuevo mdulo podra, aunque sera poco
probable, no necesitar conectarse bajo ninguna circunstancia a la base de datos, por lo que le bastara con la
informacin consumida de Kafka para trabajar. Por otro lado, si enviramos un objeto correspondiente
totalmente a un registro de CONSTANT_INFO facilitaramos la tarea del mdulo Saver, que solo tendra que
realizar un insert o update. Tomndose en consideracin ambos puntos de vista se ha optado por optimizar la
informacin transmitida, aunque eso implique que Saver deba realizar algunas acciones ms antes de almacenar
una constante en base de datos. Es preferible apostar por un modelo flexible que tomar decisiones que solo
beneficien a una aplicacin de la suite.
Una vez conocido el DTO es necesario analizar qu alternativas existen a la hora de transmitirlo o codificarlo
para su emisin por el clster. Gran parte de esta labor se ha realizado cuando se ha comparado el formato de
texto JSON con otras posibilidades en el captulo destinado a las tecnologas empleadas en el proyecto, pero aun
as conviene comentar aqu algunos datos importantes:
{"constantName":" Frecuencia cardiaca

","constantId":1,"episodeId":1,"constantDate":"May 26, 2016 1:27:24
PM","value":"90.89457584984491","manual":false}
El prrafo anterior supone una muestra concreta de un valor para la constante vital de un paciente de prueba. Si
80
observamos con atencin es fcil deducir que se trata de una representacin determinada del DTO
LFConstantInfo definido unas lneas ms arriba. El objeto Java definido con los atributos ya comentados se
transforma en un texto que sigue el esquema
nombreAtributoUno:valorUno,nombreAtributoDos:ValorDos, de acuerdo al formato JSON. Gracias a
l, o mejor dicho a una determinada librera que implementa ese formato en Java) podemos transmitir un texto
plano que apenas llegar a pesar 1KB, una cantidad irrisoria para lo que un clster de nodos Kafka es capaz de
manejar.
5.4.4 Modelo
Una vez detallados los tipos de nodos, su funcionalidad y su parametrizacin bsica ya podemos intuir algunas
caractersticas bsicas del clster de MEDIPi. A lo deducido anteriormente debemos aadir una reflexin
fundamental: la dimensin que deber tener el clster, algo que nos indicar el nmero de nodos y servidores de
un tipo u otro que deberemos manejar. Aqu nos encontramos ante un evidente dilema: no podemos seguir
realizando un estudio general como hasta ahora, en el que indicbamos las caractersticas de la solucin
diseada ignorando casi por completo el nmero de usuarios implicados, concurrencia, cantidad de datos a
manejar, etc. En resumen, por cada implantacin posible de la solucin habr que realizar un pequeo estudio
acerca de la cantidad de informacin que se va a procesar, importancia de los datos, necesidad de redundancia
y control de errores, etc.; no pudiendo establecerse un modelo genrico para todos los casos. Aun as, con objeto
de clarificar cmo debe ser un clster de MEDIPi se aborda un modelo mnimo, de acuerdo a unas nociones
concretas adquiridas tanto por la prctica como por el anlisis inicial de los actores implicados.
Como se coment adecuadamente en el apartado dedicado a la teora de la tecnologa empleada, un clster Kafka
mantiene un log particionado por cada topic, de forma que estas1 particiones son distribuidas a travs de los
diferentes brokers. Nmero de particiones y parametrizacin de los mimos estn, como ya hemos visto en el
punto anterior, ntimamente relacionados con la capacidad de paralelismo del clster.
Figura 5-16. Modelo del clster
81
Con la figura superior se pretende escenificar la arquitectura del modelo mnimo propuesto en el presente
proyecto:
- Servidores: 1 nodo Zookeeper y 2 nodos brokers, servidores para el balance de carga
- Topics: los dos topics indicados, ambos con factor de replicacin 2 (existen 2 servidores). Para el topic
de las constantes discretas se ha optado por dos particiones, mientras que se ampla a una tercera en el
caso del topic para las constantes biomdicas continuas de los pacientes.
En el esquema se pretende escenificar el control que los brokers realizan de las particiones mediante un resaltado
en negrita. Este aspecto no pertenece al mbito del usuario, si no que forma parte de las tareas de balanceo de la
tecnologa Kafka elegir qu nodo maneja qu particin partiendo de la configuracin proporcionada y el
algoritmo del protocolo. Para conocer cul es el balanceo real de un topic podemos ejecutar la siguiente
instruccin de Kafka:
../bin/kafka-topics.sh --describe --Zookeeper localhost:2181 --topic
LFConstantInfoTopic
Topic:LFConstantInfoTopic PartitionCount: 2 ReplicationFactor:2 Configs:
Topic: LFConstantInfoTopic Partition: 0 Leader: 1 Replicas: 1,0 Isr:
1,0
Topic: LFConstantInfoTopic Partition: 1 Leader: 0 Replicas: 0,1 Isr:
0,1
Donde observamos, para cada particin del topic:

- Quin es el lder de cada particin, responsable de las lecturas / escrituras de dicha particin.
- Lista de nodos que replicarn la particin, independientemente de que sean el lder o no.
- Nodos actualmente disponibles de la lista de nodos replicas.
5.4.5 Producers
Sabemos que un Producer es cada uno de los escritores de un Topic, es decir, son los actores que representan
la entrada de informacin en un topic determinado. Si volvemos al esquema del modelo de arquitectura que se
ha definido para la suite software de MEDIPi observamos que solo se ha definido un elemento que realice este
rol: el mdulo de adquisicin de datos de biodispositivos DDA.
A partir de aqu vamos a comenzar una nueva parte del sistema de intercambio de informacin, salindonos del
clster en s mismo, por lo que dejamos de trabajar con la lnea de comandos arrancando servidores, indicando
ficheros de configuracin, pasando parmetros al ejecutable, etc. Como producers (y tambin consumers) se
manejarn desde el cdigo de los mdulos emplearemos la implementacin Java de Kafka para tales labores.
En este apartado vamos a detallar el proceso que seguimos en el cdigo para la correcta creacin y configuracin
de un producer, as como las instrucciones empleadas en el envo de constantes biomdicas al clster. Ms
adelante, cuando detallemos el software de los mdulos implicados, veremos cmo determinados aspectos de
diseo y programacin del cdigo se relacionan con el producer (clase Java que lo llama, estructura dentro de la
aplicacin, ubicacin de los valores, etc.)
Siguiendo la misma estructura que en puntos anteriores, comenzamos abordando las distintas opciones de
parametrizacin posibles y justificando los valores empleados:
82
Lista de ips:puertos empleada para la

comunicacin inicial con el clster Kafka.
Mediante estos datos se iniciar el primer
Server0Ip:port, intercambio de informacin con algunos de
bootstrap.servers los brokers indicados. Una vez realizada la
Server1Ip:port, comunicacin inicial se accede a los nodos
reales del clster (que pueden modificarse
dinmicamente) y esta informacin deja de
usarse.
org.apache.kafka.common. Clase serializadora para la clave. En

key.serializer nuestro caso la clave ser un numrico de
serialization.LongSerializer tipo long.
org.apache.kafka.common. Clase serializadora para el valor. En nuestro

value.serializer
serialization.StringSerializer caso intercambiamos texto plano.
Nmero de acks que necesita recibir el

producer antes de enviar los datos al
clster:
0: no se espera ningn ack, el mensaje se
enva inmediatamente por el socket y se
acks 1 considera enviado
1: se espera a que al menos el nodo brker
lder la particin implicada devuelva ack
All: se espera a que todos los nodos que
trabajen con la particin (lderes y
seguidores) enven su consentimiento.
Nmero de bytes que el producer

buffer.memory 33554432 mantendr en su buffer a la espera de ser
enviados al servidor.
retries 1 Nmero de reintentos
El producer agrupar en un batch los

mensajes o records antes de enviarlos al
servidor. Este parmetro especifica el
linger.ms 1000
tiempo a esperar entre cada envo,
agrupando durante ese periodo todos los
records recibidos.
Tamao mximo del batch. Se producir un

envo siempre que se alcance este valor
mximo para el batch, independientemente
del retraso indicado en el linger.ms. Se
combina con el parmetro anterior para
batch.size 102400
definir una poltica que oscile entre valores
que permitan una escritura/lectura casi a
tiempo real y la optimizacin del nmero
de peticiones/respuestas intercambiadas
con los servidores.
83
Timeout de la operacin realizada en el

metadata.fetch.timeout.ms 500
intercambio del primer mensaje al topic
timeout.ms 1000 Timeout del ack del servidor
El cdigo que debe tratar el arranque de un Producer de la tecnologa Kafka comenzar siempre por la gestin
de la parametrizacin; en nuestro caso, informando al producer de la configuracin arriba detallada:
Properties props = new Properties();

props.put("bootstrap.servers", "localhost:9093, localhost:9094");
La frmula diseada por Kafka para dotar de la adecuada configuracin a sus Producers Java consiste en la
instanciacin de un objeto Properties (java.util) al que seteamos, como si de un simple mapa se tratase, una
pareja nombre -valor por cada parmetro que deseamos indicar. De esta manera podemos arrancar varios
Producers con igual configuracin a partir del mismo objeto, tal y como observamos a continuacin. Adems
de informar a la nueva instancia de Producer creado de su parametrizacin indicamos los tipos de clave
(primer tipo) y valor (segundo tipo) que deber manejar.
Producer<Long, String> producer = new KafkaProducer<Long, String>(props);

Gson gson = new Gson();
String msg = gson.toJson(constantInfo);
ProducerRecord<Long, String> producerRecord = new ProducerRecord<Long,
String>(AppConstants.KAFKA_TOPIC_CONSTANTINFO, msg);
producer.send(producerRecord);
En este segundo bloque se realiza la conversin al formato de intercambio. La librera Gson empleada nos
permite crear rpidamente un texto que represente, de acuerdo al estndar JSON, un objeto Java recibido. En
este caso le pasamos una instancia de tipo ConstantInfo (la cual no es ms que el mapeo de la entidad
correspondiente de Base de Datos) y nos construye un String con los atributos del objeto y sus valores. Gson
tambin puede ser configurada, pues puede no existir una representacin nica de un valor baja determinadas
circunstancias. Por ejemplo, podemos tomar la decisin de representar los valores sin informar (null) como una
cadena de texto null, o una cadena vaca.
Una vez terminada la conversin, creamos un mensaje, lo que en Kafka se conoce como un Record o
ProducerRecord, indicando simplemente topic, clave y mensaje. Parmonos un momento a analizar las
posibilidades de instanciar una clase ProducerRecord. El constructor de la clase ProducerRecord puede recibir
los siguientes parmetros:
A) Topic - Value B) Topic Partition_Id - Value
C) Topic Key - Value D) Topic Partition_Id Key - Value
Topic y value (el mensaje a transmitir) son los nicos parmetros constantes. El resto de posibilidades no son
ms que la combinacin de la posibilidad de incluir la clave del mensaje y un identificador de la particin a la
que queremos enviar el mensaje. En el captulo de teora de Kafka del presente proyecto se ha documentado la
importancia de las claves y las particiones. Como bien se ha explicado, debatir la necesidad de informar de una
clave anexa al mensaje implica necesariamente debatir qu modo queremos emplear para el envo de
informacin. Para ello realizaremos una doble clasificacin:
84
Clasificacin 1: Modos
- Modo clsico: los brokers manejarn particiones compuestas por los distintos records. Formarn una
cola de mensajes.
- Modo compacto: se emplea una determinada configuracin de los brokers implicados que nos permite
almacenar solo el ltimo valor asociado a una clave. Podra entenderse como un mapa clave-valor a
gran escala.
Clasificacin 2: Orden
- Sin orden: Kafka no realizar acciones especiales para intentar mantener el orden correcto en los
mensajes de un topic. El almacenamiento en el log es FIFO, los datos ms antiguos sern los primeros
en ser eliminados del log. Sin embargo, la distribucin de records entre particiones, as como otros
factores menores pueden provocar un desordenamiento de la informacin. Solo la informacin
gestionada por una misma particin se mantiene ordenada.
- Con orden: todos los mensajes pertenecientes a un determinado grupo o categora se manejarn en orden
de llegada. Es importante entender que no se puede hablar de un estricto orden temporal: somos
conscientes de la existencia de los ya comentados batch en los producers, que agrupan records antes
de ser enviados al brker. Por tanto, pueden producirse alteraciones del orde1n en situaciones de
mltiples producers.
De lo anterior se deduce que enviar mensajes controlando la particin destino (opciones B y D) nos permite
garantizar en gran medida el ordenamiento temporal de los records en el log. De igual forma, los mensajes que
comparten clave son gestionados por la misma particin, ya sea mediante el modo clsico o eliminando las
duplicidades para crear un log compacto. Con todo esto sobre la mesa nos preguntamos qu categoras deben
aplicar en nuestra situacin: est claro que no necesitamos emular ningn mapa, la informacin enviada por
alguno de los topics deber ser leda en orden de entrada, sin ningn tratamiento especfico. Adems, nos interesa
mantener un orden temporal, pero no es necesario que este sea totalmente estricto, pues las aplicaciones que leen
del clster directamente emplean la fecha (presente en el value) para realizar el tratamiento que deseen a los
datos recibidos. Este asunto puede provocar algn malentendido: Kafka es una aplicacin diseada para manejar
gran cantidad de datos a tiempo real, por lo que siempre pone el foco en mantener un correcto ordenamiento
temporal de los mensajes intercambiados. El uso de tcnicas o parmetros que intentan reducir al mnimo la
posibilidad de desrdenes es interesante pero desproporcionada para el proyecto actual, en tanto que implican
limitar otras capacidades de la tecnologa, como por ejemplo la disminucin del balanceo entre brokers que se
produce al forzar manualmente una misma particin. Por tanto, lo ms conveniente es optar por el constructor
A, que emparejamos con el modo clsico sin orden temporal estricto.
5.4.6 Consumers
Un consumer es un lector de la informacin almacenada en el clster. En el caso de la suite software de
MEDIPi observamos que tenemos dos aplicaciones que debern ser consumidoras del clster: Saver y Chart.
Una vez ms trabajaremos aqu con la implementacin java de Kafka.
Al tratar con dos consumers claramente diferenciados vamos a abordar la parametrizacin para cada uno de
ellos, aunque la mayor parte de la configuracin sea comn.
Parmetro Saver Chart Descripcin
saverGroup [No informado] Identificador del grupo de consumers. La

(Cada ejecucin pertenencia a un grupo de consumers afecta
group.id (Se producir
de Chart recibir a la recepcin de datos.
balanceo de
mensajes entre los mismos datos) Un record solo se enva a un consumer de
85
las instancias de un grupo, permitiendo de esta manera

saver) balancear la carga entre los consumers.
Lista de ips:puertos empleada para la

comunicacin inicial con el clster Kafka.
Mediante estos datos se iniciar el primer
intercambio de informacin con algunos de
bootstrap.servers Server0Ip:port,Server1Ip:port, los brokers indicados. Una vez realizada la
comunicacin inicial se accede a los nodos
reales del clster (que pueden modificarse
dinmicamente) y esta informacin deja de
usarse.
org.apache.kafka.common. Clase deserializadora para la clave. En

key.deserializer nuestro caso la clave ser un numrico de
serialization.LongDeserializer tipo long.
org.apache.kafka.common. Clase deserializadora para el valor. En

value.deserializer
serialization.StringDeserializer nuestro caso intercambiamos texto plano.
Poltica a emplear en la inicializacin del

offset en la primera peticin o cuando haga
referencia a un valor incorrecto:
auto.offset.reset earliest latest
- Earliest: primer mensaje del log
- Latest: ltimo record en el log.
Mdulo LFConstantInfoTopic RealTimeLFConstantInfoTopic
Saver S NO
Chart S S
La configuracin de los dos consumers de Chart (uno para cada topic) es similar.
La parametrizacin comn no requiere ms detalles de los ya comentados, pero si es conveniente analizar con
mayor finura las decisiones detrs de las diferencias de configuracin entre nuestros dos mdulos, pues radican
en las distintas funcionalidades de los mdulos y nos permiten comprender algunos aspectos ms de Kafka.
Como ya sabemos de sobra, Saver es el mdulo encargado de consumir del clster los datos biomdicos para,
tras un filtrado bsico, almacenarnos en una base de datos. Por su parte, Chart recibe los valores actuales de
parmetros vitales de un paciente y nos muestra una grfica a tiempo real de los mismos. Las caractersticas de
ambos sistemas son diferentes, pero podemos simplificar sus diferencias en una sola frase: Saver necesita todos
las constantes mdicas, presentes y pasadas, para poder almacenarlas adecuadamente; mientras que Chart solo
emplear las ltimas. Esta es la idea que est detrs de la heterognea configuracin.
Para Saver emplearemos el group.id, una tcnica de Kafka que permite balancear los records que sern
procesados entre los distintos consumers de un grupo. De esta manera, podemos arrancar varias instancias de
Saver en distintas mquinas que se encarguen, en paralelo, del almacenaje en base de datos de la formacin.
Adems, no queremos dejar ningn dato sin procesar, por lo que cuando se arranque una instancia de Saver se
buscar el primer mensaje del log, procesando el resto a partir de l. Se debe tener cuidado con esta
configuracin, si el log abarca mucha informacin se reprocesarn una gran cantidad de mensajes. En nuestro
caso hemos puesto un periodo de backup o de retencin en los logs bastante corto y contamos con que
podemos arrancar varias instancias en paralelo que agilicen el procesado de todos los datos desde el primero.
86
Adems, estamos hablando del topic ConstantInfo, el que menos volumen de bytes mueve. Eso s, si alguna de
las condiciones comentadas en este prrafo cambiara debera replantearse esta parametrizacin.

props.put("bootstrap.servers", "localhost:9093, localhost:9094");
...
KafkaConsumer<Long, String> constantInfoConsumer = new
KafkaConsumer<>(props);
constantInfoConsumer.subscribe(Arrays.asList(AppConstants.KAFKA_TOPIC_CONSTAN
TINFO));
ConsumerRecords<Long, String> records =
constantInfoConsumer.poll(SaverConstants.KAFKA_POLL_TS);
for (ConsumerRecord<Long, String> record : records) {
DataWriterManager.writeConstantInfoToAll(gson.fromJson(record.value(),
ConstantInfo.class));
}
En las lneas superiores tenemos las instrucciones que se emplean, grosso modo, en ambos mdulos para
instanciar un consumer a travs de la API Java de Kafka. Al igual que ocurra con los producers, comenzamos
indicando los parmetros y sus valores, e instanciando un KafkaConsumer y pasndolo el objeto Properties que
contiene la configuracin. Tras suscribirse al topic del que deseamos recibir mensajes se realiza un poll. Con un
poll estamos realizando una peticin al clster para recibir un array de records, indicando como parmetro de la
operacin el tiempo que se debe esperar mientras no hay datos disponibles. Si el clster dispone de un nuevo
record antes de que se cumpla ese plazo se termina la accin devolvindoselo; mientras que si se cumple el
timeout sin tener ningn mensaje disponible se termine la espera devolviendo un array vaco de records. En
nuestro caso lo hemos establecido en 1000 milisegundos. Ya podemos recorrer el array de records recibidos
(ConsumerRecords) y traducir el mensaje enviado mediante JSON de cada ConsumerRecord a un objeto Java
del tipo que corresponda segn el topic del que proviene.
Set<TopicPartition> topics = constantInfoConsumer.assignment();

topics.forEach(partition -> constantInfoConsumer. seekToBeginning (partition,
record.offset()));
Las lneas de cdigo superiores no se corresponden directamente con ninguna parte de los desarrollos, pero nos
ayudan a explicar algunos conceptos con los que hemos trabajado. As vemos como podemos recuperar las
particiones de un topic mediante la primera instruccin y trabajar con ellas. Podemos indicar mediante el mtodo
seek el offset a partir del cual queremos leer. En el parmetro auto.offset.reset indicamos por donde comenzar a
leer tras arrancar un consumer, mientras que estas instrucciones permiten muchas ms opciones, pues podemos
invocar un seek a un punto determinado del log en varias partes del cdigo. Por ejemplo, podramos tener inters
en reprocesar determinados mensajes bajo algunas circunstancias de manera dinmica gracias a estas
instrucciones.
Con toda esta informacin ya conocemos qu sistema de intercambio de informacin vamos a implementar, su
modelo y arquitectura concreta, as como el conjunto de instrucciones que deberemos emplear para iniciar y
configurar de acuerdo a nuestras necesidades cada uno de los elementos que lo componen. Con esta informacin
es el momento de abordar el resto de elementos software del presente proyecto.
87
Componentes software
Nos embarcamos ahora en la parte central del proyecto. A lo largo del actual captulo ya hemos comentado que
la parte software del proyecto estar compuesta por tres aplicaciones independientes enfocadas a tareas distintas.
Nombre del mdulo Icono Descripcin
Device Data
Componente software encargado de establecer la
Acquisition comunicacin con los biodispositivos y recuperar la
DDA
Mdulo que persistir la informacin recopilada por

SAVER
DDA en base de datos
Aplicacin de visualizacin de las constantes

CHART
biomdicas de los pacientes en tiempo real.
5.5.1 Estructura del software del proyecto

Las tres aplicaciones se van a comportar como mdulos independientes, de forma que cada uno puede ejecutarse
en una mquina completa, aunque habr muchos elementos en comn. Por tanto, es lgico pensar que tendremos
tres proyectos diferentes que se sustenten en un cuarto proyecto comn que aglutine las utilidades o
dependencias empleadas por todos los mdulos. Adems, en el captulo anterior hemos realizado una
comparativa entre las distintas opciones existentes para manejar las comunicaciones con la base de datos,
eligiendo finalmente emplear JPA (Java Persistence Api) con Hibernate como implementacin. Ya que el
estndar JPA implica definir clases java que mapeen las tablas del modelo de base de datos parece evidente que
todas las clases formen parte de ese proyecto comn que los tres mdulos emplearn.
Durante el apartado dedicado a la base de datos se ha establecido un modelo de datos compuesto por dos
esquemas: uno especfico de la adquisicin de datos DATA_ACQ y otro genrico de cualquier software del
mbito sanitario denominado HEALTH. Durante la explicacin del diseo se ha hecho especial hincapi en que
el esquema HEALTH sea independientemente, de forma que si se construye un mdulo que no trabaje con la
informacin almacenada en las tablas del esquema de adquisicin de datos no sea necesario, en este caso,
importar las clases java que construyan su mapeo de datos. Por tanto, sera ahora incoherente no crear dos
libreras diferenciadas. En esta lnea vamos a ir un paso ms all, llevando a una tercera librera toda la lgica
comn de nuestro uso de JPA (clases abstractas, mtodos tiles empleados por todas las aplicaciones que quieren
acceder a base de datos, patrones de acceso que debern emplearse, etc.). Conforme avancemos y vayamos
tratando el contenido de cada una de estas libreras se ir comentando con mayor detalle porqu es ms correcta,
funcional y tcnicamente, la estructura escogida frente a otras.
88
Figura 5-17. Estructura de Proyectos DOM (Document Object Model) (Base de datos)
En el prrafo anterior hemos tratado las libreras que van a proporcionar acceso a la base de datos a todos los
mdulos o aplicaciones que as lo deseen. Parece lgico realizar una tarea similar con el acceso al sistema de
intercambio de informacin, al clster Kafka. Por tanto, contaremos con otra librera que agrupe la lgica comn
de acceso a los consumers y producers de Kafka empleados, el modelo de datos de los objetos empleados, las
libreras Java especficas para tales labores, etc. Las aplicaciones que deseen trabajar con Kafka (actualmente
las tres diseadas) debern importar esta librera. Gracias a esto se evita duplicar cdigo: no es necesario que en
2 aplicaciones se haga la misma accin (instanciar un consumer de Kafka, subscribirse al topic, arrancar un hilo
para leer datos, etc.) si no que toda esta informacin est centralizada en una nica librera evitando duplicidades.
Sin embargo, es fcil imaginar un mdulo de MEDIPi que no necesite acceso al clster. Por ejemplo, se puede
crear una aplicacin de gestin de la historia clnica de un paciente que tenga ms que suficiente con la
informacin biomdica almacenada en la base de datos. En ese caso no ser necesario importar esta librera,
evitando cargar con clases intiles.
Figura 5-18. Estructura de Proyectos Cluster (Kafka)
A pesar de todo lo descrito hasta el momento, todava es posible encontrarnos con elementos duplicados y lgica
repetida entre las tres aplicaciones descritas (DDA, Saver y Chart). Se trata de la gestin de Logs, properties,
constantes comunes, mtodos Java implementados que son tiles para el tratamiento de la informacin
biomdica en ms de un mbito, etc. Para evitar esto, concluimos la modularizacin de la suite definiendo una
nueva librera que agrupa lgica comn para varias de las aplicaciones o mdulos de MEDIPi.
Figura 5-19. Estructura de Proyectos App (Elementos comunes de aplicaciones MEDIPi)
Una vez conocidos los tres grupos funcionales en los que se han divido las libreras diseadas para la suite
MEDIPi es el momento de plantear como ser la relacin entre los tres mdulos (DDA, SAVER y CHART) y
cada una de ellas.
89
Figura 5-20. Estructura de Proyectos MEDIPi. Representacin grfica.
Con el objetivo de clarificar la arquitectura software diseada se han empleado un conjunto de normas y cdigos
de colores que se procede a explicar a continuacin:
- Los rectngulos con bordes discontnuos representan elementos que son exclusivamente proyectos
Maven; es decir, indican que un determinado proyecto actua slamente como padre de un conjunto de
hijos, sin tener cdigo Java asociado. Por tanto, las lneas que van de un proyecto de este tipo a un
componente buscan indicar una relacin padre-hijo.
- Los rectngulos de lnea contnua representan proyectos Maven y Java. Sern hijos de proyectos padres
exclusivamente Maven. Adems, se representarn las depenencias con otros proyectos de la suite
mediante una lnea contnua.
- Las libreras MEDIPi-DOM se representan en naranja. Sern todas aquellas que contengan clases,
mtodos u objetos relacionados con el acceso a la base de datos.
- Las libreras MEDIPi-Cluster se representan en verde. Bajo esta categora clasificamos toda librera que
agrupe funcionalidad relacionada con el acceso y gestin del Cluster Kafka.
90
- Las libreras MEDIPi-App se representa en azul. Todo proyecto que contenga bien un mdulo de
MEDIPi, bien una librera de utilidades para las aplicaciones se incluir en este grupo.
- Toda aplicacin o librera de la suite se sustenta en una serie de convenciones o elementos bsicos. Para
el acceso a base de datos estos se encuentran en core_dom, mientras que para la comunicacin con el
clster se ubican en core_cluster. Por tanto, las libreras cuya denominacin empieza por core- se
consideran fundamentales: todo proyecto o librera de una categora se debe sustentar sobre la clase
core correspondiente de su sector.
No conviene olvidar la clasificacin realizada, pues no solo se trata de una categorizacin funcional, sino que
tambin tiene implicaciones tcnicas, tal y como veremos un poco ms adelante.
Para poder trabajar con tantas libreras y proyectos relacionados entre s se emplea la herramienta de Apache
conocida como Maven, adecuadamente documentada en secciones previas de esta memoria. La especialidad de
maven es la gestin de dependencias, un autntico quebradero de cabeza en una suite de productos como la aqu
diseada Es evidente que no solo debemos lidiar con que muchos proyectos compartan dependencias (sobre
todo los que pertenecen a una misma categora) sino tambin con la existencia de dependencias internas dentro
de la suite. A todo lo anterior Apache suma varias utilidades ya comentadas: gestin de javadoc, compilacin
del proyecto en el jar correspondiente, filtrado de recursos, etc. Por tanto, conforme se avance en la descripcin
de los distintos proyectos, junto al detalle del cdigo empleado se ir comentando la configuracin de Maven
escogida.
Figura 5-21. Estructura de Proyectos MEDIPi. Representacin en carpetas
91
5.5.2 MEDIPI Suite

En la imagen con la que se cerraba el punto anterior se puede observar la estructura de carpetas del cdigo actual
de la suite MEDIPi. Los diferentes proyectos se agrupan bajo un directorio con el nombre de la categora
correspondiente, incluyendo un archivo de Maven pom.xml para gestionar la parametrizacin comn. En el
primer nivel se observa que, adems de los directorios de las distintas categoras, existe un fichero pom.xml. Su
contenido es el siguiente.
<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>medipi</groupId>
<artifactId>medipi-suite</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<modules>
<module>medipi-dom</module>
<module>medipi-Cluster</module>
<module>medipi-app</module>
</modules>
<properties>
<JAVA_1_8_HOME>C:\Program Files\Java\jdk1.8.0_65</JAVA_1_8_HOME>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
</plugin>
<plugin>
<artifactId>maven-source-plugin</artifactId>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
<encoding>UTF-8</encoding>
<executable>${JAVA_1_8_HOME}/bin/javac</executable>
<fork>true</fork>
</configuration>
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<configuration>
92
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<plugin>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>

<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</dependency>
</dependencies>
</project>
Gracias a este pom se est definiendo un proyecto padre o proyecto general, del que colgarn todos y cada uno
de los proyectos de MEDIPi. Dicha definicin se encuentra al principio del fichero: se trata de un proyecto de
nombre medipi-suite, de la organizacin o grupo medipi, con versin 1.0-RELEASE y empaquetamiento
pom. Esto ltimo indica que no se trata de un proyecto java, en cuyo caso se indicara empaquetamiento jar,
war o el que correspondiera, sino de una agrupacin de proyectos de maven. La utilidad de esto es que podemos
definir una serie de caractersticas comunes a todos los hijos de este proyecto sin tener que duplicar el cdigo en
cada uno de ellos.
En la siguiente regin se observan los mdulos o hijos del proyecto: se tratan de las categoras comentadas, algo
que coincide perfectamente con el rbol de directorios mostrado ms arriba. Parece lgico entender que se va a
realizar una accin similar con cada una de ellas: cada categora tendr otro pom padre, que gestionar los
recursos o parametrizaciones Maven comunes a todas las libreras que pertenezcan al grupo.
La seccin properties indica una serie de propiedades que heredaran todos los hijos de este proyecto, tanto los
de primer nivel como los de niveles inferiores. En este caso, solo se especifica la ubicacin del JDK empleado
en la compilacin y la codificacin a emplear en los ficheros. Por tanto, gracias a este pom padre los
desarrolladores se ahorran duplicar esta informacin en el pom de cada proyecto. Adems, en ningn momento
se pierde independencia, pues cada proyecto puede compilarse independientemente siempre que se pueda
acceder a los pom superiores.
La etiqueta build agrupa un conjunto de acciones que se realizan durante la compilacin del proyecto. En este
caso, se especifica que todo proyecto de medipi deber compilarse con la versin 8 de java y los ficheros se
trataran con la codificacin UTF-8. Con el primer plugin se indica la generacin del jar clsico, mientras que
con el tercero se obliga a crear otro jar que incluya los ficheros fuente. En el captulo dedicado a la tecnologa
Maven se coment con ms detalle la utilidad de los plugins y el ciclo de trabajo de maven, pero conviene
93
repasar un par de cuestiones bsicas en este punto. Los plugin de Maven llevan a cabo una funcionalidad
especfica. Para emplearlos se indica su versin, configuracin y se asocian a una determinada meta. Maven
tiene un ciclo de funcionamiento organizado por fases (preparacin, compilacin, empaquetado, etc.), de forma
que se ejecutan de forma secuencial. Adems, cada fase se subdivide en metas o goals. Todo plugin se asocia a
una fase concreta, algunos de forma explcita (cuando se indica mediante los atributos execution) y otros
implcita (se asignan a la fase y meta por defecto).
La ltima de las secciones es la ms importante, aquella que supone el centro de Maven: la gestin de
dependencias del presente proyecto. En nuestro caso se est indicando una serie de libreras de logs que todo
proyecto de MEDIPi incorporar, debiendo usarla para informar de avances, problemas, errores, etc. Se ha
comentado anteriormente que la configuracin aqu indicada se replica para todos y cada uno de los proyectos
hijos. Por tanto, health-dom incorpora a librera de log4j especificada, as como el proyecto core-dom, que a su
vez tambin usa la citada librera. Es decir, se est produciendo una duplicidad, de forma que bajo el ahondamos
en el jar de health-dom deberamos ser capaces de encontrar dos log4j-1.2.17.jar. Sin embargo, esto no ocurre:
Maven conoce que ambos proyectos tienen un padre comn, por lo que automticamente importa solo una
librera log4j, ahorrando espacio y previniendo futuros errores. Adems, cuando especificamos una librera
Maven en el pom es posible realizar exclusiones, filtrando aquellas de sus libreras hijas que no deseamos. Toda
esta funcionalidad es la que hace de Maven una herramienta tremendamente til para proyectos tan
modularizados como el nuestro.
5.5.3 MEDIPi-DOM
Se trata de un proyecto maven que pretende agrupar los elementos comunes en la gestin y construccin de
todos los proyectos DOM de la suite MEDIPi, incluyendo dependencias compartidas y repositorios comunes.
Se observa que cada una de las tres categoras en las que se ha dividido funcionalmente los proyectos de MEDIPi
se corresponde con un proyecto maven que centraliza los parmetros de construccin compartidos por todos los
mdulos de dicha categora.

<project xmlns="http://maven.apache.org/POM/4.0.0"
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
</parent>
<artifactId>medipi-dom</artifactId>
<modules>
<module>core-dom</module>
<module>health-dom</module>
<module>datacq-dom</module>
</modules>
<repositories>

<repository>
<id>novamens</id>
<url>http://maven.novamens.com</url>
</repository>
</repositories>
94
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>com.mysema.maven</groupId>
<artifactId>apt-maven-plugin</artifactId>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>com.mysema.maven</groupId>
<artifactId>apt-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
<configuration>
<outputDirectory>target/generated-sources/java</outputDirectory>
<processor>com.querydsl.apt.jpa.JPAAnnotationProcessor</processor>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>

<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc6</artifactId>
<version>11.2.0.4.0</version>
</dependency>

<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>5.1.0.Final</version>
</dependency>
<dependency>
<artifactId>hibernate-entitymanager</artifactId>
</dependency>

<dependency>
<artifactId>hibernate-ehcache</artifactId>
</dependency>

<dependency>
<groupId>com.querydsl</groupId>
<artifactId>querydsl-jpa</artifactId>
</dependency>
<dependency>
<groupId>com.querydsl</groupId>
<artifactId>querydsl-apt</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
95
En las lneas superiores se encuentra el fichero pom.xml. Un primer vistazo nos indica que se trata de un proyecto
hijo de medipi-suite, pero a la vez padre de los proyectos dom (core-dom, health-dom y datacq-dom). Por tanto,
estos tres mdulos heredarn tanto la configuracin aqu indicada como la especificada en el pom superior.
Como hemos visto anteriormente, podemos indicar en un pom.xml las dependencias de nuestro proyecto
especificando grupo, id y versin. Con esta informacin Maven buscar primero en su repositorio local. Si no
encuentra el archivo buscado ir al repositorio central [67] para descargar el jar correspondiente al repositorio
local. Si, por cualquier razn, necesitamos utilizar libreras que no se encuentran en el repositorio central de
maven es posible especificar otros repositorios auxiliares, tal y como se ha hecho en el presente pom.
En el presente proyecto se trabaja con JPA, usando Hibernate como implementacin de dicho estndar. Junto a
este se ha optado por EhCache como herramienta de gestin de una cach de consultas integrable con
JPA/Hibernate. Adems, se emplear QueryDSL para la consulta a base de datos, dada su gran versatilidad.
Todo lo anterior ser empleado por las aplicaciones Java correspondientes para acceder a la base de datos Oracle
empleada. Observamos que las herramientas comentadas coinciden con las dependencias de todos los proyectos
dom, quedando todava solo un punto por explicar: la presencia del plugin apt-maven-plugin. Para entender su
utilidad conviene refrescar la memoria: en el captulo dedicado a las tecnologas se coment que QueryDSL se
sustenta en unos archivos denominados QClass. Una QClass (Query Class) es una clase Java que se sustenta
sobre una entidad de JPA, ofreciendo al framework QueryDSL una serie de funcionalidades para manejar las
consultas que se deseen realizan sobre dicha tabla / entidad. El plugin ANT de maven, configurado tal como se
indica arriba, permite generar automticamente las QClass de todas las entidades de nuestro modelo de datos.
Durante el proceso de compilacin / construccin, Maven buscar las clases del proyecto que contienen etiquetas
JPA y generar una QClass para cada una de ellas en el directorio destino correspondiente. Es importante
entender que todos los proyectos que contengan clases JPA debern tener dicho plugin si queremos que se
generen automticamente las QClass. Ubicar el plugin en este pom padre nos permite automatizar an ms esta
tarea, evitando tener que copiar y pegar esta configuracin en todo proyecto dom de la suite.
5.5.3.1 CORE-DOM
5.5.3.1.1 Funcionalidad de la libreria

El proyecto core-dom presenta la arquitectura bsica de comunicacin con la base de datos comn de la suite de
MEDIPi. Todo proyecto JPA requiere de la definicin de las entidades (que, grosso modo, mapean las tablas de
la base de datos), la configuracin/creacin de la conexin a la base de datos y la gestin de las transacciones.
A todo esto, le sumaremos la gestin de las diferentes cachs y la utilizacin del framework QueryDSL. A la
hora de configurar todos estos parmetros, se han tomado una serie de decisiones de diseo que generan una
metodologa de trabajo propia: todas las aplicaciones debern emplearla, de forma que se unifiquen criterios y
no se produzcan diferencias en las capas bsicas sobre las que se construyen los mdulos. Para escenificar esto
se ha desarrollado la librera core-dom, donde se agrupa toda la funcionalidad comentada.
Figura 5-22. Proyecto core-dom
96
5.5.3.1.2 Configuracion de proyecto Maven

Como todo proyecto de MEDIPi, emplearemos Maven para la gestin de la compilacin y construccin del
proyecto. En este caso se trata de uno de los proyectos ms sencillos, pues no cuenta con ninguna especificidad
sobre el proyecto padre medipi-dom, por lo que nos bastar con especificar la dependencia con el pom padre e
indicar los parmetros bsicos de definicin del proyecto.
<?xml version="1.0"?>
<project
http://maven.apache.org/xsd/maven-4.0.0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<parent>
</parent>
<artifactId>core-dom</artifactId>
<packaging>jar</packaging>
<name>core-db</name>
</project>
5.5.3.1.3 Codigo Java

Vamos a estructurar el cdigo desarrollado en core-dom en cuatro grandes bloques segn su funcionalidad:
modelo de entidades JPA, gestin de la conexin con base de datos, comunicacin con la misma y utilidades.
5.5.3.1.3.1 DOM Base

Ya se ha comentado en varias ocasiones que usar JPA (Java Persistence Api) implica un enfoque orientado a
objetos, de forma que las tablas de base de datos se mapean en objetos Java denominados entidades. Esto ofrece
una versatilidad mayor de la planteada en un primer punto: podemos utilizar muchos de los elementos de diseo
de la programacin orientada a objetos en estas clases: abstraccin, herencia, polimorfismo, etc. En nuestro caos
hemos definido un modelo de datos en el que todas las tablas tienen un conjunto de columnas o atributos
comunes.
DELETED NUMBER(1,0) 0 Indicador de borrado lgico. 1 borrado / 0 no borrado
INSERT_DATE TIMESTAMP(6) SYSDATE Fecha de creacin del registro
UPDATE_DATE TIMESTAMP(6) Fecha de ltima modificacin del registro
VERSION NUMBER(38,0) 0 Versin del registro
Toda tabla de MEDIPi tiene los atributos arriba definidos. Si realizamos una traduccin de lo anterior a
programacin orientada a objetos, puede decirse que los atributos deleted, insert_date, update_date y version
son comunes a todo objeto que mapee una tabla de base de datos. Parecera lgica crear una clase abstracta que
definiera dichos atributos, de forma que los distintos objetos la extendieran, ahorrando al desarrollador repetirlos.
Esta es precisamente una muestra de la utilidad del enfoque ORM que se ha decidido emplear.
97
@MappedSuperclass
public abstract class MedipiAbstractEntity {
@Column(name = "DELETED", nullable = false)

private boolean deleted = false;
@Column(name = "INSERT_DATE", nullable = false, length = 6)

private Date insertDate = new Date();
@Column(name = "UPDATE_DATE", length = 6)

private Date updateDate;
@Version
@Column(name = "VERSION", nullable = false, precision = 38, scale = 0)
private Long version;
// getters y setters de los atributos
Mediante la etiqueta @MappedSuperclass indicamos a JPA que la clase solamente contiene un conjunto de
mapeos entre columnas de base de datos y atributos que se aplicarn a todas las clases que la hereden, sin
constituir una entidad en s misma.
La etiqueta @Column permite indicar la correspondencia del atributo con una determinada columna de base de
datos, as como especificar otras opciones (nullable o no, precisin, escala, unicidad, etc.). Incluso se puede
realizar una definicin de la columna mediante la opcin ColumnDefinition empleando las instrucciones de
definicin de columnas de SQL. Por su parte, la etiqueta @Version indica a JPA que ese campo se est utilizando
para indicar el nmero de versin del registro. El atributo asociado ser manejado automticamente por la
implementacin de JPA, En nuestro caso, Hibernate lo inicializa en 0 y aumenta en uno su valor con cada
actualizacin sobre el registro.
Gracias al plugin de Maven configurado, siempre que se compile / construya el proyecto se genera la QClass
asociada a la entidad JPA MedipiAbstractEntity en el directorio target/generated-sources/java/paquete-de-la-
entidad. De esta parte solo nos interesa conocer qu son las QClass, como las generamos y cmo las utilizaremos
para realizar consultas. Por tanto, en este punto no hay necesidad de realizar un anlisis detallado de las QClasses
generadas, ms all de observar que cada atributo de la entidad se transforma en otro atributo de un tipo anlogo
en esta clase. Dichos tipos nos ofrecen, como se ver ms adelante, un conjunto de mtodos que nos ayudarn a
construir las consultas.
/**
* QMedipiAbstractEntity is a Querydsl query type for MedipiAbstractEntity
*/
@Generated("com.querydsl.codegen.SupertypeSerializer")
public class QMedipiAbstractEntity extends EntityPathBase<MedipiAbstractEntity> {
private static final long serialVersionUID = -925350210L;
public static final QMedipiAbstractEntity medipiAbstractEntity = new

QMedipiAbstractEntity("medipiAbstractEntity");
public final BooleanPath deleted = createBoolean("deleted");
public final DateTimePath<java.util.Date> insertDate =

createDateTime("insertDate", java.util.Date.class);
public final DateTimePath<java.util.Date> updateDate =

createDateTime("updateDate", java.util.Date.class);
public final NumberPath<Long> version = createNumber("version", Long.class);
public QMedipiAbstractEntity(String variable) {
98
super(MedipiAbstractEntity.class, forVariable(variable));
}
public QMedipiAbstractEntity(Path<? extends MedipiAbstractEntity> path) {

super(path.getType(), path.getMetadata());
}
public QMedipiAbstractEntity(PathMetadata metadata) {

super(MedipiAbstractEntity.class, metadata);
}
5.5.3.1.3.2 DBManager
El trabajo con JPA se sustenta en el objeto EntityManager, que contiene toda la informacin para crear
conexiones, manejar transiciones y otras funcionalidades de gestin de la base de datos. La creacin y
configuracin de este objeto, as como de otros puntos secundarios como la parametrizacin de la cach, se
ocupa esta seccin del cdigo de core-dom.
Para ello definimos una interfaz DBManager, con cuatro mtodos bsicos.
public interface DBManager {
/**
* Recupera el objeto EntityManager de JPA
*
* @return EntityManager
*/
EntityManager getEntityManager();
/**
* Libera el espacio reservado por la cach especificada
*
* @param cacheName
* Identificador de la cach
*/
void cleanCache(String cacheName);
/**
* Libera la conexin con la base de datos
*/
void shutdown();
/**
* Devuelve el identificador de la regin en la que se ubica la cach
* de queries
*
* @return Identificador de la cach de queries
*/
String getQueryCacheRegion();
}
Cada aplicacin manejar su propio DBManager, que implementar la interfaz anterior. Adems, hay varia
lgica comn a todas las aplicaciones que se centraliza en la siguiente clase abstracta.
public abstract class AbstractDBManager implements DBManager {
private EntityManagerFactory entityManagerFactory;

private CacheManager cacheManager;
private String queryCacheRegion;
public AbstractDBManager(String persistenceUnit, String queryCacheRegion) {
99
entityManagerFactory =
Persistence.createEntityManagerFactory(persistenceUnit);
cacheManager = CacheManager.getInstance();
setQueryCacheRegion(queryCacheRegion);
}
public EntityManager getEntityManager() {

return entityManagerFactory.createEntityManager();
}
public void cleanCache(String cacheName) {

cacheManager.getCache(cacheName).removeAll();
}
public void shutdown() {

entityManagerFactory.close();
cacheManager.shutdown();
}
public String getQueryCacheRegion() {

return queryCacheRegion;
}
private void setQueryCacheRegion(String queryCacheRegion) {

this.queryCacheRegion = queryCacheRegion;
}
}
Se observa como se define un constructor al que indicar el identificador de la persistenceUnit y el de la regin

de la regin en la que se cachearn las consultas en base de datos. Con lo anterior se instancian los objetos
bsicos: una factora de EntityManager y un CacheManager, indicndole a este ltimo cual es la regin para
cachear las consultas. Junto al constructor observamos varios mtodos bsicos: obtencin de un EntityManager,
limpieza de una cach indicada por el nombre de su regin, cierre de la conexin con base de datos (y borrado
de las cachs), getters y setters de la regin de cach para queries. La idea es centralizar todo el uso de los objetos
EntityManagerFactory y CacheManager en esta clase abstracta y en los DBManagers que extiendan de ella. Un
buen patrn de diseo implica separar funcionalidades: es altamente peligroso que se pueda alterar la conexin
a base de datos o jugar con las cachs en un punto cualquiera de una aplicacin. Cada aplicacin definir su
DBManager heredando el abstract arriba definido, de forma que proporcione solo una serie de mtodos al
exterior. En definitiva, solo en el DBManager se trabajar sobre los objetos bsicos que gestionan la base de
datos, comportndose como una caja negra para el resto de la aplicacin. La configuracin de la base de datos
se lleva a cabo a travs del fichero persistence.xml, mientras que parametrizacin de la cach la realiza
ehcache.xml. Como en este punto solo se han definido interfaces y abstract, no es necesaria la presencia de
ninguno de estos ficheros, los cuales comentaremos adecuadamente en cada una de las aplicaciones.
5.5.3.1.3.3 DAOs y Services

Aunque se ha comentado ya en captulos previos, conviene recordar en qu consiste exactamente el objeto
EntityManager. Cada vez que queramos trabajar con la base de datos se crear un nuevo EntityManager, que se
encargar de llevar a cabo las acciones que sobre l se indiquen. Una vez finalizada la tarea para la que se cre,
el EntityManager se cierra. Si en el futuro se desean realizar ms operaciones con la base de datos basta con
crear un nuevo EntityManager a travs del mtodo que proporciona el AbstractDBManager. Un objeto de tipo
EntityManager ofrece mtodos bsicos como persist, merge o remove que se corresponden con los clsicos
insert, update y delete. Sin embargo, una buena gestin de la comunicacin con la base de datos implica mucho
ms que llamar a esos mtodos en el momento adecuado. Como mnimo se debe tener en cuenta la
transaccionalidad. En muchos casos ser necesario realizar acciones mltiples sobre la base de datos, de forma
que deban ejecutarse atmicamente. Es decir, si se produjera algn error debera devolverse la base de datos al
estado previo. Surge el concepto de transaccionalidad: una transaccin es una sesin en base de datos. Todas
las acciones ejecutadas para esa transaccin forman una misma unidad de trabajo, de forma que o bien se
persisten en la base de datos conjuntamente o se rechazan todas. Un objeto EntityManager nos permite crear
transacciones, tal y como se observa en el siguiente fragmento de cdigo.
100
EntityTransaction tx = entityManager.getTransaction();
tx.begin();
try {
t.setDeleted(true);
t.setUpdateDate(new Date());
t = entityManager.merge(t);
tx.commit();
res = true;
} catch (Exception e) {
tx.rollback();
}
Toda accin realizada sobre un EntityManager tras el inicio de la transaccin es gestionada temporalmente, y
solo es persistida en base de datos cuando se confirma (commit). Gracias a esta lgica, si se produce algn error
inesperado se pueden deshacer todos los cambios realizados en esta transaccin (rollback), recuperando el estado
anterior de la base de datos.
Est claro que se debe seguir siempre una determinada estructura en el acceso a base de datos, por lo que
deberamos controlar el acceso a la base de datos en la medida de lo posible, haciendo que pase siempre por una
determinada lgica comn. Para ello se ha optado por emplear el patrn DAO [68] de acceso a la base de datos.
El patrn DAO es una opcin de diseo para aplicaciones Java EE que ofrece un conjunto de normas para
permitir un acceso estructurado a la base de datos. Consiste en crear objetos de acceso a bases de datos Data
Access Object (DAO) quienes sern los encargados de trabajar con el framework de acceso a datos del sistema,
en nuestro caso JPA, para realizar las acciones indicadas. De esta manera, una vez ms recurrimos a un patrn
de diseo que pretende modularizar la funcionalidad: un DAO se comporta tambin como una caja negra para
el resto de la aplicacin, de tal forma que si se desea modificar alguna lgica relativa a la comunicacin con base
de datos se har solo en el DAO en vez de buscar por toda la aplicacin en qu puntos se trabaja con la base de
datos y modificarlos uno a uno.
Figura 5-23. Patrn DAO en MEDIPi
En las aplicaciones de MEDIPi se ha optado por emplear el patrn DAO, con unas caractersticas propias:
- Un DAO est siempre asociado a una entidad de base de datos, de forma que un DAO solo contenga la
lgica relacionada con una tabla. Esto permite definir mtodos comunes para todos los DAOs (insert,
update, delete, etc.) pero es menos til cuando se pretenden operaciones algo ms complejas. Por
ejemplo, si realizamos una consulta que implique varias tablas esta metodologa de trabajo es menos
adecuada, pues habr que ubicar la consulta en algn DAO. En nuestro caso ubicaremos la consulta en
el DAO que se considere ms apropiado (en funcin del objeto a devolver o la tabla principal entre
todas las que intervienen).
- Los DAOs deben realizar operaciones casi exclusivamente de comunicacin con la base de datos. La
lgica de gran complejidad debe ubicarse en capas superiores.
- El patrn de diseo DAO se complementa habitualmente con los servicios. Un servicio es una capa
101
superior que realiza la lgica compleja, llamando a los DAOs que necesita para realizar las acciones
necesarias. En nuestro caso, estamos definiendo una arquitectura que permita a muchas aplicaciones
diferentes construirse sobre los elementos aqu definidos. Para facilitar esto no debemos llegar al
extremo de definir una nica metodologa de trabajo, algo que puede variar en funcin de las
necesidades de cada proyecto, solamente debemos cubrir la creacin de una estructura comn que
establezca una homogeneidad entre todos los mdulos de la suite MEDIPi.
- Partiendo del punto anterior, se define como una buena poltica no emplear directamente los DAOs en
el cdigo lgico, si no utilizar una capa ms de abstraccin. En el caso de las aplicaciones diseadas se
ha optado por generar una clase, representada en el esquema superior como
ApplicationConfigurationObject y que se corresponde con DDAConfiguration,
SaverConfiguration o ChartConfiguration segn la aplicacin, que mantiene una instancia de cada
DAO empleado, ofreciendo al exterior mtodos lgicos que llaman a los DAOs adecuados, Se tratan
de mtodos normalmente estticos que evitan tener que instanciar una clase en memoria cada vez que
se pretende usar la base de datos. Pueden verse como un servicio, comprendiendo que se trata de un
solo servicio por aplicacin y que no realizan una lgica muy compleja, ms all de la llamada al DAO
correspondiente. Es importante destacar que se ha optado por este patrn porque permite centralizar el
acceso a los DAOs, controlar el acceso multi-hilo a los mtodos y evitar instancias frecuentes de objetos
en memoria que se emplearn continuamente. En resumen, se ha considerado que esta metodologa de
servicio nico es la ms adecuada para las aplicaciones diseadas, pero no debe ser vista como una
parte bsica de la estructura diseada, ya que otros proyectos deben preparar su propia estructura
segn sus necesidades. Parece evidente que crear servicios es una buena prctica, pero el diseo de los
mismos puede variar: uno centralizado como en el caso actual, uno para cada funcionalidad / peticin,
etc.
Por tanto, en el proyecto core-dom se realiza la definicin de la estructura comn de los DAOs, creando para
ello una interfaz y una clase abstracta con la lgica comn, como es habitual.
public interface DAO<T> {

EntityManager getEntityManager();
T insert(T t);
T update(T t);
boolean delete(T t);
}
public abstract class AbstractDAO<T extends MedipiAbstractEntity> implements DAO<T> {
private static final Logger LOG = Logger.getLogger(AbstractDAO.class);

private DBManager myDBManager;
public AbstractDAO(DBManager myDBManager) {

this.myDBManager = myDBManager;
}
public EntityManager getEntityManager() {

return myDBManager.getEntityManager();
}
public void cacheQuery(JPAQuery<?> query) {

query.setHint(DBConstants.ACTIVE_QUERY_CACHE, true);
query.setHint(DBConstants.ACTIVATE_QUERY_CACHE_REGION,
myDBManager.getQueryCacheRegion());
}
public T insert(T t) {
EntityManager entityManager = this.getEntityManager();
EntityTransaction tx = entityManager.getTransaction();
tx.begin();
try {
t.setInsertDate(new Date());
102
entityManager.persist(t);
entityManager.flush();
entityManager.refresh(t);
tx.commit();
try {
tx.rollback();
} finally {
LOG.error("Error inserting an object: " + e);
}
} finally {
entityManager.close();
}
return t;
}
...
}
Del fragmento de cdigo anterior conviene resaltar tres puntos. En primer lugar, podemos ver cmo se manejan
las transacciones dentro de un DAO, de forma que cada mtodo de un DAO supone una transaccin con la base
de datos. Este es el diseo correcto. En segundo lugar, se ha creado un mtodo que cachea una JPAQuery en la
cach correspondiente, de forma que todo DAO pueda usarla cuando lo considere conveniente. En ltimo lugar,
comentar que se ha empleado el tipado genrico de Java para trabajar en este DAO base abstracto. Se define un
tipo genrico T con la nica condicin de extender de MedipiAbstractEntity, de tal forma que se puede trabajar
con los atributos comunes en el DAO abstracto. Si pretendemos crear un DAO para una clase concreta
realzaremos la siguiente declaracin.
public class ConstantInfoDAO extends AbstractDAO<ConstantInfo>
De forma que los mtodos del DAO accesibles a travs de una instancia de ConstantInfoDAO debern usar
entidades ConstantInfo.
5.5.3.1.3.4 Paquete Util

En este paquete se ubica simplemente una clase con todas las constantes empleadas en el presente proyecto. En
todos los proyectos desarrollados se ha seguido el mismo diseo: cada proyecto tiene una nica clase en las que
se ubican todas las constantes empleadas. Se ha optado por esta solucin porque suelen ser constantes bastante
genricas, usables desde varios lugares de la aplicacin, y adems no hay una gran cantidad de ellas. Existen
varios patrones de diseo posibles, siendo el ms habitual ubicar las constantes comunes en una clase general y
colocar las especficas como atributos de las clases que las utilicen. Al igual que ocurra con los servicios, se ha
optado por una metodologa adecuada para la situacin actual, no siendo necesario mantenerla a toda cosa.
public class DBConstants {

public static final String ACTIVE_QUERY_CACHE = "org.hibernate.cacheable";
public static final String ACTIVATE_QUERY_CACHE_REGION =
"org.hibernate.cacheRegion";
}
5.5.3.2 HEALTH-DOM
5.5.3.2.1 Funcionalidad de la libreria

En health-dom definimos las entidades JPA asociadas al esquema HEALTH de base de datos. Se ha optado por
separar esta librera del proyecto core-dom para que siempre exista una librera por cada esquema, que contenga
exclusivamente el mapeo de dicho esquema, las QClasses y las constantes relacionadas con ellas. Adems, se
103
abre la posibilidad de que se ample el modelo de datos y se considere que HEALTH no debe ser el esquema
bsico, sino que es posible que depende de otro esquema ms general. En ese caso, gracias a esta separacin,
basta con cambiar las dependencias en el pom y no hay necesidad de tocar cdigo.
Figura 5-24. Proyecto health-dom

El fichero pom.xml de health-dom es extremadamente simple, similar al del core-dom. Adems de indicar el
pom padre y definir el id del proyecto se establece la dependencia con core-dom.
<parent>
</parent>
<artifactId>health-dom</artifactId>
<name>health-dom</name>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>core-dom</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>

La prctica totalidad del proyecto consiste en el mapeo de las tablas del esquema HEALTH. Comencemos con
la primera tabla mapeada, a modo de ejemplo.
@Entity
@Table(name = "PATIENT", schema = "HEALTH")
public class Patient extends MedipiAbstractEntity {
public Patient() {
}
public Patient(Long patientId, String pid, String dni, String name, String
surname1, String surname2, PersonSex sex) {
104
this.patientId = patientId;
this.pid = pid;
this.dni = dni;
this.name = name;
this.surname1 = surname1;
this.surname2 = surname2;
this.sex = sex;
}
@Id
@Column(name = "PATIENT_ID", unique = true, nullable = false, precision = 5,
scale = 0)
@SequenceGenerator(name = "HEALTH.PATIENT_ID_SEQ", sequenceName =
"HEALTH.PATIENT_ID_SEQ", allocationSize = 1)
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator =
"HEALTH.PATIENT_ID_SEQ")
private Long patientId;
@Column(name = "PID", unique = true, nullable = false, length = 32)

private String pid;
@Column(name = "DNI", unique = true, nullable = false, length = 32)

private String dni;
@Column(name = "NAME", length = 32)

private String name;
@Column(name = "SURNAME1", length = 32)

private String surname1;
@Column(name = "SURNAME2", length = 32)

private String surname2;
@Enumerated(EnumType.ORDINAL)
@Column(name = "SEX", nullable = false, precision = 1, scale = 0)
private PersonSex sex;
// getters y setters
}
Se emplea la etiqueta @Entity para indicar que se trata de una entidad / tabla JPA. Para especificar qu tabla y
esquema se emplea @Table. Esto ocurre porque puede haber entidades que no se correspondan con una tabla
en base de datos. Por ejemplo, una vista es tambin una entidad. Incluso es posible que esa vista no tenga ninguna
correspondencia con base de datos, si no que sea una entidad interna utilizada por algn motivo concreto, aunque
no sea el caso ms habitual.
La clave primaria de una entidad se marca con @Id. Todas las claves simples de nuestro modelo de datos
emplean una secuencia, que puede mapearse directamente en JPA con las etiquetas @SequenceGenerator y
@GeneratedValue. De esta manera, JPA/Hibernate se encarga de avanzar consecuentemente la secuencia
cuando se inserta un registro. Con @SequenceGenerator estamos creando el manejador de la secuencia para
JPA: le damos un id, le indicamos la secuencia de base de datos con la que se corresponde y el aumento que
debe realizar cada vez. Por su parte, con @GeneratedValue es donde estamos indicando el valor para ese
atributo. Podemos indicar valores autogenerados de tipo identidad, tabla y secuencia, informando adems del id
del generador de secuencia creado anteriormente.
El resto de columnas nos mapeos de JPA, similares a los vistos en MedipiAbstractEntity, salvo el caso del
atributo sex. En ese caso se est indicando un mapeo con un enumerado de Java. Cuando eso ocurre basta con
indicar en la etiqueta @Enumareted si va a ser de tipo numrico o texto. En el primer caso el valor numrico en
base de datos (0, 1, 2...) se mapea con el valor que corresponde a su posicin en el enumerado. En caso de tipo
ordinal (numrico) se busca una correspondencia entre el texto almacenado en base de datos y el indicado en el
enumerado. La utilizacin de enumerados puede ser bastante til, permite transformar nmeros en base de datos
en objetos con entidad y significado propio.
105
@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(referencedColumnName = "PATIENT_ID", name = "PATIENT_ID", nullable =
false)
private Patient patient;
En las lneas superiores observamos cmo se mapea la foreing key que hay en EPISODE hace PATIENT.
Gracias a JPA, no solo tenemos el PATIENT_ID que figura en el registro, si no que podemos acceder al objeto
Patient completo, algo tremendamente til. Con @ManyToOne se especifica el tipo de relacin entre las tablas,
en este caso un registro en EPISODE se corresponde con uno en PATIENT, pero un PATIENT puede tener
mltiples EPISODES. Adems de esta etiqueta se pueden emplear otras segn la cardinalidad de la relacin:
@OneToOne, @OneToMany, @ManyToMany En todas ellas se debe indicar si el FetchType es EAGER o
LAZY. Este atributo indica el tratamiento que debe hacer JPA/Hibernate de la relacin. Si se indica EAGER el
objeto referenciado (en este caso Patient) se trae automticamente con Episode, realizando JPA las consultas
que considere oportunas para poblar el objeto Patient. Sin embargo, si se indica LAZY el objeto no est
instanciado inicialmente, si no que har falta llamar a su getter (getPatient() en el ejemplo) para que se lance la
consulta a base de datos y se forme el objeto. Ambos modos de trabajo tienen ventajas e inconvenientes. La
regla general empleada para este desarrollo es considerar EAGER aquellas relaciones que aportan sentido
funcional al objeto (como conocer el paciente de un episodio) y marcar como LAZY las que ofrecen informacin
opcional, aunque no es fcil establecer un criterio nico.
@Entity
@Table(name = "CONSTANT", schema = "HEALTH")
@Cache(usage = CacheConcurrencyStrategy.READ_ONLY, region =
HealthConstants.CACHE_CONSTANT)
public class Constant extends MedipiAbstractEntity
Terminamos el detalle del desarrollo de health-dom comentando cmo se indica el cacheo de una tabla completa.
Para ello basta con emplear la etiqueta @Cache, en este caso de Hibernate. La configuracin es bastante sencilla:
se indica la regin correspondiente y la estrategia de concurrencia [69]. Las regiones se definen en el fichero
ehcache.xml en cada aplicacin, tal y como veremos ms adelante. Junto a un nombre o identificador de la
regin se indicarn otros parmetros como tamao, tiempo que se espera antes de borrar informacin antigua,
etc. En nuestro caso definimos aqu el nombre de la regin, de forma que cada aplicacin pueda disear la cach
segn sus necesidades. Por otra parte, la estrategia puede ser:
- READ_ONLY: se usa cuando los datos no van a cambiar, por lo que solo se va a emplear en la consulta
de datos.
- READ_WRITE: se emplea cuando los datos necesitan ser actualizados, pero no se provee un
mecanismo de separacin entre transacciones simultaneas. Por tanto, puede que las transacciones no
funcionen correctamente si hay muchas inserciones/actualizaciones a la vez, provocando lecturas
fantasmas, es decir, inconsistencias en la cach.
- NONSTRICT_READ_WRITE: similar a la anterior, solo que realiza un mayor control de la

transaccionalidad.
- TRANSACTIONAL: cach totalmente transaccional. EhCache no la implementa.
Evidentemente, solo nos interesar una cach READ_ONLY, pues la informacin que se va a escribir no se
desear cachear, ya que no se consultar con frecuencia.
106
Conviene recordar que Hibernate mantiene una cach de primer nivel. Toda operacin que se realiza sobre un
objeto EntityManager es cacheada y permanece en esta situacin hasta que se elimina el objeto.
Junto al mapeo de las entidades el proyecto incluye las QClass autogeneradas y una clase HealthConstants en la
que solamente se indican las cachs diseadas, para que otros proyectos puedan conocer el nombre de la regin
y operar con ellas.
5.5.3.3 DATACQ-DOM
5.5.3.3.1 Funcionalidad de la librera

Este proyecto es el ltimo de los dedicados a la base de datos. En l se lleva a cabo el mapeo de las tablas del
esquema DATA_ACQ.
Figura 5-25. Proyecto datacq-dom

En el pom.xml definimos el proyecto Maven e indicamos la dependencia con health-dom, que a su vez incluir
la librera core-dom.
<parent>
</parent>
<artifactId>datacq-dom</artifactId>
<name>datacq-dom</name>
<dependencies>
<dependency>
</dependency>
</dependencies>
107

El mapeo del esquema DATA_ACQ no es muy diferente al visto en el proyecto anterior. La nica novedad con
respecto a lo ya comentado es remarcar que JPA nos permite crear atributos que no tienen una correspondencia
directa con ninguna columna de la tabla mapeada en base de datos. Veamos un ejemplo
@ManyToOne(fetch = FetchType.LAZY, cascade = CascadeType.REFRESH)

@JoinColumn(referencedColumnName = "MEDIPI_INSTANCE_ID", name = "MEDIPI_INSTANCE_ID",
nullable = false)
private MedipiInstance medipiInstance;
@OneToMany(orphanRemoval = true, fetch = FetchType.LAZY, mappedBy = "medipiInstance",

cascade = CascadeType.ALL)
private Set<Allocation> allocations;
El primer atributo pertenece al objeto Allocation, mientras que el segundo lo hace a MedipiInstance. Con las dos
instrucciones estamos mapeando una misma relacin, vista desde cada extremo. Desde Allocation definimos
una relacin ManyToOne a la instancia a la que est asignada, mapeando la columna de base de datos
MEDIPI_INSTANCE_ID con el objeto que representa dicha tabla. Sin embargo, en el otro extremo no estamos
realizando ninguna vinculacin entre el atributo y la base de datos. En su lugar se hace referencia al atributo que
constituye el otro extremo de la relacin. Esto nos ofrece muchas ventajas. Podemos realizar una bsqueda sobre
la tabla MedipiInstance y luego acceder a todas sus asignaciones en una lista simplemente llamando al getter del
atributo. Hibernate har el resto. Conviene comentar el significado de algunas opciones empleadas. Con
OrphanRemoval indicamos que, si existen Allocations en base de datos que no se encuentra en el objeto Java,
estos deben eliminarse al persistir el objeto MedipiInstance. De esta manera podemos recuperar las asociaciones
de una instancia, borrar una por el motivo que sea, y persistir el registro. Automticamente Hibernate borrar el
registro hurfano de la tabla Allocation. Otra novedad con respecto a lo comentado en el proyecto anterior es la
opcin cascade. Esta opcin indica qu acciones efectuadas sobre un objeto deben aplicarse tambin sobre el
objeto relacionado. Si marcamos REMOVE en la clase MedipiInstance sobre la lista de asignaciones estamos
pidiendo a la implementacin de JPA que borre todos los registros asociados a una instancia cuando esta sea
eliminada. Parece evidente que estas acciones son tremendamente tiles para extrapolar acciones sobre objetos
padres a sus objetos hijos. JPA nos permite aplicarlas tambin a la inversa, algo que debe ejecutarse con cuidado.
En nuestro caso, se indica ALL en la relacin padre-hijo (one to many) y REFRESH en la hijo padre (many
to one). Esto implica que toda accin sobre un padre se propagar sobre los hijos, mientras que a la inversa solo
se propagar la accin REFRESH. REFRESH hace referencia a una llamada de JPA para recargar el objeto,
generalmente antes de operar sobre l, por lo que es importante que esta accin se propague para evitar
incoherencias.
Se puede realizar una ltima observacin de las lneas de cdigo superiores: nos encontramos ante otro ejemplo
de utilizacin del fetch, en este caso a la inversa del expuesto en health-dom. En este caso se considera que no
ser poco habitual consultar una instancia a partir de una asignacin, ya que no suele ser el flujo de trabajo
habitual. Adems de eso, hay una cosa que conviene tener clara en el desarrollo de mapeos con JPA: no se
pueden generar ciclos: si en ambas relaciones se marca EAGER se produce un ciclo: Allocation se trae siempre
el objeto MedipiInstance, que a su vez se trae siempre en la consulta inicial los Allocations, que a su vez JPA
conoce estos ciclos y es capaz de cortarlos, pero no su presencia son una prctica totalmente desaconsejada.
5.5.4 MEDIPI-CLUSTER
Medipi-Cluster es un proyecto Maven diseado para agrupar los elementos comunes en la compilacin y
construccin de los proyectos java del rea Cluster. Actualmente solo existe uno, core-cluster, pero dado que a
108
lo largo del diseo se ha hecho especial hincapi en disear una arquitectura software robusta que permita
fcilmente su ampliacin se ha optado por crear un proyecto agrupador, de manera anloga a lo establecido en
medipi-dom y medipi-app.
<parent>
</parent>
<artifactId>medipi-Cluster</artifactId>
<modules>
<module>core-Cluster</module>
</modules>
<dependencies>

<dependency>
<groupId>org.apache.kafka</groupId>
<artifactId>kafka-clients</artifactId>
<version>0.9.0.1</version>
</dependency>

<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
</dependency>
</dependencies>
En esta ocasin no tenemos necesidad de aplicar ninguna lgica especial durante la fase de compilacin del
productor, por lo que este pom no contiene ms de los aspectos bsicos habituales: definicin del proyecto,
referencia a su pom padre, referencia a sus proyectos hijos y definicin de las dependencias que todos ellos
debern incluir.
5.5.4.1 CORE-CLUSTER

En el proyecto core-Cluster se ubica la parte del desarrollo que abarca la comunicacin con el clster de Kafka,
lo que incluye: definicin de los objetos de transferencia de datos (Data Transfer Object, DTO) empleados,
configuracin e implementacin de los consumidores y productores de datos para dicho sistema de intercambio
de informacin. Al igual que ocurre en otros aspectos de la suite, la gran utilidad que proporciona core-Cluster
es el manejo de consumers y producers de Kafka, de tal forma que ofrece a las aplicaciones que as lo deseen un
conjunto reducido de mtodos a emplear para que se produzca esta comunicacin, sin tener que entrar en detalle
de la lgica existente bajo ellos.
109
Figura 5-26. Proyecto core-Cluster

Al tratarse del nico hijo del proyecto maven medipi-Cluster toda la configuracin especial y las dependencias
se vuelcan en el pom padre, dejando para el proye8cto core-Cluster poco ms que los campos obligatorios.
<parent>
<artifactId>medipi-Cluster</artifactId>
</parent>
<artifactId>core-Cluster</artifactId>
<name>core-Cluster</name>

5.5.4.1.3.1 DTO Data Transfer Objects
En el apartado 5.4.3. DTOs se defini los objetos que servirn como base para la informacin intercambiada a
travs del clster Kafka. Cada uno de ellos se corresponde con un objeto Java, ubicado en este proyecto.
public class LFConstantInfo {
public LFConstantInfo() {
}
public LFConstantInfo(Long constantId, Long episodeId, Date constantDate,

String value, Boolean manual) {
this.constantId = constantId;
this.episodeId = episodeId;
this.constantDate = constantDate;
this.value = value;
this.manual = manual;
}
private Long constantId;

private Long episodeId;
private Date constantDate;
private String value;
private Boolean manual;
// getters y setters
}
110
5.5.4.1.3.2 Producer Kafka

Instanciar un producer Kafka desde Java no es especialmente complicado, como ya se vir en el apartado 4.4.5.
Producers. Aun as, se ha querido centralizar lo mximo posible el cdigo para evitar redundancias, de forma
que sea lo ms modular posible. Al crear un MedipiProducer con una interfaz propia evitamos que los
desarrolladores de las aplicaciones tengan q tener conocimiento alguno de Kafka. Adems, Kafka es una
tecnologa en plena fase de desarrollo, no en vano todava ni siquiera cuenta con una versin 1.0. Hemos
observado cmo se han producido algunos cambios importantes al avanzar de versiones, algunos estructurales,
otros de parametrizacin, que refuerzan la opcin escogida. Con esta modularizacin solo har falta aplicar los
cambios que impliquen nuevas versiones de Kafka en un nico proyecto, de forma que estas transformaciones
sean totalmente transparentes a otros proyectos.
Se ha optado por generar dos clases producers MedipiLFProducer y MedipiHFProducer. Ambos extienden del
AbstractMedipiProducer, en el que se encuentra la mayora de la lgica. En ambos casos su utilizacin es tan
sencilla como la expuesta en las lneas inferiores.

props.put(KafkaConstants.PROP_SERVER_LIST,PropertiesReader.getProperty(KafkaConstants.
VALUE_SERVER_LIST));
. . .
MedipiLFProducer producerLF = new MedipiLFProducer();
producerLF.initialize(props);
producerLF.sendLFConstantInfo(info);
Con cuatro instrucciones bsicas se puede mandar informacin al clster. Es interesante remarcar que se ha
optado por crear dos producers, uno para cada topic, cuando esto no es necesario: un producer puede enviar
informacin a tantos topics como quiera. Los motivos de este cambio son dos: facilitar las labores al
desarrollador y ofrecer una interfaz coherente para el uso de Kafka. Como vamos a emplear dos consumers, uno
subscrito a cada topic, es ms coherente ofrecer dos producers a los desarrolladores.
A continuacin, se indica el cdigo de las clases desarrolladas, en la lnea del especificado en captulos
anteriores.
public class AbstractMedipiProducer {
private Producer<Long, String> producer;
public void initialize(Properties props) {

producer = new KafkaProducer<Long, String>(props);
}
protected void sendKafkaMessage(String message, String topic) {

new ProducerThread(producer, new ProducerRecord<Long, String>(topic,
message)).start();
}
private class ProducerThread extends Thread {

private Producer<Long, String> producer;
private ProducerRecord<Long, String> producerRecord;
public ProducerThread(Producer<Long, String> producer,

ProducerRecord<Long, String> producerRecord) {
this.producer = producer;
this.producerRecord = producerRecord;
}
public void run() {

this.producer.send(producerRecord);
}
}
111

producer.close();
}
}
public class MedipiLFProducer extends AbstractMedipiProducer {

public void sendLFConstantInfo(LFConstantInfo info) {
String msg = gson.toJson(info);
String topic = KafkaConstants.TOPIC_LF;
sendKafkaMessage(msg, topic);
}
}
5.5.4.1.3.3 Consumer Kafka

Instanciar un consumer de Kafka es algo ms complicado que hacer lo propio con un producer. Como en el
apartado 4.4.6 Consumers ya se definieron las instrucciones bsicas que se han de emplear para consumir
informacin del clster Kafka, nos centraremos aqu en justificar las decisiones tomadas en pos de empaquetar
y personalizar la lgica necesaria para utilizar adecuadamente un consumer Kafka desde los proyectos de
MEDIPi.
Por coherencia, la estructura empleada es similar a la de los MedipiProducers: tendremos dos consumers, uno
para cada topic o canal del que queramos recibir informacin, de tal forma que ambos extienden de una clase
abstracta AbstractMedipiConsumer en la que se ubica la lgica comn.

props.put(KafkaConstants.PROP_SERVER_LIST,
. . .
MedipiLFConsumer consumerLF = new MedipiLFConsumer() {
@Override
public void receiveLFConstantInfo(LFConstantInfo info) {
receiveDataToAll(info);
}
};
consumerLF.initialize(props);
Se ha puesto especial hincapi en que la utilizacin de estos MedipiConsumers sea lo ms sencilla posible. En
este caso observamos que basta con instanciar el objeto, indicarle la configuracin mediante un fichero
Properties y sobrescribir el mtodo en el que se maneja el DTO recibido. Es destacable que un desarrollador no
tiene q conocer el funcionamiento de un consumer, de Kafka y ni siquiera la utilizacin de JSON para la
transformacin del DTO en el mensaje que va por el clster. Todo eso es totalmente transparente para l.
public abstract class AbstractMedipiConsumer {
protected KafkaConsumer<Long, String> consumer;

protected ExecutorService executor;
protected boolean end = false;

consumer = new KafkaConsumer<>(props);
executor = Executors.newCachedThreadPool();
}

end = true;
executor.shutdown();
}
}
112
public abstract class MedipiLFConsumer extends AbstractMedipiConsumer {

super.initialize(props);
consumer.subscribe(Arrays.asList(KafkaConstants.TOPIC_LF));
startLFThread();
}
private void startLFThread() {

executor.execute(new Thread() {
public void run() {
while (!end) {
ConsumerRecords<Long, String> records =
consumer.poll(KafkaConstants.POLL_TS);
for (ConsumerRecord<Long, String> record : records) {
receiveLFConstantInfo(gson.fromJson(record.value(),
LFConstantInfo.class));
}
}
consumer.close();
}
});
}
public abstract void receiveLFConstantInfo(LFConstantInfo info);

}
Observamos que se arranca un hilo encargado solamente de leer del topic. Cuando se reciben datos se reconstruyen y se
llama al mtodo que debe implementar el receptor.

La presencia de un paquete .util es habitual en todos los proyectos de la suite y siempre incluye el mismo tipo
de cdigo: una clase para almacenar todas las constantes empleadas a lo largo del proyecto.
5.5.5 MEDIPI-APP
Tal y como se ha realizado para las otras categoras, se ha decidido crear un proyecto maven que permita agrupar
las aplicaciones de MEDIPi y sus libreras comunes, centralizando dependencias y configuraciones comunes.
<parent>
</parent>
<artifactId>medipi-app</artifactId>
<modules>
<module>core-app</module>
<module>dda</module>
<module>saver</module>
<module>chart</module>
</modules>
<build>
<pluginManagement>
<plugins>
113
<plugin>
<artifactId>maven-jar-plugin</artifactId>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
<filters>
<filter>src/main/filters/conf-${environment}.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
<profiles>
<profile>
<id>development</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<environment>development</environment>
</properties>
</profile>
<profile>
<id>final</id>
<properties>
<environment>final</environment>
</properties>
</profile>
</profiles>
En las lneas superiores tenemos el contenido principal del fichero pom.xml en el que se define este proyecto
maven como un mdulo de medipi-suite y padre, a su vez, de cuatro proyectos: dda, saver, chart y core-app.
La seccin build de un pom.xml se emplear para informar de un conjunto de configuraciones o
parametrizaciones comunes a emplear durante la compilacin del proyecto. En este caso, se est indicando el so
un nuevo plugin de maven a todos los proyectos hijos de medipi-app: maven-plugin-jar. Este plugin no hace
ms que empaquetar en un fichero .jar las clases java compiladas. Cuando un proyecto se define como de tipo
jar Maven automticamente llama a este plugin tras las fases iniciales, generando un jar. Sin embargo, puede
resultar de inters llamar al plugin en otros momentos. Tal y como vimos en el captulo terico de Maven, el
ciclo de trabajo de la herramienta pasa por la compilacin y ejecucin de las clases de pruebas (que por
convencin se ubican, salvo modificacin explcita, en src/test/) pero no las empaqueta en un jar. Es aqu
donde entra la configuracin realizada: en el pom estamos indicando a Maven que llame al plugin jar en la fase
de test-jar, provocando que se genere un fichero jar con todos los tests. Se pretende con esto que todas las
aplicaciones de MEDIPi tengan un catlogo de pruebas asociadas que puedan ser ejecutadas mediante la
invocacin adecuada de este jar.
114
El siguiente punto son los filtros y los perfiles, que comentaremos conjuntamente. Para entender el trabajo
realizado vamos a comenzar comentando cada funcionalidad empleada de manera independiente.
<dependency>
</dependency>
En las lneas superiores, correspondientes al pom.xml de datacq-dom, se est indicando que el proyecto health-
dom debe incorporarse como librera externa el proyecto actual para su correcto funcionamiento. Sin embargo,
no se est definiendo explcitamente el proyecto, si no que se estn empleando variables que Maven es capaz
de entender y traducir. Cuando se indica ${project.groupId} Maven reconoce la sintaxis ${} y busca el valor
con el que se corresponde project.groupId. En este caso se trata de una variable propia de Maven, que hace
referencia al groupId del pom.xml del proyecto, pero es perfectamente posible definir nuevas variables, de
forma que puedan usarse no solo en el pom.xml, sino tambin en otros puntos del desarrollo. Para ello se emplea
la seccin properties. A continuacin, tenemos un ejemplo en el que definimos dos variables: Cluster (de valor
Kafka) y hardware (de valor Raspberry).
<properties>
<Cluster>Kafka</Cluster>
<hardware>Raspberry</hardware>
</properties>
Podemos definir un filtro indicando, con las etiquetas adecuadas en el pom.xml, el fichero de texto en el que se
ubican las variables que se quieren declarar y sus valores. Gracias a esto Maven las reconocer y permitir
realizar la traduccin en el pom.xml siempre y cuando se utilicen las variables con la sintaxis adecuada. El
siguiente paso es no traducir solo en el pom.xml, si no tener la capacidad de utilizar estas variables en el resto
de recursos del proyecto. Para ello se activa la propiedad filtering a true en la seccin resources.
Otra funcionalidad de maven empleada en este proyecto son los perfiles. Mediante la etiqueta profiles podemos
generar un catlogo de perfiles, identificados unvocamente por un id, que contienen cada uno una configuracin
determinada. Por tanto, los perfiles nos permiten personalizar an ms la construccin del proyecto. Por ejemplo,
podemos crear un perfil denominado Pruebas y ubicar en l la configuracin del plugin maven-jar-plugin que se
ha comentado. Cuando llevamos a cabo alguna fase de Maven es necesario indicar el perfil, excepto cuando solo
hay un perfil o alguno de ellos est marcado como activo por defecto.
Por ltimo, los ficheros .properties son un tipo de recursos ampliamente usados en Java como mtodo de
definicin de variables o de parmetros de configuracin, y tienen la siguiente estructura.
log_path = /opt/medipi/logs/
log_filename = dda.log
db_connection_ip = localhost
...
Todo lo anterior se va a combinar para formar un mecanismo de parametrizacin de las aplicaciones. No toda la
parametrizacin de una aplicacin debe estar en base de datos, al contrario, solo tiene sentido que est en base
de datos aquella que se pretenda modificar durante la ejecucin del software. Para definir una serie de variables
u opciones de configuracin que no se esperan que cambien es ms adecuado utilizar los ficheros .properties.
El flujo de trabajo es el siguiente: al ejecutar el software desde el IDE de desarrollo o al generar el jar compilado
se debe especificar uno de los dos perfiles posibles: development o final. Si no se indica ninguno se toma
development como perfil seleccionado, al ser el valor por defecto. El perfil seleccionado da el valor
115
correspondiente a la variable environmet. Observamos dnde se est usando esa variable: en la definicin del
fichero que usaremos de filtro. Es decir, en el proyecto deben existir dos archivos filtros ubicados en
src/main/filters: conf-development.properties y conf-final.properties. Elegir un perfil u otro est repercutiendo
en elegir entre un filtro u otro. En dicho filtro definimos una serie de valores, como se ve en el siguiente ejemplo.
log_path_value = D:/MEDIPI/logs/
log_filename_value=chart.log
Los dos filtros deben tener las mismas variables, aunque puedan tener diferente valor. Maven ahora reconoce
las variables log_path_value, log_filename_value, etc. de forma que ser capaz de sustituir
${log_filename_value} por chart.log tanto en el pom.xml como en los recursos, gracias a que activamos dicha
opcin. Qu utilidad tiene esto? Queremos poder cambiar la ruta del log, pero no es una buena prctica realizar
un desarrollo en el que leamos de un fichero u otro segn el perfil seleccionado, si no que debemos acceder
solamente a uno y que este properties vaya cambiando de valores en funcin del perfil actual. Para ello se ha
definido un archivo denominado configuration.properties. Su contenido tiene el siguiente aspecto.
log_path = ${log_path_value}
log_filename = ${log_filename_value}
Al ser un recurso, Maven lo interpreta y traduce las variables que en l encuentre, por lo que desde el punto de
vista del cdigo Java se vera de la siguiente manera,
log_path = D:/MEDIPI/logs/
log_filename = chart.log
Independientemente de cual sea el perfil, la aplicacin solo tiene que leer el valor almacenado en el fichero
configuration.properties. En resumen, el fichero configuration.properties hace uso de las variables creadas en el
filtro (con un valor diferente segn el perfil indicado), ofreciendo una capa de abstraccin al cdigo.
Hay que tener claro que el fichero configuration.properties no define nuevas variables Maven, no es un filtro,
solo es un recurso que leer la aplicacin Java como considere oportuno. Adems, no estamos filtrando solo este
fichero, estamos filtrando todos los resources, por lo que podremos hacer uso de las variables declaradas en los
filtros en otros ficheros, algo que se ver ms adelante.
5.5.5.1 CORE-APP

Al trabajar con varias aplicaciones que comparten una arquitectura comn y pretenden pertenecer a una misma
suite de proyectos, es lgico plantear la necesidad de unificar aquellos desarrollos que se consideran estructurales
o que sabemos a ciencia cierta que se deben abordar por ms de una aplicacin. Es esta la utilidad del Proyecto
core-app.
116
Figura 5-27. Proyecto core-app

Core-app queda definido como proyecto Maven mediante el sencillo pom.xml mostrado en las lneas posteriores.
<parent>
</parent>
<artifactId>core-app</artifactId>
<name>core-app</name>

5.5.5.1.3.1 Configuracin del Log
Uno de los elementos comunes a todas las aplicaciones ser la configuracin del log. Mediante unas sencillas
instrucciones se carga el fichero de configuracin de log y se inicia.
public class LogConfigurator {
public static void loadConfiguration(Class<?> initialClass) {
// Configure log4j
String log4jFile = AppConstants.LOG_CONF_FILE;
try {
Properties logProperties = new Properties();
logProperties.load(initialClass.getClassLoader().getResourceAsStre
am(log4jFile));
PropertyConfigurator.configure(logProperties);
System.err.println("Error reading Log4j configuration file " +
log4jFile);
e.printStackTrace();
System.exit(1);
}
}
}
El nico punto de inters en el desarrollo anterior es la ubicacin del fichero de configuracin del log, ya que
este mtodo debe ser empleable por muchas aplicaciones a la vez. En la constante LOG_CONF_FILE se est
indicando, como su propio nombre indica, el fichero de configuracin: log4j.properties. Sin embargo, cmo
conocemos su ubicacin? Para resolver esta pregunta deben tenerse en cuenta varios conceptos importantes.
117
Figura 5-28. Estructura de un proyecto durante el desarrollo vs compilado
El mtodo recibe la clase origen y recupera su ClassLoader. El Java Classloader (en espaol, cargador de clases
Java) es una parte del Java Runtime Environment que carga dinmicamente clases o recursos en la mquina
virtual, definiendo un recurso (resource) como un fichero de datos (imgenes, audio, texto, etc.) al que se puede
acceder desde el cdigo java de una clase. El ClassLoader recuperado nos ofrece mtodos para cargar recursos
como getResource() o getResourceAsStream(). Para ello debemos indicarle la ruta relativa desde el ClassLoader
(y no desde el class) hasta el fichero que se quiere leer. Un ClassLoader se ubica siempre en el classpath, en el
directorio base de nuestro proyecto. En la imagen superior, a la derecha, tenemos la estructura resultante de
compilar el proyecto Saver, donde observamos que el fichero log4j.properties est ubicado en el directorio base,
lugar desde donde arranca la ruta relativa del ClassLoader. Es por eso por lo que basta con indicar el nombre del
fichero. Si esta situacin cambia, habr que indicar las carpetas intermedias entre el directorio base y el fichero
a cargar. Solo queda por comprender una cosa: existe una evidente diferencia entre la estructura de carpetas de
la izquierda (durante el desarrollo) y la de la derecha (contenido del jar generado). Esto se debe a que la estructura
de carpetas src/main/java, src/test/java, src/main/resources, etc. son un conjunto de convenciones que establece
Maven para facilitar el desarrollo. Cuando se compila el proyecto la informacin contenida en
src/main/resources se mueve al directorio base, a no ser que se indique una configuracin distinta en el pom.xml.
5.5.5.1.3.2 Properties
Toda aplicacin de MEDIPi contar con un fichero denominado configuration.properties en el que los
desarrolladores ubicarn los parmetros de configuracin que no vayan a ser modificados frecuentemente, El
proyecto core-app proporcionar una interfaz de acceso comn a ese fichero; es decir, mantendr una clase,
denominada PropertiesReader, con una serie de mtodos que permitan acceder a los parmetros indicados en
ese fichero, de forma que se puedan usar sin necesidad de conocer la ubicacin del mismo.
Se ha seguido este diseo por razones ya comentadas previamente: la clase PropertiesReader deber ser
modificada si se realizan cambios estructurales como emplear ms de un fichero de configuracin, etc. Pero ser
esta la nica clase que deber modificarse, no ser necesario recorrer todo el desarrollo buscando dnde se lea
el fichero de configuracin e ir haciendo las correcciones necesarias. Por tanto, se construye un modelo ms
escalable que adems es menos propenso a errores ante cualquier cambio o modificacin.
En resumen, manejaremos una clase PropertiesReader encargada de leer el fichero configuration.properties.
Adems, tambin se proporciona la capacidad de emplear un segundo fichero de configuracin
(extra_configuration.properties). Este fichero se ubicar, en caso de existir, fuera del jar, permitiendo al
desarrollador sobrescribir los parmetros que considere necesarios.
Para llevar a cabo esta funcionalidad la clase mantendr un atributo esttico de tipo java.util.Properties. Este tipo
de objetos Java permiten interactuar con los ficheros .properties redactados en diversos formatos, entre ellos el
empleado para nuestros proyectos (nombre_parametro = valor_parametro).
Adems, la clase contar con un bloque esttico. Los bloques de cdigo estticos se ejecutan una sola vez, en la
primera llamada a cualquier mtodo de la clase (incluyendo un constructor). Ah se leer del fichero de
118
configuracin, cargando su contenido en el objeto Properties. Para ilustrarlo se incluye a continuacin una
versin reducida del cdigo.
private static Properties props;
static {
if (props == null) {
try {
loadProperties();
loadExtraProperties();
} catch (IOException e) {
LOG.error("Error loading configuration properties", e);
System.exit(1);
}
}
}
private static void loadProperties() throws IOException {

props = new Properties();
try {
InputStream inputStream = PropertiesReader.class.getClassLoader()
.getResourceAsStream(AppConstants.PROP_FILE_NAME);
props.load(inputStream);
throw new FileNotFoundException("Property file '" +
AppConstants.PROP_FILE_NAME + "' incorrect or not found in the
classpath");
}
}
private static void loadExtraProperties() throws IOException {
File file = new File(AppConstants.EXTRA_PROP_FILE_NAME);
if (file.exists()) {
InputStreamReader inputStream = new InputStreamReader(new
FileInputStream(file), Charset.forName("UTF-8"));
props.load(inputStream);
}
}
Simplemente, en la primera llamada a cualquier mtodo de la clase se invoca a los mtodos encargados de poblar
el objeto properties tanto con el fichero de configuracin regular como con el fichero de configuracin extra.
Existen pequeas pero importantes diferencias entre ellos. En loadProperties() se reinicia siempre el objeto
Properties antes de cargar la parametrizacin. Posteriormente se genera un InputStream del fichero, siguiendo
el mismo mtodo de acceso visto previamente para el log (algo lgico pues ambos ficheros se encontrarn en el
mismo directorio). Como se est empleando un formato estndar de java, basta con llamar al mtodo load del
objeto Properties. Por su parte, en loadExtraProperties() no se reinicia el objeto properties, por lo que los
parmetros que se lean del fichero de configuracin extra se aadirn o sobrescribirn. En esta ocasin si el
fichero no existe no se provoca ningn error. Adems, la instruccin para recuperar el InputStream asociado es
totalmente diferente. La instruccin new FileInputStream utilizar como ruta el working directory; es decir,
el directorio del sistema de ficheros desde el cual se invoc a la instruccin java. Por tanto, para que se carguen
adecuadamente sus parmetros, el fichero extra_configuration.properties deber colocarse en el mismo
directorio en el que se ejecute la llamada a Java.
Para terminar, PropertiesReader contar con un mtodo que recupere el valor de un parmetro a travs de su
nombre.
public static String getProperty(String name) {

String value = props.getProperty(name);
if (value == null) {
LOG.error("Error reading " + name + " property . Stopping JVM");
}
return value;
119

En la clase AppConstants se declaran todas las constantes utilizadas por este proyecto.
5.5.5.2 DDA
5.5.5.2.1 Funcionalidad de la aplicacion DDA

DDA son las siglas de Device Data Acquisition, el mdulo de MEDIPi encargado de establecer comunicacin
con los biodispositivos, a partir de un conjunto de protocolos especficos mayoritariamente propietarios,
recuperar la informacin biomdica del paciente, adaptarla a un formato propio y enviarla al Cluster de MEDIPi
para que pueda ser consumida por otras aplicaciones de la suite.
Figura 5-29. Proyecto DDA

DDA es un proyecto mdulo de medipi-app, que adems emplear core-app como dependencia para poder usar
toda la funcionalidad comn implementada por la misma. Adems, tal y como vimos al principio del presente
apartado dedicado al Software, debe incluir core-Cluster para gestionar la comunicacin con el Cluster Kafka
de MEDIPi.
<parent>
</parent>
<artifactId>dda</artifactId>
<name>dda</name>
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
</plugin>
</plugins>
</pluginManagement>
120
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<finalName>${project.groupId}-
${project.artifactId}</finalName>
<descriptors>
<descriptor>assembly.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>

<dependency>
</dependency>
<dependency>
</dependency>
<dependency>
</dependency>

</dependencies>
En el pom.xml del proyecto se emplea un plugin de maven no usado hasta el momento: maven-assembly-plugin
asociado a la fase package de Maven. Este plugin construye una versin empaquetada de la solucin de acuerdo
a una serie de reglas definidas en el archivo assembly.xml indicado. En este caso se pretende generar un fichero
.zip con los .jar necesarios para ejecutar DDA y los scripts de arranque (ubicados en src/main/resources), de
forma que sea ms sencillo el despliegue y uso de la solucin en el hardware de integracin elegido.
<assembly
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-
plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
<id>package</id>
<formats>
<format>zip</format>
</formats>
<fileSets>
<fileSet>
<directory>src/main/resources</directory>
<outputDirectory>/bin</outputDirectory>
<includes>
<include>*.sh</include>
121
<include>*.bat</include>
</includes>
<lineEnding>unix</lineEnding>
</fileSet>
</fileSets>
<dependencySets>
<dependencySet>
<outputDirectory>/lib</outputDirectory>
</dependencySet>
</dependencySets>
</assembly>
El fichero comienza indicando un identificador nico de la construccin configurada. Este id se aadir al

nombre del proyecto (artifact-id) para dar lugar al nombre del archivo/s generado/s, en este caso dda-
package.zip. Su utilidad radica en que podemos tener varios ficheros de assembly (uno por construccin) de
forma que el id nos sirva para identificar la solucin generada. Con la etiqueta formats se indica el formato o
formatos en los que se empaquetar la solucin construida. Es decir, si quisiramos generar un dda-
package.tar.gz bastara con aadir este formato a la lista, sin necesidad de duplicar el assembly.
La seccin fileSets sirve para parametrizar el tratamiento que se le va a realizar a uno o varios ficheros no Java
del proyecto. Para cada conjunto de ficheros con configuracin comn se debe declarar un fileSet. Para el
proyecto DDA es necesario que todos los ejecutables (aquellos ficheros .sh y .bat de la carpeta de resources de
Maven) se copien a una carpeta bin en el directorio raz del zip. Es interesante destacar que se pueden realizar
varias configuraciones especficas sobre los ficheros tratados, como se observa en el assembly.xml cuando se ha
parametrizado que todos los ficheros tratados utilicen la codificacin de fin de lnea de unix.
Para terminar, se puede realizar un tratamiento parecido al visto con los ficheros no Java para las dependencias,
con dependencySets y dependecySet. En este caso basta con especificar que se quiere que todas las libreras
Java (incluyendo el jar correspondiente al presente proyecto) se ubiquen en un directorio determinado.

DDA es, sin lugar a duda, la aplicacin ms compleja de las que componen la suite MEDIPi. Detallar sus
funcionalidades y las decisiones tcnicas tomadas durante el desarrollo implicar tener primero una visin
general de todas las tareas implicadas.
A grandes rasgos, DDA cuenta con cuatro secciones o agrupaciones de funcionalidad diferenciadas:
- Configuracin de las utilidades o elementos empleados: la base de datos, el log o el acceso a los
properties son elementos que se deben configurar, cada uno a su manera.
- ProtocolReader: cada instancia de DDA se identifica de forma unvoca. Mediante este identificador la
aplicacin deber ir a base de datos y conocer sus asignaciones actuales. Ser necesario mantener un
conjunto de ProtocolReaders (implementaciones de protocolos), de acuerdo a las asignaciones actuales.
Todos los ProtocolReader emplearn una serie de convenciones que permitan estandarizar la
informacin recuperada.
- CommandListener: DDA arranca un servidor para atender a peticiones de actualizacin de
asignaciones, refresco de cach, etc. Por ejemplo, una aplicacin externa informar al servidor de que
ha habido un cambio de dispositivo asignado. Gracias a esto DDA podr llamar nuevamente al
ProtocolReaderManager para que compare los lectores actuales con los requeridos segn las
asignaciones de la base de datos.
- DataSender: La informacin biomdica recuperada se enva a un DataSenderManager. Un DataSender
no es ms que un conjunto de clases preparadas para recibir los datos y almacenarlas / enviarlas a un
lugar determinado. El clster Kafka es el DataSender principal.
- Util: clase para mtodos comunes
122
Figura 5-30. Esquema de DDA
Para facilitar las secciones comentadas se ha diseado el esquema previo, en el que se muestra un diagrama de
flujo de los paquetes / clases / mtodos fundamentales del proyecto. De un primer vistazo es posible ubicar cada
agrupacin de funcionalidad en el grfico, adems de obtener una idea aproximada de las conexiones a base de
datos y al Cluster.
5.5.5.2.3.1 Configuraciones
5.5.5.2.3.1.1 Log
Para configurar el log simplemente basta con ubicar el fichero log4j.properties en la carpeta de recursos del
proyecto y llamar a la utilidad de core-app comentada en su apartado correspondiente.
LogConfigurator.loadConfiguration(Main.class);
5.5.5.2.3.1.2 Properties
Esta funcin tambin est regulada por core-app, solo que no necesita que se llame a ningn mtodo explcito
para arrancarla. Como se vio anteriormente, basta con llevar a cabo la lectura de un parmetro para que se hagan
las operaciones iniciales necesarias. DDA tiene, al igual que el resto de aplicaciones que usan core-app, los
properties configuration.properties, configuration-development.properties y configuration-final.properties
necesarios para que la lgica de core-app funcione.
5.5.5.2.3.1.3 Base de datos

El funcionamiento de la base de datos es ligeramente parecido al de los properties. Previamente se detall el
patrn de diseo empleado en el acceso a base de datos (4.5.3.1.3 DBManager y 4.5.3.1.3 DAOs y Services).
123
En resumen, los DAOs realizan las acciones sobre la base de datos (y tenemos un DAO por entidad), siendo
todas ellas accesibles a travs de un objeto Service denominado DDAConfiguration.
public class AllocationDAO extends AbstractDAO<Allocation> {
public AllocationDAO(DBManager myDBManager) {

super(myDBManager);
}
private static final Logger LOG = Logger.getLogger(AllocationDAO.class);
private static AllocationDAO instance = new

AllocationDAO(DDADBManager.getInstance());
public static AllocationDAO getInstance() {

return instance;
}
@SuppressWarnings("unchecked")
public List<Allocation> getActualAllocationsByInstance(Long medipiInstanceId) {
List<Allocation> res = new ArrayList<Allocation>();
QAllocation qallo = QAllocation.allocation;
EntityManager em = getEntityManager();
try {
Date now = new Date();
JPAQuery<?> query = new JPAQuery<Allocation>(em);
query.from(qallo);
query.where(qallo.medipiInstance.medipiInstanceId.
eq(medipiInstanceId));
query.where(qallo.startDate.before(now));
query.where(qallo.endDate.after(now).or(qallo.endDate.isNull()));
query.where(qallo.deleted.isFalse());
res = (List<Allocation>) query.fetch();
LOG.error("Error executing a query: " + e);
}
em.close();
return res;
}
}
Todos los DAOs tienen una estructura similar: cuentan con un atributo esttico denominado instance que
devuelve un objeto de esta clase. Este patrn de diseo se denomina singleton (instancia nica en ingls) y est
diseado para restringir la creacin de objetos pertenecientes a una clase o el valor de un tipo a un nico objeto.
Su intencin consiste en garantizar que una clase slo tenga una instancia y proporcionar un punto de acceso
global a ella. Esta instancia se crea con el constructor definido, que llama al constructor del AbstractDAO. Dicho
constructor requiere que se le informe de una implementacin de la instancia. En el caso actual se emplear
DDADBManager. Junto a los mtodos ya comentados se encontrarn los creados especficamente para realizar
una accin concreta, generalmente una consulta.
En getActualAllocationsByInstance(Long medipiInstanceId) podemos observar un caso concreto de QueryDSL
para generar una consulta. Basta con instanciar un objeto JPAQuery, indicarle la entidad principal de la consulta
y especificar el EntityManager. Los objetos JPAQuery nos proporcionan un conjunto de mtodos para simular
la sintaxis SQL (from, where, etc.). Para hacer referencia a las entidades debe usarse las QClass autogeneradas,
las cuales tambin cuentan con un conjunto de mtodos que nos permiten la comparacin con valores u otros
atributos. Gracias a todo esto podemos lanzar una consulta con una sintaxis muy parecido a SQL, que nos
proporcionar los resultados en los objetos JPA mapeados.
. . .
private static AllocationDAO allocationDAO = AllocationDAO.getInstance();
. . .
124
public static synchronized List<Allocation> getActualAllocations() {

List<Allocation> res = new ArrayList<Allocation>();
try {
MedipiInstance myInstance = getMyInstance();
res = allocationDAO.getActualAllocationsByInstance
(myInstance.getMedipiInstanceId());
LOG.error("Allocation for this instance can not be found", e);
}
return res;
}
El objeto DDAConfiguration simplemente se encarga de gestionar el singleton de cada DAO empleado,

ofreciendo a las clases un acceso comn a travs de sus mtodos estticos y sincronizados.
public class DDADBManager extends AbstractDBManager {
public DDADBManager(String persistenceUnit, String queryCacheRegion) {

super(persistenceUnit, queryCacheRegion);
}
private static DDADBManager instance = new

DDADBManager(DDAConstants.PERSISTENCE_UNIT,
DDAConstants.QUERY_CACHE_REGION);
public static DDADBManager getInstance() {

return instance;
}
public static void cleanProtocolConstantMapCache() {

instance.cleanCache(DataAcqConstants.CACHE_PROTOCOL_CONSTANT_MAP);
}
public static void cleanConstantCache() {

instance.cleanCache(HealthConstants.CACHE_CONSTANT);
}
public static void cleanQueryCache() {

instance.cleanCache(instance.getQueryCacheRegion());
}
}
En la clase de gestin de base de datos tambin se emplea el patrn singleton. Hasta ahora no se ha comentado
en qu punto de la aplicacin se llama al constructor de DDADBManager, provocando que se inicialice la
comunicacin con la base de datos. Al generarse estticamente una instancia de esta clase se est llamando al
constructor del AbstractDBManager, especificando el persistenceUnit y la queryCacheRegion de este proyecto,
quien crear los objetos de gestin de base de datos y cach adecuados, tal y como se coment adecuadamente
en su apartado correspondiente. Por tanto, cuando se realice la primera llamada a un mtodo (esttico) de
DDADBManager (como, por ejemplo, getInstance()) automticamente se crea la instancia, llamando al
constructor del abstract e inicializando la conexin correctamente. La creacin de todos los DAOs necesita
recibir una instancia de un objeto de interfaz DBManager, como se vio anteriormente, por lo que esa ser con
frecuencia la instruccin que acceder a DDADBManager por primera vez, creando la instancia.
Por otra parte, no hay muchas ms novedades con respecto al abstract: simplemente se proponen algunos
mtodos para limpiar las cachs propias de esta aplicacin.
Queda una parte importante de la gestin de la base de datos por comentar. Hasta ahora se ha ido desgranando
la configuracin de la base de datos, comentando la capa correspondiente a cada librera o proyecto de MEDIPi.
Es por ese motivo por el que se ha dejado para el final la capa bsica, aquella encargada de parametrizar o
configurar la conexin (indicar la ip de la base de datos, el esquema, las regiones de cach, etc.). Cada aplicacin
podr personalizar la suya, indicando simplemente el persistenceUnit y la queryCacheRegion al
125
AbstractDBManager que acta a modo de configurador comn.
Para parametrizar una conexin a base de datos con JPA se ha de emplear un fichero denominado
persistence.xml y ubicado en directorio-base-proyecto/META-INF. En este fichero, mediante una sintaxis
determinada que veremos a continuacin, se especifica toda la configuracin necesaria.
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
version="2.0">
<persistence-unit name="medipi.dda" transaction-type="RESOURCE_LOCAL">

<provider>org.hibernate.ejb.HibernatePersistence</provider>


<class>medipi.health.dom.Patient</class>
<class>medipi.health.dom.Episode</class>
<class>medipi.health.dom.Constant</class>
<class>medipi.health.dom.ConstantInfo</class>

<class>medipi.datacq.dom.Allocation</class>
<class>medipi.datacq.dom.Device</class>
<class>medipi.datacq.dom.DeviceModel</class>
<class>medipi.datacq.dom.DeviceType</class>
<class>medipi.datacq.dom.MedipiInstance</class>
<class>medipi.datacq.dom.Parameter</class>
<class>medipi.datacq.dom.Protocol</class>
<class>medipi.datacq.dom.ProtocolConstantMap</class>
<properties>


<property name="javax.persistence.jdbc.driver"
value="oracle.jdbc.driver.OracleDriver" />
<property name="javax.persistence.jdbc.url"
value="jdbc:oracle:thin:@${db_ip}:${db_port}:${db_sid}" />
. . .
</properties>
</persistence-unit>
</persistence>
En un persistence.xml podemos definir tantos persistence-unit como queramos. Cada persistence-unit es una
parametrizacin diferente, pudiendo variar cada uno de sus argumentos: base de datos, parmetros de hibernate,
cach, entidades reconocidas, etc. El nombre del persistence-unit es el identificador que el
EntityManagerFactory necesita conocer para poder generar las EntityManager. Junto al identificador se ha de
especificar el tipo de transaccin empleada. Este es un asunto complejo e implica el conocimiento de varios
elementos de JPA a bajo nivel, como la cach interna de JPA [70]. Simplificando, con el tipo JTA se puede
instanciar EntityManagers (aunque nunca una EntityManagerFactory) y cada EntityManager estar asociada a
una transaccin. Ser necesaria la existencia de una capa de negocio o servicio (siendo el estndar EJB y lo ms
empleado Spring Framework, etc.) que se comunicarn con JPA para gestionar dichas transacciones, pudiendo
el desarrollador indicar determinadas polticas de las mismas mediante anotaciones. Por otra parte,
RESOURCE_LOCAL delega en el desarrollador la tarea de crear los EntityManagers que considere necesarios
a partir de un EntityManagerFactory y de gestionar sus transacciones. Deber crearse la transaccin, realizarse
los commits y rollback adecuados segn el programador considere. Esta opcin es ms artesanal, pero evita la
necesidad de implementar una capa de servicio innecesaria para los proyectos actuales. Adems, ofrece mucha
ms versatilidad al dar ms control al desarrollador, motivos por los que se ha empleado. Conviene darse cuenta
de que est decisin es coherente con lo desarrollado en el AbstractDAO de core-dom, donde se gestiona la
126
transaccin manualmente.
Para cada persistence-unit indicamos qu implementacin de JPA se va a usar, pues JPA no es ms que el
estndar, la API que Hibernate implementa. A continuacin, se indican las entidades JPA que este persistence-
unit manejar.
La seccin de properties es la principal: en ella se encuentra la mayor parte de la configuracin. Para rellenar
muchos de los parmetros se emplean variables de Maven. Recordemos que el persistence.xml se encuentra en
una carpeta dentro de la ruta de resources de Maven y que dicho directorio est siendo filtrado, sustituyendo las
variables con sintaxis ${variable} por el valor indicado en el filtro correspondiente al perfil actual. De esta
manera podemos cambiar muchos parmetros de configuracin de acuerdo al perfil, de una manera gil y sin
inconsistencias.
Nivel Parmetro Valor Descripcin
javax.persistence. jdbc.driver oracle.jdbc.driver.OracleDriver Driver de JDBC
jdbc:oracle:thin:@${db_ip}:${
javax.persistence. jdbc.url Conexin a BBDD
db_port}:${db_sid}
Usuario para la
javax.persistence. jdbc.user ${db_user}
conexin
Password para la
javax.persistence. jdbc.password ${db_password}
conexin
Proveeder de la cach
hibernate. cache.provider_class org.cache.EhCacheProvider
de segundo nivel.
Dialecto
hibernate. dialect org.dialect.Oracle10gDialect (Especificacin) de la
base de datos empleada
hibernate. default_schema ${db_user} Esquema
hibernate. generate_statistics true Generar estadsticas
Almacena datos en un
cache.use_structured_en
hibernate. true formato ms
tries
visualizable / explotable
hibernate. cache.use_minimal_puts true Optimizador
Formatear las consultas

hibernate. format_sql true SQL para una mejor
explotacin
Visualizacin de las
hibernate. show_sql ${hibernate_sql_value}
consultas en el LOG.
cache.region.factory_cla org.cache.ehcache.EhCacheReg Clase de la factora de

hibernate.
ss ionFactory regiones de cach
cache.use_second_level Emplear cach de

hibernate. true
_cache segundo nivel
127
hibernate. cache.use_query_cache true Usar cach de consultas
configurationResourceN
net.sf.ehcache. ehcache.xml Descriptor de la cach
ame
De los parmetros solo es interesante destacar la configuracin de la cach de segundo nivel de Hibernate,
indicndole que proveedor usaremos y en qu fichero se configura.

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd">
<defaultCache eternal="false" maxElementsInMemory="100"

timeToLiveSeconds="86400" overflowToDisk="false" diskPersistent="false"
/>
<cache name="constant" maxElementsInMemory="100" eternal="false"
/>
<cache name="protocolConstantMap" maxElementsInMemory="50"
eternal="false" timeToLiveSeconds="86400" overflowToDisk="false"
diskPersistent="false" />
<cache name="queries" maxElementsInMemory="50" eternal="false"
/>
</ehcache>
La configuracin de la cach es muy sencilla. EhCach maneja un concepto denominado regiones de cach, de
forma que crea varias pequeas cachs independientes. Cada una de ellas, incluyendo la cach por defecto, se
parametrizan aqu.
Nombre Descripcin
name Identificador de la regin de cach
eternal Cach permanente
Nmero de elementos mximos en memoria. Si una cach alcanza este nmero

maxElementsInMemory de elementos, los nuevos registros se incluirn en la cach eliminando los ms
antiguos.
timeToLiveSeconds Cuando un elemento supera este timeout se borra automticamente de la cach.
Si se supera el umbral definido por maxElementsInMemory se usar el disco

overflowToDisk
duro (y no la memoria RAM) como soporte para almacenar ms datos.
Controla que la parte de la cach almacenada en el disco duro no se elimina al

diskPersistent
parar la aplicacin.
Para hacer referencia a estas regiones se han visto ya las dos opciones: indicar la regin de la cache en el mapeo
de JPA (anotacin @Cache) o indicar a una JPAQuery que debe incluir dicha consulta en una regin
determinada (query. setHint (DBConstants. ACTIVE_QUERY_CACHE, true); y query. setHint (DBConstants.
ACTIVATE_QUERY_CACHE_REGION, myDBManager. getQueryCacheRegion());).
128
5.5.5.2.3.1.4 ReportNetwok
Cada instancia de DDA, cada ejecucin de dicho programa se identifica unvocamente a travs del hostname
del equipo sobre el que corre. Por tanto, la arquitectura de DDA no est pensada para arrancar dos aplicaciones
DDA en un mismo dispositivo. El motivo es claro: este mdulo de MEDIPi se encarga de establecer una
comunicacin con los biodispositivos a los que est conectado. En captulos anteriores hemos definido que se
emplear una Raspberry Pi para correr nuestro programa, con la mayora de los dispositivos conectados
directamente mediante una interfaz USB o RS232. Por tanto, no tiene sentido que haya dos programas a la vez
intentando comunicarse con un dispositivo, pues al leer o pretender escribir a la vez en un mismo puerto
provocara que la informacin se corrompiera. Es por este razonamiento por el que se ha diseado una
arquitectura basada en una ejecucin de DDA, una mquina. Volviendo atrs, partimos de que se va a emplear
el hostname para identificar una instancia, pudiendo emplear dicho nombre de equipo para recuperar el registro
de base de datos de MEDIPI_INSTACE. A travs de l podremos, por ejemplo, encontrar los registros en la
tabla ALLOCATION de dicha MEDIPI_INSTANCE asociados actualmente.
public static void reportNetwork() {

// Discover Ip
String ip = DDAUtils.discoverMyIpAddress();
String port = String.valueOf(PropertiesReader.
getProperty(DDAConstants.COMMAND_LISTENER_PORT));
String info = ip + DDAConstants.IP_PORT_SEPARATOR + port;
// If daemon has network connectivity report server port. If not report
// connection out
if (ip != null && !ip.isEmpty() && port != null && !port.isEmpty()) {
MedipiInstance myInstance = DDAConfiguration.getMyInstance();
myInstance.setIp(info);
DDAConfiguration.saveMedipiInstance(myInstance);
}
}
ReportNetwork no es ms que un mtodo ejecutado directamente desde el main de DDA para realizar la ltima
labor de configuracin del sistema: identificar el hostname de su equipo y escribir en MEDIPI_INSTANCE la
direccin ip y el puerto con el que otros sistemas podrn comunicarse con l. Para ello se emplean dos sencillos
mtodos: discoverMyIpAddress y getMyInstance. El primero es un mtodo de DDAUtils que se encarga de
recuperar las interfaces de red (mediante NetworkInterface.getNetworkInterfaces()) y recorrerlas una a una hasta
encontrar aquella con una configuracin IP vlida. Por otro lado, getMyInstance recupera el hostname y acude
con l a base de datos para recuperar un objeto MedipiInstance que mapee dicho registro. Para recuperar el
hostname se lanza una instruccin en lnea de comandos para posteriormente leer el resultado, mediante las
utilidades proporcionadas por Java para dicha tarea.
Process process = Runtime.getRuntime().exec("hostname");

BufferedReader reader = new BufferedReader(new
InputStreamReader(process.getInputStream()));
String hostname = reader.readLine().trim();
Basta con recuperar el puerto del CommandListener (ubicado en un properties y recuperable por tanto a travs
de PropertiesReader) para tener toda la informacin necesaria antes de realizar la actualizacin en base de datos.
129
5.5.5.2.3.2 ProtocolReader
Figura 5-31. ProtocolReader
El conjunto de clases que agrupamos bajo la categora ProtocolReader constituye el ncleo de DDA, pues sern
las encargadas de realizar una implementacin estructurada y estandarizada de los protocolos necesarios para
establecer la comunicacin con los biodispositivos. En la imagen anterior observamos un esquema bsico de
esta seccin de DDA que iremos detallando a lo largo de este epgrafe. Atendiendo a dicha representacin nos
encontramos con dos elementos claramente diferenciados.
5.5.5.2.3.2.1 ProtocolReader
Cada vez que se quiera establecer una comunicacin con un dispositivo concreto ser necesario llevar a cabo el
desarrollo Java de dicha integracin. Para estandarizar esta tarea lo mximo posible se ha creado una interfaz
conocida como ProtocolReader, de forma que cada desarrollo de un protocolo concreto la implemente, teniendo
as una base comn. De esta forma, el ProtocolReaderManager podr trabajar con referencias a ProtocolReader,
independientemente de la clase concreta. Sin embargo, no nos bastar con una mera interfaz, ser imprescindible
la creacin de un Abstract que maneje la lgica comn a todos los protocolos. Por ejemplo, todos los protocolos
deben construir un objeto representativo de la variable biomdica recuperada y enviarlo al apartado software de
DDA encargado de comunicarlo al clster. Esta tarea ser comn a todos, por lo que es absurdo duplicar lgica
en las diferentes clases.
public interface ProtocolReader {

public ProtocolReader createAndConfigurate();
public void start();
public boolean stop();
public void sendObservation(String constantName, Object value, String unitName,
Date constantDate);
public void sendObservation(String constantName, Object[] value, String
unitName, Date startDate, Float periodobs);
public Allocation getAllocation();
public void setAllocation(Allocation allocation);
}
La interfaz fuerza la implementacin de varios mtodos. Los tres primeros (createAndConfigurate, start y stop)
se emplean simplemente para manejar el flujo de trabajo del protocolo. Justo tras instanciar una clase que
implemente ProtocolReader se llamar al mtodo createAndConfigure donde cada protocolo realizar las tareas
necesarias para preparar la integracin con el dispositivo. Por su parte, start y stop sern llamados por el
ProtocolReaderManager para arrancar o parar el ProtocolReader cuando sea necesario. Adems de los mtodos
130
ya comentados, ProtocolReader obliga a implementar getters y setters de la asignacin, lo que implica que todo
lector de protocolos debe conocer la asignacin concreta con la que se corresponde, U poco ms adelante
veremos la utilidad de esta decisin. Para finalizar, define dos mtodos sendObservation que los protocolos
emplearn cuando hayan recuperado una constante biomdica, realizando adems su envo a otros puntos de
DDA.
Es el turno de analizar la clase AbstractProtocolReader. Esta clase va a contener solo dos atributos: un ndice o
identificador nico del ProtocolReader en el ProtocolReaderManager y la asignacin de dispositivo a la que da
soporte. Este ltimo vena prcticamente impuesto por la interfaz, que nos obligaba a implementar su getter y
setter. El ndice solo ser realmente til cuando se vayan a instanciar dos o ms ProtocolReaders iguales, de
forma que ambos tengan un identificador nico que puedan emplear para instanciar otros objetos. Por su parte,
conocer la asignacin es mucho ms til: es posible que dos modelos de dispositivos empleen el mismo
protocolo con algunas diferencias. En ese caso, el patrn de diseo recomendado es manejar el mismo
ProtocolReader, pero emplear el campo info del modelo para identificar sus particularidades. Para solucionar
esto el ProtocolReader conoce el dispositivo al que da soporte, sabiendo su modelo, tipo, etc.
protected int index;

protected Allocation allocation;
public AbstractProtocolReader(int index, Allocation allocation) {

this.index = index;
this.allocation = allocation;
}
public int getIndex() {

return index;
}
public void setIndex(int index) {

this.index = index;
}
@Override
public void setAllocation(Allocation allocation) {
this.allocation = allocation;
}
@Override
public Allocation getAllocation() {
return allocation;
}
Por otra parte, se definen los mtodos sendObservation, encargados de recibir la informacin de una constante
biomdica del paciente, construir un objeto de tipo LFInfoConstant o HFInfoConstant y enviarlo a la clase
encargada de comunicarse con el clster Kafka. La lgica realizada en estos mtodos es muy sencilla: a partir
de los datos conocidos recuperamos la constante y el episodio al que hace referencia, construyendo el objeto
apropiado. En el caso de las LFInfoConstants se realiza una comprobacin bsica: si es una constante de tipo
numrica se ignorar la informacin si el valor se encuentra fuera de los rangos permitidos indicados en base de
datos. Tras esto, se enva el ConstantInfo al DataSenderManager, que se comentar ms adelante.
@Override
public synchronized void sendObservation(String constantName, Object value,
String unitName, Date constantDate) {
String protocolCode = allocation.getDevice().getDeviceModel().
getProtocol().getCode();
Constant cnt = DDAConfiguration.
getConstantByProtocolMap(protocolCode, constantName);
Episode epi = allocation.getEpisode();
if (cnt != null && epi != null && valueFiltering(value, cnt)) {
LFConstantInfo observation = new
LFConstantInfo(cnt.getConstantId(), epi.getEpisodeId(),
constantDate, String.valueOf(value), false);
DataSenderManager.sendInfoToAll(observation);
131
}
}
Con esto se define la arquitectura de clases de una implementacin de un protocolo para la comunicacin con
biodispositivos. Se han definido un conjunto de polticas y mecanismos que se debern seguir mediante la
herencia de la clase AbstractProtocolReader. Al margen de eso, ser tarea de cada implementacin lidiar con las
particularidades de su protocolo.
5.5.5.2.3.2.2 ProtocolReaderManager
Clase encargada de ir a base de datos, recuperar los dispositivos asignados a la instancia actual, encontrar los
ProtocolReaders asociados a dichos dispositivos y realizar las operaciones necesarias para cuadrar los
ProtocolReaders actuales del sistema con los esperados de acuerdo a la configuracin de base de datos. Es, por
tanto, una clase gestora, de forma que sus mtodos servirn de punto de acceso para otras clases de DDA. Para
evitar tener que instanciar un objeto de esta clase cada vez que se quiere refrescar, parar o arrancar un lector de
protocolos se emplearn mtodos y atributos estticos.
La base de ProtocolReaderManager es sencilla: se va a mantener un mapa con todos los ProtocolReader que
corren actualmente en el sistema, de forma que podr comparar dicho mapa con la informacin proporcionada
por la base de datos.
Map<Integer, ProtocolReader> protocolReaderMap = new LinkedHashMap<Integer,

ProtocolReader>();
ProtocolReader cuenta con un conjunto de mtodos estticos para cubrir la funcionalidad descrita:
- getProtocolReaderByAllocation: a travs de un objeto Allocation (mapeo JPA de un registro de la
tabla ALLOCATION) es posible acceder al modelo, tipo y protocolo del dispositivo concreto asociado.
Con esta informacin, el mtodo getProtocolReaderByAllocation se encarga de encontrar la
implementacin de ProtocolReader ms adecuada. Como es evidente, existir una implementacin de
ProtocolReader para cada protocolo, por lo que el ncleo del mtodo no ser ms que un conjunto de
if/else en funcin del cdigo del protocolo del dispositivo.
- startReaders: es probablemente el mtodo ms bsico de ProtocolReaderManager. Como se puede
deducir, se encarga simplemente de recuperar las asignaciones actuales en base de datos y comprobar
si ya se estn manejando mediante algn ProtocolReader. Para aquellas asignaciones nuevas se busca e
instancia el ProtocolReader adecuado (mediante una llamada a getProtocolReaderByAllocation). Este
ProtocolReader se aade al mapa para futuras comprobaciones.
- conditionalStopReaders: realiza la tarea inversa al mtodo anterior: recorre el mapa de
ProtocolReaders actual para ver si hay alguna asignacin que ya no est en base de datos, procediendo
a pararla.
- forceStopReaders: para todos los ProtocolReader actualmente arrancados, independientemente de lo
que indique la base de datos.
- updateReaders: comprueba que los ProtocolReaders son los adecuados mediante una parada
condicional, una limpieza de la cach de consultas y el arranque de los readers.
- restart: fuerza la parada de todos los ProtocolReaders actuales, limpia todas las cachs del sistema y
vuelve a arrancar los lectores de protocolos.
- getProtocolReaderByIndex: simplemente accede al mapa, devolviendo el ProtocolReader
correspondiente al ndice especificado.
- getters y setters del mapa protocolReaderMap.
132
Los distintos mtodos de ProtocolReaderManager son llamados desde varios puntos de DDA, destacando la
llamada a startReaders desde el main y las posibles llamadas a updateReaders y restart por el servidor de
comandos.
5.5.5.2.3.3 CommandListener
DDA cuenta con un servidor de comandos preparado para escuchar en un puerto determinado un conjunto de
comandos soportados que provocarn las acciones oportunas en la aplicacin. Para construirlo se va a emplear
una clase CommandListenerServer que herede de Thread, de forma que arrancamos un hilo para este servidor.
Adems, los comandos no sern ms que valores numricos decimales que se enviarn entre un cliente y este
servidor. Es decir, se buscar leer un byte de informacin, transformando este byte en su representacin decimal.
Este valor ser el comando intercambiado.
Figura 5-32. CommandListener
Se trata de un servidor muy simple, construido directamente con Java:
ServerSocket servidor = new ServerSocket(puertoConexion);

Socket conexion = servidor.accept();
BufferedInputStream is = new BufferedInputStream(conexion.getInputStream());
InputStreamReader isr = new InputStreamReader(is);
int comando;
while (true) {
comando = isr.read();
selectCommand(comando, conexion);}
Se crea un socket y se acepta la conexin. La llamada al read() bloquea el hilo hasta que se recibe un byte. Cada
byte se castea a un int y se manda a un mtodo encargado de realizar las acciones que se correspondan con dicho
comando. Las acciones soportadas se pueden ver en el esquema con el que comienza este apartado.
- refreshThreads: llama al mtodo updateThreads() de ProtocolReaderManager. Devuelve ACK.
- refreshCache: limpia todas las cachs empleadas por DDA. Devuelve ACK.
- restart: llama al mtodo restart de ProtocolReaderManager. Devuelve ACK.
- test: devuelve ACK sin realizar ninguna accin.
El valor con el que se corresponde cada uno de los comandos anteriores (incluyendo el ACK) se ha fijado en la
clase DDAUtils mediante el empleo de constantes.
Adems, se ha aadido un cliente para este servidor entre los tests de DDA, bajo la denominacin de
TestCommandListenerClient.
5.5.5.2.3.4 DataSender
Para dotar de escalabilidad a la solucin se ha optado por entender el envo de datos al Kafka como uno de los
posibles destinos de la informacin biomdica. De esta manera, la comunicacin con el clster se comporta
133
como uno de los posibles DataSenders de DDA, permitiendo al desarrollado aadir o eliminar nuevos. Por
ejemplo, podemos pensar en un nuevo DataSender muy sencillo: un fichero de texto en el que se vuelquen los
datos tal y como se van obteniendo. Por tanto, si ahora el envo de datos al clster es solo uno de los posibles
destinos es necesario una capa intermedia que reciba los datos y se los pase a los DataSenders adecuados.
El patrn de diseo es exactamente el mismo al diseado para ProtocolReader: contaremos con una interfaz que
define los mtodos bsicos (DataSender), implementaciones concretas (KafkaDataSender) y un organizador o
gestor (DataSenderManager). En este caso no es necesaria la existencia de una clase abstracta ya que no existe
lgica comn a mantener.
Figura 5-33. DataSenderManager
5.5.5.2.3.4.1 DataSender
La interfaz DataSender define solamente dos mtodos: sendInfo(LFConstantInfo) y sendInfo(HFConstantInfo).
Cada implementacin concreta deber implementar este mtodo para recibir los objetos, procesarlos si es
necesario y almacenarlos / enviarlos a donde corresponda.
Por ejemplo, KafkaDataSender simplemente instancia y configura dos MedipiProducers (uno para cada topic)
y enva los objetos recibidos al clster, gracias al diseo realizado en core-Cluster.
public class KafkaDataSender implements DataSender {
private MedipiLFProducer producerLF;

private MedipiHFProducer producerHF;
public KafkaDataSender() {
PropertiesReader.getProperty(KafkaConstants.VALUE_SERVER_LIST));
props.put(KafkaConstants.PROP_KEY_SER,
PropertiesReader.getProperty(KafkaConstants.VALUE_KEY_SER));
props.put(KafkaConstants.PROP_VALUE_SER,
PropertiesReader.getProperty(KafkaConstants.VALUE_VALUE_SER));
props.put(KafkaConstants.PROP_RETRIES,
PropertiesReader.getProperty(KafkaConstants.VALUE_VALUE_RETRIES));
props.put(KafkaConstants.PROP_LINGER,
PropertiesReader.getProperty(KafkaConstants.VALUE_LINGER));
props.put(KafkaConstants.PROP_BATCH,
PropertiesReader.getProperty(KafkaConstants.VALUE_BATCH));
props.put(KafkaConstants.PROP_FIRST_TS,
PropertiesReader.getProperty(KafkaConstants.VALUE_FIRST_TS));
props.put(KafkaConstants.PROP_ACK_TS,
PropertiesReader.getProperty(KafkaConstants.VALUE_ACK_TS));
producerLF = new MedipiLFProducer();
producerLF.initialize(props);
producerHF = new MedipiHFProducer();
producerHF.initialize(props);
}
@Override
public void sendInfo(LFConstantInfo info) {
134
producerLF.sendLFConstantInfo(info);
}
@Override
public void sendInfo(HFConstantInfo info) {
producerHF.sendHFConstantInfo(info);
}
}
5.5.5.2.3.4.2 DataSenderManager
Es una clase con dos funciones claramente diferenciadas:
- Organizar los DataSenders, instanciando y manteniendo aquellos disponibles.

static {
instantiateDataSenders();
}
private static void instantiateDataSenders() {

try {
dataSenderList = new ArrayList<DataSender>();
dataSenderList.add(new KafkaDataSender());
LOG.error("Error creating data senders.", e);
System.exit(1);
}
}
- Servir de intermediario al resto de la aplicacin: cuando un ProtocolReader haya recuperado una

constante biomdica se la enviar al DataSenderManager, quien a su vez se la reenviar a todos los
DataSenders disponibles, evitando que los ProtocolReaders tengan que conocer el estado actual de cada
DataSender disponible en el programa.
public static void sendInfoToAll(LFConstantInfo constantInfo) {
for (DataSender ds : dataSenderList) {
ds.sendInfo(constantInfo);
}
}
public static void sendInfoToAll(HFConstantInfo constantInfo) {
for (DataSender ds : dataSenderList) {
ds.sendInfo(constantInfo);
}
}
5.5.5.2.3.5 Util
Como ltimo comentario acerca de DDA se destaca que cuenta con dos clases de utilidades: una para mtodos
comunes o considerados de propsito general (DDAUtil) y otro para almacenar las constantes del mdulo de
acuerdo a la poltica general de la suite (DDAConstants).
5.5.5.3 SAVER
5.5.5.3.1 Funcionalidad de la aplicacion

SAVER es el mdulo de la suite MEDIPI encargado de consumir la informacin existente en el clster para
procesarla y almacenarla en la base de datos. Solo se van a procesar las constantes discretas o a baja frecuencia,
pues son las nicas que tiene sentido almacenar en base de datos. El resto sern tratadas por otras aplicaciones
de la suite.
135
Figura 5-34. Proyecto SAVER

Como todo proyecto Maven cuenta con un descriptor pom.xml, en el que hace referencia al proyecto padre y se
especifica nombre del proyecto, versin y dependencias. En este caso las dependencias son solo internas: core-
app para poder seguir la arquitectura de las aplicaciones de la suite, core-Cluster para la comunicacin con Kafka
y datacq-dom para poder trabajar con referencias al esquema DATA_ACQ de base de datos.
<parent>
</parent>
<artifactId>saver</artifactId>
<name>saver</name>
<dependencies>
<dependency>
</dependency>
<dependency>
</dependency>
<dependency>
</dependency>
</dependencies>

SAVER es la aplicacin ms sencilla de la suite. Esto no solo se debe a que realiza una funcionalidad que no es
excesivamente compleja (leer las constantes del clster, procesarlas y almacenarlas en base de datos), sino
tambin a que la estructura de clases diseada para cubrir dicha funcionalidad es tremendamente similar a la
empleada en DDA:
- Configuracin: ser necesario configurar el log, el acceso a los properties, a la base de datos, etc.
- DataReader: recuperacin de constantes de Kafka (y otros posibles puntos de entrada de datos).
136
- DataWriter: existirn un conjunto de clases encargados de guardar la informacin recuperada por los
DataReaders en el sistema de almacenamiento concreto de cada uno, realizando algn procesamiento
intermedio se as se desea.
- Util: constantes.
Figura 5-35. Esquema de SAVER
5.5.5.3.3.1 Configuraciones bsicas de la aplicacin

La configuracin de Log, PropertiesReader y acceso a la base de datos es similar a la comentada en el caso de
DDA.
5.5.5.3.3.2 DataReader
El principal punto de acceso de SAVER es las constantes biomdicas recibidas del clster, pero se ha empleado
el mismo patrn de diseo que en DDA para permitir mltiples puntos de acceso. Por tanto, se define una interfaz
(DataReader), una clase abstracta con lgica comn (AbstractDataSender) y un organizador
(DataSenderManager).
5.5.5.3.3.2.1 DataReader
La interfaz define simplemente tres mtodos: startReading(), readedInfo(LFConstantInfo info) y
readedInfo(HFConstantInfo info). Mientras que el primero arranca la lectura de datos, el resto sern llamados
cuando se hayan recuperado datos del origen.
Por su parte, AbstractDataReader simplemente implemente los mtodos readedInfo, enviando la informacin
comn al DataReaderWriter.
Bajo este patrn se ha creado el siguiente KafkaDataReader.
public class KafkaDataReader extends AbstractDataReader {
private Properties props;

private MedipiLFConsumer consumerLF;
137
private MedipiHFConsumer consumerHF;
public KafkaDataReader() {
props = new Properties();

PropertiesReader.getProperty(KafkaConstants.VALUE_SERVER_LIST));
props.put(KafkaConstants.PROP_GROUP,
PropertiesReader.getProperty(KafkaConstants.VALUE_GROUP));
props.put(KafkaConstants.PROP_KEY_DESER,
PropertiesReader.getProperty(KafkaConstants.VALUE_KEY_DESER));
props.put(KafkaConstants.PROP_VALUE_DESER,
PropertiesReader.getProperty(KafkaConstants.VALUE_DESER));
props.put(KafkaConstants.PROP_OFFSET,
PropertiesReader.getProperty(KafkaConstants.VALUE_OFFSET));
consumerLF = new MedipiLFConsumer() {

@Override
public void receiveLFConstantInfo(LFConstantInfo info) {
readedInfo(info);
}
};
consumerHF = new MedipiHFConsumer() {

@Override
public void receiveHFConstantInfo(HFConstantInfo info) {
readedInfo(info);
}
};
@Override
public void startReading() {
consumerLF.initialize(props);
consumerHF.initialize(props);
}
}
Simplemente, cuando cualquier DataReader procesa una constante llama al readedInfo que la enva al
DataWriterManager. Podemos observar cmo se estn recuperando informacin de los dos topics, a pesar de
que se ha indicado que no se va a guardar en base de datos las constantes a alta frecuencia. Se ha optado por
implementar el consumer del HFConstantInfoTopic para explicitar una idea: una cosa es la informacin
recuperada por el DataSender y otra la procesada por el DataWriter. En este caso, el DataReader puede recuperar
la informacin, pero el DataWriter puede descartarla si as lo necesita para cumplir su propsito.
5.5.5.3.3.2.2 DataReaderManager
El DataReaderManager es prcticamente una copia del DataSenderManager, realizando las adaptaciones
oportunas. El main de SAVER llamar al mtodo startReceiving() del Manager, que se encargar de recorrer su
mapa e invocar a dicho mtodo en cada DataReader. Como siempre, el manager tiene todos sus mtodos y
atributos estticos, para que no haya que instanciar un objeto de esta clase cada vez que se vaya a actuar sobre
los DataReaders.
5.5.5.3.3.3 DataWriter
5.5.5.3.3.3.1 DataWriter
Empleamos, nuevamente, una estructura anloga. En este caso no hay lgica comn por lo que no hay necesidad
de crear un abstract.
DBDataWriter implementa los dos mtodos de la interfaz: writeInfo((LFConstantInfo) y
writeInfo(HFconstantInfo). A travs de ellos llegarn las constantes biomdicas procedentes de los DataReaders.
138
En este caso concreto, el mtodo writeInfo de HFConstantInfo estar vaco, pues se descarta toda la informacin
de este tipo.
@Override
public void writeInfo(LFConstantInfo info) {
if (timeFiltering(info)) {
ConstantInfo ci = SaverConfiguration.
getConstantInfoByEpisodeAndConstant(info);
if (ci != null && ci.getValue() == null) {
ci.setConstantDate(info.getConstantDate());
ci.setManual(info.getManual());
ci.setValue(info.getValue());
SaverConfiguration.saveConstantInfo(ci);
}
}
}
S se implementa el writeInfo de las variables discretas, realizando un sencillo filtrado temporal. En timeFiltering
se tratan las variables recibidas para provocar que no se guarde toda la informacin recibida, solo un valor de
una misma constante mdica para un episodio cada un determinado nmero de minutos. Dicha informacin
estar parametrizada en la base de datos. Por ejemplo, podemos colocar el valor del filtro en 5 minutos, de forma
que solo habr un valor de una misma constante para un episodio cada 5 minutos. Por tanto, adems de rechazar
datos se deber tratar la fecha de la constante, poniendo una que sea representativa del periodo de filtrado (en
nuestro ejemplo sern 0, 5, 10, etc.). Tras esto, se comprueba si existe un registro en base de datos que coincida
con el que se busca insertar, machacndolo con la informacin recibida en caso afirmativo.
5.5.5.3.3.3.2 DataWriterManager
DataWriterManager sirve para distribuir las constantes biomdicas recibidas por los DataSenders. Para ello
manejar una lista de DataWriters disponible y, al recibir un objeto de tipo LFConstantInfo o HFConstantInfo
llamar al writeInfo correspondiente de cada uno de ellos.
5.5.5.3.4 Paquete Util

En esta categora SAVER solo cuenta con una clase de constantes denominada SaverConstants.
5.5.5.4 CHART
5.5.5.4.1 Funcionalidad de la aplicacion

Chart es la aplicacin de visualizacin de datos de la suite diseada en el presente proyecto. Subscribindose al
clster, mostrar las constantes vitales del paciente seleccionado en directo. Para ello, se emplear la librera
JavaFX, provocando que este sea el proyecto ms diferenciado del resto de la suite. A pesar de ello, no deja de
ser una aplicacin Java por lo que emplearemos la misma estructura que para el resto de aplicaciones.
139
Figura 5-36. Proyecto CHART

El pom.xml de CHART no se sale del patrn comentado hasta el momento: definicin del proyecto actual,
referencia al padre y dependencias. Destaca que nos encontramos ante la nica aplicacin que no tiene
dependencias hacia datacq-dom, sino hasta health-dom. Simplemente no se emplea ninguna tabla de este
esquema, por lo que podemos ignorarlo y construir un proyecto ms liviano gracias a la modularizacin.
<parent>
</parent>
<artifactId>chart</artifactId>
<name>chart</name>
<dependencies>
<dependency>
</dependency>
<dependency>
</dependency>
<dependency>
</dependency>
</dependencies>

En esta aplicacin debemos cambiar un poco el enfoque seguido hasta el momento, pues tener un objetivo
bastante diferenciado al resto provoca una estructura de software ligeramente distinta. Aun as, vamos a intentar
estructurar la explicacin del desarrollo realizado de una manera lo ms simular posible a la empleada en el resto
de aplicaciones.
140
Figura 5-37. Esquema de CHART
- Configuracin: al igual que en el resto de aplicaciones se ha de inicializar el log, los properties y el

acceso a la base de datos.
- KafkaDataReader: en este caso no se ha empleado el mismo patrn de diseo que en DDA o SAVER.
Se ha optado por tener una sola clase que gestiona la entrada de datos.
- Pantalla principal: la propia clase main arrancar una ventana en la que se debe seleccionar el paciente
del que se quieren consultar sus constantes vitales.
- Ventana de constantes vitales de un paciente.
- Util: mtodos comnes y constantes.
5.5.5.4.3.1 Configuraciones bsicas de la aplicacin

La configuracin de Log, PropertiesReader y acceso a la base de datos es similar a la comentada en el caso de
DDA y SAVER.
5.5.5.4.3.2 KafkaDataReader
En este caso se ha optado por un enfoque diferente al comentado hasta ahora, mostrando de esta manera cmo
sera y qu ventajas proporciona. Ser el main quien directamente llame a la clase KafkaDataReader encargada
de arrancar los consumers y subscribirlos a los dos topics del clster Kafka. Con este patrn de diseo se manejan
menos clases, se carga menos informacin en memoria y se facilita el cdigo, aunque se pierde en escalabilidad.
La decisin se sustenta en que Chart debe representar la informacin recuperada en tiempo real, por lo que no
tiene sentido otro punto de entrada distinto al clster.
public static synchronized void receiveDataToAll(LFConstantInfo constantInfo) {

getDataQByEpisodeId(constantInfo.getEpisodeId()).add(constantInfo);
}
public static synchronized ConcurrentLinkedQueue<LFConstantInfo>

getDataQByEpisodeId(Long episodeId) {
141
if (dataQMap.get(episodeId) == null) {
dataQMap.put(episodeId, new ConcurrentLinkedQueue<>());
}
return dataQMap.get(episodeId);
}
En las lneas superiores observamos el tratamiento que se hace de las constantes a baja frecuencia recibidas del
clster. El KafkaDataReader de CHART maneja un mapa de colas Java. Cada episodio tiene una cola de
LFConstantInfo que ser consumida por otros puntos de la aplicacin. Para las constantes a alta frecuencia se
realiza un pretratamiento que genera un conjunto de LFConstantInfo por cada valor recibido, envindolas al
mtodo comentado.
5.5.5.4.3.3 MainWindow
La clase Main de CHART es la responsable, no solo de la configuracin y arranque del KafkaDataReader, sino
tambin de generar la ventana principal de la aplicacin.
Para comentarla conviene partir de algunos conceptos bsicos de Java FX.
- Application: las clases Java que son controladoras de una ventana deben extender la clase abstracta
javafx.application.Application. Dicha clase proporciona un flujo de trabajo y obliga a implementar un
conjunto de mtodos para la construccin de la ventana.
- Stage: es el objeto que se corresponde con la ventana en s. Por ejemplo, contiene propiedades como el
icono de la ventana o el tamao. Toda clase que extiende de Application debe implementar un mtodo
start(Stage) en el que ya recibe la Stage que se mostrar en el pc donde se est ejecutando la aplicacin.
- Scene: a una Stage se le puede asignar una y solo una Scene. El objeto Scene es quien contiene la
estructura de elementos de la ventana: textos, combos, botones, imgenes, etc.
Se ha definido un abstract denominado MedipiChartWindow. Las dos ventanas de la aplicacin (la ventana
principal defina en Main y la de constantes de un paciente) extienden de este abstract, en el que simplemente se
setea el icono de la aplicacin.
public abstract class MedipiChartWindow extends Application {

@Override
public void start(Stage stage) {
stage.getIcons().add(new Image(Main.class.getClassLoader()
.getResourceAsStream(ChartConstants.ICON_FILE_NAME)));
initialize(stage);
stage.show();
}
public abstract void initialize(Stage stage);
}
El primer paso es generar los elementos que se van a mostrar en pantalla. JavaFX proporciona un objeto de cada
elemento habitual en la construccin de interfaces de usuario. Es decir, tenemos objetos ComboBox, Button,
etc. Se pueden emplear los mtodos proporcionados por los objetos UI de JavaFX para indicarles un aspecto,
texto, etc. Algunos de ellos buscan asociar un mtodo externo a una actuacin o estado concreto del elemento
en pantalla. Por ejemplo, el mtodo setOnAction de Button espera recibir un objeto de tipo EventHandler. Este
manejador de eventos simplemente define un mtodo principal en el que se desarrolla una lgica determinada.
Cuando se pulse el botn, Java llamar al mtodo principal de la clase asociada a la accin de pulsacin (en este
caso onAction). Por tanto, puede entenderse como una suscripcin a eventos proporcionados por los objetos. En
las lneas de cdigo posteriores se muestra la definicin de algunos de los elementos de la ventana principal.
142
final ComboBox<ComboEpisode> episodeComboBox = new ComboBox<ComboEpisode>();

episodeComboBox.getItems().addAll(refreshEpisodes());
episodeComboBox.valueProperty().addListener(new ChangeListener<ComboEpisode>(){
@Override
public void changed(ObservableValue<? extends ComboEpisode> observable,
ComboEpisode oldValue, ComboEpisode newValue) {
selected.setEpisodeId(newValue.getEpisodeId());
selected.setText(newValue.getText());
}
});
final Button refreshBtn = new Button(ChartConstants.REFRESH_BUTTON);

refreshBtn.setOnAction(new EventHandler<ActionEvent>() {
@Override
public void handle(ActionEvent e) {
episodeComboBox.getItems().clear();
episodeComboBox.getItems().addAll(refreshEpisodes());
}
});
final Button selectBtn = new Button(ChartConstants.SELECT_BUTTON);

selectBtn.setOnAction(new EventHandler<ActionEvent>() {
@Override
public void handle(ActionEvent e) {
if (selected.getEpisodeId() != null) {
Platform.runLater(new Runnable() {
public void run() {
try {
Long id = selected.getEpisodeId();
if (chartWindowMap.get(id) == null) {
ChartWindow win = new ChartWindow();
win.open(selected.getEpisodeId(),
selected.getText());
chartWindowMap.put(id, win);
}
LOG.error("Error launching Chart Window: ", e);
}
}
});
}
}
});
Haca al final del fragmento de cdigo indicado arriba se observa la lgica que se realiza cuando se pulsa el
botn de seleccionar. Para entenderlo hay que comentar que la clase Main maneja un atributo bsico: un mapa
de las ventanas de informacin de paciente abiertas actualmente (chartWindowMap) indexadas por el
identificador nico de episodio. Al pulsar el botn de seleccionar, si no hay ya una ventana abierta para dicho
paciente se instancia y arranca la ventana adecuada.
GridPane grid = new GridPane();

grid.setVgap(7);
grid.setHgap(4);
grid.setPadding(new Insets(20, 20, 20, 20));
grid.add(img, 0, 0, 4, 1);
GridPane.setHalignment(img, HPos.CENTER);
grid.add(new Label(ChartConstants.EPISODE_LABEL), 0, 4);
grid.add(episodeComboBox, 1, 4);
grid.add(refreshBtn, 3, 4);
grid.add(selectBtn, 0, 6, 4, 1);
GridPane.setHalignment(refreshBtn, HPos.RIGHT);
143
GridPane.setHalignment(selectBtn, HPos.CENTER);
Group root = (Group) scene.getRoot();
root.getChildren().add(grid);
stage.setScene(scene);
Una vez definidos los elementos se han de asociar a la Scene del Stage actual de acuerdo a un diseo
determinado. Para ello se ha empleado un Grid (cuadrcula) de 4x7. Al Grid se le van aadiendo los diferentes
objetos de la UI, mediante el mtodo add. En l se especifican, de izquierda a derecha: la columna, la fila, el
nmero de columnas a ocupar (1 si no se indicada nada) y el nmero de filas a ocupar (1 por defecto). De esta
manera indicamos la ubicacin de los diferentes elementos en la Scene, dotndola del aspecto que consideremos
adecuado. Una vez realizada esta tarea se ubica el grid en la raz de la escena.
5.5.5.4.3.4 ChartWindow
Ya se ha visto como se instancia objetos ChartWindow desde la clase principal cuando se selecciona un paciente
determinado y se pulsa el botn de seleccin. La clase ChartWindow, que tambin hereda del abstract comn
MedipiChartWindow, se sustenta en un objeto de tipo LineChart. Esta clase facilita la representacin de grficos
de tipo lineal, pues ofrece un conjunto de mtodos que nos permiten indicar los datos a representar y personalizar
el aspecto que tendr la grfica. Basta con llamar al constructor de Scene indicndole un objeto de tipo LineChart
para que la ventana generada incluya una grfica lineal.
Para aadir valores a representar a un LineChart se emplea el mtodo getData().add(Series). Una serie no es ms
que un conjunto de datos con sentido comn, en nuestro caso formar una serie todos los datos de una misma
constante. Para controlarlas se emplear un mapa en el que las series sern identificadas por la id de la constante
a la que representan. Como se puede ver, las series creadas para Chart esperan recibir dos valores: uno de tipo
Date para el eje X y otro de tipo Number para el eje Y.
private Map<Long, Series<Date, Number>> graphMap = new HashMap<>();
Para controlar el desplazamiento del eje temporal se va a emplear un objeto de tipo

javafx.animation.AnimationTimer. Esta clase define un timer que ser cargado en cada frame, en cada instante
temporal en el que se refresca la informacin en pantalla. Se trata de una clase abstracta que obliga a implementar
un mtodo handle(long now). En dicho mtodo se ubica la lgica que se ha de realizar para ese frame (que ocurre
en now milisegundos).
private void prepareTimeline() {

animation = new AnimationTimer() {
@Override
public void handle(long now) {
addDataToSeries();
cleanOldSeriesData();
}
};
animation.start();
}
private void addDataToSeries() {

while (!KafkaDataReader.getDataQByEpisodeId(selectedEpisodeId).isEmpty()) {
LFConstantInfo ci = KafkaDataReader.getDataQByEpisodeId
(selectedEpisodeId).remove();
Series<Date, Number> ser = getSeries(ci.getConstantId());
ser.getData().add(new Data<Date, Number>(ci.getConstantDate(),
Float.valueOf(ci.getValue())));
}
}
144
private void cleanOldSeriesData() {

Calendar cal = Calendar.getInstance();
cal.setTime(new Date());
cal.set(Calendar.SECOND, cal.get(Calendar.SECOND)
ChartConstants.INTERVAL_IN_SECONDS);
for (Long id : graphMap.keySet()) {
ObservableList<Data<Date, Number>> obList = graphMap.get(id).getData();
if (obList != null && !obList.isEmpty()) {
obList.removeIf(p -> p.getXValue().before(cal.getTime()));
}
}
}
private Series<Date, Number> getSeries(Long cntId) {

if (graphMap.get(cntId) == null) {
Series<Date, Number> series = new LineChart.Series<Date, Number>();
series.setName(ChartConfiguration.getConstantById(cntId).
getDescription());
chart.getData().add(series);
graphMap.put(cntId, series);
}
return graphMap.get(cntId);
}
En cada frame se realizan dos fases: aadir datos a la serie y eliminar datos antiguos. En el primero se lee cada
dato disponible hasta el momento para la cola de este episodio manejada por KafkaDataSender. Con cada dato
se va al mtodo getSeries para recuperar la serie de su constante. Es importante ver que en este mtodo se crea
la serie por primera vez, metindola en el mapa y, ms importante an, aadindola a Chart. Es decir, la serie se
aade a la grfica solo la primera vez, lo que estamos haciendo para cada frame ser aadir y quitar datos. Tras
recuperar la serie se aade un punto XY con los datos recibidos, pasando despus a la segunda fase, Para la fase
de eliminacin se emplea la fecha en la que se ha parado el timer (recibida en milisegundos). Con esta fecha se
puede calcular una fecha umbral (la fecha actual menos determinado intervalo de tiempo configurable) y recorrer
toda la serie para eliminar los datos antiguos. La grfica se expande / contrae automticamente segn el tamao
del eje X que debe representar. Gracias a este control nos aseguramos de que represente siempre el mismo
intervalo temporal (definido por la constante INTERVAL_IN_SECONDS), evitando que el
redimensionamiento distorsione la representacin de las constantes biomdicas del paciente.
Resumen de la descripcin de la propuesta

A lo largo del presente captulo se ha detallado con profundidad el proyecto realizado, comentando ampliamente
todas y cada una de las partes que componen esta aplicacin (o mejor dicho aplicaciones) IoMT: desde la
Raspberry Pi 2 Modelo B sobre la que correremos nuestro software de integracin con biodispositivos, pasando
por la base de datos Oracle y los servidores de colas de mensajes distribudas hasta llegar al ltimo punto del
proyecto: una aplicacin Java FX que permita a los facultativos observar las constantes mdicas de los pacientes
en tiempo real. En algunos casos nos hemos centrado solamente en explicar el enfoque tomado y en detallar la
parametrizacin y configuracin necesaria para adecuar los productos ya existentes a neustras necesidades. Sin
embargo, en los ltimos epgrafes se ha analizado los pormenores del software creado exclusivamente para este
proyecto, comentando cuando, cmo y con qu finalidad se han utilizado todas y cada una de las tecnologas
implicadas.
145
146
6 VALIDACIN
D
urante todos los captulos que componen esta memoria se ha ido detallando, desde distintas perspectivas,
la realizacin del proyecto. Se puede comprobar que en todo momento se han comentado las decisiones
funcionales, tecnolgicas o de diseo en relacin a los objetivos que se marcaron al inicio del proyecto,
y que estn presentes en el primer captulo de este texto. Con ellos en mente se va a llevar a cabo una validacin
del proyecto, probando su correcto funcionamiento.
Funcionamiento de la solucin
El primer punto de este proyecto es la Raspberry Pi 2 que, conectada a los biodispositivos y ejecutando nuestro
software de recoleccin de datos (DDA Device Data Acquisition), se encarga de interpretar los protocolos
propietarios, recuperar la informacin biomdica y mandarla al clster de Kafka.
Figura 6-1. Raspberry Pi 2 Modelo B conectada a un biodispositivo mediante un adaptador USB RS232
La Raspberry, que corre el sistema operativo Raspbian, debe contar con la ltima versin del software DDA,
encargado de establecer la comunicacin con los biodispositivos implicados.
Figura 6-2. Mdulo DDA desplegado en la Raspberry
Una vez se tiene preparada la Raspberry, debemos asegurarnos de que Base de Datos y clster Kafka estn
arrancados y funcionando adecuadamente.
147
148 Validacin
Figura 6-3. Entorno de desarrollo SQL conectado correctamente a la base de datos
Figura 6-4. Nodos Zookeeper, Broker 1 y Broker 2 arrancados sobre una misma mquina Windows
Con todo preparado, basta con arrancar DDA ejecutando el fichero start.sh ubicado en la carpeta bin de la
solucin. Inmediatamente, podemos comprobar cmo arranca la aplicacin, mostrando por el log las incidencias
que ocurran de acuerdo a su configuracin.
Figura 6-5. Log de ejecucin, en modo Debug, de DDA en la Raspberry
De igual forma, los distintos nodos de Kafka indican por consola que la Raspberry est activa y enviando datos:
148
Figura 6-6. Log de un Broker Kafka
Con lo anterior ya se estn recopilando datos, que se envan al clster, para que puedan ser recibidos por otros
mdulos de este proyecto o de terceros. Para comprobar que la comunicacin mediante Kafka es correcta, vamos
a arrancar los otros dos componentes que conforman la aplicacin.
Primero se inicia la aplicacin SAVER, ejecutando el fichero jar correspondiente en cualquier mquina
Windows o Linux.
Figura 6-7. Log de SAVER
Comprobamos que la aplicacin arranca correctamente e introduce datos procedentes de la Raspberry en la tabla
CONSTANT_INFO de la base de datos, aplicando el filtro temporal que est actualmente indicado la tabla de
parmetros (5 minutos).
Figura 6-8. Tabla CONSTANT_INFO con datos insertados por SAVER
149
150 Validacin
Para terminar, arrancamos la aplicacin Chart y comprobamos que podemos visualizar la informacin
biomdica recuperada por DDA y la Raspberry a tiempo real.
Figura 6-9. Ejecucin de Chart, en la que podemos ver datos (simulados) a tiempo real
Las operaciones realizadas hasta ahora abarcan un ciclo completo de funcionamiento del conjunto de
aplicaciones software y componentes hardware que componen este proyecto.
Resumen de la validacin
A partir de lo expuesto en el presente captulo se puede concluir que se ha creado una solucin completamente
funcional que satisface no solo la necesidad de recuperacin de las constantes clnicas de los pacientes medidas
con biodispositivos, sino que tambin abarca la centralizacin y puesta a disposicin de dicha informacin a
aplicaciones propias del proyecto o de terceros. Por tanto, la primera conclusin no puede ser ms positiva, a la
espera de abordar con ms detalle este punto, junto a las lneas futuras de mejora, en el ltimo captulo.
150
7 PLANIFICACIN
L
levar a cabo un proyecto como el presentado en esta memoria implica trabajar con numerosos frentes y
una amplia variedad de tecnologas distintas. Aunque es sencillo dividir todos los mdulos y componentes
(tanto hardware como software) que conforman el proyecto en tres sectores o categoras (integracin con
biodispositivos, almacenamiento / intercambio y visualizacin de la informacin clnica) no conviene olvidarse
que el ncleo central es la comunicacin con los biodispositivos para recuperar las constantes mdicas del
paciente. Esta tarea es, sin duda, la ms compleja de cuantas abarca el proyecto, pues implica una importante
labor de documentacin, investigacin, desarrollo y pruebas. Parece evidente entender que una planificacin
adecuada del proyecto debe dimensionar las distintas partes del mismo de acuerdo a su complejidad, no
escatimando en recursos para el anlisis y estudio inicial. En todo proyecto de innovacin partir de una base
adecuada es fundamental: cometer cualquier error de enfoque o anlisis puede provocar que el trabajo realizado
no llegue nunca a buen puerto. Es por estos motivos por los que se ha apostado decisivamente por dotar de
mayor importancia a la fase de pre desarrollo y a todo aquello relacionado con la integracin con biodispositivos
en la planificacin del proyecto realizada, la cual pasaremos a comentar a continuacin.
Fases de la planificacin
Para abordar la planificacin del proyecto vamos a dividir todas las tareas que se deben realizar / se han realizado
en seis grupos o fases:
Planteamiento del proyecto: primera fase en la que se define el proyecto a realizar, estableciendo una propuesta
concreta y elaborando los objetivos a cumplir. La mayor parte del tiempo dedicado a esta fase se emplea en
documentarse adecuadamente acerca del mundo de la IoT (Internet of Things) aplicado a la medicina,
recuperando la informacin necesaria como para entender las necesidades actuales del mercado. Solo cuando
esa etapa ha concluido y disponemos de la cantidad de informacin adecuada tiene sentido plantear una
propuesta completa de aplicacin IoMT (Internet of Medical Things) para la monitorizacin de bioseales.
Figura 7-1. Planificacin Planteamiento
Fase de anlisis: es la parte ms importante de todo proyecto de innovacin. Abarca todos los anlisis y estudios
necesarios para determinar qu caminos y estrategias se han de seguir para poder realizar el proyecto planeado,
s es posible hacerlo.
Figura 7-2. Planificacin Fase de anlisis
151
152 Planificacin
Esta fase se inicia con un estudio completo de las alternativas existentes en el mercado y en la comunidad de
cdigo libre al proyecto que se pretende realizar. Como resultado de lo anterior, se deben tratar inmediatamente
despus todas las cuestiones relacionadas con los protocolos propietarios, pues ellos determinan el enfoque que
se ha de tomar en el desarrollo posterior. Tras esta fase, dedica a analizar en exclusiva todos los elementos
implicados en la integracin, se pasa a estudiar los elementos que solo se tratarn sector del almacenamiento e
intercambio de datos. En ese punto, con toda la informacin recopilada hasta ahora a disposicin de futuros
anlisis, es el momento de plantear cmo sern las aplicaciones software que se van a desarrollar en este proyecto
y que debern relacionarse con los elementos vistos hasta ahora.
Prueba de concepto: en este proyecto se ha denominado como pre desarrollo o prueba de concepto a una fase
intermedia entre el anlisis y el desarrollo en s. En ella se deben poner en prctica las ideas planteadas durante
los estudios y anlisis ya realizados para comprobar que el desarrollo del proyecto es posible. Esta tarea incluye
la realizacin de un primer prototipo de DDA (Device Data Acquisition) que simplemente pruebe que es posible
establecer la comunicacin con los biodispositivos y acceder a la informacin medida por los mismos. Para ello
se han dedicado varios das a configurar adecuadamente el hardware de integracin, algo que abarca instalar el
sistema operativo, drivers, mquina virtual de Java, etc. La fase concluye satisfactoriamente con la realizacin
de la prueba.
Figura 7-3. Planificacin Prueba de concepto
Desarrollo: es la fase central del proyecto, en la que se implementa la solucin planeada para cumplir los
objetivos marcados. Dada la complejidad y diversidad de elementos implicados en este proyecto se ha dividido
en dos: arquitectura, que trata la instalacin, configuracin y parametrizacin de componentes como la base de
datos o el clster de servidores de colas de mensajes, y el desarrollo de las aplicaciones en s.
Figura 7-4. Planificacin Desarrollo I
La primera parte del desarrollo se centra en disear la arquitectura del proyecto, las bases sobre las que construir
las aplicaciones software que necesitamos para satisfacer los objetivos que nos hemos marcado. Esto implica en
primer lugar tener claro cmo se van a relacionar todos y cada uno de los elementos que intervendrn en el
proyecto. Con esto sobre la mesa hay que dedicarse a la tarea de instalar y configurar la base de datos, lanzar los
scripts necesarios para parametrizarla convenientemente; as como instalar y preparar los nodos Zookeeper y
Brokers de Kafka. Como ltima etapa del diseo de la arquitectura se trata la estructura bsica que deber tener
el software, separando adecuadamente los proyectos para apostar por una modularizacin adecuada.
152
Figura 7-5. Planificacin Desarrollo II
A esta fase se llega habiendo planteado ya los proyectos que compondrn nuestro software. En este punto se
tienen ya claros qu proyectos sern libreras, cuales aplicaciones y cuales meros proyectos Maven que nos
sirvan para agrupar otros mdulos, dependencias y lgicas de construccin comunes. Como se observa, esta es
la fase que ms tiempo requiere con diferencia, pues implica plasmar sobre el cdigo todas las ideas planteadas
hasta el momento. El orden en el que se abordan los componentes del software se basa en la idea de construir
primero las bases (los proyectos denominados core), para ir, poco a poco, trabajando sobre ellas para desarrollar
las libreras ms complejas. Como ya ocurra en otras etapas, existen momentos de solapamiento, pues la enorme
relacin entre todos ellos ha provocado que se descubrieran errores de cdigo o incluso de planteamiento en
algunos mdulos al empezar el desarrollo de otros relacionados. Antes de comentar la fase final es importante
destacar que toda etapa incluye la realizacin de pruebas unitarias.
Postdesarrollo: fase de validacin, pruebas, correcciones y realizacin de una memoria que permita plasmar
todo lo realizado para este proyecto.
Figura 7-6. Planificacin Postdesarrollo
La fase final del proyecto se inicia con una etapa de pruebas integradas, en las que se mezclan todos y cada uno
de los componentes hardware y software que componen el proyecto para comprobar que no existen errores en
el cdigo diseado. De igual forma, se buscan y abordan los posibles puntos de mejora y optimizacin en la
solucin realziada, de cara a generar la primera versin estable del proyecto. La primera versin estable del
proyecto pasa por una etapa de validacin, en la que se comprueba qu objetivos inicales se han cumplido, cuales
no y bajo qu argumentos. Tras esto, solo queda la redaccin de la presente memoria que de cuerpo y documente
adecuadamente todo el trabajo realizado.
Resumen de la planificacin
Durante algo ms de siete meses se ha planteado, analizado, desarrollado, probado y documentado
adecuadamente el proyecto Desarrollo de aplicacin IoMT sobre Raspberry Pi para monitorizacin de datos
biomdicos. Se ha partido siempre de la necesidad de satisfacer los requisitos u objetivos iniciales marcados en
el planteamiento del proyecto, siendo tarea del prximo capitulo estudiar el estado de los objetivos una vez
cumplida la planificacin aqu comentada.
153
154 Planificacin
154
8 CONCLUSIONES Y LNEAS FUTURAS
A
lo largo de esta memoria se ha detallado el proyecto realizado: un conjunto de aplicaciones informticas
programadas en Java y centradas en la informacin biomdica del paciente. En torno a estos datos,
recuperados mediante una aplicacin que corre sobre una Raspberry Pi, se ha diseado una arquitectura
robusta, permitiendo construir sobre estas bases otras aplicaciones o mdulos para la suite. Para ello, se ha optado
por una gran modularizacin, dividiendo las distintas funcionalidades en pequeos proyectos que puedan ser
empleados por aplicaciones actuales o futuras con facilidad y evitando duplicar desarrollos. Desde el principio
se ha trabajado teniendo en mente una idea clara: no se est diseado una aplicacin, sino una arquitectura, una
suite sobre la que sea posible construir el mayor nmero posible de proyectos diferentes. En este camino, ha sido
imprescindible apoyarse en tecnologas consolidadas (Maven, Oracle Database, JPA + Hibernate) pero tambin
se ha apostado por herramientas en fase de desarrollo temprano, algo ineludible al tratarse de un proyecto tan
enfocado a la innovacin. La necesidad de dar una solucin seria y realista a la cuestin del almacenamiento e
intercambio de las variables clnicas de los pacientes ha requerido el diseo de un clster propio de servidores
de intercambio de mensajes, apoyado sobre la nueva (y cada vez ms popular) herramienta de Apache, Kafka.
Esta decisin no solo ha dotado de ms enjundia al proyecto, permitindole abarcar algunos aspectos ms
alejados de la programacin pura, sino que tambin ha sido vital para cumplir con la condicin base del proyecto,
garantizando una arquitectura realmente preparada para crecer y abarcar nuevos productos. Junto a todo esto, y
para ofrecer un conjunto de programas reales, con capacidad de competir en el mundo real, se ha diseado una
pequea base de datos, cerrando el crculo que nos permite hablar de una verdadera suite de aplicaciones. Esto
se ha llevado hasta el extremo de disear una pequea (y simple) aplicacin visual que permitiera mostrar a los
interesados las interesantes aplicaciones prcticas que este proyecto puede tener en la vida real y la facilidad con
la que podran extenderse sus funcionalidades gracias a un planteamiento modular.
Por otra parte, no se ha abordado las implementaciones de los protocolos propietarios empleados en la
comunicacin con los biodispositivos. Esto hubiera implicado que el proyecto se centrara solo en ese proyecto,
provocando que se quedaran fueran otros aspectos ms interesantes como podran haber sido la creacin de una
arquitectura multiaplicacin o la construccin de un sistema de intercambio de informacin mediante un clster
de servidores. En el captulo dedicado al estado del arte, a las posibilidades punteras que existen en la comunidad
y el mercado de ha hablado de aplicaciones de cdigo abierto que implementan alguno de estos protocolos,
pudiendo servir al lector interesado de punto de acceso a informacin ms profunda sobre este tipo de protocolos.
Conclusiones
Con todo lo comentado anteriormente tenemos informacin ms que suficiente para comprobar el estado de los
objetivos que nos marcamos al inicio del proyecto:
- La solucin aqu diseada gira entorno a las bioseales de los pacientes, recuperadas a travs de una
placa hardware (Raspberry Pi 2) y un software especfico.
- La utilizacin de Kafka permite que todas las aplicaciones que as lo deseen puedan acceder fcilmente
a los datos, sin ms que subscribirse al clster. Esto ha quedado probado con los mdulos SAVER y
CHART, que se comportan como aplicaciones independientes completamente separadas de DDA.
- Como consecuencia de lo anterior, las constantes clnicas del paciente se convierten en fuente de
informacin para un conjunto ampliable de aplicaciones del proyecto, o incluso de terceros si se
establece un protocolo para su conexin con nuestro clster de colas de mensajes.
- Para ejemplificar que la informacin recuperada se realiza correctamente y se centraliza, estando
disponible en tiempo real para cualquiera que quiera acceder a ella se ha diseado el mdulo CHART.
- El clster de servidores gestionado por Kafka es lo suficientemente verstil como para no limitar las
aplicaciones que quieran acceder a la informacin. Esto s ocurrira si solo hubiramos apostado por
una base de datos, ya que las bases de datos SQL no se comportan adecuadamente como fuente de
informacin de sistemas big data. Con la arquitectura diseada no se limita la posible implantacin de
155
156 Conclusiones y lneas futuras
un sistema big data sobre el proyecto diseado, requisito que se haba marcado antes del inicio del
proyecto.
- Adems, se ha estudiado la posibilidad de permitir a alguna aplicacin (propia o de terceros) modificar
el comportamiento de los biodispositivos. A pesar de haber optado por implementar los protocolos
propietarios que fueran necesarios, ms proclives a esta funcionalidad que el estndar HL7 (Health
Level Seven), no se ha encontrado una cantidad mnima de protocolos que soporten esta caracterstica
ni un conjunto de acciones comunes o habituales. Por tanto, este objetivo se ha descartado.
En resumen, el desarrollo del proyecto puede considerarse ampliamente satisfactorio, al haberse cumplido la
prctica totalidad de los objetivos marcados durante el planteamiento del mismo. La solucin desarrollada cubre
la recuperacin de la informacin biomdica de los pacientes medida mediante biodispositivos, siendo capaz de
centralizarla y ponerla a disposicin de cualquier aplicacin que pretenda visualizarla, explotarla, etc.
Lneas futuras
Enfocados a la creacin de una aplicacin robusta, han aparecido a lo largo de esta memoria distintas
funcionalidades interesantes que no han podido ser abordadas en este proyecto, algo lgico al tratar con un sector
tan extenso y complejo como el sanitario. Estas nuevas caractersticas, posibles nuevos proyectos a construir
sobre las bases aqu montadas, abarcan desde pequeos cambios o mejoras en el planteamiento hasta ideas que
implicaran nuevas aplicaciones, generalmente de gran complejidad.
En la primera categora surgen varias posibilidades: realizar un tratamiento adecuado de las unidades en las que
se reciben las variables clnicas (algo que en lo que no se repara en el momento actual) o tener en cuenta las
posibles tcnicas empleadas en la medicin, algo que condiciona sin atisbo de duda el resultado obtenido.
La segunda categora abre ms posibilidades, las cuales adems implican proyectos tan interesantes o ms al
aqu comentado. Si se buscara continuar este trabajo hacia una solucin implantarle en centros sanitarios reales
sera necesario desarrollar un programa de integracin con el estndar HL7, para cubrir tres funciones
tremendamente tiles: recuperar la informacin de los dispositivos que lo empleen, poder enviar informacin en
este formato a terceros y emplear los mensajes recibidos como fuente de datos para poblar la base de datos.
Dentro de la misma lgica, aunque yendo un paso ms all, sera necesario construir un visualizador de datos
ms potente, desarrollado probablemente en alguna tecnologa front-end como Javascript, a ser posible
combinndolo con una aplicacin de historia clnica propia u ofreciendo integracin con alguna opcin de
cdigo libre existente en el mercado. Si pretendemos disear una suite de aplicaciones sanitarias en torno a los
datos clnicos del paciente es absurdo plantear que la informacin recuperada pueda mostrarse totalmente
disociada de otros valores imprescindibles como el diagnstico del paciente, los resultados de sus ltimos
estudios, los informes realizados por los distintos profesionales sanitarios que lo han atenido, etc. Hasta ahora
se han comentado mejores destinadas a obtener ms informacin del paciente y a ofrecerla de la forma ms
completa e integrada posible, pero no se ha seguido ahondando en las posibilidades que nos ofrece tener
informatizadas y centralizadas las constantes clnicas de muchos pacientes. No cuesta mucho imaginar un
escenario en el que toda esta informacin pueda ser explotada, tanto como fuente para estudios de profesionales
sanitarios como por un motor de big data que permita sacar estadsticas, reconocer patrones o incluso facilitar
la labor a los facultativos a partir de todo lo anterior. Esta ltima posibilidad se ve adems reforzada por el amplio
uso de Kafka como fuente de datos para productos de tratamiento masivo de datos.
156
REFERENCIAS
[1] Health Level Seven International, HL7, [En lnea]. Available: http://www.hl7.org/. [ltimo acceso:
Enero 2016].
[2] IHE International, Integrating the Healthcare Enterprise, [En lnea]. Available: http://www.ihe.net/.
[ltimo acceso: Enero 2016].
[3] Capsule Tech, Inc, SmartLinx, 06 2016. [En lnea]. Available: http://www.capsuletech.com/integration.
[4] Capsule Tech Inc, SmartLinx Axon, [En lnea]. Available: http://webinfo.capsuletech.com/smartlinx-
axon-product-brief. [ltimo acceso: 06 2016].
[5] Capsule Tech, Inc., SmartLinx Vitals Stream, [En lnea]. Available:
http://webinfo.capsuletech.com/smartlinx-vitals-stream-product-brief. [ltimo acceso: 06 2016].
[6] Capsule Tech, Inc, SmartLinx Client, [En lnea]. Available: http://webinfo.capsuletech.com/medical-
device-integration-smartlinx-client. [ltimo acceso: 06 2016].
[7] Capsule Tech, Inc, SmartLinx IQ, [En lnea]. Available: http://www.capsuletech.com/medical-device-
data-analytics. [ltimo acceso: 06 2016].
[8] Piscis Clinical Solutions, Hawkeye, [En lnea]. Available: http://www.picis.com/medical-device-

integration.html. [ltimo acceso: 06 2016].
[9] The OpenICE Team, OpenICE, [En lnea]. Available: https://www.openice.info. [ltimo acceso: 05
2016].
[10] MD PnP Program, MD PnP, [En lnea]. Available: http://www.mdpnp.org/. [ltimo acceso: 05 2016].
[11] ASTM International, ASTM final F-2761 - ICE Standard, [En lnea]. Available:
http://www.mdpnp.org/uploads/F2761_completed_committee_draft.pdf. [ltimo acceso: 06 2016].
[12] Real-Time Innovations, RTI DDS, [En lnea]. Available: https://www.rti.com/products/dds/. [ltimo
acceso: 06 2016].
[13] RASPBERRY PI FOUNDATION, Raspberry Pi 2, [En lnea]. Available:

https://www.raspberrypi.org/products/raspberry-pi-2-model-b/. [ltimo acceso: 01 2016].
[14] JAGUAR ELECTRONIC H.K. CO. Ltd , Jaguar One, [En lnea]. Available:
http://www.jaguarboard.org/index.php/products/buy/jaguarboard/207/jaguarboard-
detail.html#specification. [ltimo acceso: 05 2016].
[15] Shenzhen Xunlong Software CO.,Limited, Orange Pi One, [En lnea]. Available:
http://www.orangepi.org/orangepione/. [ltimo acceso: 05 2016].
[16] Hardkernel co., Ltd., ODROID-C1+, [En lnea]. Available:

http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143703355573. [ltimo acceso: 05
2016].
[17] SolidRun Ltd., HummingBoard, [En lnea]. Available: https://www.solid-run.com/freescale-imx6-

family/hummingboard/. [ltimo acceso: 05 2016].
[18] BeagleBoard.org Foundation, BeagleBoard Black, [En lnea]. Available: https://beagleboard.org/black.

[ltimo acceso: 05 2016].
[19] CubieBoard, CubieBoard5, [En lnea]. Available: http://cubieboard.org/model/. [ltimo acceso: 05

2016].
[20] LinkSprite, pcDuino4, [En lnea]. Available: http://www.linksprite.com/linksprite-pcduino/. [ltimo

acceso: 05 2016].
[21] The Raspberry Foundation, Raspbian, [En lnea]. Available: https://www.raspbian.org/. [ltimo
acceso: 05 2016].
[22] Canonical Ltd, Ubuntu MATE, [En lnea]. Available: https://ubuntu-mate.org/raspberry-pi/. [ltimo
acceso: 06 2016].
[23] Canonical Ltd, Snappy Ubuntu Core for Raspberry Pi, [En lnea]. Available:
https://developer.ubuntu.com/en/snappy/start/#snappy-raspi2. [ltimo acceso: 05 2016].
[24] Microsoft Corporation, Windows 10 IoT Core, [En lnea]. Available: http://ms-iot.github.io/content/en-
US/Downloads.htm. [ltimo acceso: 05 2016].
[25] RISC OS Open Limited, RISC OS for the Raspberry Pi, [En lnea]. Available:
https://www.riscosopen.org/content/downloads/raspberry-pi. [ltimo acceso: 06 2016].
[26] The Apache Software Foundation, Apache Kafka, [En lnea]. Available: http://kafka.apache.org/.
[27] The Apache Software Foundation!, Kafka Log Compaction, [En lnea]. Available:
https://cwiki.apache.org/confluence/display/KAFKA/Log+Compaction. [ltimo acceso: 06 2016].
[28] Pivotal Software, Inc, RabbitMQ, [En lnea]. Available: https://www.rabbitmq.com/. [ltimo acceso:
06 2016].
[29] solid IT gmbh, DB-Engines Ranking, [En lnea]. Available: http://db-engines.com/en/ranking. [ltimo
acceso: 06 2016].
[30] Oracle Corporation, Oracle Database, [En lnea]. Available:

https://www.oracle.com/es/database/index.html. [ltimo acceso: 06 2016].
[31] Oracle Corporation, MySQL, [En lnea]. Available: http://www.mysql.com/. [ltimo acceso: 06 2016].
[32] Microsoft Corporation, SQL Server, [En lnea]. Available: https://www.microsoft.com/es-es/server-

cloud/products/sql-server/. [ltimo acceso: 06 2016].
[33] Oracle Corporation, SQL Developer, [En lnea]. Available:

http://www.oracle.com/technetwork/developer-tools/sql-developer/overview/index.html. [ltimo acceso:
06 2016].
[34] Dell, Inc, TOAD, [En lnea]. Available: http://www.toadworld.com/. [ltimo acceso: 05 2016].
[35] Oracle Corporation, Java, [En lnea]. Available: https://www.java.com/. [ltimo acceso: 07 2015].
[36] Python Software Foundation, Python, [En lnea]. Available: https://www.python.org/. [ltimo acceso:
06 2016].
[37] Red Hat, Inc., Hibernate, [En lnea]. Available: http://www.hibernate.org/. [ltimo acceso: 06 2016].
[38] Eclipse Foundation, EclipseLinik, [En lnea]. Available: http://www.eclipse.org/eclipselink/. [ltimo

acceso: 06 2016].
[39] Apache Software Foundation, OpenJPA, [En lnea]. Available: http://openjpa.apache.org/. [ltimo
acceso: 06 2016].
[40] The Querydsl Team, Mysema Oy, QueryDSL, [En lnea]. Available: http://www.querydsl.com/.
[41] Apache Software Foundation, iBatis, [En lnea]. Available: http://ibatis.apache.org/. [ltimo acceso: 06
2016].
[42] Apache Software Foundation, Ant, [En lnea]. Available: http://ant.apache.org/. [ltimo acceso: 06
2016].
[43] Apache Software Foundation, Maven, [En lnea]. Available: https://maven.apache.org/. [ltimo acceso:
06 2016].
[44] Heavybit, Inc, Gradle, [En lnea]. Available: http://www.gradle.org/. [ltimo acceso: 06 2016].
[45] ZeroTurnaround, Java Tools & Technologies Landscape, 2014.
[46] Eclipse Foundation, Eclipse, [En lnea]. Available: https://eclipse.org. [ltimo acceso: 07 2015].
[47] Eclipse Foundation, SWT, [En lnea]. Available: https://wiki.eclipse.org/SWT. [ltimo acceso: 07
2015].
[48] Eclipse Foundation, JFace, [En lnea]. Available: https://wiki.eclipse.org/JFace. [ltimo acceso: 07
2015].
[49] Eclipse Foundation, JDT, [En lnea]. Available: https://wiki.eclipse.org/JDT. [ltimo acceso: 07 2015].
[50] JetBrains, IntelliJ IDEA, [En lnea]. Available: https://www.jetbrains.com/idea/. [ltimo acceso: 07
2015].
[51] InfoWorld, Top Java programming tools, [En lnea]. Available:

http://www.infoworld.com/article/2683534/development-environments/infoworld-review--top-java-
programming-tools.html. [ltimo acceso: 07 2015].
[52] Oracle Corporation, [En lnea]. Available: https://netbeans.org/. [ltimo acceso: 07 2015].
[53] Oracle Corporation, JDeveloper, [En lnea]. Available: http://www.oracle.com/technetwork/developer-

tools/jdev/overview/index-094652.html. [ltimo acceso: 07 2015].
[54] The Apache Software Foundation. , Hadoop, [En lnea]. Available: http://hadoop.apache.org/. [ltimo
acceso: 05 2016].
[55] Health Level Seven Inc, Especificacin MLLP, [En lnea]. Available:
http://www.hl7.org/documentcenter/public_temp_73F3EA42-1C23-BA17-
0C011D0AAF40F217/wg/inm/mllp_transport_specification.PDF. [ltimo acceso: 06 2016].
[56] Oracle Corporation, Oracle FAQ - Tablespaces, [En lnea]. Available:

http://www.orafaq.com/wiki/Tablespace#Default_tablespaces. [ltimo acceso: 02 2016].
[57] Oracle Corporation, Oracle FAQ - Profiles, [En lnea]. Available:

http://www.orafaq.com/wiki/Profiles_and_password_management. [ltimo acceso: 03 2016].
[58] Oracle Corporation, Oracle Help Center - Database Link, 03 2016. [En lnea]. Available:
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5005.htm.
[59] Oracle Corporation, Oracle Healp Center - Sequences, [En lnea]. Available:
https://docs.oracle.com/cd/B28359_01/server.111/b28310/views002.htm. [ltimo acceso: 03 2016].
[60] Oracle Corporation, Oracle Help Center - Indexes, [En lnea]. Available:
https://docs.oracle.com/cd/E11882_01/server.112/e40540/indexiot.htm#CNCPT721. [ltimo acceso: 03
2016].
[61] Oracle Corporation, Ask Tom - Indexes on foreign keys, [En lnea]. Available:
https://asktom.oracle.com/pls/asktom/f?p=100:11:::::P11_QUESTION_ID:292016138754. [ltimo
acceso: 03 2016].
[62] Oracle Corporation, Oracle Help Center - Grant, [En lnea]. Available:
https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_9013.htm. [ltimo acceso: 03
2016].
[63] The Apache Software Foundation, Kafka Download, [En lnea]. Available:
http://kafka.apache.org/downloads.html. [ltimo acceso: 05 2016].
[64] The Apache Foundation, Zookeeper Configuration, [En lnea]. Available:

https://zookeeper.apache.org/doc/r3.3.2/zookeeperAdmin.html#sc_configuration. [ltimo acceso: 05
2016].
[65] The Apache Foundation, Apache Kafka: Broker Configuration, [En lnea]. Available:
http://kafka.apache.org/documentation.html#brokerconfigs. [ltimo acceso: 05 2016].
[66] The Apache Foundation, Topic Configuration, [En lnea]. Available:

http://kafka.apache.org/documentation.html#topic-config. [ltimo acceso: 05 2016].
[67] The Apache Software Foundation, Maven Central Repository, [En lnea]. Available:
https://repo1.maven.org/maven2/. [ltimo acceso: 05 2016].
[68] Oracle Corporation, DAO, [En lnea]. Available:

http://www.oracle.com/technetwork/java/dataaccessobject-138824.html. [ltimo acceso: 05 2016].
[69] Red Hat, Inc., Hibernate CacheConcurrencyStrategy, [En lnea]. Available:

https://docs.jboss.org/hibernate/orm/3.2/api/org/hibernate/cache/ReadWriteCache.html. [ltimo acceso:
05 2016].
[70] The Apache Foundation, JPA Transaction Type, [En lnea]. Available: http://tomee.apache.org/jpa-
concepts.html. [ltimo acceso: 05 2016].

PFC Alfredo E SÃ¡ez PÃ©rez de La Lastra

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PFC Alfredo E SÃ¡ez PÃ©rez de La Lastra

Hochgeladen von

Copyright:

Verfügbare Formate

Proyecto Fin de Carrera

Desarrollo de aplicacin IoMT sobre Raspberry Pi

Autor: Alfredo Enrique Sez Prez de la Lastra

Equation Chapter 1 Section 1

Departamento de Ingeniera Telemtica

Desarrollo de aplicacin IoMT sobre Raspberry Pi

Departamento de Ingeniera Telemtica

Almacenamiento e intercambio de la informacin procedente de dispositivos

Visualizacin de las constantes biomdicas del paciente

Diagrama de componentes implicados

Figura 2-1. Primer esquema general del proyecto

- Software de recoleccin: se ejecutar sobre un hardware de integracin con biodispositivos

En resumen, MEDIPi se compondr de tres aplicaciones software, un hardware de integracin con

3 SOLUCIONES IOMT ALTERNATIVAS

Figura 3-1. Esquema de SMARTLINX, de Capsule Tech, Inc

La empresa lder en soluciones de centralizacin e integracin de datos procedentes de biodispositivos mdicos

Figura 3-2. Modelos de la serie SmartLinx Axon

Figura 3-3. SmartLinx IQ

Figura 3-4. Logo de HAWKEYE, de la compaa Picis Clinical Solutions

Figura 3-5. Interfaz de usuario de HAWKEYE con las constantes de un paciente.

Figura 3-6. ASTM F-2761 vs implementacin de OpenICE

Figura 3-7. Interfaz Supervisor de OpenICE

Figura 3-8. Interfaz Dispositivo OpenICE

Resumen de las soluciones IoMT alternativas

4.1.2 Anlisis de alternativas

SBC Procesador Almacenamiento RAM Conectividad Precio

ARM Cortex 4 USB 2.0,

ARM A8 1 Ghz 1 USB 2.0,

ARM A7 4 2 USB 2.0,

Sistema Operativo del Hardware de integracin

4.2.2 Anlisis de alternativas

Figura 4-1. Catlogo de Sistemas Operativos para la Raspberry Pi 2

- OSMC / LibreElec: sistemas operativos enfocados a convertir la Raspberry Pi en centros multimedia.

Clster de servidores de mensajes

4.3.2 Anlisis de alternativas

4.3.2.1 Apache Kafka

Figura 4-2. Logo de Apache Kafka

Figura 4-3. Arquitectura bsica Java

Figura 4-4. Consumicin de mensajes del clster

Figura 4-5. Topics y particiones en Kafka

Figura 4-6. Logo RabbitMQ

4.4.2 Anlisis de alternativas

Figura 4-7. Ranking de bases de datos de DB-Engines.

Figura 4-8. Logo Oracle Database

Figura 4-9. Logo MySQL

4.4.2.3 SQL Server

Figura 4-10. Logo SQL Server

Entorno de desarrollo para BBDD

4.5.2 Anlisis de alternativas

4.5.2.1 Oracle SQL Developer

Figura 4-11. Logo SQL Developer

Figura 4-12. Interfaz grfica SQL Developer

Figura 4-13. Logo de TOAD

4.6.2 Anlisis de alternativas

Figura 4-14. Logo de Java

Figura 4-15. Plataformas Java

Figura 4-16. Logo de Python

de Python Guido Van Rossum trabaja para Google.)

4.7.2 Anlisis de alternativas

4.7.2.1 Bajo nivel de abstraccin

Figura 4-17. Logo de JDBC

4.7.2.2 ORM: Object-Relational mapping

4.7.2.2.1 Motor ORM