Академический Документы
Профессиональный Документы
Культура Документы
Ttulo
Matemticas y Computacin
Curso Acadmico
2012-2013
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
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
II
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
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
VIII
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:
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:
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.
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.
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.
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.
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.
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.
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
10
03/06/12
05/06/12
Revisin memoria
05/06/12
07/06/12
Preparacin previa
29
21/02/12
27/02/12
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
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
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
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
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
13
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.
15
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
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
17
2. ANLISIS DE REQUISITOS
4.1 INTRODUCCIN
4.1.1 OBJETIVO
4.1.2 MBITO
4.1.3 REFERENCIAS
Se ha seguido la norma IEEE STD 830 1998 para la elaboracin de esta especificacin de
requisitos.
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
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.
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.
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
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
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
22
23
24
25
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.
Los usuarios de la aplicacin interactuarn con la interfaz por medio de un navegador web.
26
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:
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
5.2.2 VISTA
5.2.3 MODELO
5.2.4 CONTROLADOR
29
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:
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.
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:
31
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).
Captura con los parmetros del mtodo execute de una clase Action
33
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.
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
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.
Excepciones:
MODIFICAR SUS DATOS
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
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:
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:
Excepciones:
39
Excepciones:
40
Excepciones:
41
42
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
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.
44
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.
45
6.2.2.4 ACTIONFORMS
46
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.
47
48
49
NORMALIZACIN
50
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
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
53
54
55
56
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)
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
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
61
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.
62
63
64
65
Clases vlidas
Clases no vlidas
MODIFICACIN DE USUARIO
Condicin
Telfono
Unicidad
Email
Unicidad
Clases vlidas
Clases no vlidas
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
Prueba Unitaria 3
Descripcin
Entradas
Clases
equivalencia
Resultado
esperado
de
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
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.
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
72
El siguiente esquema es el diagrama de casos de uso relativo a este segundo ciclo del
proyecto.
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.
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
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
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
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:
Excepciones:
78
Excepciones:
Excepciones:
AADIR CDIGO POSTAL
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
79
Excepciones:
80
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.
81
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.
82
7.2.2.4 ACTIONFORMS
ProductoActionForm
ObtenerProductosActionForm
PedidoActionForm
ObtenerPedidosActionForm
RedirigirActionForm
ConfiguracionHostalActionForm
83
7.2.2.5 ACTIONS
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.
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
85
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.
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 .
86
DIAGRAMA EER
Se ha realizado el siguiente esquema EER para el almacenamiento de informacin del ciclo
2 del proyecto:
87
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
89
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.
90
91
92
93
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()%>'
95
96
ALTA DE PRODUCTO
Condicin
Nombre
Unicidad
Clases vlidas
Nombre
(AP1)
no
Clases no vlidas
existe
MODIFICACIN DE PRODUCTO
Condicin
Nombre
Unicidad
Clases vlidas
Nombre
(MP1)
no
Clases no vlidas
existe
Clases vlidas
Nombre
(ATP1)
no
Clases no vlidas
existe
Clases vlidas
Nombre
(MTP1)
no
Clases no vlidas
existe
Nombre
(MTP2)
97
existe
Clases
equivalencia
Resultado
esperado
de
Caso no vlido
Prueba Unitaria 11
Descripcin
Entradas
Clases
equivalencia
Resultado
esperado
de
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.
Caso no vlido
Prueba Unitaria 15
Descripcin
Entradas
Clases
de
equivalencia
Resultado
esperado
99
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.
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.
Se atendern los requisitos RF13, RF14, RF15, RF16, RF17, RF18, RF19, RF20, RF21, RF22,
RF23. (ver pgina 19)
101
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
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
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
El siguiente esquema muestra una representacin de las funciones que pueda hacer cada
usuario:
105
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.
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.
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
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:
107
Excepciones:
3.
4.
5.
6.
108
Excepciones:
LISTAR SUS RESERVAS DE HABITACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
109
Excepciones:
CANCELAR RESERVA DE HABITACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
LISTAR RESERVAS DE HABITACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
VER RESERVA DE HABIT ACIN
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
110
Excepciones:
Excepciones:
111
Excepciones:
112
Excepciones:
FINALIZAR RESERVA DE COMEDOR
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
CANCELAR RESERVA DE COMEDOR
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
113
Excepciones:
VER RESERVA DE COMEDOR
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
EXPLOSIN DEL CASO DE USO DE VER ESTADSTICAS
114
Excepciones:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
GENERAR GRFICA DE OCUPACIN DE HABITACIONES POR MES
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
115
Excepciones:
GENERAR GRFICA DE REGISTROS DE USUARIO POR MES
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
GENERAR GRFICA DE P EDIDOS POR TRIMESTRE
CASO DE USO:
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
GENERAR GRFICA DE OCUPACIN DE COMEDOR POR DA
CASO DE USO:
116
Descripcin:
Actores:
Precondicin:
Postcondicin:
Escenario
Principal:
Excepciones:
117
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.
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
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
8.2.2.4 ACTIONFORMS
HabitacionActionForm
ObtenerHabitacionesActionForm
ObtenerReservasActionForm
EstadisticasActionForm
ReservaActionForm
ComedorActionForm
120
8.2.2.5 ACTIONS
Los Actions de este tercer ciclo sern mostrados en las siguientes tablas:
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.
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
FiltrarReservasAbiertasAction
FiltrarReservasAction
GetReservasAbiertasAction
GetReservasAbiertasUsuarioAction
GetReservasAction
GetReservasUsuarioAction
SellarReservaAction
SeleccionarFechaReservaAction
RegistrarReservaHabitacionAction
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
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.
123
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.
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.
125
NORMALIZACIN
126
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
Otra grfica generada con jfreechart. sta muestra la ocupacin de las habitaciones del
hostal en un da concreto elegido por el administrador.
128
Pantalla del men de administrador general para realizar operaciones relacionadas con la
estructura del hostal restaurante.
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
130
131
Web/WEB-INF/Comedor
Web/WEB-INF/ReservasHabitacin
Web/WEB-INF/Estadisticas
Actions.comedor
Actions.estadisticas
Actions.reservashabitacion
132
133
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
135
136
ALTA DE HABITACIN
Condicin
Nmero
Unicidad
Clases vlidas
Nmero
(AH1)
no
Clases no vlidas
existe
MODIFICACIN DE HABITACIN
Condicin
Nmero
Unicidad
Clases vlidas
Nmero
(MH1)
no
Clases no vlidas
existe
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
MODIFICACIN DE HABITACIN
Caso vlido
Prueba Unitaria 20
Descripcin
Entradas
Clases
equivalencia
Resultado
esperado
de
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
Clases vlidas
Nmero no existe
(AH1)
Clases no vlidas
Nmero existe (AH2)
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
Caso no vlido
Prueba Unitaria 23
Descripcin
Entradas
Clases
equivalencia
Resultado
de
139
esperado
Clases
equivalencia
Resultado
esperado
de
Caso no vlido
Prueba Unitaria 25
Descripcin
Entradas
Clases
equivalencia
Resultado
esperado
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.
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.
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:
Sirvi tambin para una mayor toma de contacto con el entorno de Struts.
El ciclo 2 se desarrollaron los objetivos:
143
144
145
12. BIBLIOGRAFA
Libros
Desarrollo de aplicaciones web dinmicas con XML y Java. [David Parsons, Anaya]
Ingeniera del Software [Sommerville]
Referencias Web:
146
13. ANEXOS
13.1 DISEO WEB
13.1.1 INTRODUCCIN
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.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.
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
149
150
13.4.2 VISITANTE
Un visitante podr ver informacin del hostal restaurante o registrarse en la pgina para
poder hacer pedidos o reservas.
151
13.4.3 USUARIO
152
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.
154
155
156
13.4.4 ADMINGENERAL
157
En el apartado de Gestin Hostal podr crear y modificar habitaciones y sus tipos y ajustar
el tamao del comedor.
158
159
160
13.4.5 ADMINCOCINA
161
162
163
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.
165
166