Este documento presenta un proyecto de fin de carrera para desarrollar una aplicación web para gestionar las actividades de un hotel usando Java EE y arquitectura MVC. El proyecto incluye el desarrollo de funcionalidades para realizar y gestionar reservas, gestionar clientes, habitaciones y un complejo sistema de ofertas. El documento describe los requisitos, el diseño de la aplicación, su implementación, pruebas y documentación para los usuarios.

1. Facultad de Inform´tica de la Universidad de A Coru˜ a
a
n
Departamento de Tecnolog´ de la Informaci´n y las Comunicaciones
ıas
o
PROYECTO DE FIN DE CARRERA
´
´
INGENIER´ TECNICA INFORMATICA DE GESTION
IA ´
Dise˜ o e Implementaci´n de una Aplicaci´n Web Java EE
n
o
o
con Arquitectura MVC Destinada a Gestionar las
Actividades de un Hotel
Alumno: Sergio Pad´ Varela
ın
Director: Carlos Alberto Pan Berm´ dez
u
Fecha:
29 de septiembre de 2009

3. A mis padres, mi hermano, mis abuelos y a toda mi familia, por su apoyo y ayuda
incondicional. A todos mis amigos por los buenos momentos que me han regalado. Y a
mi novia por todo el cari˜o, apoyo y animo que me ha dado en todo momento. A todos
n
´
ellos, much´simas gracias.
ı
Sergio Pad´n Varela
ı
3

5. 5
´
Dr. Carlos Alberto Pan Bermudez
Profesor de la Faculdad de Inform´tica de la Coru˜a
a
n
Departamento de Tecnolog´ de la Informaci´n y las Comunicaciones
ıas
o
Universidad de A Coru˜a
n
CERTIFICA: Que la memoria titulada “Dise˜o e Implementaci´n de una Aplicaci´n
n
o
o
Web Java EE con Arquitectura MVC Destinada a Gestionar las Actividades de un Hotel”
ha sido realizada por Sergio Pad´ Varela bajo mi direcci´n y constituye su Proyecto
ın
o
de Fin de Carrera de Ingenier´ T´cnica Inform´tica de Gesti´n.
ıa e
a
o
En A Coru˜a, a 25 de septiembre de 2009
n
´
Dr. Carlos Alberto Pan Bermudez
Director del proyecto

7. 7
Resumen:
El proyecto realizado consiste en desarrollar una Aplicaci´n Web para la gesti´n de
o
o
las reservas de un hotel o similar. Tambi´n hay que desarrollar todo lo necesario para la
e
realizaci´n de reservas, incluyendo entre otros la gesti´n de clientes y usuarios de la web,
o
o
las habitaciones, y los pagos de las mismas.
Adem´s tambi´n se desarrolla un complejo sistema de ofertas, donde se permite crear
a
e
ofertas que puedan ser incompatibles unas con otras y basadas en reglas de aplicaci´n,
o
altamente configurables para especificar el contexto al cu´l se le puede aplicar dicha oferta.
a
Estas luego son utilizadas din´micamente a la hora de realizar la factura que tiene que
a
abonar el cliente, en donde se calcula el conjunto de ofertas compatibles entre s´ que mayor
ı
descuento proporcionan sobre la factura.
La Aplicaci´n distingue tres roles principales: el usuario/cliente (de ahora en adelante el
o
cliente), el recepcionista y el administrador. Cada uno puede realizar una serie operaciones
sobre la aplicaci´n.
o
El cliente puede realizar reservas, consultar las ya realizadas y pagarlas o cancelarlas,
ver disponibilidad de habitaciones, y todas las operaciones relacionadas con altas, bajas o
actualizaciones de su perfil web.
Por otro lado el recepcionista puede gestionar los clientes, d´ndolos de alta, de baja,
a
actualizar sus perfiles o realizar reservas a su nombre. Para todo ello el recepcionista puede
buscar a los clientes por uno o m´s par´metros. Tambi´n tiene la posibilidad de cobrar
a
a
e
una reserva a un cliente o cancelarla, entre otras cosas.
El administrador es el usuario de la aplicaci´n que m´s privilegios tiene. Este puede
o
a
a˜adir habitaciones, modificar precios y mantener todo el sistema de ofertas. Creando
n
nuevas ofertas, modific´ndolas, public´ndolas o d´ndolas de baja. Este apartado es muy
a
a
a
delicado debido a las relaciones de incompatibilidad entre ofertas y a las reglas que estas
utilizan para saber si se pueden aplicar en determinados contextos.

9. 9
Lista de palabras clave:
Aplicaci´n Web, Java, J2EE, MVC, Struts, Apache Tomcat, MySQL, HTML, XML,
o
CSS, JSP, JSPX, JSTL, Tiles, JDBC, Data Access Object (DAO), Value Object (VO),
Hotel, Reserva, Facturaci´n, Ofertas, Reglas, Incompatibilidades.
o

11. Agradecimientos1
A D. Carlos Alberto Pan Berm´dez (Profesor de la Facultad de Inform´tica, Universidad
u
a
de A Coru˜a), por la orientaci´n durante la realizaci´n del proyecto, as´ como su ayuda a la
n
o
o
ı
hora de resolver problemas puntuales durante el dise˜o e implementaci´n de la aplicaci´n.
n
o
o
A D˜a. Mar´ Luisa Carpente Rodr´
n
ıa
ıguez (Profesor de la Facultad de Inform´tica, Unia
versidad de A Coru˜a), por su ayuda a la hora de resolver de forma pr´ctica el grafo de
n
a
incompatibilidades entre las ofertas.
1
En orden alfab´tico
e
11

13. ´
Indice general
Introducci´n
o
XIII
1. Herramientas y tecnolog´ utilizadas
ıas
1
1.1. Herramientas y tecnolog´ para el Dise˜o . . . . . . . . . . . . . . . . . . .
ıas
n
1
1.2. Herramientas y tecnolog´ para la Implementaci´n . . . . . . . . . . . . . .
ıas
o
2
1.3. Herramientas y tecnolog´ para la Documentaci´n . . . . . . . . . . . . . . 10
ıas
o
2. Estado actual de las tecnolog´ utilizadas
ıas
13
3. Estudio de viabilidad
17
4. Introducci´n al desarrollo realizado
o
21
4.1. El Proceso Unificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. El Proceso Unificado en este Proyecto . . . . . . . . . . . . . . . . . . . . . 24
5. Requisitos del Sistema
29
5.1. Introducci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
o
5.2. Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
i

14. ´
Indice general
ii
5.3.1. Gesti´n de Usuarios Web . . . . . . . . . . . . . . . . . . . . . . . . 34
o
5.3.2. Gesti´n de Reservas Web . . . . . . . . . . . . . . . . . . . . . . . . 40
o
5.3.3. Gesti´n de Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
o
5.3.4. Gesti´n de Reservas . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
o
5.3.5. Gesti´n de Habitaciones . . . . . . . . . . . . . . . . . . . . . . . . . 60
o
5.3.6. Gesti´n de Ofertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
o
5.4. Modelo de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.4.1. Gesti´n de Usuarios Web . . . . . . . . . . . . . . . . . . . . . . . . 78
o
5.4.2. Gesti´n de Reservas Web . . . . . . . . . . . . . . . . . . . . . . . . 79
o
5.4.3. Gesti´n de Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
o
5.4.4. Gesti´n de Reservas . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
o
5.4.5. Gesti´n de Habitaciones . . . . . . . . . . . . . . . . . . . . . . . . . 82
o
5.4.6. Gesti´n de Ofertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
o
6. Dise˜ o de la aplicaci´n
n
o
85
6.1. Arquitectura General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.2. Capa de la Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.2.1. Hojas de Estilo - CSS . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.2.2. P´ginas JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
a
6.2.3. ActionForms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2.4. Internacionalizaci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
o
6.2.5. ApplicationObjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.3. Capa del Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

15. ´
Indice general
iii
6.3.1. Patr´n Front Controller . . . . . . . . . . . . . . . . . . . . . . . . . 94
o
6.3.2. Patr´n Chain of Responsability . . . . . . . . . . . . . . . . . . . . . 96
o
6.3.3. Acciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.3.4. Clases de Utilidad y Soporte a Acciones . . . . . . . . . . . . . . . . 99
6.4. Arquitectura del Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.4.1. Persistencia de los Datos . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.4.2. Patrones Utilizados en el Modelo . . . . . . . . . . . . . . . . . . . . 111
6.4.3. Capa de Acceso a la Base de Datos . . . . . . . . . . . . . . . . . . . 117
6.4.4. Descripci´n de los Subsistemas . . . . . . . . . . . . . . . . . . . . . 131
o
6.4.5. Sistema de Soporte - Modelo de Ofertas . . . . . . . . . . . . . . . . 166
7. Implementaci´n
o
183
7.1. Detalles Espec´
ıficos de la Implementaci´n . . . . . . . . . . . . . . . . . . . 183
o
7.2. Implementaci´n de las Base de Datos . . . . . . . . . . . . . . . . . . . . . . 185
o
7.2.1. Implementaci´n de la Base de Datos General . . . . . . . . . . . . . 185
o
7.2.2. Implementaci´n de la Base de Datos de Ofertas . . . . . . . . . . . . 190
o
7.3. Implementaciones del Sistema de Ofertas
. . . . . . . . . . . . . . . . . . . 192
7.4. Software Necesario para Desplegar la Aplicaci´n . . . . . . . . . . . . . . . 204
o
7.4.1. Instalaci´n y Configuraci´n del Software Necesario . . . . . . . . . . 204
o
o
7.5. Organizaci´n de los Directorios del Proyecto . . . . . . . . . . . . . . . . . . 208
o
7.6. Instrucciones de Compilaci´n y Despliegue . . . . . . . . . . . . . . . . . . . 209
o
8. Pruebas
211

16. ´
Indice general
iv
9. Planificaci´n y Evaluaci´n de Costes
o
o
213
10.Conclusiones y Futuras L´
ıneas de Trabajo
217
A. Manuales para la Utilizaci´n de la Aplicaci´n
o
o
221
A.1. Manual Com´n a Todos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
u
A.2. Manual Espec´
ıfico para el Usuario . . . . . . . . . . . . . . . . . . . . . . . 225
A.3. Manual Espec´
ıfico para el Recepcionista . . . . . . . . . . . . . . . . . . . . 231
A.4. Manual Espec´
ıfico para el Administrador
B. Licencia del Proyecto - GPLv3
. . . . . . . . . . . . . . . . . . . 239
251
B.1. General Public License (Version 3) . . . . . . . . . . . . . . . . . . . . . . . 251

17. ´
Indice de figuras
4.1. Gr´fico del Proceso Unificado . . . . . . . . . . . . . . . . . . . . . . . . . . 22
a
5.1. CU: Gesti´n de Usuarios Web . . . . . . . . . . . . . . . . . . . . . . . . . . 78
o
5.2. CU: Gesti´n de Reservas Web . . . . . . . . . . . . . . . . . . . . . . . . . . 79
o
5.3. CU: Gesti´n de Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
o
5.4. CU: Gesti´n de Reservas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
o
5.5. CU: Gesti´n de Habitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 82
o
5.6. CU: Gesti´n de Ofertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
o
6.1. MVC - Arquitectura General Del Sistema . . . . . . . . . . . . . . . . . . . 86
6.2. Capa Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.3. Plantilla Ventana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.4. Resultado Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.5. Patr´n Front Controller General . . . . . . . . . . . . . . . . . . . . . . . . 95
o
6.6. Paquetes - Distribucion de Acciones . . . . . . . . . . . . . . . . . . . . . . 99
6.7. Diagrama Aplicaci´n de Front Controller
o
. . . . . . . . . . . . . . . . . . . 100
6.8. Diagrama Entidad Relaci´n - General . . . . . . . . . . . . . . . . . . . . . 107
o
v

18. ´
Indice de figuras
vi
6.9. Modelo Relacional - General . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.10. Diagrama Entidad Relaci´n - Ofertas . . . . . . . . . . . . . . . . . . . . . . 110
o
6.11. Modelo Relacional - Ofertas . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.12. Diagrama de Value Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.13. Diagrama de Data Access Object . . . . . . . . . . . . . . . . . . . . . . . . 113
6.14. Diagrama de Data Access Object Utilizado . . . . . . . . . . . . . . . . . . 114
6.15. Diagrama de Session Facade y Business Delegate . . . . . . . . . . . . . . . 116
6.16. Diagrama del Procesador de Acciones . . . . . . . . . . . . . . . . . . . . . 117
6.17. Estructura de los paquetes DAO y VO . . . . . . . . . . . . . . . . . . . . . 118
6.18. Diagrama General de los DAO . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.19. Diagrama del Paquete ’persona’ . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.20. Diagrama del Paquete ’tipohabitacion’ . . . . . . . . . . . . . . . . . . . . . 120
6.21. Diagrama del Paquete ’habitacion’ . . . . . . . . . . . . . . . . . . . . . . . 121
6.22. Diagrama del Paquete ’esdetipo’ . . . . . . . . . . . . . . . . . . . . . . . . 122
6.23. Diagrama del Paquete ’incidencia’ . . . . . . . . . . . . . . . . . . . . . . . 123
6.24. Diagrama del Paquete ’lineadereserva’ . . . . . . . . . . . . . . . . . . . . . 124
6.25. Diagrama del Paquete ’reserva’ . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.26. Diagrama del Paquete ’factura’ . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.27. Diagrama del Paquete ’tipooferta’ . . . . . . . . . . . . . . . . . . . . . . . 127
6.28. Diagrama del Paquete ’oferta’ . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.29. Diagrama del Paquete ’aplicablea’ . . . . . . . . . . . . . . . . . . . . . . . 129
6.30. Diagrama del Paquete ’incompatiblecon’ . . . . . . . . . . . . . . . . . . . . 130

