You are on page 1of 179

PROYECTO FIN DE CARRERA

Ttulo

Aplicacin web para la gestin de un hostal-restaurante


Autor/es

Pablo Cacho Zueco


Director/es

Laureano Lambn Pardo


Facultad

Facultad de Ciencias, Estudios Agroalimentarios e Informtica


Titulacin

Proyecto Fin de Carrera


Departamento

Matemticas y Computacin
Curso Acadmico

2012-2013

Aplicacin web para la gestin de un hostal-restaurante, proyecto fin de carrera


de Pablo Cacho Zueco, dirigido por Laureano Lambn Pardo (publicado por la Universidad
de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan ms all de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.

El autor
Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.es
E-mail: publicaciones@unirioja.es

UNIVERSIDAD DE LA RIOJA
Facultad de Ciencias, Estudios Agroalimentarios e Informtica

PROYECTO FIN DE CARRERA


Ingeniera Tcnica en Informtica de Gestin

Aplicacin web para la gestin de un hostalrestaurante.

Alumno: Pablo Cacho Zueco


Director: Laureano Lambn Pardo

Logroo, Junio de 2013

RESUMEN
En este proyecto se quiere realizar una aplicacin web para gestionar y explotar un hostal
restaurante. La aplicacin creada permitir realizar una gestin 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 habitacin para
unas fechas concretas. Se le podr pedir tambin a la aplicacin que muestre una serie de
grficas de estadsticas con datos relacionados con el negocio.
Esta aplicacin no est destinada a un cliente concreto pero puede ser fcilmente
adaptable a multitud de pequeos y medianos hostales que buscan mostrarse en Internet.

NDICE DE CONTENIDO
TABLA DE CONTENIDO
1 Introduccin..........................................................................................................................1
1.1 Tema tratado ................................................................................................................ 1
1.2 Motivo de la eleccin .................................................................................................... 1
1.3 Lmites ........................................................................................................................... 1
2 Documento de Objetivos.......................................................................................................2
2.1 Objeto ........................................................................................................................... 2
2.2 Antecedentes ................................................................................................................ 2
2.3 Alcance .......................................................................................................................... 2
2.4 Entregables ................................................................................................................... 3
2.5 Metodologa de desarrollo ........................................................................................... 3
2.6 Tecnologas y herramientas a usar ............................................................................... 3
2.7 Recursos humanos y comunicaciones .......................................................................... 4
2.8 Riesgos y planes de accin ............................................................................................ 4
2.8.1 Posibles riesgos ..................................................................................................... 4
2.8.2 Planes de accin ................................................................................................... 4
2.9 Tareas ............................................................................................................................ 5
2.10 Plan de trabajo y temporizacin ............................................................................... 10
2.10.1 Calendario de trabajo ....................................................................................... 10
2.10.2 Estimacin temporal ......................................................................................... 10
2.11 Diagrama Gantt ......................................................................................................... 13
3 Gestin de proyecto............................................................................................................15
3.1 Introduccin ................................................................................................................ 15
3.2 Factores de retraso ..................................................................................................... 15
3.3 Primera replanificacin ............................................................................................... 15
3.4 Segunda replanificacin .............................................................................................. 16
3.5 Comparacin estimado con resultados finales .......................................................... 16
3.5.1 Comparacin fechas ........................................................................................... 16
3.5.2 Comparacin horas ............................................................................................. 16
4 Anlisis de requisitos...........................................................................................................18
4.1 Introduccin ................................................................................................................ 18

4.1.1 Objetivo ................................................................................................................. 18


4.1.2 mbito ................................................................................................................... 18
4.1.3 Referencias ............................................................................................................ 18
4.1.4 Visin general del documento............................................................................... 18
4.2 Descripcin general ....................................................................................................... 19
4.2.1 Perspectiva del producto ...................................................................................... 19
4.2.2 Funciones del producto ......................................................................................... 19
4.2.3 Caractersticas de los usuarios .............................................................................. 19
4.2.4 Restricciones.......................................................................................................... 19
4.3 Requisitos especficos .................................................................................................... 20
4.3.1 Requisitos funcionales ........................................................................................... 20
4.3.2 Requisitos de interfaz grfica ................................................................................ 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 Introduccin .................................................................................................................. 29
5.2 Arquitectura MVC .......................................................................................................... 29
5.2.1 Introduccin .......................................................................................................... 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 configuracin ..................................................................................... 31
5.3.3 Etiquetas JSP .......................................................................................................... 32
5.4 Funcionamiento Struts .................................................................................................. 32
6 Ciclo 1..................................................................................................................................35
6.1 Anlisis Ciclo 1................................................................................................................35
6.1.1 Anlisis de requisitos ........................................................................................... ..35
6.1.1.1 Introduccin .................................................................................................. 35
6.1.1.2 Usuarios involucrados ................................................................................... 35
6.1.1.3 Requisitos involucrados ................................................................................ 35
6.1.1.4 Casos de Uso ................................................................................................. 37

II

6.2 Diseo Ciclo 2..............................................................................................................42


6.2.1 Diseo de la arquitectura ................................................................................... 42
6.2.1.1 Introduccin................................................................................................ 42
6.2.1.2 Arquitectura aplicada a nuestro sistema .................................................... 42
6.2.2 Clases de negocio................................................................................................ 43
6.2.2.1 Introduccin................................................................................................ 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 Diseo de la base de datos ................................................................................. 48
6.2.3.1 Introduccin................................................................................................ 48
6.2.3.2 Requisitos de la base de datos ................................................................... 48
6.2.3.3 Diagrama de entidad-relacin .................................................................... 48
6.2.3.4 Conversin a modelo relacional ................................................................. 49
6.2.3.5 Diagrama de tablas final ............................................................................. 50
6.2.4 Interfaces grficas definitivas ............................................................................. 51
6.2.4.1 Login de usuario.......................................................................................... 51
6.2.4.2 Registro de usuario ..................................................................................... 52
6.2.4.3 Bsqueda de Usuario .................................................................................. 53
6.2.4.4 Administracin Usuario .............................................................................. 55
6.2.4.5 Perfil de usuario .......................................................................................... 55
6.3 Implementacin Ciclo 1...............................................................................................57
6.3.1 Tecnologas empleadas ....................................................................................... 57
6.3.2 Estructura de carpetas ........................................................................................ 57
6.3.3 Seguridad ............................................................................................................ 58
6.3.4 Cdigo destacable ............................................................................................... 58
6.4 Pruebas Ciclo 1............................................................................................................64
6.4.1 Introduccin ........................................................................................................ 64
6.4.2 Validacin de formularios ................................................................................... 64
6.4.3 Pruebas Unitarias ................................................................................................ 66
6.4.3.1 Clases de equivalencia ................................................................................ 66
6.4.3.2 Casos de prueba ......................................................................................... 66
6.4.3.3 Resultado de pruebas ................................................................................. 69

III

7 Ciclo 2..................................................................................................................................70
7.1 Anlisis Ciclo 2.............................................................................................................70
7.1.1 Anlisis de requisitos .......................................................................................... 70
7.1.1.1 Introduccin................................................................................................ 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 Diseo Ciclo 2..............................................................................................................81
7.2.1 Diseo de la arquitectura .......................................................................... .........81
7.2.1.1 Introduccin................................................................................................ 81
7.2.2 Clases de negocio................................................................................................ 81
7.2.2.1 Introduccin................................................................................................ 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 Diseo de la base de datos ................................................................................. 86
7.2.3.1 Introduccin................................................................................................ 86
7.2.3.2 Requisitos de la base de datos ................................................................... 86
7.2.3.3 Diagrama de entidad-relacin .................................................................... 86
7.2.3.4 Conversin a modelo relacional ................................................................. 88
7.2.3.5 Diagrama de tablas final ............................................................................. 89
7.2.4 Interfaces grficas definitivas ............................................................................. 90
7.3 Implementacin Ciclo 2...............................................................................................94
7.3.1 Tecnologas empleadas ....................................................................................... 94
7.3.2 Estructura de carpetas ....................................................................................... .94
7.3.3 Cdigo destacable .............................................................................................. .94
7.4 Pruebas Ciclo 2............................................................................................................96
7.4.1 Introduccin ........................................................................................................ 96
7.4.2 Validacin de formularios ................................................................................... 96
7.4.3 Pruebas Unitarias ................................................................................................ 96
7.4.3.1 Clases de equivalencia ................................................................................ 97
7.4.3.2 Casos de prueba ......................................................................................... 98
7.4.4 Resultado de las pruebas ................................................................................. .100
8 Ciclo 3.................................................................................................................................101

IV

8.1 Anlisis Ciclo 3...........................................................................................................101


8.1.1 Anlisis de requisitos ........................................................................................ 101
8.1.1.1 Introduccin.............................................................................................. 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 Diseo Ciclo 3............................................................................................................118
8.2.1 Diseo de la arquitectura ................................................................................. 118
8.2.1.1 Introduccin.............................................................................................. 118
8.2.2 Clases de negocio.............................................................................................. 118
8.2.2.1 Introduccin.............................................................................................. 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 Diseo de la base de datos ............................................................................... 124
8.2.3.1 Introduccin.............................................................................................. 124
8.2.3.2 Requisitos de la base de datos relativos al ciclo3 ..................................... 124
8.2.3.3 Diagrama de entidad-relacin .................................................................. 124
8.2.3.4 Conversin a modelo relacional ............................................................... 125
8.2.3.5 Diagrama de tablas final ........................................................................... 127
8.2.4 Interfaces grficas ............................................................................................. 127
8.2.4.1 Grfica representativa de ocupacin del hostal un determinado ao ..... 127
8.2.4.2 Grfica representativa de ocupacin del hostal un determinado da ...... 128
8.2.4.3 Men principal de la gestin de habitaciones y comedor........................ 129
8.2.4.4 Pgina de seleccin de fechas para una reserva de habitacin ............... 129
8.2.4.5 Parte de la pgina de creacin de grficas estadsticas........................... 130
8.3 Implementacin Ciclo 3............................................................................................132
8.3.1 Tecnologas empleadas ..................................................................................... 132
8.3.2 Estructura de carpetas ...................................................................................... 132
8.3.3 Cdigo destacable ............................................................................................. 133
8.4 Pruebas Ciclo 3...........................................................................................................137
8.4.1 Introduccin ...................................................................................................... 137
8.4.2 Validacin de formularios ................................................................................. 137
8.4.3 Pruebas Unitarias ............................................................................................. .137

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 integracin ............................................................................................. 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 Visin personal ........................................................................................................ 144
11 Glosario de trminos.......................................................................................................145
12 Bibliografa......................................................................................................................146
13 Anexos.............................................................................................................................147
13.1 Diseo Web ............................................................................................................ .147
13.1.1 Introduccin ................................................................................................... .147
13.1.2 Proceso ........................................................................................................... 147
13.1.3 Imgenes......................................................................................................... 147
13.2 Ley orgnica de proteccin de datos ...................................................................... 147
13.3 Manual de instalacin y despliegue ........................................................................ 148
13.3.1 Introduccin .................................................................................................... 148
13.3.2 Requisitos........................................................................................................ 148
13.3.3 Base de datos, mysql y apache ....................................................................... 148
13.3.4 Instalacin de servidor de aplicaciones web y despliegue ............................. 150
13.4 Manual de administrador y usuario ........................................................................ 151
13.4.1 Introduccin .................................................................................................... 151
13.4.2 Visitante .......................................................................................................... 151
13.4.3 Usuario ............................................................................................................ 152
13.4.4 admingeneral .................................................................................................. 157
13.4.5 admincocina .................................................................................................... 161
13.4.6 adminrecepcin .............................................................................................. 165

VI

NDICE DE ILUSTRACIONES
Ilustracin 1: Esquema divisin de tareas................................................................................ 9
Ilustracin 2: Esquema divisin de tareas por ciclo ............................................................... 10
Ilustracin 3: Tabla de duraciones estimadas ........................................................................ 13
Ilustracin 4: Diagrama Gantt Inicial ...................................................................................... 13
Ilustracin 5 : Diagrama de Gantt Ciclo 1............................................................................... 13
Ilustracin 6: Diagrama Gantt Ciclo 2 .................................................................................... 14
Ilustracin 7: Diagrama Gantt Ciclo 3 .................................................................................... 14
Ilustracin 8: Diagrama Gant Replanificacin 1 ..................................................................... 15
Ilustracin 9: Diagrama Gantt Replanificacin 2 .................................................................... 16
Ilustracin 10: Tabla Comparativa de fechas ......................................................................... 16
Ilustracin 11: Tabla Comparativa de horas .......................................................................... 17
Ilustracin 12: Grfica comparacin horas ............................................................................ 17
Ilustracin 13: Diagrama Casos de Uso General .................................................................... 27
Ilustracin 14: Esquema MVC ................................................................................................ 30
Ilustracin 15: Estructura XML form-bean ............................................................................. 32
Ilustracin 16: Esquema estructural Struts ............................................................................ 34
Ilustracin 17: Diagrama Casos Uso Ciclo 1 ........................................................................... 37
Ilustracin 18: Diagrama Actividad Modificar usuario ........................................................... 40
Ilustracin 19: Diagrama Clases Usuarios Ciclo 1................................................................... 44
Ilustracin 20: Diagrama Clases 2 Ciclo 1 ............................................................................... 44
Ilustracin 21: Diagrama Clase LoginBD................................................................................. 45
Ilustracin 22: Diagrama Clase UsuariosBD ........................................................................... 46
Ilustracin 23: Esquema FormBeans Ciclo 1 .......................................................................... 47
Ilustracin 24: Tabla Actions Ciclo 1 ...................................................................................... 47
Ilustracin 25: Esquema EER Ciclo 1 ...................................................................................... 49
Ilustracin 26: Diagrama Tablas Ciclo 1 ................................................................................. 51
Ilustracin 27: Interfaz login de usuario ................................................................................ 52
Ilustracin 28: Interfaz registro de usuario ............................................................................ 53
Ilustracin 29:Interfaz Bsqueda de usuarios ........................................................................ 54
Ilustracin 30: Interfaz administracin de usuarios............................................................... 55
Ilustracin 31:Interfaz datos de usuario ................................................................................ 56
Ilustracin 32: Cdigo Hibernate Filtrar Usuarios .................................................................. 60
Ilustracin 33: Cdigo Login Usuario Action .......................................................................... 61
Ilustracin 34: Cdigo Login Usuario BD ................................................................................ 62
Ilustracin 35: Cdigo Javascript confirmacin borrado de usuario...................................... 62
Ilustracin 36: Cdigo html confirmacin borrado de usuario .............................................. 63
Ilustracin 37: Interfaz validacin login ................................................................................. 64
Ilustracin 38: Interfaz validacin captcha ............................................................................ 65
Ilustracin 39: Diagrama Casos Uso Ciclo 2 ........................................................................... 73
Ilustracin 40: Diagrama Secuencia Realizar Pedido ............................................................. 76

VII

Ilustracin 41: Diagrama clases ciclo 2 .................................................................................. 82


Ilustracin 42: Diagrama Clases BD Ciclo 2 ............................................................................ 82
Ilustracin 43:Diagrama FormBeans Ciclo 2 .......................................................................... 83
Ilustracin 44: Esquema EER Ciclo 2 ...................................................................................... 87
Ilustracin 45: Esquema Tablas Ciclo 2 .................................................................................. 89
Ilustracin 46: Interfaz Carta productos ................................................................................ 90
Ilustracin 47:Interfaz carro pedido ...................................................................................... 91
Ilustracin 48: Interfaz Resumen confirmacin pedido ......................................................... 92
Ilustracin 49: Interfaz Configuracin pedidos ...................................................................... 93
Ilustracin 50: Cdigo carro html........................................................................................... 94
Ilustracin 51: Cdigo DisplayTag .......................................................................................... 95
Ilustracin 52: Interfaz validacin formulario alta producto ................................................. 96
Ilustracin 53: Diagrama Casos Uso Ciclo 3 ......................................................................... 105
Ilustracin 54:Diagrama Secuencia Reserva Habitacin ...................................................... 108
Ilustracin 55: Diagrama secuencia Reserva sitio restaurante ............................................ 112
Ilustracin 56: Diagrama Casos Uso Estadsticas ................................................................. 114
Ilustracin 57: Diagrama Clases Ciclo 3................................................................................ 119
Ilustracin 58: Diagrama Clases BD Ciclo 3 .......................................................................... 120
Ilustracin 59: Tabla Actions Habitaciones .......................................................................... 121
Ilustracin 60: Tabla Actions Reservas Habitaciones ........................................................... 122
Ilustracin 61: Tabla Actions Reservas Comedor ................................................................. 123
Ilustracin 62: Tabla Actions Estadsticas ............................................................................ 123
Ilustracin 63: Esquema EER Ciclo 3 .................................................................................... 125
Ilustracin 64: Diagrama Tablas Ciclo 3 ............................................................................... 127
Ilustracin 65: Interfaz Grfica Tipo Ocupacin hostal ........................................................ 128
Ilustracin 66: Interfaz Grfica % Ocupacin Hostal ............................................................ 128
Ilustracin 67: Interfaz Administracin hostal ..................................................................... 129
Ilustracin 68: Interfaz Eleccin Fechas Reserva Habitacin ............................................... 130
Ilustracin 69: Interfaz Generacin Grficas........................................................................ 131
Ilustracin 70: Cdigo Action Grfica ................................................................................... 134
Ilustracin 71: Interfaz Calendario ....................................................................................... 135
Ilustracin 72: Cdigo envo email ....................................................................................... 136
Ilustracin 73: Recorte de pantalla de Xampp ..................................................................... 149
Ilustracin 74: Recorte de myphpadmin.............................................................................. 149
Ilustracin 75 : Pantalla del servidor GlassFish .................................................................... 150
Ilustracin 76: Pantalla de informacin del hostal .............................................................. 151
Ilustracin 77: Pantalla de registro de usuario .................................................................... 152
Ilustracin 78: Perfil de usuario ........................................................................................... 152
Ilustracin 79: Listado de productos a la venta ................................................................... 153
Ilustracin 80: Resumen del pedido..................................................................................... 153
Ilustracin 81: Eleccin de fechas de reserva de habitacin ............................................... 154
Ilustracin 82: Habitaciones libres para unas fechas ........................................................... 154
Ilustracin 83: Resumen de reserva de habitacin .............................................................. 155
Ilustracin 84: Eleccin de datos para reserva de comedor. ............................................... 155

VIII

Ilustracin 85: Confirmacin de reserva de comedor.......................................................... 156


Ilustracin 86: Pantalla de listados de pedidos .................................................................... 156
Ilustracin 87: Pantalla de listados de reservas. .................................................................. 157
Ilustracin 88: Pantalla de administracin de usuarios ....................................................... 157
Ilustracin 89: Pantalla de listado de usuarios .................................................................... 158
Ilustracin 90: Pantalla de administracin del hostal .......................................................... 159
Ilustracin 91: Pgina de generacin de grficas ................................................................. 160
Ilustracin 92: Men administracin cocina ........................................................................ 161
Ilustracin 93: Pantalla administracin de pedidos ............................................................. 162
Ilustracin 94: Pantalla de finalizacin de pedido ............................................................... 162
Ilustracin 95: Configuracin de sistema de pedidos .......................................................... 163
Ilustracin 96: Pantalla de administracin de comedor ...................................................... 163
Ilustracin 97: Listado de reservas de comedor .................................................................. 164
Ilustracin 98: Finalizacin de reserva de comedor. ........................................................... 164
Ilustracin 99: Men administracin de la recepcin.......................................................... 165
Ilustracin 100: Listado de reservas de habitacin abiertas ................................................ 165
Ilustracin 101: Resumen de reserva de habitacin a finalizar ........................................... 166

IX

1. INTRODUCCIN
1.1 TEMA TRATADO
Este proyecto pretende abordar el desarrollo de una aplicacin web que sirva de ayuda en
la gestin de un hostal restaurante. La aplicacin ofertar unos servicios a los clientes
interesados en hacer un pedido de restaurante, reservar una habitacin o una mesa. Tambin
mostrar una serie de grficas estadsticas y unos historiales de reservas o pedidos.
1.2 MOTIVO DE LA ELECCIN
El motivo de elegir este proyecto fue debido a que prefera terminar la carrera haciendo
algo relacionado con la programacin web. La eleccin del tema de hostal-restaurante no tiene
una causa concreta, simplemente me pareci un tema interesante al haber miles de pequeos
hostales con servicio de restaurante a los que podra ser til una aplicacin de este estilo.
Asimismo me resultara til ya que la programacin 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 LMITES
Los lmites de este proyecto sern 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 trmino medio dictando unos mnimos
aceptables que debe tener todo proyecto fin de carrera y que den lugar a una aplicacin
bastante completa.

2. DOCUMENTO DE OBJETIVOS
2.1 OBJETO
El objetivo del proyecto es la creacin de un portal web para la gestin, control y
explotacin de un hostal restaurante.
Esta aplicacin contar con diferentes secciones dirigidas a distintos tipos de usuario segn
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 fcil adaptacin a otros posibles hostales o negocios similares.
2.2 ANTECEDENTES
Con el boom de Internet se han extendido de manera muy rpida multitud de negocios que
tratan de ganar mercado ofertndose en la web. Entre ellos en Espaa destacan los
relacionados con el turismo y la gastronoma. As que no es difcil 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/
Pginas con buscadores tipo http://www.hostels.com/es/

No se pretende hacer nada revolucionario sino que la motivacin 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 fcil encontrar webs que combinen la reserva de
habitaciones junto con un servicio de restaurante y pedidos. Esto unido a la personalizacin
con informacin general de un hostal nos hace creer que puede resultar interesante continuar
con la idea de la creacin del proyecto a pesar de las alternativas disponibles.
2.3 ALCANCE
La aplicacin atender las peticiones de diferentes roles de usuarios. A continuacin se
enumeran las funciones que debern ser cubiertas:

Mostrar informacin del hostal: tarifas, situacin geogrfica, habitaciones.


Gestin de reservas online: habitaciones y comedor.
Gestin de pedidos de productos de restaurante online.

Gestin 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.
Estadsticas: diferentes grficas con estadsticas del hostal-restaurante.

No se abordarn temas como las transacciones econmicas con los clientes, ni la gestin de
stock y productos usados en el hostal.
La aplicacin contar con una base de datos donde se guardarn todos los registros
necesarios para el correcto funcionamiento del servicio.
2.4 ENTREGABLES
Los entregables del proyecto sern:
Memoria.
Cdigo fuente.
Manual de instalacin.
2.5 METODOLOGA DE DESARROLLO
Se usar como metodologa 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 ms
se ha incidido en las asignaturas de la carrera.
El utilizar un ciclo de vida iterativo e incremental permitir aadir y mejorar la aplicacin a
la vez que crece obteniendo en cada ciclo un producto funcional.
Los esquemas y diagramas se harn fundamentalmente en UML.
2.6 TECNOLOGAS Y HERRAMIENTAS A USAR
Durante la creacin del proyecto se van a utilizar las siguientes herramientas:

Java EE -> Plataforma de Programacin para desarrollar software.


JSP -> Tecnologa Java que permite generar cdigo dinmico en la web. Se ha
preferido elegir JSP por encima de PHP debido al inters en profundizar ms 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 difusin y
uso en la programacin web.
Glassfish Server-> Servidor que permitir desplegar y ejecutar nuestras aplicaciones.
Struts -> Framework que implementa el patrn MVC. Se desea usarlo debido a que en

la carrera se incide en una programacin ms pura y vendr bien aprender algo ms


prctico como es el uso de Frameworks.
Poseidon -> Potente software para generar diagramas UML

2.7 RECURSOS HUMANOS Y COMUNICACIONES


En el desarrollo del proyecto participarn las siguientes personas:
Pablo Cacho: alumno de ITIG, ser el desarrollador nico y principal, se encargar de la
creacin, documentacin y presentacin de todo el proyecto.
Laureano Lamban: director del alumno.
Durante el periodo que dure el proyecto, alumno y tutor se comunicaran mediante email y
podrn concertar diferentes reuniones en el despacho del profesor para comprobar el avance
del proyecto o resolver dudas.
2.8 RIESGOS Y PLANES DE ACCIN
Se van a tratar de identificar los factores que puedan suponer retrasos y demoras en el
desarrollo del proyecto. Adems de clasificar estos riesgos se propondrn unos planes de
accin con las medidas a tomar para contrarrestarlos.

2.8.1 POSIBLES RIESGOS

1. El primer factor sera la inexperiencia del alumno en la creacin de proyectos del


tamao requerido para este proyecto fin de carrera. Esta inexperiencia podr suponer
una mala planificacin 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
podra 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 prdida de datos o tiempo al
tener que desplegar todas las herramientas del proyecto en otro ordenador distinto al
habitual.
5. Tambin puede ocurrir que una vez finalizado el proyecto no sea del agrado del
director.

2.8.2 PLANES DE ACCIN

A continuacin se van a exponer los planes de accin resultantes a los riesgos planteados
en el apartado anterior:
1. Se buscar informacin y se consultar otros proyectos parecidos con el fin de obtener
ms idea sobre los tiempos que requiere un proyecto de estas caractersticas.
2. Para evitar retrasos debido al uso de nuevas herramientas se planificar un tiempo de
aprendizaje y recogida de informacin y ejemplos de las principales herramientas a
utilizar.
3. Los factores personales son ms difciles de detectar, en este caso se har uso de la
replanificacin de tareas y horas dedicadas al proyecto.
4. Para evitar la prdida de datos se utilizarn como respaldo pendrives y un sistema de
almacenamiento de datos en la nube como DropBox.
5. Se ir enseando 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 mostrarn a continuacin la descripcin de estas tareas y unos esquemas
representativos.

TAREA 1: SEGUIMIENTO DEL PROYECTO

La tarea nmero 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 peridico de los plazos y
los posibles cambios en la planificacin mediante revisiones.

TAREA 2: GENERACIN MEMORIA

La segunda tarea va a estar dedicada a la generacin de la memoria del proyecto. Durante


la creacin de la aplicacin se debe documentar las decisiones tomadas, el modo en el que
hemos hecho el proyecto usando las tcnicas de desarrollo vistas durante la carrera.
Se ha dividido en 6 subtareas:
Creacin DOP: El Documento de objetivos del proyecto es uno de los ms 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.
Redaccin resto memoria: Partes de la memoria no contenidas en las anteriores. Por
ejemplo posibles anexos, introduccin, conclusiones

Revisin memoria: En esta subtarea se revisar toda la memoria para detectar


posibles errores antes de la entrega.

TAREA 3: PREPARACIN PREVIA

La tercera tarea que se ha identificado es la preparacin 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 estudiarn las herramientas que se han considerado
idneas 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: ESPECIFICACIN DE REQUISITOS

Esta cuarta tarea es la creacin del documento de requisitos. Se extraen en l todos los
requisitos fundamentales que debe cumplir el sistema. Se enumerarn y describirn
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 aplicacin parcial pero
funcional.
Cada tarea y ciclo consta de Anlisis, Diseo, Implementacin y Pruebas.

TAREA 8: PRUEBAS FINALES

La tarea de pruebas finales es la que se realizar una vez que los 3 ciclos estn concluidos.
Tiene como misin detectar fallos que se hayan pasado por alto y hacer nuevas pruebas al
ejecutar los 3 ciclos conjuntamente.

Adems servir para dar por finalizada toda la implementacin y para poder afirmar que el
sistema cumple todos los requisitos planteados al comienzo del proyecto.

TAREA 9: DOCUMENTACIN FINAL

La novena tarea es la redaccin de un manual de instalacin de la aplicacin. Este manual


servir para explicar cmo 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
presentacin para mostrar el resumen de todo el proceso de creacin del proyecto.
Y finalmente se realizar la defensa ante los miembros del tribunal.

Ilustracin 1: Esquema divisin de tareas

Ilustracin 2: Esquema divisin de tareas por ciclo

2.10 PLAN DE TRABAJO Y TEMPORIZACIN


2.10.1 CALENDARIO DE TRABAJO

En el momento que se ha hecho la planificacin se dispone de disponibilidad total para


realizar el proyecto.
Se pondr un horario de trabajo de varias horas al da dedicadas al mismo. Si hubiera algn
cambio en el transcurso del proyecto se indicara en el apartado de replanificacin en gestin
de proyecto.

2.10.2 ESTIMACIN TE MPORAL

En la siguiente tabla se observan las diferentes tareas y unas fechas y horas aproximadas
para su realizacin, en la parte de arriba de cada seccin se muestran las horas acumuladas y
abajo las horas desglosadas:
DURACIN
ESTIMADA
(horas)

TAREAS
Seguimiento del proyecto

INICIO
PREVISTO

FIN
PREVISTO

16

16/02/12

07/06/12

Reuniones

16/02/12

07/06/12

Planificacin

16/02/12

07/06/12

107

16/02/12

07/06/12

Creacin 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

Redaccin resto memoria

10

03/06/12

05/06/12

Revisin memoria

05/06/12

07/06/12

Preparacin previa

29

21/02/12

27/02/12

Estudio del sistema

21/02/12

Estudio de herramientas

25

22/02/12

27/02/12

Estudio viabilidad

27/02/12

27/02/12

Especificacin de requisitos

28/02/12

28/02/12

Generacin del documento de requisitos

28/02/12

28/02/12

Generacin memoria

10

21/02/12

Ciclo 1

142

29/02/12

23/03/12

29/02/12

01/03/12

Casos de uso

29/02/12

29/02/12

Actividad y secuencia

01/03/12

01/03/12

35

02/03/12

10/03/12

02/03/12

05/03/12

Identificar clases y mtodos

02/03/12

02/03/12

Diagrama de clases

05/03/12

05/03/12

06/03/12

06/03/12

06/03/12

06/03/12

23

07/03/12

10/03/12

Identificar pginas

07/03/12

07/03/12

Disear pginas

20

08/03/12

10/03/12

95

12/03/12

22/03/12

Implementar cdigo

90

12/03/12

22/03/12

Implementar BD

12/03/12

22/03/12

Documentar cdigo y BD

12/03/12

22/03/12

23/03/12

24/03/12

23/03/12

24/03/12

169

26/03/12

23/04/12

11

26/03/12

27/03/12

Casos de uso

26/03/12

26/03/12

Actividad y secuencia

27/03/12

27/03/12

30

28/03/12

04/04/12

12

28/03/12

29/03/12

Identificar clases y mtodos

28/03/12

28/03/12

Diagrama de clases

29/03/12

29/03/12

30/03/12

30/03/12

30/03/12

30/03/12

13

02/04/12

04/04/12

Identificar pginas

02/04/12

02/04/12

Disear pginas

10

02/04/12

04/04/12

Anlisis

Diseo
Diseo clases de negocio

Diseo BD
Creacin diagrama ER
Diseo Web

Implementacin

Pruebas
Pruebas unitarias
Ciclo 2
Anlisis

Diseo
Diseo clases de negocio

Diseo BD
Creacin diagrama ER
Diseo Web

11

Implementacin

121

05/04/12

20/04/12

115

05/04/12

20/04/12

Implementar BD

05/04/12

20/04/12

Documentar cdigo y BD

05/04/12

20/04/12

23/04/12

23/04/12

Pruebas unitarias

23/04/12

23/04/12

Pruebas integracin

23/04/12

23/04/12

217

24/04/12

03/06/12

19

24/04/12

26/04/12

Casos de uso

24/04/12

24/04/12

Actividad y secuencia

12

24/04/12

26/04/12

33

27/04/12

03/05/12

12

27/04/12

28/04/12

Identificar clases y mtodos

27/04/12

27/04/12

Diagrama de clases

28/04/12

28/04/12

30/04/12

30/04/12

30/04/12

30/04/12

15

01/05/12

02/05/12

Identificar pginas

01/05/12

01/05/12

Disear pginas

12

01/05/12

02/05/12

158

03/05/12

01/06/12

150

03/05/12

01/06/12

Implementar BD

03/05/12

01/06/12

Documentar cdigo y BD

03/05/12

01/06/12

02/06/12

03/06/12

Pruebas unitarias

02/06/12

02/06/12

Pruebas integracin

03/06/12

03/06/12

04/06/12

04/06/12

04/06/12

04/06/12

04/06/12

06/06/12

04/06/12

06/06/12

11

06/06/12

xx/06/12

Implementar cdigo

Pruebas

Ciclo 3
Anlisis

Diseo
Diseo clases de negocio

Diseo BD
Creacin diagrama ER
Diseo Web

Implementacin
Implementar cdigo

Pruebas

Pruebas finales
Pruebas de aceptacin
Documentacin final
Crear manual instalacin
Defensa del proyecto

12

Preparacin

10

06/06/12

xx-6-12

Defensa

xx-6-12

xx-6-12

704

16/02/12

xx-6-12

TOTAL

Ilustracin 3: Tabla de duraciones estimadas

2.11 DIAGRAMA GANTT


A continuacin se muestran varios diagramas de Gantt con la planificacin inicial del
proyecto.

Ilustracin 4: Diagrama Gantt Inicial

Ilustracin 5 : Diagrama de Gantt Ciclo 1

13

Ilustracin 6: Diagrama Gantt Ciclo 2

Ilustracin 7:Diagrama Gantt Ciclo 3

14

3. GESTIN DE PROYECTO
3.1 INTRODUCCIN
El desarrollo del proyecto ha sido afectado por diversos factores que han condicionado mi
dedicacin al mismo.
Debido a que no se han podido cumplir con las horas planificadas para la realizacin del
proyecto se ha tenido que realizar unas replanificaciones ajustando nuevas fechas para la
finalizacin 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 tambin una lectura demasiado optimista de trabajo diario y no han sido
cumplidas por mi parte las horas dedicadas.
3.3 PRIMERA REPLANIFICACIN
En la replanificacin se retocar las fechas de finalizacin de cada parte del proyecto
afectado por el retraso. Las horas estimadas no necesitarn excesivos cambios.
El proyecto estaba planificado para ser entregado en el curso pasado apurando la fecha
lmite de depsito, sin embargo, al no dedicar las horas diarias necesarias las fechas de
finalizacin de las tareas se iban retrasando. Esto provoc que para la fecha final estimada en
Junio, solo estuvieran finalizados los ciclos 1 y 2.

Ilustracin 8: Diagrama Gant Replanificacin 1

15

3.4 SEGUNDA REPLANIFICACIN


Con el ciclo 3 prcticamente acabado surgen nuevos problemas de trabajo en la dedicacin
al proyecto. Se retrasa y paraliza durante meses y se fija la finalizacin y entrega para
principios de Junio de 2013. El nmero de horas estimadas no es muy distinto del real, lo que
vara mucho es el nmero de horas diarias dedicadas.

Ilustracin 9: Diagrama Gantt Replanificacin 2

3.5 COMPARACIN ESTIMADO CON RESULTADOS FINALES


3.5.1 COMPARACIN FE CHAS

Tarea
Seguimiento
Memoria
Preparacin
Requisitos
Ciclo 1
Ciclo 2
Ciclo 3
Pruebas
finales
Manual

Fecha fin
estimada
07/06/12
07/06/12
27/02/12
28/02/12
24/03/12
23/06/12
03/06/12
03/06/12
07/06/12

Fecha fin
replanificacin 1
10/09/12
10/09/12
03/09/12
05/09/12
08/09/12

Fecha fin
replanificacin 2
31/05/13
31/05/13
24/05/13
31/05/13

Fecha
final real
23/06/13
23/06/13
15/03/12
20/03/12
30/04/12
01/06/12
01/06/13
23/06/13

31/05/13

Ilustracin 10: Tabla Comparativa de fechas

3.5.2 COMPARACIN HORAS

Tarea
Seguimiento
Memoria
Preparacin

Horas
estimadas
16
107
29

16

Horas reales
12
120
35

23/06/13

Requisitos
Ciclo 1
Ciclo 2
Ciclo 3
Pruebas finales
Manual
TOTAL

6
142
169
217
3
4
693

12
130
140
200
4
3
656

Ilustracin 11: Tabla Comparativa de horas

Ilustracin 12: Grfica comparacin horas

17

2. ANLISIS DE REQUISITOS
4.1 INTRODUCCIN
4.1.1 OBJETIVO

Se pretende realizar una aplicacin web que ayude en la gestin, administracin y


explotacin de un hostal. A travs del portal se mostrarn 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 informacin
sobre los hospedados y gestionando nuevos pedidos o reservas.

4.1.2 MBITO

La aplicacin permitir la gestin del hostal y de los usuarios registrados en el mismo. La


gestin de reservas de habitaciones y reservas de sitio en el comedor. Tambin se tramitarn
los pedidos de productos que ofrece el restaurante. Adems se mostrarn una serie de
estadsticas al administrador general del hostal.

4.1.3 REFERENCIAS

Se ha seguido la norma IEEE STD 830 1998 para la elaboracin de esta especificacin de
requisitos.

4.1.4 VISIN GENERAL DEL DOCUMENTO

En este documento se recogern los requisitos que deber satisfacer la aplicacin una vez
est terminada.
Debido a que es un proyecto de varios ciclos e incrementos aqu se van a citar unos
requisitos generales que podran ser retocados o depurados en cada una de las iteraciones del
proyecto.

18

4.2 DESCRIPCIN GENERAL


4.2.1 PERSPECTIVA DEL PRODUCTO

El sistema no formar parte de ningn otro mayor, solo interaccionar con una base de
datos MySQL para almacenar la informacin de los usuarios y el hostal.

4.2.2 FUNCIONES DEL PRODUCTO

La aplicacin constar de 2 funciones claramente separadas, la administracin del hostalrestaurante y la explotacin del mismo. En la primera participarn los administradores y en la
segunda los usuarios que quieran acceder a algn servicio.

4.2.3 CARACTERSTICAS DE LOS USUARIOS

Los usuarios que utilizarn el sistema podrn ser internautas que quieran hacer pedidos o
reservas, adaptados ya a las nuevas tecnologas del comercio por Internet. Los otros usuarios
sern los administradores del hostal, a los que la aplicacin no les causar ninguna dificultad
debido a su simplicidad.
En los administradores separaremos estos 3 tipos:

AdminGeneral: representara al dueo del hostal, podr ver estadsticas del mismo,
as como controlar con la aplicacin las habitaciones, los usuarios o el comedor del
restaurante.
AdminRecepcin: estara en la entrada del hostal, por lo que se ocupara de la entrada
y salida de clientes con reserva de habitacin.
AdminCocina: sera el encargado de gestionar los pedidos online y los productos
ofertados para la compra. El control de las reservas del comedor tambin estara en
sus cometidos.

4.2.4 RESTRICCIONES

Las restricciones sern el uso de contrasea para el acceso a la aplicacin y el uso de roles
como medio para mostrar a cada tipo de usuario unos mens distintos.

19

4.3 REQUISITOS ESPECFICOS


A continuacin se enumerarn los requisitos generales que deber cumplir la aplicacin
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 aplicacin deber ser capaz de poder efectuar las tareas de los siguientes requisitos:
RF1
Introduccin: Un visitante de la web podr darse de alta en el sistema.
Precondicin: 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 intencin 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
Introduccin: Un usuario podr gestionar sus datos.
Precondicin: El usuario debe de estar dado de alta y debe haber iniciado sesin.
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 accin correspondiente y se informar de la finalizacin con xito de
la misma.
RF3
Introduccin: Un administrador podr gestionar usuarios.
Precondicin: 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 gestin de usuarios, donde har la
accin que desee.
Salidas: Se realizar la accin indicada y se mostrar el xito.
RF4
Introduccin: Un usuario podr obtener una nueva contrasea.

20

Precondicin: El usuario debe de estar dado de alta.


Entradas: El usuario desea conseguir una nueva contrasea.
Procedimiento: El usuario pide a la aplicacin obtener una nueva contrasea.
Salidas: Se cambiar la contrasea y se le enviar al usuario.
RF5
Introduccin: Un AdminCocina podr gestionar los productos del hostal.
Precondicin: El AdminCocina debe de estar dado de alta y debe haber introducido su
usuario y contrasea correctamente.
Entradas: El administrador gestionar el alta, modificacin o borrado de nuevos productos
en el men.
Procedimiento: El administrador ir a la seccin donde se gestiona los productos y
ejecutar la accin deseada.
Salidas: Se llevar a cabo la gestin y se mostrar la confirmacin.
RF6
Introduccin: Un usuario podr realizar un pedido online.
Precondicin: El usuario debe de estar registrado y debe haber iniciado sesin.
Entradas: El usuario quiere hacer un pedido.
Procedimiento: El usuario va a la seccin 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
Introduccin: Un AdminCocina podr procesar un pedido.
Precondicin: 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 seccin donde se muestran los pedidos sin finalizar,
elige el deseado y lo finaliza.
Salidas: Se finalizar el pedido y se mostrar la confirmacin.
RF8
Introduccin: Un usuario podr ver un listado de sus pedidos.
Precondicin: El usuario debe de estar registrado, se debe haber logueado y debe haber
hecho algn pedido en el pasado.
Entradas: El usuario quiere ver el listado de pedidos.

21

Procedimiento: El usuario va a la seccin dedicada a sus pedidos donde ver la lista.


Salidas: Se mostrar la lista.
RF9
Introduccin: Un AdminCocina podr ver una lista de pedidos.
Precondicin: El AdminCocina debe de estar registrado y debe de haber iniciado sesin.
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
Introduccin: Un adminCocina podr activar y desactivar en un momento determinado el
sistema de pedidos de la web.
Precondicin: El adminCocina debe de estar registrado y con la sesin iniciada.
Entradas: El administrador quiere activar/desactivar el sistema de pedidos.
Procedimiento: El administrador va a la seccin de cocina donde activar o desactivar los
pedidos.
Salidas: La web permitir hacer pedidos o no.
RF11
Introduccin: Un adminCocina podr determinar un horario de atencin de pedidos online
Precondicin: El adminCocina debe de estar registrado y con la sesin iniciada.
Entradas: El administrador quiere establecer un horario de pedidos online.
Procedimiento: El administrador elige una hora inicial y una final de atencin de pedidos
online.
Salidas: La aplicacin permitir hacer pedidos o no en ese rango horario.
RF12
Introduccin: Un adminCocina podr establecer unos cdigos postales a los que se podrn
hacer entregas de pedidos a domicilio.
Precondicin: El adminCocina debe de estar registrado y con la sesin iniciada.
Entradas: El administrador quiere aadir o eliminar cdigos postales.
Procedimiento: El administrador va a la seccin de cocina donde aadir o eliminar los
cdigos.
Salidas: Se avisar del cambio y la aplicacin permitir realizar pedidos a domicilio a las
direcciones con esos cdigos postales.
RF13

22

Introduccin: Un adminGeneral podr gestionar las habitaciones del hostal.


Precondicin: El adminGeneral debe de estar dado de alta y con sesin iniciada.
Entradas: El administrador quiere aadir/modificar/ver una habitacin.
Procedimiento: El administrador va a la seccin de gestin del hostal donde elige y realiza la
operacin de actualizacin deseada.
Salidas: Se har la gestin y se confirmar la operacin o simplemente se mostrar
informacin.
RF14
Introduccin: Un cliente podr reservar una habitacin.
Precondicin: El cliente debe de estar registrado, con sesin iniciada y debe haber
habitaciones libres en las fechas elegidas.
Entradas: El cliente va a reservar una habitacin.
Procedimiento: El usuario va a la seccin donde selecciona las fechas elegidas y la
habitacin.
Salidas: Se realizara la reserva, se mostrar la confirmacin y se mandar un email al
usuario.
RF15
Introduccin: Un AdminRecepcin podr procesar las reservas de habitaciones.
Precondicin: El AdminRecepcin debe de estar dado de alta y se debe haber logueado.
Entradas: El administrador quiere procesar una reserva.
Procedimiento: El administrador va a la seccin 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 operacin.
RF16
Introduccin: Un usuario podr ver un listado de sus reservas de habitaciones.
Precondicin: El usuario debe de estar dado de alta, se debe haber logueado correctamente
y debe haber hecho alguna reserva de habitacin 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 habitacin del usuario.
RF17
Introduccin: Un AdminRecepcin podr ver un listado de todas las reservas de
habitaciones.

23

Precondicin: El AdminRecepcin debe de estar dado de alta, se debe haber logueado


correctamente y deben existir reservas de habitacin.
Entradas: El administrador quiere ver el listado de reservas.
Procedimiento: El administrador va a una seccin de reservas donde estar el listado con
todas.
Salidas: Se mostrar la lista de reservas de habitacin.
RF18
Introduccin: Un cliente podr hacer una reserva de mesa en el restaurante.
Precondicin: El cliente debe de estar registrado, con sesin 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 seccin de reservas de comedor donde selecciona la fecha
elegida, el horario y el nmero de personas.
Salidas: Se realizar la reserva, se mostrar la confirmacin y se mandar un email al
usuario.
RF19
Introduccin: Un usuario podr ver un listado de sus reservas en el restaurante.
Precondicin: 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 mostrarn
todas.
Salidas: Se mostrar la lista.
RF20
Introduccin: Un AdminCocina podr ver el listado de reservas en el restaurante.
Precondicin: 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
mostrarn todas.
Salidas: Se mostrar la lista de reservas completa.
RF21
Introduccin: Un AdminCocina podr procesar las reservas del restaurante.
Precondicin: El AdminCocina debe de estar registrado y con la sesin iniciada, debe existir
alguna reserva de restaurante pendiente.

24

Entradas: El administrador quiere gestionar una reserva de restaurante.


Procedimiento: El administrador va a la seccin de reservas de restaurante donde elige la
reserva para procesarla, finalizndola como exitosa o cancelndola.
Salidas: Se gestionar la reserva y se mostrar la confirmacin de la accin.
RF22
Introduccin: Un AdminGeneral podr modificar el tamao del restaurante.
Precondicin: El AdminGeneral debe de estar dado de alta y se debe haber iniciado sesin
correctamente.
Entradas: El administrador quiere modificar el tamao del comedor del restaurante puesto
a disposicin de ser reservado.
Procedimiento: El administrador va a la seccin de gestin del hostal referida al comedor
donde modificar el tamao.
Salidas: Se modificar el tamao y saldr mostrada la confirmacin.
RF23
Introduccin: Un adminGeneral podr ver una serie de estadsticas de su hostal.
Precondicin: El AdminGeneral debe de estar registrado y con la sesin iniciada.
Entradas: El administrador quiere ver una grfica de estadstica.
Procedimiento: El administrador va a la seccin de estadsticas, donde selecciona la
estadstica grfica a visualizar.
Salidas: Se mostrarn las estadsticas.

4.3.2 REQUISITOS DE INTERFAZ GRFICA

Los requisitos siguientes estarn relacionados con la parte visual de la web:


RI1
En la interfaz se mostrar informacin 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 sesin.

25

4.3.3 REQUISITOS DE SEGURIDAD

RS1
Para evitar registros masivos se utilizar un captcha en el formulario de registro de
usuarios.
RS2
La sesin de usuario debe caducar a los 10 minutos de inactividad.

4.3.4 INTERFACES EXTERNAS

Los usuarios de la aplicacin interactuarn con la interfaz por medio de un navegador web.

26

4.4 CASOS DE USO GENERALES


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

Ilustracin 13: Diagrama Casos de Uso General

Una breve explicacin de cada caso de uso:


Usuario:

Gestionar sus datos -> Cada usuario de la aplicacin podr tener acceso a sus datos y
modificarlos o borrar su cuenta.
Reservar habitacin -> Los usuarios podrn reservar una habitacin si hay disponibles.
Reservar mesa -> Los usuarios podrn hacer una reserva en el comedor del hostal
siempre que haya sitio.
Realizar pedido -> Asimismo podrn 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 habitacin-> Se muestra un listado de reservas del usuario y sus
detalles.

27

Listar reservas comedor -> Se muestran las reservas de comedor realizadas por el
usuario.

Visitante:

Registro en Web-> Podr registrarse y as en el futuro realizar las operaciones de


Usuario.

adminGeneral:

Gestionar habitaciones -> Aqu estarn todas las operaciones relativas a las
habitaciones que el hostal pone a disposicin en las reservas.
Modificar comedor -> Aumentar o disminuir el tamao del comedor.
Gestionar usuarios -> Acciones sobre los datos de los usuarios registrados.
Visualizar estadsticas -> Ver grficos con estadsticas del hostal.

adminCocina:

Gestionar productos -> Acciones sobre los productos que se ofertarn 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 administracin de las
reservas de sitio en el comedor.

adminRecepcin:

Gestionar reservas de habitacin-> Representa las acciones sobre las reservas de los
usuarios.

28

5. FRAMEWORK: STRUTS
5.1 INTRODUCCIN
Apache Struts es una herramienta de soporte basada en el patrn Modelo-VistaControlador 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 separacin 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 INTRODUCCIN

El patrn de arquitectura MVC (Model-View-Controller) permite separar la lgica de


negocio, los datos de la aplicacin 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 aplicacin, recogiendo sus peticiones e


interacciones con el sistema.

5.2.3 MODELO

El modelo contiene la lgica de negocio donde se encuentran nuestros objetos


representados. Tambin 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 aplicacin, redirigiendo todas las peticiones de


los usuarios. El controlador debe poseer de algn mapa de correspondencias entre las
peticiones que recibe y las respuestas a realizar.

29

Ilustracin 14: Esquema MVC

5.3 COMPONENTES STRUTS


Se puede separar claramente los componentes de Struts en tres tipos:

API de Struts.
Archivos de configuracin.
Etiquetas JSP

5.3.1 API

El API de Struts est formado por las distintas clases de apoyo que el framework pone a
disposicin de los programadores y diseadores para facilitar el desarrollo y estructurar la
aplicacin. La clases a utilizar se encuentran en los paquetes: org.apache.struts.action y
org.apache.struts.actions.
A continuacin 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
informacin contenida en el archivo de configuracin struts-config.xml, donde estar
reflejado el objeto org.apache.struts.action.ActionForm a instanciar y la accin 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 mtodo
execute(). Este mtodo ser el que el programador deber sobrescribir incluyendo

30

todas las instrucciones necesarias para que las peticiones se lleven a cabo
correctamente. La accin acta como un adaptador entre el contenido de una solicitud
http y la lgica de negocio correspondiente.
ActionForm: Los objetos ActionForm son un tipo JavaBean usados para transportar
datos entre las distintas capas de la aplicacin. Son usados por el ActionServlet para
capturar los datos procedentes de un formulario y envirselos al objeto Action que le
corresponda. Los ActionForm constarn de los mtodos get/set para poder y acceder
y tratar la informacin que se obtienen de ellos.
ActionMapping: Un objeto de este tipo representa una asociacin entre una peticin
de usuario y el objeto Action que la tiene que procesar. Contiene la URL que provoca la
ejecucin de la accin y las posibles redirecciones a las distintas vistas a mostrar segn
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 pgina se har usando un
ActionForward.

5.3.2 ARCHIVOS DE CONFIGURACIN

El archivo ms importante de configuracin de Struts que se va a utilizar es strutsconfig.xml que funciona como un enlace entre las capas de Modelo y Vista y define la lgica de
presentacin y navegabilidad de la aplicacin Web.
Es un archivo de tipo XML donde estn registrados y configurados los distintos
componentes de Struts que se utilizarn en la aplicacin. Entre ellos podemos encontrar las
siguientes entradas:

form-beans de la aplicacin: Los form-beans son instancias de una subclase de la clase


ActionForm.
action-mappings : Es la entrada del archivo de configuracin que contiene las reglas de
navegabilidad de la web.

31

Ilustracin 15: Estructura XML form-bean

Otros archivos de configuracin 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 tambin ofrece una serie de etiquetas para facilitar el tratamiento de la informacin
en las pginas JSP. El framework da recursos para evitar el uso de scriptlet (fragmentos Java
dentro de JSP) y mejorar la compresin 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 peticin a la aplicacin
de Struts tiene lugar el siguiente proceso:
1. Analizar la URL: Se pasa la peticin al objeto ActionServlet, ste analiza la URL para
poder as determinar la accin a realizar. Normalmente se asigna al servlet que se
ocupe de todas urls cuya terminacin sea *.do. Cualquier URL que proceda del cliente
y termine en .do provocar que la peticin sea capturada por el servlet.
Si tenemos una URL www.hostal.com/gestin/registro.do , el ActionServlet se
encargar de extraer la parte de URL que est ligada al .do, en este caso /registro.
2. Determinar accin a realizar: Una vez conseguida la ruta /registro el ActionServlet
consulta en el archivo struts-config.xml para determinar que accin debe hacer. Para
cada accin el archivo de configuracin contiene el objeto ActionForm asociado a la

32

operacin 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 peticin: Dentro del mtodo execute() del Action instanciado estar el
cdigo implementado con las operaciones a ejecutar, desde llamadas a mtodos,
almacenamiento de variables o todo aquello necesario para la correcta generacin de las
vistas (JSPs).

4. Generar la vista: Tras ejecutarse el mtodo 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 direccin JSP correspondiente.
Captura ejemplo de una declaracin 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 pgina xito.jsp.
En caso contrario la redirige a altaProducto2.jsp

Captura con los parmetros del mtodo execute de una clase Action

33

Ilustracin 16: Esquema estructural Struts

34

6. CICLO 1
6.1 ANLISIS CICLO 1
6.1.1 ANLISIS DE REQUISITOS
6.1.1.1 INTRODUCCIN

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 ms adelante harn uso de la
aplicacin.

6.1.1.2 USUARIOS INVOLUCRADOS

En este apartado intervendrn adminGeneral y Usuario (indirectamente adminRecepcin y


adminCocina al ser un Usuario con ms 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 seccin con los requisitos funcionales planteados en el anlisis de


requisitos: RF1, RF2, RF3 y RF4 (ver en documento de requisitos, pgina 20).
Se refinan los requisitos RF2 Y RF3:
RF2.1
Introduccin: Un usuario podr ver sus datos.
Precondicin: El usuario debe estar dado de alta y debe haber iniciado sesin.
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 mostrarn los datos.

35

RF2.2
Introduccin: Un usuario podr modificar sus datos.
Precondicin: El usuario debe estar registrado y debe haber iniciado sesin.
Entradas: El usuario quiere modificar sus datos de la cuenta.
Procedimiento: El usuario va a la seccin donde se encuentren los datos y modificar lo que
desee.
Salidas: Se modificarn los datos y se le indicar al usuario el xito de los cambios.

RF2.3
Introduccin: Un usuario podr borrar su cuenta.
Precondicin: 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 seccin del portal donde confirmar que desea borrar su
cuenta.
Salidas: Ser borrado el usuario y as se indicar.

RF3.1
Introduccin: Un administrador podr crear usuarios.
Precondicin: 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 seccin donde rellenar los datos del usuario a
crear.
Salidas: Se crear el usuario y se informar.
RF3.2
Introduccin: Un administrador podr modificar usuarios.
Precondicin: El administrador debe estar registrado y debe haber iniciado sesin.
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 realizarn las modificaciones y as se mostrar.
RF3.3
Introduccin: Un administrador podr borrar usuarios.
Precondicin: El administrador debe estar registrado y debe haber iniciado sesin.
Entradas: El administrador desea borrar a un usuario.
Procedimiento: El administrador va al apartado de la web donde seleccionar al usuario que
ser borrado.
Salidas: Se eliminar y se informar de que se ha borrado.

36

6.1.1.4 CASOS DE USO

El siguiente esquema muestra el diagrama de casos de uso del Ciclo1 de la aplicacin.

Ilustracin 17: Diagrama Casos Uso Ciclo 1

A continuacin se van a enumerar y describir los distintos casos de uso de este primer ciclo:
DARSE DE ALTA
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:

Darse de alta
Usuario nuevo se registra
Visitante
Se almacenan los datos del visitante.

37

Escenario
Principal:
Excepciones:

1.
2.
3.

Visitante introduce sus datos en un formulario.


Sistema registra esos datos y confirma el alta.
Termina caso de uso.
Error en los datos introducidos en el formulario.

VER SUS DATOS


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Ver sus datos


Usuario registrado mira sus datos
Usuario
Usuario est registrado y ha iniciado sesin.
Se muestran los datos.
1. Usuario solicita ver sus datos.
2. Sistema muestra datos.
3. Termina caso de uso

Excepciones:
MODIFICAR SUS DATOS
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:

Modificar sus datos


Usuario modifica sus datos
Usuario
Usuario est registrado y ha iniciado sesin.
Datos son actualizados.
1. Usuario modifica sus datos en el formulario.
2. Sistema actualiza datos y muestra la confirmacin.
3. Termina caso de uso.

Error en los datos introducidos en el formulario.

DARSE DE BAJA
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Excepciones:

Darse de baja
Usuario se da de baja de la web.
Usuario
Usuario est registrado y ha hecho login correctamente.
Todos los datos del usuario se borran
1. Usuario solicita borrar su cuenta.
2. Sistema pide contrasea.
3. Usuario escribe contrasea.
4. Sistema borra usuario y confirma la correcta eliminacin.
5. Termina caso de uso.
Error en la contrasea.

38

RECUPERAR CONTRASEA
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Recuperar contrasea
Usuario consigue una nueva contrasea
Usuario
Usuario est registrado.
Contrasea cambiada
1. Usuario solicita contrasea nueva.
2. Sistema pide datos al usuario.
3. Usuario escribe datos.
4. Sistema cambia contrasea 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:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Listar Usuarios
Administrador desea listar todos los usuarios de la Web
adminGeneral
Administrador est registrado en el sistema y ha iniciado sesin
correctamente.
Se muestra listado de usuarios.
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:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Ver Datos Usuario


Administrador quiere obtener los datos de un usuario.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Se muestra al usuario elegido.
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:

39

MODIFICAR DATOS USUARIO


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Excepciones:

Modificar Datos Usuario


Administrador quiere modificar datos de un usuario.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Usuario es modificado
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.

Error en los datos introducidos en el formulario.

Ilustracin 18: Diagrama Actividad Modificar usuario

40

DAR DE ALTA USUARIO


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:

Dar de Alta Usuario


Administrador quiere dar de alta un nuevo usuario.
adminGeneral
Administrador est registrado y se ha identificado correctamente.
Usuario nuevo es creado.
1. Administrador introduce datos de usuario en formulario.
2. Sistema crea y aade al nuevo usuario.
3. Termina caso de uso.
Error en los datos introducidos en el formulario.

DAR DE BAJA USUARIO


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Dar de Baja Usuario


Administrador quiere borrar a un usuario.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Usuario es borrado.
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:

41

6.2 DISEO CICLO 1


6.2.1 DISEO DE LA ARQUITECTURA
6.2.1.1 INTRODUCCIN

En esta seccin se describir el diseo de la arquitectura en la que estar basado nuestro


sistema.
El diseo est claramente influenciado por el uso de Struts que implementa el patrn MVC.
Este patrn proporciona una clara separacin en distintas capas de los componentes de la
aplicacin.

6.2.1.2 ARQUITECTURA APLICADA A NUESTRO SISTEMA

La arquitectura empleada es una especializacin de la usada tradicionalmente como capa


de presentacin, lgica de negocio y capa de persistencia.
MODELO
En el modelo se tiene toda la lgica de negocio y los objetos de los que se compone la
aplicacin. Tambin 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 pginas JSP (Java Server Pages). En estas pginas se mostrarn las
salidas a las peticiones realizadas por los usuarios. Se intentar en medida de lo posible evitar
el uso de fragmentos de cdigo Java (Scriptlets) ya que sera cdigo poco reutilizable y difcil de
mantener.
CONTROLADOR
El controlador es la unin entre el modelo, que es donde se encuentran los datos, y la vista,
que ser donde sern mostrados esos datos. Se encargar de controlar el flujo de
peticiones/respuestas entre el usuario y la aplicacin.
Para esta labor Struts cuenta con ActionServlet junto al archivo struts-config.xml

42

6.2.2 CLASES DE NEGOCIO


6.2.2.1 INTRODUCCIN

A continuacin se mostrar el diseo de las clases de negocio de la aplicacin en este


primer ciclo.
Las clases sern separadas en:
Objetos de negocio
Clases de persistencia
ActionForms
Actions
Los objetos de negocio sern las clases generales que representarn la informacin con la
cual es sistema opera. Las clases de persistencia sern aquellas encargadas en conectar e
interactuar con la base de datos.
Los ActionForm son clases que actan como un almacn y guardan la informacin recogida
en los campos de los formularios de la web. Esta informacin ser tratada posteriormente en
los Action.
Los Action sern aquellas clases que servirn para realizar todas las operaciones de lo que
sera la lgica 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 mtodos de la superclase. No se necesita
ninguna informacin adicional de los administradores sobre los usuarios. Un Usuario podr ser
cualquier tipo de administrador a la vez o ninguno.
Habr tambin una clase TipoUsuario. sta es necesaria en la aplicacin durante la muestra
de los distintos tipos de usuario en algunas pginas con filtros por tipo de usuario.

43

Ilustracin 19: Diagrama Clases Usuarios Ciclo 1

Estn tambin las clases Email y EncriptadorSHA1. La primera clase se emplear para la
creacin y el envo de emails a los usuarios, y el encriptador para convertir las contraseas en
una cadena SHA1 como medio de seguridad.

Ilustracin 20: Diagrama Clases 2 Ciclo 1

44

6.2.2.3 CLASE DE PERSISTENCIA

Para poder efectuar cambios y operaciones con los datos almacenados en la base de datos,
se necesitarn unas clases con acceso y privilegios suficientes.
En este primer ciclo se utilizarn las clases UsuariosBD para todas las operaciones relativas
a la gestin de los datos de los usuarios, LoginBD para la identificacin de los usuarios y la
clase ConexionBD para conectar con la base de datos.
En las siguientes figuras se muestran los mtodos que sern empleados para interactuar
con ella.

Ilustracin 21: Diagrama Clase LoginBD

45

Ilustracin 22: Diagrama Clase UsuariosBD

6.2.2.4 ACTIONFORMS

Los ActionForms usados en este ciclo sern:

UsuarioActionForm: Este ActionForm guardar toda la informacin recogida en los


formularios relativa a los datos de los usuarios.
LoginActionForm: Ser utilizado durante el proceso de login de usuarios donde
debern poner su usuario y contrasea en un formulario.
ObtenerUsuariosActionForm: Servir para guardar listados de usuarios y poder
mostrarlos en la pgina web.
RedirigirActionForm: Es necesario en ciertos aspectos de redireccin de pginas de la
aplicacin.

46

Ilustracin 23: Esquema FormBeans Ciclo 1

6.2.2.5 ACTIONS

En la tabla siguiente se enumerarn los Action creados para este ciclo junto a una breve
descripcin de cada uno.
Action
LoginAction
ModificarUsuarioAction
GetUsuariosAction
FiltrarUsuariosAction
RegistroWebAction
BajaUsuarioAction
DisplayDatosUsuarioAction
BorrarUsuarioAction
GetDatosUsuarioAction
AltaUsuarioAction
ModificarUsuarioAdminAction
RecuperarPassAction

Descripcin
Action usado durante el inicio de sesin de un usuario.
Action empleado cuando un usuario modifica sus datos.
Action empleado para listar todos los usuarios
registrados.
Action empleado para listar a los usuarios registrados
segn un filtro.
Action utilizado en el registro de un nuevo usuario en la
web.
Action que se encarga de dar de baja a un usuario que
borra su cuenta.
Action que recupera los datos de un usuario elegido por
el administrador y los muestra.
Action empleado para el borrado de un usuario por
parte de un administrador.
Action para mostrar a un usuario sus datos.
Action usado para realizar el alta de un usuario creado
por un administrador.
Action utilizado para ejecutar una modificacin de
usuario por parte del administrador.
Action a usar durante el proceso de recuperacin de
contrasea.

Ilustracin 24: Tabla Actions Ciclo 1

47

6.2.3 DISEO DE LA BASE DE DATOS


6.2.3.1 INTRODUCCIN

A continuacin se va a mostrar el diseo de la base de datos para el ciclo1. Conforme se


vayan creando nuevos ciclos la BD se ir haciendo ms grande para cubrir todas las
necesidades de la aplicacin.

6.2.3.2 REQUISITOS DE LA BASE DE DATOS

Se quiere guardar informacin de todos los usuarios y administradores de la web.


Interesara guardar el nombre, apellidos, direccin, localidad, cdigo postal, telfono, email,
contrasea y fecha de ingreso de cada usuario. Para los administradores no se necesitara
ningn detalle ms.
Cada usuario tendr un identificar nico.

6.2.3.3 DIAGRAMA DE ENTIDAD-RELACIN


DESCRIPCIN DEL DIAGRAMA.
Se han elegido los nombres de las tablas y campos de forma bastante identificativa
respecto a lo que representan. Las entidades creadas sern:

Usuario: Representa a cualquier usuario almacenado en el sistema, contiene


informacin comn y es una superclase de los administradores.
adminGeneral: Sern los administradores generales del hostal, con mayores permisos
que un simple usuario. No se guardar ninguna informacin adicional de ellos respecto
a la de un usuario cualquiera. Hereda toda la informacin de Usuario.
adminRecepcin: Representar a los administradores de la recepcin, al igual que
adminGeneral no se necesitar guardar ninguna informacin adicional propia.
adminCocina: Representa a los administradores de la cocina. Como con los otros dos
tipos de administrador, sus datos estarn en la tabla usuario.

48

Ilustracin 25: Esquema EER Ciclo 1

6.2.3.4 CONVERSIN A MODELO RELACIONAL


TABLAS RESULTANTES
Durante la conversin a tablas han surgido algunas dudas pero al final se ha decidido
apostar por el modelo mostrado en la figura de abajo.
Se poda haber utilizado una sola tabla de usuario eliminando las de los administradores
utilizando unos nuevos campos booleanos (esAdminGeneral, esAdminCocina,
esAdminRecepcin).
La razn por la que se ha decidido dejar las tablas separadas es pensando en una futura
expansin de la aplicacin donde se podra guardar ms informacin de los administradores y
habra que separar las tablas igualmente.

49

NORMALIZACIN

Primera Forma Normal (1FN)


Todas las tablas estn en 1FN al no tener atributos multievaluados.
Segunda Forma Normal (2FN)
Las tablas tambin se encuentran en la 2FN al depender sus atributos no primos de la clave
totalmente y cumplir la 1FN.
Tercera Forma Normal (3FN)
Igualmente tambin 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).
Telfono y email pasarn a ser columnas unique.

6.2.3.5 DIAGRAMA DE TABLAS FINAL

A partir del diagrama EER anterior y la normalizacin se ha generado la siguiente estructura


de tablas de la base de datos.

50

Ilustracin 26: Diagrama Tablas Ciclo 1

6.2.4 INTERFACES GRFICAS DEFINITIVAS


Se van a mostrar algunas capturas de la aplicacin referentes a este ciclo1.

6.2.4.1 LOGIN DE USUARIO

Pantalla de login, el usuario deber identificarse con su telfono y contrasea para poder
acceder a algunas secciones de la web.
Tendr la opcin de conseguir una contrasea nueva en el caso de que la haya olvidado
facilitando correctamente su email y telfono.

51

Ilustracin 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
errneos se indicar en rojo el error del campo a corregir.

52

Ilustracin 28: Interfaz registro de usuario

6.2.4.3 BSQUEDA DE USUARIO

En la pantalla de bsqueda de usuarios se distinguen 2 partes, los campos a rellenar que


sirven de filtro y el listado de usuarios que cumplen el filtro de arriba.
Los listados se pueden exportar en archivos .pdf o .xls para poder imprimirlos, guardarlos

53

Ilustracin 29:Interfaz Bsqueda de usuarios

54

6.2.4.4 ADMINISTRACIN USUARIO

La captura siguiente muestra el men de administracin general referente a la gestin de


usuarios.

Ilustracin 30: Interfaz administracin de usuarios

6.2.4.5 PERFIL DE USUARIO

En la pantalla de perfil de usuario simplemente se mostrarn sus datos y se le dar opcin a


modificarlos o borrar su cuenta.

55

Ilustracin 31:Interfaz datos de usuario

56

6.3 IMPLEMENTACIN CICLO 1


6.3.1 TECNOLOGAS EMPLEADAS
La implementacin de la aplicacin ha sido realizada utilizando tecnologa Java. Se ha usado
adems el framework Struts 1.3.1, que ha facilitado la tarea en algunos aspectos y ha
marcado un camino a seguir en el diseo de la aplicacin.
Para la conexin la base de datos se ha utilizado JDBC con la excepcin de un mtodo que
ha sido implementado mediante Hibernate, que es otro framework, desarrollado para la
persistencia. El mtodo concreto es uno que se necesitaban hacer consultas con filtros, para
los que la tecnologa JDBC deba usar muchsimas consultas distintas. As que se us como
alternativa la opcin de CRITERIA QUERIES de Hibernate que facilitaba mucho la tarea de
aadir 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
automticamente 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 generacin de cdigo y marcacin de errores.
6.3.2 ESTRUCTURA DE CARPETAS
En este primer ciclo la estructura de carpetas ser muy simple. Por un lado estarn las
carpetas que contendrn los archivos .java y en otro las carpetas con los .jsp
Las principales carpetas sern:

Objetos- Contendr el cdigo java de Usuario, AdminCocina, AdminGeneral,


AdminRecepcin, TipoUsuario, Email, EncriptadorSHA1...
Forms- Esta carpeta tendr los ActionForm, en este primer ciclo: UsuarioActionForm,
LoginActionForm y ObtenerUsuariosActionForm
Bd- Tendr las clases relativas a la interaccin con la base de datos: UsuariosBD,
LoginBD, ConexionBD

57

actions.usuarios- Carpeta que contendr los actions del primer ciclo enumerados en la
tabla de la ilustracin 24.
Config- Carpeta donde estarn los archivos de configuracin de la BD.
Actions- Carpeta donde se ubicar la accin comn de redirigir.
Web/WEB-INF/Usuarios- Directorio con todas las pginas JSP referidas a este ciclo,
con acceso restringido.
Web- Carpeta con acceso pblico.

6.3.3 SEGURIDAD
En la parte de seguridad de la aplicacin se ha implementado el comentado captcha en la
pgina de registro. Aparte de esto se han codificado las contraseas mediante SHA1, de forma
que nadie en la BD puede ver la contrasea original.
Otra medida de seguridad de cara al usuario es que una vez logueado, al pasar 10 minutos
inactivo se le cierra la sesin y se le manda a la pgina de login.
Se ha implementado tambin unos accesos y vistas segn 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 ms en el tema de seguridad en la conexin.
6.3.4 CDIGO DESTACABLE
En esta seccin se expondr parte de cdigo fuente que se considera interesante destacar.
HIBERNATE (LISTAR USUARIOS CON FILTRO)

El poner en la bsqueda de usuarios 5 variables de filtrado supona al principio hacer 2^5


consultas distintas comprobando cada campo del formulario. Para hacer ms simple esta
bsqueda con filtro era necesaria una alternativa.
Como se ha explicado hace unos apartados, se ha decidido utilizar en este mtodo
Hibernate debido a su API Criteria, que permite utilizar Criteria Queries. Como se ver en el
cdigo siguiente,
De esta forma se ahorra mucho trabajo a la hora de fijar filtros, simplemente aadiendo
unos criterios a una variable de Criteria.

58

Como se puede ver en el cdigo de abajo, para listar primero se comprueban los datos
recogidos en el formulario (nombre, apellidos, email, telfono) y si no son nulos se aaden
como restricciones que se deben cumplir. Tras esto se fija el tipo de usuario tambin
seleccionado en el formulario de filtrado de la aplicacin. Los usuarios que cumplen todas las
restricciones se aaden a una lista que ser la mostrada en la pgina.

59

Ilustracin 32: Cdigo Hibernate Filtrar Usuarios

LOGIN DE USUARIO

Bsicamente lo que hace el cdigo 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 sealar que la contrasea 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 dueo de ese telfono. Se
guarda en la sesin 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 pgina.

60

Ilustracin 33: Cdigo Login Usuario Action

61

Ilustracin 34: Cdigo Login Usuario BD

JAVASCRIPT CONFIRMACIN ELIMINAR USUARIO

El cdigo correspondiente a este apartado sirve para pedir una segunda confirmacin de
que un usuario debe ser borrado por parte del administrador.
Cuando se pulsa el botn para eliminarlo, se lanza el javascript que pregunta si est seguro.

Ilustracin 35: Cdigo Javascript confirmacin borrado de usuario

62

Ilustracin 36: Cdigo html confirmacin borrado de usuario

63

6.4 PRUEBAS CICLO 1


6.4.1 INTRODUCCIN
Antes de dar por finalizado cada ciclo se deber comprobar su correcto funcionamiento.
Se probarn los formularios para evitar que ocurran fallos provocados por la unicidad de
algn elemento de la base de datos o para comprobar bien los datos antes de que vayan a ser
utilizados por los Action. Como es lgico tambin se testear la aplicacin para que se realicen
correctamente las operaciones marcadas en los requisitos.
6.4.2 VALIDACIN DE FORMULARIOS
Los datos de los formularios se validarn mostrando los errores que se hayan producido en
la introduccin de datos.
Ejemplo de validacin del formulario de login.

Ilustracin 37: Interfaz validacin login

64

Ejemplo de validacin con captcha del formulario de registro:

Ilustracin 38: Interfaz validacin captcha

65

6.4.3 PRUEBAS UNITARIAS


A continuacin se van a probar aquellos casos en los que puede haber conflicto en la
insercin 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
Condicin
Telfono
Unicidad
Email
Unicidad

Clases vlidas

Clases no vlidas

Telfono no existe (AU1)

Telfono existe (AU2)

Email no existe (AU3)

Email existe (AU4)

MODIFICACIN DE USUARIO
Condicin
Telfono
Unicidad
Email
Unicidad

Clases vlidas

Clases no vlidas

Telfono no existe (MU1)

Telfono existe (MU2)

Email no existe (MU3)

Email existe (MU4)

6.4.3.2 CASOS DE PRUEBA


ALTA USUARIO
Caso vlido
Prueba Unitaria 1
Descripcin
Entradas

Alta de un nuevo usuario


Nombre: Federico
Apellidos: Lopera Garca
Direccin: Gran Va n 7 26004 Logroo
CP:"26006"
Telfono : 622622622
Telfono repetido: 622622622
Email: Federico@gmail.com

66

Clases
equivalencia
Resultado
esperado

de

Contrasea: 1234
Contrasea repetida: 1234
Captcha: CORRECTO
(AU1)(AU3)
Operacin exitosa

Casos no vlidos
Prueba Unitaria 2
Descripcin
Entradas

Clases
equivalencia
Resultado
esperado

de

Error, otro usuario tiene ese telfono.

Prueba Unitaria 3
Descripcin
Entradas

Clases
equivalencia
Resultado
esperado

Alta de un nuevo usuario


Nombre: Pedro
Apellidos: Lopera Garca
Direccin: Gran Va n 7 26004 Logroo
CP:"26006"
Telfono : 622622622 (existiendo)
Telfono repetido: 622622622
Email: pedro@gmail.com
Contrasea: 1234
Contrasea repetida: 1234
Captcha: CORRECTO
(AU2)

de

Alta de un nuevo usuario


Nombre: Jaime
Apellidos: Lopera Garca
Direccin: Gran Va n 7 26004 Logroo
CP:"26006"
Telfono : 633633633
Telfono repetido: 633633633
Email: Federico@gmail.com (existiendo)
Contrasea: 1234
Contrasea repetida: 1234
Captcha: CORRECTO
(AU4)
Error, otro usuario tiene ese email.

67

MODIFICAR USUARIO
Caso vlido
Prueba Unitaria 4
Descripcin
Entradas

Clases
equivalencia
Resultado
esperado

de

Modificacin de usuario
Nombre: Jaime
Apellidos: Lopera Garca
Direccin: Gran Va n 7 26004 Logroo
CP:"26006"
Telfono : 644644644
Telfono repetido: 644644644
Email: Federico@gmail.com
Contrasea: 1234
Contrasea repetida: 1234
(MU1)(MU3)
Operacin exitosa

Casos no vlidos
Prueba Unitaria 8
Descripcin
Entradas

Clases
equivalencia
Resultado
esperado

de

Prueba Unitaria 9
Descripcin
Entradas

Modificacin de usuario
Nombre: Jaime
Apellidos: Lopera Bona
Direccin: Gran Va n 7 26004 Logroo
CP:"26006"
Telfono : 622622622 (existiendo)
Telfono repetido: 622622622 (existiendo)
Email: Federico@gmail.com
Contrasea: 1234
Contrasea repetida: 1234
(MU2)
Error, otro usuario tiene ese telfono.

Modificacin de usuario
Nombre: Jaime
Apellidos: Lopera Bona

68

Clases
equivalencia
Resultado
esperado

de

Direccin: Gran Va n 7 26004 Logroo


CP:"26006"
Telfono : 622622622
Telfono repetido: 622622622
Email: pedro@gmail.com (existiendo)
Contrasea: 1234
Contrasea repetida: 1234
(MU3)
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
segn cada campo del formulario y pruebas del captcha se ha probado la integridad y el buen
funcionamiento de los formularios.
Se han realizado tambin distintas pruebas de funcionamiento de la aplicacin durante esta
primera fase de desarrollo para observar si la aplicacin funcionaba correctamente. Tras
realizar algunos cambios para solucionar errores encontrados se tiene ya la aplicacin
corregida y funcionando.

69

7. CICLO 2
7.1 ANLISIS CICLO 2
7.1.1 ANLISIS DE REQUISITOS
7.1.1.1 INTRODUCCIN

El segundo ciclo del sistema est enfocado al tratamiento de los productos del restaurante.
Estos productos sern ofrecidos para la venta online. Se tratar toda la gestin de este sistema
de pedidos, tanto lo referente a la parte de los encargos realizados por los usuarios cmo la de
administracin.

7.1.1.2 USUARIOS INVOLUCRADOS

En este apartado los protagonistas sern adminCocina y Usuario.


AdminCocina ser el administrador encargado de crear nuevos productos, modificarlos y
borrarlos. Tambin asumir la responsabilidad de gestionar los pedidos, marcndolos 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 atencin 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 continuacin se refinan ms RF5, RF7, RF10 y RF12:
RF5.1
Introduccin: Un AdminCocina podr crear un producto para el hostal.
Precondicin: El AdminCocina debe estar registrado y se debe haber logueado.
Entradas: El administrador gestionar el alta de nuevos productos de restaurante.
Procedimiento: El administrador ir al formulario donde escribir los datos del nuevo
producto.
Salidas: Se crear el producto y se informar de que se ha creado con xito.

70

RF5.2
Introduccin: Un AdminCocina podr modificar un producto para el hostal.
Precondicin: El AdminCocina debe estar dado de alta y debe haber iniciado sesin.
Entradas: El administrador quiere modificar un producto ya existente.
Procedimiento: El administrador va a una seccin 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
Introduccin: Un AdminCocina podr borrar un producto de comida para el hostal.
Precondicin: El AdminCocina debe estar registrado y logueado en la aplicacin.
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
Introduccin: Un AdminCocina podr finalizar un pedido.
Precondicin: 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 seccin 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 confirmacin.
RF7.2
Introduccin: Un AdminCocina podr cancelar un pedido.
Precondicin: 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 seccin donde se muestran los pedidos sin finalizar,
elige el deseado y lo cancela.
Salidas: Se cancelar el pedido y se mostrar la confirmacin.

RF10.1
Introduccin: Un adminCocina podr activar el sistema de pedidos de la web.

71

Precondicin: El adminCocina debe estar registrado y con la sesin iniciada.


Entradas: El administrador quiere activar el sistema de pedidos.
Procedimiento: El administrador va a la seccin de cocina donde activar los pedidos.
Salidas: La web permitir hacer pedidos.
RF10.2
Introduccin: Un adminCocina podr desactivar el sistema de pedidos de la web.
Precondicin: El adminCocina debe estar registrado y con la sesin iniciada.
Entradas: El administrador quiere desactivar el sistema de pedidos.
Procedimiento: El administrador va a la seccin de cocina donde desactivar los pedidos.
Salidas: La web ya no permitir hacer pedidos.
RF12.1
Introduccin: Un adminCocina podr aadir un cdigo postal al que hacer entregas.
Precondicin: El adminCocina debe estar registrado y con la sesin iniciada.
Entradas: El administrador quiere aadir un cdigo.
Procedimiento: El administrador va a la seccin de cocina donde aadir el cdigo.
Salidas: El cdigo se aadir permitiendo hacer entregas a domicilio a direcciones con ese
CP.
RF12.2
Introduccin: Un adminCocina podr borrar un cdigo postal al que ya no hacer entregas.
Precondicin: El adminCocina debe estar registrado y con la sesin iniciada.
Entradas: El administrador quiere borrar un cdigo.
Procedimiento: El administrador va a la seccin de cocina donde eliminar el cdigo.
Salidas: El cdigo se borrar impidiendo en el futuro hacer entregas a esos domicilios.

72

7.1.1.4 CASOS DE USO

El siguiente esquema es el diagrama de casos de uso relativo a este segundo ciclo del
proyecto.

Ilustracin 39: Diagrama Casos Uso Ciclo 2

A continuacin se enumeran y describen los distintos casos de uso:


CREAR PRODUCTO
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:

Crear Producto
Administrador quiere crear un nuevo producto
adminCocina
Administrador est registrado y ha iniciado sesin.
Producto es aadido a la BD.
1. Administrador rellena los datos del producto a aadir.
2. Sistema aade producto.
3. Termina caso de uso.

Error en los datos introducidos.

73

MODIFICAR PRODUCTO
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Excepciones:

Modificar producto
Administrador quiere modificar un producto.
adminCocina
Administrador est registrado y ha iniciado sesin.
Producto es modificado.
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.
Error en los datos introducidos.

ELIMINAR PRODUCTO
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Eliminar Producto
Administrador quiere borrar un producto.
adminCocina
Administrador est registrado y ha iniciado sesin.
Producto es borrado.
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:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Ver Producto
Administrador quiere ver un producto.
adminCocina
Administrador est registrado y ha iniciado sesin.
Producto es borrado.
1. Administrador pide listado de productos.
2. Sistema muestra productos.
3. Administrador selecciona producto.

74

4. Sistema muestra datos del producto.


5. Termina caso de uso.
Excepciones:
LISTAR PRODUCTOS
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Listar productos
Administrador quiere listar los productos.
adminCocina
Administrador est registrado y ha iniciado sesin.
Productos son mostrados.
1. Administrador pide listado.
2. Sistema muestra listado de productos.
3. Termina caso de uso.

Excepciones:
HACER PEDIDO
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Hacer Pedido
Usuario quiere hacer un pedido.
Usuario
Usuario est registrado y ha iniciado sesin.
El pedido es realizado y almacenado.
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:

75

Ilustracin 40: Diagrama Secuencia Realizar Pedido

VER SU PEDIDO
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Ver su Pedido
Usuario quiere ver un pedido realizado.
Usuario
Usuario est registrado y ha iniciado sesin.
Pedido es mostrado.
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:

76

LISTAR SUS PEDIDOS


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Listar sus pedidos


Usuario quiere ver sus pedidos.
Usuario
Usuario est registrado y ha iniciado sesin.
Pedidos son mostrados.
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:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Finalizar pedido
Administrador quiere marcar un pedido como ya pagado.
adminCocina
Administrador est registrado y ha iniciado sesin.
Pedido es marcado como pagado
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 aade pedido como pagado en el registro.
7. Termina caso de uso.

Excepciones:
CANCELAR PEDIDO
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Cancelar pedido
Administrador quiere marcar un pedido como cancelado.
adminCocina
Administrador est registrado y ha iniciado sesin.
Pedido es marcado como cancelado
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.

77

Excepciones:

VER PEDIDO
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Ver Pedido
Administrador quiere ver un pedido realizado.
Administrador
Administrador est registrado y ha iniciado sesin.
Pedido es mostrado.
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:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Listar pedidos
Administrador quiere ver listado de pedidos.
adminCocina
Administrador est registrado y ha iniciado sesin.
Pedidos son mostrados.
1. Administrador solicita listado de pedidos.
2. Sistema muestra pedidos.
3. Termina caso de uso.

Excepciones:
ACTIVAR SISTEMA DE PEDIDOS
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Activar sistema de pedidos


Administrador quiere activar el sistema de pedidos.
adminCocina
Administrador est registrado y ha iniciado sesin y los pedidos estn
desactivados.
Pedidos volvern a estar activos.
1. Administrador solicita activar pedidos.
2. Sistema activa pedidos.
3. Termina caso de uso.

Excepciones:

78

DESACTIVAR SISTEMA D E PEDIDOS


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Desactivar sistema de pedidos


Administrador quiere desactivar el sistema de pedidos.
adminCocina
Administrador est registrado y ha iniciado sesin y los pedidos estn
activados.
Pedidos online se desactivarn
1. Administrador solicita desactivar pedidos.
2. Sistema desactiva pedidos.
3. Termina caso de uso.

Excepciones:

MODIFICAR HORARIO DE SISTEMA DE PEDIDOS


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Modificar horario de sistema de pedidos


Administrador quiere modificar el horario en el que el sistema de
pedidos estar activo.
adminCocina
Administrador est registrado y ha iniciado sesin.
El nuevo rango de horas de atencin de pedidos se establecer.
1. Administrador introduce nuevas horas.
2. Sistema cambia el rango de horas.
3. Termina caso de uso.

Excepciones:
AADIR CDIGO POSTAL
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:

Aadir cdigo postal


Administrador quiere aadir un nuevo cdigo.
adminCocina
Administrador est registrado y ha iniciado sesin.
Cdigo es aadido.
1. Administrador inserta cdigo.
2. Sistema aade cdigo.
3. Termina caso de uso.
Cdigo ya existe.

79

ELIMINAR CDIGO POSTAL


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Eliminar cdigo postal


Administrador quiere borrar un cdigo.
adminCocina
Administrador est registrado y ha iniciado sesin.
Cdigo es eliminado.
1. Administrador borra cdigo.
2. Sistema elimina cdigo del registro.
3. Termina caso de uso.

Excepciones:

80

7.2 DISEO CICLO 2


7.2.1 DISEO DE LA ARQUITECTURA
7.2.1.1 INTRODUCCIN

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 diseo guiado por el patrn
MVC y con las clases que pone a disposicin Struts (ActionForm, Actions) junto a las habituales
de objetos de negocio y sus clases de gestin en la BD.

7.2.2 CLASES DE NEGOCIO


7.2.2.1 INTRODUCCIN

Ahora se mostrar el diseo de las clases de negocio del ciclo2 de la aplicacin. Se seguir
un estilo similar al del ciclo1 dividiendo las clases segn su utilizacin y tipo.

7.2.2.2 OBJETOS DE NE GOCIO

El esquema que se ve a continuacin es una ampliacin al desarrollado en el ciclo1. Se han


aadido los nuevos objetos que son utilizados en esta segunda parte del proyecto.
La clase Producto guarda la informacin referente a los productos de restaurante ofrecidos
por la aplicacin. 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 tambin que la clase ProductoEnPedido describe a los productos dentro de
un pedido con una cantidad y un precio. La clase Pedido representa, como su nombre indica, a
un pedido de productos que un usuario ha hecho en el portal web.

81

Ilustracin 41: Diagrama clases ciclo 2

7.2.2.3 CLASES DE PERSISTENCIA

En este segundo ciclo se utilizarn las clases ProductosBD y PedidosBD para realizar todas
las operaciones relativas a la gestin de productos y gestin de pedidos en las que se necesite
acceder o modificar la base de datos.
En el siguiente diagrama se puede observar los mtodos de cada clase.

Ilustracin 42: Diagrama Clases BD Ciclo 2

82

7.2.2.4 ACTIONFORMS

Los ActionForm empleados en este apartado para el tratamiento de la informacin de los


formularios van a ser:

ProductoActionForm
ObtenerProductosActionForm
PedidoActionForm
ObtenerPedidosActionForm
RedirigirActionForm
ConfiguracionHostalActionForm

Ilustracin 43:Diagrama FormBeans Ciclo 2

A destacar simplemente que la clase ConfiguracinPedidosActionForm ser usada para la


activacin y desactivacin del sistema de pedidos, la insercin o eliminacin de cdigos
postales y para la modificacin de horarios. RedirigirActionForm se encargar de cierto
redireccionamiento de la web. Los dems ActionForm sern empleados para operaciones
relacionadas con los productos y los pedidos.

83

7.2.2.5 ACTIONS

En la gestin de productos y pedidos se van a emplear las siguientes Actions:


Tabla para gestin de productos:
Action
AltaProductoAction
ObtenerProductosAction
DisplayDatosProductoAction
ModificarProductosAction
DisplayDatosTipoProductoAction
FiltrarProductosAction
AltaTipoProductoAction
ObtenerTiposProductoAction
BorrarProductoAction
BorrarTipoProductoAction
ModificarTipoProductoAction

Descripcin
Accin empleada para dar de alta un producto con
los datos recogidos del formulario.
Accin empleada para cargar un listado de
productos.
Accin que muestra los datos de un producto.
Accin que modifica los datos de un producto.
Accin que muestra los datos de un tipo de
producto.
Accin que carga una lista de productos segn un
filtro.
Accin usada para crear un nuevo tipo de producto.
Accin que carga los distintos tipos de producto que
existen.
Accin que borra un producto.
Accin empleada para borrado un tipo de producto.
Accin empleada para modificar un tipo de
producto.

Tabla para gestin de pedidos.


Action
ActualizarPedidoAction
DisplayDatosPedidoAction
DisplayDatosPedidoCerradoAction
EliminarProductoPedidoAction
AddProductoPedidoAction
FiltrarPedidosAbiertosAction
FiltrarPedidosAction
FinalizarPedidoAction

Descripcin
Accin empleada para actualizar las cantidades de
los productos de un pedido
Accin usada para mostrar los datos de un pedido
abierto.
Accin usada para mostrar los datos de un pedido
cerrado.
Accin que se usa para eliminar un producto de un
pedido que un usuario est haciendo.
Accin que aade un producto a un pedido que
est realizando un usuario.
Accin que carga un listado de pedidos abiertos
segn un filtro establecido.
Accin que filtra pedidos finalizados.
Accin usada para finalizar un pedido una vez se

84

MostrarCarroAction

GetPedidosAbiertosAction
GetPedidosAbiertosUsuarioAction
GetPedidosAction
GetPedidosUsuarioAction
SellarPedidoAction
SeleccionarProductoAction

ActivacionPedidosAction
ModificarEstadoPedidosOnline

han seleccionado todos los productos.


Accin a usar para ver los elementos del carro de
la compra, es decir, los productos seleccionados para
el pedido.
Accin que carga todos los pedidos que hay
abiertos.
Accin que carga los pedidos abiertos de un
usuario.
Accin que carga en un listado todos los pedidos.
Accin que carga en un listado todos los pedidos
de un usuario.
Accin que finaliza definitivamente un pedido,
marcando como pagado o como cancelado.
Accin que carga los productos que sern
mostrados para venderse en la web si est operativa
la venta online.
Accin utilizada para activar y desactivar el sistema
de pedidos online.
Accin empleada para modificar el horario de
atencin de pedidos online.

85

7.2.3 DISEO DE LA BASE DE DATOS


7.2.3.1 INTRODUCCIN

El diseo que se mostrar a continuacin ser una ampliacin del visto en el ciclo1
aadiendo a los esquemas y tablas la informacin 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
descripcin, el precio, la ltima fecha de actualizacin 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 tambin 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 cancelacin.
Se necesita almacenar los cdigos postales a los cuales se pueden hacer envos online. Y
tambin se desea almacenar una serie de parmetros, como si los envos estn activos y un
horario de atencin de esos pedidos .

7.2.3.3 DIAGRAMA DE ENTIDAD-RELACIN


DESCRIPCIN DEL DIAGRAMA.
Se han elegido los nombres de las entidades y campos de forma bastante identificativa. A
continuacin 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 tambin de una fecha de actualizacin, de un precio y una descripcin.
TipoProducto: Son las categoras 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.
CdigoPostal: Almacena todos los CP a los que se pueden realizar entregas a domicilio.
ConfigPedidos: Se trata de una forma de almacenar determinados datos de configuracin,
tales como el horario de atencin de pedidos, si estos estn activos o el horario de atencin.

86

DIAGRAMA EER
Se ha realizado el siguiente esquema EER para el almacenamiento de informacin del ciclo
2 del proyecto:

Ilustracin 44: Esquema EER Ciclo 2

87

7.2.3.4 CONVERSIN A MODELO RELACIONAL

TABLAS RESULTANTES
En la conversin 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 tambin la tabla ProductoEnPedido. Esta tabla almacena y relaciona cada producto
dentro de un pedido y su cantidad.
NORMALIZACIN
El esquema de abajo muestra las tablas normalizadas, solamente est incluidas las aadidas
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 configuracin y no es preciso que haya claves ni relaciones.
Claves candidatas
Las claves sern los ID en Producto, TipoProducto y Pedido, en TipoProducto nombre
tambin poda haber sido clave pero se ha preferido que tengan un identificador numrico.

88

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:

Ilustracin 45: Esquema Tablas Ciclo 2

89

7.2.4 INTERFACES GRFICAS DEFINITIVAS


VISTA CARTA PEDIDOS

Pantalla pblica de pedidos, los internautas tendrn una visin de los productos
gastronmicos que ofrece el restaurante en su carta y un enlace para comenzar un pedido
online.

Ilustracin 46: Interfaz Carta productos

Vista carro del pedido


Vista de los productos almacenados durante el proceso de pedido. En el carro se puede
borrar productos o actualizar la cantidad deseada.

90

Ilustracin 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 cdigo postal del cliente est entre los disponibles para esa entrega
se da opcin al cliente de recoger el pedido en el restaurante del hostal o de recibirlo en casa.

91

Ilustracin 48: Interfaz Resumen confirmacin pedido

92

Vista configuracin de pedidos


La vista de configuracin de pedidos muestra las opciones de configuracin que tiene un
administrador de cocina. Desde activar o desactivar los pedidos online hasta fijar un horario de
atencin de pedidos.

Ilustracin 49: Interfaz Configuracin pedidos

93

7.3 IMPLEMENTACIN CICLO 2


7.3.1 TECNOLOGAS EMPLEADAS
La implementacin del segundo ciclo ha sido realizada con las mismas tecnologas
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
estarn ubicados los actions relativos a las operaciones de pedidos y productos. Y otras 2
carpetas equivalentes para almacenar los archivos JSP que estarn en Web/WEB-INF/Pedidos
y Web/WEB-INF/Productos
7.3.3 CDIGO DESTACABLE
En esta seccin se expondr parte de cdigo fuente que se considera interesante destacar.
CARRO
En el siguiente cdigo 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 tambin un textbox para cambiar la cantidad
de ellos actualizando el pedido.

Ilustracin 50: Cdigo carro html

94

DISPLAYTAG
Displaytag provee una herramienta para mostrar tablas con datos almacenados en una
lista. Permite ordenar esa tabla por la columna que se le marque mediante la propiedad
sortable=true y a su vez permite exportar esos datos con export=true
Se ha usado una columna con un icono que al pulsarse permite la edicin 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()%>'

Ilustracin 51: Cdigo DisplayTag

95

7.4 PRUEBAS CICLO 2


7.4.1 INTRODUCCIN
Las pruebas a realizar en este ciclo van a centrarse en garantizar el correcto funcionamiento
de todo el proceso de creacin, modificacin y eliminacin de productos. Adems se probar
la realizacin de pedidos incluyendo los productos previamente creados, la finalizacin de esos
pedidos y la muestra de listados tanto de productos como de pedidos.
Como medida de integracin de los 2 ciclos se probar tambin a crear nuevos usuarios y
administradores que realicen y gestionen pedidos respectivamente.
7.4.2 VALIDACIN DE FORMULARIOS
La validacin de formularios tendr lugar para garantizar que no se puedan crear 2
productos o 2 tipos de producto iguales y tambin para chequear que se introducen tipos de
datos correctos en cada campo.

Ilustracin 52: Interfaz validacin formulario alta producto

7.4.3 PRUEBAS UNITARIAS


A continuacin se van a probar aquellos casos en los que puede haber conflicto al existir
restricciones en la base de datos de unicidad.

96

7.4.3.1 CLASES DE EQUIVALENCIA

ALTA DE PRODUCTO
Condicin
Nombre
Unicidad

Clases vlidas
Nombre
(AP1)

no

Clases no vlidas
existe

Nombre existe (AP2)

MODIFICACIN DE PRODUCTO
Condicin
Nombre
Unicidad

Clases vlidas
Nombre
(MP1)

no

Clases no vlidas
existe

Nombre existe (MP2)

ALTA DE TIPO DE PRODUCTO


Condicin
Nombre
Unicidad

Clases vlidas
Nombre
(ATP1)

no

Clases no vlidas
existe

Nombre existe (ATP2)

MODIFICACIN DE TIPO DE PRODUCTO


Condicin
Nombre
Unicidad

Clases vlidas
Nombre
(MTP1)

no

Clases no vlidas
existe

Nombre
(MTP2)

97

existe

7.4.3.2 CASOS DE PRUEBA


ALTA DE PRODUCTO
Caso vlido
Prueba Unitaria 10
Descripcin
Entradas

Clases
equivalencia
Resultado
esperado

de

Alta de un nuevo producto


Nombre: Mickey
Descripcin: Bacon, queso
Precio: 4
Categora: Bocadillos
(AP1)
Operacin exitosa

Caso no vlido
Prueba Unitaria 11
Descripcin
Entradas

Clases
equivalencia
Resultado
esperado

de

Alta de un nuevo producto


Nombre: Mickey (existiendo)
Descripcin: Bacon, queso
Precio: 4
Categora: Bocadillos
(AP2)
Ya existe un producto con ese nombre.

MODIFICACIN DE PRODUCTO
Caso vlido
Prueba Unitaria 12
Descripcin
Entradas

Clases
equivalencia

de

Modificacin de un producto
Nombre: Mickey (cambiado a Goofy)
Descripcin: Bacon, queso
Precio: 4
Categora: Bocadillos
(MP1)

98

Resultado
esperado

Operacin exitosa

Caso no vlido
Prueba Unitaria 13
Descripcin
Entradas

Clases
equivalencia
Resultado
esperado

de

Modificacin de un producto
Nombre: Mickey (cambiado a Aladdin existiendo)
Descripcin: Bacon, queso
Precio: 4
Categora: Bocadillos
(MP2)
Ya existe un producto con ese nombre.

ALTA DE TIPO DE PRODUCTO


Caso vlido
Prueba Unitaria 14
Descripcin
Entradas
Clases
de
equivalencia
Resultado
esperado

Alta de un nuevo tipo de producto


Nombre: Hamburguesas
(ATP1)
Operacin exitosa

Caso no vlido
Prueba Unitaria 15
Descripcin
Entradas
Clases
de
equivalencia
Resultado
esperado

Alta de un nuevo tipo de producto


Nombre: Hamburguesas (existiendo)
(ATP2)
Ya existe un tipo de producto con ese nombre.

99

MODIFICACIN DE TIPO DE PRODUCTO


Caso vlido
Prueba Unitaria 16
Descripcin
Entradas
Clases
de
equivalencia
Resultado
esperado

Modificacin de un producto
Nombre: Hamburguesas (cambiado a bebidas)
(MTP1)
Operacin exitosa

Caso no vlido
Prueba Unitaria 17
Descripcin
Entradas
Clases
de
equivalencia
Resultado
esperado

Modificacin de un producto
Nombre: Hamburguesas (cambiado a bocadillos existiendo)
(MTP2)
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 aplicacin. 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 atencin, activacin y desactivacin de pedidos, activacin y desactivacin de
entrega a domicilio, envo a determinados cdigos postales).

