aplicaciÓn web para el asesoramiento …tauja.ujaen.es/bitstream/10953.1/4215/1/tfg_ruiz_amate,...

Antonio Ruiz Amate Aplicación Web para el Asesoramiento Deportivo Online

1 Escuela Politécnica Superior de Jaén

Escu

ela

Polit

écn

ica S

up

eri

or

de J

aé

n

APLICACIÓN WEB PARA EL

ASESORAMIENTO DEPORTIVO

ONLINE

Alumno: Antonio Ruiz Amate

Tutor: Prof. D. José Ramón Balsas

Dpto: Departamento de Informática

UNIVERSIDAD DE JAÉN ESCUELA POLITÉCNICA SUPERIOR (JAÉN)

Trabajo Fin de Grado



Universidad de Jaén

Escuela Politécnica Superior de Jaén

Departamento de Informática

Don JOSÉ RAMÓN BALSAS ALMAGRO , tutor del Proyecto Fin de Carrera titulado:

APLICACIÓN WEB PARA EL ASESORAMIENTO DEPORTIVO ONLINE, que presenta

ANTONIO RUIZ AMATE, autoriza su presentación para defensa y evaluación en la Escuela

Politécnica Superior de Jaén.

Jaén, JUNIO de 2015

El alumno: El tutor:

D. ANTONIO RUIZ AMATE D. JOSÉ RAMÓN BALSAS ALMAGRO



AGRADECIMIENTOS

En primer lugar, y sin dudarlo ni un segundo, darle las gracias a mis padres, a quienes se lo debo todo. Sin ellos no podría estar donde estoy, ni ser lo que soy hoy en día. Gracias por el esfuerzo realizado durante estos años, y por todos los consejos que me habéis dado, por la paciencia que habéis tenido conmigo, pues

sabíamos que sería un camino duro.

En segundo lugar, le doy las gracias a Ramón Bailén, quien aparte de ser un grandísimo amigo, ha sido un mejor compañero, ha sido un apoyo diario durante la realización de este proyecto, ayudándome día a día para sacar esto adelante.

También quiero darle las gracias a David Martínez, de Academia de Informática

‘David Martínez’ a quien debo todo lo que sé sobre programación.

No me olvido de José Ramón, tutor de este proyecto, quien ha sabido guiarme desde el inicio y ha estado siempre disponible para lo que hiciese falta. Gracias

por el tiempo invertido en este mi proyecto.

Ya para acabar, mi agradecimiento también a otros compañeros que he tenido a

lo largo de los años y con los que ha sido un placer coincidir: David FP, Amador,

Edu, Escobar, Salud o Juanlu. Me olvidaré de alguno, que me perdonen.

Especial agradecimiento a un grandísimo pilar durante mis primeros años en

ITIG, Raúl Pérez Fuentes.



TABLA DE CONTENIDOS TABLA DE ILUSTRACIONES ............................................................................................... 7

RELACIÓN DE TABLAS ......................................................................................................12

1. INTRODUCCIÓN ..........................................................................................................13

1.1. Propósito ................................................................................................................13

1.2. Objetivos ................................................................................................................16

1.3. Metodología a desarrollar .......................................................................................17

1.4. Estructura del documento ......................................................................................18

2. ANÁLISIS ......................................................................................................................20

2.1. Análisis preliminar ..................................................................................................20

2.1.1. ¿Qué es el Fitness? ........................................................................................20

2.1.2. Fitness: un poco de historia.............................................................................21

2.1.3. Estado del arte de las aplicaciones para el Asesoramiento Deportivo Online ..23

2.1.3.1. Análisis Preliminar ....................................................................................23

2.1.3.2. Analizando algunas aplicaciones .............................................................24

2.1.4. Definiciones previas ........................................................................................29

2.1.5. Calculando las calorías y macros de una Dieta ...............................................31

2.1.5.1. Calcular la Tasa Metabólica Basal (TMB).................................................32

2.1.5.2. Calcular el Gasto Energético Total (GET) o Termogénesis No Asociada al

Ejercicio (TNAE) ........................................................................................................33

2.1.5.3. Calcular la Termogénesis Asociada al Ejercicio Físico (TAEF) ................34

2.1.5.4. Ajustar el valor de mantenimiento según los objetivos .............................35

2.1.5.5. Requerimientos de macronutrientes .........................................................36

2.1.6. ¿Qué es una rutina o plan de entrenamiento? ................................................40

2.1.7. Perfiles de usuario ..........................................................................................41

2.1.8. Metodologías tradicionales vs Metodologías ágiles .........................................42

2.1.9. Aplicaciones web vs Aplicaciones de escritorio ...............................................44

2.1.10. Evolución de la Web .......................................................................................45

2.1.11. Tecnologías para el desarrollo de aplicaciones web .......................................47

2.1.12. Arquitectura básica de una aplicación web ......................................................50

2.1.13. Servidores: Tomcat vs GlassFish ....................................................................51

2.2. Propuesta de solución ............................................................................................52

2.3. Requerimientos del sistema ...................................................................................53

2.3.1. Requerimientos Funcionales ...........................................................................54

2.3.2. Requerimientos No Funcionales .....................................................................60

2.4. Planificación del proyecto .......................................................................................62



2.4.1. Estructura del plan de trabajo ..........................................................................63

2.4.2. Estimación de las tareas .................................................................................65

2.4.3. Diagrama de Gantt ..........................................................................................66

2.5. Estudio de viabilidad ..............................................................................................68

2.6. Modelo de dominio .................................................................................................71

2.7. Modelo de Casos de Uso .......................................................................................75

2.7.1. Actores ............................................................................................................76

2.7.2. Relaciones ......................................................................................................77

2.7.3. Diagramas de Casos de Uso ...........................................................................77

2.7.4. Especificación de Casos de Uso .....................................................................85

3. DISEÑO ........................................................................................................................96

3.1. Diagrama Entidad-Relación ....................................................................................96

3.1.1. Introducción ....................................................................................................96

3.1.2. Descripción de las tablas del sistema ..............................................................99

3.1.3. Diagrama del Modelo E-R ............................................................................. 100

3.1.4. Creación de tablas ........................................................................................ 102

3.1.5. Normalización ............................................................................................... 108

3.2. Diagrama de Clases ............................................................................................. 111

3.3. Diagramas de secuencia ...................................................................................... 124

3.4. Diseño de la Interfaz ............................................................................................ 133

3.4.1. Diseño wireframe de las pantallas de usuario ............................................... 133

3.4.2. Metáforas ...................................................................................................... 146

3.4.3. Notificaciones y Mensajes de Error ............................................................... 149

4. IMPLEMENTACIÓN .................................................................................................... 155

4.1. Arquitectura .......................................................................................................... 155

4.2. Entorno de Desarrollo .......................................................................................... 157

4.3. Detalles sobre implementación ............................................................................ 158

4.2.1 Creando una aplicación web en NetBeans .................................................... 159

4.2.2 Estilo de la Interfaz Web ............................................................................... 161

4.2.3 Java Server Pages ........................................................................................ 162

4.2.4 Librería de jQuery ......................................................................................... 173

4.2.5 Solucionando el problema de los caracteres especiales ............................... 176

4.2.6 Preparando la BBDD ..................................................................................... 176

4.2.7 Conectando con la BBDD ............................................................................. 180

4.2.8 Creando las clases de la aplicación .............................................................. 182

4.2.9 Validación de los datos de formulario ............................................................ 184



4.2.10 Creación de los Objetos de Acceso a los Datos (DAO’s) .............................. 189

4.2.11 Autenticación y autorización a la appweb ...................................................... 192

4.2.12 Controladores de Spring ............................................................................... 197

4.2.13 Inyección de dependencias en Spring ........................................................... 199

4.4. Diseño de los Casos de Prueba ........................................................................... 203

5. CONCLUSIONES........................................................................................................ 216

5.1. Mejoras y trabajos futuros .................................................................................... 218

6. BIBLIOGRAFÍA ........................................................................................................... 222

ANEXO I. MANUAL DE USUARIO ..................................................................................... 226

ANEXO II. DESCRIPCIÓN DE CONTENIDOS SUMINISTRADOS .................................... 257



TABLA DE ILUSTRACIONES Ilustración 1 - FITNESS: tagcloud ........................................................................................14

Ilustración 2 - Evolución del Ser humano .............................................................................21

Ilustración 3 - Logotipo PROVISPORT .................................................................................24

Ilustración 4 - Logotipo MYFITNESSPAL .............................................................................25

Ilustración 5 - Logotipo FITMACRO ......................................................................................26

Ilustración 6 - Logotipo FITFOODMARKET ..........................................................................27

Ilustración 7 - Alimentos altos en proteínas ..........................................................................37

Ilustración 8 - Grasas saludables .........................................................................................38

Ilustración 9 - Hidratos de Carbono ......................................................................................39

Ilustración 10 - Tradicional VS Ágil .......................................................................................43

Ilustración 11 - The Evolution of The Web ............................................................................45

Ilustración 12 - Tecnologías Web .........................................................................................46

Ilustración 13 - MVC VS MVP VS MVVM .............................................................................48

Ilustración 14 - Arquitectura de una Aplicación Web .............................................................50

Ilustración 15 - Comparativa Servidores ...............................................................................51

Ilustración 16 - Estructura del plan de trabajo .......................................................................63

Ilustración 17 - Diagrama de Gantt .......................................................................................66

Ilustración 18 - Presupuesto .................................................................................................68

Ilustración 19 - Diagrama del Modelo de Dominio ................................................................73

Ilustración 20 - Sistema: AsesoríaDeportivaWeb ..................................................................75

Ilustración 21 - Actor: EntrenadorPersonal ...........................................................................76

Ilustración 22 - Actor: Cliente................................................................................................76

Ilustración 23 - Diagrama de Casos de Uso: Principal ..........................................................78

Ilustración 24 - Diagrama de Casos de Uso: Login ...............................................................79

Ilustración 25 - Diagrama de Casos de Uso: Gestión de Usuarios .......................................80

Ilustración 26 - Diagrama de Casos de Uso: Gestionar Paquetes ........................................81

Ilustración 27 - Diagrama de Casos de Uso: Consultar Peticiones Sin Atender ....................82

Ilustración 28 - Diagrama de Casos de Uso: Contratar Paquete ...........................................83

Ilustración 29 - Diagrama de Casos de Uso: Gestionar Mensajes ........................................84

Ilustración 30 - Entidad: ........................................................................................................96

Ilustración 31 - Atributos .......................................................................................................97

Ilustración 32 - Relación .......................................................................................................98

Ilustración 33 - Diagrama del modelo E-R .......................................................................... 100

Ilustración 34 - Ejemplo de Clase ....................................................................................... 111

Ilustración 35 – Generalización .......................................................................................... 112

Ilustración 36 - Agregación ................................................................................................. 113

Ilustración 37 – Composición.............................................................................................. 113

Ilustración 38 - Modelo-Vista-Controlador........................................................................... 114

Ilustración 39 - Patrón MVC ............................................................................................... 115

Ilustración 40 - Diagrama de Clases General ..................................................................... 116

Ilustración 41 - MVC aplicado a Clientes ............................................................................ 117

Ilustración 42 - Paquete Controladores .............................................................................. 118

Ilustración 43 - Paquete Clases .......................................................................................... 119

Ilustración 44 - Paquete DAOs ........................................................................................... 119

Ilustración 45 - Diagrama de Clases: Relaciones ............................................................... 121

Ilustración 46 - Relaciones Controladores-DAOs ................................................................ 122



Ilustración 47 - Relaciones Controladores-DAOs - 2 .......................................................... 123

Ilustración 48 - Diagramas de Secuencia: Registrarse ....................................................... 125

Ilustración 49 - Diagramas de Secuencia: Login ................................................................. 126

Ilustración 50 - Diagramas de Secuencia: Contratar Paquete............................................. 127

Ilustración 51 - Diagramas de Secuencia: Eliminar Listado de Mensajes ........................... 128

Ilustración 52 - Diagramas de Secuencia: Añadir Propósito ............................................... 129

Ilustración 53 - Diagramas de Secuencia: Modificar Datos de Usuario ............................... 130

Ilustración 54 - Diagramas de Secuencia: Asignar Rutina - Parte 1 .................................... 131

Ilustración 55 - Diagramas de Secuencia: Asignar Rutina - Parte 2 .................................... 132

Ilustración 56 - Diseño wireframe: bienvenida a la aplicación ............................................. 134

Ilustración 57 - Diseño wireframe: Gestión de Clientes (Parte del Administrador) .............. 135

Ilustración 58 - Diseño wireframe: Visualizar Datos Personales (Parte del Administrador) . 136

Ilustración 59 - Diseño wireframe: Modificar Datos Personales (Parte del Administrador) .. 137

Ilustración 60 - Diseño wireframe: Histórico de Mensajes (Parte del Administrador) .......... 138

Ilustración 61 - Diseño wireframe: Ver Petición Cliente (Parte del Administrador) .............. 139

Ilustración 62 - Diseño wireframe: Asignar Dieta Cliente (Parte del Administrador) ............ 139

Ilustración 63 - Diseño wireframe: Añadir Ejercicios a una Rutina (Parte del Administrador)

........................................................................................................................................... 140

Ilustración 64 - Diseño wireframe: Listado de Paquetes (Parte del Administrador) ............. 141

Ilustración 65 - Diseño wireframe: Añadir Nuevo Paquete (Parte del Administrador) .......... 141

Ilustración 66 - Diseño wireframe: Listado de Ejercicios (Parte del Administrador) ............. 142

Ilustración 67 - Diseño wireframe: Pantalla de Inicio (Parte del Cliente) ............................. 143

Ilustración 68 - Diseño wireframe: Visualizar Datos Personales (Parte del Cliente) ............ 144

Ilustración 69 - Diseño wireframe: Contratar Paquete (Parte del Cliente) ........................... 144

Ilustración 70 - Diseño wireframe: Formulario de Contratación (Parte del Cliente) ............. 145

Ilustración 71 - Datos de registro no válidos ....................................................................... 150

Ilustración 72 - Error Identificación ..................................................................................... 150

Ilustración 73 - Error al escribir un nuevo mensaje ............................................................. 150

Ilustración 74 - Error Añadir Usuario ................................................................................... 151

Ilustración 75 - Error Añadir Propósito ................................................................................ 151

Ilustración 76 - Notificación Eliminar Cliente ....................................................................... 152

Ilustración 77 - Notificación Eliminar Petición ..................................................................... 152

Ilustración 78 - Eliminar Cuenta de Usuario ........................................................................ 153

Ilustración 79 - Error Contratar Paquete ............................................................................. 153

Ilustración 80 - Aviso Logout .............................................................................................. 154

Ilustración 81 – Diseño Arquitectónico del sistema ............................................................. 155

Ilustración 82 - Crear nuevo proyecto ................................................................................. 159

Ilustración 83 - Nombre y localización del proyecto ............................................................ 160

Ilustración 84 - Selección del servidor y framework ............................................................ 160

Ilustración 85 - JSP: Cabecera ........................................................................................... 163

Ilustración 86 - JSP: Barra Superior ................................................................................... 165

Ilustración 87 - JSP: Botón Responsive .............................................................................. 167

Ilustración 88 - JSP: Barra Superior Responsive ................................................................ 167

Ilustración 89 - JSP: Barra de opciones + Imagen .............................................................. 167

Ilustración 90 - JSP: Navegador VS Dispositivos Móviles ................................................... 169

Ilustración 91 - JSP: Botón + Clase glyphicon .................................................................... 170

Ilustración 92 - JSP: ProgramaciTablas .............................................................................. 171

Ilustración 93 - JSP: Tabla Versión Navegador .................................................................. 172



Ilustración 94 - JSP: Tablas Versión Dispositivos Móviles .................................................. 172

Ilustración 95 - Botón Modal ............................................................................................... 173

Ilustración 96 - jQUERY: Modal para Salir .......................................................................... 173

Ilustración 97 - jQUERY: Botón para Eliminar Cliente ........................................................ 174

Ilustración 98 - jQUERY: Modal para Eliminar Cliente ........................................................ 174

Ilustración 99 - jQUERY: Script para Eliminar Cliente ......................................................... 175

Ilustración 100 - Codificación UTF-8 ................................................................................... 176

Ilustración 101 - Create Database ...................................................................................... 177

Ilustración 102 - Información BBDD .................................................................................... 177

Ilustración 103 - CREATE_TABLE ..................................................................................... 178

Ilustración 104 - Ejecutar un documento SQL .................................................................... 179

Ilustración 105 - Insertar Datos Tabla Clientes ................................................................... 179

Ilustración 106 - JDBC Connection Pool ............................................................................. 181

Ilustración 107 - glassfish-resource.xml .............................................................................. 181

Ilustración 108 - Instancia del objeto asociado al Pool de Conexiones ............................... 182

Ilustración 109 - Declaración de la clase Cliente – Atributos .............................................. 183

Ilustración 110 - Constructores de la clase Cliente ............................................................. 183

Ilustración 111 - Métodos GET y SET de la clase Cliente ................................................... 184

Ilustración 112 - Anotaciones para los Beans ..................................................................... 185

Ilustración 113 - Mensajes de error personalizados para la clase Cliente ........................... 185

Ilustración 114 - Importar fichero de mensajes personalizados .......................................... 186

Ilustración 115 - Validación de datos ContrClientes ............................................................ 186

Ilustración 116 - Formulario + Errores ................................................................................ 187

Ilustración 117 - Errores de formulario ................................................................................ 188

Ilustración 118 - Interfaz Genérica del DAO Clientes .......................................................... 189

Ilustración 119 - Interfaz Específica del DAO Clientes ........................................................ 190

Ilustración 120 - Cabecera ClienteDAOJDBC ..................................................................... 190

Ilustración 121 - Consultas y Modificaciones de la clase ClienteDAOJDBC ....................... 190

Ilustración 122 - Mapeo de datos ....................................................................................... 191

Ilustración 123 - Implementación del método CREA ........................................................... 191

Ilustración 124 - Librerías de Spring Security ..................................................................... 192

Ilustración 125 - Añadir Librerías de Spring Security .......................................................... 192

Ilustración 126 – Configuración de Spring Security en web.xml .......................................... 193

Ilustración 127 - Configurando Spring Security ................................................................... 193

Ilustración 128 - Seguridad a través de formulario .............................................................. 194

Ilustración 129 - Autenticación al sistema ........................................................................... 194

Ilustración 130 - Formulario de Login ................................................................................. 195

Ilustración 131 - LoginController ......................................................................................... 195

Ilustración 132 - Restricciones en función del rol ................................................................ 196

Ilustración 133 - Importar security.xml al applicationContext.xml ........................................ 196

Ilustración 134 - Controlador Clientes: Cabecera ............................................................... 197

Ilustración 135 - Controlador Clientes: Inyección de los DAOs ........................................... 197

Ilustración 136 - Controlador Clientes: ModelAttribute ........................................................ 198

Ilustración 137 - Controlador Clientes: métodos GET y POST de Añadir Cliente ................ 198

Ilustración 138 - Controlador Dietas + Inyecciones ............................................................. 200

Ilustración 139 - PaqueteDAOJDBC ................................................................................... 201

Ilustración 140 - Función Ver Dietas del Controlador de Dietas .......................................... 201

Ilustración 141 - Función verDietasCliente ......................................................................... 202



Ilustración 142 - Tabla de Dieta 1 ....................................................................................... 218

Ilustración 143 - Tabla de Dieta 2 ....................................................................................... 219

Ilustración 144 - Calculadora Diaria de Macronutrientes ..................................................... 220

Ilustración 145 - MU: Pantalla de Bienvenida a la aplicación .............................................. 226

Ilustración 146 - MU: Usuario creado con éxito .................................................................. 227

Ilustración 147 - MU: Pantalla de Inicio del Cliente ............................................................. 227

Ilustración 148 - MU: Modificar Datos Personales - Parte del Cliente ................................. 228

Ilustración 149 - MU: Eliminar Cuenta de Usuario - Parte del Cliente ................................. 229

Ilustración 150 - MU: Contratar Paquete - Parte del Cliente ............................................... 229

Ilustración 151 - MU: Formulario de contratación - Parte del Cliente .................................. 230

Ilustración 152 - MU: Peticiones Enviadas - Parte del Cliente ............................................ 231

Ilustración 153 - MU: Dietas Personales - Parte del Cliente ............................................... 231

Ilustración 154 - MU: Ver Dieta - Parte del Cliente ............................................................. 232

Ilustración 155 - MU: Ver Alimento - Parte del Cliente ........................................................ 233

Ilustración 156 - MU: Rutinas Personales - Parte del Cliente.............................................. 234

Ilustración 157 - MU: Ver Rutina - Parte del Cliente ........................................................... 234

Ilustración 158 - MU: Bandeja de Mensajes - Parte del Cliente .......................................... 235

Ilustración 159 - MU: Leer Mensaje - Parte del Cliente ....................................................... 236

Ilustración 160 - MU: Eliminar Mensaje - Parte del Cliente ................................................. 236

Ilustración 161 - MU: Añadir Mensaje - Parte del Cliente .................................................... 237

Ilustración 162 - MU: Opción de 'Salir' ................................................................................ 237

Ilustración 163 - MU: Cerrar Sesión.................................................................................... 238

Ilustración 164 - MU: Pantalla de Inicio del Administrador .................................................. 238

Ilustración 165 - MU: Gestión de Usuarios - Parte del Administrador ................................. 239

Ilustración 166 - MU: Añadir Usuario - Parte del Administrador .......................................... 240

Ilustración 167 - MU: Añadir Nuevo Mensaje - Parte del Administrador .............................. 242

Ilustración 168 - MU: Histórico de Mensajes - Parte del Administrador ............................... 242

Ilustración 169 - MU: Consultar Histórico de Peticiones - Parte del Administrador ............. 243

Ilustración 170 - MU: Listado de Dietas Personales - Parte del Administrador ................... 243

Ilustración 171 - MU: Listado de Alimentos Dieta - Parte del Administrador ....................... 244

Ilustración 172 - MU: Consultar Listado de Rutinas Personales - Parte del Administrador . 244

Ilustración 173 - MU: Listado de Ejercicios Rutina - Parte del Administrador ...................... 245

Ilustración 174 - MU: Gestionar Paquetes - Parte del Administrador .................................. 245

Ilustración 175 - MU: Añadir Propósito - Parte del Administrador ....................................... 246

Ilustración 176 - MU: Modificar Paquete - Parte del Administrador ..................................... 246

Ilustración 177 - MU: Gestionar Ejercicios - Parte del Administrador .................................. 247

Ilustración 178 - MU: Modificar Ejercicio - Parte del Administrador ..................................... 248

Ilustración 179 - MU: Gestionar Alimentos - Parte del Administrador.................................. 248

Ilustración 180 - MU: Añadir nuevo Alimento - Parte del Administrador .............................. 249

Ilustración 181 - MU: Peticiones Pendientes ...................................................................... 250

Ilustración 182 - MU: Ver Petición - Parte del Administrador .............................................. 250

Ilustración 183 - MU: Asignar Dieta – Parte 1 - Parte del Administrador ............................. 251

Ilustración 184 - MU: Asignar Dieta - Parte 2 - Parte del Administrador .............................. 252

Ilustración 185 - MU: Asignar Dieta - Paso 2 - Parte del Administrador .............................. 253

Ilustración 186 - MU: Asignar Alimentos a la Dieta - Parte del Administrador ..................... 254

Ilustración 187 - MU: Asignar Rutina - Parte del Administrador .......................................... 255

Ilustración 188 - MU: Asignar Ejercicios a la Rutina - Parte del Administrador ................... 255

Ilustración 189 - MU: Mensajes Sin Leer - Parte del Administrador .................................... 256



Ilustración 190 - Contenido del CD ..................................................................................... 257



RELACIÓN DE TABLAS Tabla 1 - Estimación del esfuerzo ........................................................................................65

Tabla 2 - Programación de tareas ........................................................................................67

Tabla 3 - Herramientas y licencias software utilizadas .........................................................69

Tabla 4 – Equipos Informáticos utilizados.............................................................................69

Tabla 5 - Conexión ADSL+ ...................................................................................................69

Tabla 6 - Nóminas del personal ............................................................................................70

Tabla 7 - Coste Final del Proyecto .......................................................................................70

Tabla 8 - Plantilla Especificación de Casos de Uso ..............................................................86

Tabla 9 - Especificación de Casos de Uso: Login .................................................................88

Tabla 10 - Especificación de Casos de Uso: Consultar Listado de Usuarios ........................89

Tabla 11 - Especificación de Casos de Uso: Añadir Ejercicio ...............................................90

Tabla 12 - Especificación de Casos de Uso: Modificar Alimento ..........................................91

Tabla 13 - Especificación de Casos de Uso: Eliminar Petición .............................................92

Tabla 14 - Especificación de Casos de Uso: Asignar Rutina ................................................94

Tabla 15 - Especificación de Casos de Uso: Contratar Paquete ...........................................94

Tabla 16 - Especificación de Casos de Uso: Añadir Mensaje Cliente ...................................95

Tabla 17 - Alimentos .......................................................................................................... 102

Tabla 18 - Usuarios ............................................................................................................ 102

Tabla 19 - Ejercicios ........................................................................................................... 102

Tabla 20 - Paquetes ........................................................................................................... 103

Tabla 21 - Mensajes ........................................................................................................... 103

Tabla 22 - Peticiones .......................................................................................................... 104

Tabla 23 - Dietas ................................................................................................................ 107

Tabla 24 - AlimentosDieta .................................................................................................. 107

Tabla 25 - Rutinas .............................................................................................................. 107

Tabla 26 - EjerciciosRutina ................................................................................................. 107

Tabla 27 - Relaciones Modelo E-R Modificado ................................................................... 109

Tabla 28 - Las relaciones según sus claves ....................................................................... 110

Tabla 29 - Casos de prueba ............................................................................................... 215



1. INTRODUCCIÓN

1.1. Propósito

Como veremos durante el desarrollo de esta memoria, este proyecto se

encuentra enmarcado dentro de lo que conocemos como FITNESS, concepto que

engloba activididad física y nutrición; entre otras muchas cosas.

Actualmente es de vital importancia el hecho de ser orientados por profesionales

a nivel físico y alimenticio, si queremos gozar de buena salud o si simplemente

queremos tener un cuerpo bonito, o mejorar nuestro rendimiento deportivo. De hecho,

son cada vez más las personas que acuden a los centros deportivos/gimnasios en

busca de este tipo de orientación, y a cualquier nivel.

Sin duda, este es un campo en el que poco a poco se están introduciendo

cambios, y las nuevas tecnologías se están abriendo camino, pero aún existen

oportunidades que merecen ser cubiertas.

Como usuario habitual de gimnasios y plataformas orientadas al asesoramiento

deportivo, creo que existe una carencia importante de plataformas o herramientas

100% destinadas a nuestros objetivos, en las que podamos encontrar todo lo que

necesitamos en lo referente a la nutrición y planes de entrenamiento. Durante estos

años,y ya no sólo desde la perspectiva de un asistente a centros de entrenamiento

sino también desde el punto de vista de alguien con conocimientos (aunque sean

mínimos) de informática, he podido detectar que los sistemas que habitualmente se

utilizan en estos círculos, son un poco arcaicos, puesto que no existe la

informatización que debiera.

En muchos de estos centros, aún se encuentran sistemas de gestión de usuarios

a través de medios físicos. Básicamente, lo que piden cuando accedes por primera

vez a sus instalaciones, es que rellenes un simple formulario a modo de ficha personal,

a papel, para que tus datos queden registrados, algo que supone un claro retraso en

la época de la informática en la que nos movemos. Pero no sólo eso, cuando pides a

tu entrenador que te asigne una dieta o una rutina, en la mayoría de los casos a lo

que recurren es a una simple hoja de excel, en la que manualmente van introduciendo

tanto los alimentos como los ejercicios, y posteriormente, cuando estas dietas o



rutinas están completas, las imprimen y te las entregan, perdiendo la posibilidad de

consultar esta información con el tiempo.

Aquí es cuando nace la idea de este proyecto. Aunando mis conocimientos sobre

el mundo de la musculación y la nutrición, y la informática, por supuesto, llegué a

plantearme el objetivo de diseñar una plataforma que reuniese todo el material

necesario para que cualquier centro deportivo pueda gestionar tanto a los usuarios del

mismo, como todo lo relacionado con sus peticiones de servicios, dietas y rutinas

personalizadas, ejercicios y alimentos, además de un sistema que permitiese que

tanto entrenadores como clientes tuviesen un contacto directo a través de mensajes

desde la web.

Esta idea de plataforma permitiría no sólo a los entrenadores gestionar más

fácilmente su trabajo, sino a los clientes les daría la opción de tener toda su

información accesible desde sus casas, o desde sus dispositivos móviles.

Ilustración 1 - FITNESS: tagcloud

El propósito de este Trabajo Fin de Grado es diseñar y desarrollar una aplicación

web para el Asesoramiento Deportivo Online, que permita a un centro deportivo, o

personal individual, gestionar los usuarios registrados en la plataforma, diferenciando

para ello dos tipos de usuario: entrenadores personales y clientes.



También debe permitir la gestión de paquetes ofertados en la web, gestión de

las BBDD de Alimentos y Ejercicios, diseño y consulta de dietas y planes de

entrenamiento personalizados para cada cliente de acuerdo a sus necesidades y

características básicas, las cuáles serán introducidas por este último a través de un

formulario de contratación de servicios.

Además, la plataforma debe dotar a los usuarios de un mecanismo de

comunicación por mensajes, en los que cliente y entrenador puedan tener un contacto

directo para intercambiar información, realizar consultas y evaluar el progreso de los

servicios contratados.



1.2. Objetivos

Pasamos a ver los objetivos marcados al inicio de este proyecto.

- Realizar un estudio del sistema para la realización de planes de

asesoramiento deportivo individualizado online

Se trata de realizar un análisis de las técnicas relacionadas con el asesoramiento

deportivo online, y de las plataformas o aplicaciones existentes en el mercado

relacionadas con este tema.

- Diseñar una aplicación web para el asesoramiento deportivo individualizado

vía web

Se llevará a cabo un exhaustivo análisis de los requerimientos que ha de cumplir

la aplicación, se diseñará la estructura que dará forma a la aplicación, el orden en el

que se cumplirán las fases del proyecto, se realizará un estudio de la viabilidad del

proyecto, además de otros conceptos relacionados con la fase de diseño de ingeniería

del software.

- Implementar un prototipo de aplicación web utilizando el framework

SpringMVC

En este apartado se traducirá a un lenguaje de programación, utilizando para

ello el framework de SpringMVC, todo lo hablado en el apartado anterior, tratando de

cumplir con todos los requisitos establecidos.

- Realizar una memoria con toda la documentación relacionada con el proyecto

en sus fases de análisis, diseño e implementación



1.3. Metodología a desarrollar

La definición de una correcta metodología a aplicar en un proyecto informático

es fundamental, pues nos permite definir una estructura firme con el fin de garantizar

la entrega de una buena documentación y por consiguiente de un buen producto final.

Esta determina los patrones que se deben seguir en cada una de las etapas de

desarrollo software.

En este sentido, y basado en un modelo adaptado de las fases de desarrollo

clásicas de la Ingeniería del Software: ciclo de vida clásico o Modelo en cascada, el

proyecto se ha realizado en las siguientes etapas:

- Fase de Análisis y Especificación de Requerimientos: en esta fase se

incluye un análisis exhaustivo sobre la temática a tratar y las tecnologías

relacionadas con el desarrollo de aplicaciones web, así como la búsqueda y

revisión bibliográfica relacionada con estos apartados.

- Fase de Estimación Temporal y Costes del Proyecto: por una parte, se

identificarán las principales tareas y subtareas que componen el proyecto,

estableciéndose la estructura del plan de trabajo y la estimación en

personas/día de cada una de ellas. Posteriormente, se realizará un estudio o

estimación de costes de desarrollo asociados al proyecto: personal, software,

hardware y margen de maniobra.

- Fase de Diseño del Sistema: utilizando para ello una metodología de

orientación a objetos, utilizando el patrón de diseño MVC (modelo-vista-

controlador), más específicamente, bajo el framework de Spring MVC.

- Desarrollo del prototipo del sistema: para el que se pondrán en práctica

todas las tecnologías analizadas durante la fase de análisis.

- Pruebas: en esta fase, una vez que el prototipo haya sido desarrollado, se

realizarán las pruebas pertinentes que garanticen que el sistema funciona de

acuerdo a los requerimientos establecidos al inicio.

- Documentación: elaboración de una correcta memoria o guía del proyecto,

en base al trabajo realizado y la bibliografía relacionada con este.

En lo que se refiere a metodologías de seguimiento de planes de entrenamiento

se hablará en posteriores apartados.



1.4. Estructura del documento

El presente documento se encuentra dividido en seis grandes bloques, que irán

acompañados de otros apartados que comentaré a continuación.

La primera parte del documento incluye las principales tablas o índices

relacionados con el contenido, ilustraciones y tablas de datos, que nos permitirán

ubicar de manera rápida todo el material de esta memoria, y una sección de

Agradecimientos.

En el punto número 1, titulado ‘Introducción’, encontraremos diferentes

apartados donde podremos consultar una descripción general y justificada del

proyecto, los objetivos marcados al inicio del mismo y las principales metodologías

que posteriormente se emplearán durante el desarrollo del proyecto.

El apartado 2, denominado ‘Análisis’, está dividido a su vez en ocho grandes

puntos:

- Análisis preliminar: donde realizo un análisis del sistema o contexto en el que

se engloba este proyecto, y para el que se realizará el desarrollo. Para ello,

hablaré de su historia, características, problemáticas, necesidades,

elementos que lo componen, etc.. Y estudiaré opciones similares, existentes

en el mercado, que de alguna manera puedan resolver el problema del que

voy a tratar.

- Propuesta de solución: donde daré, de forma justificada, una visión general

de mi sistema junto con las metodologías y tecnologías que posteriormente

utilizaré.

- Requerimientos del sistema: especificaré de forma detallada todas las

funcionalidades de mi sistema, tanto requerimientos funcionales, como no

funcionales.

- Calendarización del Proyecto: teniendo en cuenta las limitaciones del

proyecto, como: el tiempo, los recursos disponibles y el ámbito del mismo, se

realizará un plan de proyecto, enumerando las tareas a realizar, su duración

aproximada, el personal que se encargará de llevarlas a cabo, etc.



- Estudio de viabilidad: análisis de costes de desarrollo y explotación, y modelo

de negocio.

- Modelo de dominio: descripción de las distintas entidades, sus atributos,

papeles y relaciones.

- Modelo de Casos de Uso: análisis tanto de las funcionalidades del sistema y

de los actores que intervienen en ellas, como de las interacciones entre estos.

En el apartado 3 veremos todos los temas relacionados con el ‘Diseño’ de la

aplicación (Diseño de la Interfaz) y los principales diagramas que dan funcionalidad al

sistema: Diagrama Entidad-Relación, Diagrama de Clases y Diagramas de Secuencia.

El apartado 4 está destinado a la ‘Implementación’ de la aplicación. Dentro de

este punto veremos el diagrama arquitectónico del sistema desarrollado junto a los

elementos que lo constituyen, sus relaciones y una breve explicación de su

funcionamiento, y detalles sobre la implementación tales como: aspectos

metodológicos y técnicos sobre la implementación, documentación, recursos

empleados, bibliotecas, frameworks, servidores de aplicaciones, versiones de estos

elementos, etc.. Además, veremos un apartado relacionado con algunos Casos de

Prueba realizados sobre la aplicación.

En el punto 5, se verán las conclusiones que se han obtenido tras el desarrollo

del proyecto y un apartado relacionado con las mejoras y trabajos futuros del sistema.

El punto 6 estará relacionado con la Bibliografía consultada para la realización

del proyecto.

Para finalizar, esta memoria incluirá una serie de apéndices o anexos, donde el

lector podrá consultar el Manual de Usuario, y la Descripción de los contenido

suministrados en el CD junto a esta memoria.



2. ANÁLISIS

2.1. Análisis preliminar

En este apartado voy a describir el sistema, o contexto del que parto y para el

que realizaré el desarrollo. En este caso, realizaremos un análisis de todos los

conceptos importantes dentro del FITNESS y que guardan relación con la elaboración

de este proyecto. Además, veremos en qué situación se encuentra el mercado actual

respecto de aplicaciones relacionadas con el asesoramiento deportivo online, así

como la oferta de tecnologías y metodologías para el desarrollo de aplicaciones web

existente.

2.1.1. ¿Qué es el Fitness?

Para comenzar este análisis, considero que es oportuno ver, o tener claro, a qué

hace referencia exactamente la palabra Fitness [1]. En primer lugar, Fitness está

compuesta por la raíz fit-, la que podríamos traducir como ‘ajustado’, ‘apropiado’ o

‘adecuado’, entre otros significados. Personalizando estas definiciones para el tema

que nos ocupa (Salud, Nutrición, Actividad Deportiva, etc), podríamos decir que ‘Fit-’

es:

- Ser adecuado, tener las cualidades requeridas para algo.

- Estar en buena forma, con buen estado de salud.

En segundo lugar, la terminación –ness es la forma en la que en inglés se

construyen los sustantivos. Resumiendo, cuando nos referimos a la palabra ‘fitness’

aludimos a algo como ‘buena forma’, ‘buen estado físico’ o ‘condición física adecuada’.

Por lo que podemos observar, es un término que en cualquier caso tiene matices

positivos.

En la actualidad entendemos como ‘fitness’ aquel “estado que permite a una

persona usar su cuerpo en actividades que requieran fuerza, resistencia, flexibilidad,

coordinación, agilidad, potencia, equilibrio, velocidad y precisión, sin experimentar

fatiga”. Todos los deportes y ejercicios que nos dan la posibilidad de obtener este

estado, estarán integrados dentro del Fitness.



Como primera aproximación al tema creo que queda claro el concepto de la

palabra fitness, pero vamos a ver con un poco más de detenimiento, los orígenes del

fitness

2.1.2. Fitness: un poco de historia

Como se comenta en [2] para comprender cómo llegamos a la cultura del

moderno gimnasio, es útil remontarnos a los orígenes de nuestra espacie, donde se

entendía el ejercicio físico más como una forma de vida. Para el hombre primitivo era

necesario no sólo saber cómo correr, sino también cómo caminar, tener equilibrio,

saltar, gatear, trepar árboles, levantar o cargar objetos pesados, lanzar y atrapar

cosas, y por supuesto, luchar. Necesitaba sobrevivir en un ambiente hostil, lleno de

obstáculos, donde si querían comer o beber agua, tenían que cazar, pescar o ir a

coger agua. Y no sólo eso, tenían que hacer frente a otros enemigos naturales o

humanos.

La fuerza y la movilidad de nuestros ancestros primitivos, no es el resultado de

estructurados programas de entrenamiento, sino que es consecuencia directa de la

práctica diaria e instintiva, de la necesidad de habilidades de movimiento repetitivas y

adaptables situaciones del día a día.

Pero también podemos afirmar, que el hombre primitivo se movía por

motivaciones lúdicas o recreativas, como son las primeras formas de baile. Su

naturaleza nómada también lo obligaba a hacer largos recorridos a pie.

Ilustración 2 - Evolución del Ser humano



Con el paso del tiempo, y el desarrollo de la actividad agrícola, podemos decir

que los hábitos de la especie se volvieron menos activos, lo que tuvo consecuencias

en su salud. El pensador chino Confuncio, explicaba que para tener salud había que

moverse. Incluso antes, el yoga se desarrolló en la India, vinculado a los principios del

budismo, y el hinduismo, y tenía asociados beneficios para la salud y la espiritualidad.

Pero lo que sin dudarlo cambió el rumbo del ejercicio físico y el fitness, fue la

guerra. El entrenamiento militar antiguo tenía similitudes con los movimientos

realizados por los hombres de las cavernas, pero dotados de una estructura más firme

y un objetivo final distinto. Así aparecen habilidades fundamentales como: andar o

correr por terrenos irregulares, combates cuerpo a cuerpo, o el entrenamiento con

armas. Como ejemplos claros de este tipo de entrenamiento, tenemos a los famosos

Imperio Persa o a los Espartanos.

Para estos últimos, era primordial tener una buena condición física, tanto para

hombres, que tenían que ser los mejores guerreros, como para mujeres, debían ser

capaces de dar a luz una descendencia sana, o niños, futuros servidores del Estado.

En el caso de los griegos, más allá de la guerra, el tener un buen cuerpo estaba

también relacionado con cultivar la mente, lo que dio lugar al conocido dicho: “men

sana in corpore sano”. Por supuesto, hemos de considerar a los griegos como los

creadores de los primeros Juegos Olímpicos.

Dando un paso más en la Historia del Fitness, durante la Edad Media, se produjo

una época de rechazo al cuerpo, algo que empezó a verse como algo obsceno, o sin

valor, el alma empezó a considerarse la verdadera esencia del hombre.

El Renacimiento volvió a revivir el ideal griego del fitness. Se dio paso a un

interés mucho mayor por el cuerpo, y por su estudio, por la anatomía, la biología, la

salud y la educación física, lo que hizo de esta algo mucho más popular.

Con el tiempo, aparece en escena Friedrich Jahn, Alemania, quien es

considerado el “padre de la gimnasia”, quien consideraba el ejercicio físico como la

clave para estar prevenidos sobre posibles invasiones. En Suecia, emerge la figura

de Henrik Ling quien desarrolló los principios del desarrollo físico y preparó diferentes

programas de gimnasia a distintos niveles (gimnasia educativa, militar y médica). A



diferencia del sistema alemán, el sueco lo que promovía es un tipo de “gimnasia

suave”, que empleaba pocos o ningún aparato, centrándose en ejercicios de

‘calistenia’ (ejercicios realizados con el propio peso corporal), la respiración y los

ejercicios de estiramiento y masaje.

Al mismo tiempo, las tradiciones de la cultura física europea empezó a echar

raíces en EEUU, país que daría un paso adelante por ser de los primeros países

donde el gobierno participó activamente en impulsar la salud y el fitness.

El uso de aparatos de ejercicios se impulsó en el siglo XX, al igual que el enfoque

de la fuerza basada en pesos a la cultura física. Esta tendencia lleva a la industria a

lo que hoy en día entendemos como fitness. El desarrollo de la musculatura, el uso de

máquinas de ejercicio cada vez más complejas en los gimnasios

En la actualidad, existe una conciencia generalizada sobre la importancia de

incluir el ejercicio regular en nuestra forma de vida diaria, sea en la forma que sea:

musculación en salas de gimnasio, running, andar, natación, spinning u otra infinidad

de deportes que están al alcance de cualquiera. Esto y el hecho de entender cada vez

mejor cómo funciona el cuerpo humano y la manera en que responde al ejercicio físico,

hacen pensar en una mejora sustancial de nuestra calidad de vida actual y futura.

2.1.3. Estado del arte de las aplicaciones para el Asesoramiento

Deportivo Online

2.1.3.1. Análisis Preliminar

En este apartado desarrollaré un análisis sobre el estado de las aplicaciones web

para el Asesoramiento Deportivo Online, es decir, otras aplicaciones ofertadas en el

mercado con funcionalidades similares a las de mi ‘proyecto de aplicación’, además

de las ventajas e inconvenientes de cada una de ellas, y mi opinión personal.

En primer lugar, creo que es necesario tener claro a qué se hace referencia

exactamente con el término ‘asesoramiento deportivo online’.



Vayamos por partes, el ‘asesoramiento deportivo’ sería algo así como la

elaboración de un plan nutricional y de entrenamiento específicos, de acuerdo a las

necesidades u objetivos deportivos y físicos del individuo o deportista en general. El

término ‘online’ creo que queda bastante claro a estas alturas, vía web.

Pero, ¿cómo puede un entrenador personal evaluar el estado de un cliente?

Pues existen varias opciones para ello. Si no existiesen barreras como la distancia, o

el tiempo, lo más acertado sería la entrevista personal, pero por desgracia esto no

siempre es posible. Una ventaja que nos ofrece el asesoramiento deportivo web es

que nos permite realizar este análisis a través de internet, desde los múltiples

dispositivos de los que disponemos (ordenadores personales, tablets, móviles, etc.).

Con esta segunda opción, y ya sea a través de formularios cuidadosamente

diseñados, o mediante fotos y contacto con el cliente, un entrenador personal puede

tener una idea bastante cercana a la realidad del estado del cliente.

En lo que a este tipo de aplicaciones se refiere, he encontrado algunas que por

separado hacen las funciones que anteriormente he comentado: elaboración de

planes de entrenamiento individualizados y análisis de requerimientos nutricionales

personales, pero si es cierto que el concepto que personalmente tengo sobre

‘Aplicación para el Asesoramiento Deportivo Online’ es aquel que englobe todas las

esas funcionalidades, y en este sentido, la oferta en la red es floja.

2.1.3.2. Analizando algunas aplicaciones

PROVISPORT (Centro Deportivo Virtual)

Ilustración 3 - Logotipo PROVISPORT



ProviSport [3] es una aplicación bastante completa que permite a los usuarios

de un centro deportivo gestionar de manera rápida sus actividades dentro del centro:

alta de clientes, reserva de actividades, compra de bonos, inscripción en cursillos,

gestión de cuotas, rutinas de entrenamiento, reserva de servicios, gestión de partidos,

gestión de pagos y gestión de información personal. Además, la aplicación facilita a

los empleados del centro la gestión de sus principales tareas: gestión de usuarios,

gestión de rutinas, reservas y bonos, contabilidad y cobros, accesos al centro, etc.

Ventajas:

- Muy completa desde el punto de vista del centro deportivo.

Inconvenientes:

- No incluye apartado sobre nutrición.

- No existe comunicación entre el personal del centro y el cliente.

MYFITNESSPAL

Ilustración 4 - Logotipo MYFITNESSPAL

Es una aplicación cuya principal funcionalidad es ser un contador de calorías

totalmente gratis, y con acceso a más de 3,000.000 de alimentos. MyFitnessPal [4]

permite al cliente llevar la cuenta de las calorías que ingiere diariamente simplemente

añadiendo alimentos y comidas.

Tras un registro gratuito el cliente puede rellenar un formulario que evalúa sus

necesidades calóricas, y en base a ellas y a los alimentos ingeridos durante el día,

puede saber en todo momento las cantidades restantes de acuerdo al objetivo

marcado.



También permite al usuario llevar un registro de los ejercicios realizados durante

una sesión de entrenamiento, lo que modificará sus requerimientos calóricos diarios.

MyFitnessPal incluye también un apartado en el que podrás consultar diversos

informes y gráficos relacionados con tu progreso.

Ventajas:

- Desde el punto del cliente es perfecta para tener un registro de lo que come.

- GRATIS.

- Uso sencillo.

- No es necesario instalar nada.

- Incluye versión para móviles.

Inconvenientes:

- Enfocada solamente al registro de comidas por parte del cliente.

- El entrenador personal no interviene en ningún momento.

FITMACRO

Ilustración 5 - Logotipo FITMACRO

Al igual que MyFitnessPal, FitMacro [5] funciona como contador de calorías. Con

esta aplicación para móviles un usuario tiene la posibilidad de:

- Crear perfiles basados en los tres principales objetivos calóricos: pérdida de

grasa, mantenimiento o aumento de masa muscular.

- Gestionar recetas personalizadas: añadir, modificar y eliminar recetas

personales, con alimentos a elección del usuario.

- Registrar alimentos ingeridos por comida: lo que te ayudará a llevar la cuenta

de los macronutrientes ingeridos diariamente.



- Búsqueda de alimentos según la categoría o valor nutricional que se elija.

- Visualización de gráficos basados en tu progreso.

Ventajas:

- Permite al usuario llevar un registro bastante detallado de su ingesta calórica

diaria.

- Facilidad de uso.

- GRATIS.

Inconvenientes:

- Solo dispone de versión para móviles.

- No incluye nada relacionado con entrenamientos.

- Solo es válida desde el punto de vista del cliente, no del entrenador personal,

por lo que no hay posibilidad de interactuar.

FITFOODMARKET.es

Ilustración 6 - Logotipo FITFOODMARKET

FITFOODMARKET.es [6] es una web que se asemeja un poco más al concepto

que tengo de aplicación para el asesoramiento deportivo online.

En ella se ofertan diferentes planes según la modalidad: de entrenamiento,

dietéticos o combinados, los cuales están a disposición del cliente, y que pueden ser

contratados tras contestar a un sencillo formulario personal. Este cuestionario dará a



los entrenadores toda la información relacionada con el estado físico del cliente, su

actividad diaria y todo otro tipo de información que es de relevancia para la elaboración

de planes de entrenamiento y dietas personalizadas.

El acceso a la Plataforma Online de FitFoodMarket es de uso exclusivo para sus

clientes, con un usuario y contraseña, por lo que no he podido investigarla con más

detalle, pero según su web, el usuario tras elegir el plan deseado y rellenar el

formulario con su información personal, debe completar el pago, y un tiempo estimado

de 72h recibe el plan seleccionado, en forma de rutina de entrenamiento o dieta

personalizada.

Además, en su blog comparten diversas recetas y consejos relacionados con la

nutrición y el fitness de bastante utilidad.

Ventajas:

- Bastante completa respecto de la idea de ‘aplicación para el asesoramiento

deportivo online’ que tengo.

- Diseño muy intuitivo.

Inconvenientes:

- Al ser una aplicación de pago no he podido comprobar con detalle su

funcionamiento desde ambos puntos de vista: paneles del cliente y del

entrenador.

A modo de resumen, vemos como existen ciertas aplicaciones cuyas

funcionalidades están orientadas a nuestra idea de aplicación, pero no cubren las

necesidades que considero básicas para esta, y menos aún, reuniéndolas todas.

Un apartado clave es que hecho en falta una aplicación donde los clientes, que

no necesariamente tienen que tener conocimientos sobre entrenamiento o dietas, se

registren y tengan toda esta información accesible a través, y en exclusiva, de la

aplicación. Recalco el hecho de clientes que no tienen conocimientos sobre el tema,

pues para la mayoría de aplicaciones, se requieren ciertos conocimientos.



2.1.4. Definiciones previas

En este apartado mostraremos una serie de definiciones básicas, que creo son

necesarias, para que el lector se familiarice con los conceptos con los que

posteriormente trataremos, y comprenda un poco mejor el contexto del sistema dentro

del campo de seguimiento de dietas y planes de entrenamiento personalizados.

Caloría: una caloría [7] es una unidad energética que sirve como instrumento

para valorar el gasto calórico de un organismo. Las kilocalorías (Kcal), 1000 calorías,

nos informan del poder energético de los alimentos.

Definir: cuando hablamos de definir nos referimos a la capacidad de perder

grasa corporal manteniendo la cantidad de masa muscular intacta.

Dieta: llamamos dieta al conjunto de alimentos que componen el plan nutricional

de una persona en su día a día. Por lo tanto, podemos decir que llega a ser un hábito

o forma de vida. Más concretamente, una dieta debería ser una tabla, realizada de

forma individual y personalizada, adaptada a las necesidades calóricas de cada

individuo, y a su nivel de actividad diario.

Efecto Térmico de la Comida (ETC) [8]: cuando ingerimos un alimento, con X

Kcal, el sistema digestivo precisa de un 5 a un 15% de esta cantidad para procesarlas.

Para realizar esto, el cuerpo necesita de energía y debe recurrir a la ya almacenada,

por lo que produce un aumento del calor necesario para dicho fin.

Gasto Total de Energía (GTE): el Gasto Energético Total de una persona viene

determinado por la suma de: gasto energético asociado a las funciones mínimas del

cuerpo (Tasa Metabólica Basal) + efecto térmico de la comida (ETC) + gasto de las

actividades diarias no asociadas al ejercicio planificado (TNAE) + gasto energético

derivado de la actividad física (TAEF).

HIIT: High Intensity Interval Training – lo que en español significa: Entrenamiento

Interválico de Alta Intensidad. Consiste en realizar ejercicios por intervalos de tiempo,

alternando el nivel de intensidad durante dichos intervalos.



Macronutrientes: son los nutrientes que proporcionan al cuerpo la energía [9]

necesaria para ‘trabajar’. El prefijo macro- viene en relación a la cantidad requerida

por el cuerpo, a diferencia de los micronutrientes que se requieren en menor cantidad.

Existen 3 tipos principales de macronutrientes: Carbohidratos (o Hidratos de

Carbono), Proteínas y Grasas.

Nutrición: la nutrición [10] consiste en el consumo de alimentos de acuerdo a

los requerimientos calóricos y nutritivos del organismo. Podríamos decir que una

correcta nutrición basada en una dieta equilibrada, junto con la actividad física

organizada, es algo básico para gozar de buena salud. Una mala nutrición no

solamente tendrá como resultado un descenso del rendimiento deportivo, aplicado a

la vida diaria, traerá consigo una alteración del desarrollo físico y mental, un descenso

en la resistencia a las enfermedades y una reducción de la productividad diaria.

Objetivo Calórico: el objetivo calórico no es más que la meta en términos de

calorías que el cliente tiene a la hora de contratar una determinada dieta. Podemos

distinguir tres modalidades distintas: pérdida de grasa, si lo que el cliente desea es

reducir su porcentaje de grasa y verse de una manera más atlética; mantenimiento, si

lo que desea es conservar su estado actual, o volumen, para aquellos clientes que

desean aumentar su nivel masa muscular.

Paquete: con el término paquete hacemos referencia a los servicios que el

‘Entrenador Personal’ pone a disposición de los clientes, ya sea a modo de Dieta o

Plan de Entrenamiento (Rutina), por ejemplo.

Petición: en este proyecto, defino petición como la solicitud que un cliente hace

a un entrenador personal, contratando alguno de los servicios ofertados en la

plataforma.

Propósito: dentro de este proyecto, un propósito hace referencia a la modalidad

de entrenamiento al que está dirigido un paquete o servicio ofertado.

Rutina o Plan de Entrenamiento: una rutina o plan de entrenamiento es un

programa que basado en los objetivos específicos del cliente, nos dice el tipo de

entrenamiento que debe seguir para lograrlos. Nos muestra un análisis detallado de

la frecuencia con la que debemos entrenar (días a la semana y grupo muscular que



se entrenará cada día), el volumen de entrenamiento que debemos realizar (número

de ejercicios y repeticiones por ejercicio), e intensidad del entrenamiento.

Tasa Metabólica Basal (TMB): es el cálculo de las necesidades energéticas

mínimas de las que depende el cuerpo humano para mantener las condiciones

básicas (respirar, circulación sanguínea, actividad endocrina, etc.), y está

condicionado por factores tales como: peso, altura, edad, sexo, etc.

Termogénesis: denominamos termogénesis a los procesos de combustión

sobre la energía almacenada en nuestro cuerpo (en mayor medida sobre las grasas)

que debe realizar este para mantener una temperatura corporal de en torno a 37º,

para así garantizar un funcionamiento adecuado de todo el organismo.

Termogénesis Asociada al Ejercicio Físico (TAEF): hace referencia a la

energía gastada en aquellas actividades que tienen que ver con la práctica del

ejercicio físico planificado.

Termogénesis No Asociada al Ejercicio (TNAE): calorías invertidas en

aquellas actividades del día a día que no tienen que ver con la práctica de ejercicio

físico (deporte). En este punto se incluyen actividades como: andar, subir escaleras,

trabajar, fregar, comprar, etc.

2.1.5. Calculando las calorías y macros de una Dieta

Existen diferentes fórmulas que nos indican de qué manera determinar el número

de calorías que una persona ha de ingerir diariamente y el reparto de macronutrientes

que debe realizar para confeccionar una dieta personalizada, pero en este caso vamos

a utilizar el procedimiento ideado por Emma Leigh [11].

En primer lugar, es necesario comentar que son muchos los factores que influyen

a la hora de calcular los requerimientos de mantenimiento calórico de una persona,

así podemos ver:

- Edad: las necesidades calóricas de una persona joven son diferentes a las de

una persona de 80 años.



- Sexo: normalmente, un hombre necesitará una ingesta calórica superior a la

de una mujer.

- Peso Total y Masa Magra: a mayor número de kg de masa magra, mayor será

el gasto calórico.

- Estado Fisiológico del individuo: no es lo mismo una persona que goza de

una salud óptima, que alguien enfermo, o que una mujer embarazada.

- Hormonas: niveles de la tiroides y la hormona de crecimiento.

- Nivel de Ejercicio Físico: cuanto más ejercicio haga una persona, mayor será

el gasto energético.

- Nivel de Actividad Diaria: del mismo modo, el gasto energético no es el mismo

para una persona que camina a diario para moverse, que aquella tiene una vida

o un trabajo más sedentario.

- Dieta del individuo: relacionado con la ingesta de macronutrientes.

Para calcular tus requerimientos calóricos lo ideal sería utilizar un calorímetro (El

calorímetro es un instrumento que sirve para medir las cantidades de calor

suministradas o recibidas por los cuerpos. Es decir, sirve para determinar el calor

específico de un cuerpo, así como para medir las cantidades de calor que liberan o

absorben los cuerpos.). Este método no resulta igualmente práctico para todo el

mundo, por lo que en la mayoría de los casos debemos recurrir a fórmulas estándar

para calcular sus necesidades calóricas.

2.1.5.1. Calcular la Tasa Metabólica Basal (TMB)

Existen diversas fórmulas que nos permiten obtener la Tasa Metabólica Basal,

sin embargo, debemos tener presente que todas son una aproximación de la realidad.

En este apartado, voy a considerar las 3 más utilizadas:

Fórmula de Harris-Benedict: la más inexacta de las tres, por lo que debería

evitarse en la medida de lo posible. Tiende a sobreestimar los requerimientos calóricos

de la persona, por lo que de utilizarla, lo ideal sería un consumo por debajo del valor

indicado. Como veremos, utiliza dos ecuaciones (para hombres y mujeres) puesto que

tiene en cuenta que el hombre posee niveles mayores de masa magra (kg de masa

muscular) que la mujer.



- Hombres: TMB = 66 + [13.7 x peso (kg)] + [5 x altura (cm)] – [6.76 x edad

(años)]

- Mujeres: TMB = 655 + [9.6 x peso (kg)] + [1.8 x altura (cm)] – [4.7 x edad

(años)]

Fórmula de Mifflin-St.Jeor: más realista que la Fórmula de Harris-Benedict,

aunque sigue sin tener en cuenta los porcentajes de grasa del individuo, lo que

provoca una sobreestimación en las necesidades calóricas sobre todo en personas

con sobrepeso.

- Hombres: TMB = [9.99 x peso (kg)] + [6.25 x altura (cm)] – [4.92 x edad

(años)] + 5

- Mujeres: TMB = [9.99 x peso (kg)] + [6.25 x altura (cm)] – [4.92 x edad

(años)] – 161

Fórmula de Katch-McArdle: es la más exacta de las tres, puesto que sí incluye

factores como la masa corporal magra y el porcentaje de grasa corporal. Su uso

debería estar condicionado a una buena estimación del porcentaje graso de la

persona.

- TMB = 370 + (21.6 x IMCM)

Siendo el IMCM = [peso total (kg) x (100 – porcentaje graso)]/100

2.1.5.2. Calcular el Gasto Energético Total (GET) o Termogénesis No Asociada al Ejercicio (TNAE)

Una vez que hemos calculado la Tasa Metabólica Basal, es hora de calcular el

Gasto Energético Total (GET) [12], también llamado Termogénesis No Asociada al

Ejercicio (TNAE). No podemos quedarnos con el dato anterior, puesto que ese es el

valor si no hiciésemos nada más a lo largo del día. Como he comentado anteriormente,

existen distintos agentes que incrementan la TMB.

Es por eso que debemos multiplicar el valor obtenido en el paso anterior por un

factor denominado ‘Factor de Actividad’ o ‘Nivel de Actividad’, que cuantifica el gasto



de las actividades diarias (trabajo, estilo de vida) y un Efecto Térmico de la Comida

promedio del 15%.

Así pues, la escala para cuantificar el ‘Nivel de Actividad’ tenemos:

- 1,2 = Sedentario (escaso o nulo ejercicio y trabajo de oficina)

- 1,3-1,4 = Ligeramente activo (poca actividad diaria y ejercicio ligero 1-3 veces

por semana)

- 1,5-1,6 = Moderadamente activo (vida diaria moderadamente activa y

ejercicio moderado 3-5 veces por semana)

- 1,7-1,8 = Muy activo (estilo de vida físicamente exigente y ejercicio o deportes

intensos 6-7 días por semana)

- 1,9-2 = Extremadamente activo (ejercicio intenso a diario y trabajo físico)

El valor que obtenemos de multiplicar la TMB * Factor de Actividad se denomina

Gasto Energético Total, y es una estimación general, no un valor exacto, ya que es

común que la gente estime en exceso su nivel de actividad, y sin embargo, subestime

su porcentaje de grasa corporal.

La recomendación general es realizar un seguimiento semanal sobre el peso, y

evaluar las medidas corporales cada 2-4 semanas.

2.1.5.3. Calcular la Termogénesis Asociada al Ejercicio Físico (TAEF)

Como he comentado con anterioridad, el valor calculado en el GET (o TNAE),

ofrece los requerimientos calóricos para un día de reposo, en el que sólo se

contemplan las características de la persona, efecto térmico de los alimentos y el nivel

de actividad (trabajo y movimiento diario). Esto está bien para alguien que no practique

deporte alguno, pero lo que realmente interesa en este proyecto es calcular las

necesidades calóricas de la persona que practica deporte con frecuencia en cada uno

de esos días.

En este apartado [13] vamos a calcular las calorías que una persona emplea en

cada uno de esos días de entrenamiento, sea del tipo que sea, diferenciando entre

dos tipos de actividades: entrenamiento con pesas y entrenamiento cardiovascular.



Estas dos actividades las vamos a dividir a su vez según el nivel de intensidad

empleado en la sesión. Esto es:

- Entrenamiento con Pesas: moderado / intenso

- Entrenamiento cardiovascular: moderado / intenso / HIIT

Las fórmulas que emplearemos para calcular el gasto extra en estos días de

entrenamiento son las siguientes:

- Kcal Entrenamiento Con Pesas Moderado:

Peso (kg) x minutos de actividad / 11

- Kcal Entrenamiento Con Pesas Intenso:

Peso (kg) x minutos de actividad / 9.5

- Kcal Entrenamiento Cardiovascular Moderado:

0,06 x Peso (kg) x 2,2 x minutos de actividad

- Kcal Entrenamiento Cardiovascular Intenso:

0,129 x Peso (kg) x 2,2 x minutos de actividad

- Kcal Entrenamiento Cardiovascular HIIT:

0,7 x [0,06 x Peso (kg) x 2,2 x minutos de actividad] + 0,3 x [0,129

x Peso (kg) x 2,2 x minutos de actividad]

Lo único que tendríamos que hacer ya es sumar el valor según el tipo de

entrenamiento que realicemos en un día, a la cantidad calculada en el GET, para

obtener el total para un día de actividad deportiva completa.

2.1.5.4. Ajustar el valor de mantenimiento según los objetivos

Una vez que tenemos los requerimientos calóricos de la persona a la que

estamos calculando la dieta, es hora de ajustar dicho valor según sus objetivos.

Recordando lo que llevamos hasta ahora, el GET + las calorías extra según el nivel

de entrenamiento nos dan los requerimientos calóricos de la persona pero para un

situación de mantenimiento, es decir, si el objetivo de esta fuese mantener su peso

estable, pero en la mayoría de los casos lo que el cliente desea es reducir su nivel de

grasa, o aumentar la masa corporal magra (ganar músculo).



Para ajustar este valor existen dos opciones:

- Emplear cantidades genéricas de calorías: por ejemplo, sumar 400KCal

diarias si lo que se quiere es aumentar la masa muscular, o restar 400KCal si

lo que se quiere es perder grasa.

El inconveniente de este método es que el efecto de una caloría varía para cada

individuo, según su peso, estatura, morfología, ingesta calórica total diaria, etc. Como

ejemplo, sumar/restar 400KCal diarias no es lo mismo para una persona que consume

2000KCal al día, que para otra que consume 4000KCal.

- La opción que realmente da resultados, es ajustar dicho valor con un

porcentaje. Para no hacerlo de manera muy brusca, lo ideal es utilizar un valor

que no supere el 10%, e ir ajustándole semanalmente.

Pongamos como ejemplo una persona que toma al día 2000KCal. Si el objetivo

de esta persona fuese aumentar su masa muscular, lo que haríamos sería sumar a

estas 2000KCal un 10%, esto es, 2000 + 200 = 2200KCal diaria, para crear un

superávit de 200KCal diarias. Si por el contrario quisiera perder grasa, debería

consumir 1800KCal en lugar de las 2000KCal que marca el valor de mantenimiento.

2.1.5.5. Requerimientos de macronutrientes

Una vez realizado el análisis de la demanda calórica, necesitaremos saber cómo

repartir estas calorías entre los distintos macronutrientes [14]. A diferencia de lo que

comúnmente se cree, este reparto no debe hacer según porcentajes, sino que debe

calcularse respecto a cantidades suficientes de acuerdo a la masa magra o al peso

total. La idea de este apartado es sintetizarlo lo máximo posible, para que al cliente le

resulte lo más sencillo posible entender su dieta.

Pasamos a ver los gramos de cada macronutriente que se aconsejan tomar por

kilogramo de peso según cada caso:



Proteínas

Ilustración 7 - Alimentos altos en proteínas

Según las recomendaciones generales, en base a diferentes estudios [15],

siempre que se reciba la cantidad de calorías y carbohidratos necesarios, la ingesta

de proteínas por kilo ha de ser:

- Entrenamiento con pesas: 1,4 a 2 gr por kg de peso corporal.

- Entrenamiento de resistencia: 1,2 a 1,8 gr por kg de peso corporal.

- Entrenamiento en adolescentes: 1,8 a 2,2 gr por kg de peso corporal.

Si bien es cierto que estos mismos estudios reconocen que cuanto más

restrictiva es la dieta, o más baja en carbohidratos es, mayor debe ser la ingesta de

proteína. A parte de esto, las recomendaciones generales para las personas que

practican el culturismo (mayor estrés físico y psicológico derivado de mayores cargas

de entrenamiento e intensidad) son:

- Si crees tener una cantidad moderada de grasa: 2-2,5 gr por kg de peso

corporal.

- Si conoces tu cantidad de grasa corporal: 2-3 gr por kg de peso corporal

magro.

Por otra parte, para niveles bajos de grasa o para dietas muy bajas en calorías,

se necesitan cantidades incluso mayores de proteína:



- Porcentaje graso moderado, baja ingesta de calorías: 2,5-3 gr por kg de peso

corporal.

- Muy magro, baja ingesta de calorías: 2,5-4 gr por kg de peso corporal magro.

Para personas con sobrepeso, con un estilo de vida sedentario, o simplemente

aquellas que siguen una dieta alta en calorías, la cantidad recomendada de proteína

por kg suele ser entre 1,5 y 2 gr de proteína por kg de peso corporal, o de 2gr por kg

de masa muscular.

Existe una estrecha relación entre el consumo de proteína y los niveles de

saciedad, el control de azúcar en la sangre y la hipertrofia muscular (aumento de la

masa muscular).

El aporte calórico de las Proteínas es de 4KCal por gramo.

Grasas

Ilustración 8 - Grasas saludables

Se encuentran en diferentes proporciones en ciertos alimentos tanto de origen

animal como vegetal, y no todas las grasas son igualmente necesarias para mantener

la salud. Por ejemplo, los ácidos grasos insaturados (omega-3 y omega-6) que son un

tipo de estructura que poseen las grasas, son necesarios para diferentes funciones

fisiológicas, y puesto que el cuerpo no es capaz de sintetizarlos, sólo se pueden

obtener a través de la comida.

Comúnmente se aconsejan tomar proporciones similares a estas cantidades:

- Si tu porcentaje graso es promedio: 1-2 gr de grasa por kilo de peso corporal.

- Para porcentajes altos de grasa: 1-2 gr de grasa por kg de masa magra.



El aporte calórico de las Grasas es de 9KCal por gramo.

Hidratos de carbono

Ilustración 9 - Hidratos de Carbono

Se trata de un macronutriente de vital importancia para deportistas con grandes

cargas de intensidad en el entrenamiento, o para aquellos que desean aumentar su

masa corporal.

El aporte calórico de los Hidratos de Carbono es de 4KCal por gramo.

No existen recomendaciones corporales mínimas de carbohidratos, por lo que

para calcular las cantidades que una persona ha de ingerir basta con calcular:

- KCal de Hidratos de Carbono: Requerimiento calórico total – [(gramos de

proteína x 4) + (gramos de grasas x 9)]

- Gramos de Hidratos de Carbono: KCal de HC / 4

Como he comentado, los carbohidratos son especialmente importantes para

deportistas con alto volumen de entrenamiento, si este es el caso, se recomienda

calcular las ‘necesidades’ de carbohidratos a modo prioritario, así pues:

- Moderadamente activo: 4.5-6.5 gr por kg

- Altamente activo: 6.5-8,5 gr por kg

- Intensamente activo: +8,5 gr por kg



2.1.6. ¿Qué es una rutina o plan de entrenamiento?

Este apartado no pretende ser una guía sobre cómo se debe diseñar una rutina

o plan de entrenamiento (puedes consultar más información sobre cómo crear tu rutina

aquí [16]), sino que el objetivo es familiarizar al lector con estos conceptos.

En primer lugar vamos a introducir el concepto de grupo muscular, entendiendo

como tal las clases o diferentes tipos de músculos que posee el ser humano. Podemos

diferenciar tres grupos musculares diferentes:

- Grupos grandes: a los que pertenecen: pectoral, espalda, cuádriceps y femoral.

- Grupos intermedios: hombros y glúteos.

- Grupos pequeños: trapecio, bíceps, tríceps, antebrazos, abdominales, oblicuos

y abductores.

Aunque existen diferentes tipos de rutinas de entrenamiento, por lo general, el

método más utilizado es el Método Weider [17], quien debe su nombre a Joe Weider,

y que está basado en una serie de principios que, MUY simplificados y aplicados a

este proyecto, son los siguientes:

- El año de entrenamiento se divide en ciclos destinados a objetivos: ganancia

de fuerza, aumento de masa muscular y pérdida de grasa.

- El tipo de entrenamiento dentro de una semana lo dividiremos en tren superior

y tren inferior, considerando como tren superior e inferior a los músculos

pertenecientes a la parte superior o inferior del cuerpo.

- Entrenaremos un grupo muscular o dos por día.

- Los entrenamientos se dividen por ejercicios, que a su vez están compuestos

de series y repeticiones, los que deben ir variando secuencialmente.

Como he comentado, existen otras opciones, o tipos de entrenamiento, como el

fullbody, en el que se realizan circuitos de todos los grupos musculares en cada sesión

de entrenamiento. Normalmente este tipo de entrenamiento se realiza tres días a la

semana (si se trabajan todos los músculos) o cuatro (si se divide en tren superior e

inferior).



2.1.7. Perfiles de usuario

Es clave identificar el tipo de usuario que utilizará la aplicación para tenerlo en

cuenta en el diseño de la misma, por eso, a continuación voy a explicar los dos

principales perfiles de usuario de la aplicación, junto con una descripción de sus

principales funcionalidades.

Por una parte tenemos a los ‘Entrenadores Personales’, pero ¿qué puede hacer

exactamente un ‘Entrenador Personal’?

Un ‘Entrenador Personal’ hace las veces de administrador de la plataforma,

pudiendo entre otras cosas:

- Gestionar Clientes, esto es: añadir o dar de baja cuentas de usuario, ver y

modificar datos personales, o listar usuarios.

- Gestionar Paquetes ofertados en la web: añadir o eliminar paquetes, modificar

datos de un paquete, o listar paquetes.

- Gestionar Ejercicios y Alimentos: añadir, eliminar, modificar, y listar

ejercicios/alimentos.

- Además, recibirá y atenderá las peticiones enviadas por parte del cliente, en

las que solicita alguno de sus servicios. Para atender una petición, el

entrenador recibe el formulario de contratación enviado por parte del cliente, y

dependiendo del tipo de servicio seleccionado, iniciará el proceso de diseño y

asignación de Dieta o Rutina a dicho cliente, completando una serie de

sencillos pasos a través de la web.

- Mandar y recibir mensajes con cualquier otro usuario de la plataforma.

Por otra parte, tenemos los usuarios de tipo ‘Cliente’, quien podrá darse de alta

en la plataforma rellenando un simple formulario de registro y acceder a ella. Una vez

en la plataforma, un cliente podrá modificar sus datos personales (sólo los campos

modificables), consultar un histórico de todas sus peticiones enviadas, dietas

personalizadas o planes de entrenamiento (rutinas) individualizado. Así mismo, podrá

consultar el listado de paquetes, o servicios, ofertados en la plataforma y con unas

características u objetivos determinados, con la posibilidad de contratar dichos

servicios rellenando un formulario de contratación, un cuestionario que responde a



toda la información que los entrenadores deben conocer sobre el cliente. Por último,

podrá mandar y recibir mensajes de los entrenadores registrados en la plataforma.

En este apartado, vamos a realizar un análisis de las principales metodologías

existentes en el mercado, para el desarrollo de aplicaciones web.

2.1.8. Metodologías tradicionales vs Metodologías ágiles

Aunque existen multitud de metodologías que aplicar en la gestión de proyectos,

en este apartado vamos a repasar brevemente las más utilizadas en la actualidad,

diferenciando para ello dos tipos de metodologías de gestión de proyectos:

metodologías clásicas y metodologías ágiles. Independientemente de sus ventajas e

inconvenientes, todas ellas nos ayudarán a planificar nuestro proyectos y administrar

de la manera más adecuada los recursos de los que se dispone.

En primer lugar, vamos a repasar la más que conocida metodología para la

gestión de proyectos tradicional [18], basada en Diagrama de Gantt. Esta

metodología lleva practicandose más de 70 años, y aún es considerada una de las

más famosas, debido, entre otras cosas, a su simplicidad. Como resumen, su

funcionamiento podría definirse en:

- Definir el alcance del proyecto que se desea analizar.

- Este proceso ha de dividirse en fases o hitos, que a su vez estarán

compuestos de tareas y subtareas. Además, para cada una de estas es

necesario estimar su duración.

- Diseñar un cronograma, en el que de izquierda a derecha representaremos

las unidades de tiempo estimadas, y de arriba hacía abajo las fases o tareas

en las que está dividido el proyecto.

- Las tareas estrán representadas en el gráfico como barras horizontales, cuya

longitud vendrá determinada por la duración que se haya estimado que dura

dicha tarea.

- El gráfico incluirá tanto la fecha de inicio del proyecto, como la fecha de fin.



En el otro bando, el de las metodologías ágiles [19], la más utilizada es la llamada

metodología SCRUM [20]¸ cuyas características repasamos a continuación:

“Scrum es un proceso en el que se aplican de manera regular un conjunto de

buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor

resultado posible de un proyecto.” [20]

El trabajo, según el método SCRUM, se divide en entregas o sprints (también

llamadas iteraciones), en las que periódicamente (de 2 a 4 semanas normalmente) se

va inspeccionando el trabajo. El proceso que se sigue, a modo de resumen, es el

siguiente:

- Al inicio de cada sprint se realiza una reunión con el cliente, en el que se

determinan los requisitos que tendrá la entrega.

- El cliente ordena estos requisitos de acuerdo a sus prioridades, creando lo

que se conoce como product backlog, o pila de producto.

- El equipo de desarrollo coge un grupo de requisitos, y trabaja durante el

sprint, para al finalizar entregar un resultado concreto, referente a dicha

iteración.

- Este proceso se repite hasta que no queden requisitos.

Como vemos existe una diferencia principal entre los dos métodos comentados,

y es que mientras en el enfoque clásico se realiza una planificación global del

proyecto, la idea de las metodologías ágiles es ir revisando periodicamente el trabajo

realizado.

Ilustración 10 - Tradicional VS Ágil



2.1.9. Aplicaciones web vs Aplicaciones de escritorio

En este apartado comentaré brevemente las diferencias que existen entre estas

dos opciones, analizando para ello las ventajas e inconvenientes de cada una de ellas,

algo que me ayudará a tomar una decisión sobre por qué elegir un tipo de aplicación

u otro.

- Aplicaciones Web

Respecto de las ventajas de este tipo de aplicaciones encontramos que son

bastante ligeras, con lo que no necesitamos de grandes equipos informáticos

para ejecutarlas (aunque sí se requiere de cierta capacidad para

implementarlas); se ejecutan a través de la web, lo que facilita su portabilidad;

los procesos de actualización y mantenimiento son bastante asequibles; su

independencia del sistema operativo hace que nos despreocupemos de

problemas de compatibilidad; etc.

Pero también presentan una serie de desventajas o incovenientes, derivado

entre otras cosas del uso de internet: conexiones lentas, mala elección de un

diseño que no garantice la robustez e independencia de las tecnologías

utilizadas necesarias, mal tiempo de respuest, etc.

- Aplicaciones de Escritorio

Habitualmente, la ejecución de este tipo de aplicaciones se realiza de manera

local, es decir, sin necesidad de recurrir a recursos externos, lo que mejora

notablemente la velocidad de procesamiento y la estabilidad de la aplicación.

Aunque el tiempo de respuesta puede ser mejor que el de las aplicaciones web,

depende en gran medida de los recursos hardware del equipo donde se

ejecutan

También en el apartado de los inconvenientes, es necesario señalar que este

tipo de aplicaciones han de ser instaladas en el equipo en el que se vayan a

ejecutar, por lo que dependen del sistema operativo en el que lo hagan.

Además, su uso está limitado a cada equipo donde esté instalada la aplicación.



Para este proyecto, se necesita de una aplicación que disponga de una interfaz

intuitiva, familiar para los diferentes usuarios, y que les permita utilizarla desde

cualquier parte, sin ningún tipo de limitación hardware, para tener la posibilidad de

acceder a ella incluso desde dispositivos móviles. Teniendo en cuenta estas

características, queda claro que la opción que más se ajusta a nuestras necesiades,

es la de una aplicación web.

2.1.10. Evolución de la Web

Desde la aparición en los años 60’s del concepto de ‘Internet’ hasta ahora, ha

habido un largo camino evolutivo en el mundo de ‘la web’. Quién nos diría hoy en día,

en una sociedad totalmente dependiente de las redes sociales, las cuales nos

permiten comunicarnos al instante con alguien que podría estar en cualquier parte del

mundo, que ‘internet’ en sus inicios fue concebida como un arma militar.

En el siguiente gráfico, vamos a repasar de forma muy breve los principales

avances introducidos en la web.

Ilustración 11 - The Evolution of The Web

En 1989, nace el protocolo HTTP que aún hoy se sigue utilizando, basado en

la transferencia de hipertexto. El protocolo sigue un esquema en el que un navegador



web realiza una petición a un servidor por medio de una URL que identifica la

información que se transmite.

Poco más tarde, aparece HTML, HiperText Markup Language, el lenguaje

utilizado para la creación de páginas web de manera estática, con la posibilidad de

añadir texto, imágenes o vídeos, entre otros. Es necesario comentar, que este

estándar se fue desarrollando con los años, introduciendo diferentes versiones del

mismo, hasta la versión HTML5 que surge en 2012 y que es la que utilizamos

actualmente.

En 1993, se produce un cambio en la forma de entender o de trabajar con la

información web, con la aparición de CGI (Common Gateway Interface), cuyo

objetivo es el de añadir una mayor interacción a las páginas web, por medio de scripts

que trabajan con información dinámica.

En 1995, surge PHP (HiperText PreProccesor), otro lenguaje de programación

para la creación de contenido dinámico, pero esta vez, del lado del servidor. Está

caracterizado por su simplicidad para nuevos programadores, aunque al mismo

tiempo, ofrece una larga biblioteca de características para programadores avanzados.

En 1996, aparece el lenguaje de programación interpretado (sus instrucciones

se ejecutan de manera directa, sin necesidad de recurrir a un compilador), JavaScript.

Utilizado principalmente desde la perspectiva del cliente, como una parte del

navegador web.

Ilustración 12 - Tecnologías Web



En este mismo año, W3C desarrolla XML (Extensible Markup Language), el

que se consagra como un lenguaje de etiquetas orientado a contenidos, en lugar de a

presentación. Su principal funcionalidad es el almacenamiento e intercambio de datos

de una forma más ordenada.

Sin duda, 1996 fue un año de avances, prueba de ello es que en este mismo

año, otra compañía como Macromedia, lanza Flash, basado en el lenguaje de

programación ActionScript, es un pluggin para los navegadores web que permite

ejecutar animaciones y demás contenido dinámico. También aparece CSS

(Cascading Style Sheets), quien pretende separar la estructura de un documento de

su presentación, definiendo para ello hojas de estilo, siendo su última versión CSS3.

Para finalizar con esta evolución de la Web, destacar la inclusión en 2006 de

jQuery, librería de JavaScript para simplificar la forma de interactuar con los

documentos HTML, y el nacimiento en 2010 del concepto ‘Responsive Web Design’,

basado en la adaptación de los navegadores o contenido web a los diferentes

dispositivos.

2.1.11. Tecnologías para el desarrollo de aplicaciones web

En relación a las metodologías o patrones para el diseño de la arquitectura del

software, vamos a analizar dos alternativas que aunque están fundamentadas en el

desarrollo de aplicaciones en Java, funcionan con dos modelos de trabajo

completamente distintos, cada uno de ellos enfocados a un tipo de aplicación

diferente. En este caso vamos a analizar las características del framework SpringMVC

y JavaServer Faces.

Por un lado tenemos el framework de desarrollo software SpringMVC [21], que

es de tipo push-based (también conocido como action-based) pues los datos se

‘ponen’ en las vistas, es decir, se envían. Su arquitectura se basa en el MVC (Modelo-

Vista-Controlador) clásico, en el que de una parte tenemos los datos y la lógica de

negocio, y de otra, la interfaz de usuario.

Entre las ventajas de utilizar Spring MVC tenemos:



- Para desarrollar una aplicación bajo el framework Spring no es necesario

implementar una interfaz propia, sino que a través de una serie de

anotaciones tendremos la oportunidad de utilizar sus funcionalidades o

beneficios ofrecidos, lo que hará nuestro código mucho más reutilizable que

si utilizamos otro framework.

- El uso de la programación orientada a objetos, utilizado por Spring, dota a

nuestra aplicación de un diseño modular, lo que proporcionará un código más

limpio, ordenado y elegante, con unos niveles de acoplamiento muy bajos.

- Es muy sencillo cofigurar un proyecto para trabajar con Spring, y además

permite la integración con otras herramientas.

- Gracias al uso de anotaciones, y la inyección de dependencias propia del

framework, la labor de crear objetos resultará mucho más sencilla.

- Fácil gestión a la hora de validar datos de entrada, a través del uso de Bean

Validation.

Por otra parte, tenemos el framework JavaServer Faces, de tipo pull-based (o

component-based), en el que las vistas ‘recogen’ los datos de los controladores. Su

arquitectura esá basada en MVP (Modelo-Vista-Presentador) o MVVM (Modelo-Vista-

Vista-Modelo), y es el framework perfecto para interfaces de usuario avanzadas

(interfaces RIA), es decir, aplicaciones web que comparten las características

principales de las tradicionales aplicaciones de escritorio, en las que se produce un

flujo de información muy fluído entre el usuario y la aplicación.

Ilustración 13 - MVC VS MVP VS MVVM



Las principales ventajas de desarrollar una aplicación con el framework JSF [22]

serían:

- Existe una clara separación entre el comportamiento y la presentación, lo que

permite a los miembros del equipo de desarrollo de una appweb centrarse en

su parte del proceso de desarrollo, facilitando la labor de integrar todos estos

elementos.

- Aunque la tecnología JavaServer Faces incluye una librería de etiquetas JSP

personalizadas para representrar componentes en una página JSP, los APIs

de la tecnología JavaServer Faces se han creado directamente sobre el API

JavaServlet. Esto nos permite hacer algunas cosas: usar otra tecnología de

presentación junto a JSP, crear nuestros propios componentes

personalizados directamente desde las clases de componentes, y generar

salida para diferentes dispositivos cliente.

- Por último, JavaServer Faces proporciona una rica arquitectura para manejar

el estado de los componentes, procesar los datos, validar la entrada del

usuario, y manejar eventos.

Como podemos observar, el uso de frameworks nos aporta una serie de ventajas

como:

- El desarrollo de las aplicaciones se hace más rápido, pues el framework nos

facilita una serie de componentes que nos liberan de ciertos trabajos.

- Reutilización de componentes.

- Mayor modularidad del código.

- Aplicaciones más robustas.

Entre las desventajas tenemos:

- La curva de aprendizaje, pues cuanto mayor sea el dominio que tenemos

sobre un determinado framework, posiblemente sea mayor el esfuerzo que

requiramos a la hora de aprender otro distinto.

- Estamos demasiado ceñidos a ese framework, y la posibilidad de incluir otros

componentes se puede hacer tedioso.



2.1.12. Arquitectura básica de una aplicación web

Ilustración 14 - Arquitectura de una Aplicación Web

Como podemos observar en la ilustración anterior, una aplicación web [23] se

compone básicamente de tres elementos principales:

- Cliente: principalmente formado por los navegadores web, los cuales

interpretan las peticiones del usuario y le presentan los resultados a este.

Realiza las conexiones con el servidor, recupera y procesa la información, e

interacciona con el usuario.

- Servidor: constituido a su vez por: Servidor Web, Servidor de Aplicaciones y

BBDD. Es la parte más importante de la aplicación, pues determina los

procesos que dan la funcionalidad a la aplicación, define cómo se trabaja con

la BBDD y con los archivos que manejan la aplicación.

- Comunicación: normalmente basada en el protocolo orientado en

transacciones HTTP.



2.1.13. Servidores: Tomcat vs GlassFish

En este apartado veremos dos de las principales alternativas del mercado en

cuanto a servidores web se refiere.

En primer lugar, tenemos Tomcat [24], que bajo licencia de Apache, es

probablemente el servidor web con mayor uso en la actualidad a la hora del desarrollo

web basado en lenguaje de programación Java. Tomcat, que funciona como

contenedor de servlets, fue desarrollado por Apache Software Foundation y es aún

mantenido por los miembros de dicha fundacióny por voluntarios independientes.

En segundo lugar, tenemos GlassFish [25]. En este caso se trata de un servidor

de aplicaciones, de software libre, desarrollado por Sun Microsystems, que

implementa las tecnologías definidas por la plataforma JavaEnterprise Edition

(JavaEE).

Tomcat tiene la ventaja de ser más ligero que su competidor, además de ser una

opción más asentada. Ambos están desarrollados en Java, lo que los hace altamente

compatibles con este lenguaje. Ambos utilizan el contenedor de servlets Catalina.

Mientras que Tomcat funciona sólo como contenedor web, GlassFish nos

proporciona una suite más completa de contenedores o componentes JavaEE.

En este enlace [26], podemos consultar una comparativa sobre el uso de

servidores web, realizada este mismo año. La siguiente imagen muestra el reparto del

mercado entre este tipo de servidores.

Ilustración 15 - Comparativa Servidores



2.2. Propuesta de solución

Hasta ahora, hemos realizado un análisis exhaustivo sobre el tema que vamos

a tratar en esta memoria; el FITNESS, junto con la oferta actual respecto de

aplicaciones o herramientas especializadas en el Asesoramiento Deportivo Online,

también se ha evaluado el por qué de este proyecto, y la manera de abordar de forma

clara la solución que nosotros podemos dar a un problema o necesidad de mercado

existente.

Una vez que tenemos clara la idea a desarrollar, es hora de diseñar los

mecanismos que se utilizarán para poder llevarla a cabo. En este sentido, se ha

decidido aplicar un patrón básico de arquitectura software, como es el Modelo-Vista-

Controlador, en el que por una parte tengamos la interfaz de usuario; o la parte

accesible por el usuario final de la aplicación, y por otra, la lógica de negocio, es decir,

la forma en la que internamente se trabaja y ‘se mueven’ los datos. La idea es plantear

un diseño MVC en el desarrollo web para garantizar una aplicación robusta,

independientemente de las tecnologías que se usen finalmente.

Este modelo ha sido escogido también por poseer una serie de ventajas que

posteriormente facilitarán la labor de trabajar con él, como son su diseño modular o

escalabilidad.

Dentro del abanico de posibles opciones dentro del patrón MVC, se va a recurrir

al framework de desarrollo JVM push-based SpringMVC, por disponer de un código

ordenado, facilidad a la hora de configurar sus elementos, capacidad de integrarse

con otras herramientas y en definitiva, por ser el framework que más se adapta a

nuestras necesidades.

En el apartado de la interfaz de usuario, se ha optado por recurrir a un framework

libre como Twitter Bootstrap, por su más que innegable éxito y popularidad dentro

de los usuarios de redes sociales. Sin duda, este framework nos facilitará el trabajo

puesto que de manera gratuita nos proporciona un conjunto de plantillas de estilos

para la programación en la parte del cliente que darán no sólo una funcionalidad más

que aceptable, sino que su intuitividad harán que los usuarios se sientan mucho más

cómodos utilizando la aplicación que de usar otro.



2.3. Requerimientos del sistema

El Análisis de Requerimientos del Sistema es una labor dentro del campo de la

Ingeniería del Software [27] que comprende el espacio entre la definición del software,

a nivel de sistema, y el Diseño de Software. Este análisis nos permite especificar de

forma detallada las funcionalidades del software, así como las propiedades que debe

cumplir y establece las restricciones que debe satisfacer el software.

Algunas de las principales tareas de análisis en las cuáles se divide el Análisis

de Requisitos Software [28] son:

- Debe tenerse una comprensión clara del problema para el que se plantea el

proyecto, antes de iniciar la creación del modelo de análisis.

- Cada requerimiento debe quedar plasmado, junto a una razón de su existencia.

- Es muy importante priorizar los requerimientos.

- No debe existir ambigüedad.

Como analista, las principales técnicas que se deberían usar para tener un

conocimiento lo más preciso posible, y adaptado a las necesidades del cliente que

nos encarga el proyecto, son: entrevistas, observación del funcionamiento de la

empresa para la que se realizará el proyecto, encuestas con el cliente o empleados

del sistema, revisión de documentos y un correcto uso de las especificaciones

formales para requerimientos: cumplimiento de los estándares establecidos, Lenguaje

de Modelado Unificado UML, etc.

Es fundamental tener buena comunicación con el cliente, y tener gozar de cierto

grado de confianza, para facilitar la labor de análisis.

El proceso para la obtención de los requisitos del sistema debe considerarse en

la especificación del Propósito del Sistema, siendo una de las tareas más costosas, y

a la vez más importantes. En este proceso, intervienen tres tipos destacados de

actores: cliente (quien encarga el proyecto), desarrolladores (personal encargado de

realizar el proyecto) y usuarios (que serán los encargados de trabajar con la aplicación

una vez desarrollada). Entre todos, describen el problema y definen el sistema

encargado de solucionar dicho problema. Esta definición es conocida como:

especificación de requisitos del software.



Para obtener los requisitos y realizar el análisis, se tiene en cuenta la visión que

el propio usuario tiene del sistema.

Definimos dos tipos de requisitos:

- Requisitos funcionales: describen de manera específica el funcionamiento

del sistema. Se incluye cualquier usuario o sistema externo que interactúe con

el propio sistema.

- Requisitos no funcionales: relacionados con factores externos al sistema.

Nos proporcionan una idea de cómo debe ser el sistema. En ese apartado hay

que detallar características del sistema que no están relacionados de manera

directa con los requisitos funcionales.

A continuación, paso a detallar cuáles son los requerimientos de mi proyecto.

2.3.1. Requerimientos Funcionales

Pasamos a ver los Requerimientos Funcionales de esta aplicación. Como he

comentado anteriormente, nos darán una descripción del funcionamiento del sistema,

tratando de contemplar todas las necesidades del cliente. También se mostrará el

comportamiento del sistema frente a ciertas situaciones.

Las funcionalidades consideradas han sido las siguientes:

1) RF-01 – Registro de Usuario: el usuario debe disponer de un mecanismo de

registro que le permita crear un perfil de usuario para poder acceder al

contenido de la plataforma.

2) RF-02 – Identificación de Usuario: el usuario debe poder identificarse en la

plataforma, introduciendo los datos de usuario con los que previamente se ha

registrado, para poder acceder al contenido de la plataforma.

3) RF-03 – Escribir Mensaje Usuario: el usuario, de tipo ‘Entrenador Personal’,

debe disponer de un mecanismo que le permita contactar o mandar mensajes

a cualquiera de los demás usuarios disponibles en la plataforma.

4) RF-04 – Consultar Listado de Usuarios: el usuario, de tipo ‘Entrenador

Personal’, debe poder consultar cuando así lo precise, el listado con todos los

usuarios registrados en la plataforma, tengan el rol asignado que tengan.



5) RF-05 – Añadir Nuevo Usuario: el usuario, de tipo ‘Entrenador Personal’, debe

tener disponible una opción para registrar manualmente un nuevo usuario en

la plataforma.

6) RF-06 – Modificar Datos de Usuario: un usuario, de tipo ‘Entrenador

Personal’, debe poder modificar los datos (sólo que se puedan modificar) de

cualquier usuario registrado en la plataforma.

7) RF-07 – Eliminar Usuario: un usuario, de tipo ‘Entrenador Personal’, debe

tener la opción de eliminar todos los datos relacionados con un usuario

registrado en la plataforma.

8) RF-08 – Visualizar Datos de Usuario: un usuario, de tipo ‘Entrenador

Personal’, debe tener la opción de consultar los datos de cualquier usuario


9) RF-09 – Consultar Mensajes de Usuario: un usuario, de tipo ‘Entrenador

Personal’, debe disponer de una opción que le permita consultar el listado de

mensajes asociados a cualquier usuario registrado en la plataforma, tanto

mensajes recibidos como mensajes enviados por dicho usuario.

10) RF-10 – Eliminar Listado de Mensajes asociados un usuario: un usuario,

de tipo ‘Entrenador Personal’, debe tener la posibilidad de eliminar el listado de

mensajes asociado a cualquier usuario registrado en la plataforma.

11) RF-11 – Eliminar Mensaje: un usuario, de tipo ‘Entrenador Personal’, podrá

eliminar cualquier mensaje que aparezca en el listado de mensajes asociados

a cualquier usuario registrado en la plataforma.

12) RF-12 – Modificar Mensaje: un usuario, de tipo ‘Entrenador Personal’, debe

tener disponible la opción de modificar mensaje, que le permita cambiar marcar

como ‘leído’ o ‘no leído’ cualquier mensaje recibido.

13) RF-13 – Consultar Listado de Peticiones de un Cliente: un usuario, de tipo

‘Entrenador Personal’, debe disponer de una opción que le permita consultar el

listado de peticiones enviadas por cualquier cliente registrado en la plataforma,

junto a los datos de cada una de ellas.

14) RF-14 – Consultar Listado de Dietas de un Cliente: un usuario, de tipo


listado de dietas asociadas a cualquier cliente registrado en la plataforma, junto

a los datos de cada una de ellas.



15) RF-15 – Consultar Listado de Rutinas de un Cliente: un usuario, de tipo


listado de rutinas asociadas a cualquier cliente registrado en la plataforma,

junto a los datos de cada una de ellas.

16) RF-16 – Eliminar Petición: un usuario, de tipo ‘Entrenador Personal’, podrá

eliminar cualquier petición que aparezca en el listado de peticiones asociadas

a cualquier cliente registrado en la plataforma.

17) RF-17 – Eliminar Dieta: un usuario, de tipo ‘Entrenador Personal’, podrá

eliminar cualquier dieta que aparezca en el listado de dietas asociadas a

cualquier cliente registrado en la plataforma.

18) RF-18 – Eliminar Rutina: un usuario, de tipo ‘Entrenador Personal’, podrá

eliminar cualquier rutina que aparezca en el listado de rutinas asociadas a

cualquier cliente registrado en la plataforma.

19) RF-19 – Eliminar Petición: un usuario, de tipo ‘Entrenador Personal’, podrá

eliminar cualquier petición que aparezca en el listado de peticiones asociadas

a cualquier cliente registrado en la plataforma.

20) RF-20 – Consultar Listado de Ejercicios: un usuario, de tipo ‘Entrenador


ejercicios disponibles en la BBDD de Ejercicios de la plataforma, junto a los

datos de cada uno de ellos.

21) RF-21 – Consultar Listado de Alimentos: un usuario, de tipo ‘Entrenador


alimentos disponibles en la BBDD de Alimentos de la plataforma, junto a los


22) RF-22 – Consultar Listado de Paquetes: un usuario, de tipo ‘Entrenador


paquetes disponibles en la BBDD de Paquetes de la plataforma, junto a los


23) RF-23 – Añadir Nuevo Ejercicio: un usuario, de tipo ‘Entrenador Personal’,

debe disponer de una opción que le permita añadir un nuevo Ejercicio a la

BBDD de Ejercicios de la plataforma.

24) RF-24 – Añadir Nuevo Alimento: un usuario, de tipo ‘Entrenador Personal’,

debe disponer de una opción que le permita añadir un nuevo Alimento a la

BBDD de Alimentos de la plataforma.



25) RF-25 – Añadir Nuevo Ejercicio: un usuario, de tipo ‘Entrenador Personal’,

debe disponer de una opción que le permita añadir un nuevo Ejercicio a la

BBDD de Ejercicios de la plataforma.

26) RF-26 – Añadir Nuevo Paquete: un usuario, de tipo ‘Entrenador Personal’,

debe disponer de una opción que le permita añadir un nuevo Paquete a la

BBDD de Paquetes de la plataforma.

27) RF-27 – Añadir Nuevo Propósito: un usuario, de tipo ‘Entrenador Personal’,

debe disponer de una opción que le permita añadir un nuevo Propósito a la

BBDD de Propósitos de la plataforma.

28) RF-28 – Modificar Alimento: un usuario, de tipo ‘Entrenador Personal’, debe

disponer de una opción que le permita modificar los datos de un Alimento

existente en la BBDD de Alimentos de la plataforma.

29) RF-29 – Modificar Ejercicio: un usuario, de tipo ‘Entrenador Personal’, debe

disponer de una opción que le permita modificar los datos de un Ejercicio

existente en la BBDD de Ejercicios de la plataforma.

30) RF-30 – Modificar Paquete: un usuario, de tipo ‘Entrenador Personal’, debe

disponer de una opción que le permita modificar los datos de un Paquete

existente en la BBDD de Paquetes de la plataforma.

31) RF-31 – Eliminar Alimento: un usuario, de tipo ‘Entrenador Personal’, debe

disponer de una opción que le permita eliminar los datos asociados a un

Alimento existente en la BBDD de Alimentos de la plataforma.

32) RF-32 – Eliminar Ejercicio: un usuario, de tipo ‘Entrenador Personal’, debe


Ejercicio existente en la BBDD de Ejercicios de la plataforma.

33) RF-33 – Eliminar Paquete: un usuario, de tipo ‘Entrenador Personal’, debe


Paquete existente en la BBDD de Paquetes de la plataforma.

34) RF-34 – Consultar Listado de Alimentos asociados a una Dieta: un usuario,

de tipo ‘Entrenador Personal’, debe disponer de la opción de consultar el

Listado de Alimentos incluidos en una Dieta asociada a un cliente determinado,


35) RF-35 – Consultar Listado de Ejercicios asociados a una Rutina: un

usuario, de tipo ‘Entrenador Personal’, debe disponer de la opción de consultar



el Listado de Ejercicios incluidos en una Rutina asociada a un cliente

determinado, además de la información detallada de cada ejercicio.

36) RF-36 – Ver Alimento: un usuario, de tipo ‘Entrenador Personal’, debe

disponer de una opción que le permita consultar la información detallada de un

alimento presente en el Listado de Alimentos incluidos en una Dieta asociada

a un cliente registrado en la plataforma.

37) RF-37 – Logout (Salir de la aplicación): el usuario debe disponer de un

mecanismo que le permita abandonar la sesión abierta en cualquier momento.

38) RF-38 – Consultar Listado de Peticiones Sin Atender: un usuario, de tipo

‘Entrenador Personal’ debe disponer de una opción que le permita consultar en

cualquier momento el Listado de Peticiones Sin Atender, es decir, de aquellas

peticiones enviadas por cualquier cliente registrado en la plataforma, y en las

que el usuario logueado es el destinatario, pero que aún no han sido atendidas.

39) RF-39 – Consultar Listado de Mensajes Sin Leer: un usuario, de tipo

‘Entrenador Personal’ debe disponer de una opción que le permita consultar en

cualquier momento el Listado de Mensajes Sin Leer, es decir, de aquellos

mensajes enviados por cualquier cliente registrado en la plataforma, y en las

que el usuario logueado es el destinatario, pero que aún no han sido leídos.

40) RF-40 – Ver Petición: un usuario, de tipo ‘Entrenador Personal’ debe disponer

de una opción que le permita consultar la información enviada por un cliente en

la contratación de un servicio determinado, para poder actuar en consecuencia

y atender dicha petición.

41) RF-41 – Asignar Dieta: un usuario, de tipo ‘Entrenador Personal’, debe

disponer de un mecanismo que tras consultar los datos de una petición enviada

por un cliente, la cual incluya la opción Dieta, le permita iniciar el proceso de

creación y asignación de Dieta a dicho usuario.

42) RF-42 - Asignar Rutina: un usuario, de tipo ‘Entrenador Personal’, debe

disponer de un mecanismo que tras consultar los datos de una petición enviada

por un cliente, la cual incluya la opción Rutina, le permita iniciar el proceso de

creación y asignación de Rutina a dicho usuario.

43) RF-43 – Asignar Alimentos a Dieta: un usuario, de tipo ‘Entrenador Personal’,

debe disponer de un mecanismo que le permita añadir alimentos a una Dieta

concreta.



44) RF-44 – Asignar Ejercicios a Rutina: un usuario, de tipo ‘Entrenador

Personal’, debe disponer de un mecanismo que le permita añadir ejercicios a

una Rutina concreta.

45) RF-45 – Consultar Listado de Mensajes Sin Leer: el usuario, de tipo

‘Entrenador Personal’, debe poder consultar en cualquier momento un listado

con todos aquellos mensajes no leídos en los que él es el destinatario.

46) RF-46 – Leer Mensaje No Leído: un usuario, de tipo ‘Entrenador Personal’,

podrá consultar los datos de un mensaje nuevo recibido, o no leído, teniendo

la opción de marcar ese mensaje como ‘leído’.

47) RF-47 – Modificar Datos Personales: un usuario, de tipo ‘Cliente’, debe

disponer de una opción que le permita modificar sus datos personales, pero

sólo aquellos que se puedan modificar.

48) RF-48 – Consultar Listado De Paquetes Ofertados en la Plataforma: un

usuario, de tipo ‘Cliente’, tendrá la posibilidad de consultar un listado con todos

los paquetes o servicios ofertados en la plataforma.

49) RF-49 – Enviar Petición: un usuario, de tipo ‘Cliente’, tendrá la posibilidad de

contratar uno de los paquetes ofertados en la plataforma, seleccionando para

ello el paquete que desea contratar y rellenando un formulario de contratación.

50) RF-50 – Consultar Listado de Peticiones Enviadas: un usuario, de tipo

‘Cliente’, debe disponer de una opción que le permita consultar el histórico

(listado) con todas sus peticiones enviadas, junto a los datos de cada una de

ellas.

51) RF-51 – Consultar Listado de Dietas Personales: un usuario, de tipo

‘Cliente’, podrá consultar el Listado de Dieta Personales asignadas.

52) RF-52 – Consultar Listado de Rutinas Personales: un usuario, de tipo

‘Cliente’, podrá consultar el Listado de Rutinas Personales asignadas.

53) RF-53 – Ver Dieta: un usuario, de tipo ‘Cliente’, debe tener la opción de

consultar los datos detallados para una dieta concreta que le haya sido

asignada.

54) RF-54 – Ver Rutina: un usuario, de tipo ‘Cliente’, debe tener la opción de

consultar los datos detallados para una rutina concreta que le haya sido

asignada.



55) RF-55 – Ver Alimento: un usuario, de tipo ‘Cliente’, podrá consultar los datos

detallados, relacionados con el valor nutricional, de cualquier alimento que

aparezca incluido en cualquiera de las dietas que tiene asignadas.

56) RF-56 – Consultar Listado de Mensajes: un usuario, de tipo ‘Cliente’, podrá

consultar en cualquier momento un listado con todos los mensajes recibidos o

enviados, en los que dicho usuario interviene.

57) RF-57 – Añadir Nuevo Mensaje: un usuario, de tipo ‘Cliente’, tendrá disponible

la opción de escribir un nuevo mensaje sólo a los usuarios de tipo ‘Entrenador

Personal’, registrados en la plataforma.

58) RF-58 – Eliminar Listado de Mensajes: un usuario, de tipo ‘Cliente’, debe

tener la posibilidad de eliminar todo su listado de mensajes asociados, tanto

enviados como recibidos.

59) RF-59 – Eliminar Mensaje Enviado: un usuario, de tipo ‘Cliente’, tendrá la

posibilidad de eliminar cualquier mensaje que haya enviado a través de la

plataforma.

60) RF-60 – Leer Mensaje: un usuario, de tipo ‘Cliente’, tendrá la posibilidad de

consultar cualquier mensaje recibido para marcarlo como ‘leído’.

61) RF-61 – Eliminar Cuenta de Usuario: un usuario, de tipo ‘Cliente’, podrá

eliminar en cualquier momento su cuenta de usuario, con lo llevará consigo la

eliminación de todos sus datos.

2.3.2. Requerimientos No Funcionales

Como he comentado más arriba, los requerimientos (o requisitos) no funcionales

[29] son aquellos externos al funcionamiento del sistema. Los requerimientos no

funcionales de un sistema podemos dividirlos en tres grupos: requisitos de calidad,

requerimientos software de la aplicación y requerimientos hardware. Mientras que los

primeros vamos a detellarlos a continuación, los otros no se han tenido demasiado en

cuenta en este punto, por no aportar demasiado valor.



Requisitos de calidad

Los requisitos de calidad, como su propio nombre indica, especifican criterios

que nos ayudan a juzgar la calidad del sistema de desarrollo y de los servicios que

este ofrece. Veamos a que hacemos referencia exactamente:

- Disponibilidad: periodo de tiempo durante el cuál estará operativo y disponible

para ser utilizado.

- Eficiencia: grado en el que los recursos disponibles son aprovechados.

- Flexibilidad: facilidad del sistema para incorporar nuevas funcionalidades.

- Integridad: medida en que el sistema es inmune a situaciones anómalas, como:

accesos no autorizados, violación de datos, pérdida de datosetc.

- Interoperabilidad: disposición del sistema para interactuar con otras

aplicaciones.

- Confiabilidad: probabilidad de que el sistema funcione correctamente durante

largos periodos de tiempo.

- Robustez: grado en que el sistema resiste a pruebas de funcionamiento para

seguir funcionando correctamente.

- Usabilidad: facilidad con la que un usuario puede utilizar el sistema, o

interpretar las salidas del mismo.

- Mantenibilidad: Grado en que los fallos del sistema pueden ser corregidos.

- Portabilidad: capacidad del sistema para ser ejecutado en diferentes sistema,

o para su adaptación para ello.

- Reusabilidad: facilidad para utilizar ciertos componentes del sistema en otros.

- Testabilidad: grado de éxito para realizar pruebas o tests en el sistema y

detectar situaciones anómalas.

Requerimientos software de la aplicación

- Ejecución del sistema en cualquier sistema operativo capaz de soportar la

máquina virtual Java.

- Uso de una base de datos relacional.



2.4. Planificación del proyecto

Una vez que hemos establecido el modelo de trabajo, es necesario identificar el

conjunto de tareas que nos permitirán concluir el trabajo a tiempo. Entre las

actividades que debemos tener en cuenta, se ecuentran: enumerar las tareas y

subtareas que conforman nuestro proyecto, asignar al personal responsable de cada

tarea, y estimar el esfuerzo o duración de cada una de estas tareas. Todo esto lo

veremos en un diagrama que reflejará la estructura de distribución del trabajo.

Pero, ¿por qué es necesario realizar una planificación del proyecto [30]? A

menudo, las tareas de la Ingeniería del Software [27] se desarrollan en paralelo, de

manera que el resultado final de una tarea puede verse realmente afectado por el

desarrollo de otra tarea. Este tipo de situaciones son imposible de entender sin un

calendario.

Como he comentado más arriba, los principales pasos que debemos seguir a la

hora de elaborar el calendario del proyecto son:

1) Identificar las tareas y subtareas que se han de cumplir para finalizar el

proyecto.

2) Asignar el esfuerzo; en personas-días de esfuerzo, y la duración de cada una

de estas tareas, que a su vez estarán divididas en subtareas.

3) Crear el Diagrama de Gantt, o red de actividad.

Pero para que la planificación del proyecto sea realmente eficiente, es necesario

que cumpla una serie de requisitos de calidad:

1) Todas las tareas identificadas deben aparecer en el diagrama.

2) El reparto tanto del esfuerzo como de los recursos ha de ser equitativo.

3) Debe quedar claro la relación que hay entre las diferentes tareas, de manera

que el lector al consultar el diagrama pueda saber cuando empieza y finaliza

cada una.

4) Se deben establecer hitos, que permitan marcar el avance del proyecto.

También es preciso señalar que el calendario avanza con el tiempo, es decir,

durante la primera fase del mismo, se establecerán grandes objetivos que deben



cumplirse, y con el trascurso del mismo, estos grandes bloques se irán detallando

conforme se vaya teniendo un conocimiento más exhaustivo del sistema.

Ya conocemos toda la teoría relacionada con la planificación de proyectos, pero

es hora de ponerla en práctica, por eso vamos a definir el listado de tareas y subtareas

que estructuran nuestro plan de trabajo

2.4.1. Estructura del plan de trabajo

Ilustración 16 - Estructura del plan de trabajo

En la ilustración podemos observar como el plan de trabajo se divide en cinco

grandes tareas. Estas a su vez están también divididas en diferentes niveles o

subtareas, siendo la jerarquía resultante la siguiente:



1. Búsqueda y Revisión Bibliográfica.

2. Análisis y Búsqueda de Información sobre la temática del Proyecto

2.1. Estudio y Búsqueda de Información de conceptos relacionados con el

Proyecto.

2.2. Estudio de las Plataformas y Herramientas para el Asesoramiento Deportivo

Online.

2.3. Estudio de las Metodologías y Tecnologías de Desarrollo Web.

2.4. Análisis de Requerimientos.

HITO 1: Fase de Análisis……………………………………………………………..

3. Desarrollo del prototipo de la Aplicación Web.

3.1. Diseño del prototipo de la Aplicación Web.

3.1.1. Diseño de la Interfaz del prototipo.

3.1.2. Diseño de la arquitectura del prototipo.

3.1.3. Diseño de los mecanismos de seguridad del prototipo.

HITO 2: Diseño del prototipo de la Aplicación Web……………………………..

3.2. Implementación del prototipo de la Aplicación Web.

3.2.1. Implementación de la Interfaz del prototipo.

3.2.2. Implementación de la arquitectura del prototipo.

3.2.3. Implementación de los mecanismos de seguridad del prototipo.

HITO 3: Implementación del prototipo de la Aplicación Web………………….

4. Evaluación del prototipo.

4.1. Diseño de Casos de prueba.

4.2. Test de Casos de prueba.

HITO 4: Evaluación del prototipo de la Aplicación Web………………………..

5. Elaboración de la documentación.

5.1. Redacción de Anexos.

5.2. Completar la Memoria.

HITO 5: Elaboración de la Documentación………………………………………



El siguiente paso será asignar el esfuerzo; medido en personas-día, a cada una

de las tareas y subtareas que acabamos de listar. Toda esta información podemos

verla reflejada en la tabla que se muestra en la siguiente página.

2.4.2. Estimación de las tareas

TAREA DURACIÓN

(en días) PERSONAL

ENCARGADO

Búsqueda y Revisión Bibliográfica 10 Analista

Análisis y Búsqueda de Información sobre la temática del Proyecto

Estudio y Búsqueda de Información de conceptos relacionados con el Proyecto 3 Analista

Estudio de las Plataformas y Herramientas para el Asesoramiento Deportivo Online 2 Analista

Estudio de las Metodologías y Tecnologías de Desarrollo Web 5 Analista

Análisis de Requerimientos

5 Analista/

Programador

Desarrollo del prototipo de la Aplicación Web

Diseño del prototipo de la Aplicación Web

Diseño de la Interfaz del prototipo 10 Analista

Diseño de la arquitectura del prototipo 15 Analista

Diseño de los mecanismos de seguridad del prototipo 5 Analista

Implementación del prototipo de la Aplicación Web

Implementación de la Interfaz del prototipo 20 Programador

Implementación de la arquitectura del prototipo 40 Programador

Implementación de los mecanismos de seguridad del prototipo 10 Programador

Evaluación del prototipo

Diseño de Casos de prueba 5 Analista

Test de Casos de prueba 10 Programador

Elaboración de la documentación

Redacción de Anexos 10 Analista

Completar la Memoria 42 Analista

Tabla 1 - Estimación del esfuerzo

Para finalizar con la Planificación del Proyecto, sólo nos queda reflejar la

planificación de las tareas a través de un Diagrama de Gantt. Este diagrama es una

herramienta fácil y cómoda de visualizar las acciones a realizar. Además, nos permite

realizar el seguimiento y control del progreso de cada una de las etapas o hitos del

proyecto, visualizando la duración de cada tarea según la longitud de cada franja

horizontal.



2.4.3. Diagrama de Gantt

Ilustración 17 - Diagrama de Gantt



La siguiente tabla muestra las fechas de comienzo y fin de cada tarea, así como

la duración (en días) de cada una de ellas. Respecto del resto de datos que podemos

consultar en la tabla, destacar la información sobre tareas predecesoras, que indica

que para que una tarea empiece, su predecesora debe haber terminado.

Nombre de tarea Duración Comienzo Fin Predecesoras

HITO 1: FASE DE ANÁLISIS

Búsqueda y Revisión Bibliográfica 10 días vie 28/11/14 jue 11/12/14 Análisis y Búsqueda de Información sobre la temática del Proyecto

Estudio y Búsqueda de Información de conceptos relacionados con el Proyecto

3 días vie 12/12/14 mar 16/12/14 2

Estudio de las Plataformas y Herramientas para el Asesoramiento Deportivo Online

2 días vie 12/12/14 lun 15/12/14 2

Estudio de las Metodologías y Tecnologías de Desarrollo Web

5 días vie 12/12/14 jue 18/12/14 2

Análisis de Requerimientos 5 días vie 12/12/14 jue 18/12/14 2 HITO 2: DSEÑO DEL PROTOTIPO DE LA APLICACIÓN WEB

Desarrollo del prototipo de la Aplicación Web

Diseño del prototipo de la Aplicación Web

Diseño de la Interfaz del prototipo 10 días vie 19/12/14 jue 01/01/15 7

Diseño de la arquitectura del prototipo 15 días vie 02/01/15 jue 22/01/15 11

Diseño de los mecanismos de seguridad del prototipo 5 días vie 23/01/15 jue 29/01/15 12 HITO 3: IMPLEMENTACIÓN DEL PROTOTIPO DE LA APLICACIÓN WEB

Implementación del prototipo de la Aplicación Web

Implementación de la Interfaz del prototipo 20 días vie 02/01/15 jue 29/01/15 11

Implementación de la arquitectura del prototipo 40 días vie 23/01/15 jue 19/03/15 12 Implementación de los mecanismos de seguridad del prototipo

10 días vie 30/01/15 jue 12/02/15 13

HITO 4: EVALUACIÓN DEL PROTOTIPO DE LA APLICACIÓN WEB

Evaluación del prototipo

Diseño de Casos de prueba 5 días vie 20/03/15 jue 26/03/15 17

Test de Casos de prueba 10 días vie 27/03/15 jue 09/04/15 21 HITO 5: ELABORACIÓN DE LA DOCUMENTACIÓN

Elaboración de la documentación

Redacción de Anexos 10 días vie 10/04/15 jue 23/04/15 22

Completar la Memoria 42 días vie 24/04/15 lun 22/06/15 25 Tabla 2 - Programación de tareas

A modo de resumen, cabe destacar lo siguiente:

- Fecha de comienzo del proyecto: Viernes 28 de Noviembre de 2014.

- Duración del proyecto: 145 días laborales.

- Fecha de fin del proyecto: Lunes 22 de Junio de 2015.



2.5. Estudio de viabilidad

Como con cualquier otro tipo de proyecto, es necesario realizar un Análisis sobre

los Costes de Desarrollo y Explotación [31], para garantizar a la organización o

empresa que nos lo encarga que la inversión que va a realizar resulta realmente

rentable. Es decir, cuando ponemos en marcha un proyecto, es necesario realizar una

estimación de los costes de desarrollo [32], que nos permita calcular tanto los gastos

como los ingresos de su realización, de manera que si los ingresos superan los gastos

de manera satisfactoria, el proyecto se llevará a cabo.

Los factores que se han de tener en cuenta durante la realización de este análisis

son los siguientes:

- Coste ponderado de los Gastos de Material: herramientas utilizadas,

licencias de software, equipos utilizados, conexión a internet, alquileres, etc

- Nóminas o retribuciones al personal.

- Porcentaje de beneficio.

- Costes o gastos adicionales: margen de contingencia (posibles

imprevistos durante el desarrollo del proyecto), gastos en concepto de

Seguridad Social, rentas, impuestos por autónomos, viajes, etc.

Las tablas que se podrán consultar en la siguiente página, muestran el desglose

que se ha realizado para cada uno de estos apartados.

Ilustración 18 - Presupuesto



HERRAMIENTAS Y LICENCIAS SOFTWARE UTILIZADAS PRECIO UNIDADES

DURACIÓN DEL PROYECTO VIDA ESTIMADA PRECIO PONDERADO

Paquete Office 365 Empresa Premium 2013 11,50€ usuario/mes 2 usuarios 7 MESES 161 €

Paquete Microsoft Office Visio 2013 14,20€ usuario/mes 2 usuarios 7 MESES 198,80 €

Paquete Microsoft Office Project 2013 22,90€ usuario/mes 2 usuarios 7 MESES 320,60 €

BitDefender Antivirus Plus Hasta 3 PCs 39,90€ 1 unidad 7 MESES 23,28 €

Microsoft Windows 7 Proffesional 64bits OEM SP1 145€/licencia 2 usuarios 7 MESES 5 años 33,84 €

PDFCreator 2.1 Free - 7 MESES

MockFlow Wireframe PRO Free - 7 MESES

NetBeans IDE 8.0.2 Free - 7 MESES

Visual Paradigm 11.2 119,12€/licencia 2 usuarios 7 MESES 5 años 27,79 €

Java SE Development Kit 8 - windows x64 Free - 7 MESES

GlassFish Server Open Source Edition 4.1 Free - 7 MESES

Framework Bootstrap v3.3.4 Free - 7 MESES

Navegador Google Chrome v8.25 Free - 7 MESES Tabla 3 - Herramientas y licencias software utilizadas

* NOTA: los campos marcados como FREE significan que la licencia de dicha herramienta no supone coste alguno para el usuario.

EQUIPOS INFORMÁTICOS UTILIZADOS PRECIO UNIDADES VIDA ESTIMADA PRECIO PONDERADO

HP Pavilion DV6-6191ss 649,00 € 2 unidades 5 años 151,43 €

Slot Memoria RAM DDR3 4Gb 62,00 € 2 unidades 5 años 14,47 € Tabla 4 – Equipos Informáticos utilizados

CONEXIÓN A INTERNET PRECIO DURACIÓN DEL PROYECTO PRECIO PONDERADO

Conexión ADSL Fibra ONO 30Mb 15,9€/mes 7 MESES 111,30 € Tabla 5 - Conexión ADSL+



NÓMINAS SALARIO/

MES HORAS/MES

SALARIO/HORA

DÍAS DE TRABAJO

NÚM. HORAS/

DÍA

NÚM. HORAS

TOTALES TOTAL

ESTIMADO

Analista 1.497,48 € 160,00 9,36 € 115 5 575 5.382 € Programador 1.328,78 € 160,00 8,30 € 85 5 425 3.527,50 €

Tabla 6 - Nóminas del personal

*NOTA: el salario/mes del personal ha sido extraído del BOE a fecha de Lunes,

12 de Enero de 2015. [33]

Si agrupamos los costes estimados totales para cada uno de los factores vistos

anteriormente, obtenemos la siguiente tabla resumen:

GASTO PRECIO

Gasto en Material Total 1.042,51 €

Gasto en Nóminas del Personal Total 8.909,50 €

Porcentaje de Beneficio - 15% 1.492,80 €

Gastos Adicionales – (Margen de maniobra) - 8% 796,16 €

COSTE TOTAL DEL PROYECTO 12.240,97 € Tabla 7 - Coste Final del Proyecto

Como podemos observar, el Proyecto supondría un desembolso final por parte

de la empresa que lo contratase de 12.240,97 €, estando todos los gastos posibles

incluídos en dicha cantidad.



2.6. Modelo de dominio

Nos referimos con Modelo de Dominio [34] a la representación visual de las

clases conceptuales o de objetos reales en un dominio de interés. Este modelo incluye

los diagramas de clases, sin definir las operaciones de estas clases.

El Modelo de Dominio funciona como diccionario visual, dado que proporciona al

lector una perspectiva conceptual del sistema, incluyendo los objetos del dominio o

clases conceptuales, las asociaciones entre estas clases, y los atributos que dan

forma a las mismas. Toda esta información puede ser descrita de forma textual. El

modelo de dominio debe omitir las clases software.

A grandes rasgos, los tres pasos que debemos seguir para construir el Modelo

de Dominio, son:

- Identificar las clases conceptuales del sistema.

- Representar estas clases como clases de un Diagrama de Clases UML.

- Agregar las relaciones entre estas clases, y los atrubutos que dan forma

a las clases.

Los elementos que componen el Modelo de Dominio son los siguientes:

Objetos

Los objetos del Modelo de Dominio han de tener una identidad única que los

distinga claramente del resto.

Clases

Las clases representan grupos de objetos que comparten las mismas

propiedades, comportamientos y relaciones. Podemos decir que un objeto sería la

instancia de una clase, viéndolo con un ejemplo, si tenemos la clase ‘Persona’,

‘Persona 1’ con todos sus datos sería un objeto de dicha clase, es decir, una instancia

de la misma.



Hablamos de clases conceptuales debido al nivel de abstracción que se busca

en este modelo.

Asociaciones

Un asociación representa la conexión existente entre objetos de un Modelo de

Dominio, normalmente relacionados de forma física o conceptual. Para mostrar las

asociaciones existentes entre dos objetos utilizamos una línea contínua, acompañada

de un valor numérico denominado multiplicidad, que indica el número de ocurrencias

posibles de la relación. Existen asociaciones de una clase consigo misma, es decir,

una clase puede estar relacionada con ella misma.

Atributos

Los atributos son valores que identifican información que pertenece a un objeto.

Cada atributo suele ir acompañado del tipo de dato y de otra información

complementaria.

Una vez definido lo que es el Modelo de Dominio, y todos los elementos que lo

forman, es hora de contruir el diagrama asociado al modelo de dominio de mi

aplicación. Este lo mostraré en la siguiente página, para verlo ampliado con mayor

calidad.



Ilustración 19 - Diagrama del Modelo de Dominio



El siguiente paso que vamos a dar es analizar brevemente el diagrama anterior.

Como se puede observar, existen 9 clases, estableciéndose 8 relaciones entre

estas clases. ¿Por qué se ha decidido establecer estas relaciones y no otras?

- Relación Cliente-Mensaje: establecemos una relación entre las clases

Cliente y Mensaje, pues un cliente escribe uno o muchos mensajes, mientras

que un mensaje sólo es esccrito por un cliente (dos, si consideramos que el

mensaje pertenece a ambos: origen y destino).

- Relación Cliente-Petición: esta relación muestra como un cliente envía

una o muchas peticiones (solicitud para contratar un determinado servicio),

mientras que una petición sólo pertenece a un cliente.

- Relación Petición-Paquete: una petición sólo tiene asociado un

paquete, es decir, cuando contratamos un servicio, contratamos sólo uno,

mientras que un determinado paquete puede estar asociado a varias

peticiones, o lo que es lo mismo, varias peticiones pueden tener asociado a un

mismo paquete puesto que varios clientes hayan contratado el mismo servicio.

- Relación Paquete-Propósito: un paquete sólo tiene (incluye) un

propósito, puesto que el objetivo de ese paquete sólo puede ser uno. Sin

embargo, varios paquetes pueden tener el mismo propósito.

- Relaciones Petición-Rutina y Petición-Dieta: estas relaciones se han

establecido de 1 a 1, pues una petición determinada, solamente incluye una

rutina en concreto (ídem para dieta), y a la vez, esa rutina (o dieta) sólo

pertenece a un petición. Una petición (o contratación de servicio) sólo puede

tener asociado una rutina (o una dieta) determinada.

- Relaciones Rutina-Ejercicio y Dieta-Alimento: decimos que la relación

rutina-ejercicio (o dieta-alimento) es de muchos a muchos, pues una rutina

determinada, está formada por varios ejercicios (una dieta contiene muchos

alimentos). De igual forma, un ejercicio determinado puede pertenecer a

muchas rutinas (un alimento concreto, puede estar en muchas dietas).



2.7. Modelo de Casos de Uso

El modelo de casos de uso es el procedimiento que utilizamos dentro de la

Ingeniería del Software para determinar el comportamiento de un sistema de

desarrollo [35]. En este modelo se especifican tanto las funciones que debe cumplir el

sistema, como los actores que componen el entorno del sistema y relaciones entre

estos. Como consecuencia de estas interacciones obtenemos los diagramas de caso

de uso, cuyo principal objetivo es la de ilustrar los requerimientos o funcionalidades

del sistema, mostrando para ello las reacciones que se producen en el ámbito del

sistema, o dentro de él mismo, ante diferentes situaciones o eventos.

Cada caso de uso representa una capacidad del sistema, es decir, una

funcionalidad del mismo. Para representarlo utilizaremos un óvalo, que en su interior

llevará un nombre identificativo del caso de uso, que ha de cumplir una serie de

características:

- Debe describir de forma textual una funcionalidad del sistema.

- Debe ser claro.

Es preciso señalar que un caso de uso, en sí mismo, es un caso de uso [36].

Los sistemas dentro de un diagrama de casos de uso, lo representaremos como

un rectángulo vertical.

- AsesoríaDeportivaWeb: simbolizará nuestro sistema.

Ilustración 20 - Sistema: AsesoríaDeportivaWeb



Para conocer con un poco más de detalle en qué consiste el modelo de casos

de uso, vamos a definir los diferentes componentes de dicho modelo.

2.7.1. Actores

Un actor representa cualquier individuo que sin pertenecer al sistema, interactúa

con este. Pero cabe la pena destacar que no sólo entidades humanas pueden adoptar

el rol de actor, otros sistemas externos al propio sistema, o incluso el tiempo, son

considerados también actores del sistema. Es por este hecho, que resulta

imprescindible tener claro cuáles serán los actores de nuestro sistema.

Dentro del diagrama de casos de uso, los actores que simbolizan a una entidad

humana normalmente se representan con un monigote.

Veamos cuáles son los actores de nuestro sistema:

- ‘EntrenadorPersonal’: como su propio nombre indica, es el actor que hace

referencia a los entrenadores personales de la plataforma, teniendo los

privilegios de un administrador (‘ROLE_ADMIN’).

Ilustración 21 - Actor: EntrenadorPersonal

- ‘Cliente’: actor que simboliza a los clientes de la plataforma. (‘ROLE_USER’).

Ilustración 22 - Actor: Cliente



2.7.2. Relaciones

Las relaciones [37] dentro del modelo de casos de uso determinan las

interacciones entre los actores, el sistema, y los propios casos de uso. A menudo se

denominan ‘relaciones de comunicación’ pues representan la forma de comunicarse

entre el actor y un caso de uso.

Las relaciones se simbolizan con una línea que conecta al actor con su caso de

uso, y que dependiendo del tipo de relación, reproduciremos con un determinado

formato. La dirección en la que representaremos esta línea vendrá determinado

además por quién es el que inicia la comunicación.

Los principales tipos de relación que encontramos dentro del modelo de casos

de uso son:

Communicates: una relación de tipo ‘communicates’ muestra la participación de

un actor en un determinado caso de uso. Todas las líneas que salen de un actor dentro

de un diagrama de casos de uso, son de este tipo.

Include: una relación de tipo ‘include’ la utilizamos cuando un caso de uso utiliza

la funcionalidad de otro caso de uso, es decir, ambos casos de uso comparten dicha

funcionalidad, pero uno de ellos hace algo más.

Extends: cuando dentro de un caso de uso tenemos alguna funcionalidad que

sólo tiene lugar en algunas ocasiones, hablamos de relación de tipo ‘extends’. En una

relación de este tipo, el actor tiene la capacidad de decidir si realizar o no el caso de

uso que se extiende. Las relaciones tipo ‘extends’ se representan con una flecha de

líneas discontinuas que apunta desde el caso de uso extendido, hacia el caso de uso

base.

2.7.3. Diagramas de Casos de Uso

Como he comentado anteriormente, la principal función de los diagramas de

caso de uso es la de mostrar al lector las interacciones que se producen dentro del

sistema [38] [39], entre los diferentes actores y los casos de uso en los que participan.



Puesto que la extensión de este proyecto es un poco amplia, no considero que

sea necesario incluir en esta memoria todos los diagramas de caso de uso existentes.

Sin embargo, sí que voy a comentar los que a mi parecer son más relevantes. El resto

de diagramas de casos de uso están a disposición del lector en el contenido del CD.

En primer lugar, vamos a ver el diagrama principal de casos de uso, donde se

describen las principales funcionalidades que pueden realizar los actores del sistema:

Ilustración 23 - Diagrama de Casos de Uso: Principal

Como podemos apreciar en la imagen anterior, tenemos dos actores; más

nuestro sistema, junto con las funcionalidades en las que participan. A modo de

ejemplo, podemos observar que existen dos casos de uso en los que ambos actores

participa, estos son: ‘Login’ y ‘Logout’.



Veamos con detenimiento el caso de uso: ‘Login’.

Ilustración 24 - Diagrama de Casos de Uso: Login

La imagen anterior muestra la participación de los dos actores de nuestro

sistema, en el caso de uso ‘Login’. Es caso de uso tiene una relación de inclusión del

caso de uso ‘Registrarse’ pues para poder loguarse en la plataforma es necesario

estar registrado en la misma, aunque el proceso de registro de ambos actores sea

diferente. A su vez, el caso de uso ‘Registrarse’ incluye el caso de uso ‘Validar Datos’

pues para poder dar de alta un nuevo usuario el sistema debe verificar que los datos

de usuario introducidos son correctos.

La siguiente ilustración que vamos a analizar es la referente al caso de uso:

‘Gestionar Usuarios’ de la parte del administrador, por lo que, como veremos, el actor

principal de dicho caso de uso será el ‘EntrenadorPersonal’. En ella, podemos

observar todas las funcionalidades que puede realizar un adminsitrador de la

plataforma, desde las que son obligatorias para la propia realización del caso de uso

‘Gestión de Usuarios’, como son: ‘Mostrar Listado de Usuarios’ o ‘Añadir Nuevo

Usuario’, como las que son opcionales: ‘Eliminar Usuario’, ‘Visualizar Datos de

Usuario’, ‘Consultar Mensajes Usuario’, ‘Escribir Mensaje Usuario’, ‘Consultar

Peticiones Cliente’, ‘Consultar Dietas Cliente’ o ‘Consultar Rutinas Cliente’.

Todas estas funcionalidades se encuentran detalladas en dicha ilustración.



Ilustración 25 - Diagrama de Casos de Uso: Gestión de Usuarios



El siguiente diagrama que vamos a analizar es el que hace referencia al caso de

uso ‘Gestionar Paquetes’ de la parte del administrador, siendo el principal actor

implicado en este caso de uso ‘EntrenadorPersonal’.

Ilustración 26 - Diagrama de Casos de Uso: Gestionar Paquetes

Analizando la imagen, nos damos cuenta que el caso de uso ‘Gestionar

Paquetes’ incluye tres casos de uso: ‘Consultar Listado de Paquetes’, ‘Añadir Nuevo

Paquete’ y ‘Gestionar Propósitos’. Esto es así, pues se ha considerado que para poder

gestionar paquetes es necesario realizar cada uno de ellos.

Los casos de uso: ‘Modificar Paquete’ y ‘Eliminar Paquete’ están relacionados

mediante una relación de extensión pues no se considera obligatoria su realización

para la gestión de paquetes.

Como vemos, los casos de uso ‘Añadir Nuevo Paquete’ y ‘Modificar Paquete’

hacen uso del caso de uso ‘Validar Datos’, es decir, para la realización de estos casos

de uso es necesario que el sistema valide los datos enviados en sendos formularios.

Para acabar con los diagramas de casos de uso relacionados con el

administrador, vamos a comentar el diagrama de casos de uso relacionado con la

gestión de ‘Peticiones Sin Atender’.



Ilustración 27 - Diagrama de Casos de Uso: Consultar Peticiones Sin Atender

Como en los anteriores diagramas, el actor que interviene en los casos de uso

reflejados en la ilustracion, es el ‘EntrenadorPersnal’. El caso de uso es el que se

realiza cuando un entrenador recibe una petición por parte del cliente, y consulta el

listado de Peticiones Sin Atender, para Consultar Peticiones Sin Atender,

necesariamente tiene que ‘Consultar Listado de Peticiones’ y por ende, tiene que

‘Consultar Petición’ para poder visualizar los datos de dicha petición. Una vez

consultados estos datos, y dependiendo de lo que haya contratado el cliente, podrá

‘Asignar Dieta’ o ‘Asignar Rutina’, lo que respectivamente incluye en su proceso:

‘Asignar Alimentos Dieta’ y ‘Asignar Ejercicios Rutina’. Los procesos de creación y

asignación de dieta y rutina, y de asignación de alimentos a dieta y ejercicios a rutina,

incluyen a su vez, ‘Validar Datos’, es decir, los datos con los que se trabajan han de

ser correctos.



Ahora, vamos a analizar algunos de los diagramas de casos de uso más

representativos de la parte del cliente.

En primer lugar, pasamos a ver el diagrama para el caso de uso ‘Contratar

Paquete’, que es la principal funcionalidad del cliente.

Ilustración 28 - Diagrama de Casos de Uso: Contratar Paquete

Como podemos apreciar, el caso de uso ‘Contratar Paquete’, incluye la

funcionalidad, que da lugar a un nuevo caso de uso, ‘Consultar Listado de Paquetes’,

la que permite al cliente consultar todos los paquetes ofertados en la plataforma. Se

ha considerado que el caso de uso ‘Seleccionar Paquete’ esté relacionado mediante

una relación de extensión puesto que un cliente puede querer consultar el listado de

paquetes, sin necesidad de seleccionarlo para posteriormente hacer la compra de

dicho servicio. En el caso de que lo seleccionase, esto incluye ‘Enviar Petición’

después de ‘Rellenar formulario, que a su vez incluye la validación de datos.



El siguiente diagrama que analizaremos será ‘Gestionar Mensajes’ en el que se

reflejan todas las funcionalidades que el cliente puede realizar, relacionados con la

entidad Mensaje.

Ilustración 29 - Diagrama de Casos de Uso: Gestionar Mensajes

Como podemos ver, y como en casos anteriores relacionados con la gestión de

entidades, el primer caso de uso que necesariamente tenemos que realizar para llevar

a cabo la gestión es: ‘Consultar Listado de Mensajes’, donde aparecerá, a disposición

del cliente, un listado con todos los mensajes en los que interviene, como emisor o

receptor del mensaje.

El caso de uso ‘Escribir Nuevo Mensaje’ que permite al cliente escribir un nuevo

mensaje a cualquier entrenador de la plataforma, está relacionado con el caso de uso

padre ‘Gestionar Mensajes’ a través de una relación de extensión, puesto que es una

función opcional. Además, este caso de uso incluye una relación de inclusión con el

caso de uso ‘Validar Datos’, pues para escribir un nuevo mensaje, es necesario que

los datos sean correctos.

Como vemos, los otros tres casos de uso relacionados con ‘Gestionar Mensajes’,

están todos relacionados mediante extensión debido a su naturaleza opcional. ‘Leer

Mensaje’ permite al cliente cambiar el estado de un mensaje recibido como leído o no

léido. ‘Eliminar Listado de Mensajes’ refleja la funcionalidad que permite al cliente

eliminar toda su bandeja de mensajes. ‘Eliminar Mensaje’ permite eliminar un mensaje

enviado.



2.7.4. Especificación de Casos de Uso

La especificación de los casos de uso [40] nos debe proporcionar una

descripción detallada de cada una de las partes, o funcionalidades del sistema,

anteriormente descritas. Se trata de explicar de manera completa, cómo interactúa

cada actor con el sistema. Este será un apartado que de mucho más valor para el

lector, pues le permitirá conocer con detalle los posibles escenarios a los que se

enfrentan los actores del sistema, y la manera en que este reacciona.

Por lo general, se suele considerar que una especificación correcta de casos de

uso debe responder a las siquientes cuestiones:

- ¿Cuál es el actor que interviene en cada momento?

- ¿Qué funcionalidad concreta realizada ese actor en dicho momento?

- ¿De qué manera interviene el actor en ese proceso?

- ¿Cuál es el objetivo del actor para llevar a cabo las acciones que realiza? ¿Qué

información desea extraer del sistema?

- ¿Cómo reacciona el sistema ante comportamientos inesperados del actor?

También es necesario tomar en consideración una serie de aspectos que nos

ayudarán a realizar una correcta especificación de casos de uso:

- Interacciones: consiste en describir la intervención de los actores primarios y

secundarios en el caso de uso reflejado, desde que da comienzo, hasta su

finalización.

- Eventos: es necesario reflejar cada uno de los acontecimientos que tienen

lugar durante la realización del caso de uso.

- Nivel de detalle: el nivel de detalle va directamente relacionado con la

precisión en la estimaciones de nuestro plan de trabajo. Es decir, cuanto mayor

sea el grado de detalle con el que conocemos una funcionalidad del sistema,

mejor comprensión del sistema tendremos.

- Escenarios: es necesario no sólo contemplar todos los escenarios posibles,

sino también las diferentes formas en las que pueden ser realizados.

- Claridad y enfoque del usuario: lejos de utilizar lenguaje excesivamente

técnico, y para mayor comprensión del lector, es preciso redactar la



especificación de casos de uso con un lenguaje claro y entendible por parte del

usuario, lo que le permitirá hacer un uso mucho más adecuado del sistema.

Antes de continuar con la descripción de los casos de uso más representativos

de la plataforma, vamos a ver con detenimiento la platilla que se ha utilizado para

realizar la especificación de los casos de uso, describiendo una por una las partes de

la misma, junto con las indicaciones básicas que se han seguido para su redacción.

Caso de uso:

Actor primario:

Sistema:

Participantes:

Precondiciones:

Descripción:

Operaciones Básicas:

Alternativas:

Tabla 8 - Plantilla Especificación de Casos de Uso

- Caso de Uso: nombre del caso de uso. Debe ser un nombre lo más

identificativo y corto posible del CU, que describa de forma clara y concisa lo

que hace. Normalmente suelen empezar con un verbo o un tiempo verbal.

- Actor primario: listado de actores primarios que intervienen en dicho caso de

uso.

- Sistema: sistema en el que tiene lugar el caso de uso.



- Participantes: listado tanto de actores primarios como secundarios que

intervienen en el caso de uso, como del sistema en el que tienen lugar.

- Precondiciones: hacen referencia a los condiciones que debe cumplir el

sistema antes de iniciar el caso de uso

- Descripción: debe resumir sin entrar en mucho detalle el objetivo del caso de

uso.

- Operaciones Básicas: da una descripción de los pasos que se han de seguir

en el flujo normal del proceso de ejecución del CU.

- Alternativas: determinan los pasos alternativos que se deben seguir en los

diferentes escenarios relacionados con un caso de uso.

Una vez que hemos visto la plantilla que se ha utilizado para realizar la

especificación de casos de uso, y las diferentes partes que la componen, pasamos a

analizar algunas de las especificaciones más representativas realizadas durante la

realización de este proyecto. En esta memoria no se van a incluir todas las

especificaciones existentes para los casos de uso de este proyecto, pues su extensión

es larga y en muchos casos puede resultar repetitivo, pues el proceso para llevar a

cabo algunas de las funcionalidades del sistema se repiten para los diferentes CRUD

del sistema.



Especificación del Caso de Uso: Login

Caso de uso: Login

Actor primario: > EntrenadorPersonal

> Cliente

Sistema: Asesoría Deportiva Web

Participantes: EntrenadorPersonal - Cliente - Sistema

Precondiciones: El usuario (EntrenadorPersonal o Cliente) ha de estar registrado en la plataforma

Descripción:

Un usuario accede a la página principal de la plataforma para identificarse y poder acceder al contenido de la misma


1 El usuario accede al enlace web de la plataforma

2 Introduce sus datos de usuario: identificador y contraseña

3 ¿Los datos son correctos?

4 El sistema comprueba de qué tipo de usuario se trata y lo redirecciona a su página de inicio dependiendo del rol

5 El usuario accede al contenido de la plataforma

Alternativas:

3.1 Si los datos son incorrectos el sistema mostrará un mensaje de error y redirige al mismo formulario de identificación (Paso 2)

3.2 Si el usuario no está registrado, el sistema mostrará una pantalla de error y con la opción de volver al formulario de registro (Paso 2)

3.3 Si los datos son correctos, ir al Paso 4 Tabla 9 - Especificación de Casos de Uso: Login



Especificación del Caso de Uso: Consultar Listado de Usuarios

Caso de uso: Consultar Listado de Usuarios

Actor primario: EntrenadorPersonal


Participantes: EntrenadorPersonal - Sistema

Precondiciones: > El usuario debe estar identificado en la plataforma

> El usuario debe ser de tipo ‘Admin’

> Debe existir al menos un cliente en la BBDD

Descripción:

El sistema debe mostrar al EntrenadorPersonal un listado con todos los usuarios existentes en la BBDD






5 El usuario accede a ‘Gestión de Usuarios’

6 EL sistema mostrará el listado de usuarios registrados en la plataforma

Alternativas:

3.1 Si los datos son incorrectos el sistema mostrará un mensaje de error y volverá a pedirlos (Paso 2)

3.2 Si el usuario no está registrado, el sistema le informará que tiene que rellenar el formulario de registro (Paso)

3.3 Si los datos son correctos ir al Paso 4 Tabla 10 - Especificación de Casos de Uso: Consultar Listado de Usuarios



Especificación del Caso de Uso: Añadir Ejercicio

Caso de uso: Añadir Ejercicio


Sistema: Asesoría deportiva Web




Descripción:

El usuario de tipo ‘Admin’ accede a la plataforma y utiliza el servicio de ejercicios para añadir un nuevo Ejercicio a la BBDD






5 El usuario accede a ‘Gestionar Ejercicios’ >> ‘Añadir Ejercicio’

6 El sistema muestra el formulario para añadir un nuevo Ejercicio

7 El usuario rellena dicho formulario y envía los datos

8 El sistema recibe los datos - ¿Son los datos correctos?

Alternativas:



3.3 Si los datos son correctos ir al Paso 4

8.1 Si los datos son correctos el sistema añade el Ejercicio a la BBDD y redirige al usuario al listado de Ejercicios y Finaliza

8.2 Si los datos son incorrectos el sistema redirige al usuario al formulario (Paso 6) y mostrará un mensaje de error sobre cada campo erróneo

Tabla 11 - Especificación de Casos de Uso: Añadir Ejercicio



Especificación del Caso de Uso: Modificar Alimento

Caso de uso: Modificar Alimento

Actor primario: > EntrenadorPersonal




> El Alimento a modificar debe existir en la BBDD de usuarios

> Los campos a modificar han de ser modificables

Descripción:

El EntrenadorPersonal accede a la plataforma para modificar los datos un Alimento de la plataforma (sólo campos modificables)






5 El usuario accede a ‘Gestionar Alimentos’ >> y pulsa el enlace ‘Modificar’ asociado al Alimento que desea modificar

6 El sistema muestra el formulario con los campos modificables sobre dicho Alimento

7 El usuario modifica los campos que desea

8 El sistema recibe los nuevos datos del Alimento a modificar

Alternativas:

3.1 Si los datos son incorrectos el sistema mostrará un mensaje de error y volverá a pedirlos

4.1 Si el tipo de usuario es correcto ir al punto 5

4.2 Si el tipo de usuario es incorrecto ir al punto 2

8.1 Si los datos son correctos, el sistema actualizará la información del Alimento y redirige a la pantalla con el listado de Alimentos. Finaliza

8.2 Si los datos son incorrectos el sistema mostrará un mensaje de error sobre los campos erróneos y redirigirá al Paso 6

Tabla 12 - Especificación de Casos de Uso: Modificar Alimento



Especificación del Caso de Uso: Eliminar Petición

Caso de uso: Eliminar Petición






> Debe existir al menos una petición asociada al cliente

Descripción:

El usuario de tipo ‘Admin’ accede a la plataforma + Sección Peticiones, y elimina una petición concreta asociada a un usuario X






5 El usuario accede a ‘Gestión de Usuarios’ >> ‘Histórico Peticiones’

6 El sistema muestra el listado de peticiones asociadas al usuario X

7 El usuario pulsa el botón ‘Eliminar Petición’ sobre la petición que desea borrar

8 El sistema mostrará un mensaje de confirmación para comprobar si el usuario desea realmente eliminar la petición

Alternativas:




8.1 Si el usuario pulsa el botón de ‘Aceptar’ el sistema procesará la solicitud y eliminará la petición asociada al usuario y Finaliza

8.2 Si el usuario pulsa el botón ‘Cancelar’ el sistema redirige al usuario al listado de peticiones (Paso 6)

Tabla 13 - Especificación de Casos de Uso: Eliminar Petición



Especificación del Caso de Uso: Asignar Rutina

Caso de uso: Asignar Rutina






> El paquete seleccionado en la petición ha de incluir Rutina

Descripción:

El EntrenadorPersonal procesa una petición asignándole una Rutina






5 El EntrenadorPersonal accede a ‘Peticiones Pendientes’

6 El sistema muestra un listado con todos las peticiones sin atender con destinatario el EntrenadorPersonal logueado

7 El EntrenadorPersonal pulsa sobre el enlace de la petición de la lista que desea consultar

8 El sistema muestra los datos de dicha Petición

9 El EntrenadorPersonal pulsa sobre el botón ‘Asignar Rutina’

10 El sistema muestra el formulario para asignar los datos de la Rutina

11 El Entrenador Personal rellena el formulario y envía los datos


13 El sistema mostrará el formulario de ‘Añadir Ejercicios a la Rutina’

14 El EntrenadorPersonal rellena el formulario - ¿Son los datos correctos?

15 Repetir el proceso desde el Paso 13 hasta que el EntrenadorPersonal pulse el botón ‘Finalizar’

16 El sistema redirige a la pantalla de ‘Ver Petición’

17 El EntrenadorPersonal cambia el estado de la petición a ‘Atendida’

18 El sistema añade la Rutina a la BBDD + Actualiza el estado de la Petición + Redirige a la pantalla de ‘Peticiones Pendientes’

Alternativas:






12.1 Si los datos son correctos el sistema ir al Paso 13

12.2 Si los datos son incorrectos el sistema redirige al Paso 10, mostrando un mensaje de error sobre los campos erróneos

14.1 Si los datos son correctos el sistema ir al Paso 15

14.2 Si los datos son incorrectos el sistema redirige al Paso 13, mostrando un mensaje de error sobre los campos erróneos

15.1 Si el EntrenadorPersonal pulsa el botón ‘Finalizar’ ir al Paso 16 Tabla 14 - Especificación de Casos de Uso: Asignar Rutina

Especificación del Caso de Uso: Contratar Paquete

Caso de uso: Contratar Paquete

Actor primario: Cliente


Participantes: Cliente - Sistema


> El usuario debe ser de tipo ‘User’

> Debe existir al menos un paquete existente en la BBDD

Descripción:

El sistema mostrará al Cliente un listado con los Paquetes ofertados en la plataforma, junto con su información






5 El usuario accede a ‘Contratar Paquete’

6 El sistema muestra un listado con todos los Paquetes ofertados en la web. Finaliza

Tabla 15 - Especificación de Casos de Uso: Contratar Paquete



Especificación del Caso de Uso: Añadir Mensaje Cliente

Caso de uso: Añadir Mensaje Cliente

Actor primario: Cliente


Participantes: Cliente - Sistema


> El usuario debe ser de tipo ‘User’

Descripción:

El usuario de tipo ‘User’ accede a la plataforma y utiliza el servicio de mensajes para enviar un nuevo mensaje a alguno de los Entrenadores de la plataforma






5 El usuario accede a ‘Mensajes’ >> ‘Añadir Mensaje’ del entrenador al que desea escribir

6 El sistema muestra el formulario para añadir un nuevo mensaje

7 El usuario rellena dicho formulario y envía los datos


Alternativas:




8.1 Si los datos son correctos el sistema añade el mensaje a la BBDD y redirige al Cliente al listado de mensajes y Finaliza

8.2 Si los datos son incorrectos el sistema redirige al usuario al formulario (Paso 6) y mostrará un mensaje de error sobre cada campo erróneo

Tabla 16 - Especificación de Casos de Uso: Añadir Mensaje Cliente



3. DISEÑO

3.1. Diagrama Entidad-Relación

3.1.1. Introducción

Definimos el Modelo Entidad-Relación como una herramienta especial de

representación gráfica, que incorpora información relacionada con los datos de un

sistema, y la relación existente entre estos, para darnos una visión del mundo real.

El modelo de datos E-R, se basa en la percepción del mundo real a través de

una serie de objetos básicos, llamados entidades, y de relaciones entre estos

objetos. Así pues, vamos a definir los elementos que intervienen en el modelo E-R:

- Entidad: una entidad es una cosa u objeto del mundo real que se dstingue

claramente de otra, de acuerdo a sus características, y de la cuál almacenamos

información. Por ejemplo, una persona puede ser una entidad, y una mesa, otra

entidad diferente.

Una entidad adquiere el significado o representación de un objeto, que tiene

alguna función determinada dentro de nuestro sistema.

Gráficamente, representaremos las entidades con un rectángulo, que encierra el

nombre de la entidad en su interior. Veamos un ejemplo:

Ilustración 30 - Entidad:

- Atributos: definidos como unidades básicas de información, que sirven para

identificar o describir una entidad.

Gráficamente, representamos los atributos como elipses en cuyo interior aparece

el nombre del atributo al que se hace referencia. Estas elipses, se asocian con las

entidades mediante líneas, para representar que dicho atributo pertenece a esa

entidad.



Siguiendo con el ejemplo de la entidad USUARIO, veamos cuáles son sus

atributos:

Ilustración 31 - Atributos

Como vemos, esta entidad está formada por cinco atributos: usuario, nombre,

email, password y rol.

- Relaciones: una relación es una asociación entre varias entidades. Determina

algún tipo de colaboración, o existencia de algo en común entre entidades.

Gráficamente, representamos las relaciones mediantes rombos con el nombre

de la relación en su interior. Este rombo estará conectado con las entidades

que relaciona.

En este punto, aparece un nuevo término que denominamos Grado de una

Relación, o Cardinalidad, y que determina el número de entidades con las que otra

entidad se puede asociar a través de un conjunto de relaciones. Atendiendo a esta

clasificación, existen tres tipos de relaciones posibles:

o 1:1 (una a una): para cada ocurrencia de una entidad, le corresponde

exactamente una ocurrencia de la otra.

o 1:n (una a muchas): para cada ocurrencia de una entidad A, le pueden

corresponder muchas ocurrencias de la entidad B, pero para cada

ocurrencia de la entidad B, le corresponde sólo una ocurrecia de la

entidad A.

o n:m (muchas a muchas): a cada ocurrencia de la entidad A, le

corresponden muchas ocurrencias de la entidad B, y viceversa.



Normalmente, representamos la cardinalidad de una relación con un índice sobre

cada extremo de la relación. Veámoslo con un ejemplo:

Ilustración 32 - Relación

¿Cómo leemos la relación anteriror? Como vemos, aparece el índice 1 junto a

usuario, y el índice n junto a petición, por lo tanto, podemos decir que: Un usuario

envía n peticiones, pero una petición sólo ha sido enviada por un usuario.

Otro aspecto fundamental dentro del desarrollo del Modelo Entidad-Relación, es

conocer el concepto de Claves de una Entidad:

- Clave Primaria: denominamos como clave primaria, al conjunto de uno o más

atributos que permite identificar de manera única a cada ocurrencia de un

objeto o entidad. Gráficamente, representamos la clave (o llave) primaria de

una entidad, subrayando el atributo, o conjunto de atributos, que forman la

clave primaria de nuestra entidad.

- Clave Foránea: llamamos clave foránea al atributo, o conjunto de atributos,

que nos sirven como clave primaria de otra entidad con la que esta está

relacionada. Esta clave, también se conoce con el nombre de clave secundaria,

o clave externa.

- Entidades Débiles: una entidad será débil, cuando no contiene claves

primarias. Son aquellas entidades que no pueden ser inequívocamente

identificadas por sus atributos, y para existir, han de estar relacionadas con un

entidad fuerte. Gráficamente las representamos con un doble rectángulo.

- Agregación: una agregación se utiliza para tratar una relación como si fuese

una entidad, a la que por ende, podemos añadir atributos. Se representan

rodeando la relación con un rectángulo de líneas.

Una vez que hemos visto los elementos que constituyen el Modelo E-R, pasamos

a enumerar las tablas que forman nuestro sistema.



3.1.2. Descripción de las tablas del sistema

- Usuario: del que disponemos de identificador de usuario, nombre completo,

email, contraseña y rol que desempeña.

- Paquetes: conocemos el identificador, nombre del paquete, objetivo, opción de

incluir dieta, rutina o ambos, descripción del paquete y precio.

- Propósitos: definen el objetivo del paquete, y está compuesto sólo por el

nombre de propósito.

- Alimentos: formados por id de alimento, nombre, cantidad de alimento para el

que se reflejan el valor nutricional, kcalorías, proporción de proteínas, hidratos

y grasas.

- Ejercicios: de los que conocemos, id de ejercicio, nombre, grupo muscular al

que pertenece el ejercicio, y enlace a explicación web.

- Mensajes: de los que disponemos de id del mensaje, origen, destino, y

contenido del mensaje.

- Peticiones: cada solicitud que envía un cliente, se guarda como petición, y

para cada una de ellas disponemos de: identificador de la petición, usuario

origen o cliente que envía la petición, usuario destino o entrenador contratado,

identificador del paquete seleccionado, estado de la petición, y datos

personales del cliente, como: edad, altura, peso, porcentaje de grasa, nivel de

actividad, pesas, minPesas, cardio, minCardio, objetivo y disponibilidad. Estos

datos se explicarán más adelante.

- Dietas: toda la información relacionada con la dieta puede consultar más

adelante.

- Rutinas: compuesta de identificador de la rutina, nombre y observaciones.

- AlimentosDieta: compuestos de identificador de la dieta, identificador del

alimento, observaciones y alimento.

- EjerciciosRutina: formado por identificador de la rutina, identificador del

ejercicio, número de series, número de repeticiones, campo de observaciones

y el ejercicio.

Es hora de representar el diagrama para el modelor E-R de nuestro sistema.



3.1.3. Diagrama del Modelo E-R

Ilustración 33 - Diagrama del modelo E-R



En la imagen anterior, podemos consultar el diagrama para el modelo E-R de

nuestro sistema, que presenta todas las tablas de nuestra aplicación, en tercera forma

normal (explicaremos este concepto posteriormente).

Partiendo de la FN3 (forma normal 3 o tercera forma normal) del diagrama,

podemos comprobar que se han eliminado las relaciones de muchos a muchos,

existiendo ya sólo relaciones de 1 a 1, y de 1 a n.

Para eliminar estas relaciones de muchos a muchos, el diseño nos ha llevado a

crear tablas intermedias, que por otra parte, nos facilitan enormemente el trabajo.

En el diagrama, quedan representados los atributos para cada una de las tablas

de la aplicación, identificándose además las claves principales o llaves primarias de

cada una de estas, algo que nos permitirá identificarlas de manera inequívoca.

Atendiendo a este punto (atributos de las tablas), podemos decir que la tabla con

mayor peso será la de Dieta, pues cuenta con un total de 34 atributos, mientras que

la más ‘ligera’ sería Propósito, por contar con un solo atributo.

Como podemos observar, entre las tablas Usuario y Mensaje, existen dos

relaciones, que nos sirven para representar que un mensaje puede pertenecer a dos

usuarios: origen y destino.

En el siguiente apartado, veremos como se crean las tablas anteriormente

representadas en el diagrama, así como detallaremos los campos o atributos que las

forman, y señalaremos cómo están relacionadas, a través del conjunto de claves

primarias y foráneas.



3.1.4. Creación de tablas

El propósito de este apartado es el de presentar al lector la estructura de los

datos con los que vamos a trabajar en este sistema [41]. Como ya se ha comentado

en alguna ocasión, el número de tablas de nuestro sistema es de 11 tablas.

TABLA: ALIMENTOS

CAMPO TIPO DE DATO CLAVE DESCRIPCIÓN

ID ENTERO PRIMARIA Identificador único del alimento

NOMBRE CADENA DE CARACTERES - Nombre del alimento

CANTIDAD REAL TIPO DOBLE - Cantidad de alimento para la que se calculan los macronutrientes

CALORIAS REAL TIPO DOBLE - KCalorías del alimento

PROTEINAS REAL TIPO DOBLE - Gramos de proteína que contiene el alimento

HIDRATOS REAL TIPO DOBLE - Gramos de hidratos de carbono que contiene el alimento

GRASAS REAL TIPO DOBLE - Gramos de grasa que contiene el alimento

Tabla 17 - Alimentos

TABLA: USUARIOS


USUARIO CADENA DE CARACTERES PRIMARIA Identificador único del usuario

NOMBRE CADENA DE CARACTERES - Nombre completo del usuario

EMAIL CADENA DE CARACTERES - Correo electrónico del usuario

PASSWORD CADENA DE CARACTERES - Contraseña de acceso del usuario

ROL CADENA DE CARACTERES - Tipo de usuario (determina sus privilegios) Tabla 18 - Usuarios

TABLA: EJERCICIOS


ID ENTERO PRIMARIA Identificador único del ejercicio

NOMBRE CADENA DE CARACTERES - Nombre del ejercicio

TIPO CADENA DE CARACTERES -

Grupo muscular al que pertenece el ejercicio

ENLACE CADENA DE CARACTERES -

Enlace web a la explicación del ejercicio

Tabla 19 - Ejercicios



TABLA: PAQUETES


ID ENTERO PRIMARIA Identificador único del paquete

NOMBRE CADENA DE CARACTERES - Nombre del paquete

OBJETIVO CADENA DE CARACTERES FORÁNEA Tipo de preparación

INCLUYE ENTERO -

1: El paquete incluye Dieta 2: El paquete incluye Rutina 3: El paquete incluye Dieta + Rutina

DESCRIPCION CADENA DE CARACTERES -

Descripción del contenido del paquete

PRECIO REAL TIPO DOBLE - Precio del paquete Tabla 20 - Paquetes

TABLA: MENSAJES


IDMENSAJE ENTERO PRIMARIA Identificador único del mensaje

LEIDO BOOLEANO -

True: si el mensaje ha sido leído False: si el mensaje no ha sido leído

ORIGEN CADENA DE CARACTERES FORÁNEA

Identificador único del emisor del mensaje

DESTINO CADENA DE CARACTERES FORÁNEA

Identificador único del receptor del mensaje

CONTENIDO CADENA DE CARACTERES - Contenido del mensaje

Tabla 21 - Mensajes



TABLA: PETICIONES


IDPETICION ENTERO PRIMARIA Identificador único de la petición

ORIGEN CADENA DE CARACTERES FORÁNEA Identificador único del cliente

DESTINO CADENA DE CARACTERES FORÁNEA

Identificador único del entrenador contratado

IDPAQUETE ENTERO FORÁNEA Identificador único del paquete contratado

ESTADO BOOLEANO - 0: La petición está sin atender 1:La petición ha sido atendida

EDAD ENTERO - Edad del cliente

ALTURA ENTERO - Altura (en cm.) del cliente

PESO REAL TIPO DOBLE - Peso (en Kg.) del cliente

GRASA REAL TIPO DOBLE - Porcentaje de grasa del cliente

SEXO ENTERO - 1: Hombre 2:Mujer

ACTIVIDAD REAL TIPO DOBLE - Nivel de actividad del cliente

PESAS ENTERO -

0: El cliente no entrena con pesas 1: El cliente realiza pesas de forma moderada 2: El cliente realiza pesas de manera intensa

MINPESAS ENTERO -

Minutos durante los que se realiza el entrenamiento de pesas

CARDIO ENTERO -

0: El cliente no realiza entrenamiento cardiovascular 1: El cliente realiza entrenamiento cardiovascular de forma moderada 2: El cliente realiza entrenamiento cardiovascular de manera intensa 3: El cliente realiza HIIT

MINCARDIO ENTERO -

Minutos durante los que se realiza el entrenamiento cardiovascular

OBJETIVO ENTERO -

1: Pérdida de grasa 2: Mantenimiento del estado actual 3: Aumento de masa muscular

DISPONIBILIDAD ENTERO -

De 1 a 7 indica los días que el cliente tiene disponibles para entrenar

Tabla 22 - Peticiones



TABLA: DIETAS


IDDIETA ENTERO PRIMARIA Identificador único de la dieta

IDPETICION ENTERO FORÁNEA

Identificador único de la petición a la que está asociada la dieta

NUMCOMIDAS ENTERO - Número de comidas que debe hacer el cliente

NUMDIASDIETA ENTERO - Número de días que el cliente seguirá la dieta

MBHARRIS REAL TIPO DOBLE -

Metabolismo Basal del cliente según la fórmula de Harris-Benedict

MBJEOR REAL TIPO DOBLE -

Metabolismo Basal del cliente según la fórmula de Mifflin St-Jeor

MBKATCH REAL TIPO DOBLE -

Metabolismo Basal del cliente según la fórmula de Katch McArdle

GHARRIS REAL TIPO DOBLE -

Gasto Energético Total del cliente según la fórmula de Harris-Benedict

GJEOR REAL TIPO DOBLE -

Gasto Energético Total del cliente según la fórmula de Mifflin St-Jeor

GKATCH REAL TIPO DOBLE -

Gasto Energético Total del cliente según la fórmula de Katch McArdle

CALPESAS REAL TIPO DOBLE - Kcalorías gastadas por el cliente en un entrenamiento de pesas

CALCARDIO REAL TIPO DOBLE -

Kcalorías gastadas por el cliente en un entrenamiento cardiovascular

CALCOMPLETO REAL TIPO DOBLE -

Kcalorías gastadas por el cliente en un día de entrenamiento completo

GPESAS REAL TIPO DOBLE -

Gasto Energético Total del cliente + Kcalorías gastadas en un entrenamiento de pesas

GCARDIO REAL TIPO DOBLE -

Gasto Energético Total del cliente + Kcalorías gastadas en un entrenamiento cardiovascular

GCOMPLETO REAL TIPO DOBLE -

Gasto Energético Total del cliente + Kcalorías gastadas en un entrenamiento completo



OBJETIVO REAL TIPO DOBLE -

Porcentaje de déficit o superávit calórico que se aplicará al Gasto Energético Total

GREPOSODEFINICION REAL TIPO DOBLE -

Objetivo calórico aplicado al GET un día de reposo para una situación de pérdida de grasa

GPESASDEFINICION REAL TIPO DOBLE -

Objetivo calórico aplicado al GET un día de entrenamiento con pesas para una situación de pérdida de grasa

GCARDIODEFINICION REAL TIPO DOBLE -

Objetivo calórico aplicado al GET un día de entrenamiento cardiovascular para una situación de pérdida de grasa

GCOMPLETODEFINICION REAL TIPO DOBLE -

Objetivo calórico aplicado al GET un día de entrenamiento completo para una situación de pérdida de grasa

GREPOSOVOLUMEN REAL TIPO DOBLE -

Objetivo calórico aplicado al GET un día de reposo para una situación de aumento de masa muscular

GPESASVOLUMEN REAL TIPO DOBLE -

Objetivo calórico aplicado al GET un día de entrenamiento con pesas para una situación de aumento de masa muscular

GCARDIOVOLUMEN REAL TIPO DOBLE -

Objetivo calórico aplicado al GET un día de entrenamiento cardiovascular para una situación de masa muscular

GCOMPLETOVOLUMEN REAL TIPO DOBLE -

Objetivo calórico aplicado al GET un día de entrenamiento completo para una situación de aumento de masa muscular

GRPROTEINASPORKG REAL TIPO DOBLE - Gramos de proteína por kg que debe consumir el cliente

GRGRASASPORKG REAL TIPO DOBLE - Gramos de grasa por kg que debe consumir el cliente

GRHIDRATOSPORKG REAL TIPO DOBLE - Gramos de hidratos de carbono que debe consumir el cliente

GRP REAL TIPO DOBLE - Gramos de proteína totales que debe consumir el cliente

GRGR REAL TIPO DOBLE - Gramos de grasa totales que debe consumir el cliente

GRH REAL TIPO DOBLE -

Gramos de carbohidratos totales que debe consumir el cliente

KCALP REAL TIPO DOBLE - Kcalorías totales de proteína



KCALGR REAL TIPO DOBLE - Kcalorías totales de grasa

KCALH REAL TIPO DOBLE - Kcalorías totales de hidratos de carbono

Tabla 23 - Dietas

TABLA: ALIMENTOSDIETA


IDDIETA ENTERO FORÁNEA Identificador único de la dieta

IDALIMENTO ENTERO FORÁNEA Identificador único del alimento

OBSERVACIONES CADENA DE CARACTERES -

Observaciones asociadas a la inclusión de ese alimento en la dieta

Tabla 24 - AlimentosDieta

TABLA: RUTINAS


IDRUTINA ENTERO PRIMARIA Identificador único de la rutina

IDPETICION ENTERO FORÁNEA Identificador único de la petición a la que está asociada la rutina

NOMBRE CADENA DE CARACTERES - Nombre de rutina

DESCRIPCIÓN CADENA DE CARACTERES -

Observaciones asociadas a la rutina

Tabla 25 - Rutinas

TABLA: EJERCICIOSRUTINA


IDRUTINA ENTERO FORÁNEA Identificador único de la rutina

IDEJERCICIO ENTERO FORÁNEA Identificador único del ejercicio

SERIES ENTERO - Número de series que el cliente realizará de ese ejercicio

REPETICIONES ENTERO - Número de repeticiones que el cliente realizará de ese ejercicio

OBSERVACIONES CADENA DE CARACTERES -

Observaciones asociadas a la inclusión de ese ejercicio en la rutina

Tabla 26 - EjerciciosRutina



Es preciso señalar que las tablas de mi aplicación ha sido diseñadas para estar

en Tercera Formal Normal, pero ¿Qué es la Tercera Forma Normal? Para dar

respuesta a esta pregunta, es necesario ver el siguiente apartado.

3.1.5. Normalización

Llamamos normalización al proceso por el cuál se imponen una serie de normas

o restricciones a las tablas con el fin de asegurar que estas poseen los atributos

necesarios y suficientes para describir con exactitud la entidad a la que simbolizan

[42]. Este proceso, a través de una serie de transformaciones nos proporciona una

estructura ideal de las tablas, con el objetivo de que su implementación sea óptima.

A modo de resumen, existen tres tipos de niveles en cuanto a normalización nos

referimos. De este modo, encontramos que una tabla puede estar en:

- Primera Forma Normal (FN1): si todos los atributos que no son clave primaria,

dependen funcionalmente de esta. Es decir, no existen grupos repetitivos para

un valor clave.

- Segunda Forma Normal (FN2): todos los atributos no clave dependen

funcionalmente de forma completa de la clave primaria.

- Tercera Forma Normal (FN3): la tabla se encentra en segunda forma normal, y

además, no existen atributos no clave que tengan dependencias funcionales

entre sí.

* NOTA: decimos que existe un Dependencia Funcional entre A y B, si para cada

valor de A existe solamente un valor de B, y viceversa.

Para nuestro sistema, ha sido imprescindible la representación de las entidades

en Tercera Formal Normal, para evitar así algunos de los mayores peligros que

pueden surgir de un diseño deficiente de la base de datos, como son: repetición de la

información o información duplicada, imposibilidad de representar algún tipo de

información, o pérdida de información en el proceso de diseño de la base de datos.



Relación Nombre

R1 AlimentosDieta

R2 EjerciciosRutina

Tabla 27 - Relaciones Modelo E-R Modificado

Hemos comentado que las tablas del sistema están diseñadas buscando la

tercera forma normal por lo que, entre otras características, no existen endidades

débiles ni dependencias transitivas entre los atributos de las tablas.

Comentemos un poco las relaciones que tenemos:

- Entre las entidades; o tablas, Paquete y Proposito, encontramos una relación

de 1 a n, pues 1 paquete sólo tiene 1 propósito, pero 1 propósito puede estar

en n paquetes.

- Observamos, que entre Usuario y Mensaje existen dos relaciones, esto es

debido a que si bien 1 usuario puede escribir n mensajes, 1 mensaje pertenece

a dos usuarios, o dicho de otra manera, en 1 mensaje intervienen 2 usuarios el

emisor u origen, y el receptor o destino.

- La relación entre Usuario y Petición es de 1 a n, pues 1 usuario puede enviar n

peticiones, pero 1 petición sólo pertenece a un usuario.

- Entre Petición y Paquete existe una relación de 1 a n pues 1 petición sólo tiene

asociado 1 paquete, pero 1 paquete puede estar en n peticiones.

- La relaciones Peticion-Dieta y Peticion-Rutina, son de 1 a 1 pues 1 petición sólo

puede tener asociada 1 dieta o 1 rutina en cada caso, y a su vez, cada dieta-

rutina sólo pertenece a 1 petición.

- Por último, como podemos observar en la tabla, existen dos relaciones R1 y

R2, que representan las conexiones Dieta-Alimento y Rutina-Ejercicio, en cada

caso. Estas relaciones se han representado de esta manera pues dan lugar a

tablas intermedias, debido a que es necesario almacenar información adicional

para la relación entre ambas entidades, como se puede ver en la imagen.



Otro punto a tener en cuenta es la manera en que se relacionan las tablas. Como

se ha visto anteriormente, estas relaciones son posibles gracias a las claves foráneas,

es decir, al atributo o conjunto de atributos que nos sirven como llave primaria de la

otra entidad con la que la actual está relacionada.

En la siguiente tabla vamos a ver cuáles son las claves primarias y foráneas para

cada entidad, lo que nos permitirá entender de una forma más gráfica las relaciones

entre las tablas que componen nuestro sistema:

Entidad Clave Primaria Clave Foránea 1 Clave Foránea 2 Relación

Usuarios usuario (1) (2) (4)

Mensajes idMensaje origen (1) destino (2)

Paquetes idPaquete objetivo (3) (5)

Propósitos nombre (3)

Peticiones idPeticion origen (4) idPaquete (5) (6) (7)

Dietas idDieta idPeticion (6) (8)

Rutinas idRutina idPeticion (7) (9)

Alimentos idAlimento (8)

Ejercicios idEjercicio (9)

AlimentosDieta idDieta + idAlimento (8)

EjerciciosRutina idRutina + idEjercicio (9) Tabla 28 - Las relaciones según sus claves

En la segunda columna de la tabla podemos ver los atributos que actúan como

clave primaria de cada entidad (primera columna), mientras que las columnas tercera

y cuarta, muestran los atributos de cada tabla que son claves foráneas y nos sirven

para relacionarlos con otras tablas.

Los índices que se muestran en las columnas tercera y cuarta están conectados

con los que se muestran en la quinta columna. Así por ejemplo, tenemos que el índice

(4) representa que existe una relación entre las tablas Dietas y Usuarios, siendo el

atributo origen de la tabla Dietas el nexo de unión entre tablas (clave foránea para la

tabla Dietas, clave primaria para la tabla Usuarios).

Como se puede comprobar, en la Tabla 28 - Las relaciones según sus claves

existen 9 índices, que marcan las 9 relaciones reflejadas en la Ilustración 33 -

Diagrama del modelo E-R.



3.2. Diagrama de Clases

Los diagramas de clases [43] son el tipo de diagrama que más se emplea en el

modelado de sistemas orientado a objetos. Los diagramas de clases modelan la vista

de diseño estática del sistema mostrando para ello tanto el conjunto de clases que

componen el sistema, como las interfaces y colaboraciones, y las relaciones

existentes entre estos elementos.

Los diagramas de clases, son un tipo especial de diagrama que aunque

comparte ciertas propiedades que son comunes a otros diagramas, tiene una serie de

elementos o contenido particular, que lo distingue de otros diagramas. Generalmente,

un diagrama de clases está formado por los siguientes elementos [44]:

- Clases: Una clase es uno de los elementos más importantes dentro de

cualquier sistema orientado a objetos, debido a que nos proporciona una

descripción detallada de un conjunto de objetos que comparten los mismos

atributos, operaciones, relaciones y semántica. Las clases las representaremos

como rectángulos divididos en las tres partes más importantes de una

abstracción, como son: nombre, atributos y operaciones.

Un ejemplo de clase sería el que se muestra en la siguiente ilustración:

Ilustración 34 - Ejemplo de Clase

- Atributos: los atributos son propiedades, identificadas con un nombre, que

tienen en común los objetos que representan una clase. Un objeto de una clase,

tendrá un valor determinado para cada atributo o propiedad de dicha clase. Los

atributos se pueden especificar indicando el tipo de dato al que hacen

referencia e incluso algún valor inicial. Podemos clasificar los atributos en:

public (+), private (-) y protected (#), dependiendo de si son accesibles o no

desde fuera de la clase a la que pertenecen.



- Operaciones: las operaciones de una clase indican todo aquello que se puede

hacer a un objeto de la clase, es decir, muestran la forma de interactuar de una

clase con el resto de elementos del entorno. Como los atributos, las

operaciones pueden clasificarse en: public (+), private (-) y protected (#). Las

operaciones suelen especificarse añadiendo el nombre, tipo, valores por

defecto de todos los parámetros que utiliza y tipo de dato que devuelve.

- Relaciones: una relación entre dos clases representa una conexión entre

estas. Podemos distinguir distintos tipos de relaciones en un diagrama de

clases [45]. Los más utilizados son los siguientes:

o Asociación: indica que los objetos de una clase están conectados con

los objetos de otra clase.

o Dependencia: señala una relación de uso entre dos clases, en la que

una utiliza las operaciones de otra, o que utiliza alguna variable cuyo tipo

de dato viene determinado por la otra.

o Generalización: en este caso, señalamos que una clase adopta las

propiedades de una clase superior, o clase padre, e incluso, añade

alguna propiedad u operación.

Ilustración 35 – Generalización

o Agregación: es un tipo especial de asociación, para especificar que una

clase es parte de otra. La representamos como un rombo vacío al lado

de la clase que funciona como ‘todo’.



Ilustración 36 - Agregación

o Composición: es un tipo de asociación parecido al anterior, pero en

este caso, la diferencia es que la clase ‘todo’ se encarga de la existencia

de la clase ‘parte’. Se representa con un rombo negro al lado de la clase

que actúa como ‘todo’.

Ilustración 37 – Composición

Una vez que hemos estudiado los elementos que intervienen en un diagrama de

clases, según el Lenguaje Unificado de Modelado UML, es hora de entender de qué

manera se ha organizado el modelo de nuestro sistema. Para ello, se ha seguido la

adaptación del patrón MVC a la tecnología JavaServer Pages, llamada Model 2, cuyo

esquema es el siguiente:



Ilustración 38 - Modelo-Vista-Controlador

- Modelo: compuesto por los objetos que contienen los datos, contiene además

los mecanismos que nos indican cómo trabajar con esos datos, acceder a la

información y actualizarlos. Generalmente, los datos los tendremos

almacenados en una base de datos, por lo que esta capa nos indicará de qué

manera podemos acceder a la base de datos, realizar las consultas, etc.

- Vista: representan la capa visible de la interfaz de usuario, mostrándole a este

la información del modelo. En esta parte tenemos todo el código HTML, CSS,

JSP’s, etc. de la aplicación.

- Controlador: actua como enlace entre las vistas y los modelos. Se encarga de

gestionar los eventos o acciones realizadas por el usuario de la aplicación, y

traslada sus peticiones al modelo, solicitándole datos, pero también enviando

actualizaciones de estos. Decimos que es el nexo de unión entre el modelo y

la vista, pues envía los datos que recibe del modelo a la vista, y viceversa.

Tras conocer los elementos que intervienen en el patrón Modelo-Vista-

Controlador, vamos a repasar de qué manera se producen las interacciones entre

estos, es decir, el flujo de ejecución básico del patrón.



Ilustración 39 - Patrón MVC

1) El usuario envía una solicitud al sitio web, por lo general, tratando de acceder

una página del sistema. Dicha solicitud será recibida por el controlador.

2) Como hemos comentado, y además podemos observar en la ilustración

anterior, el controlador se comunica tanto con las vistas como con el modelo.

De una parte, recibe las peticiones enviadas por el usuario a través de las

vistas, y solicitándole información al modelo. De otra, enviando datos que el

usuario le ha enviado previamente para actualizar o modificar el modelo.

3) Una vez que se trabaja con la información desde la lógica de negocio, o

modelo de nuestro patrón, esta información es enviada de nuevo al

controlador, quien se encarga de enviarla de vuelta a las vistas.

4) La principal función de las vistas es la de mostrar al usuario la salida de datos,

repitiendo el ciclo bajo nuevas interacciones por parte del usuario.

Una vez que tenemos toda la información necesaria sobre el patrón utilizado

para organizar la arquitectura de nuestro software, veamos cuál sería el diseño

resultante de aplicar dicho patrón a nuestro sistema:



Ilustración 40 - Diagrama de Clases General

Como se puede apreciar en la imagen, se distingue claramente el esquema

comentado con anterioridad en este apartado, formado por tres grandes paquetes o

elementos: paquete para los controladores, paquete relacionado con las vistas y

paquete destinado al modelo de negocio. Este último contiene a su vez dos paquetes:

clases y objetos de acceso a los datos, también conocidos como DAOs.

Sin embargo, lo que realmente aportará valor al diagrama, será ver con exactitud

las relaciones que se producen entre los elementos que componen cada uno de estos

paquetes.

Por ello, en primer lugar, vamos a analizar un ejemplo de interacción de un

controlador en concreto, con sus correspondientes DAO’s y el paquete vistas. No se

mostrará con qué vistas específicas se relaciona, sino el paquete en general, algo que

nos proporcionará una idea del funcionamiento general.



Ilustración 41 - MVC aplicado a Clientes

Como se puede observar en la ilustración, se muestra el modelo-vista-

controlador aplicado al caso concreto del controlador de clientes.

En este caso, dicho controlador está relacionado con diferentes DAO’s, 7 en

concreto: clienteDAOJDBC, mensajeDAOJDBC, peticionDAOJDBC,

alimentosDietaDAOJDBC, dietaDAOJDBC, ejerciciosRutinaDAOJDBC, y

rutinaDAOJDBC. Se muestra además, la relación de cada uno de estos DAO’s con

sus clases.

Por último en esta imagen, se muestra la relación de ContrClientes con las vistas

(en general, como hemos comentado anteriormente), y de estas últimas con el modelo

de la aplicación. El detalle del resto de controladores sigue un esquema similar al

analizado, pero por cuestiones de espacio no se muestra en esta memoria.



Una vez visto el ejemplo anterior, es hora de pasar a analizar los diagramas de

cada uno de los paquetes que forman nuestro MVC por separado:

Paquete Controladores:

Ilustración 42 - Paquete Controladores

El paquete Controladores almacena todos los controladores de la aplicación,

siendo los controladores principales de la aplicación: contrClientes, contrDietas,

contrPeticiones o contrRutinas, debido al número de DAO’s a los que acceden o

funcionalidades que implementan mayor que en el resto de controladores. Entre los

controladores que menos ‘peso’ tienen dentro del sistema (en cuanto a accesos y

funcionalidades implementadas se refiere) tenemos a: LoginController y Registro. El

resto se encuentra en un escalón medio.

Así, por ejemplo, el controlador de clientes: contrClientes, accede a 7 DAO’s

diferentes (como hemos visto anteriormente) e iimplementa 12 funciones distintas. Sin

embargo, el controlador destinado al login: Registro, solamente accede a un DAO (el

de clientes) e implementa sólo una función.



Paquete Clases:

Ilustración 43 - Paquete Clases

El paquete Clases está formado por todas clases existentes en nuestro sistema,

almacenando, cada una de ellas, toda la información sobre cada clase. Nuevamente,

si tuviésemos que clasificar de algún modo estas clases, de acuerdo a la información

que recoge cada una de ellas, las de mayor ‘peso’ serían: Peticion y Dieta, pues están

formadas por 17 y 34 atributos respectivamente.

Paquete DAOs:

Ilustración 44 - Paquete DAOs



Este último paquete, está compuesto por los DAO’s de nuestra aplicación,

permitiendo conectar nuestros controladores con la BD. Por ejemplo, el DAO

relacionado con los mensajes: MensajesDAOJDBC, nos permitirá realizar las

consultas a la BD que nos proporcionan el identificador de usuario del

emisor/destinatario de un mensaje, listado de todos los mensajes asociados a un

usuario, listado de mensajes sin atender de un determinado usuario, número de

mensajes sin leer de un usuario, y las funcionalidades básicas del CRUD de dicho

objeto: crear, actualizar, borrar un mensaje o borrar el listado de mensajes asociados

a un usuario.

Hasta ahora hemos mostrado los elementos que componen tres de los cuatro

paquetes que se mostraban en la Ilustración 40 - Diagrama de Clases General sin

embargo, vamos a obviar aquellos que componen el paquete Vistas, pues se

considera que no aporta valor real al objetivo de este apartado.

En el siguiente diagrama veremos la manera en que se comunica el sistema,

mostrando para ello las relaciones que se establecen entre los diferentes

controladores y los daos.

* NOTA: Puesto que es posible que no se aprecien con detalle las relaciones que

se van a mostrar en el siguiente diagrama (se muestran un total de 57 relaciones),

este estará también disponible en el contenido del CD que se adjunta.



Ilustración 45 - Diagrama de Clases: Relaciones



Una vez que hemos visto el diagrama general de relaciones entre los diferentes

controladores y DAO’s del sistema, creo que es conveniente analizar algún ejemplo

concreto, tratando de simplificar el diagrama anterior.

En primer lugar, vamos a ver las relaciones que se establecen entre los

controladores: ContrDietas, ContrAlimento y ContrAlimentosDieta, con los DAO’s a los

que estos controladores acceden.

Ilustración 46 - Relaciones Controladores-DAOs

Como podemos observar, tenemos un número menor de relaciones, 15

concretamente. De todas ellas, destacar el hecho de que los tres controladores

acceden a los DAO’s: PeticionDAOJDBC y MensajeDAOJDBC, puesto que el

entrenador en todo momento necesita saber el número de peticiones y mensajes sin

atender, por lo que es necesario acceder a dichos DAO’s para lanzar la consultar que

nos permite averiguar este dato.



El siguiente y último ejemplo que vamos a desglosar, es el de los controladores:

ContrPeticiones, ContrPaquetes y ContrPropositos. Como veremos en la imagen el

número de relaciones entre estos controladores y los DAO’s a los que acceden es de:

14 relaciones.

Ilustración 47 - Relaciones Controladores-DAOs - 2

A modo de resumen comentar, que por ejemplo, el controlador ContrPeticiones,

es, junto al de clientes, el que más significado tiene para el sistema, pues es el que

conecta a los clientes con sus solicitudes, dietas, rutinas y resto de funcionalidades

de los usuarios.



3.3. Diagramas de secuencia

Un diagrama de secuencia es un tipo de diagrama UML utilizado para mostrar

de manera gráfica la interacción entre los diferentes objetos de un sistema, de manera

ordenada en un secuencia de tiempo [46].

Sirve para detallar de manera visual como evoluciona un caso de uso en el

tiempo, mostrando tanto los objetos, como las clases involucradas en un determinado

escenario, así como el intercambio de mensajes realizado entre objetos que es

necesario para cumplir con la funcionalidad del escenario.

Por lo general, un diagrama de secuencia marca una asociación entre el caso de

uso con su realización en la vista lógica del sistema de desarrollo.

Los elementos que componen un diagrama de secuencia [47] son los siguientes:

- Actor: participante externo al sistema que particiapa en el interacción.

- Línea de vida: dibujada con una línea vertical, representa la secuencia de

eventos que lleva a cabo un actor durante una interacción. En esta línea de

vida, también aparece un pequeño rectángulo, llamado activación, que

representa la duración de ejecución de una operación realizada por un objeto,

es decir, desde el momento en que se activa (o inicia la acción), hasta que se

‘desactiva’ (o finaliza).

- Objetos: representados de manera usual mediante rectángulos que incluyen el

nombre en el interior, subrayado. Normalmente se colocan en la parte superior

del diagrama, apareciendo ordenados de izquierda a derecha según su

aparición en el tiempo.

- Mensajes: se representan con líneas horizontales que van de un objeto a otro,

a su línea de vida más exactamente, mostrando de qué manera interactúan los

objetos.

- Tiempo: el tiempo se muestra representado en el diagrama por la secuencia de

interacciones de manera vertical, iniciándose en la parte superior del diagrama,

avanzando hacia la parte final.



Una vez analizado en qué consiste un diagrama de secuencia, y vistos sus

componentes, vamos a repasar los diagramas de secuencia más representativos de

la aplicación:

Diagramas de Secuencia: Registrarse

Ilustración 48 - Diagramas de Secuencia: Registrarse



Diagramas de Secuencia: Login

Ilustración 49 - Diagramas de Secuencia: Login



Partiendo de esta situación inicial, es decir, un usuario (del tipo que sea) que ya

se ha identificado en la plataforma (diagrama que puede observarse en la imagen

anterior), y ya se encuentra en su página de inicio correspondiente, vamos a

desarrollar los siguientes diagramas de secuencia.

En primer lugar, tenemos el siguiente diagrama de secuencia para el caso de

uso: Contratar Paquete, que realizan cualquier usuario de tipo cliente.

Diagramas de Secuencia: Contratar Paquete

Ilustración 50 - Diagramas de Secuencia: Contratar Paquete



El siguente diagrama de secuencia que vamos a ver, es el relacionado con la

acción ‘Eliminar Listado de Mensajes’ de la parte del cliente:

Diagramas de Secuencia: Eliminar Listado de Mensajes

Ilustración 51 - Diagramas de Secuencia: Eliminar Listado de Mensajes



Diagramas de Secuencia: Añadir Propósito

En el siguiente diagrama podemos consultar la evolución del caso de uso; de la

parte del administrador, Añadir Propósito, en el que un entrenador personal añade un

nuevo objetivo que incorporar a los paquetes ofertados en la plataforma.

Ilustración 52 - Diagramas de Secuencia: Añadir Propósito



Diagramas de Secuencia: Modificar Datos de Usuario

Ilustración 53 - Diagramas de Secuencia: Modificar Datos de Usuario



Diagramas de Secuencia: Asignar Rutina – Parte 1

Ilustración 54 - Diagramas de Secuencia: Asignar Rutina - Parte 1

En esta pantalla se muestra la primera parte del proceso de elaboración de

rutinas o planes de entrenamiento. Esta primera parte va desde que el entrenador

selecciona la vista con el listado de peticiones pendientes, hasta que rellena los

primeros pasos del proceso, los del formulario de crear rutinas. Como este proceso se

divide en dos alternativas, dependiendo de si el formulario se ha rellenado

correctamente o no, vamos a separar el diagrama para estos dos procesos:



Diagramas de Secuencia: Asignar Rutina – Parte 2

Ilustración 55 - Diagramas de Secuencia: Asignar Rutina - Parte 2

Como he comentado anteriormente, este diagrama muestra los distintos flujos

que pueden producirse cuando el entrenador rellena el formulario de creación de

rutina: para un flujo correcto e incorrecto.

Dentro del flujo correcto, encontramos un cuadro bajo la etiqueta Loop, que

significa que todas las interacciones dentro de este cuadro se realizan en un bucle,

que se repetirá n-veces, a elección del usuario. El bucle hace referencia al hecho de

añadir un nuevo ejercicio a la rutina, acción que el entrenador puede repetir hasta que

crea que la rutina está completa, y una vez finalizado, cerrará la rutina.



3.4. Diseño de la Interfaz

3.4.1. Diseño wireframe de las pantallas de usuario

Uno de los primeros pasos que debemos seguir a la hora de desarrollar una

aplicación, del tipo que sea, es diseñar los bocetos o wireframe de las pantallas de

usuario y las funcionalidades básicas de la aplicación.

El wireframe o boceto, proporciona el esqueleto del diseño de la aplicación,

representado solamente con líneas y vértices, sin incluir estilos ni imágenes. El

objetivo es simplemente proporcionar al lector una visión general del funcionamiento

del sistema [48].

En primer lugar, comentar que aunque la mejor herramienta para diseñar las

pantallas y crear la estructura que tendrán estas, es realizar los dibujos a mano alzada

con papel y lápiz, puesto que se ahorra tiempo y nos proporciona mayor flexibilidad

para modificar los diseños, yo he utilizado una herramienta especializada en el diseño

de este tipo de bocetos, y la verdad es que me ha resultado bastante intuitiva de utilizar

y muy cómoda para modificar o añadir nuevos elementos. La herramienta en cuestión

se llama MockFlow, y aunque es una aplicación con licencia, dispone de una versión

gratuita que permite crear un máximo de cuatro páginas. Además dispone de una

amplia gama de elementos GUI que pueden ser utilizados por los usuarios tanto de

plataformas Windows como Mac.

Sin nada más que contar acerca de la herramienta, pasamos a ver los prototipos

diseñados. En este caso, he considerado los más representativos de la aplicación,

pues dentro de la misma existen diferentes objetos de negocio que realizan las

mismas tareas pero aplicadas a cada objeto, e incluirlas todas podría resultar

demasiado repetitivo.



Pantalla de bienvenida a la aplicación

Ilustración 56 - Diseño wireframe: bienvenida a la aplicación

Como podemos observar en la Ilustración 56 - Diseño wireframe: bienvenida a

la aplicación, la pantalla se divide en dos secciones principales, junto con una

cabecera para la descripción del proyecto. Estas dos secciones (de izquierda a

derecha) son:

- Identificación: donde el usuario que ya esté registrado en la plataforma

introducirá sus credenciales para acceder a la misma.

- Registro: donde un nuevo visitante podrá introducir los datos que se requieren

en el formulario de registro para darse de alta como nuevo miembro de la

aplicación y poder hacer uso de sus beneficios. Por defecto, el usuario será

creado con el rol cliente.



Pantalla de Gestión de Clientes – Parte del Administrador

Ilustración 57 - Diseño wireframe: Gestión de Clientes (Parte del Administrador)

En esta pantalla podemos observar tres secciones claramente diferenciadas. Por

una parte, disponemos de una barra superior, la cual es fija, en la podemos observar

un mensaje que nos indicará el nombre de usuario de la persona logueada, junto con

un botón que le permitirá abandonar la sesión en cualquier momento.

Justo debajo de esta barra se muestra una imagen de cabecera junto con una

barra horizontal que permitirá al usuario acceder a diferentes funcionalidades que le

ofrece la plataforma. Estos dos elementos se mantendrán a lo largo del resto de

páginas de la web.

Por último, en la sección que contiene el contenido propio de cada página, y en

este caso en concreto, podemos ver una tabla que incluye el listado de usuarios de la

plataforma, con una serie de funcionalidades asociadas a cada uno de ellos, como

son:

- Datos: opción para consultar los datos personales del cliente en cuestión.

- Mensajes: para consultar el listado de mensajes asociados a un cliente

determinado.

- Peticiones: mostrará el listado de peticiones enviadas por un cliente.

- Dietas: se mostrará el listado de dietas asignadas a un determinado cliente.

- Rutinas: planes de entrenamiento asociados a un cliente.



- Eliminar: opción para eliminar todos los datos asociados a un determinado

cliente junto con su cuenta de usuario.

Como se muestra en la propia imagen, las opciones ‘Mensajes’ y ‘Peticiones’,

van acompañadas de un indicador entre paréntesis que advertirán al ‘Entrenador

Personal’ que tiene un mensaje (o petición) sin atender de un usuario en concreto.

Visualizar Datos Personales de un usuario – Parte del Administrador

Ilustración 58 - Diseño wireframe: Visualizar Datos Personales (Parte del Administrador)

En esta pantalla se mostrará una ficha con los datos personales del usuario

seleccionado, junto con las partes comunes comentadas anteriormente, y un botón

que permitirá al administrador modificar los datos del cliente en cuestión.



Modificar Datos de Usuario – Parte del Administrador

Ilustración 59 - Diseño wireframe: Modificar Datos Personales (Parte del Administrador)

La Ilustración 59 - Diseño wireframe: Modificar Datos Personales (Parte del

Administrador) muestra la pantalla que el ‘Entrenador Personal’ verá cuando pulse la

opción de ‘Modificar Datos’ de un usuario registrado en la plataforma. Como podemos

observar, el contenido de la página se divide en dos secciones, una imagen a la

izquierda y otra con los campos que reflejan los datos personales del cliente referentes

al registro en la plataforma.

Como se especifica en la propia imagen, el identificador de usuario aparece

bloqueado, pues al ser el campo clave, y para evitar problemas, no se podrá modificar.

El resto de campos que se pueden modificar son: nombre completo del usuario, email,

password y rol. Respecto de este último, es necesario recalcar que solo es accesible

o modificable por los usuarios de tipo administrador (‘Entrenador Personal’) quienes

serán los encargados de asignar nuevos ‘Entrenadores Personales’.



Histórico de mensajes asociados a un cliente – Parte del Administrador

Ilustración 60 - Diseño wireframe: Histórico de Mensajes (Parte del Administrador)

Pantalla que muestra a parte del contenido común, un listado con los mensajes

tanto recibidos como enviados por parte de un usuario de la plataforma. Para cada

mensaje se muestra además:

- Usuario origen: usuario que ha escrito el mensaje.

- Usuario destino: usuario que recibe el mensaje en cuestión.

- Fecha y hora: fecha y hora en las que el mensaje ha sido escrito.

- Contenido del mensaje.

- Leído: determina si el mensaje ha sido atendido (leído) o no.



Histórico de peticiones de un cliente – Parte del Administrador

Ilustración 61 - Diseño wireframe: Ver Petición Cliente (Parte del Administrador)

En esta pantalla se debe mostrar toda la información que el cliente haya

proporcionado en el formulario de contratación de servicios, junto con la parte común

de la aplicación. Esta información permitirá al ‘Entrenador Personal’ elaborar la dieta

o plan de entrenamiento solicitados por el cliente, accediendo a los botones que se

muestran en cada caso.

Pantalla Asignar Dieta a un cliente – Parte del Administrador

Ilustración 62 - Diseño wireframe: Asignar Dieta Cliente (Parte del Administrador)



En esta pantalla se mostrarán todos los pasos y cálculos que el ‘Entrenador

Personal’ debe seguir para asignar una dieta al cliente.

Pantalla Asignar Ejercicios Rutina – Parte del Administrador

Ilustración 63 - Diseño wireframe: Añadir Ejercicios a una Rutina (Parte del Administrador)

Esta pantalla mostrará al ‘Entrenador Personal’ el listado de ejercicios que ya ha

añadido a una rutina determinada de un cliente, si los hay, y si no le dará la

oportunidad de añadirlos rellenando los campos necesarios.

El botón ‘Finalizar’ indicará que el ‘Entrenador Personal’ no quiere añadir nuevos

ejercicios y desea finalizar el proceso.



Gestión de paquetes ofertados en la plataforma – Parte del Administrador

Ilustración 64 - Diseño wireframe: Listado de Paquetes (Parte del Administrador)

Pantalla que muestra el listado de los paquetes ofertados en la plataforma, junto

con las opciones de editar y eliminar asociadas a cada paquete, y la opción de añadir

un nuevo paquete a la BBDD de la aplicación.

Añadir nuevo Paquete – Parte del Administrador

Ilustración 65 - Diseño wireframe: Añadir Nuevo Paquete (Parte del Administrador)

La pantalla de ‘Añadir nuevo Paquete’ permitirá al administrador añadir un nuevo

paquete ofertado en la plataforma, rellenando los campos que se muestran en la

ilustración. Estos son:



- Nombre del paquete.

- Objetivo: indica al cliente para qué tipo de clientes está orientado el paquete.

- Incluye: determina si un paquete incluye sólo dieta, sólo rutina o incluye ambas

opciones.

- Descripción: explicación detallada del contenido del paquete.

- Precio.

Pantalla de Ejercicios – Parte del Administrador

Ilustración 66 - Diseño wireframe: Listado de Ejercicios (Parte del Administrador)

Como podemos observar, en esta pantalla se mostrará un listado de todos los

ejercicios existentes en la BBDD de Ejercicios de la plataforma, separador por grupo

muscular, junto con las opciones de ‘Editar’ y ‘Eliminar’, que nos permitirán modificar

los datos de un ejercicio determinado, o de eliminarlo.



Pantalla de inicio del Cliente

Ilustración 67 - Diseño wireframe: Pantalla de Inicio (Parte del Cliente)

La Ilustración 67 - Diseño wireframe: Pantalla de Inicio (Parte del Cliente)

muestra la pantalla que podrá ver el cliente una vez haya accedido de manera correcta

a la plataforma. En ella, y como se muestra en la imagen, se mantiene la barra superior

que también veíamos en la parte del administrador, que muestra el identificador del

usuario logueado junto con la opción de ‘Cerrar sesión’, pero con una diferencia. Ahora

aparece también el icono de un pequeño sobre que permitirá al cliente acceder a su

sección de mensajes.

También se puede observar cómo se mantiene la imagen de cabecera junto con

la barra horizontal de opciones.

Por último, en la parte central de la pantalla se mostrará un texto con información

acerca de la plataforma, y sus beneficios.



Pantalla de Información Personal del Cliente

Ilustración 68 - Diseño wireframe: Visualizar Datos Personales (Parte del Cliente)

En la pantalla de información personal del cliente, se mostrarán todos los campos

introducidos en el formulario de registro, junto con las opciones: ‘Modificar Datos

Personales’ y ‘Dar de baja la cuenta’.

Consultar el catálogo de Paquete Ofertados en la plataforma – Parte del

Cliente

Ilustración 69 - Diseño wireframe: Contratar Paquete (Parte del Cliente)



En esta pantalla se mostrarán las fichas con la información de cada paquete

ofertado en la web, junto con un botón debajo de cada ficha, que permita al cliente

seleccionar el paquete que más se ajusta sus necesidades e ir a la siguiente pantalla

(Formulario de contratación de servicios), haciendo ‘click’ en el botón correspondiente.

Formulario de contratación de servicios

Ilustración 70 - Diseño wireframe: Formulario de Contratación (Parte del Cliente)

Esta pantalla muestra el formulario con toda la información que el ‘Entrenador

Personal’ necesita para poder elaborar la dieta o rutina incluida en un paquete, y que

el cliente podrá contestar rellenando los campos indicados.

Una vez haya rellenado todos los campos, y sean correctos, al pulsar el botón

‘Contratar’ se enviará la petición al ‘Entrenador Personal’



3.4.2. Metáforas

Una metáfora [49] es un mecanismo que nos permite asociar nueva información

con conocimientos que el usuario poseía previamente. Con las metáforas sustituimos

un mensaje que puede resultar complejo para el lector, por otro concepto o imagen

más simple que transfiera a este su significado. Como ejemplo más claro del uso de

metáforas a lo largo de la historia, podríamos citar los jeroglíficos.

Su efectividad está basada en una mejor comprensión global sobre el

funcionamiento de nuestra interfaz, facilitando la asimilación de nuevos conceptos.

Pero para que una metáfora sea realmente eficaz, ha de cumplir una serie de

características [50] muy sencillas:

- Debe ser fácil de comprender.

- No debe existir ambigüedad.

- Debe ser adecuada al público al que se dirige.

A continuación pasamos a ver algunas de las metáforas empleadas en la

realización de este proyecto:

- Visualizar datos de usuario.

- Escribir nuevo mensaje.

- Consultar Listado de Mensajes – Esta opción permite al usuario

consultar el listado de mensajes asociados a cualquier usuario de la plataforma.

- Eliminar elemento - Este botón está asociado a la función eliminar de

cualquier elemento, excepto ‘Eliminar Mensaje’, esto es eliminar: usuarios,

ejercicios, alimentos, paquetes, peticiones, dietas y rutinas.

- Elemento bloqueado – Esta funcionalidad está desactivada.

- Consultar Peticiones – Este botón sirve para consultar el Listado de

Peticiones asociadas a un determinado cliente, tanto las enviadas y sin atender,

como las ya atendidas.



- Consultar Dietas – Este botón sirve para consultar el Listado de Dietas

asociadas a un determinado cliente.

- Consultar Rutinas – Este botón sirve para consultar el Listado de Rutinas

asociadas a un determinado cliente.

- Modificar Datos – Este botón sirve para modificar los datos de los

diferentes tipos de objetos de la aplicación.

- Eliminar Mensaje – Este mensaje sirve para eliminar un determinado

mensaje de la lista de mensajes asociada a un usuario en concreto.

- Leer Mensaje – Este mensaje permite consultar la información de un

mensaje recibido que aparezca en el listado de mensaje de un cliente, para

modificar su estado y marcarlo como leído o no.

- Añadir - Los botones marcados con un signo ‘+’ tienen la función de añadir

un nuevo elemento, del tipo que sea, esto es por ejemplo: añadir nuevo usuario,

añadir ejercicio, añadir alimento, añadir paquete, añadir propósito, añadir

mensaje, etc.

- Modificar – Este botón sirve para modificar los datos de los

diferentes objetos de la aplicación.

- Eliminar Mensajes – La función de este botón en la de

eliminar el listado completo de mensajes asociados a un usuario.

- Atrás – La funcionalidad de este botón es la de redirigir al usuario

a la pantalla anterior.

- Salir – Este es el botón asociado al ‘Logout’ de la aplicación.

Permite cerrar la sesión de usuario abierta en un determinado momento.

- Eliminar Cuenta – Este botón le permite al usuario eliminar

su cuenta de usuario, eliminando además toda la información relacionada con



dicho usuario: datos personales, paquetes contratados, peticiones, dietas,

rutinas y mensajes.



3.4.3. Notificaciones y Mensajes de Error

Todos los elementos descritos hasta ahora, como: diseño wireframe de las

pantallas del usuario, metáforas y estilo de la interfaz, son una representación

bastante real de la comunicación que se va a producir entre el sistema y el usuario

que hará uso de la plataforma, pero otra de las piezas clave que ejemplificarán la

forma de interactuar entre el sistema y los usuarios serán los mensajes de error y las

notificaciones que el primero muestre a estos.

A menudo, los mensajes de error se producen por desconocimiento del

funcionamiento de la plataforma por parte de los usuarios, de modo que a través de

este tipo de avisos, el usuario será capaz de tener una mejor comprensión de la

usabilidad de la misma.

Para que esto sea posible, y el usuario sea capaz de aprender con el uso

reiterado de la plataforma,tanto los avisos como los mensajes de error han de cumplir

una serie de requisitos, como son:

- Han de ser concisos, es decir, cortos y lo más claros posibles.

- El mensaje debe dejar claro qué se pide al usuario, y lo que este debe hacer

para que todo marche correctamente.

- El lenguaje empleado ha de ser amable, a modo informativo.

- No emplear lenguaje excesivamente técnico, por lo que ha de ser natural.

- El formato debe ser diferenciable.

Cuando hablamos de notificaciones o mensajes de error, no sólo estamos

haciendo referencia a mensajes en forma de texto, sino que también podemos incluir

imágenes, sonidos o incluso ventanas de alerta.

Veamos los principales mensajes de error contemplados para este proyecto:

Error en el registro de nuevo cliente: mensaje de error que el sistema muestra

al usuario, en caso de introducir incorrectamente los valores para los campos del

formulario de registro en la plataforma. Como se ve, se indica al usuario la manera en

que debe introducir estos datos:



Ilustración 71 - Datos de registro no válidos

Error en la identificación: mensaje de error mostrado cuando los datos de

acceso a la plataforma son erróneos. Se muestra la opción de retroceder para volver

a introducir los datos correctamente.

Ilustración 72 - Error Identificación

Error al escribir un nuevo mensaje: en este caso se muestra el mensaje de

error que el sistema proporciona a los usuarios en caso dejar el campo contenido en

blanco.

Ilustración 73 - Error al escribir un nuevo mensaje



Error al añadir nuevo usuario: cuando un entrenador utiliza la plataforma para

añadir de manera manual un nuevo cliente, y deja algún campo en blanco, o los datos

de alguno de estos es erróneo, recibe el siguiente error marcado en rojo sobre el

campo erróneo.

Ilustración 74 - Error Añadir Usuario

También podemos obeservar como el sistema advierte al usuario el formato en

que debe introducir el campo email, según el patrón:

[identificadorEmail]@[plataforma].[dominio].

Error al añadir un nuevo propósito: en la siguiente ilustración se muestra otro

de los errores típicos de la plataforma, esto es, cuando la longitud del campo

introducido es superior a la permitida.

Ilustración 75 - Error Añadir Propósito



NOTA: estos mensajes de error son extensibles a las opciones modificar

disponibles para el administrador.

En el capítulo de avisos o notificaciones, durante la realización de este

proyecto se han considerado los siguientes:

Eliminar de forma manual los datos de un usuario: en la siguiente imagen se

puede consultar la ventana emergente que se muestra al usuario (en este caso de tipo

administrador) que el sistema proporcionará cuando haga uso de la opción Eliminar

Usuario. En esta ventana se muestra un pequeño mensaje que advierte al lector que

de pulsar el botón Aceptar eliminará todos los datos asociados al usuario que desea

eliminar, La ventana también muestra dos opciones para cancelar la operación.

Ilustración 76 - Notificación Eliminar Cliente

Eliminar Petición: en este caso, mostramos el aviso recibido cuando un

entrenador hace click sobre la opción Eliminar Petición.

Ilustración 77 - Notificación Eliminar Petición

En general, todos las opciones de eliminar cualquier elemento, tienen asociadas

una ventana emergente de este tipo, en las que se informa al usuario que de pulsar el

botón Aceptar, se eliminarán todos los datos asociados a dicho elemento. Así pues,

en esta categoría tendríamos: Eliminar Mensaje, Eliminar Listado de Mensajes,



Eliminar Usuario, Eliminar Petición, Eliminar Dieta, Eliminar Rutina, Eliminar Paquete,

Eliminar Ejercicio, y Eliminar Alimento.

Respecto de la parte del cliente, comentar que si bien sus funcionalidades son

más limitadas que las del administrador, este también puede recibir una serie de

avisos o mensajes de error. Veamos los más identificativos de este tipo de usuarios.

Eliminar Cuenta de Usuario: cuando un usuario logueado; de tipo cliente,

quiere dar de baja su cuenta de usuario, recibirá el siguiente aviso:

Ilustración 78 - Eliminar Cuenta de Usuario

Mensajes de error al Contratar Paquete: los errores mostrados en el formulario

de contratación de servicios, son los que siguen:

Ilustración 79 - Error Contratar Paquete



Como se puede observar en la ilustración anterior, se muestran los tipos de error

básicos que se pueden dar por el mal uso de la web, como son los campos vacíos o

rangos de valores erróneos.

El último aviso o notificación emergente que vamos a analizar es el que tanto

administradores como clientes comparten, el referido a abandonar la plataforma o

sesión abierta.

Aviso Logout

Ilustración 80 - Aviso Logout

Con toda esta información, disponemos ya de los medios necesarios para hacer

que los usuarios de nuestra plataforma aprendan a utilizar la aplicación a través de

los avisos diseñados.



4. IMPLEMENTACIÓN

En este apartado veremos todo lo relacionado con la fase de implementación del

prototipo de aplicación web que hemos diseñado en el apartado anterior. Para ello en

primer lugar y de manera gráfica, mostraremos el diseño arquitectónico del sistema,

veremos las principales características software y hardware de las que ha de disponer

el sistema para desarrollar una aplicación de este tipo, posteriormente veremos con

detalle el código fuente utilizado durante el proceso, y para finalizar, diseñaremos los

principales casos de prueba del sistema.

4.1. Arquitectura

Con el diseño arquitectónico del sistema, lo que se pretende es mostrar las

diferentes tecnologías y herramientas empleadas durante la realización de este

proyecto, así como representar las relaciones existentes entre estas.

Ilustración 81 – Diseño Arquitectónico del sistema



La imagen anterior muestra el diagrama arquitectónico del sistema, en el que se

pude diferenciar claramente la separación entre el cliente y el servidor.

- La parte del cliente hace referencia a la interfaz de usuario, es decir, la parte

accesible por estos y desde donde se envían todo tipo de peticiones.

Para esta sección se han empleado las siguientes herramientas: framework

BootStrap, HTML5, CSS3, JavaScript o jQuery.

- La parte del servidor hace referencia a la lógica de negocio y es la encargada

de dar respuesta a las peticiones enviadas desde el lado del cliente. Como se

puede apreciar, es la parte encargada de conectar con la base de datos.

Para esta sección las tecnologías utilizadas han sido: framework SpringMVC,

lenguaje de programación JAVA y el servidor de aplicaciones GlassFish, y para

la parte de la BD se ha decidido trabajar con Derby, aunque podrías haberse

elegido otra alternativa en cuanto a motores de bases de datos SQL, como:

MySQL, u Oracle.



4.2. Entorno de Desarrollo

Requerimientos software

Dentro de este apartado, consideraremos todas las necesidades software

mínimas requeridas para ejecutar la aplicación. En este caso:

- Sistema Operativo Windows 7 (64-bit).

- NetBeans IDE 8.0.2.

- Java 8 (Update 31).

- Java SE Development Kit 7 Update 71. (64-bit). (JDK 1.7).

- Navegador Google Chrome versión 42.0.2311.152 m (64-bit).

- NetBeans connector 1.1.2 para enlazar el IDE con el navegador.

- Servidor de Aplicaciones Glassfish v4.1.

- Librerías de Spring Framework 4.0.1.

- Librerías de JSTL 1.2.2.

- Java DB Driver para la BBDD Derby.

- Librerías Spring Security 3.2.5. RELEASE.

- Librerías de Bootstrap v3.3.1 (o superior).

- Conexión a internet establecida.

Requerimientos hardware

Este apartado hace refencia a los requisitos hardware que debe tener la máquina

en la que se ejecuta la aplicación, para poder ejecutarla de manera fluida. Veamos

cuáles son los requerimientos hardware de mi aplicación, bajo mi propia experiencia:

- Procesador: Intel Core i5-2410M o superior. Sistema de 64bits.

- Memoria RAM: DDR3 de 8GB o superior.

- Unidad de allmacenamiento: 500GB (7200 rpm) o superior.

- Interfaz de red: LAN Ethernet Gigabit 10/100/1000 o superior



4.3. Detalles sobre implementación

En esta sección veremos de qué manera se ha implementado la arquitectura y

el diseño del sistema, descritos en apartados anteriores. Para ello, se mostrarán los

aspectos que se han considerado más relevantes de la fase de desarrollo tras el

análisis y diseño del sistema. Se dará muestra de las diferentes tecnologías y

metodologías utilizadas para la implementación del sistema.

Como se ha comentado anteriormente, el prototipo de aplicación web será

desarrollado mediante el lenguaje de programación Java, utilizando para ello el

entorno de programación NetBeans.

En posteriores páginas se irán detallando las tecnologías utilizadas, junto con

fragmentos de código que mostrarán la aplicación de dichas tecnologías a este

proyecto.



4.2.1 Creando una aplicación web en NetBeans

En primera instancia, vamos a explicar los pasos necesarios para crear y

configurar un nuevo proyecto de NetBeans que nos permita desarrollar una aplicación

web bajo el framework de Spring MVC.

Puesto que vamos a crear el proyecto desde el inicio, en nuestra ventana

principal de NetBeans, hacemos click sobre File >> New Project, donde se nos abrirá

una pantalla como esta:

Ilustración 82 - Crear nuevo proyecto

En esta pantalla, seleccionamos la carpeta marcada en el panel izquierdo, Java

Web, y seleccionamos el tipo de proyecto que vamos a desarrollar: Web Application.

Ahora, pulsamos la opción Next >.

En la siguiente pantalla, introduciremos el nombre del proyecto y el directorio

donde se creará este, para poder localizarlo fácilmente y hacer las copias de seguridad

necesarias. Lo vemos en la siguiente imagen:



Ilustración 83 - Nombre y localización del proyecto

Las pantallas que se muestran a continuación nos permiten seleccionar el

servidor que vamos a utilizar (pantalla 3) y la posibilidad de incluir un framework con

el que vayamos a trabajar (pantalla 4). En nuestro caso, el servidor escogido será

GlassFish y el framework que vamos a utilizar Spring Web MVC 4.0.1 incluyendo las

librerías de JSTL.

Ilustración 84 - Selección del servidor y framework

Con esto, ya tenemos preparado nuestro proyecto. ¡¡EMPECEMOS!!



4.2.2 Estilo de la Interfaz Web

En este apartado veremos todo lo relacionado con los estilos utilizados para dar

una apariencia atractiva a la interfaz de la aplicación.

En este caso, se ha utlizado para ello el framework Twitter Bootstrap, puesto

que a parte de tener un diseño bastante intuitivo y fácil de manejar para el usuario, es

de software libre. Este framework nos facilita en un mismo repositorio una serie de

plantillas predefinidas que dan formato a todos los elementos de un sitio web: estilos

de letra, formularios, botones, enlaces, iconos, cuadros de texto, elementos de

navegación, tablas, y otros muchos.

Otra de las características del framework, y que personalmente ha supuesto un

elemento clave para su elección, ha sido que soporta con increíble facilidad la

adaptación del sitio web a diferentes dispositivos y navegadores, algo que conocemos

como web responsive design. En palabras sacadas de la propia web de Bootstrap:

“..para Bootstrap (versión 3), los dispositivos móviles son lo más importante..”.

Para hacer uso de los pluggin relacionados con JavaScript, es necesario incluir

la librería de jQuery en el documento HTML en el que se esté trabajando.

Decimos que Bootstrap es modular, pues basa su personalización en un diseño

a través de rejillas, donde los elementos se disponen mediante filas y columnas. Este

hecho será especialmente importante; como veremos posteriormente, pues nos

permitirá diseñar el layout (o plantilla) de nuestra web, separando el contenido de las

ventanas entre las partes fijas (como barras de opciones, logout, etc.) del contenido

de la página, que variará según vayamos navegando.



4.2.3 Java Server Pages

En este apartado explicaré el uso de la tecnología Java empleada en la creación

de contenido dinámico de la aplicación web, haciendo uso para ello documentos

HTML o XML, entre otros. Este tipo de tecnología se conoce con el nombre de Java

Server Pages, comúnmente identificado con sus siglas JSP.

Los documentos .jsp son básicamente documentos HTML que contienen código

Java, aunque también lo puede hacer de otros tipos: XML, JSON, etc. Mediante el uso

de scripts, este código java nos permite generar el contenido dinámico de nuestro

documento. Para traducir este tipo de documentos y ejecutarlos, es necesario hacer

uso de un servidor web compatible con contenedores servlet, como puede ser Apache

Tomcat o GlassFish (es un servidor de aplicaciones que contiene este tipo de

servidores web compatibles).

Decimos que necesitamos un servidor web compatible con contenedores de

servlets, pues los JSP están estrechamente relacionados con los servlets, mientras

que estos últimos (Servlets) se centran en el procesamiento de peticiones HTTP, los

documentos JSP se centran en el contenido de dicha petición.

Aunque no vamos a entrar en detalles demasiados específicos de la tecnología,

sí que vamos a analizar algunos aspectos que pueden resultar interesantes. Una

página o documento JSP, está compuesto de los siguientes elementos:

- Contenido estático: generalmente código HTML.

- Scriplets o fragmentos de código java: encerrados bajo unas etiquetas

específicas.

- Directivas: las cuáles dan información al contenedor de servlets para indicar de

que manera ha de procesarlas.

- Etiquetas de acción: para redirecciones forzadas, carga de contenido externo,

etc. Se procesan en cada petición.

Del mismo modo, en estos documentos utilizaremos otro lenguaje; Expression

Language (EL), que nos permitirá interactuar con los datos facilitados por el servidor:

accediendo a variables, accediendo a diferentes objetos en distintos ámbitos (sesión,

página, petición o aplicación).



Respecto de la organización del contenido de un documento JSP, o Layout, es

necesario diferenciar tres enfoques:

- Nivel visual: cómo estará organizado el contenido.

- Nivel funcional: qué función va a cumplir cada una de estas partes.

- Nivel semántico: tipo de información con la que se va a trabajar en cada parte.

Esto es fundamental para: garantizar una correcta reutilización del contenido,

fácil identificación de cada elemento, uso adecuado de las reglas de estilo y

accesibilidad, es decir, que un usuario que accede por primera vez (o sucesivas), no

se ‘pierda’ a la hora de navegar por la página.

A continuación, vamos a ver todos estos conceptos aplicados al código o

documentos JSP de este proyecto, detallando las tecnologías presentes en este. El

documento que vamos a ir analizando es el “inicio_admin.jsp” que hace referencia a

la página de inicio, de la sección del administrador (o entrenador personal).

Ilustración 85 - JSP: Cabecera

Analizando la imagen, en primer lugar tenemos dos etiquetas con el formato

<%@taglib.....%>. Con el uso de estas etiquetas, de tipo JSP Standard Tag Library

(JSTL), no estamos generando una salida visible para el usuario, pero sí estamos



indicando internamente en el documento JSP, que se va a hacer uso de las bibliotecas

de etiquetas que ahí se comentan, y que el prefijo con el que se identificará a sus

etiquetas es form y c, en cada caso:

- prefix=”form” : conjunto de etiquetas de formularios.

- prefix=”c” : conjunto de etiquetas core. Comprenden el funcionamiento de

funciones scripts básicas como loops, condicionales, y entrada/salida.

La siguiente etiqueta que aparece es: <%@page contentType=”text/html”

pageEncoding=”UTF-8” %>, e indica al navegador de qué manera ha de procesar la

información.

Las siguientes etiquetas hacen referencia a la organización propia del contenido

de una página HTML. Como vemos, la etiqueta <head></head> que hace referencia

a la cabecera, incluye una serie de etiquetas que nos permiten que la página se

muestre correctamente en diferentes dispositivos móviles, y que el zoom funcione de

manera adecuada. En este bloque de etiquetas están todas las que se indican en la

imagen en el bloque “PROPIEDADES CSS”.

El siguiente bloque, mostrado en la Ilustración 85 - JSP: Cabecera, incluye todas

las etiquetas <script></script> y <link> que nos permiten importar al documento los

siguientes elementos:

- Hojas de estilo del Framework BootStrap.

- Librerías de jQuery: explicaré su funcionamiento más detalladamente en el

siguiente epígrafe de esta memoria.

Por último, vemos un selector de estilo, aplicado a toda la hoja, que da formato

al cuerpo (body) de nuestro documento o página web. Este selector de estilo va

encerrado en la etiqueta <style></style> y el formato que se aplica es: identificador

del bloque de contenido junto a las propiedades que se le quieren dar entre { }

separadas por ; .



Ilustración 86 - JSP: Barra Superior

Esta nueva sección (del mismo documento JSP) hace referencia a la primera

parte de la etiqueta <body></body>, que es el cuerpo de nuestra página o documento

HTML.

En primer lugar, la etiqueta <nav></nav> representa una barra de navegación

horizontal, que según las propiedades que tiene, y como podemos observar en la

imagen, indican que será una elemento fijo situado en la parte superior de nuestra

sección contenido (propiedad navbar-fixed-top). Esta barra superior se mantendrá

fija durante toda la ejecución de la aplicación, y es común para los dos principales

tipos de usuarios existentes en la plataforma.

La etiqueta <div></div>, se emplea para definir un bloque de contenido dentro

de un documento HTML, que en nuestro caso identificará el contenido de la barra

superior de nuestras página. Si nos vamos al cuadro de la imagen con el nombre de

“BARRA SUPERIOR: INFO + LOGOUT” podemos observar que está encerrado bajo

la etiqueta <form..></form> pues este elemento funcionará como un formulario que

nos permitirá enviar una orden al controlador pertinente, concretamente este

formulario está asociado a la funcionalidad Logout o Salir de la Aplicación.



En esta misma etiqueta podemos ver como nuevamente aparecen algunas

reglas de estilo aplicadas a ciertos elementos del documento, como:

- <strong style=”color: white”> </strong> indica que el contenido encerrado

en esta etiqueta tendrá color blanco (white) y además la fuente aparecerá en

negrita (strong).

Otro aspecto a destacar en la imagen anterior, es el uso de las etiquetas de

Expression Language, como aparecen a continución:

- ${usuario.nombre}: el uso de la etiqueta ${ } indica que vamos a acceder al

contenido de la variable encerrada entre las llaves. La separación por puntos,

refleja que accedemos al contenido de un campo determinado dentro de la

variable. En nuestro caso, estaremos accediendo al campo nombre de la

variable usuario.

- ${usuario.rol}: indica que accedemos al campo rol de la variable usuario.

La última etiqueta que podemos observar dentro de nuestro bloque de contenido

<div></div> es un enlace, pues está encerrado bajo la etiqueta <a href=”…”></a>, al

que se le ha dado las propiedades de apariencia de un botón (class="btn btn-danger

btn-sm"). Este será el elemento que funcione como botón para abandonar la

aplicación, y veremos su funcionamiento en el siguiente epígrafe.

La apariencia que esta barra superior tendría en el navegador es la siguiente:

Como vemos, la barra muestra la información de la variable a la que accedemos

con las etiquetas de EL, con el formato indicado, además del botón para Salir de la

aplicación.

Un ejemplo claro de aquello a lo que hacemos referencia cuando hablamos de

diseño responsive, es el último elemento que se muestra en la imagen, el elemento

<button></button>. Este es el botón que aparecerá en pantalla cuando el contenido

de esta sea tan pequeño para no permitir que el contenido de la barra superior (por



ejemplo) puede visualizarse por pantalla. El resultado que obtendríamos en el

navegador, sería el siguiente:

Ilustración 87 - JSP: Botón Responsive

Si desplegamos el botón para dispositivos móviles, vemos como aparece la

misma información que en la barra del navegador, pero adaptado a dispositivos

móviles.

Ilustración 88 - JSP: Barra Superior Responsive

Continuemos con el contenido del documento JSP que estamos analizando.

Ilustración 89 - JSP: Barra de opciones + Imagen



Si analizamos la imagen anterior, lo primero que vemos es una nueva etiqueta

<div></div> para definir un nuevo bloque de contenido. En este caso, está

acompañada del atributo class=”container” lo que nos permite centrar el contenido

de dicho bloque en la pantalla del navegador.

Las siguientes etiquetas son típicas del diseño en rejilla del framework BootStrap,

pues como ya hemos comentado con anterioridad, este framework está diseñado en

filas y columnas. Así pues, tenemos en primer en primer lugar la etiqueta que nos

permite definir una fila (<div class=”row”>) dentro del layout de nuestra página,

seguido de la etiqueta que nos divide esta fila en columnas. En nuestro caso, se ha

decidido añadir una sóla columna, que tenga todo el ancho de la página. El framework

vuestro está diseñado, como hemos dicho, en filas y columnas. Mientras que el

número de filas puede variar, sí que se establece un número máximo de columnas, o

una anchura máxima, por así decirlo. Las columnas del layout de BootStrap podrán

dividirse hasta en 12 columnas. En nuestro caso, esto se ve reflejado en la siguiente

etiqueta:

- <div class=”col-md-12” >: indica que el ‘ancho’ de esta columna estará

ocupado por los 12 fragmentos posibles. Si quisiéramos que en una fila

apareciesen 4 columnas, tendríamos que tener (por ejemplo) cuatro etiquetas

de la siguiente manera definidas: <div class=”col-md-3” >.

El siguiente elemento definido en la imagen es otro de los que permanecerá fijo

durante toda la navegación del administrador por la plataforma. Hablamos de la barra

horizontal de opciones, que en el código la representamos con la etiqueta: <ul

class=”nav nav-pills”>. Cada uno de los elementos que forme esta ‘lista’ vendrá

indicado con una etiqueta: <li….></li> junto a las propiedades que definen su aspecto.

Estos elementos han sido considerados como enlaces, que nos permitirán acceder a

las diferentes funcionalidades de la web.

El uso de la etiqueta: <c:url value=”/Clientes/gestionClientes” />”, disponible

gracias a que, como vimos anteriormente, incluimos la librería de etiquetas core, hace

que forcemos la redirección a dicha URL, cuando un usuario pulse sobre este enlace.

Lo que nos llevará al controlador correspondiente.



Nuevamente, aparece el uso de Expression Language, con el que utilizando las

etiquetas ${usuario.usuario}, ${numPeticiones} o ${numMensajes}, podemos

acceder al contenido de dichas variables.

Todo lo visto hasta ahora, conforma la parte fija de nuestras ventanas de

navegación, es decir, todos aquellos elementos comunes a todas ellas. El contenido

que se verá a partir de ahora, es el que variará en función de la página en la que nos

encontremos.

Para finalizar con el análisis de este documento JSP (“inicio_admin.jsp”),

vamos a ver la inclusión de otro elemento importante en el diseño de contenido

dinámico de nuestra página HTML. La etiqueta: <img src="<c:url

value="/resources/imagenes/images.jpg"/>" class="img-responsive"

width="700" height="250">.

Nos permite insertar una imagen a una página web, cargando dicha imagen de

la URL que indicamos en <c:url../>. El atributo class="img-responsive" se hace

especialmente interesante en este punto, pues es el que nos permite ajustar el tamaño

de la imagen al tamaño de la ventana en la que se muestra, para garantizar un diseño

responsive o ajustable, de la web.

En la siguiente imagen, veremos cuál es el resultado final de la página, tanto en

el navegador, como en la versión móvil.

Ilustración 90 - JSP: Navegador VS Dispositivos Móviles

Como se puede observar, el contenido de la página se ajusta en ambas pantallas

al tamaño de estas.



Otro de los aspectos que me gustaría destacar dentro del apartado destinado a

la programación en el lado del cliente, es el uso de las tablas en JavaServer Pages.

Como el resto de documentos jsp de la aplicación, el archivo gestion_clientes.jsp

está formado por un serie de elementos comunes que no vamos a incluir de nuevo,

como: inclusión de librerías de etiquetas; cabecera de la página, que además de incluir

las etiquetas propias de HTML tiene código JavaScript; barra horizontal fija, barra

horizontal de opciones, y contenido.

Es este último apartado el que vamos a repasar, pues es donde se muestra el

contenido que varía en cada página. En este caso concreto, lo que veremos es como

definimos en lenguaje HTML una tabla, junto con las propiedades específicas del

framework Twitter BootStrap.

Ilustración 91 - JSP: Botón + Clase glyphicon

En 1 podemos observar como introducimos un nuevo elemento típico de este

framework, la clase glyphicon que con la etiqueta class nos permite hacer uso de una

extensa librería de iconos a la que podemos acceder a través de la web de BootStrap

[51].

El siguiente elemento que vamos a analizar recibe el nombre de panel, en el que

hemos incluído una tabla que contendrá el listado de usuarios de la aplicación,

separados por su rol (administradores y clientes), para diferenciar con mayor claridad

las funciones que podemos realizar sobre cada uno de ellos.

A estos paneles y tablas se le han dado las propiedades que proporciona el

framework con el que venimos trabajando, y que nos permite, de una manera sencilla,

dar un aspecto bastante atractivo a nuestra web.



Ilustración 92 - JSP: ProgramaciTablas

Como se puede observar, la imagen muestra un pequeño fragmento del código

en el que se declara una tabla, y se le aplican las características del formato. Además,

realizamos una serie de operaciones sobre las variables recibidas del controlador

ContrClientes haciendo uso para ello de las notaciones de ExpressionLanguage.

En la siguiente imagen, se muestra el resultado gráfico de esta pantalla en el

navegador, en sus versiones para ordenador y dispositivos móviles con el diseño

responsive.



- Fragmento de la versión para el navegador

Ilustración 93 - JSP: Tabla Versión Navegador

- Versión para dispositivos móviles (diseño responsive)

Ilustración 94 - JSP: Tablas Versión Dispositivos Móviles

En esta segunda imagen podemos observar (1) la barra de desplazamiento

horizontal que nos permite navegar por el contenido de la tabla (de manera horizontal)

en la versión de dispositivos móviles.

Con esto, doy por finalizada la parte de programación en la parte del cliente,

gracias a la tecnología JavaServer Pages, y el lenguaje de programación: Java, HTML

y la notación de Expression Language.



4.2.4 Librería de jQuery

Durante la realización de este proyecto, también se ha utilizado jQuery, una

biblioteca de JavaScript que nos permite interactuar con los documentos HTML y

manejar eventos, entre otras funcionalidades.

Como ya hemos visto en la Ilustración 85 - JSP: Cabecera para hacer uso de

estas librerías hemos recurrido a importarlas mediante una redirección a web, por lo

que el uso de conexión de red se hace especiamente importante en este punto, sin

conexión, los elementos que dependan de estas librerías no funcionarán.

También es necesario importar la hoja de estilos correspondiente de BootStrap, que

dará formato a los botones y a los modales.

Veamos un ejemplo sencillo del uso de JavaScript y jQuery, para la generación

de ventanas emergentes (modales en BootStrap [52]), en este caso, para la ventana

que nos permite Salir de la aplicación.En primer lugar, vamos a ver el botón que hará

de enlace con el modal (o ventana emergente).

Ilustración 95 - Botón Modal

El siguiente paso, será crear la ventana emergente que aparecerá cuando el

usuario pulse sobre el botón Salir, en nuestro caso:

Ilustración 96 - jQUERY: Modal para Salir



El siguiente ejemplo que vamos a repasar, introduce un nivel más de

complejidad. Vamos a analizar la ventana emergente que recibe un administrador

cuando pulsa sobre la opción Eliminar Cliente. En primer lugar tenemos el botón que

actúa como enlace con la ventana emergente. Como se puede observar, el atributo

data-target; que es el encargado de decirnos ‘dónde’ se dirige ese enlace, tiene el

identificador #myModal, por lo que en la sección <!—Modales--> de nuestro

documento JSP, tendremos que irnos al que tiene este id.

Ilustración 97 - jQUERY: Botón para Eliminar Cliente

Otro atributo a tener en cuenta dentro de esta imagen, es el que recibe el nombre

de data-id que nos permitirá ‘capturar’ el identificador de usuario del cliente sobre el

que estamos haciendo click. Esto podemos hacerlo, de nuevo, utilizando EL, con la

etiqueta ${c.usuario}, es decir, seleccionamos el atributo usuario de la variable c.

El siguiente fragmento de código, muestra el contenido de la ventana emergente

que se mostrará cuando se pulse en el enlace anteriormente comentado (enlace con

id= #myModal).

Ilustración 98 - jQUERY: Modal para Eliminar Cliente



Como podemos observar en la ilustración anterior, tenemos las tres mismas secciones

que en el modal anterior: cabecera del modal, cuerpo y pie, siendo este último el que

tiene la opción de confirmar la acción que se va a realizar. En este caso, vemos que

el enlace que nos permite Aceptar la operación, <a class=”btn btn-sucess”

id=”btEliminar” role=”button” href=”” /> tiene un atributo llamado id. Este atributo

nos permite enlazar la acción del botón a su correspondiente script de JavaScript, el

que tenga el id = ‘btEliminar’. El código de dicho script es el siguiente:

Ilustración 99 - jQUERY: Script para Eliminar Cliente

Como vemos, se trata de un fragmento de código de tipo JavaScript, (encerrado

con las etiquetas <script></script>), e implementa una función de este tipo. En ella se

define (entre otras) la variable id a la que asignamos el valor recogido anteriormente

en el atributo data-id.

Los pasos desde que el usuario pulsa el botón Eliminar hasta que confirma la

operación serían:

1) El usuario pulsa el botón.

2) Capturamos su id con data-id y mostramos la ventana emergente asociada a

data-target=#myModal.

3) Cuando el usuario pulsa el botón Aceptar del modal, se ejecuta el fragmento

de código JavaScript, haciendo la redirección a la URL que se indica en dicho

código, con el valor concreto de la variable id (identificador del usuario a

eliminar).



4.2.5 Solucionando el problema de los caracteres especiales

Para una correcta visualización y guardado en la BD de información que contiene

caracteres especiales, como tildes, símbolos u otros caracteres especiales, es

necesario incluir un filtro de Spring que fuerce la recodificación de esta información

antes de ser enviada al controlador.

Simplemente se trata de incluir las siguientes entradas al fichero de configuración

de nuestra aplicación, el web.xml:

Ilustración 100 - Codificación UTF-8

4.2.6 Preparando la BBDD

En este apartado [53] veremos los pasos que son necesarios seguir para crear

la base de datos y prepararla para trabajar con ella, es decir, crearemos las tablas,

insertaremos los datos de prueba, etc.

En mi caso, he utilizado Derby, que es una base de datos relacional

implementada íntegramente en Java, disponible bajo licencia Apache v2.0. Derby,

cumple con los estándares JDBC y SQL con los que trabajaremos. Para dar acceso

vía red en arquitecturas cliente/servidor como la nuestra es necesario hacer uso del

driver JDBC org.apache.derby.derby.jdbc.ClientDriver.

A continuación se muestran los pasos necesarios para configurar este tipo de

tecnología.



En primer lugar, tenemos que añadir la librería “Java DB Driver” a nuestro

proyecto de NetBeans. Para ello, haciendo click derecho sobre las propiedades de

nuestro proyecto, iremos a Propiedades>Libraries>Add library.

A continuación, debemos ir a la pestaña ‘Services’ de nuestro asistente de

NetBeans, hacer click en el botón derecho sobre el icono ‘Java DB’ y ‘Create

Database’, como se muestra en la ilustración siguiente:

Ilustración 101 - Create Database

Una vez hecho esto, aparecerá la siguiente pantalla, donde tendremos que tener

cuidado a la hora de introducir la información que ahí se pide, pues será de vital

importancia para posteriormente crear el pool de conexiones y establecer los

parámetros de acceso a la BBDD.

Ilustración 102 - Información BBDD

Como vemos, los datos que se piden son: un nombre para la BD, los datos de

acceso a esta (usuario y contraseña) los cuáles es recomendable rellenar, y por último

un apartado ‘localización’, que será un directorio de nuestro equipo personal donde se



almacenará la BD. Este hecho es importante pues nos permitirá copiar la BD con

posterioridad para darle el uso que deseemos.

Una vez que tengamos estos datos, la base de datos se habrá creado, por lo que

es hora de crear las tablas que compoenen mi aplicación. En este caso, tengo un

documento, con extensión .SQL con las instrucciones DDL (Data Definition

Language), que es el que cargaré desde NetBeans para que el sistema cree todas las

tablas de manera automática. El documento aparece en la siguiente ruta, del directorio

de la aplicación que se adjunta en el CD de esta memoria:

AsesoriaDeportivaWeb\web\WEB-INF\jsp\archivos_sql .

Un ejemplo de cómo se haría la creación de tablas es el que se muestra en la

siguiente página.

* NOTA: no se añaden todas las tablas en esta memoria, pues el sistema dispone

de 11 tablas y su extensión no aportaría gran valor a este documento.

Ilustración 103 - CREATE_TABLE

Como podemos observar, por ejemplo, el segundo create table que se incluye

en la imagen, es el referido a la creación de la tabla Clientes (referente a los



USUARIOS en general de la aplicación). La tabla está formada por 5 columnas o

atributos, siendo el atributo USUARIO la clave primaria de dicha tabla, bajo la

restricción de que no puede ser un campo nulo.

En NetBeans, para ejecutar un archivo SQL, lo que haríamos sería: abrir el

documento + seleccionar todos los CREATE_TABLE que queremos ejecutar, y pulsar

sobre la sguiente opción:

Ilustración 104 - Ejecutar un documento SQL

En la opción connection tenemos que seleccionar la BBDD en la que queremos

ejecutar el documento, y posteriormente pulsar sobre el icono que encontramos al

lado. Además la que se ve en la imagen, será la URL de acceso a la BD de la

aplicación.

Una vez que hemos creado todas las tablas de nuestro sistema, es hora de

insertar todos los datos de prueba que tendrá la aplicación. Como en el caso de la

creación de tablas, la inserción se realizará ejecutando los diferentes archivos que

contienen todos los INSERT o sentencias SQL que nos permiten insertar datos en las

tablas, de la misma forma que se explica para crear las tablas (seleccionar contenido

de cada archivo SQL + seleccionar la BBDD deseada + pulsar sobre el botón de la

imagen anterior).

Otra vez, a modo de ejemplo, veamos el contenido que tendría uno de estos

documentos, en este caso, haremos la inserción de los clientes por defecto de la

BBDD.

Ilustración 105 - Insertar Datos Tabla Clientes



Como se puede observar, se introducen cuatro clientes por defecto, de los que

el USUARIO con id de usuario = ‘ara00012’ es el único administrador de la plataforma,

siendo el resto usuarios de tipo cliente.

Para ‘preparar’ todas las tablas (insertar todos sus datos), deberíamos repetir

este proceso con todos los documentos asociados a cada tabla de la BBDD que

requiere de datos de prueba (pues algunas de las tablas no requieren de datos por

defecto, sino que se van rellenando conforme avanza el uso de la aplicación). Las

tablas que sí necesitan algún dato por defecto son: Clientes, Paquetes, Propósitos,

Alimentos y Ejercicios.

4.2.7 Conectando con la BBDD

En este apartado [53], veremos todo lo referente a la creación del Pool de

Conexiones a la BD [54]. Puesto que el proceso de apertura y cierre de una conexión

a BD es a menudo lento, y consume demasiados recursos, y además, muchos

usuarios puden intentar acceder a la BD con los mismos datos de acceso a la misma,

sería conveniente poder reutilizar estas conexiones. Un pool de conexiones plantea

una solución a este problema, proporcionando a los clientes de la BD un conjunto

determinado de conexiones que se reutilizan contiuamente, lo que mejora

notablemente el consumo de recursos para el acceso y cierre a la BD. Este pool de

conexiones será gestionado por un contenedor de Servlets, de manera que la

aplicación web sólo deberá conectarse con este para, a través de objetos de tipo

DataSource, solicitar la conexión al pool de conexiones.

Como ya se ha comentado, utilizaremos el servidor de aplicaciones GlassFish,

por lo que para configurar nuestro pool de conexiones en este servidor, tendremos

que acceder a la URL del navegador: localhost:4848/common/index.jsf y desde

esta pantalla acceder a: JDBC>JDBC Connection Pools y seleccionar “New..”.

Como datos obligatorios a introducir a la hora de crear un pool de conexiones,

tenemos el nombre, y no es obligatorio aunque sí conveniente introducir el tipo de

recurso (resource type), donde debemos seleccionar javax.sql.DataSource. Pero es

en la pestaña de propiedades adicionales en las que configuraremos el pool de

conexiones.



La siguiente imagen muestra esta ventana:

Ilustración 106 - JDBC Connection Pool

Este pool de conexiones también lo podemos modificar con el siguiente

documento (con extensión XML) que tenemos en la carpeta “Server Resources” de la

raíz de nuestro proyecto. Aquí podemos observar toda la información relacionada con

el nombre de la BD, servidor al que accede, puerto de la BD, información de acceso a

la BD, etc.

Ilustración 107 - glassfish-resource.xml



Para poder acceder a este pool de conexiones desde nuestra aplicación web,

sólo tendremos que crear objetos de tipo DataSource que vendrán referenciados con

el campo jndi-name=”jdbc/tfg”.

Para indicar a Spring que instancie el objeto DataSource asociado al pool de

conexiones que acabamos de crear, es necesario modificar el documento de

configuración de Spring: /WEB-INF/applicationContext.xml, como podemos ver en

la siguiente ilustración.

Ilustración 108 - Instancia del objeto asociado al Pool de Conexiones

4.2.8 Creando las clases de la aplicación

El siguiente paso que vamos a dar, va a ser el de crear las clases.java de

nuestro sistema. Para cada una de estas clases crearemos lo constructores

necesarios y los métodos GET y SET que nos permitirán posteriormente trabajar con

las operaciones de cada una de estas clases, en los controladores de nuestro sistema,

a través de la inyección de dependencias. En mi caso, no he necesitado de

operaciones adicionales, así que este es el resultado.

Como muestra, vamos a estudiar la clase Cliente.java que hace referencia a un

USUARIO en general de la plataforma. Veamos el código asociado a esta clase:



Ilustración 109 - Declaración de la clase Cliente – Atributos

En la imagen podemos observar como se declara la clase que será de tipo

pública, además de los atributos que componen dicha clase. En nuestro caso, la clase

Cliente está formada por cinco atributos, todos ellos de tipo String (cadena de

caracteres).

Ilustración 110 - Constructores de la clase Cliente

El siguiente fragmento, hace referencia a los métodos GET y SET de la clase.

Métodos que nos permitirán trabajar; como se ha dicho anteriormente, con estas

operaciones en los controladores.



Ilustración 111 - Métodos GET y SET de la clase Cliente

4.2.9 Validación de los datos de formulario

Llegados a este punto, lo que haremos será asociar los datos enviados a través

de un formulario [53], a un bean en el modelo, con el fin de realizar una validación de

las propiedades de un objeto, utilizando para ello el API de validación de beans JSR-

303/349. Para realizar esta función, con la versión del servidor que estamos utilizando,

GlassFish v4.0.1 no es necesario añadir ningún tipo de librería adicional al proyecto.

En primer lugar, lo que vamos a hacer es crear una serie de anotaciones sobre

las atributos de cada una de las clases de nuestra aplicación, cuyos valores o formato,

queremos restringir. En nuestro caso, estableceremos restricciones respecto de la

posibilidad o no de introducir un valor nulo en un campo, su longitud, valor mínimo y

máximo, o patrón a la hora de introducir un determinado valor. Estas restricciones, a

parte de ayudarnos a controlar los valores que un usuario puede introducir en los

formularios, nos sirven para limitar el tamaño de estos datos a la hora de introducirlos

en la BD.



En primer lugar, es preciso incluir a la clase una serie de librerías que nos

permiten utilizar estas anotaciones. Veamos además las restricciones que se han

considerado para la clase Cliente.java:

Ilustración 112 - Anotaciones para los Beans

Para personalizar los errores que queremos que se muestren cuando se

inclumple una de estas restricciones, es necesario crear un nuevo paquete en el

directorio Source Packages, de nuestro proyecto de NetBeans, en el que incluiremos

el archivo que contendrá todos los mensajes de error personalizados.

Los mensajes de error, asociados a la clase Cliente.java son los siguientes:

Ilustración 113 - Mensajes de error personalizados para la clase Cliente

Para indicar que es de este archivo de donde el sistema debe cargar estos

mensajes de error, tenemos que añadir la siguiente etiqueta al archivo dispatcher-

servlet.xml de nuestro proyecto:



Ilustración 114 - Importar fichero de mensajes personalizados

Como se puede observar, estos mensajes de error personalizados, se

encuentran en el archivo messages dentro del directorio msg.

El siguiente paso que vamos a dar será analizar el controlador ContrClientes

(a modo de ejemplo, ya que el proceso es el mismo para todos los controladores), en

el que veremos como conseguimos que estos reciban objetos de tipo bean con las

propiedades asociadas a cada campo del formulario.

Ilustración 115 - Validación de datos ContrClientes

En 1 podemos observar el uso de la anotación @ModelAttribute(“variable”),

que nos permite, entre otras cosas, recibir un objeto introducido desde un formulario.

Si el objeto ya existe o lo recibimos desde un formulario, recupera su información y se

la asigna al parámetro al que esté asociado. Si es la primera vez que se accede a él,

se crea un objeto del tipo que corresponda y le asigna los valores por defecto que se

hayan establecido, y se pasa el ModelMap al formulario. En nuestro caso, el

@ModelAttribute está asociado a un dato de tipo Cliente, por lo que la variable “cliente”

dentro de este, será de ese tipo.



Este mismo cuadro, muestra el uso de la anotación @Valid que asociado a un

bean determinado, permite a Spring MVC realizar una validación automática de los

datos enviados por el formulario. La variable result de tipo BindingResult nos permite

comprobar si han ocurrido errores de validación a la hora de implementar el método,

antes de pasarle estos al DAO para su posterior almacenamiento.

Como vemos en el cuadro marcado con un 2, hacemos uso de una de las

operaciones propias de este tipo de validación de datos, para comprobar si los datos

recibidos a través de result tienen errores de validación o no. En este caso, si no hay

errores, se mandan los datos al DAO (clienteDAO) para que cree un nuevo usuario, y

seguidamente hacemos una limpieza de la variable model. Si por el contrario, existen

errores de validación, hacemos una redirección a la vista del formulario, pero esta vez,

mostrando los errores personalizados, que habíamos definido anteriormente.

Vemos como se muestran estas situaciones de manera gráfica:

Ilustración 116 - Formulario + Errores

Como se puede apreciar en 1, hacemos uso de la etiqueta <form:errors /> que

nos permite mostrar los errores asociados a la validación de propiedades de un

determinado bean, según los datos recibidos de la variable result en el controlador.



Por último, en la próxima página, veremos como se mostrarían estos mensajes

de error en el formulario de alta de nuevo usuario de la parte del administrador de la

plataforma:

Ilustración 117 - Errores de formulario

Como se puede observar, sobre cada campo o propiedad que incumple alguna

de las restricciones que habíamos establecido, se muestra un mensaje de error (de

los que habíamos definido en nuestro archivo messages.properties) con el formato

indicado en el formulario de la imagen Ilustración 116 - Formulario + Errores.



4.2.10 Creación de los Objetos de Acceso a los Datos (DAO’s)

Cuando hablábamos de la arquitectura de la aplicación web en base al patrón de

diseño MVC, veíamos el valor de separar los detalles del modelo y del acceso a los

datos del sistema de la lógica de control de este. Es por ello que recurrimos a los

Objetos de Acceso a Datos [53], conocidos como DAO’s, para que manejen los

detalles de acceso a la BD.

A la hora de diseñar un DAO, es importante separar la interfaz de uso del DAO,

de la implementación de cada una de las funciones que conforman este DAO. Así

pues, esta interfaz contendrá la declaración de los métodos básicos del CRUD de una

determinada clase, y a partir de esta interfaz construiremos las clases específicas para

cada uno de los DAOs asociados a una entidad del sistema.

Para cada uno de nuestros DAO’s tendremos tres archivos: interfaz genérica del

DAO, interfaz específica de la clase e implementación del DAO. Para verlo con mayor

claridad, vamos a analizar el DAO referido a los CLIENTES (USUARIOS) de nuestra

aplicación.

- INTERFAZ GENÉRICA DEL DAO CLIENTES

Ilustración 118 - Interfaz Genérica del DAO Clientes



- INTERFAZ ESPECÍFICA DE LA CLASE CLIENTE

Ilustración 119 - Interfaz Específica del DAO Clientes

- IMPLEMENTACIÓN DE LA CLASE CLIENTEDAOJDBC

En primer lugar repasamos la cabecera del documento, en la que como se puede

observar en la imagen aparecen el nombre del paquete, clases de JAVA importadas

y otras librerías importadas.

Ilustración 120 - Cabecera ClienteDAOJDBC

Lo siguiente que hacemos, es simplificar el código del constructor de la clase

ClienteDAOJDBC y añadir una anotación @Repository, para que Spring pueda

localizar e instanciar esta clase de forma automática.

Ilustración 121 - Consultas y Modificaciones de la clase ClienteDAOJDBC



A continuación, tenemos que inyectar o hacer referencia al pool de conexiones,

y convertir la entidad que gestiona el DAO desde el repositorio donde se almacena

(un registro de una tabla en nuestro caso) a un objeto del modelo de datos, es decir,

tenemos que hacer un mapeo de estos datos.

Ilustración 122 - Mapeo de datos

Por último, sólo nos quedaría implementar los métodos que hemos definido en

la interfaz genérica de la clase GenericDAO. A modo de ejemplo, vamos a analizar

una de estas operaciones implementadas que represente algún valor para el presente

documento.

Ilustración 123 - Implementación del método CREA

* NOTA: En esta memoria no se va a añadir la implementación de todas las

operaciones de todas las entidades del sistema, pues no aportaría gran valor al

documento. Esta información está disponible en el proyecto adjunto a esta memoria.



4.2.11 Autenticación y autorización a la appweb

Para la autenticación y autorización del sistema se ha recurrido a Spring Security.

Para configurar nuestra aplicación según sus parámetros, lo primero que tenemos que

hacer es descargar una serie de librerías, las cuáles hay que añadir al proyecto

existente de NetBeans, y que se muestran a continuación.

Ilustración 124 - Librerías de Spring Security

Estas librerías se encuentran disponibles en el repositorio de Spring Security de

la plataforma GitHub, disponible en [55].

Para añadir estas librerías al proyecto de Netbeans, tenemos que hacer click con

el botón derecho sobre el icono de este, Properties, y desde aquí iremos a la opción

Libraries:

Ilustración 125 - Añadir Librerías de Spring Security



Acto seguido, hemos de configurar el archivo web.xml de nuestro proyecto, para

indicar que el procedimiento a seguir en cuanto a la seguridad de nuestra aplicación

se hará a través de Spring Security.

Ilustración 126 – Configuración de Spring Security en web.xml

El documento que realmente dará forma a la configuración de Spring Security es

el archivo security.xml. En primer lugar, tenemos que indicar qué librerías va a utilizar

el documento:

Ilustración 127 - Configurando Spring Security

El siguiente paso, será indicar qué tipo de seguridad vamos a utilizar, en nuestro

caso, seguridad por formulario de login. Para indicar esto, tenemos que insertar las

siguientes entradas al documento:



Ilustración 128 - Seguridad a través de formulario

Como indica la etiqueta, la seguridad se realizará a través de un formulario de

login (form-login), siendo la página de este formulario la que contiene la ruta “/login”,

la ruta por defecto será “/main”, y la página de error en el formulario de login la que

contenga la ruta “/loginError”. Para el logout o cierre de sesión, se borrarán las

cookies (delete-cookies), y se invalidará la sesión abierta (invalidate-session),

produciéndose además una redirección a la base de la aplicación (logout-success-

url).

¿Pero como sabe la aplicación qué campos servirán para realizar el LOGIN ?

Para este fin, tenemos que configurar, en este mismo documento, de dónde debe el

sistema coger las credenciales necesarias. Puesto que nosotros ya disponemos de

una tabla Clientes (referente a los USUARIOS en general de la aplicación), las

credenciales de acceso al sistema las cogeremos de aquí. Como veíamos

anteriormente, la tabla está compuesta de una serie de campos de los cuáles haremos

uso de los siguientes: usuario, rol y password. Para el formulario de autenticación

utilizaremos el usuario y password, cosa que indicamos de la siguiente manera:

Ilustración 129 - Autenticación al sistema

Como podemos comprobar, en primer lugar lo que hacemos es indicar el pool

de conexiones que vamos a utilizar para acceder a los datos de la BD con data-

source-ref=”dataSourceBean”. En la siguiente línea: users-by-username-query:

indicamos los datos que vamos a necesitar para el login, campos (usuario,

password) y tabla (Clientes). Por último, authorities-by-username-query, indica el

rol de cada uno de los usuarios que accederá al sistema: administrador

(ROLE_ADMIN) o cliente (ROLE_USER).



Lo siguiente que vamos a ver es el formulario al que hacemos referencia, y que

servirá de acceso a la plataforma. Este formulario, se encuentra en el archivo

index.jsp, y tiene el siguiente formato:

Ilustración 130 - Formulario de Login

Para hacer la redirección a una sección u otra del sistema, dependiendo del rol

del usuario que accede al sistema, tenemos que analizar el controlador encargado de

ello, en nuestro caso, LoginController:

Ilustración 131 - LoginController



Las restricciones que tiene el sistema, en función del rol, es necesario indicarlas

en el archivo security.xml y en mi caso, se ha decidido establecer las siguientes:

Ilustración 132 - Restricciones en función del rol

Lo último que tenemos que hacer, en cuanto a la configuración de Spring

Security se refiere, es importar el archivo security.xml al applicationContext.xml:

Ilustración 133 - Importar security.xml al applicationContext.xml



4.2.12 Controladores de Spring

En esta sección veremos cómo se crean los controladores específicos de Spring

[56]. Todo esto lo vamos a ir analizando con imágenes, que contendrán las

explicaciones necesarias para entender el proceso.

Como hasta ahora, vamos a analizar el controlador relacionado con los Clientes

(USUARIOS) de la aplicación. El resto está disponible en la documentación adjunta.

Ilustración 134 - Controlador Clientes: Cabecera

El fragmento de código en el que se incluyen otras librerías con las que se

trabaja, ha sido obviado pues no aporta gran valor a la explicación.

Ilustración 135 - Controlador Clientes: Inyección de los DAOs



La siguiente imagen muestra dos funciones que al estar situadas en la anotación

ModelAttribute están compartidas por todas las funciones del controlador. Esta

anotación permite recuperar un valor existente en el ModelMap. Ambas funciones nos

permiten contabilizar el número de mensajes sin leer y peticiones pendientes de un

usuario, en este caso el usuario logueado como así indica la función

principal.getName().

Ilustración 136 - Controlador Clientes: ModelAttribute

A continuación, crearemos dos métodos que nos permitirán por un parte

visualizar el formulario con el que podremos dar de alta un nuevo usuario a la

plataforma, y por otra, recibir los datos enviados a través de dicho formulario.

Ilustración 137 - Controlador Clientes: métodos GET y POST de Añadir Cliente

En este caso, utilizamos la anotación @RequestMapping, para asignar a cada

método una petición distinta, dependiendo del tipo de petición utilizada: GET, en el

primer caso, y POST en el segundo.



Como vemos en la imagen anterior, el primero de los casos está asociado a una

petición de tipo GET, que lo que hace simplemtente es redirigirnos a la vista /WEB-

INF/jsp/admin/usuarios/clientes/add_cliente.jsp donde se mostrará el formulario

que permite a un administrador dar de alta de forma manual a un nuevo usuario.

El segundo de los casos está asociado a una petición de tipo POST, en la que

una vez que el usuario pulse el botón enviar del formulario, se envían los datos a esta

petición.

Una vez que el controlador recibe los datos comprueba que estos son correctos

(condicional if que se ve en la imagen). De ser así, el controlador llama a la función

crea del DAO clienteDAO, pasándole los datos recibidos en la variable cliente que

será de tipo Cliente del @ModelAttribute. Cuando haya terminado redirige al usuario

a la URL que indica la variable view.

4.2.13 Inyección de dependencias en Spring

Aunque ya hemos dado pequeñas pinceladas de lo que significa este concepto

y cómo y para qué se utiliza, en este apartado vamos a explicarlo con un poco más

de detalle.

La inyección de dependencias de Spring [53] es posiblemente una de las

particularidades más reseñables de su core. Básicamente se trata de cargar las

propiedades de los beans a través de sus constructores o sus métodos de tipo SET

(setters) justo cuando iniciamos la aplicación. En otras palabras, con la inyección de

dependencias lo que conseguimos es que en lugar de ser las clases las que crean los

objetos con los que van a trabajar, estos objetos los inyectamos mediante sus métodos

set y constructores en el momento en que se crea dicha clase. De esta forma evitamos

tener que crear los objetos cada vez que los necesitamos, y podemos reutilizarlo

siempre que queramos.

Spring dispone de un contenedor que es el encargado de gestionar esta

inyección de dependencias según se quiera, ya sea a través de un documento de

configuración XML o a través de anotaciones.



En la práctica, vamos a ver un ejemplo sobre el controlador de dietas

(ContrDietas.java), en el que primero crearemos una referencia a los DAOs que este

controlador utiliza, y la inyección de dependencias de Spring para hacer uso de dichos

objetos.

En la siguiente imagen podemos observar el uso de anotaciones (@Autowired)

para inyectar un DAO en un controlador.

Ilustración 138 - Controlador Dietas + Inyecciones

Ahora, para localizar el DAO correspondiente, Spring hará uso de las

anotaciones que hemos incluido en la imagen anterior, y buscará la que ‘case’

(coincida) con el DAO buscado, como vemos en la siguiente imagen, que hace

referencia a la clase paqueteDAOJdbc (por ejemplo).



Ilustración 139 - PaqueteDAOJDBC

Como observamos, el uso de la anotación @Component permite a Spring hacer

referencia a este DAO, e inyectarlo en el controlador que haga uso de él.

A modo de ejemplo, para visualizar el listado de Dietas asociadas a un

determinado cliente, necesitamos obtener todas las dietas del DAO correspondiente,

para así poder pasárselos a la vista. La siguiente ilustración muestra el método del

controlador ContrDietas que se encarga de acceder a la operación del DAO

dietaDAOJDBC que nos devuelve el listado de dietas asociadas a un cliente.

Información que obtenemos de la BD Dietas a través de una sencilla consulta SQL.

Ilustración 140 - Función Ver Dietas del Controlador de Dietas

Si analizamos la imagen, vemos que en 1 con la anotación @RequestMapping

lo que hacemos es capturar la URL que contenga por una parte la ruta del controlador

/Dietas + /verDietas/{user}. El uso de {user} hace referencia al valor de dicha variable

que capturamos en 2 con el uso de la anotación @PathVariable. En este mismo

punto, se produce una asignación implícita en la que asigna dicho valor a la variable

cliente de tipo String, en la que se almacena el identificador de usuario del cliente del

que queremos consultar el listado de dietas.

En 3, lo que hacemos es hacer uso de la operación buscaUsuario del DAO

clienteDAO, para buscar los datos del usuario que nos pasan en el string (cadena de

caracteres) ‘cliente’. Toda esta información la almacenamos en la variable “cliente” del

ModelMap a través de model.addAttribute. Con esto lo que conseguimos es pasarle

esta información a la vista.



En 4 declaramos una variable dietas que es de tipo lista, que contiene datos de

tipo Dieta. A través de una simple consulta a la BD, lo que hacemos es guardar en

esta lista de dietas, cada una de las dietas asociadas al cliente que le pasamos como

parámetro a la función buscaDietasCliente. Nuevamente esta información la

almacenamos en la variable model que nos permite compartir esta información con la

vista, como podemos ver en el punto 5.

La función del DAO DietaDAOJDBC que nos permite lanzar la consulta a la BD

es la siguiente:

Ilustración 141 - Función verDietasCliente

La consulta SQL que lanzamos es la siguiente: SQL_BUSCADIETASCLIENTE

= "SELECT * FROM Dietas INNER JOIN Peticiones ON Dietas.idPeticion =

Peticiones.idPeticion AND Peticiones.origen = ? ORDER BY dietas.idDieta".



4.4. Diseño de los Casos de Prueba

¿En qué consisten los casos de prueba [57]? Cuando hacemos referencia al

término Prueba del Software hablamos de aplicar a nuestro sistema una serie

mecanismos con los que probar que efectivamente cumple con los requisitos que se

le piden, con el fin de hallar posibles errores en la programación del mismo.

A través de estas pruebas será posible resolver gran parte de estos errores de

software. También es preciso señalar que este proceso de prueba no debe acabar

nunca, es decir, no debe existir una etapa dentro del desarrollo de software en la que

una vez testeadas unas pruebas determinadas, el proceso finalice, sino que el sistema

debe estar en continua prueba. En este sentido, la labor de probar de la aplicación

pasa del ingeniero al usuario final de la misma.

Los casos de prueba que llevaremos a cabo serán a un nivel muy general, es

decir, serán errores orientados a posibles acciones erróneas del usuario y si el sistema

responde satisfactoriamente a estos errores, mostrando para ello los mensajes de

error correspondientes y de manera que queden claros para que el usuario trate de

no volver a cometerlos.

Este tipo de pruebas se conocen con el nombre de pruebas de caja negra, y

están dirigidas a verificar los requerimientos funcionales del software. Entre los errores

que se pretenden localizar tenemos: errores en la interfaz de usuario, errores en la

validación de datos de los formularios, errores en la identificación de los usuarios,

funcionalidades olvidadas, errores en las redirecciones o errores de comportamientos

extraños de la aplicación.

En resumidas cuentas, lo que una prueba de caja negra pretende demostrar es

que las entradas son aceptadas de forma correcta por el sistema, y este a su vez

muestra una salida correcta.

Definimos una clase de equivalencia como un conjunto de estados para los que

una condición de entrada es válida o no. De este modo, mínimo tendría dos clases de

equivalencia para un mismo caso de uso: una clase de equivalencia válida (para la

que según unos valores determinados la condición de entrada es correcta) y una clase



de equivalencia inválida (para la que según un conjunto de valores de entrada

erróneos la condición muestra un fallo del sistema).

Para cada caso de uso, vamos a analizar el comportamiento del sistema para

sus clases de equivalencia válida e inválida. En realidad deberían comprobarse todas

las posibles clases de equivalencia para cada uno de los casos de uso del sistema,

pero como la extensión del mismo es demasiado amplia, sólo vamos a comprobar

aquellas en las que el sistema funciona de manera esperada, y las que lo llevan a

error.

Situación Comportamiento del sistema ¿Testeado?

RF-01 – Registro de Usuario

Datos correctos

El sistema muestra una imagen confirmando que el usuario ha sido creado

con éxito y lo redirige al formulario de acceso a la plataforma SÍ

Datos erróneos

El sistema redirige al usuario a una página de error, en la que muestra las pautas a seguir para registrarse correctamente SÍ

RF-02 – Identificación de Usuario

Datos correctos

El sistema redirige al usuario a la página de inicio correspondiente, dependiendo del

tipo de rol asignado SÍ

Datos erróneos

El sistema redirige al usuario a una página de error y le muestra un mensaje diciendo

que los datos no se han encontrado SÍ

RF-03 – Escribir Mensaje Usuario

Datos correctos

El sistema envía el mensaje al destinatario, y redirige al usuario al listado de mensajes SÍ

Datos erróneos El sistema muestra un mensaje de error, de

color rojo, sobre el campo(s) erróneo(s) SÍ

RF-04 – Consultar Listado de Usuarios

Existen usuarios

El sistema muestra al administrador el listado de usuarios existentes en la

plataforma, separando entre administradores y clientes, junto a las opciones sobre cada tipo de usuario SÍ

No existen usuarios

El sistema muestra al administrador un mensaje indicando que no hay usuarios

disponibles además de la opción de añadir uno nuevo SÍ



RF-05 – Añadir Nuevo Usuario

Datos correctos

El sistema crea una nueva cuenta de usuario con los datos introducidos y

redirige al administrador al listado de usuarios SÍ



RF-06 – Modificar Datos de Usuario

Datos correctos

El sistema actualiza los valores modificados y redirige al administrador a la ventana de

información personal del cliente SÍ



RF-07 – Eliminar Usuario

Aceptar operación

El sistema elimina todos los datos asociados al usuario eliminado y redirige al

administrador al listado de usuarios SÍ

Cancelar operación

El sistema cancela la operación, manteniéndose en la misma pantalla SÍ

RF-08 – Visualizar Datos de Usuario

El usuario existe

El sistema redirige al administrador a la página con la información personal del

usuario seleccionado SÍ

El usuario no existe

El sistema muestra el formulario de información del usuario en blanco SÍ

RF-09 – Consultar Mensajes de Usuario

Existen mensajes

El sistema muestra el listado de mensajes asociados al usuario seleccionado SÍ

No existen mensajes

El sistema muestra en mensaje indicando que nos existen mensajes asociados a dicho usuario, junto con la opción de escribir un

nuevo mensaje SÍ

RF-10 – Eliminar Listado de Mensajes asociados un usuario Aceptar

operación

El sistema elimina el listado de mensajes asociados a dicho usuario y redirige al

administrador a la pantalla del listado de mensajes pero vacía SÍ



Cancelar operación


RF-11 – Eliminar Mensaje

Aceptar operación

El sistema elimina el mensaje seleccionado y redirige al administrador a la pantalla del

listado de mensajes SÍ

Cancelar operación


RF-12 – Modificar Mensaje

Datos correctos

El sistema actualiza el estado del mensaje y redirige al usuario al listado de mensajes SÍ

Datos erróneos No existe opción de que los datos sean

erróneos SÍ

RF-13 – Consultar Listado de Peticiones de un Cliente

Existen peticiones

El sistema mostrará al usuario el listado de peticiones enviadas por el cliente

seleccionado SÍ

No existen peticiones

El sistema muestra un mensaje indicando que no existen peticiones enviadas por el

cliente seleccionado SÍ

RF-14 – Consultar Listado de Dietas de un Cliente

Datos correctos

El sistema mostrará al usuario el listado de dietas asociadas al cliente seleccionado SÍ

Datos erróneos

El sistema muestra un mensaje indicando que no existen dietas asociadas al cliente

seleccionado SÍ

RF-15 – Consultar Listado de Rutinas de un Cliente

Datos correctos

El sistema mostrará al usuario el listado de rutinas asociadas al cliente seleccionado SÍ

Datos erróneos

El sistema muestra un mensaje indicando que no existen rutinas asociadas al cliente

seleccionado SÍ



RF-16 – Eliminar Petición

Aceptar operación

El sistema eliminará los datos de la petición seleccionada SÍ

Cancelar operación


RF-17 – Eliminar Dieta

Aceptar operación

El sistema eliminará los datos de la dieta seleccionada SÍ

Cancelar operación


RF-18 – Eliminar Rutina

Aceptar operación

El sistema eliminará los datos de la rutina seleccionada SÍ

Cancelar operación


RF-19 – Eliminar Petición

Aceptar operación

El sistema eliminará los datos de la petición seleccionada SÍ

Cancelar operación


RF-20 – Consultar Listado de Ejercicios

Existen ejercicios

El sistema mostrará al administrador el listado de ejercicios disponibles en la

plataforma junto con las operaciones sobre cada ejercicio SÍ

No existen ejercicios

El sistema mostrará un mensaje indicando que no existen ejercicios, junto con la opción de añadir un nuevo ejercicio SÍ

RF-21 – Consultar Listado de Alimentos Existen

alimentos

El sistema mostrará al administrador el listado de alimentos disponibles en la

plataforma junto con las operaciones sobre cada alimento SÍ



No existen alimentos

El sistema mostrará un mensaje indicando que no existen alimentos junto con la opción de añadir un nuevo alimento SÍ

RF-22 – Consultar Listado de Paquetes

Existen paquetes

El sistema mostrará al administrador el listado de paquetes disponibles en la

plataforma junto con las operaciones sobre cada paquete SÍ

No existen paquetes

El sistema mostrará un mensaje indicando que no existen paquetes junto con la opción de añadir un nuevo paquete SÍ

RF-23 – Añadir Nuevo Ejercicio

Datos correctos

El sistema añade el nuevo ejercicio a la plataforma y redirige al administrador al

listado de ejercicios SÍ



RF-24 – Añadir Nuevo Alimento

Datos correctos

El sistema añade el nuevo alimento a la plataforma y redirige al administrador al

listado de alimentos SÍ



RF-25 – Añadir Nuevo Ejercicio

Datos correctos

El sistema añade el nuevo ejercicio a la plataforma y redirige al administrador al

listado de ejercicios SÍ



RF-26 – Añadir Nuevo Paquete

Datos correctos

El sistema añade el nuevo paquete a la plataforma y redirige al administrador al

listado de paquetes SÍ





RF-27 – Añadir Nuevo Propósito

Datos correctos

El sistema añade el nuevo propósito a la plataforma y redirige al administrador al

listado de paquetes SÍ



RF-28 – Modificar Alimento

Datos correctos

El sistema actualiza los valores modificados y redirige al administrador al listado de

alimentos SÍ



RF-29 – Modificar Ejercicio

Datos correctos


ejercicios SÍ



RF-30 – Modificar Paquete

Datos correctos


paquetes SÍ



RF-31 – Eliminar Alimento

Aceptar operación

El sistema elimina el alimento seleccionado y redirige al administrador al listado de

alimentos SÍ

Cancelar operación


RF-32 – Eliminar Ejercicio Aceptar

operación

El sistema elimina el ejercicio seleccionado y redirige al administrador al listado de

ejercicios SÍ



Cancelar operación


RF-33 – Eliminar Paquete

Aceptar operación

El sistema elimina el paquete seleccionado y redirige al administrador al listado de

paquetes SÍ

Cancelar operación


RF-34 – Consultar Listado de Alimentos asociados a una Dieta

Existen alimentos asociados a la dieta

El sistema muestra el listado de alimentos asociados a la dieta seleccionada SÍ

No existen alimentos asociados a la dieta No existe posibilidad de este caso SÍ

RF-35 – Consultar Listado de Ejercicios asociados a una Rutina

Existen ejercicios asociados a la rutina

El sistema muestra el listado de ejercicios asociados a la rutina seleccionada SÍ

No existen ejercicios asociados a la rutina No existe posibilidad de este caso SÍ

RF-36 – Ver Alimento

Existe el alimento

El sistema muestra la información o valor nutricional del alimento seleccionado SÍ

No existe el alimento

El sistema muestra el formulario de información del alimento en blanco SÍ

RF-37 – Logout (Salir de la aplicación)

Aceptar operación

El sistema cierra la sesión abierta y redirige al usuario a la pantalla de bienvenida a la

aplicación SÍ

Cancelar operación




RF-38 – Consultar Listado de Peticiones Sin Atender

Existen peticiones sin atender

El sistema muestra el listado de peticiones sin atender, ordenadas por orden de

llegada, junto con la opción de consultar la información de cada una de ellas SÍ

No existen peticiones sin atender

El sistema muestra un mensaje indicando que no existen peticiones pendientes SÍ

RF-39 – Consultar Listado de Mensajes Sin Leer

Existen mensajes sin leer

El sistema muestra el listado de mensajes sin leer ordenados por orden de llegada,

junto con la opción de consultar la información de cada uno de ellos SÍ

No existen mensajes sin leer

El sistema muestra un mensaje indicando que no existen mensajes sin leer SÍ

RF-40 – Ver Petición

Existe la petición

El sistema redirige al administrador a la pantalla que muestra toda la información relacionada con dicha petición, junto con

las opciones disponibles sobre dicha petición SÍ

No existe la petición

El sistema muestra el formulario de información de la petición en blanco SÍ

RF-41 – Asignar Dieta

Datos correctos

El sistema crea una nueva dieta y redirige al administrador a la pantalla para asignar

alimentos a la dieta SÍ



RF-42 - Asignar Rutina

Datos correctos

El sistema crea una nueva rutina y redirige al administrador a la pantalla para asignar

ejercicios a la rutina SÍ



RF-43 – Asignar Alimentos a Dieta

Datos correctos

El sistema añade uno por uno los alimentos a la dieta, hasta que el usuario hace click sobre 'Finalizar', momento en el que lo

redirige a la pantalla de visualizar datos de petición SÍ





RF-44 – Asignar Ejercicios a Rutina

Datos correctos

El sistema añade uno por uno los ejercicios a la rutina hasta que el usuario hace click sobre 'Finalizar', momento en el que lo

redirige a la pantalla de visualizar datos de petición SÍ



RF-45 – Consultar Listado de Mensajes Sin Leer

Existen mensajes sin leer

El sistema muestra el listado de mensajes sin leer ordenados por orden de llegada,

junto con la opción de consultar la información de cada uno de ellos SÍ

No existen mensajes sin leer

El sistema muestra un mensaje indicando que no existen mensajes sin leer SÍ

RF-46 – Leer Mensaje No Leído

Datos correctos

El sistema actualiza el estado del mensaje y redirige al usuario al listado de mensajes sin

leer SÍ

Datos erróneos No existe posibilidad de este caso SÍ

RF-47 – Modificar Datos Personales

Datos correctos

El sistema actualiza los valores modificados y redirige al cliente a la pantalla de inicio SÍ



RF-48 – Consultar Listado De Paquetes Ofertados en la Plataforma

Hay paquetes

El sistema muestra al cliente el listado de paquetes ofertados en la plataforma junto

a la opción de contratarlo SÍ

No hay paquetes

El sistema muestra al cliente un mensaje indicando que no existen paquetes

disponibles en la plataforma SÍ



RF-49 – Enviar Petición

Datos correctos

El sistema crea una nueva petición asociada a dicho cliente, y lo redirige a la pantalla de

inicio SÍ



RF-50 – Consultar Listado de Peticiones Enviadas

Hay peticiones

El sistema muestra el listado de peticiones asociadas a dicho cliente, junto con la

opción de consultar la información de cada una de estas peticiones SÍ

No hay peticiones

El sistema muestra un mensaje indicando que no existen peticiones enviadas por

dicho cliente SÍ

RF-51 – Consultar Listado de Dietas Personales

Hay dietas

El sistema muestra el listado de dietas asociadas a dicho cliente, junto con la

opción de consultar la información de cada una de estas dietas SÍ

No hay dietas

El sistema muestra un mensaje indicando que no existen dietas asociadas a dicho

cliente SÍ

RF-52 – Consultar Listado de Rutinas Personales

Hay rutinas

El sistema muestra el listado de rutinas asociadas a dicho cliente, junto con la

opción de consultar la información de cada una de estas rutinas SÍ

No hay rutinas

El sistema muestra un mensaje indicando que no existen rutinas asociadas a dicho

cliente SÍ

RF-53 – Ver Dieta Existe la dieta

El sistema muestra al cliente la información relacionada con dicha dieta SÍ

No existe la dieta

El sistema muestra el formulario de información de la dieta en blanco SÍ

RF-54 – Ver Rutina

Existe la rutina El sistema muestra al cliente la información

relacionada con dicha rutina SÍ



No existe la rutina

El sistema muestra el formulario de información de la rutina en blanco SÍ

RF-55 – Ver Alimento

Existe el alimento

El sistema muestra la información o valor nutricional del alimento seleccionado SÍ

No existe el alimento

El sistema muestra el formulario de información del alimento en blanco SÍ

RF-56 – Consultar Listado de Mensajes

Existen mensajes

El sistema muestra el listado de mensajes asociados a dicho cliente SÍ

No existen mensajes

El sistema muestra en mensaje indicando que nos existen mensajes asociados a dicho

cliente, junto con la opción de escribir un nuevo mensaje SÍ

RF-57 – Añadir Nuevo Mensaje

Datos correctos

El sistema envía el mensaje al destinatario, y redirige al usuario al listado de mensajes SÍ



RF-58 – Eliminar Listado de Mensajes

Aceptar operación

El sistema elimina el listado de mensajes asociados a dicho usuario y redirige al

administrador a la pantalla del listado de mensajes pero vacía SÍ

Cancelar operación


RF-59 – Eliminar Mensaje Enviado

Aceptar operación

El sistema elimina el mensaje seleccionado y redirige al usuario a la pantalla del listado

de mensajes SÍ

Cancelar operación




RF-60 – Leer Mensaje

Datos correctos

El sistema actualiza el estado del mensaje y redirige al usuario al listado de mensajes SÍ

Datos erróneos No existe opción de que los datos sean

erróneos SÍ

RF-61 – Eliminar Cuenta de Usuario

Aceptar operación

El sistema eliminar toda la información relacionada con dicho cliente y lo redirige a

la pantalla de bienvenida a la aplicación SÍ

Cancelar operación


Tabla 29 - Casos de prueba

Para finalizar con este apartado, podemos concluir que tras las pruebas

realizadas, se considera que todos los casos de uso, así como sus alternativas, están

cubiertos, algo que sin duda nos habrá ayudado a reducir en gran medida el número

de errores que podrían producirse en el sistema en desarrollo.



5. CONCLUSIONES

En primer lugar, es preciso señalar que tras la finalización de este proyecto

podemos concluir que se han alcanzado los objetivos marcados al inicio de este,

puesto que en primer lugar se realizó un detallado análisis tanto de la temática a tratar;

como el FITNESS: conceptos previos, historia, metodologías para el diseño y creación

de dietas y rutinas personalizadas, aplicaciones existentes en el mercado y

oportunidades, como de las tecnologías para el desarrollo de aplicaciones web.

Concluida la etapa de análisis, se diseñó un prototipo de aplicación web, utilizando

para ello una metodología de diseño MVC bajo el framework Spring MVC, para

finalizar con la implementación de este prototipo, recogiendo todos los objetivos

inicialmente planteados.

Está claro que vivimos en una sociedad en la que la tecnología e internet, están

cada vez más presentes entre nosotros, incluso en ámbitos en los que hace unos años

no habríamos podido imaginar. Uno de estos ámbitos debe ser el del entrenamiento

deportivo y la nutrición, en el que poco a poco debemos ir abriéndonos paso, pues

como hemos visto durante la fase de análisis tratada al inicio de este proyecto, los

centros deportivos no acaban de adaptarse al uso de estas tecnologías. La motivación

principal a la hora de desarrollar este proyecto era la de poder contar con una

herramienta web que permitiese agilizar el proceso de gestión de usuarios, peticiones,

dietas y entrenamientos personalizados por parte de este tipo de centros, algo que

como veremos, se ha logrado conseguir satisfactoriamente.

El desarrollo de este proyecto ha supuesto un gran reto personal, auque también

una gran motivación, pues he intentado aunar dos grandes aficiones, como son el

mundo de la informática y el mundo del fitness. Un reto porque el alcance del proyecto

quizás podía haber sido demasiado amplio, y verse ‘sólo’ ante esta situación era algo

nuevo, aunque gracias a mi tutor, a algunos de mis compañeros, y sobre todo gracias

al trabajo duro y al esfuerzo, he podido encauzar el trabajo y lograr acabarlo con éxito

(espero).

La elección de las diferentes tecnologías y metodologías utilizadas, ha sido todo

un éxito, pues una vez que adquirí todos los conocimientos que necesitaba, me han

facilitado el trabajo sobremanera. Aunque como con cualquier aspecto de la vida, o



cualquier otro proyecto que se lleva a cabo, ha habido dificultades, y muchas noches

sin dormir, pero la constancia y no bajar nunca el ritmo de trabajo, han logrado que

esta aventura merezca la pena.

También es preciso señalar que tras un realizar exhaustivo análisis del sistema,

se elaboró de manera conveniente el listado de requisitos del sistema, bajo las

necesidades de un rol ‘ficticio’ de cliente, que yo mismo desempeñé, además de contar

con la ayuda de los propios dueños del gimnasio al que asisto, a los que consulté al

inicio de este proyecto para analizar las necesidades que ellos mismos encontraban,

como dueños de un centro deportivo. Este hecho sin ninguna duda ha facilitado el

desarrollo de la aplicación, logrando satisfacer practicamente en su totalidad los

objetivos marcados al inicio de este proyecto.

El desarrollo de este proyecto se ha realizado bajo la tecnología Java,

empleando para ello el entorno de desarrollo NetBeans, algo que a la larga ha

resultado ser un gran acierto, por su apariencia intuitiva y su fácil uso. Para la elección

de los diferentes frameworks, tanto a nivel de arquitectura utilizando SpringMVC,

como a nivel de interfaz de usuario utilizando BootStrap, conté con la orientación de

mi tutor, José Ramón, alguien que domina estos conceptos de forma asombrosa, y al

que debo darle las gracias pues creo que reflejan con acierto el enfoque que quería

darle a la aplicación.

Me gustaría destacar que durante la realización de este proyecto he podido

poner en práctica muchos de los conocimientos y habilidades adquiridos durante mis

años de formación en la Universidad de Jaén, tanto en Ingeniería Técnica en

Informática de Gestión como en los últimos en el curso de convalidación a Grado en

Ingeniería Informática. Aunque también he tenido la oportunidad de profundizar en

algunos aspectos que indiscutiblemente me servirán de gran ayuda en el futuro y en

los que me gustaría especializarme, como el desarrollo de aplicaciones web y diseño

web.



5.1. Mejoras y trabajos futuros

Aunque considero que he cumplido en un porcentaje bastante elevado con los

propósitos marcados al inicio de este proyecto, sí que es cierto que por motivos de

tiempo, extensión del proyecto u otros, hay algunos aspectos que bien podrían

mejorarse o ciertas funcionalidades que podrían añadirse, y que paso a analizar a

continuación.

Uno de los aspectos que no me ha dejado satisfecho al 100% ha sido el tema de

las ‘Dietas’. Cuando al inicio de este proyecto imaginaba esta sección, pensaba en

dos partes: la primera consistía en un análisis de necesidades calóricas y reparto de

macronutrientes del cliente, que sí se ha podido realizar, pero también manejaba la

idea de crear una Tabla de Dieta, dividida en días y ‘comidas’, en la que se indicaba

al detalle (alimento y cantidad de alimento) lo que un cliente debía comer ese día, y

en esa comida. La siguiente imagen muestra con mayor precisión esta idea:

Ilustración 142 - Tabla de Dieta 1



Ilustración 143 - Tabla de Dieta 2

Esta idea no se ha podido llevar a cabo, debido al alcance del proyecto, pues se

trata de un Trabajo Fin de Grado, y un prototipo de la aplicación. De haberlo hecho,

hubiese sido un esfuerzo aún mayor, que no hubiese aportado mucho más valor del

que ya posee la aplicación.

En primer lugar, me hubiese gustado añadir los campos ‘fecha’ y ‘hora’ a las

clases ‘Mensaje’, ‘Petición, ‘Dieta’ y ‘Rutina’, para que quedasen reflejados

exactamente estos datos en dichas clases. Esto no se ha podido llevar a cabo por mi

desconocimiento sobre algunos aspectos de los lenguajes de programación

empleados durante la realización de este proyecto y la falta de tiempo asociada a la

búsqueda necesaria de esta información, que no hubiese aportado gran valor al

proyecto.

El siguiente aspecto que se podría mejorar sería la generación de PDF’s con

cualquier tipo de documentación asociada a un cliente, o incluso a un entrenador. De

esta manera, tanto el entrenador personal, como el cliente, podrían generar los PDF’s

de información relacionada con una petición en concreto realizada por el cliente,

listados de cualquier tipo (clientes, peticiones asociadas a un cliente, listados de

ejercicios o alimentos, etc), dietas o rutinas personales de un cliente, mensajes u otros

informes.

Respecto de este último apartado, sería bastante interesante poder generar

Informes de Evolución o Resultados, acompañados de gráficos, que muestren el

progreso de un cliente, tanto a nivel alimenticio (evolución respecto de los objetivos

marcados en una dieta concreta), como de entrenamiento (evolución de los pesos que

es capaz de mover el cliente con el trascurso del tiempo, etc). Por motivos del alcance



de este proyecto, un Trabajo Fin de Grado, y al tratarse sólo de un prototipo, este sería

un aspecto que incluir en trabajos futuros.

Otro aspecto en el que se debería trabajar en el futuro, sería la inclusión de una

Pasarela de Pago, con la que el cliente sea capaz de realizar los pagos necesarios a

la hora de contratar un determinado servicio, y por consecuencia, el entrenador reciba

dichos honorarios.

Otra mejora, o trabajo futuro que se podría realizar sobre la aplicación, sería una

Calculadora Diaria de Macronutrientes. La idea sería que el cliente dispusiera de

una tabla, dividida en ‘comidas’, las x-comidas recomendadas por el entrenador, en la

que cada una de estas comidas tuviese un número determinado de campos donde el

cliente pudiese introducir un alimento existente en la BBDD de Alimentos, junto con la

cantidad ingerida de dicho alimento, y la aplicación de manera automática, calculase

la proporción de macronutrientes de dicho alimento, así como los totales para cada

comida y para el día en general, y a partir de ahí, generar una serie de informes de

evolución (como también comentaba más arriba). La idea sería tener algo así, para

cada una de las comidas del día:

Ilustración 144 - Calculadora Diaria de Macronutrientes

Otra mejora que daría una funcionalidad bastante interesante a la aplicación,

sería la de incluir un mecanismo que permita a los usuarios, tanto entrenadores como

clientes, Escanear códigos de barras de productos, para añadirlos a la BBDD.

Día 19/05/2015 TOTAL 1512,30 116,12 193,34 22,61

Desayuno Cantidad Kcal Pro Carbs Fat

Claras de huevo (Hacendado) 200 88 16 0 2

Harina de Avena ChocoBlanco AMIX50 170 4 29 2

Leche desnatada sin lactosa (Hacendado)250 82,50 7,50 12,50 0,00

Queso batido 0% (Hacendado) 125 57,50 10,00 5,00 0,00

TOTAL 398,00 37,50 46,50 4,00



Otro aspecto a considerar podría ser el cifrado de contraseñas, para

almacenarlas en la BBDD mediante algún algoritmo de cifrado, y que dotase a la

aplicación de un grado aún mayor de seguridad.

Mejorar el apartado del Sistema de Seguridad + SQL Injection: otra de las

posibles mejoras que no se han podido realizar debido a la envergadura del proyecto,

es el tema de la seguridad, aunque las tecnologías escogidas permiten que fácilmente

este hecho pueda ser revisado.

Para finalizar, un trabajo futuro que se podría llevar a cabo sería el de

implementar una Aplicación íntegra para móviles, de la aplicación, aunque como ya

se ha comentado en algún otro apartado de esta memoria, la actual cuenta con diseño

responsive, para adaptar el formato de la pantalla a los diferentes dispositivos móviles

existentes en el mercado.

Todas estas mejoras propuestas, no serían complicadas de abordar, puesto que

el diseño planteado nos proporciona los mecanismos para introducirlas de manera

fácil y natural, pero por motivos de alcance del proyecto, no ha sido posible su

desarrollo.



6. BIBLIOGRAFÍA

[1] «La palabra Fitness,» Noviembre 2012. [En línea]. Available:

http://isanceblog.blogspot.com.es/2012/11/los-origenes-del-concepto-del-fitness.html.

[2] E. L. Corre, «La Historia del Fitness,» [En línea]. Available:

http://www.entrenamientonatural.com/la-historia-del-fitness/.

[3] «ProviSport,» [En línea]. Available:

http://www.provis.es/WebProvis/Productos/CentroDeportivoVirtual.aspx.

[4] «MyFitnessPal,» [En línea]. Available: http://www.myfitnesspal.com.mx.

[5] «FitMacro,» [En línea]. Available: http://www.fitmacro.com.

[6] «FitFoodMarket,» [En línea]. Available: http://fitfoodmarket.es.

[7] «Definición de caloría,» Enero 2014. [En línea]. Available: http://goo.gl/GUiXS7.

[8] «El efecto térmico de los Alimentos (ETA),» Agosto 2011. [En línea]. Available:

http://www.adelgazarapido.org/2011/08/el-efecto-termico-de-los-alimentos.

[9] E. García, «Una alimentación saludable para un buen desarrollo en la infancia,»

Noviembre 2010. [En línea]. Available: http://bit.ly/1FduAbD.

[10] «Definiciones básicas de nutrición,» [En línea]. Available: http://bit.ly/1erXK02.

[11] @MusclePower, «Cálculo de calorías y macronutrientes de la dieta (Emma Leigh),»

[En línea]. Available: http://www.realfitness.es/nutricion/calculo-calorias-macros-dieta-

emma-leigh.

[12] J. Revenga, «El nutricionista de la general,» Febrero 2014. [En línea]. Available:

http://bit.ly/1duUYqB.

[13] D. Díaz, «Calcula tu dieta paso a paso,» [En línea]. Available: http://bit.ly/1lYhoNV.

[14] A. Carbajal, «Manual de Nutrición y Dietética,» Universidad Complutense de Madrid,

2013. [En línea]. Available: https://www.ucm.es/nutricioncarbajal/manual-de-nutricion.

[15] D. N. Palacios y D. Z. Montalvo, «Alimentación, Nutrición e Hidratación en el Deporte.,»

[En línea]. Available: http://bit.ly/1iBKFi6.

[16] D. Díaz, «Aprende a crear tu propia rutina de pesas,» [En línea]. Available:

http://www.vitonica.com/musculacion/aprende-a-crear-tu-propia-rutina-de-pesas-i;

http://www.vitonica.com/musculacion/aprende-a-crear-tu-propia-rutina-de-pesas-ii .



[17] «¿Qué es el método Weider?,» Abril 2014. [En línea]. Available:

http://ejerciciosencasa.es/metodo-weider.

[18] S. McConnell, Desarrollo del proyectos informáticos, Madrid: McGraw Hill, D.L., 2000.

[19] P. González, Apuntes de la asignatura: Desarrollo Ágil, Jaén: Universidad de Jaén,

2014.

[20] «¿Qué es SCRUM?,» [En línea]. Available: http://www.proyectosagiles.org/que-es-

scrum.

[21] W. Wheeler y J.White, Spring in Practice. [Online] Disponible en Recursos Electrónicos

de la Universidad de Jaén, Safari, 2012.

[22] J. d. Andalucía, «Marco de desarrollo de la Junta de Andalucía: JavaServer Faces

(JSF),» [En línea]. Available:

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/101.

[23] J. Z. Jiménez, Aplicaciones web, Madrid: Macmillan Iberia S.A. [Online] Disponible en

Recursos Electrónicos de la Universidad de Jaén, 2013.

[24] «Apache Tomcat,» Apache Software Foundation, [En línea]. Available:

http://tomcat.apache.org/.

[25] «GlassFish Server Open Source Edition,» [En línea]. Available:

https://glassfish.java.net/es/.

[26] Antonio, «Servidores J2EE 7 Certificados (Junio 2015),» Servidores de Aplicaciones,

11 Junio 2015. [En línea]. Available:

http://blog.servidoresdeaplicaciones.com/tag/comparativa/.

[27] I. Sommerville, Ingeniería del Software. 9ª Ed., México: Pearson, 2011.

[28] J. Olguín, «Análisis de Requisitos del Software,» [En línea]. Available:

http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm.

[29] S. d. Valle y A. Oliveros, «Requerimientos no funcionales para aplicaciones web,» [En

línea]. Available: http://bit.ly/1Arko2D.

[30] J. I. Gómez, Apuntes de la asignatura: Gestión de proyectos software, Jaén:

Universidad de Jaén, 2014.

[31] L. Martínez, Apuntes de la asignatura: Gestión y Control de proyectos informáticos,

Jaén: Universidad de Jaén, 2014.

[32] R. Pressman, Ingeniería del Software: un enfoque práctico. 7ª Ed., México: McGraw-

Hill, 2010.



[33] M. d. E. y. S. Social, «Boletín Oficial del Estado,» 12 Enero 2015. [En línea]. Available:

http://www.boe.es/boe/dias/2015/01/12/pdfs/BOE-A-2015-255.pdf.

[34] I. Martínez, «Clase 6: Modelo Conceptual/Modelo de Dominio,» [En línea]. Available:

http://bit.ly/1Kx8VSd.

[35] P. Kimmel, Manual de UML., McGraw-Hill Interamericana. [Online] Disponible en

Recursos Electrónicos de la Universidad de Jaén., 2010.

[36] S. Ceria, «Casos de Uso: Un método práctico para explorar requerimientos,» [En

línea]. Available: http://bit.ly/1J2gL4u.

[37] L. Ortiz, «Casos a Incluir y Casos a Extender,» [En línea]. Available:

http://goo.gl/2fp0R.

[38] M. Vega, «Casos de Uso: UML,» LSI-UGR. Granada, Octubre 2010. [En línea].

Available: http://bit.ly/1t4B4UG.

[39] C. G. Cosío, Casos prácticos de UML, Editorial Complutense. [Online] Disponible en

Recursos Electrónicos de la Universidad de Jaén., 2011.

[40] A. Pérez, «Estructuración y Especificación de Casos de Uso,» [En línea]. Available:

https://goo.gl/ylSmuV.

[41] A. Molina y M. T. Martín, Apuntes de la asignatura: Fundamentos de Bases de Datos,

Jaén: Universidad de Jaén, 2014.

[42] A. Silberschatz, H. Korth y S. Sudarshan, Fundamentos de bases de datos, Madrid:

McGraw-Hill, 2002.

[43] L. A. Ureña y J. I. Gómez, Apuntes de la asignatura: Fundamentos de Ingeniería del

Software, Jaén: Universidad de Jaén, 2014.

[44] C. Fontela, UML: Modelado de Software para profesionales, Buenos Aires: Alfaomega.

Grupo Editor, 2011.

[45] J. Schmuller, Aprendiendo UML en 24 horas., Pearson, 2001.

[46] J. Olguín, «Introducción al UML,» [En línea]. Available:

http://yaqui.mxl.uabc.mx/~molguin/as/UMLCurso2.htm.

[47] G. Booch y J. Rumbaugh, El lenguaje unificado de modelado. 2ª Ed., México: Pearson,

2006.

[48] P. González, Apuntes de la asignatura: Diseño de Software, Jaén: Universidad de

Jaén, 2014.



[49] J. Domínguez, «Interfaces y Metáforas,» [En línea]. Available:

http://tecnologiaedu.us.es/cursos/29/html/cursos/tema_accioni/2-4.htm.

[50] P. d. Moreno y M. Sosa, «Análisis de las ventajas del uso de la aplicación de metáforas

en la interfaz de usuario,» [En línea]. Available:

http://fhu.unse.edu.ar/carreras/rcifra/c5/sosa-romero.pdf.

[51] «BootStrap: Components,» BootStrap v3.3.4, [En línea]. Available:

http://getbootstrap.com/components/.

[52] J. Aguilar, «Bootstrap jQuery Modal,» [En línea]. Available: http://www.jose-

aguilar.com/blog/bootstrap-modal/.

[53] J. R. B. Almagro, Apuntes de la asignatura: Desarrollo de Aplicaciones Web, Jaén:


[54] «¿Sabes qué es un Pool de Conexiones?,» Julio 2007. [En línea]. Available:

http://ayuda-java.blogspot.com.es/2007/07/sabes-qu-es-un-pool-de-

conexiones_21.html.

[55] «GitHub/spring-projects/spring-security,» Agosto 2014. [En línea]. Available:

https://github.com/spring-projects/spring-security/releases.

[56] D. Marco, «Desarrollando una aplicacion Spring Framework MVC paso a paso,» [En

línea]. Available: http://www.davidmarco.es/spring-mvc.

[57] J. I. Gómez, Apuntes de la asignatura: Calidad del Software, Jaén: Universidad de

Jaén, 2014.

[58] C. Larman, UML y Patrones. 2ª Ed., Madrid: Pearson Educación., 2010.

[59] B. Kurniawan., Java: A beginner's Tutorial. 4th Ed., Quebec, Canada. :

BrainySoftware., 2015. .

[60] D. D. Coward., Java EE7: The big picture., Oracle Press. , 2014. .

[61] H. Schildt., Java: The complete reference. 9th Ed., New York.: McGraw-Hill Education. ,

2014..

[62] «Apache Tomcat,» Apache Software Foundation, [En línea]. Available:

http://tomcat.apache.org/.

[63] A. Montejo, Apuntes de la asignatura: Tecnologías basadas en la web, Jaén:




ANEXO I. MANUAL DE USUARIO

El siguiente anexo recoge el Manual de Usuario de la aplicación web titulada

‘Aplicación Web para el Asesoramiento Deportivo Online’, y pretende ser una guía que

de manera visual muestre todas las funcionalidades del sistema, para que cualquier

tipo de usuario que desee hacer uso de ella pueda resolver todas las dudas sobre su

funcionamiento.

Pantalla de Bienvenida a la aplicación

Ilustración 145 - MU: Pantalla de Bienvenida a la aplicación

Como podemos observar, la pantalla se encuentra dividida en tres secciones:

- Cabecera: compuesta de una barra superior y una imagen de cabecera.

- Identificación: donde los usuarios que ya estén registrados en la plataforma

deberán introducir sus datos de usuario, identificador de usuario y contraseña,

para poder acceder al contenido de la plataforma.

- Formulario de registro: en esta sección todo aquel que acceda por primera vez

a la plataforma, podrá crear un nuevo usuario simplemente rellenando los

campos que ahí se reflejan, como son: identificador de usuario, nombre

completo, email y contraseña.

Pongámonos en la situación de un ‘cliente’ que accede por primera vez a la web

y rellena los campos del formulario de registro. Si los ha introducido de forma correcta,

se le creará al nuevo usuario un perfil, de tipo ‘Cliente’, para poder acceder al



contenido de la plataforma, y se le mostrará la siguiente pantalla, que confirmará que

el nuevo usuario ha sido creado con éxito. En esta nueva pantalla, ya sólo se le

mostrará el apartado de Identificación, donde deberá introducir su usuario y

contraseña para acceder.

Ilustración 146 - MU: Usuario creado con éxito

Una vez introducidos los datos de inicio de sesión, pasamos al siguiente punto.

Pantalla de Inicio – Parte del Cliente

La pantalla que recibirá el cliente cuando acceda a la plataforma, es la que se

muestra en la siguiente ilustración:

Ilustración 147 - MU: Pantalla de Inicio del Cliente



Como vemos, está dividida en tres secciones, dos de las cuáles permanecerán

fijas a lo largo del resto de pantallas de la sección del cliente (las dos primeras). Estas

tres secciones son las siguientes:

- Barra superior: donde se muestra el título de la web, la información principal del

cliente: nombre completo y rol que desempeña, y un botón que permitirá al

usuario cerrar la sesión en cualquier momento.

- Barra horizontal de opciones: donde el cliente tendrá disponibles las principales

funcionalidades que puede llevar a cabo, como son: ir al inicio, modificar datos

personales, contratar paquete, consultar peticiones enviadas, consultar dietas

personales, consultar rutinas personales, acceder a mensajes.

- Contenido de la pantalla: donde simplemente se muestra una imagen y los

datos de la plataforma.

Modificar Datos Personales – Parte del Cliente

Ilustración 148 - MU: Modificar Datos Personales - Parte del Cliente

Si nos fijamos en la sección destinada al contenido de la pantalla, distinguimos

claramente dos partes. La primera de ellas, situada a la izquierda, muestra una imagen

acompañada de un botón en la parte inferior. Este botón, bajo el nombre de ‘Eliminar

Cuenta’ permitirá al cliente eliminar no sólo sus datos de usuario, sino todo lo

relacionado con el mismo, es decir, todas las peticiones enviadas o paquetes

contratados, todas las dietas y rutinas personales que tuviese asociadas, y todo su

historial de mensajes.



La pantalla que recibiremos si pulsamos sobre este botón, es la que sigue:

Ilustración 149 - MU: Eliminar Cuenta de Usuario - Parte del Cliente

En la parte derecha, podemos ver un formulario donde el cliente puede modificar

sus datos personales. Aunque como podemos observar, sólo aparecen tres campos

modificables: nombre completo, email y contraseña, mientras que el identificador de

usuario aparece bloqueado. Esto es así puesto que dicho campo no se puede

modificar. Este formulario incluye además tres botones para: ir a la página anteriror,

guardar los nuevos datos, y resetear los campos del formulario.

Contratar Paquete – Parte del Cliente

Ilustración 150 - MU: Contratar Paquete - Parte del Cliente

En esta pantalla, aparecerá el listado con todos los paquetes ofertados en la

plataforma, y que están a disposición de ser contratados por el cliente.



Si analizamos con detenimiento la información de cada paquete, mostrada en

cuadros independientes, vemos que cada paquete incluye seis apartados: nombre del

paquete, objetivo del paquete, apartado donde se especifica qué incluye el paquete,

descripción, precio y una opción o enlace para contratar dicho paquete, donde

haciendo click nos llevará a la siguiente pantalla:

Formulario de Contratación – Parte del Cliente

Ilustración 151 - MU: Formulario de contratación - Parte del Cliente

Esta pantalla muestra el formulario que permitirá al cliente contratar un

determinado servicio. A parte de algunos datos que ya se tienen tanto del cliente como

del paquete, entre los datos que se le piden a este tenemos: edad, altura, peso,

porcentaje de grasa (si se conoce, 0 si se desconoce), sexo, nivel de actividad diaria,

nivel del entrenamiento de pesas (si se realiza) y minutos que dedica a dicha actividad,

nivel de entrenamiento cardiovascular (si se realiza) y minutos que se dedican a dicha

actividad, entrenador que desea contratar de los disponibles en la plataforma,

disponibilidad para realizar ejercicio y objetivo calórico del cliente. Junto a estos datos,

los botones habituales para retroceder, guardar datos y reset.



Una vez que el cliente rellene y confirme los datos del formulario, se enviará la

petición al entrenador personal seleccionado, y se redireccionará al cliente a la página

de inicio vista anteriormente.

Consultar Listado de Peticiones Enviadas – Parte del Cliente

Ilustración 152 - MU: Peticiones Enviadas - Parte del Cliente

En esta pantalla, el cliente podrá consultar un listado con todas las peticiones

que haya enviado, tanto las que están sin atender, como las que ya han recibido una

respuesta por parte del entrenador.

Para cada petición, se muestran todos los datos facilitados por el cliente en dicha

petición.

Consultar Listado de Dietas Personales – Parte del Cliente

Ilustración 153 - MU: Dietas Personales - Parte del Cliente

En esta pantalla, el cliente puede consultar un listado con todas las Dietas

Personales que ya tiene asociadas, asociadas por orden de creación.

La información que se muestra para dieta es el número que ocupa, el idDieta y

el idPetición de la petición a la que está asociada la dieta. Para consultar toda la



información detallada de cada dieta, basta con hacer click en el enlace que muestra

la información comentada.

Ver Dieta – Parte del Cliente

Ilustración 154 - MU: Ver Dieta - Parte del Cliente

Esta pantalla muestra al cliente la información detallada de una dieta concreta.



En primer lugar, se muestran los nombres completos del cliente y del entrenador

personal contratado.

En el cuadro de texto, con fondo azul situado a la izquierda de la pantalla, se

muestra la información facilitada por el cliente en el formulario de contratación: sexo,

porcentaje de grasa, altura, peso, edad, nivel de actividad diario, intensidad del

entrenamiento de pesas y minutos de dicha actividad, e intensidad del entrenamiento

cardiovascular y minutos de dicha actividad.

En la parte de la derecha podemos consultar una serie de tablas que detallan al

cliente tanto los Requerimientos Calóricos generales; en términos de calorías, como

los Requerimientos aproximados de Macronutrientes, que hacen referencia a las

cantidades necesarias que el cliente debe ingerir de cada macronutriente.

El cliente también puede consultar en esta pantalla: el número de comidas que

debe realizar al día, y el número de días en los que debe serguir la dieta.

Para finalizar con esta pantalla, se muestra una tabla con el Listado de Alimentos

recomendados para el cliente, dividida en tres columnas: Nombre del Alimento,

Observaciones o recomendaciones asociadas a citado alimento, y Opción Ver; que

permite al usuario consultar el valor nutricional de cada alimento (y que se muestra en

la siguiente imagen).

Ilustración 155 - MU: Ver Alimento - Parte del Cliente

Consultar Listado de Rutinas Personales – Parte del Cliente



Ilustración 156 - MU: Rutinas Personales - Parte del Cliente

Al igual que en el caso de la pantalla del Listado de Dietas, esta pantalla muestra

las rutinas ordenadas por fecha de creación, junto con el idRutina y el idPeticion al

que pertenece cada rutina. Para poder visualizar la información detallada de una

rutina, el cliente sólamente ha de hacer click en el enlace de la rutina que desea

consultar.

Ver Rutina – Parte del Cliente

Ilustración 157 - MU: Ver Rutina - Parte del Cliente



Dentro de esta pantalla, el cliente encontrará un apartado, situado a la izquierda

de su pantalla con fondo azul, en el que podrá recordar todos los datos enviados a

través del formulario de contratación de servicios.

A la derecha, podrá encontrar toda la información relacionada con su rutina o

plan de entrenamiento, información dividida en dos tablas. En la primera aparece el id

de la rutina, el nombre de dicha rutina, y una serie de pautas u observaciones a tener

en cuenta durante la realización de la misma. Más abajo, encontramos el listado de

ejercicios que contiene la rutina, ordenados por grupo muscular, junto con el número

de series, repeticiones, observaciones y enlace web de cada ejercicio. Haciendo click

sobre este último, la aplicación nos redirecciona a YouTube, donde se muestra un

vídeo en el que se explica de qué manera se debe realizar cada ejercicio.

Bandeja de Mensajes – Parte del Cliente

Ilustración 158 - MU: Bandeja de Mensajes - Parte del Cliente

En esta pantalla, el usuario puede consultar el listado de mensajes recibidos y

enviados en los que interviene. Como se puede observar, cada mensaje incluye su

idMensaje, una etiqueta que diferencia entre mensajes: enviados o recibidos, y un

texto que indica el usuario a quien se dirije el mensaje (en cado de tratarse de un

mensaje enviado), o quien nos ha mandado un mensaje (si se trata de un mensaje

recibido). Los mensajes recibidos que no hayan sido leidos todavía, aparecen

marcados en negrita (ver mensaje con id 73). Veamos las diferentes funcionalidades

que nos ofrece esta pantalla:



Leer mensaje: Para leer un mensaje sólo tenemos que hacer click sobre el

enlace que acompaña a la etiqueta del mensaje. Si lo hacemos, el sistema nos

mostrará la siguiente pantalla:

Ilustración 159 - MU: Leer Mensaje - Parte del Cliente

La imagen muestra un nuevo mensaje recibido por parte del entrenador, con el

nombre que se indica, el id del mensaje, los identificadores de usuario del emisor y

receptor del mensaje, el contenido del mensaje y una opción para marcar el mensaje

como leido o no leido. Para hacer uso de esta opción, simplemente pulsaremos sobre

la opción deseada, y después sobre ‘Aceptar’, si es lo que queremos, o ‘Atrás’ si

queremos dejar el estado del mensaje tal y como está.

Eliminar mensaje: Aquellos mensajes que incluyen la etiqueta ‘enviados’, van

acompañados además de una opción que permite eliminarlos, por si el cliente detecta

algún error. Para hacer uso de dicha opción bastará con hacer click en la misma. Si

pulsamos, recibiremos el siguiente mensaje de confirmación:

Ilustración 160 - MU: Eliminar Mensaje - Parte del Cliente



La aplicación nos pide que confirmemos si deseamos realmente eliminar el

mensaje seleccionado, pulsando el botón ‘Aceptar’, o cancelar la operación, botón

‘Cancelar’ o ‘X’ en la parte superior del cuadro de diálogo.

Eliminar Listado de Mensajes: pulsando este botón se eliminará todo el listado

de mensajes del usuario, previa confirmación como en el caso anterior.

Añadir Mensaje: esta opción permite al usuario escribir un nuevo mensaje a

través de la pantalla que se muestra en la siguiente ilustración:

Ilustración 161 - MU: Añadir Mensaje - Parte del Cliente

Se puede observar que la opción origen del mensaje indica por defecto el

identificador de usuario del cliente logueado, y el apartado destino incluye una lista

desplegable que permitirá al cliente seleccionar a qué entrenador de los disponibles

en la plataforma desea escribir el mensaje. Para escribir el mensaje, simplemente

tenemos que rellenar el cuadro de texto que se observa, y pulsar el botón ‘Guardar’.

Cerrar Sesión

Para cerrar sesión, sea cuál sea el rol de usuario logueado en un determinado

instante, tendremos que hacer uso de la opción que se muestra en la siguiente

ilustración:

Ilustración 162 - MU: Opción de 'Salir'



Si pulsamos en el botón mostrado en la imagen, el usuario recibirá el siguiente

cuadro de diálogo, en el que se le pedirá que confirme si realmente desea abandonar

la plataforma, haciendo click en el botón ‘Aceptar’.

Ilustración 163 - MU: Cerrar Sesión

Pantalla de Inicio – Parte del Administrador

Ilustración 164 - MU: Pantalla de Inicio del Administrador

Al igual que en la pantalla de bienvenida del cliente, podemos diferenciar tres

secciones en esta:

- Barra superior fija: muestra el título de la web, información del cliente y botón

para ‘salir’ de la plataforma. Aparecerá fija e inmóvil durante todo el proceso.

- Barra horizontal de opciones: será otro elemento que aparecerá en el resto de

pantallas del cliente. Aquí podemos consultar todas las funcionalidades que

están a disposición del entrenador personal, como son: gestión de usuarios,

gestión de paquetes, gestión de ejercicios, gestión de alimentos, peticiones

pendientes y bandeja de mensajes.



- Contenido de la página: es la sección que muestra el contenido propio de cada

página, y que varía en cada una de ellas. En este caso, sólo se muestra una

imagen, y datos relacionados con este proyecto.

Gestión de Usuarios – Parte del Administrador

Ilustración 165 - MU: Gestión de Usuarios - Parte del Administrador

- Opción ‘Añadir Usuario’: permite al entrenador introducir de forma manual un

nuevo usuario a la plataforma, de tipo entrenador o de tipo cliente.

- Listado de Entrenadores Personales: se muestra el listado de entrenadores

personales existentes en la plataforma, junto con las funcionalidades que un

administrador logueado puede realizar sobre cada uno de ellos. Estas

operaciones son: Visualizar Datos de Usuario, Escribir Nuevo Mensaje, y

Consultar Histórico de Mensajes asociado a cada entrenador. *NOTA: como se

puede observar, un entrenador logueado tiene deshabilitadas las opciones de

escribirse un mensaje a sí mismo, y eliminar su cuenta de usuario, puesto que

dichas opciones no son accesibles.



- Listado de Clientes: tabla que muestra el listado de clientes registrados en la

plataforma, junto con las funcionalidades que se pueden realizar sobre cada

uno de ellos. Dichas funcionalidades son: Visualizar Datos, Escribir Mensaje,

Consultar Histórico de Mensajes, Consultar Histórico de Peticiones enviadas

por dicho cliente, Consutar Listado de Dietas Personales, Consultar Listado de

Rutinas Personales y Eliminar Cliente.

En los siguientes apartados, veremos como debemos proceder para hacer uso

de cada una de estas funcionalidades.

Añadir Usuario – Parte de Administrador

Ilustración 166 - MU: Añadir Usuario - Parte del Administrador

El administrador dispone de un formulario con el que rellenando los campos que

se indican en la imagen, podrá crear un nuevo perfil de usuario.

Como elemento destacable de este formulario, podemos señalar que el

administrador puede decidir el tipo o rol de usuario, del nuevo perfil que está creando,

diferenciando entre administrador (Entrenador Personal) o user (Cliente).



Visualizar Datos de Usuario – Parte del Administrador

La imagen muestra todos los datos del usuario seleccionado, junto con las

opciones de ‘retroceder’ y ‘Modificar’. Esta última opción permite al administrador ir a

la pantalla siguiente, donde podrá modificar la información personal del usuario.

Modificar Datos de Usuario – Parte del Administrador

Para modificar los datos de usuario, basta con cambiar los valores de los campos

incluidos en el formulario y pulsar en el botón ‘Guardar’. Una vez hecho esto, el

sistema nos redireccionará a la pantalla vista anteriormente ‘Visualizar Datos de

Usuario’.



Escribir Mensaje (o Añadir Nuevo Mensaje) – Parte del Administrador

Ilustración 167 - MU: Añadir Nuevo Mensaje - Parte del Administrador

Para poder ‘Escribir un Nuevo Mensaje’, nos iremos al cuadro de texto que se

muestra en la imagen, e introduciremos el contenido del mensaje que deseamos

escribir. Seguidamente, pulsaremos el botón ‘Guardar’, y el mensaje quedará

grabado, redireccionándonos la aplicación a la bandeja de mensajes del cliente al que

hayamos escrito el mensaje. Esta nueva ventana pasamos a verla en el siguiente

apartado.

Histórico de Mensajes – Parte del Administrador

Ilustración 168 - MU: Histórico de Mensajes - Parte del Administrador

El administrador o entrenador personal logueado, puede consultar en esta

pantalla el listado de mensajes asociado a cualquier usuario de la plataforma, tanto

mensajes enviados, como recibidos, ordenados siempre por el id de mensaje que se

crea al escribir un nuevo mensaje.



Para cada mensaje, disponemos de si idMensaje, origen o emisor del mensaje,

destino o receptor del mensaje, contenido, estado y dos opciones, una que nos

permitirá cambiar el estado de un mensaje recibido; ‘Modificar Mensaje’, y ‘Eliminar

Mensaje’.

Además de esto, el usuario dispone de sendos botones para ‘Añadir Mensaje’ y

‘Eliminar Listado de Mensajes’. (NOTA: Estas opciones ha sido revisadas en el

apartado de las pantallas del cliente).

Consultar Histórico de Peticiones – Parte del Administrador

Ilustración 169 - MU: Consultar Histórico de Peticiones - Parte del Administrador

En esta pantalla, el entrenador personal tiene la posibilidad de consultar el listado

de peticiones enviadas por cualquier usuario de la plataforma, así como de todos los

datos enviados en cada una de ellas, además de la opción de ‘Eliminar Petición’ que

tiene accesible pulsando sobre el icono marcado en la imagen.

Consultar Listado de Dietas Personales – Parte del Administrador

Ilustración 170 - MU: Listado de Dietas Personales - Parte del Administrador



A parte de poder consultar toda la información de la dieta de manera detallada,

y eliminar una dieta concreta, el usuario puede acceder desde esta pantalla al Listado

de alimentos que componen dicha dieta, pulsando la opción ‘Ver’ que aparece en

pantalla, mostrándose la siguiente pantalla:

Ilustración 171 - MU: Listado de Alimentos Dieta - Parte del Administrador

Seleccionando la opción ‘Ver’ que se muestra en la imagen, podremos acceder

a la información relacionada con el valor nutricional de cada alimento de la lista.

Consultar Listado de Rutinas Personales – Parte del Administrador

Ilustración 172 - MU: Consultar Listado de Rutinas Personales - Parte del Administrador

Para cada rutina tenemos la opción de visualizar sus datos, eliminarla y consultar

el listado de ejercicios que la componen. La pantalla que recibimos si hacemos click

en la opción ‘Ver’ de la columna ListEjercicios es la siguiente:



Ilustración 173 - MU: Listado de Ejercicios Rutina - Parte del Administrador

En esta pantalla podemos consultar el listado de ejercicios que componen un

plan de entrenamiento, clasificados por grupo muscular. Para cada ejercicio aparece

el número de series y repeticiones que el cliente debe realizar de cada ejercicio, un

campo de observaciones asociadas a cada ejercicio, y un enlace a la explicación de

dicho ejercicio, al que accederemos directamente con hacer click sobre él.

Gestionar Paquetes – Parte del Administrador

Ilustración 174 - MU: Gestionar Paquetes - Parte del Administrador

Como vemos, existen dos botones que nos permitirán: ‘Añadir Paquete’ y ‘Añadir

Propósito’.



Para cada paquete, aparece: su id, nombre, objetivo o propósito, descripción y

precio, junto con la opción de modificar los datos del paquete, y de eliminarlo.

Añadir Propósito – Parte del Administrador

Ilustración 175 - MU: Añadir Propósito - Parte del Administrador

Puesto que un propósito sólo está compuesto por un nombre, para añadir uno

nuevo bastará con rellenar el campo que se muestra en la imagen y pulsar sobre el

botón ‘Guardar’.

Modificar Paquete – Parte del Administrador

Ilustración 176 - MU: Modificar Paquete - Parte del Administrador

Para modificar los datos de un paquete, sólo tenemos que modificar uno (o más)

de los campos modificables que aparecen en el formulario de la ilusración anterior y



pulsar el botón ‘Guardar’. La opción ‘Objetivo’ muestra un desplegable que nos

permite seleccionar uno de los propósitos existentes en el sistema. (NOTA: no se ha

incluido la pantalla Añadir Paquete en este Manual de Usuario, pues su

funcionamiento es idéntico al de Modificar Paquete).

Gestionar Ejercicios – Parte del Administrador

Ilustración 177 - MU: Gestionar Ejercicios - Parte del Administrador

La ventana muestra los listados de ejercicios para cada grupo muscular,

detallando la información de cada ejercicio, y las opciones de añadir, modificar y

eliminar ejercicio. Si accedemos, por ejemplo a la opción ‘Modificar’ de un ejercicio

cualquiera, el sistema nos redireccionará a la siguiente pantalla:



Modificar Ejercicio – Parte del Administrador

Ilustración 178 - MU: Modificar Ejercicio - Parte del Administrador

Como en otros casos anteriores, para modificar la información de un ejercicio

(NOTA: el proceso es extensible para la opción Añadir Ejercicio, que no se muestra

en este Manual de Usuario), basta con modificar el campo deseado y pulsar el botón

de ‘Guardar’. Una vez hecho esto, el sistema nos devolverá al listado de ejercicios.

Gestionar Alimentos – Parte del Admnistrador

Ilustración 179 - MU: Gestionar Alimentos - Parte del Administrador



La imagen muestra la nformación detallada para todos los alimentos existentes

en el sistema, junto con las opciones de modificar y eliminar cada alimento. Para

añadir un nuevo alimento sólo tenemos que hacer click en el botón que se muestra en

la misma, y que nos permitirá acceder a la siguiente pantalla:

Añadir nuevo Alimento – Parte del Administrador

Ilustración 180 - MU: Añadir nuevo Alimento - Parte del Administrador

Para añadir un nuevo alimento rellenaremos los datos que se piden en el

formulario de la imagen anterior y pulsaremos ‘Guardar’. (NOTA: de forma análoga

modificaremos los datos de un alimento concreto).



Peticiones Pendientes – Parte del Administrador

Ilustración 181 - MU: Peticiones Pendientes

En esta pantalla aparecen todas las peticiones enviadas por los clientes que

contratan los servicios del entrenador personal logueado en un momento determinado,

ordenadas por antigüedad. Como se puede observar, la tabla muestra un indicador

con el número total de peticiones que tiene sin atender dicho entrenador, y un mensaje

indicando qué usuario ha realizado la petición. Para acceder a la información de una

petición determinada, sólo tenemos que hacer click sobre el enlace de dicha petición.

Ver Petición – Parte del Administrador

Ilustración 182 - MU: Ver Petición - Parte del Administrador



La información que se recoge en esta pantalla es toda la facilitada por el cliente

al rellenar el formulario de contratación de servicios. Esta información se divide en tres

secciones: Información del Cliente, Datos de Contratación e Información necesaria

para atender la petición.

Además, al lado del nombre del cliente aparecerá uno o dos botones,

dependiendo de los servicios contratados por este. Si el paquete seleccionado por un

cliente incluye Dieta aparecerá un botón para Asignar Dieta (como se observa en la

imagen), mientras que si el paquete incluye una Rutina, aparecerá el botón de Asignar

Rutina. Si el paquete seleccionado incluyese ambos, dieta y rutina, aparecerían los

dos botones.

Pasos a seguir para atender una Petición

1) Ir al botón correspondiente (según los casos que se han visto más arriba).

2) Seguir los pasos en cada caso, como se verá posteriormente.

3) Una vez que los pasos se hayan completado en cada caso, el sistema nos

devolverá a la pantalla Ver Petición, donde seleccionaremos la opción

Atendida, que marca una petición como atendida, y Guardar.

4) Una vez hecho esto, volveremos de forma automática a la pantalla de

Peticiones Pendientes, donde, de haber más peticiones sin atender,

repetiremos el proceso.

Asignar Dieta – Parte del Administrador

Ilustración 183 - MU: Asignar Dieta – Parte 1 - Parte del Administrador



Ilustración 184 - MU: Asignar Dieta - Parte 2 - Parte del Administrador



Para Asignar una Dieta es necesario seguir los pasos que se observan en las

dos imágenes anteriores. Algunos de estos pasos sólo muestran los cálculos que se

mostrarán posteriormente, pero sin embargo, en el Paso 6, sí es necesario que el

entrenador introduzca algún valor, algo que hará rellenando el campo

correspondiente, y bajo las indicaciones que se muestran en la ilustración.

Cuando hagamos click en ‘Calcular’, la Dieta se habrá creado, y el sistema nos

redirijirá a la siguiente pantalla que nos permitirá visualizar el Análisis de

Requerimientos Calóricos del Cliente, y seguir rellenando algunos datos, como se

muestra a continuación:

Ilustración 185 - MU: Asignar Dieta - Paso 2 - Parte del Administrador



Una vez pulsemos en ‘Guardar’, estaremos en disposición de pasar a la última

pantalla de asignación de Dieta, la que nos permitirá Asignar Alimentos a la Dieta,

como puede verse en la siguiente imagen:

Asignar Alimentos a la Dieta – Parte del Administrador

Ilustración 186 - MU: Asignar Alimentos a la Dieta - Parte del Administrador

En esta pantalla iremos añadiendo alimentos a la dieta, seleccionando el

alimento que queramos incluir en la dieta, de los disponibles en la lista desplegabe

que se muestra en la imagen, y rellenando el campo observaciones para cada

alimento introducido. Una vez tengamos rellenos ambos datos del alimento,

pulsaremos en ‘Añadir’ y el alimento se añadirá a la lista, mostrándonos el sistema de

nuevo las opciones necesarias para añadir un nuevo alimento, como se muestra en la

ilustración.

Cuando hayamos añadido todos los alimentos que deseamos a la dieta,

pulsaremos el botón ‘Finalizar’, y el sistema nos llevará a la pantalla vista

anteriormente, denominada Ver Petición, donde, como ya se ha indicado,

cambiaremos el estado de la petición, si hemos finalizado el proceso.



Asignar Rutina – Parte del Administrador

Ilustración 187 - MU: Asignar Rutina - Parte del Administrador

El primer paso para elaborar una plan de entrenamiento a un cliente, es asignar

un nombre a la rutina, y definir las pautas, u observaciones, a tener en cuenta por

parte del cliente, durante la realización de dicha rutina. Para hacer esto, sólo tenemos

que rellenar los campos que se muestran más arriba, y pulsar en el botón indicado, lo

que nos llevará a la siguiente pantalla.

Asignar Ejercicios a la Rutina – Parte del Administrador

Ilustración 188 - MU: Asignar Ejercicios a la Rutina - Parte del Administrador



Como en el caso que comentábamos, de Asignar Alimentos a la Dieta, una vez

que completemos los datos que se piden para un ejercicio, pulsaremos ‘Añadir’,

repitiendo el proceso hasta que hayamos finalizado, cuando pulsaremos en ‘Finalizar’.

Mensajes Sin Leer – Parte del Administrador

Para poder consultar la bandeja de mensajes sin leer en cualquier momento, el

entrenador personal logueado puede acceder a la siguiente pantalla, en la que se

muestran todos los mensajes nuevos recibidos, de parte de otros usuarios de la

plataforma. Los mensajes están ordenados de manera descendente, de los más

antigüos a los más recientes.

Ilustración 189 - MU: Mensajes Sin Leer - Parte del Administrador

Para poder acceder al contenido del mensaje, y marcarlo como leido (Ver

Apartado Leer Mensaje – Parte del Cliente), sólo tenemos que pulsar el enlace bajo

el texto ‘Nuevo mensaje sin leer de:’ del mensaje que queramos consultar.

FIN



ANEXO II. DESCRIPCIÓN DE CONTENIDOS SUMINISTRADOS

El CD que se entrega está compuesto de los siguientes elementos:

- TFG_AntonioRuizAmate: Memoria del TFG (en PDF).

- AsesoriaDeportivaWeb: código fuente del proyecto.

- AsesoriaDeportivaWeb.war: paquete de la aplicación web.

- ADO_DB: archivos para copiar la base de datos.

- AsesoriaDeportivaWeb_Diagramas: documento de VisualParadigm en el

que se pueden encontrar todos los diagramas incluidos en esta memoria, y

alguno más.

- EspecificacionCasosDeUso: documento de Excel, en el que se puede

consultar la Especificación de todos los Casos de Uso existentes.

- TFG_AntonioRuizAmate.wmv: Vídeo descriptivo del funcionamiento de la

aplicación.

Ilustración 190 - Contenido del CD

aplicaciÓn web para el asesoramiento …tauja.ujaen.es/bitstream/10953.1/4215/1/tfg_ruiz_amate,...

Documents