19. ´
Indice de figuras
vii
6.31. Diagrama Simple de Gesti´n de Usuarios
o
. . . . . . . . . . . . . . . . . . . 132
6.32. Actions y Exceptions de Gesti´n de Usuarios . . . . . . . . . . . . . . . . . 132
o
6.33. Diagrama Simple de Gesti´n de Clientes . . . . . . . . . . . . . . . . . . . . 135
o
6.34. Actions y Exceptions de Gesti´n de Clientes . . . . . . . . . . . . . . . . . . 136
o
6.35. Diagrama Simple de Gesti´n de Reservas
o
. . . . . . . . . . . . . . . . . . . 139
6.36. Actions y Exceptions de Gesti´n de Reservas . . . . . . . . . . . . . . . . . 140
o
6.37. Diagrama Simple de Gesti´n de Habitaciones . . . . . . . . . . . . . . . . . 145
o
6.38. Actions de Gesti´n de Habitaciones . . . . . . . . . . . . . . . . . . . . . . . 146
o
6.39. Diagrama Simple de Gesti´n de Tipos de Ofertas . . . . . . . . . . . . . . . 151
o
6.40. Actions de Gesti´n de Tipos de Ofertas . . . . . . . . . . . . . . . . . . . . 152
o
6.41. Diagrama Simple de Gesti´n de Ofertas . . . . . . . . . . . . . . . . . . . . 156
o
6.42. Actions de Gesti´n de Ofertas . . . . . . . . . . . . . . . . . . . . . . . . . . 157
o
6.43. Diagrama de la Interfaz Ofertable . . . . . . . . . . . . . . . . . . . . . . . . 160
6.44. Diagrama Simple de Gesti´n de Facturas . . . . . . . . . . . . . . . . . . . . 162
o
6.45. Actions y Exceptions de Gesti´n de Facturas . . . . . . . . . . . . . . . . . 163
o
6.46. Diagrama del Sistema de Reglas
. . . . . . . . . . . . . . . . . . . . . . . . 173
6.47. Diagrama de clase BestSetOfOffers . . . . . . . . . . . . . . . . . . . . . . . 176
6.48. Diagrama de las Clases Calculadoras . . . . . . . . . . . . . . . . . . . . . . 178
6.49. Diagrama Simple del Sistema de Ofertas . . . . . . . . . . . . . . . . . . . . 181
6.50. Diagrama Secuencia de la Acci´n de Calcular . . . . . . . . . . . . . . . . . 182
o
9.1. Planificaci´n - Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . 215
o
10.1. Gesti´n de Reservas de Otra Aplicaci´n . . . . . . . . . . . . . . . . . . . . 218
o
o

20. ´
Indice de figuras
viii
A.1. P´gina Principal del Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
a
A.2. P´gina Registro de Nuevo Usuario . . . . . . . . . . . . . . . . . . . . . . . 222
a
A.3. P´gina Autentificaci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
a
o
A.4. P´gina Principal del Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 225
a
A.5. P´gina de Aviso al Darse de Baja . . . . . . . . . . . . . . . . . . . . . . . . 226
a
A.6. P´gina para Realizar una Nueva Reserva . . . . . . . . . . . . . . . . . . . . 227
a
A.7. P´gina para Listar las Reservas . . . . . . . . . . . . . . . . . . . . . . . . . 228
a
A.8. P´gina para Modificar una Reserva . . . . . . . . . . . . . . . . . . . . . . . 229
a
A.9. P´gina para Mostrar el Borrador de una Factura . . . . . . . . . . . . . . . 229
a
A.10.P´gina para Mostrar una Factura Pagada . . . . . . . . . . . . . . . . . . . 230
a
A.11.P´gina Principal del Recepcionista . . . . . . . . . . . . . . . . . . . . . . . 231
a
A.12.P´gina para Listar las Habitaciones para el Recpecionista . . . . . . . . . . 232
a
A.13.P´gina para Mostrar los Datos de un Tipo de Habitaci´n . . . . . . . . . . 233
a
o
A.14.P´gina para Dar de Alta un Nuevo Cliente . . . . . . . . . . . . . . . . . . 234
a
A.15.P´gina para Buscar Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
a
A.16.P´gina para Listar los Clientes Buscados . . . . . . . . . . . . . . . . . . . . 235
a
A.17.P´gina Principal del Recepcionista Despu´s de Seleccionar Cliente . . . . . 236
a
e
A.18.P´gina Principal del Administrador . . . . . . . . . . . . . . . . . . . . . . . 239
a
A.19.P´gina para Crear una Nueva Oferta . . . . . . . . . . . . . . . . . . . . . . 240
a
A.20.P´gina para Crear una Nueva Oferta (Rellenada) . . . . . . . . . . . . . . . 241
a
A.21.P´gina para Crear un Nuevo Tipo de Oferta . . . . . . . . . . . . . . . . . . 243
a
A.22.P´gina para Listar las Ofertas . . . . . . . . . . . . . . . . . . . . . . . . . . 244
a

21. ´
Indice de figuras
ix
A.23.P´gina para Realizar Operaciones con las Ofertas . . . . . . . . . . . . . . . 244
a
A.24.P´gina para Realizar Operaciones con los Tipos de Ofertas . . . . . . . . . 245
a
A.25.P´gina para Dar de Alta una Habitaci´n . . . . . . . . . . . . . . . . . . . . 246
a
o
A.26.P´gina para Crear un Nuevo Tipo de Habitaci´n . . . . . . . . . . . . . . . 246
a
o
A.27.P´gina para Listar las Habitaciones para el Administrador . . . . . . . . . . 247
a
A.28.P´gina para Consultar/Modificar los Datos de una Habitaci´n
a
o
. . . . . . . 248
A.29.P´gina para Consultar/Modificar los Datos de un Tipo de Habitaci´n . . . 248
a
o
A.30.P´gina para Listar las Incidencias de una Habitaci´n . . . . . . . . . . . . . 249
a
o
A.31.P´gina para Registrar una Incidencia de una Habitaci´n . . . . . . . . . . . 250
a
o

23. ´
Indice de cuadros
3.1. Tabla de costes para estudio de viabilidad . . . . . . . . . . . . . . . . . . . 18
9.1. Planificaci´n - Tabla de Tareas . . . . . . . . . . . . . . . . . . . . . . . . . 214
o
xi

25. Introducci´n
o
Determinaci´n de la situaci´n actual
o
o
En la actualidad el turismo es una fuente indiscutible de ingresos para muchas zonas, e
Internet llega casi a todos los rincones del mundo, por eso es una de las mejores formas de
dar a conocer negocios de todo tipo. Es especialmente util a la hora de ofrecer servicios
´
de alojamiento, y ocio entre otros.
Cada d´ m´s personas planean sus vacaciones a trav´s de Internet, por lo que no s´lo
ıa a
e
o
es bueno dar a conocer los servicios que se prestan, sin´ tambi´n dar la oportunidad de
o
e
poder contratar esos servicios est´ donde est´ el cliente.
e
e
Hoy en d´ muchas peque˜as empresas hoteleras a´n siguen registrando sus reservas
ıa
n
u
manualmente en un libro para tal efecto. Estas se producen normalmente por tel´fono,
e
no ofreciendo pr´cticamente ninguna garant´ de que la reserva vaya a ser pagada, los
a
ıa
responsables del establecimiento dieron su palabra al cliente que llam´ y esa estancia
o
puede que quede sin ocupar, con las posibles p´rdidas que ello pueda conllevar. Adem´s
e
a
normalmente no tienen un sitio web que puedan usar para promocionarse, lo que implica
que s´lo se pueden dar a conocer a trav´s de anuncios o similares y esto supone un gasto
o
e
adicional para la empresa.
Las grandes firmas de hoteles y multinacionales no tienen todos esos problemas. La
mayor´ permite que se reserven habitaciones a trav´s de su sitio web y pide que se abone
ıa
e
el pago de dicha reserva, as´ se aseguran que esta se va llevar a cabo. Las que no permiten
ı
xiii

26. xiv
hacer el pago en el momento de la realizaci´n de la reserva tampoco pierden demasiado,
o
ya que la p´rdida de una estancia es compensada por la multitud que se hacen efectivas
e
debido a sus vol´menes de negocio. Estas empresas tampoco se tienen que preocupar
u
demasiado por la publicidad, ya que pueden permitirse hacer campa˜as publicitarias por
n
todo el mundo, y todas tienen sus sitios web actualizados.
Alcance y objetivos
La forma tradicional de gestionar un hotel, es tediosa y a veces incluso dif´ de llevar a
ıcil
cabo si el volumen de trabajo del hotel es elevado o si hay muchas habitaciones y servicios
de los cuales hay que mantener actualizados sus datos.
Este proyecto surge para ayudar a simplificar y facilitar las tareas propias de la gesti´n
o
de un hotel, comenzando por desarrollar un sistema a trav´s del cual se puedan realizar
e
reservas y generar facturas, as´ como gestionar las habitaciones, etc. Para esto se desarrolla
ı
una Aplicaci´n Web, que permitir´ hacer reservas on-line del mismo modo que tambi´n
o
a
e
se podr´ gestionar el hotel en su totalidad, f´cil y c´modamente.
a
a
o
Se pretende entre otras cosas que este proyecto sea f´cilmente ampliable, de forma que,
a
a medida que vayan surgiendo necesidades distintas dentro de la gesti´n de un hotel, se
o
pueda dar una soluci´n f´cil, r´pida y lo m´s elegante posible. Adem´s se desarrolla de
o a
a
a
a
forma que se pueda integrar de forma c´moda la gesti´n del hotel y la gesti´n del sitio
o
o
o
web, ya que actualmente en el ´mbito de los hoteles hay la necesidad de darlos a conocer
a
a un mayor p´blico para ampliar el mercado.
u
Para comenzar se definen los usuarios que van a interactuar con la aplicaci´n. El Cliente,
o
el Recepcionista y el Administrador ser´n los usuarios principales, pero no los unicos, ya
a
´
que la aplicaci´n necesitar´ tambi´n tener como actor de soporte alguna entidad financiera
o
a
e
contra la cual se realizar´n los pagos de las reservas.
a

27. xv
Cualquier usuario que entre en el portal del hotel puede consultar nuevas noticia acerca
del hotel, la ofertas que actualmente ofrece el establecimiento y diversos datos referentes
al hotel: ubicaci´n, fotograf´ etc.
o
ıas,
El usuario tendr´ la posibilidad de crearse una cuenta en el portal web del hotel, con la
a
cual podr´ realizar distintas acciones. El usuario que est´ registrado podr´ modificar sus
a
e
a
datos personales en cualquier momento o darse de baja cuando lo desee. Tambi´n tendr´ la
e
a
posibilidad de realizar tantas reservas como quiera y luego podr´ pasar a administrarlas,
a
pudiendo as´ cancelar o modificar las reservas efectuadas, o comprobar la factura para ver
ı
cu´nto tendr´ que pagar. Esta factura se calcula de forma din´mica aplicando el conjunto
a
ıa
a
de ofertas que descuenten la mayor cantidad de dinero a la factura. Una vez vista la fatura
podr´ pagarla en ese preciso momento, a partir del cual la reserva quedar´ hecha.
a
a
A partir del momento en el que un usuario registrado paga su primera reserva, ya se
puede considerar como cliente del hotel.
Por otro lado el recepcionista del hotel puede realizar tambi´n reservas para un cliente.
e
En primer lugar se le da la opci´n de actualizar sus datos personales. Tambi´n puede
o
e
buscar a un cliente en la base de datos por varios criterios, nombre, apellidos, etc. Si el
cliente no est´ registrado, se le da la oportunidad de darlo de alta en el sistema, y si lo
a
est´ se puede tambi´n modificar su perfil. A continuaci´n se le permite realizar la reserva
a
e
o
que el cliente le pueda pedir. Y cuando el cliente pague la reserva el empleado de recepci´n
o
del hotel podr´ marcar la factura como pagada en la aplicaci´n.
a
o
Asimismo, puede consultar las reservas de un cliente, las habitaciones, precios y otras
consultas generales acerca del hotel.
El administrador de la aplicaci´n y del hotel tiene como actividades principales en
o
el sistema gestionar las distintas partes del mismo. Puede crear habitaciones, consultar
y modificar sus datos, tambi´n tiene la posibilidad de hacer lo mismo con los tipos de
e
habitaciones que son los que en realidad definen los precios y condiciones que tienen las
mismas.

