R000001695 PDF

PROYECTO FIN DE CARRERA
Título
Aplicación web para la gestión de un hostal-restaurante
Autor/es
Pablo Cacho Zueco
Director/es
Laureano Lambán Pardo

Facultad
Facultad de Ciencias, Estudios Agroalimentarios e Informática

Titulación
Proyecto Fin de Carrera
Departamento
Matemáticas y Computación
Curso Académico
2012-2013
Aplicación web para la gestión de un hostal-restaurante, proyecto fin de carrera
de Pablo Cacho Zueco, dirigido por Laureano Lambán Pardo (publicado por la Universidad
de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
© El autor
© Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.es
E-mail: publicaciones@unirioja.es
UNIVERSIDAD DE LA RIOJA
Facultad de Ciencias, Estudios Agroalimentarios e Informática
PROYECTO FIN DE CARRERA

Ingeniería Técnica en Informática de Gestión
Aplicación web para la gestión de un hostal-

restaurante.
Alumno: Pablo Cacho Zueco

Director: Laureano Lambán Pardo
Logroño, Junio de 2013

RESUMEN
En este proyecto se quiere realizar una aplicación web para gestionar y explotar un hostal
restaurante. La aplicación creada permitirá realizar una gestión de usuarios, de pedidos al
restaurante y será capaz de proporcionar un sistema de reservas de habitaciones y mesas.
Este sistema permitirá a los clientes realizar pedidos online o reservar una habitación para
unas fechas concretas. Se le podrá pedir también a la aplicación que muestre una serie de
gráficas de estadísticas con datos relacionados con el negocio.
Esta aplicación no está destinada a un cliente concreto pero puede ser fácilmente
adaptable a multitud de pequeños y medianos hostales que buscan mostrarse en Internet.
ÍNDICE DE CONTENIDO
TABLA DE CONTENIDO
1 Introducción..........................................................................................................................1
1.1 Tema tratado ................................................................................................................ 1
1.2 Motivo de la elección .................................................................................................... 1
1.3 Límites ........................................................................................................................... 1
2 Documento de Objetivos.......................................................................................................2
2.1 Objeto ........................................................................................................................... 2
2.2 Antecedentes ................................................................................................................ 2
2.3 Alcance .......................................................................................................................... 2
2.4 Entregables ................................................................................................................... 3
2.5 Metodología de desarrollo ........................................................................................... 3
2.6 Tecnologías y herramientas a usar ............................................................................... 3
2.7 Recursos humanos y comunicaciones .......................................................................... 4
2.8 Riesgos y planes de acción ............................................................................................ 4
2.8.1 Posibles riesgos ..................................................................................................... 4
2.8.2 Planes de acción ................................................................................................... 4
2.9 Tareas ............................................................................................................................ 5
2.10 Plan de trabajo y temporización ............................................................................... 10
2.10.1 Calendario de trabajo ....................................................................................... 10
2.10.2 Estimación temporal ......................................................................................... 10
2.11 Diagrama Gantt ......................................................................................................... 13
3 Gestión de proyecto............................................................................................................15
3.1 Introducción ................................................................................................................ 15
3.2 Factores de retraso ..................................................................................................... 15
3.3 Primera replanificación ............................................................................................... 15
3.4 Segunda replanificación .............................................................................................. 16
3.5 Comparación estimado con resultados finales .......................................................... 16
3.5.1 Comparación fechas ........................................................................................... 16
3.5.2 Comparación horas ............................................................................................. 16
4 Análisis de requisitos...........................................................................................................18
4.1 Introducción ................................................................................................................ 18
I
4.1.1 Objetivo ................................................................................................................. 18
4.1.2 Ámbito ................................................................................................................... 18
4.1.3 Referencias ............................................................................................................ 18
4.1.4 Visión general del documento............................................................................... 18
4.2 Descripción general ....................................................................................................... 19
4.2.1 Perspectiva del producto ...................................................................................... 19
4.2.2 Funciones del producto ......................................................................................... 19
4.2.3 Características de los usuarios .............................................................................. 19
4.2.4 Restricciones.......................................................................................................... 19
4.3 Requisitos específicos .................................................................................................... 20
4.3.1 Requisitos funcionales ........................................................................................... 20
4.3.2 Requisitos de interfaz gráfica ................................................................................ 25
4.3.3 Requisitos de seguridad ........................................................................................ 26
4.3.4 Interfaces Externas ................................................................................................ 26
4.4 Casos de Uso Generales ................................................................................................ 27
5 Struts......................................................................................................................................29
5.1 Introducción .................................................................................................................. 29
5.2 Arquitectura MVC .......................................................................................................... 29
5.2.1 Introducción .......................................................................................................... 29
5.2.2 Vista ....................................................................................................................... 29
5.2.3 Modelo .................................................................................................................. 29
5.2.4 Controlador ........................................................................................................... 29
5.3 Componentes Struts ...................................................................................................... 30
5.3.1 API.......................................................................................................................... 30
5.3.2 Archivos de configuración ..................................................................................... 31
5.3.3 Etiquetas JSP .......................................................................................................... 32
5.4 Funcionamiento Struts .................................................................................................. 32
6 Ciclo 1..................................................................................................................................35
6.1 Análisis Ciclo 1................................................................................................................35
6.1.1 Análisis de requisitos ........................................................................................... ..35
6.1.1.1 Introducción .................................................................................................. 35
6.1.1.2 Usuarios involucrados ................................................................................... 35
6.1.1.3 Requisitos involucrados ................................................................................ 35
6.1.1.4 Casos de Uso ................................................................................................. 37
II
6.2 Diseño Ciclo 2..............................................................................................................42
6.2.1 Diseño de la arquitectura ................................................................................... 42
6.2.1.1 Introducción................................................................................................ 42
6.2.1.2 Arquitectura aplicada a nuestro sistema .................................................... 42
6.2.2 Clases de negocio................................................................................................ 43
6.2.2.1 Introducción................................................................................................ 43
6.2.2.2 Objetos de negocio ..................................................................................... 43
6.2.2.3 Clase de persistencia .................................................................................. 45
6.2.2.4 ActionForms................................................................................................ 46
6.2.2.5 Actions ........................................................................................................ 47
6.2.3 Diseño de la base de datos ................................................................................. 48
6.2.3.1 Introducción................................................................................................ 48
6.2.3.2 Requisitos de la base de datos ................................................................... 48
6.2.3.3 Diagrama de entidad-relación .................................................................... 48
6.2.3.4 Conversión a modelo relacional ................................................................. 49
6.2.3.5 Diagrama de tablas final ............................................................................. 50
6.2.4 Interfaces gráficas definitivas ............................................................................. 51
6.2.4.1 Login de usuario.......................................................................................... 51
6.2.4.2 Registro de usuario ..................................................................................... 52
6.2.4.3 Búsqueda de Usuario .................................................................................. 53
6.2.4.4 Administración Usuario .............................................................................. 55
6.2.4.5 Perfil de usuario .......................................................................................... 55
6.3 Implementación Ciclo 1...............................................................................................57
6.3.1 Tecnologías empleadas ....................................................................................... 57
6.3.2 Estructura de carpetas ........................................................................................ 57
6.3.3 Seguridad ............................................................................................................ 58
6.3.4 Código destacable ............................................................................................... 58
6.4 Pruebas Ciclo 1............................................................................................................64
6.4.1 Introducción ........................................................................................................ 64
6.4.2 Validación de formularios ................................................................................... 64
6.4.3 Pruebas Unitarias ................................................................................................ 66
6.4.3.1 Clases de equivalencia ................................................................................ 66
6.4.3.2 Casos de prueba ......................................................................................... 66
6.4.3.3 Resultado de pruebas ................................................................................. 69
III
7 Ciclo 2..................................................................................................................................70
7.1 Análisis Ciclo 2.............................................................................................................70
7.1.1 Análisis de requisitos .......................................................................................... 70
7.1.1.1 Introducción................................................................................................ 70
7.1.1.2 Usuarios involucrados................................................................................. 70
7.1.1.3 Requisitos involucrados .............................................................................. 70
7.1.1.4 Casos de Uso ............................................................................................... 73
7.2 Diseño Ciclo 2..............................................................................................................81
7.2.1 Diseño de la arquitectura .......................................................................... .........81
7.2.1.1 Introducción................................................................................................ 81
7.2.2 Clases de negocio................................................................................................ 81
7.2.2.1 Introducción................................................................................................ 81
7.2.2.2 Objetos de negocio ..................................................................................... 81
7.2.2.3 Clases de Persistencia ................................................................................. 82
7.2.2.4 ActionForms................................................................................................ 83
7.2.2.5 Actions ........................................................................................................ 84
7.2.3 Diseño de la base de datos ................................................................................. 86
7.2.3.1 Introducción................................................................................................ 86
7.2.3.2 Requisitos de la base de datos ................................................................... 86
7.2.3.3 Diagrama de entidad-relación .................................................................... 86
7.2.3.4 Conversión a modelo relacional ................................................................. 88
7.2.3.5 Diagrama de tablas final ............................................................................. 89
7.2.4 Interfaces gráficas definitivas ............................................................................. 90
7.3 Implementación Ciclo 2...............................................................................................94
7.3.1 Tecnologías empleadas ....................................................................................... 94
7.3.2 Estructura de carpetas ....................................................................................... .94
7.3.3 Código destacable .............................................................................................. .94
7.4 Pruebas Ciclo 2............................................................................................................96
7.4.1 Introducción ........................................................................................................ 96
7.4.2 Validación de formularios ................................................................................... 96
7.4.3 Pruebas Unitarias ................................................................................................ 96
7.4.3.1 Clases de equivalencia ................................................................................ 97
7.4.3.2 Casos de prueba ......................................................................................... 98
7.4.4 Resultado de las pruebas ................................................................................. .100
8 Ciclo 3.................................................................................................................................101
IV
8.1 Análisis Ciclo 3...........................................................................................................101
8.1.1 Análisis de requisitos ........................................................................................ 101
8.1.1.1 Introducción.............................................................................................. 101
8.1.1.2 Usuarios involucrados............................................................................... 101
8.1.1.3 Requisitos involucrados ............................................................................ 101
8.1.1.4 Casos de Uso ............................................................................................. 105
8.2 Diseño Ciclo 3............................................................................................................118
8.2.1 Diseño de la arquitectura ................................................................................. 118
8.2.1.1 Introducción.............................................................................................. 118
8.2.2 Clases de negocio.............................................................................................. 118
8.2.2.1 Introducción.............................................................................................. 118
8.2.2.2 Objetos de negocio ................................................................................... 118
8.2.2.3 Clases de Persistencia ............................................................................... 119
8.2.2.4 ActionForms.............................................................................................. 120
8.2.2.5 Actions ...................................................................................................... 121
8.2.3 Diseño de la base de datos ............................................................................... 124
8.2.3.1 Introducción.............................................................................................. 124
8.2.3.2 Requisitos de la base de datos relativos al ciclo3 ..................................... 124
8.2.3.3 Diagrama de entidad-relación .................................................................. 124
8.2.3.4 Conversión a modelo relacional ............................................................... 125
8.2.3.5 Diagrama de tablas final ........................................................................... 127
8.2.4 Interfaces gráficas ............................................................................................. 127
8.2.4.1 Gráfica representativa de ocupación del hostal un determinado año ..... 127
8.2.4.2 Gráfica representativa de ocupación del hostal un determinado día ...... 128
8.2.4.3 Menú principal de la gestión de habitaciones y comedor........................ 129
8.2.4.4 Página de selección de fechas para una reserva de habitación ............... 129
8.2.4.5 Parte de la página de creación de gráficas estadísticas........................... 130
8.3 Implementación Ciclo 3............................................................................................132
8.3.1 Tecnologías empleadas ..................................................................................... 132
8.3.2 Estructura de carpetas ...................................................................................... 132
8.3.3 Código destacable ............................................................................................. 133
8.4 Pruebas Ciclo 3...........................................................................................................137
8.4.1 Introducción ...................................................................................................... 137
8.4.2 Validación de formularios ................................................................................. 137
8.4.3 Pruebas Unitarias ............................................................................................. .137
V
8.4.3.1 Clases de equivalencia .............................................................................. 137
8.4.3.2 Casos de prueba ....................................................................................... 137
8.4.4 Resultado pruebas ............................................................................................ 140
9 Pruebas finales..................................................................................................................141
9.1 Pruebas de integración ............................................................................................. 141
9.2 Pruebas de sistema ................................................................................................... 142
10 Conclusiones....................................................................................................................143
10.1 Comparativa entre objetivos y resultados obtenidos ............................................. 143
10.2 Posibles mejoras y ampliaciones ............................................................................ 144
10.3 Visión personal ........................................................................................................ 144
11 Glosario de términos.......................................................................................................145
12 Bibliografía......................................................................................................................146
13 Anexos.............................................................................................................................147
13.1 Diseño Web ............................................................................................................ .147
13.1.1 Introducción ................................................................................................... .147
13.1.2 Proceso ........................................................................................................... 147
13.1.3 Imágenes......................................................................................................... 147
13.2 Ley orgánica de protección de datos ...................................................................... 147
13.3 Manual de instalación y despliegue ........................................................................ 148
13.3.1 Introducción .................................................................................................... 148
13.3.2 Requisitos........................................................................................................ 148
13.3.3 Base de datos, mysql y apache ....................................................................... 148
13.3.4 Instalación de servidor de aplicaciones web y despliegue ............................. 150
13.4 Manual de administrador y usuario ........................................................................ 151
13.4.1 Introducción .................................................................................................... 151
13.4.2 Visitante .......................................................................................................... 151
13.4.3 Usuario ............................................................................................................ 152
13.4.4 admingeneral .................................................................................................. 157
13.4.5 admincocina .................................................................................................... 161
13.4.6 adminrecepción .............................................................................................. 165
VI
ÍNDICE DE ILUSTRACIONES
Ilustración 1: Esquema división de tareas................................................................................ 9
Ilustración 2: Esquema división de tareas por ciclo ............................................................... 10
Ilustración 3: Tabla de duraciones estimadas ........................................................................ 13
Ilustración 4: Diagrama Gantt Inicial ...................................................................................... 13
Ilustración 5 : Diagrama de Gantt Ciclo 1............................................................................... 13
Ilustración 6: Diagrama Gantt Ciclo 2 .................................................................................... 14
Ilustración 7: Diagrama Gantt Ciclo 3 .................................................................................... 14
Ilustración 8: Diagrama Gant Replanificación 1 ..................................................................... 15
Ilustración 9: Diagrama Gantt Replanificación 2 .................................................................... 16
Ilustración 10: Tabla Comparativa de fechas ......................................................................... 16
Ilustración 11: Tabla Comparativa de horas .......................................................................... 17
Ilustración 12: Gráfica comparación horas ............................................................................ 17
Ilustración 13: Diagrama Casos de Uso General .................................................................... 27
Ilustración 14: Esquema MVC ................................................................................................ 30
Ilustración 15: Estructura XML form-bean ............................................................................. 32
Ilustración 16: Esquema estructural Struts ............................................................................ 34
Ilustración 17: Diagrama Casos Uso Ciclo 1 ........................................................................... 37
Ilustración 18: Diagrama Actividad Modificar usuario ........................................................... 40
Ilustración 19: Diagrama Clases Usuarios Ciclo 1................................................................... 44
Ilustración 20: Diagrama Clases 2 Ciclo 1 ............................................................................... 44
Ilustración 21: Diagrama Clase LoginBD................................................................................. 45
Ilustración 22: Diagrama Clase UsuariosBD ........................................................................... 46
Ilustración 23: Esquema FormBeans Ciclo 1 .......................................................................... 47
Ilustración 24: Tabla Actions Ciclo 1 ...................................................................................... 47
Ilustración 25: Esquema EER Ciclo 1 ...................................................................................... 49
Ilustración 26: Diagrama Tablas Ciclo 1 ................................................................................. 51
Ilustración 27: Interfaz login de usuario ................................................................................ 52
Ilustración 28: Interfaz registro de usuario ............................................................................ 53
Ilustración 29:Interfaz Búsqueda de usuarios ........................................................................ 54
Ilustración 30: Interfaz administración de usuarios............................................................... 55
Ilustración 31:Interfaz datos de usuario ................................................................................ 56
Ilustración 32: Código Hibernate Filtrar Usuarios .................................................................. 60
Ilustración 33: Código Login Usuario Action .......................................................................... 61
Ilustración 34: Código Login Usuario BD ................................................................................ 62
Ilustración 35: Código Javascript confirmación borrado de usuario...................................... 62
Ilustración 36: Código html confirmación borrado de usuario .............................................. 63
Ilustración 37: Interfaz validación login ................................................................................. 64
Ilustración 38: Interfaz validación captcha ............................................................................ 65
Ilustración 39: Diagrama Casos Uso Ciclo 2 ........................................................................... 73
Ilustración 40: Diagrama Secuencia Realizar Pedido ............................................................. 76
VII
Ilustración 41: Diagrama clases ciclo 2 .................................................................................. 82
Ilustración 42: Diagrama Clases BD Ciclo 2 ............................................................................ 82
Ilustración 43:Diagrama FormBeans Ciclo 2 .......................................................................... 83
Ilustración 44: Esquema EER Ciclo 2 ...................................................................................... 87
Ilustración 45: Esquema Tablas Ciclo 2 .................................................................................. 89
Ilustración 46: Interfaz Carta productos ................................................................................ 90
Ilustración 47:Interfaz carro pedido ...................................................................................... 91
Ilustración 48: Interfaz Resumen confirmación pedido ......................................................... 92
Ilustración 49: Interfaz Configuración pedidos ...................................................................... 93
Ilustración 50: Código carro html........................................................................................... 94
Ilustración 51: Código DisplayTag .......................................................................................... 95
Ilustración 52: Interfaz validación formulario alta producto ................................................. 96
Ilustración 53: Diagrama Casos Uso Ciclo 3 ......................................................................... 105
Ilustración 54:Diagrama Secuencia Reserva Habitación ...................................................... 108
Ilustración 55: Diagrama secuencia Reserva sitio restaurante ............................................ 112
Ilustración 56: Diagrama Casos Uso Estadísticas ................................................................. 114
Ilustración 57: Diagrama Clases Ciclo 3................................................................................ 119
Ilustración 58: Diagrama Clases BD Ciclo 3 .......................................................................... 120
Ilustración 59: Tabla Actions Habitaciones .......................................................................... 121
Ilustración 60: Tabla Actions Reservas Habitaciones ........................................................... 122
Ilustración 61: Tabla Actions Reservas Comedor ................................................................. 123
Ilustración 62: Tabla Actions Estadísticas ............................................................................ 123
Ilustración 63: Esquema EER Ciclo 3 .................................................................................... 125
Ilustración 64: Diagrama Tablas Ciclo 3 ............................................................................... 127
Ilustración 65: Interfaz Gráfica Tipo Ocupación hostal ........................................................ 128
Ilustración 66: Interfaz Gráfica % Ocupación Hostal ............................................................ 128
Ilustración 67: Interfaz Administración hostal ..................................................................... 129
Ilustración 68: Interfaz Elección Fechas Reserva Habitación ............................................... 130
Ilustración 69: Interfaz Generación Gráficas........................................................................ 131
Ilustración 70: Código Action Gráfica ................................................................................... 134
Ilustración 71: Interfaz Calendario ....................................................................................... 135
Ilustración 72: Código envío email ....................................................................................... 136
Ilustración 73: Recorte de pantalla de Xampp ..................................................................... 149
Ilustración 74: Recorte de myphpadmin.............................................................................. 149
Ilustración 75 : Pantalla del servidor GlassFish .................................................................... 150
Ilustración 76: Pantalla de información del hostal .............................................................. 151
Ilustración 77: Pantalla de registro de usuario .................................................................... 152
Ilustración 78: Perfil de usuario ........................................................................................... 152
Ilustración 79: Listado de productos a la venta ................................................................... 153
Ilustración 80: Resumen del pedido..................................................................................... 153
Ilustración 81: Elección de fechas de reserva de habitación ............................................... 154
Ilustración 82: Habitaciones libres para unas fechas ........................................................... 154
Ilustración 83: Resumen de reserva de habitación .............................................................. 155
Ilustración 84: Elección de datos para reserva de comedor. ............................................... 155
VIII
Ilustración 85: Confirmación de reserva de comedor.......................................................... 156
Ilustración 86: Pantalla de listados de pedidos .................................................................... 156
Ilustración 87: Pantalla de listados de reservas. .................................................................. 157
Ilustración 88: Pantalla de administración de usuarios ....................................................... 157
Ilustración 89: Pantalla de listado de usuarios .................................................................... 158
Ilustración 90: Pantalla de administración del hostal .......................................................... 159
Ilustración 91: Página de generación de gráficas ................................................................. 160
Ilustración 92: Menú administración cocina ........................................................................ 161
Ilustración 93: Pantalla administración de pedidos ............................................................. 162
Ilustración 94: Pantalla de finalización de pedido ............................................................... 162
Ilustración 95: Configuración de sistema de pedidos .......................................................... 163
Ilustración 96: Pantalla de administración de comedor ...................................................... 163
Ilustración 97: Listado de reservas de comedor .................................................................. 164
Ilustración 98: Finalización de reserva de comedor. ........................................................... 164
Ilustración 99: Menú administración de la recepción.......................................................... 165
Ilustración 100: Listado de reservas de habitación abiertas ................................................ 165
Ilustración 101: Resumen de reserva de habitación a finalizar ........................................... 166
IX
1. INTRODUCCIÓN
1.1 TEMA TRATADO
Este proyecto pretende abordar el desarrollo de una aplicación web que sirva de ayuda en
la gestión de un hostal restaurante. La aplicación ofertará unos servicios a los clientes
interesados en hacer un pedido de restaurante, reservar una habitación o una mesa. También
mostrará una serie de gráficas estadísticas y unos historiales de reservas o pedidos.
1.2 MOTIVO DE LA ELECCIÓN
El motivo de elegir este proyecto fue debido a que prefería terminar la carrera haciendo
algo relacionado con la programación web. La elección del tema de hostal-restaurante no tiene
una causa concreta, simplemente me pareció un tema interesante al haber miles de pequeños
hostales con servicio de restaurante a los que podría ser útil una aplicación de este estilo.
Asimismo me resultaría útil ya que la programación web está muy demandada y tiene
bastantes salidas en la actualidad. Esto es debido al aumento del acceso y uso de internet que
ha hecho que multitud de empresas quieran hacer negocio mediante un portal web.
1.3 LÍMITES
Los límites de este proyecto serán puestos por nosotros mismos al no tener un cliente
concreto que nos marque las directrices.
El problema estará tanto en no quedarse corto en los requisitos del sistema ni tampoco
pasarse a la hora de fijar los objetivos. Se buscará un término medio dictando unos mínimos
aceptables que debe tener todo proyecto fin de carrera y que den lugar a una aplicación
bastante completa.
1
2. DOCUMENTO DE OBJETIVOS
2.1 OBJETO
El objetivo del proyecto es la creación de un portal web para la gestión, control y

explotación de un hostal restaurante.
Esta aplicación contará con diferentes secciones dirigidas a distintos tipos de usuario según
el uso que le vayan a dar, desde los administradores del hostal hasta internautas que se
registran en la web para poder acceder a diferentes servicios que ofrece el hostal-restaurante.
A pesar de basarse en un caso bastante concreto se pretende buscar en la medida de lo

posible, generalidad y fácil adaptación a otros posibles hostales o negocios similares.
2.2 ANTECEDENTES
Con el boom de Internet se han extendido de manera muy rápida multitud de negocios que
tratan de ganar mercado ofertándose en la web. Entre ellos en España destacan los
relacionados con el turismo y la gastronomía. Así que no es difícil encontrarse con varias
soluciones en el mercado parecidas a lo que se quiere hacer en este proyecto.
Por ejemplo, en el ámbito de sistemas para gestionar hostales u hoteles podemos ver:
 http://www.themovie.org/es/15/30/motor-de-reservas-on-line-para-hoteles.html
 http://www.turisoft.com/
 Páginas con buscadores tipo http://www.hostels.com/es/
No se pretende hacer nada revolucionario sino que la motivación reside en ser capaz de
plantear y finalizar algo parecido. Como novedad podemos decir que así como hay multitud de
webs de reservas de hostal, no es tan fácil encontrar webs que combinen la reserva de
habitaciones junto con un servicio de restaurante y pedidos. Esto unido a la personalización
con información general de un hostal nos hace creer que puede resultar interesante continuar
con la idea de la creación del proyecto a pesar de las alternativas disponibles.
2.3 ALCANCE
La aplicación atenderá las peticiones de diferentes roles de usuarios. A continuación se

enumeran las funciones que deberán ser cubiertas:
 Mostrar información del hostal: tarifas, situación geográfica, habitaciones.

 Gestión de reservas online: habitaciones y comedor.
 Gestión de pedidos de productos de restaurante online.
2
 Gestión de usuarios: registro obligatorio de clientes para reservas y pedidos, diferentes
permisos para el personal y administradores del hostal.
 Historiales: historial de pedidos, reservas de habitaciones y reservas de mesas del
comedor.
 Estadísticas: diferentes gráficas con estadísticas del hostal-restaurante.
No se abordarán temas como las transacciones económicas con los clientes, ni la gestión de
stock y productos usados en el hostal.
La aplicación contará con una base de datos donde se guardarán todos los registros
necesarios para el correcto funcionamiento del servicio.
2.4 ENTREGABLES
Los entregables del proyecto serán:

 Memoria.
 Código fuente.
 Manual de instalación.
2.5 METODOLOGÍA DE DESARROLLO
Se usará como metodología de desarrollo el Proceso Unificado. Se ha escogido ya que se

considera que es la que mejor se adaptará a las necesidades del proyecto y por ser la que más
se ha incidido en las asignaturas de la carrera.
El utilizar un ciclo de vida iterativo e incremental permitirá añadir y mejorar la aplicación a

la vez que crece obteniendo en cada ciclo un producto funcional.
Los esquemas y diagramas se harán fundamentalmente en UML.
2.6 TECNOLOGÍAS Y HERRAMIENTAS A USAR
Durante la creación del proyecto se van a utilizar las siguientes herramientas:
 Java EE -> Plataforma de Programación para desarrollar software.

 JSP -> Tecnología Java que permite generar código dinámico en la web. Se ha
preferido elegir JSP por encima de PHP debido al interés en profundizar más en este
lenguaje.
 JDBC -> API para ejecutar operaciones sobre bases de datos bajo el lenguaje Java.
 MySQL -> Sistema gestor de bases de datos libre, se ha elegido por su alta difusión y
uso en la programación web.
 Glassfish Server-> Servidor que permitirá desplegar y ejecutar nuestras aplicaciones.
 Struts -> Framework que implementa el patrón MVC. Se desea usarlo debido a que en
3
la carrera se incide en una programación más pura y vendrá bien aprender algo más
práctico como es el uso de Frameworks.
 Poseidon -> Potente software para generar diagramas UML
2.7 RECURSOS HUMANOS Y COMUNICACIONES
En el desarrollo del proyecto participarán las siguientes personas:
Pablo Cacho: alumno de ITIG, será el desarrollador único y principal, se encargará de la

creación, documentación y presentación de todo el proyecto.
Laureano Lamban: director del alumno.
Durante el periodo que dure el proyecto, alumno y tutor se comunicaran mediante email y
podrán concertar diferentes reuniones en el despacho del profesor para comprobar el avance
del proyecto o resolver dudas.
2.8 RIESGOS Y PLANES DE ACCIÓN
Se van a tratar de identificar los factores que puedan suponer retrasos y demoras en el
desarrollo del proyecto. Además de clasificar estos riesgos se propondrán unos planes de
acción con las medidas a tomar para contrarrestarlos.
2.8.1 POSIBLES RIESGOS
1. El primer factor sería la inexperiencia del alumno en la creación de proyectos del

tamaño requerido para este proyecto fin de carrera. Esta inexperiencia podrá suponer
una mala planificación de fechas al calcular mal el tiempo exigido para cada tarea.
2. El segundo factor es el desconocimiento de alguna de las herramientas a utilizar. Esto
podría suponer un estancamiento en el desarrollo de alguna tarea.
3. Otro factor clave son las causas de índole personal. Pueden surgir impedimentos de
trabajo, enfermedades, viajes que resten horas de desarrollo al alumno.
4. Problemas de hardware o software que supongan una pérdida de datos o tiempo al
tener que desplegar todas las herramientas del proyecto en otro ordenador distinto al
habitual.
5. También puede ocurrir que una vez finalizado el proyecto no sea del agrado del
director.
2.8.2 PLANES DE ACCIÓN
4
A continuación se van a exponer los planes de acción resultantes a los riesgos planteados
en el apartado anterior:
1. Se buscará información y se consultará otros proyectos parecidos con el fin de obtener

más idea sobre los tiempos que requiere un proyecto de estas características.
2. Para evitar retrasos debido al uso de nuevas herramientas se planificará un tiempo de
aprendizaje y recogida de información y ejemplos de las principales herramientas a
utilizar.
3. Los factores personales son más difíciles de detectar, en este caso se hará uso de la
replanificación de tareas y horas dedicadas al proyecto.
4. Para evitar la pérdida de datos se utilizarán como respaldo pendrives y un sistema de
almacenamiento de datos en la nube como DropBox.
5. Se irá enseñando el proyecto conforme aumenten las funcionalidades.
2.9 TAREAS
El proyecto se va a descomponer en una serie de tareas bien diferenciadas como forma de

ordenar todo lo que se debe hacer y poder asignar unos tiempos a cada una de ellas.
Se mostrarán a continuación la descripción de estas tareas y unos esquemas

representativos.
TAREA 1: SEGUIMIENTO DEL PROYECTO
La tarea número 1 es la relativa al control y revisiones del proyecto a lo largo de todo su

desarrollo. Esta tarea tiene el objetivo de mantener un seguimiento periódico de los plazos y
los posibles cambios en la planificación mediante revisiones.
TAREA 2: GENERACIÓN MEMORIA
La segunda tarea va a estar dedicada a la generación de la memoria del proyecto. Durante

la creación de la aplicación se debe documentar las decisiones tomadas, el modo en el que
hemos hecho el proyecto usando las técnicas de desarrollo vistas durante la carrera.
Se ha dividido en 6 subtareas:
 Creación DOP: El Documento de objetivos del proyecto es uno de los más importantes,
por esto ha sido incluido como una subtarea a destacar.
 Ciclo 1, Ciclo 2 y Ciclo 3: Partes de la memoria referidas a cada ciclo.
 Redacción resto memoria: Partes de la memoria no contenidas en las anteriores. Por
ejemplo posibles anexos, introducción, conclusiones…
5
 Revisión memoria: En esta subtarea se revisará toda la memoria para detectar
posibles errores antes de la entrega.
TAREA 3: PREPARACIÓN PREVIA
La tercera tarea que se ha identificado es la preparación previa. Esta tarea está sobretodo
enfocada al estudio previo de las herramientas no vistas hasta ahora.
Se estudiará que sistema se quiere crear, qué herramientas se pueden usar para llevar a
cabo con éxito el proyecto. Y se comprobará la viabilidad viendo si es posible hacer el proyecto
con las herramientas encontradas.
Está separada en 3 subtareas:
 Estudio del sistema: Se mirará que tipo de sistema se desea crear y que herramientas
hay disponibles para realizarlo.
 Estudio de herramientas: Se estudiarán las herramientas que se han considerado
idóneas para el desarrollo del proyecto si no se han utilizado nunca antes.
 Estudio viabilidad: Se comprueba que el proyecto se puede realizar con las
herramientas estudiadas.
TAREA 4: ESPECIFICACIÓN DE REQUISITOS
Esta cuarta tarea es la creación del documento de requisitos. Se extraen en él todos los
requisitos fundamentales que debe cumplir el sistema. Se enumerarán y describirán
correctamente para identificarlos a medida que vayamos avanzando en el proyecto.
TAREA 5, 6 Y 7: CICLO 1, CICLO 2 Y CICLO 3
Las tareas 5, 6 y 7 se agrupan debido a las similitudes entre las tres. Representan a cada
uno de las iteraciones del proyecto. Al final de cada ciclo se tendrá una aplicación parcial pero
funcional.
Cada tarea y ciclo consta de Análisis, Diseño, Implementación y Pruebas.
TAREA 8: PRUEBAS FINALES
La tarea de pruebas finales es la que se realizará una vez que los 3 ciclos estén concluidos.
Tiene como misión detectar fallos que se hayan pasado por alto y hacer nuevas pruebas al
ejecutar los 3 ciclos conjuntamente.
6
Además servirá para dar por finalizada toda la implementación y para poder afirmar que el
sistema cumple todos los requisitos planteados al comienzo del proyecto.
TAREA 9: DOCUMENTACIÓN FINAL
La novena tarea es la redacción de un manual de instalación de la aplicación. Este manual

servirá para explicar cómo desplegar el proyecto correctamente en un equipo.
TAREA 10: DEFENSA
La última tarea será la relacionada con la defensa del proyecto del alumno. Se creará una
presentación para mostrar el resumen de todo el proceso de creación del proyecto.
Y finalmente se realizará la defensa ante los miembros del tribunal.
7
Ilustración 1: Esquema división de tareas
9
Ilustración 2: Esquema división de tareas por ciclo
9
2.10 PLAN DE TRABAJO Y TEMPORIZACIÓN
2.10.1 CALENDARIO DE TRABAJO
En el momento que se ha hecho la planificación se dispone de disponibilidad total para

realizar el proyecto.
Se pondrá un horario de trabajo de varias horas al día dedicadas al mismo. Si hubiera algún
cambio en el transcurso del proyecto se indicaría en el apartado de replanificación en gestión
de proyecto.
2.10.2 ESTIMACIÓN TE MPORAL
En la siguiente tabla se observan las diferentes tareas y unas fechas y horas aproximadas
para su realización, en la parte de arriba de cada sección se muestran las horas acumuladas y
abajo las horas desglosadas:
DURACIÓN
INICIO FIN
TAREAS ESTIMADA
PREVISTO PREVISTO
(horas)
Seguimiento del proyecto 16 16/02/12 07/06/12
Reuniones 7 16/02/12 07/06/12
Planificación 9 16/02/12 07/06/12
Generación memoria 107 16/02/12 07/06/12
Creación DOP 14 16/02/12 20/02/12
Ciclo 1 20 29/02/12 23/03/12
Ciclo 2 25 26/03/12 23/04/12
Ciclo 3 32 24/04/12 03/06/12
Redacción resto memoria 10 03/06/12 05/06/12
Revisión memoria 6 05/06/12 07/06/12
Preparación previa 29 21/02/12 27/02/12
Estudio del sistema 3 21/02/12 21/02/12
Estudio de herramientas 25 22/02/12 27/02/12

Estudio viabilidad 1 27/02/12 27/02/12
Especificación de requisitos 6 28/02/12 28/02/12
Generación del documento de requisitos 6 28/02/12 28/02/12
10
Ciclo 1 142 29/02/12 23/03/12
Análisis 7 29/02/12 01/03/12
Casos de uso 2 29/02/12 29/02/12
Actividad y secuencia 5 01/03/12 01/03/12
Diseño 35 02/03/12 10/03/12
Diseño clases de negocio 8 02/03/12 05/03/12
Identificar clases y métodos 4 02/03/12 02/03/12
Diagrama de clases 4 05/03/12 05/03/12
Diseño BD 4 06/03/12 06/03/12
Creación diagrama ER 4 06/03/12 06/03/12
Diseño Web 23 07/03/12 10/03/12
Identificar páginas 3 07/03/12 07/03/12
Diseñar páginas 20 08/03/12 10/03/12
Implementación 95 12/03/12 22/03/12
Implementar código 90 12/03/12 22/03/12
Implementar BD 3 12/03/12 22/03/12
Documentar código y BD 2 12/03/12 22/03/12
Pruebas 5 23/03/12 24/03/12
Pruebas unitarias 5 23/03/12 24/03/12
Ciclo 2 169 26/03/12 23/04/12
Análisis 11 26/03/12 27/03/12
Casos de uso 4 26/03/12 26/03/12
Diseño 30 28/03/12 04/04/12
Diseño BD 5 30/03/12 30/03/12
Diseño Web 13 02/04/12 04/04/12
Diseñar páginas 10 02/04/12 04/04/12
11
Implementación 121 05/04/12 20/04/12
Implementar BD 3 05/04/12 20/04/12
Pruebas 7 23/04/12 23/04/12
Pruebas integración 2 23/04/12 23/04/12
Ciclo 3 217 24/04/12 03/06/12
Análisis 19 24/04/12 26/04/12
Casos de uso 7 24/04/12 24/04/12
Diseño 33 27/04/12 03/05/12
Diseño BD 6 30/04/12 30/04/12
Diseño Web 15 01/05/12 02/05/12
Diseñar páginas 12 01/05/12 02/05/12
Implementación 158 03/05/12 01/06/12
Implementar BD 3 03/05/12 01/06/12
Pruebas 7 02/06/12 03/06/12
Pruebas integración 2 03/06/12 03/06/12
Pruebas finales 3 04/06/12 04/06/12
Pruebas de aceptación 3 04/06/12 04/06/12
Documentación final 4 04/06/12 06/06/12
Crear manual instalación 4 04/06/12 06/06/12
Defensa del proyecto 11 06/06/12 xx/06/12
12
Preparación 10 06/06/12 xx-6-12
Defensa 1 xx-6-12 xx-6-12
TOTAL 704 16/02/12 xx-6-12
Ilustración 3: Tabla de duraciones estimadas
2.11 DIAGRAMA GANTT
A continuación se muestran varios diagramas de Gantt con la planificación inicial del

proyecto.
Ilustración 4: Diagrama Gantt Inicial
Ilustración 5 : Diagrama de Gantt Ciclo 1
13
Ilustración 6: Diagrama Gantt Ciclo 2
Ilustración 7:Diagrama Gantt Ciclo 3
14
3. GESTIÓN DE PROYECTO
3.1 INTRODUCCIÓN
El desarrollo del proyecto ha sido afectado por diversos factores que han condicionado mi
dedicación al mismo.
Debido a que no se han podido cumplir con las horas planificadas para la realización del
proyecto se ha tenido que realizar unas replanificaciones ajustando nuevas fechas para la
finalización de las tareas.
3.2 FACTORES DE RETRASO
El motivo del retraso han sido tanto factores personales como de trabajo, que han hecho
que no se pudieran dedicar en el proyecto las horas necesarias para su desarrollo. No he
podido llevar un ritmo adecuado de horas diarias, lo que ha provocado un abandono del
proyecto durante unos meses.
Se ha producido también una lectura demasiado optimista de trabajo diario y no han sido
cumplidas por mi parte las horas dedicadas.
3.3 PRIMERA REPLANIFICACIÓN
En la replanificación se retocará las fechas de finalización de cada parte del proyecto

afectado por el retraso. Las horas estimadas no necesitarán excesivos cambios.
El proyecto estaba planificado para ser entregado en el curso pasado apurando la fecha
límite de depósito, sin embargo, al no dedicar las horas diarias necesarias las fechas de
finalización de las tareas se iban retrasando. Esto provocó que para la fecha final estimada en
Junio, solo estuvieran finalizados los ciclos 1 y 2.
Ilustración 8: Diagrama Gant Replanificación 1
15
3.4 SEGUNDA REPLANIFICACIÓN
Con el ciclo 3 prácticamente acabado surgen nuevos problemas de trabajo en la dedicación

al proyecto. Se retrasa y paraliza durante meses y se fija la finalización y entrega para
principios de Junio de 2013. El número de horas estimadas no es muy distinto del real, lo que
varía mucho es el número de horas diarias dedicadas.
Ilustración 9: Diagrama Gantt Replanificación 2
3.5 COMPARACIÓN ESTIMADO CON RESULTADOS FINALES
3.5.1 COMPARACIÓN FE CHAS
Tarea Fecha fin Fecha fin Fecha fin Fecha

estimada replanificación 1 replanificación 2 final real
Seguimiento 07/06/12 10/09/12 31/05/13 23/06/13
Memoria 07/06/12 10/09/12 31/05/13 23/06/13
Preparación 27/02/12 - - 15/03/12
Requisitos 28/02/12 - - 20/03/12
Ciclo 1 24/03/12 - - 30/04/12
Ciclo 2 23/06/12 - - 01/06/12
Ciclo 3 03/06/12 03/09/12 24/05/13 01/06/13
Pruebas 03/06/12 05/09/12 31/05/13 23/06/13
finales
Manual 07/06/12 08/09/12 31/05/13 23/06/13
Ilustración 10: Tabla Comparativa de fechas
3.5.2 COMPARACIÓN HORAS
Tarea Horas Horas reales

estimadas
Seguimiento 16 12
Memoria 107 120
Preparación 29 35
16
Requisitos 6 12
Ciclo 1 142 130
Ciclo 2 169 140
Ciclo 3 217 200
Pruebas finales 3 4
Manual 4 3
TOTAL 693 656
Ilustración 11: Tabla Comparativa de horas
Ilustración 12: Gráfica comparación horas
17
2. ANÁLISIS DE REQUISITOS
4.1 INTRODUCCIÓN
4.1.1 OBJETIVO
Se pretende realizar una aplicación web que ayude en la gestión, administración y

explotación de un hostal. A través del portal se mostrarán los servicios ofertados por el
negocio con el fin de atraer nuevos clientes.
Asimismo servirá para gestionar y llevar un mejor control del hostal guardando información
sobre los hospedados y gestionando nuevos pedidos o reservas.
4.1.2 ÁMBITO
La aplicación permitirá la gestión del hostal y de los usuarios registrados en el mismo. La

gestión de reservas de habitaciones y reservas de sitio en el comedor. También se tramitarán
los pedidos de productos que ofrece el restaurante. Además se mostrarán una serie de
estadísticas al administrador general del hostal.
4.1.3 REFERENCIAS
Se ha seguido la norma IEEE STD 830 1998 para la elaboración de esta especificación de
requisitos.
4.1.4 VISIÓN GENERAL DEL DOCUMENTO
En este documento se recogerán los requisitos que deberá satisfacer la aplicación una vez
esté terminada.
Debido a que es un proyecto de varios ciclos e incrementos aquí se van a citar unos
requisitos generales que podrían ser retocados o depurados en cada una de las iteraciones del
proyecto.
18
4.2 DESCRIPCIÓN GENERAL
4.2.1 PERSPECTIVA DEL PRODUCTO
El sistema no formará parte de ningún otro mayor, solo interaccionará con una base de
datos MySQL para almacenar la información de los usuarios y el hostal.
4.2.2 FUNCIONES DEL PRODUCTO
La aplicación constará de 2 funciones claramente separadas, la administración del hostal-

restaurante y la explotación del mismo. En la primera participarán los administradores y en la
segunda los usuarios que quieran acceder a algún servicio.
4.2.3 CARACTERÍSTICAS DE LOS USUARIOS
Los usuarios que utilizarán el sistema podrán ser internautas que quieran hacer pedidos o
reservas, adaptados ya a las nuevas tecnologías del comercio por Internet. Los otros usuarios
serán los administradores del hostal, a los que la aplicación no les causará ninguna dificultad
debido a su simplicidad.
En los administradores separaremos estos 3 tipos:
 AdminGeneral: representaría al “dueño” del hostal, podrá ver estadísticas del mismo,
así como controlar con la aplicación las habitaciones, los usuarios o el comedor del
restaurante.
 AdminRecepción: estaría en la entrada del hostal, por lo que se ocuparía de la entrada
y salida de clientes con reserva de habitación.
 AdminCocina: sería el encargado de gestionar los pedidos online y los productos
ofertados para la compra. El control de las reservas del comedor también estaría en
sus cometidos.
4.2.4 RESTRICCIONES
Las restricciones serán el uso de contraseña para el acceso a la aplicación y el uso de roles
como medio para mostrar a cada tipo de usuario unos menús distintos.
19
4.3 REQUISITOS ESPECÍFICOS
A continuación se enumerarán los requisitos generales que deberá cumplir la aplicación

una vez que esté terminada. Se empezará con los requisitos funcionales siguiendo con los
relacionados con la interfaz y seguridad.
4.3.1 REQUISITOS FUNCIONALES
La aplicación deberá ser capaz de poder efectuar las tareas de los siguientes requisitos:
RF1
Introducción: Un visitante de la web podrá darse de alta en el sistema.

Precondición: El visitante no debe estar dado de alta.
Entradas: El visitante va a darse de alta.
Procedimiento: El usuario informa al sistema de que tiene intención de registrarse e
introduce sus datos.
Salidas: Se dará de alta al usuario al que se le mandará un email y se mostrará un mensaje
confirmando el registro.
RF2
Introducción: Un usuario podrá gestionar sus datos.

Precondición: El usuario debe de estar dado de alta y debe haber iniciado sesión.
Entradas: El usuario quiere ver/modificar sus datos o borrar su cuenta.
Procedimiento: El usuario va a su perfil, donde hará los cambios y acciones oportunas.
Salidas: Se realizará la acción correspondiente y se informará de la finalización con éxito de
la misma.
RF3
Introducción: Un administrador podrá gestionar usuarios.

Precondición: El administrador debe de estar dado de alta y se debe haber logueado.
Entradas: El administrador desea crear/modificar o borrar un usuario o listarlos.
Procedimiento: El usuario va al apartado dedicado a la gestión de usuarios, donde hará la
acción que desee.
Salidas: Se realizará la acción indicada y se mostrará el éxito.
RF4
Introducción: Un usuario podrá obtener una nueva contraseña.
20
Precondición: El usuario debe de estar dado de alta.
Entradas: El usuario desea conseguir una nueva contraseña.
Procedimiento: El usuario pide a la aplicación obtener una nueva contraseña.
Salidas: Se cambiará la contraseña y se le enviará al usuario.
RF5
Introducción: Un AdminCocina podrá gestionar los productos del hostal.

Precondición: El AdminCocina debe de estar dado de alta y debe haber introducido su
usuario y contraseña correctamente.
Entradas: El administrador gestionará el alta, modificación o borrado de nuevos productos
en el menú.
Procedimiento: El administrador irá a la sección donde se gestiona los productos y
ejecutará la acción deseada.
Salidas: Se llevará a cabo la gestión y se mostrará la confirmación.
RF6
Introducción: Un usuario podrá realizar un pedido online.

Precondición: El usuario debe de estar registrado y debe haber iniciado sesión.
Entradas: El usuario quiere hacer un pedido.
Procedimiento: El usuario va a la sección donde se realizan los pedidos, donde ve los
productos, selecciona los que quiera adquirir y confirma el pedido
Salidas: Se registrará el pedido y se mandará un email al cliente.
RF7
Introducción: Un AdminCocina podrá procesar un pedido.

Precondición: El AdminCocina debe de estar dado de alta y se debe haber logueado.
Entradas: El administrador quiere marcar un pedido como ya entregado o cancelar uno
existente.
Procedimiento: El administrador va a la sección donde se muestran los pedidos sin finalizar,
elige el deseado y lo finaliza.
Salidas: Se finalizará el pedido y se mostrará la confirmación.
RF8
Introducción: Un usuario podrá ver un listado de sus pedidos.

Precondición: El usuario debe de estar registrado, se debe haber logueado y debe haber
hecho algún pedido en el pasado.
Entradas: El usuario quiere ver el listado de pedidos.
21
Procedimiento: El usuario va a la sección dedicada a sus pedidos donde verá la lista.
Salidas: Se mostrará la lista.
RF9
Introducción: Un AdminCocina podrá ver una lista de pedidos.

Precondición: El AdminCocina debe de estar registrado y debe de haber iniciado sesión.
Entradas: El administrador desea ver la lista.
Procedimiento: El administrador va al apartado donde se muestran todos los pedidos.
Salidas: Se mostrará el listado correspondiente.
RF10
Introducción: Un adminCocina podrá activar y desactivar en un momento determinado el

sistema de pedidos de la web.
Precondición: El adminCocina debe de estar registrado y con la sesión iniciada.
Entradas: El administrador quiere activar/desactivar el sistema de pedidos.
Procedimiento: El administrador va a la sección de cocina donde activará o desactivará los
pedidos.
Salidas: La web permitirá hacer pedidos o no.
RF11
Introducción: Un adminCocina podrá determinar un horario de atención de pedidos online

Entradas: El administrador quiere establecer un horario de pedidos online.
Procedimiento: El administrador elige una hora inicial y una final de atención de pedidos
online.
Salidas: La aplicación permitirá hacer pedidos o no en ese rango horario.
RF12
Introducción: Un adminCocina podrá establecer unos códigos postales a los que se podrán
hacer entregas de pedidos a domicilio.
Entradas: El administrador quiere añadir o eliminar códigos postales.
Procedimiento: El administrador va a la sección de cocina donde añadirá o eliminará los
códigos.
Salidas: Se avisará del cambio y la aplicación permitirá realizar pedidos a domicilio a las
direcciones con esos códigos postales.
RF13
22
Introducción: Un adminGeneral podrá gestionar las habitaciones del hostal.
Precondición: El adminGeneral debe de estar dado de alta y con sesión iniciada.
Entradas: El administrador quiere añadir/modificar/ver una habitación.
Procedimiento: El administrador va a la sección de gestión del hostal donde elige y realiza la
operación de actualización deseada.
Salidas: Se hará la gestión y se confirmará la operación o simplemente se mostrará
información.
RF14
Introducción: Un cliente podrá reservar una habitación.

Precondición: El cliente debe de estar registrado, con sesión iniciada y debe haber
habitaciones libres en las fechas elegidas.
Entradas: El cliente va a reservar una habitación.
Procedimiento: El usuario va a la sección donde selecciona las fechas elegidas y la
habitación.
Salidas: Se realizara la reserva, se mostrará la confirmación y se mandará un email al
usuario.
RF15
Introducción: Un AdminRecepción podrá procesar las reservas de habitaciones.

Precondición: El AdminRecepción debe de estar dado de alta y se debe haber logueado.
Entradas: El administrador quiere procesar una reserva.
Procedimiento: El administrador va a la sección relativa a reservas donde elige la reserva
para procesarla una vez esté ya finalizada o cancelada.
Salidas: Se finalizará o cancelará la reserva y se mostrará el éxito de la operación.
RF16
Introducción: Un usuario podrá ver un listado de sus reservas de habitaciones.

Precondición: El usuario debe de estar dado de alta, se debe haber logueado correctamente
y debe haber hecho alguna reserva de habitación en el pasado.
Entradas: El usuario quiere ver el listado de sus reservas.
Procedimiento: El usuario va a un apartado de reservas donde estará el listado con las
suyas.
Salidas: Se mostrará la lista de reservas de habitación del usuario.
RF17
Introducción: Un AdminRecepción podrá ver un listado de todas las reservas de

habitaciones.
23
Precondición: El AdminRecepción debe de estar dado de alta, se debe haber logueado
correctamente y deben existir reservas de habitación.
Entradas: El administrador quiere ver el listado de reservas.
Procedimiento: El administrador va a una sección de reservas donde estará el listado con
todas.
Salidas: Se mostrará la lista de reservas de habitación.
RF18
Introducción: Un cliente podrá hacer una reserva de mesa en el restaurante.

Precondición: El cliente debe de estar registrado, con sesión iniciada y debe haber sitio
suficiente sin ocupar en el comedor del restaurante.
Entradas: El cliente va a reservar una mesa.
Procedimiento: El usuario va a la sección de reservas de comedor donde selecciona la fecha
elegida, el horario y el número de personas.
Salidas: Se realizará la reserva, se mostrará la confirmación y se mandará un email al
usuario.
RF19
Introducción: Un usuario podrá ver un listado de sus reservas en el restaurante.

Precondición: El usuario debe de estar dado de alta, se debe haber logueado correctamente
y debe haber hecho alguna reserva en el pasado.
Entradas: El usuario quiere ver el listado de reservas.
Procedimiento: El usuario va a un apartado de reservas de comedor, donde se le mostrarán
todas.
Salidas: Se mostrará la lista.
RF20
Introducción: Un AdminCocina podrá ver el listado de reservas en el restaurante.

Precondición: El AdminCocina debe de estar dado de alta, se debe haber logueado
correctamente y debe existir alguna reserva de restaurante.
Entradas: El administrador quiere ver el listado de reservas.
Procedimiento: El administrador va a al de apartado de reservas de comedor donde se le
mostrarán todas.
Salidas: Se mostrará la lista de reservas completa.
RF21
Introducción: Un AdminCocina podrá procesar las reservas del restaurante.

Precondición: El AdminCocina debe de estar registrado y con la sesión iniciada, debe existir
alguna reserva de restaurante pendiente.
24
Entradas: El administrador quiere gestionar una reserva de restaurante.
Procedimiento: El administrador va a la sección de reservas de restaurante donde elige la
reserva para procesarla, finalizándola como exitosa o cancelándola.
Salidas: Se gestionará la reserva y se mostrará la confirmación de la acción.
RF22
Introducción: Un AdminGeneral podrá modificar el tamaño del restaurante.

Precondición: El AdminGeneral debe de estar dado de alta y se debe haber iniciado sesión
correctamente.
Entradas: El administrador quiere modificar el tamaño del comedor del restaurante puesto
a disposición de ser reservado.
Procedimiento: El administrador va a la sección de gestión del hostal referida al comedor
donde modificará el tamaño.
Salidas: Se modificará el tamaño y saldrá mostrada la confirmación.
RF23
Introducción: Un adminGeneral podrá ver una serie de estadísticas de su hostal.

Precondición: El AdminGeneral debe de estar registrado y con la sesión iniciada.
Entradas: El administrador quiere ver una gráfica de estadística.
Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la
estadística gráfica a visualizar.
Salidas: Se mostrarán las estadísticas.
4.3.2 REQUISITOS DE INTERFAZ GRÁFICA
Los requisitos siguientes estarán relacionados con la parte visual de la web:
RI1
En la interfaz se mostrará información relativa al hostal como medio para atraer clientes y
darlo a conocer.
RI2
Se mostrará en todo momento en pantalla un enlace para que los usuarios puedan hacer
desloguearse si han iniciado sesión.
25
4.3.3 REQUISITOS DE SEGURIDAD
RS1
Para evitar registros masivos se utilizará un captcha en el formulario de registro de

usuarios.
RS2
La sesión de usuario debe caducar a los 10 minutos de inactividad.
4.3.4 INTERFACES EXTERNAS
Los usuarios de la aplicación interactuarán con la interfaz por medio de un navegador web.
26
4.4 CASOS DE USO GENERALES
A continuación se muestra el esquema general de casos de uso del sistema, sirve para
hacerse una idea del alcance del mismo y de qué acciones puede realizar cada usuario.
Ilustración 13: Diagrama Casos de Uso General
Una breve explicación de cada caso de uso:
Usuario:
 Gestionar sus datos -> Cada usuario de la aplicación podrá tener acceso a sus datos y
modificarlos o borrar su cuenta.
 Reservar habitación -> Los usuarios podrán reservar una habitación si hay disponibles.
 Reservar mesa -> Los usuarios podrán hacer una reserva en el comedor del hostal
siempre que haya sitio.
 Realizar pedido -> Asimismo podrán hacer un pedido con los productos ofertados en la
web.
 Listar pedidos -> Se recupera un listado de pedidos del usuario y se pueden ver los
detalles de cada pedido.
 Listar reservas habitación-> Se muestra un listado de reservas del usuario y sus
detalles.
27
 Listar reservas comedor -> Se muestran las reservas de comedor realizadas por el
usuario.
Visitante:
 Registro en Web-> Podrá registrarse y así en el futuro realizar las operaciones de

Usuario.
adminGeneral:
 Gestionar habitaciones -> Aquí estarán todas las operaciones relativas a las
habitaciones que el hostal pone a disposición en las reservas.
 Modificar comedor -> Aumentar o disminuir el tamaño del comedor.
 Gestionar usuarios -> Acciones sobre los datos de los usuarios registrados.
 Visualizar estadísticas -> Ver gráficos con estadísticas del hostal.
adminCocina:
 Gestionar productos -> Acciones sobre los productos que se ofertarán en la web.
 Procesar pedido -> Operaciones sobre los pedidos que han hecho los usuarios.
 Gestionar sistema pedidos -> Activar o desactivar el sistema de pedidos de la web para
permitir realizar pedidos o no en un momento dado.
 Gestionar reservas de comedor -> Refleja las acciones para la administración de las
reservas de sitio en el comedor.
adminRecepción:
 Gestionar reservas de habitación-> Representa las acciones sobre las reservas de los
usuarios.
28
5. FRAMEWORK: STRUTS
5.1 INTRODUCCIÓN
Apache Struts es una herramienta de soporte basada en el patrón Modelo-Vista-

Controlador que permite el desarrollo de aplicaciones web en Java.
Struts provee un entorno que nos permitirá reducir el tiempo de desarrollo y nos brindará
una correcta separación entre las distintas capas de la arquitectura MVC.
Forma parte de Apache Struts Project y es de libre uso.
5.2 ARQUITECTURA MVC
5.2.1 INTRODUCCIÓN
El patrón de arquitectura MVC (Model-View-Controller) permite separar la lógica de

negocio, los datos de la aplicación y la forma en la que se presentan esos datos al usuario.
Se pueden diferenciar tres partes fundamentales: la vista, el modelo y el controlador.
5.2.2 VISTA
Es la capa encargada de presentar al usuario la aplicación, recogiendo sus peticiones e

interacciones con el sistema.
5.2.3 MODELO
El modelo contiene la lógica de negocio donde se encuentran nuestros objetos

representados. También contiene la persistencia, desde la cual tendremos acceso a nuestros
datos para poder actualizarlos, eliminarlos, modificarlos y almacenarlos en nuestra base de
datos.
5.2.4 CONTROLADOR
Se encarga de controlar todo el flujo de la aplicación, redirigiendo todas las peticiones de

los usuarios. El controlador debe poseer de algún mapa de correspondencias entre las
peticiones que recibe y las respuestas a realizar.
29
Ilustración 14: Esquema MVC
5.3 COMPONENTES STRUTS
Se puede separar claramente los componentes de Struts en tres tipos:
 API de Struts.
 Archivos de configuración.
 Etiquetas JSP
5.3.1 API
El API de Struts está formado por las distintas clases de apoyo que el framework pone a
disposición de los programadores y diseñadores para facilitar el desarrollo y estructurar la
aplicación. La clases a utilizar se encuentran en los paquetes: org.apache.struts.action y
org.apache.struts.actions.
A continuación se enumeran las principales clases de este API:
 ActionServlet: Es el componente Controlador (MVC) de Struts, es implementado

mediante el servlet org.apache.struts.action.ActionServlet .Este servlet se encarga de
recibir todas las entradas y peticiones HTTP de los clientes y delega el control de cada
solicitud a una clase definida por el usuario del tipo org.apache.struts.action.Action.
Para ello el ActionServlet extrae la última parte de la URL y la contrasta con la
información contenida en el archivo de configuración struts-config.xml, donde estará
reflejado el objeto org.apache.struts.action.ActionForm a instanciar y la acción a
realizar.
 Action: Tal como se ha apuntado arriba, los objetos Action son los responsables en
realizar las peticiones que le delega el ActionServlet, para ello utilizan el método
execute(). Este método será el que el programador deberá sobrescribir incluyendo
30
todas las instrucciones necesarias para que las peticiones se lleven a cabo
correctamente. La acción actúa como un adaptador entre el contenido de una solicitud
http y la lógica de negocio correspondiente.
 ActionForm: Los objetos ActionForm son un tipo JavaBean usados para transportar
datos entre las distintas capas de la aplicación. Son usados por el ActionServlet para
capturar los datos procedentes de un formulario y enviárselos al objeto Action que le
corresponda. Los ActionForm constarán de los métodos get/set para poder y acceder
y tratar la información que se obtienen de ellos.
 ActionMapping: Un objeto de este tipo representa una asociación entre una petición
de usuario y el objeto Action que la tiene que procesar. Contiene la URL que provoca la
ejecución de la acción y las posibles redirecciones a las distintas vistas a mostrar según
le indique el Action.
 ActionForward: La clase ActionForward representa el destino al que el controlador
debe enviar el control una vez que el Action se ha completado. De esta manera, cada
vez que se quiera redirigir al usuario a una determinada página se hará usando un
ActionForward.
5.3.2 ARCHIVOS DE CONFIGURACIÓN
El archivo más importante de configuración de Struts que se va a utilizar es struts-

config.xml que funciona como un enlace entre las capas de Modelo y Vista y define la lógica de
presentación y navegabilidad de la aplicación Web.
Es un archivo de tipo XML donde están registrados y configurados los distintos

componentes de Struts que se utilizarán en la aplicación. Entre ellos podemos encontrar las
siguientes entradas:
 form-beans de la aplicación: Los form-beans son instancias de una subclase de la clase

ActionForm.
 action-mappings : Es la entrada del archivo de configuración que contiene las reglas de
navegabilidad de la web.
31
Ilustración 15: Estructura XML form-bean
Otros archivos de configuración son validator-rules.xml y validation.xml, que son utilizados

para validar los campos de los formularios. Aunque en este proyecto se ha decidido validar los
formularios sin utilizar estos recursos.
5.3.3 ETIQUETAS JSP
Struts también ofrece una serie de etiquetas para facilitar el tratamiento de la información
en las páginas JSP. El framework da recursos para evitar el uso de scriptlet (fragmentos Java
dentro de JSP) y mejorar la compresión y mantenibilidad de las vistas.
Proporciona etiquetas de HTML, bean, logic o nested.
5.4 FUNCIONAMIENTO STRUTS
Una vez explicados de forma general los componentes de Struts se pasa a comentar el
funcionamiento y las relaciones entre ellos. Cada vez que se hace una petición a la aplicación
de Struts tiene lugar el siguiente proceso:
1. Analizar la URL: Se pasa la petición al objeto ActionServlet, éste analiza la URL para
poder así determinar la acción a realizar. Normalmente se asigna al servlet que se
ocupe de todas urls cuya terminación sea *.do. Cualquier URL que proceda del cliente
y termine en .do provocará que la petición sea capturada por el servlet.
Si tenemos una URL www.hostal.com/gestión/registro.do , el ActionServlet se

encargará de extraer la parte de URL que esté ligada al .do, en este caso “/registro”.
2. Determinar acción a realizar: Una vez conseguida la ruta “/registro” el ActionServlet

consulta en el archivo struts-config.xml para determinar que acción debe hacer. Para
cada acción el archivo de configuración contiene el objeto ActionForm asociado a la
32
operación y la clase Action que debe ser instanciada. Tras obtener los datos del archivo
el ActionServlet:
1. Crea la instancia del objeto ActionForm y lo rellena con los datos obtenidos
con el formulario que ha pulsado el usuario.
2. Crea una instancia del objeto Action requerido pasando como referencia el
objeto ActionForm creado en el punto 1.
3. Procesar la petición: Dentro del método execute() del Action instanciado estará el
código implementado con las operaciones a ejecutar, desde llamadas a métodos,
almacenamiento de variables o todo aquello necesario para la correcta generación de las
vistas (JSPs).
4. Generar la vista: Tras ejecutarse el método execute() devuelve al ActionServlet un

objeto ActionForward que identifica que recurso se ha utilizado y que respuesta debe
generarse. Finalmente el ActionServlet revisa de nuevo el archivo struts-config.xml y utiliza
el valor previamente generado para redirigir a la dirección JSP correspondiente.
Captura ejemplo de una declaración de Action en el archivo struts-xml
En este caso si el alta de producto se produce correctamente el ActionServlet dirige la web

a la página éxito.jsp.
En caso contrario la redirige a altaProducto2.jsp
Captura con los parámetros del método execute de una clase Action
33
Ilustración 16: Esquema estructural Struts
34
6. CICLO 1
6.1 ANÁLISIS CICLO 1
6.1.1 ANÁLISIS DE REQUISITOS
6.1.1.1 INTRODUCCIÓN
El primer ciclo del sistema va enfocado al tratamiento de datos de los usuarios registrados.
Las altas, bajas, modificaciones o listados de los usuarios que más adelante harán uso de la
aplicación.
6.1.1.2 USUARIOS INVOLUCRADOS
En este apartado intervendrán adminGeneral y Usuario (indirectamente adminRecepción y

adminCocina al ser un Usuario con más poderes).
El adminGeneral será el administrador que pueda modificar o borrar a los usuarios del
sistema, dar de alta nuevos usuarios y administradores y listar usuarios con distintos filtros.
El Usuario simplemente podrá tratar sus datos y cuenta.
6.1.1.3 REQUISITOS INVOLUCRADOS
Trataremos en la sección con los requisitos funcionales planteados en el análisis de

requisitos: RF1, RF2, RF3 y RF4 (ver en documento de requisitos, página 20).
Se refinan los requisitos RF2 Y RF3:
RF2.1
Introducción: Un usuario podrá ver sus datos.
Precondición: El usuario debe estar dado de alta y debe haber iniciado sesión.
Entradas: El usuario quiere ver sus datos de la cuenta.
Procedimiento: El usuario va al apartado de la web donde se encuentran sus datos.
Salidas: Se mostrarán los datos.
35
RF2.2
Introducción: Un usuario podrá modificar sus datos.
Precondición: El usuario debe estar registrado y debe haber iniciado sesión.
Entradas: El usuario quiere modificar sus datos de la cuenta.
Procedimiento: El usuario va a la sección donde se encuentren los datos y modificará lo que
desee.
Salidas: Se modificarán los datos y se le indicará al usuario el éxito de los cambios.
RF2.3
Introducción: Un usuario podrá borrar su cuenta.
Precondición: El usuario debe estar dado de alta y debe haberse identificado
correctamente.
Entradas: El usuario desea borrar su cuenta.
Procedimiento: El usuario va a la sección del portal donde confirmará que desea borrar su
cuenta.
Salidas: Será borrado el usuario y así se indicará.
RF3.1
Introducción: Un administrador podrá crear usuarios.
Precondición: El administrador debe estar dado de alta y debe haber hecho login.
Entradas: El administrador quiere crear un nuevo usuario.
Procedimiento: El administrador va a una sección donde rellenará los datos del usuario a
crear.
Salidas: Se creará el usuario y se informará.
RF3.2
Introducción: Un administrador podrá modificar usuarios.
Precondición: El administrador debe estar registrado y debe haber iniciado sesión.
Entradas: El administrador quiere modificar a un usuario.
Procedimiento: El administrador va a un apartado donde elegirá al usuario que quiere
modificar, cambiará sus datos y los guardará.
Salidas: Se realizarán las modificaciones y así se mostrará.
RF3.3
Introducción: Un administrador podrá borrar usuarios.
Precondición: El administrador debe estar registrado y debe haber iniciado sesión.
Entradas: El administrador desea borrar a un usuario.
Procedimiento: El administrador va al apartado de la web donde seleccionará al usuario que
será borrado.
Salidas: Se eliminará y se informará de que se ha borrado.
36
6.1.1.4 CASOS DE USO
El siguiente esquema muestra el diagrama de casos de uso del Ciclo1 de la aplicación.
Ilustración 17: Diagrama Casos Uso Ciclo 1
A continuación se van a enumerar y describir los distintos casos de uso de este primer ciclo:
DARSE DE ALTA
CASO DE USO: Darse de alta

Descripción: Usuario nuevo se registra
Actores: Visitante
Precondición:
Postcondición: Se almacenan los datos del visitante.
37
Escenario 1. Visitante introduce sus datos en un formulario.
Principal: 2. Sistema registra esos datos y confirma el alta.
3. Termina caso de uso.
Excepciones:  Error en los datos introducidos en el formulario.
VER SUS DATOS
CASO DE USO: Ver sus datos

Descripción: Usuario registrado mira sus datos
Actores: Usuario
Precondición: Usuario está registrado y ha iniciado sesión.
Postcondición: Se muestran los datos.
Escenario 1. Usuario solicita ver sus datos.
Principal: 2. Sistema muestra datos.
3. Termina caso de uso
Excepciones:
MODIFICAR SUS DATOS
CASO DE USO: Modificar sus datos

Descripción: Usuario modifica sus datos
Actores: Usuario
Postcondición: Datos son actualizados.
Escenario 1. Usuario modifica sus datos en el formulario.
Principal: 2. Sistema actualiza datos y muestra la confirmación.
DARSE DE BAJA
CASO DE USO: Darse de baja

Descripción: Usuario se da de baja de la web.
Actores: Usuario
Precondición: Usuario está registrado y ha hecho login correctamente.
Postcondición: Todos los datos del usuario se borran
Escenario 1. Usuario solicita borrar su cuenta.
Principal: 2. Sistema pide contraseña.
3. Usuario escribe contraseña.
4. Sistema borra usuario y confirma la correcta eliminación.
Excepciones:  Error en la contraseña.
38
RECUPERAR CONTRASEÑA
CASO DE USO: Recuperar contraseña

Descripción: Usuario consigue una nueva contraseña
Actores: Usuario
Precondición: Usuario está registrado.
Postcondición: Contraseña cambiada
Escenario 1. Usuario solicita contraseña nueva.
Principal: 2. Sistema pide datos al usuario.
3. Usuario escribe datos.
4. Sistema cambia contraseña y se la facilita al usuario.
Excepciones:  Error en los datos facilitados por el usuario.
LISTAR USUARIOS
CASO DE USO: Listar Usuarios

Descripción: Administrador desea listar todos los usuarios de la Web
Actores: adminGeneral
Precondición: Administrador está registrado en el sistema y ha iniciado sesión
correctamente.
Postcondición: Se muestra listado de usuarios.
Escenario 1. Administrador solicita un determinado listado de usuarios.
Principal: 2. Sistema muestra el listado
3. Termina caso de Uso.
Excepciones:
VER DATOS USUARIO
CASO DE USO: Ver Datos Usuario

Descripción: Administrador quiere obtener los datos de un usuario.
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Se muestra al usuario elegido.
Escenario 1. Administrador pide listado de usuarios.
Principal: 2. Sistema muestra lista de usuarios.
3. Administrador elige al usuario.
4. Sistema muestra usuario.
Excepciones:
39
MODIFICAR DATOS USUARIO
CASO DE USO: Modificar Datos Usuario

Descripción: Administrador quiere modificar datos de un usuario.
Postcondición: Usuario es modificado
Principal: 2. Sistema muestra lista de usuarios.
3. Administrador elige al usuario.
4. Sistema muestra usuario.
5. Administrador modifica usuario.
Ilustración 18: Diagrama Actividad Modificar usuario
40
DAR DE ALTA USUARIO
CASO DE USO: Dar de Alta Usuario

Descripción: Administrador quiere dar de alta un nuevo usuario.
Precondición: Administrador está registrado y se ha identificado correctamente.
Postcondición: Usuario nuevo es creado.
Escenario 1. Administrador introduce datos de usuario en formulario.
Principal: 2. Sistema crea y añade al nuevo usuario.
DAR DE BAJA USUARIO
CASO DE USO: Dar de Baja Usuario

Descripción: Administrador quiere borrar a un usuario.
Postcondición: Usuario es borrado.
Principal: 2. Sistema muestra usuarios.
3. Administrador selecciona usuario.
4. Sistema muestra datos del usuario.
5. Administrador borra usuario.
6. Sistema borra al usuario del registro.
Excepciones:
41
6.2 DISEÑO CICLO 1
6.2.1 DISEÑO DE LA ARQUITECTURA
En esta sección se describirá el diseño de la arquitectura en la que estará basado nuestro

sistema.
El diseño está claramente influenciado por el uso de Struts que implementa el patrón MVC.
Este patrón proporciona una clara separación en distintas capas de los componentes de la
aplicación.
6.2.1.2 ARQUITECTURA APLICADA A NUESTRO SISTEMA
La arquitectura empleada es una especialización de la usada tradicionalmente como capa

de presentación, lógica de negocio y capa de persistencia.
MODELO
En el modelo se tiene toda la lógica de negocio y los objetos de los que se compone la
aplicación. También está incluida la persistencia que se compondrá de varias clases Java
encargadas de conectar con la base de datos.
VISTA
La vista se compondrá de páginas JSP (Java Server Pages). En estas páginas se mostrarán las
salidas a las peticiones realizadas por los usuarios. Se intentará en medida de lo posible evitar
el uso de fragmentos de código Java (Scriptlets) ya que sería código poco reutilizable y difícil de
mantener.
CONTROLADOR
El controlador es la unión entre el modelo, que es donde se encuentran los datos, y la vista,
que será donde serán mostrados esos datos. Se encargará de controlar el flujo de
peticiones/respuestas entre el usuario y la aplicación.
Para esta labor Struts cuenta con ActionServlet junto al archivo struts-config.xml
42
6.2.2 CLASES DE NEGOCIO
A continuación se mostrará el diseño de las clases de negocio de la aplicación en este

primer ciclo.
Las clases serán separadas en:

 Objetos de negocio
 Clases de persistencia
 ActionForms
 Actions
Los objetos de negocio serán las clases generales que representarán la información con la
cual es sistema opera. Las clases de persistencia serán aquellas encargadas en conectar e
interactuar con la base de datos.
Los ActionForm son clases que actúan como un almacén y guardan la información recogida
en los campos de los formularios de la web. Esta información será tratada posteriormente en
los Action.
Los Action serán aquellas clases que servirán para realizar todas las operaciones de lo que
sería la lógica de negocio.
6.2.2.2 OBJETOS DE NEGOCIO
Se tendrá la clase Usuario con todos los datos de los usuarios registrados en la web, y las
clases de tipos de administrador que heredan los métodos de la superclase. No se necesita
ninguna información adicional de los administradores sobre los usuarios. Un Usuario podrá ser
cualquier tipo de administrador a la vez o ninguno.
Habrá también una clase TipoUsuario. Ésta es necesaria en la aplicación durante la muestra
de los distintos tipos de usuario en algunas páginas con filtros por tipo de usuario.
43
Ilustración 19: Diagrama Clases Usuarios Ciclo 1
Están también las clases Email y EncriptadorSHA1. La primera clase se empleará para la
creación y el envío de emails a los usuarios, y el encriptador para convertir las contraseñas en
una cadena SHA1 como medio de seguridad.
Ilustración 20: Diagrama Clases 2 Ciclo 1
44
6.2.2.3 CLASE DE PERSISTENCIA
Para poder efectuar cambios y operaciones con los datos almacenados en la base de datos,
se necesitarán unas clases con acceso y privilegios suficientes.
En este primer ciclo se utilizarán las clases UsuariosBD para todas las operaciones relativas
a la gestión de los datos de los usuarios, LoginBD para la identificación de los usuarios y la
clase ConexionBD para conectar con la base de datos.
En las siguientes figuras se muestran los métodos que serán empleados para interactuar
con ella.
Ilustración 21: Diagrama Clase LoginBD
45
Ilustración 22: Diagrama Clase UsuariosBD
6.2.2.4 ACTIONFORMS
Los ActionForms usados en este ciclo serán:
 UsuarioActionForm: Este ActionForm guardará toda la información recogida en los

formularios relativa a los datos de los usuarios.
 LoginActionForm: Será utilizado durante el proceso de login de usuarios donde
deberán poner su usuario y contraseña en un formulario.
 ObtenerUsuariosActionForm: Servirá para guardar listados de usuarios y poder
mostrarlos en la página web.
 RedirigirActionForm: Es necesario en ciertos aspectos de redirección de páginas de la
aplicación.
46
Ilustración 23: Esquema FormBeans Ciclo 1
6.2.2.5 ACTIONS
En la tabla siguiente se enumerarán los Action creados para este ciclo junto a una breve
descripción de cada uno.
Action Descripción
LoginAction Action usado durante el inicio de sesión de un usuario.
ModificarUsuarioAction Action empleado cuando un usuario modifica sus datos.
GetUsuariosAction Action empleado para listar todos los usuarios
registrados.
FiltrarUsuariosAction Action empleado para listar a los usuarios registrados
según un filtro.
RegistroWebAction Action utilizado en el registro de un nuevo usuario en la
web.
BajaUsuarioAction Action que se encarga de dar de baja a un usuario que
borra su cuenta.
DisplayDatosUsuarioAction Action que recupera los datos de un usuario elegido por
el administrador y los muestra.
BorrarUsuarioAction Action empleado para el borrado de un usuario por
parte de un administrador.
GetDatosUsuarioAction Action para mostrar a un usuario sus datos.
AltaUsuarioAction Action usado para realizar el alta de un usuario creado
por un administrador.
ModificarUsuarioAdminAction Action utilizado para ejecutar una modificación de
usuario por parte del administrador.
RecuperarPassAction Action a usar durante el proceso de recuperación de
contraseña.
Ilustración 24: Tabla Actions Ciclo 1
47
6.2.3 DISEÑO DE LA BASE DE DATOS
A continuación se va a mostrar el diseño de la base de datos para el ciclo1. Conforme se

vayan creando nuevos ciclos la BD se irá haciendo más grande para cubrir todas las
necesidades de la aplicación.
6.2.3.2 REQUISITOS DE LA BASE DE DATOS
Se quiere guardar información de todos los usuarios y administradores de la web.

Interesaría guardar el nombre, apellidos, dirección, localidad, código postal, teléfono, email,
contraseña y fecha de ingreso de cada usuario. Para los administradores no se necesitaría
ningún detalle más.
Cada usuario tendrá un identificar único.
6.2.3.3 DIAGRAMA DE ENTIDAD-RELACIÓN
DESCRIPCIÓN DEL DIAGRAMA.
Se han elegido los nombres de las tablas y campos de forma bastante identificativa
respecto a lo que representan. Las entidades creadas serán:
 Usuario: Representa a cualquier usuario almacenado en el sistema, contiene

información común y es una superclase de los administradores.
 adminGeneral: Serán los administradores generales del hostal, con mayores permisos
que un simple usuario. No se guardará ninguna información adicional de ellos respecto
a la de un usuario cualquiera. Hereda toda la información de Usuario.
 adminRecepción: Representará a los administradores de la recepción, al igual que
adminGeneral no se necesitará guardar ninguna información adicional propia.
 adminCocina: Representa a los administradores de la cocina. Como con los otros dos
tipos de administrador, sus datos estarán en la tabla usuario.
48
Ilustración 25: Esquema EER Ciclo 1
6.2.3.4 CONVERSIÓN A MODELO RELACIONAL
TABLAS RESULTANTES
Durante la conversión a tablas han surgido algunas dudas pero al final se ha decidido
apostar por el modelo mostrado en la figura de abajo.
Se podía haber utilizado una sola tabla de usuario eliminando las de los administradores
utilizando unos nuevos campos booleanos (esAdminGeneral, esAdminCocina,
esAdminRecepción).
La razón por la que se ha decidido dejar las tablas separadas es pensando en una futura
expansión de la aplicación donde se podría guardar más información de los administradores y
habría que separar las tablas igualmente.
49
NORMALIZACIÓN
Primera Forma Normal (1FN)
Todas las tablas están en 1FN al no tener atributos multievaluados.
Segunda Forma Normal (2FN)
Las tablas también se encuentran en la 2FN al depender sus atributos no primos de la clave
totalmente y cumplir la 1FN.
Tercera Forma Normal (3FN)
Igualmente también cumplen la 3FN ya que los atributos primos dependen de forma no
transitiva de la clave.
Claves candidatas
En Usuario se ha decidido utilizar como clave primaria el atributo entero autoincrementado

(ID).
Teléfono y email pasarán a ser columnas unique.
6.2.3.5 DIAGRAMA DE TABLAS FINAL
A partir del diagrama EER anterior y la normalización se ha generado la siguiente estructura

de tablas de la base de datos.
50
Ilustración 26: Diagrama Tablas Ciclo 1
6.2.4 INTERFACES GRÁFICAS DEFINITIVAS
Se van a mostrar algunas capturas de la aplicación referentes a este ciclo1.
6.2.4.1 LOGIN DE USUARIO
Pantalla de login, el usuario deberá identificarse con su teléfono y contraseña para poder
acceder a algunas secciones de la web.
Tendrá la opción de conseguir una contraseña nueva en el caso de que la haya olvidado
facilitando correctamente su email y teléfono.
51
Ilustración 27: Interfaz login de usuario
6.2.4.2 REGISTRO DE USUARIO
La pantalla de registro muestra los datos requeridos para registrarse, el captcha a rellenar y
las condiciones ficticias de uso de la web. En el caso de que los datos introducidos sean
erróneos se indicará en rojo el error del campo a corregir.
52
Ilustración 28: Interfaz registro de usuario
6.2.4.3 BÚSQUEDA DE USUARIO
En la pantalla de búsqueda de usuarios se distinguen 2 partes, los campos a rellenar que

sirven de filtro y el listado de usuarios que cumplen el filtro de arriba.
Los listados se pueden exportar en archivos .pdf o .xls para poder imprimirlos, guardarlos…
53
Ilustración 29:Interfaz Búsqueda de usuarios
54
6.2.4.4 ADMINISTRACIÓN USUARIO
La captura siguiente muestra el menú de administración general referente a la gestión de

usuarios.
Ilustración 30: Interfaz administración de usuarios
6.2.4.5 PERFIL DE USUARIO
En la pantalla de perfil de usuario simplemente se mostrarán sus datos y se le dará opción a

modificarlos o borrar su cuenta.
55
Ilustración 31:Interfaz datos de usuario
56
6.3 IMPLEMENTACIÓN CICLO 1
6.3.1 TECNOLOGÍAS EMPLEADAS
La implementación de la aplicación ha sido realizada utilizando tecnología Java. Se ha usado

además el framework Struts 1.3.1, que ha facilitado la tarea en algunos aspectos y ha
marcado un camino a seguir en el diseño de la aplicación.
Para la conexión la base de datos se ha utilizado JDBC con la excepción de un método que
ha sido implementado mediante Hibernate, que es otro framework, desarrollado para la
persistencia. El método concreto es uno que se necesitaban hacer consultas con filtros, para
los que la tecnología JDBC debía usar muchísimas consultas distintas. Así que se usó como
alternativa la opción de CRITERIA QUERIES de Hibernate que facilitaba mucho la tarea de
añadir criterios de filtro en unas consultas SQL.
Para mostrar listados en pantalla se ha empleado DisplayTag.

http://www.displaytag.org/1.2/
Es una suite sencilla de utilizar para mostrar datos presentados en tablas y
automáticamente ordenables y exportables.
El captcha del apartado registro se hecho con jcaptcha.

http://jcaptcha.sourceforge.net
Es un sistema que nos permite usarlo como filtro ante ataques bot y que se integra bien
junto a Struts.
El desarrollo ha tenido lugar con el IDE Netbeans debido a su potencia y a sus ayudas para
facilitar la generación de código y marcación de errores.
6.3.2 ESTRUCTURA DE CARPETAS
En este primer ciclo la estructura de carpetas será muy simple. Por un lado estarán las
carpetas que contendrán los archivos .java y en otro las carpetas con los .jsp
Las principales carpetas serán:
 Objetos- Contendrá el código java de Usuario, AdminCocina, AdminGeneral,

AdminRecepción, TipoUsuario, Email, EncriptadorSHA1...
 Forms- Esta carpeta tendrá los ActionForm, en este primer ciclo: UsuarioActionForm,
LoginActionForm y ObtenerUsuariosActionForm
 Bd- Tendrá las clases relativas a la interacción con la base de datos: UsuariosBD,
LoginBD, ConexionBD
57
 actions.usuarios- Carpeta que contendrá los actions del primer ciclo enumerados en la
tabla de la ilustración 24.
 Config- Carpeta donde estarán los archivos de configuración de la BD.
 Actions- Carpeta donde se ubicará la acción común de redirigir.
 Web/WEB-INF/Usuarios- Directorio con todas las páginas JSP referidas a este ciclo,
con acceso restringido.
 Web- Carpeta con acceso público.
6.3.3 SEGURIDAD
En la parte de seguridad de la aplicación se ha implementado el comentado captcha en la

página de registro. Aparte de esto se han codificado las contraseñas mediante SHA1, de forma
que nadie en la BD puede ver la contraseña original.
Otra medida de seguridad de cara al usuario es que una vez logueado, al pasar 10 minutos
inactivo se le cierra la sesión y se le manda a la página de login.
Se ha implementado también unos accesos y vistas según el rol del usuario (usuario,
administradores). Cada persona tendrá unas vistas en su web y no podrá acceder a donde no
esté autorizado a entrar.
Debido a que el alcance del proyecto no llega a los pagos por internet de los pedidos y
reservas no se ha incidido mucho más en el tema de seguridad en la conexión.
6.3.4 CÓDIGO DESTACABLE
En esta sección se expondrá parte de código fuente que se considera interesante destacar.
HIBERNATE (LISTAR USUARIOS CON FILTRO)
El poner en la búsqueda de usuarios 5 variables de filtrado suponía al principio hacer 2^5

consultas distintas comprobando cada campo del formulario. Para hacer más simple esta
búsqueda con filtro era necesaria una alternativa.
Como se ha explicado hace unos apartados, se ha decidido utilizar en este método

Hibernate debido a su API Criteria, que permite utilizar Criteria Queries. Como se verá en el
código siguiente,
De esta forma se ahorra mucho trabajo a la hora de fijar filtros, simplemente añadiendo
unos criterios a una variable de Criteria.
58
Como se puede ver en el código de abajo, para listar primero se comprueban los datos
recogidos en el formulario (nombre, apellidos, email, teléfono) y si no son nulos se añaden
como restricciones que se deben cumplir. Tras esto se fija el tipo de usuario también
seleccionado en el formulario de filtrado de la aplicación. Los usuarios que cumplen todas las
restricciones se añaden a una lista que será la mostrada en la página.
59
Ilustración 32: Código Hibernate Filtrar Usuarios
LOGIN DE USUARIO
Básicamente lo que hace el código es recuperar los datos que ha captado el formulario de
login y comprueba si esos datos encajan con los almacenados en la base de datos de la web.
Hay que señalar que la contraseña está codificada en SHA1 y por lo tanto antes de comparar
con la BD se debe encriptar esa clave.
Si los datos coinciden se comprueba que rol de usuario posee el dueño de ese teléfono. Se
guarda en la sesión el rol o roles que posee para mostrar unas partes de la web solo accesibles
a administradores.
Si el login es exitoso se redirige a index y si por el contrario es fallido se carga el error a

mostrar en la página.
60
Ilustración 33: Código Login Usuario Action
61
Ilustración 34: Código Login Usuario BD
JAVASCRIPT CONFIRMACIÓN ELIMINAR USUARIO
El código correspondiente a este apartado sirve para pedir una segunda confirmación de
que un usuario debe ser borrado por parte del administrador.
Cuando se pulsa el botón para eliminarlo, se lanza el javascript que pregunta si está seguro.
Ilustración 35: Código Javascript confirmación borrado de usuario
62
Ilustración 36: Código html confirmación borrado de usuario
63
6.4 PRUEBAS CICLO 1
6.4.1 INTRODUCCIÓN
Antes de dar por finalizado cada ciclo se deberá comprobar su correcto funcionamiento.
Se probarán los formularios para evitar que ocurran fallos provocados por la unicidad de
algún elemento de la base de datos o para comprobar bien los datos antes de que vayan a ser
utilizados por los Action. Como es lógico también se testeará la aplicación para que se realicen
correctamente las operaciones marcadas en los requisitos.
6.4.2 VALIDACIÓN DE FORMULARIOS
Los datos de los formularios se validarán mostrando los errores que se hayan producido en
la introducción de datos.
Ejemplo de validación del formulario de login.
Ilustración 37: Interfaz validación login
64
Ejemplo de validación con captcha del formulario de registro:
Ilustración 38: Interfaz validación captcha
65
6.4.3 PRUEBAS UNITARIAS
A continuación se van a probar aquellos casos en los que puede haber conflicto en la
inserción de datos en la BD al existir restricciones de unicidad. Se contará con las siguientes
clases de equivalencia y los correspondientes casos de prueba.
6.4.3.1 CLASES DE EQUIVALENCIA
ALTA USUARIO
Condición Clases válidas Clases no válidas

Teléfono
Unicidad Teléfono no existe (AU1) Teléfono existe (AU2)
Email
Unicidad Email no existe (AU3) Email existe (AU4)
MODIFICACIÓN DE USUARIO

Teléfono
Unicidad Teléfono no existe (MU1) Teléfono existe (MU2)
Email
Unicidad Email no existe (MU3) Email existe (MU4)
6.4.3.2 CASOS DE PRUEBA
ALTA USUARIO
Caso válido
Prueba Unitaria 1
Descripción Alta de un nuevo usuario
Entradas Nombre: “Federico”
Apellidos: “Lopera García”
Dirección: “Gran Vía nº 7 26004 Logroño”
CP:"26006"
Teléfono : “622622622”
Teléfono repetido: “622622622”
Email: “Federico@gmail.com”
66
Contraseña: ”1234”
Contraseña repetida: ”1234”
Captcha: CORRECTO
Clases de (AU1)(AU3)
equivalencia
Resultado Operación exitosa
esperado
Casos no válidos
Prueba Unitaria 2
Entradas Nombre: “Pedro”
CP:"26006"
Teléfono : “622622622” (existiendo)
Email: “pedro@gmail.com”
Captcha: CORRECTO
Clases de (AU2)
equivalencia
Resultado Error, otro usuario tiene ese teléfono.
esperado
Prueba Unitaria 3
Entradas Nombre: “Jaime”
CP:"26006"
Teléfono : “633633633”
Email: Federico@gmail.com (existiendo)
Captcha: CORRECTO
Clases de (AU4)
equivalencia
Resultado Error, otro usuario tiene ese email.
esperado
67
MODIFICAR USUARIO
Caso válido
Prueba Unitaria 4
Descripción Modificación de usuario
CP:"26006"
Teléfono : “644644644”
Clases de (MU1)(MU3)
equivalencia
esperado
Casos no válidos
Prueba Unitaria 8
Apellidos: “Lopera Bona”
CP:"26006"
Teléfono : “622622622” (existiendo)
Teléfono repetido: “622622622” (existiendo)
Clases de (MU2)
equivalencia
Resultado Error, otro usuario tiene ese teléfono.
esperado
Prueba Unitaria 9
Apellidos: “Lopera Bona”
68
CP:"26006"
Teléfono : “622622622”
Email: pedro@gmail.com (existiendo)
Clases de (MU3)
equivalencia
Resultado Error, otro usuario tiene ese email.
esperado
6.4.3.3 RESULTADO DE PRUEBAS
Tras ejecutar las pruebas unitarias, junto a pruebas relativas a la concordancia de los datos
según cada campo del formulario y pruebas del captcha se ha probado la integridad y el buen
funcionamiento de los formularios.
Se han realizado también distintas pruebas de funcionamiento de la aplicación durante esta

primera fase de desarrollo para observar si la aplicación funcionaba correctamente. Tras
realizar algunos cambios para solucionar errores encontrados se tiene ya la aplicación
corregida y funcionando.
69
7. CICLO 2
7.1 ANÁLISIS CICLO 2
El segundo ciclo del sistema está enfocado al tratamiento de los productos del restaurante.
Estos productos serán ofrecidos para la venta online. Se tratará toda la gestión de este sistema
de pedidos, tanto lo referente a la parte de los encargos realizados por los usuarios cómo la de
administración.
En este apartado los protagonistas serán adminCocina y Usuario.
AdminCocina será el administrador encargado de crear nuevos productos, modificarlos y

borrarlos. También asumirá la responsabilidad de gestionar los pedidos, marcándolos como
pagados o como cancelados. Tendrá la posibilidad de activar o desactivar el sistema de
pedidos online de la web y fijar un horario de venta y atención de esos pedidos.
Usuario podrá realizar pedidos online así como acceder a listados de sus pedidos y detalles
de los mismos.
Se satisfacen los requisitos RF5, RF7, RF8, RF9, RF10, RF11 y RF12 en el ciclo 2 del proyecto.
A continuación se refinan más RF5, RF7, RF10 y RF12:
RF5.1
Introducción: Un AdminCocina podrá crear un producto para el hostal.

Precondición: El AdminCocina debe estar registrado y se debe haber logueado.
Entradas: El administrador gestionará el alta de nuevos productos de restaurante.
Procedimiento: El administrador irá al formulario donde escribirá los datos del nuevo
producto.
Salidas: Se creará el producto y se informará de que se ha creado con éxito.
70
RF5.2
Introducción: Un AdminCocina podrá modificar un producto para el hostal.

Precondición: El AdminCocina debe estar dado de alta y debe haber iniciado sesión.
Entradas: El administrador quiere modificar un producto ya existente.
Procedimiento: El administrador va a una sección donde elegirá el producto a modificar y
hará los cambios oportunos.
Salidas: Se modificará el producto y se indicará que se ha hecho correctamente.
RF5.3
Introducción: Un AdminCocina podrá borrar un producto de comida para el hostal.

Precondición: El AdminCocina debe estar registrado y logueado en la aplicación.
Entradas: El administrador quiere borrar un producto en el menú.
Procedimiento: El administrador va al apartado de productos donde elige el que quiere
eliminar.
Salidas: Se borrará y así se indicará.
RF7.1
Introducción: Un AdminCocina podrá finalizar un pedido.

Precondición: El AdminCocina debe estar dado de alta y debe haber logueado.
Entradas: El administrador quiere marcar un pedido como ya finalizado correctamente.
elige el deseado y lo marca como pagado y finalizado.
Salidas: Se finalizará el pedido y se mostrará la confirmación.
RF7.2
Introducción: Un AdminCocina podrá cancelar un pedido.

Precondición: El AdminCocina debe estar dado de alta y se debe haber logueado.
Entradas: El administrador quiere cancelar un pedido.
elige el deseado y lo cancela.
Salidas: Se cancelará el pedido y se mostrará la confirmación.
RF10.1
Introducción: Un adminCocina podrá activar el sistema de pedidos de la web.
71
Precondición: El adminCocina debe estar registrado y con la sesión iniciada.
Entradas: El administrador quiere activar el sistema de pedidos.
Procedimiento: El administrador va a la sección de cocina donde activará los pedidos.
Salidas: La web permitirá hacer pedidos.
RF10.2
Introducción: Un adminCocina podrá desactivar el sistema de pedidos de la web.

Entradas: El administrador quiere desactivar el sistema de pedidos.
Procedimiento: El administrador va a la sección de cocina donde desactivará los pedidos.
Salidas: La web ya no permitirá hacer pedidos.
RF12.1
Introducción: Un adminCocina podrá añadir un código postal al que hacer entregas.

Entradas: El administrador quiere añadir un código.
Procedimiento: El administrador va a la sección de cocina donde añadirá el código.
Salidas: El código se añadirá permitiendo hacer entregas a domicilio a direcciones con ese
CP.
RF12.2
Introducción: Un adminCocina podrá borrar un código postal al que ya no hacer entregas.

Entradas: El administrador quiere borrar un código.
Procedimiento: El administrador va a la sección de cocina donde eliminará el código.
Salidas: El código se borrará impidiendo en el futuro hacer entregas a esos domicilios.
72
El siguiente esquema es el diagrama de casos de uso relativo a este segundo ciclo del
proyecto.
A continuación se enumeran y describen los distintos casos de uso:
CREAR PRODUCTO
CASO DE USO: Crear Producto

Descripción: Administrador quiere crear un nuevo producto
Actores: adminCocina
Postcondición: Producto es añadido a la BD.
Escenario 1. Administrador rellena los datos del producto a añadir.
Principal: 2. Sistema añade producto.
Excepciones:  Error en los datos introducidos.
73
MODIFICAR PRODUCTO
CASO DE USO: Modificar producto

Descripción: Administrador quiere modificar un producto.
Postcondición: Producto es modificado.
Escenario 1. Administrador pide listado de productos existentes.
Principal: 2. Sistema muestra listado de productos.
3. Administrador selecciona producto a modificar
4. Sistema muestra datos del producto.
5. Administrador modifica producto.
6. Sistema modifica producto en la BD.
Excepciones:  Error en los datos introducidos.
ELIMINAR PRODUCTO
CASO DE USO: Eliminar Producto

Descripción: Administrador quiere borrar un producto.
Postcondición: Producto es borrado.
Escenario 1. Administrador pide listado de productos existentes.
3. Administrador selecciona producto a eliminar.
5. Administrador borra producto.
6. Sistema borra al producto del registro.
Excepciones:
VER PRODUCTO
CASO DE USO: Ver Producto

Descripción: Administrador quiere ver un producto.
Postcondición: Producto es borrado.
Escenario 1. Administrador pide listado de productos.
Principal: 2. Sistema muestra productos.
3. Administrador selecciona producto.
74
Excepciones:
LISTAR PRODUCTOS
CASO DE USO: Listar productos

Descripción: Administrador quiere listar los productos.
Postcondición: Productos son mostrados.
Escenario 1. Administrador pide listado.
Excepciones:
HACER PEDIDO
CASO DE USO: Hacer Pedido

Descripción: Usuario quiere hacer un pedido.
Actores: Usuario
Postcondición: El pedido es realizado y almacenado.
Escenario 1. Usuario selecciona productos.
Principal: 2. Sistema almacena productos.
3. Usuario elige cantidades.
4. Sistema almacena cantidades.
5. Usuario finaliza la compra.
6. Sistema registra pedido.
Excepciones:
75
Ilustración 40: Diagrama Secuencia Realizar Pedido
VER SU PEDIDO
CASO DE USO: Ver su Pedido

Descripción: Usuario quiere ver un pedido realizado.
Actores: Usuario
Postcondición: Pedido es mostrado.
Escenario 1. Usuario pide listado de pedidos.
Principal: 2. Sistema muestra pedidos.
3. Usuario selecciona pedido.
4. Sistema muestra datos del pedido.
Excepciones:
76
LISTAR SUS PEDIDOS
CASO DE USO: Listar sus pedidos

Descripción: Usuario quiere ver sus pedidos.
Actores: Usuario
Postcondición: Pedidos son mostrados.
Escenario 1. Usuario pide un listado de sus pedidos.
Principal: 2. Sistema muestra listado de pedidos.
Excepciones:
FINALIZAR PEDIDO
CASO DE USO: Finalizar pedido

Descripción: Administrador quiere marcar un pedido como ya pagado.
Postcondición: Pedido es marcado como pagado
Escenario 1. Administrador pide listado de pedidos.
3. Administrador selecciona pedido a finalizar
5. Administrador selecciona finalizar.
6. Sistema añade pedido como pagado en el registro.
Excepciones:
CANCELAR PEDIDO
CASO DE USO: Cancelar pedido

Descripción: Administrador quiere marcar un pedido como cancelado.
Postcondición: Pedido es marcado como cancelado
3. Administrador selecciona pedido a cancelar.
5. Administrador lo cancela.
6. Sistema marca el pedido como cancelado.
77
Excepciones:
VER PEDIDO
CASO DE USO: Ver Pedido

Descripción: Administrador quiere ver un pedido realizado.
Actores: Administrador
Postcondición: Pedido es mostrado.
3. Administrador selecciona pedido.
Excepciones:
LISTAR PEDIDOS
CASO DE USO: Listar pedidos

Descripción: Administrador quiere ver listado de pedidos.
Escenario 1. Administrador solicita listado de pedidos.
Excepciones:
ACTIVAR SISTEMA DE PEDIDOS
CASO DE USO: Activar sistema de pedidos

Descripción: Administrador quiere activar el sistema de pedidos.
Precondición: Administrador está registrado y ha iniciado sesión y los pedidos están
desactivados.
Postcondición: Pedidos volverán a estar activos.
Escenario 1. Administrador solicita activar pedidos.
Principal: 2. Sistema activa pedidos.
Excepciones:
78
DESACTIVAR SISTEMA D E PEDIDOS
CASO DE USO: Desactivar sistema de pedidos

Descripción: Administrador quiere desactivar el sistema de pedidos.
Precondición: Administrador está registrado y ha iniciado sesión y los pedidos están
activados.
Postcondición: Pedidos online se desactivarán
Escenario 1. Administrador solicita desactivar pedidos.
Principal: 2. Sistema desactiva pedidos.
Excepciones:
MODIFICAR HORARIO DE SISTEMA DE PEDIDOS
CASO DE USO: Modificar horario de sistema de pedidos

Descripción: Administrador quiere modificar el horario en el que el sistema de
pedidos estará activo.
Postcondición: El nuevo rango de horas de atención de pedidos se establecerá.
Escenario 1. Administrador introduce nuevas horas.
Principal: 2. Sistema cambia el rango de horas.
Excepciones:
AÑADIR CÓDIGO POSTAL
CASO DE USO: Añadir código postal

Descripción: Administrador quiere añadir un nuevo código.
Postcondición: Código es añadido.
Escenario 1. Administrador inserta código.
Principal: 2. Sistema añade código.
Excepciones:  Código ya existe.
79
ELIMINAR CÓDIGO POSTAL
CASO DE USO: Eliminar código postal

Descripción: Administrador quiere borrar un código.
Postcondición: Código es eliminado.
Escenario 1. Administrador borra código.
Principal: 2. Sistema elimina código del registro.
Excepciones:
80
7.2 DISEÑO CICLO 2
La arquitectura empleada en el desarrollo del ciclo 2 es exactamente igual que la usada en

el ciclo 1 y que la de los ciclos posteriores. Se seguirá utilizando un diseño guiado por el patrón
MVC y con las clases que pone a disposición Struts (ActionForm, Actions) junto a las habituales
de objetos de negocio y sus clases de gestión en la BD.
Ahora se mostrará el diseño de las clases de negocio del ciclo2 de la aplicación. Se seguirá
un estilo similar al del ciclo1 dividiendo las clases según su utilización y tipo.
7.2.2.2 OBJETOS DE NE GOCIO
El esquema que se ve a continuación es una ampliación al desarrollado en el ciclo1. Se han

añadido los nuevos objetos que son utilizados en esta segunda parte del proyecto.
La clase Producto guarda la información referente a los productos de restaurante ofrecidos

por la aplicación. Está ligada a TipoProducto ya que todo Producto tiene que ser de un tipo
concreto. Por ejemplo, puede haber un producto llamada “Pepito” que sea de tipo bocadillo, u
otro llamado “Carbonara” de tipo Pizza.
Cabe destacar también que la clase ProductoEnPedido describe a los productos dentro de
un pedido con una cantidad y un precio. La clase Pedido representa, como su nombre indica, a
un pedido de productos que un usuario ha hecho en el portal web.
81
Ilustración 41: Diagrama clases ciclo 2
7.2.2.3 CLASES DE PERSISTENCIA
En este segundo ciclo se utilizarán las clases ProductosBD y PedidosBD para realizar todas
las operaciones relativas a la gestión de productos y gestión de pedidos en las que se necesite
acceder o modificar la base de datos.
En el siguiente diagrama se puede observar los métodos de cada clase.
Ilustración 42: Diagrama Clases BD Ciclo 2
82
7.2.2.4 ACTIONFORMS
Los ActionForm empleados en este apartado para el tratamiento de la información de los

formularios van a ser:
 ProductoActionForm
 ObtenerProductosActionForm
 PedidoActionForm
 ObtenerPedidosActionForm
 RedirigirActionForm
 ConfiguracionHostalActionForm
Ilustración 43:Diagrama FormBeans Ciclo 2
A destacar simplemente que la clase ConfiguraciónPedidosActionForm será usada para la

activación y desactivación del sistema de pedidos, la inserción o eliminación de códigos
postales y para la modificación de horarios. RedirigirActionForm se encargará de cierto
redireccionamiento de la web. Los demás ActionForm serán empleados para operaciones
relacionadas con los productos y los pedidos.
83
7.2.2.5 ACTIONS
En la gestión de productos y pedidos se van a emplear las siguientes Actions:
Tabla para gestión de productos:
Action Descripción
AltaProductoAction Acción empleada para dar de alta un producto con
los datos recogidos del formulario.
ObtenerProductosAction Acción empleada para cargar un listado de
productos.
DisplayDatosProductoAction Acción que muestra los datos de un producto.
ModificarProductosAction Acción que modifica los datos de un producto.
DisplayDatosTipoProductoAction Acción que muestra los datos de un tipo de
producto.
FiltrarProductosAction Acción que carga una lista de productos según un
filtro.
AltaTipoProductoAction Acción usada para crear un nuevo tipo de producto.
ObtenerTiposProductoAction Acción que carga los distintos tipos de producto que
existen.
BorrarProductoAction Acción que borra un producto.
BorrarTipoProductoAction Acción empleada para borrado un tipo de producto.
ModificarTipoProductoAction Acción empleada para modificar un tipo de
producto.
Tabla para gestión de pedidos.
Action Descripción
ActualizarPedidoAction Acción empleada para actualizar las cantidades de
los productos de un pedido
DisplayDatosPedidoAction Acción usada para mostrar los datos de un pedido
abierto.
DisplayDatosPedidoCerradoAction Acción usada para mostrar los datos de un pedido
cerrado.
EliminarProductoPedidoAction Acción que se usa para eliminar un producto de un
pedido que un usuario está haciendo.
AddProductoPedidoAction Acción que añade un producto a un pedido que
está realizando un usuario.
FiltrarPedidosAbiertosAction Acción que carga un listado de pedidos abiertos
según un filtro establecido.
FiltrarPedidosAction Acción que filtra pedidos finalizados.
FinalizarPedidoAction Acción usada para finalizar un pedido una vez se
84
han seleccionado todos los productos.
MostrarCarroAction Acción a usar para ver los elementos del carro de
la compra, es decir, los productos seleccionados para
el pedido.
GetPedidosAbiertosAction Acción que carga todos los pedidos que hay
abiertos.
GetPedidosAbiertosUsuarioAction Acción que carga los pedidos abiertos de un
usuario.
GetPedidosAction Acción que carga en un listado todos los pedidos.
GetPedidosUsuarioAction Acción que carga en un listado todos los pedidos
de un usuario.
SellarPedidoAction Acción que finaliza definitivamente un pedido,
marcando como pagado o como cancelado.
SeleccionarProductoAction Acción que carga los productos que serán
mostrados para venderse en la web si está operativa
la venta online.
ActivacionPedidosAction Acción utilizada para activar y desactivar el sistema
de pedidos online.
ModificarEstadoPedidosOnline Acción empleada para modificar el horario de
atención de pedidos online.
85
El diseño que se mostrará a continuación será una ampliación del visto en el ciclo1
añadiendo a los esquemas y tablas la información referida a la actividad de este segundo ciclo.
7.2.3.2 REQUISITOS DE LA BASE DE DATOS
Para los productos ofertados por el restaurante se quiere guardar su nombre, una breve
descripción, el precio, la última fecha de actualización y a su vez tener almacenados los
diferentes tipos de productos con un nombre para que se pueda tenerlos categorizados en la
web.
De los pedidos se necesita guardar el precio total, la fecha del pedido y el usuario que ha
realizado ese pedido, asimismo también se recuperará que productos han sido comprados en
el pedido junto la cantidad de ellos.
Interesará saber si un pedido ya ha sido pagado o ha sido cancelado, guardando el motivo

de la cancelación.
Se necesita almacenar los códigos postales a los cuales se pueden hacer envíos online. Y
también se desea almacenar una serie de parámetros, como si los envíos están activos y un
horario de atención de esos pedidos .
Se han elegido los nombres de las entidades y campos de forma bastante identificativa. A
continuación se pasa a enumerar y describir las nuevas entidades:
Producto: Representa a un producto ofrecido por el hostal para la venta, cada uno su
identificador. Consta también de una fecha de actualización, de un precio y una descripción.
TipoProducto: Son las categorías de los distintos tipos de productos que oferta el
restaurante.
Pedido: Representa el historial de pedidos realizados por los usuarios, con su identificar
único y los identificadores de los productos encargados, así como el precio total del pedido y la
fecha de cuando se realizó.
CódigoPostal: Almacena todos los CP a los que se pueden realizar entregas a domicilio.
ConfigPedidos: Se trata de una forma de almacenar determinados datos de configuración,
tales como el horario de atención de pedidos, si estos están activos o el horario de atención.
86
DIAGRAMA EER
Se ha realizado el siguiente esquema EER para el almacenamiento de información del ciclo

2 del proyecto:
87
TABLAS RESULTANTES
En la conversión a tablas se ha decidido crear una tabla para almacenar los pedidos que se
han cancelado y para comprobar si está finalizado se usará un booleano en la tabla Pedido.
Aparece también la tabla ProductoEnPedido. Esta tabla almacena y relaciona cada producto
dentro de un pedido y su cantidad.
NORMALIZACIÓN
El esquema de abajo muestra las tablas normalizadas, solamente está incluidas las añadidas
en el ciclo 2.
Las nuevas tablas cumplen: 1FN, 2FN y 3FN Aunque el caso de ConfigPedidos es especial ya
que es una tabla de configuración y no es preciso que haya claves ni relaciones.
Claves candidatas
Las claves serán los ID en Producto, TipoProducto y Pedido, en TipoProducto nombre

también podía haber sido clave pero se ha preferido que tengan un identificador numérico.
88
La siguiente figura muestra el esquema final de la estructura de tablas para la segunda

parte de este proyecto:
Ilustración 45: Esquema Tablas Ciclo 2
89
7.2.4 INTERFACES GRÁFICAS DEFINITIVAS
VISTA CARTA PEDIDOS
Pantalla pública de pedidos, los internautas tendrán una visión de los productos
gastronómicos que ofrece el restaurante en su carta y un enlace para comenzar un pedido
online.
Ilustración 46: Interfaz Carta productos
Vista carro del pedido
Vista de los productos almacenados durante el proceso de pedido. En el carro se puede

borrar productos o actualizar la cantidad deseada.
90
Ilustración 47:Interfaz carro pedido
Vista resumen del pedido
En la siguiente captura se ve la pantalla final antes de confirmar un pedido. Si la entrega a

domicilio está activa y el código postal del cliente está entre los disponibles para esa entrega
se da opción al cliente de recoger el pedido en el restaurante del hostal o de recibirlo en casa.
91
Ilustración 48: Interfaz Resumen confirmación pedido
92
Vista configuración de pedidos
La vista de configuración de pedidos muestra las opciones de configuración que tiene un

administrador de cocina. Desde activar o desactivar los pedidos online hasta fijar un horario de
atención de pedidos.
Ilustración 49: Interfaz Configuración pedidos
93
La implementación del segundo ciclo ha sido realizada con las mismas tecnologías
explicadas en el correspondiente apartado del ciclo 1. Se sigue utilizando NetBeans, Struts y
JDBC como principales herramientas y de nuevo se cuenta con DisplayTag como medio para
presentar listados.
En el segundo ciclo la estructura de carpetas es la misma que en la del ciclo anterior.

Solamente se crean 2 directorios nuevos llamados actions.pedidos y actions.productos donde
estarán ubicados los actions relativos a las operaciones de pedidos y productos. Y otras 2
carpetas equivalentes para almacenar los archivos JSP que estarán en Web/WEB-INF/Pedidos
y Web/WEB-INF/Productos
En esta sección se expondrá parte de código fuente que se considera interesante destacar.
CARRO
En el siguiente código del carro de productos en un pedido se ve el bucle que carga la lista
de productos seleccionados. Se destaca la etiqueta logic:iterate que como su nombre indica,
sirve para iterar en una lista y obtener los elementos que se encuentran en ella.
En este caso se tiene una lista de ProductosEnPedido y se muestran en una tabla junto a un
icono que permite eliminarlos de la lista. Posee también un textbox para cambiar la cantidad
de ellos actualizando el pedido.
Ilustración 50: Código carro html
94
DISPLAYTAG
Displaytag provee una herramienta para mostrar tablas con datos almacenados en una
lista. Permite ordenar esa tabla por la columna que se le marque mediante la propiedad
sortable=”true” y a su vez permite exportar esos datos con export=”true”
Se ha usado una columna con un icono que al pulsarse permite la edición del elemento
mostrado en esa fila. Para ello se ha empleado un campo oculto que almacena el identificador
del elemento de esa fila.
value='<%= ((Producto)pageContext.getAttribute("productos")).getNombre()%>'
Ilustración 51: Código DisplayTag
95
7.4 PRUEBAS CICLO 2
7.4.1 INTRODUCCIÓN
Las pruebas a realizar en este ciclo van a centrarse en garantizar el correcto funcionamiento
de todo el proceso de creación, modificación y eliminación de productos. Además se probará
la realización de pedidos incluyendo los productos previamente creados, la finalización de esos
pedidos y la muestra de listados tanto de productos como de pedidos.
Como medida de integración de los 2 ciclos se probará también a crear nuevos usuarios y
administradores que realicen y gestionen pedidos respectivamente.
La validación de formularios tendrá lugar para garantizar que no se puedan crear 2

productos o 2 tipos de producto iguales y también para chequear que se introducen tipos de
datos correctos en cada campo.
Ilustración 52: Interfaz validación formulario alta producto
A continuación se van a probar aquellos casos en los que puede haber conflicto al existir
restricciones en la base de datos de unicidad.
96
ALTA DE PRODUCTO

Nombre
Unicidad Nombre no existe Nombre existe (AP2)
(AP1)
MODIFICACIÓN DE PRODUCTO

Nombre
Unicidad Nombre no existe Nombre existe (MP2)
(MP1)
ALTA DE TIPO DE PRODUCTO

Nombre
Unicidad Nombre no existe Nombre existe (ATP2)
(ATP1)
MODIFICACIÓN DE TIPO DE PRODUCTO

Nombre
Unicidad Nombre no existe Nombre existe
(MTP1) (MTP2)
97
ALTA DE PRODUCTO
Caso válido
Prueba Unitaria 10
Descripción Alta de un nuevo producto
Entradas Nombre: Mickey
Descripción: Bacon, queso
Precio: 4
Categoría: Bocadillos
Clases de (AP1)
equivalencia
esperado
Caso no válido
Prueba Unitaria 11
Descripción Alta de un nuevo producto
Entradas Nombre: Mickey (existiendo)
Precio: 4
Clases de (AP2)
equivalencia
Resultado Ya existe un producto con ese nombre.
esperado
MODIFICACIÓN DE PRODUCTO
Caso válido
Prueba Unitaria 12
Descripción Modificación de un producto
Entradas Nombre: Mickey (cambiado a Goofy)
Precio: 4
Clases de (MP1)
equivalencia
98
esperado
Caso no válido
Prueba Unitaria 13
Entradas Nombre: Mickey (cambiado a Aladdin existiendo)
Precio: 4
Clases de (MP2)
equivalencia
Resultado Ya existe un producto con ese nombre.
esperado
ALTA DE TIPO DE PRODUCTO
Caso válido
Prueba Unitaria 14
Descripción Alta de un nuevo tipo de producto
Entradas Nombre: Hamburguesas
Clases de (ATP1)
equivalencia
esperado
Caso no válido
Prueba Unitaria 15
Descripción Alta de un nuevo tipo de producto
Entradas Nombre: Hamburguesas (existiendo)
Clases de (ATP2)
equivalencia
Resultado Ya existe un tipo de producto con ese nombre.
esperado
99
MODIFICACIÓN DE TIPO DE PRODUCTO
Caso válido
Prueba Unitaria 16
Entradas Nombre: Hamburguesas (cambiado a bebidas)
Clases de (MTP1)
equivalencia
esperado
Caso no válido
Prueba Unitaria 17
Entradas Nombre: Hamburguesas (cambiado a bocadillos existiendo)
Clases de (MTP2)
equivalencia
Resultado Ya existe un tipo de producto con ese nombre.
esperado
7.5.4 RESULTADO DE LAS PRUEBAS
Se efectuaron distintas pruebas para ver el correcto funcionamiento de la aplicación. Todo

el proceso de pedidos online fue testeado y corregidos los errores encontrados.
Se comprobó el correcto funcionamiento de las restricciones en el sistema de pedidos
(horarios de atención, activación y desactivación de pedidos, activación y desactivación de
entrega a domicilio, envío a determinados códigos postales).
100
8. CICLO 3
8.1 ANALISIS CICLO 3
Este tercer ciclo será el último y más extenso. Engloba todo lo relacionado con las reservas
de habitaciones en el hostal, desde la creación de nuevas habitaciones y tipos de habitación
hasta la muestra de habitaciones libres para unas determinadas fechas y su posterior elección
por un usuario registrado.
También está incluidas las reservas de sitio en el comedor restaurante y su gestión. Se

incluirán además una serie de estadísticas del hostal mediante gráficas.
En este apartado intervendrán todos los tipos de usuario: adminCocina, adminRecepción,

adminGeneral y Usuario.
El adminRecepción es el administrador encargado de procesar todas las entradas y salidas

en el hostal de gente, tendrá que finalizar las reservas.
El adminGeneral es el encargado de agregar nuevas habitaciones y tipos de habitaciones al

hostal, también podrá modificarlas o eliminarlas. Dispondrá de unos formularios con unas
determinadas gráficas de estadísticas.
Los adminCocina atenderán las reservas de sitio en el comedor restaurante.
El Usuario podrá realizar reservas online de habitaciones libres y de sitio en el comedor.
Se atenderán los requisitos RF13, RF14, RF15, RF16, RF17, RF18, RF19, RF20, RF21, RF22,
RF23. (ver página 19)
101
Se refinan y detallan RF13, RF15, RF21 y RF23:
RF13.1
Introducción: Un adminGeneral podrá dar de alta una habitación del hostal.

Precondición: El adminGeneral debe estar registrado y se debe haber logueado.
Entradas: El administrador quiere añadir una habitación.
Procedimiento: El administrador va a un apartado de la web donde añade una habitación.
Salidas: Se añadirá la habitación y se informará de ello.
RF13.2
Introducción: Un adminGeneral podrá modificar una habitación del hostal.

Precondición: El adminGeneral debe estar registrado y debe haber iniciado sesión.
Entradas: El administrador quiere modificar una habitación.
Procedimiento: El administrador va a una sección donde elige la habitación y la modifica.
Salidas: Se modificará la habitación y se mostrará una confirmación.
RF13.3
Introducción: Un adminGeneral podrá dar de baja una habitación del hostal.

Precondición: El adminGeneral debe estar registrado y debe haber hecho login
correctamente.
Entradas: El administrador quiere borrar una habitación.
Procedimiento: El administrador va a un apartado donde elige la habitación a borrar y la
elimina.
Salidas: Se borrará la habitación y se informará.
RF15.1
Introducción: Un AdminRecepción podrá finalizar las reservas de habitaciones.

Precondición: El AdminRecepción debe estar dado de alta y se debe haber logueado.
Entradas: El administrador quiere finalizar una reserva.
Procedimiento: El administrador va a la sección relativa a reservas de habitaciones donde
elige la reserva para marcarla como pagada.
Salidas: Se finalizará la reserva y se mostrará el éxito de la operación.
RF15.2
Introducción: Un AdminRecepción podrá cancelar las reservas de habitaciones.

Precondición: El AdminRecepción debe estar dado de alta y se debe haber logueado.
102
Entradas: El administrador quiere cancelar una reserva.
Procedimiento: El administrador va a la sección relativa a reservas donde elige la reserva
para cancelarla.
Salidas: Se cancelará la reserva y se mostrará que se ha hecho con éxito.
RF21.1
Introducción: Un AdminCocina podrá finalizar las reservas del restaurante.

Precondición: El AdminCocina debe estar registrado y con la sesión iniciada, debe existir
Entradas: El administrador quiere finalizar una reserva de restaurante.
reserva para marcarla como pagada..
Salidas: Se finalizará la reserva y se mostrará la confirmación de la acción.
RF21.2
Introducción: Un AdminCocina podrá cancelar las reservas del restaurante.

Precondición: El AdminCocina debe estar registrado y con la sesión iniciada, debe existir
Entradas: El administrador quiere cancelar una reserva de restaurante.
reserva para cancelarla.
Salidas: Se cancelará la reserva y se mostrará la confirmación de la acción.
RF23.1
Introducción: Un adminGeneral podrá ver una gráfica del % de ocupación de las

habitaciones en un día
Entradas: El administrador quiere ver una gráfica de ocupación de las habitaciones en un
día.
estadística a visualizar eligiendo una fecha.
Salidas: Se mostrará la gráfica.
RF23.2
Introducción: Un adminGeneral podrá ver una gráfica del número de reservas en el

comedor en un año mostradas trimestralmente.
Entradas: El administrador quiere ver la gráfica.
103
estadística a visualizar eligiendo un año.
RF23.3
Introducción: Un adminGeneral podrá ver una gráfica del % del tipo de pensión elegida por
los clientes en un año.
Precondición: El AdminGeneral debe estar registrado y con la sesión iniciada.
Entradas: El administrador quiere ver la gráfica descrita arriba.
RF23.4
Introducción: Un adminGeneral podrá ver una gráfica de la ocupación de las habitaciones

en un año agrupadas mensualmente.
RF23.5
Introducción: Un adminGeneral podrá ver una gráfica del número de pedidos durante un
año agrupados trimestralmente.
RF23.6
Introducción: Un adminGeneral podrá ver una gráfica del % de ocupación del comedor
durante un año representado trimestralmente.
104
RF23.7
Introducción: Un adminGeneral podrá ver una gráfica del número de registros en la web de
nuevos usuarios agrupados mensualmente.
El siguiente esquema muestra una representación de las funciones que pueda hacer cada
usuario:
105
CASOS DE USO DE LA GESTIÓN DE HABITACIONES
CREAR HABITACIÓN
CASO DE USO: Crear Habitación

Descripción: Administrador quiere crear una nueva habitación
Postcondición: Habitación es añadida.
Escenario 1. Administrador introduce datos de la nueva habitación.
Principal: 2. Sistema añade habitación.
Excepciones:  Error en los datos.
MODIFICAR HABITACIÓN
CASO DE USO: Modificar Habitación

Descripción: Administrador quiere modificar una habitación.
Postcondición: Producto es modificado.
Escenario 1. Administrador pide listado de habitaciones.
Principal: 2. Sistema muestra listado de habitaciones.
3. Administrador elige habitación.
4. Sistema muestra datos de la habitación.
5. Administrador modifica habitación.
6. Sistema modifica habitación.
Excepciones:  Error en los datos.
ELIMINAR HABITACIÓN
CASO DE USO: Eliminar Habitación

Descripción: Administrador quiere borrar una habitación.
Postcondición: Habitación es borrada.
3. Administrador selecciona habitación.
5. Administrador borra habitación.
106
6. Sistema borra la habitación.
Excepciones:
VER HABITACIÓN
CASO DE USO: Ver Habitación

Descripción: Administrador quiere ver los datos de una habitación.
Postcondición: Se muestra la habitación.
3. Administrador selecciona habitación.
Excepciones:
LISTAR HABITACIONES
CASO DE USO: Listar habitaciones

Descripción: Administrador quiere listar las habitaciones.
Precondición: Usuarios y administrador están registrados y han iniciado sesión.
Postcondición: Productos son mostrados.
Principal: 2. Sistema muestra habitaciones.
Excepciones:
CASOS DE USO DE LA GESTIÓN DE RESERVA DE HABITACIONES
HACER RESERVA DE HABITACIÓN
CASO DE USO: Hacer Reserva de habitación

Descripción: Usuario quiere hacer una reserva de habitación.
Actores: Usuario
Postcondición: Pedido es realizado.
Escenario 1. Usuario elige fechas.
Principal: 2. Sistema muestra habitaciones libres en esas fechas.
107
3. Usuario elige habitación y tipo de pensión.
4. Sistema registra reserva.
5. Sistema envía confirmación.
Excepciones:  Error en las fechas.
 Error porque otro usuario ha reservado antes.
Ilustración 54:Diagrama Secuencia Reserva Habitación
108
VER SU RESERVA DE HABITACIÓ N
CASO DE USO: Ver su Reserva de habitación

Descripción: Usuario quiere ver una reserva.
Actores: Usuario
Postcondición: Reserva es mostrada.
Escenario 1. Usuario busca reserva.
Principal: 2. Sistema muestra listado de reservas de habitaciones.
3. Usuario selecciona reserva.
4. Sistema muestra datos de la reserva de la habitación.
Excepciones:
LISTAR SUS RESERVAS DE HABITACIÓN
CASO DE USO: Listar sus reservas de habitación

Descripción: Usuario quiere ver sus reservas.
Actores: Usuario
Postcondición: La lista de reservas es mostrada.
Escenario 1. Administrador pide listado de reservas de habitación.
Principal: 2. Sistema muestra el listado.
Excepciones:
FINALIZAR RESERVA DE HABITACIÓN
CASO DE USO: Finalizar reserva de habitación

Descripción: Administrador quiere marcar una reserva de habitación como
pagada.
Actores: adminRecepción
Postcondición: La reserva de habitación es marcada como finalizada correctamente.
Escenario 1. Administrador pide listado de reservas.
Principal: 2. Sistema muestra reservas.
3. Administrador selecciona reserva.
4. Sistema muestra datos de la reserva.
5. Administrador finaliza la reserva.
6. Sistema registra reserva como pagada.
109
Excepciones:
CANCELAR RESERVA DE HABITACIÓN
CASO DE USO: Cancelar reserva de habitación

Descripción: Administrador quiere marcar una reserva como cancelada.
Postcondición: Reserva es marcado como cancelado
5. Administrador cancela la reserva.
6. Sistema marca como cancelada la reserva.
Excepciones:
LISTAR RESERVAS DE HABITACIÓN
CASO DE USO: Listar reservas de habitación

Descripción: Administrador quiere ver un listado de reservas de habitación.
Escenario 1. Administrador pide listado de reservas de habitación.
Principal: 2. Sistema muestra listado de reservas.
Excepciones:
VER RESERVA DE HABIT ACIÓN
CASO DE USO: Ver su Reserva de habitación

Descripción: Administrador quiere ver una reserva.
Actores: Administrador
Principal: 2. Sistema muestra listado de reservas de habitaciones.
3. Usuario selecciona reserva.
4. Sistema muestra datos de la reserva de la habitación.
110
Excepciones:
CASOS DE USO DE LA GESTIÓN DE RESERVA DE COMEDOR
HACER RESERVA DE COMEDOR
CASO DE USO: Hacer Reserva de comedor

Descripción: Usuario quiere hacer una reserva de plazas en el comedor.
Actores: Usuario
Precondición: Usuario está registrado y han iniciado sesión.
Postcondición: Pedido es realizado.
Escenario 1. Usuario selecciona fecha y plazas.
Principal: 2. Sistema confirma reserva.
3. Sistema envía confirmación.
Excepciones:  No hay plazas disponibles.
 Error en la fecha.
111
Ilustración 55: Diagrama secuencia Reserva sitio restaurante
VER SU RESERVA DE COMEDOR
CASO DE USO: Ver su reserva de comedor

Descripción: Usuario quiere ver una reserva suya.
Actores: Usuario
Escenario 1. Usuario pide listado de reservas de comedor.
Principal: 2. Sistema muestra un listado con las reservas.
3. Usuario selecciona la reserva que quiere ver
Excepciones:
112
LISTAR SUS RESERVAS DE COMEDOR
CASO DE USO: Listar sus reservas de comedor

Descripción: Usuario quiere ver sus reservas.
Actores: Usuario
Postcondición: La lista de reservas de comedor es mostrada.
Escenario 1. Administrador va a sección reservas.
Excepciones:
FINALIZAR RESERVA DE COMEDOR
CASO DE USO: Finalizar reserva de comedor

Descripción: Administrador quiere marcar una reserva de comedor como
finalizada correctamente.
Postcondición: La reserva de comedor es marcada como pagada.
Principal: 2. Sistema muestra reservas abiertas.
5. Administrador finaliza reserva.
6. Sistema añade reserva como pagada en la BD.
Excepciones:
CANCELAR RESERVA DE COMEDOR
CASO DE USO: Cancelar reserva de comedor

Descripción: Administrador quiere marcar una reserva como cancelada.
Postcondición: Reserva es marcado como cancelado
Escenario 1. Administrador pide listado de reservas de comedor.
3. Administrador selecciona la reserva.
5. Administrador cancela la reserva.
6. Sistema marca la reserva como cancelada.
113
Excepciones:
LISTAR RESERVAS DE COMEDOR
CASO DE USO: Listar reservas de comedor

Descripción: Administrador quiere ver listado de pedidos.
Postcondición: La lista de reservas de comedor es mostrada.
Principal: 2. Sistema muestra listado.
Excepciones:
VER RESERVA DE COMEDOR
CASO DE USO: Ver reserva de comedor

Descripción: Administrador quiere ver una reserva .
Actores: Usuario
Principal: 2. Sistema muestra un listado con las reservas.
3. Administrador selecciona la reserva que quiere ver
Excepciones:
EXPLOSIÓN DEL CASO DE USO DE VER ESTADÍSTICAS
Ilustración 56: Diagrama Casos Uso Estadísticas
114
GENERAR GRÁFICA DE OCUPACIÓN DE HABITACIONES POR DÍA
CASO DE USO: Generar Gráfica Ocupación Habitaciones Día

Descripción: Administrador puede ver una gráfica con el % ocupación de las
habitaciones de un día concreto.
Postcondición: Se muestra la gráfica.
Escenario 1. Administrador introduce fecha.
Principal: 2. Sistema muestra gráfica de esa fecha.
Excepciones:
GENERAR GRÁFICA DE T IPO DE PENSIÓN
CASO DE USO: Generar Gráfica Tipo Pensión

Descripción: Administrador puede ver una gráfica que enseñe los porcentajes de
cada tipo de reserva de habitación que eligen los usuarios del año que le
pongas.
Escenario 1. Administrador introduce año.
Principal: 2. Sistema muestra gráfica con los datos del año.
Excepciones:
GENERAR GRÁFICA DE OCUPACIÓN DE HABITACIONES POR MES
CASO DE USO: Generar Gráfica Ocupación Habitaciones Mes

Descripción: Administrador puede ver una gráfica con la ocupación de las
habitaciones por meses en el año seleccionado.
Principal: 2. Sistema muestra gráfica.
Excepciones:
115
GENERAR GRÁFICA DE RESERVA DE COMEDOR POR TRIMESTRE
CASO DE USO: Generar Gráfica Reservas Comedor Trimestre

Descripción: Administrador puede ver una gráfica con la ocupación del comedor
por trimestres del año elegido.
Excepciones:
GENERAR GRÁFICA DE REGISTROS DE USUARIO POR MES
CASO DE USO: Generar Gráfica Registros Mes

Descripción: Administrador quiere ver una gráfica con el número de registros
mensual del año seleccionado.
Excepciones:
GENERAR GRÁFICA DE P EDIDOS POR TRIMESTRE
CASO DE USO: Generar Gráfica Pedidos Trimestre

Descripción: Administrador quiere ver una gráfica con número de pedidos,
representados trimestralmente del año elegido.
Excepciones:
GENERAR GRÁFICA DE OCUPACIÓN DE COMEDOR POR DÍA
CASO DE USO: Generar Gráfica Ocupación Comedor Día
116
Descripción: Administrador quiere ver una gráfica con el % ocupación del
comedor de un día concreto.
Escenario 1. Administrador selecciona fecha.
Excepciones:
117
8.2 DISEÑO CICLO 3
De nuevo al igual que en los 2 primeros ciclos del proyecto se mantiene la arquitectura.
Para más información se puede revisar el apartado del ciclo 1 donde queda explicada.
Se amplían las clases de negocio vistas anteriormente con las nuevas referentes a este ciclo.
En este caso los diagramas y apartados quedarán algo más densos debido a la mayor extensión
de esta última parte de la aplicación.
8.2.2.2 OBJETOS DE NEGOCIO
Los nuevos objetos de negocio van a ser las clases Comedor, Habitación, TipoHabitación,
ReservaHabitación y ReservaComedor.
Los nombres son bastante descriptivos de lo que representarán en la aplicación. En la parte

dedicada a las reservas de habitaciones estarían Habitación y su TipoHabitación. Por ejemplo,
una Habitación tendría un número y el tipo contendría una descripción de esa habitación, si es
doble o individual, la capacidad o el precio...
La ReservaHabitación es otra clase que representa una reserva de una habitación de un

usuario en unas fechas concretas.
En la parte de reservas de comedor quedarían las clases Comedor, que sería una clase de
tipo Singleton representando al comedor del hostal. Este tendría una capacidad que sería
ocupada por los usuarios no alojados en el hostal.
La clase ReservaComedor representa, como su nombre indica, a una reserva de unas

determinadas plazas del comedor.
Podía haberse intentado una generalización con la clase Reserva: ReservaComedor y

ReservaHabitación pero se ha considerado que no sería muy útil ya que prácticamente solo
mantienen como elementos comunes que ambas reservas las realiza un Usuario y tienen un
identificador.
118
A continuación se muestra el diagrama de clases que intervienen en este ciclo.
Ilustración 57: Diagrama Clases Ciclo 3
8.2.2.3 CLASES DE PERSISTENCIA
Las clases utilizadas para interactuar con la base de datos serán HabitacionesBD,
ReservasHabitacionBD y ComedorBD.
En el esquema de abajo se pueden ver los métodos de cada clase.
119
Ilustración 58: Diagrama Clases BD Ciclo 3
8.2.2.4 ACTIONFORMS
Los ActionForms que manejarán la información de los formularios de esta parte de la

aplicación serán:
 HabitacionActionForm
 ObtenerHabitacionesActionForm
 ObtenerReservasActionForm
 EstadisticasActionForm
 ReservaActionForm
 ComedorActionForm
120
8.2.2.5 ACTIONS
Los Actions de este tercer ciclo serán mostrados en las siguientes tablas:
ACTIONS GESTIÓN DE HABITACIONES
Actions Descripción
AltaHabitacionAction Acción utilizada para añadir una nueva habitación.
GetHabitacionesAction Acción usada para recuperar listados de
habitaciones.
DisplayDatosHabitacionAction Acción usada para mostrar los datos de una
habitación.
FiltrarHabitacionesAction Acción que devolverá una lista de habitaciones
según un criterio de filtro.
BorrarHabitacionAction Acción utilizada para dar de baja una habitación.
ModificarHabitacionesAction Acción empleada para modificar una habitación.
AltaTipoHabitacionAction Acción usada en el proceso de creación de un
nuevo tipo de habitación
BorrarTipoHabitacionAction Acción utilizada para borrar un tipo de habitación.
DisplayDatosTipoHabitacionAction Acción utilizada para mostrar los datos de un tipo
de habitación.
GetTiposHabitacionesAction Acción empleada para devolver una lista con todos
los tipos de habitaciones existentes.
ModificarTipoHabitacionAction Acción empleada para modificar un tipo de
habitación.
MostrarTiposHabitacionHostal Acción que carga los tipos de habitación que
dispone el hostal.
Ilustración 59: Tabla Actions Habitaciones
ACTIONS RESERVA DE HABITACIONES
ContinuarReserva2Action Acción usada en el paso 2 del proceso
de reserva de habitación por un usuario.
ContinuarReservaAction Acción usada durante el paso 1 de la
reserva de habitación por un usuario.
DisplayDatosReservaAction Acción que muestra los datos de una
reserva de habitación.
DisplayDatosReservaAdminAction Acción que le muestra al administrador
los datos de una reserva de habitación.
DisplayDatosReservaCerradaAdminAction Acción que le muestra al administrador
121
los datos de una reserva de habitación ya
finalizada.
FiltrarReservasAbiertasAction Acción que devuelve una lista con las
reservas que han pasado un filtro.
FiltrarReservasAction Acción que filtra una serie de reservas
de habitación y las muestra en una lista.
GetReservasAbiertasAction Acción que devuelve una lista al
administrador con todas las reservas aún
abiertas.
GetReservasAbiertasUsuarioAction Acción que devuelve una lista con todas
las reservas aún abiertas de un usuario.
GetReservasAction Acción que devuelve una lista al con
todas las reservas registradas.
GetReservasUsuarioAction Acción que devuelve una lista al
administrador con todas las reservas de un
usuario.
SellarReservaAction Acción que finaliza definitivamente una
reserva de habitación marcándola como
pagada o como cancelada.
SeleccionarFechaReservaAction Acción usada en el proceso de reserva
para marcar las fechas de reservas elegidas
por el usuario.
RegistrarReservaHabitacionAction Acción que registra la reserva del
usuario.
Ilustración 60: Tabla Actions Reservas Habitaciones
ACTIONS RESERVA DE COMEDOR
DisplayReservaComedorAdminAction Acción que muestra los datos de una
reserva del comedor elegida por el
administrador.
FiltrarReservasComedorAction Acción que muestra una lista filtrada de
reservas de comedor.
SellarReservaComedorAction Acción que finaliza definitivamente una
reserva de comedor.
GetReservasComedorAdmAction Acción que devuelve al administrador
una lista de todas las reservas.
GetReservasComedorUsuarioAction Acción que devuelve al usuario una lista
de todas sus reservas.
DisplayDatosReservaComedorAction Acción que muestra los datos de una
reserva del comedor.
FiltrarReservasComedorAbiertasAction Acción que devuelve una lista filtrada de
122
todas las reservas del comedor.
GetReservasComedorAbiertasAdminAction Acción que devuelve al administrador
una lista de todas las reservas del comedor
abiertas.
GetReservasComedorAbiertasUsuarioAction Acción que devuelve al usuario una lista
de todas las reservas del comedor abiertas.
RegistrarReservaComedorAction Acción que guarda una reserva de
comedor de un usuario.
SeleccionarFechaReservaComedorAction Acción que guarda la fecha elegida por el
usuario para la realización de la reserva.
ModificarCapacidadComedor Acción que cambia la capacidad del
comedor.
DisplayDatosReservaComedorAction Acción que le muestra al usuario los
datos de su reserva de comedor.
Ilustración 61: Tabla Actions Reservas Comedor
ACTIONS ESTADÍSTICAS
GraficaOcupacionComedorDiaAction Acción que crea una gráfica de estadísticas
de la ocupación del comedor en un día elegido.
GraficaOcupacionDiaAction Acción que crea una gráfica de estadísticas
de la ocupación de las habitaciones del hostal
en un día elegido.
GraficaOcupacionHostalMesAction Acción que crea una gráfica con la
ocupación del hostal en un año representada
en meses.
GraficaOcupacionTipoPensionAction Acción que crea una gráfica con los % de los
tipos de pensión elegidos para los usuarios en
un año.
GraficaPedidosTrimestreAction Acción que crea una gráfica con el número
de pedidos mensual de un año seleccionado.
GraficaRegistrosAñoAction Acción que muestra un diagrama de barras
con el número de registros anual
representándolos por meses.
GraficaReservasComedorTrimestreAction Acción que crea una gráfica con la
ocupación del comedor en un año
representada en trimestres.
Ilustración 62: Tabla Actions Estadísticas
123
En este apartado del ciclo 3 se va a finalizar el diseño de la base de datos de la aplicación.

Se añadirán las nuevas entidades y tablas al diseño de los ciclos anteriores.
8.2.3.2 REQUISITOS DE LA BASE DE DATOS RELATIVOS AL CICLO3
El hostal almacenará las habitaciones con un número y estas serán descritas por un tipo de
habitación. Cada tipo de habitación tendrá una descripción, un precio y el número de personas
que pueden ocuparla.
Se guardarán tanto las reservas de habitaciones como las reservas relativas al comedor. En
las reservas de habitaciones interesará guardar el usuario que la ha hecho, las fechas de
entrada y salida, la fecha de la reserva, la habitación elegida y el precio total.
En las reservas de comedor se almacenará información como el número de personas que

irán al comedor por reserva, la fecha, el horario, el usuario que la ha realizado y el precio final.
Todas las reservas, sean del tipo que sean, tendrán un identificador único y se quiere saber
si están finalizadas (pagadas o canceladas) o no para mostrar distintos listados en la aplicación.
Interesa almacenar también el tamaño del comedor para poder modificarlo en el futuro si
se diera el caso. Solo hay un comedor puesto a disposición de los clientes no alojados, sin más
posibles divisiones.
La figura que se ve abajo representa el diagrama Entidad Relación relativo al ciclo 3. Se va a

pasar a explicar solo las nuevas entidades porque las de los ciclos anteriores ya se
mencionaron.
Habitación: Representa las habitaciones del hostal con el identificador del tipo de
habitación que las describirá.
TipoHabitación: Entidad descriptora de habitaciones, con un precio o números de
ocupantes.
ReservaHabitación: Representa las reservas de habitaciones realizadas por los usuarios con
su fecha de entrada, fecha de salida, habitación o precio.
124
ReservaComedor: Esta entidad representa las reservas de comedor hechas por los usuarios
registrados de la web con el número de personas que acudirán a comer y otra información
relevante.
ConfigComedor: Entidad que representa al comedor del hostal y almacena solamente su
capacidad.
DIAGRAMA EER
El esquema de abajo representa el diagrama EER de la base de datos del ciclo 3.
TABLAS RESULTANTES
Han aparecido nuevas tablas en la conversión del esquema EER. Habrá 2 tablas para
registrar las reservas de habitación y reservas de comedor canceladas. Y una para almacenar
la capacidad del comedor.
125
NORMALIZACIÓN
Las nuevas tablas cumplen: 1FN, 2FN y 3FN
Claves candidatas
Las claves serán unos identificadores autoincrementados en Habitación, TipoHabitación,

ReservaHabitación y ReservaComedor. En ConfigComedor al ser una tabla de configuración y
haber solo un comedor no se pondrá ninguna clave. Y en las tablas de canceladas la clave será
conjunta el identificador de las reservas.
126
Ilustración 64: Diagrama Tablas Ciclo 3
8.2.4 INTERFACES GRÁFICAS
A continuación se van a mostrar una serie de pantallas realizadas durante este último ciclo
de la aplicación.
8.2.4.1 GRÁFICA REPRESENTATIVA DE OCUPACIÓN DEL HOSTAL UN DETERMINADO

AÑO
La siguiente pantalla muestra una gráfica del tipo de pensión elegido por los clientes en un
año concreto. Las gráficas son realizadas con jfreechart y son altamente personalizables en
colores, tamaños, etiquetas...
127
Ilustración 65: Interfaz Gráfica Tipo Ocupación hostal
8.2.4.2 GRÁFICA REPRESENTATIVA DE OCUPACIÓN DEL HOSTAL UN DETERMINADO

DÍA
Otra gráfica generada con jfreechart. Ésta muestra la ocupación de las habitaciones del
hostal en un día concreto elegido por el administrador.
Ilustración 66: Interfaz Gráfica % Ocupación Hostal
128
8.2.4.3 MENÚ PRINCIPAL DE LA GESTIÓN DE HABITACIONES Y COMEDOR
Pantalla del menú de administrador general para realizar operaciones relacionadas con la
estructura del hostal restaurante.
Ilustración 67: Interfaz Administración hostal
8.2.4.4 PÁGINA DE SELECCIÓN DE FECHAS PARA UNA RESERVA DE HABITACIÓN
Página pública mostrada a los internautas para comprobar si hay habitaciones libres en
unas determinadas fechas. Si se eligen fechas de forma errónea saldrá un error indicándolo.
129
Ilustración 68: Interfaz Elección Fechas Reserva Habitación
8.2.4.5 PARTE DE LA PÁGINA DE CREACIÓN D E GRÁFICAS ESTADÍSTICAS
La siguiente imagen muestra parte del apartado indicado a la generación y muestra de

gráficas estadísticas. Cada gráfica se genera mediante un formulando seleccionando unas
fechas.
130
Ilustración 69: Interfaz Generación Gráficas
131
En el desarrollo del ciclo 3 se siguen utilizando las mismas tecnologías explicadas en los
anteriores ciclos.
Como novedad en este ciclo se ha hecho uso de una librería Java llamada jFreeChart.
http://www.jfree.org/jfreechart/ Esta librería ha sido empleada para facilitar la creación de
gráficos de calidad y de todo tipo en Java.
Para elegir las fechas de reservas, tanto de comedor como de habitación se ha utilizado un
calendario libre hecho en Javascript.
http://www.rainforestnet.com/datetimepicker/datetimepicker.htm
La estructura de carpetas seguirá el mismo patrón que en las implementaciones pasadas.

Se han añadido los nuevos directorios referentes a las clases .java y las páginas JSP de este
tercer ciclo.
Se añadirán las clases correspondientes a las carpetas objetos, forms y bd.
Y las nuevas carpetas serán:
 Web/WEB-INF/Comedor
 Web/WEB-INF/ReservasHabitación
 Web/WEB-INF/Estadisticas
 Actions.comedor
 Actions.estadisticas
 Actions.reservashabitacion
132
EJEMPLO JFREECHART, DIAGRAMA DE SECTORES
133
Ilustración 70: Código Action Gráfica
En la figura de arriba se muestra un ejemplo de Action en el que se ha utilizado Jfreechart

para la creación de una gráfica.
El proceso es simple usando las librerías que proporciona Jfreechart. En este ejemplo se
crea un diagrama de sectores con el % de mesas libres y ocupadas en un determinado día.
1. Se empieza creando un objeto de tipo pieDataset (DefaultPieDataset pieDataset =
new DefaultPieDataset();)
2. Se obtienen los valores a mostrar en esa gráfica.
3. Se asignan los valores al objeto pieDataSet (pieDataset.setValue(porcMesaslibres +
"% Mesas libres", porcMesaslibres);)
4. Se crea la gráfica final de utilizando el pieDataSet iniciado anteriormente y unos
valores como el titulo u otros datos que se quiere que aparezcan en la gráfica.
(JFreeChart chart = ChartFactory.createPieChart("Ocupación comedor " + horario + "
" + fecha, pieDataset, true, true, false);)
5. Se exporta en un archivo JPEG que será mostrado en la aplicación.
(ChartUtilities.saveChartAsJPEG( new
File(this.getServlet().getServletContext().getRealPath(".") +
"/images/graficos/DiagramaOcupacionComedorDia.jpg"), chart, 500, 300);)
CALENDARIO
Se ha decidido utilizar un calendario gráfico para la inserción de fechas. De esta manera se

elimina el problema de una inserción de fechas en un formato erróneo. El calendario es libre y
de fácil implementación, simplemente se tiene que hacer referencia al archivo js
datetimepicker_css.js y ejecutar el método NewCssCal('demo1','ddMMyyyy') . El primer
parámetro representa un nombre identificativo y el segundo el formato de fecha elegido. El
calendario posee varias opciones más como incluir una hora pero no es necesario para esta
aplicación.
134
Ilustración 71: Interfaz Calendario
ENVÍO EMAIL TRAS RESERVA
La aplicación enviará en determinadas ocasiones emails a los usuarios. Cuando un usuario

realice un pedido o una reserva recibirá un email con un resumen y confirmación de la misma.
Debido a ser un proyecto sin hosting ni servidor planteado inicialmente, se usará una
cuenta de Google para el envío de emails.
Para realizar este cometido se ha empleado una clase Email genérica y dependiendo del
tipo de email que sea se cambiará el asunto o el contenido. Para el envío se ha hecho uso de
una serie de clases de javax.mail
135
Ilustración 72: Código envío email
136
8.4 PRUEBAS CICLO 3
8.4.1 INTRODUCCIÓN
Las pruebas que se van a realizar en este último ciclo se centrarán en testear el
funcionamiento de los procesos de reservas, de la gestión de habitaciones y comedor, de la
generación de estadísticas y de la muestra de listados de reservas.
Con la validación de formularios se asegurará que los datos introducidos por los usuarios
son correctos para su posterior tratamiento por la aplicación.
Se validarán los formularios que intervienen en la gestión de habitaciones, gestión de

comedor y aquellos que sean usados en las reservas.
ALTA DE HABITACIÓN

Número
Unicidad Número no existe Número existe (AH2)
(AH1)
MODIFICACIÓN DE HABITACIÓN

Número
Unicidad Número no existe Número existe (MH2)
(MH1)
Caso válido
Prueba Unitaria 18
Descripción Alta de una nueva habitación
137
Entradas Número: “1”
Tipo Habitación: “Habitación doble”
Clases de (AH1)
equivalencia
esperado
Caso no válido
Prueba Unitaria 19
Descripción Alta de una nueva habitación
Entradas Número: “1”(existiendo)
Clases de (AH2)
equivalencia
Resultado Ya existe una habitación con ese nombre.
esperado
MODIFICACIÓN DE HABITACIÓN
Caso válido
Prueba Unitaria 20
Descripción Modificación de una habitación
Entradas Número: “1”(cambio a “2”)
Clases de (MH1)
equivalencia
esperado
Caso no válido
Prueba Unitaria 21
Entradas Número: “1”(cambio a “3” existiendo)
Clases de (MH2)
equivalencia
Resultado Ya existe una habitación con ese nombre.
esperado
138
ALTA DE TIPO DE HABITACIÓN

Número
Unicidad Número no existe Número existe (AH2)
(AH1)
MODIFICACIÓN DE TIPO DE HABITACIÓN

Número
Unicidad Número no existe Número existe (MH2)
(MH1)
CASOS DE PRUEBA
ALTA DE TIPO DE HABITACIÓN
Caso válido
Prueba Unitaria 22
Descripción Alta de un nuevo tipo de habitación
Entradas Descripción: “Habitación doble”
Precio:20
Ocupantes:2
Clases de (AH1)
equivalencia
esperado
Caso no válido
Prueba Unitaria 23
Descripción Alta de un nuevo tipo de habitación
Entradas Descripción: “Habitación doble” (existiendo)
Precio:20
Ocupantes:2
Clases de (AH2)
equivalencia
Resultado Ya existe un tipo de habitación con esa descripción.
139
esperado
MODIFICACIÓN DE TIPO DE HABITACIÓN
Caso válido
Prueba Unitaria 24
Descripción Modificación de un nuevo tipo de habitación
Entradas Descripción: “Habitación doble” (cambio a “habitación triple”)
Precio:20
Ocupantes:2
Clases de (MH1)
equivalencia
esperado
Caso no válido
Prueba Unitaria 25
Descripción Modificación de un nuevo tipo de habitación
Entradas Descripción: “Habitación doble” (cambio a “habitación triple”
existiendo)
Precio:20
Ocupantes:2
Clases de (MH2)
equivalencia
Resultado Ya existe un tipo de habitación con esa descripción.
esperado
8.4.4 RESULTADO PRUEBAS
Se han realizado distintas pruebas para comprobar el correcto funcionamiento de las

operaciones de este tercer ciclo. Se han encontrado algunos errores en el sistema de reservas
de habitaciones que ya están solucionados.
En las pruebas se personalizaron más las gráficas cambiando algunos colores y leyendas. En
las habitaciones se añadió restricciones en la base de datos para que no pudieran tener la
misma descripción.
140
9. PRUEBAS FINALES
9.1 PRUEBAS DE INTEGRACIÓN
Por último se van a seguir una serie de pasos para probar la integración de los tres ciclos
conjuntamente.
Los pasos y pruebas a realizar serán:
Con adminGeneral:
1. Se darán de alta a varios usuarios, unos serán adminRecepción, otros adminCocina y

otros Usuarios normales.
2. Se modificarán y borrarán algunos.
3. Se crearán tipos de habitación y habitaciones asociadas a esos tipos.
4. Se crearán unas habitaciones asociadas a esos tipos.
5. Se crearán varias gráficas estadísticas .
Con adminCocina:
1. Se crearán unos tipos de productos y unos productos para ponerlos a la venta en la

web.
2. Una vez que los usuarios hayan hecho sus pedidos unos se cancelarán y otros se
marcarán como pagados, se comprobarán en los listados los cambios de estado.
3. Se comprobarán, marcarán como pagadas o canceladas varias reservas de comedor.
Con usuario:
1. Se harán varios pedidos en la aplicación.

2. Se harán varias reservas de habitaciones en la aplicación.
3. Se harán reservas de plazas en el comedor del restaurante.
4. Se mirarán sus historiales de pedidos y reservas para ver los cambios de las mismas.
5. Se realizará un reserva simultánea de una misma habitación en mismas fechas entre 2
usuarios.
6. Se realizará una reserva simultánea de sitio en el comedor que supere la capacidad
del mismo.
7. Se modificará los datos de la cuenta.
8. Se eliminará la cuenta.
141
Con adminRecepcion:
1. Se atenderán las reservas efectuadas por el usuario, cancelando unas y marcando

como pagadas las otras.
2. Se observarán en los listados como cambian de situación, de abiertas a pagadas o
canceladas.
9.2 PRUEBAS DE SISTEMA
Para probar el sistema final completo hay que ejecutar con éxito cada uno de los requisitos
funcionales requeridos.
Como no existe un cliente como tal, seremos nosotros los que valoraremos si se ha
cumplido con los mínimos de un proyecto de este estilo.
Se han ejecutado correctamente todos los requisitos, así que se darán por finalizadas las
pruebas y se declarará el proyecto como concluido.
142
10. CONCLUSIONES
Esta sección pretende recoger las impresiones finales del alumno sobre la totalidad del
proyecto.
10.1 COMPARATIVA ENTRE OBJETIVOS Y RESULTADOS OBTENIDOS
En el apartado de Alcance recogido en el documento de objetivos se plantearon los

objetivos a cubrir con la realización de este proyecto, se resumían en:
 Mostrar información del hostal: Tarifas, situación geográfica, habitaciones, comedor,

productos.
 Gestión de reservas online: Habitaciones y comedor.
 Gestión online de pedidos de productos de restaurante.
 Gestión de usuarios: Registro obligatorio de clientes para reservas y pedidos,
diferentes permisos para el personal y administradores del hostal.
 Historiales: Historial de pedidos, reservas de habitaciones y reservas de mesas del
comedor.
 Estadísticas: Diferentes gráficas con estadísticas del hostal-restaurante.
Tras terminar la aplicación se ha comprobado que los objetivos se han cumplido

satisfactoriamente. El desarrollo de estos objetivos fue dividido en ciclos con el fin de mejorar
la organización y planificación del proyecto.
En el ciclo 1 se cubrieron los objetivos:
 Gestión y listados de usuarios.
Sirvió también para una mayor toma de contacto con el entorno de Struts.
El ciclo 2 se desarrollaron los objetivos:
 Gestión de pedidos, historiales de pedidos.
En el tercer y último ciclo tuvieron cabida:
 Gestión de reservas de habitaciones.

 Gestión de reservas de comedor.
 Historiales de reservas.
 Gráficas estadísticas.
143
10.2 POSIBLES MEJORAS Y AMPLIACIONES
La aplicación podría ser ampliada en el futuro conforme a las necesidades de un cliente

final que la pudiera utilizar. Se podría añadir por ejemplo una pasarela de pago para que los
clientes a la vez que hicieran un pedido lo pagaran.
Otra ampliación podría ser la adición de un sistema de envío de sms que avisara al cliente
de ciertas informaciones, como pudiera ser el aviso de una reserva o de que un pedido
estuviera listo para recoger.
10.3 VISIÓN PERSONAL
Finalizado el proyecto me considero satisfecho del resultado obtenido. Se ha conseguido

crear una aplicación web cubriendo las necesidades y objetivos planteados.
Uno de los aspectos que más se incide en la carrera es el relativo a las fases a seguir
durante todo el proceso de creación de software y su respectiva documentación. Aunque a
veces el alumno no valore toda esta “teoría” una vez que te pones a desarrollar una aplicación
de tamaño medio o grande te das cuenta de su importancia.
El tiempo que se gasta en una buena planificación de tareas, en un análisis o un diseño es

recompensado con creces luego a la hora de programar. De otra manera hay que andar con
cambios “sobre la marcha” que provocan muchas pérdidas de tiempo.
En lo que se refiere a la planificación personal creo que podía haber sido muy mejorable
por mi parte. Debido a varios factores personales no he ocupado horas que estaban dedicadas
al proyecto. Eso ha provocado que se haya retrasado demasiado la finalización del mismo.
También me interesaba mejorar mis conocimientos en Java y en la programación web en

general. Y otro de los objetivos del proyecto era el de aprender a utilizar algún framework de
desarrollo de software y con Struts he conseguido unas nociones que me serán útiles en el
futuro..
Sin embargo, la utilización de frameworks está tan extendida en el desarrollo de

aplicaciones como ésta que, lo que al comienzo del proyecto suponía una novedad y un
aliciente de aprendizaje hace más de dos años, en la actualidad ha perdido cierto sentido.
144
11. GLOSARIO DE TÉRMINOS
Framework: Herramienta que facilita el desarrollo de software ofreciendo una serie de

clases y utilidades.
Struts: Framework de apache para aplicaciones web desarrolladas en Java.
ActionServlet: Controlador de Struts que maneja el flujo de operaciones de la aplicación.
Action: Clase de Struts empleada en la ejecución de un formulario.
ActionForm: Clase de Struts usada en la captura de datos de los formularios.
Struts-config.xml: Archivo xml de configuración de Struts donde se definen entre otras

cosas los Action y los ActionForm de la aplicación.
Ciclo: Iteración del proyecto.
adminCocina: Administrador o encargado de la parte relacionada con la cocina del

restaurante.
adminRecepción: Administrador o encargado de la parte relacionada con la recepción de

hospedados al hostal.
adminGeneral: Encargado general del hostal restaurante.
145
12. BIBLIOGRAFÍA
Libros
 Desarrollo de aplicaciones web dinámicas con XML y Java. [David Parsons, Anaya]
 Ingeniería del Software [Sommerville]
Referencias Web:
 Foro preguntas-respuestas de programación http://stackoverflow.com/

 Página con tutoriales de diseño web. http://w3schools.com/
 Guía de usuario de la web oficial de Struts
http://struts.apache.org/development/1.x/userGuide/
 http://www.roseindia.net
 Pequeña introducción a Struts
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=miPrimeraWebStr
uts
 http://dev.mysql.com/doc/
 http://www.coderanch.com/
146
13. ANEXOS
13.1 DISEÑO WEB
13.1.1 INTRODUCCIÓN
Durante la redacción de la memoria se ha hecho sobretodo hincapié a la parte de

programación de la web. La parte de diseño ha quedado en un segundo plano. Por ello en esta
sección se va a explicar de manera muy breve el diseño web.
13.1.2 PROCESO
El diseño de la web fue empezado en papel recogiendo las secciones que debía tener la
aplicación. Se creó un diseño final utilizando hojas de estilo para mejorar la mantenibilidad de
la web.
Se han utilizado principalmente capas (div) combinadas con tablas para posicionar los
elementos en la web. Se ha cargado 2 hojas de estilo distintas dependiendo del navegador (IE
o Firefox, Chrome...) para la correcta visualización en todos navegadores.
En la aplicación se muestra información pública del hostal como marcaban los requisitos.,
tales como la situación, los precios o información típica de un hostal-restaurante.
13.1.3 IMÁGENES
Todas las imágenes o iconos empleados han sido sacados de repositorios libres de internet.
Las imágenes de habitaciones o elementos del hostal restaurante pertenecen al Hostal
Merced-Concordia y han sido utilizadas con su consentimiento para la realización de este
proyecto.
13.2 LEY ORGÁNICA DE PROTECCIÓN DE DATOS
Como se ha visto en esta memoria, la aplicación creada necesitará recopilar datos relativos
a personas físicas para su funcionamiento. La aplicación estaría, en principio, planteada para
ser usada en España por lo que debería adaptarse a la legislación española. En este sentido
está creada la Ley Orgánica 15/1999, de Protección de Datos de Carácter Personal (LOPD).
http://noticias.juridicas.com/base_datos/Admin/lo15-1999.html
147
La presente Ley Orgánica tiene por objeto garantizar y proteger, en lo que concierne al
tratamiento de los datos personales, las libertades públicas y los derechos fundamentales de
las personas físicas, y especialmente de su honor e intimidad personal y familiar.
Para cumplir los requerimientos de dicha ley la empresa deberá básicamente de:
 Informar de la existencia de un fichero o ficheros con datos de carácter personal
relativos a los usuarios registrados.
 Notificar los ficheros ante el Registro General de Protección de Datos para su
inscripción.
 Facilitar y garantizar el derecho del acceso, modificación, cancelación de esos datos.
 Obtener el consentimiento para el tratamiento de los datos personales.
 Asegurarse que los datos son veraces y han sido obtenidos lícita y legítimamente y
tratados para los fines que fueron obtenidos.
Para más información se puede mirar esta guía puesta por la agencia de protección de
datos.
http://www.agpd.es/portalwebAGPD/canaldocumentacion/publicaciones/common/pdfs/guia
_responsable_ficheros.pdf
13.3 MANUAL DE INSTALACIÓN Y DESPLIEGUE
En el cd del proyecto se va a entregar el código fuente desarrollado con NetBeans aunque

para desplegar la aplicación basta con el archivo .war generado, la base de datos .sql, el
servidor Glassfish y los servicios de apache y mysql.
13.3.2 REQUISITOS
Este breve manual está pensado para el despliegue en un entorno Windows. Será necesario
tener instalado JDK, los servicios de Apache y MySql y el servidor GlassFish.
13.3.3 BASE DE DATOS, MYSQL Y APACHE
Para instalar los servicios de mysql, apache y cargar la base de datos lo más simple es
descargarse Xampp http://www.apachefriends.org/es/xampp.html
Xampp es un servidor independiente de software libre que permite la instalación de un

servidor apache y una base de datos Mysql de forma sencilla. Incluye la herramienta
phpMyAdmin para manejar fácilmente ese tipo de bases de datos.
148
Ilustración 73: Recorte de pantalla de Xampp
Con Xampp instalado para cargar la base de datos hay que:
1. Iniciar los servicios de apache y mysql.

2. Ir al navegador y en la ruta poner localhost.
3. Ir a phpmyadmin.
4. Crear base de datos con nombre hostalbd.
5. En la pestaña importar cargar el archivo .sql
Ilustración 74: Recorte de myphpadmin
149
En el proceso de carga se ejecutan automáticamente todas las consultas incluidas en ese
archivo y al finalizar ya se tiene la base de datos instalada.
13.3.4 INSTALACIÓN DE SERVIDOR DE APLICACIONES WEB Y DESPLIEGUE
Para cargar e implementar la aplicación se usará Glassfish.

https://glassfish.java.net/es/downloads/3.0.1-final.html
Una vez instalado hay que utilizar la utilidad asadmin.

http://docs.oracle.com/cd/E18930_01/html/821-2416/giobi.html
Para ello se puede añadir al path de Windows la carpeta bin creada en la ruta de instalación
elegida para Glassfish, o ejecutar este comando en símbolo del sistema con la ruta completa
donde está asadmin.
asadmin start-domain
Una vez que el dominio está creado correctamente hay que escribir de nuevo en consola.
asadmin deploy {ruta al archivo .war}
Otra opción para desplegar la aplicación tras escribir el comando de asadmin start-domain
es entrar en la página de configuración de GlassFish en localhost:4848 . Tras escribir el usuario
y contraseña que elegimos en la instalación, habrá que ir al apartado aplicaciones desde
donde cargaremos el archivo .war.
Ilustración 75 : Pantalla del servidor GlassFish
150
Debería desplegarse también correctamente. Con la aplicación desplegada se puede
acceder a ella y probarla en http://localhost:8080/Hostal-PFC/index.jsp o clickeando en Iniciar
desde la página de Glassfish.
13.4 MANUAL DE ADMINISTRADOR Y USUARIO
Debido a que es una aplicación bastante entendible y común no es necesario crear un

manual muy extenso sobre cómo utilizarla. A continuación se pasará a mostrar brevemente
algunas descripciones y capturas de como cada tipo de usuario interactuaría con la web.
13.4.2 VISITANTE
Un visitante podrá ver información del hostal restaurante o registrarse en la página para
poder hacer pedidos o reservas.
Ilustración 76: Pantalla de información del hostal
151
Ilustración 77: Pantalla de registro de usuario
13.4.3 USUARIO
Un usuario registrado podrá ver y modificar sus datos en el enlace de perfil:
Ilustración 78: Perfil de usuario
También podrá realizar pedidos de productos desde el enlace de arriba de pedidos o desde
el del lateral.
152
Ilustración 79: Listado de productos a la venta
Irá seleccionando los que quiera comprar y finalizará su pedido clickeando primero en carro
y después en finalizar pedido.
Ilustración 80: Resumen del pedido
153
Un usuario también podrá realizar reservas de habitación y de comedor. Para las reservas
de habitación primero elegirá las fechas de entrada y salida para comprobar si hay
habitaciones libres.
Ilustración 81: Elección de fechas de reserva de habitación
Ilustración 82: Habitaciones libres para unas fechas
154
Si las hay, elegirá la habitación que le interese y completará la reserva.
Ilustración 83: Resumen de reserva de habitación
Respecto a las reservas de comedor, el usuario deberá elegir un horario, con su fecha y
número de personas que van a acudir.
Ilustración 84: Elección de datos para reserva de comedor.
Y confirmará la reserva si hay sitio suficiente.
155
Ilustración 85: Confirmación de reserva de comedor.
Finalmente un usuario podrá ver listados de sus pedidos y reservas abiertas o ya cerradas.
Ilustración 86: Pantalla de listados de pedidos
156
Ilustración 87: Pantalla de listados de reservas.
13.4.4 ADMINGENERAL
Un adminGeneral se encargará de la gestión de usuarios, de las habitaciones del hostal, del

tamaño del comedor y de la visualización de estadísticas.
El administrador podrá ver, modificar o crear usuarios desde el enlace de Gestión Usuarios:
Ilustración 88: Pantalla de administración de usuarios
157
Ilustración 89: Pantalla de listado de usuarios
En el apartado de Gestión Hostal podrá crear y modificar habitaciones y sus tipos y ajustar
el tamaño del comedor.
158
Ilustración 90: Pantalla de administración del hostal
Y en el enlace de estadísticas el administrador podrá crear unas gráficas con información

del estado del hostal restaurante. Podrá consultar datos de pedidos, registros o reservas según
elija crear una gráfica u otra.
159
Ilustración 91: Página de generación de gráficas
160
13.4.5 ADMINCOCINA
El administrador de cocina se encarga de todo lo relacionado con el sistema de pedidos.

Creará los productos puestos a la venta online, finalizará los pedidos y podrá configurar el
sistema con un horario de atención o actividad.
Ilustración 92: Menú administración cocina
En el menú de pedidos se podrá diferenciar entre los pedidos ya cerrados y los abiertos que
quedan por atender. Si se hace click en esos enlaces aparecerá un listado de pedidos donde se
podrá finalizarlos en el caso de que estén aún abiertos o simplemente consultarlos.
161
Ilustración 93: Pantalla administración de pedidos
Ilustración 94: Pantalla de finalización de pedido
162
En sistema de pedidos estará toda la configuración:
Ilustración 95: Configuración de sistema de pedidos
El apartado de reservas de comedor será bastante similar, se podrán ver listados de

reservas, abiertas o cerradas, que se podrán consultar o finalizar.
Ilustración 96: Pantalla de administración de comedor
163
Ilustración 97: Listado de reservas de comedor
Ilustración 98: Finalización de reserva de comedor.
164
13.4.6 ADMINRECEPCIÓN
Los administradores de recepción serán los encargados en gestionar las reservas online,
atendiendo a las entradas de clientes en el hostal con su reserva anteriormente hecha.
Tendrán listados de reservas que deberán finalizar cuando el cliente deje el hostal o cuando
cancele esa reserva.
Ilustración 99: Menú administración de la recepción
Ilustración 100: Listado de reservas de habitación abiertas
165
Elegirán la reserva abierta que deseen y la finalizarán.
Ilustración 101: Resumen de reserva de habitación a finalizar
166

R000001695 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

R000001695 PDF

Cargado por

Copyright:

Formatos disponibles

PROYECTO FIN DE CARRERA

Aplicación web para la gestión de un hostal-restaurante

Pablo Cacho Zueco

Laureano Lambán Pardo

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Proyecto Fin de Carrera

Facultad de Ciencias, Estudios Agroalimentarios e Informática

PROYECTO FIN DE CARRERA

Aplicación web para la gestión de un hostal-

Alumno: Pablo Cacho Zueco

Logroño, Junio de 2013

1.2 MOTIVO DE LA ELECCIÓN

El objetivo del proyecto es la creación de un portal web para la gestión, control y

A pesar de basarse en un caso bastante concreto se pretende buscar en la medida de lo

La aplicación atenderá las peticiones de diferentes roles de usuarios. A continuación se

 Mostrar información del hostal: tarifas, situación geográfica, habitaciones.

Los entregables del proyecto serán:

2.5 METODOLOGÍA DE DESARROLLO

Se usará como metodología de desarrollo el Proceso Unificado. Se ha escogido ya que se

El utilizar un ciclo de vida iterativo e incremental permitirá añadir y mejorar la aplicación a

Los esquemas y diagramas se harán fundamentalmente en UML.

2.6 TECNOLOGÍAS Y HERRAMIENTAS A USAR

Durante la creación del proyecto se van a utilizar las siguientes herramientas:

 Java EE -> Plataforma de Programación para desarrollar software.

2.7 RECURSOS HUMANOS Y COMUNICACIONES

En el desarrollo del proyecto participarán las siguientes personas:

Pablo Cacho: alumno de ITIG, será el desarrollador único y principal, se encargará de la

Laureano Lamban: director del alumno.

2.8 RIESGOS Y PLANES DE ACCIÓN

2.8.1 POSIBLES RIESGOS

1. El primer factor sería la inexperiencia del alumno en la creación de proyectos del

2.8.2 PLANES DE ACCIÓN

1. Se buscará información y se consultará otros proyectos parecidos con el fin de obtener

El proyecto se va a descomponer en una serie de tareas bien diferenciadas como forma de

Se mostrarán a continuación la descripción de estas tareas y unos esquemas

TAREA 1: SEGUIMIENTO DEL PROYECTO

La tarea número 1 es la relativa al control y revisiones del proyecto a lo largo de todo su

TAREA 2: GENERACIÓN MEMORIA

La segunda tarea va a estar dedicada a la generación de la memoria del proyecto. Durante

TAREA 3: PREPARACIÓN PREVIA

TAREA 4: ESPECIFICACIÓN DE REQUISITOS

TAREA 5, 6 Y 7: CICLO 1, CICLO 2 Y CICLO 3

Cada tarea y ciclo consta de Análisis, Diseño, Implementación y Pruebas.

TAREA 8: PRUEBAS FINALES

TAREA 9: DOCUMENTACIÓN FINAL

La novena tarea es la redacción de un manual de instalación de la aplicación. Este manual

TAREA 10: DEFENSA

Y finalmente se realizará la defensa ante los miembros del tribunal.

2.10.1 CALENDARIO DE TRABAJO

En el momento que se ha hecho la planificación se dispone de disponibilidad total para

2.10.2 ESTIMACIÓN TE MPORAL

Estudio de herramientas 25 22/02/12 27/02/12

2.11 DIAGRAMA GANTT

A continuación se muestran varios diagramas de Gantt con la planificación inicial del

Ilustración 4: Diagrama Gantt Inicial

Ilustración 5 : Diagrama de Gantt Ciclo 1

Ilustración 7:Diagrama Gantt Ciclo 3

3.2 FACTORES DE RETRASO

3.3 PRIMERA REPLANIFICACIÓN

En la replanificación se retocará las fechas de finalización de cada parte del proyecto

Ilustración 8: Diagrama Gant Replanificación 1

Con el ciclo 3 prácticamente acabado surgen nuevos problemas de trabajo en la dedicación

Ilustración 9: Diagrama Gantt Replanificación 2