100

8. CICLO 3
8.1 ANALISIS CICLO 3
8.1.1 ANLISIS DE REQUISITOS
8.1.1.1 INTRODUCCIN

Este tercer ciclo ser el ltimo y ms extenso. Engloba todo lo relacionado con las reservas
de habitaciones en el hostal, desde la creacin de nuevas habitaciones y tipos de habitacin
hasta la muestra de habitaciones libres para unas determinadas fechas y su posterior eleccin
por un usuario registrado.
Tambin est incluidas las reservas de sitio en el comedor restaurante y su gestin. Se
incluirn adems una serie de estadsticas del hostal mediante grficas.

8.1.1.2 USUARIOS INVOLUCRADOS

En este apartado intervendrn todos los tipos de usuario: adminCocina, adminRecepcin,


adminGeneral y Usuario.
El adminRecepcin 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, tambin podr modificarlas o eliminarlas. Dispondr de unos formularios con unas
determinadas grficas de estadsticas.
Los adminCocina atendern 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 atendern los requisitos RF13, RF14, RF15, RF16, RF17, RF18, RF19, RF20, RF21, RF22,
RF23. (ver pgina 19)

101

Se refinan y detallan RF13, RF15, RF21 y RF23:


RF13.1
Introduccin: Un adminGeneral podr dar de alta una habitacin del hostal.
Precondicin: El adminGeneral debe estar registrado y se debe haber logueado.
Entradas: El administrador quiere aadir una habitacin.
Procedimiento: El administrador va a un apartado de la web donde aade una habitacin.
Salidas: Se aadir la habitacin y se informar de ello.
RF13.2
Introduccin: Un adminGeneral podr modificar una habitacin del hostal.
Precondicin: El adminGeneral debe estar registrado y debe haber iniciado sesin.
Entradas: El administrador quiere modificar una habitacin.
Procedimiento: El administrador va a una seccin donde elige la habitacin y la modifica.
Salidas: Se modificar la habitacin y se mostrar una confirmacin.
RF13.3
Introduccin: Un adminGeneral podr dar de baja una habitacin del hostal.
Precondicin: El adminGeneral debe estar registrado y debe haber hecho login
correctamente.
Entradas: El administrador quiere borrar una habitacin.
Procedimiento: El administrador va a un apartado donde elige la habitacin a borrar y la
elimina.
Salidas: Se borrar la habitacin y se informar.