28. xvi
Otra de las operaciones que puede realizar el administrador es la creaci´n y publicaci´n
o
o
de ofertas. Cuando el administrador crea una oferta, ademas de cubrir de qu´ fecha a
e
qu´ fecha la oferta ser´ aplicable, tambi´n debe especificar la regla que se debe cumplir
e
a
e
con respecto al contexto en el cual se har´ efectiva la oferta, de esta forma se podr´ definir
a
a
m´s concretamente los par´metros que se deben de cumplir para que la oferta se pueda
a
a
aplicar. Mediante el uso de reglas se podr´ definir, por ejemplo, que una oferta s´lo se
a
o
pueda aplicar a los clientes de un determinado pa´ que hayan nacido antes de una fecha
ıs
determinada y que paguen la reserva antes de un d´ fijado.
ıa
Estas reglas podr´n definirse a trav´s del lenguaje natural, siguiendo simplemente unas
a
e
condiciones en la escritura de las mismas, como que las diferentes partes en las que se divide
una regla est´n separadas utilizando unos caracteres especiales. Por ejemplo, una posible
e
regla para decir que solo se puede aplicar a personas de Espa˜a que nacieran antes del 20 de
n
Octubre de 1980 ser´ la siguiente: “PersonFrom:Espa˜a&&PersonBornBefore:20,10,1980”
ıa
n
El sistema de reglas desarrollado es altamente configurable de forma que se pueden
a˜adir nuevas reglas al sistema sin tener que alterar nada de lo que ya est´ hecho. As´ de
n
a
ı
este modo se podr´ definir en caso necesario, condiciones m´s elaboradas, como por
ıan
a
ejemplo, que s´lo se pudiese aplicar a aquellas personas que desde la apertura del hotel
o
hayan gastado en ´l m´s de una cantidad de dinero.
e a
La internacionalizaci´n de la aplicaci´n es algo fundamental en este caso ya que al
o
o
tratarse de un hotel es imprescindible especificarlo todo en varios idiomas y as´ llegar
ı
mejor a clientes extranjeros. La aplicaci´n web tendr´ traducci´nes a Espa˜ol, Gallego e
o
a
o
n
Ingl´s, y ser´ muy sencillo a˜adir nuevas traducciones en un futuro, de igual forma tambi´n
e
a
n
e
estar´n internacionalizadas las fechas y los n´meros, pero se dejan sin internacionalizar
a
u
los precios ya que todas las transacciones se har´n y se calcular´n en Euros.
a
a

29. xvii
Estructura de la memoria
Esta memoria se ha estructurado en 10 cap´
ıtulos en los cuales se explican los diferentes
temas a tener en cuenta en la realizaci´n de un proyecto software.
o
Cap´
ıtulo 1.
En este cap´
ıtulo se detallan de forma breve todas las tecnolog´ empleadas
ıas
en el desarrollo y documentaci´n del proyecto, desde las herramientas utilizadas para
o
realizar el c´digo fuente de la aplicaci´n, hasta las tecnolog´ empleadas para que esta
o
o
ıas
funcionase correctamente en el momento del despliege final de la misma.
Cap´
ıtulo 2.
En este apartado se explica el estado de las tecnolog´ utilizadas en la
ıas
actualidad, as´ como la diferencia con otras tecnolog´ disponibles en el mercado, y el
ı
ıas
porqu´ se utilizaron unas y no otras. Para esta eleci´n estuvo muy presente la idea de que
e
o
la aplicaci´n final deber´ poder licenciarse como software libre por lo que las licencias de
o
ıa
algunas tecnolog´ impidieron su uso.
ıas
Cap´
ıtulo 3.
Se estudia en este cap´
ıtulo la viabilidad del desarrollo de la aplicaci´n que
o
se realizar´. En este estudio se tiene en cuenta desde el tiempo estimado que se emplear´ en
a
a
su desarrollo como el coste este conllevar´, adem´s de otras cuestiones como la posible
a
a
comercializaci´n del producto una vez terminado.
o
Cap´
ıtulo 4.
En este cap´
ıtulo se indica la metodolog´ que se sigue en el desarrollo del
ıa
proyecto. En este caso se detallan las caracter´
ısticas del Proceso Unificado y sus diferentes
fases en el ciclo de desarrollo de la aplicaci´n.
o
Adem´s se explica detalladamente lo que se hizo en cada una de estas fases en el proyecto,
a
indicando exactamente en qu´ momento, iteraci´n, de la fase del Proceso Unificado se
e
o
realiz´.
o

30. xviii
Cap´
ıtulo 5.
Se detallan en este cap´
ıtulo todos los requisitos que regir´n el desarrollo
a
del proyecto. En un primer lugar se analizar´n textualmente y de forma general las funa
cionalidades que deber´ contemplar la aplicaci´n, que luego ser´n detalladas exactamente
a
o
a
en un modelo de casos de uso.
Este modelo de casos de uso se explicar´ dividi´ndolo en subconjuntos de casos de uso
a
e
relacionados, y dentro de cada subconjunto se detallar´ cada uno de los casos de uso por
a
separado y se mostrar´ un diagrama de casos de uso para ver como se relacionan estos
a
con los actores que interactuar´n con la aplicaci´n.
a
o
Cap´
ıtulo 6.
Este cap´
ıtulo junto con el anterior son los dos cap´
ıtulos fundamentales en
el desarrollo del proyecto, ya que en este se detalla todo el dise˜o del sistema final.
n
Se explican en este apartado las diferentes capas en las que se divide el sistema, b´sia
camente se describe la arquitectura Modelo-Vista-Controlador utilizada. Despu´s de una
e
introducci´n al dise˜o realizado se detalla el funcionamiento y el dise˜o de cada una de
o
n
n
las capas por separado.
En la capa modelo es donde se realiza especial incapi´ ya que es donde estar´ situae
a
da toda la l´gica de negocio del sistema, donde realmente se implementar´n los casos de
o
a
uso especificados en el modelo de casos de uso. Para desglosar esta capa, se realiza una
separaci´n en subsistemas, se puede identificar claramente cada uno de ellos con un subo
conjunto de casos de uso y a continuaci´n se explica el dise˜o utilizado en estos subsistemas
o
n
acompa˜andolos en todo momento de los diagramas UML correspondientes.
n´
Para terminar, pero ni mucho menos importante, se explica en detalle el sistema de
soporte de las ofertas realizado para resolver, de forma aislada del resto del modelo, las
cuestiones referente al comportamiento de las ofertas. Para detallar este comportamiento
se comienza con una explicaci´n textual de c´mo deben operar e interacturar entre ellas y a
o
o
continuaci´n se hace un an´lisis m´s formal apoy´ndose en un grafo de incompatibilidades
o
a
a
a
y su resoluci´n, realizado expresamente para solventar las cuestiones m´s complejas del
o
a

31. xix
sistema. Por otro lado se explica tambi´n el funcionamiento del sistema de reglas y el
e
lenguaje utilizado para definirlas, siendo las reglas las que rigen la aplicabilidad de las
ofertas dependiendo del contexto.
Cap´
ıtulo 7.
En este apartado se describe como se ha realizado la implementaci´n de
o
la aplicaci´n, as´ como el software utilizado para su despliegue y configuraci´n. Adem´s
o
ı
o
a
tambi´n se expondr´n problemas surgidos durante la implementaci´n del proyecto y sus
e
a
o
soluciones.
Cap´
ıtulo 8.
Este cap´
ıtulo de la memoria describe las diferentes pruebas realizadas para
probar el correcto funcionamiento de la aplicaci´n. Entre las pruebas hechas destacan las
o
pruebas de unidad, aunque no menos importantes son las pruebas de funcionalidad para
chequear que la aplicaci´n cumpliese con todos los requisitos de funcionalidad requeridos
o
al inicio del proyecto.
Cap´
ıtulo 9.
En este cap´
ıtulo se establece la planificaci´n de tiempo y costes para la
o
realizaci´n del proyecto, ilustrado todo con un diagrama de Gantt.
o
Cap´
ıtulo 10.
Este es el cap´
ıtulo d´nde se comentan las impresiones acerca del proyecto,
o
as´ como las conclusiones sobre los conocimientos adquiridos y futuras posibles modificaı
ciones sobre este proyecto.

33. Cap´
ıtulo 1
Herramientas y tecnolog´
ıas
utilizadas
Para la realizaci´n de este proyecto se utilizaron distintas herramientas y tecnolog´
o
ıas,
desde el dise˜o y la implementaci´n, hasta la documentaci´n del sistema.
n
o
o
1.1.
Herramientas y tecnolog´ para el Dise˜ o
ıas
n
ArgoUML
Es una aplicaci´n para realizar diagramas UML escrita en Java y publicada
o
bajo la Licencia BSD open source. Dado que es una aplicaci´n Java, est´ disponible en
o
a
cualquier plataforma soportada por Java. Aunque la interfaz gr´fica no es lo mejor del
a
mercado, la potencia para realizar diagramas y exportarlo a la mayor´ de los formatos
ıa
que se puedan querer, hace de esta aplicaci´n una herramienta de gran ayuda a la hora de
o
realizar los diagramas para desarrollar una aplicaci´n.
o
Adem´s esta aplicaci´n permite realizar ingenier´ directa de diagramas UML a c´digo,
a
o
ıa
o
pero no s´lo a c´digo Java, sin´ tambi´n a otros lenguajes como C# o PHP. Tambi´n
o
o
o
e
e
permite la realizaci´n de ingenier´ inversa, generando un modelo a partir de c´digo fuente.
o
ıa
o
Esto es muy util a la hora de documentar un proyecto, ya que de esta forma se asegura
´
1

34. 1.2. Herramientas y tecnolog´ para la Implementaci´n
ıas
o
2
de que no se olvida de nada, especialmente cuando se crea un modelo de clases detallado,
donde muy a menudo se puede olvidar de alg´n m´todo, atributo, etc.
u
e
DIA
Es una aplicaci´n gr´fica de prop´sito general para la creaci´n de diagramas, desao
a
o
o
rrollada como parte del proyecto GNOME. Est´ concebido de forma modular, con difea
rentes paquetes de formas para diferentes necesidades.
Dia est´ dise˜ado como un sustituto de la aplicaci´n comercial Visio de Microsoft. Se
a
n
o
puede utilizar para dibujar diferentes tipos de diagramas. Actualmente se incluyen diagramas entidad-relaci´n, diagramas UML, diagramas de flujo, diagramas de redes, diagramas
o
de circuitos el´ctricos, etc. Nuevas formas pueden ser f´cilmente agregadas, dibuj´ndolas
e
a
a
con un subconjunto de SVG e incluy´ndolas en un archivo XML.
e
El formato para leer y almacenar gr´ficos es XML (comprimido con gzip, para ahorrar
a
espacio). Pero lo interesante, al igual que con ArgoUML es que puede producir salida en
m´ltiples formatos como: EPS, SVG, PNG, etc. Y al igual que ArgoUML, Dia, gracias al
u
paquete ‘dia2code‘, puede generar el esqueleto del c´digo a escribir a partir de un diagrama
o
UML.
1.2.
Herramientas y tecnolog´ para la Implementaci´n
ıas
o
Java EE Java Platform, Enterprise Edition, tambi´n conocida como J2EE es un cone
junto de especificaciones Java definidas para la construcci´n de aplicaciones empresariales.
o
Estas aplicaciones empresariales est´n estructuradas en diferentes capas, donde cada una
a
de ellas se comporta como un componente software totalmente independiente y que puede
interactuar con otro componente. Una de las separaciones en capas que se puede ver m´s
a
frecuentemente es la de modelo, vista y controlador.
El modelo es el que define la l´gica de negocio de la aplicaci´n, es totalmente indepeno
o
diente de la vista y del controlador. En ´l residen los objetos de la aplicaci´n incluyendo
e
o
sus datos y comportamiento.

35. 1.2. Herramientas y tecnolog´ para la Implementaci´n
ıas
o
3
Por otro lado la vista es la encargada de la representaci´n de los datos en una interfaz
o
de usuario para interactuar con este. Esta capa tambi´n es independiente de las dem´s
e
a
aunque necesita conocer al modelo que es donde tiene que recoger los datos a representar.
Por su parte el controlador es el encargado de conectar el modelo y la vista. Este recoge
los eventos producidos por el usuario sobre la capa vista e invoca a las acciones pertinentes
de la capa del modelo.
JDBC
Java Database Connectivity. Es un API que permite la ejecuci´n de operaciones
o
sobre bases de datos desde Java. Con este API se define una interfaz que permite interactuar con gran variedad de bases de datos relacionales. Este API forma parte de la edici´n
o
est´ndar de java (J2SE) y tambi´n de la edici´n empresarial (J2EE).
a
e
o
Los drivers JDBC son implementaciones particulares del API de JDBC para una base
de datos relacional particular, y facilitan mucho el acceso a las bases de datos. En el caso
de este proyecto se utiliza un driver JDBC para MySQL.
JUnit
Es un ‘framework‘, conjunto de clases, que permite probar el funcionamiento de
clases Java de manera controlada. Probando el funcionamiento de cada uno de los m´todos
e
de la clase para ver que se comporta como se espera. Es decir, en funci´n de ciertos valores
o
de entrada se eval´an y luego se comprueba que la respuesta es la esperada, si la clase
u
cumple con la especificaci´n, entonces JUnit devolver´ que el m´todo de la clase pas´ exio
a
e
o
tosamente la prueba, en caso de que el valor esperado sea diferente al que devolvi´ el
o
m´todo durante la ejecuci´n, JUnit devolver´ un fallo en el m´todo correspondiente.
e
o
a
e
A trav´s de JUnit tambi´n se puede controlar que despu´s de hacer cambios en la
e
e
e
implementaci´n de una clase, se sigan cumpliendo las especificaciones.
o
El propio framework incluye formas de ver los resultados que pueden ser en modo texto
o gr´fico. Y en la actualidad las herramientas de desarrollo como NetBeans y Eclipse
a
cuentan con plugins que permiten que la generaci´n de las plantillas necesarias para la
o
creaci´n de las pruebas de una clase Java se realice de manera autom´tica, facilitando al
o
a

