Diseño de una aplicación Learning Management System (LMS) para dispositivos móviles

Diseño de una aplicación Learning Management System (LMS) para dispositivos móviles TRABAJO FIN DE GRADO EN INFORMÁTICA/SOFTWARE Daniel Serrano Torres David García Álvarez Juan Luís Pérez Valbuena Departamento de Ingeniería de Arquitectura de Computadores y Automática Facultad de Informática Universidad Complutense de Madrid Junio 2015 Diseño de una aplicación Learning Management System (LMS) para dispositivos móviles Memoria que presenta para optar al título de Graduado en Ingeniería en Informática/Software Daniel Serrano Torres David García Álvarez Juan Luís Pérez Valbuena Dirigida por el Doctor José Miguel Montañana Aliaga Departamento de Ingeniería de Arquitectura de Computadores y Automática Facultad de Informática Universidad Complutense de Madrid Junio 2015 v Sólo podemos ver poco del futuro, pero lo suficiente para darnos cuenta de que hay mucho que hacer. Alan Turing (1912-1954) Autorización de difusión y utilización Se autoriza a la Universidad Complutense a difundir y utilizar con fines académicos, no comerciales y mencionando expresamente a sus autores, tanto la propia memoria, como el código, la documentación y/o el prototipo desarrollado. Madrid, 18 de Junio de 2015 Fdo. Daniel Serrano Torres Fdo. David García Álvarez Fdo. Juan Luís Pérez Valbuena vii Agradecimientos Queremos expresar nuestro más sincero agradecimiento a nuestros padres (Miguel Ángel y Ana María, José Ramón y Lucita, José Luís y Antonia) por habernos proporcionado el apoyo necesario para poder llegar donde nos encontramos ahora. También queremos agraceder a todas las personas que han colaborado directa o indirectamente con este proyecto. A todos de corazón. .. ¡gracias! ix xvi Índice 5.1.1. Cliente-servidor . . . . . . . . . . . . . . . . . . . . . . 41 5.1.2. Arquitectura en tres capas . . . . . . . . . . . . . . . . 42 5.1.3. Arquitectura orientada a servicios . . . . . . . . . . . . 43 5.1.4. Elección de arquitectura . . . . . . . . . . . . . . . . . 43 5.2. Application Programming Interface (API) . . . . . . . . . . . 43 5.3. Sistemas de comunicación . . . . . . . . . . . . . . . . . . . . 44 5.3.1. XML............................ 44 5.3.2. JSON ........................... 44 5.4. Estructura, diseño e implementación . . . . . . . . . . . . . . 45 5.4.1. Servidor.......................... 45 5.4.2. Aplicaciones móviles . . . . . . . . . . . . . . . . . . . 48 6. Trabajo Realizado 49 6.1. Servidor.............................. 49 6.1.1. Fundamentos básicos del API desarrollado . . . . . . . 49 6.1.2. Sistema de Chat . . . . . . . . . . . . . . . . . . . . . 51 6.1.3. Despliegue......................... 51 6.2. Aplicaciones móviles . . . . . . . . . . . . . . . . . . . . . . . 52 6.2.1. Primera ejecución . . . . . . . . . . . . . . . . . . . . . 53 6.2.2. UC1: Registrar Usuario . . . . . . . . . . . . . . . . . 53 6.2.3. UC2: Autenticación de usuario . . . . . . . . . . . . . 55 6.2.4. UC3: Obtener mensajes tablón . . . . . . . . . . . . . 55 6.2.5. UC4: Enviar mensaje tablón . . . . . . . . . . . . . . . 56 6.2.6. UC5: Marcar mensaje favorito . . . . . . . . . . . . . . 56 6.2.7. UC6: Borrar mensaje . . . . . . . . . . . . . . . . . . . 57 6.2.8. UC7: Agregar/Borrar asignatura a favoritos . . . . . . 58 6.2.9. UC8: Realizar examen . . . . . . . . . . . . . . . . . . 58 6.2.10. UC9: Visualizar estadísticas . . . . . . . . . . . . . . . 62 6.2.11. UC10: Subir un examen/apuntes . . . . . . . . . . . . 63 6.2.12. UC11: Consultar examen/apuntes . . . . . . . . . . . 63 6.2.13. UC12: Modificar perfil usuario . . . . . . . . . . . . . 64 6.2.14. UC13: Crear sala de chat . . . . . . . . . . . . . . . . 65 6.2.15. UC14: Enviar mensajes chat . . . . . . . . . . . . . . . 66 6.2.16. UC15: Recibir mensaje chat . . . . . . . . . . . . . . . 66 6.3. Contribución al proyecto . . . . . . . . . . . . . . . . . . . . . 67 6.3.1. Daniel Serrano Torres . . . . . . . . . . . . . . . . . . 68 6.3.2. David García Álvarez . . . . . . . . . . . . . . . . . . 69 6.3.3. Juan Luís Pérez Valbuena . . . . . . . . . . . . . . . . 70 7. Discusión y conclusión 71 7.1. Discusión sobre objetivos . . . . . . . . . . . . . . . . . . . . 71 Índice xvii 7.1.1. Objetivos principales . . . . . . . . . . . . . . . . . . . 71 7.1.2. Objetivos extraordinarios . . . . . . . . . . . . . . . . 72 7.2. E-Learning, futuro . . . . . . . . . . . . . . . . . . . . . . . . 73 7.3. Trabajofuturo .......................... 73 7.4. Conclusión............................. 74 8. Discussion and conclusion 75 8.1. Discussion on objectives . . . . . . . . . . . . . . . . . . . . . 75 8.1.1. Main objectives . . . . . . . . . . . . . . . . . . . . . . 75 8.1.2. Extraordinary objectives . . . . . . . . . . . . . . . . . 75 8.2. E-Learning, future . . . . . . . . . . . . . . . . . . . . . . . . 76 8.3. Futurework............................ 77 8.4. Conclusion............................. 78 Glosario 79 Acrónimos 81 A. ORM API en Django 83 A.1. Modelos para el ejemplo . . . . . . . . . . . . . . . . . . . . . 83 A.2. Creando un nuevo registro en la base de datos . . . . . . . . . 84 A.3. Consultando todos los registros de la entidad Entry . . . . . . 84 A.4. Relaciones entre tablas a través de los modelos . . . . . . . . 84 B. Enlaces de interés 85 Índice de figuras 1.1. Datos sobre cantidad de dispositivos extraídos de la fuente: [1]. 2 1.2. Datos de cuota de mercado extraídos de la fuente: [2]. . . . . 2 3.1. Tablón en AndroidTM, iOSTM y Windows Phone R ...... 12 3.2. Casos de Uso de Tablón . . . . . . . . . . . . . . . . . . . . . 13 3.3. Casos de Uso de Salas de chat . . . . . . . . . . . . . . . . . . 14 3.4. Chat en AndroidTM, iOSTM y Windows Phone R ....... 14 3.5. Casos de Uso de Archivos . . . . . . . . . . . . . . . . . . . . 15 3.6. Archivos en AndroidTM, iOSTM y Windows Phone R ..... 16 3.7. Exámenes en AndroidTM, iOSTM y Windows Phone R . . . . 16 3.8. Casos de Uso de Exámenes . . . . . . . . . . . . . . . . . . . 17 3.9. Panelweb............................. 18 4.1. Centralizado............................ 21 4.2. TravisCI.............................. 23 4.3. EclipseTM con el complemento de PyDevTM .......... 24 4.4. Android: Servicio de Chat . . . . . . . . . . . . . . . . . . . . 26 4.5. Xcode R iOSTM IDE....................... 27 4.6. Diagrama MVC en iOSTM .................... 27 4.7. StoryBoard en iOSTM ...................... 28 4.8. Autolayout ............................ 29 4.9. Userdefaults ........................... 30 4.10.CoreData............................. 30 4.11.Patróndelegado.......................... 31 4.12.VisualStudio ........................... 32 4.13.NokiaLumia520......................... 32 4.14.CapasdelMVVM ........................ 34 4.15. Ejemplo de IValueConverter . . . . . . . . . . . . . . . . . . . 35 4.16. Descripción gráfica del IsolatedStorage . . . . . . . . . . . . . 36 4.17. Ejemplo de AplicationSettings . . . . . . . . . . . . . . . . . . 37 xix xx Índice de figuras 4.18. Explicación de la caché de imágenes y su interacción con el servidor .............................. 38 4.19. Características almacenamiento interno WP . . . . . . . . . . 39 5.1. Cliente-servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.2. Arquitectura en tres capas . . . . . . . . . . . . . . . . . . . . 42 5.3. Iniciodesesión .......................... 46 5.4. Iniciodesesión .......................... 47 6.1. Estructura sistema . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2. ConexiónalChat......................... 52 6.3. Mensajes enviados por el servidor . . . . . . . . . . . . . . . . 52 6.4. Mensajes enviados por los dispositivos . . . . . . . . . . . . . 53 6.5. Pantalla de inicio AndroidTM, iOSTM y Windows Phone R . . 54 6.6. Proceso de registro en AndroidTM, iOSTM y Windows Phone R 54 6.7. Tablón en AndroidTM, iOSTM y Windows Phone R ...... 56 6.8. Escribir mensaje en AndroidTM, iOSTM y Windows Phone R 57 6.9. Borrar mensaje en AndroidTM, iOSTM y Windows Phone R . 58 6.10. Agregar asignatura a favoritos en AndroidTM, iOSTM y Windows Phone R ........................... 59 6.11. Seleccion de un tema para realizar un exámen en AndroidTM, iOSTM y Windows Phone R ................... 59 6.12. Examen tipo text única respuesta AndroidTM, iOSTM y Windows Phone R ........................... 60 6.13. Examen tipo text multi-respuesta AndroidTM, iOSTM y Windows Phone R ........................... 61 6.14. Examen tipo respuestas cortas AndroidTM, iOSTM y Windows Phone R .............................. 62 6.15. Examen tipo parejas AndroidTM, iOSTM y Windows Phone R 62 6.16. Gráficas en AndroidTM, iOSTM y Windows Phone R ..... 63 6.17. Subir exámen AndroidTM, iOSTM y Windows Phone R . . . . 64 6.18. Subir exámen AndroidTM, iOSTM y Windows Phone R . . . . 65 6.19. Cambiar perfil AndroidTM , iOSTM y Windows Phone R . . . 65 6.20. Chat en AndroidTM, iOSTM y Windows Phone R ....... 66 6.21. Chat en AndroidTM, iOSTM y Windows Phone R ....... 67 Capítulo 1 Introducción La educación es uno de los pilares más importantes de la sociedad actual, puesto que cuantos más conocimientos y experiencia tiene una persona, más facilidad tendrá para encontrar un trabajo. Hoy en día estamos viviendo en la era digital, la tecnología ha hecho que muchas tareas de la vida cotidiana cambien y la educación está entre ellas. Una de las tecnologías que más está destacando en este momento es la tecnología de los dispositivos móviles, en la cual podemos incluir desde smartphones, tablets, phablets hasta los nuevos smartwatch. Podemos decir que el auge de esta tecnología empezó en 2007 con la salida del primer iPhoneTM [3] con iOSTM, desarrollado por Apple R . Un año más tarde, con la aparición de AndroidTM en el mercado [4] como sistema operativo open source para dispositivos móviles, otras compañías como SamsungTM se animaron a diseñar grandes terminales para aquellos tiempos, como por ejemplo el SamsungTM Galaxy S1. Viendo que el mercado de la tecnología móvil evolucionaba favorablemente, MicrosoftTM también se incorporó anunciando su sistema operativo Windows Phone R para sus dispositivos. En este momento se estima que 1.75 miles de millones de personas alrededor del mundo están usando al menos un dispositivo móvil [1] y la tendencia es que este valor crezca con el paso del tiempo, como podemos ver en la gráfica a continuación (figura 1.1): La figura 1.2 muestra el porcentaje abarcado por cada sistema móvil del año 2014, se puede observar que el 99% [2] de la cuota de mercado está comprendido por los sistemas AndroidTM, iOSTM, Windows Phone R . El término Electronic Learning (E-Learning) aparece en 1999 [5], siendo utilizado este término por primera vez en los seminarios de sistemas CBT (Cognitive Behavioral Therapy). El primer sistema de E-Learning fue introducido en los años setenta, 1 2Capítulo 1. Introducción Figura 1.1: Datos sobre cantidad de dispositivos extraídos de la fuente: [1]. Figura 1.2: Datos de cuota de mercado extraídos de la fuente: [2]. construido para distribuir información entre los estudiantes. A partir de entonces los sistemas E-Learning comienzan a ser más interactivos. Con la expansión de la computación e Internet las herramientas de ELearning se expandieron, junto con la llegada de computadores para uso doméstico (el primer MAC R ) se facilitó el aprendizaje de temas particulares y desarrollo de habilidades por parte de los usuarios. Durante los siguientes diez años estos sistemas de enseñanza prosperaron notablemente. Llegando al entorno laboral sistemas de aprendizaje a distancia a partir del año 2000. Dejando a un lado la historia del E-Learning se van a exponer algunas de las ventajas más notables que este sistema de aprendizaje aporta. No existen restricciones de espacio ni de tiempo para aprender. Un curso diseñado para ser interactivo hace el aprendizaje más atractivo y distendido. Disminuye costes para ambas partes implicadas en el curso. Como ya desde el pasado ha venido ocurriendo una convergencia educa- 3 ción y tecnología, lo que ha llevado a la aparición del término E-Learning, el cual trata sobre cómo integrar la tecnología en general con la educación de los estudiantes de la forma más efectiva posible. Algunos autores se han atrevido incluso a crear subcategorías de E-Learning según la tecnología que se use para enseñar a dichos estudiantes, algunos de los ejemplos son: M-Learning: estilo de enseñanza en la cual el medio son los dispositivos móviles. U-Learning: tiene cierta similitud con el M-Learning, con la diferencia de que es más amplio, no solo se basa en dispositivos móviles, y busca una experiencia más distribuida en el tiempo y el espacio [6, 7]. T-Learning: enseñanza vía TV gracias a la multiplexación de canales que nos ofrece la TDT [8]. Existen ya muchas tecnologías E-Learning en uso y de forma muy extendida como pueden ser las plataformas MoodleTM y Sakai R definidas como Learning Manager System (LMS), existen más que las mencionadas pero no se van a tratar. Moodle es una plataforma de código abierto para gestionar los cursos de alumnos matriculados en una institución de enseñanza, permite administrar las asiganturas de forma independiente, gestionar material de aprendizaje, comunicación entre estudiantes y profesores, etc. El carácter de proyecto libre otorga el beneficio de las aportaciones de la comunidad, esto hace que MoodleTM pueda mejorar como plataforma gracias a los complementos y cambios informporados por la comunidad de desarrolladores. Si bien es una plataforma completa de gestión para la enseñanza carece del carácter ubicuo que puede otorgar una aplicación para sistemas móviles, ya que Moodle depende de utilizar un navegador de internet y no siendo adaptable de manera adecuada a pantallas de dispositivos móviles. Por otro lado está Sakai R , es una plataforma similar a MoodleTM que aporta alguna característica nueva como puede ser el directorio de compartición de recursos y la capacidad de compartir mayor variedad de recursos (audio, portfolios, etc). Pero al igual que Moodle carece de la adaptación correcta a los dispositivos móviles que facilite su uso desde cualquier lugar. Por las carencias descritas en las plataformas LMS MoodleTM y Sakai R  se ha decidido desarrollar el proyecto cuya propuesta se expone más a delante. Se ha explicado cuando surge el E-Learning, que es e incluso plataformas LMS que muestran el potencial de este en la educación. El E-Learning 4Capítulo 1. Introducción realiza una gran aportación a la educación eliminando la barrera temporal. Con este estilo de herramientas los estudiantes pueden aprender en el momento que deseen, puesto que no necesitan un profesor presencial, el propio dispositivo electrónico les brinda lo que necesitan. Si a esto le añadimos que las tecnologías móviles, a diferencia de los PC y las TV, son más manejables eliminando así la barrera espacial. Con estas dos barreras eliminadas los alumnos podrán estudiar cuándo y dónde quieran. Desde un punto de vista social se debe prestar atención al fenómeno de crecimiento masivo, que el uso de las tecnologías móviles ha provocado en las Redes Sociales, de esta forma han llegado a su máximo esplendor. No es posible saber cuál y cuándo apareció la primera Red Social en Internet, pero lo que sí podemos mencionar es que una de las redes sociales pioneras y más grandes en la actualidad a nivel mundial es FacebookTM. FacebookTM fue fundada en el 2004 [9] y ahora mismo es la red social con más usuarios registrados en el mundo, teniendo más del 80 % de los usuarios de Internet [10]. Aunque FacebookTM sea posiblemente la red social más importante en estos momentos, no podemos dejar de mencionar a otras redes sociales que también poseen una gran cantidad de usuarios registrados y que además tienen un estilo diferente al de FacebookTM . Estas redes sociales son YoutubeTM (el 60 % de los usuarios de internet tienen cuenta), Google+TM (60%), TwitterTM (53%). Dada la aceptación por parte de los usuarios de Internet hacia las redes sociales, es interesante tener cuenta su enfoque a la hora de desarrollar una aplicación, sobre todo si denota algún carácter interactivo y/o grupal. Además el componente social es un elemento que puede favorecer en gran medida el E-Learning [11, 12, 13, 10], es una gran idea el hecho de introducir características (como por ejemplo sociales, colaborativas, etc...) en un entorno E-Learning; por un lado los usuarios están familiarizados con estas funcionalidades y por otro fomenta el intercambio, transferencia y desarrollo del conocimiento. Por ello este proyecto incorpora un componente social para que los usuarios colaboren, difundan y se comuniquen en el entorno educativo. Capítulo 2 Trabajo relacionado A continuación se van a tratar trabajos previos en E-learning, la motivación y objetivos de dichos trabajos antes de abordar la propuesta de nuestro proyecto. Actualmente es un momento más favorable para el uso de E-Learning como paradigma de aprendizaje, Chris Jones y sus compañeros de trabajo han realizado un estudio [14] con estudiantes de lo que han denominado “digital-natives” o “net-generation”, donde han tratado de buscar claros patrones mientras desarrollan estudios que integran el E-Learning. Este estudio compara dos grupos de estudiantes de primer curso de carrera donde unos usan algunas nuevas tecnologías y el otro conjunto realiza un uso extenso de las nuevas tecnologías, dándose cuenta que los estudiantes nacidos a partir de 1983 pertenecen a un sola generación. Si bien concluyen que de entre los estudiantes de primer año hay variaciones significativas en cuanto al uso de las nuevas tecnologías seguimos pudiendo afirmar que son una nueva generación que ha asimilado la tecnología de una manera más natural y profunda, y ello nos lleva a tener una generación más favorable en la adopción del ELearning como parte de su proceso de aprendizaje. El artículo recoge datos del acceso de los estudiantes a medios digitales que pueden facilitar el uso de tecnologías E-Learning (ordenadores de escritorio, ordenadores portátiles), pero hoy día el 99 % [2] de los estudiantes ya disponen de un smartphone propio lo que nos permite llevar el E-Learning un poco más lejos y por lo cual surge este proyecto. Por otro lado ya han surgido muchas iniciativas de E-Learning hasta hoy, y la gran mayoría acaba por tener un uso descontinuado por parte de los estudiantes. El autor de [15] Ming-Chi Lee ha realizado un estudio para explicar por qué ocurre esta descontinuación y para tratar de predecirla, en el estudio se afirma que la aceptación inicial de un sistema E-Learning es fundamental para que se produzca algún tipo de continuación en su uso y 5 12 Capítulo 3. Propuesta de trabajo 3.3. Secciones de la aplicación a implementar Hemos dividido la funcionalidad en distintos bloques, que cada plataforma móvil adaptará en función del los patrones de diseño propios dicha plataforma. Es decir, la funcionalidad de cada plataforma móvil será idéntica, pero la experiencia de uso de cada una de ellas puede variar. 3.3.1. Tablón Un tablón es un lugar donde se asocian mensajes cortos que han sido enviados por los usuarios. Cada facultad tiene asociado un tablón, pudiendo un mensaje sólo estar asociado a una facultad y a un tablón. Fomentamos el aprendizaje colaborativo a través de un tablón donde los usuarios podrán preguntar sus dudas o simplemente comentar cualquier tema que les parezca oportuno, e incluso compartir noticias sobre los temas que deseen (figura 3.1). Cada facultad tiene asociado un tablón, pudiendo un mensaje sólo estar asociado a una facultad y a un tablón. Figura 3.1: Tablón en AndroidTM, iOSTM y Windows Phone R  3.3. Secciones de la aplicación a implementar 13 Los usuarios podrán interactuar con el tablón de las siguientes maneras, como se aprecia en el diagrama 3.2: Figura 3.2: Casos de Uso de Tablón Un usuario envía un mensaje a un tablón, el usuario compone un mensaje de texto corto ( menos de 140 caracteres), elige si desea enviar el mensaje de forma anónima o no. Se pulsa el botón de enviar para que el mensaje aparezca en el tablón. Un usuario recibe mensajes de un tablón cuando inicia sesión o pulsa el botón de actualizar mensajes tablón. Un usuario hace/deshace favorito un mensaje de un tablón pulsando el botón de hacer/deshacer favorito un mensaje. 3.3.2. Chat Esta sección será diseñada para fomentar el trabajo en equipo y colaborativo, permitirá que los usuarios trabajen con un sistema de comunicación en tiempo real para realizar tareas en grupo. Es por ello que habilitaremos un sistema de mensajería instantánea (figuras 3.4) que nos permitirá comunicarnos con quien deseemos de manera instantánea. El sistema de chat se se basará en el Internet Relay Chat [26] para proveer una integración de de chat en nuestra aplicación, incluyendo mejoras de autenticación (se utiliza la propia autenticación de la aplicación) y el uso del protocolo JSON como método para el recepción y envío de datos. Se ha determinado el nombre de “Sala” a cada uno de los canales definidos por el protocolo IRC [26]. Los usuarios podrán interactuar con el Chat de las siguientes maneras, detalladas en el siguiente diagrama 3.3: 14 Capítulo 3. Propuesta de trabajo Figura 3.3: Casos de Uso de Salas de chat Un usuario, simplemente por el hecho de conectarse a la aplicación, se conectará a la Sala de su Facultad. Por otra parte, se permitirá la creación de Salas con nombre personalizado. Si al introducir el nombre no existía, se creará una nueva y sino, simplemente se unirá a dicha sala. Finalmente el usuario, a través de la interfaz, elegirá de que Sala quiere recibir/enviar mensajes. Figura 3.4: Chat en AndroidTM, iOSTM y Windows Phone R  3.3. Secciones de la aplicación a implementar 15 3.3.3. Archivos Esta sección complementará las dos anteriores proporcionando un sistema de compartición de ficheros para que los alumnos puedan compartir documentación relevante al estudio. Se distingue entre apuntes y exámenes de años anteriores. Cada archivo pertenece a una asignatura o a un tema de una asignatura para facilitar la búsqueda. También se añadirá una fecha para que el usuario pueda tener en cuenta la antiguedad del archivo subido (figuras 3.6). Los usuarios podrán interactuar con los Archivos de las siguientes maneras (diagrama 3.5): Figura 3.5: Casos de Uso de Archivos Un usuario podrá visualizar archivos, ya sean apuntes o exámenes, a través de una asignatura o tema. Un usuario podrá subir archivos, indicando los datos del mismo y eligiendo, a través de la interfaz, la imagen o imágenes que desea subir. 3.3.4. Exámenes En este apartado, se incluye la parte más académica de nuestro LMS. Los profesores podrán componer preguntas para que los alumnos puedan responderlas. La idea es que sean preguntas conceptuales, que resaltan conceptos clave de la asignatura en cuestión y su modo de responder sea intuitivo y fácil. No tenemos intención de obligar al alumno a resolver un problema complejo a través de un dispositivo móvil, sino de resolver muchos problemas sencillos con conceptos clave. 16 Capítulo 3. Propuesta de trabajo Figura 3.6: Archivos en AndroidTM, iOSTM y Windows Phone R  Se implementarán cuatro tipos de tests, preguntas de única respuesta, preguntas de respuesta múltiple, preguntas de respuesta breve y por último preguntas de emparejamiento de respuestas (figuras 3.7). Figura 3.7: Exámenes en AndroidTM, iOSTM y Windows Phone R  Los usuarios podrán interactuar con los Exámenes de las siguientes maneras, como muestra el diagrama 3.8: 3.3. Secciones de la aplicación a implementar 17 Figura 3.8: Casos de Uso de Exámenes Un usuario podrá acceder a la sección de exámenes y elegir asignaturas de la lista habiendo seleccionado previamente el curso de la asignatura. Posteriormente aparece una lista de temas de la asignatura seleccionada, al elegir uno de estos el usuario podrá escoger el tipo de examen a realizar y enviar los resultados cuando termine de realizarlo. 3.3.5. Web Por último se desarrollará un panel de administración (figura 3.9) el cual permitirá, de forma cómoda, la gestión del sistema,tanto para administradores del sistema como para profesorado. Esta parte Web, estará disponible dentro del sistema (no haría falta una aplicación externa para la gestión), pero para mayor comodidad, se permite también el acceso desde un dispositivo cualquiera conectado a Internet. Un usuario con privilegios (profesor) podrá: Componer cualquier tipo de preguntas Obtener los resultados de los test realizados Un usuario administrador podrá: Realizar cualquier gestión relacionada con el sistema, ya que tendrá acceso total al mismo. 18 Capítulo 3. Propuesta de trabajo Figura 3.9: Panel web Capítulo 4 Herramientas de trabajo y organización En este capítulo se explicarán las distintas herramientas de trabajo y organización usadas por el equipo. Al ser un trabajo realizado por más de una persona, la organización y el trabajo en equipo es fundamental. Es por ello que se haya hecho uso de múltiples herramientas para facilitar la tarea conjunta. 4.1. Documentación Se ha hecho uso de dos herramientas para la generación de la distinta documentación requerida por el trabajo. Para realizar documentación interna, se ha decidido utilizar el Servicio de almacenamiento en línea Google DriveTM. Dicha plataforma otorga muchas ventajas para el trabajo en equipo. Por un lado permite la compartición de documentos de forma sencilla y manteniendo la privacidad de estos a usuarios ajenos al proyecto. también proporciona un sistema de control de cambios sobre cada documento que hace mucho más fácil volver a una versión anterior o simplemente conocer qué cambios exactos en el documento se han realizado. Por otra parte y para la generación de documentación externa, como por ejemplo la realización de esta memoria, se ha utilizado OverleafTM que nos permite, de forma colaborativa, editar un documento de tipo L A TEX de manera gratuita (esta memoria ha sido confeccionada en L A TEX). 19 20 Capítulo 4. Herramientas de trabajo y organización Como característica quizá más útil e importante (al menos para este proyecto) es la capacidad que permiten el Servicio de almacenamiento en línea Google DriveTM y OverleafTM de edición en colaborativa en tiempo real, permitiendo así que varios de los componentes de este proyecto trabajen en un mismo documento al mismo tiempo. 4.2. Control de versiones para el código fuente Se ha utilizado Git como herramienta de control de versiones para todos los códigos fuente desarrollados en este proyecto. En este apartado se intenta explicar Git y sus fundamentos básicos. Git es un sistema de control de versiones diseñado para tratar con los proyectos Software sea cual sea su tamaño con rapidez y eficacia. Git tiene múltiples ventajas con respecto a otros sistemas de administración de código fuente, ya puedan ser Subversion, CVS, Perforce u otros. Branchs (ramas): Se puede disponer de múltiples ramas, una para el código en producción, otra para pruebas y otras para distintas características que se estén desarrollando para la aplicación. Ligero y rápido: muchas de las operaciones son realizadas de forma local, dando ventaja a los sistemas centralizados que necesitan comunicarse con un servidor constantemente. Seguridad de datos: para evitar corrupción en los datos, cada subida de código tiene una suma de comprobación que se realiza antes de subir en el cliente y una vez subido en el servidor. Software libre, y por supuesto, gratuito. Distribuido: Una de las mejores características de Git es que necesitas “clonar” el repositorio entero. Esto ofrece múltiples ventajas: •Múltiples copias de seguridad •Se permite usar cualquier “flujo de trabajo” ya sea: ◦Centralizado: todos los desarrolladores suben cambios al mismo repositorio (digrama 4.1). 4.2. Control de versiones para el código fuente 21 ◦“Blessed Repository”: los desarrolladores suben cambios a su repositorio privado y solicitan a un usuario (manager de integración) que suba sus cambios al “Blessed Repository”. Se usa para repositorios de GitHub y otros de código abierto. ◦“Dictador” y “tenientes”: Parecido al anterior pero hay varios usuarios responsables (“tenientes”) de distintos subsistemas que aprueban los cambios que otros desarrolladores han subido. Existe un usuario por encima de los tenientes que sube los cambios al “Blessed Repository”. Figura 4.1: Centralizado GIT dispone de múltiples herramientas gráficas, pero dispone de una potente línea de comandos donde poder realizar todas las operaciones. A diferencia de otros sistemas de control de versiones como SVN, GIT guarda y procesa la información de forma muy diferente, aunque a través de la interfaz de usuario sea parecida. Instantáneas, no diferencias: Esto afecta en como GIT guarda los datos. Conceptualmente los otros sistemas (SVN, etc.) guardan la información como una lista de cambios en los archivos. Estos sistemas tienen la información como un conjunto de archivos y los cambios que se han ido realizando a lo largo del tiempo, así funciona SVN y similares. Sin embargo, GIT no guarda la información de esta manera. GIT almacena distintas instantáneas de un pequeño sistema de archivos. Cada vez que 28 Capítulo 4. Herramientas de trabajo y organización Storyboard Storyboard (figura 4.7) es una herramienta dentro de Xcode R que permite crear las interfaces de usuario colocando los elementos de manera visual, también permite interconectar diferentes vistas para definir el flujo de la aplicación, e incluso propiedades y datos para estos elementos que de otra forma se debería hacer programando directamente. Por supuesto, esto facilita en gran medida crear interfaces de usuario con cierto comportamiento. Aunque por otro lado existe, como se ha mencionado antes, la forma de conectar los elementos visuales a los datos de la aplicación se realiza de una forma fácil pero que no queda reflejada en el código y puede llegar a hacer difícil encontrar errores y/o ver clara la conexión entre ciertos elementos. Figura 4.7: StoryBoard en iOSTM 4.4. Entornos de desarrollo 29 Autolayout Esta es una característica realmente especial de iOSTM por la cual los elemento de la interfaz responden adecuadamente adaptándose a cambios de orientación y tamaño de la pantalla del dispositivo. Funciona a base de restricciones matemáticas que se pueden definir a un elemento en relación a la vista en la que está y/o al resto de elementos. Figura 4.8: Autolayout En la figura 4.8 se aprecia como añadir una restricción de posición al elemento en la vista que se está editando. Almacenamiento interno En iOS existen varias formas de almacenamiento en el dispositivo móvil, estas son: espacio de usuario para almacenar ficheros, user defaults (almacenamiento de propiedades al estilo contenedor asociativo, clave-valor) y core data (ORM - Object-Relational Mapping para SQLite). User defaults Este primer sistema permite almacenar las preferencias de la aplicación en términos de elementos clave-valor (clave1=”valor2”, etc). De esta manera se mantiene un sistema simple de persistencia para datos sencillos y sin relaciones entre sí de referencia directa ni de integridad. En la figura 4.9 se puede apreciar como se registra a la propiedad CacheDataAgressively con un valor booleano YES. Este tipo de almacenamiento sobrevive al cierre de la aplicación, apagado del dispositivo, etc. Core data Es un framework para el acceso a base de datos utilizando persistencia de objetos (diagrama 4.10), esto permite definir por ejemplo objetos con relaciones entre sí, listas de elementos, etc. . . que se pueden almacenar directamente en la base de datos sin necesidad de acceder a la información del 30 Capítulo 4. Herramientas de trabajo y organización Figura 4.9: User defaults objeto ni construir un sentencia de SQL. Figura 4.10: Core Data Por supuesto la mayor este sistema de almacenamiento, al igual que user defaults, es persistente. Paso de información entre vistas (delegados) En este caso se puede hacer de varias formas, o instanciando vía programación el controlador de la vista que se va a mostrar y pasando los datos explícitamente, o usando el patrón delegado. El patrón delegado (diagrama 4.11) permite que un objeto actúe de com- 4.4. Entornos de desarrollo 31 portamiento de otro o el proveedor de este. Figura 4.11: Patrón delegado Por lo tanto es tan simple como definir un objeto delegado que contenga la información de la vista que se va a crear y que esta lo use para obtenerla. Al final la ventana creada tiene una referencia a la ventana padre que la invoca o al objeto delegado que se asigne. 4.4.4. Windows Phone R  Windows Phone R (WP) es propiedad de Microsoft R , por este motivo todo el entorno de desarrollo gira alrededor del sistema operativo para computadora Windows R . En este caso la aplicación a desarrollar es para WP 8.1 y esto pide el requisito mínimo de tener instalado en el PC Windows R  8.1 [28]. El IDE (Integrated Development Environment) recomendado por Microsoft R  para realizar aplicaciones para Windows Phone R es Microsoft Visual Studio R  [29], del cual Microsoft R también es propietario.4.12 La aplicación a desarrollar es una aplicación para móviles, por ese motivo aparte de necesitar una computadora sobre el que desarrollar la aplicación se necesita un terminal que tenga el sistema operativo Windows Phone R 8.1. Aunque el IDE Visual Studio R incorpora una máquina virtual que simula ser un móvil WP para que puedas ejecutar tus aplicaciones, el equipo de desarrollo optó por la compra de un terminal Windows Phone R para tener un dispositivo real en el que ejecutar la aplicación. Debido al bajo presupuesto del que se dispone se ha optado por comprar un terminal de gama baja, el Nokia Lumia 520 (figura 4.13). Este modelo de terminal será sobre el que se ejecute la aplicación y se harán las pruebas. 4.4.4.1. Características especiales de la plataforma En este apartado se procederá a exponer las principales diferencias de Windows Phone R con las otras plataformas sobre las que se han creado la aplicación. 32 Capítulo 4. Herramientas de trabajo y organización Figura 4.12: Visual Studio Figura 4.13: Nokia Lumia 520 Model-View-ViewModel A lo largo del desarrollo de la aplicación se han usado muchos patrones de diseño puesto que como es bien conocido ayudan al desarrollo de la aplicación, la escalabilidad y a su posterior mantenimiento [30] . El objetivo de 4.4. Entornos de desarrollo 33 este apartado no es hacer hincapié en estos patrones bien conocidos como: Factoría abstracta, Singleton, Adapter o Decorator, puesto que estos patrones se pueden usar en la mayoría de los de lenguajes de programación. Lo que se va a describir en este apartado es un patrón exclusivo de MicrosoftTM para desarrollo de aplicaciones para Windows R y Windows Phone R : ModelView-ViewModel. Model-View-ViewModel (también denominado MVVM) es un patrón de diseño de aplicaciones para desacoplar código de interfaz de usuario y código que no pertenezca a dicha interfaz. En funcionamiento de este patrón es bastante sencillo, se define la interfaz de usuario mediante XAML y usas el marcado de enlace de datos para vincularla a otras capas que contengan datos. Esta infraestructura de enlace de datos proporciona un acoplamiento débil que mantiene sincronizada la interfaz del usuario con los datos a los que está vinculado. Usando este patrón el código queda estructurado de tal formas que es posible cambiar cualquiera de las partes de forma individual sin que el resto de las partes se vea afectada. Esto nos ofrece varias ventajas como: Permitir un estilo de codificación exploratorio e iterativo. Simplifica las pruebas unitarias. Permite aprovechar mejor algunas herramientas como Expression Blend. Admite la colaboración en equipos. Como dice el nombre del patrón, al utilizarlo la aplicación se divide en tres capas (diagrama 4.14): Capa del modelo (Model) incluye todo el código que implementa la lógica principal de la aplicación y define los tipos requeridos para modelar el dominio de la aplicación. Capa de la vista (View) define la interfaz de usuario en un lenguaje declarativo, es este caso XAML. El marcado de enlace de datos define la conexión entre componentes de la interfaz y diversos miembros de la vista. Capa de modelo de vista (ViewModel) proporciona destinos de enlace de datos para la vista. En la mayoría de los caso el ViewModel expone a la View el modelo o miembros encapsulados del modelo. El ViewModel también es el encargado de definir un seguimiento de datos que son relevantes para la interfaz de usuario pero no para el modelo, como por ejemplo el orden en que aparecen estos datos en la interfaz. 34 Capítulo 4. Herramientas de trabajo y organización Figura 4.14: Capas del MVVM Esta división en capas ofrece la ventaja de facilitar la comprensión del código, esta ventaja se viene dada a que el código de características específicas a menudo es independiente del otro código, lo que facilita su uso y reutilización. Otra ventaja que nos ofrece esta separación es la realización de pruebas unitarias automatizadas del código que no es parte de la interfaz de usuario. Como conclusión podemos ver que esta arquitectura desacoplada permite aislar el impacto de cambios que se realicen en el código y su reutilización, lo cual es una característica muy importante a tener en cuenta a la hora de desarrollar un proyecto software. ValueConverter En el apartado anterior se vio como un Model mediante un ViewModel queda vinculado a una View, es decir el ViewModel le pasa los datos del Model a la View para que este los muestre. En el caso más sencillo, por ejemplo una cadena de caracteres, solo tendría que mostrar en un cuadro de texto esa cadena de caracteres, pero podemos encontrarnos con un problema si, por ejemplo, el color de texto de un párrafo depende de un valor booleano (verdadero o falso), puesto que esta conversión no será directa. Para estas situaciones tenemos los ValueConverter, se vincularía este valor booleano al color de letra del texto y se le diría que tiene que pasar por el ValueConverter que se ha definido, el cual transformará el valor booleano a un color. Para crear un ValueConverter solo hay que crearse una clase que implemente la interfaz IValueConverter. Esta interfaz obliga a implementar 4.4. Entornos de desarrollo 35 dos funciones Convert(...) y ConvertBack(...). En Convert se recibe el parámetro que se quiere convertir y se devuelve en el formato que se quería, ConvertBack ocurre lo contrario. En el proyecto esto se ha utilizado por ejemplo para saber si un usuario le dio favorito a un mensaje y que aparezca el corazón pintado o no y transformar fechas en formato Unix Timestamp a un formato más legible por el ser humano. Esto se muestra de forma esquemática en la 4.15. Figura 4.15: Ejemplo de IValueConverter 36 Capítulo 4. Herramientas de trabajo y organización Almacenamiento interno Existen diversas formas de almacenar de forma interna en la aplicación datos e información. Para este proyecto se ha optado por 2 formas distintas almacenar la información, según el tipo de datos. IsolatedStorage Es una herramienta que viene por defecto instalada en el SDK de Windows Phone R , permite copiar, mover o reemplazar archivos y directorios a una carpeta local y exclusiva de tu aplicación. Esto se divide en tres apartados como se ve en el diagrama 4.16. Figura 4.16: Descripción gráfica del IsolatedStorage Parejas Clave/Valor Es una forma de almacenar información en formato clave valor. La información solo se puede guardar como cadena de caracteres. Muy útil y sencilla de utilizar, pero tiene una gran limitación, puesto que solo se podrán guardar cadenas de caracteres u objetos serializados en cadena de caracteres. Este tipo de almacenamiento se usa en la aplicación para guardar información con tipo de dato sencillo (cadena de caracteres, enteros, decimales, booleanos) que puede ser necesaria de acceder desde cualquier punto de la aplicación. Por ejemplo el token de sesión, el ID del usuario registrado, el ID de la facultad del usuario, si los mensajes de tablón se ponen de forma anónima, etc. Para acceder a esta información descrita anteriormente se usa una clase 4.4. Entornos de desarrollo 37 estática que se llama AplicationSettings la cual tiene las funciones GET y SET para acceder o modificar esta información. A continuación en el diagrama 4.17, para guardar y coger el token. Figura 4.17: Ejemplo de AplicationSettings Archivos y carpetas. Este apartado es el que te permite crear carpetas dentro de la aplicación y archivos. A estas carpetas y archivos solo tendrá acceso la aplicación que las creó, de esta forma son privadas de la aplicación. Para esta aplicación esto se usara para guardar las fotos de los usuarios, de esta forma no será necesario descargarlas del servidor siempre que quieran mostrarse. Cada vez que se quiere mostrar la foto de un usuario pueden suceder 3 cosas (diagrama 4.18): La foto no está. La foto no se encuentra descargada en el terminal y hay que descargarla y almacenarla. A parte de guardar la foto se guarda la fecha de última modificación que te da el servidor en la cabecera de la petición HTTP. La foto esta y es la actual. La foto se encuentra ya descargada en la aplicación y es la actual. Para saber si la foto es la actual se manda un mensaje HTTP HEAD al servidor, el cual te responde con varios parámetros (sin incluir la imagen que es la parte más pesada de la comunicación), entre esos parámetros esta la fecha de última modificación. Si la fecha de última modificación que se tenía almacenada de la foto coincide con la respuesta del servidor significa que tenemos la foto actualizada. La foto esta y no es la actual. Como se describió en el apartado anterior 44 Capítulo 5. Decisiones de diseño 5.3. Sistemas de comunicación Existen varios sistemas de comunicación que se pueden elegir para las respuestas proporcionadas por un API a los clientes, se van a tratar los más utilizados y conocidos para exponer su estructura y valorar el adecuado para escoger en este proyecto. 5.3.1. XML XML es un lenguaje de marcado muy extendido que se ha convertido en un estándar, desarrollado por el World Wide Web Consortium. Sirve para representar información de forma legible, comunicación entre sistemas de forma independiente del lenguaje o tecnología utilizados, e incluso da soporte para bases de datos. Este lenguaje has sido y sigue siendo ampliamente utilizado, sobre todo en el entorno web. Por ejemplo se utiliza en sistemas SOAP en los cuales se definen como dos objetos de diferentes sistemas pueden comunicarse mediante XML. Un desventaja que se puede encontrar en el uso de XML al ser independiente del sistema es que cada lenguaje debe utilizar un sistema de interpretación de este lenguaje para convertir la información en una estructura de datos manejable por el lenguaje utilizado. 5.3.2. JSON JSON es un formato de datos en representación literal de los objetos de JavaScript, estructura de datos también conocida como diccionario o contenedor asociativo. Una de las características de esta representación de los datos es la ligereza (en término de tamaño) que otorga el formato, es decir, para representar la información se necesitan menos caracteres que en lenguajes como XML. Por otro lado la simplicidad de este formato de datos implica directamente en que el analizador que interpreta la información en una estructura JSON es más sencillo de construir. De los sistemas expuestos arriba para este proyecto se ha decidido utilizar JSON, dado que minimiza los datos necesarios a enviar en la comunicación, siendo esto fundamental ya que ayuda notablemente a minimizar el consumo de datos en dispositivos móviles. 5.4. Estructura, diseño e implementación 45 5.4. Estructura, diseño e implementación En este apartado se expone la estructura y el diseño del servidor y de las aplicaciones móviles desarrolladas, incluyendo donde sea necesario descripciones sobre decisiones de implementación. 5.4.1. Servidor Como ya se ha mencionado antes el servidor está diseñado bajo una arquitectura multicapa (más concretamente modelo-vista-controlador) y con un API como sitema de comunicación con los clientes. Toda la información es enviada y recibida en formato JSON a excepción del panel web, que se trata de HTML. A continuación se exponen aspectos de diseño e implementación que se han considerado relevantes. Inicio de sesión La primera decisión de diseño viene dada por incorporar el sistema en API al servidor, esta trata sobre el inicio de sesión de usuario. Ya que el diseño de un API proporciona una serie de consultas independientes entre si al servidor, se necesita garantizar que el cliente que las realiza lo hace siendo el usuario correcto y autorizado. Para ello se opta por un sistema de token, un identificador único que se obtienen del servidor al realizar la llamada de inicio de sesión y que es requerido para el resto de consultas. 46 Capítulo 5. Decisiones de diseño Figura 5.3: Inicio de sesión En el diagrama 5.3 se muestra como el sistema inicio de sesión es seguro dado que usa tokens, mencionado anteriormente, si no son válidos o han caducado no se permitirá la comunicación con el backend, en caso contrario las peticiones de datos transcurren de forma esperada. Decoradores o capa de middleware Dada la necesidad mencionada en el sistema de inicio de sesión de utilizar un token para la obtención de información se genera la necesidad de comprobar que el token de sesión o identificador único de sesión es válido para la consulta a realizar. Todas las consultas que se pueden realizar al API requieren un token, por lo que la comprobación de dicho token debe realizarse siempre antes de la consulta. Para solucionar esto se ha decidido utilizar un característica del lenguaje Python que se llama decorador, esto permite resolver exactamente la necesidad expuesta, se trata de una función que se ejecutará siempre antes de las consultas al API comprobando la validez del token y permitiendo que se continúe con la consulta sólo en el caso de que lo sea (diagrama 5.3). En el diagrama 5.4 se muestra como la capa de middleware funciona en el caso de las comprobaciones del token. Pero también nos permite registrar accesos al sistema para obtener estadísticas. 5.4. Estructura, diseño e implementación 47 Figura 5.4: Inicio de sesión Arquitectura modelo-vista-controlador El sistema desarrollado como API hace uso del framework Django el cual utiliza una arquitectura modelo-vista-controlador (MVC), esto permite separar la definición de los datos del sistema de la forma en la que se almacenan y del comportamiento de este (albergado en el controlador), también a su vez se abstrae de cómo se van a mostrar los datos en el cliente (vistas). En este sistema en particular las vistas están desarrolladas en las aplicaciones móviles y el acceso en forma de API solo conlleva involucrar al controlador, modelo e integración. A excepción por su puesto del panel de administración web que sigue este modelo fielmente. ORM API Otra de las características que incorpora Django es un API para abstraer el tratamiento de datos a nivel de base de datos, es decir, permite que no se necesario utilizar lenguajes como SQL para realizar las consultas y modificaciones de los datos en el sistema de integración (véase en el apéndice A sección ORM API en Django). 48 Capítulo 5. Decisiones de diseño 5.4.2. Aplicaciones móviles Dado que cada aplicación móvil ha sido desarrollada en una plataforma diferente se da el caso donde todo el ecosistema cambia de una a otra, herramientas de desarrollo, lenguaje, plataforma, diseño de interfaces y sus elementos, etc. Por ello es que el desarrollo de cada aplicación ha tenido que adaptarse o respetar las particularidades de su plataforma. Interfaz de usuario Este es uno de los puntos más diferenciales entre las aplicaciones, dado que en cada sistema existen unos elementos de interfaz de usuario diferentes, distintos métodos para gestionar las vistas y el paso de información entre ellas. Por lo tanto se ha optado por tomar la decisión de que cada aplicación móvil resuelva los diseños y problemas en base a los recursos particulares del sistema. Pero siempre manteniendo la misma funcionalidad. Consumo de datos Las aplicaciones desarrolladas, como se ha mencionado anteriormente en el capítulo dos y tres, tienen un carácter ubicuo; esto lleva a considerar que los recursos de los dispositivos móviles son limitados (datos y batería). Teniendo en cuenta la limitación de recursos en el desarrollo del proyecto se ha buscado agrupar la información al máximo posible en la comunicación entre cliente y servidor para disminuir el consumo de ambos factores. Sistema de almacenamiento En el caso del sistema de almacenamiento del dispositivo móvil también se encuentran cambios significativos, tomando de ejemplo iOS no hace uso sentencias SQL ya que tiene un sistema ORM llamado Core Data (consulte el apéndice A, la sección de almacenamiento interno para cada plataforma). Por lo cual la técnicas de almacenamiento persistente cada dispositivo móvil se han implementado de forma diferente tal y como cada sistema resuelve dicha situación. Capítulo 6 Trabajo Realizado En este capítulo se explicará el trabajo que se ha realizado. Se ha dividido en dos secciones : el servidor de aplicaciones (API) y los distintos clientes en aplicaciones móviles. 6.1. Servidor Para gestionar el backend del sistema M-Learning utilizando el lenguaje de programación Python (v2.7) y el framework Django (v1.7). Para lograr una mayor escalabilidad y evitar problemas de conexión en las redes universitarias o privadas se ha utilizado el protocolo HTTP para las conexiones con el backend, ya que otro tipo de protocolos pueden tener dificultades en este tipo de redes para operar con normalidad debido a las restricciones de seguridad. 6.1.1. Fundamentos básicos del API desarrollado La comunicación de la aplicación móvil se realiza mediante las peticiones HTTP comentadas anteriormente con el backend y este responde en formato JSON, este formato es muy ligero en consumo de datos, fácil de tratar y modelar, y que las tres aplicaciones móviles tratan perfectamente. El API desarrollada tiene una serie de funciones definidas, las cuales realizan un trabajo expecificado para cumplir con los requisitos del sistema. Estas funciones reciben una serie de parámetros en formato HTTP GET o HTTP POST, según corresponda. Por ejemplo, si la llamada requirie el envío de una fichero únicamente puede realizarse vía POST, y para esta llamada todos los parámetros se envían por la misma vía. En cambio si no se requieriese el envío de ningún archivo todos los parámetros de la llamada se incluirán en el HTTP GET. El formato de una función con parametros HTTP GET es: 49 50 Capítulo 6. Trabajo Realizado http://www.bsodsoftware.me/funcion?parametro1=dato1¶metro2=dato2 Los parámetros que recibe el API al realizar una llamada pueden ser de dos tipos: parámetros obligatorios o parámetros opcionales. Antes de realizar cualquier acción, las funciones del servidor con parámetros obligatorios comprueban de su existencia. Se indicará que faltan parámetros obligatorios en la respuesta para ayudar a los desarrolladores y control de errores. La mayoría de las funciones que se invocan tienen una dependencia del usuario que lo hace, por ese motivo incluyen un parametro denominado “token” que es el identificador de sesión de un usuario. El “token” es una cadena alfanumérica aleatoria y única, lo obtiene el usuario al registrarse manteniendolo hasta su proxima conexión con el sistema. Como la comprobación del parámetro “token” es recurrente, ya que para la mayor parte de las invocaciones es necesario estar autenticado en el sistema para hacer uso de ellas, se decidió implementar un “decorador” (capítulo cinco para más detalles acerca de decoradores) para la comprobación de su existencia en las invocaciones a funciones. Esto es una función que “envuelve” a otra, es decir que se ejecutara antes y podra abortar la ejecución en caso necesario. En nuestro caso la función invocada no se puede ejecutar si falta el "token". Además esto proporciona una gran cantidad de ventajas como se puede ver en [31]. En el diagrama 6.1 se puede observar la arquitectura del sistema MLearning, donde el usuario que interactúa con la aplicación móvil crea una comunicación desde esta hacia el backend y el backend a su vez con la base de datos. Generando de esta manera un canal de comunicación bidireccional. Figura 6.1: Estructura sistema 6.1. Servidor 51 6.1.2. Sistema de Chat Para la implementación del chat se ha optado por la programación orientada a eventos, en este caso los eventos son las nuevas conexiones TCP al puerto 8000 para el posterior envío/recepción de información. Se ha hecho uso de Twisted, que es un motor de comunicación orientado a eventos de red escrito en Python [32]. El primer paso necesario para utilizar es chat se trata de autenticarse en el sistema. Como para entrar al chat se necesitan credenciales, los usuarios podrán estar en dos estados distintos. El primero “conectándose” cuando su terminal se conecta al puerto del servidor y empieza a mandar las credenciales para poder acceder al chat. Y el segundo “chat” cuando las credenciales del usuario son aceptadas. Una vez se encuentra en el segundo estado ya esta listo para conectarse a salas, crearlas, mandar o recibir mensajes. A continuación se muestra un ejemplo de conexión en la figura 6.2. La comunicación entre el servidor y el móvil del usuario está encapsulada en JSON y existen una serie de mensajes predefinidos, a continuación se mostrarán los mensajes del servidor (figura 6.3) en y de la aplicación móvil (figura 6.4). Para el servidor el mensaje de tipo “status” informa al terminal en que estado se encuentra, si esta “conectándose” o esta ya en estado “chat”. El mensaje de tipo “message” lo manda el servidor cuando otro usuario ha mandado un mensaje a una determinada sala en la que el móvil está conectado. El último tipo de mensaje que puede mandar el servidor es de tipo “error” para notificar que se ha producido un error, como por ejemplo credenciales inválidas. El terminal también puede mandar tres tipos de mensajes diferentes, el primero “login” para mandar las credenciales y asi poder conectarse al chat. Con el segundo “message” se mandan mensajes al resto de usuarios de una determinada sala y con “room” se accede a una sala. En caso de que la sala a la que se quiere conectar no exista el servidor la crea. 6.1.3. Despliegue Para facilitar el despliegue del API en el servidor de producción, se desarrollaron unos scripts en Shell Bash para producir una automatización del despliegue, actualizando el código desde repositorio de GitHubTM y actualizando el modelo de datos si fuere necesario. 52 Capítulo 6. Trabajo Realizado Figura 6.2: Conexión al Chat Figura 6.3: Mensajes enviados por el servidor 6.2. Aplicaciones móviles En este apartado se explicará cómo se han afrontado los casos de uso en las tres plataformas sobre las que se ha desarrollado. 6.2. Aplicaciones móviles 53 Figura 6.4: Mensajes enviados por los dispositivos Se debe tener en cuenta que las tres plataformas sobre las que se ha desarrollado la aplicación tienen estilos distintos, por este motivo y aun que las tres cumplen con todos los requisitos del sistema, es bastante probable que no coincidan en la forma de implementarlos. En estos casos se hará una aclaración para cada plataforma si fuere necesario. 6.2.1. Primera ejecución Hay dos casos de uso iniciales, Registrar e Iniciar Sesión. Por ese motivo la aplicación lo primero que hará nada más abrirla será consultar si hay un usuario ya registrado. En caso de que no se exista un usuario registrado hay que dar opción al usuario a elegir entre Iniciar Sesión o Registrarse si ya tiene una cuenta. En la figura 6.5 se muestra los descrito anteriormente y una captura del registro. 6.2.2. UC1: Registrar Usuario Para empezar se va suponer que el usuario acaba de instalar la aplicación, si este es el caso el siguiente paso será que pulse en el botón registrar y de esta forma la siguiente pantalla que verá será en 6.6. Una vez aquí el usuario deberá elegir su nombre de usuario con el cual se registrara en la aplicación. también tendrá que elegir una contraseña, correo electrónico, provincia, universidad y por último facultad. Esto parece sencillo, pero tenemos que tener en cuenta que no pueden existir dos usuarios con el mismo nombre de usuario ni con el mismo correo electrónico, a esto hay que sumarle que por motivos de seguridad no son aceptadas las contraseñas cortas. Estos pequeños detalles se controlan y muestran en 6.6. Para controlar que no se repita nombre de usuario lo que hace el terminal es hacer una llamada al servidor preguntando si ese nombre de usuario está 60 Capítulo 6. Trabajo Realizado moverse entre las preguntas. El usuario podrá navegar entre las preguntas tantas veces desee y una vez considere que está finalizado podrá enviar el mismo. Tras finalizar cada examen se mostrará la nota obtenida y se proporcionará la opción de salir o visualizar la corrección. Para visualizar la corrección, el usuario deberá navegar entre las preguntas y podrá comprobar las respuestas acertadas y falladas en distintos colores. El terminal enviará la información de preguntas acertadas, no respondidas o falladas. A continuacion se expondrán ejemplos sobre los tipos de examenes que se pueden realizar, las preguntas son de prueba, por eso la información que contienen no es relevante. Examen tipo test respuesta única Consta de preguntas tipo test con una única respuesta correcta. El número de respuestas puede variar desde dos a cinco, pero solo una es la correcta. Esto se muestra en 6.12. Figura 6.12: Examen tipo text única respuesta AndroidTM, iOSTM y Windows Phone R  Examen tipo test multirespuesta Consta de preguntas tipo test con una o más de una respuesta correcta. Igual que en el caso anterior el número de respuestas puede variar de dos a cinco, pero en este caso puede haber más de una correcta, el número de respuestas correctas también puede variar desde una hasta todas las que se 6.2. Aplicaciones móviles 61 muestran 6.13. Figura 6.13: Examen tipo text multi-respuesta AndroidTM, iOSTM y Windows Phone R  Examen respuestas cortas El tercer tipo de examen es respuestas cortas. En esta ocasión el usuario deberá escribir la respuesta que considere oportuna. En la corrección de exámenes con respuesta corta se mostrarán en la misma pantalla la respuesta correcta y la que ha dado el usuario. En caso de que las respuestas coinciden se muestra la respuesta del usuario con fondo verde, en caso contrario se muestra con fondo rojo. Se puede visualizar un ejemplo en 6.14. Tipo respuestas en parejas El último tipo de examen son los exámenes tipo respuestas en pareja. En este caso se mostrará dos columnas y el usuario deberá relacionarlas. Cada columna consta de tres respuestas. El usuario deberá relacionar cada una de las columnas con su opuesta. El estilo en el que se muestra la corrección es bastante similar a los exámenes multirespuesta, puesto que se dispone del botón que permite cambiar entre respuestas dadas por el usuario o la corrección. Cuando se muestran las respuestas dadas por el usuario se usarán diferentes tonalidades de verde para las que están correctas y diferentes tonalidades de rojo para las incorrectas. 62 Capítulo 6. Trabajo Realizado Figura 6.14: Examen tipo respuestas cortas AndroidTM, iOSTM y Windows Phone R  Figura 6.15: Examen tipo parejas AndroidTM, iOSTM y Windows Phone R  6.2.10. UC9: Visualizar estadísticas Tras realizar al menos un examen, se proporciona la posibilidad de obtener estadísticas relacionadas a la realización de los mismos. 6.2. Aplicaciones móviles 63 La información que se mostrará será la nota media de los exámenes y el tiempo medio de realización agrupada por todos los examenes realizados hasta la fecha. Posteriormente se mostrarán (figura 6.16) dos gráficas: un diagrama circular indicando las preguntas acertadas, falladas y no contestadas; una gráfica lineal de los exámenes de forma individualizada que indican las fechas de realización de los mismos y la nota obtenida, preguntas acertadas, falladas y no respondidas. Figura 6.16: Gráficas en AndroidTM, iOSTM y Windows Phone R  6.2.11. UC10: Subir un examen/apuntes Para poder subir un examen o apuntes se pedirán unos datos básicos para poder identificar el examen o los apuntes que el usuario desea compartir. En ambos casos el tema de la asignatura será algo opcional, puesto que puede ser un examen o apuntes de toda la asignatura y no de un tema específico. Una vez rellenados los datos y seleccionadas las imágenes ya está listo para enviar 6.17. 6.2.12. UC11: Consultar examen/apuntes El apartado anterior no tendría ningún sentido si los usuarios no pudieran ver los exámenes o apuntes que se han subido, en este apartado se mostrará como ver esos apuntes. Al igual que en el apartado anterior, por su similitud 64 Capítulo 6. Trabajo Realizado Figura 6.17: Subir exámen AndroidTM, iOSTM y Windows Phone R  se explican juntos. En esta vista de búsqueda existe un formulario en el cual se debe rellenar lo que quiere buscar. Una vez rellenado esto se le envía al servidor la petición y se abre una vista con todos los exámenes o apuntes que cumplen esos requisitos. Se selecciona el que se quiere ver y se abre la vista individual del examen o los apuntes y se pueden ver las imágenes que lo forman 6.18. 6.2.13. UC12: Modificar perfil usuario En este apartado se permiten múltiples modificaciones : Para cambiar la foto de perfil solo hay que acceder al perfil de usuario, esto nos permite poner cualquier foto que se encuentre en el terminal. A partir de ese momento, se usará la nueva foto del usuario para identificarle . Además, se permite a un usuario cambiar su contraseña y facultad. Por motivos de seguridad antes de realizar ningún cambio se pide la contraseña actual. Todos los parámetros son comprobados finalmente por el servidor, que nos indicará si el cambio ha sido satisfactorio o por el contrario existe algún error en los datos introducidos. 6.2. Aplicaciones móviles 65 Figura 6.18: Subir exámen AndroidTM, iOSTM y Windows Phone R  Figura 6.19: Cambiar perfil AndroidTM , iOSTM y Windows Phone R  6.2.14. UC13: Crear sala de chat En este apartado los usuarios podrán crear salas con el objetivo de chatear con otros usuarios. Los mensajes de estas salas sólo los recibirán los usuarios que están conectados a dicha sala y la información no se almacena, es decir los mensajes no se guarda indefinidamente simplemente se muestran mientras 66 Capítulo 6. Trabajo Realizado se permanece en la sala 6.20 . Figura 6.20: Chat en AndroidTM, iOSTM y Windows Phone R  El funcionamiento del chat visto de la perspectiva del móvil consiste en conectarse a un socket TCP al puerto del servidor. Luego seguir los pasos de registro que sean oportunos y ya estará listo para recibir y transmitir. 6.2.15. UC14: Enviar mensajes chat Cuando el usuario considere oportuno a parte de poder conectarse a una sala podrá escribir en ella, de esta forma tendrá la posibilidad de interactuar con el resto de usuarios de forma inmediata 6.21. El terminal lo que hara será encapsular la información en un JSON y mandarselo al servidor para que este lo distribuya entre el resto de usuarios. 6.2.16. UC15: Recibir mensaje chat Cuando el servidor envía los terminales conectados a una determinada sala los mensajes que han escrito otros usuarios, los terminales colocaran esta información en la pantalla de teléfono del usuario para que este pueda leerlo y responder si lo considera necesario. 6.3. Contribución al proyecto 67 Figura 6.21: Chat en AndroidTM, iOSTM y Windows Phone R  6.3. Contribución al proyecto Como se ha visto en este mismo capítulo el proyecto consta de cuatro aplicaciones principales: servidor, aplicación para AndroidTM, iOSTM y Windows Phone R . La distribución general ha sido la siguiente: Cada integrante del equipo del equipo desarrolló por completo cada una de las aplicaciones para dispositivos móviles y el servidor fue desarrollado de forma colaborativa, es decir, para cada problema a resolver, cada integrante propone una forma de resolver el problema y se decide entre los integrantes cual será la solución a implementar. Es por este motivo, que es complicado intentificar tareas realizadas por cada integrante, ya que se ha trabajado en equipo como un único integrante, siendo solo identificable el trabajo individual realizado por cada uno de las aplicaciones para dispositivos móviles. Se ha realizado un proceso incremental e iterativo de desarrollo para cada uno de las distintas secciones que formaban parte, siendo estas: Identificación del caso de uso a resolver. Proposición de las distintas soluciones al problema. Selección de la solución a implementar. 68 Capítulo 6. Trabajo Realizado Implementación en el servidor de la solución decidida. Integración de las llamadas anteriormente implementadas en las distintas plataformas móviles. Pruebas de integración y de aplicación, localización de posibles errores y solución. Por otra parte, se realizaron dos test a dos grupos distintos de alumnos de la Facultad de Informática de la Universidad Complutense de Madrid. El primer grupo, formado por alumnos de la asignatura de Diseño Autómatico de Sistemas, se les permitió explorar la aplicación, resolver un examen real realizado por José Miguel Montañana Aliaga, y resolver un test de opinión en aplicación. Otro test se realizó a papel a un grupo de control, simplemente explicando en qué consiste la aplicación, pero sin permitir explorar la aplicación y solamente permitiendo responder a preguntas de opinión. Para la realización de estos test, todos los integrantes realizaron una investigación leyendo diversos artículos científicos de prestigiosas revistas como Computers on Education entre otras, para tomar como ejemplo investigaciones anteriores para realizar preguntas similares o mejorar las ya realizadas y finalmente se procedió a la composición de las mismas, usandolas en los test anteriormente mencionados. 6.3.1. Daniel Serrano Torres Desarrollo completo de la aplicación para la plataforma iOSTM y colaboración en el desarrollo del servidor. Dado que la plataforma de desarrollo de Apple R , iOSTM, antes de comenzar el proyecto era completamente desconocida por el desarrollador se ha necesitado un un proceso de investigación en varias áreas o aspectos del proceso de desarrollo enumeradas a continuación: Si bien la plataforma de iOSTM puede ser desarrolada con dos lenguajes de programación, Swift y Objective C. Para el desarrollo de esta aplicación se ha optado por Objective C, que ha llevado un proceso de investigación contínuo ya que el propio diseño interno del lenguaje dista notablemente en sintáxis e implementación respecto a otros lenguajes como puden ser Java, Python, C++. El lenguaje de programación es una parte muy importande a aprender para el desarrollo de la aplicación, pero también lo es el deseño de la arquitectura y funcionamiento de las aplicaciones de este. Por lo tanto el estudio de la arquitectura de las aplicaciones de iOSTM ha 6.3. Contribución al proyecto 69 sido otra tarea de investigación realizada durante el proyecto, donde se han aprendido conceptos fundamentales como por ejemplo: el diseño de interfaces (Autolayout), almacenamiento interno (Core Data) y vinculación de código y elementos visuales (Storyboard). De cara a realizar un proceso de desarrollo adecuado también ha sido necesario un proceso de aprendizaje e investigación sobre la herramienta Xcode R (el IDE para iOSTM), funcionamiento, atajos de teclado, sistema de depuración de errores, configuración de proyectos, integración de un gestor de dependencias para librerías externas, etc. Para realizar pruebas en un dispositivo real, y dado que no se dispone de presupuesto para un dispositivo con iOSTM actual ni para una licencia anual de desarrollador, se ha utilizado un dispositivo antiguo para el cual ha sido necesario un proceso de investigación con el objetivo de conseguir acceso al terminal (JailBreak) sin necesidad de poseer una licencia de desarrollador; y poder desplegar la aplicación de para realizar pruebas. Este proceso se ha realizado en un entorno de carácter educativo. De cara al desarrollo de partes del servidor también se han realizado procesos de investigación que por ejemplo abarcan el diseño de un modelo basado en herencia con atributos personalizados, en término de estructura de datos a manejar entre el modelo y la base de datos. 6.3.2. David García Álvarez Desarrollador de la aplicación de Windows Phone R y colaboración en el desarrollo del servidor. Sin conocimientos previos de esta plataforma, a parte del desarrollo de la aplicación, hubo un trabajo previo de investigación y aprendizaje del lenguaje C# y .NET. Como parte a destacar del trabajo en Windows Phone R , a parte de la implementación de los casos de uso, tenemos: Obtención de una licencia de Visual Studio R e instalación. Adaptación a este nuevo entorno de desarrollo. Obtención de licencia de desarrollo por parte de Microsoft R , para Windows Phone R . Lectura y desarrollo de los ejemplos del libro Desarrollo en Windows 8 y Windows Phone 8 con XAML y C# [33]. Lectura y desarrollo de los ejemplos del The Absolute Beginner [34]. 76 Capítulo 8. Discussion and conclusion or the time taken to use the mobile device tasks outside lesson time. Collaboration, another aspect that education can be a very useful and necessary factor but can become complicated to archieve a way that can be profitable. Already mentioned above (Chapter Two) one factor hindering the cooperation of groups of study or work is the need for the members of these require physically meet to share work material for this particular point are chosen mobile platforms to grant a ubiquity allowing the application to overcome this barrier; and ,on the other hand, also as an important factor, is communication of the members of the working group, which has been solved in the project with a real-time chat system (IRC like). This project aims to provide to the educational system a useful tool that promotes E-learning. It is therefore also interesting disseminating knowledge more easily, share files section is with which we meet this goal and encourage the dissemination of educational material. On the other hand this functionality also improves the collaborative nature since sharing the necessary documents for a group project. As last extraordinary objective has been propoused to decrease the abandonment of the E-Learning systems, this is where we go back on the decision to develop the project on mobile devices that gives us the ubiquitous factor system. Thereby we bring greater flexibility to the user to use the application when and where you want, and thus can take advantage of motivation or idle moments to use rather than having a fixed time and place where you should go to perform the task. This can help increase user motivation to use the application, being one of the factors discussed in chapter two. To conclude the discussion on the objectives can say that this project has fullfilled all the objectives addressed in its proposal and even some more without these being part of the initial requirements. 8.2. E-Learning, future This method of teaching is widespread and in different forms and areas, and thanks to technology, the tools are getting better. On the other hand seeing the E-Learning is about twenty years and each time has gone but not believe it is a tendency to disappear, which we consider good idea to bet and invest in their development. Since education is incredibly extensive and varied E-Learning takes time trying to supplement the teaching of effective and measurable way. There are many fields where the E-Learning has focused its development: micro 8.3. Future work 77 learning, it focuses on design activities with short steps in digital media environments, which means the day of knowledge of many workers; Gamification is a field of E-Learning focused on bringing education and knowledge through games, puzzles and solving development problems; personalized learning, teaching is customized individually where even students can choose what you want to learn and can achieve defined goals and types of reward for doing so. All of the above reveals that the E-Learning has a great future ahead of evolving and improving, making a good decision to consider developing systems such as this project. 8.3. Future work As already stated the E-Learning covers a wide range of fields, issues and ways to improve teaching processes, this leads to our project has ample capacity for improvement and incorporation of new features. We will expose some improvements that we believe may be included in the developed system. One of the features of the application is more extensible is the test section, currently has developed four types of controls that can be performed. This is where you can include as many new models of questions as may occur, for example complete sentences with a set of words (extensible code snippets in the case of computers science). Timeline section can incorporate a system of references to news from other users, in order to relate to each news and other content. As every software with user interface there is always improvement to the presentation layer, providing better usability with the feedback provided by the users. To file section can incorporate a gallery of the existing filter system to find shared documents more easily The chat can be incorporated a system of inviting rooms created by other users. Finally, another application could be developed, such as PC, Mac R or GNU Linux because the current architecture allows full scalability. These are just some of the ideas for improvement for this project, you can appreciate the extent of improvement of an M-Learning system as it has developed. 78 Capítulo 8. Discussion and conclusion 8.4. Conclusion This project has managed to archieve all the objectives sought, although, besides being a tool of support to education (LMS) with a list of features that simply attending, extend and/or improve certain tasks in education, also it has been designed with the idea of archieve objectives beyond the mere fact develop a software, that is, more of the objectives of this project are trying to provide solutions or improvements on issues and factors involved in any process of E-learning that difficult their success. During development of the project has been surveyed two groups of students, one of these groups performed within the mobile application, which on the other hand shows the potential and the proper functioning of the module examinations since the survey was performed through this. On one side it has assessed the correct functioning and utility of module examinations denoting the capacity of this versatile, since it allows surveys or questionnaires to similar types of examinations and controls. Other sections have been tested successfully in environments relevant on all mobile platforms. Glosario API (Application Programming Interface) Una interfaz definida y conocida por los clientes para realizar peticiones de información. Cliente Cualquier sistema que realice peticiones de información al sistema en el servidor. Backend Sistema que se ejecuta en el servidor para proveer información o realizar tareas. Branch En el contexto de un sistema de control de versiones hace referencia a una rama, es decir, un flujo de trabajo derivado del principal. Framework Estructura y librería de software. HTTP (HyperText Transfer Protocol) Es un protocolo de intercambio de información en formato de texto a través de conexiones de red para sistemas web. IDE (Integrated Developement Enviroment) Un entorno integrado de desarrollo es un conjunto de herramientas que facilitan el proceso de desarrollo de un producto software. JSON (JavaScript Simple Object Notation) Formato para representar información de forma sencilla y ligera. ORM (Object Relational Mapping) Sistema de abstracción del modelo y la base de datos, permitiendo objetos del lenguaje de programación en vez de lenguajes como SQL. Servidor Plataforma conectada a internet que alberga una serie de servicios provistos a los clientes que entablen comunicación con esta. SOAP (Simple Object Access Protocol) Protocolo que define la comunicación entre dos objetos de diferentes procesos a través de XML. Token 79 80 Capítulo 8. Discussion and conclusion Identificador único para comunicaciones con identificación de cliente. XML (eXtensible Markup Language) Lenguaje de marcado para representar información. Acrónimos API: Application Programming Interface CBT: Cognitive Behavioral Therapy E-Learning: Electronic Learning HTTP: HyperText Transfer Protocol IDE: Integrated Development Enviroment JSON: JavaScript Simple Object Notation LMS: Learning Management System M-Learning: Mobile Learning SQL: Structured Query Language T-Learning: Television Learning U-Learning: Ubiquitous Learning 81 Apéndice A ORM API en Django A.1. Modelos para el ejemplo from django.db import models class Blog(models.Model): name = models.CharField(max_length=100) tagline = models.TextField() def __str__(self): # __unicode__ on Python 2 return self.name class Author(models.Model): name = models.CharField(max_length=50) email = models.EmailField() def __str__(self): # __unicode__ on Python 2 return self.name class Entry(models.Model): blog = models.ForeignKey(Blog) headline = models.CharField(max_length=255) body_text = models.TextField() pub_date = models.DateField() mod_date = models.DateField() authors = models.ManyToManyField(Author) n_comments = models.IntegerField() n_pingbacks = models.IntegerField() rating = models.IntegerField() def __str__(self): # __unicode__ on Python 2 83 84 Apéndice A. ORM API en Django return self.headline A.2. Creando un nuevo registro en la base de datos from blog.models import Blog b = Blog(name=’Beatles Blog’, tagline=’All the latest Beatles news.’) b.save() A.3. Consultando todos los registros de la entidad Entry all_entries = Entry.objects.all() A.4. Relaciones entre tablas a través de los modelos entry = Entry.objects.get(pk=1) cheese_blog = Blog.objects.get(name="Cheddar Talk") entry.blog = cheese_blog entry.save() Apéndice B Enlaces de interés Aplicaciones móviles Aplicación para AndroidTM: https://play.google.com/store/apps/ detailsiid=com.bsod.uniapp Aplicación para Windows Phone R : https://www.windowsphone.com/s?appid=8a9f1939e74b-4d1a-89bd-0a96fa8355a1 Repositorios de código fuente Aplicación para AndroidTM: https://github.com/PaytonZ/TFG-droid Aplicación para Windows Phone R : https://github.com/own3dh2so4/TFGWP Aplicación para iOSTM: https://github.com/plandevida/TFG-iOS Aplicación para el servidor: https://github.com/plandevida/TFG-Webservice 85