RF15.1
Introduccin: Un AdminRecepcin podr finalizar las reservas de habitaciones.
Precondicin: El AdminRecepcin debe estar dado de alta y se debe haber logueado.
Entradas: El administrador quiere finalizar una reserva.
Procedimiento: El administrador va a la seccin 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 operacin.
RF15.2
Introduccin: Un AdminRecepcin podr cancelar las reservas de habitaciones.
Precondicin: El AdminRecepcin debe estar dado de alta y se debe haber logueado.

102

Entradas: El administrador quiere cancelar una reserva.


Procedimiento: El administrador va a la seccin 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
Introduccin: Un AdminCocina podr finalizar las reservas del restaurante.
Precondicin: El AdminCocina debe estar registrado y con la sesin iniciada, debe existir
alguna reserva de restaurante pendiente.
Entradas: El administrador quiere finalizar una reserva de restaurante.
Procedimiento: El administrador va a la seccin de reservas de restaurante donde elige la
reserva para marcarla como pagada..
Salidas: Se finalizar la reserva y se mostrar la confirmacin de la accin.
RF21.2
Introduccin: Un AdminCocina podr cancelar las reservas del restaurante.
Precondicin: El AdminCocina debe estar registrado y con la sesin iniciada, debe existir
alguna reserva de restaurante pendiente.
Entradas: El administrador quiere cancelar una reserva de restaurante.
Procedimiento: El administrador va a la seccin de reservas de restaurante donde elige la
reserva para cancelarla.
Salidas: Se cancelar la reserva y se mostrar la confirmacin de la accin.
RF23.1
Introduccin: Un adminGeneral podr ver una grfica del % de ocupacin de las
habitaciones en un da
Precondicin: El AdminGeneral debe de estar registrado y con la sesin iniciada.
Entradas: El administrador quiere ver una grfica de ocupacin de las habitaciones en un
da.
Procedimiento: El administrador va a la seccin de estadsticas, donde selecciona la
estadstica a visualizar eligiendo una fecha.
Salidas: Se mostrar la grfica.

