Repositorio Institucional de Documentos

Proyecto Final de Carrera Ingenier´ıa Inform´atica Curso 2011-2012 Desarrollo de Funcionalidades, Plugins y Herramientas para Software de Neuroterapia Sergio Serrano S´anchez Diciembre de 2011 Director: Javier M´ınguez Zafra Departamento de Inform´atica e Ingenier´ıa de Sistemas Centro Polit´ecnico Superior Universidad de Zaragoza ii El dolor es inevitable, el sufrimiento, opcional. iv Agradecimientos A mis compa˜neros de clase, por las tardes y noches de laboratorio. Amisamigos,porserellos. A Sergio y Ana, por darle luz a mis noches. A Fernando, por ense˜narme lo que es un gradiente, y por sus ”terrorismos”. A los BBTs, por aceptarme con mis defectos y virtudes, por ayudarme en los momentos m´as dificiles. A la secci´on de deportes San Agust´ın, por permitirme aprender de ellos tantos a˜nos. A Carlos Sebasti´an, por ense˜narme que, la lucha por llegar, nos hace fuertes. A Mar´ıa, por compartir sus metas conmigo, y darme la oportunidad de trabajar cada d´ıa, por un ma˜nana distinto. A Javier, por dirigir este PFC y por su incansable esfuerzo en convertir todo lo que nos rodea en algo mejor. A mis t´ıos, por sus llamadas furtivas, por tener siempre una palabra de aliento. A mis padres, por celebrar mis triunfos, pero sobre todo por estar a mi lado en mis derrotas. A mi hermano y a Eva, por mostrarme el camino de regreso. A mis abuelos, por ense˜narme que no hay nada imposible. YcomonoaMerche,porguiarme,porentenderme,porre-escribirelpresente,por hacerme so˜nar con el futuro. v vi Resumen Desarrollo de Funcionalidades, Plugins y Herramientas para un Software de Neuroterapia El objetivo de este proyecto es el an´alisis, dise˜no e implementaci´on de diversas herramientas que proporcionan funcionalidades para un software de neuroterapia por medio de tecnolog´ıa BCI (Interfaz Cerebro Computador). El contexto de este proyecto es utilizar BCI como herramienta adicional para el tratamiento de diversas patolog´ıas (TDA, accidente cerebro-vascular, depresi´on, fibromialgia) o incluso como herramienta orientada a la mejora de las capacidades cognitivas. La forma mas b´asica de aplicaci´on de la tecnolog´ıa BCI para trabajar con cualquier tipo de caracter´ıstica o trastorno ha sido denominada neurofeedback, el cual es una forma de biofeedback ligado a aspectos espec´ıficos de la actividad el´ectrica del cerebro, los cuales se sabe que est´an relacionados con aspectos cognitivos humanos que se desea potenciar. Se espera que una mejora en estos derive en una mejora de las capacidades cognitivas asociadas. En concreto los objetivos del proyecto son: Analizar, dise˜nar e implementar plugins y funcionalidades necesarias dentro del software de neuroterapia. Analizar, dise˜nar e implementar una herramienta de comprobaci´on de defectos de montaje, teniendo en cuenta aspectos de usabilidad y facilidad de manejo. Analizar, dise˜nar e implementar funcionalidades adscritas a la instalaci´on del software BrainUp. Colaborar en las diversas etapas de ingenier´ıa del software BrainUp desde su fase m´as temprana. vii viii ´ Indice 1. Introducci´on 1 1.1. Alcancedelproyecto .............................. 2 2. Contexto 5 2.1. Conceptos sobre Neurofeedback . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. ArquitecturaBZI................................ 9 2.3. BrainUp : Construya su propia Neuroterapia . . . . . . . . . . . . . . . . . 12 2.3.1. Paso 1: Gesti´on de Usuarios . . . . . . . . . . . . . . . . . . . . . . 12 2.3.2. Paso 2: Gesti´on de Terapia . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.3. Paso 3: Comprobaci´on de defectos de montaje . . . . . . . . . . . . 14 2.3.4. Paso 4: Calibraci´on de Ritmos . . . . . . . . . . . . . . . . . . . . . 15 2.3.5. Paso5:Terapia............................. 16 3. Desarrollo 17 3.1. Herramienta de comprobaci´on de defectos de montaje . . . . . . . . . . . . 18 3.1.1. Introducci´on............................... 18 3.1.2. An´alisis ................................. 18 3.1.3. Dise˜no.................................. 20 3.1.4. Implementaci´on............................. 25 3.1.5. Pruebas ................................. 25 3.2. Unidad de detecci´on de defectos de montaje . . . . . . . . . . . . . . . . . 27 ix 1. Introducci´on 1.1 Alcance del proyecto 4 2. Contexto 2.1. Conceptos sobre Neurofeedback Figura 2.1: Esquema general del neurofeedback. Una aplicaci´on basada en neurofeedback, responde a la estructura b´asica de una interfaz cerebro-computador (Figura 2.1). En sucesivas secciones se concretar´a el dise˜no y funcionamiento particular de una terapia de neurofeedback, comenzaremos en ´esta explicando qu´e elementos posee en com´un con cualquier interfaz cerebro-computador (BCI): 1. Adquisici´on: Se lleva a cabo mediante un gorro EEG (montaje), unido a un amplificador operacional encargado de amplificar la se˜nal. En la actualidad comienzan a proliferar, sistemas hardware ”secos” (sin necesidad de aplicar gel conductor), de f´acil montaje y coste inferior a un equipo de EEG tradicional. 2. Procesado: Realizado con dos objetivos, por un lado la b´usqueda de patrones relevantes de los que deseamos mejora y escogidos dentro del entrenamiento que nos ocupe (Upper Alpha,Lower Alpha)yporotro,lagesti´ondelase˜nalnecesariapara tales fines, ya sea filtrando, editando o almacenando la misma. 3. Aplicaci´on: Parte esencial del sistema, pues proporciona al usuario feedback (visual/auditivo/t´actil) dependiendo de su correcci´on/fallo en la realizaci´on de la tarea (control sobre ritmos determinados), consiguiendo as´ı un mayor control en el usuario/paciente gracias al aprendizaje por refuerzo. 5 2. Contexto 2.1 Conceptos sobre Neurofeedback Como ya hemos comentado anteriormente el prop´osito general de una terapia basada en neurofeedback, es conseguir que el usuario adquiera gracias al condicionamiento operante cierto grado de auto-control sobre bandas o ritmos determinados que se considera reflejan rendimiento cognitivo, como por ejemplo la memoria de trabajo [15][16][17]. Definici´on de Banda: Existen diversas bandas o ritmos presentes en la actividad cerebral (Figura 2.2), pudiendo realizarse terapias/entrenamientos de neurofeedback en cualquiera de ´estas y extrayendo mejoras cognitivas diferentes dependiendo de la banda o ritmo seleccionado. En el caso que nos ocupa, tanto por la experiencia acumulada por BitBrain Technologies como por la Universidad de Zaragoza, se escoge la banda Alpha como objeto de estudio. Figura 2.2: Bandas de trabajo de una neuroterapia. Las terapias basadas en neurofeedback desarrolladas hasta la fecha se realizaban sobre una banda Alpha fija, sin embargo, la existencia de problemas derivados de una metodolog´ıa de banda fija, como por ejemplo, su ineficacia en grupos con importantes variaciones ”inter-usuario”, as´ı como el desconocimiento de qu´e aspectos cognitivos eran mejorados realmente si se optaba por metodolog´ıas de banda completa[17][18], desembocaron en la aparici´on de nuevas metodolog´ıas de neurofeedback. Como respuesta a este tipo de limitaciones, se introduce el concepto de Individual Alpha Frequency (IAF), definido como punto de anclaje distintivo entre dos sub-bandas independientes, upper-alpha (UA) ylower-alpha (LA) y calculado de manera individual para cada sujeto permitiendo de este modo tener en cuenta variaciones ”inter-usuario”. Dichas sub-bandas han demostrado comportarse de manera distinta ante distintos tipos de tareas, siendo la banda UA la que parece m´as relacionada con mejoras cognitivas[18]. Su localizaci´on en cada sujeto requiere de la realizaci´on de tareas previas al entrenamiento. En nuestro caso, una tarea pasiva y una activa, con el fin de localizar la posici´on y potencia del IAF dentro de la totalidad de la banda Alpha,estastareas,tambi´enconocidas como calibraci´on de ritmos, se ver´an detalladas en secciones posteriores. 6 2. Contexto 2.1 Conceptos sobre Neurofeedback Figura 2.3: Esquema de una neuroterapia. Concepto de terapia: Los interfaces cerebro-computador basados en neurofeedback se estructuran en terapias (Figura 2.3), una terapia se compone de una o varias sesiones, pudiendo realizarse en un espacio temporal reducido o bien dilatarse en el tiempo (d´ıas, semanas o meses). Cada una de estas sesiones se encuentra estructurada en fases, siendo posible realizar trabajo com´un o espec´ıfico (tabla 2.1), dotando as´ı de versatilidad a la terapia. Tienen una duraci´on aproximada de entre 10 y 30 minutos, contando con el tiempo programado de descanso entre fases. Ejemplo Protocolo para pacientes de depresi´on Fase 1: Mejora cognitiva. Fase 2: Refuerzo emocional. Tabla 2.1: Ejemplo de diferencia entre fases. Cada una de las fases esta compuesta por : 1. Tarea Pasiva: Realizada ´unicamente al inicio de la sesi´on, su duraci´on aproximada es de 2 minutos, donde el usuario/paciente debe estar relajado y permanecer con los ojos cerrados, procurando aislarse en la manera de lo posible del exterior. 2. Tarea Activa: Realizada ´unicamente al inicio de la sesi´on, su duraci´on aproximada es de unos 2 minutos, donde el usuario/paciente debe realizar una determinada 7 2. Contexto 2.1 Conceptos sobre Neurofeedback actividad, por ejemplo contar cambios de tonalidad dentro de una gama de colores ofrecida por pantalla, se trata de una tarea activa si bien todav´ıa no forma parte del entrenamiento. Como hemos comentado, la presencia de artefactos puede perturbar la se˜nal dej´andola inservible, es por ello por lo que durante la tarea activa tambi´en es realizada la calibraci´on del filtro ICA cuyo objetivo es el filtrado autom´atico de este tipo de componentes. 3. Trial: Tambi´en llamados repeticiones, tras la ejecuci´on de las tareas pasivas y activas, se procede a realizar tandas de entrenamiento, correspondientes al aspecto a reforzar en la fase (entrenamiento de memoria, de atenci´on), el usuario recibe feedback positivo en caso de alcanzar el estado mental adecuado, y feeedback negativo en caso contrario, ya sea de tipo visual, auditivo o t´actil. Todos los trials deben reforzar el mismo aspecto cognitivo, pues pertenecen a la misma fase. El paciente no es informado en ning´un instante de la estrategia a seguir para alcanzar el estado mental adecuado, se ha demostrado que no existe una ´unica correcta[16], sino varias, y que a su vez, la b´usqueda por parte del usuario/paciente de estrategias propias eindividualespodr´ıaenriquecerypotenciarelentrenamientofrenteausuarios/pacientes informados con anterioridad. La decisi´on de proporcionar feedback positivo o negativo es tomada en torno a un valor denominado baseline, valor de referencia al inicio de la sesi´on (calibraci´on de ritmos). De esta forma nuestra terapia se convierte en un proceso din´amico, donde los resultados obtenidos en el d´ıa nestar´an relacionados con los progresos particulares del sujeto en cuesti´on, adapt´andose a ´estos de forma transparente. Validaci´on: La validaci´on de la terapia se realiz´o con 50 sujetos sanos, repartidos en semanas completas de experimentaci´on y distribuidos bajo los siguientes roles: 1. Grupo de pacientes: Realizan una bater´ıa de test el primer d´ıa de entrenamiento y otra el ´ultimo, con el fin de medir su evoluci´on tras la terapia/entrenamiento. 2. Grupo de control: Realizan los mismos test pero sin recibir ning´un tipo de entrenamiento, gracias a esto podemos estimar la capacidad de adaptaci´on al test por parte de los sujetos, y con ello definir la mejora real del grupo de pacientes. Los resultados arrojaron mejoras de entorno al 10 % en el grupo de pacientes. Por ´ultimo cabr´ıa destacar que nos movemos en un terreno de gran complejidad, una terapia o protocolo de neurofeedback es el resultado de un intenso trabajo multidisciplinar y, si bien las fases de adquisici´on, procesado y aplicaci´on son comunes a todos los interfaces BCI, la configuraci´on y dise˜no de una terapia presenta unos niveles de heterogeneidad elevados, a esta y otras cuestiones pretende dar respuesta el software desarrollado por BitBrain Technologies de nombre BrainUp. 8 2. Contexto 2.2 Arquitectura BZI BrainUp: Quiz´as la mejor manera de explicar de qu´e se compone BrainUp, es remontarnos a la definici´on de interfaz cerebro computador dada en el cap´ıtulo anterior, donde quedaba dividida en tres fases bien diferenciadas, enriqueci´endolas ahora con nuevas necesidades como la creaci´on y edici´on de una terapia, o la realizaci´on de tareas de localizaci´on del IAF y de filtrado autom´atico de artefactos (ICA). BrainUp se encuentra dividido en dos grandes bloques, por un lado la arquitectura BZI, encargada de las tareas de gesti´on de la se˜nal cerebral, por otro la interfaz de usuario, encargada de la edici´on, configuraci´on y ejecuci´on de la terapia. 1. Adquisici´on: Realizada directamente por la arquitectura BZI proveniente del amplificador operacional. 2. Procesado: Realizado por la arquitectura BZI, encargada de las diferentes tareas de gesti´on de la se˜nal, extracci´on de caracter´ısticas y clasificaci´on. 3. Aplicaci´on: Realizado tanto por la arquitectura BZI, como la interfaz de usuario contenida en BrainUp a)Arquitectura BZI: Encargada de la visualizaci´on del feedback de usuario, conforme a la realizaci´on del entrenamiento por parte del sujeto b)Interfaz de Usuario: Monitorizaci´on y edici´on del entrenamiento, ya sea paus´andolo, repiti´endolo o modific´andolo. 2.2. Arquitectura BZI Esta secci´on proporciona una descripci´on mas detallada de la plataforma para desarrollo de sistemas BCI proporcionada por BitBrain Technologies en colaboraci´on con la Universidad de Zaragoza, y de nombre BZI. Esta arquitectura responde al esquema general comentado anteriormente, donde puede observarse de manera diferenciada, m´odulos de adquisici´on en tiempo real, m´odulos correspondientes a procesado, as´ı como elementos de visualizaci´on que asisten y proporcionan feedback al usuario o paciente. 9 2. Contexto 2.2 Arquitectura BZI Figura 2.4: Esquema que describe la arquitectura de la plataforma BZI. La arquitectura BZI contiene una serie de componentes b´asicos: m´odulos y un manager de prop´osito general (Figura 2.4). Figura 2.5: Esquema de un m´odulo dentro de la plataforma BZI. Los m´odulos pueden ser de adquisici´on, procesamiento o aplicaci´on final, y se encuentran comunicados mediante protocolos TCP/IP, es necesario aclarar que no existe comunicaci´on entre ellos, sino que cada m´odulo adquiere y deposita la informaci´on pertinente en el manager, mediante mecanismos de suscripci´on (Figura 2.5). 10 2. Contexto 2.2 Arquitectura BZI Figura 2.6: Esquema del manager dentro de la plataforma BZI. Los m´odulos se encuentran formados por unidades de procesamiento, son unidades encargadas de realizar alg´un tipo de procesamiento de datos espec´ıfico. Pueden ser encadenadas construyendo un tratamiento secuencial sobre la se˜nal (Filtro paso banda + FFT + Detecci´on de m´aximo). Al igual que en los m´odulos, no poseen comunicaci´on directa entre ellas haciendo uso de un repositorio com´un, el control viene dado por la estructura que engloba varias unidades de procesamiento, dicese el m´odulo. El manager ya mencionado, hace las veces tanto de concentrador de la informaci´on presente en el proceso, como labores de control, gesti´on y coordinaci´on del proceso de neurofeedback, especial relevancia poseen las entradas y salidas del sistema, puesto que ademas de aquellas est´andar del sistema definidas anteriormente, tambi´en podemos encontramos elementos de control y configuraci´on capaces de adoptar este tipo de roles (Figura 2.6). La din´amica de un sistema BCI desarrollado sobre BZI est´a dirigida por el flujo de datos, todos los m´odulos del sistema BCI y el manager se implementan como procesos que est´an dormidos hasta la llegada de los mismos. El flujo de datos se inicia con la adquisici´on de se˜nal de EEG, dicha se˜nal es amplificada y muestreada a una frecuencia determinada (pre-procesado de se˜nal en el hardware de adquisici´on). La se˜nal digitalizada llega al m´odulo de adquisici´on, este m´odulo procesa el EEG para obtener un conjunto de muestras (bloque) que son almacenadas (disco y almacenadas en el manager). Tras la adquisici´on el manager env´ıa los datos al siguiente proceso en el flujo de ejecuci´on: el m´odulo de procesado de se˜nal, en este m´odulo se lleva a cabo la extracci´on de caracter´ısticas y clasificaci´on, dicha tarea es realizada en las unidades de proceso,cada una de las cuales implementa alg´un tipo de filtro de se˜nal. Finalmente el flujo de datos pasa al m´odulo de aplicaci´on que aplica reglas y transforma los datos para emitir la respuesta del sistema. 11 2. Contexto 2.3 BrainUp : Construya su propia Neuroterapia 2.3. BrainUp : Construya su propia Neuroterapia BrainUp surge para dar respuesta a todas aquellas necesidades expuestas a lo largo de las secciones anteriores, se trata de un software de gesti´on de neuroterapia, donde el usuario/terapeuta, puede crear, gestionar y desarrollar las terapias o entrenamientos que considere adecuadas para su usuario/paciente. Alolargodeestasecci´on,desglosaremosloselementosquecomponenelsistemade gesti´on de neuroterapia desarrollado por BitBrain Technologies, de nombre BrainUp. 2.3.1. Paso 1: Gesti´on de Usuarios Figura 2.7: Aspecto de la interfaz de usuario correspondiente a la gesti´on y edici´on de usuarios. Como se puede observar en la figura 2.7 se trata de la interfaz encargada del alta/edici´on de los usuarios dentro de BrainUp, muestra de manera clara los datos necesarios para el alta de un nuevo usuario, permitiendo tambi´en la b´usqueda de aquellos 12 2. Contexto 2.3 BrainUp : Construya su propia Neuroterapia registrados anteriormente. Todos los datos de usuario surgidos durante el proceso de terapia, as´ı como los datos generados durante el proceso de alta, ser´an almacenados en una base de datos, cumpliendo adem´as con los protocolos de protecci´on de datos en vigor. 2.3.2. Paso 2: Gesti´on de Terapia Figura 2.8: Aspecto de la interfaz de usuario correspondiente a la gesti´on y edici´on de la terapia. Una vez seleccionado o creado el usuario destino del entrenamiento, realizaremos tareas de edici´on y configuraci´on de la sesi´on en curso de la terapia (Figura 2.8), pudiendo modificar en ´esta tanto el n´umero de fases/repeticiones, como la duraci´on de las mismas. Tambi´en permite ejecutar la configuraci´on de sesi´on por defecto del sistema. La selecci´on personalizada del n´umero de fases o repeticiones correspondientes a la sesi´on en curso, nos permitir´a personalizar la terapia a petici´on del usuario final, adecu´andolo a sus necesidades. Por otro lado, la opci´on por defecto suministrada por BrainUp 13 3. Desarrollo 3.1 Herramienta de comprobaci´on de defectos de montaje C´odigo Descripci´on RF-0 El sistema debe ofrecer una herramienta de comprobaci´on del montaje RF-1 La herramienta debe tener un indicador central de estado del montaje. RF-2 El sistema debe tener una representaci´on visual del montaje. RF-3 El sistema debe ofrecer la causa de error de los diferentes sensores. RNF-1 Debe ser intuitiva. RNF-2 Debe ser muy eficiente y funcionar en tiempo real. RNF-3 Debe estar disponible en diferentes idiomas. Tabla 3.2: Requisitos de la herramienta de comprobaci´on de defectos de montaje. 3.1.3. Dise˜no Figura 3.3: Diagrama de clase base GenericCalibration. Como hemos comentado anteriormente, se trata de un sistema completo dentro de las interfaces de usuario presentes en BrainUp (figura 2.9), a tal efecto, deber´a integrarse y adaptarse a la estructura dise˜nada para la aplicaci´on. Comenzaremos nuestro dise˜no definiendo la clase base de nuestra herramienta GenericCalibration,cuyamisi´onesaglutinarelementoscomunesafuturosdise˜nosoespecializaciones de la misma. En nuestro caso, cualquier calibraci´on poseer´a al menos dos elementos b´asicos: 20 3. Desarrollo 3.1 Herramienta de comprobaci´on de defectos de montaje 1. Un objeto Data, contenedor de valores gen´ericos y encargado de dotar a cualquier especializaci´on de esta clase de m´etodos de adquisici´on y distribuci´on de datos. 2. Un indicador de estado general del montaje centralizado e independiente de las herramientas de visualizaci´on incluidas. Figura 3.4: Diagrama de clase de la herramienta de comprobaci´on de defectos de montaje De la clase base definida anteriormente hereda CalibrationGUI, interfaz de usuario encargado de la comprobaci´on del montaje acorde con los requisitos extra´ıdos anteriormente. Deber´a encontrarse debidamente comunicado con el resto de interfaces de BrainUp. Entre sus componentes se encuentra: Montage: Se trata de la clase m´as importante dentro de nuestra herramienta. Act´ua como almac´en central de informaci´on entre la unidad de detecci´on de electrodos err´oneos (BZI) y el interfaz de usuario en el que nos encontramos, evitando as´ı la necesidad de instanciar un contenedor de datos para cada uno de ellos. Al tratarse de un elemento com´un a ambas partes del sistema es creado por una instancia superior dentro de BrainUp llamada InterfaceController yajenaaeste PFC, su misi´on es la creaci´on y gesti´on de los diferentes interfaces de usuario, as´ı como aquellos elementos compartidos con BZI. Head: Representaci´on visual del montaje realizado, obtiene los datos necesarios para su representaci´on del objeto Montage. CommentsFrame: Cuya misi´on es la creaci´on y gesti´on de una o varias zonas de notificaci´on en modo texto. NonEssentialComment: Representa el ´area de notificaci´on de defectos de montaje (modo texto), as´ı como sus operaciones de pintado. Adquiere sus datos del objeto Montage. 21 3. Desarrollo 3.1 Herramienta de comprobaci´on de defectos de montaje StateMontage: Fruto de la herencia con la clase base, hace las veces de indicador central e inequ´ıvoco del estado del montaje. Este objeto tomar´a especial relevancia en futuras implementaciones, donde existir´an diferentes niveles de error y por consiguiente, diferentes tipos de notificaci´on. Figura 3.5: Secuencia de comprobaci´on de defectos de montaje. La adquisici´on/distribuci´on de los valores dentro de CalibrationGUI se realiza a trav´es del mecanismo heredado de GenericCalibration,graciasaestetipodeoperacionesconseguimos operar los datos de forma gen´erica. En la figura 3.5 y 3.6 podemos observar la secuencia de acciones relativa al caso de uso 3.2 donde un usuario que desea comprobar el estado del montaje accede al interfaz de usuario, previa creaci´on del objeto montaje y de la interfaz de comprobaci´on de defectos del montaje. Tras la comunicaci´on por parte de BZI de qu´e electrodos se encuentran err´oneos (realizada a InterfacesControl v´ıa TCP/IP) procederemos a actualizar el ob jeto montaje y a repintar todos los elementos en pantalla. Estas dos ´ultimas operaciones se realizar´an de manera iterativa mientras se siga adquiriendo se˜nal y procesando electrodos, o mientras alguno de los objetos de comprobaci´on de montaje se encuentre instanciado en los interfaces de usuario. Como puede observarse en la figura 3.6, es InterfacesControl el encargado de la creaci´on del objeto CalibrationGUI,elobjetoMontage ydosvectoresdedatos,unvector correspondiente a los electrodos err´oneos y otro a los electrodos borrados. Tras esta operaci´on, el interfaz queda a la espera de ser visualizado a petici´on del usuario. 22 3. Desarrollo 3.1 Herramienta de comprobaci´on de defectos de montaje Por ´ultimo en la figura 3.7 definimos la secuencia de acciones a realizar para la representaci´on visual de los electrodos err´oneos, en primera instancia y tras la llegada desde BZI de los datos, procederemos a actualizar el montaje que como recordaremos almacena la informaci´on referenciada por todos las clases. Tras esto distribuiremos los datos entre los objetos de representaci´on y procederemos a actualizar la representaci´on cada uno de los indicadores visuales. Las secuencias espec´ıficas de repintado de los elementos por pantalla se encuentran detalladas en al anexo A. Tras esta fase obtenemos un primer prototipo de la herramienta (Figura 3.8) Figura 3.6: Prototipo de la herramienta de comprobaci´on de defectos del montaje. 23 3. Desarrollo 3.1 Herramienta de comprobaci´on de defectos de montaje Figura 3.7: Secuencia de representaci´on de electrodo err´oneo 24 3. Desarrollo 3.1 Herramienta de comprobaci´on de defectos de montaje Figura 3.8: Secuencia de creaci´on de la herramienta de comprobaci´on. 3.1.4. Implementaci´on Realizada en C++ bajo el framework Qt[19], en el que se encuentran implementados todos las interfaces de usuario de BrainUp. Debido a que la operaci´on de representaci´on/pintado es muy costosa en Qt,seutilizo para Head un tipo especial de elemento gr´afico de nombre QPainterPath[20], donde en lugar de dibujar cada elemento individualmente, se permite agrupar gran cantidad de ´estos en una ´unica capa y dibujarla de manera at´omica tantas veces como sea necesario. En el caso que nos ocupa, donde la mayor´ıa de los electrodos no van a modificar su estado en largos periodos de tiempo, y teniendo un tiempo de ciclo reducido, resulta m´as eficiente a˜nadir elementos comunes (electrodos correctos o err´oneos) en una variable QPainterPath que dibujarlos individualmente[21] en cada iteraci´on de adquisici´on, tarea que resultaba cr´ıtica. 3.1.5. Pruebas Las pruebas se realizaron en Matlab, comparando los electrodos err´oneos provenientes de la unidad de detecci´on de defectos de montaje (la cual explicaremos en la pr´oxima secci´on) con los errores presentes en el objeto Montage en el instante previo a la invocaci´on a repaint(). De esta manera somos capaces de asegurar que los datos generados 25 3. Desarrollo 3.1 Herramienta de comprobaci´on de defectos de montaje por la unidad de detecci´on y los datos preparados para su pintado son iguales, y que por consiguiente la representaci´on visual es correcta. Las pruebas 3.3 fueron realizadas con cuatro ficheros de EEG grabados con anterioridad, y se encuentran disponibles en el anexo C. Fichero: testS00R004.bzi Precondici´on: El interfaz de comprobaci´on y la unidad han procesado fichero. Datos de entrada: unitChannelsS00R004 : contiene los canales detectados como err´oneos calculadas por la unidad. interfaceChannelsS00R004 : contiene los canales detectados como err´oneos presentes en el interfaz. A=loadFile(interfaceChannelsS00R004) B=loadFile(matlabChannelsS00R004) ans =A−B Resultado: ans = 0 Los canales detectados como err´oneos son iguales tanto en cu´ales son detectados, como en qu´e instante temporal. Tabla 3.3: Prueba 1 de la herramienta de comprobaci´on de defectos de montaje. Asuvez,serealizaronpruebasconsem´anticadiferencialconelfindeconocerel grado de aceptaci´on de la herramienta, as´ı como su calificaci´on en materia de usabilidad, claridad y facilidad de uso. Estas pruebas, cuyo resultado puede observarse en la tabla 3.4 les fueron realizadas a 10 sujetos y se encuentran disponibles por cada uno de los usuarios en el anexo C. La t´ecnica se desarrolla proponiendo dos adjetivos al sujeto, que se han de relacionar con los conceptos propuestos siendo presentados de forma bipolar, mediando entre ambos extremos una serie de valores intermedios. El sujeto procede puntuando as´ı : Bueno 3 2 1 0 -1 -2 -3 Malo. Pregunta Respuesta 3210-1-2-3 En general el interfaz de comprobaci´on de montaje Me gusta 2.3 El interfaz me parece Intuitivo 2.9 El notificador de estado del montaje Claro 2.6 La representaci´on visual del montaje Claro 2.8 La representaci´on tipo texto de los errores Claro 1.9 En t´erminos generales el funcionamiento me parece Claro 2.7 Tabla 3.4: Resultados globales de la evaluaci´on. 26 3. Desarrollo 3.2 Unidad de detecci´on de defectos de montaje 3.2. Unidad de detecci´on de defectos de montaje 3.2.1. Introducci´on Figura 3.9: Unidad de comprobaci´on. Como en todo sistema de comprobaci´on y chequeo, el apartado visual solo representa una peque˜na parte de la herramienta, siendo necesario un algoritmo de procesamiento capaz de proveer datos a esta interfaz de usuario. En nuestro caso, versiones anteriores se limitaban a proporcionar EEG no filtrado como mecanismo de chequeo mediante inspecci´on visual, resultando altamente ineficiente pues requer´ıa de conocimientos previos en material de se˜nal. Son estos conocimientos en materia de se˜nal los que han permitido a BitBrain Technologies desarrollar un m´etodo de procesamiento donde como entrada tendremos la se˜nal EEG tradicional, y como salida qu´e electrodos del montaje se encuentran err´oneos as´ı como su causa. Gracias a este tipo de algoritmos somos capaces de ofrecer una interfaz usable e intuitiva al usuario/terapeuta, sin necesidad de que ´este posea conocimientos previos sobre encefalograf´ıa. El m´etodo de forma gen´erica consta de lo siguientes pasos: 1. Subsampleo: Debido a que necesitamos una ventana temporal de nsegundos, pero no deseamos procesar la totalidad de la informaci´on, por ello elegimos un factor de subsampleo m,seg´unelcualser´anadquiridos1decadamsamples. 2. C´alculo de medias: Tras subsamplear la se˜nal procedente de la fase de adquisici´on se proceder´a al calculo de las medias por cada canal (sensor) para cualquier instante de tiempo y en valor absoluto, procediendo en ´ultima instancia a su ordenaci´on de menor a mayor. 3. Regresi´on: Calcularemos la recta de regresi´on conforme a las num primeras medias anteriormente calculadas. 27 3. Desarrollo 3.2 Unidad de detecci´on de defectos de montaje 4. L´ogica: Tras el c´alculo de la recta de regresi´on se procede a aplicar l´ogica de decisi´on sobre la distancia de cada una de las medias a la recta, y en comparaci´on con un threshold definido previamente. Si la distancia supera el threshold,seconsideraque en ese sensor y en ese instante temporal (sample) se ha producido popping. Un electrodo puede producir error por las siguientes razones: Ausencia de gel: Para el correcto funcionamiento de los electrodos del montaje debe aplicarse en cada uno de ellos un gel conductor evitando as´ı los problemas de medici´on producidos por el tejido epitelial o el cuero cabelludo. Electrodo suelto (Popping): Es el problema m´as com´un en un montaje de EEG, se produce cuando un electrodo pierde el contacto durante momentos puntuales del entrenamiento/terapia perturbando la se˜nal. Ruido: Aumentando sustancialmente la frecuencia y amplitud de la se˜nal, puede ser provocado por artefactos de tipo muscular (tensi´on involuntaria en la frente, pulso) o de tipo el´ectrico (acoplamiento, electricidad est´atica). Puente (Bridge): Evidencia de interconexi´on en el gel aplicado en dos sensores pr´oximos en el espacio, provocando un cortocirtuito y obteniendo en ambos la misma se˜nal el´ectrica. El m´etodo expuesto anteriormente, permite la detecci´on de popping de forma robusta, su eficacia ha sido probada en el entorno matem´atico Matlab con resultados satisfactorios. El procesamiento del resto de defectos de montaje se encuentra en fase de desarrollo. 3.2.2. An´alisis En este caso no existen nuevos casos de uso, pues ya han sido definidos para la herramienta de comprobaci´on de defectos de montaje en la secci´on 3.1.2, sin embargo, como fruto del an´alisis, en esta secci´on si es generado un nuevo requisito no funcional la necesidad de implementar una unidad de detecci´on de defectos de montaje dentro de la arquitectura BZI. 28 3. Desarrollo 3.2 Unidad de detecci´on de defectos de montaje C´odigo Descripci´on RF-0 El sistema debe ofrecer una herramienta de comprobaci´on del montaje RF-1 La herramienta debe ofrecer un indicador de estado del montaje. RF-2 El sistema debe contener una representaci´on visual del montaje. RF-3 El sistema debe ofrecer la causa de error de los diferentes sensores. RNF-1 Debe procesarse la informaci´on con una unidad de BZI para obtener los sensores err´oneos y poder representarlos. RNF-2 Debe ser intuitiva. RNF-3 Debe ser muy eficiente y funcionar en tiempo real. RNF-4 Debe estar disponible en diferentes idiomas. Tabla 3.5: Requisitos completos de la herramienta de comprobaci´on de defectos de montaje. 3.2.3. Dise˜no Figura 3.10: Estructura de la clase base GenericUnit Comenzaremos comentando la estructura de clase base proporcionada por BZI para la creaci´on de unidades de procesamiento (figura 3.10), como podemos observar se dota a cualquier especializaci´on de ´esta de mecanismos de inicializaci´on, procesado y reseteo, as´ı como acceso a la estructura de repositorio y compartici´on de datos presente en BZI. 29 3. Desarrollo 3.3 Informe de resultados Nombre Caso de uso 1 Actores que intervienen Usuario/Terapeuta Descripci´on Comprobaci´on del estado del montaje. Precondici´on El terapeuta se encuentra en un interfaz de usuario. Secuencia de acciones 1. Visualiza el n´umero de sesi´on y los datos del paciente. 2. Visualiza los datos de calibraci´on de ritmos. 3. Visualiza la gr´afica de progreso. 4. Visualiza la gr´afica de tiempo. 5. Visualiza la gr´afica de las tres ´ultimas sesiones. 6. El usuario/terapeuta obtiene el informe en PDF. Resultados El usuario/terapeuta ha visualizado y obtenido el informe. Tabla 3.8: Caso de uso correspondiente a visualizaci´on y impresi´on del informe. funcionales del sistema. Figura 3.16: Gr´afico de caso de uso correspondiente al informe. Obteniendo los siguientes requisitos a satisfacer: 36 3. Desarrollo 3.3 Informe de resultados C´odigo Descripci´on RF-0 Debe ofrecer el n´umero de sesi´on y los datos de paciente RF-1 Debe contener la duraci´on de la terapia y de las repeticiones. as´ı como la de la calibraci´on de ritmos. RF-2 Debe ofrecer una representaci´on gr´afica del progreso (rendimiento). RF-3 Debe ofrecer una representaci´on gr´afica del progreso (tiempo). RF-4 Debe contener una comparaci´on de las tres ´ultimas sesiones. RF-4 El informe debe poder imprimirse. RNF-1 Debe ser intuitivo. RNF-2 Debe guardarse en PDF. RNF-3 Debe estar disponible en diferentes idiomas. Tabla 3.9: Requisitos del informe. 3.3.3. Dise˜no Figura 3.17: Diagrama de clase base GenericUnit Comenzaremos dise˜nando la clase base de nombre GenericGraph,puestoquesedebe permitir de cara a futuras implementaciones, un amplio espectro de representaciones gr´aficas (diagramas de barras, puntos, o funciones interpoladas), as´ı como diferentes formatos, colores o estilos de l´ınea. 37 3. Desarrollo 3.3 Informe de resultados Es por ello, por lo que adem´as de disponer de los habituales m´etodos de adquisici´on/distribuci´on de datos, contiene los siguientes elementos: 1. QwtPlotCurve: Perteneciente a Qwt (framework de representaci´on gr´afica x-yen C++ [23]), y cuya misi´on es proveer soporte matem´atico a la representaci´on gr´afica, cada objeto QwtPlotCurve representa una f(x)diferente. 2. QwtPlot: Clase Qwt encargada de las labores de visualizaci´on, le pueden ser transmitidas de 1 a nQwtPlotCurve gracias al procedimiento Attach(). Una vez a˜nadidas al objeto, pueden ser representadas invocando a la funci´on show() de manera similar al resto de componentes de los diferentes interfaces de usuario, permitiendo adem´as editar su estilo y su escala. 3. QColor: Debe contener todos aquellos colores que deseemos incluir en la representaci´on gr´afica. 4. QMap: Relaciona cada color incluido en QColor con una QwtPlotCurve diferente, de manera que podamos representar todos aquellos puntos pertenecientes a un determinado color con una ´unica QwtPlotCurve Ej: [1,3,5] Rojo; [2,4,6] Azul; Estilo=’Barras’. 5. ReportLegend: Proporciona la leyenda de la gr´afica, su posici´on en la misma es configurable gracias a un atributo enumerado (Above, Below, Left, Right). ReportGraph se define como una especializaci´on de GenericGraph,dondedeber´aimplementarse la l´ogica de decisi´on de qu´e puntos del eje xcorresponden a qu´e colores, as´ı como qu´e estilo debe ser aplicado (puntos,barras,l´ıneas). Contemplaremos dos casos: Caso 1: Los valores en el eje xrepresentar´an repeticiones/trials, y los del eje ypotencia media de todos los canales por cada repetici´on/trial. Aquellos puntos por encima del baseline inicial se representar´an en rojo, mientras que aquellos que se encuentren por debajo, se representar´an en azul, el baseline ser´a representado con una l´ınea amarilla horizontal (Estilo=’Barras’). Caso 2: Los valores en el eje xrepresentar´an repeticiones/trials, y los del eje yel tiempo que ha permanecido el usuario/paciente por encima del baseline en cada repetici´on/trial. Aquellos puntos por encima de duracionEnSegundosDelTrial/2 se representar´an en rojo, mientras que aquellos que se encuentren por debajo, se representar´an en azul, duracionEnSegundosDelTrial/2 ser´a representado con una l´ınea amarilla horizontal (Estilo=’Barras’). ThreeSessionGraph se dise˜na tambi´en como una especializaci´on de GenericGraph bajo la siguiente premisa: 38 3. Desarrollo 3.3 Informe de resultados Caso 1: Los valores en el eje xrepresentar´an repeticiones/trials de las tres ´ultimas sesiones, y los del eje ypotencia media de todos los canales por cada repetici´on/trial en las tres ´ultimas sesiones. Aquellos puntos por encima del baseline de cada sesi´on se representar´an en rojo, mientras que aquellos que se encuentren por debajo, se representar´an en azul, el baseline ser´a representado como un punto en xadicional pero en color amarillo, todos los valores se encontrar´an normalizados al baselinede la primera sesi´on representada (Estilo=’Puntos’). Figura 3.18: Diagrama de clases del informe de resultados. La figura 3.19 ilustra la estructura del objeto principal NtpReport,compuestoasuvez de QScrollArea (necesario para desplazarnos dentro del documento formato A4 generado), ReportTopWidget (encabezado donde aparecer´an el n´umero de sesi´on y los datos del usuario/paciente), y un objeto de tipo MainReport que contiene el informe en s´ı. MainReport se compone de dos objetos de tipo ReportGraph (gr´afica de rendimiento y de tiempo) y uno de tipo ThreeSessionGraph (gr´afica de tres ultimas sesiones). 39 3. Desarrollo 3.3 Informe de resultados Figura 3.19: Diagrama de clases del informe de resultados. Figura 3.20: Diagrama de secuencia de representaci´on del informe. Como podemos observar en la figura 3.20 y 3.21 la estrategia utilizada para el informe de resultados es similar a la utilizada en apartado anteriores. Tras la petici´on por parte del usuario de ”Siguiente pantalla”, InterfaceController procede a servir a cada uno de los objetos mencionados los datos necesarios para su correcta representaci´on, una vez visualizado el informe se procede a su impresi´on en formato PDF. 40 3. Desarrollo 3.3 Informe de resultados Figura 3.21: Diagrama de secuencia de llegada de datos y representaci´on del informe. El diagrama de secuencia correspondiente a la representaci´on gr´afica de ReportGraph se encuentra disponible en el anexo A, figura A.11. Tras esta fase obtenemos un primer prototipo de la herramienta (Figura 3.22). 41 3. Desarrollo 3.3 Informe de resultados 7                                                                Figura 3.22: Prototipo del informe de resultados. 42 3. Desarrollo 3.3 Informe de resultados 3.3.4. Implementaci´on Aquellas tareas relacionadas con la gesti´on y edici´on de los elementos a representar en el informe se desarrollaron con el framework Qt, mientras que las gr´aficas incluidas en el mismo se realizaron con el framework gr´afico Qwt, compatible a todos los efectos con Qt. Debido a la necesidad de imprimir el documento en formato PDF se utiliz´o una resoluci´on de pantalla similar en dimensiones al A4,provocandoquenofueraposibleobservar por pantalla el informe en su totalidad. A fin de que pudiera observarse el mismo antes de ser impreso se incluy´o el objeto QScrollArea, permitiendo as´ı desplazarse con libertad. As´ı mismo hubo que definir los ppp (puntos por pulgada) a los que el documento ser´ıa impreso, siendo seleccionada una resoluci´on de 300 ppp,porsuexcelentecompromiso calidad-tiempo tanto en labores de creaci´on y visualizaci´on, como de impresi´on. 3.3.5. Pruebas Se realizaron pruebas con sem´antica diferencial a 10 sujetos, con el fin de conocer el grado de aceptaci´on del informe, as´ı como su calificaci´on en materia de usabilidad, claridad y facilidad de uso, obteniendo los siguientes resultados: Pregunta Respuesta 3210-1-2-3 En general el informe de resultados Me gusta 2.4 El informe me parece Intuitivo 2.1 La gr´afica de rendimiento me parece Claro 2.2 La gr´afica de tiempo me parece Claro 2 La gr´afica de las tres ´ultimas sesiones me parece Claro 2.4 En t´erminos generales el funcionamiento me parece Claro 2.3 Tabla 3.10: Resultados globales de la evaluaci´on del informe. Se encuentran disponibles en el anexo de pruebas los resultados detallados para cada uno de los usuarios. 43 3. Desarrollo 3.4 Plugin de visualizaci´on de actividad cerebral 3.4. Plugin de visualizaci´on de actividad cerebral 3.4.1. Introducci´on Figura 3.23: Visualizador de actividad. En todo interfaz de usuario orientado a la usabilidad, deben existir tanto herramientas encargadas de la comprobaci´on (representaci´on visual del montaje, notificaci´on modo texto) de manera intuitiva, como otras encargadas de la representaci´on en tiempo real de cierto tipo de datos (EEG, FFT). En el caso que nos ocupa y como tarea dentro de este PFC, se ha desarrollado un plugin de visualizaci´on espacial, cuya misi´on es mostrar la actividad cerebral en tiempo real del usuario/paciente mediante un mapa de calor, donde el color rojo corresponder´a a la cota superior y el azul a la inferior. 3.4.2. An´alisis La tabla 3.11 corresponde a la secuencia de acciones que satisfacen el caso de uso 3.24. El usuario ejecuta la interfaz donde se encuentra contenido el plugin de visualizaci´on, ´esta procede a la creaci´on del objeto visualizador y a la distribuci´on de los datos pertinentes mientras se contin´ue adquiriendo se˜nal o la interfaz se encuentre activa. Como resultado de esta secuencia el usuario observa la actividad correctamente. La tabla 3.12 representa la extracci´on de requisitos funcionales y no funcionales realizada al caso de uso 3.11. 44 3. Desarrollo 3.4 Plugin de visualizaci´on de actividad cerebral Nombre Caso de uso 1 Actores que intervienen Usuario/Terapeuta Descripci´on Visualizaci´on de la actividad cerebral. Precondici´on El terapeuta se encuentra en la interfaz de usuario. donde se encuentra el visualizador. Secuencia de acciones 1. A trav´es del plugin visualiza la actividad cerebral. Resultados El usuario/terapeuta ha visualizado la actividad cerebral. Tabla 3.11: Caso de uso correspondiente a la visualizaci´on de la actividad cerebral. C´odigo Descripci´on RF-0 El plugin debe ofrecer un sistema de visualizaci´on espacial de la actividad cerebral. RNF-0 Se debe poder incluir f´acilmente en cualquier interfaz de usuario. RNF-1 Se aproximar´an el resto de elementos a visualizar conforme a los valores obtenidos del montaje. RNF-2 Debe tener un tiempo de ejecuci´on reducido y funcionar en tiempo real. Tabla 3.12: Requisitos del plugin de visualizaci´on de actividad cerebral. Figura 3.24: Gr´afico de caso de uso correspondiente al Plugin de visualizaci´on de actividad cerebral. 45 3. Desarrollo 3.4 Plugin de visualizaci´on de actividad cerebral Figura 3.31: Comparaci´on visualizador Matlab vs PFC. de ciclo (30 ms)manteni´endoseenunintervalode2-6ms.Lasoluci´onofrecidapor Matlab sin embargo posee un tiempo de ejecuci´on m´ınimo de 107,1 ms. El resto de pruebas de funcionamiento, y una prueba individual del visualizador, se encuentran presentes en el anexo C, secci´on C.4. 52 4. Localizaci´on del software A la hora de desarrollar una soluci´on inform´atica de cualquier tipo, especialmente en fases tempranas de an´alisis o desarrollo, surgen inevitablemente cuestiones referidas al dise˜no, la eficiencia, o incluso a la usabilidad de la misma, sin embargo ¿Qu´e ocurre con la localizaci´on del software?, ¿Qu´e idioma acompa˜na por defecto a la aplicaci´on? ¿Qu´e lenguas posibilitamos? y sobre todo ¿C´omo las incluimos? Las limitaciones producidas por una incorrecta localizaci´on software pueden llegar a imposibilitar la utilizaci´on del mismo, disminuir su atractivo en ciertos entornos comerciales e incluso relegarla a un segundo plano frente a aplicaciones inferiores t´ecnicamente, pero localizadas adecuadamente. En casos extremos una mala localizaci´on puede desembocar en una p´esima o equ´ıvoca valoraci´on del producto final(p.ej : Nissan Moco, Volkswagen Jetta). Como tarea dentro de este PFC, se realiz´o la localizaci´on de BrainUp, atendiendo a su vez al requisito no funcional presente en todos los apartados anteriores (”Debe estar disponible en diferentes idiomas”). El idioma seleccionado por defecto para la aplicaci´on es el ingl´es, se trata de una de las lenguas mas habladas y estudiadas del planeta, adem´as de su ubicua presencia en los entornos de divulgaci´on cient´ıfica, y puesto que nuestro software se encuentra enmarcado dentro de un ´ambito cient´ıfico-t´ecnico, convenimos que el ingl´es era el m´as adecuado a las necesidades del usuario final. La localizaci´on y gesti´on de idiomas se realiz´o conforme al proceso descrito en la API de Qt Qt Linguist[24], gracias a este m´etodo conseguimos generalizar y desacoplar la localizaci´on software, haci´endola accesible incluso a personal no habituado a entornos de desarrollo software, como los ling¨uistas. 53 4. Localizaci´on del software Figura 4.1: Esquema del proceso de localizaci´on. El proceso como podr´a observar en la figura 4.1 consta de las siguientes fases: 1. Trabajo previo: Dentro del documento de normas de programaci´on, de obligado cumplimiento por parte de los ingenieros de BitBrain Technologies, incluimos una norma acerca de la necesaria utilizaci´on de la funci´on ”tr”previa cualquier cadena de texto que se desea mostrar por pantalla (p.ej. tr(”mitexto”)), permitiendo de este modo la correcta localizaci´on de cualquier aplicaci´on generada ahora o en el futuro por la compa˜nia. 2. Modificaci´on archivo .pro: Este tipo de archivo es b´asico dentro de la creaci´on de soluciones basadas en Qt,setratadeunmeta-makefile en el que quedan definidas las librer´ıas a incluir, las dependencias, as´ı como el c´odigo fuente y cabeceras que se implementar´an en el entorno de desarrollo elegido (en nuestro caso Visual Studio 2008), debemos modificarlo a˜nadiendo los idiomas que deseamos generar y completar a posteriori, como por ejemplo: Translations: bUp-es ES.ts bUp-fr FR.ts bUp-de DE.ts bUp-ja JP.ts bUp-pt PT.ts 54 4. Localizaci´on del software Figura 4.2: Aspecto del editor de lenguajes. 3. Lupdate: Invocaci´on correspondiente a la API de Qt Linguist y realizada por l´ınea de comando, su principal funci´on es recorrer los diferentes archivos correspondientes al c´odigo fuente, en busca de cadenas de tipo ”tr(cadena)” ysensiblesdesertraducidas, generando los ficheros .ts adecuados a los idiomas definidos en el archivo .pro. 4. Traducci´on: Una vez generados los ficheros .ts para los distintos idiomas, procedemos a su traducci´on gracias a la herramienta de edici´on proporcionada por Qt, aunque tambi´en pueden ser modificados de manera directa, pues se trata simplemente de un fichero en formato .xml. Como se puede observar en la figura 4.2 el programa dispone de tres zonas principales: a) Zona 1: Selecci´on de objeto cuyos elementos deseamos traducir. b) Zona 2: Selecci´on de elemento a traducir dentro de un objeto. c) Zona 3:Realizaci´on de la traducci´on. 5. Lrelease: Invocaci´on correspondiente a la API de Qt Linguist y realizada por l´ınea de comando, su principal funci´on es generar los diferentes archivos .qm correspon- 55 4. Localizaci´on del software dientes a la traducci´on de las secuencias tr(”mitexto”),estosser´ancargadosde manera din´amica por el ejecutable traduciendo el texto por pantalla. Translations: bUp-es ES.qm bUp-fr FR.qm bUp-de DE.qm bUp-ja JP.qm bUp-pt PT.qm 6. QTranslator: Una vez confeccionado el fichero de traducci´on y generados los archivos .qm,debemosinstanciarunobjetodetipoQTranslator en nuestro procedimiento principal, de manera que nuestra aplicaci´on cargue autom´aticamente el idioma adecuado de acuerdo a nuestra configuraci´on regional, en caso de que este no est´e disponible, se har´a uso del idioma por defecto. a)QString locale = QLocale::system().name(); : Almacenamos gracias a esta invocaci´on bajo qu´e c´odigo regional operamos (p.ej. es ES fr FR) el primero codifica la lengua en formato ISO 639,mientraselsegundocodificaelpa´ısenISO 3166, pudiendo as´ı distinguir por ejemplo, entre ingl´es brit´anico o americano (en GB en US). b)QTranslator translator; : Instanciamos un objeto de tipo QTranslator. c)QString name = ’bUp’+ locale; : Construimos una string en la que almacenaremos el idioma adecuado a nuestra regi´on. d)translator.load(name,”../”) :Cargamoselficherocorrespondiente,encasode no ser encontrado, se har´a uso del idioma por defecto (en nuestro caso ingl´es). e)app.installTranslator(translator); : El traductor queda completamente operativo en nuestro ejecutable. Conseguimos gracias a este m´etodo satisfacer los requisitos no funcionales antes expuestos y generalizar la localizaci´on de nuestra aplicaci´on, de forma que la adici´on de un nuevo idioma a la misma no conlleve nuevos esfuerzos de implementaci´on sobre el n´ucleo. 56 5. Instalador 5.1. Descripci´on Tras varias iteraciones sobre el proceso unificado de desarrollo software descrito en cap´ıtulos anteriores desembocamos en la primera versi´on estable de la aplicaci´on, sin embargo, quedan a´un multitud de tareas a realizar hasta considerar a ´esta como un producto terminado. Tareas por ejemplo relativas al empaquetado y distribuci´on de la aplicaci´on, al m´etodo de obtenci´on del hardware que la acompa˜na (amplificador operacional), a los manuales que deben servir de gu´ıa a usuarios noveles, o a su m´etodo de instalaci´on y configuraci´on. En el caso que nos ocupa, y dentro de las tareas realizadas en este PFC se procedi´o al an´alisis dise˜no e implementaci´on de un instalador para la aplicaci´on BrainUp. A pesar de que el framework sobre el que se implementa BrainUp es multiplataforma, se desarroll´o el instalador ´unicamente para sistemas operativos Windows por tratarse del sistema en el que es comercializado BrainUp en primera instancia, teniendo como requisito m´ınimo Windows XP y realizando distinci´on entre las versiones de 32 y 64 bits, la motivaci´on de esta ser´a detallada en la secci´on 6. Durante este proceso tambi´en se realizar´a la instalaci´on del software correspondiente a terceros, necesario para la correcta ejecuci´on de la aplicaci´on, como por ejemplo: 1. Drivers Gtec: Drivers del fabricante necesarios al tratarse de un dispositivo de adquisici´on conectado a nuestro ordenador por USB. 2. API Gtec: Librer´ıas utilizadas por BZI para la correcta adquisici´on de se˜nal. 3. Base de datos PostgreSQL: Requerida para la gesti´on de datos relativos usuarios y terapia. Tambi´en se ejecutar´an scripts encargados de la creaci´on de una estructura de base de datos adecuada para la terapia, as´ı como la inserci´on de las variables de entorno en el path del sistema, una por cada una de las librer´ıas requeridas por la aplicaci´on (Qt,Qwt,Armadillo). 57 5. Instalador 5.2 An´alisis Se implement´o paralelamente al instalador, el desinstalador pertinente, aunque no se dot´o a este ´ultimo de estrategias de reparaci´on o recuperaci´on en caso de una instalaci´on incompleta. 5.2. An´alisis Siguiendo la metodolog´ıa expuesta en el cap´ıtulo 3 se definen dos casos de uso principales, iniciando as´ı la fase de extracci´on de requisitos: 1. Instalaci´on de la aplicaci´on: El usuario procede a instalar y configurar BrainUp. 2. Desinstalaci´on de la aplicaci´on: El usuario procede a desinstalar BrainUp. En las tablas 5.1 y 5.3 as´ı como en las gr´aficas 5.1 y 5.3 pueden observarse los mismos. Figura 5.1: Diagrama de caso de uso de instalaci´on. 58 5. Instalador 5.2 An´alisis Nombre Caso de uso 1 Actores que intervienen Usuario Descripci´on Instalaci´on y configuraci´on de la aplicaci´on. Precondici´on El usuario posee el ejecutable de BrainUp. Secuencia de acciones 1. Selecciona el idioma de instalaci´on 2. Acepta los t´erminos de licencia. 3. Selecciona el directorio destino de la aplicaci´on. 4. Finalmente el usuario acepta y se reinicia el equipo. Resultados Se ha instalado y configurado BrainUp correctamente. Tabla 5.1: Caso de uso de instalaci´on. Nombre Caso de uso 2 Actores que intervienen Usuario Descripci´on Desinstalaci´on de la aplicaci´on. Precondici´on El usuario posee instalado BrainUp. Secuencia de acciones 1. Selecciona el idioma de desinstalaci´on 2. Selecciona desintalar. Resultados Se ha desinstalado BrainUp correctamente. Tabla 5.2: Caso de uso de desinstalaci´on. Figura 5.2: Diagrama de caso de uso de desinstalaci´on. Gracias a los casos de uso descritos anteriormente, sintetizamos los requisitos funcionales y no funcionales necesarios para el instalador. 59 5. Instalador 5.3 Dise˜no C´odigo Descripci´on RF-0 El instalador debe ofrecer selecci´on de idioma. RF-1 El instalador debe permitir la selecci´on de la carpeta destino. RF-2 El instalador debe obligar al reinicio del equipo tras la instalaci´on. RNF-0 Se debe detectar el sistema operativo destino de la aplicaci´on copiando los archivos adecuados a cada versi´on. RNF-1 Se debe realizar la instalaci´on de componentes o tareas pertenecientes a terceros, de manera desatendida. RNF-2 Debe ser usable e intuitivo. RNF-3 Debe estar disponible en diferentes idiomas. Tabla 5.3: Requisitos del instalador. 5.3. Dise˜no Un diagrama de actividades es utilizado con el fin de modelar el comportamiento del sistema o describir como un sistema implementa su propia funcionalidad, cada diagrama representa una actividad, que a su vez puede estar formada por actividades m´as peque˜nas, adem´as est´an basados en redes de petri. Mientras un diagrama de interacci´on muestra como los objetos gestionan los mensajes, uno de actividades muestra las operaciones ocurridas entre entidades de nuestro sistema, sirven para modelar la din´amica de un conjunto de objetos, el flujo de control de una operaci´on, caso de uso, o bien un hilo de trabajo (workflow). En la figura 5.3 podemos observar el diagrama de actividades correspondiente al instalador. Figura 5.3: Diagrama de actividades del instalador. Para finalizar el proceso de dise˜no se realizaron prototipos de las ventanas correspon- 60 5. Instalador 5.4 Implementaci´on dientes al proceso de instalaci´on, incluidas en el anexo de desarrollo. 5.4. Implementaci´on La implementaci´on fue realizada sobre NSIS[25], lenguaje de script de licencia opensource y desarrollado por NullSoft, creadores del afamado Winamp. La popularidad de ´este ha crecido de forma exponencial en los ´ultimos a˜nos, debido sobre todo a su versatilidad, el magn´ıfico soporte ofrecido por una amplia comunidad de desarrolladores, y por tratarse de una alternativa libre y gratuita frente a otras como InstallShield de elevado coste. Adem´as de resultar una alternativa libre y gratuita, NSIS ofrece las siguientes funcionalidades: 1. Reducido tama˜no: NSIS fue concebido para ser peque˜no, r´apido y eficiente, un instalador b´asico completamente funcional tendr´ıa un tama˜no aproximado de 34 KB,muyinferioralrestodesolucionesexistentes. 2. Los ejecutables generados son compatibles con todas las versiones de Windows disponibles hasta la fecha, satisfaciendo as´ı uno de los requerimientos de nuestro instalador. 3. Permite la ampliaci´on de sus funcionalidades mediante invocaciones C, C++ o Delphi entre otros. 4. Al contrario que otras soluciones, genera ejecutables auto-contenidos, sin necesidad de extracci´on alguna previa a la instalaci´on. 5. Posee soporte multilenguaje. 6. Como caracter´ıstica m´as destacada, las diferentes aportaciones realizadas por la comunidad de desarrolladores, ya sea en la creaci´on de nuevos plugins o funcionalidades, como en la modificaci´on del n´ucleo de lenguaje, dot´andolo as´ı de nuevas capacidades. NSIS requiere definir previamente cada una de las p´aginas de las que constar´a el instalador, p´agina de bienvenida, selecci´on de ruta de destino, progreso de instalaci´on, realizando una configuraci´on de las mismas previa a su invocaci´on (iconos a mostrar, texto por pantalla, colores). Dentro de las soluciones suministradas por la comunidad de desarrollo, tres fueron de especial utilidad dentro de nuestra implementaci´on: 61 7. Conclusiones y trabajo futuro 7.1 Trabajo futuro 2. Unidad de detecci´on de defectos de montaje: No todos los defectos o errores presentes en un montaje poseen las mismas caracter´ısticas, ya sea en t´erminos de amplitud, frecuencia o rango temporal, luego su detecci´on no conlleva el mismo tipo de procesamiento. Como futura tarea queda la adici´on de nuevos m´etodos de detecci´on de defectos de montaje. 3. Plugin de visualizaci´on de actividad cerebral: Se trata de un plugin altamente optimizado, la visualizaci´on en tiempo real de la actividad cerebral conlleva el interpolado y representaci´on de gran cantidad de puntos en cada uno de los ciclos de adquisici´on (30 ms), a tal efecto y como ya se ha comentado en secciones anteriores, se fij´o el tama˜no del mismo con el fin de pre-calcular los coeficientes de interpolaci´on, disminuyendo as´ı en gran medida el tiempo de c´alculo y permitiendo su ejecuci´on en un tiempo estimado de entre 2 y 6 ms. Es esta extrema especializaci´on la que lo convierte en un plugin r´ıgido para ciertos interfaces de usuario, quedando pues como trabajo futuro la implementaci´on de una soluci´on intermedia, donde se sacrifique cierto tiempo de ejecuci´on en pro de una mayor flexibilidad. 4. Informe: Como comentamos en el cap´ıtulo 2 las terapias basadas en neurofeedback son el resultado de un intenso trabajo multidisciplinar, y como resultado, los avances realizados en cada una de ellas influyen enormemente sobre el resto. Quedar´ıa pues como trabajo en un futuro, la adaptaci´on del report a estas nuevas exigencias, inclusive su reimplementaci´on. 5. Instalador: En su caso, futuras versiones deben implementarse sobre la estructura proporcionada por ”Modern User Interface”[30] correspondiente tambi´en a NSIS, pero m´as cercano visualmente a los interfaces modernos. Se trata entonces, de modificaciones en el aspecto y no en la estructura o funcionamiento del instalador. 68 Bibliograf´ıa [1] J.R.Wolpaw, N.Birbaumer, D.J.McFarland, G.Pfurtscheller, and T.M.Vaughan. Brain-computer interfaces for communication and control. Clinical Neurophysiology., 113(6), 2002. [2] T.H.Budzynski, H.K.Budzynski, J.R.Evans, and A.Abarbanel. Introduction to Quantitative EEG and Neurofeedback, Second Edition: Advanced Theory and Applications. Academic Press, 1999. [3] C.Escolano, J.Antelis, and J.M´ınguez. Human Brain-Teleoperated Robot between Remote Places. IEEE International Conference on Robotics and Automation.,September 2009. [4] I.Iturrate, J.Antelis, A.K¨ubler, and J.M´ınguez. Non-Invasive Brain-Actuated Wheelchair based on a P300 Neurophysiological Protocol and Automated Navigation. IEEE Transaction on Robotics, June 2009. [5] T.Elbert, N.Birbaumer, P.Wolf, A.Duchting-Roth, M.Reker, I.Daum, W.Lutzenberger, and J.Dichgans. Cortical sefl-regulation in patients with epilepsies. Epilepsy res, 14:63–72, 1993. [6] J.N. Demos. Getting started with neurofeedback. WW Norton, 2005. [7] H.Gevensleben, B.Holl, and B.Albrecht. Is neurofeedback an efficacious treatment for ADHD? A randomised controlled clinical trial. Journal of Child Psychology and Psychiatry and Allied Disciplines., 50(7), 2009. [8] M.Abikoff. Cognitive training in ADHD children: less to it than meets the eye. Journal of Learning Disabilities, 24:205–209, 1991. [9] U.Strehl. Self-regulation of Slow Cortical Potentials: A New Treatment for Children With Attention-Deficit/Hyperactivity Disorder. Pediatrics, 2006. [10] E.G.Peniston and P.J.Kulkosky. Alpha-theta brainwave training and beta-endorphin levels in alcoholics. Alcolism: Clinical and Experimental Research, 13:271–279, 2007. 69 [11] Actualidad Econ´omica. Sistema para hacer gimnasia mental en pacientes de fibromialgia y depresi´on. http://bitbrain.es/wp-content/uploads/2011/09/ ActualidadEconomicaBBT.pdf, 2011. [12] Neurosky. Brainwave sensors for everybody. http://www.neurosky.com/, 2010. [13] B. Hamadicharef, Xu Mufeng, and S.Aditya. Brain-Computer Interface (BCI) Based Musical Composition. Cyberworlds (CW), 2010 International Conference on ,pages 282–286, 2010. [14] Neurowear. Nekomimi. http://neurowear.com/, 2011. [15] C.Escolano, M.Aguilar, and J.M´ınguez. Effects of Upper Alpha Neurofeedback Training on Working Memory Performance and on Electrophysiology. 33 rd Annual International IEEE EMBS Conference, April 2011. [16] B. Zoefel, R.J.Huster, and Christoph S.Herrmann. Neurofeedback training of the upper alpha frequency band in EEG improves cognitive performance. NeuroImage, August 2010. [17] S. Hanslmayr, P. Sauseng, M. Doppelmayr, M. Schabus, and W. Klimesch. Increasing individual upper alpha power by neurofeedback improves cognitive performance in human subjects. Applied Psychophysiology and Biofeedback, 2005. [18] W. Klimesch. EEG alpha and theta oscillations reflect cognitive and memory performance: a review and analysis. Brain Research Reviews, 1999. [19] Nokia. Qt libraries. http:/qt.nokia.com, 1992. [20] Nokia. Qpainterpath library. http://doc.qt.nokia.com/latest/qpainterpath. html, 1992. [21] Nokia. Qpainter library. http://doc.qt.nokia.com/stable/qpainter.html,1992. [22] Conrad Sanderson. Armadillo libraries. http://arma.sourceforge.net/, 2007. [23] Uwe Rathmann. Qwt libraries. http://qwt.sourceforge.net/, 1997. [24] Nokia. Qt linguist. http://doc.qt.nokia.com/latest/linguist-manual.html, 1992. [25] NullSoft. Nsis reference. http://nsis.sourceforge.net/Main_Page.html, 2001. [26] Dselkirk and Eccles. Logiclib plugin. http://nsis.sourceforge.net/LogicLib. html, 2004. [27] NullSoft. x64 plugin. http://nsis.sourceforge.net/Include/x64.nsh, 2004. [28] NullSoft. Environment path manipulation plugin. http://nsis.sourceforge.net/ Path_Manipulation.html, 2004. 70 [29] NullSoft. Script reference. http://nsis.sourceforge.net/Docs/Chapter4.html, 2004. [30] NullSoft. Nsis mui reference. http://nsis.sourceforge.net/Docs/Modern%20UI/ Readme.html, 2007. 71 72