VR Class. Procesamiento y manipulación de imágenes … · entorno de desarrollo Unity3D que...
Transcript of VR Class. Procesamiento y manipulación de imágenes … · entorno de desarrollo Unity3D que...
Álvaro García León
Arturo Jaime Elizondo
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Grado en Ingeniería Informática
2014-2015
Título
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
VR Class. Procesamiento y manipulación de imágenes deescáneres biomédicos mediante realidad virtual y
seguimiento de manos
Autor/es
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015
publicaciones.unirioja.esE-mail: [email protected]
VR Class. Procesamiento y manipulación de imágenes de escáneres biomédicos mediante realidad virtual y seguimiento de manos, trabajo fin de
gradode Álvaro García León, dirigido por Arturo Jaime Elizondo (publicado por la Universidad
de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a lostitulares del copyright.
Autor: Álvaro García León
Tutor: Arturo Jaime Elizondo
Curso académico: 2014/15
Grado en Ingeniería
Informática
Departamento de Matemáticas
y Computación
Facultad de Ciencias, Estudios
Agroalimentarios e Informática
VR Class
Procesamiento y manipulación de
imágenes de escáneres biomédicos
mediante realidad virtual y
seguimiento de manos
3
Universidad de La Rioja TFG – VR CLASS
RESUMEN El campo de la realidad virtual no es nuevo, este concepto apareció por primera vez
en 1965 de la mano de Ivan Sutherland quién desarrolló las primeras teorías. Más
tarde con la aparición del estereoscopio en 1844, se obtuvo el primer visor de
realidad virtual de la historia. Sin embargo este artilugio y la teoría que lo acompaña
ha evolucionado1 hasta lo que hoy conocemos como casco de realidad virtual todo
gracias a empresas como Oculus, propiedad de Facebook la cual ha provocado un
nuevo auge de esta tecnología en los últimos 15 años.
Debido a este nuevo auge de la realidad virtual y la posibilidad de hacer uso de ella,
se decidido desarrollar una aplicación de escritorio que permita ver las aplicaciones
útiles que puede tener la realidad virtual en un futuro en campos como la medicina o
la educación.
El desarrollo de dicha aplicación viene explicado más adelante en este documento,
pero para ser breve simplemente diré que esta usa las gafas Oculus Rift para
visualizar modelos 3D e imágenes 2D que permitan estudiar conceptos teóricos sobre
medicina y de esta forma dar un nuevo punto de vista interactivo al aprendizaje de
los alumnos de cursos formativos.
Por otra parte he incluido otra tecnología como es el reconocimiento de gestos de la
mano, el cual puede capturarse mediante Leap Motion, que básicamente es un
dispositivo con sensores de infrarrojos y que es capaz de detectar huesos de la mano
con la suficiente precisión para detectar gestos. Así puedo combinar ambos para
crear entornos 3D y simular la interacción de la persona con el modelo como si fuese
real.
Para usar ambos dispositivos, me he valido de integración de los mismos en el
entorno de desarrollo Unity3D que además me permite programar la totalidad de la
aplicación en C#, un lenguaje de programación conocido ya en el grado de ingeniería
informática al cual va destinado este proyecto.
Para concluir esta introducción y comenzar con los detalles del proyecto añadiré que
este tipo de aplicaciones están siendo desarrolladas por otras personas del mundo y
su finalización conlleva mucho tiempo dado el tipo de contenidos que emplea
(gráficos y nuevas tecnologías aún en desarrollo). Por lo tanto y para que sirva de
ejemplo antes de la demostración de la aplicación que yo mismo desarrollaré incluyo
aquí dos videos para dar una idea de lo que se intenta crear:
https://www.youtube.com/watch?v=cJZyRtjvJEM
https://www.youtube.com/watch?t=38&v=f5IyCGSQ-6Y
1 Auge, caída y nuevo auge de la realidad virtual, artículo en The Verge.
4
Universidad de La Rioja TFG – VR CLASS
SUMMARY Virtual Reality’s field isn’t new, this concept appeared for the first time in 1965 by
Ivan Sutherland who developed the first theories. Later with the appeareance of the
stereoscope in 1844, the first virtual reality viewer in history was obtained. However
this gadget and its accompanying theory has evolved2 until today we know as head
mounted display all thanks to companies like Oculus, property of Facebook, which
has led to a revival of this technology in the last 15 years.
Because of this new boom of virtual reality and the possibility of making use of it, was
decided to develop a desktop application that allows to see the useful applications
that virtual reality can have in the future in fields like medicine or education.
The development of this application is explained later in this document, but to be
brief I’m going to simply say it uses Oculus Rift glasses to display 3D models and 2D
images for the study of theoretical concepts of medicine and thus give a new
interactive perspective of the learning of students in training courses.
Moreover I have included other technology such as the recognition of hand gestures,
which can be captured using Leap Motion, which is basically a device with infrared
sensors that can detect hand bones with sufficient accuracy to detect gestures. So I
can combine both to create 3D environments and simulate the interaction of the
person with the model as if it were real.
To use both devices, I have used its integration with the development environment
Unity3D which also allows me to program the entire application in C#, a
programming language known in the degree of computer science which this project is
intended for.
To conclude this introduction and start with the project details I will add that these
applications are being developed by other people in the world and its completion
time takes much time given the type of content that it employs ( graphics and new
technologies still in development ) . Therefore, and to serve as an example before the
demo of the application that I will develop, two videos are included here to give an
idea of what we are trying to create:
https://www.youtube.com/watch?v=cJZyRtjvJEM
https://www.youtube.com/watch?t=38&v=f5IyCGSQ-6Y
2 Rise , fall and rise of virtual reality, article on The Verge.
5
Universidad de La Rioja TFG – VR CLASS
ÍNDICE RESUMEN .................................................................................................................................... 3
SUMMARY................................................................................................................................... 4
INTRODUCCIÓN .......................................................................................................................... 6
Motivaciones .......................................................................................................................... 6
Objetivo .................................................................................................................................. 6
DESARROLLO DEL PROYECTO ..................................................................................................... 7
PLANIFICACIÓN ........................................................................................................................... 8
Gestión del alcance ................................................................................................................. 8
Gestión del tiempo ............................................................................................................... 11
Gestión de adquisiciones ...................................................................................................... 18
ANÁLISIS DE REQUISITOS .......................................................................................................... 19
Requisitos funcionales .......................................................................................................... 20
Requisitos no funcionales ..................................................................................................... 24
Requisitos mínimos hardware .............................................................................................. 24
DISEÑO ...................................................................................................................................... 25
Arquitectura del sistema ...................................................................................................... 25
Diseño de la interfaz ............................................................................................................. 26
Diseño de la base de datos ................................................................................................... 33
Organización de contenidos dentro de la aplicación ........................................................... 37
Diseño de las clases .............................................................................................................. 38
IMPLEMENTACIÓN.................................................................................................................... 39
Tecnologías utilizadas ........................................................................................................... 39
Estructura del proyecto ........................................................................................................ 41
Lógica de negocio y persistencia .......................................................................................... 43
Interfaz .................................................................................................................................. 48
DESPLIEGUE Y PRUEBAS DEL SISTEMA ..................................................................................... 51
SEGUIMIENTO Y CONTROL ....................................................................................................... 54
LECCIONES APRENDIDAS .......................................................................................................... 57
MEJORAS ................................................................................................................................... 59
ANEXOS ..................................................................................................................................... 60
BIBLIOGRAFÍA ........................................................................................................................... 68
AGRADECIMIENTOS .................................................................................................................. 69
6
Universidad de La Rioja TFG – VR CLASS
INTRODUCCIÓN El contenido incluido a continuación en esta memoria detalla el desarrollo de una
aplicación de realidad virtual como trabajo de fin de grado en Ingeniería Informática,
por la Universidad de La Rioja, en colaboración con la empresa CreativiTIC Innova S.L.
Comenzaré explicando cuales han sido las principales razones para llevar a cabo este
proyecto.
Motivaciones
Actualmente mi empresa de prácticas ha colaborado en un proyecto junto con el
Centro de Investigación Biomédica de La Rioja (CIBIR) en el que se procesan imágenes
de escáneres biomédicos en 2D para extraer modelos 3D de las mismas y más tarde
puedan manipularse mediante gestos. Este proyecto está dirigido a profesionales de la
medicina en ámbitos como radiología o medicina nuclear que utilizan equipos
informáticos evaluaciones de casos de pacientes a los que tratan o en sus
investigaciones.
Sin embargo, algunos miembros del personal médico que participan en el proyecto
también imparten sesiones formativas a alumnos de medicina en estos campos y según
su experiencia, los alumnos que asisten tienen ciertas dificultades para entender
ciertos conceptos mostrados en las sesiones.
Por esta razón he pensado que una buena forma de solventar dicho problema es hacer
uso de la realidad virtual, desarrollando una aplicación que permita enseñar de forma
interactiva dichos conceptos a los alumnos de esas sesiones.
Por último, es necesario destacar que esta aplicación no tiene un destinatario concreto
(un cliente), sino que la intención es desarrollarla como un ejemplo de las aplicaciones
que tiene la realidad virtual en el ámbito educativo y mostrar así su potencial en este
campo.
Objetivo
El objetivo de este proyecto es, por tanto, el de desarrollar una aplicación de realidad
virtual que permita enseñar conceptos teóricos y prácticos relacionados con diversos
ámbitos médicos haciendo uso de representaciones en dos y tres dimensiones y
preguntas relacionadas sobre dichos conceptos.
Concretamente su propósito consiste en mostrar las posibilidades que ofrece la
realidad virtual como nuevo paradigma de educación, haciendo a esta mucho más
interactiva para los alumnos de forma que la asimilación de conceptos sea más fácil.
8
Universidad de La Rioja TFG – VR CLASS
PLANIFICACIÓN Gestión del alcance
Planificación del alcance
En la fase más temprana de este proyecto se ha intentado definir los límites del
producto que se iba a desarrollar. Sin embargo, debido al deseo de hacer uso de
tecnologías innovadoras como son la realidad virtual y la detección de gestos se ha
tardado más tiempo en hacerlo por varias razones.
La primera es el análisis de alternativas, dado que en la empresa de prácticas se tiene
acceso a varias tecnologías similares pero no todas son sencillas de usar y de
desarrollar con ellas.
La segunda y más importante es que este tipo de productos engloban varias
tecnologías, entre ellas los gráficos 3D y este es un campo muy amplio que no entra
entre los conocimientos adquiridos en el grado de Ingeniería Informática, por esto
mismo, es necesario limitar el uso de dichas tecnologías hasta el punto en el que no
sobrepasen el tiempo máximo ni los conocimientos necesarios para llevar a cabo dicho
proyecto.
De esta forma, el alcance quedará limitado a la parte más básica de los gráficos 3D y
se centrará más en el desarrollo de una aplicación tal y como la hemos visto a lo largo
del grado, es decir, realizando análisis, diseño e implementación y dividiendo en capas
los componentes de la misma.
Definición del alcance
El producto que se va a desarrollar será una aplicación de escritorio dirigida
principalmente a alumnos de cursos formativos de medicina. Las tecnologías usadas
para llevar a cabo esta tarea serán Unity3D, que incluye C# como lenguaje de
desarrollo (entre otros), Leap Motion y Oculus Rift, con los cuales podemos reconocer
gestos y simular entornos virtuales respectivamente.
Esta aplicación permitirá visualizar lecciones sobre medicina a partir de información
textual, imágenes, y modelos 3D. La obtención de dichas imágenes y modelos viene
detallada en la gestión de adquisiciones más adelante en este documento.
Generalizando más, las lecciones se agruparán en la aplicación en forma de temas
según sus contenidos. Además estos temas pueden ser valorados por los usuarios de
la aplicación.
Esta aplicación tendrá dos modos diferenciados de visualizar las lecciones. Uno será el
Modo Visor, en el que sólo se verá el modelo 3D, las imágenes y el texto necesario,
pero además el usuario podrá mover el modelo con las manos ayudándose del
dispositivo Leap Motion.
9
Universidad de La Rioja TFG – VR CLASS
El otro será el Modo Simulación, que se diferencia del primero en que aparte de lo
anterior, el usuario también ve un entorno virtual (como por ejemplo una sala de
hospital) simulando así un entorno real.
Además, la aplicación contará con una base de datos que almacene sólo la información
sobre el progreso del usuario en las lecciones que visualiza y tests que completa. Para
esta parte se usará SQLite vistos los problemas existentes con la implementación de
otras bases de datos comunes que se detallan más adelante en este documento.
Por último, aclarar que esta aplicación es considerada como la primera de dos fases en
las que se divide el objetivo propuesto inicialmente, en el que la segunda fase supondrá
la creación de una plataforma web a la que la aplicación se podrá conectar para poder
generar nuevos temas o descargarse temas ya creados por otros usuarios.
De esta manera se intentará crear una comunidad abierta en la que poder compartir y
valorar los contenidos que otros usuarios publiquen ayudando así a expandir los
contenidos disponibles para la misma.
Sin embargo, esta segunda fase queda excluida de los objetivos del proyecto debido a
la falta de tiempo para llevar a cabo todo el desarrollo en el tiempo estimado para la
realización del trabajo de fin de grado.
Podemos ver representado el alcance del proyecto en diagrama de estructura de
descomposición del trabajo adjunto en este documento más adelante (Figura 1).
10
Universidad de La Rioja TFG – VR CLASS
Estructura de Descomposición del Trabajo
Figura 1: Estructura de descomposición del trabajo
11
Universidad de La Rioja TFG – VR CLASS
Gestión del tiempo
Definición de actividades
A continuación se indica que contenidos va a abarcar el proyecto y cómo se va a
estructurar este en cada una de sus partes.
Diccionario de la EDT
1.1.1 Configuración del entorno: Instalación de MySQL Workbench3 para la creación
de la base de datos y Unity3D junto con Visual Studio4 como editor de código
para el desarrollo de la aplicación.
1.1.2 Diseño de la BD: Diseño de la base de datos desde el análisis de requisitos hasta
la distribución en tablas de la misma.
1.1.3 Conector BD: Implementación de las clases, en C#, que permiten la conexión
entre la base de datos MySQL y Unity3D para acceder a los datos y modificarlos.
1.1.4 Pruebas: Comprobar que la conexión entre la aplicación y la base de datos se
realiza correctamente y la recuperación y el almacenamiento de datos sigue lo
establecido en el análisis de datos.
1.2.1. Interfaz:
1.2.1.1. Diseño del prototipo: Se realizarán un prototipo sobre un primer diseño
de la interfaz de la aplicación. También se empezarán a definir algunos
gestos usados en la aplicación. Si es necesario también se realizará una
guía de estilo, para determinar los elementos comunes de la aplicación.
1.2.1.2. Evaluación del prototipo (I): El prototipo anterior será evaluado
centrándonos en la usabilidad y navegabilidad por parte del usuario. Se
obtendrán informes que determinen que mejoras deben realizarse en
la interfaz y que debe mantenerse.
1.2.1.3. Implementación: Menús, botones y demás componentes gráficos
deben ser generados para probar la navegación entre escenas de la
aplicación. Todo esto se llevará a cabo haciendo uso del nuevo sistema
de interfaz de usuario que Unity3D incluye en su última versión (en este
momento 4.6).
1.2.1.4. Evaluación prototipo (II): Evaluación del nuevo diseño de la interfaz y
evaluación del segundo prototipo que abarca los controles de Leap
Motion.
3 Enlace a la página web de descarga. 4 Enlace a la página web de la versión gratuita.
12
Universidad de La Rioja TFG – VR CLASS
1.2.2. Lógica de negocio: Clases para la gestión de los objetos usados en la aplicación
como temas, preguntas, lecciones, tests, etc...
1.2.3. Contenidos: Creación de varios temas con sus correspondientes lecciones, test
y datos que contengan para probar más tarde que se muestran correctamente.
1.2.4. Pruebas: Realización de pruebas para comprobar el correcto funcionamiento
de la interfaz y determinar si el diseño se adapta a la lógica de negocio definida.
Comprobar que los contenidos de los temas son recuperados correctamente
según el esquema de organización establecido y que los dispositivos Oculus y
Leap Motion son reconocidos correctamente.
1.3.1. Planificación: Creación de un plan de temporal de desarrollo del proyecto en el
que realice la división del mismo en tareas y se establezca una previsión de
tiempos para cada una de ellas.
1.3.2. Seguimiento: Revisión de las horas planificadas y reales asignadas a la
realización de las tareas del proyecto. Inclusión de cualquier desviación o re-
planificación en caso de que se produzcan.
1.3.3. Memoria: Documento con los detalles del desarrollo de la aplicación según lo
establecido por la normativa de la Universidad de La Rioja.
1.4.1. Material para la presentación: Preparación de un vídeo para la exponer la
aplicación ante el tribunal, así como imágenes y otros contenidos que incluya
la presentación.
1.4.2. Presentación: Elaboración de una presentación para la defensa del trabajo ante
el tribunal con una exposición de 15 minutos.
Cabe destacar que no se han incluido las tareas localizadas fuera de los límites del
proyecto. Es decir, la fase dos (plataforma web) no se incluye, aunque el orden de
prioridad asociado a esta continúa con la numeración establecida en el diagrama EDT
mostrado anteriormente.
Establecimiento de la secuencia de actividades
Se establece además, un orden de prioridad en el desarrollo de las actividades
anteriores con el fin de asegurar que el contenido más importante de la aplicación se
completa con éxito, dando la posibilidad de ampliar su funcionalidad en futuras
versiones.
En cuanto a este orden, queda establecido por la numeración de las tareas numeradas
previamente. Como se puede ver, este orden es incremental indicando así que las
primeras actividades son las de más importancia, aunque en realidad todas deben ser
completadas.
13
Universidad de La Rioja TFG – VR CLASS
Estimación de la duración de las actividades
Lo primero de todo es aclarar que el proyecto se llevará a cabo usando la metodología
en cascada a lo largo de 20 semanas situadas entre el 2 de Enero de 2015 y el 19 de
Junio del mismo año. Durante estas 20 semanas se excluirán del tiempo de trabajo los
fines de semana y cualquier festivo existente durante este periodo.
Lo segundo es la estructura de tareas, la cual he dejado reflejada en el diagrama EDT
ya visto en el alcance del proyecto y que he descompuesto en semanas en el
correspondiente diagrama Gantt (Figura 2).
A continuación se muestra la estimación en horas de la duración de las actividades a
lo largo de las 300 horas de tiempo que se asignan al proyecto para su realización:
Gestión de la base de datos Semanas 05 – 07
1.1.1. Configuración del entorno: 6 horas de trabajo entre el 9 y el 11 de Marzo.
1.1.2. Diseño de la base de datos: 10 horas de trabajo desde el 2 al 6 de Marzo.
1.1.3 Conector BD: 4 horas de trabajo durante los días 12 y 13 de Marzo.
1.1.4 Pruebas: 4 horas durante los días 16 y 18 de Marzo.
Aplicación Unity Semanas 08 – 18
1.2.1. Gestor BD: 4 horas a realizar entre los días 19 y 20 de Marzo.
1.2.2. Lógica de negocio: 20 horas a dividir entre el 23 de Marzo y el 17 de Abril.
1.2.3. Interfaz: 40 horas entre el 23 de Marzo y el 24 de Abril.
1.2.4. Contenidos: 40 horas entre el 27 de Abril y el 22 de Mayo.
1.2.5. Pruebas: 20 horas entre el 25 de Mayo y el 5 de Junio.
Gestión del proyecto Semanas 01 – 20
1.3.1. Planificación: 20 horas entre el 16 y el 27 de Febrero.
1.3.2. Seguimiento: 40 horas entre el 2 de Marzo y el 19 de Junio.
1.3.3. Memoria: 72 horas entre el 2 de Febrero y el 19 de Junio.
Defensa del proyecto Semanas 19 – 20
1.4.1. Material para la presentación: Del 8 al 19 de Junio se asignan 15 horas de
trabajo.
1.4.2. Presentación: 5 horas de trabajo desde el 15 al 19 de Junio
14
Universidad de La Rioja TFG – VR CLASS
A partir de esta estimación, he definido también una serie de hitos que establecerán
un punto de seguimiento y control en el cual se evaluará el trabajo realizado hasta
entonces con ayuda del tutor.
Estos eventos de importancia se pueden de forma agrupada en la tabla de hitos (Figura
2) incluida más adelante.
Además se ha creado un diagrama Gantt con los tiempos estimados para cada tarea
indicando el orden de desarrollo del alcance del proyecto. Al igual que el diagrama de
hitos, este se encuentra más adelante.
18
Universidad de La Rioja TFG – VR CLASS
Gestión de adquisiciones
Obtención de imágenes y modelos
Dado que la gran mayoría de las imágenes en formato DICOM que se desea utilizar en
la aplicación son privadas por considerarse datos personales y de nivel alto según la
Ley Orgánica de Protección de datos (LOPD5) y los servicios médicos no dan acceso a
las mismas, optaré por utilizar imágenes obtenidas a partir de alguna de las fuentes de
imágenes DICOM abiertas y gratuitas que hay disponibles en Internet como por
ejemplo:
http://www.dicomlibrary.com/
http://www.osirix-viewer.com/datasets/
Sin embargo, si más adelante esta aplicación fuese adherida a cursos de formación
oficiales y se tuviese acceso a imágenes de pacientes, estas siempre deberán requerir
la autorización necesaria para su uso en la aplicación.
No se tienen en cuenta, para este caso, aquellas imágenes o modelos utilizados en la
aplicación que sean obtenidos o generados a partir de otros medios ajenos a personas
físicas, como por ejemplo, modelos realizados con software de modelado 3D.
Generación de modelos
Otro aspecto importante a tener en cuenta, es la generación de los modelos 3D que la
aplicación usará. En un principio estos se obtendrán a partir de un programa externo
a la aplicación que se desarrollará en este proyecto y que por tanto no se incluye
dentro del alcance del mismo, sin embargo, es posible que más adelante esta
funcionalidad que aporta dicho programa, podrá ser incluida en la aplicación mediante
plugins o librerías adheridas a Unity3D.
Un ejemplo de ello sería usar la librería VTK6, que para los que no la conozcan se trata
de una librería de código abierto especializada en visualización de datos,
procesamiento de imágenes y gráficos en 3D, la cual se usa mucho en investigación.
Más concretamente podemos hacer uso de un plugin de Unity3D (VTKtoUnity7) que
permite usar esta librería de C++ en C# y así poder visualizar los modelos 3D sin
necesidad de generar el modelo 3D y guardarlo en un fichero que Unity3D pueda
manipular.
5 Enlace al reglamento de la LOPD. 6 Enlace a la web de la librería. 7 Página del proyecto en Github.
19
Universidad de La Rioja TFG – VR CLASS
ANÁLISIS DE REQUISITOS En esta sección comentaré con más detalle cada fase del proceso de desarrollo de la
aplicación para dar una idea más clara de sus elementos. Comenzaré por el análisis de
requisitos:
La aplicación permitirá al usuario elegir un tema de entre todos los disponibles en un
catálogo. Cada tema contendrá al menos una lección y cada lección tendrá un conjunto
de imágenes en 2D y al menos un modelo 3D, generado (o no) previamente a partir de
dichas imágenes, que junto con información textual permitirán seguir la lección.
Opcionalmente las lecciones podrán poseer tests con listas de preguntas que sirvan
para afianzar conceptos mostrados en la misma y que el usuario podrá elegir responder
o no. Siguiendo con la lección elegida por el usuario, este deberá decidir qué modo de
visualización desea.
Existirán dos modos, el primero llamado “Visor”, en el cual las imágenes y el modelo
3D se mostrarán y el usuario controlará el movimiento de la cámara mediante Leap
Motion. Y el segundo, llamado “Simulador”, en el que el usuario es inmerso en un
entorno virtual real, como habitaciones de quirófano o similares donde tiene la
posibilidad interactuar con equipamiento real desde el punto de vista de primera
persona (a través de las gafas Oculus Rift) y pueda realizar diagnósticos a partir de la
información que se le suministre, aplicando así conceptos de las lecciones.
Cabe destacar que no siempre estarán disponibles ambos modos, ya que esto
dependerá de la lección. Por lo tanto, los modelos podrán verse tanto en el modo Visor
como dentro del modo Simulador pero no ocurre lo mismo con los entornos, los cuales
no son representados en el modo Visor.
Por otra parte, los temas vendrán clasificados en categorías según los contenidos de
los mismos y la valoración que los usuarios den de estos. Además este catálogo será
actualizable cuando la aplicación se conecte a una web que hará de repositorio.
Un punto a tener en cuenta también, es que las respuestas de las preguntas de test
deben ser sólo leídas por la aplicación para evitar que alguna persona se beneficie de
ello. Por eso mismo, la aplicación se encarga de cifrar o comprimir los datos
debidamente.
20
Universidad de La Rioja TFG – VR CLASS
Requisitos funcionales
A continuación se definen los casos de uso que contienen la funcionalidad de la
aplicación:
CU1. Iniciar sesión
Actor: Usuario
1. El usuario inicia la aplicación y tras pasar la pantalla de carga, le aparece el
formulario de inicio de sesión.
2. El usuario introduce los datos de su cuenta e inicia sesión.
3. Se carga el menú principal con la información existente de ese usuario.
Extensiones:
1. Si el usuario introduce datos incorrectos correspondientes a una cuenta de
usuario, la aplicación muestra un mensaje de error y pide que vuelva a
introducir los datos.
CU2. Elegir tema
Actor: Usuario
1. El usuario pulsa en comenzar y navega por el catálogo de temas.
2. Elige un tema del catálogo.
3. El sistema muestra información sobre las lecciones disponibles en ese
tema.
CU3. Cambiar configuración
Actor: Usuario
1. El usuario selecciona el menú de configuración.
2. Modifica las opciones de configuración según sus preferencias.
3. Guarda las preferencias y vuelve al menú principal.
Extensiones:
1. Si el usuario no guarda las preferencias antes de salir, estas no se
guardarán.
CU4. Elegir lección
Actor: Usuario
1. El sistema muestra el listado de lecciones contenidas en el tema
seleccionado una por una.
2. El usuario escoge uno de ellos de la lista.
3. El sistema muestra información de la lección.
21
Universidad de La Rioja TFG – VR CLASS
CU5. Visualizar lección.
Actor: Usuario
Precondiciones: La lección debe estar descargada previamente para poder usarla.
1. El sistema muestra la información de la lección.
2. El usuario elige la opción de visualizar la lección.
3. El sistema muestra que modos de visualización están disponibles para
dicha lección, mostrando información sobre lo que hace cada uno de ellos.
CU6. Elegir modo.
Actor: Usuario
1. El sistema está mostrando que modos de visualización están disponibles.
2. El usuario elige uno de ellos.
3. El sistema carga el primer modelo de la lección así como las imágenes
correspondientes si se elige el modo visor o permite elegir el modelo que
desea simular si se elige el modo simulación.
CU7. Valorar tema
Actor: Usuario
1. El sistema muestra la información sobre el tema, entre ella la valoración
previa de ese tema si la tiene.
2. El usuario elige la opción de valorar el tema.
3. El usuario escoge una puntuación para valorar el tema.
4. El sistema aplica esa valoración y calcula la nueva puntuación en función
de la nueva valoración y las anteriores, si las tiene.
CU8. Responder tests
Actor: Usuario
1. El sistema muestra la información de una lección.
2. A continuación, si la lección contiene tests asociados, el usuario puede
seleccionar responderlos.
3. El sistema entonces cargará los tests de esa lección y se los mostrará al
usuario.
22
Universidad de La Rioja TFG – VR CLASS
CU9. Elegir test
Actor: Usuario
1. Se muestra la lista de test disponibles.
2. El usuario elige uno.
3. El sistema carga la primera pregunta del test para que el usuario pueda
empezar a responderla.
CU10. Omitir pregunta
Actor: Usuario
1. Mientras el usuario está respondiendo preguntas, el sistema mostrará la
pregunta correspondiente en cada momento.
2. Si el usuario desea no contestarla o no la sabe, puede omitir la pregunta y
pasar a la siguiente seleccionando la opción de omitir.
3. Entonces el sistema contará esa pregunta cómo no contestada y pasará a
mostrar la siguiente.
CU11. Mover modelo
Actor: Usuario
1. El sistema está mostrando el modelo 3D en pantalla.
2. El usuario puede en este momento rotar, hacer zoom y moverlo mediante
los gestos establecidos para cada tarea.
3. El sistema debe detectar estos gestos y realizar la transformación sobre el
modelo 3D de acuerdo a estos.
Todos estos casos anteriormente nombrados se incluyen en el siguiente diagrama de
casos de uso.
24
Universidad de La Rioja TFG – VR CLASS
Requisitos no funcionales
Requisitos tecnológicos
La aplicación está pensada para ser usada con Oculus Rift y Leap Motion
principalmente, pero si no se dispone de alguno de estos dispositivos, la aplicación
puede adaptarse para usar teclado y ratón y el monitor por defecto del ordenador.
Sin embargo de esta forma, la experiencia de usuario no será la misma que se había
pensado para esta aplicación.
Requisitos de interfaz
La interfaz de cualquiera de los dos modos de visualización está pensada para hacer
uso de Leap Motion como medio de interacción con la aplicación. Por lo tanto, estas
deben seguir las guías de diseño de Leap Motion a la hora de diseñar los menús y
adaptar su funcionamiento al uso de los gestos. La interfaz del resto de menús quedará
en manos de los resultados de la fase de diseño del proyecto.
Por otra parte, al tratarse de tecnologías poco conocidas, será conveniente que se
incluya un tutorial de uso de la aplicación dentro de la misma.
Requisitos de rendimiento
Al tener un fuerte componente visual, la aplicación debe ofrecer una experiencia de
usuario rápida y sencilla, de forma que tanto las interacciones como la manipulación
de los modelos 3D sean fluidas y tengan el menor tiempo de respuesta posible.
Requisitos mínimos hardware
Para poder hacer uso de toda la funcionalidad de la aplicación es recomendable tener
el siguiente equipamiento:
Gafas de realidad virtual Oculus Rift:
o Windows 7 o superior, Mac OS X 10.8 o superior o Linux Ubuntu 12.04
LTS o superior.
o Procesador de 2 GHz como mínimo
o 2 GB de RAM.
o Puertos HDMI o DVI y USB 2.0
o Tarjeta gráfica compatible con Direct3D 10 u OpenGL 3, capaz de correr
juegos en 1080p a 75 FPS o superior.
Dispositivo de tracking Leap Motion.
o Windows 7 o superior o Mac OS X 10.7
o Procesador AMD Phenom II o Intel Core i3/i5/i7
o Puerto USB 2.0
Conexión a Internet, para poder conectarse a la plataforma web y descargar
nuevos contenidos.
25
Universidad de La Rioja TFG – VR CLASS
DISEÑO Arquitectura del sistema
La aplicación creada en esta primera fase sigue el esquema cliente-servidor, siendo
esta el cliente que realiza peticiones al servidor para obtener nuevos contenidos para
visualizar en la misma.
El cliente consiste en una aplicación de escritorio, inicialmente para sistemas
operativos Windows pero que será ampliada posteriormente a entornos Linux y Mac.
Este sigue una arquitectura dividida en tres capas, en la cual podemos distinguir la
interfaz de usuario, lógica de negocio y los datos.
La capa de presentación o interfaz de usuario viene compuesta por las
escenas que Unity3D utiliza para visualizar los distintos menús y los scripts
encargados de gestionar eventos y modificaciones en esas escenas.
En segundo lugar tenemos la lógica de negocio, en la cual se incluyen las
clases asociadas a los objetos que la aplicación gestiona como pueden ser
temas o lecciones junto con otras clases auxiliares para una gestión más
sencilla de la aplicación.
Por último tenemos los datos, a los que accedemos a través de una capa de
acceso, entre los que encontramos la base de datos SQLite y el resto de
ficheros que contienen los modelos 3D, las imágenes 2D y los temas,
lecciones y test con sus respectivas preguntas.
Adicionalmente tendremos un servidor que dará soporte a la aplicación web que
permite crear y compartir nuevos temas para usar en el cliente. Las especificaciones
de dicho servidor aún están por concretar, pero si se puede asegurar casi con total
seguridad que el sistema gestor de base de datos será MySQL vistos los problemas de
compatibilidad con ciertos proveedores de bases de datos al usar Unity3D.
Figura 5: Arquitectura del sistema
26
Universidad de La Rioja TFG – VR CLASS
Diseño de la interfaz
Contexto
Teniendo en cuenta que la aplicación que se va a desarrollar tiene un alto contenido
visual se le debe dar mayor importancia al diseño de la interfaz. Sin embargo, durante
el desarrollo de la misma, el entorno de desarrollo Unity3D se ha visto actualizado
hasta tres veces durante las cuales se ha añadido un nuevo sistema para la creación de
interfaces.
Cabe destacar que el sistema inicial previo a dichas actualizaciones era arcaico y había
que crearlo todo mediante código. Por el contrario el nuevo sistema (incluido a partir
de la versión 4.6), elimina todo ese código y permite generar las interfaces desde el
editor de manera visual, simplificando la tarea tan sólo a arrastrar y soltar
componentes y programando los eventos.
En la captura siguiente puede verse el editor de Unity3D en acción diseñando uno de
los menús de la aplicación mediante el nuevo sistema de interfaz de usuario.
Creación del prototipo de la interfaz
Como ya se ha mencionado en el alcance, se planificó la creación de dos prototipos de
la interfaz que iba a usar la aplicación. Uno de ellos abarcaba los menús de navegación
desde el comienzo de esta hasta justo la selección del modo de visualización. El
segundo prototipo, por el contrario se centraba sólo en los modos de visualización
donde se muestran los modelos y las imágenes.
Lo primero que se realizó fue el primero de los prototipos anteriores, en el ordenador
mediante la herramienta de dibujo vectorial8 Inkscape. El prototipo debía ser
interactivo, cosa que se consiguió añadiendo código Javascript a las propiedades de los
ficheros generados en Inkscape. Después simplemente podría ser visualizado desde un
navegador web como Chrome o Firefox.
8 Información sobre gráficos vectoriales.
Figura 6: Componentes de interfaz en Unity3D (versión 4.6)
27
Universidad de La Rioja TFG – VR CLASS
Sin embargo el segundo prototipo quedó sin realizar debido a la falta de tiempo tal y
como se explica en el seguimiento y control. Por tanto, lo que veremos aquí será el
proceso de evaluación del primer prototipo.
NOTA: Para evitar ocupar espacio en esta sección, se incluirán capturas del prototipo
en los anexos que se incluirán al final del documento.
Método de evaluación de la usabilidad
Primero comenzaré explicando por qué y cómo se ha evaluado el prototipo y luego las
razones por las qué se ha hecho de esa forma:
El objetivo de la creación del prototipo no es más que la posterior evaluación de su
usabilidad. En este caso con usabilidad nos referimos a que sea fácil de usar, pero en
otros casos podría buscarse otra cosa. Evaluando si es fácil de usar conseguimos que
los usuarios sin experiencia con ordenadores consigan utilizar la aplicación
rápidamente y sin problemas.
Por otra parte, el método de evaluación elegido para comprobar si es usable o no la
interfaz se conoce como recorrido cognitivo. Este método se clasifica (entre los
métodos de evaluación existentes aprendidos en la asignatura de Diseño de Interfaces
de Usuario) como método de inspección.
Este tipo de métodos consiste en elegir a un grupo de evaluadores expertos que se
encargarán de examinar aspectos relacionados con la usabilidad mediante la
exploración del prototipo.
Concretamente el método elegido evalúa la facilidad de aprendizaje el cual es el
objetivo principal de esta evaluación. Además este método está pensado para ser
usado durante la fase de diseño que es donde nos encontramos ahora.
A continuación se muestran los pasos que se siguen al realizar la evaluación con este
método de evaluación:
Paso 1
Lo primero que debe hacerse es elegir varias tareas que se realizan en la aplicación que
sean representativas, es decir, que sean comunes a toda la aplicación. Posteriormente
se presentan al grupo de evaluadores junto con los pasos a seguir para su realización,
definidos por el autor del prototipo y para que comprueben si son adecuados o deben
ser modificados.
Paso 2
Para cada tarea, cada evaluador intenta realizar los pasos necesarios para completarla
de forma correcta según su criterio, explicando a la vez de forma creíble el por qué los
usuarios ejecutarán los pasos de la misma forma que él.
28
Universidad de La Rioja TFG – VR CLASS
Los motivos que el evaluador crea que llevarán a los usuarios a realizar esos pasos
pueden ser la experiencia previa, la información que la interfaz proporcione o una
correcta retroalimentación hacia el usuario cumpliendo con el objetivo deseado entre
otras.
Paso 3
La aplicación (sistema) realizará la acción correspondiente al paso realizado por el
evaluador y mostrará la realimentación.
Paso 4
Finalmente, el evaluador debe verificar que los pasos realizados por él mismo son
semejantes a los definidos por el autor y por tanto dirigen al éxito en la resolución de
la tarea. En caso contrario, se comunicará el problema mediante un informe que
veremos más adelante.
Para comprobar que la tarea se está realizando con éxito, los propios evaluadores
deberán preguntarse las siguientes 4 preguntas:
1. ¿Los usuarios intentarán alcanzar el objetivo correctamente?
2. ¿El usuario se dará cuenta de que está disponible la acción correcta?
3. ¿El usuario asociará la acción correcta al efecto que se alcanzará?
4. ¿El usuario verá que se está progresando hacia la solución de la tarea, si se
realiza la acción correcta?
Si al responder a estas preguntas, la respuesta es en su mayoría sí, entonces es que el
diseño de la interfaz es fácil de aprender y por tanto usable.
Evaluadores y tareas
Tras explicar en qué consiste el método y su realización, lo que hay que aclarar son
quienes han sido los evaluadores del prototipo y cuáles son las tareas que han
evaluado:
Evaluadores:
- Se acordó la evaluación de los prototipos por parte de los alumnos de la
asignatura optativa de Diseño de Interfaces de Usuario a través de
reuniones con la profesora María Vico Pascual.
- Esta que se imparte en el grado de Ingeniería Informática durante los
últimos años de dicho grado. Dicha evaluación formaría parte de un
ejercicio para la asignatura.
- Su elección se debe a la experiencia necesaria que dichos alumnos poseen
para evaluar un prototipo desde el punto de vista de un experto evaluador
de interfaces de usuario.
29
Universidad de La Rioja TFG – VR CLASS
Tareas:
1. Iniciar la lección nº 1 del tema “Medicina nuclear” en modo visor.
2. Dar una valoración de 3 estrellas al tema “Medicina nuclear”.
Las dos tareas elegidas implican un flujo de navegación amplio a lo largo de la
aplicación, lo que permitirá obtener una retroalimentación de cómo el usuario
interactúa con la mayor parte de la aplicación.
Informe de evaluación
Continuando con el ejercicio de evaluación, el autor del prototipo y de la aplicación
debe de crear formularios como el siguiente para que los evaluadores puedan
comunicar sus resultados de la evaluación y poder sacar las conclusiones a partir de
ellos:
32
Universidad de La Rioja TFG – VR CLASS
Como puede verse el formulario contiene las cuatro preguntas anteriores y la
secuencia de pasos a seguir para cada tarea. Además se le ha añadido un campo de
sugerencias en el que los evaluadores podían incluir recomendaciones.
Lo siguiente era distribuirlo así que aprovechando que la herramienta Google Drive
permite crearlos la usamos para poder agrupar todos los resultados de forma online y
centralizada y sacar posteriormente conclusiones.
Resultados
Tras un periodo para su realización, los 16 evaluadores enviaron el formulario, así que
el siguiente paso es leerlos y resumir los resultados en acciones sencillas que permitan
cambiar el prototipo para conseguir que solucionen los problemas expuestos en dichos
informes.
Dichos informes establecen los siguientes problemas en la interfaz (el número de
evaluadores que incidían en el ese problema se indica entre paréntesis):
- Dificultad de uso del menú principal de la aplicación (14/16):
El usuario desconoce cómo navegar entre las opciones de dicho menú y si
están disponibles o no.
- Falta de retroalimentación al realizar ciertas acciones (5/16):
Por ejemplo, al valorar un tema no se comunica si lo ha hecho
correctamente o no saber si un botón realiza una acción.
- Posibilidad de perderse durante la navegación entre menús (3/16):
Cuanto más en profundidad entra el usuario en la elección de un tema,
menos sabe dónde se encuentra dentro de la aplicación, ya que no hay
información del menú en el que se encuentra.
- Necesidad de pequeñas ayudas al colocar el ratón sobre los botones de la
interfaz (3/16):
Algunos botones no informan de la funcionalidad que realizan, como la
flecha de vuelta al menú anterior.
Gracias en mayor parte a la inclusión de las sugerencias en el formulario y junto con el
resto de preguntas se puede apreciar que aunque no haya muchos marquen un
problema en la interfaz, el hecho de que varios coincidan da lugar a posibles problemas
que también podrían tener los usuarios y que también deben solventarse.
Finalmente ante estos problemas se ha planteado el siguiente informe con las
siguientes soluciones por parte del autor del prototipo:
- Cambio del diseño del menú principal por un menú circular completamente
visible que muestra información sobre cada opción al colocarse encima de
ella.
- Inclusión de cabeceras para los menús que indiquen el menú en el que se
encuentra el usuario y que debe realizar.
33
Universidad de La Rioja TFG – VR CLASS
- Se ha añadido migas de pan en los menús de selección de tema y lección,
así como otros incluidos posteriormente.
- En la versión funcional final de la aplicación los botones cambian de color
para indicar que están activos o deshabilitados.
- Añadida la posibilidad de valorar un tema haciendo clic sobre las estrellas
directamente, colorear las estrellas al pasar por encima de ellas para saber
qué valoración se va a dar e informar de la correcta valoración al finalizar.
Diseño de la base de datos
Elección de base de datos
Para almacenar dichos datos inicialmente se investigó que soporte daba Unity3D para
bases de datos y aparentemente permitía usar bases de datos comunes como MySQL
así que el desarrollo de la aplicación comenzó haciendo uso de esta y añadiendo la
capacidad de acceder a otros proveedores de bases de datos mediante una capa de
acceso a datos.
Esto queda definido en la planificación del alcance inicial, pero en el seguimiento y
control se realizan cambios que explicaremos a continuación.
Dichos cambios se producen debido a que a la hora de compilar la aplicación, Unity3D
sufría conflictos y mostraba múltiples errores al intentar conectarse con las distintas
bases de datos mediante el uso de librerías dinámicas (dll’s).
Dado este problema, se investigaron soluciones para el mismo en los foros de Unity3D
pero sin éxito. Así que en vez de continuar dedicando más tiempo a su solución
pudiendo sufrir retrasos en la realización del resto del proyecto se ha acabado utilizado
SQLite como base de datos en local, puesto que el soporte para esta sí está asegurado
y es recomendado para usarlo en el caso de desarrollar apps para dispositivos móviles.
El hecho de usar SQLite también implica ventajas para la aplicación. Algunas de ellas
son el almacenamiento de la base de datos en un único fichero (como si se almacenase
la información en un fichero de texto) y el reducido tamaño de la base de datos en
disco.
Además el acceso a la misma mediante código es semejante a otras bases de datos. El
único inconveniente de su uso es el tamaño de la base de datos, limitado a 2 TB, pero
esto no supone problema puesto que la aplicación no contendrá gran cantidad de
datos.
34
Universidad de La Rioja TFG – VR CLASS
Análisis de requisitos de la base de datos
La aplicación debe encargarse de almacenar el progreso de los usuarios a la hora de
realizar las lecciones y los tests que estas contienen. Por lo tanto, la única información
guardada en la base de datos será:
Para cada tema, un identificador, el nombre, la categoría, la valoración del
usuario y la ruta de la carpeta que lo contiene. Los temas se guardan para saber
cuáles se han visitado recientemente.
Para cada lección que el usuario visualice, se guardará un identificador, el
nombre y la ruta con el fichero que contiene su información. Una vez
visualizada esta se marcará como completada.
En el caso de los tests, se debe conocer un identificador, el número de
preguntas que tienen y la ruta del fichero que lo contiene.
La ruta es necesaria para localizar un test con preguntas no contestadas.
También se guarda información de los usuarios registrados en la aplicación a
forma de cuentas privadas para mantener la sesión en la aplicación. Junto con
estos debe conocerse que tests ha realizado cada usuario y si los ha completado
(contestar a las preguntas al menos una vez aunque se omita alguna).
Por último, es necesario saber que números de preguntas ha omitido un
usuario en un test de forma que pueda volver a contestarlas en otro momento.
Una vez vistos los requisitos esenciales, cabe decir que el resto de datos como las
imágenes o los modelos no tienen la necesidad de ser almacenados en la base de datos
puesto que ocupan gran tamaño y nuestro límite para la base de datos como veremos
a continuación es de 2TB. Además podemos recuperarlos desde el resto de ficheros
guardados en la base de datos.
Diagrama entidad-relación
Tras el análisis de requisitos veamos ahora como se ha organizado la información en la
base de datos con el siguiente esquema entidad-relación (Figura 8):
36
Universidad de La Rioja TFG – VR CLASS
Esquema de tablas
Continuando con el proceso de diseño de la base de datos, el siguiente paso fue
transformar el diagrama entidad-relación a tablas. A continuación puede verse como
ha quedado distribuida la información:
TEMA
Id_Tema Nombre Categoría Carpeta Valoración
Unique
LECCIÓN
Id_Leccion Nombre Fichero Id_Tema
CE: Tema
TEST
Id_Test Fichero NumPreguntas Porc_Completado Id_Leccion
Formula CE: Leccion USUARIO
Id_Usuario Nombre Contraseña E-mail
Unique Unique
PREGUNTA
NumPregunta
USUARIO_LECCION
Id_Usuario Id_Leccion Completada?
CE:Usuario CE:Leccion
USUARIO_TEST
Id_Usuario Id_Test Completado?
CE:Usuario CE:Test
USUARIO_TEST_PREGUNTA
Id_Usuario Id_Test NumPregunta
CE:Usuario CE:Test CE:Pregunta
NOTA: El esquema de tablas ya viene normalizado en forma normal de Boyce-Codd.
Diseño físico
No se ha realizado ningún tipo de diseño físico puesto que la cantidad de información
almacenada en la base de datos no es lo suficientemente grande como para mejorar
las consultas.
Además, como veremos en la fase de implementación, la aplicación para crear la
base de datos nos crea automáticamente los índices necesarios para las tablas
definidas.
37
Universidad de La Rioja TFG – VR CLASS
Organización de contenidos dentro de la aplicación
Para resolverlo se ha optado por seguir el siguiente esquema a la hora de almacenar
los temas y sus contenidos entre los recursos de la aplicación:
Dentro de la carpeta Resources en el proyecto de Unity3D existe una
carpeta llamada Contenidos, la cual será donde la aplicación almacenará en
carpetas los distintos temas descargados.
Para cada tema (carpeta) deberá existir un fichero llamado Manifest.xml el
cual incluirá los siguientes campos:
Nombre del tema
Descripción
Autor
Categoría
Valoración
Fecha de creación
Listado de lecciones que contiene
Dentro de cada lección de la lista se incluirá su nombre, su descripción, los
modos de visualización para los que está disponible y finalmente tres listas
con los nombres de los ficheros que contienen los modelos, las imágenes y
los tests.
A continuación se puede ver un ejemplo de cómo sería un archivo manifest.
De esta forma, cuando la aplicación necesite cargar los modelos y las
imágenes en el modo visor, simplemente buscará los ficheros con el
nombre establecido en el fichero del manifiesto.
Figura 17: Fichero Manifest.xml de ejemplo de un tema.
38
Universidad de La Rioja TFG – VR CLASS
Diseño de las clases
Otro punto importante en este proyecto es la estructura de la lógica que contiene la
aplicación. Como ya se ha visto antes en este documento, la aplicación de escritorio
se divide en tres capas, como en la mayoría de aplicaciones informáticas, que son
interfaz de usuario, lógica de negocio y persistencia. Esta división puede verse más
claramente al observar la estructura de las clases del proyecto.
En la imagen vemos como tenemos 3 carpetas, de forma que las clases que se
encargan de gestionar cada capa quedan agrupadas en la carpeta correspondiente a
dicha capa.
Por ejemplo, las clases que hay en la carpeta persistencia son aquellas que permiten
realizar la conexión con la base de datos SQLite u obtener otros datos desde los
contenidos de la aplicación, mientras que en la carpeta persistencia encontraremos
los scripts que gestionan los menús de la aplicación y los eventos que se producen en
ellos.
Figura 9: Carpetas del proyecto que contienen las clases de la aplicación.
Figura 10: Clases para los menús de la aplicación.
39
Universidad de La Rioja TFG – VR CLASS
IMPLEMENTACIÓN Tecnologías utilizadas
En esta sección veremos que tecnologías se han usado para implementar la
aplicación y en que consiste cada una.
Unity3D, Visual Studio y UnityVS
Unity3D surgió como un motor de videojuegos con el que los desarrolladores pudiesen
crear juegos de calidad para múltiples plataformas de forma fácil y sencilla. Esta
herramienta nos provee de un editor (aplicación de escritorio) desde el que podemos
diseñar los niveles mediante un sistema de componentes con simplemente arrastrar y
soltar. De esta forma podemos importar los modelos creados con programas de
terceros y visualizarlos sin tener que lidiar con el código OpenGL9 necesario para ello.
Usando Unity3D también nos permite programar, con nuestro editor de texto favorito
la lógica de nuestra aplicación y configurar a nuestro gusto el desarrollo de la misma
por ejemplo trabajando en equipo y hasta usando control de versiones.
Por su cuenta Unity3D tiene un IDE adaptado para usar el motor gráfico llamado
MonoDevelop pero su uso es tedioso y la mayoría de programadores hacen uso de
Visual Studio 2015 ahora que Microsoft y Unity3D han establecido un convenio y se
han creado los plugins (UnityVS) necesarios para su uso. Así podemos acceder a todas
las herramientas que ofrece Visual Studio con la misma facilidad con que se adaptaba
MonoDevelop.
Eso sí, el uso de Visual Studio aún puede contener ciertos bugs que tienen que
solucionarse, pero en general la experiencia de uso es mucho mejor que con
MonoDevelop.
Leap Motion
Esta es la primera tecnología emergente de estos últimos años que usa la aplicación.
Leap Motion es un dispositivo hardware compuesto por dos cámaras infrarrojas que
actúan como un sensor de movimiento capaz de detectar las articulaciones de las
manos.
9 Información sobre OpenGL en Wikipedia.
40
Universidad de La Rioja TFG – VR CLASS
Actualmente debe conectarse a un puerto USB pero algunos fabricantes de
ordenadores y portátiles como ASUS pretenden incluirlo junto con el trackpad en sus
equipos en un futuro cercano.
Con este dispositivo podemos controlar la navegación de nuestra aplicación de forma
innovadora mediante gestos que nosotros mismos podemos programar aunque
algunos ya vienen hechos. Así la interacción con los modelos 3D puede ser mucho más
intuitiva si se hace correctamente al igual que usamos gestos en nuestros dispositivos
móviles.
Oculus Rift (Development Kit 2)
El Oculus Rift es un casco de realidad virtual desarrollado por Palmer Luckey (fundador
de Oculus VR), con el objetivo de mejorar los cascos disponibles en el mercado desde
hace años y hacerlo a un precio más económico para los usuarios.
El casco cuenta con una pantalla OLED de 7 pulgadas que muestra las imágenes y
delante de esta se encuentran dos lentes de cristal que crean el efecto 3D tal y como
lo hacen la visión humana (estereoscopia10).
Junto a lo anterior encontramos una serie de giroscopios, acelerómetros y
magnetómetros que permiten realizar el seguimiento de la posición del casco para que
la pantalla pueda actualizar la imagen según los movimientos del casco, creando así
una sensación de inmersión por parte del usuario.
10 Información sobre estereoscopía en Wikipedia.
Figura 12: Oculus Rift DK2 con Leap Motion en acción.
Figura 11: Dispositivo de tracking Leap Motion
41
Universidad de La Rioja TFG – VR CLASS
Si además añadimos que en sus últimas actualizaciones han añadido integración con
Leap Motion para incluir nuestras manos en el mundo virtual que visualizamos, lo que
conseguimos es una experiencia cercana a la que ve una persona a través de sus ojos.
Sin embargo en esta versión de desarrollo (dk2), pueden existir algunos problemas con
la velocidad de refresco de la pantalla, los cuales provocan mareos y pérdida de
orientación al usuario. Esto espera solucionarse en la versión final de Oculus Rift que
saldrá a la venta para todo el mundo en 2016 junto nuevas mejoras como la conexión
Wireless y la integración de auriculares.
Estructura del proyecto
Al contrario que con los proyectos de aplicaciones informáticas comunes, los proyectos
de Unity3D no poseen una estructura clara y definida sino que podemos organizarla a
nuestro gusto con algunas restricciones. En este caso el conjunto de todos los
componentes que forman el proyecto puede verse reflejado en la siguiente imagen.
Veamos cada una de ellas más en detalle para ver cómo se relacionan:
La carpeta principal llamada Assets viene a ser la carpeta raíz del proyecto
donde debemos incluir todo lo que Unity3D vaya a necesitar en la aplicación,
ya sean scripts, modelos 3D, imágenes, etc. Existe siempre que se crea un
proyecto nuevo.
Dentro de esta encontramos algunas carpetas consideradas especiales en
cualquier proyecto con Unity3D. Estas son Editor, Gizmos, Plugins y Resources.
De estas las más importantes son las dos últimas, las cuales tienen las
siguientes funciones:
o Plugins: Esta carpeta debe contener todas las librerías dinámicas (dll’s)
y archivos en general de terceros que añadan nuevos servicios o
funcionalidades que Unity3D por sí mismo no incluye.
o Resources: En esta otra, lo que incluimos son todos los contenidos de
la aplicación que se usan en Unity3D. Es importante saber, que Unity
emplea este nombre para localizar los recursos de cualquier aplicación
que creemos, así que no vale usar el nombre “Recursos” o cualquier
otro nombre que se nos ocurra. En la siguiente imagen podemos ver
todo lo que tiene nuestra aplicación guardada en esa carpeta:
Figura 13: Estructura del proyecto en Unity3D
42
Universidad de La Rioja TFG – VR CLASS
Estos recursos están clasificados a su vez en carpetas, permitiendo así
separar en la lógica de negocio la obtención de cada uno de ellos en
tiempo de ejecución y mejorando así la organización del proyecto.
Las dos primeras sin embargo son carpetas que contienen elementos que
ayudan a extender la funcionalidad del editor de Unity. Entre ellos scripts para
creación de menús personalizados y marcadores de objetos que visualicemos
en las escenas.
Por otra parte la carpeta Scripts es lo suficientemente descriptiva como para
saber que contiene los ficheros con las clases forman la aplicación y que pueden
adjuntarse a objetos del editor para asociar el comportamiento deseado de los
mismos. No es obligatoria.
En cuanto a la carpeta Escenas, esta contiene precisamente eso “Escenas”. Y es
que Unity está pensado para crear videojuegos divididos en niveles o escenas.
Así que aquí encontraremos las escenas que corresponden con cada menú o
ventana de la aplicación. Tampoco es obligatoria.
También tenemos 3 carpetas de terceros, que son OVR, LeapMotion y
LeapMotion+OVR, que son las que contienen clases, prefabricados y objetos
de Unity que se usan para la integración de Leap Motion y Oculus Rift. Por
ejemplo, aquí podemos encontrar los modelos para las manos que se
visualicen en la aplicación entre otros. En este caso es mejor dejarlas como
están debido a la estructura interna que haya podido usar cada empresa.
Por último encontramos la carpeta Config, que contiene archivos de
configuración de la aplicación, como cadenas de conexión a base de datos, el
fichero de base de datos y las opciones configuradas por el usuario al usar la
aplicación. No es obligatoria.
Tras la compilación de nuestro proyecto para las distintas plataformas de escritorio,
Unity3D nos creará un archivo ejecutable con los valores establecidos durante la
configuración del proyecto, como el nombre, el icono y la configuración al ejecutarse.
Junto a este ejecutable siempre aparecerá una carpeta (con distinto nombre según el
sistema operativo) que contendrá el resto de datos y recursos que la aplicación
(incluidos en la carpeta Resources entre otras).
Figura 14: Directorio de recursos que usa la aplicación.
43
Universidad de La Rioja TFG – VR CLASS
Lógica de negocio y persistencia
Creación de la base de datos
El diseño de la base de datos de la aplicación aquí desarrollada ya se ha explicado
previamente, así que ahora veremos cómo hemos implementado dicho diseño y lo
hemos puesto a prueba de forma real.
Lo primero que debe quedar claro es que las bases de datos en SQLite se almacenan
en un único fichero con extensión .db (o .sqlite). Para crear dicho fichero haremos uso
de una herramienta externa llamada DB Browser for SQLite que nos permitirá crear
todas las tablas que se incluyen en el diseño de la base de datos de forma rápida y
sencilla de forma similar a otras herramientas que se han visto en el grado de ingeniería
informática como MySQL Workbench.
En la imagen anterior se muestra la lista de tablas creadas y almacenadas en el fichero
de base de datos con nombre “VRClass.db”. Además a la derecha de cada tabla se nos
muestra la instrucción SQL ejecutada para crear cada tabla, la cual nos servirá más
adelante para crear un script que se ejecute al iniciar la aplicación y poder crear así la
base de datos desde cero en caso de no existir esta previamente.
Tras crear el fichero de base de datos, simplemente lo incluimos en el proyecto de
Unity3D y mediante la capa de acceso a la base de datos podremos recuperar y
modificar los datos almacenados en la aplicación. Veremos a continuación como se ha
desarrollado esta capa de acceso.
Figura 15: Diseño de la base de datos en DB Browser for SQLite
44
Universidad de La Rioja TFG – VR CLASS
Un último comentario sobre el acceso a este fichero de datos es el hecho de incluir las
librerías de SQLite en la carpeta Plugins del proyecto en Unity3D para poder realizar
operaciones sobre esta. Concretamente se han de incluir las dll’s para sistemas de 32
y 64 bits e incluirlas en las carpetas x86 y x64 correspondientemente de lo contrario
Unity3D lanzará una excepción y la aplicación podría dejar de funcionar.
Capa de acceso a base de datos
Uno de los problemas que se tenía al comienzo del desarrollo fue conseguir el acceso
a la base de datos. Tras cambiar de base de datos se solucionó el problema y se
modificó la capa de acceso a datos dejando la siguiente combinación de 4 clases:
IDBManager: Es una interfaz que determina que métodos debe tener toda
clase que se conecte a una base de datos. En nuestro caso implementaremos
los métodos de dicha interfaz para que podamos conectarnos a nuestra base
de datos SQLite.
SQLiteDBManager: Esta clase hereda de la interfaz anterior. Es la encargada de
crear y configurar las conexiones a la base de datos, así como de obtener los
objetos intermedios necesarios para la ejecución de consultas y recuperación
de resultados.
SQLiteDBManagerFactory: Por otra parte, la clase SQLiteDBManager emplea
un patrón de diseño factoría con el que conseguir conexiones, sentencias SQL
y demás objetos necesarios para realizar operaciones sobre la base de datos.
En el caso futuro de que necesitásemos realizar operaciones sobre otro
proveedor de bases de datos, simplemente podríamos añadir la funcionalidad
necesaria a esta clase sin tocar ninguna de las anteriores.
GestorBD: Por último en esta clase se engloban los distintos métodos que la
aplicación utiliza para realizar las operaciones CRUD sobre la base de datos
empleando para ello la clase SQLiteDBManager.
En la siguiente captura puede verse el diagrama de clases que conforman estas clases
y las relaciones que se establecen entre cada una de ellas.
En el caso de la clase GestorBD se han obviado los métodos que realizan operaciones
sobre la base de datos para evitar ocupar más espacio del debido en el diagrama.
45
Universidad de La Rioja TFG – VR CLASS
Deserialización de contenidos
El segundo punto crítico en la aplicación después del acceso a la base de datos la
recuperación de los datos de los temas, lecciones y tests que la aplicación encuentre
en el ordenador. Para recuperar dichos datos siguiendo la estructura organizativa
explicada anteriormente se realizaron las siguientes tareas:
Se han implementado varias clases que incluyen atributos para la
deserialización de ficheros xml. Estas clases son Manifest, Leccion, Test,
Pregunta y Respuesta.
En la siguiente captura se puede ver cómo se definen los atributos en la clase
Manifest:
Figura 16: Diagrama de clases para la persistencia de la aplicación.
46
Universidad de La Rioja TFG – VR CLASS
Finalmente la clase Manifest, incluye un método estático llamado
Deserializar que será el que se utilizará para poder acceder a toda la
información de los ficheros XML. Esto implica que tanto los objetos Lección
y Test deberán ser obtenidos desde la escena de elección de tema y pasarlos
a las siguientes escenas para que estos los muestren.
Protección de tests
Comentarlo en el análisis
Ya vimos en el análisis, que cabía la posibilidad de que algún usuario alguno con la
suficiente experiencia tratase de investigar los contenidos de la aplicación y pudiese
acceder a las respuestas correctas de los tests a través de los ficheros XML.
Bien, pues para solventar este problema se ha modificado en última instancia el
método Deserializar de la clase Manifest para que descomprima los datos que vendrán
cifrados al descargarlos de la plataforma web y estos sólo puedan ser leídos por la
aplicación.
Para ello podría haberse usado las clases que .NET provee para estos casos como bien
se indica aquí y modificar simplemente una línea al método deserializar. Sin embargo
Unity3D al usar la implementación de Mono no incluye estas clases por defecto y por
tanto se ha tenido que hacer uso de las clases de .NET portadas a Mono que un usuario
de Unity3D suministró en la store de Unity.
El paquete con las clases se puede encontrar aquí:
https://www.assetstore.unity3d.com/en/#!/content/31902
Figura 18: Clase Manifest.cs preparada para deserializar el fichero manifest.xml
47
Universidad de La Rioja TFG – VR CLASS
Implementación de Leap Motion
El último punto importante de esta sección, que además ha sido novedoso en el
desarrollo de la aplicación y que por tanto requiere hablar de él es la integración de
Leap Motion en el modo de visualización Visor.
Al principio, en el resumen de este documento, se incluía un vídeo donde se puede ver
como una persona usa Leap Motion para girar el modelo 3D. Este mismo
comportamiento es el deseado en nuestra aplicación.
Para poder conseguir eso debemos hacer uso del API de Leap Motion al que podemos
acceder tras incluir las dll’s en la carpeta Plugins de nuestro proyecto.
Ahora bien, a la hora de programar ese comportamiento, lo difícil no es que detecte el
dispositivo de tracking, que para eso ya se nos proveen métodos y propiedades. El
problema de estos métodos es que según la documentación se recomienda hacer uso
de un Listener personalizado. Un Listener en realidad no es más que una clase que
hereda de la interfaz Listener y cuyos métodos se activan cuando se detectan cambios
en la información obtenida por el dispositivo.
Esta información puede ser desde conectar y desconectar el dispositivo al ordenador
hasta la detección de manos y falanges individuales. Pero este tipo de implementación
tiene un problema y es que usa hilos (threads) pero Unity3D no soporta múltiples hilos
y simula estos mediante corutinas.
Por lo tanto se ha tenido que rediseñar este modelo y finalmente se ha creado una
clase que se adjunta a la cámara de la escena y permite el mismo funcionamiento del
dispositivo que antes pero haciendo uso de un único hilo.
La pega de esta clase es que tiene que buscar continuamente datos disponibles para
leer en el dispositivo. Estos datos vienen almacenados en un objeto llamado Frame
que viene a ser la representación lo que muestra la pantalla en cada instante como en
los videojuegos los frames por segundo.
El proceso se complica más aun teniendo en cuenta que estos Frames se recuperan de
uno en uno y los gestos sólo se detectan al comparar varios Frames. Pero no todo son
problemas. Por suerte, en los Assets de Leap Motion para Unity existen varias clases
que ya implementan la recuperación de los Frames y la detección de objetos con un
único hilo.
En especial me gustaría mencionar la clase LeapRecorder, que es la que hace toda la
magia para obtener los Frames. Esta clase actua como una grabadora serializando
Frames y sus respectivos datos a lo largo del tiempo y recuperando de nuevo dichos
datos cuando se necesitan. Digamos que es como un buffer que contiene los Frames
pero que nos evita detectar gestos pasando uno por uno entre ellos.
48
Universidad de La Rioja TFG – VR CLASS
Interfaz
Sistema de navegación entre escenas
La navegación entre menús es uno de los puntos importantes de la aplicación explicada
en este documento. Esto es debido a que el usuario debe desplazarse por varios menús
antes de poder llegar a interactuar con los modelos de una lección concreta.
La implementación de dicho flujo de navegación a lo largo de la aplicación es digno de
mención puesto que este se aleja de los desarrollos habituales que se dan en
aplicaciones de escritorio basadas en ventanas. Veamos pues como se ha creado dicho
sistema.
El pilar principal de la navegación dentro de la aplicación son las escenas. Cada escena
constituye un menú o ventana de la aplicación. Si contamos el número de menús que
van a mostrarse finalmente tras la revisión del prototipo obtenemos los siguientes:
Ahora bien, por defecto, el cambio o transición entre dichas escenas se realiza al llamar
a una función llamada Application.LoadLevel() pasándole como parámetro el nombre
de la escena deseada.
El problema de esta función es que al ejecutarse, la escena actual en que nos
encontramos y todos los objetos que esta contiene son destruidos para liberar
memoria y en su lugar se crean la escena que se va a cargar y lo que esta contenga.
Esto implica que el estado de la aplicación entre escenas no se mantiene.
Para ello lo que se ha hecho es crear una clase llamada GestorEscenas que sirve de
envoltorio a esta función y que permite controlar el flujo de la navegación entre
escenas sabiendo en que escena estamos y hacia cual vamos.
Figura 19: Escenas usadas en la aplicación.
49
Universidad de La Rioja TFG – VR CLASS
Sin embargo con esto no solucionamos el problema del estado entre escenas. Para
mantener el estado, ya sea por ejemplo guardando la sesión abierta de un usuario o
detectando que tema ha elegido el usuario, simplemente se ha optado por crear un
objeto vacío dentro del editor de Unity3D. Un objeto vacío simplemente es un objeto
de la clase GameObject que no contiene ningún componente y que por tanto no se
muestra en pantalla.
Este objeto vacío al que he llamado ApplicationManager se crea en la primera escena
de la aplicación y tiene asociado un script que contiene un objeto de tipo
GestorEscenas y un diccionario de pares clave, valor que nos sirve para almacenar
objetos compartidos entre escenas como el usuario de la sesión o el tema elegido por
este.
Eso sí, como ya se ha dicho antes, al cargar una nueva escena usando el GestorEscenas
desde el ApplicationManager hace que se destruyan todos los objetos de la escena
previa. Por lo tanto el ApplicationManager desaparecerá al cambiar de escena y ya no
podremos avanzar.
Figura 20: Clase GestorEscenas
Figura 21: Configuración del ApplicationManager
50
Universidad de La Rioja TFG – VR CLASS
Para evitar este último problema, se hace uso de la instrucción DontDestroyOnLoad ()
pasando el objeto vacío como parámetro. De esta forma Unity3D es notificado de que
no debe borrar ese objeto al cargar una nueva escena y así poder localizarlo en esa
nueva escena para poder avanzar a otras escenas.
51
Universidad de La Rioja TFG – VR CLASS
DESPLIEGUE Y PRUEBAS DEL SISTEMA 1. Pruebas de unidad
Prueba 1.1. Consultar el listado de temas de una lección
Descripción: Estando en el menú principal, el usuario pulsa en Comenzar y se cargar el menú del catálogo
Resultado: El sistema recupera temas disponibles dentro de los contenidos de la aplicación.
Estado: CORRECTO
Prueba 1.2. Consultar el listado de tests de una lección
Descripción: Estando en el menú de selección de lección, el usuario pulsa sobre el botón de ver tests y se carga el menú donde deben mostrarse.
Resultado: El sistema recupera los tests disponibles para esa lección y muestra la información de ese test cada ítem de la lista.
Estado: CORRECTO
Prueba 1.3. Iniciar sesión en la aplicación
Descripción: El usuario llega al formulario de inicio de sesión e introduce los datos desu cuenta. A continuación pulsa sobre el botón entrar.
Resultado: La aplicación recoge los datos y comprueba si corresponden a un usuario existente en la base de datos. En caso correcto permite al usuario continuar en cargando el menú principal y cargando su usuario en la sesión de la aplicación.
Estado: CORRECTO
Prueba 1.4. Guardar un test completado
Descripción: El usuario está respondiento preguntas en el menú de test. El usuario pulsa el botón Siguiente al terminar la última pregunta del test.
Resultado: El sistema muestra los resultados del test y guarda la información de este en la base de datos.
Estado: CORRECTO
52
Universidad de La Rioja TFG – VR CLASS
Prueba 1.5. Guardar una lección completada
Descripción: El usuario está en el modo Visor y sale de este para volver al menú Lección.
Resultado: El sistema guarda la lección visualizada en la base de datos.
Estado: CORRECTO
Prueba 1.6. Valorar un tema
Descripción: El usuario está en el menú de un tema. Este pulsa sobre las estrellas y elige la valoración que quiere. Acepta finalmente la valoración.
Resultado: El sistema guarda la valoración del tema en la base de datos.
Estado: CORRECTO
2. De integración
Prueba 2.1. Comprobar que el fichero de base de datos existe.
Descripción: Durante el inicio de la aplicación el usuario debe esperar en la pantalla de carga para comprobar si existe un fichero de base de datos correcto para su uso con la aplicación.
Resultado: El sistema comprueba que el fichero existe y permite continuar al formulario de inicio de sesión.
Estado: CORRECTO
Prueba 2.2. Comprobar que el dispositivo Leap Motion está
conectado.
Descripción: El usuario inicia una lección en modo Visor.
Resultado: El sistema comprueba que un dispositivo Leap Motion está conectado al ordenador y muestra un mensaje indicándolo.
Estado: CORRECTO
53
Universidad de La Rioja TFG – VR CLASS
Prueba 2.3. Adaptabilidad de la aplicación
Descripción: Se ha probado a ejecutar la aplicación en distintos monitores de ordenador para ver si la interfaz se adapta a múltiples resoluciones.
Resultado: El sistema muestra de forma incorrecta la interfaz en monitores distintos al usado para el desarrollo de la aplicación.
Estado: INCORRECTO. Deben configurarse las anclas de los elementos de la interfaz.
3. De aceptación
Durante el desarrollo del proyecto se han ido eliminado algunas funcionalidades de la
aplicación por falta de tiempo. Sin embargo, serán implementadas como mejoras en
las siguientes versiones así que una versión reducida como la que se ha llegado a
completar también es correcta.
54
Universidad de La Rioja TFG – VR CLASS
SEGUIMIENTO Y CONTROL Gestión de cambios
Debido a imprevistos no incluidos en la planificación del proyecto, me he sentido
obligado a modificar tanto la estructura del proyecto como el seguimiento y control
del mismo.
El principal problema ha sido tener que trabajar desde después de semana santa hasta
día de hoy de entrega de este documento en un empleo temporal de 8 horas diarias
con apenas 2 o 3 días libres a la semana. Añadido a esto se encuentra la obligación de
ayudar en casa con una reforma que comenzó en el mes de junio y que me quitó aún
más tiempo para realizar el proyecto.
Sin embargo he sido capaz de terminar un alcance del proyecto más pequeño que el
original antes de la entrega de este proyecto durante la segunda convocatoria (Junio).
Por lo tanto, incluiré a continuación las modificaciones realizadas a la planificación
inicial del proyecto:
Estructura de descomposición de tareas
Provocado principalmente por un problema surgido con la implementación de la
conexión a la base de datos desde la aplicación usando MySQL, se decidió buscar otra
base de datos que sirviese. Como ya se ha podido ver antes en este documento, la
elegida fue SQLite la cual no presentó problema alguno.
Este cambio me obligó a modificar las partes de la EDT conocidas como ConectorBD y
GestorBD que ahora he modificado y agrupado en una sola, llamada Implementación
DAL. Este tiempo es un añadido puesto que las clases anteriores ya estaban creadas.
Por lo tanto las pruebas de acceso a la base de datos también se atrasaron.
En el segundo plazo más importante, centrado en el desarrollo del cliente con Unity3D,
los paquetes de trabajo de la EDT afectados fueron la Interfaz y los Contenidos.
La interfaz tras su actualización a partir de la versión 4.6 de Unity3D fue mejorada y
tuve que dedicarle un tiempo extra al aprendizaje e implementación de la misma según
el prototipo creado. Además debido al trabajo no pudo realizarse la segunda
evaluación de la interfaz que abarcaba el uso de Leap Motion.
En cambio los Contenidos, los he reducido para que pueda darme tiempo a terminar
la parte de la aplicación que no requiere tanto esfuerzo y conforma la mayor parte de
esta. Por ejemplo, he reducido el número de lecciones incluidas en la aplicación y
centré todos los esfuerzos a organizar los temas y recuperar sus datos.
Las pruebas de este segundo periodo también se han visto retrasadas de la misma
manera.
55
Universidad de La Rioja TFG – VR CLASS
Se ha añadido también la integración con Leap Motion, ya que la de Oculus no daba
tiempo como nuevo paquete de trabajo, ya que no dispuse del dispositivo hasta hace
unas semanas.
En cuanto a la planificación, seguimiento y memoria, el tiempo que le he intentado
dedicar ha sido más o menos el mismo que debía dedicarle desde que comencé a
trabajar, que son mes y medio o dos meses. Por lo tanto las horas no se han visto
alteradas, tan sólo el periodo de tiempo en el que se distribuían.
Por último, tanto el material de la presentación y la propia presentación serán
aplazados tras la entrega del proyecto por si hubiese quedado alguna cosa que retocar
de la memoria y así finalizar correctamente la entrega del proyecto.
A continuación incluyo la tabla de plazos y horas estimadas y reales dedicadas a cada
tarea de la antigua estructura de descomposición del trabajo.
Seguimiento
Tarea Plazo planificado Plazo real Horas
estimadas Horas reales
Configuración del entorno
09/03/15 – 11/03/15 09/03/15 – 11/05/15 6 6
Diseño de la base de datos
02/03/15 – 06/03/15 02/03/15 – 06/03/15 10 10
Conector BD 12/03/15 – 13/03/15 12/03/15 – 16/05/15 4 15
Pruebas 16/03/15 – 18/02/15 13/07/15 – 23/05/15 4 4
Gestor BD 19/03/15 – 20/03/15 19/03/15 – 17/05/15 4 10
Lógica de Negocio
23/03/15 – 17/04/15 23/03/15 – 20/07/15 20 20
Interfaz 23/03/15 – 24/04/15 23/03/15 – 20/07/15 40 70
Contenidos 27/04/15 – 22/05/15 08/06/15 – 22/06/15 40 10
Leap Motion 06/07/15 – 10/07/15 10 10
Pruebas 25/05/15 – 05/06/15 25/05/15 – 24/06/15 20 20
Planificación 16/02/15 – 27/02/15 16/02/15 – 29/07/15 20 20
Seguimiento 02/03/15 – 19/06/15 24/06/15 – 29/07/15 40 40
Memoria 02/02/15 – 19/06/15 02/02/15 – 29/07/15 72 72
Material presentación
08/06/15 – 19/06/15 03/08/15 – 06/08/15 15 15
Presentación 15/06/15 – 19/06/15 30/07/15 – 02/08/15 5 5
TOTAL 02/03/15 29/07/15 300 327
Se puede apreciar como el tiempo estipulado para la realización del
proyecto se ha visto superado en casi 30 horas. Aunque teniendo en cuenta
que la aplicación tiene margen de mejora, serán más que suficientes para
mostrar la funcionalidad básica de la aplicación.
Finalmente incluyo el diagrama de descomposición del trabajo final que se ha seguido.
57
Universidad de La Rioja TFG – VR CLASS
LECCIONES APRENDIDAS El resultado final de este proyecto queda resumido en una primera implementación
del cliente para la plataforma VR Class. Este cliente no es más que un pequeño ejemplo
y primer paso para el desarrollo de aplicaciones de realidad virtual que permitirán
llevar el paradigma educativo a otro nivel, más ameno e interactivo y con el que los
alumnos puedan aprender divirtiéndose.
Esta primera implementación está sujeta a la aplicación de las mejoras que se verán
tras este aparatado en este documento y por tanto el resultado final expuesto en este
documento puede verse afectado en la presentación del mismo ante el tribunal de
evaluación.
Por otra parte, el autor de este documento establece a continuación una serie de
consideraciones sobre los conceptos vistos y asimilados durante la realización del
proyecto que considera positivos para su evolución como ingeniero informático:
Se ha expuesto una de las aplicaciones que la realidad virtual puede tener en
el ámbito educativo y en este caso del campo de la medicina de forma
conjunta, dando la posibilidad a nuevas aplicaciones que mejoren los métodos
de enseñanza mediante el uso de la tecnología.
Se ha aprendido sobre la integración y programación de nuevas tecnologías de
realidad virtual y tracking de movimiento en aplicaciones de escritorio,
permitiendo así mostrar distintas formas de interacción con los ordenadores
apartándonos de la comunicación habitual mediante teclado y ratón.
Es muy importante saber que realizar un proyecto de 300 horas durante el
empleo en un trabajo fijo o temporal estándar producirá casi seguro
desviaciones en la planificación de tiempos del proyecto.
Tomar notas de las dificultades que plantea programar un dispositivo
tecnológico todavía en desarrollo, pudiendo faltar documentación, existir bugs
en la implementación o incluso no disponer de ellos durante el tiempo
necesario para indagar en profundidad. También cuenta el elevado coste inicial
de estos dispositivos que impide que llegue a más desarrolladores.
El diseño de una interfaz de usuario no es trivial y lleva su tiempo. Además
requiere de la opinión de múltiples personas para poder llegar a desarrollar
una buena interfaz que sea usable.
58
Universidad de La Rioja TFG – VR CLASS
Cabe destacar las ventajas y desventajas de usar un motor de videojuegos
multiplataforma para programar aplicaciones con contenido gráfico:
a. Facilidad para representar contenidos gráficos con apenas unas pocas
líneas de código.
b. Posibilidad de desarrollar aplicaciones multiplataforma desde un único
equipo.
c. Dificultad para implementar las guías de estilo de interfaces comunes a
aplicaciones de escritorio, pero facilidad para generar la interfaz de
acuerdo a un prototipo definido por el usuario (mayor libertad).
d. Posibles problemas de integración entre componentes del motor y
librerías externas o plugins. Es recomendable consultar su
compatibilidad antes de usarlas.
e. Tener en cuenta que un motor de videojuegos está continuamente en
desarrollo y tanto la documentación como la API y los flujos de trabajo
con la misma pueden cambiar provocando que tengamos que cambiar
gran parte de nuestro código. A esto hay que añadir el proceso de
aprendizaje de la nueva forma de trabajo.
59
Universidad de La Rioja TFG – VR CLASS
MEJORAS Como ya se ha expuesto anteriormente en la definición del alcance de este proyecto,
esta aplicación constituye la primera fase de un proyecto mayor en el que se incluye la
creación de una plataforma web desde la que proveer con más contenidos a nuestra
aplicación.
Por lo tanto, es razonable pensar, que la propia aplicación tenga margen para la mejora
de sus funcionalidades con el objetivo de comunicarse con la plataforma web. Sin
embargo, la propia aplicación puede mejorarse en muchos otros sentidos.
A continuación se muestra el roadmap con las mejoras planificadas para la aplicación
en un futuro cercano:
Añadir animaciones y sonidos a los componentes de la interfaz de usuario para
dar más dinamismo e interactividad a la aplicación.
Permitir elegir entre varias dificultades para los tests.
Añadir filtros de búsqueda para los temas según su categoría, valoración u otros
parámetros.
Añadir shaders y otras herramientas que permitan visualizar mejor los detalles
de los modelos 3D.
Soporte para más idiomas implementando un sistema de internacionalización.
Compilación de la aplicación para sistemas Linux y Mac.
Creación de un plugin que permita hacer uso de la librería VTK para renderizar
los modelos 3D y así evitar el uso de ficheros con formatos asociados a
programas de modelado. Con esta mejora, el tamaño de los contenidos se vería
notablemente reducido, pero posiblemente perderíamos alguna funcionalidad
aplicable a la interacción con los propios modelos, aunque también eliminamos
la necesidad de programas externos de generación de modelos para las
imágenes DICOM.
Implementación de un sistema de guiones (con ficheros XML), en forma de
secuencia, que organicen los contenidos de una lección y su orden de
visualización. Esto simplificaría la creación de contenidos en la plataforma web.
60
Universidad de La Rioja TFG – VR CLASS
ANEXOS Anexo I – Prototipo de la interfaz de usuario.
Figura: Splash screen
Figura: Menú principal
61
Universidad de La Rioja TFG – VR CLASS
Figura: Menú principal (II)
Figura: Menú catálogo de temas
63
Universidad de La Rioja TFG – VR CLASS
Figura: Menú selección de lección
Figura: Menú selección de modo de visualización
64
Universidad de La Rioja TFG – VR CLASS
Las capturas aquí expuestas representan varios contextos del prototipo mostrados
durante el proceso de evaluación de la usabilidad de la aplicación.
Figura: Modo visor
Figura: Salir del modo Visor.
68
Universidad de La Rioja TFG – VR CLASS
BIBLIOGRAFÍA Documentación de Unity3D
- Docs: http://unity3d.com/es/learn/documentation
- Fórum: forum.unity3d.com
- Preguntas de usuarios: http://answers.unity3d.com/
- Sesiones en directo: http://unity3d.com/learn/live-training
- Tutoriales: http://unity3d.com/learn/tutorials/modules
Documentación de Oculus Rift
- Docs: https://developer.oculus.com/documentation/
- Foro dedicado en Unity3D: http://forum.unity3d.com/forums/virtual-
reality.80/
- Wikipedia: http://www.wikiwand.com/es/Oculus_Rift
Documentación de Leap Motion
- Docs para C#:
https://developer.leapmotion.com/documentation/csharp/index.html
- Assets Unity3D (Integración):
- https://developer.leapmotion.com/gallery/category/unity3d
Serialización y Deserialización en XML
- http://www.codeproject.com/Articles/483055/XML-Serialization-and-
Deserialization-Part
- http://www.codeproject.com/Articles/487571/XML-Serialization-and-
Deserialization-Part-2
Configuración de SQLite y Unity3D
- http://answers.unity3d.com/questions/743400/database-sqlite-setup-for-
unity.html
- http://forum.unity3d.com/threads/using-plugins-for-x86-and-x86_64-
architectures-issue-with-sqlite3-dll-in-beta-9-solved.276719/
69
Universidad de La Rioja TFG – VR CLASS
AGRADECIMIENTOS
Al equipo de CreativiTIC, Jorge R. López, Enara Artetxe, Álvaro Pérez y Aratz Setién que me han ayudado a resolver todas mis dudas siempre que podían, haciéndome avanzar según se presentaban los problemas y que me han apoyado a lo largo de
todo el proyecto.
En especial a Enara por aguantarme hasta cuando no tenía ni tiempo para ello, o no sabía cómo ayudarme y a la cual le doy más importancia porque sin ella no podría
haber avanzado a través del desarrollo de este proyecto.
A Arturo Jaime Elizondo por dirigir este trabajo y aconsejarme con todas las dudas que me han surgido en cuanto a la realización del proyecto a pesar de los pocos
momentos para comunicarnos.
A mis compañeros de clase y grado que han estado ahí para hacerme más ameno
este viaje de desarrollo intelectual y profesional a lo largo de todos los cursos y que
también me han ayudado con lo que han podido.
Finalmente a mi familia, por haber conseguido con paciencia y esfuerzo que llegase
hasta donde estoy ahora poniendo lo mejor de su parte.