RF23.2
Introduccin: Un adminGeneral podr ver una grfica del nmero de reservas en el
comedor en un ao mostradas trimestralmente.
Precondicin: El AdminGeneral debe de estar registrado y con la sesin iniciada.
Entradas: El administrador quiere ver la grfica.

103

Procedimiento: El administrador va a la seccin de estadsticas, donde selecciona la


estadstica a visualizar eligiendo un ao.
Salidas: Se mostrar la grfica.

RF23.3
Introduccin: Un adminGeneral podr ver una grfica del % del tipo de pensin elegida por
los clientes en un ao.
Precondicin: El AdminGeneral debe estar registrado y con la sesin iniciada.
Entradas: El administrador quiere ver la grfica descrita arriba.
Procedimiento: El administrador va a la seccin de estadsticas, donde selecciona la
estadstica a visualizar eligiendo un ao.
Salidas: Se mostrar la grfica.
RF23.4
Introduccin: Un adminGeneral podr ver una grfica de la ocupacin de las habitaciones
en un ao agrupadas mensualmente.
Precondicin: El AdminGeneral debe estar registrado y con la sesin iniciada.
Entradas: El administrador quiere ver la grfica.
Procedimiento: El administrador va a la seccin de estadsticas, donde selecciona la
estadstica a visualizar eligiendo un ao.
Salidas: Se mostrar la grfica.
RF23.5
Introduccin: Un adminGeneral podr ver una grfica del nmero de pedidos durante un
ao agrupados trimestralmente.
Precondicin: El AdminGeneral debe estar registrado y con la sesin iniciada.
Entradas: El administrador quiere ver la grfica.
Procedimiento: El administrador va a la seccin de estadsticas, donde selecciona la
estadstica a visualizar eligiendo un ao.
Salidas: Se mostrar la grfica.

