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


Universidad 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


4


Í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


5


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


6


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


7


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


8


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.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.8. Iteración 7 ............................................................................ 109

5.8.1. Análisis .............................................................................. 109


9


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.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.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


10


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


11


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


13


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.


15


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.


16


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.


17


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


18


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.


19


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


20


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,


21


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.


22


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


23


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.


24


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

http://knowre.com/

https://kahoot.com/

https://codecombat.com/

https://www.classdojo.com/

http://www.classcraft.com/es/


25


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.


26


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.


27


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,


28


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,


29


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.


30


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.


31


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.


32


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.


33


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


34


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


35


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


36


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


37


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


38


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


39


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


40


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


41


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


42


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


43


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.


44


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.


45


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.


46


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


47


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


48


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


49


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


50


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


51


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


52


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.


53


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.


54


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.


55


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 €


56


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.


57


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.


58


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.


59


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.


60


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


61


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


62


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.


63


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


64


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


65


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


66


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.


67


Ilustración 19: Implementación de la clase UserDAO para acceso a BBDD


68


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


69


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


70


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.


71


Implementación de DTOs

UserDTO

Ilustración 21: Implementación de la clase UserDTO

ActivityDTO

Ilustración 22: Implementación de la clase ActivityDTO


72


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


73


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


74


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.


75


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


76


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.


77


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.


78


El servicio REST utilizado es el siguiente.

Obtener perfil de usuario

URL /users/{username}/profile

HTTP Method GET

Consumes -

Produces application/json

RequestBody -


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 -


RequestBody -


Tabla 11: Servicio REST Obtener usuario por username


79


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 -


RequestBody -


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.


80


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 -


RequestBody 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á.


81


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


Produces -

RequestBody NewUser

ResponseEntity String

Tabla 14: Servicio REST Editar contraseña.


82


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


Produces -

RequestBody NewUser


83



Tabla 15: Servicio REST Cambiar contraseña.


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


84


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


Produces -

RequestBody NewActivity


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


85


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.


86


Obtener actividad por nombre

URL /activities/{activityName}

HTTP Method GET

Consumes -


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 -


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.


87


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


Produces -

RequestBody ActivityDTO

ResponseEntity -

Tabla 19: Servicio REST Editar actividad


88


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


Produces -

RequestBody NewObjective


89


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.


90


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 -


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


91


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


92


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


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.


93


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


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


94


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.


95


Obtener tanda de tickets

URL /batches/{idBatch}

HTTP Method GET

Consumes -


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


96


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)


HTTP Method PUT


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.





comprobar que sea profesor de la actividad a la que pertenece la tanda que se

quiere editar.


97


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 -


RequestBody -

ResponseEntity TicketDTO

Tabla 26: Servicio REST Obtener Ticket






98


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


Produces -

RequestBody ExchangeDTO


Tabla 27: Servicio REST Canjear Ticket


99


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.


100


Ilustración 45: Diagrama de secuencia de Canjear ticket.


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


101


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.


102


Ranking de actividad

URL /activities/{activityName}/ranking

HTTP Method GET

Consumes -


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.


103


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 -


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.


104


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


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.


105


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.


106


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


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


107


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 -


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.


108


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 -


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.


109


Ilustración 51: Diagrama de secuencia Canjeos de Usuario en Objetivo


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


110


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 -


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.


111


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 -


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.


112


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


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.


113


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


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.


114


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 -


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.


115


Ilustración 56: Diagrama de secuencia Eliminar usuario


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.


116


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.


117


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


118


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 -



119


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 -


RequestBody -


120


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.


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


HTTP Method DELETE

Consumes -


RequestBody -


Tabla 40: Servicio REST Eliminar objetivo


121


También se eliminarán los tickets asociados a dicha tanda, así como los

Canjeos realizados con esos tickets.


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


122


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.


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.


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.


Hemos podido completar con éxito la octava iteración de nuestro proyecto

completando los 37 puntos de historia que correspondían a la misma.


123


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.


GET a /users/{username}/roles para mantener sus roles

actualizados en el sistema


perfil de usuario y pasarlos a la vista para el usuario pueda

visualizarlos.


124



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.


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 -


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.


125


PUT a /users/{idUser} para llevar a cabo la actualización de los

datos de usuario siempre que sea posible.


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.




PUT a /users/profile para actualizar su contraseña en el sistema


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.




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.


126


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.




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.




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.



que puede editar cualquier usuario del sistema.


127


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




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


Produces -

RequestBody NewUser


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.


128




que puede editar cualquier usuario del sistema.


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.


129


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.




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.




GET a /activities/id/{idActivity} para obtener los datos actuales

de la actividad que se quiere editar y pasarlos a la vista.


130


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.




GET a /activities/{activityName}/objetives para obtener la lista

de los objetivos pertenecientes a una actividad e mostrarlos en la

vista


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.




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.


131



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.




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.


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.




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.


132


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


ya que ambos pueden modificar las tandas de tickets de sus actividades.


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


133


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.




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.


ya que ambos pueden acceder a los tickets pertenecientes a las tandas de tickets

de sus actividades.


134


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.




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.



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)




GET a /batches/{idBatch} para obtener información de la tanda de

tickets y pasársela a la vista para que la utilice.


135


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.



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.




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.


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.


136


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.




GET a /activities/{activityName}/ranking para obtener el ranking

de una actividad concreta.


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.


137


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.




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.


138


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.


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.




GET a /activities/{activityName}/teachers para obtener el listado

de profesores pertenecientes a una actividad concreta y pasárselo

a la vista.


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


139


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.




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.




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.


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.


140


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


141


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


142


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


143


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,


144


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


145


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.


146


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.


147


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.


148


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.


149


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.


150


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.


151


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.


152


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.


153


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.


154


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.


155


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

https://www.youtube.com/watch?v=4IrKb16G1XE&feature=youtu.be


156


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:


157


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.


158


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


159


[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


160


[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

GAMIFICACIÓN UNIVERSITARIA Trabajo Fin de...

Documents

Transcript of GAMIFICACIÓN UNIVERSITARIA Trabajo Fin de...