36. 1.2. Herramientas y tecnolog´ para la Implementaci´n
ıas
o
4
programador enfocarse en la prueba y el resultado esperado, y dejando a la herramienta
la creaci´n de las clases que permiten coordinar las pruebas.
o
JSP Java Server Pages, es una tecnolog´ Java que permite generar contenido din´mico
ıa
a
para web, en forma de documentos HTML, XML o de otro tipo. Estos documentos deben
de estar contenidos en un servidor web que soporte esta tecnolog´ y se compilan a clases
ıa,
java la primera vez que se accede a cada p´gina.
a
Las JSP’s permiten la utilizaci´n de c´digo Java mediante scripts. Adem´s, es posible
o
o
a
utilizar algunas acciones JSP predefinidas mediante etiquetas. Estas etiquetas pueden
ser enriquecidas mediante la utilizaci´n de librer´ de etiquetas externas, como las que
o
ıas
proporciona el framework struts, e incluso se pueden constru´ etiquetas personalizadas.
ır
JSTL
JavaServer Pages Standard Tag Library, es un componente de Java EE. Extiende
las JavaServer Pages (JSP) proporcionando librer´ de etiquetas con utilidades ampliaıas
mente utilizadas en el desarrollo de p´ginas web din´micas.
a
a
Las diferentes librer´ de JSTL permiten realizar tareas comunes en el desarrollo de
ıas
la mayor´ de las aplicaciones web din´micas, estas tareas son: iteradores para recorrer
ıa
a
colecciones de elementos y poder mostrarlos, etiquetas condicionales por si hay que escoger
entre varias opciones, y unas de las m´s utilizadas, las etiquetas de internacionalizaci´n,
a
o
que facilitan en gran medida el proceso de cambiar f´cilmente el idioma de la aplicaci´n
a
o
as´ como el formateo de datos para los diferentes pa´
ı
ıses.
HTML
HyperText Markup Language, es el lenguaje de marcado m´s utilizado para
a
la construcci´n de p´ginas web. Es usado para describir la estructura y el contenido en
o
a
forma de texto, as´ como para complementar el texto con objetos tales como im´genes,
ı
a
tablas, etc. Este es el lenguaje de marcado que son capaces de interpretar los navegadores
web. La sintaxis de este lenguaje de marcado consiste en escribir ‘etiquetas‘ que estar´n
a
rodeadas por corchetes angulares, ‘<etiqueta>‘. HTML tambi´n puede describir, hasta
e

37. 1.2. Herramientas y tecnolog´ para la Implementaci´n
ıas
o
5
un cierto punto, la apariencia de un documento, y puede incluir un script que puede
afectar el comportamiento de navegadores web y otros procesadores de HTML. Aunque
normalmente, y lo m´s correcto es separar la apariencia y el comportamiento en diferentes
a
ficheros.
XML
EXtensible Markup Language, es un metalenguaje extensible de etiquetas desa-
rrollado por el World Wide Web Consortium (W3C). Es una simplificaci´n y adaptaci´n
o
o
del SGML y permite definir la gram´tica de lenguajes espec´
a
ıficos. Por lo tanto XML no es
realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes
necesidades. Algunos de estos lenguajes que usan XML para su definici´n son XHTML,
o
SVG, MathML.
XML no ha nacido s´lo para su aplicaci´n en Internet, sino que se propone como un
o
o
est´ndar para el intercambio de informaci´n estructurada entre diferentes plataformas. Se
a
o
puede usar en bases de datos, editores de texto, hojas de c´lculo y casi cualquier cosa
a
imaginable.
XML es una tecnolog´ sencilla que tiene a su alrededor otras que la complementan
ıa
y la hacen mucho m´s grande y con unas posibilidades mucho mayores. Tiene un papel
a
muy importante en la actualidad ya que permite la compatibilidad entre sistemas para
compartir la informaci´n de una manera segura, fiable y f´cil.
o
a
CSS Cascade Style Sheet, como su nombre indica son hojas de estilo, se utilizan para
definir la apariencia de una p´gina web. En el documento HTML simplemente hay que
a
indicar en cada etiqueta un identificador que servir´ para luego establecer su apariencia a
a
partir del CSS.
CSS es una herramienta muy potente, dado que permite hacer cambios radicales en la
apariencia de una p´gina sin tener que modificar en absoluto el c´digo fuente. Permite
a
o
realizar casi cualquier cosa imaginable, desde cambiar tama˜os, fuentes o colores, hasta la
n
posici´n y el comportamientdo de los distintos elementos de una p´gina.
o
a

38. 1.2. Herramientas y tecnolog´ para la Implementaci´n
ıas
o
6
Apache Struts Apache Struts es un framework gratuito de c´digo abierto para crear
o
aplicaciones web en Java de forma sencilla y r´pida.
a
Las aplicaciones web difieren de las p´ginas web convencionales en que las aplicaciones
a
web pueden crear una respuesta din´mica. Muchos sitios web ofrecen s´lo las p´ginas
a
o
a
est´ticas. Una aplicaci´n web puede interactuar con bases de datos o motores de la l´gica
a
o
o
de negocio para personalizar una respuesta.
En las aplicaciones basadas en JavaServer Pages, a veces se mezclan el c´digo de acceso
o
a base de datos con c´digo de dise˜o de la misma, y el c´digo de control de flujo. En
o
n
o
la pr´ctica, nos encontramos con que a menos que estas preocupaciones est´n separadas,
a
a
aplicaciones grandes son muy dif´
ıciles de mantener.
Una forma de separar las distintas partes de una aplicaci´n de software es utilizar una
o
arquitectura Modelo-Vista-Controlador (MVC). El modelo representa la empresa o de base
de datos de c´digo, la vista representa el c´digo de dise˜o de la p´gina, y el Contralor
o
o
n
a
representa el c´digo de la navegaci´n. La plataforma Struts est´ dise˜ada para ayudar a
o
o
a
n
los desarrolladores a crear aplicaciones web que utilizan una arquitectura MVC.
MySQL 5.0 Es un sistema de gesti´n de base de datos relacional, multihilo y multio
usuario con m´s de seis millones de instalaciones. Este sistema de gesti´n es uno de los m´s
a
o
a
utilizados, porque, a parte de tener una licencia GPL, libre y gratuita, es f´cil de utilizar
a
en proyectos peque˜os y actualmente es compatible con las tecnolog´ m´s importantes
n
ıas a
del mercado, las cuales proporcionan APIs para conectarse y realizar consultas contra la
base de datos.
MySQL AB, desde enero de 2008 una subsidiaria de Sun Microsystems y esta a su vez
de Oracle Corporation desde abril de 2009, desarrolla MySQL como software libre en un
esquema de licenciamiento dual.
Esto ultimo consiste en que por un lado se ofrece bajo la GNU GPL para cualquier
´
uso compatible con esta licencia, pero para aquellas empresas que quieran incorporarlo en

39. 1.2. Herramientas y tecnolog´ para la Implementaci´n
ıas
o
7
productos privativos deben comprar a la empresa una licencia espec´
ıfica que les permita
este uso. Est´ desarrollado en su mayor parte en ANSI C.
a
Al contrario de proyectos como Apache, donde el software es desarrollado por una comunidad p´blica y el copyright del c´digo est´ en poder del autor individual, MySQL es
u
o
a
propietario y est´ patrocinado por una empresa privada, que posee el copyright de la maa
yor parte del c´digo. Esto es lo que posibilita el esquema de licenciamiento anteriormente
o
mencionado. Adem´s de la venta de licencias privativas, la compa˜´ ofrece soporte y sera
nıa
vicios. Para sus operaciones contratan trabajadores alrededor del mundo que colaboran
v´ Internet.
ıa
Apache Tomcat
Apache Tomcat es una servidor web de c´digo abierto, que sirve como
o
contenedor de p´ginas web para las tecnolog´ Java Servlet y JavaServer Pages.
a
ıas
Apache Tomcat est´ desarrollado en un entorno abierto y participativo por la compa˜´
a
nıa
Apache y publicado bajo la licencia Apache Software. Est´ en continuo desarrollo y mantea
nimiento, y aunque hay diferentes productos no gratuitos que ofrecen m´s funcionalidades,
a
para una aplicaci´n sencilla, es suficiente para ejecutarla.
o
IDE Eclipse
Es un entorno de desarrollo integrado de c´digo abierto multiplataforma
o
para desarrollar lo que ´l llama ‘Aplicaciones de Cliente Enriquecido‘, opuesto a las aplie
caciones ‘Cliente-liviano‘ basadas en navegadores. Esta plataforma, t´
ıpicamente ha sido
usada para desarrollar entornos de desarrollo integrados (del ingl´s IDE), como el IDE de
e
Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega como
parte de Eclipse (y que son usados tambi´n para desarrollar el mismo Eclipse). Sin embare
go, tambi´n se puede usar para otros tipos de aplicaciones cliente, y para otros lenguajes
e
de programaci´n. Adem´s es un entorno que posibilita la utilizaci´n de plugins por lo que
o
a
o
se pueden a˜adir los plugins que se necesiten y ampliar de esa forma las funcionalidades
n
que se estimen oportunas.

40. 1.2. Herramientas y tecnolog´ para la Implementaci´n
ıas
o
8
Eclipse es tambi´n una comunidad de usuarios, extendiendo constantemente las ´reas
e
a
de aplicaci´n cubiertas. Un ejemplo es el recientemente creado Eclipse Modeling Project,
o
cubriendo casi todas las ´reas de la Ingenier´ dirigida por el modelo.
a
ıa
Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para VisualAge. Eclipse sigue siendo desarrollado por la fundaci´n Eclipse,
o
una organizaci´n independiente sin ´nimo de lucro que fomenta una comunidad de c´digo
o
a
o
abierto y un conjunto de productos complementarios, capacidades y servicios.
PhpMyAdmin
Es una herramienta de software libre escrito en PHP hecho con la in-
tenci´n de manejar la administraci´n de MySQL en la World Wide Web. PhpMyAdmin
o
o
es compatible con una amplia gama de operaciones con MySQL. Las operaciones m´s
a
frecuentes son el apoyo de la interfaz de usuario (gesti´n de bases de datos, tablas, camo
pos, relaciones, ´
ındices, usuarios, permisos, etc) mientras que el usuario todav´ tiene la
ıa
capacidad de ejecutar directamente cualquier sentencia SQL.
Configurar PhpMyAdmin es muy sencillo y facilita mucho la tarea de administrar las
distintas bases de datos que necesita una aplicaci´n. As´ como la de realizar las diferentes
o
ı
consultas que se puedan querer hacer.
Mozilla Firefox
Es un navegador de Internet libre y de c´digo abierto descendiente de
o
Mozilla Application Suite, desarrollado por la Corporaci´n Mozilla, la Fundaci´n Mozilla
o
o
y un gran n´mero de voluntarios externos.
u
Firefox es un navegador multiplataforma y est´ disponible en varias versiones de Mia
crosoft Windows, Mac OS X, GNU/Linux y algunos sistemas Unix. Su c´digo fuente es
o
software libre, publicado bajo una triple licencia GPL/LGPL/MPL.
Actualmente cuenta con un alto porcentaje del mercado de navegadores web, haciendo
as´ firme competencia al navegador Internet Explorer de Microsoft. Y cada a˜o este naı
n
vegador gana nuevos adeptos, gracias, entre otras cosas, al licenciamiento como software

41. 1.2. Herramientas y tecnolog´ para la Implementaci´n
ıas
o
9
libre y a que cuenta con un gran n´mero de personas que consiguen sacar parches para
u
errores puntuales en un tiempo r´cord gracias al eficaz sistema de reporte de errores.
e
Para visualizar p´ginas web, Firefox usa el motor de renderizado Gecko, que implementa
a
la mayor´ de los est´ndares web actuales adem´s de otras funciones, algunas de las cuales
ıa
a
a
est´n destinadas a anticipar probables adiciones a los est´ndares web.
a
a
Incluye navegaci´n por pesta˜as, corrector ortogr´fico, b´squeda progresiva, marcadores
o
n
a
u
din´micos, un administrador de descargas y un sistema de b´squeda integrado que utiliza
a
u
el motor de b´squeda que desee el usuario. Adem´s se pueden a˜adir funciones a trav´s
u
a
n
e
de complementos desarrolladas por terceros, muy util a la hora de comprobar aplicaciones
´
web o de realizar el dise˜o de la interfaz de usuario de estas.
n
Apache Maven 2 Maven 2 es una herramienta para la gesti´n de proyectos software que
o
proporciona soluciones a tareas comunes a todos los proyectos desde la compilaci´n inicial
o
hasta la distribuci´n e instalaci´n en los sistemas finales. Maven genera una estructura de
o
o
directorios y ficheros que sirve de estructura base. Esta estructura de directorios es est´ndar
a
en todos los proyectos lo que permite a los desarrolladores moverse entre proyectos con
mayor comodidad y familiaridad, algo muy importante a la hora de que otro desarrollador
mantenga una aplicaci´n, ya que siempre sabr´ donde puede encontrar las cosas.
o
a
Maven utiliza un fichero XML conocido como Project Object Model (POM) para describir el proyecto de software a construir, sus dependencias de otros m´dulos y componentes
o
externo, y el orden de construcci´n de los elementos. Esta es una caracter´
o
ıstica importante
de Maven ya que el desarrollador no se tiene que preocupar de tener las dependencias de
su proyecto, simplemente se describen en el fichero POM las que necesitar´ y Maven ya
a
se encarga de tenerlas preparadas, siempre y cuando disponga de conexi´n a Internet, ya
o
que le har´ falta en caso de que tenga que descargar las dependencias que necesita.
a