RF23.6
Introduccin: Un adminGeneral podr ver una grfica del % de ocupacin del comedor
durante un ao representado trimestralmente.
Precondicin: El AdminGeneral debe estar registrado y con la sesin iniciada.
Entradas: El administrador quiere ver la grfica.

104

Procedimiento: El administrador va a la seccin de estadsticas, donde selecciona la


estadstica a visualizar eligiendo un ao.
Salidas: Se mostrar la grfica.
RF23.7
Introduccin: Un adminGeneral podr ver una grfica del nmero de registros en la web de
nuevos usuarios agrupados mensualmente.
Precondicin: El AdminGeneral debe estar registrado y con la sesin iniciada.
Entradas: El administrador quiere ver la grfica.
Procedimiento: El administrador va a la seccin de estadsticas, donde selecciona la
estadstica a visualizar eligiendo un ao.
Salidas: Se mostrar la grfica.

8.1.1.4 CASOS DE USO

El siguiente esquema muestra una representacin de las funciones que pueda hacer cada
usuario:

Ilustracin 53: Diagrama Casos Uso Ciclo 3

105

CASOS DE USO DE LA GESTIN DE HABITACIONES


CREAR HABITACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:

Crear Habitacin
Administrador quiere crear una nueva habitacin
adminGeneral
Administrador est registrado y ha iniciado sesin.
Habitacin es aadida.
1. Administrador introduce datos de la nueva habitacin.
2. Sistema aade habitacin.
3. Termina caso de uso.

