GAMIFICACIÓN UNIVERSITARIA Trabajo Fin de...
Transcript of GAMIFICACIÓN UNIVERSITARIA Trabajo Fin de...
Escu
ela
Polit
écn
ica S
upe
rior
de
Jaén
UNIVERSIDAD DE JAÉN
Escuela Politécnica Superior de Jaén
Trabajo Fin de Grado
GAMIFICACIÓN
UNIVERSITARIA
Alumno: Carlos Jesús Serrano Martínez
Tutor: Prof. D. Manuel Carlos Díaz Galiano
Dpto: Departamento de informática
Septiembre, 2017
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
2
Escuela Politécnica Superior de Jaén
Universidad de Jaén
Escuela Politécnica Superior de Jaén
Departamento de Informática
Don Manuel Carlos Díaz Galiano , tutor del Proyecto Fin de Carrera
titulado: Gamificación Universitaría, que presenta Carlos Jesús Serrano
Martínez, autoriza su presentación para defensa y evaluación en la Escuela
Politécnica Superior de Jaén.
Jaén, Septiembre de 2017
El alumno: Los tutores:
Carlos Jesús Serrano Martínez Manuel Carlos Díaz Galiano
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
4
Escuela Politécnica Superior de Jaén
Índice
Agradecimientos .................................................................................... 13
1. Introducción .................................................................................. 15
2. Gamificación ................................................................................. 16
2.1. Plataformas de Gamificación actuales ................................... 17
2.1.1. Plataforma de Gamificación desarrollada por la UJA .......... 17
2.1.1.1. Funcionamiento de la plataforma: Administrador ............. 17
2.1.1.2. Funcionamiento en la parte del usuario ........................... 19
2.1.1.3. Inconvenientes y problemas de esta plataforma .............. 21
2.1.2. Otras plataformas de gamificación actuales ....................... 24
3. Fase inicial de análisis del problema ............................................ 25
3.1. Roles en el sistema ................................................................ 27
3.1.1. Rol admin ............................................................................ 27
3.1.2. Rol profesor ........................................................................ 28
3.1.3. Rol estudiante ..................................................................... 28
3.2. Casos de uso de la plataforma. Requisitos funcionales. ........ 28
3.2.1. Diagrama de casos de uso. ................................................ 29
3.2.2. Registro en el sistema ......................................................... 29
3.2.3. Acceso a la aplicación ......................................................... 30
3.2.4. Visualizar perfil .................................................................... 30
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
5
Escuela Politécnica Superior de Jaén
3.2.5. Canjear ticket ...................................................................... 30
3.2.6. Listar usuarios del sistema .................................................. 30
3.2.7. Crear usuario ...................................................................... 30
3.2.8. Listar actividades del sistema ............................................. 30
3.2.9. Crear actividad .................................................................... 31
3.2.10. Listar objetivos .................................................................. 31
3.2.11. Crear objetivo .................................................................... 31
3.2.12. Ranking objetivo................................................................ 31
3.2.13. Tandas tickets ................................................................... 31
3.2.14. Crear tanda ....................................................................... 31
3.2.15. Listado tickets ................................................................... 31
3.2.16. Ver tickets ......................................................................... 32
3.2.17. Listar usuarios de actividad ............................................... 32
3.2.18. Canjeos ............................................................................. 32
3.2.19. Listar profesores de la actividad ....................................... 32
3.3. Requisitos no funcionales de la aplicación ............................. 32
3.4. Tecnologías para el desarrollo de la plataforma. Análisis
técnico del proyecto. ..................................................................................... 33
3.4.1. Spring Framework vs Java EE ............................................ 34
3.4.2. Capa de lógica negocio ....................................................... 36
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
6
Escuela Politécnica Superior de Jaén
3.4.3. Capa de persistencia de datos ............................................ 36
3.4.4. Capa de presentación ......................................................... 38
3.5. Modelo de dominio. ................................................................ 40
4. Metodología de trabajo y estimación inicial del proyecto. ............. 40
4.1. Metodología de trabajo. ......................................................... 40
4.2. Metodología ágil: Scrum......................................................... 43
4.3. Planificación y definición de lo que vamos a desarrollar ........ 46
4.4. Presupuesto y costos del proyecto ........................................ 55
5. Diseño e implementación del back-end y del front-end: API REST y
Cliente web Java .............................................................................................. 56
5.1. Arquitectura de 4 capas ......................................................... 57
5.1.1. Capa de modelo de datos ................................................... 58
5.1.2. Capa de lógica de negocio .................................................. 58
5.1.3. Capa de persistencia .......................................................... 58
5.1.4. Capa de servicios................................................................ 58
5.2. Iteración 1 .............................................................................. 59
5.2.1. Análisis ................................................................................ 59
5.2.2. Diagrama de clases: capa de persistencia y capa de lógica
de negocio. 60
5.2.3. Implementación del modelo de datos e Implementación de la
capa de persistencia. ................................................................................. 63
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
7
Escuela Politécnica Superior de Jaén
5.2.4. Cierre de la iteración 1 ........................................................ 68
5.3. Iteración 2 .............................................................................. 68
5.3.1. Análisis ................................................................................ 68
5.3.2. Crear usuario ...................................................................... 73
5.3.3. Autenticación de usuario ..................................................... 75
5.3.4. Obtener usuario .................................................................. 77
5.3.5. Editar usuario ...................................................................... 80
5.3.6. Editar contraseña ................................................................ 81
5.3.7. Cambiar contraseña ............................................................ 82
5.3.8. Cierre de la iteración 2 ........................................................ 83
5.4. Iteración 3 .............................................................................. 83
5.4.1. Análisis ................................................................................ 83
5.4.2. Crear actividad .................................................................... 84
5.4.3. Obtener actividad ................................................................ 85
5.4.4. Editar actividad ................................................................... 87
5.4.5. Crear objetivo ...................................................................... 88
5.4.6. Obtener objetivo. ................................................................. 90
5.4.7. Cierre iteración 3. ................................................................ 91
5.5. Iteración 4 .............................................................................. 91
5.5.1. Análisis ................................................................................ 91
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
8
Escuela Politécnica Superior de Jaén
5.5.2. Editar Objetivo. ................................................................... 92
5.5.3. Crear tanda de tickets ......................................................... 93
5.5.4. Obtener tanda de tickets ..................................................... 94
5.5.5. Editar tanda de tickets ......................................................... 96
5.5.6. Obtener Ticket .................................................................... 97
5.5.7. Canjear Ticket. .................................................................... 98
5.5.8. Cierre de la iteración 4 ...................................................... 100
5.6. Iteración 5 ............................................................................ 101
5.6.1. Análisis .............................................................................. 101
5.6.2. Ranking de actividad ......................................................... 101
5.6.3. Ranking de objetivo ........................................................... 103
5.6.4. Cierre de la iteración 5 ...................................................... 104
5.7. Iteración 6 ............................................................................ 105
5.7.1. Análisis .............................................................................. 105
5.7.2. Añadir profesor a una actividad ........................................ 106
5.7.3. Canjeos de un usuario en una actividad ........................... 107
5.7.4. Canjeos de un usuario en una actividad ........................... 108
5.7.5. Cierre de la iteración 6 ...................................................... 109
5.8. Iteración 7 ............................................................................ 109
5.8.1. Análisis .............................................................................. 109
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
9
Escuela Politécnica Superior de Jaén
5.8.2. Obtener listado de actividades .......................................... 110
5.8.3. Obtener listado los usuarios .............................................. 111
5.8.4. Eliminar estudiante de una actividad ................................. 112
5.8.5. Eliminar profesor de una actividad .................................... 113
5.8.6. Eliminar usuario ................................................................ 114
5.8.7. Cierre de la iteración 7 ...................................................... 115
5.9. Iteración 8 ............................................................................ 115
5.9.1. Análisis .............................................................................. 115
5.9.2. Eliminar actividad .............................................................. 118
5.9.3. Eliminar objetivo ................................................................ 119
5.9.4. Eliminar tanda ................................................................... 120
5.9.5. Formulario de registro ....................................................... 121
5.9.6. Formulario de inicio de sesión .......................................... 122
5.9.7. Página de inicio ................................................................. 122
5.9.8. Cierre de la iteración 8 ...................................................... 122
5.10. Iteración 9 ............................................................................ 123
5.10.1. Análisis ............................................................................ 123
5.10.2. Página para visualizar perfil de usuario .......................... 123
5.10.3. Formulario de edición de perfil ........................................ 124
5.10.4. Formulario de edición de contraseña .............................. 125
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
10
Escuela Politécnica Superior de Jaén
5.10.5. Página para visualizar usuarios. ..................................... 125
5.10.6. Página para ver detalles de usuario. ............................... 126
5.10.7. Formulario de edición de usuario .................................... 126
5.10.8. Formulario de cambio de contraseña .............................. 127
5.10.9. Cierre de la iteración 9 .................................................... 128
5.11. Iteración 10 .......................................................................... 128
5.11.1. Análisis ............................................................................ 128
5.11.2. Página para visualizar actividades .................................. 129
5.11.3. Formulario para editar actividades .................................. 129
5.11.4. Página para visualizar objetivo ....................................... 130
5.11.5. Formulario de edición de objetivos.................................. 130
5.11.6. Página para listar tandas de tickets ................................ 131
5.11.7. Formulario de edición de tandas ..................................... 131
5.11.8. Cierre de la iteración 10 .................................................. 132
5.12. Iteración 11 .......................................................................... 132
5.12.1. Análisis ............................................................................ 132
5.12.2. Página para visualizar tickets con QR ............................. 133
5.12.3. Página para listar tickets ................................................. 134
5.12.4. Página de detalles de un ticket ....................................... 134
5.12.5. Página de ranking por objetivo ........................................ 135
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
11
Escuela Politécnica Superior de Jaén
5.12.6. Página de ranking por actividad ...................................... 136
5.12.7. Cierre de la iteración número 11 ..................................... 136
5.13. Iteración 12 .......................................................................... 137
5.13.1. Análisis ............................................................................ 137
5.13.2. Página de Canjeos de un usuario ................................... 137
5.13.3. Página de profesores de una actividad ........................... 138
5.13.4. Página para añadir profesor a una actividad ................... 138
5.13.5. Formulario de canjeo de un ticket. .................................. 139
5.13.6. Cierre de la iteración 12 .................................................. 139
6. Manual y funcionalidad de la aplicación ..................................... 140
7. Conclusiones finales del proyecto y planes futuros .................... 155
Referencias .......................................................................................... 158
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
13
Escuela Politécnica Superior de Jaén
Agradecimientos
En primer lugar quiero dar las gracias a toda mi familia, que me ha
apoyado en el transcurso, no solo de la carrera, si no de mi vida en general y
que sin su ayuda y apoyo no me cabe la menor duda de que no habría sido capaz
de conseguir todo lo que he conseguido en lo personal y profesional.
A todos y cada uno docentes de la Universidad de Jaén, que me han
ayudado a lo largo de todo este camino y de los cuales me quedo una pequeña
parte para mí y para siempre.
De estos docentes quiero hacer una mención especial a D. José Ramón
Balsas Almagro, el cual me ha recibido siempre dispuesto a ayudarme en todo
lo que fuese posible, incluso alargando sus tutorías y fuera de horario laboral con
tal de ayudarme a resolver mis problemas. También a D. Antonio Jesús Rueda
Ruiz porque a pesar de su exigencia, haces que saques lo mejor de ti mismo y
demuestres de lo que eres capaz
Dar gracias a mi tutor D. Manuel Carlos Díaz Galiano, a pesar de no
haber sido profesor mío durante el grado, por el apoyo y la confianza para llevar
a cabo este proyecto y por su predisposición y ayuda durante el mismo.
A todos mis compañeros que me han echado una mano cuando más falta
hacía y sin los cuales no hubiese sido posible superar tantos obstáculos. Como
Daniel Muñoz Gallardo el cual me ha ayudado enormemente en la elaboración
de este documento, sobre todo con la organización del mismo
A todos esos compañeros, que además se han convertido en amigos para
toda la vida que me han aportado su apoyo, no solo en lo académico, sino en
ámbito personal del día a día y con los que espero mantener el contacto siempre.
Todo final no es solo un final. También es un comienzo de una etapa de
la que espero que todos sigáis formando parte.
MUCHAS GRACIAS A TODOS.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
15
Escuela Politécnica Superior de Jaén
1. Introducción
En este documento se va a redactar el proceso de realización de mi trabajo
fin de grado, como culmen a los años que llevo estudiando el grado en ingeniería
informática.
He decidido realizar este proyecto gracias a que la propuesta llevada a
cabo por mi tutor D. Manuel Carlos Díaz Galiano, me llamó muchísimo la
atención desde el principio debido a que se trataba de un prototipo de un
proyecto que realmente puede ser funcional, y el cual podría ser utilizado por
una institución, en este caso la Universidad de Jaén, aunque también podría
ser útil en otras.
Mi principal motivación para la realización de este proyecto, además de la
ya contada funcionalidad y utilidad que tiene, tanto en el ámbito educativo como
en otros aspectos, es que para llevarlo a cabo sabía que podría utilizar
herramientas que ya conocía, y que el proyecto me permitiría profundizar mucho
más e incidir en estas tecnologías, lo que me da la oportunidad de, además de
empezar el proyecto con algo conocido, poder aprender mucho más y adquirir
nuevos conocimientos.
El tipo de tecnologías que se utilizan en este proyecto son tecnologías
relacionadas con la web, debido a que desde que comencé a estudiarlas en el
grado, me sorprendió muchísimo la potencia que estas tecnologías tienen y con
la posibilidad de ser utilizadas en una multitud de plataformas. Las asignaturas
del grado que me han proporcionado los conocimientos para poder llevar a cabo
esto han sido Desarrollo de aplicaciones web con el profesor D. José Ramón
Balsas Almagro y la asignatura de Desarrollo de aplicaciones empresariales
con el profesor D. Antonio Jesús Rueda Ruiz.
El proyecto aborda el tema de la Gamificación, cuyo objetivo es motivar e
introducir a los usuarios que la utilizan a lograr unos objetivos previamente
establecidos para una actividad (asignaturas, cursos, juegos…) para lo que se
usan técnicas y dinámicas de juego, en este caso relacionadas con las nuevas
tecnologías.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
16
Escuela Politécnica Superior de Jaén
El reto que afrontamos en este proyecto, es el de aunar todos estos
conceptos en una única plataforma en la que se gestionen los objetivos a cumplir,
los usuarios que quieren cumplir dichos objetivos, y las técnicas relacionadas
con las nuevas tecnologías que nos permitirán cumplir dichos objetivos.
2. Gamificación
La Gamificación [3] es un concepto que se puede definir de muchas formas,
aunque de forma muy genérica se podría definir así:
“La Gamificación es el uso de mecánicas y técnicas de juego en entornos
que son ajenos al juego” (Sebastian Deterding).
Es un término que hoy en día tiene una gran popularidad en entornos
digitales, debido a que las nuevas tecnologías nos dan la oportunidad de
desarrollar herramientas relacionadas con este tipo de técnicas innovadores que
incentivan al alumnado a participar en el cumplimiento de los objetivos
establecidos, y como consecuencia de ello hacen que puedan aprender de una
forma divertida y diferente a la tradicional.
Con este tipo de plataformas podemos aprovechar el continuo deseo de los
usuarios que las utilizan, como puede ser el de obtener recompensas por un
logro, incluso el de una posición de estatus dentro de un ámbito o un grupo social,
lo que hace que los docentes puedan aprovechar el lado bueno de la
competitividad que un usuario puede tener, para lograr que cumpla unos
objetivos, y que a la vez logre el verdadero objetivo de todo esto que es el de
aprender y adquirir conocimientos.
Para llevar a cabo todo esto, será necesario implantar una plataforma en la
que se muestren premios, puntuaciones para los alumnos, e incluso rankings
para reflejar ese “juego” que nos ayudará a la evaluación del alumno.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
17
Escuela Politécnica Superior de Jaén
2.1. Plataformas de Gamificación actuales
En este apartado vamos a detallar algunas de las plataformas actuales.
2.1.1. Plataforma de Gamificación desarrollada por la UJA
Esta idea no ha sido fruto de un día que se pensó y decidieron establecer
como una propuesta de Trabajo Fin de Grado sin más, sino que era una idea
madurada desde hace un tiempo llevada a cabo por el tutor de este trabajo entre
otras personas. Esto supuso que se llevara a cabo la especificación e
implementación de una aplicación prototipo de una plataforma con una idea muy
similar a la que se describirá en este documento. Se trata de una pequeña
aplicación con una técnica de trabajo similar a la que hemos realizado ahora,
pero con mucho menos contenido y complejidad, y como es lógico, realizada con
menos tiempo, aunque nos servirá como introducción a lo que nosotros
queremos llevar a cabo y también para comparar y observar las diferencias entre
las plataformas cuando posteriormente se exponga la nueva. Comenzamos.
2.1.1.1. Funcionamiento de la plataforma: Administrador
Ilustración 1: Imagen de plataforma de Gamificación actual en la UJA
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
18
Escuela Politécnica Superior de Jaén
Esta es la que sería la página principal de la plataforma actual de la que he
hablado anteriormente (Ilustración 1).
Esta plataforma, lo que principalmente es seguía que los alumnos
participaran para cumplir unos objetivos y el método que se utiliza en este caso,
es el de otorgar premios. La plataforma permite que el profesor pueda crear
una lista con códigos QR (que también será un elemento importante en la
aplicación desarrollada para este TFG) y que posteriormente entregará a los
alumnos para que ellos los escaneen con su teléfono móvil y esto quede
registrado en la plataforma, lo que permitirá al usuario acumularlos y obtener
esos premios mencionados anteriormente
Ilustración 1.1: Vista de las listas de tickets
En la imagen anterior (Ilustración 1.1) podemos ver, como el administrador
del sistema puede crear tandas con un número de tickets en cada tanda. Estos
tickets son generados automáticamente en el sistema. Una vez el administrador
tiene una lista de tickets, podrá imprimirlos y repartirlos a los alumnos para
escanearlos y contabilizarlos en el ranking y otorgarle los premios de los cuales
les hemos hablado antes. A continuación se ilustra dicho proceso de escaneo de
un ticket para mostrar lo que tiene que llevar a cabo un usuario que utilice la
aplicación, debido a que las capturas mostradas anteriormente son de la parte
de administración.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
19
Escuela Politécnica Superior de Jaén
2.1.1.2. Funcionamiento en la parte del usuario
Ilustración 1.2: Ticket de la actual plataforma
Este sería lo que el profesor le daría al alumno como recompensa a algo
realizado por el mismo en su asignatura.
Ilustración 1.3: Página de canjeo Ilustración 1.4: Página de canjeo
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
20
Escuela Politécnica Superior de Jaén
Ilustración 1.5. Confirmación de canjeo Ilustración 1.6: Listado de canjeos
En las imágenes anteriores ilustramos el que sería el proceso se canjeo de
un ticket en la plataforma actual.
En primer lugar, el usuario escanea el código QR. Este contiene la URL a
la que te tienes que dirigir para llevar a cabo el canjeo del ticket, como se puede
ver en la Ilustración 1.3, esa sería la URL de destino para canjear el ticket
En segundo lugar tienes que introducir el identificador (nombre, id de la uja,
DNI, etc) para registrarlo en la plataforma, acompañado de un captcha que el
usuario tiene que introducir. Esto se puede ver en la Ilustración 1.4
En la Ilustración 1.5 podemos ver lo que resulta de llevar a cabo el canjeo
del ticket, informando de su correcto canjeo.
Como también se puede observar en la Ilustración 1.5, arriba a la derecha
nos encontramos con el símbolo que nos permite acceder al listado de las
personas que han canjeado el ticket.
Ese listado lo podemos ver en la Ilustración 1.6 donde vemos que el
usuario manolo tiene doce tickets y al lado tiene 4 estrellas. Esas estrellas serían
los premios que manolo tiene, puesto que como hemos visto en la Ilustración 1,
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
21
Escuela Politécnica Superior de Jaén
el número de tickets para conseguir un premio es de 3 tickets, lo que hace que
si tiene 12 tickets , hagan un total de 12/3 = 4 premios.
2.1.1.3. Inconvenientes y problemas de esta plataforma
Como hemos podido ver, la plataforma es una plataforma sencilla aborda
el tema de la Gamificación de la forma de la que queremos hacer en nuestro
proyecto, pero si se analiza detenidamente, es una plataforma que tiene
bastantes carencias que queremos solucionar, o al menos, si no todas, algunas
de ellas con la realización de nuestro proyecto haciendo que tanto para el
administrador del sistema como para los usuarios, sea más atractiva y fácil de
utilizar.
Aunque como se puede observar, se trata de una aplicación bastante
usable e intuitiva, hay muchos aspectos que faltan y a continuación exponemos
algunas de las “pegas” o carencias que se le pueden sacar a esta plataforma.
1. En primer lugar, como hemos visto en todas las imágenes, la
asignatura para la que está este sistema definido es para una
llamada Prácticas INFORMÁTICA: Grado en Ing. Industrial. Lo
único que podemos cambiar de esto es el nombre.
¿Qué quiere esto decir? Pues muy sencillo, es decir, no podemos
añadir diferentes asignaturas ni nada por el estilo. La aplicación es
solo para una asignatura o actividad, lo que hace que esté muy
limitada. Entonces se preguntará,
“¿Y si quiero tener más de una asignatura u otra actividad cómo
podría ser un curso de verano, que tengo que hacer?”
En tal caso, se necesita desplegar la aplicación en un servidor tantas
veces como asignaturas tengamos, lo que hace que haya una
aplicación desplegada por cada asignatura y es un gran
inconveniente si se decide usar mucho.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
22
Escuela Politécnica Superior de Jaén
2. Otro de los grandes problemas de esta plataforma es la gestión de
los usuarios que la utilizan, aunque más que “problema en la gestión
de usuarios” es “ausencia de gestión de usuarios”, lo que hace que
llevar a cabo el seguimiento por parte de los profesores sea más
complicado y también la utilización de la plataforma para los alumnos
sea también más tediosa y propensa a errores humanos. Decimos
esto porque al no haber gestión de usuarios, cuando se canjea un
ticket se necesita saber quién ha llevado a cabo dicho canjeo. Como
podemos ver en la Ilustración 1.3 e Ilustración 1.4 es necesario
que cada vez que se va a escanear un ticket, el usuario que lo hace
introduzca su identificador de forma manual, y esto nos puede dar
muchos problemas:
a. Que el usuario se equivoque al escribirlo, ya sea porque le
haya faltado alguna letra, o simplemente ponga la primera con
mayúscula cuando la vez anterior lo hizo con minúscula y no
se le sume a su contador personal. Lo podemos ver en la
siguiente imagen (Ilustración 1.7).
Ilustración 1.7.Listado de canjeos
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
23
Escuela Politécnica Superior de Jaén
Como se puede ver en la Ilustración 1.7 si escaneas un ticket
escribiendo “Manolo” y otro escribiendo “manolo” son
totalmente distintos para el sistema, y esta acción es
totalmente irreversible a no ser que se manipule la base de
datos de forma manual.
b. Otro gran problema es que cuando el usuario vaya a escanear
el ticket, no recuerde cual es el identificador que puso (DNI,
correo, nombre…) y en pleno proceso de canjeo tenga que ir
al listado para ver cuál es. Las posibilidades de que esto
suceda se incrementan si estás utilizando el sistema para
más de una actividad y en cada una utilizas un identificador
diferente.
3. Otro de los grandes problemas que presenta la aplicación es el no
gestionar de forma personalizada diversos objetivos dentro de una
misma asignatura o actividad. Para entender mejor el por qué esto
es un problema, vamos a exponer un supuesto:
Imagine que es docente de una asignatura en la universidad, pero
sólo es docente de una parte, por ejemplo la teoría. En la asignatura
también hay otro docente que imparte las prácticas, sin embargo ambos
quieren utilizar la plataforma de gamificación y tener de forma
personalizada la información de los tickets que se le dan a un alumno en
un objetivo en particular (Asistencia a prácticas, asistencia en teoría…).
¿Sería posible con esta plataforma?
La respuesta es NO. Al menos no sin llevar a cabo lo que hemos
comentado antes de desplegar la aplicación dos veces, una para cada
objetivo, lo que además de suponer un problema para el profesor, también
lo supone para el alumno puesto que no puede llevar a cabo un
seguimiento desde un solo lugar y de forma sencilla.
Como apunte final a este apartado, destacar que exponemos estos
problemas para obtener una comparativa con la nueva plataforma.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
24
Escuela Politécnica Superior de Jaén
2.1.2. Otras plataformas de gamificación actuales
Actualmente existen multitud de plataformas [4] que están orientadas a que
las personas y que las utilizan aprendan algún tema concreto, sin embargo, no
encontramos una plataforma del estilo a la que hemos diseñado, es decir, una
plataforma que sirva para establecer unos objetivos de manera personalizada
por un profesor y evaluable por el mismo, independientemente del tema tratado.
La mayoría de las plataformas como dicho, se centran en una disciplina en
concreto como pueden ser las matemáticas, anatomía, etc. A continuación
ponemos algunos ejemplos por si quiere obtener más información.
1. Knowre: Plataforma de gamificación que incluye retos sobre álgebra y
geometría, y que busca ser un accesorio para la clase más formativa y
tradicional. Primero la explicación del profesor y luego a jugar para
afianzar los conocimientos. Se trata de una plataforma online disponible
a través de web y para dispositivos iPad.
2. Kahoot: Herramienta que permite crear juegos de preguntas y respuestas
de forma muy intuitiva. Podrás crear tus propios quizs o unirte a alguno
de los muchos ya creados, y disponibles para múltiples edades y niveles.
Rankings, aprendizaje.
3. CodeCombat: Un videojuego para aprender a programar en el que
tendremos que ir resolviendo ciertos retos y problemas a través de código
para ir avanzando y mejorar nuestro nivel y equipamiento. Cada vez serán
planteamientos más complicados, que conllevan un mayor aprendizaje.
4. ClassDojo: Combina una parte de gamificación y recursos para ello junto
con una importante plataforma para informar a los padres del avance de
sus hijos, a la vez que nosotros, los profesores, llevamos un registro de la
evolución de cada uno de ellos.
5. ClassCraft: Es, posiblemente, lo más cercano a un
videojuego. Classcraft es una especie de ‘World of Warcraft’ para
educación con una enorme carga de gamificación, una plataforma
tremendamente visual y atractiva que permite crear un mundo de
personajes (magos, sanadores y guerreros) que deberán cooperar y
participar en misiones para ir ganando puntos y oro con el que
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
25
Escuela Politécnica Superior de Jaén
mejorar su equipo. El objetivo, ir avanzando de forma colaborativa a la vez
que aprenden y desarrollan su conocimiento
Estos son solo algunos ejemplos de plataformas de gamificación que hay
disponibles. Si quiere obtener más información acerca de ellas, acceda a los
enlaces establecidos para las mismas. No se han desarrollado en exceso debido
a que el principal objetivo de este punto era explicar y describir la plataforma
actual relacionada con la institución que nos interesa, en este caso la
Universidad de Jaén.
3. Fase inicial de análisis del problema
En este apartado, llevaremos a cabo un análisis de lo que queremos llevar
a cabo en la que habrá una reunión inicial de captación de objetivos con el tutor
del proyecto. En esta reunión inicial se establecerá que es lo que queremos llevar
a cabo para situarnos un poco y tener con qué empezar a trabajar cuanto antes.
A continuación detallamos lo hablado en dicha reunión.
En primer lugar hemos tenido muy claro que queremos mejorar la
plataforma anterior, y por tanto cubrir las deficiencias que sean posibles de la
que mencionamos anteriormente. Es por ello que hemos establecido que un
usuario podrá acceder a la plataforma iniciando sesión con un usuario o
username y una contraseña o password. Por supuesto, antes de llevar a cabo
dicho inicio de sesión, el usuario deberá registrarse en la plataforma mediante
un formulario de registro, en el que el usuario tendrá que proporcionar un
username, un password y un correo electrónico. El sistema comprobará si el
usuario introducido está ya en el sistema, y se en tal caso se lo comunicará al
usuario que deberá de introducir otro.
Una vez dentro de la plataforma, el usuario tendrá una página inicial en la
que le aparecerán los elementos a los que tiene acceso y que dependerán del
rol (papel que un usuario desempeña en dentro de un sistema) o roles que el
usuario tiene y de lo cual hablaremos un poco más adelante. También habrá una
parte de la interfaz que le permita acceder a los datos se su perfil y le permita
modificarlos y también cambiar la contraseña si lo desea.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
26
Escuela Politécnica Superior de Jaén
Nuestra plataforma será capaz de gestionar asignaturas, o como nosotros
las hemos llamado, ACTIVIDADES, puesto que no queremos limitar su posible
uso a la universidad y este es un nombre más genérico que podríamos utilizar
en otros aspectos como en cursos de verano, empresas privadas que quieran
compensar a sus empleados, etc… Estas actividades podrán ser creadas,
modificadas, y eliminadas del sistema por quienes tengan permiso para ello.
Cuando llevamos a cabo la explicación de la plataforma actual,
comentamos un supuesto en el que mencionábamos que si quisiéramos
gestionar más de un objetivo diferente dentro de una misma asignatura o
actividad (Ej: Asistencia y participación), no sería posible hacerlo de manera
personalizada. Es por eso, que está nueva plataforma sea capaz de gestionar
OBJETIVOS dentro de cada actividad, creando tantos como queramos y siendo
independientes los unos de los otros. Al igual que en las actividades, los objetivos
podrán ser creados, modificados y eliminados por quienes tengan permiso para
ello. Por supuesto al igual que las actividades, también podrán ser modificados
y eliminados.
Dentro de cada uno de los objetivos, se podrán crear TANDAS DE
TICKETS, siendo un ticket un código QR único para ser utilizado posteriormente.
Para crear estas tandas de tickets, será necesario proporcionar algunos datos
como: número de tickets que se desean crear, las veces que un ticket puede
canjearse, y la fecha en hasta la que el ticket se puede canjear. Como vemos,
aquí resolveríamos más carencias del sistema actual, puesto que los tickets de
este solo se pueden canjear una sola vez, mientras que ahora es el que crear la
tanda de tickets quien lo decide. Otro de los problemas que solucionamos es el
de la fecha de caducidad de los tickets, puesto que la plataforma anterior no te
daba esa opción.
Con esto, logramos que los objetivos de cada actividad no dependan los
unos de los otros pero como detallaremos a continuación, podremos unirlos si
queremos.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
27
Escuela Politécnica Superior de Jaén
Otro de los elementos vitales de la gamificación es que los usuarios puedan
seguir de alguna forma su progreso en la plataforma, es por eso que hemos
decidido que para llevar a cabo ese seguimiento, se establecerá un ranking o
rankings, con los que podamos realizar esto. En primer lugar tendremos un
ranking para cada objetivo donde los usuarios podrán ver la posición que
ocupan dentro del ranking y el número de tickets que han canjeado. En segundo
lugar tendremos un ranking similar pero esta vez a nivel de actividad, donde
se contabilizarán todos los tickets en todos los objetivos de la asignatura o
actividad. Esta es nuestra forma de unir la evaluación de todos los objetivos.
Como ya hemos mencionado, tendremos más de un rol en el sistema.
Definiremos 3 roles totalmente independientes y que los usuarios podrán tener
sin que unos interfieran con los otros. A continuación definimos dichos roles, y
explicamos con más detalle.
3.1. Roles en el sistema
En el sistema distinguiremos 3 roles diferentes, y como hemos dicho, son
independientes y no excluyentes, por lo que un usuario puede tenerlos todos,
algunos o ninguno.
3.1.1. Rol admin
El rol admin o administrador es el rol que representa al administrador del
sistema. Este administrador es el usuario que más permisos tiene en el sistema
y prácticamente tendrá un poder ilimitado sobre el resto de elementos del mismo.
El usuario que posea este rol podrá acceder a todos los usuarios que se
encuentren en el sistema. Tendrá la capacidad de crear nuevos usuarios,
eliminarlos, modificarlos e incluso cambiar su contraseña si lo desea. El usuario
administrador es el encargado asignar los roles que quiera al resto de usuarios,
ya que estos cuando se registran se crean con un rol por defecto, pero es el
administrador el que decide si le otorga un rol superior. El usuario con este rol,
además de a todos los usuarios del sistema, también tendrá acceso a todas las
actividades creadas en el sistema y tiene permisos para alterarlas o eliminarlas
si es necesario. Por supuesto al poder hacer esto con las actividades,
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
28
Escuela Politécnica Superior de Jaén
evidentemente también puede llevar a cabo esto con los objetivos de las
actividades y sus tandas de tickets.
3.1.2. Rol profesor
El rol profesor o teacher es un rol más limitado que el del administrador
del sistema, aunque también puede llevar a cabo muchas tareas. Un usuario con
el rol de profesor, será capaz de crear actividades en el sistema y gestionarlas
como hemos dicho antes (editarlas, eliminarlas, crear y editar objetivos y tandas
de tickets, etc…). También podrá añadir a otros profesores a las actividades que
él cree en el sistema, y este tendrá los mismos permisos que él. Lo que le
diferencia del administrador, es que a diferencia de este, un profesor solo tiene
acceso a las actividades que el mismo ha creado, o a las actividades de las que
es profesor (aunque no las haya creado). Tampoco tiene acceso al resto de
usuarios del sistema y por lo tanto no tiene ningún poder sobre ellos. Este rol
está diseñado para que pueda gestionar sus propias actividades sin interferir en
las demás, y poder seguir el progreso de sus alumnos.
3.1.3. Rol estudiante
El rol estudiante o student es el rol más débil de todo el sistema, debido
a que es el que tiene una actuación más limitada en el sistema de lo que lo tiene
un profesor o un administrador.
El rol estudiante es el rol que un usuario adquiere automáticamente cuando
se registra el sistema, aunque no podrá ver ni hacer nada a excepción de
modificar su perfil, hasta que no se encuentre como alumno de alguna actividad.
Un estudiante podrá canjear tickets, ver los rankings de las actividades en las
cuales esté matriculado, y ver los Canjeos que ha realizado.
3.2. Casos de uso de la plataforma. Requisitos funcionales.
Después del análisis inicial junto con el tutor del proyecto y una vez definida
la idea de lo que queremos hacer, en base a eso nos disponemos a establecer
los requisitos iniciales del sistema. Para establecer estos requisitos iniciales,
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
29
Escuela Politécnica Superior de Jaén
vamos a llevar a cabo un diagrama con los casos de uso necesarios para cumplir
con nuestros requisitos.
3.2.1. Diagrama de casos de uso.
Tras la realización de los casos de uso, que refleja un esbozo de lo que
podría ser nuestro sistema, el tutor del proyecto aprueba las funcionalidades
presentadas para continuar trabajando en ello.
Ilustración 2: Diagrama de casos de uso
A continuación, explicaremos los casos de uso y que es lo que queremos
hacer estableciendo cada uno de ellos.
3.2.2. Registro en el sistema
Para acceder a la aplicación, como antes hemos mencionado, el usuario
necesitará registrarse en el sistema proporcionando un nombre de usuario o
username, una contraseña o password y un correo electrónico.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
30
Escuela Politécnica Superior de Jaén
3.2.3. Acceso a la aplicación
Una vez el usuario esté registrado en el sistema, deberá proporcionar el
username y el password para acceder a la aplicación. En caso de iniciar sesión
de forma correcta, el usuario será redirigido a la página de inicio.
3.2.4. Visualizar perfil
Una vez el usuario haya iniciado sesión, podrá visualizar su perfil de usuario
en el que aparecerán todos sus datos y que podrá modificar a su gusto, incluso
la contraseña de acceso.
3.2.5. Canjear ticket
El usuario, una vez iniciada la sesión podrá llevar a cabo el canjeo de un
ticket, ya sea de forma automática, mediante un escáner de códigos QR, o de
forma manual introduciendo el código situado en el ticket manualmente.
3.2.6. Listar usuarios del sistema
El usuario, una vez iniciada la sesión, podrá listar todos los usuarios que
hay en el sistema siempre y cuando tenga permiso para ello.
3.2.7. Crear usuario
Los usuarios que ya hayan iniciado sesión y tengan permiso para ello,
tendrán la posibilidad de crear nuevos usuarios.
3.2.8. Listar actividades del sistema
Un usuario será capaz de listar una serie de actividades, estas
dependiendo del rol que el usuario tenga: si es administrador, podrá listar todas
las actividades del sistema. Si es profesor, tendrá la oportunidad de listar las
actividades de las cual es profesor. Si es estudiante, podrá listar las actividades
de las cual es estudiante. En el caso de que el usuario tenga más de un rol, se
le dará la opción del rol con el que desea llevar a cabo esta acción.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
31
Escuela Politécnica Superior de Jaén
3.2.9. Crear actividad
Un usuario será capaz de crear una nueva actividad en el sistema siempre
y cuando tenga permiso para ello.
3.2.10. Listar objetivos
Un usuario será capaz de listar los objetivos que tiene una actividad,
siempre y cuando tenga los pertinentes permisos de acceso a dicha actividad.
3.2.11. Crear objetivo
Un usuario será capaz de crear objetivos para una actividad, siempre y
cuando tenga permiso de acceso a esa actividad.
3.2.12. Ranking objetivo
Un usuario podrá visualizar el ranking de un objetivo, siempre y cuando
tenga permiso de acceso a la actividad a la cual pertenece ese objetivo.
3.2.13. Tandas tickets
Un usuario podrá visualizar las diferentes tandas de tickets de un objetivo,
siempre y cuando tenga permiso de acceso a la actividad a la que pertenece
dicho objetivo y tenga un rol que le permita realizar esta acción
3.2.14. Crear tanda
Un usuario podrá crear una nueva tanta de tickets para un determinado
objetivo, siempre y cuando tenga permiso de acceso a la actividad a la que
pertenece dicho objetivo, y tenga un rol que le permita realizar esta acción
3.2.15. Listado tickets
Un usuario podrá listar los tickets que tiene una tanda, siempre y cuando
tenga acceso a la actividad a la que pertenezca esa tanda y tenga un rol que le
permita realizar esta acción.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
32
Escuela Politécnica Superior de Jaén
3.2.16. Ver tickets
Un usuario podrá visualizar los códigos QR en una vista para poder
imprimirlos, siempre y cuando tenga acceso a la actividad a la que pertenezca
esa tanda y tenga un rol que le permita realizar esta acción.
3.2.17. Listar usuarios de actividad
Un usuario podrá listar a los distintos usuarios que están matriculados en
una actividad siempre y cuando tengan acceso a dicha actividad.
3.2.18. Canjeos
Un usuario podrá acceder a los Canjeos que ha llevado a cabo tanto en un
objetivo como en la actividad al completo siempre y cuando tenga permiso de
acceso a dicha actividad.
3.2.19. Listar profesores de la actividad
Un usuario podrá listar a los profesores que pertenecen a una actividad,
siempre y cuando tengan acceso a dicha actividad.
3.3. Requisitos no funcionales de la aplicación
En toda aplicación es necesario establecer un mínimo de requisitos no
funcionales también llamados de calidad. Los requisitos no funcionales son
aquellos que representan características generales y restricciones de una
aplicación aunque son más complicados de evaluar puesto que la conformidad
o no conformidad con dicho requisito es de libre interpretación. A continuación
presentamos una lista con los requisitos no funcionales que en principio requiere
nuestra aplicación.
Interfaz usable e intuitiva que no requiera un alto nivel de
conocimiento de la plataforma para que un usuario pueda utilizarla
sin mayores dificultades.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
33
Escuela Politécnica Superior de Jaén
Comunicación de forma segura entre cliente y servidor, es decir,
que la información no se transmita en texto plato, sino mediante
un protocolo que encripte la información.
Las contraseñas de los usuarios que se almacenen en la base de
datos, no debe estar en texto plano, por lo que debemos realizar
algún tipo de encriptación de las contraseñas
NOTA: Estos requisitos podrán ampliarse y se ira informando de ello
durante el proceso.
3.4. Tecnologías para el desarrollo de la plataforma. Análisis
técnico del proyecto.
En este apartado vamos a llevar un aspecto que es muy importante antes
de desarrollar un proyecto. Una vez hemos establecido los requisitos en los
apartados anteriores, vamos a llevar a cabo un análisis del aspecto más técnico
del proyecto y elegir las tecnologías existentes que creemos que mejor se
pueden adaptar a las características de nuestro proyecto teniendo en cuenta que
necesitamos un back-end y un front-end para nuestra aplicación y teniendo en
cuenta la enorme variedad de tecnologías que existen en el mundo del desarrollo
web, intentaremos elegir correctamente
En transcurso de mi experiencia en el grado en Ingeniería informática, el
desarrollo web que he llevado a cabo siempre ha estado orientado al lenguaje
de programación Java. En este proceso de aprendizaje, he tenido la oportunidad
de conocer algunas tecnologías que se pueden adaptar perfectamente a lo que
se necesita llevar a cabo en este proyecto
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
34
Escuela Politécnica Superior de Jaén
3.4.1. Spring Framework vs Java EE
Ilustración 3: Logotipo Spring Framework
Spring Framework [2][5] es un framework para el desarrollo de
aplicaciones y contenedor de inversión del control (también conocido como
contenedor IoC), de código abierto para la plataforma java. La primera versión
fue escrita por Rod Johnson, quien lo lanzó junto a la publicación de su
libro Expert One-on-One J2EE Design and Development aunque esto fue de
forma teórica. La versión 1.0 del framework vio la luz en 2004. Ganó popularidad
a finales de 2004 y principios de 2005. Surgió como una alternativa a otras
conocidas plataformas de desarrollo web como por ejemplo Java Enterprise
Edition (J2EE) [2].
Ilustración 4: Logotipo Java Enterprise Edition
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
35
Escuela Politécnica Superior de Jaén
Java Entreprise Edition se trata de un framework de desarrollo basado en
el lenguaje Java, que aparece en 2001 para el desarrollo de aplicaciones
empresariales distribuidas. Se trataba de un framework con una elevada
complejidad, lo que acarreó múltiples críticas. Esto hizo que Rod Johnson
propusiera un framework más ligero en su libro anteriormente comentado.
Tras la salida de Spring Framework, y debido a su alta aceptación, en 2006
aparece Java EE 5 rediseñado completamente, siguiendo los principios de
Spring Framework
Además, hay que incidir en que Java Enterprise Edition, además de ser un
framework muy complejo, incorpora muchísimas funcionalidades que la mayoría
de aplicaciones no utilizan como por ejemplo el funcionamiento distribuido
Otro de los inconvenientes de J2EE es que se implementan mediante los
llamados Enterprise JavaBeans, que requieren la implementación de varias
interfaces complejas y un servidor de aplicaciones.
Spring Framework se trata de uno muy bien construido con un gran
soporte desde que se creó, diseñado para el desarrollo de aplicaciones
empresariales que tengan una importante carga de usuarios. Esto hace que
como framework de desarrollo para la parte de nuestro servidor, sea más que
adecuado. El framework es muy amplio y abarca muchas partes, y en este caso
la que nos interesa a nosotros es la parte de de implementación de aplicaciones
web. Para ello Spring framework posee una especificación muy completa y muy
potente, llamada Spring MVC, que además es muy utilizada por las empresas
para la llevar a cabo grandes proyectos.
Spring Framework utiliza para la creación de objetos de negocio los Plain
Old Java Objects (POJOs), es decir clases de objetos sencillas sin
implementación de interfaces.
A la hora de llevar a cabo nuestra lógica de negocio, encontramos que
Spring Framework, al ser un framework muy modular, a diferencia de J2EE como
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
36
Escuela Politécnica Superior de Jaén
hemos comentado antes ya que cabe destacar puesto que solo incorporas a tu
proyecto aquellos módulos que se necesiten.
Creo que ha quedado bastante claro, pero recalcamos que el framework
que utilizaremos será Spring framework.
3.4.2. Capa de lógica negocio
Como ya hemos dicho antes, para la implementación de estos objetos de
negocio, J2EE utiliza los Enterprise JavaBeans que implementa interfaces
complejas para su desarrollo, frente a los objetos planos y sencillos (POJOs)
que necesita Spring Framework, lo que en este aspecto, le hace mejor y gana
enteros, aunque estos POJOs hay que implementarlos al completo. Aun así,
compensa la facilidad y ligereza de Spring para lo que nosotros queremos llevar
a cabo.
J2EE ha mejorado mucho en sus últimas versiones pero a pesar de ello,
Spring Framework sigue siendo mejor para el problema que queremos
desarrollar teniendo en cuenta todos estos puntos y los mencionados en el
apartado anterior.
3.4.3. Capa de persistencia de datos
En este apartado, explicaremos cual es el sistema de gestión de base de
datos que vamos a utilizar para el desarrollo de nuestro proyecto además del uso
de las tecnologías ORM (Mapeo Objeto-Relacional) que nos permitirá guardar
la información que utilice nuestra aplicación de forma segura y permanente y
será la que se comunique con la capa de lógica de negocio para llevar cabo este
intercambio de información.
Para llevar a cabo esta persistencia, hemos decidido utilizar un sistema de
gestión de bases de datos, que en nuestro caso es Apache Derby.
Apache Derby [21] es un sistema gestor de bases de datos
relacional escrito en Java que puede ser empotrado en aplicaciones Java y
utilizado para procesos de transacciones online. Se trata de un SGBD que se
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
37
Escuela Politécnica Superior de Jaén
acopla perfectamente a un proyecto java como el nuestro, y al trabajar Spring
MVC, simplemente cambiando algunos detalles en la configuración, podríamos
migrar el proyecto a otro SGBD si fuese necesario o tuviésemos otras
preferencias.
Considero que es un SGBD adecuado debido a que tiene las siguientes
características:
API para JDBC y SQL. Soporta todas las características de SQL92
y la mayoría de SQL99.
Soporta cifrado completo, roles y permisos. Además posee SQL
SCHEMAS para separar la información en una única base de datos
y control complejo de usuarios.
Soporta internamente procedimientos almacenados, cifrado y
compresión.
Trae soporte multilenguaje y localizaciones específicas.
Transacciones y recuperación ante errores ACID.
Ilustración 5: Logotipo Apache Derby
Una vez explicada la base de datos que vamos a utilizar para el desarrollo
del proyecto, vamos a explicar cómo vamos a crear la base de datos para nuestro
proyecto, debido a que no lo vamos a hacer de un modo normal, es decir, lo
que se suele hacer en estos casos en un proyecto es crear un diagrama E/R
(Entidad-Relación) acorde a las clases de nuestro modelo que necesitamos
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
38
Escuela Politécnica Superior de Jaén
persistir y una vez tuviésemos nuestro esquema y nuestra base de datos creada,
accederíamos a dichos datos mediante JDBC, pero como hemos dicho, vamos
a hacerlo de una manera muy diferente, y que en mi opinión, es mucho más
sencilla y fácil. Ya veremos el por qué.
Como mencionamos al principio, vamos a llevar a cabo esto, con una
tecnología muy utilizada en la actualidad, y que va en incremento en cuando a
dicho uso, que es el uso de herramientas para un ORM (Mapeo Objeto-
Relacional). Se trata de Hibernate, que soporta Spring Framework y cuyo uso
nos facilitará mucho la vida, mediante la API JPA (Java Persistence API).
Ilustración 6: Logotipo Hibernate JPA
3.4.4. Capa de presentación
En este apartado hablaremos de la tecnología que vamos a utilizar para
llevar a cabo la capa de presentación de nuestra aplicación. Cuando hablamos
de capa de presentación nos referimos a esa parte de la aplicación, donde el
usuario interactúa con el sistema para un intercambio de información, es decir,
que esta capa representará la interfaz de usuario de nuestro sistema.
Uno de los requisitos no funcionales para nuestra aplicación es que
tengamos una interfaz sencilla e intuitiva para el usuario, de tal manera que no
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
39
Escuela Politécnica Superior de Jaén
necesite de entrenamiento previo para su utilización. En esta parte de la
aplicación es donde vamos a poder hacer esto posible.
Para llevar a cabo esto, vamos a utilizar el que probablemente sea el
framework más conocido y utilizado en este aspecto para el desarrollo web. Se
trata del framework Bootstrap, un framework que utiliza HTML, CSS y
Javascript para llevar a cabo sus implementaciones. En nuestro caso, haremos
uso de una plantilla llamada AdminLTE [11].
Bootstrap [10] es conocido por prácticamente todo el mundo que alguna
vez haya realizado algún tipo de proyecto relacionado con el desarrollo web, y
nos permitirá establecer una cantidad de elementos muy amplia en nuestras
vistas, que además cuenta con un soporte enorme y posee una de las
características que para nosotros va a ser vital como es el diseño responsive,
es decir, que los elementos se adaptan a las medidas de los dispositivos
actualmente más utilizados como son los SmartPhones y Tablets.
Ilustración 7: Logotipo Bootstap
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
40
Escuela Politécnica Superior de Jaén
3.5. Modelo de dominio.
En este apartado representaremos el modelo de dominio de nuestra
aplicación. El modelo de dominio es un esquema que representa los elementos
principales y sus relaciones de nuestro proyecto.
Ilustración 8: Modelo de dominio de la aplicación
Los elementos de nuestro modelo de dominio representan lo siguiente
acorde a la especificación inicial:
User: Son los usuarios que formarán parte de nuestro sistema.
Activity: Son las actividades de las que hablamos anteriormente.
Objective: Son los objetivos que tienen las actividades.
Batch: Son las tandas de tickets que tiene cada objetivo
Ticket: Son los tickets que tendrán las tandas
Exchange: Son los Canjeos que se pueden hacer con los tickets.
Este es nuestro modelo de dominio, cuyas relaciones parecen sencillas de
llevar a cabo, pero como veremos posteriormente, la lógica de control no será
tan fácil de llevar a cabo.
4. Metodología de trabajo y estimación inicial del proyecto.
4.1. Metodología de trabajo.
A la hora de llevar a cabo un proyecto informático, existen diversas formas
de hacerlo y en este apartado elegiremos una de ellas, explicaremos en que
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
41
Escuela Politécnica Superior de Jaén
consiste, y el por qué la elegimos para la realización de nuestro proyecto.
Teniendo en cuenta que no estoy muy acostumbrado a llevar a cabo proyectos
más grandes, esta decisión no es fácil, pero intentaremos que sea lo más
acertada posible
Por lo general, unos años atrás los proyectos informáticos se llevaban a
cabo mediante un enfoque tradicional, pero actualmente, se han desarrollado
metodologías de trabajo que cada vez son más extendidas entre las empresas
como son las metodologías ágiles. A continuación explicaremos la diferencia
entre ellas.
Cuando surgió la ingeniería de software, lo hizo para hacer frente a la
crisis del software. Surgió debido a la necesidad creciente de realizar software
de forma cada vez más profesional, complejo y a mayor escala de lo que se
estaba realizando hasta entonces, y ese software era necesario.
Debido a esto surgió el enfoque tradicional o también conocido como
modelo en cascada.
Ilustración 9: Representación del modelo en cascada o tradicional.
A priori puede parecer algo bastante lógico a la hora de desarrollar un
proyecto, sin embargo en la práctica. En un proyecto de una magnitud media-
alta, los requisitos son muy cambiantes a lo largo del proyecto, la planificación a
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
42
Escuela Politécnica Superior de Jaén
largo plazo y estimación de recursos suele ser muy imprecisa, la productividad
del equipo no se corresponde con lo que se necesita y la calidad del software
construido no suele ser la adecuada, y mencionando que exceptuando el inicio
del proyecto, la participación del cliente a lo largo del proceso es inexistente.
Todo esto hace que sea muy complicado trabajar, puesto que se trabaja
con abundante documentación que probablemente nadie lea nunca, lo que quita
capacidad de trabajo a la hora de desarrollar y testear software, y al no ser muy
tolerante al cambio de requisitos, cada vez que se lleva a cabo uno, el trabajo
hasta introducirlo a mitad de proyecto es enorme y costoso.
Tras esto, surge un cambio de paradigma en el que se intentan establecer
mejores prácticas de desarrollo de software.
Este nuevo paradigma promueve ciertos principios que harán que se
desarrolle un software de mayor calidad como:
Metodologías que se centren en la evolución del proyecto (para
modificar el software existente).
Cambios de forma incremental (añadir funcionalidad al software ya
existente).
Que promueva la Refactorización (limpiar estructura del software
sin cambiar la funcionalidad del mismo).
Colaboración con el cliente.
Respuestas ante el cambio en el desarrollo de un proyecto.
Software que funcione por encima de tanta documentación.
Como consecuencia a todo esto, surgen las metodologías ágiles, que
como hemos mencionado están cada vez más presentes en las grandes
empresas y las que no las usan es principalmente por un miedo al cambio en su
estructura de trabajo.
Debido a las muchas ventajas que tiene el llevar a cabo el desarrollo de un
proyecto software de esta forma, se ha decidido realizar este proyecto utilizando
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
43
Escuela Politécnica Superior de Jaén
una de las metodologías ágiles más utilizadas actualmente como es la
Metodología Scrum y que desarrollamos a continuación.
4.2. Metodología ágil: Scrum.
Scrum [6] es como hemos dicho una metodología ágil muy utilizada en
proyectos reales, pero nos preguntaremos el porqué de utilizarla y es lo que
vamos a explicar a continuación.
Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más
alto valor de negocio en el menor tiempo posible. Nos permite inspeccionar
rápida y repetidamente el trabajo hecho en el software (cada 2/4 semanas
aproximadamente).
Características de Scrum
Equipos de trabajo auto-organizados
El producto avanza mediante una serie de iteraciones conocidas en
Scrum como Sprints, y que tienen una duración de 2 a 4 semanas
Los requisitos son capturados como elementos de una lista que
podríamos denominar Pila del producto, o como se denomina en
Scrum, Product Backlog.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
44
Escuela Politécnica Superior de Jaén
Ciclo de trabajo de Scrum
Ilustración 10: Ciclo de trabajo metodología Scrum
En esta imagen podemos ver el que sería el ciclo de trabajo de la
metodología Scrum que detallamos a continuación.
1. En primer lugar se toman los requisitos del cliente. Para cada
requisito principal se crea un bloque de trabajo llamado Historia de
usuario. Estas historias de usuario son las que componen el
Product Backlog.
2. Ese Product Backlog se ordena según la prioridad de entrega del
cliente.
3. El equipo de trabajo toma un grupo de historias de usuario que hay
en el Product Backlog con las que forman un Spring Backlog, es
decir, serán las historias que dicho grupo utilice para llevar a cabo
un Sprint (en el transcurso de un Sprint no se producen cambios).
4. Una vez finalizado el Sprint tenemos un software que entregar al
cliente, y para seguir desarrollando del proyecto volvemos al punto
2.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
45
Escuela Politécnica Superior de Jaén
Roles y responsabilidades en Scrum
En un proyecto Scrum existen una serie de roles que los miembros del
equipo y colaboradores del proyecto deben ocupar. Esos roles son los
siguientes.
Product Owner o propietario del producto: Se trata de un
representante del cliente o el mismo cliente. Es el que define lo que
quiere en el proyecto y las prioridades del mismo. No forma parte del
equipo de desarrollo. Para hacernos una idea, este Rol sería
ocupado por el tutor del proyecto.
Scrum Master: Se trata de la persona que representa a la gestión
del proyecto. Es el responsable de promover las prácticas y valores
de Scrum. También se encarga de estrechar la cooperación entre
todos los roles y se encarga de cualquier interferencia externa.
El equipo de desarrollo: Conjunto de personas que van a
desarrollar el proyecto (programadores, probadores, analistas,
etc…)
Stakeholders: Son todos aquellos que de alguna forma aportan algo
al producto mediante su feedback, como pueden ser los usuarios
finales de la aplicación.
Reuniones en Scrum
En la metodología Scrum, podemos encontrar una serie de reuniones que
se producen en en transcurso de un proyecto.
Sprint Planning: El equipo selecciona del Product Backlog que es
lo que pueden comprometerse a completar. Aquí es donde se crea
el Sprint Backlog y se desarrolla un diseño a alto nivel.
Daily Scrum meeting: Es la reunión diaria de corta duración (15 min
aproximadamente) en la que se ponen al día con el trabajo realizado,
y con el trabajo que piensan hacer. Puede asistir cualquiera, pero
solo pueden intervenir el equipo de desarrollo, el Scrum Master y el
Product Owner.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
46
Escuela Politécnica Superior de Jaén
Sprint review: Se realiza al final del Sprint y es un poco informal,
donde puede asistir todo el mundo y por lo general sirve como una
demo de las nuevas características del producto.
Sprint retrospective: A diferencia del Spring review que es una
reunión que tiene que ver con lo realizado en el Sprint, el Sprint
retrospective o reunión de retrospectiva consiste en echar un vistazo
a lo que funciona y a lo que no, pero de todo el proyecto para ver
una situación general del mismo.
4.3. Planificación y definición de lo que vamos a desarrollar
En el apartado anterior hemos explicado en qué consistían los elementos
de la metodología Scrum para llevar a cabo un proyecto, entre ellas el Product
Backlog. Esta pila de producto será lo que necesitemos para mostrar nuestra
planificación de nuestro proyecto, pero no hemos explicado cómo se lleva a cabo
esa planificación para convertir nuestros requisitos en historias de usuario que
conformarán dicho Product Backlog. En este punto también llevaremos a cabo
un presupuesto inicial de nuestra aplicación.
Como hemos dicho antes, el Product Backlog es un contenedor en el
cual introducimos los diferentes objetivos para completar nuestro proyecto.
Conforme el proyecto vaya avanzando, este se irá reduciendo puesto que
quedarán menos historias de usuario por completar. Para introducir las historias
de usuario, necesitamos llevar a cabo lo que se conoce como una estimación
ágil, que no es más que una medida de dificultad de las historias de usuario. La
unidad de medida que se utiliza se denomina punto de historia, que no es más
que un valor numérico indicando la dificultad de la historia de usuario (a mayor
valor, mayor dificultad).
Cuando se trabaja de esta forma, puede resultar un tanto extraño, y tal
vez alguien se pregunte ¿y por qué no realizamos simplemente una estimación
en horas trabajadas? Pues es muy sencillo, puesto que hacer una estimación en
horas es imposible cuando una cada persona y cada equipo de trabajo es capaz
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
47
Escuela Politécnica Superior de Jaén
de llevar una velocidad de trabajo muy diferente, es por eso que establecemos
una unidad de medida global que sea adapte a cualquier equipo de trabajo.
Ya sabemos que tenemos que estimar las historias de usuario mediante
puntos de historia, el siguiente paso es llevar a cabo esa estimación. Existen
diversas técnicas de estimación ágil como la denominada Planning Poker, que
es un tipo de estimación en la que interviene todo el equipo, donde cada uno de
ellos dice cuál cree que es la dificultad y exponiendo los porqués, y se llega a un
consenso entre todo el equipo.
En este caso, la estimación de las historias de usuario solo va a ser la que
yo crea, debido a que soy el único miembro del equipo de desarrollo. También
hay que tener en cuenta que el proyecto tiene una fecha tope la cual no podemos
exceder, que en este caso es el último día de plazo de entrega del TFG que en
este caso sería el 6 de Septiembre de 2017, así que hay que tenerlo también
en cuenta a la hora de la estimación de las historias de usuario, además de
determinar la velocidad de trabajo más adelante.
Como hemos dicho, vamos a proceder con la estimación de las historias
de usuario conforme a los requisitos que tenemos anteriormente.
Historias de usuario (Servidor o Back-end) Puntos de
historia
Diseño e Implementación del modelo de datos 21
Diseño e implementación de la capa de persistencia de datos 13
Crear usuario 8
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
48
Escuela Politécnica Superior de Jaén
Autenticación de usuario 8
Obtener usuario 3
Editar usuario 8
Editar contraseña 8
Cambiar contraseña 5
Crear Actividad 8
Obtener Actividad 3
Editar Actividad 8
Crear Objetivo 8
Obtener Objetivo 3
Editar Objetivo 8
Crear tanda de tickets 8
Obtener tanda de tickets 3
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
49
Escuela Politécnica Superior de Jaén
Editar tanda de tickets 13
Obtener ticket 3
Canjear ticket 21
Ranking de la actividad 13
Ranking de un objetivo 13
Añadir profesor a una actividad 8
Canjeos de un usuario en una actividad 13
Canjeos de un usuario en un objetivo 13
Obtener listado actividades 8
Obtener todos los usuarios 5
Eliminar a un estudiante de una actividad 8
Eliminar a un profesor de una actividad 5
Eliminar usuario 5
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
50
Escuela Politécnica Superior de Jaén
Eliminar actividad 8
Eliminar objetivo 5
Eliminar tanda 5
Tabla 1: Tabla con historias de usuario y estimaciones del Servidor
Historias de usuario (Cliente o Front-end) Puntos de
historia
Formulario de registro 5
Formulario de inicio de sesion 5
Página de inicio 13
Página para visualizar perfil de usuario 5
Formulario de edición del perfil 5
Formulario de edición de contraseña 5
Página para visualizar usuarios 5
Página para ver detalles de usuario 5
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
51
Escuela Politécnica Superior de Jaén
Formulario de edición de usuario 8
Formulario de cambio de contraseña 3
Página para visualizar actividades 5
Formulario para editar actividades 5
Página para visualizar objetivos 5
Formulario de edición de objetivos 3
Página para listar tandas de tickets 5
Formulario de edición de tandas 8
Página para visualizar tickets con QR 13
Página para listar tickets 5
Página de detalles de un ticket 8
Página de ranking por objetivo 8
Página ranking por actividad 8
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
52
Escuela Politécnica Superior de Jaén
Página de Canjeos de un usuario 3
Página profesores de actividad 5
Página para añadir profesor a la actividad 8
Formulario de canjeo de un ticket 3
Tabla 2: Tabla con historias de usuario y estimaciones del Cliente
Como podemos ver en ambas tablas, tenemos por un lado 269 puntos
de historia pertenecientes a la parte del Front-end o Servidor, y por otro lado
tenemos 151 puntos de historia pertenecientes a la parte del Back-end o
Cliente. Esto hace un total de 420 puntos de historia para el desarrollo de
nuestro proyecto, que tenemos que realizar en varias iteraciones.
Una vez hemos estimado las historias de usuario mediante los puntos de
historia, el siguiente paso es uno de los más complicados en este aspecto,
aunque tenemos que darlo. Se trata de estimar cual es la velocidad que podemos
llevar en el desarrollo del proyecto. El tomar esta decisión es algo que da la
experiencia de trabajar con proyectos de este tipo. Como punto negativo,
tenemos que decir que no tengo esa experiencia con proyectos de esta magnitud
y por tanto es difícil llevar a cabo una predicción de esto. Sin embargo como
punto positivo he de decir que vamos a trabajar con tecnologías con las que ya
he trabajado antes y aunque no se pueda decir que soy un experto en su
funcionamiento, sí que puedo decir que se los pasos a afrontar para llevar a cabo
lo que queremos hacer, lo que es muy positivo.
Como antes hemos mencionado, también tenemos que tener en cuenta la
fecha de entrega del proyecto, y sabiendo que queremos entregarlo antes del 6
de Septiembre de 2017, vamos a llevar a cabo una planificación de iteraciones
de tal manera que esto pueda ser posible.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
53
Escuela Politécnica Superior de Jaén
Sopesando detenidamente todos estos aspectos como son las diferentes
historias de usuario, la dificultad de las mismas, etc, hemos estimado que
podemos llevar a cabo una velocidad de trabajo de 37 puntos de historia por
iteración, teniendo en cuenta que las iteraciones son de 2 semanas cada una.
Cada iteración como decimos será de 2 semanas, lo que hace un total de
10 días de trabajo por iteración (no contamos sábados y domingos). La
jornada laboral será de 8 horas
En total tenemos 420 puntos de historia, y creemos que vamos a ser
capaces de llevar una velocidad de 37 puntos de historia por iteración. Si
dividimos 420 entre 37, obtenemos las iteraciones que durará nuestro proyecto,
que en este caso es de 11,35 iteraciones. Esto quiere decir que estableceremos
un total de 12 iteraciones. Hemos redondeado a la alza en el número de
iteraciones, porque como hemos visto la estimación de la velocidad no es muy
exacta. Esto hace que en Scrum sea conveniente para nosotros trabajar con
cierto margen debido a que puede haber posibles retrasos en algunas
iteraciones, y si trabajamos con un margen, nos podremos cubrir las espaldas.
Para que el proyecto se pueda llevar a cabo, teniendo en cuenta que
tenemos esas 12 iteraciones, si dividimos 420 puntos de historia entre las 12
iteraciones obtenemos que como mínimo tenemos que llevar una velocidad de
35 puntos de historia por iteración para cumplir con el proyecto. Pero como
hemos dicho, es mejor tener un margen y la velocidad de 37 puntos de historia
que hemos establecido está muy bien por ahora.
Dicho esto, ya sabemos que nuestro proyecto constará de 12 iteraciones,
por tanto nuestra planificación ágil será la que veremos en la siguiente tabla.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
54
Escuela Politécnica Superior de Jaén
Iteración Fecha inicio – Fecha fin
1 30/01/2017 – 10/02/2017
2 13/02/2017 – 24/02/2017
3 27/02/2017 – 10/03/2017
4 13/03/2017 – 24/03/2017
5 27/03/2017 – 07/04/2017
6 17/04/2017 – 28/04/2017
7 01/05/2017 – 12/05/2017
8 15/05/2017 – 26/05/2017
9 29/05/2017 – 09/06/2017
10 12/06/2017 – 23/06/2017
11 26/06/2017 – 07/07/2017
12 10/07/2017 – 21/07/2017
Tabla 3: Planificación Ágil de nuestro proyecto.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
55
Escuela Politécnica Superior de Jaén
Como podemos observar, entre el fin de la iteración 5 y el principio de la
iteración 6 transcurren 10 días en lugar de 3 como ocurre con el resto de las
iteraciones, esto se debe a que hemos tomado la Semana Santa como una
semana de vacaciones.
4.4. Presupuesto y costos del proyecto
En este apartado, vamos a calcular el precio que supondría llevar a cabo
este proyecto para un potencial cliente real. Ahora que tenemos la duración del
proyecto, la jornada laboral y demás, podemos llevar a cabo esto sin ningún
problema y lo detallaremos a continuación.
En primer lugar, sabemos que el proyecto tendrá una duración total de 12
iteraciones, de dos semanas de duración cada una. También hemos
mencionado, que eso significa que cada iteración tendrá 10 días de trabajo
laborales, además cada jornada de trabajo tendrá una duración de 8 horas al
día. Teniendo en cuenta todos estos datos procedemos al cálculo de todo.
Dias por iteración
Horas de trabajo al dia
Número de iteraciones
Horas totales trabajadas
10 días 8 horas al dia 12 iteraciones 960 horas
Tabla 5: Tabla de horas de trabajo
Sueldo programador Sueldo a la hora Total
2500 € / mes 15,625 € 15.000 €
Tabla 6: Tabla de sueldos
Material informático
Precio unitario Vida del equipo
Tiempo en el Proyecto
Total
Portátil Toshiba P50-b-
10v 999 € 5 años 6 meses 99,90 €
NetBeans IDE 8.0.1
0 € - 6 meses 0 €
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
56
Escuela Politécnica Superior de Jaén
Visual Paradigm Standard Edition
0 € (liciencia estudiante)
- 6 meses 0 €
Tabla 7: Tabla de costes del material informático
Concepto Coste
Salarios 15.000 €
Material informático 99,99 €
Beneficio del 15 % 2.264,99 €
Base imponible 17.364,98 €
I.V.A. (21%) 3.646,64 €
Coste total 21.011,62 €
Tabla 8: Tabla de costes totales del proyecto.
5. Diseño e implementación del back-end y del front-end: API
REST y Cliente web Java
En este apartado vamos a llevar a cabo lo que hemos especificado la
planificación ágil en lo que respecta al back-end de nuestro proyecto. Como ya
hemos comentado anteriormente, cuando hablamos de back-end, nos estamos
refiriendo a la parte de la aplicación que lleva a cabo todos los cálculos de lógica
de negocio, almacena los datos y ofrece información al front-end para que este
pueda gestionarla y mostrarla al usuario.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
57
Escuela Politécnica Superior de Jaén
A la hora de trabajar en un back-end en Spring, tenemos que tener muy
claras cuáles son las distintas partes que lo conforman para tener todo muy bien
estructurado debido a que habrá mucho código fuente, y una buena estructura
organización nos permitirá poder mantener y actualizar nuestro código en un
futuro de forma menos dificultosa.
Posteriormente llevaremos a cabo la implementación del front-end,
utilizando los servicios ofrecidos por el back-end
Ahora vamos a explicar las distintas partes que conformarán nuestro
back-end antes de llevar a cabo las diferentes iteraciones.
5.1. Arquitectura de 4 capas
En puntos anteriores cuando explicábamos las tecnologías que íbamos a
utilizar, hablábamos de capa de persistencia, capa de lógica de negocio… Todo
esto no era fruto de la casualidad.
Ilustración 11: Capas del back-end representadas de un modo conceptual
Cuando hablábamos de ello, sabíamos las diferentes partes de las que
iba a constar nuestro proyecto, y es por ello que lo definíamos de esta forma. A
continuación lo explicamos más detalladamente.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
58
Escuela Politécnica Superior de Jaén
5.1.1. Capa de modelo de datos
Cuando hablamos de modelo de datos, estamos hablando de la capa
sobre la que se cimienta todo lo demás, es decir, el modelo de datos son los
elementos y clases básicas que forman nuestra aplicación. En nuestro caso, se
trata de las clases que podíamos ver en el modelo de dominio de nuestro
problema, o más bien podríamos decir que el modelo de dominio es una parte
del modelo de datos. Las distintas relaciones que se establecen entre todas
estas clases forman parte del modelo de datos de nuestra aplicación. En la
Ilustración 11, sería una parte de la lógica de negocio.
5.1.2. Capa de lógica de negocio
Esta capa implementa las reglas reales del negocio. Es decir, implementa
como la información es creada, procesada y almacenada mediante una serie de
objetos de negocio (capa de modelo de datos). En la Ilustración 11, sería la
capa de lógica de negocio.
5.1.3. Capa de persistencia
Es la capa que permite mantener la información que necesitemos de
forma permanente y segura. Esta es la que capa mediante la que accederemos
a la base de datos para cederle dichos datos a la capa de lógica de negocio. En
la Ilustración 11, podemos verla en la parte inferior puesto que es la capa de
más profundidad.
5.1.4. Capa de servicios
Es la capa que hace accesible a otras aplicaciones la funcionalidad de la
lógica de negocio de nuestra aplicación mediante protocolos universales y
estandarizados como puede ser HTTP. Sería como la barrera entre todo lo
externo a nuestra aplicación y la misma por así decirlo. En nuestro caso será un
controlador o controladores REST que ofrezcan servicios al exterior para poder
utilizarlos desde cualquier otra aplicación.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
59
Escuela Politécnica Superior de Jaén
5.2. Iteración 1
5.2.1. Análisis
En esta iteración vamos a llevar a cabo las primeras historias de usuario
teniendo en cuenta que hemos planificado una velocidad aproximada de 37
puntos de historia por iteración, así que serán esos puntos de historia los que
intentemos completar en esta iteración. Serían los siguientes.
Diseño e implementación del modelo de datos (21 p.h.)
Diseño e implementación de la capa de persistencia (13 p.h.)
Crear usuario (8 p.h.)
Como vemos, las historias se usuario que hemos introducido en esta
iteración superan los 37 puntos de historia, de hecho suman 42 puntos de
historia. No hay que alarmarse, para cumplir con la planificación tenemos que
realizar las 2 primeras historias de usuario (34 puntos de historia), y una parte
de la tercera. El resto de la tercera historia será realizada en la siguiente
iteración.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
60
Escuela Politécnica Superior de Jaén
5.2.2. Diagrama de clases: capa de persistencia y capa de lógica de
negocio.
Ilustración 12: Diagrama de clases de diseño de nuestro proyecto
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
61
Escuela Politécnica Superior de Jaén
En el diagrama de clases de diseño que hemos llevado a cabo podemos
ver perfectamente lo que serían las 4 capas en nuestra aplicación.
En la parte inferior tendríamos nuestro modelo de datos con las diferentes
clases que vimos por encima cuando ilustramos el modelo de dominio. A
continuación vamos a ilustrar las relaciones entre cada uno de los elementos del
modelo.
En primer lugar podemos observar que entre la clase User y la
clase Activity existen 2 relaciones que son independientes. Esto
es porque por un lado queremos gestionar a los alumnos o como
los hemos llamado nosotros, users que forman parte de una
actividad. En segundo lugar, queremos gestionar los profesores de
dichas actividades.
Después vemos que existe una relación de composición entre
Activity y Objective con cardinalidad de 1 a muchos. Esto se debe
a que como especificamos desde un inicio, en una actividad pueda
haber varios objetivos, pero un objetivo solo pertenece a una sola
actividad.
También podemos ver una relación de composición entre
Objective y Batch. Esto lo hacemos para que dentro de cada
objetivo podamos crear varias tandas de tickets, pero una tanda de
tickets solo pertenece a un objetivo concreto, de ahí la cardinalidad
de 1 a muchos.
También observamos que existe una relación de composición entre
Batch y Ticket. Como es lógico hacemos esto para que una tanda
de tickets pueda contener muchos tickets
Tenemos además una asociación entre Ticket y Exchange puesto
que un canjeo estará asociado a un ticket. Al igual que tenemos
una composición entre User y Exchange debido a que un usuario
tiene muchos Canjeos.
Encima tendríamos la capa de persistencia de datos. En la práctica son
una serie de clases hacen que comunican la lógica de negocio con la base de
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
62
Escuela Politécnica Superior de Jaén
datos para extraer información de la base de datos y guardarla en la misma
cuando lo necesitemos. Implementa el acceso a base de datos mediante la
sintaxis de la API JPA de Hibernate [8] de la que ya hablamos.
Encima de esta tendríamos la mencionada capa de lógica de negocio. Es
la que contendrá todas las reglas lógicas que necesitaremos para que los datos
de nuestra aplicación y la base de datos tengan una forma y coherencia. En el
caso de nuestra aplicación se trata de una clase encargada de llevar la ejecución
y cumplimiento de dichas reglas.
Y en la parte superior de nuestro diagrama, tenemos lo que sería nuestra
capa de servicios, que se encarga de ofrecer información al exterior y recibirla
para poder mandarla a la capa de lógica de negocio. En nuestro caso está
formada por 5 controladores REST los cuales desarrollan su función.
En primer lugar tenemos ResourceCentralController. Se trata de
un controlador al que puede acceder cualquier usuario que esté
registrado en el sistema y tenga establecido alguno de los roles de
los que hablamos con anterioridad (Administrador, profesor o
estudiante). Su función es recibir la petición de los elementos que
son iguales para todos los roles, como por ejemplo los datos de
perfil de usuario, el servicio para editar su contraseña, etc.
En segundo lugar tenemos ResourceCentralControllerAll. Se
trata de un controlador al que puede acceder cualquiera, esté en el
sistema o no. Su función es poder registrar usuarios en el sistema
principalmente.
En tercer lugar tenemos ResourceCentralControllerAdmin. Este
es un controlador al que solo tienen acceso los usuarios que estén
en el sistema y además tengan el rol de Administrador. El usuario
que tenga acceso a este controlador es el que tiene más poder en
el sistema, ya que puede realizar prácticamente cualquier función
que se pueda realizar. Como es obvio, contiene las operaciones
que puede realizar el administrador.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
63
Escuela Politécnica Superior de Jaén
En cuarto lugar tenemos ResourceCentralControllerTeacher. Se
trata del controlador que contiene las operaciones que puede
realizar un usuario con rol de Profesor.
En quinto y último lugar, tenemos
ResourceCentralControllerStudent, que se trata del controlador
que contiene las diferentes funciones que puede llevar a cabo un
usuario con el rol de Estudiante.
5.2.3. Implementación del modelo de datos e Implementación de la
capa de persistencia.
A continuación mostraremos la implementación de las clases que forman
el modelo de datos, que van acompañadas de anotaciones para realizar el
mapeo de clases a una base de datos.
User
Ilustración 13: Implementación de la clase User con anotaciones de JPA
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
64
Escuela Politécnica Superior de Jaén
Activity
Ilustración 14: Implementación de la clase Activity con anotaciones de JPA
Objective
Ilustración 15: Implementación de la clase Objective con anotaciones de JPA
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
65
Escuela Politécnica Superior de Jaén
Batch
Ilustración 16: Implementación de la clase Batch con anotaciones de JPA
Ticket
Ilustración 17: Implementación de la clase Ticket con anotaciones de JPA
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
66
Escuela Politécnica Superior de Jaén
Exchange
Ilustración 18: Implementación de la clase Exchange con anotaciones de JPA
Hemos visto la implementación de nuestras clases para que se pueda
realizar un correcto mapeo a la base de datos. Para ello, es necesario llevar a
cabo la correspondiente configuración en el fichero de configuración de Spring,
para indicar a que base de datos se realiza ese mapeo y demás. Este fichero de
configuración lo veremos más adelante con más detalle.
Una vez hemos visto esto, tenemos que tener formas de acceder a la base
de datos utilizando la API JPA. Como hemos explicado antes, la capa de
persistencia de nuestro diagrama de clases es la que encarga de llevar a cabo
esta función mediante el conocido patrón DAO. Cuando hablamos de patrón
DAO estamos hablando de un conjunto de clases que implementan ciertos
métodos que nos permite operar con la bases de datos e intercambiar
información entre dicha base de datos y memoria principal para operar con esos
datos.
Vamos a ejemplificar la implementación de un DAO solo, debido a que los de
todas las clases funcionan prácticamente igual.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
67
Escuela Politécnica Superior de Jaén
Ilustración 19: Implementación de la clase UserDAO para acceso a BBDD
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
68
Escuela Politécnica Superior de Jaén
5.2.4. Cierre de la iteración 1
Con lo que acabamos de ver, se ha llevado a cabo de forma correcta la
implementación de las 2 primeras historias de usuario. Por desgracia no se ha
podido llevar a cabo la tercera historia de usuario o al menos una parte de ella
que era lo que teníamos planeado, con lo que en total de los 37 puntos de historia
que teníamos planeado realizar hemos realizado: Diseño e implementación del
model de datos (21 puntos de historia) y Diseño e implementación de la
capa de persistencia (13 puntos de historia) lo que hace un total de 34 puntos
de historia completados. Pero no hay que alarmarse. Normalmente cuando
hacemos frente a un proyecto, el comienzo siempre es un poco más lento del
ritmo normal de trabajo, además no nos hemos quedado tan lejos de cumplir con
el objetivo inicialmente planteado, que es una buena noticia. En principio no
vamos a modificar la velocidad de trabajo, porque teniendo en cuenta el margen
que dejamos en la planificación y que se trata de la primera iteración, se ha
cumplido con lo que podíamos esperar. La historia de usuario que no hemos
completado aquí será introducida en la siguiente iteración.
5.3. Iteración 2
5.3.1. Análisis
En esta iteración continuaremos con la misma velocidad de trabajo que
teníamos establecida (37 puntos de historia por iteración) y con la misma
dinámica. Las historias de usuario que vamos a intentar completar son las
siguientes.
Crear usuario (8 p.h.)
Autenticación de usuario (8 p.h.)
Obtener usuario (3 p.h.)
Editar usuario (8 p.h.)
Editar contraseña (8 p.h.)
Cambiar contraseña (5 p.h.)
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
69
Escuela Politécnica Superior de Jaén
Como podemos ver en las historias de usuario que hemos definido
anteriormente, tenemos un total de 40 puntos de historia. Intentaremos llevar
a cabo todas las historias a pesar de que nuestra velocidad de trabajo es de 37
puntos de historia, o al menos realizar de forma completa las 5 primeras que
forman un total de 35 puntos de historia y una parte de la última para completar
los 37 puntos de historia que tenemos en nuestra velocidad de trabajo.
IMPORTANTE
A partir de ahora, las diferentes historias de usuario que son
requerimientos que nos pide el cliente y por tanto van a estar implementados
sobre las capas que hemos definido anteriormente. Para que las historias de
usuario funcionen en la práctica, es necesario que esto suceda y trabajar con
todas las capas a la vez, y el recorrido que habrá será el siguiente:
1. En primer lugar se creará un servicio REST en nuestra llamada capa de
servicios la cual hemos explicado antes para que se pueda tener acceso
desde fuera.
2. En segundo lugar la capa de lógica de negocio pedirá o ejecutara lo que el
usuario solicite a la capa de lógica de negocio, trabajando con los elementos
del modelo y con los DAO para acceder a la base de datos.
3. Por último, la lógica de negocio pasará la información que el usuario necesite
a la capa de servicios, y este se los cederá al usuario.
Este es el proceso que se llevará a cabo a la hora de implementar cualquier
servicio que el usuario tiene disponible en nuestro back-end, pero hay algo más.
A la hora de trabajar con la base de datos, la lógica de negocio trabajará con
los objetos del modelo, pero esos objetos contienen mucha información y no se
los podemos transferir a la capa de servicios para que esta se los ceda al usuario.
Para solucionar esto tenemos 2 opciones. En primer lugar podemos crear
interfaces que limiten el acceso a la información. En segundo lugar, y como
opción que he optado, es añadir una capa más. En lugar de transferir los
objetos completos, transferimos una versión de los objetos con menos
información y más controlada por nosotros. Para llevar esto a cabo, hemos
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
70
Escuela Politécnica Superior de Jaén
utilizado el patrón DTO (Data Transfer Object), que consiste en la
transformación de objetos del modelo de datos en otros más sencillos que si
podamos enviar al usuario. Lo ilustramos en la siguiente imagen.
Ilustración 20: Capas mostradas de forma conceptual.
Como podemos observar, incorporamos la capa DTOs entre la de lógica
de negocio y la capa de servicios. Para llevar a cabo esto hemos necesitado
implementar una versión de los objetos del modelo, siendo estos más
manejables y sencillos. A continuación ilustramos su implementación.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
71
Escuela Politécnica Superior de Jaén
Implementación de DTOs
UserDTO
Ilustración 21: Implementación de la clase UserDTO
ActivityDTO
Ilustración 22: Implementación de la clase ActivityDTO
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
72
Escuela Politécnica Superior de Jaén
ObjectiveDTO
Ilustración 23: Implementación de la clase ObjectiveDTO
BatchDTO
Ilustración 24: Implementación de la clase BatchDTO
TicketDTO
Ilustración 25: Implementación de la clase TicketDTO
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
73
Escuela Politécnica Superior de Jaén
Además de estos DTO existen otros que utilizamos pero solo para recibir
información, como por ejemplo, a la hora de crear un usuario, recibimos y
construimos un objeto llamado NewUser. La razón por la que hacemos esto, es
simplemente que son objetos adaptados a nuestras necesidades para llevar a
cabo una acción. En las implementaciones de las historias de usuario,
ilustraremos también la implementación de estos DTOs extras conforme
vayamos viendo que se necesitan en algún servicio REST,
Ya hemos ilustrado el proceso que vamos a realizar para llevar a cabo la
implementación de nuestras historias de usuario, así que nos ponemos a ello.
NOTA: Como dijimos tenemos 5 controladores, esto hace que los
servicios puedan estar repetidos en diferentes controladores pero adaptados
para los permisos que tienen los usuarios con acceso dichos controladores. Por
ejemplo: A la hora de obtener una actividad, en el controlador del administrador
no se realizará ninguna comprobación puesto que tiene acceso a todas las
actividades, sin embargo en el controlador del profesor, hay que comprobar que
el usuario además de poseer ese rol, esté como profesor de la actividad a la que
quiere acceder, y al igual sucede con el estudiante.
5.3.2. Crear usuario
Para llevar a cabo la creación de un usuario, tenemos un servicio que
recibe información de un usuario, se realizan una serie de comprobaciones, y si
todo está correcto se lleva a cabo el alta de un usuario. Las comprobaciones
realizadas son:
Que el nombre de usuario no esté en el sistema
Que la contraseña y repite contraseña sean iguales
Una vez hecho esto, si todo es correcto, se lleva a cabo la inserción del
usuario en la base de datos
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
74
Escuela Politécnica Superior de Jaén
El servicio REST utilizado es el siguiente:
Crear usuario
URL /users
HTTP Method POST
Consumes application/json
Produces -
RequestBody NewUser
ResponseEntity UserDTO
Tabla 9: Servicio REST Crear Usuario
Como vemos, aquí tenemos una clase llamada NewUser de la que hemos
hablado antes y es la que utilizamos para obtener los datos de un usuario a crear.
A continuación ilustramos su implementación.
Ilustración 26: Implementación de la clase NewUser
A continuación vamos a llevar a cabo una representación conceptual del
mencionado proceso.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
75
Escuela Politécnica Superior de Jaén
Ilustración 27: Diagrama de secuencia de Crear usuario.
Lo hemos ilustrado como se haría desde el controlador del administrador,
pero esto es algo que también tenemos disponible en el controlador
ResourceCentralControllerAll, para que cualquiera se pueda dar de alta en el
sistema.
También cabe destacar que para la creación de un usuario en nuestro
sistema, tal y como especificamos en los requisitos no funcionales de la
aplicación, teníamos que almacenar las claves de los usuarios en la base de
datos de tal forma que no se encontrasen en texto plano, es por ello que hemos
utilizado el algoritmo Bcrypt, ya que el módulo de seguridad de Spring
framework lo incorpora para su uso y lo hemos aprovechado.
5.3.3. Autenticación de usuario
Para autenticar a un usuario en nuestro sistema, vamos a utilizar un
módulo de seguridad muy completo y fácil de usar de Spring Framework llamada
Spring Security. Para llevar a cabo la configuración de este módulo, primero
necesitamos importarlo en nuestro proyecto. Después necesitamos llevar a
cabo la configuración de dicha seguridad en algunos ficheros del proyecto como
vamos a mostrar a continuación.
Para llevar a cabo esta configuración, primero tenemos que establecer un
filtro en el fichero de configuración web.xml del proyecto. Lo que va a hacer
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
76
Escuela Politécnica Superior de Jaén
dicho filtro, es interceptar todas las URLs que se le indiquen mediante un patrón.
En nuestro caso, le indicaremos que intercepte todas las URLs, El filtro se
establecería así.
Ilustración 28: Filtro Spring Security en el fichero web.xml.
El siguiente paso es crear un fichero exclusivo para la configuración de
Spring Security, que nosotros hemos llamado spring-security.xml. En este
fichero podemos filtrar las URLs de forma personalizadas conforme a nuestras
necesidades y permitir el acceso según los diferentes roles de los usuarios. Es
en este fichero donde hemos llevado los filtros para acceder a los diferentes
controladores según el rol que el usuario tenga.
Ilustración 29: Contenido del fichero spring-security.xml.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
77
Escuela Politécnica Superior de Jaén
Como podemos ver en la Ilustración 29, damos los pertinentes permisos
de acceso a las diferentes URLs de los controladores además de indicar cuál es
la consulta que se debe realizar para acceder a la información de los usuarios y
a la de sus respectivos roles. También se puede observar cómo obligamos a que
se haga una petición mediante HTTPS. Para poder implementar esto hemos
tenido que crear un certificado autofirmado [18] [19] y utilizar el protocolo SSL
para que eso sea posible.
También le indicamos que las contraseñas de la bases de datos están
encriptadas con el algoritmo Bcrypt para que pueda autenticar a los usuarios de
forma correcta.
Por último necesitamos indicar la existencia de este fichero en el contexto
de Spring en el fichero de configuración web.xml.
Ilustración 30: Fragmento del fichero web.xml.
5.3.4. Obtener usuario
Este servicio nos permitirá obtener los datos de un usuario como es lógico.
Hemos llevado a cabo varios servicios para realizar esta acción porque
dependiendo de unas necesidades u otras, se accederá a dichos datos de una
forma u otra. En primer lugar, hemos implementado un servicio en el controlador
ResourceCentralController, que recordamos que era el controlador al que
podía acceder cualquier usuario registrado en el sistema, sea cual sea su rol.
Pues bien, el servicio que implementamos aquí se utiliza para que el usuario que
lo invoca obtenga sus propios datos y nada más. Para ello comprueba que el
usuario logeado en el sistema es el mismo que los datos que se están pidiendo.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
78
Escuela Politécnica Superior de Jaén
El servicio REST utilizado es el siguiente.
Obtener perfil de usuario
URL /users/{username}/profile
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity UserDTO
Tabla 10: Servicio REST Obtener perfil de usuario
También hemos creado otro servicio REST que permite acceder a un
usuario mediante su username. Este servicio está implementado en el
controlador ResourceCentralControllerAdmin puesto que como ya dijimos, los
administradores podrán acceder a la información de cualquiera.
Obtener usuario por username
URL /users/{username}
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity UserDTO
Tabla 11: Servicio REST Obtener usuario por username
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
79
Escuela Politécnica Superior de Jaén
Además y debido a nuestras necesidades, también implementamos un
servicio idéntico al anterior, pero en lugar de indicar el username, indicamos el
id del usuario del cual queremos obtener la información. Al igual que el anterior,
sólo se encuentra en el controlador del administrador
Obtener usuario por id
URL /users/idUser/{idUser}
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity UserDTO
Tabla 12: Servicio REST Obtener usuario por id
A continuación ilustramos un diagrama de secuencia de cómo se produce
ese acceso a los datos, Para los 3 casos es exactamente igual solo que se hacen
o en controladores distintos, o pasando como parámetro el username o el id.
Ilustración 31: Diagrama de secuencia de Obtener usuario.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
80
Escuela Politécnica Superior de Jaén
5.3.5. Editar usuario
En esta historia de usuario, lo que queremos es editar los datos de un
usuario. Para ello utilizamos el siguiente servicio REST
Editar usuario (admin y perfil)
URL /users/{idUser}
HTTP Method PUT
Consumes -
Produces application/json
RequestBody UserDTO
ResponseEntity UserDTO
Tabla 13: Servicio REST Editar usuario.
Este es un servicio REST que tenemos implementado en 2 controladores:
En el que tienen acceso todos los usuarios, es decir, en
ResourceCentralController, para que los usuarios puedan editar su perfil. Este
servicio comprueba que los datos del usuario que quieres modificar son los del
usuario logeado en el sistema. El otro controlador que dispone de este servicio
es el del administrador ResourceCentralControllerAdmin que puede editar
cualquier otro usuario.
A la hora de editar el usuario comprueba si el nuevo nombre existe en el
sistema y no eres tú (si es que has cambiado el nombre).
Solo vamos a ilustrar como lo hacemos con uno de los dos, puesto que el
otro sería exactamente igual obviando los permisos claro está.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
81
Escuela Politécnica Superior de Jaén
Ilustración 32: Diagrama de secuencia de editar Usuario.
5.3.6. Editar contraseña
Esta funcionalidad en el sistema, nos permitirá editar la contraseña del
perfil de un usuario. El servicio REST utilizado es el siguiente.
Editar contraseña
URL /users/profile
HTTP Method PUT
Consumes application/json
Produces -
RequestBody NewUser
ResponseEntity String
Tabla 14: Servicio REST Editar contraseña.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
82
Escuela Politécnica Superior de Jaén
Es un servicio que está situado en el controlador
ResourceCentralController, puesto que todos pueden editar su propia
contraseña. La única comprobación que utiliza es que el usuario que cambia la
contraseña, cambia su propia contraseña y no la de otro usuario, además de que
conozca su antigua contraseña y que los atributos ‘contraseña’ y
‘nuevaContraseña’ son iguales.
Ilustración 33: Diagrama de secuencia de editar contraseña.
5.3.7. Cambiar contraseña
Esta funcionalidad del sistema permitirá al administrador del sistema
cambiar la contraseña de cualquier usuario del sistema. La única diferencia con
el anterior es que el servicio se encuentra situado en el controlador del
administrador. Al ser igual no vamos a hacer el diagrama de secuencia.
Cambiar contraseña (admin)
URL /users/password
HTTP Method PUT
Consumes application/json
Produces -
RequestBody NewUser
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
83
Escuela Politécnica Superior de Jaén
ResponseEntity String
Tabla 15: Servicio REST Cambiar contraseña.
5.3.8. Cierre de la iteración 2
A pesar de documentarlo, en esta iteración no hemos completado esta
última historia de usuario, solo la parte que nos correspondía para llevar a cabo
los 37 puntos de historia que nosotros teníamos que completar. Los puntos de
historia restantes se llevarían a cabo en la iteración 3. Esto quiere decir que en
esta iteración habríamos completado 2 puntos de historia mientras que faltan 3
puntos de historia a desarrollar en la siguiente.
5.4. Iteración 3
5.4.1. Análisis
En esta iteración, vamos a continuar con la misma velocidad de trabajo
que teníamos, porque a pesar de retrasarnos mínimamente en la iteración 1, y
más aun siendo algo que se podía esperar en el comienzo, vamos avanzando
según lo previsto. Dicho esto, las siguientes historias de usuario serán las que
llevemos a cabo en esta iteración.
Crear actividad (8 p.h.)
Obtener actividad (3 p.h.)
Editar actividad (8 p.h.)
Crear Objetivo (8 p.h)
Obtener Objetivo (3 p.h.)
Editar Objetivo (8 p.h.)
Como podemos observar, estas historias de usuario no suman 37 puntos
de historia, sino que suman 38 puntos de historia. Además que recordar que
una parte de la anterior historia de usuario Cambiar contraseña, corresponde a
esta iteración aunque aquí no vayamos a documentarlo, concretamente 3
puntos de historia, lo que sumarian un total de 41 puntos de historia para esta
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
84
Escuela Politécnica Superior de Jaén
iteración. Así que intentaremos llevar a cabo todas estas historias de usuario
excepto la última, de la que diseñaremos solo el servicio REST y la
implementación la dejaremos para la siguiente iteración.
5.4.2. Crear actividad
Esta historia de usuario nos permitirá crear una actividad en el sistema, y
a continuación detallaremos cual es el proceso a llevar a cabo para hacerlo. El
servicio REST que utilizamos es el siguiente.
Crear actividad
URL /activities
HTTP Method POST
Consumes application/json
Produces -
RequestBody NewActivity
ResponseEntity String
Tabla 16: Servicio REST Crear actividad.
Como vemos, este servicio se sirve de una clase de las que hemos
mencionado antes llamada NewActivity y de la que nos servimos para la creación
de actividades solo. A continuación detallamos su implementación.
Ilustración 34: Implementación de la clase NewActivity
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
85
Escuela Politécnica Superior de Jaén
Se trata de un servicio REST que está implementado en 2 controladores.
El controlador al que tienen acceso los administradores y el controlador al que
tienen acceso los profesores, ya que ambos pueden crear actividades por igual.
Para crear una actividad, el sistema comprueba que una actividad con
este nombre no exista en el sistema. Una vez hecho eso, comprueba si el usuario
que la crea tiene el rol de profesor (puede que solo sea administrador) y si no es
así, le asigna dicho rol. Posteriormente, le incluye como profesor de la
asignatura.
Ilustración 35: Diagrama de secuencia de Crear actividad
5.4.3. Obtener actividad
En esta historia de usuario, mostraremos los servicios que tenemos para
obtener una actividad. A continuación mostramos el servicio REST utilizado, en
el que se accede por el nombre de la actividad.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
86
Escuela Politécnica Superior de Jaén
Obtener actividad por nombre
URL /activities/{activityName}
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity ActivityDTO
Tabla 17: Servicio REST Obtener actividad por nombre
Dependiendo de la necesidad, también podemos acceder a una mediante
el id, al igual que sucedía con los usuarios.
Obtener actividad por id (admin, teacher y estudiante)
URL /activities/id/{idActivity}
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity ActivityDTO
Tabla 18: Servicio REST Obtener actividad por id
Este servicio está implementado en los tres controladores a los que tienen
acceso los usuarios de manera individual, es decir, en el controlador de
administradores, de profesores y de estudiantes. Todos pueden acceder las
actividades, pero algunos con alguna restricción.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
87
Escuela Politécnica Superior de Jaén
Los administradores pueden acceder a todas las actividades sin
ninguna limitación
Los profesores pueden acceder a las actividades de las que él sea
profesor
Los estudiantes pueden acceder a las actividades de las que sean
estudiantes.
Es por eso que el acceso se hace de la misma forma, solo que para cada
uno se realiza una comprobación en el caso de que sea necesario. No vamos a
realizar diagrama de secuencia, debido a que es exactamente igual que el de
obtener un usuario pero con la comprobación de la que estamos hablando para
cada rol y que el acceso es a través de ActivityDAO en lugar de UserDAO.
5.4.4. Editar actividad
Este servicio está implementado para que podamos editar las
características de una actividad.
Editar actividad
URL /activities/{idActivity}
HTTP Method PUT
Consumes application/json
Produces -
RequestBody ActivityDTO
ResponseEntity -
Tabla 19: Servicio REST Editar actividad
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
88
Escuela Politécnica Superior de Jaén
Este servicio está implementado tanto en el controlador del administrador,
como en el controlador del cliente pero al igual que a la hora de obtener una
actividad, existe una diferencia. En el controlador del administrador no se hace
ninguna comprobación antes de editarla respecto a los permisos de acceso, sin
embargo en el del profesor, se comprueba que el usuario sea profesor de la
actividad que va a modificar. A la hora de actualizar al igual que cuando se crea
la actividad, se comprueba que no haya ninguna actividad con el nuevo nombre
que le intentemos dar si es que es así.
Ilustración 36: Diagrama de secuencia de Editar actividad
5.4.5. Crear objetivo
Este servicio nos permitirá crear un objetivo dentro de una actividad
concreta.
Crear Objetivo
URL /{activityName}/objectives
HTTP Method POST
Consumes application/json
Produces -
RequestBody NewObjective
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
89
Escuela Politécnica Superior de Jaén
ResponseEntity ObjectiveDTO
Tabla 20: Servicio REST Crear Objetivo
Como podemos ver, al igual que sucedía con las actividades, para crear
un objetivo utilizamos una clase especial que nos proporciona la información que
necesitamos para ello. A continuación detallamos su implementación.
Ilustración 37: Implementación de la clase NewObjective.
Este servicio está implementado tanto en el controlador del administrador
como en el controlador del profesor. Al igual que pasaba con las actividades, en
el controlador del administrador no se realizar comprobación alguna debido a
que tiene acceso a todo, sin embargo en el del profesor, antes de crear un
objetivo, se comprueba que el usuario que la va a crear es profesor de la
actividad en la cual quiere crear dicho objetivo. También comprueba que dentro
de esa actividad no existe un objetivo con ese mismo nombre.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
90
Escuela Politécnica Superior de Jaén
Ilustración 38: Diagrama de secuencia de Crear objetivo.
5.4.6. Obtener objetivo.
Este servicio nos permitirá obtener un objetivo concreto de nuestra
aplicación.
Obtener objetivo
URL /objectives/{idObjective}
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity ObjectiveDTO
Tabla 21: Servicio REST Obtener Objetivo
Este servicio se encuentra implementado en el controlador del
administrador, en el controlador del profesor y también en el del estudiante pero
se hacen las pertinentes comprobaciones para acceder, es decir, en el caso del
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
91
Escuela Politécnica Superior de Jaén
administrador no se hace ninguna, y en la del profesor se comprueba que el
profesor lo es de esa asignatura, e igual sucede con el estudiante.
El diagrama de secuencia no vamos a llevarlo a cabo, debido a que es
igual que el de Obtener Actividad solo que en lugar de pedir el objetico al
ActivityDAO, se hace a ObjectiveDAO,
5.4.7. Cierre iteración 3.
En esta iteración hemos realizado correctamente los 37 puntos de historia
que teníamos que llevar a cabo aunque no cuadra con las historias realizadas.
Pero recordamos:
Crear actividad (8 p.h.)
Obtener actividad (3 p.h.)
Editar actividad (8 p.h.)
Crear Objetivo (8 p.h)
Obtener Objetivo (3 p.h.)
Estas 5 historias de usuario suman 30 puntos de historia. A eso hay que
añadirle los 3 puntos de historia de la historia de usuario que nos faltó por
completar en la iteración anterior, lo que hace un total del 33. Y por último, hemos
podido llevar a cabo una parte de la historia de usuario Editar objetivo (8 p.h.)
de los cuales hemos realizado 4), sin embargo para no liarnos mucho va a ser
documentada en la siguiente iteración al completo.
5.5. Iteración 4
5.5.1. Análisis
Al igual que ha sucedido en las iteraciones anteriores, vamos a mantener
la velocidad de trabajo de 37 puntos de historia, y para ello será necesario llevar
a cabo las siguientes historias de usuario.
Editar objetivo (8 p.h. de los que tenemos que hacer 4)
Crear tanda de tickets (8 p.h.)
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
92
Escuela Politécnica Superior de Jaén
Obtener tanda de tickets (3 p.h.)
Editar tanda de tickets (13 p.h.)
Obtener ticket (3 p.h.)
Canjear Ticket (21 p.h.)
Como podemos observar, en lugar de 37 puntos de historia, las historias
de usuario que tenemos aquí suman un total de 52 puntos de historia. Esto se
debe a que en esta iteración nos tocará llevar a cabo una parte de la historia de
usuario Canjear Ticket que es una de las más complejas, y otra parte en la
siguiente iteración.
5.5.2. Editar Objetivo.
Este servicio es el que hemos comentado que teníamos que hacer una
parte aquí y otra parte en la iteración anterior, aunque la vamos a documentar
toda aquí.
Editar objetivo
URL /objectives/{idObj}
HTTP Method PUT
Consumes application/json
Produces -
RequestBody ObjectiveDTO
ResponseEntity -
Tabla 22: Servicio REST Editar objetivo
Este es un servicio que está implementado tanto en el controlador del
administrador, que puede modificar cualquier objetivo, como en el del profesor,
que al igual que antes solo podrá modificar los objetivos que están en sus
asignaturas.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
93
Escuela Politécnica Superior de Jaén
Ilustración 39: Diagrama de secuencia de Editar objetivo.
5.5.3. Crear tanda de tickets
Con este servicio se podrán crear tandas de tickets asociados a un
objetivo concreto.
Crear tanda de tickets
URL /objectives/{idObjective}/batches
HTTP Method POST
Consumes application/json
Produces -
RequestBody NewBatch
ResponseEntity BatchDTO
Tabla 23: Servicio REST Crear tanda de tickets
Como podemos ver, para crear la tanda, utilizamos otra clase que no
hemos documentado antes como es la clase NewBatch y que nos sirve para
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
94
Escuela Politécnica Superior de Jaén
almacenar la información necesaria para crear dicha tanda de tickets. Aquí
tenemos su implementación
Ilustración 40: Implementación de la clase NewBatch.
Este es un servicio que tenemos disponible para el controlador del
administrador, para el que no necesita ninguna comprobación, y para el
controlador del profesor, que antes de crear una tanda de tickets realiza la
comprobación de que es profesor de la actividad que contiene el objetivo para el
cual se pretende crear la tanda de tickets.
Ilustración 41: Diagrama de secuencia de Crear tanda de tickets
5.5.4. Obtener tanda de tickets
Este es un servicio que dado el id de una tanda de tickets, nos permite
obtener su información.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
95
Escuela Politécnica Superior de Jaén
Obtener tanda de tickets
URL /batches/{idBatch}
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity BatchDTO
Tabla 24: Servicio REST Obtener tanda de tickets
Se trata de un servicio que está en la misma situación que la historia de
usuario anterior, debido a que está tanto en los controladores del administrador
como en el del profesor. Y sabemos que en el del administrador no hay que
realizar ninguna comprobación, sin embargo en la del profesor, hay que
comprobar que sea profesor de la actividad a la que pertenece la tanda.
Ilustración 42: Diagrama de secuencia de Obtener tanda de tickets
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
96
Escuela Politécnica Superior de Jaén
5.5.5. Editar tanda de tickets
Servicio que nos permite editar la información de una tanda. Es importante
destacar que eso no incluye el número de tickets, que una tanda siempre tiene
el número de tickets con la que ha sido creada. Este es el servicio REST.
Editar tanda de tickets (admin y teacher)
URL /batches/{idBatch}
HTTP Method PUT
Consumes application/json
Produces -
RequestBody NewBatch
ResponseEntity -
Tabla 25: Servicio REST Editar tanda de tickets
Este servicio nos permite editar cosas como la fecha de validez de los
tickets de una tanda, el título de la tanda y el número de Canjeos posibles por
ticket.
Se trata de un servicio que está en la misma situación que la historia de
usuario anterior, debido a que está tanto en los controladores del administrador
como en el del profesor. Y sabemos que en el del administrador no hay que
realizar ninguna comprobación, sin embargo en la del profesor, hay que
comprobar que sea profesor de la actividad a la que pertenece la tanda que se
quiere editar.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
97
Escuela Politécnica Superior de Jaén
Ilustración 43: Diagrama de secuencia de Editar tanda de tickets
5.5.6. Obtener Ticket
Se trata de un servicio REST que te permite obtener la información de un
ticket a partir de su id.
Obtener ticket (admin y teacher)
URL /tickets/{idTicket}
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity TicketDTO
Tabla 26: Servicio REST Obtener Ticket
Se trata de un servicio que está en la misma situación que la historia de
usuario anterior, debido a que está tanto en los controladores del administrador
como en el del profesor. Y sabemos que en el del administrador no hay que
realizar ninguna comprobación, sin embargo en la del profesor, hay que
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
98
Escuela Politécnica Superior de Jaén
comprobar que sea profesor de la actividad a la que pertenece el ticket que
queremos obtener.
Ilustración 44: Diagrama de secuencia de Obtener Ticket.
5.5.7. Canjear Ticket.
Este será el servicio que nos permitirá canjear un ticket mediante el id del
mismo. Es uno de los más complejos y no por el proceso de canjeo en sí, sino
por la cantidad de comprobaciones que hay que llevar a cabo para que ver si
podemos efectuar ese canjeo o no.
Canjear ticket
URL /exchanges
HTTP Method POST
Consumes application/json
Produces -
RequestBody ExchangeDTO
ResponseEntity String
Tabla 27: Servicio REST Canjear Ticket
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
99
Escuela Politécnica Superior de Jaén
Tenemos que recordar que esta historia de usuario, no pertenece
íntegramente a esta iteración. Solo 6 puntos de historia de los 21 que tiene
nuestra historia de usuario, pertenecen a esta iteración, pero para complicarnos
menos vamos a documentarla por completo en esta iteración.
Este es un servicio que se encuentra disponible en el controlador
ResourceCentralController, que como ya dijimos, es el controlador al que tiene
acceso cualquier usuario que esté en el sistema mientras tenga los 3 roles
disponibles.
Lo complejo como hemos dicho es las diferentes comprobaciones que hay
que llevar a cabo a la hora de canjear un ticket.
En primer lugar se comprueba que el ticket existe en el sistema, en
caso de que no sea así se lanza una excepción.
En segundo lugar, se comprueba si ya existe el canjeo que se
desea hacer, es decir, que el usuario ya haya canjeado ese ticket
antes. De ser así, se lanzaría una excepción.
Después se comprueba que el ticket no esté caducado, es decir,
que el ticket tenga una fecha de validez superior a la de la fecha de
canjeo. Si no es así se lanza una excepción.
Posteriormente se comprueba que el número de Canjeos actuales
es inferior al de Canjeos posibles. Si no es así se lanza una
excepción.
Por último, si el usuario que ha canjeado el ticket no tiene el rol de
estudiante, se le asigna.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
100
Escuela Politécnica Superior de Jaén
Ilustración 45: Diagrama de secuencia de Canjear ticket.
5.5.8. Cierre de la iteración 4
Como hemos visto, se trata de la parte más compleja y donde más fallos
se pueden producir. También es cierto que he querido ilustrar todas las posibles
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
101
Escuela Politécnica Superior de Jaén
excepciones y casuísticas que se pueden producir en el proceso, algo que no
hemos se suele hacer en todos los diagramas de secuencia.
Como ya hemos mencionado, una parte de este último punto de historia
debe desarrollarse en la siguiente iteración, así que hay que tenerlo en cuenta a
la hora de elegir las historias de usuario a desarrollar.
5.6. Iteración 5
5.6.1. Análisis
En la iteración anterior completamos los 37 puntos de historia de nuestra
velocidad por lo que para esta iteración hemos decidido mantenerla.
Recordamos que aunque fue documentada en la anterior iteración, la historia de
usuario Canjear ticket también forma parte de esta iteración. Aunque vamos a
indicarla entre las historias de usuario para iteración, no vamos a documentar
nada de ella debido a que ya lo hemos hecho.
Como hemos dicho, vamos a mantener la velocidad de trabajo en esta
iteración, por lo que necesitamos llevar a cabo las siguientes historias de usuario
para que esto suceda.
Canjear ticket (21 p.h. de los cuales tenemos que hacer 15 p.h.)
Ranking de actividad (13 p.h.)
Ranking de objetivo (13 p.h.)
Como vemos, los puntos de historia a desarrollar que tenemos aquí son
41 puntos de historia en lugar de 37 puntos de historia con lo que la prioridad
es completar las 2 primeras historias de usuario y al menos una parte de la
última.
5.6.2. Ranking de actividad
Este servicio nos va a permitir mandar el ranking de una determinada
actividad con un determinado formato a quien lo solicite.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
102
Escuela Politécnica Superior de Jaén
Ranking de actividad
URL /activities/{activityName}/ranking
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity Ranking
Tabla 28: Servicio REST Ranking de actividad
Como podemos ver, este servicio responde a quien lo solicita con una
clase que no hemos visto antes. Esta clase la hemos utilizado para dar formato
a ese ranking y poder procesar los datos. Como veremos a continuación, es una
clase formada por dos Listas. En primer lugar, una de ellas contiene los nombres
de usuarios que hay en el ranking. En la otra tenemos el número de tickets que
tienen los usuarios de la primera lista.
Ilustración 46: Implementación de la clase Ranking
Este se trata de un servicio que se encuentra en los 3 controladores a los
que tienen acceso los roles de forma individual, es decir, en el controlador del
administrador, el controlador del profesor, y el controlador del estudiante, pero al
igual que sucedía en muchos otros servicios, hay restricciones. En el del
administrador, como sabemos, no hay ninguna. En el del profesor, se comprueba
que el usuario es profesor de la actividad a la que pertenece el ranking, y sucede
lo mismo con el del estudiante.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
103
Escuela Politécnica Superior de Jaén
Ilustración 47: Diagrama de secuencia Ranking de actividad
5.6.3. Ranking de objetivo
Este servicio nos permitirá ceder el Ranking de un determinado objetivo
con un determinado formato quien lo solicite.
Ranking de objetivo
URL /objectives/{idObjective}/ranking
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity Ranking
Tabla 29: Servicio REST Ranking de objetivo
Como podemos ver, al igual que sucedía con la historia de usuario
anterior, utilizamos la clase Ranking para enviar el ranking de un objetivo al
usuario.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
104
Escuela Politécnica Superior de Jaén
Al igual que sucedía antes, se trata de un servicio que se encuentra en los
3 controladores a los que tienen acceso los roles de forma individual, es decir,
en el controlador del administrador, el controlador del profesor, y el controlador
del estudiante, pero al igual que sucedía en muchos otros servicios, hay
restricciones. En el del administrador, como sabemos, no hay ninguna. En el del
profesor, se comprueba que el usuario es profesor de la actividad a la que
pertenece el objetivo del cual solicitamos el ranking, y sucede lo mismo con el
del estudiante.
Ilustración 48: Diagrama de secuencia Ranking de objetivo
5.6.4. Cierre de la iteración 5
En esta historia de usuario hemos completado los 37 puntos de historia
que buscábamos completar, aunque como vemos, hemos documentado la
historia de usuario Ranking de Objetivo por completo. Esto no significa que la
hayamos completado en esta iteración, pero lo hacemos así para que su
información se encuentre compacta y fácilmente legible. Como sabemos, una
parte de dicha historia de usuario pertenece a la siguiente iteración, que aunque
lo reflejaremos en el análisis, no será documentada por segunda vez.
Para situarnos, vamos a hacer recuento de lo que hemos hecho y de lo
que nos falta por hacer.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
105
Escuela Politécnica Superior de Jaén
En total, hemos desarrollado un total de 19 historias de usuario, las cuales
suman un total de 173 puntos (historias de usuario completas) de historia de los
420 puntos de historias de usuario. Esto hace que al quedarnos 7 iteraciones,
para completar el proyecto con éxito necesitemos llevar una velocidad superior
a 35,28 puntos de historia por iteración. Este dato nos favorece enormemente
teniendo en cuenta que nuestra velocidad media es de 37 puntos de historia por
iteración, y más aun teniendo en cuenta que la parte de la última historia de
usuario que hemos realizado no se ha contabilizado en estos cálculos. Significa
que vamos por buen camino.
5.7. Iteración 6
5.7.1. Análisis
Como hemos comentado, en esta iteración corresponde hacer una parte
de la última historia de usuario documentada anteriormente, es decir, Ranking
de objetivo pero aunque la completaremos aquí, no vamos a documentar nada.
Como hemos concluido en la anterior iteración, vamos a continuar con nuestra
velocidad de trabajo puesto que es adecuada para completar el proyecto. Para
ello las historias de usuario a realizar serían las siguientes.
Ranking de objetivo (13 p.h. de los que nos corresponde hacer 4
p.h.)
Añadir profesor a una actividad (8 p.h)
Canjeos de un usuario en una actividad (13 p.h.)
Canjeos de un usuario en un objetivo (13 p.h.)
Como podemos observar, estas historias de usuario no suman 37 puntos
de historia sino que suman 38 puntos de historia. Vamos a intentar
completarlas del todo puesto que la diferencia es mínima y además iríamos por
delante de la planificación. En el caso de que no fuese posible, intentaríamos
completar la última historia de usuario casi del todo.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
106
Escuela Politécnica Superior de Jaén
5.7.2. Añadir profesor a una actividad
Este servicio, nos permitirá añadir establecer a un profesor como profesor
de una actividad.
Añadir professor a actividad
URL /activities/{activityName}/teachers
HTTP Method PUT
Consumes application/json
Produces -
RequestBody UserDTO
ResponseEntity -
Tabla 30: Servicio REST Añadir profesor a actividad
Se trata de un servicio disponible en el controlador del administrador y en
controlador del profesor. El administrador puede añadir profesores a todas las
actividades, pero el profesor solo puede hacerlo en las actividades de las que él
ya es profesor.
Ilustración 49: Diagrama de secuencia Añadir profesor a actividad
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
107
Escuela Politécnica Superior de Jaén
5.7.3. Canjeos de un usuario en una actividad
Este servicio nos permitirá obtener los Canjeos de un usuario en una
actividad concreta. Esto puede servir para ver al alumno que tickets ha canjeado
y cuando en todos los objetivos de la actividad, y al profesor para controlar todos
los Canjeos de sus alumnos.
Canjeos de un usuario en una actividad
URL /users/{idUser}/activities/{activityName}/exchanges
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity List<ExchangeDTO>
Tabla 31: Servicio REST Canjeos de usuario en actividad
El servicio se encuentra disponible en los 3 controladores a los que los
usuarios tienen acceso de forma individual según el rol, es decir, el controlador
del administrador, el del profesor y el del alumno. Pero como siempre sucede,
hay restricciones. El administrador no tiene, así que puede ver los Canjeos de
cualquier usuario en cualquier actividad en el sistema. El profesor puede ver los
Canjeos de los estudiantes pero solo en sus actividades. Y el estudiante solo
puede ver sus propios Canjeos.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
108
Escuela Politécnica Superior de Jaén
Ilustración 50: Diagrama de secuencia Canjeos de usuario en Actividad
5.7.4. Canjeos de un usuario en una actividad
Este servicio hace exactamente lo mismo que el anterior, pero en lugar de
ser para una Actividad, es para un Objetivo concreto.
Canjeos de un usuario en un objetivo
URL /users/{idUser}/objectives/{idObjective}/exchanges
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity List<ExchangeDTO>
Tabla 32: Servicio REST Canjeos de Usuario en Objetivo
Este servicio se encuentra en los mismos controladores que el anterior y
tiene exactamente las mismas restricciones de acceso.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
109
Escuela Politécnica Superior de Jaén
Ilustración 51: Diagrama de secuencia Canjeos de Usuario en Objetivo
5.7.5. Cierre de la iteración 6
En esta iteración hemos conseguido completar todas las historias de
usuario que sumaban un total de 38 puntos de historia. La dinámica de trabajo
que llevamos es bastante buena, así que continuaremos con ella.
5.8. Iteración 7
5.8.1. Análisis
Como ha ido siendo la dinámica de trabajo, la cual nos ha ido bastante
bien, continuaremos con nuestra velocidad establecida de 37 puntos de historia
por iteración para el desarrollo de las siguientes historias de usuario. Las
historias de usuario a desarrollar en la siguiente iteración son las siguientes.
Obtener listado de actividades (8 p.h.)
Obtener todos los usuarios (5 p.h.)
Eliminar a un estudiante de una actividad (8 p.h.)
Eliminar a un profesor de una actividad (5 p.h.)
Eliminar usuario (5 p.h.)
Eliminar actividad (8 p.h.)
Como podemos observar, el número de puntos de historia que suman
estas historias de usuario no es de 37 puntos de historia sino que es que 39
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
110
Escuela Politécnica Superior de Jaén
puntos de historia. La última historia de usuario, es decir, Eliminar actividad, si
no podemos llevarla a cabo completamente, al menos intentaremos hacer una
parte para completar nuestros puntos de historia como hemos hecho hasta
ahora.
5.8.2. Obtener listado de actividades
Este servicio nos permitirá obtener un listado con las actividades a las que
tenemos acceso dependiendo del rol en el sistema.
Obtener listado de actividades
URL /activities
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity List<ActivityDTO>
Tabla 33: Servicio REST Obtener listado de actividades
Este servicio se encuentra en los 3 controladores a los que tiene acceso
cada rol de forma individualizada, es decir, en el del administrador, en el del
profesor y en el del estudiante. Sin embargo a cada uno de ellos ceden unos
datos diferentes.
Al administrador le proporciona un listado con todas las
actividades del sistema.
Al profesor le proporciona un listado con las actividades que tiene
como profesor.
Al estudiante le proporciona un listado de las actividades que tiene
como estudiante.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
111
Escuela Politécnica Superior de Jaén
Ilustración 52: Diagrama de secuencia Obtener listado actividades
Los diagramas de secuencia para los profesores y para los estudiantes
son exactamente iguales. Lo único que cambia es la llamada a la clase
ActivityDAO, para que la consulta a la base de datos sea otra distinta.
5.8.3. Obtener listado los usuarios
Este servicio nos permite obtener un listado con la información de todos
los usuarios que se encuentran en el sistema.
Obtener listado de usuarios
URL /users
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity List<UserDTO>
Tabla 34: Servicio REST Obtener listado de usuarios
Este servicio, como es lógico, se encuentra implementado solamente en
el controlador al que tienen acceso los usuarios con rol de administrador.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
112
Escuela Politécnica Superior de Jaén
Ilustración 53: Diagrama de secuencia Obtener listado de usuarios
5.8.4. Eliminar estudiante de una actividad
Este servicio nos va a permitir eliminar a un usuario como estudiante de
una actividad concreta. La utilidad de esto es que el profesor quiera que alguien
en concreto no pueda ver la información de su actividad.
Eliminar estudiante de una actividad
URL /activities/{activityName}/deleteUser
HTTP Method PUT
Consumes application/json
Produces -
RequestBody UserDTO
ResponseEntity -
Tabla 35: Servicio REST Eliminar estudiante de actividad
Es un servicio que se implementa tanto en el controlador del administrador
como en el del profesor. El administrador podrá eliminar estudiantes de cualquier
actividad, mientras que el profesor podrá hacerlo de las actividades de las que
él es profesor.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
113
Escuela Politécnica Superior de Jaén
Cabe destacar también que tal y como se implementa este servicio, solo
es el estudiante el que deja de pertenecer a esa actividad, así que sus Canjeos
se mantendrán y seguirá apareciendo en los rankings de la actividad.
Ilustración 54: Diagrama de secuencia Eliminar estudiante de actividad
5.8.5. Eliminar profesor de una actividad
Este servicio nos va a permitir eliminar a un usuario como profesor de una
actividad concreta
Eliminar profesor de actividad (admin, teacher)
URL /activities/{activityName}/deleteTeacher
HTTP Method PUT
Consumes application/json
Produces -
RequestBody UserDTO
ResponseEntity -
Tabla 36: Servicio REST Eliminar profesor de actividad
Es un servicio que se implementa tanto en el controlador del administrador
como en el del profesor. El administrador podrá eliminar profesores de cualquier
actividad, mientras que el profesor podrá hacerlo de las actividades de las que
él es profesor.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
114
Escuela Politécnica Superior de Jaén
Ilustración 55: Diagrama de secuencia Eliminar profesor de actividad
5.8.6. Eliminar usuario
Con este servicio podremos eliminar a un usuario por completo del
sistema.
Eliminar usuario
URL /users/{idUser}
HTTP Method DELETE
Consumes -
Produces application/json
RequestBody -
ResponseEntity -
Tabla 37: Servicio REST Eliminar usuario
Se trata de un servicio que solo está implementado en el controlador del
administrador, puesto que al ser una herramienta docente, no hemos querido dar
la posibilidad de que los usuarios se den de baja a sí mismos. Es el administrador
el encargado de gestionar esto, por lo que podrá eliminar a cualquiera del
sistema. Es importante destacar que un administrador no se puede eliminar a sí
mismo del sistema.
Cabe destacar que si un usuario es eliminado también se eliminan los
Canjeos que ha llevado a cabo en el sistema.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
115
Escuela Politécnica Superior de Jaén
Ilustración 56: Diagrama de secuencia Eliminar usuario
5.8.7. Cierre de la iteración 7
En esta iteración hemos completado todas las historias de usuario menos
la última, es decir, Eliminar actividad, de la que solo hemos podido completar
la mitad de ella, aunque la documentaremos al completo en la siguiente
iteración. Esto quiere decir que solo hemos completado 35 puntos de historia
de los 37 que nos marcaba nuestra velocidad, pero como íbamos un poco
adelantados de las iteraciones anteriores, esto no nos supone un problema para
continuar trabajando igual.
5.9. Iteración 8
5.9.1. Análisis
En esta iteración vamos a seguir trabajando con la misma velocidad ágil
debido a que nos ha ido bien hasta ahora.
IMPORTANTE: En esta iteración terminamos de llevar a cabo las historias
de usuario relacionadas con el back-end, y comenzamos las relacionadas con
el front-end, A continuación detallamos como vamos a proceder a documentar
las historias de usuario relacionadas con el front-end.
A la hora de realizar un cliente que se comunique con nuestro servidor,
las partes que lo conforman son una serie de vistas, que en nuestro caso al ser
un cliente java, serán una serie de archivos JSP que se comunicarán con uno o
varios controladores de la parte de cliente, que son los que se comunican con
nuestro servidor realizando peticiones REST. Lo ilustramos en la siguiente
imagen.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
116
Escuela Politécnica Superior de Jaén
Ilustración 57: Mapa conceptual de la comunicación entre cliente y servidor
Si lo que vamos a tener es un cliente y un servidor implementados con la
misma tecnología y que juntos habrían conectado perfectamente, entonces se
preguntará:
¿Por qué hacerlo de forma separada en lugar de unificarlo todo para
ahorrar en tiempo y trabajo?
Se ha decidido desarrollar el servidor como una API REST capaz de
recibir peticiones, debido a que estando diseñada de esta forma, cualquier cliente
implementado en cualquier lenguaje, desde cualquier lugar y desde cualquier
tipo de dispositivo. A continuación se ilustra.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
117
Escuela Politécnica Superior de Jaén
Ilustración 58: Conexión de diferentes clientes con un Servidor
Una vez hecho esto cabe destacar la estructura que tiene nuestro cliente
y los componentes que posee.
En primer lugar, tenemos una serie de clases que nos sirven para
comunicarnos con el Servidor. Esas clases son las que aparecen
en los apartados RequestBody y ResponseEntity que antes
hemos visto en los servicios REST.
En segundo lugar y para tener una mejor organización, disponemos
también de 4 controladores.
o Uno de ellos llamado ClientController en el cual se
implementan los métodos comunes que tienen los 3 roles
como los de acceso al perfil de usuario.
o Otro llamado AdminController que implementa los
métodos del administrador y los accesos a sus vistas.
o Otro llamado TeacherController que implementa los
métodos del profesor y los accesos a sus vistas.
o Otro llamado StudentController que implementa los
métodos del estudiante y los accesos a sus vistas.
Dicho todo esto, las historias de usuario las vamos a documentar de tal
forma que, al ser todas ellas formularios y vistas, diremos que roles tienen
acceso a esas vistas, y que peticiones REST se han lanzado al servidor para
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
118
Escuela Politécnica Superior de Jaén
poder mostrarlas. Si se quiere ver la implementación de las vistas, es mejor
revisar el código fuente directamente.
Una vez concluida esta introducción, nos disponemos a ver las historias
de usuario que tenemos en esta iteración, y la llevaremos a cabo.
Para completar los 37 puntos de historia de nuestra velocidad ágil,
necesitaremos realizar las siguientes historias de usuario.
Eliminar actividad (8 p.h. de los cuales tenemos que hacer 4)
Eliminar Objetivo (5 p.h.)
Eliminar tanda (5 p.h)
Y pertenecientes al front-end.
Formulario de registro (5 p.h.)
Formulario de inicio de sesión (5 p.h.)
Página de inicio (13 p.h)
Como vemos, suman los 37 puntos de historia que necesitamos hacer
para seguir con nuestra planificación.
5.9.2. Eliminar actividad
Se trata de un servicio, el cual nos va a permitir una actividad del sistema
por completo
Eliminar actividad
URL /activities/{activityName}
HTTP Method DELETE
Consumes -
Produces application/json
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
119
Escuela Politécnica Superior de Jaén
RequestBody -
ResponseEntity -
Tabla 38: Servicio REST Eliminar actividad
Cabe destacar, que el borrado de una actividad implica el borrado de los
objetivos de la misma y de las tandas de tickets de dichos objetivos, con todos
sus tickets y Canjeos.
Se trata de un servicio situado en los controladores del administrador, que
puede eliminar cualquier actividad, y en el del profesor, que puede eliminar las
actividades de las que es profesor.
Ilustración 59: Diagrama de secuencia Eliminar Actividad.
5.9.3. Eliminar objetivo
Es un servicio que nos permite eliminar un objetivo completamente de
nuestro sistema
Eliminar objetivo
URL /objectives/{idObjective}
HTTP Method DELETE
Consumes -
Produces application/json
RequestBody -
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
120
Escuela Politécnica Superior de Jaén
ResponseEntity -
Tabla 39: Servicio REST Eliminar objetivo
Cabe destacar que el borrado de un objetivo, al igual que ocurría con la
historia de usuario anterior, implica el borrado de las tandas de tickets que tiene
asociadas, unido a sus respectivos tickets con los Canjeos de esos tickets.
Se trata de un servicio situado en los controladores del administrador, que
puede eliminar cualquier objetivo, y en el del profesor, que puede eliminar los
objetivos que pertenezcan a las actividades de las que es profesor.
Ilustración 60: Diagrama de secuencia Eliminar Objetivo.
5.9.4. Eliminar tanda
Este servicio nos permitirá eliminar una tanda de tickets.
Eliminar tanda
URL /batches/{idBatch}
HTTP Method DELETE
Consumes -
Produces application/json
RequestBody -
ResponseEntity String
Tabla 40: Servicio REST Eliminar objetivo
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
121
Escuela Politécnica Superior de Jaén
También se eliminarán los tickets asociados a dicha tanda, así como los
Canjeos realizados con esos tickets.
Se trata de un servicio situado en los controladores del administrador, que
puede eliminar cualquier tanda, y en el del profesor, que puede eliminar las
tandas que pertenezcan a las actividades de las que es profesor.
Ilustración 61: Diagrama de secuencia Eliminar tanda.
5.9.5. Formulario de registro
Esta es la primera historia de usuario que vamos a llevar a cabo
perteneciente al front-end de nuestro proyecto.
NOTA: Recordamos que todo formulario no solo nos sirve para
mostrarnos datos, sino que también los usamos para mandarlos, función que
también reflejaremos cuando definamos cualquier formulario
Podemos acceder a ella mediante un botón situado en la página de inicio,
y ya nos daría la posibilidad de acceder.
Los servicios REST que utiliza son:
POST a /users , para intentar llevar a cabo el registro en el sistema
La interacción de este formulario se encuentra implementada en el
controlador ClientController
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
122
Escuela Politécnica Superior de Jaén
5.9.6. Formulario de inicio de sesión
Se trata de un formulario mediante el cual accedemos al sistema con
nuestro usuario y contraseña.
Los servicios REST que utiliza son:
GET a /users/{username}/profile, para acceder a sus datos de
perfil de usuario
GET a /activities en caso de que el usuario que ha iniciado sesión
solo tenga el rol de estudiante, puesto que en la página de inicio se
muestran las actividades del usuario
La interacción de este formulario se encuentra implementada en el
controlador ClientController.
5.9.7. Página de inicio
Se trata de una página que muestra la situación de usuario en el sistema.
Utiliza los mismos servicios REST indicados anteriormente.
GET a /users/{username}/profile, para acceder a sus datos de
perfil de usuario
GET a /activities en caso de que el usuario que ha iniciado sesión
solo tenga el rol de estudiante, puesto que en la página de inicio se
muestran las actividades del usuario
Se encuentra implementado en el controlador ClientController.
5.9.8. Cierre de la iteración 8
Hemos podido completar con éxito la octava iteración de nuestro proyecto
completando los 37 puntos de historia que correspondían a la misma.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
123
Escuela Politécnica Superior de Jaén
5.10. Iteración 9
5.10.1. Análisis
Poco a poco vamos llegando al final de nuestro proyecto. Nos situamos
en la iteración 9, en la cual vamos a seguir con la misma velocidad de trabajo
que hemos llevado hasta ahora de 37 puntos de historia por iteración. Para que
esto se cumpla una vez más en esta iteración, es necesario que llevemos a cabo
las siguientes historias de usuario.
Página para visualizar perfil de usuario (5 p.h.)
Formulario de edición de perfil (5 p.h.)
Formulario de edición de contraseña (5 p.h.)
Página para visualizar usuarios (5 p.h.)
Página para ver detalles de usuario (5 p.h.)
Formulario de edición de usuario (8 p.h.)
Formulario de cambio de contraseña (3 p.h.)
Página para visualizar actividades (5 p.h.)
Como podemos ver, estas historias de usuario suman un total de 41
puntos de historia, por lo que para seguir con lo planeado, necesitamos llevar
a cabo las 7 primeras y una parte de la última.
5.10.2. Página para visualizar perfil de usuario
Se trata de una vista, mediante la cual un usuario puede ver los datos de
su perfil.
Los servicios REST que utiliza son:
GET a /users/{username}/roles para mantener sus roles
actualizados en el sistema
GET a /users/{username}/profile, para acceder a sus datos de
perfil de usuario y pasarlos a la vista para el usuario pueda
visualizarlos.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
124
Escuela Politécnica Superior de Jaén
Se encuentra implementado en el controlador ClientController.
5.10.3. Formulario de edición de perfil
Este es un formulario que nos permite editar nuestros datos de perfil de
usuario enviando dichos datos que se quieren modificar al servidor
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /users/{username}/profile, para acceder a sus datos de
perfil de usuario y pasarlos a la vista para el usuario pueda
visualizarlos.
GET a /users/{username}, para ccomprobar si un nombre de
usuario existe. Este servicio REST no lo hemos plasmado antes,
así que lo hacemos aquí.
Comprobar si existe nombre de usuario
URL /users/{username}
HTTP Method GET
Consumes -
Produces application/json
RequestBody -
ResponseEntity Boolean
Tabla 41: Servicio REST Comprobar si existe nombre de usuario
Este servicio se encuentra implementado en el controlador del
servidor ResourceCentralControllerAll, que recordamos que era
el controlador al que cualquier usuario podía acceder, incluso lo
que no estuviesen en el sistema.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
125
Escuela Politécnica Superior de Jaén
PUT a /users/{idUser} para llevar a cabo la actualización de los
datos de usuario siempre que sea posible.
Se encuentra implementado en el controlador ClientController.
5.10.4. Formulario de edición de contraseña
Se trata de un formulario que permitirá a un usuario modificar su
contraseña en el sistema. El usuario tiene que introducir su contraseña actual, y
2 veces la nueva contraseña.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
PUT a /users/profile para actualizar su contraseña en el sistema
Se encuentra implementado en el controlador ClientController.
5.10.5. Página para visualizar usuarios.
Se trata de una vista donde se listan todos los usuarios que hay en el
sistema. La vista también tiene un buscador por texto.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /users para obtener el listado de todos los usuarios del
sistema y pasarlos a la vista posteriormente.
Esto se encuentra implementado en el AdminController puesto que el
administrador es el único que puede acceder a todos los usuarios del sistema.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
126
Escuela Politécnica Superior de Jaén
5.10.6. Página para ver detalles de usuario.
En esta vista, el administrador podrá ver la información de un usuario
concreto del sistema.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /users/{username} para obtener los datos de un usuario
concreto y pasarlos a la vista.
Al igual que sucedía en la anterior historia de usuario, esto se encuentra
implementado en el AdminController puesto que el administrador es el único
que puede acceder a todos los usuarios del sistema.
5.10.7. Formulario de edición de usuario
Este se trata de un formulario, con el que el administrador del sistema
puede modificar los datos de perfil de cualquier otro usuario del sistema.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /users/idUser/{idUser} para coger los datos actuales del
usuario que quiere modificar y plasmarlos en el formulario.
GET a /users/{username} para comprobar s el nuevo nombre de
usuario que quiere introducir en el sistema existe ya o no.
PUT a /users/{idUser} para completar la edición del usuario.
Al igual que sucedía en la anterior historia de usuario, esto se encuentra
implementado en el AdminController puesto que el administrador es el único
que puede editar cualquier usuario del sistema.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
127
Escuela Politécnica Superior de Jaén
5.10.8. Formulario de cambio de contraseña
Este es un formulario con el que el administrador puede modificar la
contraseña de cualquier otro usuario sin necesidad de conocer la antigua. Para
realizar esto necesitará introducir la nueva contraseña a establecer 2 veces
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /users/idUser/{idUser} para obtener datos del usuario y
mostrarlos en la vista.
PUT a users/password para editar la contraseña de un usuario
Este servicio REST tampoco ha sido mostrado antes, por lo que lo
hacemos en este apartado.
Editar contraseña de usuario
URL /users/password
HTTP Method PUT
Consumes application/json
Produces -
RequestBody NewUser
ResponseEntity String
Tabla 42: Servicio REST Editar contraseña de usuario
Este servicio REST se encuentra en el servidor en el controlador
ResourceCentralControllerAdmin puesto que solo el
administrador puede cambiar las contraseñas a otros usuarios.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
128
Escuela Politécnica Superior de Jaén
Al igual que sucedía en la anterior historia de usuario, esto se encuentra
implementado en el AdminController puesto que el administrador es el único
que puede editar cualquier usuario del sistema.
5.10.9. Cierre de la iteración 9
En esta iteración, hemos podido completar un total de 7 historias de
usuario con un total de 36 puntos de historia completados. Aunque no hemos
podido completar los 37 se nuestra velocidad no pasa nada puesto que íbamos
adelantados en la planificación, Así que continuaremos con la misma velocidad
de trabajo.
5.11. Iteración 10
5.11.1. Análisis
En esta iteración como ya hemos dicho antes, vamos a continuar con la
velocidad ágil impuesta hasta ahora de 37 puntos de historia por iteración. Para
llevar a cabo esto, va a ser necesario realizar las siguientes historias de usuario.
Página para visualizar actividades (5 p.h.)
Formulario para editar actividades (5 p.h.)
Página para visualizar objetivos (5 p.h.)
Formulario de edición de objetivos (3 p.h.)
Página para listar tandas de tickets (5 p.h.)
Formulario de edición de tandas (8 p.h.)
Página para visualizar tickets con QR (13 p.h)
Como podemos ver, las historias de usuario que hemos establecido
suman más de 37 puntos de historia. Concretamente suman 44 puntos de
historia. Esto quiere decir, al igual que ya nos ha sucedido antes, que de la última
historia de usuario, solo estamos obligados a desarrollar una parte de ella, y el
resto, será realizado en la siguiente iteración.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
129
Escuela Politécnica Superior de Jaén
5.11.2. Página para visualizar actividades
Se trata de una vista con la que los usuarios podrán ver sus actividades
en el sistema. Dependiendo del rol que ocupe, mostrará lo siguiente como ya
comentamos en otros apartados
Para los administradores, mostrará todas las actividades
Para los profesores, mostrará las actividades de las que ese
usuario es profesor
Para los estudiantes mostrará las actividades de las que ese
usuario es estudiante.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /activities para obtener las actividades que a cada usuario
le corresponda
Esto se encuentra implementado AdminController, TeacherController y
StudentController para que cada uno haga la petición al servidor el rol mediante
el que lo quiere hacer.
5.11.3. Formulario para editar actividades
Este es un formulario mediante el cual se podrá editar una actividad del
sistema. Se podrá modificar el nombre, así como el número de usuarios a los
cuales se les permite matricularse en la misma.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /activities/id/{idActivity} para obtener los datos actuales
de la actividad que se quiere editar y pasarlos a la vista.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
130
Escuela Politécnica Superior de Jaén
PUT a /activities/{idActivity} para actualizar los datos de la
actividad.
Esto se encuentra implementado AdminController, TeacherController,
ya que ambos pueden editar actividades.
5.11.4. Página para visualizar objetivo
Esta es una página para visualizar los objetivos de una actividad.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /activities/{activityName}/objetives para obtener la lista
de los objetivos pertenecientes a una actividad e mostrarlos en la
vista
Esto se encuentra implementado AdminController, TeacherController,
y StudentController ya que todos pueden ver los objetivos de sus actividades.
5.11.5. Formulario de edición de objetivos
Se trata de un formulario que nos permite modificar el nombre de un
objetivo concreto si es que así lo queremos.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /objectives/{idObjective} para obtener los datos actuales
del objetivo que se quiere editar, entre ellos el nombre.
PUT a /objectives/{idObjective} para llevar a cabo la edición del
objetivo.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
131
Escuela Politécnica Superior de Jaén
Esto se encuentra implementado AdminController, TeacherController,
ya que ambos pueden editar objetivos.
5.11.6. Página para listar tandas de tickets
Esta es una vista mediante la que podemos listar las tandas de tickets que
tiene un objetivo concreto.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /objectives/{idObjective}/batches para obtener un listado
con las tandas de tickets de un objetivo concreto
GET a /objectives/{idObjective} para acceder a los datos del
objetivo para poder pasárselos a la vista.
Esto se encuentra implementado AdminController, TeacherController,
ya que ambos pueden ver las tandas de tickets que tienes sus actividades.
5.11.7. Formulario de edición de tandas
Este es un formulario con el que podemos editar las tandas de los tickets.
Se podrá editar el título de la tanda, el número de Canjeos por ticket que voy a
permitir y la fecha de validez de los tickets de dicha tanda.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /batches/{idBatch} para obtener los datos actuales de la
tanda que vamos a editar
GET a /batches/{idBatch}/validity para conocer la fecha de
validez de la tanda. Esto lo hacemos porque la fecha de validez de
la tanda no la almacena la tanda en sí, sino que es almacenada por
cada uno de los tickets de dicha tanda.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
132
Escuela Politécnica Superior de Jaén
GET a /batches/{idBatch}/posiblesExchanges para obtener el
número actual de Canjeos de la tanda. Al igual que antes, este dato
es almacenado por los tickets de la tanda.
PUT a /batches/{idBatch} para modificar los datos de una tanda
Esto se encuentra implementado AdminController, TeacherController,
ya que ambos pueden modificar las tandas de tickets de sus actividades.
5.11.8. Cierre de la iteración 10
En esta iteración solo hemos podido completar las 6 primeras historias de
usuario y nada de la última historia Página para visualizar tickets con QR
debido a que nos han surgido complicaciones en la historia de usuario
Formulario de editar tandas a la hora de parsear fechas, lo que nos ha
provocado que tardemos más tiempo en implementarlo del esperado.
En la planificación esto no tiene ningún efecto debido a que como nuestra
velocidad era mayor de la necesaria a la hora de afrontar las iteraciones, hemos
llegado a las iteraciones finales con más margen de maniobra y tardar más en la
anterior historia de usuario es un lujo que nos podemos permitir.
Recapitulando, nos quedan 61 puntos de historia por terminar con la
implementación de nuestro proyecto para un total de 2 iteraciones, así que
podemos seguir con la misma dinámica llevada hasta ahora con la velocidad ágil,
y mantenerla en 37 puntos de historia por iteración, aunque llegaremos a la
última iteración más desahogados.
5.12. Iteración 11
5.12.1. Análisis
En esta iteración vamos a mantener la velocidad de 37 puntos de historia
por iteración. Para llevar a cabo esto, va a ser necesario que se completen las
siguientes historias de usuario.
Página para visualizar tickets con QR (13 p.h.)
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
133
Escuela Politécnica Superior de Jaén
Página para listar tickets (5 p.h.)
Página de detalles de un ticket (8 p.h.)
Página de ranking por objetivo (8 p.h)
Página de ranking por actividad (8 p.h.)
Como podemos observar, estas historias de usuario suman un total de 42
puntos de historia, por lo que para llevar a cabo la iteración a nuestra velocidad,
sería necesario completar las 4 primeras historias de usuario, y una parte de la
última.
5.12.2. Página para visualizar tickets con QR
Esta es una vista en la que solo aparecen estructurados en 2, 3, 4, o 6
columnas, una lista con los tickets, con sus correspondientes códigos QR, para
que el usuario pueda generar una vista de impresión de los mismos.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /batches/{idBatch}/tickets para obtener un listado con los
tickets de una tanda concreta.
GET a /batches/{idBatch}/objective para obtener los datos del
objetivo de la tanda de tickets, y usar la información para mostrarla
en la vista
GET a /objectives/{idObjective}/activity para obtener datos de la
actividad de la tanda de tickets y usar la información para mostrarla
en la vista.
Esto se encuentra implementado AdminController, TeacherController,
ya que ambos pueden acceder a los tickets pertenecientes a las tandas de tickets
de sus actividades.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
134
Escuela Politécnica Superior de Jaén
5.12.3. Página para listar tickets
Esta vista nos permite obtener un listado de los tickets, pero en esta
ocasión lo que visualiza es la información de los tickets, para poder
posteriormente acceder a sus detalles.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /batches/{idBatch}/tickets para obtener un listado con los
tickets de una tanda concreta.
GET a /batches/{idBatch} para obtener información de la tanda de
tickets y pasársela a la vista para que la utilice.
GET a /objectives/{idObjective} para obtener datos del objetivo al
que pertenece la tanda, y pasársela a la vista para que la utilice.
Esto se encuentra implementado AdminController, TeacherController,
ya que ambos pueden acceder a los tickets pertenecientes a las tandas de tickets
de sus actividades.
5.12.4. Página de detalles de un ticket
Esta vista nos permitirá ver los detalles de un ticket concreto (fecha de
validez, número de Canjeos posibles, número de Canjeos realizados, id del
ticket, un pequeño código QR e incluso un listado con los usuarios que han
canjeado el ticket y la fecha)
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /batches/{idBatch} para obtener información de la tanda de
tickets y pasársela a la vista para que la utilice.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
135
Escuela Politécnica Superior de Jaén
GET a /objectives/{idObjective} para obtener datos del objetivo al
que pertenece la tanda, y pasársela a la vista para que la utilice.
GET a /tickets/{idTicket} para obtener los detalles del ticket
concreto
GET a /tickets/{idTicket}/exchanges para obtener un listado con
los Canjeos que se han hecho a ese ticket y pasárselo a la vista.
Esto se encuentra implementado AdminController, TeacherController,
ya que ambos pueden acceder a los tickets pertenecientes a las tandas de tickets
de sus actividades.
5.12.5. Página de ranking por objetivo
Esta vista nos permitirá ver un ranking de un objetivo concreto, en el cual
se muestra el nombre de un usuario y al lado el número de tickets que ese
usuario tiene en ese objetivo.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /objectives/{idObjective}/ranking para obtener el ranking
de un objetivo concreto
GET a /objectives/{idObjective} para obtener datos del objetivo,
y pasársela a la vista para que la utilice.
Esto se encuentra implementado AdminController, TeacherController y
StudentController ya que todos acceden a algún tipo de ranking. Los
administradores pueden acceder al ranking de cualquier objetivo. Los profesores
pueden acceder al ranking de los objetivos que pertenecen a las actividades de
las que es profesor y los estudiantes pueden acceder al ranking de sus
actividades.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
136
Escuela Politécnica Superior de Jaén
5.12.6. Página de ranking por actividad
Esta vista nos permitirá ver un ranking de una actividad concreta, en el
cual se muestra el nombre de usuario y al lado el número de tickets que ese
usuario tiene en esa actividad.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /activities/{activityName}/ranking para obtener el ranking
de una actividad concreta.
Esto se encuentra implementado AdminController, TeacherController y
StudentController ya que todos acceden a algún tipo de ranking de actividad.
Los administradores pueden acceder al ranking de cualquier actividad. Los
profesores pueden al ranking de las actividades de las cuales ellos son
profesores y los estudiantes pueden acceder al ranking de sus actividades.
5.12.7. Cierre de la iteración número 11
En esta iteración hemos completado los 37 puntos de historia que
teníamos pensado completar, sin embargo parece que hemos completado todas
las historias de usuario. Eso no ha sido así, puesto que hemos completado las
4 primeras iteraciones, y solo una parte de la quinta iteración Página de ranking
por actividad, sin embargo, la hemos documentado aquí por completo para no
dividir la información de una historia de usuario.
En la siguiente iteración, hay que completar 5 puntos de historia que no
se han completado en esta iteración de dicha historia de usuario.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
137
Escuela Politécnica Superior de Jaén
5.13. Iteración 12
5.13.1. Análisis
Estamos ante la última iteración de nuestra planificación. Aquí ya no
hablamos de velocidad de trabajo ni nada, puesto que ya vamos a completar las
historias de usuario que nos quedan.
Página de ranking por actividad (13 p.h. de los que tenemos
que completar 5 p.h.)
Página de Canjeos de un usuario (3 p.h.)
Página de profesores de una actividad (5 p.h.)
Página para añadir profesor a una actividad (8 p.h.)
Formulario de canjeo de un ticket (3 p.h.)
Como podemos ver, solo nos quedan por realizar 24 puntos de historia
para completar el proyecto. Recordamos que de la historia de usuario Página de
ranking por actividad, no vamos a documentar nada aquí debido a que ya lo
hemos hecho antes.
5.13.2. Página de Canjeos de un usuario
Esta es una vista con la que podemos ver los Canjeos que un usuario ha
realizado, ya sea en una actividad, o en un objetivo. Depende desde donde
solicitemos esta vista.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /users/{idUser}/activities/{activityName}/exchanges
para obtener los Canjeos de una actividad, en el caso de que
solicitemos esta vista desde el ranking de actividad.
GET a /users/{username} para obtener datos del usuario al que
pertenecen los Canjeos, y pasarle dichos datos a la vista para que
los utilice.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
138
Escuela Politécnica Superior de Jaén
GET a /users/{idUser}/objectives/{idObjective}/exchanges para
obtener los Canjeos de un objetivo, en el caso de que solicitemos
esta vista desde el ranking de un objetivo.
GET a /objectives/{idObjective} para obtener datos del objetivo,
y pasársela a la vista para que la utilice, al igual que antes, en el
caso de que solicitemos esta vista desde el ranking de un objetivo.
Esto se encuentra implementado AdminController, TeacherController y
StudentController ya que todos acceden a ver los Canjeos de alguien. Los
administradores pueden acceder a los Canjeos de cualquier actividad u objetivo.
Los profesores pueden a los Canjeos de las actividades de las que son
profesores y los estudiantes pueden acceder a sus propios Canjeos.
5.13.3. Página de profesores de una actividad
En esta vista podemos ver los profesores que forman parte de una
actividad.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /activities/{activityName}/teachers para obtener el listado
de profesores pertenecientes a una actividad concreta y pasárselo
a la vista.
Esto se encuentra implementado AdminController, TeacherController y
StudentController ya que todos pueden acceder al listado de profesores
pertenecientes a sus actividades.
5.13.4. Página para añadir profesor a una actividad
Esta es una página con la que se puede añadir un profesor a una
actividad. Esta página lista los profesores existentes en el sistema, que no son
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
139
Escuela Politécnica Superior de Jaén
profesores de dicha actividad, y en caso de que se pulse un botón, se añade a
dicha actividad como profesor de la misma.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
GET a /users/teacherForActivity/{activityName} para obtener un
listado con los profesores del sistema que no pertenecen a esa
asignatura.
Una vez en la vista, si se pulsa para algún profesor, el botón
correspondiente para añadir a la actividad, se utiliza el siguiente servicio REST
PUT a /activities/{activityName}/teachers, para añadirlo a la
actividad.
5.13.5. Formulario de canjeo de un ticket.
Este es un formulario con el que podremos canjear un ticket en el sistema.
Los servicios REST que utiliza son los siguientes:
GET a /users/{username}/roles para mantener los roles del
usuario activo actualizados en el sistema.
POST a /exchanges para intentar llevar a cabo en el servidor el
canjeo de un ticket.
GET a /tickets/{idTicket}/actividad para obtener datos de la
actividad a la que pertenece el ticket, y pasarlos a la vista.
5.13.6. Cierre de la iteración 12
En esta iteración 24 puntos de historia cumpliendo con los plazos del
proyecto, terminando la implementación del mismo. Con esto damos por
concluidas todas las iteraciones.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
140
Escuela Politécnica Superior de Jaén
6. Manual y funcionalidad de la aplicación
En primer lugar, al acceder a la aplicación tendrá un formulario para iniciar
sesión, y podrá acceder a registrarse en el caso de que sea necesario
Ilustración 62: Pantalla de inicio de sesión
Si es un usuario que se acaba de registrar, al acceder a la aplicación
tendrá una vista de la interfaz como la que veremos a continuación, puesto que
solo tendría el rol de estudiante sin estar matriculado en ninguna actividad.
Ilustración 63: Pantalla de inicio de un usuario nuevo en el sistema
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
141
Escuela Politécnica Superior de Jaén
NOTA: El resto de este Manual se llevará a cabo desde un usuario que
tenga los 3 roles (Administrador, Profesor y Estudiante) para que sea más
sencillo llevar a cabo.
La pantalla de inicio de este usuario sería la siguiente:
Ilustración 64: Pantalla de inicio de un usuario con os 3 roles
Este usuario tiene perfectamente divididas las opciones que puede llevar
a cabo con los distintos roles.
A continuación veremos que pulsando arriba a la derecha en el nombre
de usuario, en este caso Carlos > Perfil, podremos ver el perfil del usuario
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
142
Escuela Politécnica Superior de Jaén
Ilustración 65: Pantalla de perfil de usuario
Una vez nos situamos aquí, tenemos varias opciones. En primer lugar
podemos darle al botón Editar perfil con el que podremos acceder a un
formulario para editar nuestro perfil de usuario (Ilustración 66) o podemos pulsar
la opción Cambiar a la derecha de Contraseña donde podremos acceder a un
formulario para cambiar nuestra contraseña de acceso. (Ilustración 67)
Ilustración 66: Formulario para editar perfil
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
143
Escuela Politécnica Superior de Jaén
Ilustración 67: Formulario para editar contraseña
A continuación, siendo administrador, desde la página de inicio
(Ilustración 64) o desde la barra de la izquierda en el desplegable Admin,
podemos acceder a la opción Usuarios que serían todos los usuarios del
sistema.
Ilustración 68: Pantalla de Usuarios del sistema
En este apartado, podemos manipular las características de los diferentes
usuarios del sistema. Si pulsamos la opción Borrar en un usuario, se borrará
todo rastro del usuario en el sistema. Si pulsamos la opción Ver detalles,
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
144
Escuela Politécnica Superior de Jaén
podremos ver los datos de perfil de ese usuario (Ilustración 65).Al igual que
sucedía antes, tenemos las opciones de editar el perfil del usuario, opción a la
que accederemos pulsando el botón Editar usuario, y se nos mostrará un
formulario para editar el perfil de ese usuario, pero ligeramente diferente al de
editar nuestro propio perfil, es decir, porque al ser administradores, también
podremos asignar y quitar los diferentes Roles a ese usuario.
Ilustración 69: Formulario para editar usuario
Desde los datos del usuario (Ilustración 65) y al igual que sucedía con el
perfil de usuario, podremos cambiar la contraseña de ese usuario pulsando en
Cambiar a la derecha de Contraseña y nos aparecería un formulario como el
de la Ilustración 67 con la diferencia que en este no aparecerá para introducir
la Contraseña actual.
A continuación, siendo administrador, desde la página de inicio
(Ilustración 64) o desde la barra de la izquierda en el desplegable Admin,
podemos acceder a la opción Actividades que serían todas las actividades del
sistema.
NOTA: Todo lo que llevemos a cabo en las actividades como
administradores, lo podrán realizar también los profesores con la salvedad de
que los administradores pueden hacerlo con todas las actividades del sistema, y
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
145
Escuela Politécnica Superior de Jaén
los profesores solo con las actividades de las que son profesores. Debido a esto,
NO EXPLICAREMOS DESPUÉS LO QUE HACEN LOS PROFESORES EN
LAS ACTIVIDADES ya que sería información redundante.
Ilustración 70: Pantalla de Actividades del sistema
Estando en esta pantalla, podemos crear una nueva actividad pulsando
en la opción Nueva Actividad donde nos aparecerá un formulario para crear la
actividad.
Ilustración 71: Pantalla para crear una actividad.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
146
Escuela Politécnica Superior de Jaén
Estando de nuevo en el listado de actividades (Ilustración 70) podemos
pulsar en la opción Editar actividad donde nos aparecerá un formulario muy
parecido al de la Ilustración 71 donde podremos editar dicha actividad.
Estando en el listado de actividades (Ilustración 70), si pulsamos el botón
de Usuarios de color rosa, accederemos al listado de usuarios del sistema, que
también es el ranking de la actividad, en el que aparecen los nombres de los
usuarios, con el número de tickets canjeados y la opción de eliminarlos de la
actividad.
Ilustración 72: Pantalla usuarios de una actividad
Una vez en esta pantalla, podemos ver que tickets ha canjeado cada
usuario, y cuando, pulsando en el número de tickets que hay al lado del nombre
de cada usuario.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
147
Escuela Politécnica Superior de Jaén
Ilustración 73: Pantalla Canjeos en una actividad de un usuario
Como ya hemos dicho, estando en la pantalla de usuarios de una
actividad (Ilustración 72) si pulsamos la opción de Eliminar de la actividad, el
usuario es eliminado de la actividad, de tal forma que no podrá ver los detalles
de la actividad hasta que canjee otro ticket, pero seguirá siendo visible en el
ranking.
De nuevo nos situamos en el listado de actividades (Ilustración 70). Si
pulsamos la opción de Eliminar, se eliminará por completo la actividad del
sistema. Ahora accedemos a la opción Profesores. Cuando pulsamos esta
opción, se nos listan los profesores de esa actividad.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
148
Escuela Politécnica Superior de Jaén
Ilustración 74: Pantalla profesores de una actividad
Si pulsamos la opción Eliminar de la actividad ese profesor dejará de
serlo de esa actividad.
También podemos añadir un profesor a la misma pulsando en la opción
Añadir profesor a la actividad, donde nos aparecerá un listado de los
profesores del sistema, y nos los listará para poder añadirlos.
Ilustración 75: Pantalla añadir profesor a una actividad.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
149
Escuela Politécnica Superior de Jaén
En el caso de que pulsáramos la opción de Añadir para algún profesor,
aparecería en la Ilustración 74.
De nuevo nos situamos en la página del listado de actividades
(Ilustración 70). Si pulsamos la opción Objetivos nos aparecerá un listado con
los objetivos de esa actividad como vemos a continuación.
Ilustración 76: Pantalla listado de objetivos.
Aquí vemos ese listado de objetivos. Si pulsamos en la opción Nuevo
objetivo, nos aparecerá un formulario para añadir un objetivo a la actividad.
Ilustración 77: Formulario añadir objetivo.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
150
Escuela Politécnica Superior de Jaén
De nuevo nos situamos en el listado de objetivos (Ilustración 76). Si
pulsamos la opción de Editar, aparecerá un formulario exactamente igual que el
de la ilustración 77 para poder editar el nombre del objetivo. Si pulsamos la
opción de Borrar podremos borrar el objetivo por completo.
También podemos acceder a la opción Ranking, donde nos aparecerá el
ranking pero solamente de ese objetivo en concreto.
Ilustración 78: Página de ranking de un objetivo.
Al igual que sucedía con el ranking de una actividad (Ilustración 72), si
pulsamos el número de tickets de un usuario, al igual que antes nos llevará a los
Canjeos de ese usuario en ese objetivo. (Ilustración 73).
De nuevo nos situamos en el listado de objetivos (Ilustración 76). Si
pulsamos la opción Tandas Tickets, accederemos al listado de tandas de tickets
que tiene ese objetivo.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
151
Escuela Politécnica Superior de Jaén
Ilustración 79: Página del listado de tandas de tickets.
Una vez aquí, si pulsamos la opción Nueva tanda de tickets, se abrirá un
formulario para la creación de una nueva tanda de tickets.
Ilustración 80: Formulario de creación de tandas de tickets.
Nos situamos de nuevo en el listado de tandas (Ilustración 79). Si
pulsamos la opción de Editar nos aparecerá un formulario igual que el anterior
para poder editar la tanda. Si pulsamos la opción de Borrar se eliminará por
completo la tanda de tickets.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
152
Escuela Politécnica Superior de Jaén
Si pulsamos la opción Ver tickets, nos mostrará una vista con los códigos
QR de esa tanda, para poder imprimirlos. Esa vista mostrará los QR en 2, 3, 4 o
6 columnas según se lo indique el usuario. A continuación se lo mostramos con
columnas de 3 tickets
Ilustración 81: Página de listado de códigos QR
Nos situamos de nuevo en el listado de tandas (Ilustración 79). Si
pulsamos la opción de Listado sobre una tanda, nos aparecerá un listado con
los tickets de la tanda. De cada ticket se podrá ver su identificador, el estado del
ticket (Canjeado, Caducado, Sin Canjear, etc…) y una opción para ver los
detalles del ticket.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
153
Escuela Politécnica Superior de Jaén
Ilustración 82: Página de listado de tickets
Estando en esta pantalla, si pulsamos en la opción de Ver Detalles,
podremos ver los detalles del ticket como su fecha de caducidad, quien lo ha
canjeado, los Canjeos posibles, los Canjeos actuales, etc…
Ilustración 83: Página de detalles de un ticket
A continuación ilustraremos como un usuario lleva a cabo un
canjeo.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
154
Escuela Politécnica Superior de Jaén
En primer lugar, el usuario escanea un ticket con su escáner de QR. Ese
ticket que ha escaneado le redirigirá a una URL en su navegador, la cual si
está identificado, le permitirá acceder directamente a la pantalla de canjeo de
un ticket que es la siguiente.
Ilustración 83: Página de detalles de un ticket
Una vez hecho esto, hay que darle al botón de Canjear ticket. Si el
canjeo del ticket es correcto, te redirigirá a la pantalla del ranking de la
actividad, aunque para los estudiantes es diferente a los profesores y
administradores, puesto que no aparece la opción de Eliminar de la actividad.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
155
Escuela Politécnica Superior de Jaén
Ilustración 83: Página de ranking de actividad para estudiantes
Pulsando en su número de tickets, podrán acceder a sus Canjeos en esa
actividad.
Para ilustrar el funcionamiento de la aplicación de forma más dinámica,
he creado un pequeño video en el que, aunque un poco rápido, se ilustra lo que
el software es capaz de hacer y lo que hemos explicado aquí.
Puede verlo aquí:
https://www.youtube.com/watch?v=4IrKb16G1XE&feature=youtu.be
7. Conclusiones finales del proyecto y planes futuros
Con este proyecto como mencionamos al principio de este documento,
queríamos desarrollar una herramienta de apoyo a la docencia con el objetivo de
que los alumnos que la usen se impliquen en las asignaturas de forma dinámica
y divertida, consiguiendo cierto reconocimiento o recompensa por el trabajo
realizado día a día, algo que no es generalmente visible debido a que en estos
niveles de estudios tan superiores se suele valorar muchísimo más lo que se
hace en un examen final que lo que un alumno trabaja o se esfuerza durante un
periodo de tiempo más amplio. Una herramienta de este tipo, puede ayudar a
docentes a seguir de una manera más fácil y personalizada teniendo en cuenta
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
156
Escuela Politécnica Superior de Jaén
que el volumen de alumnos que puede tener puede ser enorme y esto sería difícil
llevarlo a cabo de otra forma. También puede ayudar a un estudiante a
monitorizar su progreso en una determinada actividad, y algo muy importante
como compararlo con el progreso de los demás, y a la misma vez sentirse
motivado sabiendo que progresa y que se tiene en cuenta ese progreso.
En cuanto a mi experiencia personal con este proyecto, creo que he
adquirido, o reforzado unos conocimientos y una experiencia que me puede ser
muy útil en el ámbito laboral trabajando en proyectos informáticos reales.
También he aprendido en la enorme importancia del trabajo en equipo a la hora
de que un proyecto tenga éxito. Que no se me malinterprete. He llevado a cabo
el desarrollo de este proyecto desde 0 y en solitario (o más bien con la
inestimable ayuda de mi tutor), y precisamente por eso se valora un grupo de
personas que te puede aportar mucho conocimiento que antes no poseías.
Gracias a consultas sobre cómo llevar a cabo alguna tarea realizadas a
profesores y compañeros de la facultad, he podido aprender multitud de cosas
de las que antes no tenía ni idea, además de permitirme solucionar problemas
serios en mi proyecto, en los cuales te atascas y a pesar de lo sencillo que pueda
llegar a ser, el simple hecho de no conocer cómo se lleva a cabo, te puede
complicar mucho la vida. Ahí es cuando echas en falta gente con otros
conocimientos y otras formas de enfocar las cosas.
En planos generales me siento muy satisfecho por el software realizado,
el cual ha ocupado una gran parte de mi tiempo este curso académico, aunque
me hubiese gustado tener mucho más tiempo para llevar a cabo una mejor
documentación del mismo.
En lo que se refiere a planes de futuro, siendo sincero, me gustaría que si
se llega a implantar el software de forma funcional para alguna institución, poder
estar implicado de alguna forma en su mantenimiento y ampliación. No
recordemos que esto no es más que un prototipo de lo que podría llegar a ser, y
en un futuro me gustaría implantar algunos elementos como:
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
157
Escuela Politécnica Superior de Jaén
Un sistema de notificaciones cuando un profesor mete a otro profesor
en una actividad, o cuando se te asigna un rol que antes no tenías.
También me hubiese gustado implantar ciertas medidas de seguridad,
como por ejemplo que cuando un usuario intente iniciar sesión en el
sistema y cometa unos cuantos errores, se bloquee la IP de durante
un tiempo.
Poner un log en el servidor que registre cualquier acción que se lleva
a cabo, algo que sería útil para la detección de errores
Algo que estaría muy bien sería la posibilidad de cambiar el tipo de
billete para los tickets
Como conclusión final, decir que estoy muy contento de haber realizado
concretamente este proyecto y con este tutor, que a pesar de sus momentos
malos donde crees que nada te va a salir, no solo acabas saliendo, sino que en
el proceso aprendes algo más, que es lo más importante.
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
158
Escuela Politécnica Superior de Jaén
Referencias
[1] Apuntes asignatura Desarrollo de aplicaciones web
[2] Apuntes de la asignatura Desarrollo de aplicaciones empresariales
[3] Gamificación: el aprendizaje divertido. http://www.educativa.com/blog-
articulos/gamificacion-el-aprendizaje-divertido/
[4] Herramientas de Gamificación.
http://www.educaciontrespuntocero.com/recursos/herramientas-gamificacion-
educacion/33094.html
[5] Spring Framework. https://projects.spring.io/spring-framework/
[6] Scrum Methodology. http://scrummethodology.com/
[7] Hibernate and UUID identifiers.
https://vladmihalcea.com/2014/07/01/hibernate-and-uuid-identifiers/
[8] Hibernate. http://hibernate.org/orm/
[9] JPA. Native Queries. https://www.thoughts-on-java.org/jpa-native-
queries/
[10] Bootstrap. http://getbootstrap.com/
[11] AdminLTE. https://adminlte.io/
[12] QR codes with jquery.
http://www.codesynthesis.co.uk/tutorials/generating-qr-codes-with-jquery
[13] jquery qrcode Plugin. https://github.com/jeromeetienne/jquery-
qrcode
[14] Session Object Spring MVC. http://www.javaroots.com/2013/08/how-
to-get-session-object-in-spring-mvc.html
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
159
Escuela Politécnica Superior de Jaén
[15] Scope Session Spring
http://richardchesterwood.blogspot.com.es/2011/03/using-sessions-in-spring-
mvc-including.html
[16] HttpClient with SSL. http://www.baeldung.com/httpclient-ssl
[17] Basic authentication with RestTemplate.
http://www.baeldung.com/how-to-use-resttemplate-with-basic-authentication-in-
spring
[18] SSL Client with Spring Boot.
https://stackoverflow.com/questions/30770280/spring-boot-ssl-client
[19] Securing your Tomcat App With SSL and Spring security.
https://technet.microsoft.com/es-es/library/dd351057(v=exchg.160).aspx
[20] RestTemplate HTTPS.
https://stackoverflow.com/questions/17619871/access-https-rest-service-using-
spring-resttemplate
[21] Derby DataBase. https://db.apache.org/derby/
[22] Visual Paradigm. https://www.visual-paradigm.com/
[23] https://stackoverflow.com/questions/39333079/jstl-loop-counter-3-
increment
[24] JAR in Maven.
https://stackoverflow.com/questions/17693040/adding-external-jar-to-maven-
project-in-netbeans
[25] Date object to Calendar Object.
https://stackoverflow.com/questions/6185966/converting-a-date-object-to-a-
calendar-object
[26] RequestParam vs PathVariable.
https://stackoverflow.com/questions/13715811/requestparam-vs-pathvariable
Carlos Jesús Serrano Martínez Proyecto Gamificación UJA
160
Escuela Politécnica Superior de Jaén
[27] HttpClient Basic Authentication.
https://stackoverflow.com/questions/9402653/apache-httpclient-4-1-and-newer-
how-to-do-basic-authentication
[28] Datatimepicker.
https://stackoverflow.com/questions/19382189/change-language-for-bootstrap-
datetimepicker
[29] Exception BAD REQUEST.
https://stackoverflow.com/questions/38019212/org-springframework-web-client-
httpclienterrorexception-400-bad-request
[30] List in JSON RestTemplate.
https://stackoverflow.com/questions/23674046/get-list-of-json-objects-with-
spring-resttemplate
[31] Expresiones Regulares en java con Split.
http://puntocomnoesunlenguaje.blogspot.com.es/2013/07/ejemplos-
expresiones-regulares-java-split.html
[32] Spring redirect with variables.
https://stackoverflow.com/questions/19280718/spring-mvc-redirect-with-
variables