42. 1.3. Herramientas y tecnolog´ para la Documentaci´n
ıas
o
10
1.3.
Herramientas y tecnolog´ para la Documentaci´n
ıas
o
A
L TEX
Es un lenguaje de marcado para documentos, y un sistema de preparaci´n de
o
documentos, formado por un gran conjunto de macros de TEX, escritas inicialmente por
Leslie Lamport (LamportTeX) en 1984, con la intenci´n de facilitar el uso del lenguaje de
o
composici´n tipogr´fica creado por Donald Knuth. Es muy utilizado para la composici´n
o
a
o
de art´
ıculos acad´micos, tesis y libros t´cnicos, dado que la calidad tipogr´fica de los
e
e
a
A
documentos realizados con L TEX es comparable a la de una editorial cient´
ıfica de primera
A
l´
ınea. L TEX es software libre bajo licencia libre.
Kile
A
Es una herramienta para trabajar con L TEX en GNU/Linux. Facilita entre otras
cosas las labores de compilaci´n L TEX y de generaci´n de documentos. Adem´s proporo A
o
a
ciona caracter´
ısticas algunas t´
ıpicas de los entornos de edici´n de texto ‘wysiwyg‘ como
o
Microsoft Word o OpenOffice Writer. Los comandos b´sicos para la edici´n de un texa
o
A
to L TEX no hay que sab´rselos, ya que Kile proporciona un entorno que facilita mucho
e
el aspecto de escribir los comandos, proporcionando en forma de botones aquellos m´s
a
utilidados. A continuaci´n se se˜alan algunas cuestiones de configuraci´n que resulta util
o
n
o
´
conocer.
Configurar bien la codificaci´n de la p´gina, ya que, salvo que se le indique lo contrario,
o
a
Kile utiliza la codificaci´n que el sistema GNU/Linux tiene activada por defecto. En las
o
configuraciones modernas la codificaci´n frecuentemente es utf-8 (unicode). Sin embargo lo
o
A
m´s habitual en los documentos L TEX que utilizamos es usar latin1, que corresponde con
a
la codificaci´n iso 8859-1 o iso 8859-15 si los textos en espa˜ol van a utilizar alg´n s´
o
n
u ımbolo
especial. Si al abrir un archivo aparecen caracteres raros esto indica una configuraci´n de
o
codificaci´n de Kile no es la correcta y habr´ que modificarla.
o
a
Planner
Aplicaci´n software libre para realizar planificani´n de proyectos, utililzada
o
o
para la planificaci´n del proyecto actual y la evaluaci´n de costes. Entre sus funcionalidades
o
o

43. 1.3. Herramientas y tecnolog´ para la Documentaci´n
ıas
o
11
se puede observar la del c´lculo del coste asociado a cada una de las tareas, realizaci´n de
a
o
diagramas de Gantt para seguir la realizaci´n del proyecto.
o
El unico inconveniente de esta aplicaci´n es que no exporta a ning´n formato de imagen
´
o
u
los diagramas finales.
GIMP
Es un editor de im´genes software libre que permite crear y modificar im´genes de
a
a
distintos formatos y exportarlas finalmente a pr´cticamente cualquier formato de imagen.
a
Este editor tiene unas prestaciones parecidas al programa Photoshop de Adobe pero con
las ventajas de que no hay que pagar una licencia por ´l, es c´modo de usar y, auque tiene
e
o
una curva de aprendizaje larga, es muy r´pido de utilizar una vez que se sabe manejar.
a

45. Cap´
ıtulo 2
Estado actual de las tecnolog´
ıas
utilizadas
Antes de desarrollar cualquier proyecto software lo primero que hay que hacer es identificar todas las tecnolog´ que se utilizar´n en el mismo. Para ello un desarrollador se
ıas
a
sirve de su experiencia con las distintas herramientas y de los requisitos que tendr´ que
a
cumplir la aplicaci´n que va a desarrolar, ya que algunas tecnolog´ no permitir´n que
o
ıas
a
estos se cumplan.
En un primer lugar para este proyecto se descartar´n autom´ticamente todas aquellas
a
a
tecnolog´ que impidan licenciar el sistema final como software libre, siendo b´sicamente
ıas
a
todas aquellas que est´n licenciadas bajo una licencia privativa. En ciertas situaciones
e
ser´ complicado encontrar aplicaciones, y tecnolog´ libres equivalentes a las tecnolog´
a
ıas
ıas
privativas m´s comunes, adem´s de ser una dificultad el encontrar alg´n software, tambi´n
a
a
u
e
influir´ en el tiempo de desarrollo del proyecto, ya que habr´ que aprender a manejar las
a
a
tecnolog´ elegidas.
ıas
Cuando se quiere desarrollar una aplicaci´n web lo primero que hay que identificar es
o
la plataforma a utilizar, en este caso J2EE, ya se sab´ de antemano porque era uno de
ıa
los requisitos del proyecto, pero aparte de J2EE hay otras alternativas como pueden ser la
13

46. 14
plataforma .NET o PHP, cualquiera de ellas se podr´ utilizar. En el caso de J2EE la curva
ıa
de aprendizaje es muy larga, entre otras cosas porque se necesita saber utilizar un unico
´
lenguaje de programaci´n, pero a parte de eso se necesitan aprender como funcionan las
o
diferentes tecnolog´ que se utilizar´n conjuntamente a la hora de desarrollar el proyecto.
ıas
a
En este caso J2EE y PHP tienen multitud de comunidades de usuarios ya sea de los propios
proyectos, Apache, MySQL, como grupos independientes de desarrolladores, mientras que
en proyectos .NET las comunidades de desarrolladores est´n controladas y gestionadas
a
por Microsoft.
Aunque la tecnolog´ a utilizar no estuviera previamente determinada, .NET no se podr´
ıa
ıa
utilizar debido a que su entorno de desarrollo integrado es propietario y de un coste muy
elevado que har´ inviable el proyecto, frente a los entornos de desarrollo que existen en el
ıa
mercado para trabajar con J2EE entre los que destaca Eclipse, considerado por muchos
el mejor entorno de desarrollo integrado libre del mercado. Adem´s hay otros aspectos de
a
J2EE que corren a su favor, como la portabilidad entre diferentes plataformas, gracias en
gran medida a estar todo realizado en Java. Esto proporciona que el proyecto final sea
totalmente independiente de la plataforma, cosa que no sucede con .NET que hasta el
momento s´lo se puede montar sobre plataformas de Microsoft. Del mismo modo .NET
o
s´lo cuenta con servidores comerciales de pago mientras que J2EE funciona tanto sobre
o
servidores de pago como libres.
Por otra parte dada la naturaleza del proyecto y a que se licenciar´ como software libre
a
para que otros desarrolladores puedan agregar nuevas mejoras, este debe ser f´cilmente
a
escalable, por eso tambi´n en este caso de adapta perfectamente J2EE que permite gran ese
calabilidad por si en el futuro se desea integrar esta aplicaci´n con otras para proporcionar
o
m´s funcionalidades.
a
J2EE nos es la opci´n m´s r´pida del mercado, ya que en este aspecto otras tecnolog´
o
a a
ıas
como PHP no tienen competidor, pero es lo suficientemente r´pido para dar soporte a las
a
necesidades de la aplicaci´n final.
o

47. 15
Se necesita tambi´n un gestor de bases de datos para el proyecto y para ello habr´ que
e
a
tener en cuenta de igual forma que sea una tecnolog´ libre, por lo que quedan descartaıa
dos gestores de bases de datos como Oracle. Entre la oferta disponible destacan MySQL
y PostgreSQL, y puestos a tener que elegir, como ambas ofrecen m´s o menos las misa
mas prestaciones, se utilizar´ MySQL dada la familiaridad que se tiene, a que tiene una
a
comunidad de usuarios bien organizada y al bajo coste debido a su licencia libre.

49. Cap´
ıtulo 3
Estudio de viabilidad
Obviamente antes de realizar el proyecto que aqu´ se est´ detallando, se estudi´ si era
ı
a
o
viable realizarlo y terminarlo con ´xito en el tiempo previsto, puesto que, al ser un proyecto
e
acad´mico para dar fin a la formaci´n que se ha estado recibiendo, la fecha l´
e
o
ımite ser´ la
ıa
que marcaran las convocatorias para la entrega del proyecto. Si el proyecto no fuese viable
no se podr´ realizar porque no se tendr´ la garant´ de terminarlo.
ıa
ıa
ıa
A parte del tiempo del que se dispone para la realizaci´n de esta aplicaci´n, tambi´n es
o
o
e
un factor decisivo para estudiar la viabilidad del mismo, el coste, que deber´ ser el m´
a
ınimo
posible.
Este proyecto no solo valdr´ para terminar los estudios, sin´ que se har´ de tal forma
a
o
a
que sea facilmente ampliable para que en el futuro se pueda adaptar para una aplicaci´n
o
empresarial real con muy poco esfuerzo y haciendo los m´
ınimos cambios posibles. Para
posibilitar la realizaci´n de futuros cambios, en la realizaci´n del dise˜o de la aplicaci´n ya
o
o
n
o
se han tenido en cuenta posibles puntos de amplicaci´n. De esta forma se podr´ adaptar
o
ıa
la aplicaci´n para venderla, y con muy pocos cambios sacarle mucha rentabilidad a la
o
aplicaci´n web.
o
Por otro lado como la realizaci´n del proyecto s´lo se har´ por parte de una persona,
o
o
a
este no se har´ demasiado extenso para que sea viable realizarlo en 4 o 6 meses.
a
17

50. 18
Para que cualquier proyecto sea rentable realizarlo hay que tener en cuenta el coste en
cuanto a tiempo de desarrollo y tambi´n el coste derivado de la utilizaci´n de las distintas
e
o
tecnolog´ Por esa raz´n para que la realizaci´n del proyecto saliese rentable, se decide
ıas.
o
o
utilizar solamente software libre y gratuito, gracias a esto tambi´n cabe la posibilidad de
e
licenciar la aplicaci´n final como software libre.
o
A continuaci´n se detallan algunas de las tecnolog´ y herramientas software consideo
ıas
radas y finalmente utilizadas, as´ como su coste asociado.
ı
Herramienta
Descripci´n
o
MySQL
Gestor de base de datos relacional
utilizado para almacenar los datos
de la aplicaci´n
o
Entorno de programaci´n integrado
o
utilizado para realizar la programaci´n de la aplicaci´n
o
o
Servidor de Aplicaciones Web utilizado contener la aplicaci´n
o
Editor de diagramas utilizados utilizados para realizar los diagramas
del modelo Entidad-Relaci´n de la
o
base de datos
Editor de diagramas UML utilizados para realizar los diagramas
UML del modelo de la aplicaci´n
o
Aplicaci´n utilizada para gestionar
o
y monitorizar las bases de datos utilizadas
Editor
de
textos
para
A
L TEXutilizado para realizar toda la documentaci´n necesaria para
o
la aplicaci´n
o
IDE Eclipse
Apache Tomcat
DIA
Argo UML
PhpMyAdmin
Kile
Cantidad
Precio (e)
1
0.00
1
0.00
1
0.00
1
0.00
1
0.00
1
0.00
1
0.00
Cuadro 3.1: Tabla de costes para estudio de viabilidad
Resumiendo, gracias a las licencias libres de todas las herramientas y tecnolog´ utiliıas
zadas, el coste total de todas es de 0.00e, por lo que el coste final ser´ igual al coste del
a
tiempo empleado en el desarrollo de la aplicaci´n. Esto cambiar´ si se utilizasen herrao
ıa

51. 19
mientas y tecnolog´ de pago, porque s´lo por el coste de las licencias, el proyecto que se
ıas
o
desea realizar ser´ totalmente inviable para realizar como proyecto fin de carrera.
ıa

53. Cap´
ıtulo 4
Introducci´n al desarrollo
o
realizado
4.1.
El Proceso Unificado
Para realizar este proyecto se utiliza una metodolog´ basada en iteraciones, donde en
ıa
cada una de ellas se consigue implementar un conjunto de funcionalidades de la aplicaci´n,
o
casos de uso, y as´ al terminar la utima iteraci´n se tiene un sofware que implementa todos
ı
´
o
los casos de uso.
En cada una de las iteraciones se realizar´ an´lisis, dise˜o, implementaci´n y pruebas.
a a
n
o
Para realizar estas iteraci´nes se utiliza la metodolog´ que define el Proceso Unificado,
o
ıa
(UP, Unified Process). Este proceso de desarrollo, acompa˜ado del leguaje de modelado
n
UML (Unified Modelling Languaje) son, conjuntamente, la metodolog´ que m´s se utiliza
ıa
a
actualmente a la hora de desarrollar un nuevo proyecto software.
El Proceso Unificado de desarrollo software es un marco de desarrollo software iterativo
e incremental, el UP se puede extender para ser adaptado a organizaciones o proyectos
expec´
ıficos, de hecho, el refinamiento m´s conocido del Proceso Unificado es el Proceso
a
21

