Aplicación web para la gestión de un hostal-restaurante
179
Pablo Cacho Zueco Aplicación web para la gestión de un hostal-restaurante Laureano Lambán Pardo Facultad de Ciencias, Estudios Agroalimentarios e Informática Proyecto Fin de Carrera Matemáticas y Computación 2012-2013 Título Autor/es Director/es Facultad Titulación Departamento PROYECTO FIN DE CARRERA Curso Académico
Transcript of Aplicación web para la gestión de un hostal-restaurante
Pablo Cacho Zueco
Aplicación web para la gestión de un hostal-restaurante
Laureano Lambán Pardo
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Proyecto Fin de Carrera
Matemáticas y Computación
2012-2013
Título
Autor/es
Director/es
Facultad
Titulación
Departamento
PROYECTO FIN DE CARRERA
Curso Académico
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.esE-mail: [email protected]
Aplicación web para la gestión de un hostal-restaurante, proyecto fin de carrerade Pablo Cacho Zueco, dirigido por Laureano Lambán Pardo (publicado por la Universidad
de La Rioja), se difunde bajo una LicenciaCreative 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.
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.
I
Í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
II
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
III
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
IV
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
V
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
VI
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
VII
Í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
VIII
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
IX
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
1
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.
2
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.
3
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
4
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
5
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…
6
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.
7
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.
9
Ilustración 1: Esquema división de tareas
9
Ilustración 2: Esquema división de tareas por ciclo
10
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 TEMPORAL
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:
TAREAS
DURACIÓN
ESTIMADA
(horas)
INICIO
PREVISTO
FIN
PREVISTO
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
11
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
Actividad y secuencia 7 27/03/12 27/03/12
Diseño 30 28/03/12 04/04/12
Diseño clases de negocio 12 28/03/12 29/03/12
Identificar clases y métodos 7 28/03/12 28/03/12
Diagrama de clases 5 29/03/12 29/03/12
Diseño BD 5 30/03/12 30/03/12
Creación diagrama ER 5 30/03/12 30/03/12
Diseño Web 13 02/04/12 04/04/12
Identificar páginas 3 02/04/12 02/04/12
Diseñar páginas 10 02/04/12 04/04/12
12
Implementación 121 05/04/12 20/04/12
Implementar código 115 05/04/12 20/04/12
Implementar BD 3 05/04/12 20/04/12
Documentar código y BD 3 05/04/12 20/04/12
Pruebas 7 23/04/12 23/04/12
Pruebas unitarias 5 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
Actividad y secuencia 12 24/04/12 26/04/12
Diseño 33 27/04/12 03/05/12
Diseño clases de negocio 12 27/04/12 28/04/12
Identificar clases y métodos 7 27/04/12 27/04/12
Diagrama de clases 5 28/04/12 28/04/12
Diseño BD 6 30/04/12 30/04/12
Creación diagrama ER 6 30/04/12 30/04/12
Diseño Web 15 01/05/12 02/05/12
Identificar páginas 3 01/05/12 01/05/12
Diseñar páginas 12 01/05/12 02/05/12
Implementación 158 03/05/12 01/06/12
Implementar código 150 03/05/12 01/06/12
Implementar BD 3 03/05/12 01/06/12
Documentar código y BD 5 03/05/12 01/06/12
Pruebas 7 02/06/12 03/06/12
Pruebas unitarias 5 02/06/12 02/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
13
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
14
Ilustración 6: Diagrama Gantt Ciclo 2
Ilustración 7:Diagrama Gantt Ciclo 3
15
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
16
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 FECHAS
Tarea Fecha fin
estimada
Fecha fin
replanificación 1
Fecha fin
replanificación 2
Fecha
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
finales
03/06/12 05/09/12 31/05/13 23/06/13
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
estimadas
Horas reales
Seguimiento 16 12
Memoria 107 120
Preparación 29 35
17
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
18
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.
19
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.
20
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.
21
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.
22
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
Precondición: El adminCocina debe de estar registrado y con la sesión iniciada.
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.
Precondición: El adminCocina debe de estar registrado y con la sesión iniciada.
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
23
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.
24
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.
25
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.
26
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.
27
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.
28
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.
29
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.
30
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
31
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.
32
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
33
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
34
Ilustración 16: Esquema estructural Struts
35
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.
36
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.
37
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.
38
Escenario
Principal:
1. Visitante introduce sus datos en un formulario.
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
Principal:
1. Usuario solicita ver sus datos.
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
Precondición: Usuario está registrado y ha iniciado sesión.
Postcondición: Datos son actualizados.
Escenario
Principal:
1. Usuario modifica sus datos en el formulario.
2. Sistema actualiza datos y muestra la confirmación.
3. Termina caso de uso.
Excepciones: Error en los datos introducidos en el formulario.
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
Principal:
1. Usuario solicita borrar su cuenta.
2. Sistema pide contraseña.
3. Usuario escribe contraseña.
4. Sistema borra usuario y confirma la correcta eliminación.
5. Termina caso de uso.
Excepciones: Error en la contraseña.
39
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
Principal:
1. Usuario solicita contraseña nueva.
2. Sistema pide datos al usuario.
3. Usuario escribe datos.
4. Sistema cambia contraseña y se la facilita al usuario.
5. Termina caso de uso.
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
Principal:
1. Administrador solicita un determinado listado de usuarios.
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.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Se muestra al usuario elegido.
Escenario
Principal:
1. Administrador pide listado de usuarios.
2. Sistema muestra lista de usuarios.
3. Administrador elige al usuario.
4. Sistema muestra usuario.
5. Termina caso de uso.
Excepciones:
40
MODIFICAR DATOS USUARIO
CASO DE USO: Modificar Datos Usuario
Descripción: Administrador quiere modificar datos de un usuario.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Usuario es modificado
Escenario
Principal:
1. Administrador pide listado de usuarios.
2. Sistema muestra lista de usuarios.
3. Administrador elige al usuario.
4. Sistema muestra usuario.
5. Administrador modifica usuario.
6. Termina caso de uso.
Excepciones: Error en los datos introducidos en el formulario.
Ilustración 18: Diagrama Actividad Modificar usuario
41
DAR DE ALTA USUARIO
CASO DE USO: Dar de Alta Usuario
Descripción: Administrador quiere dar de alta un nuevo usuario.
Actores: adminGeneral
Precondición: Administrador está registrado y se ha identificado correctamente.
Postcondición: Usuario nuevo es creado.
Escenario
Principal:
1. Administrador introduce datos de usuario en formulario.
2. Sistema crea y añade al nuevo usuario.
3. Termina caso de uso.
Excepciones: Error en los datos introducidos en el formulario.
DAR DE BAJA USUARIO
CASO DE USO: Dar de Baja Usuario
Descripción: Administrador quiere borrar a un usuario.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Usuario es borrado.
Escenario
Principal:
1. Administrador pide listado de usuarios.
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.
7. Termina caso de uso.
Excepciones:
42
6.2 DISEÑO CICLO 1
6.2.1 DISEÑO DE LA ARQUITECTURA
6.2.1.1 INTRODUCCIÓN
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
43
6.2.2 CLASES DE NEGOCIO
6.2.2.1 INTRODUCCIÓN
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.
44
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
45
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
46
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.
47
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
48
6.2.3 DISEÑO DE LA BASE DE DATOS
6.2.3.1 INTRODUCCIÓN
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.
49
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.
50
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.
51
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.
52
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.
53
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…
54
Ilustración 29:Interfaz Búsqueda de usuarios
55
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.
56
Ilustración 31:Interfaz datos de usuario
57
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
58
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.
59
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.
60
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.
61
Ilustración 33: Código Login Usuario Action
62
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
63
Ilustración 36: Código html confirmación borrado de usuario
64
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
65
Ejemplo de validación con captcha del formulario de registro:
Ilustración 38: Interfaz validación captcha
66
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)
Unicidad Email no existe (AU3) Email existe (AU4)
MODIFICACIÓN DE USUARIO
Condición Clases válidas Clases no válidas
Teléfono
Unicidad Teléfono no existe (MU1)
Teléfono existe (MU2)
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: “[email protected]”
67
Contraseña: ”1234”
Contraseña repetida: ”1234”
Captcha: CORRECTO
Clases de
equivalencia
(AU1)(AU3)
Resultado
esperado
Operación exitosa
Casos no válidos
Prueba Unitaria 2
Descripción Alta de un nuevo usuario
Entradas Nombre: “Pedro”
Apellidos: “Lopera García”
Dirección: “Gran Vía nº 7 26004 Logroño”
CP:"26006"
Teléfono : “622622622” (existiendo)
Teléfono repetido: “622622622”
Email: “[email protected]”
Contraseña: ”1234”
Contraseña repetida: ”1234”
Captcha: CORRECTO
Clases de
equivalencia
(AU2)
Resultado
esperado
Error, otro usuario tiene ese teléfono.
Prueba Unitaria 3
Descripción Alta de un nuevo usuario
Entradas Nombre: “Jaime”
Apellidos: “Lopera García”
Dirección: “Gran Vía nº 7 26004 Logroño”
CP:"26006"
Teléfono : “633633633”
Teléfono repetido: “633633633”
Email: [email protected] (existiendo)
Contraseña: ”1234”
Contraseña repetida: ”1234”
Captcha: CORRECTO
Clases de
equivalencia
(AU4)
Resultado
esperado
Error, otro usuario tiene ese email.
68
MODIFICAR USUARIO
Caso válido
Prueba Unitaria 4
Descripción Modificación de usuario
Entradas Nombre: “Jaime”
Apellidos: “Lopera García”
Dirección: “Gran Vía nº 7 26004 Logroño”
CP:"26006"
Teléfono : “644644644”
Teléfono repetido: “644644644”
Email: “[email protected]”
Contraseña: ”1234”
Contraseña repetida: ”1234”
Clases de
equivalencia
(MU1)(MU3)
Resultado
esperado
Operación exitosa
Casos no válidos
Prueba Unitaria 8
Descripción Modificación de usuario
Entradas Nombre: “Jaime”
Apellidos: “Lopera Bona”
Dirección: “Gran Vía nº 7 26004 Logroño”
CP:"26006"
Teléfono : “622622622” (existiendo)
Teléfono repetido: “622622622” (existiendo)
Email: “[email protected]”
Contraseña: ”1234”
Contraseña repetida: ”1234”
Clases de
equivalencia
(MU2)
Resultado
esperado
Error, otro usuario tiene ese teléfono.
Prueba Unitaria 9
Descripción Modificación de usuario
Entradas Nombre: “Jaime”
Apellidos: “Lopera Bona”
69
Dirección: “Gran Vía nº 7 26004 Logroño”
CP:"26006"
Teléfono : “622622622”
Teléfono repetido: “622622622”
Email: [email protected] (existiendo)
Contraseña: ”1234”
Contraseña repetida: ”1234”
Clases de
equivalencia
(MU3)
Resultado
esperado
Error, otro usuario tiene ese email.
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.
70
7. CICLO 2
7.1 ANÁLISIS CICLO 2
7.1.1 ANÁLISIS DE REQUISITOS
7.1.1.1 INTRODUCCIÓN
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.
7.1.1.2 USUARIOS INVOLUCRADOS
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.
7.1.1.3 REQUISITOS INVOLUCRADOS
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.
71
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.
Procedimiento: El administrador va a la sección donde se muestran los pedidos sin finalizar,
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.
Procedimiento: El administrador va a la sección donde se muestran los pedidos sin finalizar,
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.
72
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.
Precondición: El adminCocina debe estar registrado y con la sesión iniciada.
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.
Precondición: El adminCocina debe estar registrado y con la sesión iniciada.
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.
Precondición: El adminCocina debe estar registrado y con la sesión iniciada.
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.
73
7.1.1.4 CASOS DE USO
El siguiente esquema es el diagrama de casos de uso relativo a este segundo ciclo del
proyecto.
Ilustración 39: Diagrama Casos Uso Ciclo 2
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
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Producto es añadido a la BD.
Escenario
Principal:
1. Administrador rellena los datos del producto a añadir.
2. Sistema añade producto.
3. Termina caso de uso.
Excepciones: Error en los datos introducidos.
74
MODIFICAR PRODUCTO
CASO DE USO: Modificar producto
Descripción: Administrador quiere modificar un producto.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Producto es modificado.
Escenario
Principal:
1. Administrador pide listado de productos existentes.
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.
7. Termina caso de uso.
Excepciones: Error en los datos introducidos.
ELIMINAR PRODUCTO
CASO DE USO: Eliminar Producto
Descripción: Administrador quiere borrar un producto.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Producto es borrado.
Escenario
Principal:
1. Administrador pide listado de productos existentes.
2. Sistema muestra listado de productos.
3. Administrador selecciona producto a eliminar.
4. Sistema muestra datos del producto.
5. Administrador borra producto.
6. Sistema borra al producto del registro.
7. Termina caso de uso.
Excepciones:
VER PRODUCTO
CASO DE USO: Ver Producto
Descripción: Administrador quiere ver un producto.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Producto es borrado.
Escenario
Principal:
1. Administrador pide listado de productos.
2. Sistema muestra productos.
3. Administrador selecciona producto.
75
4. Sistema muestra datos del producto.
5. Termina caso de uso.
Excepciones:
LISTAR PRODUCTOS
CASO DE USO: Listar productos
Descripción: Administrador quiere listar los productos.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Productos son mostrados.
Escenario
Principal:
1. Administrador pide listado.
2. Sistema muestra listado de productos.
3. Termina caso de uso.
Excepciones:
HACER PEDIDO
CASO DE USO: Hacer Pedido
Descripción: Usuario quiere hacer un pedido.
Actores: Usuario
Precondición: Usuario está registrado y ha iniciado sesión.
Postcondición: El pedido es realizado y almacenado.
Escenario
Principal:
1. Usuario selecciona productos.
2. Sistema almacena productos.
3. Usuario elige cantidades.
4. Sistema almacena cantidades.
5. Usuario finaliza la compra.
6. Sistema registra pedido.
7. Termina caso de uso.
Excepciones:
76
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
Precondición: Usuario está registrado y ha iniciado sesión.
Postcondición: Pedido es mostrado.
Escenario
Principal:
1. Usuario pide listado de pedidos.
2. Sistema muestra pedidos.
3. Usuario selecciona pedido.
4. Sistema muestra datos del pedido.
5. Termina caso de uso.
Excepciones:
77
LISTAR SUS PEDIDOS
CASO DE USO: Listar sus pedidos
Descripción: Usuario quiere ver sus pedidos.
Actores: Usuario
Precondición: Usuario está registrado y ha iniciado sesión.
Postcondición: Pedidos son mostrados.
Escenario
Principal:
1. Usuario pide un listado de sus pedidos.
2. Sistema muestra listado de pedidos.
3. Termina caso de uso.
Excepciones:
FINALIZAR PEDIDO
CASO DE USO: Finalizar pedido
Descripción: Administrador quiere marcar un pedido como ya pagado.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Pedido es marcado como pagado
Escenario
Principal:
1. Administrador pide listado de pedidos.
2. Sistema muestra pedidos.
3. Administrador selecciona pedido a finalizar
4. Sistema muestra datos del pedido.
5. Administrador selecciona finalizar.
6. Sistema añade pedido como pagado en el registro.
7. Termina caso de uso.
Excepciones:
CANCELAR PEDIDO
CASO DE USO: Cancelar pedido
Descripción: Administrador quiere marcar un pedido como cancelado.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Pedido es marcado como cancelado
Escenario
Principal:
1. Administrador pide listado de pedidos.
2. Sistema muestra pedidos.
3. Administrador selecciona pedido a cancelar.
4. Sistema muestra datos del pedido.
5. Administrador lo cancela.
6. Sistema marca el pedido como cancelado.
7. Termina caso de uso.
78
Excepciones:
VER PEDIDO
CASO DE USO: Ver Pedido
Descripción: Administrador quiere ver un pedido realizado.
Actores: Administrador
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Pedido es mostrado.
Escenario
Principal:
1. Administrador pide listado de pedidos.
2. Sistema muestra pedidos.
3. Administrador selecciona pedido.
4. Sistema muestra datos del pedido.
5. Termina caso de uso.
Excepciones:
LISTAR PEDIDOS
CASO DE USO: Listar pedidos
Descripción: Administrador quiere ver listado de pedidos.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Pedidos son mostrados.
Escenario
Principal:
1. Administrador solicita listado de pedidos.
2. Sistema muestra pedidos.
3. Termina caso de uso.
Excepciones:
ACTIVAR SISTEMA DE PEDIDOS
CASO DE USO: Activar sistema de pedidos
Descripción: Administrador quiere activar el sistema de pedidos.
Actores: adminCocina
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
Principal:
1. Administrador solicita activar pedidos.
2. Sistema activa pedidos.
3. Termina caso de uso.
Excepciones:
79
DESACTIVAR SISTEMA DE PEDIDOS
CASO DE USO: Desactivar sistema de pedidos
Descripción: Administrador quiere desactivar el sistema de pedidos.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión y los pedidos están
activados.
Postcondición: Pedidos online se desactivarán
Escenario
Principal:
1. Administrador solicita desactivar pedidos.
2. Sistema desactiva pedidos.
3. Termina caso de uso.
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.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: El nuevo rango de horas de atención de pedidos se establecerá.
Escenario
Principal:
1. Administrador introduce nuevas horas.
2. Sistema cambia el rango de horas.
3. Termina caso de uso.
Excepciones:
AÑADIR CÓDIGO POSTAL
CASO DE USO: Añadir código postal
Descripción: Administrador quiere añadir un nuevo código.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Código es añadido.
Escenario
Principal:
1. Administrador inserta código.
2. Sistema añade código.
3. Termina caso de uso.
Excepciones: Código ya existe.
80
ELIMINAR CÓDIGO POSTAL
CASO DE USO: Eliminar código postal
Descripción: Administrador quiere borrar un código.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Código es eliminado.
Escenario
Principal:
1. Administrador borra código.
2. Sistema elimina código del registro.
3. Termina caso de uso.
Excepciones:
81
7.2 DISEÑO CICLO 2
7.2.1 DISEÑO DE LA ARQUITECTURA
7.2.1.1 INTRODUCCIÓN
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.
7.2.2 CLASES DE NEGOCIO
7.2.2.1 INTRODUCCIÓN
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 NEGOCIO
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.
82
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
83
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.
84
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
85
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.
86
7.2.3 DISEÑO DE LA BASE DE DATOS
7.2.3.1 INTRODUCCIÓN
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 .
7.2.3.3 DIAGRAMA DE ENTIDAD-RELACIÓN
DESCRIPCIÓN DEL DIAGRAMA.
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.
87
DIAGRAMA EER
Se ha realizado el siguiente esquema EER para el almacenamiento de información del ciclo
2 del proyecto:
Ilustración 44: Esquema EER Ciclo 2
88
7.2.3.4 CONVERSIÓN A MODELO RELACIONAL
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.
89
7.2.3.5 DIAGRAMA DE TABLAS FINAL
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
90
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.
91
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.
92
Ilustración 48: Interfaz Resumen confirmación pedido
93
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
94
7.3 IMPLEMENTACIÓN CICLO 2
7.3.1 TECNOLOGÍAS EMPLEADAS
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.
7.3.2 ESTRUCTURA DE CARPETAS
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
7.3.3 CÓDIGO DESTACABLE
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
95
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
96
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.
7.4.2 VALIDACIÓN DE FORMULARIOS
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
7.4.3 PRUEBAS UNITARIAS
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.
97
7.4.3.1 CLASES DE EQUIVALENCIA
ALTA DE PRODUCTO
Condición Clases válidas Clases no válidas
Nombre
Unicidad Nombre no existe
(AP1)
Nombre existe (AP2)
MODIFICACIÓN DE PRODUCTO
Condición Clases válidas Clases no válidas
Nombre
Unicidad Nombre no existe
(MP1)
Nombre existe (MP2)
ALTA DE TIPO DE PRODUCTO
Condición Clases válidas Clases no válidas
Nombre
Unicidad Nombre no existe
(ATP1)
Nombre existe (ATP2)
MODIFICACIÓN DE TIPO DE PRODUCTO
Condición Clases válidas Clases no válidas
Nombre
Unicidad Nombre no existe
(MTP1)
Nombre existe
(MTP2)
98
7.4.3.2 CASOS DE PRUEBA
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
equivalencia
(AP1)
Resultado
esperado
Operación exitosa
Caso no válido
Prueba Unitaria 11
Descripción Alta de un nuevo producto
Entradas Nombre: Mickey (existiendo)
Descripción: Bacon, queso
Precio: 4
Categoría: Bocadillos
Clases de
equivalencia
(AP2)
Resultado
esperado
Ya existe un producto con ese nombre.
MODIFICACIÓN DE PRODUCTO
Caso válido
Prueba Unitaria 12
Descripción Modificación de un producto
Entradas Nombre: Mickey (cambiado a Goofy)
Descripción: Bacon, queso
Precio: 4
Categoría: Bocadillos
Clases de
equivalencia
(MP1)
99
Resultado
esperado
Operación exitosa
Caso no válido
Prueba Unitaria 13
Descripción Modificación de un producto
Entradas Nombre: Mickey (cambiado a Aladdin existiendo)
Descripción: Bacon, queso
Precio: 4
Categoría: Bocadillos
Clases de
equivalencia
(MP2)
Resultado
esperado
Ya existe un producto con ese nombre.
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
equivalencia
(ATP1)
Resultado
esperado
Operación exitosa
Caso no válido
Prueba Unitaria 15
Descripción Alta de un nuevo tipo de producto
Entradas Nombre: Hamburguesas (existiendo)
Clases de
equivalencia
(ATP2)
Resultado
esperado
Ya existe un tipo de producto con ese nombre.
100
MODIFICACIÓN DE TIPO DE PRODUCTO
Caso válido
Prueba Unitaria 16
Descripción Modificación de un producto
Entradas Nombre: Hamburguesas (cambiado a bebidas)
Clases de
equivalencia
(MTP1)
Resultado
esperado
Operación exitosa
Caso no válido
Prueba Unitaria 17
Descripción Modificación de un producto
Entradas Nombre: Hamburguesas (cambiado a bocadillos existiendo)
Clases de
equivalencia
(MTP2)
Resultado
esperado
Ya existe un tipo de producto con ese nombre.
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).
101
8. CICLO 3
8.1 ANALISIS CICLO 3
8.1.1 ANÁLISIS DE REQUISITOS
8.1.1.1 INTRODUCCIÓN
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.
8.1.1.2 USUARIOS INVOLUCRADOS
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.
8.1.1.3 REQUISITOS INVOLUCRADOS
Se atenderán los requisitos RF13, RF14, RF15, RF16, RF17, RF18, RF19, RF20, RF21, RF22,
RF23. (ver página 19)
102
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.
103
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
alguna reserva de restaurante pendiente.
Entradas: El administrador quiere finalizar una reserva de restaurante.
Procedimiento: El administrador va a la sección de reservas de restaurante donde elige la
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
alguna reserva de restaurante pendiente.
Entradas: El administrador quiere cancelar una reserva de restaurante.
Procedimiento: El administrador va a la sección de reservas de restaurante donde elige la
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
Precondición: El AdminGeneral debe de estar registrado y con la sesión iniciada.
Entradas: El administrador quiere ver una gráfica de ocupación de las habitaciones en un
día.
Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la
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.
Precondición: El AdminGeneral debe de estar registrado y con la sesión iniciada.
Entradas: El administrador quiere ver la gráfica.
104
Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la
estadística a visualizar eligiendo un año.
Salidas: Se mostrará la gráfica.
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.
Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la
estadística a visualizar eligiendo un año.
Salidas: Se mostrará la gráfica.
RF23.4
Introducción: Un adminGeneral podrá ver una gráfica de la ocupación de las habitaciones
en un año agrupadas mensualmente.
Precondición: El AdminGeneral debe estar registrado y con la sesión iniciada.
Entradas: El administrador quiere ver la gráfica.
Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la
estadística a visualizar eligiendo un año.
Salidas: Se mostrará la gráfica.
RF23.5
Introducción: Un adminGeneral podrá ver una gráfica del número de pedidos durante un
año agrupados trimestralmente.
Precondición: El AdminGeneral debe estar registrado y con la sesión iniciada.
Entradas: El administrador quiere ver la gráfica.
Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la
estadística a visualizar eligiendo un año.
Salidas: Se mostrará la gráfica.
RF23.6
Introducción: Un adminGeneral podrá ver una gráfica del % de ocupación del comedor
durante un año representado trimestralmente.
Precondición: El AdminGeneral debe estar registrado y con la sesión iniciada.
Entradas: El administrador quiere ver la gráfica.
105
Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la
estadística a visualizar eligiendo un año.
Salidas: Se mostrará la gráfica.
RF23.7
Introducción: Un adminGeneral podrá ver una gráfica del número de registros en la web de
nuevos usuarios agrupados mensualmente.
Precondición: El AdminGeneral debe estar registrado y con la sesión iniciada.
Entradas: El administrador quiere ver la gráfica.
Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la
estadística a visualizar eligiendo un año.
Salidas: Se mostrará la gráfica.
8.1.1.4 CASOS DE USO
El siguiente esquema muestra una representación de las funciones que pueda hacer cada
usuario:
Ilustración 53: Diagrama Casos Uso Ciclo 3
106
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
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Habitación es añadida.
Escenario
Principal:
1. Administrador introduce datos de la nueva habitación.
2. Sistema añade habitación.
3. Termina caso de uso.
Excepciones: Error en los datos.
MODIFICAR HABITACIÓN
CASO DE USO: Modificar Habitación
Descripción: Administrador quiere modificar una habitación.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Producto es modificado.
Escenario
Principal:
1. Administrador pide listado de habitaciones.
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.
7. Termina caso de uso.
Excepciones: Error en los datos.
ELIMINAR HABITACIÓN
CASO DE USO: Eliminar Habitación
Descripción: Administrador quiere borrar una habitación.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Habitación es borrada.
Escenario
Principal:
1. Administrador pide listado de habitaciones.
2. Sistema muestra listado de habitaciones.
3. Administrador selecciona habitación.
4. Sistema muestra datos de la habitación.
5. Administrador borra habitación.
107
6. Sistema borra la habitación.
7. Termina caso de uso.
Excepciones:
VER HABITACIÓN
CASO DE USO: Ver Habitación
Descripción: Administrador quiere ver los datos de una habitación.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Se muestra la habitación.
Escenario
Principal:
1. Administrador pide listado de habitaciones.
2. Sistema muestra listado de habitaciones.
3. Administrador selecciona habitación.
4. Sistema muestra datos de la habitación.
5. Termina caso de uso.
Excepciones:
LISTAR HABITACIONES
CASO DE USO: Listar habitaciones
Descripción: Administrador quiere listar las habitaciones.
Actores: adminGeneral
Precondición: Usuarios y administrador están registrados y han iniciado sesión.
Postcondición: Productos son mostrados.
Escenario
Principal:
1. Administrador pide listado de habitaciones.
2. Sistema muestra habitaciones.
3. Termina caso de uso.
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
Precondición: Usuario está registrado y ha iniciado sesión.
Postcondición: Pedido es realizado.
Escenario
Principal:
1. Usuario elige fechas.
2. Sistema muestra habitaciones libres en esas fechas.
108
3. Usuario elige habitación y tipo de pensión.
4. Sistema registra reserva.
5. Sistema envía confirmación.
6. Termina caso de uso.
Excepciones: Error en las fechas.
Error porque otro usuario ha reservado antes.
Ilustración 54:Diagrama Secuencia Reserva Habitación
109
VER SU RESERVA DE HABITACIÓN
CASO DE USO: Ver su Reserva de habitación
Descripción: Usuario quiere ver una reserva.
Actores: Usuario
Precondición: Usuario está registrado y ha iniciado sesión.
Postcondición: Reserva es mostrada.
Escenario
Principal:
1. Usuario busca reserva.
2. Sistema muestra listado de reservas de habitaciones.
3. Usuario selecciona reserva.
4. Sistema muestra datos de la reserva de la habitación.
5. Termina caso de uso.
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
Precondición: Usuario está registrado y ha iniciado sesión.
Postcondición: La lista de reservas es mostrada.
Escenario
Principal:
1. Administrador pide listado de reservas de habitación.
2. Sistema muestra el listado.
3. Termina caso de uso.
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
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: La reserva de habitación es marcada como finalizada correctamente.
Escenario
Principal:
1. Administrador pide listado de reservas.
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.
7. Termina caso de uso.
110
Excepciones:
CANCELAR RESERVA DE HABITACIÓN
CASO DE USO: Cancelar reserva de habitación
Descripción: Administrador quiere marcar una reserva como cancelada.
Actores: adminRecepción
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Reserva es marcado como cancelado
Escenario
Principal:
1. Administrador pide listado de reservas.
2. Sistema muestra reservas.
3. Administrador selecciona reserva.
4. Sistema muestra datos de la reserva.
5. Administrador cancela la reserva.
6. Sistema marca como cancelada la reserva.
7. Termina caso de uso.
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.
Actores: adminRecepción
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Pedidos son mostrados.
Escenario
Principal:
1. Administrador pide listado de reservas de habitación.
2. Sistema muestra listado de reservas.
3. Termina caso de uso.
Excepciones:
VER RESERVA DE HABITACIÓN
CASO DE USO: Ver su Reserva de habitación
Descripción: Administrador quiere ver una reserva.
Actores: Administrador
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Reserva es mostrada.
Escenario
Principal:
1. Administrador pide listado de reservas.
2. Sistema muestra listado de reservas de habitaciones.
3. Usuario selecciona reserva.
4. Sistema muestra datos de la reserva de la habitación.
5. Termina caso de uso.
111
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
Principal:
1. Usuario selecciona fecha y plazas.
2. Sistema confirma reserva.
3. Sistema envía confirmación.
4. Termina caso de uso.
Excepciones: No hay plazas disponibles.
Error en la fecha.
112
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
Precondición: Usuario está registrado y ha iniciado sesión.
Postcondición: Reserva es mostrada.
Escenario
Principal:
1. Usuario pide listado de reservas de comedor.
2. Sistema muestra un listado con las reservas.
3. Usuario selecciona la reserva que quiere ver
4. Sistema muestra datos de la reserva.
5. Termina caso de uso.
Excepciones:
113
LISTAR SUS RESERVAS DE COMEDOR
CASO DE USO: Listar sus reservas de comedor
Descripción: Usuario quiere ver sus reservas.
Actores: Usuario
Precondición: Usuario está registrado y ha iniciado sesión.
Postcondición: La lista de reservas de comedor es mostrada.
Escenario
Principal:
1. Administrador va a sección reservas.
2. Sistema muestra reservas.
3. Termina caso de uso.
Excepciones:
FINALIZAR RESERVA DE COMEDOR
CASO DE USO: Finalizar reserva de comedor
Descripción: Administrador quiere marcar una reserva de comedor como
finalizada correctamente.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: La reserva de comedor es marcada como pagada.
Escenario
Principal:
1. Administrador pide listado de reservas.
2. Sistema muestra reservas abiertas.
3. Administrador selecciona reserva.
4. Sistema muestra datos de la reserva.
5. Administrador finaliza reserva.
6. Sistema añade reserva como pagada en la BD.
7. Termina caso de uso.
Excepciones:
CANCELAR RESERVA DE COMEDOR
CASO DE USO: Cancelar reserva de comedor
Descripción: Administrador quiere marcar una reserva como cancelada.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Reserva es marcado como cancelado
Escenario
Principal:
1. Administrador pide listado de reservas de comedor.
2. Sistema muestra reservas.
3. Administrador selecciona la reserva.
4. Sistema muestra datos de la reserva.
5. Administrador cancela la reserva.
6. Sistema marca la reserva como cancelada.
114
7. Termina caso de uso.
Excepciones:
LISTAR RESERVAS DE COMEDOR
CASO DE USO: Listar reservas de comedor
Descripción: Administrador quiere ver listado de pedidos.
Actores: adminCocina
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: La lista de reservas de comedor es mostrada.
Escenario
Principal:
1. Administrador pide listado de reservas de comedor.
2. Sistema muestra listado.
3. Termina caso de uso.
Excepciones:
VER RESERVA DE COMEDOR
CASO DE USO: Ver reserva de comedor
Descripción: Administrador quiere ver una reserva .
Actores: Usuario
Precondición: Usuario está registrado y ha iniciado sesión.
Postcondición: Reserva es mostrada.
Escenario
Principal:
1. Administrador pide listado de reservas de comedor.
2. Sistema muestra un listado con las reservas.
3. Administrador selecciona la reserva que quiere ver
4. Sistema muestra datos de la reserva.
5. Termina caso de uso.
Excepciones:
EXPLOSIÓN DEL CASO DE USO DE VER ESTADÍSTICAS
Ilustración 56: Diagrama Casos Uso Estadísticas
115
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.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Se muestra la gráfica.
Escenario
Principal:
1. Administrador introduce fecha.
2. Sistema muestra gráfica de esa fecha.
3. Termina caso de uso.
Excepciones:
GENERAR GRÁFICA DE TIPO 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.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Se muestra la gráfica.
Escenario
Principal:
1. Administrador introduce año.
2. Sistema muestra gráfica con los datos del año.
3. Termina caso de uso.
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.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Se muestra la gráfica.
Escenario
Principal:
1. Administrador introduce año.
2. Sistema muestra gráfica.
3. Termina caso de uso.
Excepciones:
116
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.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Se muestra la gráfica.
Escenario
Principal:
1. Administrador introduce año.
2. Sistema muestra gráfica.
3. Termina caso de uso.
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.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Se muestra la gráfica.
Escenario
Principal:
1. Administrador introduce año.
2. Sistema muestra gráfica.
3. Termina caso de uso.
Excepciones:
GENERAR GRÁFICA DE PEDIDOS 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.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Se muestra la gráfica.
Escenario
Principal:
1. Administrador introduce año.
2. Sistema muestra gráfica.
3. Termina caso de uso.
Excepciones:
GENERAR GRÁFICA DE OCUPACIÓN DE COMEDOR POR DÍA
CASO DE USO: Generar Gráfica Ocupación Comedor Día
117
Descripción: Administrador quiere ver una gráfica con el % ocupación del
comedor de un día concreto.
Actores: adminGeneral
Precondición: Administrador está registrado y ha iniciado sesión.
Postcondición: Se muestra la gráfica.
Escenario
Principal:
1. Administrador selecciona fecha.
2. Sistema muestra gráfica.
3. Termina caso de uso.
Excepciones:
118
8.2 DISEÑO CICLO 3
8.2.1 DISEÑO DE LA ARQUITECTURA
8.2.1.1 INTRODUCCIÓN
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.
8.2.2 CLASES DE NEGOCIO
8.2.2.1 INTRODUCCIÓN
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.
119
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.
120
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
121
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
Actions Descripción
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
122
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
Actions Descripción
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
123
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
Actions Descripción
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
124
8.2.3 DISEÑO DE LA BASE DE DATOS
8.2.3.1 INTRODUCCIÓN
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.
8.2.3.3 DIAGRAMA DE ENTIDAD-RELACIÓN
DESCRIPCIÓN DEL DIAGRAMA.
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.
125
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.
Ilustración 63: Esquema EER Ciclo 3
8.2.3.4 CONVERSIÓN A MODELO RELACIONAL
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.
126
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.
127
8.2.3.5 DIAGRAMA DE TABLAS FINAL
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...
128
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
129
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.
130
Ilustración 68: Interfaz Elección Fechas Reserva Habitación
8.2.4.5 PARTE DE LA PÁGINA DE CREACIÓN DE 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.
131
Ilustración 69: Interfaz Generación Gráficas
132
8.3 IMPLEMENTACIÓN CICLO 3
8.3.1 TECNOLOGÍAS EMPLEADAS
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
8.3.2 ESTRUCTURA DE CARPETAS
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
133
8.3.3 CÓDIGO DESTACABLE
EJEMPLO JFREECHART, DIAGRAMA DE SECTORES
134
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.
135
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
136
Ilustración 72: Código envío email
137
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.
8.4.2 VALIDACIÓN DE FORMULARIOS
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.
8.4.3 PRUEBAS UNITARIAS
8.4.3.1 CLASES DE EQUIVALENCIA
ALTA DE HABITACIÓN
Condición Clases válidas Clases no válidas
Número
Unicidad Número no existe
(AH1)
Número existe (AH2)
MODIFICACIÓN DE HABITACIÓN
Condición Clases válidas Clases no válidas
Número
Unicidad Número no existe
(MH1)
Número existe (MH2)
8.4.3.2 CASOS DE PRUEBA
Caso válido
Prueba Unitaria 18
Descripción Alta de una nueva habitación
138
Entradas Número: “1”
Tipo Habitación: “Habitación doble”
Clases de
equivalencia
(AH1)
Resultado
esperado
Operación exitosa
Caso no válido
Prueba Unitaria 19
Descripción Alta de una nueva habitación
Entradas Número: “1”(existiendo)
Tipo Habitación: “Habitación doble”
Clases de
equivalencia
(AH2)
Resultado
esperado
Ya existe una habitación con ese nombre.
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”)
Tipo Habitación: “Habitación doble”
Clases de
equivalencia
(MH1)
Resultado
esperado
Operación exitosa
Caso no válido
Prueba Unitaria 21
Descripción Modificación de un producto
Entradas Número: “1”(cambio a “3” existiendo)
Tipo Habitación: “Habitación doble”
Clases de
equivalencia
(MH2)
Resultado
esperado
Ya existe una habitación con ese nombre.
139
ALTA DE TIPO DE HABITACIÓN
Condición Clases válidas Clases no válidas
Número
Unicidad Número no existe
(AH1)
Número existe (AH2)
MODIFICACIÓN DE TIPO DE HABITACIÓN
Condición Clases válidas Clases no válidas
Número
Unicidad Número no existe
(MH1)
Número existe (MH2)
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
equivalencia
(AH1)
Resultado
esperado
Operación exitosa
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
equivalencia
(AH2)
Resultado Ya existe un tipo de habitación con esa descripción.
140
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
equivalencia
(MH1)
Resultado
esperado
Operación exitosa
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
equivalencia
(MH2)
Resultado
esperado
Ya existe un tipo de habitación con esa descripción.
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.
141
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.
142
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.
143
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.
144
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.
145
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.
146
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/
147
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
148
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
13.3.1 INTRODUCCIÓN
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.
149
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
150
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
151
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
13.4.1 INTRODUCCIÓN
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
152
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.
153
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
154
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
155
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.
156
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
157
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
158
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.
159
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.
160
Ilustración 91: Página de generación de gráficas
161
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.
162
Ilustración 93: Pantalla administración de pedidos
Ilustración 94: Pantalla de finalización de pedido
163
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
164
Ilustración 97: Listado de reservas de comedor
Ilustración 98: Finalización de reserva de comedor.
165
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
166
Elegirán la reserva abierta que deseen y la finalizarán.
Ilustración 101: Resumen de reserva de habitación a finalizar
![Trabajo Proyectos Hostal Final[1]](https://static.fdocuments.ec/doc/165x107/55cf8c7b5503462b138ce325/trabajo-proyectos-hostal-final1.jpg)
![[MEMORIA DE EMPRESA] - Cum Laude Academy · de los siguientes sectores; empleado de bar, restaurante, gobernanta / gobernante de hotel / hostal, administración y gestión de empresas,](https://static.fdocuments.ec/doc/165x107/5e4d4b85dc78e96c5d4cf650/memoria-de-empresa-cum-laude-academy-de-los-siguientes-sectores-empleado-de.jpg)