Error en los datos.

MODIFICAR HABITACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Excepciones:

Modificar Habitacin
Administrador quiere modificar una habitacin.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Producto es modificado.
1. Administrador pide listado de habitaciones.
2. Sistema muestra listado de habitaciones.
3. Administrador elige habitacin.
4. Sistema muestra datos de la habitacin.
5. Administrador modifica habitacin.
6. Sistema modifica habitacin.
7. Termina caso de uso.

Error en los datos.

ELIMINAR HABITACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Eliminar Habitacin
Administrador quiere borrar una habitacin.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Habitacin es borrada.
1. Administrador pide listado de habitaciones.
2. Sistema muestra listado de habitaciones.
3. Administrador selecciona habitacin.
4. Sistema muestra datos de la habitacin.
5. Administrador borra habitacin.

106

6. Sistema borra la habitacin.


7. Termina caso de uso.
Excepciones:
VER HABITACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Ver Habitacin
Administrador quiere ver los datos de una habitacin.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Se muestra la habitacin.
1. Administrador pide listado de habitaciones.
2. Sistema muestra listado de habitaciones.
3. Administrador selecciona habitacin.
4. Sistema muestra datos de la habitacin.
5. Termina caso de uso.

Excepciones:
LISTAR HABITACIONES
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Listar habitaciones
Administrador quiere listar las habitaciones.
adminGeneral
Usuarios y administrador estn registrados y han iniciado sesin.
Productos son mostrados.
1. Administrador pide listado de habitaciones.
2. Sistema muestra habitaciones.
3. Termina caso de uso.

Excepciones:

CASOS DE USO DE LA GESTIN DE RESERVA DE HABITACIONES


HACER RESERVA DE HABITACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Hacer Reserva de habitacin


Usuario quiere hacer una reserva de habitacin.
Usuario
Usuario est registrado y ha iniciado sesin.
Pedido es realizado.
1. Usuario elige fechas.
2. Sistema muestra habitaciones libres en esas fechas.

107

Excepciones:

3.
4.
5.
6.

Usuario elige habitacin y tipo de pensin.


Sistema registra reserva.
Sistema enva confirmacin.
Termina caso de uso.
Error en las fechas.
Error porque otro usuario ha reservado antes.

Ilustracin 54:Diagrama Secuencia Reserva Habitacin

108

VER SU RESERVA DE HABITACI N


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Ver su Reserva de habitacin


Usuario quiere ver una reserva.
Usuario
Usuario est registrado y ha iniciado sesin.
Reserva es mostrada.
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 habitacin.
5. Termina caso de uso.

Excepciones:
LISTAR SUS RESERVAS DE HABITACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Listar sus reservas de habitacin


Usuario quiere ver sus reservas.
Usuario
Usuario est registrado y ha iniciado sesin.
La lista de reservas es mostrada.
1. Administrador pide listado de reservas de habitacin.
2. Sistema muestra el listado.
3. Termina caso de uso.

Excepciones:

FINALIZAR RESERVA DE HABITACIN


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Finalizar reserva de habitacin


Administrador quiere marcar una reserva de habitacin como
pagada.
adminRecepcin
Administrador est registrado y ha iniciado sesin.
La reserva de habitacin es marcada como finalizada correctamente.
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.

109

Excepciones:
CANCELAR RESERVA DE HABITACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Cancelar reserva de habitacin


Administrador quiere marcar una reserva como cancelada.
adminRecepcin
Administrador est registrado y ha iniciado sesin.
Reserva es marcado como cancelado
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 HABITACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Listar reservas de habitacin


Administrador quiere ver un listado de reservas de habitacin.
adminRecepcin
Administrador est registrado y ha iniciado sesin.
Pedidos son mostrados.
1. Administrador pide listado de reservas de habitacin.
2. Sistema muestra listado de reservas.
3. Termina caso de uso.

Excepciones:
VER RESERVA DE HABIT ACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Ver su Reserva de habitacin


Administrador quiere ver una reserva.
Administrador
Administrador est registrado y ha iniciado sesin.
Reserva es mostrada.
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 habitacin.
5. Termina caso de uso.

110

Excepciones:

CASOS DE USO DE LA GESTIN DE RESERVA DE COMEDOR


HACER RESERVA DE COMEDOR
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Excepciones:

Hacer Reserva de comedor


Usuario quiere hacer una reserva de plazas en el comedor.
Usuario
Usuario est registrado y han iniciado sesin.
Pedido es realizado.
1. Usuario selecciona fecha y plazas.
2. Sistema confirma reserva.
3. Sistema enva confirmacin.
4. Termina caso de uso.
No hay plazas disponibles.
Error en la fecha.

111

Ilustracin 55: Diagrama secuencia Reserva sitio restaurante

VER SU RESERVA DE COMEDOR


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Ver su reserva de comedor


Usuario quiere ver una reserva suya.
Usuario
Usuario est registrado y ha iniciado sesin.
Reserva es mostrada.
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:

112

LISTAR SUS RESERVAS DE COMEDOR


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Listar sus reservas de comedor


Usuario quiere ver sus reservas.
Usuario
Usuario est registrado y ha iniciado sesin.
La lista de reservas de comedor es mostrada.
1. Administrador va a seccin reservas.
2. Sistema muestra reservas.
3. Termina caso de uso.

Excepciones:
FINALIZAR RESERVA DE COMEDOR
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Finalizar reserva de comedor


Administrador quiere marcar una reserva de comedor como
finalizada correctamente.
adminCocina
Administrador est registrado y ha iniciado sesin.
La reserva de comedor es marcada como pagada.
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 aade reserva como pagada en la BD.
7. Termina caso de uso.

Excepciones:
CANCELAR RESERVA DE COMEDOR
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Cancelar reserva de comedor


Administrador quiere marcar una reserva como cancelada.
adminCocina
Administrador est registrado y ha iniciado sesin.
Reserva es marcado como cancelado
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.

113

7. Termina caso de uso.


Excepciones:
LISTAR RESERVAS DE COMEDOR
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Listar reservas de comedor


Administrador quiere ver listado de pedidos.
adminCocina
Administrador est registrado y ha iniciado sesin.
La lista de reservas de comedor es mostrada.
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:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Ver reserva de comedor