54. 4.1. El Proceso Unificado
22
Unificado de Rational que es un marca registrada de IBM, pero hay otros muchos refinamientos: Agile UP, Open UP, etc.
El UP est´ compuesto por cuatro fases denominadas Concepci´n, Elaboraci´n, Consa
o
o
trucci´n y Transici´n, donde cada una de estas fases se divide en iteraciones. Cada una
o
o
de las iteraciones ofrece como resultado un incremento del producto que a˜ade o mejora
n
funcionalidades del sistema.
Cada iteraci´n se divide en disciplinas c´mo las que se defin´ en el ciclo de vida
o
o
ıan
cl´sico: An´lisis de requisitos, Dise˜o, Implementaci´n, Pruebas, etc. Pero, aunque todas
a
a
n
o
las iteraciones incluyen trabajo en casi todas las disciplinas, cada una de ellas se centra
m´s en una iteraci´n u otra. Este ´nfasis en cada iteraci´n se puede observar en el gr´fico
a
o
e
o
a
de la figura 4.1.
Figura 4.1: Gr´fico del Proceso Unificado
a
El Proceso Unificado se caracteriza, entre otras cosas, por estar dirgido por los casos de
uso, estos se utilizan para capturar los requisitos funcionales y para definir los contenidos
de cada iteraci´n. Estos contenidos son los recogidos en un cada uno de los conjuntos
o

55. 4.1. El Proceso Unificado
23
de casos de uso o escenarios, de forma que cada iteraci´n pase a trav´s de todas las
o
e
disciplinas: dise˜o, implementaci´n, etc. Adem´s, siguiendo este proceso de desarrollo, hay
n
o
a
que centrarse en los riesgos, es decir, se deben identificar los riesgos cr´
ıticos que pueden
afectar al desarrollo del proyecto lo antes posible. Identificando los riesgos en una etapa
temprana luego el desarrollo se debe centrar en resolver estos puntos cr´
ıticos en primer
lugar.
A continuaci´n se detalla lo que tiene lugar en las distintas fases del Proceso Unificado:
o
Fase de Concepci´n
o
Esta fase es la m´s peque˜a del proyecto, en ella se deben establer el ´mbito del
a
n
a
proyecto y una justificaci´n de por qu´ se realiza.
o
e
Adem´s es en este momento cu´ndo se esbozan los casos de uso y los requisitos
a
a
principales por los cuales se dirigir´n las cuestiones de dise˜o del proyecto. Por otro
a
n
lado se deben comenzar a buscar las arquitecturas generales que mejor se adapten
al proyecto que se quiere realizar e identificar los riesgos cr´
ıticos para el mismo. A
continuaci´n se debe preparar un plan para el proyecto y una estimaci´n de los costes
o
o
que este conllevar´.
a
Fase de Elaboraci´n
o
Es la fase en la cual se capturan la mayor´ de los requisitos del sistema, identificando
ıa
tambi´n los riesgos y estableciendo la arquitectura general del sistema.
e
Adem´s se debe implementar una Base de Arquitectura Ejecutable para demostrar
a
que el sistema final soportar´ los aspectos claves de funcionalidad establecidos y
a
comprobar que tiene un rendimiento, escalabilidad y coste adecuados.
Fase de Construcci´n
o
Es la m´s larga del proyecto, donde se construye el sistema en base a lo especificado
a
en la fase de elaboraci´n. Esta fase se divide en una serie de iteraciones, y en cada
o

56. 4.2. El Proceso Unificado en este Proyecto
24
una de ellas se implementa un conjunto de las funcionalidades, terminando cada una
con una versi´n completa de la aplicaci´n final.
o
o
Fase de Transici´n
o
Esta es la fase en la que se despliega la aplicaci´n para el usuario final, y recogiendo
o
las impersiones de estos para incorporar refinamientos al sistema en sucesivas iteraciones, esta fase tambi´n incluye el entrenamiento en la utilizaci´n del sistema por
e
o
parte de los usuarios.
4.2.
El Proceso Unificado en este Proyecto
A continuaci´n se ver´ c´mo se aplic´ el Proceso Unificado en el desarrollo de este
o
a o
o
proyecto, para ello se ir´n indicando las diferentes fases por las que se fue pasando y las
a
iteraciones que se realizaron en cada una de ellas con una descripci´n de lo que se hizo.
o
Fase de Concepci´n
o
1. Iteraci´n 1
o
En esta iteraci´n se hizo un an´lisis de las funcionalidades que deber´ cono
a
ıa
templar la aplicaci´n, estableciendo textualmente los requisitos principales del
o
sistema.
A partir de este an´lisis de requisitos se realiz´ el dise˜o Entidad Relaci´n de
a
o
n
o
la base de datos que necesitar´ la aplicaci´n, para luego realizar el modelo relaa
o
cional. A continuaci´n se implementa la base de datos en base a lo especificado
o
en el modelo relacional.
Adem´s en este momento se vi´ que probablemente ser´ un riesgo a solventar
a
o
ıa
que el driver JDBC, que posteriormente se utilizar´ para conectarse a la base
a
de datos, funcionase correctamente. Se detect´ en este momento un mal funcioo
namiento de la conexi´n con la base de datos y se resolvi´ despu´s de consultar
o
o
e
la documentaci´n espec´
o
ıfica del manejador JDBC.

57. 4.2. El Proceso Unificado en este Proyecto
25
Fase de Elaboraci´n
o
1. Iteraci´n 1
o
En esta iteraci´n se realiza un an´lisis de requisitos m´s exhaustivo, realizando
o
a
a
el modelo de casos de uso. A partir de este an´lisis de requisitos se refina el
a
dise˜o de la base de datos y se implementan los cambios realizados.
n
Se dise˜a en este momento como ser´ la capa modelo, los DAO y las Fachadas
n
a
que se necesitar´n. A partir de este dise˜o se implementa la capa de acceso a
a
n
base de datos (DAO) y alguna de las fachadas, tambi´n se hacen las pruebas
e
de unidad correspondientes a estas implementaciones.
Adem´s se hacen pruebas para ver como funciona la tecnolog´ struts que se
a
ıa
utilizar´ para implementar la capa controladora de la aplicaci´n web.
a
o
Fase de Construcci´n
o
1. Iteraci´n 1
o
En esta iteraci´n se refinan peque˜os detalles de los requisitos y se dise˜a la
o
n
n
capa controladora y la vista.
Es ahora cuando se implementa un subconjunto completo de casos de uso, en
este caso el referido a la gesti´n de usuarios. Se implementa desde las acciones
o
del modelo, que implementan realmente los casos de uso, hasta la capa vista.
Entre estos casos de uso se encuentran los de autentificar al usuario en la aplicaci´n, darlo de alta, etc, para lo que tambi´n hay que implementar el mecanismo
o
e
para mantener las sesiones.
Para terminar con esta iteraci´n y conseguir una versi´n funcional del sistema
o
o
se prueba que se realicen correctamente los requisitos especificados en los casos
de uso.
Iteraci´n 2
o

58. 4.2. El Proceso Unificado en este Proyecto
26
En este momento se refina el dise˜o de las fachadas que se van a implementar de
n
forma que se ajuste exactamente a lo que se desea. Adem´s se dise˜a la estructura
a
n
general del sistema de ofertas con el que se iteractuar´ a la hora de realizar las
a
facturas.
En este momento se implementan otros dos subconjuntos completos de casos de uso,
en este caso los referidos a la gesti´n de reservas y habitaciones. Se implementa
o
desde las acciones del modelo que implementan realmente los casos de uso hasta la
capa vista. Entre estos casos de uso se encuentran los de realizar una nueva reserva,
consultar las reservas y modificarlas, para ello es necesario implementar una forma
de gestionar la realizaci´n de las reservas.
o
Para terminar con esta iteraci´n y conseguir una versi´n funcional del sistema se
o
o
prueba que se realicen correctamente los requisitos especificados en los casos de uso.
Iteraci´n 3
o
En este momento se refina el dise˜o del sistema de las ofertas para que se ajuste
n
exactamente a los requisitos requeridos por el mismo.
En este momento se implementan otros dos subconjuntos completos de casos de uso,
en este caso los referidos a la gesti´n de facturas y ofertas. Se implementa desde las
o
acciones del modelo que implementan realmente los casos de uso hasta la capa vista.
Entre estos casos de uso se encuentran los de ver el borrador de una factura en el
que entra en juego el sistema de ofertas desarrollado, pagar una factura o cancelarla,
etc.
Para terminar con esta iteraci´n y conseguir una versi´n funcional del sistema se
o
o
prueba que se realicen correctamente los requisitos especificados en los casos de uso,
prestando especial atenci´n al sistema de ofertas, ya que la unica forma de probarlo
o
´
es en este momento, debido a la dificultad de realizar pruebas de unidad de cada
uno de los m´todos que forman sus clases.
e
Fase de Transici´n
o

59. 4.2. El Proceso Unificado en este Proyecto
27
Esta fase del Proceso Unificado no es necesaria realizarla para la realizaci´n del proo
yecto debido a que en este caso s´lo valdr´ para evaluar los conocimientos adquiridos
o
a
durantes los estudios realizados. Si este proyecto tuviese que ser adaptado para su
comercializaci´n, ser´ en esta fase cuando se desplegar´ ante el usuario final para
o
ıa
ıa
que informase si todo est´ como se hab´ pedido y cuando se ense˜ar´ al usuario a
a
ıa
n ıa
utilizar la aplicaci´n.
o

61. Cap´
ıtulo 5
Requisitos del Sistema
5.1.
Introducci´n
o
Antes de comenzar cualquier proyecto de desarrollo de software, lo primero que hay que
hacer es un an´lisis de requisitos del sistema, es decir, hay que conocer las caracter´
a
ısticas
que debe tener el sistema.
Las caracter´
ısticas de una aplicaci´n las determinan el cliente que la solicita y el usuario
o
final que lo va a utilizar. En nuestro caso necesitamos una aplicaci´n que permita gestionar
o
las reservas de un hotel y dem´s partes del mismo, de una forma sencilla. El sistema a
a
desarrollar est´ orientado a las peque˜as y medianas empresas hoteleras, por lo que el
a
n
coste del producto lo hay que reducir lo m´ximo posible.
a
En la actualidad la gran mayor´ de peque˜os hoteles o similares realizan sus tareas de
ıa
n
una forma manual, o utilizando numerosos productos software. La gesti´n de las reservas
o
se suele hacer por tel´fono o en persona en el lugar donde se encuentre el establecimiento,
e
anotando las mismas en un libro de reservas ya sea, en formato papel o digital. Adem´s
a
necesitan un software especial para gestionar el proceso de facturaci´n del hotel, y no
o
tienen manera de gestionar de forma autom´tica y eficaz, todas las ofertas que puedan, o
a
quieran, tener a disposici´n del consumidor.
o
29

62. 5.1. Introducci´n
o
30
Las grandes firmas hoteleras y las cooperativas de varios hoteles no tienen estos problemas, ya que tienen financiamiento suficiente para contratar el desarrollo de aplicaciones
que se ajusten a sus necesidades.
Lo que se intenta hacer con este proyecto es ofrecer una soluci´n lo m´s gen´rica posible
o
a
e
para todas aquellas peque˜as empresas a las cuales un producto como este les facilitar´
n
ıa
much´
ısimo las cosas a la hora de gestionar sus modestos negocios, adem´s de proporcionar
a
la opci´n de gestionar un sitio web propio que est´ totalmente integrado, dando, entre
o
e
otras cosas, la opci´n de hacer reservas y consultas on-line.
o
Una de las cosas m´s importantes es que este sistema se licenciar´ como software libre
a
a
bajo una licencia GPL (General Public License), de modo que todo aquel que lo necesite
pueda acceder a ´ste software de manera totalmente gratuita.
e
El desarrollo de este producto software est´ pensado para que, en caso necesario, sea
a
f´cilmente ampliable, configurable y ajustable, para adaptarse a las necesidades del usuario
a
final. Esta aplicaci´n contiene las funcionalidades b´sicas que un establecimiento hotelero
o
a
pueda necesitar en su d´ a d´ pero est´ orientado a que en cualquier momento se puedan
ıa
ıa,
a
realizar cambios de forma sencilla y sin alterar su estructura general.
El funcionamiento b´sico del sistema final tiene que dar soporte para dar de alta a
a
nuevos clientes, as´ como para la realizaci´n de reservas por parte de los clientes a trav´s
ı
o
e
de internet y en el establecimiento del hotel por parte del recepcionista, tambi´n dar´ la
e
a
posibilidad de que el administrador gestione todas las partes m´s cr´
a
ıticas del negocio,
como son las habitaciones y sus precios, o la publicaci´n de nuevas ofertas para que est´n
o
e
a disposici´n de los usuarios.
o
Cuando un nuevo usuario acceda a la aplicaci´n a trav´s de internet se le proporcionar´ la
o
e
a
oportunidad de darse de alta, o si ya lo est´, de acceder al sistema. Para ello se le pedir´n
a
a
sus datos personales, los cuales ser´n utilizados posteriormente a la hora de realizar las
a
facturas a nombre del cliente. Si por el contrario el alta del nuevo cliente la realiza el
recepcionista, se le pedir´n los mismos datos a excepci´n del nombre de usuario que desea
a
o

