Download Monitorizacion de Tareas del Proyecto Previrnec

Departament d’Enginyeria Informàtica i M atemàtiques
Monitorización de Tareas del Proyecto Previrnec
Proyecto Final de Carrera
TITULACIÓN: Ingeniería Informática
AUTOR: Carles Anglés Tafalla
DIRECTOR: Maria Ferré Bergadà
FECHA: Septiembre / 2009
Monitorización de Tareas del Proyecto Previrnec
2
Monitorización de Tareas del Proyecto Previrnec
Índice
1 Introducción ............................................................................................................7
2
3
4
5
1.1 Investigación clínica del Instituto Guttmann.........................................................7
1.1.1 Contenidos terapéuticos basados en mundos virtuales...............................7
1.1.2 Telerehabilitación: motorización de contenidos terapéuticos ....................8
1.1.3 Resumen .....................................................................................................8
1.2 Proyecto PREVIRNEC..........................................................................................9
1.2.1 Plataforma Previrnec ..................................................................................9
1.2.2 Aplicación Web-Servidor Previrnec...........................................................9
1.2.3 Aplicación Cliente 2D/3D Previrnec..........................................................10
1.2.4 Comunicación entre Aplicación Cliente y Aplicación Web-Servidor .......10
Objetivos del proyecto .........................................................................................11
Tecnologías usadas ................................................................................................12
3.1 Java 2 Standard Edition.........................................................................................12
3.1.1 Java.awt ......................................................................................................12
3.1.2 Javax.swing ................................................................................................12
3.1.3 Java 2D .......................................................................................................13
3.2 Servicios Web XML-RPC.....................................................................................13
3.3 Java Web Start.......................................................................................................13
3.4 Eclipse ...................................................................................................................14
Análisis ......................................................................................................................15
4.1 Conocimientos previos ..........................................................................................15
4.1.1 Tareas Terapéuticas ....................................................................................15
4.1.2 Aplicación Cliente ......................................................................................17
4.1.3 Diseño de la Aplicación Cliente .................................................................18
4.2 Requisitos de la Aplicación Cliente ......................................................................19
4.2.1 Tipos de usuarios ........................................................................................19
4.2.2 Requisitos funcionales de los pacientes......................................................20
4.2.3 Requisitos funcionales generales................................................................20
4.2.4 Requisitos no funcionales...........................................................................20
4.2.5 Diagrama de casos de uso del paciente ......................................................20
4.3 Requisitos del Visualizador...................................................................................21
4.3.1 Tipo de usuarios .........................................................................................21
4.3.2 Requisitos funcionales de los terapeutas ....................................................21
4.3.3 Requisitos funcionales generales................................................................21
4.3.4 Requisitos no funcionales...........................................................................22
4.3.5 Diagrama de casos de uso del terapeuta .....................................................22
4.4 Requisitos del Web-servidor .................................................................................23
4.4.1 Tipo de usuarios .........................................................................................23
4.4.2 Requisitos funcionales de los terapeutas ....................................................23
4.4.3 Requisitos funcionales del administrador...................................................23
4.4.4 Requisitos funcionales generales................................................................23
4.4.5 Diagrama de casos de uso del administrador .............................................23
4.4.6 Diagrama de casos de uso del Terapeuta....................................................24
Diseño .........................................................................................................................25
5.1 Arquitectura Aplicación Cliente............................................................................25
5.1.1 Clase Fullscreen..........................................................................................26
3
Monitorización de Tareas del Proyecto Previrnec
6
7
8
9
10
11
5.1.2 Clases DemoContext y Event .....................................................................27
5.1.3 Clases TaskInfo y ClientXmlRpc...............................................................28
5.2 Arquitectura del Visualizador ...............................................................................30
5.2.1 Clases DemoContext y Event .....................................................................31
5.2.2 Clase ThreadEventPublisher ......................................................................32
5.2.3 Clase Fullscreen..........................................................................................32
5.2.4 Clase DemoViewer.....................................................................................33
Desarrollo .................................................................................................................35
6.1 Aplicación Cliente.................................................................................................35
6.1.1 Captura de Eventos.....................................................................................35
6.1.2 Captura de aleatorios ..................................................................................36
6.1.3 Script de substitución .................................................................................37
6.1.4 Captura de la relación de aspecto ...............................................................37
6.1.5 Envío de la información capturada.............................................................38
6.2 Aplicación Visualizador ........................................................................................39
6.2.1 Inyección de eventos ..................................................................................39
6.2.2 Inyección de aleatorios ...............................................................................40
6.2.3 Dibujo del Telepointer................................................................................40
6.2.4 Distinción de eventos ................................................................................42
6.2.5 Controles del Visualizador .........................................................................44
6.2.6 Descarga de la información de la tarea.......................................................45
6.3 Servidor-Web ........................................................................................................46
6.3.1 Almacenamiento y recuperación de información.......................................46
6.3.2 Ejecución del Visualizador desde el Servidor-Web ...................................46
6.3.3 Cambios en la interfaz grafica de la web....................................................48
Evaluación ................................................................................................................49
Conclusiones ............................................................................................................51
Trabajo Futuro.......................................................................................................52
Manual de usuario.................................................................................................53
10.1 Manual de uso para el Administrador ...................................................................54
10.2 Manual de para el Terapeuta .................................................................................55
10.2.1 Activar la monitorización en una tarea.......................................................55
10.2.2 Monitorizar una tarea..................................................................................55
Bibliografía ..............................................................................................................58
4
Monitorización de Tareas del Proyecto Previrnec
Índice de figuras
Figura 1
Figura 2
Figura 3
Figura 4
Figura 5
Figura 6
Figura 7
Figura 8
Figura 9
Figura 10
Figura 11
Figura 12
Figura 13
Figura 14
Figura 15
Figura 16
Figura 17
Figura 18
Figura 19
Figura 20
Interacción Paciente y Terapeuta en Plataforma Previnec ...........................10
Imagen de la tarea 2D Puzzle Ejercicio........................................................17
Imagen de la Aplicación Cliente ..................................................................17
Diagrama de clases de la Aplicación Cliente ...............................................18
Diagrama de casos de uso de la Aplicación Cliente.....................................21
Diagrama de casos de uso del Visualizador .................................................22
Diagrama de casos de uso para Gestión de Tareas.......................................24
Diagrama de casos de uso para Consulta de Tareas .....................................24
Diagrama de clases de la nueva Aplicación Cliente.....................................25
Clase Fullscreen............................................................................................26
Clases Event y DemoContext .......................................................................27
Clases TaskInfo y ClientXmlRpc.................................................................28
Diagrama de clases del Visualizador............................................................30
Clases Event y DemoContext .......................................................................31
Clase ThreadEventPublisher ........................................................................32
Clase Fullscreen............................................................................................33
Clase DemoViewer.......................................................................................34
Problema de la estela de telepointers............................................................41
Telepointer....................................................................................................42
Controles del Visualizador ...........................................................................44
Índice de tablas
Tabla 1
Clasificación de las tareas terapéuticas ...........................................................16
5
Monitorización de Tareas del Proyecto Previrnec
6
Monitorización de Tareas del Proyecto Previrnec
1
Introducción
En la actualidad las diferentes tecnologías de la información y la comunicación se han
ido implantando en la mayoría de los sectores profesionales, facilitando nuevas formas de
organización más eficientes y adecuadas a sus necesidades. Uno de estos sectores es la
medicina, donde nace el concepto de telemedicina.
La telemedicina consiste en la prestación de servicios sanitarios a distancia mediante la
utilización de sistemas informáticos y de telecomunicación. Su objetivo principal se centra
en el desarrollo de nuevas aplicaciones que proporcionan un grado superior de movilidad a
los profesionales de la medicina y a los pacientes, facilitando la comunicación salvando
barreras de tiempo y distancia.
Dentro de este contexto se desarrolla el proyecto PREVIRNEC del Instituto
Guttmann, al cual forma parte el vigente proyecto de final de carrera.
1.1 Investigación clínica del Instituto Guttmann
El daño cerebral adquirido (DCA), ya sea producido por un accidente cerebro-vascular
o un traumatismo craneoencefálico, constituye un importante problema de salud en nuestra
sociedad actual. Las cifras de esta patología han experimentado un gran crecimiento en los
últimos años debido fundamentalmente a la alta siniestralidad vial, en la actualidad más de
300.000 personas afectadas en España según la Federación Española de Daño Cerebral.
Estas lesiones derivan en déficits cognitivos (atención, memoria, lenguaje, trastornos
emocionales, etc.), de aquí la importancia de los tratamientos de rehabilitación cognitiva.
Estos tratamientos deben estar enfocados al estilo de vida, necesidades y capacidades
actuales de la persona que requiere el tratamiento, lo que implica elaborar tratamientos
personalizados y buscar soluciones para aquellos pacientes con dificultades de movilidad
(ya sean físicas o de dependencia) que les impiden desplazarse a un centro de
rehabilitación.
El Instituto Guttmann, Hospital de Neurorehabilitación, dentro del programa de
investigación clínica, como Instituto Universitario adscrito a la Universidad Autónoma de
Barcelona, y con la colaboración del departamento de Universitats, Recerca i Societat de
la Informació de la Generalitat de Cataluña, investiga en el desarrollo de nuevos
tratamientos de rehabilitación cognitiva incorporando servicios telemáticos, con el fin de
mejorar la calidad de vida de estas personas.
1.1.1 Contenidos terapéuticos basados en mundos virtuales
La distancia que hay entre las actividades planteadas durante las sesiones terapéuticas y
las dificultades reales con las que se encuentran los pacientes después del tratamiento, es la
principal limitación de la rehabilitación cognitiva convencional. Parte de la investigación
clínica del Instituto Guttmann, se dedica al diseño y desarrollo de tareas terapéuticas en
mundos virtuales 3D y ejercicios en el mudo 2D, para tratar las diferentes disfunciones
neuro-cognitivas reduciendo la distancia entre la práctica clínica y la realidad cotidiana.
Todo ello junto a investigaciones en la implantación de algún tipo de aplicación
informática que permita a los pacientes realizar dichas tareas.
Las tareas 3D se refieren a reproducir situaciones reales a los pacientes, mediante el
desarrollo de realidades virtuales de espacios cotidianos a partir de gráficos en 3D para
7
Monitorización de Tareas del Proyecto Previrnec
ordenadores. Un ejemplo seria una cocina virtual donde el paciente tiene que realizar
diversas tareas, como guardar alimentos en la nevera o preparar una ensalada. Con tareas
como éstas, complejas de simular en entornos clínicos, el paciente puede trabajar su
capacidad de planificación, secuenciación y categorización, o el uso de la memoria.
Por otro lado las tareas 2D se refieren a ejercicios de diversa dinámica, diseñados para
estimular disfunciones cognitivas (atención, lenguaje, memoria, funciones ejecutivas, etc.)
en un contexto terapéutico, ejercicios de cálculo y retención de información, que se
visualizan a partir de gráficos 2D.
Una visión de futuro que se contempla dentro de la investigación clínica del Instituto
Guttmann, es explorar diferentes tipos de actividades que combinen los ejercicios 2D con
tareas 3D.
1.1.2 Telerehabilitación: motorización de contenidos terapéuticos
Muchos de los pacientes con disfunciones cognitivas presentan un problema añadido,
algún tipo de discapacidad física o de dependencia que les impide desplazarse a los centro
de rehabilitación. Actualmente existe una plataforma europea de teleasistencia para
pacientes discapacitados con lesiones cerebrales, congénita o adquirida, conocida como
EuroPaNet.
El proyecto EuroPaNet esta orientado a proporcionar tratamientos personalizados
utilizando la teleasistencia mediante videoconferencia, correo electrónico y entorno de
aplicaciones compartidas. Esta metodología permite la interacción entre el equipo
terapéutico y la familia facilitando el seguimiento del paciente a distancia, orientando,
asesorando y dando soporte a la familia en los problemas que puedan aparecer en la
reinserción familiar y social.
Una limitación que presenta la actual plataforma EuroPaNet es un bajo nivel de
motorización en la ejecución de las tareas de rehabilitación. Por este motivo uno de los
objetivos de la investigación clínica llevada a cabo por el Instituto Guttmann es el
desarrollo e implantación de una aplicación informática con todas las ventajas de la
teleasistencia, pero que además permita al paciente realizar tareas en mundos 3D y
ejercicios diseñados en 2D, en su propio domicilio o centros de rehabilitación, aplicando
técnicas de telerehabilitación. De esta manera se consigue monitorizar el proceso del
usuario mediante un seguimiento continuado y efectivo del tratamiento, pudiéndose
modificar el programa de rehabilitación en función de los resultados que éste obtiene.
1.1.3 Resumen
Para solventar las limitaciones que presentan las actuales terapias de rehabilitación
cognitiva convencional, que son tratamientos alejados de la realidad del paciente y no están
adaptados a las necesidades de pacientes con movilidad reducida, se inicia el Proyecto
PREVIRNEC. Este proyecto se desarrolla dentro del contexto de investigación clínica del
Instituto Guttmann, para desarrollar una plataforma de telerehabilitación para pacientes
con disfunciones neuro-cognitivas.
8
Monitorización de Tareas del Proyecto Previrnec
1.2 Proyecto PREVIRNEC
El objetivo principal de este proyecto es diseñar y desarrollar una plataforma para la
rehabilitación de pacientes con disfunciones neuro-cognitivas, producidas por daños
cerebrales adquiridos, la Plataforma Previrnec. Un sistema de telerehabilitación que
ofrezca a los terapeutas, generalmente neuropsicólogos, la posibilidad de elaborar planes
terapéuticos personalizados a modo de tareas 2D y 3D a través de Internet. Que permita
además, de forma automática, asignar programas de rehabilitación intensiva durante el
periodo de tiempo necesario, guardar los resultados y adecuar el nivel de dificultad de cada
tarea en función del rendimiento; ofreciendo al paciente la posibilidad de realizar el
tratamiento sin tener que desplazarse de su domicilio, y con la garantía de que todas las
tareas realizadas serán siempre en rango terapéutico.
El proyecto cuenta con un equipo multidisciplinar de investigadores en el que
participan un equipo del Instituto Guttmann, hospital de referencia en neurorehabilitación,
que aporta los conocimientos neuropsicológicos y terapéuticos necesarios, el Centro de
Investigación en Ingeniería Biomédica (CREB) de la Universidad Politécnica de Cataluña
(UPC), que se encarga de la parte del software ligado al desarrollo de mundos virtuales en
3D, y el grupo de Arquitecturas y Servicios Telemáticos (AST), del Departamento de
Ingeniería Informática y Matemáticas (DEIM), de la Universidad Rovira i Virgili (URV)
de Tarragona , que se encargan de la parte del software distribuido e implementación de
ejercicios en el mundo 2D.
1.2.1 Plataforma Previrnec
La Plataforma Previrnec, como solución software al proyecto Previrnec, esta diseña
para proporcionar un medio de interacción entre el Paciente y el Terapeuta. Esta formada
por dos aplicaciones diferentes que se comunican entre si vía Internet, una Aplicación
Cliente para el Paciente instalada de forma local en su ordenador personal o ordenadores
de los centros de rehabilitación, y una Aplicación Web-Servidor para los Terapeutas que
actúa como servidor para la Aplicación Cliente Previrnec del Paciente.
Para proporcionar una visión global del funcionamiento de la plataforma, a
continuación se explicara, sin profundizar, en que consisten las dos aplicaciones que la
conforman y como interactúan entre si. En posteriores capítulos se ira entrando en detalles
más técnicos y explicaciones más detalladas.
1.2.2 Aplicación Web-Servidor Previrnec
La Aplicación Web-Servidor permite a los Terapeutas planificar tratamientos
terapéuticos personalizados, sesiones diarias de tareas 2D y 3D disponibles en la
Aplicación Cliente Previrnec del Paciente. Además los terapeutas pueden realizar
seguimientos exhaustivos de los resultados obtenidos de dichas sesiones. Se trata de un
planificador automatizado de tareas, que permite que los propios terapeutas puedan adaptar
el grado de dificultad de cada tarea, a los resultados que van obteniendo los pacientes de
forma individualizada.
Esta diseñada para almacenar y procesar los resultados enviados por la Aplicación
Cliente Previrnec, obtenidos en la ejecución de las tareas pautadas en cada una de las
sesiones terapéuticas, de tal manera que la propia aplicación, de forma autónoma, puede
realiza ajustes en el grado de dificultad para parametrizar tareas especiales de rescate que
se ejecutarán en estas sesiones.
9
Monitorización de Tareas del Proyecto Previrnec
1.2.3 Aplicación Cliente 2D/3D Previrnec
La Aplicación Cliente cuenta con un amplio conjunto de tareas terapéuticas diseñadas
por los neuropsicólogos, a modo 2D y 3D. A través de esta aplicación los Pacientes podrán
realizar las diferentes tareas, pautadas con anterioridad por los terapeutas a través de la
Aplicación Web Previrnec. Esta diseñada para dar un acceso fácil y ajustado a las
necesidades de los pacientes, puesto que en la mayoría de los casos, sufren disfunciones
neuro-cognitivas muy pronunciadas que les impiden entender el manejo de entornos
informatizados, que para el resto de personas resultan accesibles.
1.2.4 Comunicación entre Aplicación Cliente y Aplicación Web-Servidor
La aplicación Cliente es dependiente de la aplicación Web-Servidor; a través de esta
obtendrá la información necesaria para su correcta ejecución.
El Paciente ejecuta la aplicación Cliente, esta inicia la comunicación con la aplicación
Web-Servidor, vía Internet, y tras un proceso de identificación, recibe los datos sobre la
sesión pautada por un determinado Terapeuta para este Paciente. Seguidamente genera la
ejecución de las diferentes tareas en el mismo orden que las pauto el Terapeuta. Al
finalizar la ejecución de cada tarea, restablece dicha comunicación para enviar los
resultados obtenidos y recibir, dependiendo de estos, un grado de dificultad mayor o
menor, e iniciar la ejecución de la misma tarea parametrizada respecto al nuevo grado de
dificultad, definiéndola como tarea de rescate; o la siguiente tarea en la planificación
prevista por el terapeuta.
PACIENTE
TERAPEUTA
APLICACIÓN
NAVEGADOR
CLIENTE
INTERNET
APLICACIÓN
WEB-SERVIDOR
Figura 1. Interacción del paciente y terapeuta en la Plataforma Previrnec
10
Monitorización de Tareas del Proyecto Previrnec
2
Objetivos del proyecto
El objetivo de este proyecto consiste en ampliar las funcionalidades de la ya existente
Plataforma Previrnec y dotarla de un sistema de monitorización de ejercicios cognitivos, a
estos ejercicios se los conoce con el nombre de tareas terapéuticas.
Con este nuevo sistema de monitorización los terapeutas del instituto Guttmann podrán
reproducir gráficamente como se han desenvuelto sus pacientes durante el desarrollo de
estas tareas, esto puede ser muy útil a los terapeutas ya que les permitirá hacer un
seguimiento más completo de los pacientes que lo requieran sin necesidad de encontrarse
en el un mismo marco espacial y temporal.
Para desarrollar un sistema de monitorización es imprescindible un fase de captura de
información, durante esta fase se han de capturar todos los datos que posteriormente se
necesitaran para monitorizar. Hay que destacar que el sistema de monitorización que se
propone no será en tiempo real, es decir los datos que se obtengan durante la fase de
captura deberán almacenarse y estar a disposición de los terapeutas cuando los soliciten
indirectamente a través de un visualizador. Por lo tanto a la hora de diseñar el sistema, se
ha de tener en cuenta que la información necesaria para la monitorización de tareas se
guardará en la base de datos de la Plataforma, junto con el resto de información
terapéutica, esto implica que será necesario buscar un sistema poco costoso en términos de
memoria para almacenar la información relativa a la monitorización.
La parte central de proyecto consistirá en desarrollar un Visualizador, este elemento ha
de ser capaz de utilizar la información que se ha obtenido durante la fase de captura para
reproducir, de manera totalmente idéntica, el desarrollo de la tarea sobre la que se aplicó
dicha captura.
Se propone, además, que este visualizador esté integrado en la aplicación web-servidor,
de manera que los terapeutas puedan iniciarlo desde la misma web donde comprueban los
resultados de los ejercicios de sus pacientes; para esto el tutor ha recomendado usar Java
Web Start, que se adecua bastante a lo propuesto.
Hay que ser consciente que la Plataforma Previrnec ha alcanzado un tamaño importante
y que sigue creciendo, sobretodo en términos de tareas terapéuticas, de las cuales hay
todavía un gran numero en desarrollo, teniendo en cuenta esto y el hecho que están siendo
desarrolladas por distintas entidades, se deberá intentar que el impacto sobre estas sea
mínimo, intentando que las modificaciones recaigan sobre una capa superior, consiguiendo
así transparencia a nivel de tareas y evitando que esta nueva funcionalidad adultere el
funcionamiento de las mismas.
Con estas premisas empieza el proyecto.
11
Monitorización de Tareas del Proyecto Previrnec
3
Tecnologías usadas
En este punto se explican de manera general las tecnologías que se han ido usando a lo
largo de este proyecto.
3.1 Java 2 Standard Edition
Java 2 Standard Edition (conocido anteriormente hasta la versión 5.0 como Plataforma
Java 2, Standard Edition o J2SE), es una colección de APIs del lenguaje de programación
Java útiles para muchos programas de la Plataforma Java. La Plataforma Java 2, Enterprise
Edition incluye todas las clases en el Java SE, además de algunas de las cuales son útiles
para programas que se ejecutan en servidores sobre workstations.
Algunos de los paquetes que nos proporciona esta plataforma son: java.lang, java.io,
java.math, java.text, java.util, java.applet, java.beans, java.awt, javax.swing, etc.
Aunque durante este proyecto se usan muchos de los paquetes que proporciona J2SE
los que tienen un papel más destacado java.awt y javax.swing.
Han tenido especial importancia en el proyecto todas las herramientas que proporciona
este lenguaje para el control y gestión de los eventos, ya que muchas de las partes
importantes del proyecto se han movido en este entorno.
3.1.1 Java.awt
La Abstract Window Toolkit (AWT, en español Kit de Herramientas de Ventana
Abstracta) es un kit de herramientas de gráficos, interfaz de usuario, y sistema de ventanas
independiente de la plataforma original de Java.
En J2SE 1.2, los widgets de AWT fueron ampliamente superados por aquellos del kit
de herramientas Swing. Además de proveer un conjunto más rico de widgets UI, Swing
dibuja sus propios widgets (usando Java 2D para llamar a las subrutinas de bajo nivel en el
subsistema de gráficos local) en lugar de confiar en el módulo de interfaz de usuario de
alto nivel del sistema operativo. Swing suministra la opción de usar un aspecto nativo o de
plataforma cruzada para la aplicación.
AWT continúa suministrando el núcleo del subsistema de eventos GUI y la interfaz
entre el sistema de ventanas nativo y la aplicación Java, suministrando la estructura que
necesita Swing. También suministra gestores de disposición básicos, un paquete de
transferencia de datos para uso con el Bloc de notas y Arrastrar y Soltar, y la interfaz para
los dispositivos de entrada tales como el ratón y el teclado.
3.1.2 Javax.swing
Swing es una biblioteca gráfica para Java. Incluye widgets para interfaz gráfica de
usuario tales como cajas de texto, botones, desplegables y tablas.
12
Monitorización de Tareas del Proyecto Previrnec
3.1.3 Java 2D
La API Java2D amplía muchas de las capacidades gráficas de la biblioteca AWT
(Abstract Window Toolkit - Herramientas Abstractas de Ventanas), permitiendo la
creación de mejores interfaces de usuario y de aplicaciones Java mucho más impactantes
visualmente. El rango que abarcan todas estas mejoras es muy amplio, ya que comprende
el renderizado, la definición de figuras geométricas, el uso de fuentes de letras, la
manipulación de imágenes y el enriquecimiento en la definición del color.
3.2 Servicios Web XML-RPC
XML-RPC es una especificación y conjunto de aplicaciones de software que permiten
la ejecución en diferentes sistemas operativos, funcionado en diferentes ambientes para
hacer llamadas de procedimiento a través de Internet. Es decir, un protocolo de llamada a
procedimiento remoto que funciona a través de Internet. Un mensaje XML-RPC es una
petición HTTP POST, donde el cuerpo de la solicitud es en XML.
XML-RPC está diseñado para ser lo más sencillo posible, permitiendo al mismo
tiempo estructuras complejas de datos que pueden transmitirse, procesar y ser devueltos,
proporcionando servicios Web para intercambiar datos entre aplicaciones.
3.3 Java Web Start
Java Web Start es un software que permite descargar y ejecutar aplicaciones Java desde
la Web. Entre otras cosas nos permite:
-
Activar aplicaciones con un simple clic
Ejecutar siempre la última versión de la aplicación
Elimina complejos procedimientos en la instalación o actualización
Cuando se descarga por primera vez una aplicación que utiliza la tecnología Java Web
Start, el software de Java Web Start se ejecuta automáticamente y guarda la aplicación
localmente, en la memoria caché del equipo. De este modo, las subsiguientes ejecuciones
son prácticamente instantáneas, ya que los recursos necesarios están disponibles de forma
local. Cada vez que se inicia la aplicación, el componente de software de Java Web Start
comprueba si en la sede Web de la aplicación hay una versión nueva disponible; si es así,
la descarga y la ejecuta de forma automática. Con Java Web Start las aplicaciones de
pueden ejecutar:
-
-
Desde un navegador: haga clic en un vínculo de una página Web.
Desde un icono del escritorio: si utiliza una aplicación con frecuencia, puede crear
un acceso directo en su escritorio o en el menú Inicio. Java Web Start le preguntará
si desea crear accesos directos o una entrada en el menú Inicio. Si responde "sí",
todas las ejecuciones posteriores de la aplicación se podrán iniciar sin necesidad de
un navegador.
Desde el Visualizador de la memoria caché de aplicaciones de Java: Java Web
Start también proporciona un Visualizador de la memoria caché de aplicaciones,
13
Monitorización de Tareas del Proyecto Previrnec
que puede ejecutar desde el Panel de control de Java. Este visualizador le permite
ejecutar directamente las aplicaciones que se descargue.
Java Web Start se empezó a distribuir con Java Runtime Envirorment (JRE) a partir de
su versión 5.0, esto significa que al instalar el JRE, Java Web Start se instala
automáticamente.
3.4 Eclipse
Eclipse es un entorno de desarrollo integrado de código abierto multiplataforma para
desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las
aplicaciones "Cliente-liviano" basadas en navegadores. Esta plataforma, típicamente ha
sido usada para desarrollar entornos de desarrollo integrados (del inglés IDE), como el IDE
de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega
como parte de Eclipse (y que son usados también para desarrollar el mismo Eclipse). Sin
embargo, también se puede usar para otros tipos de aplicaciones cliente, como BitTorrent
Azureus.
Eclipse es también una comunidad de usuarios, extendiendo constantemente las áreas
de aplicación cubiertas. Un ejemplo es el recientemente creado Eclipse Modeling Project,
cubriendo casi todas las áreas de Model Driven Engineering.
Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de
herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse, una
organización independiente sin ánimo de lucro que fomenta una comunidad de código
abierto y un conjunto de productos complementarios, capacidades y servicios.
14
Monitorización de Tareas del Proyecto Previrnec
4
Análisis
En este apartado se hará un análisis detallado de los requisitos y funcionalidades con
las que se ha de dotar a la ya existente Plataforma Previrnec para que sea posible introducir
la nueva aplicación Visualizador, la cual ha de permitir monitorizar gráficamente las tareas
que hayan sido completadas.
4.1 Conocimientos previos
Para poder entender los análisis, consideraciones y modificaciones que se harán en los
siguientes capítulos sobre la plataforma Previrnec será necesario conocer las partes de
dicha plataforma así como su funcionamiento.
4.1.1 Tareas Terapéuticas
Las tareas terapéuticas son el elemento básico del sistema y toda la Plataforma
Previrnec gira en torno a ellas. Tal y como se explicó en el primer capítulo son pequeñas
aplicaciones informáticas desarrolladas a partir del conocimiento en Neurorehabilitación
del Instituto Guttmann y cuyo objetivo es estimular determinadas funciones neurocognitivas (atención, memoria, funciones ejecutivas, etc.). Estas tareas están definidas por
un conjunto de parámetros de entrada que determinan el grado de dificultad; al terminar
su ejecución la tareas generan un serie de resultados que determinan el comportamiento
del paciente ante la funciones neuro-cognitivas que estimulan dicha tarea.
Mediante estas tareas los terapeutas podrán programar tratamientos específicos a sus
pacientes, no solo en función de las funciones neuro-cognitivas que deseen estimular sino
también en que intensidad desean estimularlas.
Dichas tareas se ejecutaran a través del Cliente Previrnec que podrá estar instalado en
cualquier equipo que disponga de conexión a Internet.
4.1.1.1 Clasificación de Tareas Terapéuticas
Las tareas terapéuticas se clasifican en funciones y subfunciones atendiendo a las
funciones cognitivas que estimulan en el paciente que las realiza. Aunque cada tarea
pertenece a una función y a una subfuncion determinada, esta puede estar dividida en
varias subtareas que a la vez pueden estar organizadas varios subniveles; normalmente
todas estas subtareas suelen ser variantes de la idea que representa la tarea.
Por ejemplo, la tarea que se explica en el siguiente apartado (Puzzle) pertenece a la
función Atención y a la subfunción Selectiva, pero dentro de este nivel está subdividida en
dos subtareas: Competición y Ejercicio, que son dos variantes del juego.
15
Monitorización de Tareas del Proyecto Previrnec
Por el momento las clasificaciones función-subfunción son las siguientes, aunque hay
que tener en cuenta que el proyecto Previrnec está en constante crecimiento y es posible
que esta jerarquía se someta a cambios en el futuro:
Función
Atención
Subfunción
- Selectiva
- Dividida
- Sostenida
Funciones Ejecutivas - Inhibición
- Flexibilidad
- Secuencias
- Planificación
- Categorización
Memoria
- Visual
- Verbal
- De Trabajo
Tabla 1. Clasificación de las tareas terapéuticas
4.1.1.2 Ejemplo de Tarea Terapéutica
Veamos como ejemplo la tarea 2D Puzzle modalidad ejercicio, diseñada para
estimular la función cognitiva atención:
Definición de la tarea: a partir de una imagen y de los parámetros de entrada se divide
la imagen en trozos. Al usuario se le irán mostrando pedazos de dicha imagen de forma
desordenada y este tendrá que seleccionar la celda de la imagen que se corresponda con
el fragmento mostrado. Si selecciona una celda que no corresponde a la subimagen
mostrada, se contabilizará como un error, si en caso contrario es la correcta se le
contará un acierto.
Parámetros de entrada: número de columnas, número de filas (determinan las celdas
en que se dividirá la imagen) e identificador de la imagen (imagen que se motrará).
Parámetros de salida: porcentaje de errores, número de errores, número de aciertos y
el tiempo que el usuario ha tardado en acabar la tarea. Salvo excepciones estos suelen
ser los parámetros de salida por defecto para todas las tareas.
16
Monitorización de Tareas del Proyecto Previrnec
Figura 2. Imagen de la tarea 2D Puzzle Ejercicio, función cognitiva asociada: Atención Selectiva
4.1.2 Aplicación Cliente
La Aplicación Cliente gestiona todas las tareas terapéuticas que se han desarrollado
hasta la fecha y permite a los pacientes realizar aquellas que les hayan recetado los
terapeutas con la aplicación Web-servidor.
Esta aplicación ha sido diseñada para que se pueda ejecutar de cualquier ordenador
personal que disponga de conexión a Internet, de está manera cualquier paciente que pueda
tener dificultades para desplazarse podrá realizar las tareas que le haya pautado el terapeuta
en su propio hogar.
La conexión a Internet es necesaria ya que el cliente es dependiente de la aplicación
Web-servidor, que es la dispone de toda la información del paciente, y necesita comprobar
las tareas que el terapeuta ha recetado al paciente cada vez que se inicia, de esta manera la
aplicación cliente solo carga aquellas tareas que el usuario necesita completar; una vez el
paciente completa sus ejercicios la aplicación termina y ya no se pueden volver a invocar
más tareas hasta que el terapeuta vuelva a recetarlas.
Figura 3. Imagen de la Aplicación Cliente
17
Monitorización de Tareas del Proyecto Previrnec
4.1.3 Diseño de la Aplicación Cliente
En la siguiente figura se muestra un diagrama de clases de la aplicación cliente, en este
diagrama se aprecian las clases más importantes que intervienen en la ejecución dicha
aplicación, a continuación se explicará la principal función de cada una de ellas:
Aplicación Servidor-Web
Launcher
Login
Main
ClientXmlRPC
TaskInfo
Tareas
- Atención
- Funciones Ej.
- Memoria
Fullscreen
Figura 4. Diagrama de clases de la Aplicación Cliente
Launcher
Es la clase que contiene el main y desde la cual se inicia toda la aplicación.
Login
Dibuja la pantalla de login y espera a que el usuario introduzca los datos de usuario,
cuando se pulse el botón aceptar se llamará a la clase Main.
Main
Su principal función es dibujar la pantalla principal del cliente y llamar a las tareas
(tasks), así mismo, cuando las tareas terminan esta clase retoma el control.
En cuanto a su funcionamiento es básicamente el siguiente: en primer lugar lee el
fichero server que contiene la URL del servidor y genera una clase TaskInfo, estos dos
(entre otros) serán parámetros de entrada que recibirá el constructor de la clase
ClientXmlRpc, que se encargará de las conexiones con el servidor; si el usuario tiene
tareas por hacer se dibujará el menú principal y se esperará a que un evento mousepressed
inicie la tarea que nos indica la variable del tipo TaskInfo (que nos modifica la clase
ClientXmlRpc).
18
Monitorización de Tareas del Proyecto Previrnec
ClientXmlRPC
Se encarga de todas las acciones que requieren conexión con el servidor, algunas de sus
funciones más importantes consisten en la autentificación de usuarios, obtener la
información de las tareas que tiene recetadas un usuario y remitir los resultados obtenidos
al acabar una tarea.
Cabe remarcar que esta clase también genera un xml con los parámetros de la tarea que
se hayan descargado del servidor; es mediante este fichero que la aplicación cliente se
comunica con las tareas y les transmite información.
TaskInfo
Contiene información de la tarea que la clase Main va a invocar a continuación, esta
información la proporciona la clase ClientXmlRPC al recibir desde el servidor la
información de las tareas pendientes del usuario.
Fullscreen
Fullscreen es la clase base para todas las aplicaciones 2D de la plataforma Previrnec.
Esta clase que hereda de JFrame encapsula la información necesaria para realizar varias
operaciones de render que soporta Java y proporciona diferentes métodos que permiten
dibujar imágenes, texto y formas geométricas con tamaños relativos a la resolución de la
pantalla.
Además, esta clase JFrame no sólo mostrará por pantalla lo que se desee dibujar sino
que también recaerán sobre él todos los eventos mediante los cuales los usuarios
interactúen con la aplicación cliente.
Tanto las Tareas como la clase Main reciben la instancia de esta clase para poder usar
los métodos de dibujo 2D que esta proporciona, de la misma forma, si desean obtener los
eventos que generan los usuarios (ya sean de teclado, ratón, etc.) también tendrán que
obtenerlos a través de la misma.
Tareas
Tal como se ha explicado en el apartado 4.1.1 las tareas están clasificadas en varias
funciones cognitivas, en la aplicación cliente los directorios de las tareas se organizan
siguiendo este mismo criterio; así pues la clasificación de las tareas determinará la
jerarquía a seguir, si la clase Main desea invocar una tarea terapéutica, necesitará conocer
el nombre de la clase que implementa la tarea y la jerarquía de directorios que debe seguir
para identificarla internamente; esta información la proporciona la clase ClientXmlRPC
quien a su vez la obtiene del servidor.
4.2 Requisitos de la Aplicación Cliente
Para que el nuevo sistema de monitorización basado en eventos, propuesto en los
puntos anteriores, sea viable, es necesario introducir una serie de modificaciones en la
aplicación cliente. Con estas variaciones se capturará la información necesaria sobre la
tarea para que pueda volverse a reproducir.
4.2.1 Tipos de usuarios
La aplicación cliente está pensada para pacientes del Instituto Guttmann que necesiten
estimular determinadas funciones cognitivas.
19
Monitorización de Tareas del Proyecto Previrnec
4.2.2 Requisitos Funcionales de los pacientes
Aunque se deben introducir cambios en la Aplicación Cliente esto no afecta a las
operaciones que pueden realizar los pacientes, ya que la totalidad de estos cambios son
trasparentes para estos.
Las operaciones que puede realizar un paciente son:
-
-
Login: con esta operación el paciente puede autentificarse, lo que le permitirá
iniciar las tareas que le haya preinscrito un terapeuta.
Realizar tarea: El usuario interactúa con la tarea mediante el ratón y el teclado
hasta finalizarla, esta funcionalidad se generaliza debido a la gran cantidad y
diversidad de tareas que existen.
Salir: El paciente puede abandonar la aplicación cuando lo crea necesario, no
obstante y como es lógico los resultados de la tarea se verán afectados
negativamente por esta decisión.
4.2.3 Requisitos funcionales generales
-
-
-
Captura de eventos: Durante el transcurso de la tarea se capturarán todos los
eventos de teclado y ratón que se detecten; estos eventos son los únicos mediante
los cuales el paciente se comunica con las tareas.
Captura de aleatorios: Es necesario capturar toda variable de carácter aleatorio
que pueda variar o alterar el curso de la tarea durante su ejecución, de manera que
cuando se vuelva a reproducir la tarea su ejecución sea idéntica.
Captura de resolución de pantalla: Al iniciar la tarea se captura la relación de
aspecto con la que se esta ejecutando la tarea (16:9, 16:10, 4:3, etc.), ya que esto
afecta directamente a las posiciones “x” y “y” que nos devuelven los eventos de
mouse.
4.2.4 Requisitos no funcionales
-
-
Transparencia para el paciente: El paciente no debe notar ningún cambio entre
una tarea monitorizable y una que no lo es; las modificaciones que se hagan en la
aplicación no deben afectar al funcionamiento de las tareas.
No modificar las tareas: Todos los requisitos para la aplicación cliente que se han
mencionado anteriormente se han de llevar a cabo sin modificar el código de las
tareas, es decir, tratar de hacer las modificaciones en una capa superior.
4.2.5 Diagrama de casos de uso del paciente
En el siguiente diagrama se muestran las funcionalidades básicas que puede
desempeñar un paciente al que le han asignado tareas, ahora con los nuevos requisitos,
algunas de las acciones del paciente implican alguna subfuncionalidad extra:
20
Monitorización de Tareas del Proyecto Previrnec
Figura 5. Diagrama de casos de uso de la Aplicación Cliente
4.3 Requisitos del Visualizador
El Visualizador será una de las partes más importantes del proyecto, ya que será la
aplicación que se encargará de mostrar gráficamente todo lo que se desee monitorizar. El
objetivo fundamental del proyecto es monitorizar tareas terapéuticas, por lo que el
visualizador se diseñará para tal cometido. Este usará toda la información que recoja la
Aplicación Cliente sobre una tarea y la usará para volver a reproducirla exactamente como
la desarrolló el paciente.
4.3.1 Tipo de usuarios
Esta aplicación esta diseñada para el uso de los terapeutas, gracias a la cual podrán
volver a reproducir gráficamente como un paciente ha desarrollado una tarea con
independencia del marco espacial o temporal en el que se encuentren.
4.3.2 Requisitos funcionales de los terapeutas
-
Iniciar la reproducción de la tarea, con lo que se iniciará la inyección de eventos.
Pausar la reproducción de la tarea, se detendrá la inyección de eventos. Sólo
disponible si la reproducción se encuentra en estado Play.
Poder detener la reproducción y volver a iniciar la monitorización de la tarea.
Salir de la aplicación.
4.3.3 Requisitos funcionales generales
-
Inyección de eventos: Los eventos de teclado y ratón que ha almacenado
anteriormente la Aplicación Cliente se inyectaran en el Visualizador, simulando
que hay un usuario realizando la tarea.
21
Monitorización de Tareas del Proyecto Previrnec
-
-
-
Dibujar telepointer: Además del cursor del sistema operativo se debe disponer de
un segundo cursor que solamente atienda a los eventos que inyectamos
manualmente, es decir aquellos que ha guardado previamente la Aplicación
Cliente; obviamente deberá ignorar el resto, es decir, aquellos que pueda generar el
terapeuta mientras observa la monitorización.
Distinguir eventos: Es necesario distinguir entre los eventos de ratón o teclado que
han sido capturados por la Aplicación cliente y posteriormente inyectados, y
aquellos que han sido generados “en vivo” por el terapeuta al controlar el
visualizador.
Botones Funcionales: Harán falta una serie de botones para que el terapeuta pueda
interactuar con el visualizador de tareas, obviamente las ordenes que podrá dar
serán las que se han comentado en el apartado anterior.
4.3.4 Requisitos no funcionales
-
No modificar las tareas terapéuticas: Debido a la gran cantidad de tareas que hay
implementadas, es interesante que estas se puedan usar en el visualizador sin
necesidad de que sufran modificación alguna.
4.3.5 Diagrama de casos de uso del terapeuta
En el diagrama se muestran las acciones que podrá realizar el terapeuta cuando esté
reproduciendo tareas con el Visualizador.
Figura 6. Diagrama de casos de uso del Visualizador
22
Monitorización de Tareas del Proyecto Previrnec
4.4 Requisitos del Web-servidor
Por último será necesario añadir una serie de modificaciones en el servidor para que los
añadidos y modificaciones que se contemplan en los apartados 4.2 y 4.3 queden integradas
en la Plataforma Previrnec. Obviamente de nada servirán las nuevas funcionalidades de la
plataforma si el servidor no nos permite usarlas.
4.4.1 Tipos de usuarios
Por una parte el administrador, ahora ya responsable de la gestión y administración de
las tareas terapéuticas, tendrá la responsabilidad de modificar la configuración de las tareas
para decidir cuales de ellas tendrán la propiedad de ser monitorizables.
Por otra parte el terapeuta, que será a quien va dirigida la aplicación de
monitorización que se desarrolla en este proyecto, podrá decidir que tareas de las que
asigna a sus pacientes se podrán monitorizar. Una vez los pacientes las hayan completado
podrá iniciar su reprodución en el momento que quiera. Obviamente esto sólo será posible
si el administrador ha habilitado dichas tareas con la opción de monitorizar.
4.4.2 Requisitos funcionales de los terapeutas
-
Decidir si monitorizar la tarea: El terapeuta puede decidir si la tarea terapéutica
que receta al paciente se podrá monitorizar en el futuro
Empezar visualización: El terapeuta puede iniciar la aplicación Visulizador desde
la aplicación Web-Servidor
4.4.3 Requisitos funcionales del administrador
-
Configurar la tarea como monitorizable: El administrador puede modificar las
configuraciones de las tareas para declararlas aptas o no aptas para la
monitorización.
4.4.4 Requisitos funcionales generales
-
Guardar información en la base de datos: Para que la monitorización tenga
sentido es necesario que se pueda guardar la información generada por cada una de
las tareas que sean aptas para la monitorización. Será necesario habilitar la base de
datos para poder guardar dicha información.
4.4.5 Diagrama de casos de uso del administrador
El siguiente diagrama muestra el conjunto de casos de uso para la gestión de datos de
las tareas, aunque se muestran todas funcionalidades que se le permiten al administrador en
este ámbito, tan solo el caso Habilitar/Deshabilitar Monitorización en nuevo respecto al
servidor-web original.
23
Monitorización de Tareas del Proyecto Previrnec
Figura 7. Diagrama de casos de uso de la gestión de tareas del Administrador
4.4.6 Diagrama de casos de uso del Terapeuta
En este diagrama se ven los casos de uso de un terapeuta para la consulta de
información de las tareas. Aunque en este diagrama se muestran todas las acciones que
puede realizar en dicho ámbito, sólo hay una nueva funcionalidad, esta le permite iniciar la
monitorización de una tarea cuando esté consultando sus datos.
Figura 8. Diagrama de casos de uso de la consulta de tareas de los Terapeutas
24
Monitorización de Tareas del Proyecto Previrnec
5
Diseño
En este capítulo se hablará de la arquitectura y el diseño de las partes más singulares
que forman parte de la nueva aplicación de monitorización.
5.1 Arquitectura Aplicación Cliente
Tal como se ha comentado en el apartado análisis, es necesario que la aplicación
cliente capture información durante el transcurso de la tarea para que posteriormente sea
posible reproducirla, esto obliga a introducir una serie de modificaciones en la aplicación
que alterarán algunos de sus componentes. En el siguiente diagrama de clases se pueden
ver aquellas clases que han sufrido algún tipo de cambio:
Figura 9. Diagrama de clases de la nueva Aplicación Cliente
25
Monitorización de Tareas del Proyecto Previrnec
Respecto al cliente original que se explicó en el apartado 4.1.3 sólo ha habido
modificaciones en la clase Fullscreen, además de la inclusión de dos nuevas clases:
DemoContext y Event. En la figura 9 puede verse la estructura y relaciones que presentan,
en los siguientes apartados se verán con más detalle.
5.1.1 Clase Fullscreen
Figura 10. Clase Fullscreen
Como ya se ha explicado en el apartado de conocimientos previos (4.1) la clase
Fullscreen realiza operaciones de render, proporciona métodos de dibujo (imágenes,
figuras geométricas, etc.) y además es sobre la cual recaen los eventos de ratón y teclado
que generan los usuarios de la aplicación; todo esto la convierte en la candidata perfecta
para recopilar la información necesaria para el proceso de monitorización. Por ese motivo,
se ha dotado a la clase Fullscreen de los métodos necesarios para tal empresa, los más
destacados son los métodos handleEvent y getRandom.
El método handleEvent se encarga de capturar los eventos de teclado y ratón que va
generando el usuario, además de información extra sobre estos que pueda ser necesaria
para el proceso de monitorización, por ejemplo: el tiempo ha tardado en generarse el
evento desde el inicio de la tarea.
El segundo método destacado es getRandom, este método tiene un funcionamiento
distinto dependiendo de si la clase Fullscreen la instancia la aplicación Cliente o el
Visualizador para la monitorización, en este caso sólo se comentará su uso en la aplicación
Cliente. Su funcionamiento es bastante sencillo, simplemente se dedica a generar y guardar
los enteros aleatorios que necesiten las tareas, esta captura de aleatorios es necesaria por
los motivos que se han mencionado en apartados anteriores (ver apartado 4.2.3).
26
Monitorización de Tareas del Proyecto Previrnec
Finalmente remarcar la presencia de los métodos startLogging y stopLogging que
permiten iniciar y detener la captura de información, de esta manera si una tarea no se ha
solicitado como monitorizable ya no se realizará el proceso de captura de información,
evitando así un consumo inútil de recursos.
5.1.2 Clases DemoContext y Event
Tal como se ha comentado al inicio del apartado, el hecho que la aplicación cliente
necesite capturar información obliga necesariamente a la aparición de estas dos nuevas
clases:
Figura 11. Clases Event y DemoContext
Sólo echando una mirada rápida a los atributos de las dos clases que nos muestra la
figura 11 ya se puede intuir cual es el propósito de Event y DemoContext. Estas dos clases
han sido diseñadas para almacenar toda la información que captura la clase Fullscreen
durante la ejecución de una tarea (tal como se ha comentado en el apartado anterior) y que
se necesita par poder volver a reproducirla posteriormente.
Tal como podemos ver en el diagrama de clases, DemoContext guarda: el nombre de la
tarea se ha ejecutado en taskName, los parámetros de la tarea (taskInformation), la
relación de aspecto (4:3, 16:9, etc) en que se ejecuta la tarea (aspectRatio), los randoms
que ha generado la tarea para situaciones que requieran aleatoriedad (Lista
randomsQueue) y finalmente todos los eventos de teclado o ratón que ha generado el
usuario para resolver la tarea (Lista eventsQueue). A partir de esto se puede deducir que la
clase Event es la que almacena toda la información correspondiente a un único evento.
Aunque para estas dos clases la mayoría de métodos sean getters and setters1 hay
varios métodos que merecen una mención especial, como es el caso de save(), que serializa
la clase DemoContext en un único fichero para su posterior envío, y del método
1
Getters and Setters: Métodos de acceso para variables privadas, get (captador) para lectura y set (definidor)
para escritura
27
Monitorización de Tareas del Proyecto Previrnec
loadFromXml() que carga en la variable taskInformation el fichero xml que contiene los
parámetros con los que se debe que ejecutar la tarea.
Sólo queda remarcar la existencia de varios métodos que aunque son importantes para
la clase DemoContext no se usan en la Aplicación Cliente, por lo tanto no se comentarán
en este apartado y se dejan pendientes para cuando se trate la arquitectura del Visualizador.
5.1.3 Clases TaskInfo y ClientXmlRpc
Tal como se explicó en el apartado 4.1.3 la clase ClienteXmlRpc se encarga de
establecer las comunicaciones entre la aplicación cliente y el servidor de la Plataforma
Previrnec; sus principales funciones son las operaciones de login, el envío de resultados
obtenidos en una tarea y la descarga de información de las tareas pautadas por un
terapeuta.
Por otra parte la clase TaskInfo sólo se encarga de almacenar la información de la tarea
que se va a ejecutar a continuación, esta información es la que previamente ha descargado
la clase ClientXmlRpc.
Figura 12. Clases TaskInfo y ClientXmlRpc
28
Monitorización de Tareas del Proyecto Previrnec
En comparación con el resto de clases que hemos comentado en este apartado, las dos
que se muestran en la figura 12 sólo han necesitado un par de ajustes para poder adaptarlas
a las nuevas funcionalidades con las que se han dotado a la aplicación cliente.
La clase ClientXmlRpc no cuenta con ninguna función o variable nueva, sólo se ha
ampliado la funcionalidad del método sendTasksResults() ya que ahora es necesario
enviar al servidor la información que se recopila durante el transcurso de la tarea, esta
información se encuentra almacenada en un fichero que se obtiene al serializar la clase
DemoContext (ver el apartado dedicado a esta clase).
A la clase TaskInfo se le ha añadido la variable reproduction, esta variable indica si la
tarea ha de ser monitorizable o no, es decir, si durante su ejecución se ha de estar
capturando información para que sea posible su posterior reproducción. Esta última
variable será un parámetro extra que se les pasará a las tareas, por lo tanto se incluirá en el
fichero in.xml junto con el resto de parámetros de la tarea; recordemos que la aplicación
cliente y las tareas que esta invoca se comunican con este tipo de ficheros.
29
Monitorización de Tareas del Proyecto Previrnec
5.2 Arquitectura del Visualizador
A continuación se mostrará el diagrama de clases del visualizador:
Figura 13. Diagrama de clases del Visualizador
La estructura de este diagrama es muy parecida a la que presenta la aplicación cliente
(figura 9), esto se debe a que tienen funcionamientos muy similares, ya que ambas
aplicaciones se dedican, básicamente, a llamar tareas con independencia que quien o que
inyecta los eventos que dictaran su progreso. Como consecuencia, y tal como ya se había
mencionado antes, las dos aplicaciones comparten muchas de las clases que las componen,
todo y que hacen uso de métodos diferentes y algunos de sus funciones alteran su
funcionamiento mediante variables booleanas que cambian su valor según la clase que las
inicializa.
30
Monitorización de Tareas del Proyecto Previrnec
5.2.1 Clases DemoContext y Event
En este caso las clases DemoContext y Event que usa la aplicación Visualizador son
exactamente la mismas que se han explicado en la Aplicación Cliente:
Figura 14. Clases Event y DemoContext
Aunque las clases sean las mismas su uso cambia; para el cliente la clase DemoContext
empezaba totalmente vacía y se iba llenando conforme avanzaba la ejecución de la tarea,
para posteriormente serializarla en un fichero mediante el método save(). En este caso al
inicializar la clase DemoContext se llama al método load() que se encarga de descargar el
archivo serializado de la tarea que hay que monitorizar y completar las variables de la clase
con la información correspondiente, de esta manera se consigue toda la información de la
tarea que hay que reproducir.
Otro método que hay de destacar es saveToXml(), el cual es paso inverso al
loadFromXml() explicado en el apartado del Cliente, este método se encarga de crear el
fichero in.xml a partir de la información almacenada en la variable taskInformation, la cual
contiene los parámetros que necesita leer la tarea para poder ejecutarse.
Respecto a la clase Event es evidente que tampoco cambiará, y tal como ocurre con su
contenedora, sólo se usarán funciones de lectura. Esto se debe a que el Visualizador sólo
necesita recuperar la información que previamente recogió la Aplicación Cliente.
31
Monitorización de Tareas del Proyecto Previrnec
5.2.2 Clase ThreadEventPublisher
Esta clase tiene un papel fundamental en la aplicación Visualizador, su función
principal es ir cogiendo los eventos, tanto de ratón como de teclado, de cola eventsQueue
que esta contenida en la clase DemoContext e ir inyectándolos a Fullscreen de manera que
estos lleguen a la tarea. De esta manera se pueden volver a reproducir los pasos que ha
seguido un paciente al realizar la tarea.
Figura 15. Clase ThreadEventPublisher
En cuanto a las variables destacar el uso de: currentTime, prevCurrentTime,
startTime y timeWhenStoped; la función de todas ellas es la de almacenar tiempos con el
fin de conseguir que los eventos se inyecten en orden y en el momento preciso, además de
evitar que cualquier interacción que haga el terapeuta (como por ejemplo una pausa) afecte
a la inyección de eventos.
Por lo que respecta a los métodos son bastante generales y permiten hacer las tres
operaciones que se proponen en el análisis: play() para iniciar la inyección de eventos,
pause() que pausa la inyección con opción a reanudarla y finalmente stopEvents() que la
detiene totalmente sin opción a retomarla desde el punto donde se paró.
Quedan comentar un par de métodos especiales para tareas que tienen hilos
ejecutándose concurrentemente: pauseTaskThread() y resumeTaskThread(). Estas dos
tareas permiten pausar y reanudar dichos hilos. Esto es útil cuando tienes, por ejemplo, una
cuenta atrás y no quieres que cuando pauses esta sigua decreciendo.
5.2.3 Clase Fullscreen
La clase Fullscreen presenta algunas variaciones dependiendo de la aplicación que
instancia, pero su función sigue siendo la misma: proporcionar herramientas de render y de
dibujo a las clases que lo necesiten, en este caso únicamente las tareas.
32
Monitorización de Tareas del Proyecto Previrnec
Figura 16. Clase Fullscreen
En primer lugar comentar el uso de la variable windowed, un valor true en este atributo
indica que Fullscreen se esta ejecutando en modo de monitorización. Esta variable debe su
nombre al hecho de que el JFrame que contiene esta clase se ejecuta en modo ventana
cuando se esta monitorizando alguna tarea.
Por lo que respecta a las funciones cabe destacar el uso de drawCursor que dibuja el
telepointer, una imagen que simulará ser un segundo cursor y que solo atenderá a
MouseEvents que lance la clase ThreadEventPublisher. Normalmente esta función la
llamará updateScreen() y siempre precedida del método drawScreen().
Queda por mencionar el funcionamiento del método getRandom() durante la
monitorización, el cual en vez de ir generando aleatorios para la tarea y guardarlos en una
lista, hace lo contrario los va retirando de la lista y se los va devolviendo a la tarea; la lista
esta contenida en la clase DemoContext.
5.2.4 Clase DemoViewer
Finalmente queda por comentar el main del Visualizador, esta clase se encarga de
inicializar las clases que hemos ido comentando en los anteriores puntos dedicados a esta
aplicación. Además en el recae la responsabilidad de invocar las tareas que se han
monitorizar, obviamente cuando se ejecuta la clase main DemoViewer ya se debe saber de
antemano que tarea es la que queremos reproducir, es por eso que a esta clase se le debe
proporcionar un parámetro de entrada. Este parámetro representa el identificador de la
tarea que se ha de reproducir y lo usará la clase DemoContext (explicada anteriormente)
33
Monitorización de Tareas del Proyecto Previrnec
para conectar con el servidor y descargar la información necesaria para la monitorización
(listas de eventos, aleatorios, nombre de la tarea, parámetros de la tarea, etc.).
Figura 17. Clase DemoViewer
De esta clase remarcar la presencia de la variable controls que contiene un JDialog con
los controles que podrán usar los terapeutas durante la reproducción de la tarea (play,
pause y stop).
34
Monitorización de Tareas del Proyecto Previrnec
6
Desarrollo
En este apartado se describe como se han planteado y implementado las diferentes
partes del proyecto, además de los problemas que han ido surgiendo y como se han
solucionado.
6.1 Aplicación Cliente
Para que sea posible monitorizar tareas, es decir, poder volver a reproducir una tarea
que un paciente/usuario haya resuelto previamente, requerirá que durante el desarrollo de
la misma se almacene información adicional. Para ello es totalmente indispensable que se
introduzcan una serie de modificaciones que permitan capturar dicha información;
obviamente es totalmente indispensable que este proceso de captura no afecte en ningún
sentido al paciente, ya que esta nueva funcionalidad que estamos desarrollando no implica
ningún tipo de interacción con este tipo de usuario y se espera que sea totalmente
transparente para él.
Un aspecto importante a tener en cuenta es intentar no modificar las tareas terapéuticas
que ya están implementadas, porque supondría un gran esfuerzo a nivel de implementación
debido a la gran cantidad de tareas que existen, eso sin tener en cuenta que la mayoría de
ellas cuentan con varias subtareas (algunas llegan a tener hasta once). Sin embargo en los
siguientes apartados veremos que en algunos casos esto será inevitable, aunque estos
cambios serán de mínimo impacto y se podrán automatizar.
6.1.1 Captura de Eventos
Durante el transcurso de las tareas el usuario puede interactuar con estas mediante el
ratón y en algunos casos el teclado, generando en cada caso eventos correspondientes a
cada periférico. Como el objetivo es volver a reproducir el progreso del paciente durante la
tarea es imprescindible que se almacenen todos los eventos de ratón y teclado que genere
el usuario.
Para conseguir esto lo más sencillo sería aprovechar los listeners añadidos en las tareas
para que cada vez que se active alguno de ellos se guarde una copia del evento en una lista,
sin embargo esto implicaría modificar una a una las tareas y sería un proceso costoso e
inútil sobretodo habiendo otras alternativas.
En la solución a este problema juega un papel muy importante la clase Fullscreen, que
contiene un JFrame sobre el que se dibujan todos los elementos que se deben mostrar por
pantalla, y lo que es más importante, sobre el cual recaen todos los eventos que genera el
usuario.
Teniendo en cuenta lo anterior se han declarado MouseListeners y KeyListeners en la
clase Fullscreen, de manera que cuando se invoque cualquiera de los métodos asociados a
los listeners se guarde el MouseEvent o el KeyEvent que lo ha originado.
Además de guardar el evento como un AWTEvent, con toda la información que esta
clase lleva implícita, también es necesario guardar información adicional, como son: el
momento en el que se ha generado el evento, que permitirá ubicar el evento dentro del
marco temporal de la tarea, y la posición en que se ha generado el evento dentro de la
pantalla, siempre, claro esta, que se trate de un evento de ratón.
35
Monitorización de Tareas del Proyecto Previrnec
Toda esta información sobre los eventos se almacenará en una cola de eventos
contenida en la clase llamada DemoContext especialmente diseñada para este propósito, su
estructura se muestra en la figura 11 mostrada en capítulos anteriores.
6.1.2 Captura de aleatorios
Todas las tareas de la plataforma cuentan con lo que llamamos una parte aleatoria, esta
parte aleatoria hace que cada vez que ejecutemos una tarea esta tenga variaciones que
hacen que su solución sea diferente. Por ejemplo supongamos que estamos resolviendo la
tarea “sopa de letras”, cada vez que ejecutemos esta tarea nos aparecerán distintas palabras
para buscar, además estarán colocadas en diferentes lugares.
Obviamente aunque se capturen todos los eventos que ha generado el paciente y
después se inyecten la aplicación Visualizador no se conseguirá nada si la tarea ha
cambiado. Si volvemos a tomar como ejemplo la tarea de la sopa de letras, podría darse el
caso de estar pulsando una cuadrícula donde antes empezaba una palabra, y ahora al volver
a ejecutar la tarea para la monitorización ya no haya nada o sea una cuadricula
intranscendente.
Echando un ojo a las tareas se aprecia que estas partes aleatorias se generan con el
método nextint(int max) que nos proporciona la clase Random, este método genera enteros
aleatorios de valor entre 0 y un máximo.
Como es lógico la solución pasa por capturar estos números aleatorios con el fin de
poder recrear las mismas condiciones aleatorias cuando se quiera volver a recrear la tarea,
esto genera un problema que obligará a romper uno de los requisitos que se planteaban al
inicio del proyecto, ya que no es posible capturar los aleatorios que genera la función
nextint() al ser Random una clase java la cual no podemos modificar; eso sin mencionar
que posteriormente se han de inyectar dichos aleatorios.
La única solución viable consiste en modificar el código de las tareas para en vez de
llamar a método nextInt, llamen a un método que haga exactamente lo que se necesita:
public int getRandom(){
int n;
if(isReplay) {
return demoContext.removeFirstRandom();
}
else
{
Random rnd = new Random();
n = rnd.nextInt();
if(logging)demoContext.addRandomNumber(n);
return n;
}
}
Con este método getRandom se solucionan los problemas de captura e inyección de
aleatorios, ya que permite generar los aleatorios y almacenarlos en una cola cuando el
paciente esta realizando la tarea, e inyectarlos cuando se esta en modo monitorización.
36
Monitorización de Tareas del Proyecto Previrnec
Tal como ocurre con la captura de eventos la información que se captura sobre los
aleatorios se almacena en una cola de enteros que contiene la clase DemoContext cuya
estructura como ya se ha comentado puede verse en la figura 11.
Sin embargo, la solución a este problema genera otro, ahora hay que modificar todas
las tareas para que en vez de llamar al método nextInt() de la clase Random, llamen al
nuevo método getRandom que se hospeda en la clase Fullscreen. Para solucionarlo se ha
diseñado un script que agilizará el proceso, del cual se hablará en el siguiente punto.
6.1.3 Script de substitución
Aunque en los requisitos tanto de la aplicación cliente como del visualizador se instaba
a evitar cualquier tipo de cambio en las tareas, esto no será posible debido a los problemas
comentados en el punto anterior. Sin embargo este cambio sigue siempre la misma
mecánica, es decir, se debe cambiar la expresión “nombre_de_variable.nextInt(“ por
“screen.getRandom(“ en todas las tareas del proyecto que sean aptas para monitorizar; por
lo tanto es viable automatizar este proceso con un pequeño programa.
Para este proceso se ha implementado el script Replace.java; este script, partiendo del
path absoluto que le indica el usuario, recorre recursivamente todos los directorios en
busca de archivos .java, y para cada uno de ellos realiza la substitución siguiente:
replaceAll("[a-zA-Z][a-zA-Z_0-9]*\\.nextInt\\(", "screen.getRandom(");
Con esta operación podemos realizar la substitución que se ha comentado
anteriormente, como puede verse para conseguirlo ha sido necesario el uso de expresiones
regulares, ya que cada programador habra llamado a su variable de tipo random de manera
distinta.
"[a-zA-Z][a-zA-Z_0-9]*\\.nextInt\\("
Mediante la expresión regular anterior conseguimos expresar exactamente lo que
queremos sustituir: “cualquier_nombre_de_variable.nextInt(“.
6.1.4 Captura de la relación de aspecto
A diferencia de lo que pasaba hace años, hoy en día es bastante habitual que las
pantallas tengan diferentes relaciones de aspecto, las más habituales suelen ser 16:9, 16:10
y 4:3.
Normalmente las tareas ante un cambio de relación de aspecto simplemente hacen un
reescalado, con lo cual aunque el visualizador se ejecute con una relación de aspecto
distinta a la que se ha hecho la captura simplemente deformará los objetos que se dibujen,
pero las posiciones de de los MouseEvent seguirán siendo válidas. No obstante, hay tareas
que dibujan sus objetos en función de la relación de aspecto, por lo tanto al ejecutarlo
relaciones de aspecto distintas puede darse el caso que un objeto que se encontraba en la
posición (x,y) haya cambiado de ubicación, con lo cual los eventos de mouse estarán
descompensados.
37
Monitorización de Tareas del Proyecto Previrnec
La solución más simple a este problema es obligar al visualizador a ejecutarse con la
misma relación de aspecto con la que fue ejecutada durante al captura de datos. Para esto
se captura la información sobre la resolución de la pantalla mediante los métodos de que
dispone la clase Fullscreen y almacena el resultado del cálculo ancho/alto, obviamente esto
se almacena en la clase DemoContext en un variable del tipo float especialmente incluida
para este cometido.
Este sistema no ocasiona ningún tipo de deficiencia visual a la aplicación visualizador,
ya que siempre se ejecuta en modo ventana y así se evitan deformaciones por reescalado,
además se controla el tamaño de la misma para evitar que la ventana se salga de los límites
de la pantalla, pero siempre manteniendo la relación de aspecto requerida.
6.1.5 Envío de la información capturada
Una vez el paciente finaliza la tarea se da por concluido el periodo de captura de
información y esta se encuentra almacenada en la clase DemoContext que se ha diseñado
para tal propósito. El siguiente paso consiste en enviar esta información al servidor para
que quede almacenada en la base de datos de la plataforma, de manera que pueda ser
recuperada posteriormente.
Para llevar a cabo lo que hemos descrito en el párrafo anterior, el administrador del
servidor nos ha proporcionado un método remoto con el cual podemos enviar y almacenar
el contenido de la clase DemoContext en la base de datos del servidor:
addDemoContext(int idBlockTask, byte[] fileByte)
Como podemos ver, el método necesita dos parámetros: idBlockTask que es el
identificador de la tarea y fileByte que es un array de bytes; este array es, como se puede
imaginar, la infomación que se ha de enviar. Así pues para enviar la información se
serializa la clase DemoContext en un fichero llamado “demoContext.ser” y posteriormente
se transforma en un array de bytes.
Finalmente utilizando el comando execute que nos proporciona la clase XmlRpcClient
se hace un invocación remota del método addDemoContext pasándole por parámetro el id
de la tarea y la clase DemoContext serializada. Dicha invocación se realizará justo después
del envío de los resultados de la tarea, de esta manera se puede aprovechar la conexión
Xmlrpc que se ha abierto para tal cometido.
38
Monitorización de Tareas del Proyecto Previrnec
6.2 Aplicación Visualizador
En este punto se explica el visualizador, aplicación que se encarga de monitorizar
tareas, es decir, reproducir una tarea exactamente igual que como la realizo el paciente. La
idea general de esta aplicación consiste en invocar la tarea que queremos reproducir y,
usando la información que en su momento se capturó de dicha tarea, emular las mismas
condiciones para que al inyectar los mismos eventos que generó el usuario, el desarrollo
sea exactamente igual.
Igual que en el apartado anterior uno de los requisitos que se pide es no modificar la
implementación de las tareas terapéuticas, de la misma manera también se sabe que esta
condición no se podrá respetar al cien por cien, ya que nos topamos con el caso de
inyección/captura de aleatorios descrito en el punto 6.1.2, pero en ese caso concreto el
cambio era trivial y se podía automatizar con un script de sustitución. Así pues se seguirá
con la misma estrategia que hasta ahora, y no se harán cambios en las tareas a no ser que
sea del todo imprescindible, aunque como se verá en los siguientes puntos esto ocasionará
un buen número de problemas.
6.2.1 Inyección de eventos
El primer paso para construir el visualizador es conseguir que la tarea se ejecute y
progrese sola, es decir que una vez invocada vayan entrando los eventos que estaban
almacenados sin necesidad de el usuario realice ninguna acción.
Para hacer esto se ha diseñado una clase ThreadEventPublisher, que hereda de la clase
thread para que pueda ejecutarse en concurrencia, y cuya función consiste en ir inyectando
los MouseEvent y los KeyEvents que hay almacenados en la clase DemoContext en la cola
de eventos del sistema; para esto se usa el java Toolkit, que entre muchas otras
aplicaciones permite usar la siguiente orden:
Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(e);
Mediante la función postEvent se puede introducir el evento “e” al final de la cola de
eventos del sistema, que es exactamente lo que se precisa para esta parte de desarrollo.
Un aspecto a tener en cuenta es sobre quien recaerán todos estos eventos, como ya se
ha mencionado en otros apartados, las tareas, sólo detectan aquellos eventos que se aplican
sobre la clase Fullscreen (la cual es un JFrame), es por eso que para evitar problemas de
cambios de focus (es decir que elemento del escritorio tenemos seleccionado) fijamos
como source del evento la clase Fullscreen. Esto se puede hacer mediante la función
setSource() que disponen todas la clases del tipo evento, usando este método haga lo que
haga el usuario que ejecute el Visualizador los eventos siempre irán dirigidos a las Tareas.
Durante el apartado de desarrollo de la aplicación cliente se ha comentado que el
visualizador se ejecutaría en modo ventana, siempre respetando la relación de aspecto
aunque no el tamaño; es decir si ejecutamos la tarea en 1024x768 es seguro que el
visualizador al ejecutarse en ventana usará una resolución menor (como podría ser
800x600), ya que el programa se asegura que la ventana y los controles cabrán dentro de la
pantalla. Esto ocasiona un pequeño problema con la posiciones de los eventos de ratón que
se han almacenado durante el transcurso de la tarea, si esta se ejecutó a, por ejemplo,
1024x768 las posiciones de los eventos son relativas a esta resolución, y cuando se ejecute
el visualizador a una resolución menor estas posiciones estarán descompensadas. Para
39
Monitorización de Tareas del Proyecto Previrnec
solucionarlo hay que recalcular estas las posiciones a partir de las resoluciones de ambas
aplicaciones.
6.2.2 Inyección de aleatorios
Como ya se ha comentado las tareas tienen variables aleatorias que hacen que varíen
ligeramente cada vez que se ejecutan, obviamente cuando el visualizador reproduce una
tarea se espera que esta sea totalmente igual que cuando la ejecutó el paciente; no es
permisible que, por ejemplo, en un test aparezcan distintas preguntas cuando
monitoricemos, ya que sus respuestas también serán distintas y el progreso de la tarea
variaría.
Durante la monitorización, el método getRandom es el que se ocupa de proporcionar a
las tareas los mismos números aleatorios que se generaron cuando el paciente resolvió la
tarea. Para ello se dispone de una cola con todos los aleatorios que se generaron durante
ejecución de la tarea (véase clase DemoContext); getRandom se dedica a devolver el
primer elemento de la cola cada vez que la tarea solicita un aleatorio, de tal manera que se
va simulado el mismo contexto que tenia la tarea realizada por el paciente.
El funcionamiento completo del método getRandom está explicado en el apartado de
aleatorios de la aplicación cliente.
6.2.3 Dibujo del Telepointer
Con los dos puntos anteriores se consigue que la tarea se ejecute y progrese sola, sin
intervención del usuario. Sin embargo esto es incompleto ya que no se puede ver lo que
hace el usuario, de momento sólo se puede intuir lo que hace basándose en las
consecuencias de sus actos sobre la tarea. Como es lógico, es necesario un cursor
(obviamente sólo en casos de eventos de ratón) que permita visualizar los eventos que se
están inyectado sobre la tarea.
Como primera solución se pensó en usar la función mouseMove(x,y) de la clase
awt.Robot integrada en java para dar movimiento al ratón. Obviamente era una solución
sencilla y óptima, no obstante con esta solución el ratón está ocupado mientras dura el
proceso de monitorización e impide que el usuario que esta viendo la reproducción pueda
interactuar con él. Esta restricción no se puede asumir, ya que el usuario ha de poder
interactuar con los botones play, pause y stop con el ratón, tal y como se especificó en los
requisitos del visualizador.
Para solventar este requisito es necesario que mientras se este ejecutando el
visualizador haya dos cursores, uno que atienda los eventos que genera el usuario y otro
que solo atienda a los que se están inyectando. Como tener dos cursores es imposible, el
segundo será una imagen que simulará ser un cursor, a este segundo cursor se le denomina
telepointer.
40
Monitorización de Tareas del Proyecto Previrnec
Para esto se ha implementado la siguiente función drawCursor en la clase Fullscreen:
public synchronized void drawCursor(int x, int y) {
try{
Graphics2D g =
(Graphics2D)this.getBufferStrategy().getDrawGraphics();
g.drawImage(this.screenToDraw,0,0,null);
g.drawImage(cursor, x, y, null);
this.getBufferStrategy().show();
}
catch(Exception e){System.err.println("Error!");}
}
Este método pinta una imagen en la posición que le indican los dos parámetros de
entrada x y y, estas dos variables irán tomando en valor de la posiciones donde se
produzcan los eventos de ratón.
De esta función se ha que destacar sobre todo que se dibujan dos imágenes
(drawImge), en primer lugar se dibuja todo el entorno de la tarea y posteriormente se
superpone la imagen del cursor. Esto es necesario porque las tareas no refrescan la pantalla
periódicamente, sino que la refrescan cada vez que un evento que requiere algún tipo de
efecto visual; esta medida puede ocasionar que se necesite actualizar varias veces la
posición del telepointer pero aún no se haya refrescado el entorno de la tarea en la pantalla,
con lo cual se iría dejando una estela de telepointers tal como se ve en la imagen siguiente:
Figura 18. Problema de la estela de telepointers
41
Monitorización de Tareas del Proyecto Previrnec
Otro tema que se debe comentar es cuando llamar a esta función, como es lógico se
deberá llamar dentro del método updateScreen(), que como ya se ha comentado en
apartados anteriores es una función de la clase Fullscreen que usan las tareas para refrescar
la pantalla con los últimos cambios; esto aunque correcto es incompleto por el mismo
motivo que se ha comentado en párrafo anterior, las tareas no refrescan la pantalla
periódicamente sino que la refrescan cuando quieren mostrar un cambio visual, y por tanto
ocurre que se pierden todos los eventos ocurridos entre refresco y refresco. Para solucionar
esto la clase Fullscreen llama a drawCursor cada vez que detecta un evento de ratón.
Figura 19. Telepointer
6.2.4 Distinción de eventos
Aunque con la solución del apartado anterior se consigue simular un puntero con una
imagen dibujándola cuando la clase Fullscreen detecta un MouseEvent o un KeyEvent,
aún quedan problemas que resolver, ya que ahora el usuario que este usando el
Visualizador tiene libertad para generar eventos desde el teclado y el ratón. Generalmente
esto no tiene mayor trascendencia, pero si los eventos que genera van dirigidos al JFrame
de Fullscreen el evento se procesará igual que si hubiese sido inyectado. Esto ocurre
porque tanto el telepointer como la tarea que se esta reproduciendo no tienen manera de
distinguir si el que ha generado el evento ha sido el usuario o una inyección del
ThreadEventPublisher.
Distinguir quien ha generado el evento es sencillo, pues al inyectarlos
ThreadEventPublisher puede modificar el valor de algunos de sus atributos de manera que
la combinación sea imposible de generar para el usuario que monitoriza las tareas, como
42
Monitorización de Tareas del Proyecto Previrnec
por ejemplo isPopupTrigger() == true y getButton() == 3, de esta manera puede se indicar
que este evento en concreto ha sido inyectado (obviamente para eventos de teclado se
usaran otros atributos, ya que isPopupTrigger no existe).
No obstante aunque es fácil distinguir los eventos que genera el usuario, el problema
radica en que hay que detener dichos eventos para que ni la tarea ni el telepointer se vean
afectados. Para detener eventos y que no se sigan procesando en niveles de ejecución
inferiores los eventos de java cuentan con la función consume(), sin embargo en esta
aplicación todos los listeners se encuentran en una misma clase (Fullscreen) y por lo tanto
en el mismo nivel, cosa que implica que aunque se use la función consume no se
conseguirá detener el evento en cuestión.
Antes de llegar a la solución definitiva se probaron algunas alternativas que no llegaron
a buen puerto. La mas destacada de ellas consistió en usar la función translatePoint(x,y)
para trasladar cualquier evento de mouse fuera de la zona de acción de la tarea, por
ejemplo: transladar un mousePressed a la posición (10000, 10000); como no habían
elementos con los que interactuar en esa zona un clic allí era del todo inefectivo. Sin
embargo había operaciones a las que aún les afectaba que se hiciera un clic aunque este
fuera en una posición intrascendente, como por ejemplo las operaciones de arrastrado; esto
hacía que esta solución fuera inviable.
Para detener los eventos se ha usado un AWTEventListener, este listener no permite
capturar los eventos que llegan a la cola del sistema y procesarlos a nuestro gusto, como se
ve en las líneas de código inferiores también es posible filtrar el tipo de eventos que se
quiere capturar:
Toolkit toolkit = Toolkit.getDefaultToolkit();
toolkit.addAWTEventListener(listener, AWTEvent.MOUSE_EVENT_MASK |
AWTEvent.MOUSE_MOTION_EVENT_MASK | AWTEvent.KEY_EVENT_MASK);
Mediante este listener será posible tratar los eventos desde un nivel más alto de
ejecución con lo cual el método consume() será suficiente para evitar que las tareas traten
los eventos que no hayan sido inyectados por ThreadEventPublisher. Sin embargo, sólo se
deben detener los eventos generados por el usuario que vayan destinados al JFrame de
Fullscreen, ya que el resto posiblemente sean eventos destinados a los controles del
visualizador.
Hay que remarcar que los eventos de teclado tienen un poco más de dificultad al
tratarlos, ya que por defecto, java asigna todos los eventos de teclado que se generan al
componente que tengamos seleccionado, así que al tratar los eventos de teclado, además de
filtrar aquellos que no has sido inyectados por ThreadEventPublisher, hay que fijar como
focus owner a la clase Fullscreen.
43
Monitorización de Tareas del Proyecto Previrnec
6.2.5 Controles del Visualizador
Para que el terapeuta pueda interactuar con el visulizador se ha implementado un
sistema de controles que le permitirán hacer las cuatro funciones básicas que se proponían
en el análisis: play, pause, stop y exit.
Figura 20. Controles del Visualizador
Tal como se puede suponer los botones pause y play sólo detienen y retoman la
inyección de mouseEvents y keyEvents de la clase ThreadEventPublisher, sin embargo
conviene tener en cuenta que los eventos se van inyectando en función del tiempo, es decir
si durante la captura, entre la generación del primer evento y el segundo el paciente dejó
pasar 10 segundos, cuando estemos monitorizando entre estos dos eventos se esperará 10
segundos. Para controlar el tiempo que ha pasado se va comparando el tiempo del reloj del
sistema con el tiempo que tenia este al inicio de la monitorización. El tiempo del reloj del
sistema se obtiene gracias la orden siguiente:
System.currentTimeMillis();
Un aspecto a tener en cuenta cuando la aplicación está pausada y no inyecta eventos es
que el reloj del sistema sigue contando, esto significa que si no se tienen en cuenta este
tiempo, cuando se vuelva al estado play se inyectarán de golpe todos los eventos que
deberían haberse inyectado durante el periodo de pausa. Para evitar este efecto se ha de
restar el tiempo que ha estado pausada la aplicación del que nos devuelve el reloj del
sistema.
Queda por comentar un último problema por lo que respecta a las operaciones de
play/pause. Hay algunas tareas que lanzan threads cuando han de controlar algún proceso
concurrentemente, como por ejemplo un contador que indica cuanto tiempo queda para
terminar la tarea, esto es un problema ya que aunque detengamos la inyección de threads el
contador seguirá su cuenta atrás. Para solucionarlo se ha diseñado el siguiente método:
public static void pauseTaskThread( ) {
ThreadGroup currentGroup =
Thread.currentThread().getThreadGroup();
int numThreads = currentGroup.activeCount();
Thread[] listOfThreads = new Thread[numThreads];
currentGroup.enumerate(listOfThreads);
for(Thread t: listOfThreads){
if(t.getName().substring(0,7).equals("Thread-")){
t.suspend();
}
}
}
44
Monitorización de Tareas del Proyecto Previrnec
Este método conseguirá todos los threads que ha creado la aplicación visualizador y
pausará solamente aquellos que haya iniciado la tarea, estos son fácilmente reconocibles ya
que su nombre siempre se inicia con “Thread-“. Obviamente también se ha creado un
método que permite volver a ponerlos en funcionamiento, este es totalmente igual al que se
muestra en la página anterior solo que cambia la orden suspend por resume.
Poco que comentar sobre las dos funciones restantes, stop reinicia el visualizador para
que la simulación vuelva al inicio lista para volver a empezar; y exit simplemente llama un
system.exit(0) que permite cerrar la aplicación Visualizador.
6.2.6 Descarga de la información de la tarea
Durante el desarrollo de la aplicación Visualizador se ha usado información sobre la
tarea que capturó la aplicación cliente cuando el paciente la resolvía. Esta información era
entre otras cosas: nombre de la tarea, parámetros de la tarea, eventos de ratón/teclado que
generó el paciente y números aleatorios que generó la tarea. Toda esta información se
descarga del servidor si se almacena en la clase DemoContext hasta que el Visualizador la
consume.
Para descargarla se abre una conexión XmlRpc con el servidor y se invoca
remotamente la función siguiente:
byte[] getDemoContext(int idBlockTask)
Esta función que nos proporciona el administrador del servidor, descarga la clase
DemoContext serializada en un secuencia de bytes correspondiente al id de la tarea que le
proporcionamos. El id de la tarea concreta que se quiere visualizar es un argumento de
entrada de la aplicación Visualizador; de esta manera cuando el servidor-web llame
mediante Java Web Start al Visualizador, podrá indicarle que tarea se ha de reproducir.
45
Monitorización de Tareas del Proyecto Previrnec
6.3 Servidor-Web
En el capítulo “Análisis” se comentó que serían necesarios cambios en el servidor-web
de la plataforma para el funcionamiento del Visualizador, en primer lugar porque es
necesario almacenar la información que permitirá monitorizar las tareas, en segundo
porque se han de poder gestionar las tareas monitorizables desde la interfaz web y por
último porque la aplicación Visualizador se ha de poder arrancar desde el servidor-web,
para conseguirlo se usara Java Web Start.
6.3.1 Almacenamiento y recuperación de información
Como ya se ha comentado es necesario guardar en la Base de Datos de la plataforma la
información que captura la Aplicación Cliente sobre el progreso de la tarea, esta
información la deberá poder recuperar más tarde la Aplicación Visualizador para poder
reproducir exactamente el progreso de dicha tarea.
Para llevar a cabo estas acciones el administrador nos ha facilitado dos métodos que
deben ser llamados remotamente mediante una conexión xml-rpc:
void addDemoContext(int idBlockTask, byte[] fileByte)
byte[] getDemoContext(int idBlockTask)
Estas dos funciones añaden y recuperan respectivamente un array de bytes de la base
de datos del sistema, este array de bytes es concretamente la clase DemoContext
serializada.
6.3.2 Ejecución del Visualizador desde el Servidor-Web
Para poder lanzar la aplicación Visualizador desde la interfaz web del servidor se usará
Java Web Start, cuya lógica se ha explicado en el capitulo “Tecnología usada”. Para que
esto sea posible será necesario empaquetar toda la aplicación Visualizador en un archivo
.jar.
Conseguir crear un archivo .jar con la aplicación Visualizador no es difícil, ya que
existen plugins para Eclipse que permiten hacerlo, sin embargo esto provoca problemas
cuando se quiere acceder a los recursos de la aplicación, entendemos por recursos todas las
imágenes, sonidos, etc. a los que necesitan las tareas para poderse ejecutar correctamente.
El problema radica en que ahora estos recursos se encuentran encapsulados dentro del
archivo .jar y ya no se puede acceder a ellos por los medios habituales, por ejemplo para
abrir una imagen:
new File("images/" + lang + "/exit.jpg")
Si se quiere acceder a un fichero dentro de un .jar se debe usar el método getResource
de la siguiente manera:
clase_que_necesita_recurso.class.getClassLoader()
.getResource("images/" + lang + "/exit.jpg")
46
Monitorización de Tareas del Proyecto Previrnec
Por lo tanto se han substituido en toda la aplicación Visualizador, incluidas las tareas
todos los accesos a recursos que se estuvieran usando, aunque en ocasiones se ha podido
reaprovechar el script que se diseño para el caso de getRandom descrito en puntos
anteriores, en muchos casos ha sido necesario realizar los cambios a mano, resultando una
tarea ardua y tediosa.
Una vez preparado el ejecutable .jar, se ha de generar el fichero jnlp. Este fichero esta
escrito en formato xml y contiene información de configuración sobre como va ejecutar
Java Web Start nuestra aplicación .jar. Un fichero jnlp tiene la siguiente estructura:
<?xml version="1.0" encoding="ISO-8859-1"?>
<jnlp spec="0.2 1.0"
codebase="https://planet.urv.es:8080/previrnec/previrnec2D/patients"
href="10.jnlp">
<information>
<title>PREVIRNEC</title>
<vendor>Sun Microsystems, Inc.</vendor>
<description>Client 2D</description>
<offline-allowed/>
</information>
<security><all-permissions/></security>
<resources>
<j2se version="1.6+"
href="http://java.sun.com/products/autodl/j2se"/>
<j2se version="1.6+"/>
<jar
href="https://planet.urv.es:8080/previrnec/previrnec2D/previrnec2D.j
ar" main="true" download="eager"/>
</resources>
<application-desc main-class="tasks.DemoViewer">
<argument>1004</argument>
</application-desc>
</jnlp>
Como vemos el fichero jnlp se inicia con la cabecera típica de un xml y consta de una
serie de etiquetas que contienen la información que necesitará Java Web Stara para
ejecutar nuestro jar. De este fichero hay que comentar unas cuantas etiquetas:
-
La etiqueta jnlp indica la url donde se encuentra el fichero jnlp
Security indica los privilegios que se tendrán en la máquina donde se ejecute el
archivo jar.
J2se indica la versión de java que se necesita para ejecutar el jar
Jar href indica la url donde se hospeda nuestro archivo jar
Application-desc main-class indica cual el la clase que contiene el main de la
aplicación empaquetada dentro del jar
Argument que indica los argumentos que se le han de pasar al main de la apliación
Para poder iniciar la ejecución del .jar desde una página web, tan solo hay que crear un
link desde dicha web a la url donde se hospeda el fichero .jnlp.
47
Monitorización de Tareas del Proyecto Previrnec
6.3.3 Cambios en la interfaz grafica de la web
Finalmente comentar que el administrador del servidor ha introducido cambios en la
web que sirve de interfaz para la gestión de las tareas, de esta manera ahora al introducir o
modificar tareas es posible indicar si dicha tarea estará disponible para la monitorización.
También se ha añadido un formulario en la pantalla de asignación de tareas que permite
a los terapeutas decidir si la tarea que están recetando estará disponible para monitorizar.
Por último se ha añadido una opción, presente en la pantalla de resultados de tareas,
que permite iniciar la monitorización de la tarea de la cual estamos viendo los resultados,
siempre, claro está, que el terapeuta la seleccionara como monitorizable.
48
Monitorización de Tareas del Proyecto Previrnec
7
Evaluación
La fase de evaluación si inició una vez se hubo conseguido una primera versión
operativa del Visulizador, esta primera versión sólo era capaz reproducir correctamente un
tipo muy concreto de tareas. Durante la fase de evaluación se fue comprobando el
funcionamiento de esta primera versión del Visualizador en el resto de tareas y corrigiendo
los errores de funcionamiento que se iban presentando.
Llegado a este punto se pudo observar que los problemas que daban la mayoría de las
tareas eran siempre los mismos y obviamente los ocasionaban los mismos aspectos, de
acuerdo con esto se pudo llegar a una clasificación que permitía determinar que tareas se
podrían reproducir al resolver cada uno de estos problemas.
Los aspectos de las tareas que producían problemas eran:
1. Número de buffers que utiliza la tarea en el dibujado: Las tareas implementadas
en un único buffer ocasionan problemas en el dibujo del telepointer, se produce
el efecto de estela que se ha comentado en el apartado de desarrollo, es decir se
van dejando telepointers dibujados por allí donde pasa el cursor simulado.
2. La tarea sólo implementa el mousePressed y no trata el resto de eventos de
ratón, esto ocasiona que el telepointer sólo se dibuje cuando haya eventos
mousePressed, ya que es el único momento en que se llama a updatescreen
(metodo que actualiza la pantalla).
3. Tareas que usan eventos de teclado.
Por lo tanto en primer lugar se probaron tareas de dos buffers que implementaban todos
los eventos de ratón, ya que teóricamente eran la que no provocaban ningún tipo de
problemática adicional. Cuando se consiguió esta primera versión del visualizador se paso
a la segunda fase de pruebas.
Para la segunda fase de pruebas se testearon las tareas de dos buffers que sólo
implementaban la función mousePressed del Mouselistener, como consecuencia
aparecieron los problemas que hemos descrito en el punto dos. Una vez resueltos (la
solución ha dichos problemas se describe en el capítulo “Desarrollo”) se pasó a la siguiente
fase.
La tercera fase consistió en comprobar el funcionamiento de las tareas de un buffer,
obviamente esto requiso comprobar tanto las que sólo tenían implementado el
mousePressed como las que no. Tal como se ha comentado en el primer punto las tareas de
un único buffer ocasionaban el problema de la estela de telepointers (tal como se ha
mencionado en la segunda fase la solución al problema se menciona en el capítulo de
Desarrollo).
Una vez se solventaron los problemas con la visualización de eventos de ratón, se paso
a comprobar el funcionamiento de las tareas que usaban eventos de teclado, en esta última
fase de evaluación se descubrió un problema con respecto a la inyección de eventos de
teclado. Este problema lo provocaba la política de Java al considerar que todos los eventos
de teclado deben ir destinados al componente que tengamos seleccionando, ignorando el
49
Monitorización de Tareas del Proyecto Previrnec
campo source de que disponen todos los tipos de eventos y que indica a que componente
va destinado este. Como en los anteriores puntos la solución que se aplicó al problema
comentado anteriormente puede verse en el capítulo de Desarrollo en el apartado de la
aplicación Visulizador.
Con las pruebas que se han comentado en este apartado se han conseguido reproducir
todas las tareas terapéuticas que el Instituto Guttmann tiene activas actualmente, con lo que
se da por cerrada la fase de evaluación.
50
Monitorización de Tareas del Proyecto Previrnec
8
Conclusiones
El sistema de monitorización que se ha desarrollado en este proyecto interactúa con el
resto de la Plataforma Previrnec, de este modo el primer paso en su desarrollo fue entender
el funcionamiento de todas las partes que la forman. Para lograr los conocimientos
necesarios se hizo una primera toma de contacto arreglando pequeños fallos en tareas
terapéuticas que estaban incompletas. De este modo se asumieron las bases necesarias para
plantear el proyecto.
En líneas generales fue relativamente sencillo conseguir un primer prototipo del
visualizador, la problemática aumentó de sobremanera cuando se introdujeron conceptos
como el segundo cursor, llamado telepointer, y la distinción de eventos. La causa de que
estos cambios, a priori no tan complejos, provocaran tal cantidad de problemas fue sin
duda la gran diversidad de las tareas y la intención de que todos los cambios fuesen
transparentes para estas.
Aunque se intentó por todos los medios no modificar código de las tareas durante el
progreso del proyecto, al final no se pudo evitar. Fue necesario reemplazar el método que
usaban las tareas para generar aleatorios por uno propio que permitiera capturarlos o
inyectarlos según conviniera. Sin embargo como era un cambio muy mecánico, se pudo
automatizar usando un pequeño programa de reemplazo, y aunque en algunos casos es
necesario hacer una revisión manual, evita tener que ir modificando las tareas una por una.
La versión final de Visualizador es capaz de reproducir correctamente todas las tareas
que actualmente tiene en activo el instituto Guttmann, además de poder reproducir la gran
mayoría de las que se encuentran en la fase final de desarrollo. De todas formas, cuando
una tarea no se reproduce correctamente suele se por problemas en la captura de aleatorios,
la mayoría fáciles de solucionar.
Finalmente los terapeutas podrán ejecutar el Visualizador desde la web de la
plataforma. La herramienta Java Web Start permite que el usuario final no deba
preocuparse de las instalaciones ni actualizaciones de software, ya que este proceso se
realiza automáticamente. Al evitar esta gestión por parte del usuario, se evitan los
problemas que puedan surgir a causa de unos limitados conocimientos informático, además
de resultar mucho más cómodo y sencillo.
51
Monitorización de Tareas del Proyecto Previrnec
9
Trabajo Futuro
El control por parte del terapeuta de la realización de los ejercicios terapéuticos se
podría definir en distintos niveles. Un primer nivel es el que ofrece la actual plataforma
Previrnec, que permite la consulta de los resultados que ha obtenido el paciente en
términos de errores/aciertos, etc. El siguiente nivel sería la monitorización, donde el
terapeuta puede reproducir exactamente el ejercicio que ha realizado el paciente; esto es lo
que se ha hecho durante el actual proyecto. Un nivel más avanzado sería donde el terapeuta
puede influir en la realización del ejercicio terapéutico en tiempo real. En este caso se
estaría hablando de tareas colaborativas.
El trabajo futuro consistiría en abordar el nivel de las tareas colaborativas.
52
Monitorización de Tareas del Proyecto Previrnec
10 Manual de usuario
En este punto se explicará como usar las nuevas funcionalidades que se le han atribuido
al servidor de la Plataforma Previrnec, todas ellas derivadas de inclusión de la nueva
aplicación Visualizador.
El usuario accederá a todas estas funcionalidades desde un navegador introduciendo
URL siguiente: https://servidor:8080/previrnec/home.do, donde servidor se refiere a la IP
o nombre de la máquina donde esta instalado el servidor de la plataforma.
El usuario tendrá que introducir su nombre de usuario y contraseña, según el tipo de
usuario que sea (terapeuta o administrador) se le otorgarán distintos privilegios y por lo
tanto tendrán acceso a distintas funciones.
53
Monitorización de Tareas del Proyecto Previrnec
10.1 Manual de uso para el Administrador
A las operaciones que ya podía realizar el administrador ahora se le añade la
posibilidad de decidir que tareas terapéuticas contarán con la opción de ser monitorizables.
Para hacer uso de esta nueva funcionalidad hay que acceder al servidor-web como
administrador y seleccionar el apartado tareas:
Llegado este punto para declarar tareas monitorizables podemos o bien crear una nueva
tarea o modificar creada previamente, en ambos casos nos aparecerá la siguiente pantalla:
54
Monitorización de Tareas del Proyecto Previrnec
La opción resaltada en rojo es la que permitirá seleccionar una tarea como
monitorizable o no monitorizable, en caso afirmativo a los terapeutas contarán una opción
adicional que les permitirá decidir cuales de las tareas que receten podrán volver a
reproducir.
10.2 Manual de para el Terapeuta
Con los nuevos añadidos en la plataforma, cualquier terapeuta podrá reproducir las
tareas que hayan hecho sus pacientes, para ello deberá activar la opción correspondiente
durante la fase de asignación de tareas.
10.2.1 Activar la monitorización en una tarea
Si una tarea ha sido habilitada para la monitorización, cuando un terapeuta la intente
asignar le aparecerá una opción extra que le permitirá monitoriazarla (remarcada en rojo en
la imagen inferior), si se activa esta opción será posible reproducir la tarea una vez el
paciente la haya completado.
10.2.2 Monitorizar una tarea
Si se ha activado la opción de monitorización al pautar una tarea, una vez que el
paciente la haya completado estará disponible para reproducirla. Para ello hay que acceder
a los resultados de la tarea donde habrá aparecido un nuevo enlace, este nos permitirá
iniciar la reproducción de la tarea.
55
Monitorización de Tareas del Proyecto Previrnec
Una vez se inicie el proceso, Java Web Start comprobará si es necesario descargar
alguna actualización de la aplicación Visualizador, obviamente la primera vez que se
ejecute será necesario descargar la aplicación completamente. En la siguiente imagen se
muestra la pantalla de descarga:
Cuando finalicen las actualizaciones se iniciará la monitorización. A partir de este
punto el terapeuta podrá controlar el progreso de la reproducción mediante los controles
play, pause y stop.
56
Monitorización de Tareas del Proyecto Previrnec
57
Monitorización de Tareas del Proyecto Previrnec
11 Bibliografía
Libros
CEBALLOS SIERRA, F. J. Java 2: interfaces gráficas y aplicaciones para Internet.
Madrid: Ra-ma, cop. 2008, 600 p.
ECKEL, B. Piensa en Java. Madrid: Prentice Hall, 2002
HOLZNER, Steven. La Biblia de Java 2. 1a ed. Madrid: Anaya Multimedia, 2000, 929 p.
MOLDES, F. Javier. Java SE 6. 1a ed. Madrid: Anaya Multimedia, 2008, 416 p.
Páginas Web
Exprimiendo JavaWebStart. Asociación javaHispano. Disponible en:
http://www.javahispano.org/contenidos/es/exprimiendo_javawebstart/
Java 2 Platform SE (2009, febrero-agosto). Disponible en:
http://www.j2ee.me/j2se/1.4.2/docs/api/overview-summary.html
Java 2D: An Introduction and Tutorial (2009, junio). Disponible en:
http://www.apl.jhu.edu/~hall/java/Java2D-Tutorial.html
Java en Castellano. Expresiones Regulares en Java (2009, mayo). Disponible en:
http://www.programacion.com/java/articulo/expresionesreg/
58