Administrador quiere ver una reserva .
Usuario
Usuario est registrado y ha iniciado sesin.
Reserva es mostrada.
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:
EXPLOSIN DEL CASO DE USO DE VER ESTADSTICAS

Ilustracin 56: Diagrama Casos Uso Estadsticas

114

GENERAR GRFICA DE OCUPACIN DE HABITACIONES POR DA


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Generar Grfica Ocupacin Habitaciones Da


Administrador puede ver una grfica con el % ocupacin de las
habitaciones de un da concreto.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Se muestra la grfica.
1. Administrador introduce fecha.
2. Sistema muestra grfica de esa fecha.
3. Termina caso de uso.

Excepciones:

GENERAR GRFICA DE T IPO DE PENSIN


CASO DE USO:
Descripcin:

Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Generar Grfica Tipo Pensin


Administrador puede ver una grfica que ensee los porcentajes de
cada tipo de reserva de habitacin que eligen los usuarios del ao que le
pongas.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Se muestra la grfica.
1. Administrador introduce ao.
2. Sistema muestra grfica con los datos del ao.
3. Termina caso de uso.

Excepciones:
GENERAR GRFICA DE OCUPACIN DE HABITACIONES POR MES
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Generar Grfica Ocupacin Habitaciones Mes


Administrador puede ver una grfica con la ocupacin de las
habitaciones por meses en el ao seleccionado.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Se muestra la grfica.
1. Administrador introduce ao.
2. Sistema muestra grfica.
3. Termina caso de uso.

Excepciones:

115

GENERAR GRFICA DE RESERVA DE COMEDOR POR TRIMESTRE


CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Generar Grfica Reservas Comedor Trimestre


Administrador puede ver una grfica con la ocupacin del comedor
por trimestres del ao elegido.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Se muestra la grfica.
1. Administrador introduce ao.
2. Sistema muestra grfica.
3. Termina caso de uso.

Excepciones:
GENERAR GRFICA DE REGISTROS DE USUARIO POR MES
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Generar Grfica Registros Mes


Administrador quiere ver una grfica con el nmero de registros
mensual del ao seleccionado.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Se muestra la grfica.
1. Administrador introduce ao.
2. Sistema muestra grfica.
3. Termina caso de uso.

Excepciones:
GENERAR GRFICA DE P EDIDOS POR TRIMESTRE
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Generar Grfica Pedidos Trimestre


Administrador quiere ver una grfica con nmero de pedidos,
representados trimestralmente del ao elegido.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Se muestra la grfica.
1. Administrador introduce ao.
2. Sistema muestra grfica.
3. Termina caso de uso.

Excepciones:
GENERAR GRFICA DE OCUPACIN DE COMEDOR POR DA
CASO DE USO:

Generar Grfica Ocupacin Comedor Da

116

Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:

Administrador quiere ver una grfica con el % ocupacin del


comedor de un da concreto.
adminGeneral
Administrador est registrado y ha iniciado sesin.
Se muestra la grfica.
1. Administrador selecciona fecha.
2. Sistema muestra grfica.
3. Termina caso de uso.

Excepciones:

117

8.2 DISEO CICLO 3


8.2.1 DISEO DE LA ARQUITECTURA
8.2.1.1 INTRODUCCIN

De nuevo al igual que en los 2 primeros ciclos del proyecto se mantiene la arquitectura.
Para ms informacin se puede revisar el apartado del ciclo 1 donde queda explicada.
8.2.2 CLASES DE NEGOCIO
8.2.2.1 INTRODUCCIN

Se amplan las clases de negocio vistas anteriormente con las nuevas referentes a este ciclo.
En este caso los diagramas y apartados quedarn algo ms densos debido a la mayor extensin
de esta ltima parte de la aplicacin.

8.2.2.2 OBJETOS DE NEGOCIO

Los nuevos objetos de negocio van a ser las clases Comedor, Habitacin, TipoHabitacin,
ReservaHabitacin y ReservaComedor.
Los nombres son bastante descriptivos de lo que representarn en la aplicacin. En la parte
dedicada a las reservas de habitaciones estaran Habitacin y su TipoHabitacin. Por ejemplo,
una Habitacin tendra un nmero y el tipo contendra una descripcin de esa habitacin, si es
doble o individual, la capacidad o el precio...
La ReservaHabitacin es otra clase que representa una reserva de una habitacin de un
usuario en unas fechas concretas.
En la parte de reservas de comedor quedaran las clases Comedor, que sera una clase de
tipo Singleton representando al comedor del hostal. Este tendra una capacidad que sera
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.
Poda haberse intentado una generalizacin con la clase Reserva: ReservaComedor y
ReservaHabitacin pero se ha considerado que no sera muy til ya que prcticamente solo
mantienen como elementos comunes que ambas reservas las realiza un Usuario y tienen un
identificador.

118

A continuacin se muestra el diagrama de clases que intervienen en este ciclo.

Ilustracin 57: Diagrama Clases Ciclo 3

8.2.2.3 CLASES DE PERSISTENCIA

Las clases utilizadas para interactuar con la base de datos sern HabitacionesBD,
ReservasHabitacionBD y ComedorBD.
En el esquema de abajo se pueden ver los mtodos de cada clase.

119

Ilustracin 58: Diagrama Clases BD Ciclo 3

8.2.2.4 ACTIONFORMS

Los ActionForms que manejarn la informacin de los formularios de esta parte de la


aplicacin sern:

HabitacionActionForm
ObtenerHabitacionesActionForm
ObtenerReservasActionForm
EstadisticasActionForm
ReservaActionForm
ComedorActionForm

120

8.2.2.5 ACTIONS

Los Actions de este tercer ciclo sern mostrados en las siguientes tablas:

ACTIONS GESTIN DE HABITACIONES


Actions
AltaHabitacionAction
GetHabitacionesAction
DisplayDatosHabitacionAction
FiltrarHabitacionesAction
BorrarHabitacionAction
ModificarHabitacionesAction
AltaTipoHabitacionAction
BorrarTipoHabitacionAction
DisplayDatosTipoHabitacionAction
GetTiposHabitacionesAction
ModificarTipoHabitacionAction
MostrarTiposHabitacionHostal

Descripcin
Accin utilizada para aadir una nueva habitacin.
Accin usada para recuperar listados de
habitaciones.
Accin usada para mostrar los datos de una
habitacin.
Accin que devolver una lista de habitaciones
segn un criterio de filtro.
Accin utilizada para dar de baja una habitacin.
Accin empleada para modificar una habitacin.
Accin usada en el proceso de creacin de un
nuevo tipo de habitacin
Accin utilizada para borrar un tipo de habitacin.
Accin utilizada para mostrar los datos de un tipo
de habitacin.
Accin empleada para devolver una lista con todos
los tipos de habitaciones existentes.
Accin empleada para modificar un tipo de
habitacin.
Accin que carga los tipos de habitacin que
dispone el hostal.

Ilustracin 59: Tabla Actions Habitaciones

ACTIONS RESERVA DE HABITACIONES


Actions
ContinuarReserva2Action

Descripcin
Accin usada en el paso 2 del proceso
de reserva de habitacin por un usuario.
Accin usada durante el paso 1 de la
reserva de habitacin por un usuario.
Accin que muestra los datos de una
reserva de habitacin.
Accin que le muestra al administrador
los datos de una reserva de habitacin.
Accin que le muestra al administrador

ContinuarReservaAction
DisplayDatosReservaAction
DisplayDatosReservaAdminAction
DisplayDatosReservaCerradaAdminAction

121

los datos de una reserva de habitacin ya


finalizada.
Accin que devuelve una lista con las
reservas que han pasado un filtro.
Accin que filtra una serie de reservas
de habitacin y las muestra en una lista.
Accin que devuelve una lista al
administrador con todas las reservas an
abiertas.
Accin que devuelve una lista con todas
las reservas an abiertas de un usuario.
Accin que devuelve una lista al con
todas las reservas registradas.
Accin que devuelve una lista al
administrador con todas las reservas de un
usuario.
Accin que finaliza definitivamente una
reserva de habitacin marcndola como
pagada o como cancelada.
Accin usada en el proceso de reserva
para marcar las fechas de reservas elegidas
por el usuario.
Accin que registra la reserva del
usuario.

FiltrarReservasAbiertasAction
FiltrarReservasAction
GetReservasAbiertasAction

GetReservasAbiertasUsuarioAction
GetReservasAction
GetReservasUsuarioAction

SellarReservaAction

SeleccionarFechaReservaAction

RegistrarReservaHabitacionAction

Ilustracin 60: Tabla Actions Reservas Habitaciones

ACTIONS RESERVA DE COMEDOR


Actions
DisplayReservaComedorAdminAction

FiltrarReservasComedorAction
SellarReservaComedorAction
GetReservasComedorAdmAction
GetReservasComedorUsuarioAction
DisplayDatosReservaComedorAction
FiltrarReservasComedorAbiertasAction

Descripcin
Accin que muestra los datos de una
reserva del comedor elegida por el
administrador.
Accin que muestra una lista filtrada de
reservas de comedor.
Accin que finaliza definitivamente una
reserva de comedor.
Accin que devuelve al administrador
una lista de todas las reservas.
Accin que devuelve al usuario una lista
de todas sus reservas.
Accin que muestra los datos de una
reserva del comedor.
Accin que devuelve una lista filtrada de

122

GetReservasComedorAbiertasAdminAction

GetReservasComedorAbiertasUsuarioAction
RegistrarReservaComedorAction
SeleccionarFechaReservaComedorAction
ModificarCapacidadComedor
DisplayDatosReservaComedorAction

todas las reservas del comedor.


Accin que devuelve al administrador
una lista de todas las reservas del comedor
abiertas.
Accin que devuelve al usuario una lista
de todas las reservas del comedor abiertas.
Accin que guarda una reserva de
comedor de un usuario.
Accin que guarda la fecha elegida por el
usuario para la realizacin de la reserva.
Accin que cambia la capacidad del
comedor.
Accin que le muestra al usuario los
datos de su reserva de comedor.

Ilustracin 61: Tabla Actions Reservas Comedor

ACTIONS ESTADSTICAS
Actions
GraficaOcupacionComedorDiaAction
GraficaOcupacionDiaAction

GraficaOcupacionHostalMesAction

GraficaOcupacionTipoPensionAction

GraficaPedidosTrimestreAction
GraficaRegistrosAoAction

GraficaReservasComedorTrimestreAction

Descripcin
Accin que crea una grfica de estadsticas
de la ocupacin del comedor en un da elegido.
Accin que crea una grfica de estadsticas
de la ocupacin de las habitaciones del hostal
en un da elegido.
Accin que crea una grfica con la
ocupacin del hostal en un ao representada
en meses.
Accin que crea una grfica con los % de los
tipos de pensin elegidos para los usuarios en
un ao.
Accin que crea una grfica con el nmero
de pedidos mensual de un ao seleccionado.
Accin que muestra un diagrama de barras
con el nmero de registros anual
representndolos por meses.
Accin que crea una grfica con la
ocupacin del comedor en un ao
representada en trimestres.

Ilustracin 62: Tabla Actions Estadsticas

123

8.2.3 DISEO DE LA BASE DE DATOS


8.2.3.1 INTRODUCCIN

En este apartado del ciclo 3 se va a finalizar el diseo de la base de datos de la aplicacin.


Se aadirn las nuevas entidades y tablas al diseo de los ciclos anteriores.

8.2.3.2 REQUISITOS DE LA BASE DE DATOS RELATIVOS AL CICLO3

El hostal almacenar las habitaciones con un nmero y estas sern descritas por un tipo de
habitacin. Cada tipo de habitacin tendr una descripcin, un precio y el nmero de personas
que pueden ocuparla.
Se guardarn 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 habitacin elegida y el precio total.
En las reservas de comedor se almacenar informacin como el nmero de personas que
irn 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, tendrn un identificador nico y se quiere saber
si estn finalizadas (pagadas o canceladas) o no para mostrar distintos listados en la aplicacin.
Interesa almacenar tambin el tamao del comedor para poder modificarlo en el futuro si
se diera el caso. Solo hay un comedor puesto a disposicin de los clientes no alojados, sin ms
posibles divisiones.

8.2.3.3 DIAGRAMA DE ENTIDAD-RELACIN


DESCRIPCIN DEL DIAGRAMA.
La figura que se ve abajo representa el diagrama Entidad Relacin relativo al ciclo 3. Se va a
pasar a explicar solo las nuevas entidades porque las de los ciclos anteriores ya se
mencionaron.
Habitacin: Representa las habitaciones del hostal con el identificador del tipo de
habitacin que las describir.
TipoHabitacin: Entidad descriptora de habitaciones, con un precio o nmeros de
ocupantes.
ReservaHabitacin: Representa las reservas de habitaciones realizadas por los usuarios con
su fecha de entrada, fecha de salida, habitacin o precio.

124

ReservaComedor: Esta entidad representa las reservas de comedor hechas por los usuarios
registrados de la web con el nmero de personas que acudirn a comer y otra informacin
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.

Ilustracin 63: Esquema EER Ciclo 3

8.2.3.4 CONVERSIN A MODELO RELACIONAL


TABLAS RESULTANTES
Han aparecido nuevas tablas en la conversin del esquema EER. Habr 2 tablas para
registrar las reservas de habitacin y reservas de comedor canceladas. Y una para almacenar
la capacidad del comedor.

125

NORMALIZACIN

Las nuevas tablas cumplen: 1FN, 2FN y 3FN


Claves candidatas
Las claves sern unos identificadores autoincrementados en Habitacin, TipoHabitacin,
ReservaHabitacin y ReservaComedor. En ConfigComedor al ser una tabla de configuracin y
haber solo un comedor no se pondr ninguna clave. Y en las tablas de canceladas la clave ser
conjunta el identificador de las reservas.

126

8.2.3.5 DIAGRAMA DE TABLAS FINAL

Ilustracin 64: Diagrama Tablas Ciclo 3

8.2.4 INTERFACES GRFICAS


A continuacin se van a mostrar una serie de pantallas realizadas durante este ltimo ciclo
de la aplicacin.

8.2.4.1 GRFICA REPRESENTATIVA DE OCUPACIN DEL HOSTAL UN DETERMINADO


AO

La siguiente pantalla muestra una grfica del tipo de pensin elegido por los clientes en un
ao concreto. Las grficas son realizadas con jfreechart y son altamente personalizables en
colores, tamaos, etiquetas...

127

Ilustracin 65: Interfaz Grfica Tipo Ocupacin hostal

8.2.4.2 GRFICA REPRESENTATIVA DE OCUPACIN DEL HOSTAL UN DETERMINADO


DA

Otra grfica generada con jfreechart. sta muestra la ocupacin de las habitaciones del
hostal en un da concreto elegido por el administrador.

Ilustracin 66: Interfaz Grfica % Ocupacin Hostal

128

8.2.4.3 MEN PRINCIPAL DE LA GESTIN DE HABITACIONES Y COMEDOR

Pantalla del men de administrador general para realizar operaciones relacionadas con la
estructura del hostal restaurante.

Ilustracin 67: Interfaz Administracin hostal

8.2.4.4 PGINA DE SELECCIN DE FECHAS PARA UNA RESERVA DE HABITACIN

Pgina pblica mostrada a los internautas para comprobar si hay habitaciones libres en
unas determinadas fechas. Si se eligen fechas de forma errnea saldr un error indicndolo.

129

Ilustracin 68: Interfaz Eleccin Fechas Reserva Habitacin

8.2.4.5 PARTE DE LA PGINA DE CREACIN D E GRFICAS ESTADSTICAS

La siguiente imagen muestra parte del apartado indicado a la generacin y muestra de


grficas estadsticas. Cada grfica se genera mediante un formulando seleccionando unas
fechas.

130

Ilustracin 69: Interfaz Generacin Grficas

131

8.3 IMPLEMENTACIN CICLO 3


8.3.1 TECNOLOGAS EMPLEADAS
En el desarrollo del ciclo 3 se siguen utilizando las mismas tecnologas explicadas en los
anteriores ciclos.
Como novedad en este ciclo se ha hecho uso de una librera Java llamada jFreeChart.
http://www.jfree.org/jfreechart/ Esta librera ha sido empleada para facilitar la creacin de
grficos de calidad y de todo tipo en Java.
Para elegir las fechas de reservas, tanto de comedor como de habitacin 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 patrn que en las implementaciones pasadas.
Se han aadido los nuevos directorios referentes a las clases .java y las pginas JSP de este
tercer ciclo.
Se aadirn las clases correspondientes a las carpetas objetos, forms y bd.
Y las nuevas carpetas sern:

Web/WEB-INF/Comedor
Web/WEB-INF/ReservasHabitacin
Web/WEB-INF/Estadisticas
Actions.comedor
Actions.estadisticas
Actions.reservashabitacion

132

8.3.3 CDIGO DESTACABLE


EJEMPLO JFREECHART, DIAGRAMA DE SECTORES

133

Ilustracin 70: Cdigo Action Grfica

En la figura de arriba se muestra un ejemplo de Action en el que se ha utilizado Jfreechart