63. 5.1. Introducci´n
o
31
y su contrase˜a, ya que esos datos se los tendr´ que pedir expl´
n
a
ıcitamente el cliente al
recepcionista.
Un cliente, una vez registrado y autentificado en el sistema tendr´, la posibilidad de
a
hacer una reserva para los d´ que desee. Para la realizaci´n de una reserva simplemente
ıas
o
ser´ necesario que el cliente est´ registrado, pero esta reserva no ser´ una reserva real hasta
a
e
a
que el cliente la pague, para lo cual el administrador del hotel tendr´ que dar un plazo,
a
y si el cliente no paga la reserva dentro de ese plazo ´sta ser´ cancelada. De este modo
e
a
se pueden evitar p´rdidas derivadas de intentos de sabotaje por parte de alg´n usuario
e
u
malintencionado.
Una vez realizada la misma, se le comunica al cliente el n´mero de reserva que deu
ber´ buscar para pagar. A partir de ese momento el cliente puede consultar la reserva
a
realizada y modificarla si lo desea, o ver la factura y pagarla o cancelarla. La factura que
ve el cliente se genera autom´ticament; para ello el sistema deber´ utilizar alg´n algoritmo
a
a
u
especial que permite aplicar las ofertas pertinentes.
El sistema de ofertas es quiz´ una de las partes de la aplicaci´n m´s complicada de resola
o
a
ver. Una oferta va a pertenecer a un tipo de ofertas; estos tipos los definir´ el administrador
a
(obviamente de cada tipo de oferta s´lo se podr´ aplicar una oferta).
o
a
Hasta aqu´ la parte sencilla, este sistema tambi´n permitir´ acumular ofertas de forma
ı
e
a
que se puedan aplicar varios descuentos de ofertas distintas sobre el importe inicial, y
dejar´ al administrador especificar mediante reglas altamente configurables, el conjunto
a
de clientes o aquellas situaciones espec´
ıficas en las cuales se podr´ aplicar una oferta; por
a
lo tanto, otro problema a solventar ser´ la definici´n de dicho lenguaje de reglas.
a
o
Como acabamos de mencionar, de cada tipo de oferta solamente una se podr´ aplicar,
a
pero adem´s los tipos tendr´n incompatibilidades entre s´ relaciones mediante las cuales
a
a
ı,
se definir´ que ofertas no se pueden aplicar conjuntamente. La aplicaci´n debe resolver de
a
o
forma r´pida y eficaz esta problem´tica, ya que a la hora de calcular la mejor oferta que
a
a

64. 5.2. Actores
32
se le puede ofrecer a un cliente sobre una factura, tendr´ que calcular cu´l es el conjunto
a
a
de ofertas que a ´ste le proporcionar´ un mayor descuento.
e
a
En las siguientes secciones se ver´n en detalle todas las situaciones que el sistema dea
ber´ contemplar y resolver, y todos los usuarios que interactuar´n con la aplicaci´n.
a
a
o
Para la definici´n de las funcionalidades del sistema se emplear´ notaci´n UML (Unified
o
a
o
Modelling Language) especificando los usuarios del sistema y todos los que interact´an
u
con ´l (actores), y los comportamientos del mismo ante las peticiones de los actores (casos
e
de uso).
Las funcionalidades b´sicas de este producto se definir´n en cojuntos de casos de uso, a
a
a
trav´s de los cuales se detallar´ el funcionamiento de la aplicaci´n.
e
a
o
5.2.
Actores
Como se acaba de mencionar, un actor es alguien o algo que intercambia informaci´n
o
con el sistema, bien sea un usuario u otro sistema. Varios usuarios se pueden representar
como un s´lo actor para el sistema y viceversa, un mismo usuario puede ser representado
o
por varios actores.
Se pueden distinguir varios tipos de actores, de los cuales los m´s importantes son:
a
Los actores primarios y los de soporte. Los actores primarios son aquellos que utilizan
el sistema para alcanzar sus objetivos y a trav´s de los cuales se pueden identificar los
e
objetivos a desarrollar en el sistema. Los actores de soporte son los que proveen un servicio
al sistema, estos actores sirven para identificar interfaces externos a nuestro sistema que
hay que utilizar.
En nuestro sistema podemos encontrar los siguientes actores primarios:
Persona Es toda persona que entra en la aplicaci´n y no se autentifica o se registra. Este
o
usuario puede hacer consultas de precios, ofertas y dem´s, pero no podr´ realizar
a
a

65. 5.3. Casos de Uso
33
ningua reserva. Este tipo de usuario tiene la opci´n de autentificarse o de registrarse
o
en el sistema.
Cliente Es aquel usuario que se ha autentificado, tiene la posibilidad de hacer las mismas operaciones que una Persona, pero adem´s tambi´n puede realizar reservas de
a
e
habitaciones, hacer consultas sobre sus reservas y facturas, y pagar o cancelar las
reservas que desee. Entre otras cosas este usuario tambi´n puede actualizar su perfil
e
o darse de baja en el sistema.
Recepcionista Es el empleado del hotel que se encarga de la recepci´n del mismo, este
o
usuario es el encargado de recibir a los clientes en el establecimiento y tiene la
posibilidad de dar de alta a un nuevo cliente y realizarle una reserva si es necesario.
Administrador Es el empleado encargado de gestionar y mantener todo el sistema por
lo que tiene unos privilegios que no posee ning´n otro usuario.
u
C´mo el Cliente va a poder hacer las mismas operaciones que la Persona, esto significa
o
que entre los dos constituyen una jerarqu´ de usuarios.
ıa
Pero adem´s la aplicaci´n necesita un indispensable actor de soporte:
a
o
Entidad Financiera Es el sistema de pago contra el cual nuestro sistema tiene que
realizar y verificar los pagos de las reservas. Este usuario permite que las reservas se
puedan pagar on-line.
5.3.
Casos de Uso
Un caso de uso es una forma de definir el escenario completo de una operaci´n. Un caso
o
de uso especifica claramente lo que hace una operaci´n desde el punto de vista del actor
o
que la realiza. En ´l aparecer´n exclusivamente aquellos detalles que son relevantes para
e
a
el actor.

66. 5.3. Casos de Uso
34
En primer lugar se expecificar´n los distintos casos de uso siguiendo las especificaciones
a
que proporciona el proceso de desarrollo unificado, que es el que se est´ siguiendo en la
a
elaboraci´n de este proyecto. Estas especificaciones indican que el detallado de un caso de
o
uso debe contener la siguiente informaci´n: actores, precondiciones, postcondiciones, flujo
o
b´sico y flujo alternativo.
a
Los actores son los usuarios implicados en el caso de uso en cuesti´n. Las precondiciones
o
especifican todas las condiciones del sistema que son obligatorias que se cumplan antes de
que comience el caso de uso. Por otro lado, las postcondiciones son aquellas condiciones
en las que, con toda seguridad, quedar´ el sistema una vez termine la ejecuci´n del caso
a
o
de uso.
Aunque lo m´s importante para detallar un caso de uso es indicar cu´l va a ser su flujo
a
a
b´sico de eventos y cu´l su flujo alternativo. El flujo b´sico de eventos indica los eventos
a
a
a
que se han de realizar para que el caso de uso termine exitosamente. El flujo alternativo
es aquel flujo de eventos que se seguir´ en caso de que alg´n fallo ocurra durante el flujo
a
u
b´sico del mismo.
a
Una vez aclarados estos conceptos ya se puede comenzar a detallar cada uno de los casos
de uso de este sistema, y para que se puedan entender mejor van a estar agrupados por
conjuntos donde est´n contextualmente relacionados entre s´
a
ı.
5.3.1.
Casos de Uso de Gesti´n de Usuarios Web
o
Estos casos de uso son todos aquellos relacionados con la gestion de los Usuarios del
sistema, registro, autentificaci´n, etc. Se puede ver el diagrama correspondiente en la figura
o
5.1 de la p´gina 78.
a
1. Autenticarse
Actores Primarios: Cliente, Recepcionista, Administrador.

67. 5.3. Casos de Uso
35
Descripci´n: Permite a una persona entrar en el sistema.
o
Precondiciones: La persona a´n no est´ autenticada en el sistema.
u
a
Postcondiciones: La persona pasa a estar autenticada en el sistema.
Flujo b´sico:
a
1 La persona quiere autenticarse en el sistema.
2 El sistema pide a la persona que introduzca su nombre de usuario y su contrase˜a.
n
3 La persona introduce su nombre de usuario y su contrase˜a.
n
4 La persona confirma que desea autenticarse.
5 El sistema autentica a la persona.
Flujo alternativo:
*.1 En cualquier momento la persona tiene la posibilidad de cancelar el proceso.
4.1 La persona no ha introducido el login, la contrase˜a o ambos.
n
4.2 El sistema indica que tiene que indicar el nombre de usuario y contrase˜a.
n
4.3 Se vuelve al evento 2 del flujo b´sico.
a
5.1 El nombre de usuario o contrase˜a son incorrectos.
n
5.2 El sistema se lo indica a la persona y le da la opci´n de registrarse.
o
5.3 Se vuelve al paso 2.
2. Salir del sistema
Actores Primarios: Cliente, Recepcionista, Administrador
Descripci´n: Permite a un cliente dejar de estar autenticado en el sistema.
o
Precondiciones: El cliente est´ autenticado en el sistema.
a

68. 5.3. Casos de Uso
36
Postcondiciones: El cliente deja de estar autenticado en el sistema.
Flujo b´sico:
a
1 La persona quiere salir del sistema.
2 El sistema pide al cliente que confirme que desea salir del sistema.
3 El cliente confirma que desea salir.
4 El sistema procesa la petici´n y el cliente deja de estar autenticado en la
o
aplicaci´n.
o
Flujo alternativo:
*.1 En cualquier momento la persona tiene la posibilidad de cancelar el proceso.
3. Dar de Alta Usuario
Actores Primarios: Persona
Descripci´n: Permite a una nueva persona que entra en el portal Web del hotel darse de alta
o
como usuario del mismo.
Precondiciones: La persona no est´ autenticada en el sistema.
a
Postcondiciones: La persona pasa a estar autenticada en el sistema y se registra como nuevo
usuario de este.
Flujo b´sico:
a
1 La persona quiere darse de alta en el sistema.
2 El sistema pide a la persona que introduzca los siguientes datos de los cuales
algunos son obligatorios:
• Nombre (obligatorio)

69. 5.3. Casos de Uso
37
• Apellidos (obligatorio)
• DNI o pasaporte (obligatorio)
• Fecha de Nacimiento (obligatorio)
• Direcci´n completa (obligatorio)
o
• Pa´ (obligatorio)
ıs
• Direcci´n de e-mail (obligatorio)
o
• Tel´fono1 (opcional)
e
• Tel´fono2 (opcional)
e
• Nombre de Usuario (obligatorio)
• Contrase˜a (obligatorio)
n
• Confirmaci´n de contrase˜a (obligatorio)
o
n
3 La persona introduce los datos solicitados.
4 La persona confirma que desea darse de alta.
5 El sistema procesa la informaci´n del nuevo cliente.
o
6 La persona pasa a estar dada de alta como cliente.
7 El sistema autentica al cliente en la aplicaci´n.
o
8 El cliente est´ autenticado en el sistema.
a
Flujo alternativo:
*.1 En cualquier momento la persona tiene la posibilidad de cancelar el proceso.
4.1.1 La persona no ha introducido todos los datos obligatorios o las contrase˜as no coinciden.
n
4.1.2 El sistema indica que tiene que introducir los datos obligatorios y se
vuelve al evento 2 del flujo b´sico.
a
4.2.1 El nombre de usuario ya existe como nombre de usuario de otro cliente.
4.2.2 Se solicita que cambie el nombre de usuario y se vuelve al paso 2.
4.3.1 El dni indica que esa persona ya est´ dada de alta.
a

70. 5.3. Casos de Uso
38
4.3.2 Se le pide a la persona que compruebe que ha escrito bie su dni y se
vuelve al paso 2.
4. Modificar datos de Usuario
Actores Primarios: Cliente, Recepcionista, Administrador
Descripci´n: Permite a un cliente modificar los datos con los que se di´ de alta como usuario
o
o
del sistema.
Precondiciones: El cliente est´ autenticado en el sistema.
a
Postcondiciones: Los datos del cliente est´n actualizados.
a
Flujo b´sico:
a
1 El cliente quiere midificar los datos con los que se di´ de alta en el sistema.
o
2 El sistema muestra los datos actuales del cliente y pide al cliente que actualice
los que desee de los siguientes:
• Nombre (obligatorio)
• Apellidos (obligatorio)
• Fecha de Nacimiento (obligatorio)
• Direcci´n completa (obligatorio)
o
• Pa´ (obligatorio)
ıs
• Direcci´n de e-mail (obligatorio)
o
• Tel´fono1 (opcional)
e
• Tel´fono2 (opcional)
e
• Contrase˜a (obligatorio)
n
• Confirmaci´n de contrase˜a (obligatorio)
o
n
3 El cliente modifica los datos que quiere.

71. 5.3. Casos de Uso
39
4 El cliente confirma que desea actualizar sus datos.
5 El sistema procesa la actualizaci´n de los datos del cliente.
o
6 Los datos del cliente pasan a estar actualizados.
Flujo alternativo:
*.1 En cualquier momento la persona tiene la posibilidad de cancelar el proceso.
4.1 La persona no ha introducido todos los datos obligatorios o las contrase˜as
n
no coinciden.
4.2 El sistema indica que tiene que introducir los datos obligatorios y se vuelve
al evento 2 del flujo b´sico.
a
5. Consultar datos de Usuario
Actores Primarios: Cliente, Recepcionista, Administrador
Descripci´n: Permite a un cliente consultar los datos con los que se di´ de alta en el sistema.
o
o
Precondiciones: El cliente est´ autenticado en el sistema.
a
Postcondiciones: Ninguna.
Flujo b´sico:
a
1 El cliente quiere consultar los datos con los que se di´ de alta en el sistema.
o
2 El sistema muestra al cliente sus datos personales.
6. Dar de baja Usuario
Actores Primarios: Cliente
Descripci´n: Permite a un un cliente darse de baja como usuario del sistema.
o

