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.



http://www.theverge.com/a/virtual-reality/intro

4


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:



2 Rise , fall and rise of virtual reality, article on The Verge.



http://www.theverge.com/a/virtual-reality/intro

5


Í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


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.

7


DESARROLLO DEL PROYECTO

8


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


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


Estructura de Descomposición del Trabajo

Figura 1: Estructura de descomposición del trabajo

11


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.

https://www.mysql.com/products/workbench/

https://www.visualstudio.com/

12


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


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


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.

15


Diagrama de hitos

Figura 2: Tabla de hitos

16


Cronograma

17


Figura 3: Diagrama de Gantt

18


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.

http://www.dicomlibrary.com/

http://www.osirix-viewer.com/datasets/

http://www.agpd.es/portalwebAGPD/canaldocumentacion/informes_juridicos/reglamento_lopd/index-ides-idphp.php

http://www.vtk.org/

https://github.com/ufz-vislab/VtkUnity

19


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


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


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


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.

23


Figura 4: Diagrama de casos de uso

24


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


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


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)

http://www.wikiwand.com/es/Gr%C3%A1fico_vectorial

27


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


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


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:

30


31


Figura 7: Formulario de evaluación del prototipo

32


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


- 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


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):

35


Figura 8: Diagrama entidad-relación de la base de datos

36


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


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


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


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.

http://www.wikiwand.com/es/OpenGL

40


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

http://www.wikiwand.com/es/Estereoscop%C3%ADa

41


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


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


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


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


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


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

http://stackoverflow.com/questions/18212311/c-sharp-xml-compression

https://www.assetstore.unity3d.com/en/#!/content/31902

47


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


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


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


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


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


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


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


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


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.

56


Estructura de descomposición del trabajo (final)

57


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


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


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


ANEXOS Anexo I – Prototipo de la interfaz de usuario.

Figura: Splash screen

Figura: Menú principal

61


Figura: Menú principal (II)

Figura: Menú catálogo de temas

62


Figura: Menú tema elegido

Figura: Valorar tema elegido

63


Figura: Menú selección de lección

Figura: Menú selección de modo de visualización

64


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.

65


Anexo II – Diseño final de la aplicación

66


67


68


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/

http://unity3d.com/es/learn/documentation

http://answers.unity3d.com/

http://unity3d.com/learn/live-training

http://unity3d.com/learn/tutorials/modules

https://developer.oculus.com/documentation/

http://forum.unity3d.com/forums/virtual-reality.80/

http://forum.unity3d.com/forums/virtual-reality.80/

https://developer.leapmotion.com/documentation/csharp/index.html

https://developer.leapmotion.com/gallery/category/unity3d

http://www.codeproject.com/Articles/483055/XML-Serialization-and-Deserialization-Part

http://www.codeproject.com/Articles/483055/XML-Serialization-and-Deserialization-Part

http://www.codeproject.com/Articles/487571/XML-Serialization-and-Deserialization-Part-2

http://www.codeproject.com/Articles/487571/XML-Serialization-and-Deserialization-Part-2

http://answers.unity3d.com/questions/743400/database-sqlite-setup-for-unity.html

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/

http://forum.unity3d.com/threads/using-plugins-for-x86-and-x86_64-architectures-issue-with-sqlite3-dll-in-beta-9-solved.276719/

69


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.

vr class. procesamiento y manipulación de imágenes … · entorno de desarrollo unity3d que...

Documents