para la creacin de una grfica.
El proceso es simple usando las libreras que proporciona Jfreechart. En este ejemplo se
crea un diagrama de sectores con el % de mesas libres y ocupadas en un determinado da.
1. Se empieza creando un objeto de tipo pieDataset (DefaultPieDataset pieDataset =
new DefaultPieDataset();)
2. Se obtienen los valores a mostrar en esa grfica.
3. Se asignan los valores al objeto pieDataSet (pieDataset.setValue(porcMesaslibres +
"% Mesas libres", porcMesaslibres);)
4. Se crea la grfica final de utilizando el pieDataSet iniciado anteriormente y unos
valores como el titulo u otros datos que se quiere que aparezcan en la grfica.
(JFreeChart chart = ChartFactory.createPieChart("Ocupacin comedor " + horario + "
" + fecha, pieDataset, true, true, false);)
5. Se exporta en un archivo JPEG que ser mostrado en la aplicacin.
(ChartUtilities.saveChartAsJPEG(
new
File(this.getServlet().getServletContext().getRealPath(".")
+
"/images/graficos/DiagramaOcupacionComedorDia.jpg"), chart, 500,
300);)

CALENDARIO
Se ha decidido utilizar un calendario grfico para la insercin de fechas. De esta manera se
elimina el problema de una insercin de fechas en un formato errneo. El calendario es libre y
de fcil implementacin, simplemente se tiene que hacer referencia al archivo js
datetimepicker_css.js y ejecutar el mtodo NewCssCal('demo1','ddMMyyyy') . El primer
parmetro representa un nombre identificativo y el segundo el formato de fecha elegido. El
calendario posee varias opciones ms como incluir una hora pero no es necesario para esta
aplicacin.

134

Ilustracin 71: Interfaz Calendario

ENVO EMAIL TRAS RESERVA


La aplicacin enviar en determinadas ocasiones emails a los usuarios. Cuando un usuario
realice un pedido o una reserva recibir un email con un resumen y confirmacin de la misma.
Debido a ser un proyecto sin hosting ni servidor planteado inicialmente, se usar una
cuenta de Google para el envo de emails.
Para realizar este cometido se ha empleado una clase Email genrica y dependiendo del
tipo de email que sea se cambiar el asunto o el contenido. Para el envo se ha hecho uso de
una serie de clases de javax.mail

135

Ilustracin 72: Cdigo envo email

136

8.4 PRUEBAS CICLO 3


8.4.1 INTRODUCCIN
Las pruebas que se van a realizar en este ltimo ciclo se centrarn en testear el
funcionamiento de los procesos de reservas, de la gestin de habitaciones y comedor, de la
generacin de estadsticas y de la muestra de listados de reservas.
8.4.2 VALIDACIN DE FORMULARIOS
Con la validacin de formularios se asegurar que los datos introducidos por los usuarios
son correctos para su posterior tratamiento por la aplicacin.
Se validarn los formularios que intervienen en la gestin de habitaciones, gestin de
comedor y aquellos que sean usados en las reservas.
8.4.3 PRUEBAS UNITARIAS
8.4.3.1 CLASES DE EQUIVALENCIA

ALTA DE HABITACIN
Condicin
Nmero
Unicidad

Clases vlidas
Nmero
(AH1)

no

Clases no vlidas
existe

Nmero existe (AH2)

MODIFICACIN DE HABITACIN
Condicin
Nmero
Unicidad

Clases vlidas
Nmero
(MH1)

no

Clases no vlidas
existe

Nmero existe (MH2)

8.4.3.2 CASOS DE PRUEBA


Caso vlido
Prueba Unitaria 18
Descripcin

Alta de una nueva habitacin

137

Entradas
Clases
equivalencia
Resultado
esperado

de

Nmero: 1
Tipo Habitacin: Habitacin doble
(AH1)
Operacin exitosa

Caso no vlido
Prueba Unitaria 19
Descripcin
Entradas
Clases
equivalencia
Resultado
esperado

de

Alta de una nueva habitacin


Nmero: 1(existiendo)
Tipo Habitacin: Habitacin doble
(AH2)
Ya existe una habitacin con ese nombre.

MODIFICACIN DE HABITACIN
Caso vlido
Prueba Unitaria 20
Descripcin
Entradas
Clases
equivalencia
Resultado
esperado

de

Modificacin de una habitacin


Nmero: 1(cambio a 2)
Tipo Habitacin: Habitacin doble
(MH1)
Operacin exitosa

Caso no vlido
Prueba Unitaria 21
Descripcin
Entradas
Clases
equivalencia
Resultado
esperado

de

Modificacin de un producto
Nmero: 1(cambio a 3 existiendo)
Tipo Habitacin: Habitacin doble
(MH2)
Ya existe una habitacin con ese nombre.

138

ALTA DE TIPO DE HABITACIN


Condicin
Nmero
Unicidad

Clases vlidas
Nmero no existe
(AH1)

Clases no vlidas
Nmero existe (AH2)

MODIFICACIN DE TIPO DE HABITACIN


Condicin
Nmero
Unicidad

Clases vlidas
Nmero no existe
(MH1)

Clases no vlidas
Nmero existe (MH2)

CASOS DE PRUEBA
ALTA DE TIPO DE HABITACIN
Caso vlido
Prueba Unitaria 22
Descripcin
Entradas

Clases
equivalencia
Resultado
esperado

de

Alta de un nuevo tipo de habitacin


Descripcin: Habitacin doble
Precio:20
Ocupantes:2
(AH1)
Operacin exitosa

Caso no vlido
Prueba Unitaria 23
Descripcin
Entradas

Clases
equivalencia
Resultado

de

Alta de un nuevo tipo de habitacin


Descripcin: Habitacin doble (existiendo)
Precio:20
Ocupantes:2
(AH2)
Ya existe un tipo de habitacin con esa descripcin.

139

esperado

MODIFICACIN DE TIPO DE HABITACIN


Caso vlido
Prueba Unitaria 24
Descripcin
Entradas

Clases
equivalencia
Resultado
esperado

de

Modificacin de un nuevo tipo de habitacin


Descripcin: Habitacin doble (cambio a habitacin triple)
Precio:20
Ocupantes:2
(MH1)
Operacin exitosa

Caso no vlido
Prueba Unitaria 25
Descripcin
Entradas

Clases
equivalencia
Resultado
esperado

Modificacin de un nuevo tipo de habitacin


Descripcin: Habitacin doble (cambio a habitacin triple
existiendo)
Precio:20
Ocupantes:2
de
(MH2)
Ya existe un tipo de habitacin con esa descripcin.

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 estn solucionados.
En las pruebas se personalizaron ms las grficas cambiando algunos colores y leyendas. En
las habitaciones se aadi restricciones en la base de datos para que no pudieran tener la
misma descripcin.

140

9. PRUEBAS FINALES
9.1 PRUEBAS DE INTEGRACIN
Por ltimo se van a seguir una serie de pasos para probar la integracin de los tres ciclos
conjuntamente.
Los pasos y pruebas a realizar sern:
Con adminGeneral:
1. Se darn de alta a varios usuarios, unos sern adminRecepcin, otros adminCocina y
otros Usuarios normales.
2. Se modificarn y borrarn algunos.
3. Se crearn tipos de habitacin y habitaciones asociadas a esos tipos.
4. Se crearn unas habitaciones asociadas a esos tipos.
5. Se crearn varias grficas estadsticas .
Con adminCocina:
1. Se crearn 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 cancelarn y otros se
marcarn como pagados, se comprobarn en los listados los cambios de estado.
3. Se comprobarn, marcarn como pagadas o canceladas varias reservas de comedor.
Con usuario:
1.
2.
3.
4.
5.

Se harn varios pedidos en la aplicacin.


Se harn varias reservas de habitaciones en la aplicacin.
Se harn reservas de plazas en el comedor del restaurante.
Se mirarn sus historiales de pedidos y reservas para ver los cambios de las mismas.
Se realizar un reserva simultnea de una misma habitacin en mismas fechas entre 2
usuarios.
6. Se realizar una reserva simultnea de sitio en el comedor que supere la capacidad
del mismo.
7. Se modificar los datos de la cuenta.
8. Se eliminar la cuenta.

141

Con adminRecepcion:
1. Se atendern las reservas efectuadas por el usuario, cancelando unas y marcando
como pagadas las otras.
2. Se observarn en los listados como cambian de situacin, 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 mnimos de un proyecto de este estilo.
Se han ejecutado correctamente todos los requisitos, as que se darn por finalizadas las
pruebas y se declarar el proyecto como concluido.

142

10. CONCLUSIONES
Esta seccin 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 realizacin de este proyecto, se resuman en:

Mostrar informacin del hostal: Tarifas, situacin geogrfica, habitaciones, comedor,


productos.
Gestin de reservas online: Habitaciones y comedor.
Gestin online de pedidos de productos de restaurante.
Gestin 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.
Estadsticas: Diferentes grficas con estadsticas del hostal-restaurante.

Tras terminar la aplicacin 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 organizacin y planificacin del proyecto.
En el ciclo 1 se cubrieron los objetivos:

Gestin y listados de usuarios.

Sirvi tambin para una mayor toma de contacto con el entorno de Struts.
El ciclo 2 se desarrollaron los objetivos:

Gestin de pedidos, historiales de pedidos.

En el tercer y ltimo ciclo tuvieron cabida:

Gestin de reservas de habitaciones.


Gestin de reservas de comedor.
Historiales de reservas.
Grficas estadsticas.

143

10.2 POSIBLES MEJORAS Y AMPLIACIONES


La aplicacin podra ser ampliada en el futuro conforme a las necesidades de un cliente
final que la pudiera utilizar. Se podra aadir por ejemplo una pasarela de pago para que los
clientes a la vez que hicieran un pedido lo pagaran.
Otra ampliacin podra ser la adicin de un sistema de envo 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 VISIN PERSONAL


Finalizado el proyecto me considero satisfecho del resultado obtenido. Se ha conseguido
crear una aplicacin web cubriendo las necesidades y objetivos planteados.
Uno de los aspectos que ms se incide en la carrera es el relativo a las fases a seguir
durante todo el proceso de creacin de software y su respectiva documentacin. Aunque a
veces el alumno no valore toda esta teora una vez que te pones a desarrollar una aplicacin
de tamao medio o grande te das cuenta de su importancia.
El tiempo que se gasta en una buena planificacin de tareas, en un anlisis o un diseo es
recompensado con creces luego a la hora de programar. De otra manera hay que andar con
cambios sobre la marcha que provocan muchas prdidas de tiempo.
En lo que se refiere a la planificacin personal creo que poda 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 finalizacin del mismo.
Tambin me interesaba mejorar mis conocimientos en Java y en la programacin web en
general. Y otro de los objetivos del proyecto era el de aprender a utilizar algn framework de
desarrollo de software y con Struts he conseguido unas nociones que me sern tiles en el
futuro..
Sin embargo, la utilizacin de frameworks est tan extendida en el desarrollo de
aplicaciones como sta que, lo que al comienzo del proyecto supona una novedad y un
aliciente de aprendizaje hace ms de dos aos, en la actualidad ha perdido cierto sentido.

144

11. GLOSARIO DE TRMINOS


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 aplicacin.
Action: Clase de Struts empleada en la ejecucin de un formulario.
ActionForm: Clase de Struts usada en la captura de datos de los formularios.
Struts-config.xml: Archivo xml de configuracin de Struts donde se definen entre otras
cosas los Action y los ActionForm de la aplicacin.
Ciclo: Iteracin del proyecto.
adminCocina: Administrador o encargado de la parte relacionada con la cocina del
restaurante.
adminRecepcin: Administrador o encargado de la parte relacionada con la recepcin de
hospedados al hostal.
adminGeneral: Encargado general del hostal restaurante.

145

12. BIBLIOGRAFA
Libros

Desarrollo de aplicaciones web dinmicas con XML y Java. [David Parsons, Anaya]
Ingeniera del Software [Sommerville]

Referencias Web:

Foro preguntas-respuestas de programacin http://stackoverflow.com/


Pgina con tutoriales de diseo web. http://w3schools.com/
Gua de usuario de la web oficial de Struts
http://struts.apache.org/development/1.x/userGuide/
http://www.roseindia.net
Pequea introduccin a Struts
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=miPrimeraWebStr
uts
http://dev.mysql.com/doc/
http://www.coderanch.com/

146

13. ANEXOS
13.1 DISEO WEB
13.1.1 INTRODUCCIN

Durante la redaccin de la memoria se ha hecho sobretodo hincapi a la parte de


programacin de la web. La parte de diseo ha quedado en un segundo plano. Por ello en esta
seccin se va a explicar de manera muy breve el diseo web.

13.1.2 PROCESO

El diseo de la web fue empezado en papel recogiendo las secciones que deba tener la
aplicacin. Se cre un diseo 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 visualizacin en todos navegadores.
En la aplicacin se muestra informacin pblica del hostal como marcaban los requisitos.,
tales como la situacin, los precios o informacin tpica de un hostal-restaurante.

13.1.3 IMGENES

Todas las imgenes o iconos empleados han sido sacados de repositorios libres de internet.
Las imgenes de habitaciones o elementos del hostal restaurante pertenecen al Hostal
Merced-Concordia y han sido utilizadas con su consentimiento para la realizacin de este
proyecto.
13.2 LEY ORGNICA DE PROTECCIN DE DATOS
Como se ha visto en esta memoria, la aplicacin creada necesitar recopilar datos relativos
a personas fsicas para su funcionamiento. La aplicacin estara, en principio, planteada para
ser usada en Espaa por lo que debera adaptarse a la legislacin espaola. En este sentido
est creada la Ley Orgnica 15/1999, de Proteccin de Datos de Carcter Personal (LOPD).
http://noticias.juridicas.com/base_datos/Admin/lo15-1999.html

147

La presente Ley Orgnica tiene por objeto garantizar y proteger, en lo que concierne al
tratamiento de los datos personales, las libertades pblicas y los derechos fundamentales de
las personas fsicas, y especialmente de su honor e intimidad personal y familiar.
Para cumplir los requerimientos de dicha ley la empresa deber bsicamente de:
Informar de la existencia de un fichero o ficheros con datos de carcter personal
relativos a los usuarios registrados.
Notificar los ficheros ante el Registro General de Proteccin de Datos para su
inscripcin.
Facilitar y garantizar el derecho del acceso, modificacin, cancelacin de esos datos.
Obtener el consentimiento para el tratamiento de los datos personales.
Asegurarse que los datos son veraces y han sido obtenidos lcita y legtimamente y
tratados para los fines que fueron obtenidos.
Para ms informacin se puede mirar esta gua puesta por la agencia de proteccin de
datos.
http://www.agpd.es/portalwebAGPD/canaldocumentacion/publicaciones/common/pdfs/guia
_responsable_ficheros.pdf

13.3 MANUAL DE INSTALACIN Y DESPLIEGUE


13.3.1 INTRODUCCIN

En el cd del proyecto se va a entregar el cdigo fuente desarrollado con NetBeans aunque


para desplegar la aplicacin 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 ms simple es
descargarse Xampp http://www.apachefriends.org/es/xampp.html
Xampp es un servidor independiente de software libre que permite la instalacin de un
servidor apache y una base de datos Mysql de forma sencilla. Incluye la herramienta
phpMyAdmin para manejar fcilmente ese tipo de bases de datos.

148

Ilustracin 73: Recorte de pantalla de Xampp


Con Xampp instalado para cargar la base de datos hay que:
1.
2.
3.
4.
5.

Iniciar los servicios de apache y mysql.


Ir al navegador y en la ruta poner localhost.
Ir a phpmyadmin.
Crear base de datos con nombre hostalbd.
En la pestaa importar cargar el archivo .sql

Ilustracin 74: Recorte de myphpadmin

149

En el proceso de carga se ejecutan automticamente todas las consultas incluidas en ese


archivo y al finalizar ya se tiene la base de datos instalada.

13.3.4 INSTALACIN DE SERVIDOR DE APLICACIONES WEB Y DESPLIEGUE

Para cargar e implementar la aplicacin 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 aadir al path de Windows la carpeta bin creada en la ruta de instalacin
elegida para Glassfish, o ejecutar este comando en smbolo 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 opcin para desplegar la aplicacin tras escribir el comando de asadmin start-domain
es entrar en la pgina de configuracin de GlassFish en localhost:4848 . Tras escribir el usuario
y contrasea que elegimos en la instalacin, habr que ir al apartado aplicaciones desde
donde cargaremos el archivo .war.

Ilustracin 75 : Pantalla del servidor GlassFish

150

Debera desplegarse tambin correctamente. Con la aplicacin desplegada se puede


acceder a ella y probarla en http://localhost:8080/Hostal-PFC/index.jsp o clickeando en Iniciar
desde la pgina de Glassfish.

13.4 MANUAL DE ADMINISTRADOR Y USUARIO


13.4.1 INTRODUCCIN

Debido a que es una aplicacin bastante entendible y comn no es necesario crear un


manual muy extenso sobre cmo utilizarla. A continuacin se pasar a mostrar brevemente
algunas descripciones y capturas de como cada tipo de usuario interactuara con la web.

13.4.2 VISITANTE

Un visitante podr ver informacin del hostal restaurante o registrarse en la pgina para
poder hacer pedidos o reservas.

Ilustracin 76: Pantalla de informacin del hostal

151

Ilustracin 77: Pantalla de registro de usuario

13.4.3 USUARIO

Un usuario registrado podr ver y modificar sus datos en el enlace de perfil:

Ilustracin 78: Perfil de usuario


Tambin podr realizar pedidos de productos desde el enlace de arriba de pedidos o desde
el del lateral.

152

Ilustracin 79: Listado de productos a la venta


Ir seleccionando los que quiera comprar y finalizar su pedido clickeando primero en carro
y despus en finalizar pedido.

Ilustracin 80: Resumen del pedido

153

Un usuario tambin podr realizar reservas de habitacin y de comedor. Para las reservas
de habitacin primero elegir las fechas de entrada y salida para comprobar si hay
habitaciones libres.

Ilustracin 81: Eleccin de fechas de reserva de habitacin

Ilustracin 82: Habitaciones libres para unas fechas

154

Si las hay, elegir la habitacin que le interese y completar la reserva.

Ilustracin 83: Resumen de reserva de habitacin


Respecto a las reservas de comedor, el usuario deber elegir un horario, con su fecha y
nmero de personas que van a acudir.

Ilustracin 84: Eleccin de datos para reserva de comedor.


Y confirmar la reserva si hay sitio suficiente.

155

Ilustracin 85: Confirmacin de reserva de comedor.


Finalmente un usuario podr ver listados de sus pedidos y reservas abiertas o ya cerradas.

Ilustracin 86: Pantalla de listados de pedidos

156

Ilustracin 87: Pantalla de listados de reservas.

13.4.4 ADMINGENERAL

Un adminGeneral se encargar de la gestin de usuarios, de las habitaciones del hostal, del


tamao del comedor y de la visualizacin de estadsticas.
El administrador podr ver, modificar o crear usuarios desde el enlace de Gestin Usuarios:

Ilustracin 88: Pantalla de administracin de usuarios

157

Ilustracin 89: Pantalla de listado de usuarios

En el apartado de Gestin Hostal podr crear y modificar habitaciones y sus tipos y ajustar
el tamao del comedor.

158

Ilustracin 90: Pantalla de administracin del hostal


Y en el enlace de estadsticas el administrador podr crear unas grficas con informacin
del estado del hostal restaurante. Podr consultar datos de pedidos, registros o reservas segn
elija crear una grfica u otra.

159

Ilustracin 91: Pgina de generacin de grficas

160

13.4.5 ADMINCOCINA

El administrador de cocina se encarga de todo lo relacionado con el sistema de pedidos.


Crear los productos puestos a la venta online, finalizar los pedidos y podr configurar el
sistema con un horario de atencin o actividad.

Ilustracin 92: Men administracin 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 estn an abiertos o simplemente consultarlos.

161

Ilustracin 93: Pantalla administracin de pedidos

Ilustracin 94: Pantalla de finalizacin de pedido

162

En sistema de pedidos estar toda la configuracin:

Ilustracin 95: Configuracin de sistema de pedidos

El apartado de reservas de comedor ser bastante similar, se podrn ver listados de


reservas, abiertas o cerradas, que se podrn consultar o finalizar.

Ilustracin 96: Pantalla de administracin de comedor

163

Ilustracin 97: Listado de reservas de comedor

Ilustracin 98: Finalizacin de reserva de comedor.

164

13.4.6 ADMINRECEPCIN

Los administradores de recepcin sern los encargados en gestionar las reservas online,
atendiendo a las entradas de clientes en el hostal con su reserva anteriormente hecha.
Tendrn listados de reservas que debern finalizar cuando el cliente deje el hostal o cuando
cancele esa reserva.

Ilustracin 99: Men administracin de la recepcin

Ilustracin 100: Listado de reservas de habitacin abiertas

165

Elegirn la reserva abierta que deseen y la finalizarn.

Ilustracin 101: Resumen de reserva de habitacin a finalizar

166

You might also like