72. 5.3. Casos de Uso
40
Precondiciones: El cliente est´ autenticado en el sistema.
a
Postcondiciones: El cliente deja de estar autenticado en el sistema y deja de existir como usuario
de la aplicaci´n.
o
Flujo b´sico:
a
1 La persona quiere darse de baja del sistema.
2 El sistema muestra un aviso al cliente, y pide a este que confirme que desea
darse de baja.
3 El cliente confirma que desea darse de baja.
4 El sistema procesa la baja del cliente.
5 El cliente deja de ser usuario de la aplicaci´n.
o
Flujo alternativo:
*.1 En cualquier momento el cliente tiene la posibilidad de cancelar el proceso.
5.3.2.
Casos de Uso de Gesti´n de Reservas Web
o
Los Casos de Uso que aqu´ se detallan son todos los relacionados con la gesti´n de las
ı
o
reservas en el portal web del hotel por parte de los clientes. Se puede ver el diagrama
correspondiente en la figura 5.2 de la p´gina 79.
a
7. Hacer reserva web
Actores Primarios: Cliente
Descripci´n: Permite a un cliente realizar una reserva de una o varias habitaciones para un
o
d´ determinado.
ıa
Precondiciones: El cliente est´ autenticado en el sistema.
a

73. 5.3. Casos de Uso
41
Postcondiciones: La reserva queda realizada a espera de que el cliente la pague.
Flujo b´sico:
a
1 El cliente quiere realizar una reserva de habitaci´n.
o
2 La aplicaci´n pide al cliente que indique el tipo de habitaci´n que desea
o
o
reserva, el d´ que llega, el d´ de salida, y la cantidad de habitaciones de
ıa
ıa
ese tipo que necesita.
3 El cliente especifica todos los datos solicitados.
4 El cliente confirma que desea realizar la reserva de ese tipo de habitaci´n
o
para los d´ indicados.
ıas
5 El sistema procesa la reserva.
6 La reserva pasa a estar realizada a la espera de ser pagada y se le muestra al
cliente el n´mero de reserva para que la pueda localizar.
u
Flujo alternativo:
*.1 En cualquier momento el cliente tiene la posibilidad de cancelar el proceso.
4.1.1 El cliente no ha introducido todos los datos.
4.1.2 El sistema indica que tiene que especificar todos los datos y se vuelve al
evento 2 del flujo b´sico.
a
4.2.1 El cliente ha introducido una fecha de llegada o de salida err´nea.
o
4.2.2 El sistema indica que vuelva a introducir las fechas correctamente. y se
vuelve al evento 2.
4.3.1 No hay habitaciones disponibles para los valores especificados, se indica
y se vuelve al paso 2.
4.4.1 El cliente indica que desea realizar la reserva de otro tipo de habitaci´n.
o
4.4.2 El sistema procesa la reserva.
4.4.3 Se vuelve al paso 2 para realizar la siguiente reserva.

74. 5.3. Casos de Uso
42
8. Consultar reservas web
Actores Primarios: Cliente
Descripci´n: Permite a un cliente consultar las reservas que ha realizado desde que es cliente
o
del hotel, se podr´n ver las reservas pagadas, las canceladas y las que est´n a´n
a
a u
pendientes de pago.
Precondiciones: El cliente est´ autenticado en el sistema.
a
Postcondiciones: Ninguna.
Flujo b´sico:
a
1 El cliente quiere consultar las reservas que ha realizado hasta el momento
2 El sistema muestra al cliente todas sus reservas.
9. Modificar reserva web
Actores Primarios: Cliente
Descripci´n: Permite a un cliente modificar una reserva realizada
o
Precondiciones: El cliente est´ autenticado en el sistema, y la reserva no est´ pagada ni cancea
a
lada.
Postcondiciones: La reserva queda modificada a espera de que el cliente la pague.
Flujo b´sico:
a
1 El cliente quiere modificar una reserva de habitaciones.
2 El cliente indica que desea a˜adir una nueva reserva de habitaci´n.
n
o

75. 5.3. Casos de Uso
43
3 La aplicaci´n pide al cliente que indique el tipo de habitaci´n que desea
o
o
reserva, el d´ que llega, el d´ de salida, y la cantidad de habitaciones de
ıa
ıa
ese tipo que necesita.
4 El cliente especifica todos los datos solicitados.
5 El cliente confirma que desea realizar la reserva de ese tipo de habitaci´n
o
para los d´ indicados.
ıas
6 El sistema procesa la reserva.
7 El cliente confirma que quiere guardar los cambios realizados en la reserva
de habitaciones.
8 El sistema guarda la reserva.
Flujo alternativo:
*.1 En cualquier momento el cliente tiene la posibilidad de cancelar el proceso.
2.1 El cliente indica que desea eliminar una reserva de habitaci´n.
o
2.2 El sistema pide al usuario que indique cual es la l´
ınea de reserva que desea
eliminar.
2.3 El cliente especifica la l´
ınea de reserva que quiere eliminar.
2.4 El sistema procesa la eliminaci´n de la l´
o
ınea de reserva.
2.5 Se pasa al paso 2 del flujo b´sico.
a
5.1.1 El cliente no ha introducido todos los datos.
5.1.2 El sistema indica que tiene que especificar todos los datos y se vuelve al
evento 2 del flujo b´sico.
a
5.2.1 El cliente ha introducido una fecha de llegada o de salida err´nea.
o
5.2.2 El sistema indica que vuelva a introducir las fechas correctamente. y se
vuelve al evento 2.
5.3.1 No hay habitaciones disponibles para los valores especificados, se indica
y se vuelve al paso 2.

76. 5.3. Casos de Uso
44
7.4.1 El cliente indica que desea seguir modificando la reserva.
7.4.2 El sistema procesa la reserva.
7.4.3 Se vuelve al paso 2 para continuar modificando
10. Consultar factura web
Actores Primarios: Cliente
Descripci´n: Permite a un cliente consultar la factura de cualquier reserva que haya realizado
o
desde que es cliente del hotel, se podr´n ver las facturas pagadas, las canceladas
a
y las que est´n a´n pendientes de pago.
a u
Precondiciones: El cliente est´ autenticado en el sistema.
a
Postcondiciones: Ninguna.
Flujo b´sico:
a
1 El cliente quiere consultar una factura de una reserva que ha realizado.
2 El sistema pide al cliente que indique el n´mero de reserva para la factura
u
que desea consultar.
3 El cliente indica el n´mero de reserva deseado.
u
4 El sistema muestra al cliente la factura de la reserva solitada. En el caso
de que la factura ya est´ pagada o cancelada muestra el importe que ha
e
pagado y si la factura est´ pendiente de pago muestra el total que debe
a
pagar indicando aquellos descuentos que se le han proporcionado debido a
las ofertas que se le han podido aplicar.
Flujo alternativo:
*.1 En cualquier momento el cliente tiene la posibilidad de cancelar el proceso.

77. 5.3. Casos de Uso
45
11. Cancelar reserva web
Actores Primarios: Cliente
Descripci´n: Permite a un cliente cancelar cualquier reserva que haya realizado y a´n no diso
u
frutado, si la factura estuviese pagada se le devuelve un porcentaje del importe,
dependiendo de la antelaci´n con la que la cancele.
o
Precondiciones: El cliente est´ autenticado en el sistema.
a
Postcondiciones: La reserva queda cancelada.
Flujo b´sico:
a
1 El cliente quiere cancelar una reserva que ha realizado.
2 El sistema pide al cliente que indique el n´mero de reserva que desea cancelar.
u
3 El cliente indica el n´mero de reserva deseado.
u
4 El sistema pide al cliente la confirmaci´n de que quiere cancelarlas.
o
5 El cliente lo confirma.
6 El sistema cancela la reserva.
Flujo alternativo:
*.1 En cualquier momento el cliente tiene la posibilidad de cancelar el proceso.
3.1 El cliente indica un n´mero de reserva que ya hab´ sido cancelada o disu
ıa
frutada.
3.2 Se le muestra un error al cliente y se termina el proceso sin que se cancele
ninguna reserva.
12. Pagar factura web

78. 5.3. Casos de Uso
46
Actores Primarios: Cliente
Actores de Soporte: Entidad Financiera
Descripci´n: Permite a un cliente pagar la factura de una reserva.
o
Precondiciones: El cliente est´ autenticado en el sistema.
a
Postcondiciones: La factura de la reserva est´ pendiente de pago y no est´ cancelada.
a
a
Flujo b´sico:
a
1 El cliente quiere pagar la factura de una reserva que ha realizado.
2 El sistema pide al cliente que indique el n´mero de reserva que desea pagar.
u
3 El cliente indica el n´mero de reserva deseado.
u
4 El sistema muestra al cliente la factura de la reserva y le pide la confirmaci´n
o
de que quiere pagarla.
5 El cliente lo confirma.
6 El sistema marca la factura como en proceso de pago y env´ los datos del
ıa
pago a la entidad financiera.
7 El cliente y la entidad financiera gestionan el pago de la factura.
8 La entidad financiera env´ al sistema la confirmaci´n de pago de la factura.
ıa
o
9 El sistema comprueba la confirmaci´n.
o
10 La factura se marca como pagada.
Flujo alternativo:
(1-5).1 En cualquier momento el cliente tiene la posibilidad de cancelar el
proceso.
3.1 El cliente indica un n´mero de reserva que ya hab´ sido pagado o que ya
u
ıa
est´ en proceso de pago.
a
3.2 Se le muestra un error al cliente y se termina el proceso sin que se pague
la factura de la reserva.

79. 5.3. Casos de Uso
47
8.1 La entidad financiera no env´ la confirmaci´n de pago de la factura.
ıa
o
8.2 El pago de la factura se interrumpe y la factura deja de estar en proceso
de pago.
5.3.3.
Casos de Uso de Gesti´n de Clientes
o
Estos casos de uso son todos aquellos relacionados con la gestion de los Clientes,
en la recepci´n del hotel, registro de nuevos clientes, consulta y modificaci´n de sus
o
o
datos, etc. Se puede ver el diagrama correspondiente en la figura 5.3 de la p´gina 80.
a
13. Buscar Cliente
Actores Primarios: Recepcionista
Descripci´n: Permite al recepcionista buscar a un cliente para trabajar con ´l.
o
e
Precondiciones: El recepcionista est´ autenticado en el sistema.
a
Postcondiciones: El recepcionista sigue siendo el usuario real del sistema, pero el cliente elegido
es el usuario efectivo del mismo.
Flujo b´sico:
a
1 El recepcionista quiere buscar a un cliente para trabajar con ´l.
e
2 El sistema pide al recepcionista que introduzca los par´metros requeridos
a
para realizar la b´squeda del cliente.
u
3 El recepcionista introduce todos, algunos o ninguno de los par´metros requea
ridos
4 El recepcionista confirma que desea buscar a un cliente que coincida con esos
par´metros
a
5 El sistema muestra todos los clientes que coinciden con los par´metros de
a
b´squeda y pide al recepcionista que elija a uno de ellos.
u

80. 5.3. Casos de Uso
48
6 El recepcionista escoge el cliente que buscaba.
7 El sistema pone al cliente elegido como usuario efectivo del sistema.
Flujo alternativo:
*.1 En cualquier momento la persona tiene la posibilidad de cancelar el proceso.
14. Salir de la cuenta de un cliente
Actores Primarios: Recepcionista
Descripci´n: Permite al recepcionista dejar de trabajar con la cuenta de un cliente.
o
Precondiciones: El recepcionista est´ autenticado en el sistema y hay un cliente como usuario
a
efectivo.
Postcondiciones: El cliente deja de ser el usuario efectivo de la aplicaci´n.
o
Flujo b´sico:
a
1 El recepcionista quiere salir de la cuenta de un cliente.
2 El sistema pide al recepcionista que confirme que desea salir de la cuenta del
cliente.
3 El recepcionista confirma que desea salir.
4 El sistema procesa la petici´n y el cliente deja de ser el usuario efectivo de
o
la aplicaci´n.
o
Flujo alternativo:
*.1 En cualquier momento el recepcionista tiene la posibilidad de cancelar el
proceso.

81. 5.3. Casos de Uso
49
15. Dar de Alta Cliente
Actores Primarios: Recepcionista
Descripci´n: Permite al recepcionista dar de alta a un nuevo cliente en el sistema cuando
o
llega al hotel para realizar una reserva.
Precondiciones: El recepcionista est´ autenticado en el sistema.
a
Postcondiciones: El nuevo cliente pasa a estar registrado en el sistema y es usuario efectivo del
mismo.
Flujo b´sico:
a
1 El recepcionista quiere dar de alta al nuevo usuario en el sistema.
2 El sistema pide al recepcionista que introduzca los siguientes datos de los
cuales algunos son obligatorios:
• Nombre (obligatorio)
• Apellidos (obligatorio)
• DNI o pasaporte (obligatorio)
• Fecha de Nacimiento (obligatorio)
• Direcci´n completa (obligatorio)
o
• Pa´ (obligatorio)
ıs
• Direcci´n de e-mail (obligatorio)
o
• Tel´fono1 (opcional)
e
• Tel´fono2 (opcional)
e
3 El recepcionista introduce los datos solicitados.
4 El recepcionista confirma que desea dar de alta al nuevo cliente.
5 El sistema procesa la informaci´n del nuevo cliente.
o
6 El nuevo cliente pasa a estar dada de alta como cliente y es usuario efectivo
del sistema en ese momento.