PROYECTO FIN DE CARRERA. Aplicación web para la gestión de un hostal-restaurante

Transcripción

1 PROYECTO FIN DE CARRERA Título Aplicación web para la gestión de un hostal-restaurante Autor/es Pablo Cacho Zueco Director/es Laureano Lambán Pardo Facultad Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación Proyecto Fin de Carrera Departamento Matemáticas y Computación Curso Académico

2 Aplicación web para la gestión de un hostal-restaurante, proyecto fin de carrera de Pablo Cacho Zueco, dirigido por Laureano Lambán Pardo (publicado por la Universidad de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright. El autor Universidad de La Rioja, Servicio de Publicaciones, 2013 publicaciones.unirioja.es publicaciones@unirioja.es

3 UNIVERSIDAD DE LA RIOJA Facultad de Ciencias, Estudios Agroalimentarios e Informática PROYECTO FIN DE CARRERA Ingeniería Técnica en Informática de Gestión Aplicación web para la gestión de un hostalrestaurante. Alumno: Pablo Cacho Zueco Director: Laureano Lambán Pardo Logroño, Junio de 2013

4 RESUMEN En este proyecto se quiere realizar una aplicación web para gestionar y explotar un hostal restaurante. La aplicación creada permitirá realizar una gestión de usuarios, de pedidos al restaurante y será capaz de proporcionar un sistema de reservas de habitaciones y mesas. Este sistema permitirá a los clientes realizar pedidos online o reservar una habitación para unas fechas concretas. Se le podrá pedir también a la aplicación que muestre una serie de gráficas de estadísticas con datos relacionados con el negocio. Esta aplicación no está destinada a un cliente concreto pero puede ser fácilmente adaptable a multitud de pequeños y medianos hostales que buscan mostrarse en Internet.

5 ÍNDICE DE CONTENIDO TABLA DE CONTENIDO 1 Introducción Tema tratado Motivo de la elección Límites Documento de Objetivos Objeto Antecedentes Alcance Entregables Metodología de desarrollo Tecnologías y herramientas a usar Recursos humanos y comunicaciones Riesgos y planes de acción Posibles riesgos Planes de acción Tareas Plan de trabajo y temporización Calendario de trabajo Estimación temporal Diagrama Gantt Gestión de proyecto Introducción Factores de retraso Primera replanificación Segunda replanificación Comparación estimado con resultados finales Comparación fechas Comparación horas Análisis de requisitos Introducción I

6 4.1.1 Objetivo Ámbito Referencias Visión general del documento Descripción general Perspectiva del producto Funciones del producto Características de los usuarios Restricciones Requisitos específicos Requisitos funcionales Requisitos de interfaz gráfica Requisitos de seguridad Interfaces Externas Casos de Uso Generales Struts Introducción Arquitectura MVC Introducción Vista Modelo Controlador Componentes Struts API Archivos de configuración Etiquetas JSP Funcionamiento Struts Ciclo Análisis Ciclo Análisis de requisitos Introducción Usuarios involucrados Requisitos involucrados Casos de Uso II

7 6.2 Diseño Ciclo Diseño de la arquitectura Introducción Arquitectura aplicada a nuestro sistema Clases de negocio Introducción Objetos de negocio Clase de persistencia ActionForms Actions Diseño de la base de datos Introducción Requisitos de la base de datos Diagrama de entidad-relación Conversión a modelo relacional Diagrama de tablas final Interfaces gráficas definitivas Login de usuario Registro de usuario Búsqueda de Usuario Administración Usuario Perfil de usuario Implementación Ciclo Tecnologías empleadas Estructura de carpetas Seguridad Código destacable Pruebas Ciclo Introducción Validación de formularios Pruebas Unitarias Clases de equivalencia Casos de prueba Resultado de pruebas III

8 7 Ciclo Análisis Ciclo Análisis de requisitos Introducción Usuarios involucrados Requisitos involucrados Casos de Uso Diseño Ciclo Diseño de la arquitectura Introducción Clases de negocio Introducción Objetos de negocio Clases de Persistencia ActionForms Actions Diseño de la base de datos Introducción Requisitos de la base de datos Diagrama de entidad-relación Conversión a modelo relacional Diagrama de tablas final Interfaces gráficas definitivas Implementación Ciclo Tecnologías empleadas Estructura de carpetas Código destacable Pruebas Ciclo Introducción Validación de formularios Pruebas Unitarias Clases de equivalencia Casos de prueba Resultado de las pruebas Ciclo IV

9 8.1 Análisis Ciclo Análisis de requisitos Introducción Usuarios involucrados Requisitos involucrados Casos de Uso Diseño Ciclo Diseño de la arquitectura Introducción Clases de negocio Introducción Objetos de negocio Clases de Persistencia ActionForms Actions Diseño de la base de datos Introducción Requisitos de la base de datos relativos al ciclo Diagrama de entidad-relación Conversión a modelo relacional Diagrama de tablas final Interfaces gráficas Gráfica representativa de ocupación del hostal un determinado año Gráfica representativa de ocupación del hostal un determinado día Menú principal de la gestión de habitaciones y comedor Página de selección de fechas para una reserva de habitación Parte de la página de creación de gráficas estadísticas Implementación Ciclo Tecnologías empleadas Estructura de carpetas Código destacable Pruebas Ciclo Introducción Validación de formularios Pruebas Unitarias V

10 Clases de equivalencia Casos de prueba Resultado pruebas Pruebas finales Pruebas de integración Pruebas de sistema Conclusiones Comparativa entre objetivos y resultados obtenidos Posibles mejoras y ampliaciones Visión personal Glosario de términos Bibliografía Anexos Diseño Web Introducción Proceso Imágenes Ley orgánica de protección de datos Manual de instalación y despliegue Introducción Requisitos Base de datos, mysql y apache Instalación de servidor de aplicaciones web y despliegue Manual de administrador y usuario Introducción Visitante Usuario admingeneral admincocina adminrecepción VI

11 ÍNDICE DE ILUSTRACIONES Ilustración 1: Esquema división de tareas... 9 Ilustración 2: Esquema división de tareas por ciclo Ilustración 3: Tabla de duraciones estimadas Ilustración 4: Diagrama Gantt Inicial Ilustración 5 : Diagrama de Gantt Ciclo Ilustración 6: Diagrama Gantt Ciclo Ilustración 7: Diagrama Gantt Ciclo Ilustración 8: Diagrama Gant Replanificación Ilustración 9: Diagrama Gantt Replanificación Ilustración 10: Tabla Comparativa de fechas Ilustración 11: Tabla Comparativa de horas Ilustración 12: Gráfica comparación horas Ilustración 13: Diagrama Casos de Uso General Ilustración 14: Esquema MVC Ilustración 15: Estructura XML form-bean Ilustración 16: Esquema estructural Struts Ilustración 17: Diagrama Casos Uso Ciclo Ilustración 18: Diagrama Actividad Modificar usuario Ilustración 19: Diagrama Clases Usuarios Ciclo Ilustración 20: Diagrama Clases 2 Ciclo Ilustración 21: Diagrama Clase LoginBD Ilustración 22: Diagrama Clase UsuariosBD Ilustración 23: Esquema FormBeans Ciclo Ilustración 24: Tabla Actions Ciclo Ilustración 25: Esquema EER Ciclo Ilustración 26: Diagrama Tablas Ciclo Ilustración 27: Interfaz login de usuario Ilustración 28: Interfaz registro de usuario Ilustración 29:Interfaz Búsqueda de usuarios Ilustración 30: Interfaz administración de usuarios Ilustración 31:Interfaz datos de usuario Ilustración 32: Código Hibernate Filtrar Usuarios Ilustración 33: Código Login Usuario Action Ilustración 34: Código Login Usuario BD Ilustración 35: Código Javascript confirmación borrado de usuario Ilustración 36: Código html confirmación borrado de usuario Ilustración 37: Interfaz validación login Ilustración 38: Interfaz validación captcha Ilustración 39: Diagrama Casos Uso Ciclo Ilustración 40: Diagrama Secuencia Realizar Pedido VII

12 Ilustración 41: Diagrama clases ciclo Ilustración 42: Diagrama Clases BD Ciclo Ilustración 43:Diagrama FormBeans Ciclo Ilustración 44: Esquema EER Ciclo Ilustración 45: Esquema Tablas Ciclo Ilustración 46: Interfaz Carta productos Ilustración 47:Interfaz carro pedido Ilustración 48: Interfaz Resumen confirmación pedido Ilustración 49: Interfaz Configuración pedidos Ilustración 50: Código carro html Ilustración 51: Código DisplayTag Ilustración 52: Interfaz validación formulario alta producto Ilustración 53: Diagrama Casos Uso Ciclo Ilustración 54:Diagrama Secuencia Reserva Habitación Ilustración 55: Diagrama secuencia Reserva sitio restaurante Ilustración 56: Diagrama Casos Uso Estadísticas Ilustración 57: Diagrama Clases Ciclo Ilustración 58: Diagrama Clases BD Ciclo Ilustración 59: Tabla Actions Habitaciones Ilustración 60: Tabla Actions Reservas Habitaciones Ilustración 61: Tabla Actions Reservas Comedor Ilustración 62: Tabla Actions Estadísticas Ilustración 63: Esquema EER Ciclo Ilustración 64: Diagrama Tablas Ciclo Ilustración 65: Interfaz Gráfica Tipo Ocupación hostal Ilustración 66: Interfaz Gráfica % Ocupación Hostal Ilustración 67: Interfaz Administración hostal Ilustración 68: Interfaz Elección Fechas Reserva Habitación Ilustración 69: Interfaz Generación Gráficas Ilustración 70: Código Action Gráfica Ilustración 71: Interfaz Calendario Ilustración 72: Código envío Ilustración 73: Recorte de pantalla de Xampp Ilustración 74: Recorte de myphpadmin Ilustración 75 : Pantalla del servidor GlassFish Ilustración 76: Pantalla de información del hostal Ilustración 77: Pantalla de registro de usuario Ilustración 78: Perfil de usuario Ilustración 79: Listado de productos a la venta Ilustración 80: Resumen del pedido Ilustración 81: Elección de fechas de reserva de habitación Ilustración 82: Habitaciones libres para unas fechas Ilustración 83: Resumen de reserva de habitación Ilustración 84: Elección de datos para reserva de comedor VIII

13 Ilustración 85: Confirmación de reserva de comedor Ilustración 86: Pantalla de listados de pedidos Ilustración 87: Pantalla de listados de reservas Ilustración 88: Pantalla de administración de usuarios Ilustración 89: Pantalla de listado de usuarios Ilustración 90: Pantalla de administración del hostal Ilustración 91: Página de generación de gráficas Ilustración 92: Menú administración cocina Ilustración 93: Pantalla administración de pedidos Ilustración 94: Pantalla de finalización de pedido Ilustración 95: Configuración de sistema de pedidos Ilustración 96: Pantalla de administración de comedor Ilustración 97: Listado de reservas de comedor Ilustración 98: Finalización de reserva de comedor Ilustración 99: Menú administración de la recepción Ilustración 100: Listado de reservas de habitación abiertas Ilustración 101: Resumen de reserva de habitación a finalizar IX

14 1. INTRODUCCIÓN 1.1 TEMA TRATADO Este proyecto pretende abordar el desarrollo de una aplicación web que sirva de ayuda en la gestión de un hostal restaurante. La aplicación ofertará unos servicios a los clientes interesados en hacer un pedido de restaurante, reservar una habitación o una mesa. También mostrará una serie de gráficas estadísticas y unos historiales de reservas o pedidos. 1.2 MOTIVO DE LA ELECCIÓN El motivo de elegir este proyecto fue debido a que prefería terminar la carrera haciendo algo relacionado con la programación web. La elección del tema de hostal-restaurante no tiene una causa concreta, simplemente me pareció un tema interesante al haber miles de pequeños hostales con servicio de restaurante a los que podría ser útil una aplicación de este estilo. Asimismo me resultaría útil ya que la programación web está muy demandada y tiene bastantes salidas en la actualidad. Esto es debido al aumento del acceso y uso de internet que ha hecho que multitud de empresas quieran hacer negocio mediante un portal web. 1.3 LÍMITES Los límites de este proyecto serán puestos por nosotros mismos al no tener un cliente concreto que nos marque las directrices. El problema estará tanto en no quedarse corto en los requisitos del sistema ni tampoco pasarse a la hora de fijar los objetivos. Se buscará un término medio dictando unos mínimos aceptables que debe tener todo proyecto fin de carrera y que den lugar a una aplicación bastante completa. 1

15 2. DOCUMENTO DE OBJETIVOS 2.1 OBJETO El objetivo del proyecto es la creación de un portal web para la gestión, control y explotación de un hostal restaurante. Esta aplicación contará con diferentes secciones dirigidas a distintos tipos de usuario según el uso que le vayan a dar, desde los administradores del hostal hasta internautas que se registran en la web para poder acceder a diferentes servicios que ofrece el hostal-restaurante. A pesar de basarse en un caso bastante concreto se pretende buscar en la medida de lo posible, generalidad y fácil adaptación a otros posibles hostales o negocios similares. 2.2 ANTECEDENTES Con el boom de Internet se han extendido de manera muy rápida multitud de negocios que tratan de ganar mercado ofertándose en la web. Entre ellos en España destacan los relacionados con el turismo y la gastronomía. Así que no es difícil encontrarse con varias soluciones en el mercado parecidas a lo que se quiere hacer en este proyecto. Por ejemplo, en el ámbito de sistemas para gestionar hostales u hoteles podemos ver: Páginas con buscadores tipo No se pretende hacer nada revolucionario sino que la motivación reside en ser capaz de plantear y finalizar algo parecido. Como novedad podemos decir que así como hay multitud de webs de reservas de hostal, no es tan fácil encontrar webs que combinen la reserva de habitaciones junto con un servicio de restaurante y pedidos. Esto unido a la personalización con información general de un hostal nos hace creer que puede resultar interesante continuar con la idea de la creación del proyecto a pesar de las alternativas disponibles. 2.3 ALCANCE La aplicación atenderá las peticiones de diferentes roles de usuarios. A continuación se enumeran las funciones que deberán ser cubiertas: Mostrar información del hostal: tarifas, situación geográfica, habitaciones. Gestión de reservas online: habitaciones y comedor. Gestión de pedidos de productos de restaurante online. 2

16 Gestión de usuarios: registro obligatorio de clientes para reservas y pedidos, diferentes permisos para el personal y administradores del hostal. Historiales: historial de pedidos, reservas de habitaciones y reservas de mesas del comedor. Estadísticas: diferentes gráficas con estadísticas del hostal-restaurante. No se abordarán temas como las transacciones económicas con los clientes, ni la gestión de stock y productos usados en el hostal. La aplicación contará con una base de datos donde se guardarán todos los registros necesarios para el correcto funcionamiento del servicio. 2.4 ENTREGABLES Los entregables del proyecto serán: Memoria. Código fuente. Manual de instalación. 2.5 METODOLOGÍA DE DESARROLLO Se usará como metodología de desarrollo el Proceso Unificado. Se ha escogido ya que se considera que es la que mejor se adaptará a las necesidades del proyecto y por ser la que más se ha incidido en las asignaturas de la carrera. El utilizar un ciclo de vida iterativo e incremental permitirá añadir y mejorar la aplicación a la vez que crece obteniendo en cada ciclo un producto funcional. Los esquemas y diagramas se harán fundamentalmente en UML. 2.6 TECNOLOGÍAS Y HERRAMIENTAS A USAR Durante la creación del proyecto se van a utilizar las siguientes herramientas: Java EE -> Plataforma de Programación para desarrollar software. JSP -> Tecnología Java que permite generar código dinámico en la web. Se ha preferido elegir JSP por encima de PHP debido al interés en profundizar más en este lenguaje. JDBC -> API para ejecutar operaciones sobre bases de datos bajo el lenguaje Java. MySQL -> Sistema gestor de bases de datos libre, se ha elegido por su alta difusión y uso en la programación web. Glassfish Server-> Servidor que permitirá desplegar y ejecutar nuestras aplicaciones. Struts -> Framework que implementa el patrón MVC. Se desea usarlo debido a que en 3

17 la carrera se incide en una programación más pura y vendrá bien aprender algo más práctico como es el uso de Frameworks. Poseidon -> Potente software para generar diagramas UML 2.7 RECURSOS HUMANOS Y COMUNICACIONES En el desarrollo del proyecto participarán las siguientes personas: Pablo Cacho: alumno de ITIG, será el desarrollador único y principal, se encargará de la creación, documentación y presentación de todo el proyecto. Laureano Lamban: director del alumno. Durante el periodo que dure el proyecto, alumno y tutor se comunicaran mediante y podrán concertar diferentes reuniones en el despacho del profesor para comprobar el avance del proyecto o resolver dudas. 2.8 RIESGOS Y PLANES DE ACCIÓN Se van a tratar de identificar los factores que puedan suponer retrasos y demoras en el desarrollo del proyecto. Además de clasificar estos riesgos se propondrán unos planes de acción con las medidas a tomar para contrarrestarlos POSIBLES RIESGOS 1. El primer factor sería la inexperiencia del alumno en la creación de proyectos del tamaño requerido para este proyecto fin de carrera. Esta inexperiencia podrá suponer una mala planificación de fechas al calcular mal el tiempo exigido para cada tarea. 2. El segundo factor es el desconocimiento de alguna de las herramientas a utilizar. Esto podría suponer un estancamiento en el desarrollo de alguna tarea. 3. Otro factor clave son las causas de índole personal. Pueden surgir impedimentos de trabajo, enfermedades, viajes que resten horas de desarrollo al alumno. 4. Problemas de hardware o software que supongan una pérdida de datos o tiempo al tener que desplegar todas las herramientas del proyecto en otro ordenador distinto al habitual. 5. También puede ocurrir que una vez finalizado el proyecto no sea del agrado del director PLANES DE ACCIÓN 4

18 A continuación se van a exponer los planes de acción resultantes a los riesgos planteados en el apartado anterior: 1. Se buscará información y se consultará otros proyectos parecidos con el fin de obtener más idea sobre los tiempos que requiere un proyecto de estas características. 2. Para evitar retrasos debido al uso de nuevas herramientas se planificará un tiempo de aprendizaje y recogida de información y ejemplos de las principales herramientas a utilizar. 3. Los factores personales son más difíciles de detectar, en este caso se hará uso de la replanificación de tareas y horas dedicadas al proyecto. 4. Para evitar la pérdida de datos se utilizarán como respaldo pendrives y un sistema de almacenamiento de datos en la nube como DropBox. 5. Se irá enseñando el proyecto conforme aumenten las funcionalidades. 2.9 TAREAS El proyecto se va a descomponer en una serie de tareas bien diferenciadas como forma de ordenar todo lo que se debe hacer y poder asignar unos tiempos a cada una de ellas. Se mostrarán a continuación la descripción de estas tareas y unos esquemas representativos. TAREA 1: SEGUIMIENTO DEL PROYECTO La tarea número 1 es la relativa al control y revisiones del proyecto a lo largo de todo su desarrollo. Esta tarea tiene el objetivo de mantener un seguimiento periódico de los plazos y los posibles cambios en la planificación mediante revisiones. TAREA 2: GENERACIÓN MEMORIA La segunda tarea va a estar dedicada a la generación de la memoria del proyecto. Durante la creación de la aplicación se debe documentar las decisiones tomadas, el modo en el que hemos hecho el proyecto usando las técnicas de desarrollo vistas durante la carrera. Se ha dividido en 6 subtareas: Creación DOP: El Documento de objetivos del proyecto es uno de los más importantes, por esto ha sido incluido como una subtarea a destacar. Ciclo 1, Ciclo 2 y Ciclo 3: Partes de la memoria referidas a cada ciclo. Redacción resto memoria: Partes de la memoria no contenidas en las anteriores. Por ejemplo posibles anexos, introducción, conclusiones 5

19 Revisión memoria: En esta subtarea se revisará toda la memoria para detectar posibles errores antes de la entrega. TAREA 3: PREPARACIÓN PREVIA La tercera tarea que se ha identificado es la preparación previa. Esta tarea está sobretodo enfocada al estudio previo de las herramientas no vistas hasta ahora. Se estudiará que sistema se quiere crear, qué herramientas se pueden usar para llevar a cabo con éxito el proyecto. Y se comprobará la viabilidad viendo si es posible hacer el proyecto con las herramientas encontradas. Está separada en 3 subtareas: Estudio del sistema: Se mirará que tipo de sistema se desea crear y que herramientas hay disponibles para realizarlo. Estudio de herramientas: Se estudiarán las herramientas que se han considerado idóneas para el desarrollo del proyecto si no se han utilizado nunca antes. Estudio viabilidad: Se comprueba que el proyecto se puede realizar con las herramientas estudiadas. TAREA 4: ESPECIFICACIÓN DE REQUISITOS Esta cuarta tarea es la creación del documento de requisitos. Se extraen en él todos los requisitos fundamentales que debe cumplir el sistema. Se enumerarán y describirán correctamente para identificarlos a medida que vayamos avanzando en el proyecto. TAREA 5, 6 Y 7: CICLO 1, CICLO 2 Y CICLO 3 Las tareas 5, 6 y 7 se agrupan debido a las similitudes entre las tres. Representan a cada uno de las iteraciones del proyecto. Al final de cada ciclo se tendrá una aplicación parcial pero funcional. Cada tarea y ciclo consta de Análisis, Diseño, Implementación y Pruebas. TAREA 8: PRUEBAS FINALES La tarea de pruebas finales es la que se realizará una vez que los 3 ciclos estén concluidos. Tiene como misión detectar fallos que se hayan pasado por alto y hacer nuevas pruebas al ejecutar los 3 ciclos conjuntamente. 6

20 Además servirá para dar por finalizada toda la implementación y para poder afirmar que el sistema cumple todos los requisitos planteados al comienzo del proyecto. TAREA 9: DOCUMENTACIÓN FINAL La novena tarea es la redacción de un manual de instalación de la aplicación. Este manual servirá para explicar cómo desplegar el proyecto correctamente en un equipo. TAREA 10: DEFENSA La última tarea será la relacionada con la defensa del proyecto del alumno. Se creará una presentación para mostrar el resumen de todo el proceso de creación del proyecto. Y finalmente se realizará la defensa ante los miembros del tribunal. 7

21 Ilustración 1: Esquema división de tareas 9

22 Ilustración 2: Esquema división de tareas por ciclo 9

23 2.10 PLAN DE TRABAJO Y TEMPORIZACIÓN CALENDARIO DE TRABAJO En el momento que se ha hecho la planificación se dispone de disponibilidad total para realizar el proyecto. Se pondrá un horario de trabajo de varias horas al día dedicadas al mismo. Si hubiera algún cambio en el transcurso del proyecto se indicaría en el apartado de replanificación en gestión de proyecto ESTIMACIÓN TEMPORAL En la siguiente tabla se observan las diferentes tareas y unas fechas y horas aproximadas para su realización, en la parte de arriba de cada sección se muestran las horas acumuladas y abajo las horas desglosadas: TAREAS DURACIÓN ESTIMADA (horas) INICIO PREVISTO FIN PREVISTO Seguimiento del proyecto 16 16/02/12 07/06/12 Reuniones 7 16/02/12 07/06/12 Planificación 9 16/02/12 07/06/12 Generación memoria /02/12 07/06/12 Creación DOP 14 16/02/12 20/02/12 Ciclo /02/12 23/03/12 Ciclo /03/12 23/04/12 Ciclo /04/12 03/06/12 Redacción resto memoria 10 03/06/12 05/06/12 Revisión memoria 6 05/06/12 07/06/12 Preparación previa 29 21/02/12 27/02/12 Estudio del sistema 3 21/02/12 21/02/12 Estudio de herramientas 25 22/02/12 27/02/12 Estudio viabilidad 1 27/02/12 27/02/12 Especificación de requisitos 6 28/02/12 28/02/12 Generación del documento de requisitos 6 28/02/12 28/02/12 10

24 Ciclo /02/12 23/03/12 Análisis 7 29/02/12 01/03/12 Casos de uso 2 29/02/12 29/02/12 Actividad y secuencia 5 01/03/12 01/03/12 Diseño 35 02/03/12 10/03/12 Diseño clases de negocio 8 02/03/12 05/03/12 Identificar clases y métodos 4 02/03/12 02/03/12 Diagrama de clases 4 05/03/12 05/03/12 Diseño BD 4 06/03/12 06/03/12 Creación diagrama ER 4 06/03/12 06/03/12 Diseño Web 23 07/03/12 10/03/12 Identificar páginas 3 07/03/12 07/03/12 Diseñar páginas 20 08/03/12 10/03/12 Implementación 95 12/03/12 22/03/12 Implementar código 90 12/03/12 22/03/12 Implementar BD 3 12/03/12 22/03/12 Documentar código y BD 2 12/03/12 22/03/12 Pruebas 5 23/03/12 24/03/12 Pruebas unitarias 5 23/03/12 24/03/12 Ciclo /03/12 23/04/12 Análisis 11 26/03/12 27/03/12 Casos de uso 4 26/03/12 26/03/12 Actividad y secuencia 7 27/03/12 27/03/12 Diseño 30 28/03/12 04/04/12 Diseño clases de negocio 12 28/03/12 29/03/12 Identificar clases y métodos 7 28/03/12 28/03/12 Diagrama de clases 5 29/03/12 29/03/12 Diseño BD 5 30/03/12 30/03/12 Creación diagrama ER 5 30/03/12 30/03/12 Diseño Web 13 02/04/12 04/04/12 Identificar páginas 3 02/04/12 02/04/12 Diseñar páginas 10 02/04/12 04/04/12 11

25 Implementación /04/12 20/04/12 Implementar código /04/12 20/04/12 Implementar BD 3 05/04/12 20/04/12 Documentar código y BD 3 05/04/12 20/04/12 Pruebas 7 23/04/12 23/04/12 Pruebas unitarias 5 23/04/12 23/04/12 Pruebas integración 2 23/04/12 23/04/12 Ciclo /04/12 03/06/12 Análisis 19 24/04/12 26/04/12 Casos de uso 7 24/04/12 24/04/12 Actividad y secuencia 12 24/04/12 26/04/12 Diseño 33 27/04/12 03/05/12 Diseño clases de negocio 12 27/04/12 28/04/12 Identificar clases y métodos 7 27/04/12 27/04/12 Diagrama de clases 5 28/04/12 28/04/12 Diseño BD 6 30/04/12 30/04/12 Creación diagrama ER 6 30/04/12 30/04/12 Diseño Web 15 01/05/12 02/05/12 Identificar páginas 3 01/05/12 01/05/12 Diseñar páginas 12 01/05/12 02/05/12 Implementación /05/12 01/06/12 Implementar código /05/12 01/06/12 Implementar BD 3 03/05/12 01/06/12 Documentar código y BD 5 03/05/12 01/06/12 Pruebas 7 02/06/12 03/06/12 Pruebas unitarias 5 02/06/12 02/06/12 Pruebas integración 2 03/06/12 03/06/12 Pruebas finales 3 04/06/12 04/06/12 Pruebas de aceptación 3 04/06/12 04/06/12 Documentación final 4 04/06/12 06/06/12 Crear manual instalación 4 04/06/12 06/06/12 Defensa del proyecto 11 06/06/12 xx/06/12 12

26 Preparación 10 06/06/12 xx-6-12 Defensa 1 xx-6-12 xx-6-12 TOTAL /02/12 xx-6-12 Ilustración 3: Tabla de duraciones estimadas 2.11 DIAGRAMA GANTT A continuación se muestran varios diagramas de Gantt con la planificación inicial del proyecto. Ilustración 4: Diagrama Gantt Inicial Ilustración 5 : Diagrama de Gantt Ciclo 1 13

27 Ilustración 6: Diagrama Gantt Ciclo 2 Ilustración 7:Diagrama Gantt Ciclo 3 14

28 3. GESTIÓN DE PROYECTO 3.1 INTRODUCCIÓN El desarrollo del proyecto ha sido afectado por diversos factores que han condicionado mi dedicación al mismo. Debido a que no se han podido cumplir con las horas planificadas para la realización del proyecto se ha tenido que realizar unas replanificaciones ajustando nuevas fechas para la finalización de las tareas. 3.2 FACTORES DE RETRASO El motivo del retraso han sido tanto factores personales como de trabajo, que han hecho que no se pudieran dedicar en el proyecto las horas necesarias para su desarrollo. No he podido llevar un ritmo adecuado de horas diarias, lo que ha provocado un abandono del proyecto durante unos meses. Se ha producido también una lectura demasiado optimista de trabajo diario y no han sido cumplidas por mi parte las horas dedicadas. 3.3 PRIMERA REPLANIFICACIÓN En la replanificación se retocará las fechas de finalización de cada parte del proyecto afectado por el retraso. Las horas estimadas no necesitarán excesivos cambios. El proyecto estaba planificado para ser entregado en el curso pasado apurando la fecha límite de depósito, sin embargo, al no dedicar las horas diarias necesarias las fechas de finalización de las tareas se iban retrasando. Esto provocó que para la fecha final estimada en Junio, solo estuvieran finalizados los ciclos 1 y 2. Ilustración 8: Diagrama Gant Replanificación 1 15

29 3.4 SEGUNDA REPLANIFICACIÓN Con el ciclo 3 prácticamente acabado surgen nuevos problemas de trabajo en la dedicación al proyecto. Se retrasa y paraliza durante meses y se fija la finalización y entrega para principios de Junio de El número de horas estimadas no es muy distinto del real, lo que varía mucho es el número de horas diarias dedicadas. Ilustración 9: Diagrama Gantt Replanificación COMPARACIÓN ESTIMADO CON RESULTADOS FINALES COMPARACIÓN FECHAS Tarea Fecha fin estimada Fecha fin replanificación 1 Fecha fin replanificación 2 Fecha final real Seguimiento 07/06/12 10/09/12 31/05/13 23/06/13 Memoria 07/06/12 10/09/12 31/05/13 23/06/13 Preparación 27/02/ /03/12 Requisitos 28/02/ /03/12 Ciclo 1 24/03/ /04/12 Ciclo 2 23/06/ /06/12 Ciclo 3 03/06/12 03/09/12 24/05/13 01/06/13 Pruebas 03/06/12 05/09/12 31/05/13 23/06/13 finales Manual 07/06/12 08/09/12 31/05/13 23/06/13 Ilustración 10: Tabla Comparativa de fechas COMPARACIÓN HORAS Tarea Horas estimadas Seguimiento Memoria Preparación Horas reales 16

30 Requisitos 6 12 Ciclo Ciclo Ciclo Pruebas finales 3 4 Manual 4 3 TOTAL Ilustración 11: Tabla Comparativa de horas Ilustración 12: Gráfica comparación horas 17

31 2. ANÁLISIS DE REQUISITOS 4.1 INTRODUCCIÓN OBJETIVO Se pretende realizar una aplicación web que ayude en la gestión, administración y explotación de un hostal. A través del portal se mostrarán los servicios ofertados por el negocio con el fin de atraer nuevos clientes. Asimismo servirá para gestionar y llevar un mejor control del hostal guardando información sobre los hospedados y gestionando nuevos pedidos o reservas ÁMBITO La aplicación permitirá la gestión del hostal y de los usuarios registrados en el mismo. La gestión de reservas de habitaciones y reservas de sitio en el comedor. También se tramitarán los pedidos de productos que ofrece el restaurante. Además se mostrarán una serie de estadísticas al administrador general del hostal REFERENCIAS Se ha seguido la norma IEEE STD para la elaboración de esta especificación de requisitos VISIÓN GENERAL DEL DOCUMENTO En este documento se recogerán los requisitos que deberá satisfacer la aplicación una vez esté terminada. Debido a que es un proyecto de varios ciclos e incrementos aquí se van a citar unos requisitos generales que podrían ser retocados o depurados en cada una de las iteraciones del proyecto. 18

32 4.2 DESCRIPCIÓN GENERAL PERSPECTIVA DEL PRODUCTO El sistema no formará parte de ningún otro mayor, solo interaccionará con una base de datos MySQL para almacenar la información de los usuarios y el hostal FUNCIONES DEL PRODUCTO La aplicación constará de 2 funciones claramente separadas, la administración del hostalrestaurante y la explotación del mismo. En la primera participarán los administradores y en la segunda los usuarios que quieran acceder a algún servicio CARACTERÍSTICAS DE LOS USUARIOS Los usuarios que utilizarán el sistema podrán ser internautas que quieran hacer pedidos o reservas, adaptados ya a las nuevas tecnologías del comercio por Internet. Los otros usuarios serán los administradores del hostal, a los que la aplicación no les causará ninguna dificultad debido a su simplicidad. En los administradores separaremos estos 3 tipos: AdminGeneral: representaría al dueño del hostal, podrá ver estadísticas del mismo, así como controlar con la aplicación las habitaciones, los usuarios o el comedor del restaurante. AdminRecepción: estaría en la entrada del hostal, por lo que se ocuparía de la entrada y salida de clientes con reserva de habitación. AdminCocina: sería el encargado de gestionar los pedidos online y los productos ofertados para la compra. El control de las reservas del comedor también estaría en sus cometidos RESTRICCIONES Las restricciones serán el uso de contraseña para el acceso a la aplicación y el uso de roles como medio para mostrar a cada tipo de usuario unos menús distintos. 19

33 4.3 REQUISITOS ESPECÍFICOS A continuación se enumerarán los requisitos generales que deberá cumplir la aplicación una vez que esté terminada. Se empezará con los requisitos funcionales siguiendo con los relacionados con la interfaz y seguridad REQUISITOS FUNCIONALES La aplicación deberá ser capaz de poder efectuar las tareas de los siguientes requisitos: RF1 Introducción: Un visitante de la web podrá darse de alta en el sistema. Precondición: El visitante no debe estar dado de alta. Entradas: El visitante va a darse de alta. Procedimiento: El usuario informa al sistema de que tiene intención de registrarse e introduce sus datos. Salidas: Se dará de alta al usuario al que se le mandará un y se mostrará un mensaje confirmando el registro. RF2 Introducción: Un usuario podrá gestionar sus datos. Precondición: El usuario debe de estar dado de alta y debe haber iniciado sesión. Entradas: El usuario quiere ver/modificar sus datos o borrar su cuenta. Procedimiento: El usuario va a su perfil, donde hará los cambios y acciones oportunas. Salidas: Se realizará la acción correspondiente y se informará de la finalización con éxito de la misma. RF3 Introducción: Un administrador podrá gestionar usuarios. Precondición: El administrador debe de estar dado de alta y se debe haber logueado. Entradas: El administrador desea crear/modificar o borrar un usuario o listarlos. Procedimiento: El usuario va al apartado dedicado a la gestión de usuarios, donde hará la acción que desee. Salidas: Se realizará la acción indicada y se mostrará el éxito. RF4 Introducción: Un usuario podrá obtener una nueva contraseña. 20

34 Precondición: El usuario debe de estar dado de alta. Entradas: El usuario desea conseguir una nueva contraseña. Procedimiento: El usuario pide a la aplicación obtener una nueva contraseña. Salidas: Se cambiará la contraseña y se le enviará al usuario. RF5 Introducción: Un AdminCocina podrá gestionar los productos del hostal. Precondición: El AdminCocina debe de estar dado de alta y debe haber introducido su usuario y contraseña correctamente. Entradas: El administrador gestionará el alta, modificación o borrado de nuevos productos en el menú. Procedimiento: El administrador irá a la sección donde se gestiona los productos y ejecutará la acción deseada. Salidas: Se llevará a cabo la gestión y se mostrará la confirmación. RF6 Introducción: Un usuario podrá realizar un pedido online. Precondición: El usuario debe de estar registrado y debe haber iniciado sesión. Entradas: El usuario quiere hacer un pedido. Procedimiento: El usuario va a la sección donde se realizan los pedidos, donde ve los productos, selecciona los que quiera adquirir y confirma el pedido Salidas: Se registrará el pedido y se mandará un al cliente. RF7 Introducción: Un AdminCocina podrá procesar un pedido. Precondición: El AdminCocina debe de estar dado de alta y se debe haber logueado. Entradas: El administrador quiere marcar un pedido como ya entregado o cancelar uno existente. Procedimiento: El administrador va a la sección donde se muestran los pedidos sin finalizar, elige el deseado y lo finaliza. Salidas: Se finalizará el pedido y se mostrará la confirmación. RF8 Introducción: Un usuario podrá ver un listado de sus pedidos. Precondición: El usuario debe de estar registrado, se debe haber logueado y debe haber hecho algún pedido en el pasado. Entradas: El usuario quiere ver el listado de pedidos. 21

35 Procedimiento: El usuario va a la sección dedicada a sus pedidos donde verá la lista. Salidas: Se mostrará la lista. RF9 Introducción: Un AdminCocina podrá ver una lista de pedidos. Precondición: El AdminCocina debe de estar registrado y debe de haber iniciado sesión. Entradas: El administrador desea ver la lista. Procedimiento: El administrador va al apartado donde se muestran todos los pedidos. Salidas: Se mostrará el listado correspondiente. RF10 Introducción: Un admincocina podrá activar y desactivar en un momento determinado el sistema de pedidos de la web. Precondición: El admincocina debe de estar registrado y con la sesión iniciada. Entradas: El administrador quiere activar/desactivar el sistema de pedidos. Procedimiento: El administrador va a la sección de cocina donde activará o desactivará los pedidos. Salidas: La web permitirá hacer pedidos o no. RF11 Introducción: Un admincocina podrá determinar un horario de atención de pedidos online Precondición: El admincocina debe de estar registrado y con la sesión iniciada. Entradas: El administrador quiere establecer un horario de pedidos online. Procedimiento: El administrador elige una hora inicial y una final de atención de pedidos online. Salidas: La aplicación permitirá hacer pedidos o no en ese rango horario. RF12 Introducción: Un admincocina podrá establecer unos códigos postales a los que se podrán hacer entregas de pedidos a domicilio. Precondición: El admincocina debe de estar registrado y con la sesión iniciada. Entradas: El administrador quiere añadir o eliminar códigos postales. Procedimiento: El administrador va a la sección de cocina donde añadirá o eliminará los códigos. Salidas: Se avisará del cambio y la aplicación permitirá realizar pedidos a domicilio a las direcciones con esos códigos postales. RF13 22

36 Introducción: Un admingeneral podrá gestionar las habitaciones del hostal. Precondición: El admingeneral debe de estar dado de alta y con sesión iniciada. Entradas: El administrador quiere añadir/modificar/ver una habitación. Procedimiento: El administrador va a la sección de gestión del hostal donde elige y realiza la operación de actualización deseada. Salidas: Se hará la gestión y se confirmará la operación o simplemente se mostrará información. RF14 Introducción: Un cliente podrá reservar una habitación. Precondición: El cliente debe de estar registrado, con sesión iniciada y debe haber habitaciones libres en las fechas elegidas. Entradas: El cliente va a reservar una habitación. Procedimiento: El usuario va a la sección donde selecciona las fechas elegidas y la habitación. Salidas: Se realizara la reserva, se mostrará la confirmación y se mandará un al usuario. RF15 Introducción: Un AdminRecepción podrá procesar las reservas de habitaciones. Precondición: El AdminRecepción debe de estar dado de alta y se debe haber logueado. Entradas: El administrador quiere procesar una reserva. Procedimiento: El administrador va a la sección relativa a reservas donde elige la reserva para procesarla una vez esté ya finalizada o cancelada. Salidas: Se finalizará o cancelará la reserva y se mostrará el éxito de la operación. RF16 Introducción: Un usuario podrá ver un listado de sus reservas de habitaciones. Precondición: El usuario debe de estar dado de alta, se debe haber logueado correctamente y debe haber hecho alguna reserva de habitación en el pasado. Entradas: El usuario quiere ver el listado de sus reservas. Procedimiento: El usuario va a un apartado de reservas donde estará el listado con las suyas. Salidas: Se mostrará la lista de reservas de habitación del usuario. RF17 Introducción: Un AdminRecepción podrá ver un listado de todas las reservas de habitaciones. 23

37 Precondición: El AdminRecepción debe de estar dado de alta, se debe haber logueado correctamente y deben existir reservas de habitación. Entradas: El administrador quiere ver el listado de reservas. Procedimiento: El administrador va a una sección de reservas donde estará el listado con todas. Salidas: Se mostrará la lista de reservas de habitación. RF18 Introducción: Un cliente podrá hacer una reserva de mesa en el restaurante. Precondición: El cliente debe de estar registrado, con sesión iniciada y debe haber sitio suficiente sin ocupar en el comedor del restaurante. Entradas: El cliente va a reservar una mesa. Procedimiento: El usuario va a la sección de reservas de comedor donde selecciona la fecha elegida, el horario y el número de personas. Salidas: Se realizará la reserva, se mostrará la confirmación y se mandará un al usuario. RF19 Introducción: Un usuario podrá ver un listado de sus reservas en el restaurante. Precondición: El usuario debe de estar dado de alta, se debe haber logueado correctamente y debe haber hecho alguna reserva en el pasado. Entradas: El usuario quiere ver el listado de reservas. Procedimiento: El usuario va a un apartado de reservas de comedor, donde se le mostrarán todas. Salidas: Se mostrará la lista. RF20 Introducción: Un AdminCocina podrá ver el listado de reservas en el restaurante. Precondición: El AdminCocina debe de estar dado de alta, se debe haber logueado correctamente y debe existir alguna reserva de restaurante. Entradas: El administrador quiere ver el listado de reservas. Procedimiento: El administrador va a al de apartado de reservas de comedor donde se le mostrarán todas. Salidas: Se mostrará la lista de reservas completa. RF21 Introducción: Un AdminCocina podrá procesar las reservas del restaurante. Precondición: El AdminCocina debe de estar registrado y con la sesión iniciada, debe existir alguna reserva de restaurante pendiente. 24

38 Entradas: El administrador quiere gestionar una reserva de restaurante. Procedimiento: El administrador va a la sección de reservas de restaurante donde elige la reserva para procesarla, finalizándola como exitosa o cancelándola. Salidas: Se gestionará la reserva y se mostrará la confirmación de la acción. RF22 Introducción: Un AdminGeneral podrá modificar el tamaño del restaurante. Precondición: El AdminGeneral debe de estar dado de alta y se debe haber iniciado sesión correctamente. Entradas: El administrador quiere modificar el tamaño del comedor del restaurante puesto a disposición de ser reservado. Procedimiento: El administrador va a la sección de gestión del hostal referida al comedor donde modificará el tamaño. Salidas: Se modificará el tamaño y saldrá mostrada la confirmación. RF23 Introducción: Un admingeneral podrá ver una serie de estadísticas de su hostal. Precondición: El AdminGeneral debe de estar registrado y con la sesión iniciada. Entradas: El administrador quiere ver una gráfica de estadística. Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la estadística gráfica a visualizar. Salidas: Se mostrarán las estadísticas REQUISITOS DE INTERFAZ GRÁFICA Los requisitos siguientes estarán relacionados con la parte visual de la web: RI1 En la interfaz se mostrará información relativa al hostal como medio para atraer clientes y darlo a conocer. RI2 Se mostrará en todo momento en pantalla un enlace para que los usuarios puedan hacer desloguearse si han iniciado sesión. 25

39 4.3.3 REQUISITOS DE SEGURIDAD RS1 Para evitar registros masivos se utilizará un captcha en el formulario de registro de usuarios. RS2 La sesión de usuario debe caducar a los 10 minutos de inactividad INTERFACES EXTERNAS Los usuarios de la aplicación interactuarán con la interfaz por medio de un navegador web. 26

40 4.4 CASOS DE USO GENERALES A continuación se muestra el esquema general de casos de uso del sistema, sirve para hacerse una idea del alcance del mismo y de qué acciones puede realizar cada usuario. Ilustración 13: Diagrama Casos de Uso General Una breve explicación de cada caso de uso: Usuario: Gestionar sus datos -> Cada usuario de la aplicación podrá tener acceso a sus datos y modificarlos o borrar su cuenta. Reservar habitación -> Los usuarios podrán reservar una habitación si hay disponibles. Reservar mesa -> Los usuarios podrán hacer una reserva en el comedor del hostal siempre que haya sitio. Realizar pedido -> Asimismo podrán hacer un pedido con los productos ofertados en la web. Listar pedidos -> Se recupera un listado de pedidos del usuario y se pueden ver los detalles de cada pedido. Listar reservas habitación-> Se muestra un listado de reservas del usuario y sus detalles. 27

41 Listar reservas comedor -> Se muestran las reservas de comedor realizadas por el usuario. Visitante: Registro en Web-> Podrá registrarse y así en el futuro realizar las operaciones de Usuario. admingeneral: Gestionar habitaciones -> Aquí estarán todas las operaciones relativas a las habitaciones que el hostal pone a disposición en las reservas. Modificar comedor -> Aumentar o disminuir el tamaño del comedor. Gestionar usuarios -> Acciones sobre los datos de los usuarios registrados. Visualizar estadísticas -> Ver gráficos con estadísticas del hostal. admincocina: Gestionar productos -> Acciones sobre los productos que se ofertarán en la web. Procesar pedido -> Operaciones sobre los pedidos que han hecho los usuarios. Gestionar sistema pedidos -> Activar o desactivar el sistema de pedidos de la web para permitir realizar pedidos o no en un momento dado. Gestionar reservas de comedor -> Refleja las acciones para la administración de las reservas de sitio en el comedor. adminrecepción: Gestionar reservas de habitación-> Representa las acciones sobre las reservas de los usuarios. 28

42 5. FRAMEWORK: STRUTS 5.1 INTRODUCCIÓN Apache Struts es una herramienta de soporte basada en el patrón Modelo-Vista- Controlador que permite el desarrollo de aplicaciones web en Java. Struts provee un entorno que nos permitirá reducir el tiempo de desarrollo y nos brindará una correcta separación entre las distintas capas de la arquitectura MVC. Forma parte de Apache Struts Project y es de libre uso. 5.2 ARQUITECTURA MVC INTRODUCCIÓN El patrón de arquitectura MVC (Model-View-Controller) permite separar la lógica de negocio, los datos de la aplicación y la forma en la que se presentan esos datos al usuario. Se pueden diferenciar tres partes fundamentales: la vista, el modelo y el controlador VISTA Es la capa encargada de presentar al usuario la aplicación, recogiendo sus peticiones e interacciones con el sistema MODELO El modelo contiene la lógica de negocio donde se encuentran nuestros objetos representados. También contiene la persistencia, desde la cual tendremos acceso a nuestros datos para poder actualizarlos, eliminarlos, modificarlos y almacenarlos en nuestra base de datos CONTROLADOR Se encarga de controlar todo el flujo de la aplicación, redirigiendo todas las peticiones de los usuarios. El controlador debe poseer de algún mapa de correspondencias entre las peticiones que recibe y las respuestas a realizar. 29

43 Ilustración 14: Esquema MVC 5.3 COMPONENTES STRUTS Se puede separar claramente los componentes de Struts en tres tipos: API de Struts. Archivos de configuración. Etiquetas JSP API El API de Struts está formado por las distintas clases de apoyo que el framework pone a disposición de los programadores y diseñadores para facilitar el desarrollo y estructurar la aplicación. La clases a utilizar se encuentran en los paquetes: org.apache.struts.action y org.apache.struts.actions. A continuación se enumeran las principales clases de este API: ActionServlet: Es el componente Controlador (MVC) de Struts, es implementado mediante el servlet org.apache.struts.action.actionservlet.este servlet se encarga de recibir todas las entradas y peticiones HTTP de los clientes y delega el control de cada solicitud a una clase definida por el usuario del tipo org.apache.struts.action.action. Para ello el ActionServlet extrae la última parte de la URL y la contrasta con la información contenida en el archivo de configuración struts-config.xml, donde estará reflejado el objeto org.apache.struts.action.actionform a instanciar y la acción a realizar. Action: Tal como se ha apuntado arriba, los objetos Action son los responsables en realizar las peticiones que le delega el ActionServlet, para ello utilizan el método execute(). Este método será el que el programador deberá sobrescribir incluyendo 30

44 todas las instrucciones necesarias para que las peticiones se lleven a cabo correctamente. La acción actúa como un adaptador entre el contenido de una solicitud http y la lógica de negocio correspondiente. ActionForm: Los objetos ActionForm son un tipo JavaBean usados para transportar datos entre las distintas capas de la aplicación. Son usados por el ActionServlet para capturar los datos procedentes de un formulario y enviárselos al objeto Action que le corresponda. Los ActionForm constarán de los métodos get/set para poder y acceder y tratar la información que se obtienen de ellos. ActionMapping: Un objeto de este tipo representa una asociación entre una petición de usuario y el objeto Action que la tiene que procesar. Contiene la URL que provoca la ejecución de la acción y las posibles redirecciones a las distintas vistas a mostrar según le indique el Action. ActionForward: La clase ActionForward representa el destino al que el controlador debe enviar el control una vez que el Action se ha completado. De esta manera, cada vez que se quiera redirigir al usuario a una determinada página se hará usando un ActionForward ARCHIVOS DE CONFIGURACIÓN El archivo más importante de configuración de Struts que se va a utilizar es strutsconfig.xml que funciona como un enlace entre las capas de Modelo y Vista y define la lógica de presentación y navegabilidad de la aplicación Web. Es un archivo de tipo XML donde están registrados y configurados los distintos componentes de Struts que se utilizarán en la aplicación. Entre ellos podemos encontrar las siguientes entradas: form-beans de la aplicación: Los form-beans son instancias de una subclase de la clase ActionForm. action-mappings : Es la entrada del archivo de configuración que contiene las reglas de navegabilidad de la web. 31

45 Ilustración 15: Estructura XML form-bean Otros archivos de configuración son validator-rules.xml y validation.xml, que son utilizados para validar los campos de los formularios. Aunque en este proyecto se ha decidido validar los formularios sin utilizar estos recursos ETIQUETAS JSP Struts también ofrece una serie de etiquetas para facilitar el tratamiento de la información en las páginas JSP. El framework da recursos para evitar el uso de scriptlet (fragmentos Java dentro de JSP) y mejorar la compresión y mantenibilidad de las vistas. Proporciona etiquetas de HTML, bean, logic o nested. 5.4 FUNCIONAMIENTO STRUTS Una vez explicados de forma general los componentes de Struts se pasa a comentar el funcionamiento y las relaciones entre ellos. Cada vez que se hace una petición a la aplicación de Struts tiene lugar el siguiente proceso: 1. Analizar la URL: Se pasa la petición al objeto ActionServlet, éste analiza la URL para poder así determinar la acción a realizar. Normalmente se asigna al servlet que se ocupe de todas urls cuya terminación sea *.do. Cualquier URL que proceda del cliente y termine en.do provocará que la petición sea capturada por el servlet. Si tenemos una URL el ActionServlet se encargará de extraer la parte de URL que esté ligada al.do, en este caso /registro. 2. Determinar acción a realizar: Una vez conseguida la ruta /registro el ActionServlet consulta en el archivo struts-config.xml para determinar que acción debe hacer. Para cada acción el archivo de configuración contiene el objeto ActionForm asociado a la 32

46 operación y la clase Action que debe ser instanciada. Tras obtener los datos del archivo el ActionServlet: 1. Crea la instancia del objeto ActionForm y lo rellena con los datos obtenidos con el formulario que ha pulsado el usuario. 2. Crea una instancia del objeto Action requerido pasando como referencia el objeto ActionForm creado en el punto Procesar la petición: Dentro del método execute() del Action instanciado estará el código implementado con las operaciones a ejecutar, desde llamadas a métodos, almacenamiento de variables o todo aquello necesario para la correcta generación de las vistas (JSPs). 4. Generar la vista: Tras ejecutarse el método execute() devuelve al ActionServlet un objeto ActionForward que identifica que recurso se ha utilizado y que respuesta debe generarse. Finalmente el ActionServlet revisa de nuevo el archivo struts-config.xml y utiliza el valor previamente generado para redirigir a la dirección JSP correspondiente. Captura ejemplo de una declaración de Action en el archivo struts-xml En este caso si el alta de producto se produce correctamente el ActionServlet dirige la web a la página éxito.jsp. En caso contrario la redirige a altaproducto2.jsp Captura con los parámetros del método execute de una clase Action 33

47 Ilustración 16: Esquema estructural Struts 34

48 6. CICLO ANÁLISIS CICLO ANÁLISIS DE REQUISITOS INTRODUCCIÓN El primer ciclo del sistema va enfocado al tratamiento de datos de los usuarios registrados. Las altas, bajas, modificaciones o listados de los usuarios que más adelante harán uso de la aplicación USUARIOS INVOLUCRADOS En este apartado intervendrán admingeneral y Usuario (indirectamente adminrecepción y admincocina al ser un Usuario con más poderes). El admingeneral será el administrador que pueda modificar o borrar a los usuarios del sistema, dar de alta nuevos usuarios y administradores y listar usuarios con distintos filtros. El Usuario simplemente podrá tratar sus datos y cuenta REQUISITOS INVOLUCRADOS Trataremos en la sección con los requisitos funcionales planteados en el análisis de requisitos: RF1, RF2, RF3 y RF4 (ver en documento de requisitos, página 20). Se refinan los requisitos RF2 Y RF3: RF2.1 Introducción: Un usuario podrá ver sus datos. Precondición: El usuario debe estar dado de alta y debe haber iniciado sesión. Entradas: El usuario quiere ver sus datos de la cuenta. Procedimiento: El usuario va al apartado de la web donde se encuentran sus datos. Salidas: Se mostrarán los datos. 35

49 RF2.2 Introducción: Un usuario podrá modificar sus datos. Precondición: El usuario debe estar registrado y debe haber iniciado sesión. Entradas: El usuario quiere modificar sus datos de la cuenta. Procedimiento: El usuario va a la sección donde se encuentren los datos y modificará lo que desee. Salidas: Se modificarán los datos y se le indicará al usuario el éxito de los cambios. RF2.3 Introducción: Un usuario podrá borrar su cuenta. Precondición: El usuario debe estar dado de alta y debe haberse identificado correctamente. Entradas: El usuario desea borrar su cuenta. Procedimiento: El usuario va a la sección del portal donde confirmará que desea borrar su cuenta. Salidas: Será borrado el usuario y así se indicará. RF3.1 Introducción: Un administrador podrá crear usuarios. Precondición: El administrador debe estar dado de alta y debe haber hecho login. Entradas: El administrador quiere crear un nuevo usuario. Procedimiento: El administrador va a una sección donde rellenará los datos del usuario a crear. Salidas: Se creará el usuario y se informará. RF3.2 Introducción: Un administrador podrá modificar usuarios. Precondición: El administrador debe estar registrado y debe haber iniciado sesión. Entradas: El administrador quiere modificar a un usuario. Procedimiento: El administrador va a un apartado donde elegirá al usuario que quiere modificar, cambiará sus datos y los guardará. Salidas: Se realizarán las modificaciones y así se mostrará. RF3.3 Introducción: Un administrador podrá borrar usuarios. Precondición: El administrador debe estar registrado y debe haber iniciado sesión. Entradas: El administrador desea borrar a un usuario. Procedimiento: El administrador va al apartado de la web donde seleccionará al usuario que será borrado. Salidas: Se eliminará y se informará de que se ha borrado. 36

50 CASOS DE USO El siguiente esquema muestra el diagrama de casos de uso del Ciclo1 de la aplicación. Ilustración 17: Diagrama Casos Uso Ciclo 1 A continuación se van a enumerar y describir los distintos casos de uso de este primer ciclo: DARSE DE ALTA CASO DE USO: Descripción: Actores: Precondición: Postcondición: Darse de alta Usuario nuevo se registra Visitante Se almacenan los datos del visitante. 37

51 Escenario Principal: 1. Visitante introduce sus datos en un formulario. 2. Sistema registra esos datos y confirma el alta. 3. Termina caso de uso. Excepciones: Error en los datos introducidos en el formulario. VER SUS DATOS CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Ver sus datos Usuario registrado mira sus datos Usuario Usuario está registrado y ha iniciado sesión. Se muestran los datos. 1. Usuario solicita ver sus datos. 2. Sistema muestra datos. 3. Termina caso de uso MODIFICAR SUS DATOS CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Modificar sus datos Usuario modifica sus datos Usuario Usuario está registrado y ha iniciado sesión. Datos son actualizados. 1. Usuario modifica sus datos en el formulario. 2. Sistema actualiza datos y muestra la confirmación. 3. Termina caso de uso. Excepciones: Error en los datos introducidos en el formulario. DARSE DE BAJA CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Darse de baja Usuario se da de baja de la web. Usuario Usuario está registrado y ha hecho login correctamente. Todos los datos del usuario se borran 1. Usuario solicita borrar su cuenta. 2. Sistema pide contraseña. 3. Usuario escribe contraseña. 4. Sistema borra usuario y confirma la correcta eliminación. 5. Termina caso de uso. Excepciones: Error en la contraseña. 38

52 RECUPERAR CONTRASEÑA CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Recuperar contraseña Usuario consigue una nueva contraseña Usuario Usuario está registrado. Contraseña cambiada 1. Usuario solicita contraseña nueva. 2. Sistema pide datos al usuario. 3. Usuario escribe datos. 4. Sistema cambia contraseña y se la facilita al usuario. 5. Termina caso de uso. Excepciones: Error en los datos facilitados por el usuario. LISTAR USUARIOS CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Listar Usuarios Administrador desea listar todos los usuarios de la Web admingeneral Administrador está registrado en el sistema y ha iniciado sesión correctamente. Se muestra listado de usuarios. 1. Administrador solicita un determinado listado de usuarios. 2. Sistema muestra el listado 3. Termina caso de Uso. VER DATOS USUARIO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Ver Datos Usuario Administrador quiere obtener los datos de un usuario. admingeneral Administrador está registrado y ha iniciado sesión. Se muestra al usuario elegido. 1. Administrador pide listado de usuarios. 2. Sistema muestra lista de usuarios. 3. Administrador elige al usuario. 4. Sistema muestra usuario. 5. Termina caso de uso. Excepciones: 39

53 MODIFICAR DATOS USUARIO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Modificar Datos Usuario Administrador quiere modificar datos de un usuario. admingeneral Administrador está registrado y ha iniciado sesión. Usuario es modificado 1. Administrador pide listado de usuarios. 2. Sistema muestra lista de usuarios. 3. Administrador elige al usuario. 4. Sistema muestra usuario. 5. Administrador modifica usuario. 6. Termina caso de uso. Excepciones: Error en los datos introducidos en el formulario. Ilustración 18: Diagrama Actividad Modificar usuario 40

54 DAR DE ALTA USUARIO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Dar de Alta Usuario Administrador quiere dar de alta un nuevo usuario. admingeneral Administrador está registrado y se ha identificado correctamente. Usuario nuevo es creado. 1. Administrador introduce datos de usuario en formulario. 2. Sistema crea y añade al nuevo usuario. 3. Termina caso de uso. Excepciones: Error en los datos introducidos en el formulario. DAR DE BAJA USUARIO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Dar de Baja Usuario Administrador quiere borrar a un usuario. admingeneral Administrador está registrado y ha iniciado sesión. Usuario es borrado. 1. Administrador pide listado de usuarios. 2. Sistema muestra usuarios. 3. Administrador selecciona usuario. 4. Sistema muestra datos del usuario. 5. Administrador borra usuario. 6. Sistema borra al usuario del registro. 7. Termina caso de uso. 41

55 6.2 DISEÑO CICLO DISEÑO DE LA ARQUITECTURA INTRODUCCIÓN En esta sección se describirá el diseño de la arquitectura en la que estará basado nuestro sistema. El diseño está claramente influenciado por el uso de Struts que implementa el patrón MVC. Este patrón proporciona una clara separación en distintas capas de los componentes de la aplicación ARQUITECTURA APLICADA A NUESTRO SISTEMA La arquitectura empleada es una especialización de la usada tradicionalmente como capa de presentación, lógica de negocio y capa de persistencia. MODELO En el modelo se tiene toda la lógica de negocio y los objetos de los que se compone la aplicación. También está incluida la persistencia que se compondrá de varias clases Java encargadas de conectar con la base de datos. VISTA La vista se compondrá de páginas JSP (Java Server Pages). En estas páginas se mostrarán las salidas a las peticiones realizadas por los usuarios. Se intentará en medida de lo posible evitar el uso de fragmentos de código Java (Scriptlets) ya que sería código poco reutilizable y difícil de mantener. CONTROLADOR El controlador es la unión entre el modelo, que es donde se encuentran los datos, y la vista, que será donde serán mostrados esos datos. Se encargará de controlar el flujo de peticiones/respuestas entre el usuario y la aplicación. Para esta labor Struts cuenta con ActionServlet junto al archivo struts-config.xml 42

56 6.2.2 CLASES DE NEGOCIO INTRODUCCIÓN A continuación se mostrará el diseño de las clases de negocio de la aplicación en este primer ciclo. Las clases serán separadas en: Objetos de negocio Clases de persistencia ActionForms Actions Los objetos de negocio serán las clases generales que representarán la información con la cual es sistema opera. Las clases de persistencia serán aquellas encargadas en conectar e interactuar con la base de datos. Los ActionForm son clases que actúan como un almacén y guardan la información recogida en los campos de los formularios de la web. Esta información será tratada posteriormente en los Action. Los Action serán aquellas clases que servirán para realizar todas las operaciones de lo que sería la lógica de negocio OBJETOS DE NEGOCIO Se tendrá la clase Usuario con todos los datos de los usuarios registrados en la web, y las clases de tipos de administrador que heredan los métodos de la superclase. No se necesita ninguna información adicional de los administradores sobre los usuarios. Un Usuario podrá ser cualquier tipo de administrador a la vez o ninguno. Habrá también una clase TipoUsuario. Ésta es necesaria en la aplicación durante la muestra de los distintos tipos de usuario en algunas páginas con filtros por tipo de usuario. 43

57 Ilustración 19: Diagrama Clases Usuarios Ciclo 1 Están también las clases y EncriptadorSHA1. La primera clase se empleará para la creación y el envío de s a los usuarios, y el encriptador para convertir las contraseñas en una cadena SHA1 como medio de seguridad. Ilustración 20: Diagrama Clases 2 Ciclo 1 44

58 CLASE DE PERSISTENCIA Para poder efectuar cambios y operaciones con los datos almacenados en la base de datos, se necesitarán unas clases con acceso y privilegios suficientes. En este primer ciclo se utilizarán las clases UsuariosBD para todas las operaciones relativas a la gestión de los datos de los usuarios, LoginBD para la identificación de los usuarios y la clase ConexionBD para conectar con la base de datos. En las siguientes figuras se muestran los métodos que serán empleados para interactuar con ella. Ilustración 21: Diagrama Clase LoginBD 45

59 Ilustración 22: Diagrama Clase UsuariosBD ACTIONFORMS Los ActionForms usados en este ciclo serán: UsuarioActionForm: Este ActionForm guardará toda la información recogida en los formularios relativa a los datos de los usuarios. LoginActionForm: Será utilizado durante el proceso de login de usuarios donde deberán poner su usuario y contraseña en un formulario. ObtenerUsuariosActionForm: Servirá para guardar listados de usuarios y poder mostrarlos en la página web. RedirigirActionForm: Es necesario en ciertos aspectos de redirección de páginas de la aplicación. 46

60 Ilustración 23: Esquema FormBeans Ciclo ACTIONS En la tabla siguiente se enumerarán los Action creados para este ciclo junto a una breve descripción de cada uno. Action LoginAction ModificarUsuarioAction GetUsuariosAction FiltrarUsuariosAction RegistroWebAction BajaUsuarioAction DisplayDatosUsuarioAction BorrarUsuarioAction GetDatosUsuarioAction AltaUsuarioAction ModificarUsuarioAdminAction RecuperarPassAction Descripción Action usado durante el inicio de sesión de un usuario. Action empleado cuando un usuario modifica sus datos. Action empleado para listar todos los usuarios registrados. Action empleado para listar a los usuarios registrados según un filtro. Action utilizado en el registro de un nuevo usuario en la web. Action que se encarga de dar de baja a un usuario que borra su cuenta. Action que recupera los datos de un usuario elegido por el administrador y los muestra. Action empleado para el borrado de un usuario por parte de un administrador. Action para mostrar a un usuario sus datos. Action usado para realizar el alta de un usuario creado por un administrador. Action utilizado para ejecutar una modificación de usuario por parte del administrador. Action a usar durante el proceso de recuperación de contraseña. Ilustración 24: Tabla Actions Ciclo 1 47

61 6.2.3 DISEÑO DE LA BASE DE DATOS INTRODUCCIÓN A continuación se va a mostrar el diseño de la base de datos para el ciclo1. Conforme se vayan creando nuevos ciclos la BD se irá haciendo más grande para cubrir todas las necesidades de la aplicación REQUISITOS DE LA BASE DE DATOS Se quiere guardar información de todos los usuarios y administradores de la web. Interesaría guardar el nombre, apellidos, dirección, localidad, código postal, teléfono, , contraseña y fecha de ingreso de cada usuario. Para los administradores no se necesitaría ningún detalle más. Cada usuario tendrá un identificar único DIAGRAMA DE ENTIDAD-RELACIÓN DESCRIPCIÓN DEL DIAGRAMA. Se han elegido los nombres de las tablas y campos de forma bastante identificativa respecto a lo que representan. Las entidades creadas serán: Usuario: Representa a cualquier usuario almacenado en el sistema, contiene información común y es una superclase de los administradores. admingeneral: Serán los administradores generales del hostal, con mayores permisos que un simple usuario. No se guardará ninguna información adicional de ellos respecto a la de un usuario cualquiera. Hereda toda la información de Usuario. adminrecepción: Representará a los administradores de la recepción, al igual que admingeneral no se necesitará guardar ninguna información adicional propia. admincocina: Representa a los administradores de la cocina. Como con los otros dos tipos de administrador, sus datos estarán en la tabla usuario. 48

62 Ilustración 25: Esquema EER Ciclo CONVERSIÓN A MODELO RELACIONAL TABLAS RESULTANTES Durante la conversión a tablas han surgido algunas dudas pero al final se ha decidido apostar por el modelo mostrado en la figura de abajo. Se podía haber utilizado una sola tabla de usuario eliminando las de los administradores utilizando unos nuevos campos booleanos (esadmingeneral, esadmincocina, esadminrecepción). La razón por la que se ha decidido dejar las tablas separadas es pensando en una futura expansión de la aplicación donde se podría guardar más información de los administradores y habría que separar las tablas igualmente. 49

63 NORMALIZACIÓN Primera Forma Normal (1FN) Todas las tablas están en 1FN al no tener atributos multievaluados. Segunda Forma Normal (2FN) Las tablas también se encuentran en la 2FN al depender sus atributos no primos de la clave totalmente y cumplir la 1FN. Tercera Forma Normal (3FN) Igualmente también cumplen la 3FN ya que los atributos primos dependen de forma no transitiva de la clave. Claves candidatas En Usuario se ha decidido utilizar como clave primaria el atributo entero autoincrementado (ID). Teléfono y pasarán a ser columnas unique DIAGRAMA DE TABLAS FINAL A partir del diagrama EER anterior y la normalización se ha generado la siguiente estructura de tablas de la base de datos. 50

64 Ilustración 26: Diagrama Tablas Ciclo INTERFACES GRÁFICAS DEFINITIVAS Se van a mostrar algunas capturas de la aplicación referentes a este ciclo LOGIN DE USUARIO Pantalla de login, el usuario deberá identificarse con su teléfono y contraseña para poder acceder a algunas secciones de la web. Tendrá la opción de conseguir una contraseña nueva en el caso de que la haya olvidado facilitando correctamente su y teléfono. 51

65 Ilustración 27: Interfaz login de usuario REGISTRO DE USUARIO La pantalla de registro muestra los datos requeridos para registrarse, el captcha a rellenar y las condiciones ficticias de uso de la web. En el caso de que los datos introducidos sean erróneos se indicará en rojo el error del campo a corregir. 52

66 Ilustración 28: Interfaz registro de usuario BÚSQUEDA DE USUARIO En la pantalla de búsqueda de usuarios se distinguen 2 partes, los campos a rellenar que sirven de filtro y el listado de usuarios que cumplen el filtro de arriba. Los listados se pueden exportar en archivos.pdf o.xls para poder imprimirlos, guardarlos 53

67 Ilustración 29:Interfaz Búsqueda de usuarios 54

68 ADMINISTRACIÓN USUARIO La captura siguiente muestra el menú de administración general referente a la gestión de usuarios. Ilustración 30: Interfaz administración de usuarios PERFIL DE USUARIO En la pantalla de perfil de usuario simplemente se mostrarán sus datos y se le dará opción a modificarlos o borrar su cuenta. 55

69 Ilustración 31:Interfaz datos de usuario 56

70 6.3 IMPLEMENTACIÓN CICLO TECNOLOGÍAS EMPLEADAS La implementación de la aplicación ha sido realizada utilizando tecnología Java. Se ha usado además el framework Struts 1.3.1, que ha facilitado la tarea en algunos aspectos y ha marcado un camino a seguir en el diseño de la aplicación. Para la conexión la base de datos se ha utilizado JDBC con la excepción de un método que ha sido implementado mediante Hibernate, que es otro framework, desarrollado para la persistencia. El método concreto es uno que se necesitaban hacer consultas con filtros, para los que la tecnología JDBC debía usar muchísimas consultas distintas. Así que se usó como alternativa la opción de CRITERIA QUERIES de Hibernate que facilitaba mucho la tarea de añadir criterios de filtro en unas consultas SQL. Para mostrar listados en pantalla se ha empleado DisplayTag. Es una suite sencilla de utilizar para mostrar datos presentados en tablas y automáticamente ordenables y exportables. El captcha del apartado registro se hecho con jcaptcha. Es un sistema que nos permite usarlo como filtro ante ataques bot y que se integra bien junto a Struts. El desarrollo ha tenido lugar con el IDE Netbeans debido a su potencia y a sus ayudas para facilitar la generación de código y marcación de errores ESTRUCTURA DE CARPETAS En este primer ciclo la estructura de carpetas será muy simple. Por un lado estarán las carpetas que contendrán los archivos.java y en otro las carpetas con los.jsp Las principales carpetas serán: Objetos- Contendrá el código java de Usuario, AdminCocina, AdminGeneral, AdminRecepción, TipoUsuario, , EncriptadorSHA1... Forms- Esta carpeta tendrá los ActionForm, en este primer ciclo: UsuarioActionForm, LoginActionForm y ObtenerUsuariosActionForm Bd- Tendrá las clases relativas a la interacción con la base de datos: UsuariosBD, LoginBD, ConexionBD 57

71 actions.usuarios- Carpeta que contendrá los actions del primer ciclo enumerados en la tabla de la ilustración 24. Config- Carpeta donde estarán los archivos de configuración de la BD. Actions- Carpeta donde se ubicará la acción común de redirigir. Web/WEB-INF/Usuarios- Directorio con todas las páginas JSP referidas a este ciclo, con acceso restringido. Web- Carpeta con acceso público SEGURIDAD En la parte de seguridad de la aplicación se ha implementado el comentado captcha en la página de registro. Aparte de esto se han codificado las contraseñas mediante SHA1, de forma que nadie en la BD puede ver la contraseña original. Otra medida de seguridad de cara al usuario es que una vez logueado, al pasar 10 minutos inactivo se le cierra la sesión y se le manda a la página de login. Se ha implementado también unos accesos y vistas según el rol del usuario (usuario, administradores). Cada persona tendrá unas vistas en su web y no podrá acceder a donde no esté autorizado a entrar. Debido a que el alcance del proyecto no llega a los pagos por internet de los pedidos y reservas no se ha incidido mucho más en el tema de seguridad en la conexión CÓDIGO DESTACABLE En esta sección se expondrá parte de código fuente que se considera interesante destacar. HIBERNATE (LISTAR USUARIOS CON FILTRO) El poner en la búsqueda de usuarios 5 variables de filtrado suponía al principio hacer 2^5 consultas distintas comprobando cada campo del formulario. Para hacer más simple esta búsqueda con filtro era necesaria una alternativa. Como se ha explicado hace unos apartados, se ha decidido utilizar en este método Hibernate debido a su API Criteria, que permite utilizar Criteria Queries. Como se verá en el código siguiente, De esta forma se ahorra mucho trabajo a la hora de fijar filtros, simplemente añadiendo unos criterios a una variable de Criteria. 58

72 Como se puede ver en el código de abajo, para listar primero se comprueban los datos recogidos en el formulario (nombre, apellidos, , teléfono) y si no son nulos se añaden como restricciones que se deben cumplir. Tras esto se fija el tipo de usuario también seleccionado en el formulario de filtrado de la aplicación. Los usuarios que cumplen todas las restricciones se añaden a una lista que será la mostrada en la página. 59

73 Ilustración 32: Código Hibernate Filtrar Usuarios LOGIN DE USUARIO Básicamente lo que hace el código es recuperar los datos que ha captado el formulario de login y comprueba si esos datos encajan con los almacenados en la base de datos de la web. Hay que señalar que la contraseña está codificada en SHA1 y por lo tanto antes de comparar con la BD se debe encriptar esa clave. Si los datos coinciden se comprueba que rol de usuario posee el dueño de ese teléfono. Se guarda en la sesión el rol o roles que posee para mostrar unas partes de la web solo accesibles a administradores. Si el login es exitoso se redirige a index y si por el contrario es fallido se carga el error a mostrar en la página. 60

74 Ilustración 33: Código Login Usuario Action 61

75 Ilustración 34: Código Login Usuario BD JAVASCRIPT CONFIRMACIÓN ELIMINAR USUARIO El código correspondiente a este apartado sirve para pedir una segunda confirmación de que un usuario debe ser borrado por parte del administrador. Cuando se pulsa el botón para eliminarlo, se lanza el javascript que pregunta si está seguro. Ilustración 35: Código Javascript confirmación borrado de usuario 62

76 Ilustración 36: Código html confirmación borrado de usuario 63

77 6.4 PRUEBAS CICLO INTRODUCCIÓN Antes de dar por finalizado cada ciclo se deberá comprobar su correcto funcionamiento. Se probarán los formularios para evitar que ocurran fallos provocados por la unicidad de algún elemento de la base de datos o para comprobar bien los datos antes de que vayan a ser utilizados por los Action. Como es lógico también se testeará la aplicación para que se realicen correctamente las operaciones marcadas en los requisitos VALIDACIÓN DE FORMULARIOS Los datos de los formularios se validarán mostrando los errores que se hayan producido en la introducción de datos. Ejemplo de validación del formulario de login. Ilustración 37: Interfaz validación login 64

78 Ejemplo de validación con captcha del formulario de registro: Ilustración 38: Interfaz validación captcha 65

79 6.4.3 PRUEBAS UNITARIAS A continuación se van a probar aquellos casos en los que puede haber conflicto en la inserción de datos en la BD al existir restricciones de unicidad. Se contará con las siguientes clases de equivalencia y los correspondientes casos de prueba CLASES DE EQUIVALENCIA ALTA USUARIO Condición Clases válidas Clases no válidas Teléfono Unicidad Teléfono no existe (AU1) Teléfono existe (AU2) Unicidad no existe (AU3) existe (AU4) MODIFICACIÓN DE USUARIO Condición Clases válidas Clases no válidas Teléfono Unicidad Teléfono no existe (MU1) Teléfono existe (MU2) Unicidad no existe (MU3) existe (MU4) CASOS DE PRUEBA ALTA USUARIO Caso válido Prueba Unitaria 1 Descripción Entradas Alta de un nuevo usuario Nombre: Federico Apellidos: Lopera García Dirección: Gran Vía nº Logroño CP:"26006" Teléfono : Teléfono repetido: Federico@gmail.com 66

80 Clases equivalencia Resultado esperado de Contraseña: 1234 Contraseña repetida: 1234 Captcha: CORRECTO (AU1)(AU3) Operación exitosa Casos no válidos Prueba Unitaria 2 Descripción Entradas Clases equivalencia Resultado esperado de Alta de un nuevo usuario Nombre: Pedro Apellidos: Lopera García Dirección: Gran Vía nº Logroño CP:"26006" Teléfono : (existiendo) Teléfono repetido: pedro@gmail.com Contraseña: 1234 Contraseña repetida: 1234 Captcha: CORRECTO (AU2) Error, otro usuario tiene ese teléfono. Prueba Unitaria 3 Descripción Entradas Clases equivalencia Resultado esperado de Alta de un nuevo usuario Nombre: Jaime Apellidos: Lopera García Dirección: Gran Vía nº Logroño CP:"26006" Teléfono : Teléfono repetido: Federico@gmail.com (existiendo) Contraseña: 1234 Contraseña repetida: 1234 Captcha: CORRECTO (AU4) Error, otro usuario tiene ese . 67

81 MODIFICAR USUARIO Caso válido Prueba Unitaria 4 Descripción Entradas Clases equivalencia Resultado esperado de Modificación de usuario Nombre: Jaime Apellidos: Lopera García Dirección: Gran Vía nº Logroño CP:"26006" Teléfono : Teléfono repetido: Federico@gmail.com Contraseña: 1234 Contraseña repetida: 1234 (MU1)(MU3) Operación exitosa Casos no válidos Prueba Unitaria 8 Descripción Entradas Clases equivalencia Resultado esperado de Modificación de usuario Nombre: Jaime Apellidos: Lopera Bona Dirección: Gran Vía nº Logroño CP:"26006" Teléfono : (existiendo) Teléfono repetido: (existiendo) Federico@gmail.com Contraseña: 1234 Contraseña repetida: 1234 (MU2) Error, otro usuario tiene ese teléfono. Prueba Unitaria 9 Descripción Entradas Modificación de usuario Nombre: Jaime Apellidos: Lopera Bona 68

82 Clases equivalencia Resultado esperado de Dirección: Gran Vía nº Logroño CP:"26006" Teléfono : Teléfono repetido: pedro@gmail.com (existiendo) Contraseña: 1234 Contraseña repetida: 1234 (MU3) Error, otro usuario tiene ese RESULTADO DE PRUEBAS Tras ejecutar las pruebas unitarias, junto a pruebas relativas a la concordancia de los datos según cada campo del formulario y pruebas del captcha se ha probado la integridad y el buen funcionamiento de los formularios. Se han realizado también distintas pruebas de funcionamiento de la aplicación durante esta primera fase de desarrollo para observar si la aplicación funcionaba correctamente. Tras realizar algunos cambios para solucionar errores encontrados se tiene ya la aplicación corregida y funcionando. 69

83 7. CICLO ANÁLISIS CICLO ANÁLISIS DE REQUISITOS INTRODUCCIÓN El segundo ciclo del sistema está enfocado al tratamiento de los productos del restaurante. Estos productos serán ofrecidos para la venta online. Se tratará toda la gestión de este sistema de pedidos, tanto lo referente a la parte de los encargos realizados por los usuarios cómo la de administración USUARIOS INVOLUCRADOS En este apartado los protagonistas serán admincocina y Usuario. AdminCocina será el administrador encargado de crear nuevos productos, modificarlos y borrarlos. También asumirá la responsabilidad de gestionar los pedidos, marcándolos como pagados o como cancelados. Tendrá la posibilidad de activar o desactivar el sistema de pedidos online de la web y fijar un horario de venta y atención de esos pedidos. Usuario podrá realizar pedidos online así como acceder a listados de sus pedidos y detalles de los mismos REQUISITOS INVOLUCRADOS Se satisfacen los requisitos RF5, RF7, RF8, RF9, RF10, RF11 y RF12 en el ciclo 2 del proyecto. A continuación se refinan más RF5, RF7, RF10 y RF12: RF5.1 Introducción: Un AdminCocina podrá crear un producto para el hostal. Precondición: El AdminCocina debe estar registrado y se debe haber logueado. Entradas: El administrador gestionará el alta de nuevos productos de restaurante. Procedimiento: El administrador irá al formulario donde escribirá los datos del nuevo producto. Salidas: Se creará el producto y se informará de que se ha creado con éxito. 70

84 RF5.2 Introducción: Un AdminCocina podrá modificar un producto para el hostal. Precondición: El AdminCocina debe estar dado de alta y debe haber iniciado sesión. Entradas: El administrador quiere modificar un producto ya existente. Procedimiento: El administrador va a una sección donde elegirá el producto a modificar y hará los cambios oportunos. Salidas: Se modificará el producto y se indicará que se ha hecho correctamente. RF5.3 Introducción: Un AdminCocina podrá borrar un producto de comida para el hostal. Precondición: El AdminCocina debe estar registrado y logueado en la aplicación. Entradas: El administrador quiere borrar un producto en el menú. Procedimiento: El administrador va al apartado de productos donde elige el que quiere eliminar. Salidas: Se borrará y así se indicará. RF7.1 Introducción: Un AdminCocina podrá finalizar un pedido. Precondición: El AdminCocina debe estar dado de alta y debe haber logueado. Entradas: El administrador quiere marcar un pedido como ya finalizado correctamente. Procedimiento: El administrador va a la sección donde se muestran los pedidos sin finalizar, elige el deseado y lo marca como pagado y finalizado. Salidas: Se finalizará el pedido y se mostrará la confirmación. RF7.2 Introducción: Un AdminCocina podrá cancelar un pedido. Precondición: El AdminCocina debe estar dado de alta y se debe haber logueado. Entradas: El administrador quiere cancelar un pedido. Procedimiento: El administrador va a la sección donde se muestran los pedidos sin finalizar, elige el deseado y lo cancela. Salidas: Se cancelará el pedido y se mostrará la confirmación. RF10.1 Introducción: Un admincocina podrá activar el sistema de pedidos de la web. 71

85 Precondición: El admincocina debe estar registrado y con la sesión iniciada. Entradas: El administrador quiere activar el sistema de pedidos. Procedimiento: El administrador va a la sección de cocina donde activará los pedidos. Salidas: La web permitirá hacer pedidos. RF10.2 Introducción: Un admincocina podrá desactivar el sistema de pedidos de la web. Precondición: El admincocina debe estar registrado y con la sesión iniciada. Entradas: El administrador quiere desactivar el sistema de pedidos. Procedimiento: El administrador va a la sección de cocina donde desactivará los pedidos. Salidas: La web ya no permitirá hacer pedidos. RF12.1 Introducción: Un admincocina podrá añadir un código postal al que hacer entregas. Precondición: El admincocina debe estar registrado y con la sesión iniciada. Entradas: El administrador quiere añadir un código. Procedimiento: El administrador va a la sección de cocina donde añadirá el código. Salidas: El código se añadirá permitiendo hacer entregas a domicilio a direcciones con ese CP. RF12.2 Introducción: Un admincocina podrá borrar un código postal al que ya no hacer entregas. Precondición: El admincocina debe estar registrado y con la sesión iniciada. Entradas: El administrador quiere borrar un código. Procedimiento: El administrador va a la sección de cocina donde eliminará el código. Salidas: El código se borrará impidiendo en el futuro hacer entregas a esos domicilios. 72

86 CASOS DE USO El siguiente esquema es el diagrama de casos de uso relativo a este segundo ciclo del proyecto. Ilustración 39: Diagrama Casos Uso Ciclo 2 A continuación se enumeran y describen los distintos casos de uso: CREAR PRODUCTO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Crear Producto Administrador quiere crear un nuevo producto admincocina Administrador está registrado y ha iniciado sesión. Producto es añadido a la BD. 1. Administrador rellena los datos del producto a añadir. 2. Sistema añade producto. 3. Termina caso de uso. Excepciones: Error en los datos introducidos. 73

87 MODIFICAR PRODUCTO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Modificar producto Administrador quiere modificar un producto. admincocina Administrador está registrado y ha iniciado sesión. Producto es modificado. 1. Administrador pide listado de productos existentes. 2. Sistema muestra listado de productos. 3. Administrador selecciona producto a modificar 4. Sistema muestra datos del producto. 5. Administrador modifica producto. 6. Sistema modifica producto en la BD. 7. Termina caso de uso. Excepciones: Error en los datos introducidos. ELIMINAR PRODUCTO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Eliminar Producto Administrador quiere borrar un producto. admincocina Administrador está registrado y ha iniciado sesión. Producto es borrado. 1. Administrador pide listado de productos existentes. 2. Sistema muestra listado de productos. 3. Administrador selecciona producto a eliminar. 4. Sistema muestra datos del producto. 5. Administrador borra producto. 6. Sistema borra al producto del registro. 7. Termina caso de uso. VER PRODUCTO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Ver Producto Administrador quiere ver un producto. admincocina Administrador está registrado y ha iniciado sesión. Producto es borrado. 1. Administrador pide listado de productos. 2. Sistema muestra productos. 3. Administrador selecciona producto. 74

88 Excepciones: 4. Sistema muestra datos del producto. 5. Termina caso de uso. LISTAR PRODUCTOS CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Listar productos Administrador quiere listar los productos. admincocina Administrador está registrado y ha iniciado sesión. Productos son mostrados. 1. Administrador pide listado. 2. Sistema muestra listado de productos. 3. Termina caso de uso. HACER PEDIDO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Hacer Pedido Usuario quiere hacer un pedido. Usuario Usuario está registrado y ha iniciado sesión. El pedido es realizado y almacenado. 1. Usuario selecciona productos. 2. Sistema almacena productos. 3. Usuario elige cantidades. 4. Sistema almacena cantidades. 5. Usuario finaliza la compra. 6. Sistema registra pedido. 7. Termina caso de uso. 75

89 Ilustración 40: Diagrama Secuencia Realizar Pedido VER SU PEDIDO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Ver su Pedido Usuario quiere ver un pedido realizado. Usuario Usuario está registrado y ha iniciado sesión. Pedido es mostrado. 1. Usuario pide listado de pedidos. 2. Sistema muestra pedidos. 3. Usuario selecciona pedido. 4. Sistema muestra datos del pedido. 5. Termina caso de uso. 76

90 LISTAR SUS PEDIDOS CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Listar sus pedidos Usuario quiere ver sus pedidos. Usuario Usuario está registrado y ha iniciado sesión. Pedidos son mostrados. 1. Usuario pide un listado de sus pedidos. 2. Sistema muestra listado de pedidos. 3. Termina caso de uso. FINALIZAR PEDIDO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Finalizar pedido Administrador quiere marcar un pedido como ya pagado. admincocina Administrador está registrado y ha iniciado sesión. Pedido es marcado como pagado 1. Administrador pide listado de pedidos. 2. Sistema muestra pedidos. 3. Administrador selecciona pedido a finalizar 4. Sistema muestra datos del pedido. 5. Administrador selecciona finalizar. 6. Sistema añade pedido como pagado en el registro. 7. Termina caso de uso. CANCELAR PEDIDO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Cancelar pedido Administrador quiere marcar un pedido como cancelado. admincocina Administrador está registrado y ha iniciado sesión. Pedido es marcado como cancelado 1. Administrador pide listado de pedidos. 2. Sistema muestra pedidos. 3. Administrador selecciona pedido a cancelar. 4. Sistema muestra datos del pedido. 5. Administrador lo cancela. 6. Sistema marca el pedido como cancelado. 7. Termina caso de uso. 77

91 Excepciones: VER PEDIDO CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Ver Pedido Administrador quiere ver un pedido realizado. Administrador Administrador está registrado y ha iniciado sesión. Pedido es mostrado. 1. Administrador pide listado de pedidos. 2. Sistema muestra pedidos. 3. Administrador selecciona pedido. 4. Sistema muestra datos del pedido. 5. Termina caso de uso. LISTAR PEDIDOS CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Listar pedidos Administrador quiere ver listado de pedidos. admincocina Administrador está registrado y ha iniciado sesión. Pedidos son mostrados. 1. Administrador solicita listado de pedidos. 2. Sistema muestra pedidos. 3. Termina caso de uso. ACTIVAR SISTEMA DE PEDIDOS CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Activar sistema de pedidos Administrador quiere activar el sistema de pedidos. admincocina Administrador está registrado y ha iniciado sesión y los pedidos están desactivados. Pedidos volverán a estar activos. 1. Administrador solicita activar pedidos. 2. Sistema activa pedidos. 3. Termina caso de uso. 78

92 DESACTIVAR SISTEMA DE PEDIDOS CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Desactivar sistema de pedidos Administrador quiere desactivar el sistema de pedidos. admincocina Administrador está registrado y ha iniciado sesión y los pedidos están activados. Pedidos online se desactivarán 1. Administrador solicita desactivar pedidos. 2. Sistema desactiva pedidos. 3. Termina caso de uso. MODIFICAR HORARIO DE SISTEMA DE PEDIDOS CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Modificar horario de sistema de pedidos Administrador quiere modificar el horario en el que el sistema de pedidos estará activo. admincocina Administrador está registrado y ha iniciado sesión. El nuevo rango de horas de atención de pedidos se establecerá. 1. Administrador introduce nuevas horas. 2. Sistema cambia el rango de horas. 3. Termina caso de uso. AÑADIR CÓDIGO POSTAL CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Añadir código postal Administrador quiere añadir un nuevo código. admincocina Administrador está registrado y ha iniciado sesión. Código es añadido. 1. Administrador inserta código. 2. Sistema añade código. 3. Termina caso de uso. Excepciones: Código ya existe. 79

93 ELIMINAR CÓDIGO POSTAL CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Eliminar código postal Administrador quiere borrar un código. admincocina Administrador está registrado y ha iniciado sesión. Código es eliminado. 1. Administrador borra código. 2. Sistema elimina código del registro. 3. Termina caso de uso. 80

94 7.2 DISEÑO CICLO DISEÑO DE LA ARQUITECTURA INTRODUCCIÓN La arquitectura empleada en el desarrollo del ciclo 2 es exactamente igual que la usada en el ciclo 1 y que la de los ciclos posteriores. Se seguirá utilizando un diseño guiado por el patrón MVC y con las clases que pone a disposición Struts (ActionForm, Actions) junto a las habituales de objetos de negocio y sus clases de gestión en la BD CLASES DE NEGOCIO INTRODUCCIÓN Ahora se mostrará el diseño de las clases de negocio del ciclo2 de la aplicación. Se seguirá un estilo similar al del ciclo1 dividiendo las clases según su utilización y tipo OBJETOS DE NEGOCIO El esquema que se ve a continuación es una ampliación al desarrollado en el ciclo1. Se han añadido los nuevos objetos que son utilizados en esta segunda parte del proyecto. La clase Producto guarda la información referente a los productos de restaurante ofrecidos por la aplicación. Está ligada a TipoProducto ya que todo Producto tiene que ser de un tipo concreto. Por ejemplo, puede haber un producto llamada Pepito que sea de tipo bocadillo, u otro llamado Carbonara de tipo Pizza. Cabe destacar también que la clase ProductoEnPedido describe a los productos dentro de un pedido con una cantidad y un precio. La clase Pedido representa, como su nombre indica, a un pedido de productos que un usuario ha hecho en el portal web. 81

95 Ilustración 41: Diagrama clases ciclo CLASES DE PERSISTENCIA En este segundo ciclo se utilizarán las clases ProductosBD y PedidosBD para realizar todas las operaciones relativas a la gestión de productos y gestión de pedidos en las que se necesite acceder o modificar la base de datos. En el siguiente diagrama se puede observar los métodos de cada clase. Ilustración 42: Diagrama Clases BD Ciclo 2 82

96 ACTIONFORMS Los ActionForm empleados en este apartado para el tratamiento de la información de los formularios van a ser: ProductoActionForm ObtenerProductosActionForm PedidoActionForm ObtenerPedidosActionForm RedirigirActionForm ConfiguracionHostalActionForm Ilustración 43:Diagrama FormBeans Ciclo 2 A destacar simplemente que la clase ConfiguraciónPedidosActionForm será usada para la activación y desactivación del sistema de pedidos, la inserción o eliminación de códigos postales y para la modificación de horarios. RedirigirActionForm se encargará de cierto redireccionamiento de la web. Los demás ActionForm serán empleados para operaciones relacionadas con los productos y los pedidos. 83

97 ACTIONS En la gestión de productos y pedidos se van a emplear las siguientes Actions: Tabla para gestión de productos: Action AltaProductoAction Descripción Acción empleada para dar de alta un producto con los datos recogidos del formulario. ObtenerProductosAction Acción empleada para cargar un listado de productos. DisplayDatosProductoAction ModificarProductosAction DisplayDatosTipoProductoAction FiltrarProductosAction AltaTipoProductoAction ObtenerTiposProductoAction BorrarProductoAction BorrarTipoProductoAction ModificarTipoProductoAction Acción que muestra los datos de un producto. Acción que modifica los datos de un producto. Acción que muestra los datos de un tipo de producto. Acción que carga una lista de productos según un filtro. Acción usada para crear un nuevo tipo de producto. Acción que carga los distintos tipos de producto que existen. Acción que borra un producto. Acción empleada para borrado un tipo de producto. Acción empleada para modificar un tipo de producto. Tabla para gestión de pedidos. Action ActualizarPedidoAction DisplayDatosPedidoAction DisplayDatosPedidoCerradoAction EliminarProductoPedidoAction AddProductoPedidoAction FiltrarPedidosAbiertosAction FiltrarPedidosAction FinalizarPedidoAction Descripción Acción empleada para actualizar las cantidades de los productos de un pedido Acción usada para mostrar los datos de un pedido abierto. Acción usada para mostrar los datos de un pedido cerrado. Acción que se usa para eliminar un producto de un pedido que un usuario está haciendo. Acción que añade un producto a un pedido que está realizando un usuario. Acción que carga un listado de pedidos abiertos según un filtro establecido. Acción que filtra pedidos finalizados. Acción usada para finalizar un pedido una vez se 84

98 MostrarCarroAction GetPedidosAbiertosAction GetPedidosAbiertosUsuarioAction GetPedidosAction GetPedidosUsuarioAction SellarPedidoAction SeleccionarProductoAction ActivacionPedidosAction ModificarEstadoPedidosOnline han seleccionado todos los productos. Acción a usar para ver los elementos del carro de la compra, es decir, los productos seleccionados para el pedido. Acción que carga todos los pedidos que hay abiertos. Acción que carga los pedidos abiertos de un usuario. Acción que carga en un listado todos los pedidos. Acción que carga en un listado todos los pedidos de un usuario. Acción que finaliza definitivamente un pedido, marcando como pagado o como cancelado. Acción que carga los productos que serán mostrados para venderse en la web si está operativa la venta online. Acción utilizada para activar y desactivar el sistema de pedidos online. Acción empleada para modificar el horario de atención de pedidos online. 85

99 7.2.3 DISEÑO DE LA BASE DE DATOS INTRODUCCIÓN El diseño que se mostrará a continuación será una ampliación del visto en el ciclo1 añadiendo a los esquemas y tablas la información referida a la actividad de este segundo ciclo REQUISITOS DE LA BASE DE DATOS Para los productos ofertados por el restaurante se quiere guardar su nombre, una breve descripción, el precio, la última fecha de actualización y a su vez tener almacenados los diferentes tipos de productos con un nombre para que se pueda tenerlos categorizados en la web. De los pedidos se necesita guardar el precio total, la fecha del pedido y el usuario que ha realizado ese pedido, asimismo también se recuperará que productos han sido comprados en el pedido junto la cantidad de ellos. Interesará saber si un pedido ya ha sido pagado o ha sido cancelado, guardando el motivo de la cancelación. Se necesita almacenar los códigos postales a los cuales se pueden hacer envíos online. Y también se desea almacenar una serie de parámetros, como si los envíos están activos y un horario de atención de esos pedidos DIAGRAMA DE ENTIDAD-RELACIÓN DESCRIPCIÓN DEL DIAGRAMA. Se han elegido los nombres de las entidades y campos de forma bastante identificativa. A continuación se pasa a enumerar y describir las nuevas entidades: Producto: Representa a un producto ofrecido por el hostal para la venta, cada uno su identificador. Consta también de una fecha de actualización, de un precio y una descripción. TipoProducto: Son las categorías de los distintos tipos de productos que oferta el restaurante. Pedido: Representa el historial de pedidos realizados por los usuarios, con su identificar único y los identificadores de los productos encargados, así como el precio total del pedido y la fecha de cuando se realizó. CódigoPostal: Almacena todos los CP a los que se pueden realizar entregas a domicilio. ConfigPedidos: Se trata de una forma de almacenar determinados datos de configuración, tales como el horario de atención de pedidos, si estos están activos o el horario de atención. 86

100 DIAGRAMA EER Se ha realizado el siguiente esquema EER para el almacenamiento de información del ciclo 2 del proyecto: Ilustración 44: Esquema EER Ciclo 2 87

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

102 DIAGRAMA DE TABLAS FINAL La siguiente figura muestra el esquema final de la estructura de tablas para la segunda parte de este proyecto: Ilustración 45: Esquema Tablas Ciclo 2 89

103 7.2.4 INTERFACES GRÁFICAS DEFINITIVAS VISTA CARTA PEDIDOS Pantalla pública de pedidos, los internautas tendrán una visión de los productos gastronómicos que ofrece el restaurante en su carta y un enlace para comenzar un pedido online. Ilustración 46: Interfaz Carta productos Vista carro del pedido Vista de los productos almacenados durante el proceso de pedido. En el carro se puede borrar productos o actualizar la cantidad deseada. 90

104 Ilustración 47:Interfaz carro pedido Vista resumen del pedido En la siguiente captura se ve la pantalla final antes de confirmar un pedido. Si la entrega a domicilio está activa y el código postal del cliente está entre los disponibles para esa entrega se da opción al cliente de recoger el pedido en el restaurante del hostal o de recibirlo en casa. 91

105 Ilustración 48: Interfaz Resumen confirmación pedido 92

106 Vista configuración de pedidos La vista de configuración de pedidos muestra las opciones de configuración que tiene un administrador de cocina. Desde activar o desactivar los pedidos online hasta fijar un horario de atención de pedidos. Ilustración 49: Interfaz Configuración pedidos 93

107 7.3 IMPLEMENTACIÓN CICLO TECNOLOGÍAS EMPLEADAS La implementación del segundo ciclo ha sido realizada con las mismas tecnologías explicadas en el correspondiente apartado del ciclo 1. Se sigue utilizando NetBeans, Struts y JDBC como principales herramientas y de nuevo se cuenta con DisplayTag como medio para presentar listados ESTRUCTURA DE CARPETAS En el segundo ciclo la estructura de carpetas es la misma que en la del ciclo anterior. Solamente se crean 2 directorios nuevos llamados actions.pedidos y actions.productos donde estarán ubicados los actions relativos a las operaciones de pedidos y productos. Y otras 2 carpetas equivalentes para almacenar los archivos JSP que estarán en Web/WEB-INF/Pedidos y Web/WEB-INF/Productos CÓDIGO DESTACABLE En esta sección se expondrá parte de código fuente que se considera interesante destacar. CARRO En el siguiente código del carro de productos en un pedido se ve el bucle que carga la lista de productos seleccionados. Se destaca la etiqueta logic:iterate que como su nombre indica, sirve para iterar en una lista y obtener los elementos que se encuentran en ella. En este caso se tiene una lista de ProductosEnPedido y se muestran en una tabla junto a un icono que permite eliminarlos de la lista. Posee también un textbox para cambiar la cantidad de ellos actualizando el pedido. Ilustración 50: Código carro html 94

108 DISPLAYTAG Displaytag provee una herramienta para mostrar tablas con datos almacenados en una lista. Permite ordenar esa tabla por la columna que se le marque mediante la propiedad sortable= true y a su vez permite exportar esos datos con export= true Se ha usado una columna con un icono que al pulsarse permite la edición del elemento mostrado en esa fila. Para ello se ha empleado un campo oculto que almacena el identificador del elemento de esa fila. value='<%= ((Producto)pageContext.getAttribute("productos")).getNombre()%>' Ilustración 51: Código DisplayTag 95

109 7.4 PRUEBAS CICLO INTRODUCCIÓN Las pruebas a realizar en este ciclo van a centrarse en garantizar el correcto funcionamiento de todo el proceso de creación, modificación y eliminación de productos. Además se probará la realización de pedidos incluyendo los productos previamente creados, la finalización de esos pedidos y la muestra de listados tanto de productos como de pedidos. Como medida de integración de los 2 ciclos se probará también a crear nuevos usuarios y administradores que realicen y gestionen pedidos respectivamente VALIDACIÓN DE FORMULARIOS La validación de formularios tendrá lugar para garantizar que no se puedan crear 2 productos o 2 tipos de producto iguales y también para chequear que se introducen tipos de datos correctos en cada campo. Ilustración 52: Interfaz validación formulario alta producto PRUEBAS UNITARIAS A continuación se van a probar aquellos casos en los que puede haber conflicto al existir restricciones en la base de datos de unicidad. 96

110 CLASES DE EQUIVALENCIA ALTA DE PRODUCTO Condición Clases válidas Clases no válidas Nombre Unicidad Nombre no existe (AP1) Nombre existe (AP2) MODIFICACIÓN DE PRODUCTO Condición Clases válidas Clases no válidas Nombre Unicidad Nombre no existe (MP1) Nombre existe (MP2) ALTA DE TIPO DE PRODUCTO Condición Clases válidas Clases no válidas Nombre Unicidad Nombre no existe (ATP1) Nombre existe (ATP2) MODIFICACIÓN DE TIPO DE PRODUCTO Condición Clases válidas Clases no válidas Nombre Unicidad Nombre no existe (MTP1) Nombre (MTP2) existe 97

111 CASOS DE PRUEBA ALTA DE PRODUCTO Caso válido Prueba Unitaria 10 Descripción Entradas Clases equivalencia Resultado esperado de Alta de un nuevo producto Nombre: Mickey Descripción: Bacon, queso Precio: 4 Categoría: Bocadillos (AP1) Operación exitosa Caso no válido Prueba Unitaria 11 Descripción Entradas Clases equivalencia Resultado esperado de Alta de un nuevo producto Nombre: Mickey (existiendo) Descripción: Bacon, queso Precio: 4 Categoría: Bocadillos (AP2) Ya existe un producto con ese nombre. MODIFICACIÓN DE PRODUCTO Caso válido Prueba Unitaria 12 Descripción Entradas Clases de equivalencia Modificación de un producto Nombre: Mickey (cambiado a Goofy) Descripción: Bacon, queso Precio: 4 Categoría: Bocadillos (MP1) 98

112 Resultado esperado Operación exitosa Caso no válido Prueba Unitaria 13 Descripción Entradas Clases equivalencia Resultado esperado de Modificación de un producto Nombre: Mickey (cambiado a Aladdin existiendo) Descripción: Bacon, queso Precio: 4 Categoría: Bocadillos (MP2) Ya existe un producto con ese nombre. ALTA DE TIPO DE PRODUCTO Caso válido Prueba Unitaria 14 Descripción Entradas Clases equivalencia Resultado esperado de Alta de un nuevo tipo de producto Nombre: Hamburguesas (ATP1) Operación exitosa Caso no válido Prueba Unitaria 15 Descripción Entradas Clases equivalencia Resultado esperado de Alta de un nuevo tipo de producto Nombre: Hamburguesas (existiendo) (ATP2) Ya existe un tipo de producto con ese nombre. 99

113 MODIFICACIÓN DE TIPO DE PRODUCTO Caso válido Prueba Unitaria 16 Descripción Entradas Clases equivalencia Resultado esperado de Modificación de un producto Nombre: Hamburguesas (cambiado a bebidas) (MTP1) Operación exitosa Caso no válido Prueba Unitaria 17 Descripción Entradas Clases equivalencia Resultado esperado de Modificación de un producto Nombre: Hamburguesas (cambiado a bocadillos existiendo) (MTP2) Ya existe un tipo de producto con ese nombre RESULTADO DE LAS PRUEBAS Se efectuaron distintas pruebas para ver el correcto funcionamiento de la aplicación. Todo el proceso de pedidos online fue testeado y corregidos los errores encontrados. Se comprobó el correcto funcionamiento de las restricciones en el sistema de pedidos (horarios de atención, activación y desactivación de pedidos, activación y desactivación de entrega a domicilio, envío a determinados códigos postales). 100

114 8. CICLO ANALISIS CICLO ANÁLISIS DE REQUISITOS INTRODUCCIÓN Este tercer ciclo será el último y más extenso. Engloba todo lo relacionado con las reservas de habitaciones en el hostal, desde la creación de nuevas habitaciones y tipos de habitación hasta la muestra de habitaciones libres para unas determinadas fechas y su posterior elección por un usuario registrado. También está incluidas las reservas de sitio en el comedor restaurante y su gestión. Se incluirán además una serie de estadísticas del hostal mediante gráficas USUARIOS INVOLUCRADOS En este apartado intervendrán todos los tipos de usuario: admincocina, adminrecepción, admingeneral y Usuario. El adminrecepción es el administrador encargado de procesar todas las entradas y salidas en el hostal de gente, tendrá que finalizar las reservas. El admingeneral es el encargado de agregar nuevas habitaciones y tipos de habitaciones al hostal, también podrá modificarlas o eliminarlas. Dispondrá de unos formularios con unas determinadas gráficas de estadísticas. Los admincocina atenderán las reservas de sitio en el comedor restaurante. El Usuario podrá realizar reservas online de habitaciones libres y de sitio en el comedor REQUISITOS INVOLUCRADOS Se atenderán los requisitos RF13, RF14, RF15, RF16, RF17, RF18, RF19, RF20, RF21, RF22, RF23. (ver página 19) 101

115 Se refinan y detallan RF13, RF15, RF21 y RF23: RF13.1 Introducción: Un admingeneral podrá dar de alta una habitación del hostal. Precondición: El admingeneral debe estar registrado y se debe haber logueado. Entradas: El administrador quiere añadir una habitación. Procedimiento: El administrador va a un apartado de la web donde añade una habitación. Salidas: Se añadirá la habitación y se informará de ello. RF13.2 Introducción: Un admingeneral podrá modificar una habitación del hostal. Precondición: El admingeneral debe estar registrado y debe haber iniciado sesión. Entradas: El administrador quiere modificar una habitación. Procedimiento: El administrador va a una sección donde elige la habitación y la modifica. Salidas: Se modificará la habitación y se mostrará una confirmación. RF13.3 Introducción: Un admingeneral podrá dar de baja una habitación del hostal. Precondición: El admingeneral debe estar registrado y debe haber hecho login correctamente. Entradas: El administrador quiere borrar una habitación. Procedimiento: El administrador va a un apartado donde elige la habitación a borrar y la elimina. Salidas: Se borrará la habitación y se informará. RF15.1 Introducción: Un AdminRecepción podrá finalizar las reservas de habitaciones. Precondición: El AdminRecepción debe estar dado de alta y se debe haber logueado. Entradas: El administrador quiere finalizar una reserva. Procedimiento: El administrador va a la sección relativa a reservas de habitaciones donde elige la reserva para marcarla como pagada. Salidas: Se finalizará la reserva y se mostrará el éxito de la operación. RF15.2 Introducción: Un AdminRecepción podrá cancelar las reservas de habitaciones. Precondición: El AdminRecepción debe estar dado de alta y se debe haber logueado. 102

116 Entradas: El administrador quiere cancelar una reserva. Procedimiento: El administrador va a la sección relativa a reservas donde elige la reserva para cancelarla. Salidas: Se cancelará la reserva y se mostrará que se ha hecho con éxito. RF21.1 Introducción: Un AdminCocina podrá finalizar las reservas del restaurante. Precondición: El AdminCocina debe estar registrado y con la sesión iniciada, debe existir alguna reserva de restaurante pendiente. Entradas: El administrador quiere finalizar una reserva de restaurante. Procedimiento: El administrador va a la sección de reservas de restaurante donde elige la reserva para marcarla como pagada.. Salidas: Se finalizará la reserva y se mostrará la confirmación de la acción. RF21.2 Introducción: Un AdminCocina podrá cancelar las reservas del restaurante. Precondición: El AdminCocina debe estar registrado y con la sesión iniciada, debe existir alguna reserva de restaurante pendiente. Entradas: El administrador quiere cancelar una reserva de restaurante. Procedimiento: El administrador va a la sección de reservas de restaurante donde elige la reserva para cancelarla. Salidas: Se cancelará la reserva y se mostrará la confirmación de la acción. RF23.1 Introducción: Un admingeneral podrá ver una gráfica del % de ocupación de las habitaciones en un día Precondición: El AdminGeneral debe de estar registrado y con la sesión iniciada. Entradas: El administrador quiere ver una gráfica de ocupación de las habitaciones en un día. Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la estadística a visualizar eligiendo una fecha. Salidas: Se mostrará la gráfica. RF23.2 Introducción: Un admingeneral podrá ver una gráfica del número de reservas en el comedor en un año mostradas trimestralmente. Precondición: El AdminGeneral debe de estar registrado y con la sesión iniciada. Entradas: El administrador quiere ver la gráfica. 103

117 Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la estadística a visualizar eligiendo un año. Salidas: Se mostrará la gráfica. RF23.3 Introducción: Un admingeneral podrá ver una gráfica del % del tipo de pensión elegida por los clientes en un año. Precondición: El AdminGeneral debe estar registrado y con la sesión iniciada. Entradas: El administrador quiere ver la gráfica descrita arriba. Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la estadística a visualizar eligiendo un año. Salidas: Se mostrará la gráfica. RF23.4 Introducción: Un admingeneral podrá ver una gráfica de la ocupación de las habitaciones en un año agrupadas mensualmente. Precondición: El AdminGeneral debe estar registrado y con la sesión iniciada. Entradas: El administrador quiere ver la gráfica. Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la estadística a visualizar eligiendo un año. Salidas: Se mostrará la gráfica. RF23.5 Introducción: Un admingeneral podrá ver una gráfica del número de pedidos durante un año agrupados trimestralmente. Precondición: El AdminGeneral debe estar registrado y con la sesión iniciada. Entradas: El administrador quiere ver la gráfica. Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la estadística a visualizar eligiendo un año. Salidas: Se mostrará la gráfica. RF23.6 Introducción: Un admingeneral podrá ver una gráfica del % de ocupación del comedor durante un año representado trimestralmente. Precondición: El AdminGeneral debe estar registrado y con la sesión iniciada. Entradas: El administrador quiere ver la gráfica. 104

118 Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la estadística a visualizar eligiendo un año. Salidas: Se mostrará la gráfica. RF23.7 Introducción: Un admingeneral podrá ver una gráfica del número de registros en la web de nuevos usuarios agrupados mensualmente. Precondición: El AdminGeneral debe estar registrado y con la sesión iniciada. Entradas: El administrador quiere ver la gráfica. Procedimiento: El administrador va a la sección de estadísticas, donde selecciona la estadística a visualizar eligiendo un año. Salidas: Se mostrará la gráfica CASOS DE USO El siguiente esquema muestra una representación de las funciones que pueda hacer cada usuario: Ilustración 53: Diagrama Casos Uso Ciclo 3 105

119 CASOS DE USO DE LA GESTIÓN DE HABITACIONES CREAR HABITACIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Crear Habitación Administrador quiere crear una nueva habitación admingeneral Administrador está registrado y ha iniciado sesión. Habitación es añadida. 1. Administrador introduce datos de la nueva habitación. 2. Sistema añade habitación. 3. Termina caso de uso. Excepciones: Error en los datos. MODIFICAR HABITACIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Modificar Habitación Administrador quiere modificar una habitación. admingeneral Administrador está registrado y ha iniciado sesión. Producto es modificado. 1. Administrador pide listado de habitaciones. 2. Sistema muestra listado de habitaciones. 3. Administrador elige habitación. 4. Sistema muestra datos de la habitación. 5. Administrador modifica habitación. 6. Sistema modifica habitación. 7. Termina caso de uso. Excepciones: Error en los datos. ELIMINAR HABITACIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Eliminar Habitación Administrador quiere borrar una habitación. admingeneral Administrador está registrado y ha iniciado sesión. Habitación es borrada. 1. Administrador pide listado de habitaciones. 2. Sistema muestra listado de habitaciones. 3. Administrador selecciona habitación. 4. Sistema muestra datos de la habitación. 5. Administrador borra habitación. 106

120 Excepciones: 6. Sistema borra la habitación. 7. Termina caso de uso. VER HABITACIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Ver Habitación Administrador quiere ver los datos de una habitación. admingeneral Administrador está registrado y ha iniciado sesión. Se muestra la habitación. 1. Administrador pide listado de habitaciones. 2. Sistema muestra listado de habitaciones. 3. Administrador selecciona habitación. 4. Sistema muestra datos de la habitación. 5. Termina caso de uso. LISTAR HABITACIONES CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Listar habitaciones Administrador quiere listar las habitaciones. admingeneral Usuarios y administrador están registrados y han iniciado sesión. Productos son mostrados. 1. Administrador pide listado de habitaciones. 2. Sistema muestra habitaciones. 3. Termina caso de uso. CASOS DE USO DE LA GESTIÓN DE RESERVA DE HABITACIONES HACER RESERVA DE HABITACIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Hacer Reserva de habitación Usuario quiere hacer una reserva de habitación. Usuario Usuario está registrado y ha iniciado sesión. Pedido es realizado. 1. Usuario elige fechas. 2. Sistema muestra habitaciones libres en esas fechas. 107

121 3. Usuario elige habitación y tipo de pensión. 4. Sistema registra reserva. 5. Sistema envía confirmación. 6. Termina caso de uso. Excepciones: Error en las fechas. Error porque otro usuario ha reservado antes. Ilustración 54:Diagrama Secuencia Reserva Habitación 108

122 VER SU RESERVA DE HABITACIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Ver su Reserva de habitación Usuario quiere ver una reserva. Usuario Usuario está registrado y ha iniciado sesión. Reserva es mostrada. 1. Usuario busca reserva. 2. Sistema muestra listado de reservas de habitaciones. 3. Usuario selecciona reserva. 4. Sistema muestra datos de la reserva de la habitación. 5. Termina caso de uso. LISTAR SUS RESERVAS DE HABITACIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Listar sus reservas de habitación Usuario quiere ver sus reservas. Usuario Usuario está registrado y ha iniciado sesión. La lista de reservas es mostrada. 1. Administrador pide listado de reservas de habitación. 2. Sistema muestra el listado. 3. Termina caso de uso. FINALIZAR RESERVA DE HABITACIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Finalizar reserva de habitación Administrador quiere marcar una reserva de habitación como pagada. adminrecepción Administrador está registrado y ha iniciado sesión. La reserva de habitación es marcada como finalizada correctamente. 1. Administrador pide listado de reservas. 2. Sistema muestra reservas. 3. Administrador selecciona reserva. 4. Sistema muestra datos de la reserva. 5. Administrador finaliza la reserva. 6. Sistema registra reserva como pagada. 7. Termina caso de uso. 109

123 Excepciones: CANCELAR RESERVA DE HABITACIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Cancelar reserva de habitación Administrador quiere marcar una reserva como cancelada. adminrecepción Administrador está registrado y ha iniciado sesión. Reserva es marcado como cancelado 1. Administrador pide listado de reservas. 2. Sistema muestra reservas. 3. Administrador selecciona reserva. 4. Sistema muestra datos de la reserva. 5. Administrador cancela la reserva. 6. Sistema marca como cancelada la reserva. 7. Termina caso de uso. LISTAR RESERVAS DE HABITACIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Listar reservas de habitación Administrador quiere ver un listado de reservas de habitación. adminrecepción Administrador está registrado y ha iniciado sesión. Pedidos son mostrados. 1. Administrador pide listado de reservas de habitación. 2. Sistema muestra listado de reservas. 3. Termina caso de uso. VER RESERVA DE HABITACIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Ver su Reserva de habitación Administrador quiere ver una reserva. Administrador Administrador está registrado y ha iniciado sesión. Reserva es mostrada. 1. Administrador pide listado de reservas. 2. Sistema muestra listado de reservas de habitaciones. 3. Usuario selecciona reserva. 4. Sistema muestra datos de la reserva de la habitación. 5. Termina caso de uso. 110

124 Excepciones: CASOS DE USO DE LA GESTIÓN DE RESERVA DE COMEDOR HACER RESERVA DE COMEDOR CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Hacer Reserva de comedor Usuario quiere hacer una reserva de plazas en el comedor. Usuario Usuario está registrado y han iniciado sesión. Pedido es realizado. 1. Usuario selecciona fecha y plazas. 2. Sistema confirma reserva. 3. Sistema envía confirmación. 4. Termina caso de uso. Excepciones: No hay plazas disponibles. Error en la fecha. 111

125 Ilustración 55: Diagrama secuencia Reserva sitio restaurante VER SU RESERVA DE COMEDOR CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Ver su reserva de comedor Usuario quiere ver una reserva suya. Usuario Usuario está registrado y ha iniciado sesión. Reserva es mostrada. 1. Usuario pide listado de reservas de comedor. 2. Sistema muestra un listado con las reservas. 3. Usuario selecciona la reserva que quiere ver 4. Sistema muestra datos de la reserva. 5. Termina caso de uso. 112

126 LISTAR SUS RESERVAS DE COMEDOR CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Listar sus reservas de comedor Usuario quiere ver sus reservas. Usuario Usuario está registrado y ha iniciado sesión. La lista de reservas de comedor es mostrada. 1. Administrador va a sección reservas. 2. Sistema muestra reservas. 3. Termina caso de uso. FINALIZAR RESERVA DE COMEDOR CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Finalizar reserva de comedor Administrador quiere marcar una reserva de comedor como finalizada correctamente. admincocina Administrador está registrado y ha iniciado sesión. La reserva de comedor es marcada como pagada. 1. Administrador pide listado de reservas. 2. Sistema muestra reservas abiertas. 3. Administrador selecciona reserva. 4. Sistema muestra datos de la reserva. 5. Administrador finaliza reserva. 6. Sistema añade reserva como pagada en la BD. 7. Termina caso de uso. CANCELAR RESERVA DE COMEDOR CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Cancelar reserva de comedor Administrador quiere marcar una reserva como cancelada. admincocina Administrador está registrado y ha iniciado sesión. Reserva es marcado como cancelado 1. Administrador pide listado de reservas de comedor. 2. Sistema muestra reservas. 3. Administrador selecciona la reserva. 4. Sistema muestra datos de la reserva. 5. Administrador cancela la reserva. 6. Sistema marca la reserva como cancelada. 113

127 Excepciones: 7. Termina caso de uso. LISTAR RESERVAS DE COMEDOR CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Listar reservas de comedor Administrador quiere ver listado de pedidos. admincocina Administrador está registrado y ha iniciado sesión. La lista de reservas de comedor es mostrada. 1. Administrador pide listado de reservas de comedor. 2. Sistema muestra listado. 3. Termina caso de uso. VER RESERVA DE COMEDOR CASO DE USO: Ver reserva de comedor Descripción: Administrador quiere ver una reserva. Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Usuario Usuario está registrado y ha iniciado sesión. Reserva es mostrada. 1. Administrador pide listado de reservas de comedor. 2. Sistema muestra un listado con las reservas. 3. Administrador selecciona la reserva que quiere ver 4. Sistema muestra datos de la reserva. 5. Termina caso de uso. EXPLOSIÓN DEL CASO DE USO DE VER ESTADÍSTICAS Ilustración 56: Diagrama Casos Uso Estadísticas 114

128 GENERAR GRÁFICA DE OCUPACIÓN DE HABITACIONES POR DÍA CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Generar Gráfica Ocupación Habitaciones Día Administrador puede ver una gráfica con el % ocupación de las habitaciones de un día concreto. admingeneral Administrador está registrado y ha iniciado sesión. Se muestra la gráfica. 1. Administrador introduce fecha. 2. Sistema muestra gráfica de esa fecha. 3. Termina caso de uso. GENERAR GRÁFICA DE TIPO DE PENSIÓN CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Generar Gráfica Tipo Pensión Administrador puede ver una gráfica que enseñe los porcentajes de cada tipo de reserva de habitación que eligen los usuarios del año que le pongas. admingeneral Administrador está registrado y ha iniciado sesión. Se muestra la gráfica. 1. Administrador introduce año. 2. Sistema muestra gráfica con los datos del año. 3. Termina caso de uso. GENERAR GRÁFICA DE OCUPACIÓN DE HABITACIONES POR MES CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Generar Gráfica Ocupación Habitaciones Mes Administrador puede ver una gráfica con la ocupación de las habitaciones por meses en el año seleccionado. admingeneral Administrador está registrado y ha iniciado sesión. Se muestra la gráfica. 1. Administrador introduce año. 2. Sistema muestra gráfica. 3. Termina caso de uso. 115

129 GENERAR GRÁFICA DE RESERVA DE COMEDOR POR TRIMESTRE CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Generar Gráfica Reservas Comedor Trimestre Administrador puede ver una gráfica con la ocupación del comedor por trimestres del año elegido. admingeneral Administrador está registrado y ha iniciado sesión. Se muestra la gráfica. 1. Administrador introduce año. 2. Sistema muestra gráfica. 3. Termina caso de uso. GENERAR GRÁFICA DE REGISTROS DE USUARIO POR MES CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Generar Gráfica Registros Mes Administrador quiere ver una gráfica con el número de registros mensual del año seleccionado. admingeneral Administrador está registrado y ha iniciado sesión. Se muestra la gráfica. 1. Administrador introduce año. 2. Sistema muestra gráfica. 3. Termina caso de uso. GENERAR GRÁFICA DE PEDIDOS POR TRIMESTRE CASO DE USO: Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Generar Gráfica Pedidos Trimestre Administrador quiere ver una gráfica con número de pedidos, representados trimestralmente del año elegido. admingeneral Administrador está registrado y ha iniciado sesión. Se muestra la gráfica. 1. Administrador introduce año. 2. Sistema muestra gráfica. 3. Termina caso de uso. GENERAR GRÁFICA DE OCUPACIÓN DE COMEDOR POR DÍA CASO DE USO: Generar Gráfica Ocupación Comedor Día 116

130 Descripción: Actores: Precondición: Postcondición: Escenario Principal: Excepciones: Administrador quiere ver una gráfica con el % ocupación del comedor de un día concreto. admingeneral Administrador está registrado y ha iniciado sesión. Se muestra la gráfica. 1. Administrador selecciona fecha. 2. Sistema muestra gráfica. 3. Termina caso de uso. 117

131 8.2 DISEÑO CICLO DISEÑO DE LA ARQUITECTURA INTRODUCCIÓN De nuevo al igual que en los 2 primeros ciclos del proyecto se mantiene la arquitectura. Para más información se puede revisar el apartado del ciclo 1 donde queda explicada CLASES DE NEGOCIO INTRODUCCIÓN Se amplían las clases de negocio vistas anteriormente con las nuevas referentes a este ciclo. En este caso los diagramas y apartados quedarán algo más densos debido a la mayor extensión de esta última parte de la aplicación OBJETOS DE NEGOCIO Los nuevos objetos de negocio van a ser las clases Comedor, Habitación, TipoHabitación, ReservaHabitación y ReservaComedor. Los nombres son bastante descriptivos de lo que representarán en la aplicación. En la parte dedicada a las reservas de habitaciones estarían Habitación y su TipoHabitación. Por ejemplo, una Habitación tendría un número y el tipo contendría una descripción de esa habitación, si es doble o individual, la capacidad o el precio... La ReservaHabitación es otra clase que representa una reserva de una habitación de un usuario en unas fechas concretas. En la parte de reservas de comedor quedarían las clases Comedor, que sería una clase de tipo Singleton representando al comedor del hostal. Este tendría una capacidad que sería ocupada por los usuarios no alojados en el hostal. La clase ReservaComedor representa, como su nombre indica, a una reserva de unas determinadas plazas del comedor. Podía haberse intentado una generalización con la clase Reserva: ReservaComedor y ReservaHabitación pero se ha considerado que no sería muy útil ya que prácticamente solo mantienen como elementos comunes que ambas reservas las realiza un Usuario y tienen un identificador. 118

132 A continuación se muestra el diagrama de clases que intervienen en este ciclo. Ilustración 57: Diagrama Clases Ciclo CLASES DE PERSISTENCIA Las clases utilizadas para interactuar con la base de datos serán HabitacionesBD, ReservasHabitacionBD y ComedorBD. En el esquema de abajo se pueden ver los métodos de cada clase. 119

133 Ilustración 58: Diagrama Clases BD Ciclo ACTIONFORMS Los ActionForms que manejarán la información de los formularios de esta parte de la aplicación serán: HabitacionActionForm ObtenerHabitacionesActionForm ObtenerReservasActionForm EstadisticasActionForm ReservaActionForm ComedorActionForm 120

134 ACTIONS Los Actions de este tercer ciclo serán mostrados en las siguientes tablas: ACTIONS GESTIÓN DE HABITACIONES Actions AltaHabitacionAction Descripción Acción utilizada para añadir una nueva habitación. GetHabitacionesAction Acción usada para recuperar listados de habitaciones. DisplayDatosHabitacionAction FiltrarHabitacionesAction BorrarHabitacionAction ModificarHabitacionesAction AltaTipoHabitacionAction BorrarTipoHabitacionAction DisplayDatosTipoHabitacionAction GetTiposHabitacionesAction ModificarTipoHabitacionAction MostrarTiposHabitacionHostal Acción usada para mostrar los datos de una habitación. Acción que devolverá una lista de habitaciones según un criterio de filtro. Acción utilizada para dar de baja una habitación. Acción empleada para modificar una habitación. Acción usada en el proceso de creación de un nuevo tipo de habitación Acción utilizada para borrar un tipo de habitación. Acción utilizada para mostrar los datos de un tipo de habitación. Acción empleada para devolver una lista con todos los tipos de habitaciones existentes. Acción empleada para modificar un tipo de habitación. Acción que carga los tipos de habitación que dispone el hostal. Ilustración 59: Tabla Actions Habitaciones ACTIONS RESERVA DE HABITACIONES Actions ContinuarReserva2Action ContinuarReservaAction DisplayDatosReservaAction DisplayDatosReservaAdminAction DisplayDatosReservaCerradaAdminAction Descripción Acción usada en el paso 2 del proceso de reserva de habitación por un usuario. Acción usada durante el paso 1 de la reserva de habitación por un usuario. Acción que muestra los datos de una reserva de habitación. Acción que le muestra al administrador los datos de una reserva de habitación. Acción que le muestra al administrador 121

135 FiltrarReservasAbiertasAction FiltrarReservasAction los datos de una reserva de habitación ya finalizada. Acción que devuelve una lista con las reservas que han pasado un filtro. Acción que filtra una serie de reservas de habitación y las muestra en una lista. GetReservasAbiertasAction Acción que devuelve una lista al administrador con todas las reservas aún abiertas. GetReservasAbiertasUsuarioAction GetReservasAction Acción que devuelve una lista con todas las reservas aún abiertas de un usuario. Acción que devuelve una lista al con todas las reservas registradas. GetReservasUsuarioAction Acción que devuelve una lista al administrador con todas las reservas de un usuario. SellarReservaAction SeleccionarFechaReservaAction RegistrarReservaHabitacionAction Ilustración 60: Tabla Actions Reservas Habitaciones Acción que finaliza definitivamente una reserva de habitación marcándola como pagada o como cancelada. Acción usada en el proceso de reserva para marcar las fechas de reservas elegidas por el usuario. Acción que registra la reserva del usuario. ACTIONS RESERVA DE COMEDOR Actions DisplayReservaComedorAdminAction FiltrarReservasComedorAction SellarReservaComedorAction GetReservasComedorAdmAction GetReservasComedorUsuarioAction DisplayDatosReservaComedorAction FiltrarReservasComedorAbiertasAction Descripción Acción que muestra los datos de una reserva del comedor elegida por el administrador. Acción que muestra una lista filtrada de reservas de comedor. Acción que finaliza definitivamente una reserva de comedor. Acción que devuelve al administrador una lista de todas las reservas. Acción que devuelve al usuario una lista de todas sus reservas. Acción que muestra los datos de una reserva del comedor. Acción que devuelve una lista filtrada de 122

136 GetReservasComedorAbiertasAdminAction GetReservasComedorAbiertasUsuarioAction RegistrarReservaComedorAction SeleccionarFechaReservaComedorAction ModificarCapacidadComedor DisplayDatosReservaComedorAction todas las reservas del comedor. Ilustración 61: Tabla Actions Reservas Comedor Acción que devuelve al administrador una lista de todas las reservas del comedor abiertas. Acción que devuelve al usuario una lista de todas las reservas del comedor abiertas. Acción que guarda una reserva de comedor de un usuario. Acción que guarda la fecha elegida por el usuario para la realización de la reserva. Acción que cambia la capacidad del comedor. Acción que le muestra al usuario los datos de su reserva de comedor. ACTIONS ESTADÍSTICAS Actions GraficaOcupacionComedorDiaAction GraficaOcupacionDiaAction Descripción Acción que crea una gráfica de estadísticas de la ocupación del comedor en un día elegido. Acción que crea una gráfica de estadísticas de la ocupación de las habitaciones del hostal en un día elegido. GraficaOcupacionHostalMesAction Acción que crea una gráfica con la ocupación del hostal en un año representada en meses. GraficaOcupacionTipoPensionAction GraficaPedidosTrimestreAction GraficaRegistrosAñoAction Acción que crea una gráfica con los % de los tipos de pensión elegidos para los usuarios en un año. Acción que crea una gráfica con el número de pedidos mensual de un año seleccionado. Acción que muestra un diagrama de barras con el número de registros anual representándolos por meses. GraficaReservasComedorTrimestreAction Acción que crea una gráfica con la ocupación del comedor en un año representada en trimestres. Ilustración 62: Tabla Actions Estadísticas 123

137 8.2.3 DISEÑO DE LA BASE DE DATOS INTRODUCCIÓN En este apartado del ciclo 3 se va a finalizar el diseño de la base de datos de la aplicación. Se añadirán las nuevas entidades y tablas al diseño de los ciclos anteriores REQUISITOS DE LA BASE DE DATOS RELATIVOS AL CICLO3 El hostal almacenará las habitaciones con un número y estas serán descritas por un tipo de habitación. Cada tipo de habitación tendrá una descripción, un precio y el número de personas que pueden ocuparla. Se guardarán tanto las reservas de habitaciones como las reservas relativas al comedor. En las reservas de habitaciones interesará guardar el usuario que la ha hecho, las fechas de entrada y salida, la fecha de la reserva, la habitación elegida y el precio total. En las reservas de comedor se almacenará información como el número de personas que irán al comedor por reserva, la fecha, el horario, el usuario que la ha realizado y el precio final. Todas las reservas, sean del tipo que sean, tendrán un identificador único y se quiere saber si están finalizadas (pagadas o canceladas) o no para mostrar distintos listados en la aplicación. Interesa almacenar también el tamaño del comedor para poder modificarlo en el futuro si se diera el caso. Solo hay un comedor puesto a disposición de los clientes no alojados, sin más posibles divisiones DIAGRAMA DE ENTIDAD-RELACIÓN DESCRIPCIÓN DEL DIAGRAMA. La figura que se ve abajo representa el diagrama Entidad Relación relativo al ciclo 3. Se va a pasar a explicar solo las nuevas entidades porque las de los ciclos anteriores ya se mencionaron. Habitación: Representa las habitaciones del hostal con el identificador del tipo de habitación que las describirá. TipoHabitación: Entidad descriptora de habitaciones, con un precio o números de ocupantes. ReservaHabitación: Representa las reservas de habitaciones realizadas por los usuarios con su fecha de entrada, fecha de salida, habitación o precio. 124

138 ReservaComedor: Esta entidad representa las reservas de comedor hechas por los usuarios registrados de la web con el número de personas que acudirán a comer y otra información relevante. ConfigComedor: Entidad que representa al comedor del hostal y almacena solamente su capacidad. DIAGRAMA EER El esquema de abajo representa el diagrama EER de la base de datos del ciclo 3. Ilustración 63: Esquema EER Ciclo CONVERSIÓN A MODELO RELACIONAL TABLAS RESULTANTES Han aparecido nuevas tablas en la conversión del esquema EER. Habrá 2 tablas para registrar las reservas de habitación y reservas de comedor canceladas. Y una para almacenar la capacidad del comedor. 125

139 NORMALIZACIÓN Las nuevas tablas cumplen: 1FN, 2FN y 3FN Claves candidatas Las claves serán unos identificadores autoincrementados en Habitación, TipoHabitación, ReservaHabitación y ReservaComedor. En ConfigComedor al ser una tabla de configuración y haber solo un comedor no se pondrá ninguna clave. Y en las tablas de canceladas la clave será conjunta el identificador de las reservas. 126

140 DIAGRAMA DE TABLAS FINAL Ilustración 64: Diagrama Tablas Ciclo INTERFACES GRÁFICAS A continuación se van a mostrar una serie de pantallas realizadas durante este último ciclo de la aplicación GRÁFICA REPRESENTATIVA DE OCUPACIÓN DEL HOSTAL UN DETERMINADO AÑO La siguiente pantalla muestra una gráfica del tipo de pensión elegido por los clientes en un año concreto. Las gráficas son realizadas con jfreechart y son altamente personalizables en colores, tamaños, etiquetas

141 Ilustración 65: Interfaz Gráfica Tipo Ocupación hostal GRÁFICA REPRESENTATIVA DE OCUPACIÓN DEL HOSTAL UN DETERMINADO DÍA Otra gráfica generada con jfreechart. Ésta muestra la ocupación de las habitaciones del hostal en un día concreto elegido por el administrador. Ilustración 66: Interfaz Gráfica % Ocupación Hostal 128

142 MENÚ PRINCIPAL DE LA GESTIÓN DE HABITACIONES Y COMEDOR Pantalla del menú de administrador general para realizar operaciones relacionadas con la estructura del hostal restaurante. Ilustración 67: Interfaz Administración hostal PÁGINA DE SELECCIÓN DE FECHAS PARA UNA RESERVA DE HABITACIÓN Página pública mostrada a los internautas para comprobar si hay habitaciones libres en unas determinadas fechas. Si se eligen fechas de forma errónea saldrá un error indicándolo. 129

143 Ilustración 68: Interfaz Elección Fechas Reserva Habitación PARTE DE LA PÁGINA DE CREACIÓN DE GRÁFICAS ESTADÍSTICAS La siguiente imagen muestra parte del apartado indicado a la generación y muestra de gráficas estadísticas. Cada gráfica se genera mediante un formulando seleccionando unas fechas. 130

144 Ilustración 69: Interfaz Generación Gráficas 131

145 8.3 IMPLEMENTACIÓN CICLO TECNOLOGÍAS EMPLEADAS En el desarrollo del ciclo 3 se siguen utilizando las mismas tecnologías explicadas en los anteriores ciclos. Como novedad en este ciclo se ha hecho uso de una librería Java llamada jfreechart. Esta librería ha sido empleada para facilitar la creación de gráficos de calidad y de todo tipo en Java. Para elegir las fechas de reservas, tanto de comedor como de habitación se ha utilizado un calendario libre hecho en Javascript ESTRUCTURA DE CARPETAS La estructura de carpetas seguirá el mismo patrón que en las implementaciones pasadas. Se han añadido los nuevos directorios referentes a las clases.java y las páginas JSP de este tercer ciclo. Se añadirán las clases correspondientes a las carpetas objetos, forms y bd. Y las nuevas carpetas serán: Web/WEB-INF/Comedor Web/WEB-INF/ReservasHabitación Web/WEB-INF/Estadisticas Actions.comedor Actions.estadisticas Actions.reservashabitacion 132

146 8.3.3 CÓDIGO DESTACABLE EJEMPLO JFREECHART, DIAGRAMA DE SECTORES 133

147 Ilustración 70: Código Action Gráfica En la figura de arriba se muestra un ejemplo de Action en el que se ha utilizado Jfreechart para la creación de una gráfica. El proceso es simple usando las librerías que proporciona Jfreechart. En este ejemplo se crea un diagrama de sectores con el % de mesas libres y ocupadas en un determinado día. 1. Se empieza creando un objeto de tipo piedataset (DefaultPieDataset piedataset = new DefaultPieDataset();) 2. Se obtienen los valores a mostrar en esa gráfica. 3. Se asignan los valores al objeto piedataset (piedataset.setvalue(porcmesaslibres + "% Mesas libres", porcmesaslibres);) 4. Se crea la gráfica final de utilizando el piedataset iniciado anteriormente y unos valores como el titulo u otros datos que se quiere que aparezcan en la gráfica. (JFreeChart chart = ChartFactory.createPieChart("Ocupación comedor " + horario + " " + fecha, piedataset, true, true, false);) 5. Se exporta en un archivo JPEG que será mostrado en la aplicación. (ChartUtilities.saveChartAsJPEG( new File(this.getServlet().getServletContext().getRealPath(".") + "/images/graficos/diagramaocupacioncomedordia.jpg"), chart, 500, 300);) CALENDARIO Se ha decidido utilizar un calendario gráfico para la inserción de fechas. De esta manera se elimina el problema de una inserción de fechas en un formato erróneo. El calendario es libre y de fácil implementación, simplemente se tiene que hacer referencia al archivo js datetimepicker_css.js y ejecutar el método NewCssCal('demo1','ddMMyyyy'). El primer parámetro representa un nombre identificativo y el segundo el formato de fecha elegido. El calendario posee varias opciones más como incluir una hora pero no es necesario para esta aplicación. 134

148 Ilustración 71: Interfaz Calendario ENVÍO TRAS RESERVA La aplicación enviará en determinadas ocasiones s a los usuarios. Cuando un usuario realice un pedido o una reserva recibirá un con un resumen y confirmación de la misma. Debido a ser un proyecto sin hosting ni servidor planteado inicialmente, se usará una cuenta de Google para el envío de s. Para realizar este cometido se ha empleado una clase genérica y dependiendo del tipo de que sea se cambiará el asunto o el contenido. Para el envío se ha hecho uso de una serie de clases de javax.mail 135

149 Ilustración 72: Código envío 136

150 8.4 PRUEBAS CICLO INTRODUCCIÓN Las pruebas que se van a realizar en este último ciclo se centrarán en testear el funcionamiento de los procesos de reservas, de la gestión de habitaciones y comedor, de la generación de estadísticas y de la muestra de listados de reservas VALIDACIÓN DE FORMULARIOS Con la validación de formularios se asegurará que los datos introducidos por los usuarios son correctos para su posterior tratamiento por la aplicación. Se validarán los formularios que intervienen en la gestión de habitaciones, gestión de comedor y aquellos que sean usados en las reservas PRUEBAS UNITARIAS CLASES DE EQUIVALENCIA ALTA DE HABITACIÓN Condición Clases válidas Clases no válidas Número Unicidad Número no existe (AH1) Número existe (AH2) MODIFICACIÓN DE HABITACIÓN Condición Clases válidas Clases no válidas Número Unicidad Número no existe (MH1) Número existe (MH2) CASOS DE PRUEBA Caso válido Prueba Unitaria 18 Descripción Alta de una nueva habitación 137

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

152 ALTA DE TIPO DE HABITACIÓN Condición Clases válidas Clases no válidas Número Unicidad Número no existe (AH1) Número existe (AH2) MODIFICACIÓN DE TIPO DE HABITACIÓN Condición Clases válidas Clases no válidas Número Unicidad Número no existe (MH1) Número existe (MH2) CASOS DE PRUEBA ALTA DE TIPO DE HABITACIÓN Caso válido Prueba Unitaria 22 Descripción Entradas Clases equivalencia Resultado esperado de Alta de un nuevo tipo de habitación Descripción: Habitación doble Precio:20 Ocupantes:2 (AH1) Operación exitosa Caso no válido Prueba Unitaria 23 Descripción Entradas Clases de equivalencia Resultado Alta de un nuevo tipo de habitación Descripción: Habitación doble (existiendo) Precio:20 Ocupantes:2 (AH2) Ya existe un tipo de habitación con esa descripción. 139

153 esperado MODIFICACIÓN DE TIPO DE HABITACIÓN Caso válido Prueba Unitaria 24 Descripción Entradas Clases equivalencia Resultado esperado de Modificación de un nuevo tipo de habitación Descripción: Habitación doble (cambio a habitación triple ) Precio:20 Ocupantes:2 (MH1) Operación exitosa Caso no válido Prueba Unitaria 25 Descripción Entradas Clases equivalencia Resultado esperado de Modificación de un nuevo tipo de habitación Descripción: Habitación doble (cambio a habitación triple existiendo) Precio:20 Ocupantes:2 (MH2) Ya existe un tipo de habitación con esa descripción RESULTADO PRUEBAS Se han realizado distintas pruebas para comprobar el correcto funcionamiento de las operaciones de este tercer ciclo. Se han encontrado algunos errores en el sistema de reservas de habitaciones que ya están solucionados. En las pruebas se personalizaron más las gráficas cambiando algunos colores y leyendas. En las habitaciones se añadió restricciones en la base de datos para que no pudieran tener la misma descripción. 140

154 9. PRUEBAS FINALES 9.1 PRUEBAS DE INTEGRACIÓN Por último se van a seguir una serie de pasos para probar la integración de los tres ciclos conjuntamente. Los pasos y pruebas a realizar serán: Con admingeneral: 1. Se darán de alta a varios usuarios, unos serán adminrecepción, otros admincocina y otros Usuarios normales. 2. Se modificarán y borrarán algunos. 3. Se crearán tipos de habitación y habitaciones asociadas a esos tipos. 4. Se crearán unas habitaciones asociadas a esos tipos. 5. Se crearán varias gráficas estadísticas. Con admincocina: 1. Se crearán unos tipos de productos y unos productos para ponerlos a la venta en la web. 2. Una vez que los usuarios hayan hecho sus pedidos unos se cancelarán y otros se marcarán como pagados, se comprobarán en los listados los cambios de estado. 3. Se comprobarán, marcarán como pagadas o canceladas varias reservas de comedor. Con usuario: 1. Se harán varios pedidos en la aplicación. 2. Se harán varias reservas de habitaciones en la aplicación. 3. Se harán reservas de plazas en el comedor del restaurante. 4. Se mirarán sus historiales de pedidos y reservas para ver los cambios de las mismas. 5. Se realizará un reserva simultánea de una misma habitación en mismas fechas entre 2 usuarios. 6. Se realizará una reserva simultánea de sitio en el comedor que supere la capacidad del mismo. 7. Se modificará los datos de la cuenta. 8. Se eliminará la cuenta. 141

155 Con adminrecepcion: 1. Se atenderán las reservas efectuadas por el usuario, cancelando unas y marcando como pagadas las otras. 2. Se observarán en los listados como cambian de situación, de abiertas a pagadas o canceladas. 9.2 PRUEBAS DE SISTEMA Para probar el sistema final completo hay que ejecutar con éxito cada uno de los requisitos funcionales requeridos. Como no existe un cliente como tal, seremos nosotros los que valoraremos si se ha cumplido con los mínimos de un proyecto de este estilo. Se han ejecutado correctamente todos los requisitos, así que se darán por finalizadas las pruebas y se declarará el proyecto como concluido. 142

156 10. CONCLUSIONES Esta sección pretende recoger las impresiones finales del alumno sobre la totalidad del proyecto COMPARATIVA ENTRE OBJETIVOS Y RESULTADOS OBTENIDOS En el apartado de Alcance recogido en el documento de objetivos objetivos a cubrir con la realización de este proyecto, se resumían en: se plantearon los Mostrar información del hostal: Tarifas, situación geográfica, habitaciones, comedor, productos. Gestión de reservas online: Habitaciones y comedor. Gestión online de pedidos de productos de restaurante. Gestión de usuarios: Registro obligatorio de clientes para reservas y pedidos, diferentes permisos para el personal y administradores del hostal. Historiales: Historial de pedidos, reservas de habitaciones y reservas de mesas del comedor. Estadísticas: Diferentes gráficas con estadísticas del hostal-restaurante. Tras terminar la aplicación se ha comprobado que los objetivos se han cumplido satisfactoriamente. El desarrollo de estos objetivos fue dividido en ciclos con el fin de mejorar la organización y planificación del proyecto. En el ciclo 1 se cubrieron los objetivos: Gestión y listados de usuarios. Sirvió también para una mayor toma de contacto con el entorno de Struts. El ciclo 2 se desarrollaron los objetivos: Gestión de pedidos, historiales de pedidos. En el tercer y último ciclo tuvieron cabida: Gestión de reservas de habitaciones. Gestión de reservas de comedor. Historiales de reservas. Gráficas estadísticas. 143

157 10.2 POSIBLES MEJORAS Y AMPLIACIONES La aplicación podría ser ampliada en el futuro conforme a las necesidades de un cliente final que la pudiera utilizar. Se podría añadir por ejemplo una pasarela de pago para que los clientes a la vez que hicieran un pedido lo pagaran. Otra ampliación podría ser la adición de un sistema de envío de sms que avisara al cliente de ciertas informaciones, como pudiera ser el aviso de una reserva o de que un pedido estuviera listo para recoger VISIÓN PERSONAL Finalizado el proyecto me considero satisfecho del resultado obtenido. Se ha conseguido crear una aplicación web cubriendo las necesidades y objetivos planteados. Uno de los aspectos que más se incide en la carrera es el relativo a las fases a seguir durante todo el proceso de creación de software y su respectiva documentación. Aunque a veces el alumno no valore toda esta teoría una vez que te pones a desarrollar una aplicación de tamaño medio o grande te das cuenta de su importancia. El tiempo que se gasta en una buena planificación de tareas, en un análisis o un diseño es recompensado con creces luego a la hora de programar. De otra manera hay que andar con cambios sobre la marcha que provocan muchas pérdidas de tiempo. En lo que se refiere a la planificación personal creo que podía haber sido muy mejorable por mi parte. Debido a varios factores personales no he ocupado horas que estaban dedicadas al proyecto. Eso ha provocado que se haya retrasado demasiado la finalización del mismo. También me interesaba mejorar mis conocimientos en Java y en la programación web en general. Y otro de los objetivos del proyecto era el de aprender a utilizar algún framework de desarrollo de software y con Struts he conseguido unas nociones que me serán útiles en el futuro.. Sin embargo, la utilización de frameworks está tan extendida en el desarrollo de aplicaciones como ésta que, lo que al comienzo del proyecto suponía una novedad y un aliciente de aprendizaje hace más de dos años, en la actualidad ha perdido cierto sentido. 144

158 11. GLOSARIO DE TÉRMINOS Framework: Herramienta que facilita el desarrollo de software ofreciendo una serie de clases y utilidades. Struts: Framework de apache para aplicaciones web desarrolladas en Java. ActionServlet: Controlador de Struts que maneja el flujo de operaciones de la aplicación. Action: Clase de Struts empleada en la ejecución de un formulario. ActionForm: Clase de Struts usada en la captura de datos de los formularios. Struts-config.xml: Archivo xml de configuración de Struts donde se definen entre otras cosas los Action y los ActionForm de la aplicación. Ciclo: Iteración del proyecto. admincocina: Administrador o encargado de la parte relacionada con la cocina del restaurante. adminrecepción: Administrador o encargado de la parte relacionada con la recepción de hospedados al hostal. admingeneral: Encargado general del hostal restaurante. 145

159 12. BIBLIOGRAFÍA Libros Desarrollo de aplicaciones web dinámicas con XML y Java. [David Parsons, Anaya] Ingeniería del Software [Sommerville] Referencias Web: Foro preguntas-respuestas de programación Página con tutoriales de diseño web. Guía de usuario de la web oficial de Struts Pequeña introducción a Struts uts

160 13. ANEXOS 13.1 DISEÑO WEB INTRODUCCIÓN Durante la redacción de la memoria se ha hecho sobretodo hincapié a la parte de programación de la web. La parte de diseño ha quedado en un segundo plano. Por ello en esta sección se va a explicar de manera muy breve el diseño web PROCESO El diseño de la web fue empezado en papel recogiendo las secciones que debía tener la aplicación. Se creó un diseño final utilizando hojas de estilo para mejorar la mantenibilidad de la web. Se han utilizado principalmente capas (div) combinadas con tablas para posicionar los elementos en la web. Se ha cargado 2 hojas de estilo distintas dependiendo del navegador (IE o Firefox, Chrome...) para la correcta visualización en todos navegadores. En la aplicación se muestra información pública del hostal como marcaban los requisitos., tales como la situación, los precios o información típica de un hostal-restaurante IMÁGENES Todas las imágenes o iconos empleados han sido sacados de repositorios libres de internet. Las imágenes de habitaciones o elementos del hostal restaurante pertenecen al Hostal Merced-Concordia y han sido utilizadas con su consentimiento para la realización de este proyecto LEY ORGÁNICA DE PROTECCIÓN DE DATOS Como se ha visto en esta memoria, la aplicación creada necesitará recopilar datos relativos a personas físicas para su funcionamiento. La aplicación estaría, en principio, planteada para ser usada en España por lo que debería adaptarse a la legislación española. En este sentido está creada la Ley Orgánica 15/1999, de Protección de Datos de Carácter Personal (LOPD)

161 La presente Ley Orgánica tiene por objeto garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades públicas y los derechos fundamentales de las personas físicas, y especialmente de su honor e intimidad personal y familiar. Para cumplir los requerimientos de dicha ley la empresa deberá básicamente de: Informar de la existencia de un fichero o ficheros con datos de carácter personal relativos a los usuarios registrados. Notificar los ficheros ante el Registro General de Protección de Datos para su inscripción. Facilitar y garantizar el derecho del acceso, modificación, cancelación de esos datos. Obtener el consentimiento para el tratamiento de los datos personales. Asegurarse que los datos son veraces y han sido obtenidos lícita y legítimamente y tratados para los fines que fueron obtenidos. Para más información se puede mirar esta guía puesta por la agencia de protección de datos. _responsable_ficheros.pdf 13.3 MANUAL DE INSTALACIÓN Y DESPLIEGUE INTRODUCCIÓN En el cd del proyecto se va a entregar el código fuente desarrollado con NetBeans aunque para desplegar la aplicación basta con el archivo.war generado, la base de datos.sql, el servidor Glassfish y los servicios de apache y mysql REQUISITOS Este breve manual está pensado para el despliegue en un entorno Windows. Será necesario tener instalado JDK, los servicios de Apache y MySql y el servidor GlassFish BASE DE DATOS, MYSQL Y APACHE Para instalar los servicios de mysql, apache y cargar la base de datos lo más simple es descargarse Xampp Xampp es un servidor independiente de software libre que permite la instalación de un servidor apache y una base de datos Mysql de forma sencilla. Incluye la herramienta phpmyadmin para manejar fácilmente ese tipo de bases de datos. 148

162 Ilustración 73: Recorte de pantalla de Xampp Con Xampp instalado para cargar la base de datos hay que: 1. Iniciar los servicios de apache y mysql. 2. Ir al navegador y en la ruta poner localhost. 3. Ir a phpmyadmin. 4. Crear base de datos con nombre hostalbd. 5. En la pestaña importar cargar el archivo.sql Ilustración 74: Recorte de myphpadmin 149

163 En el proceso de carga se ejecutan automáticamente todas las consultas incluidas en ese archivo y al finalizar ya se tiene la base de datos instalada INSTALACIÓN DE SERVIDOR DE APLICACIONES WEB Y DESPLIEGUE Para cargar e implementar la aplicación se usará Glassfish. Una vez instalado hay que utilizar la utilidad asadmin. Para ello se puede añadir al path de Windows la carpeta bin creada en la ruta de instalación elegida para Glassfish, o ejecutar este comando en símbolo del sistema con la ruta completa donde está asadmin. asadmin start-domain Una vez que el dominio está creado correctamente hay que escribir de nuevo en consola. asadmin deploy {ruta al archivo.war} Otra opción para desplegar la aplicación tras escribir el comando de asadmin start-domain es entrar en la página de configuración de GlassFish en localhost:4848. Tras escribir el usuario y contraseña que elegimos en la instalación, habrá que ir al apartado aplicaciones desde donde cargaremos el archivo.war. Ilustración 75 : Pantalla del servidor GlassFish 150

164 Debería desplegarse también correctamente. Con la aplicación desplegada se puede acceder a ella y probarla en o clickeando en Iniciar desde la página de Glassfish MANUAL DE ADMINISTRADOR Y USUARIO INTRODUCCIÓN Debido a que es una aplicación bastante entendible y común no es necesario crear un manual muy extenso sobre cómo utilizarla. A continuación se pasará a mostrar brevemente algunas descripciones y capturas de como cada tipo de usuario interactuaría con la web VISITANTE Un visitante podrá ver información del hostal restaurante o registrarse en la página para poder hacer pedidos o reservas. Ilustración 76: Pantalla de información del hostal 151

165 Ilustración 77: Pantalla de registro de usuario USUARIO Un usuario registrado podrá ver y modificar sus datos en el enlace de perfil: Ilustración 78: Perfil de usuario También podrá realizar pedidos de productos desde el enlace de arriba de pedidos o desde el del lateral. 152

166 Ilustración 79: Listado de productos a la venta Irá seleccionando los que quiera comprar y finalizará su pedido clickeando primero en carro y después en finalizar pedido. Ilustración 80: Resumen del pedido 153

167 Un usuario también podrá realizar reservas de habitación y de comedor. Para las reservas de habitación primero elegirá las fechas de entrada y salida para comprobar si hay habitaciones libres. Ilustración 81: Elección de fechas de reserva de habitación Ilustración 82: Habitaciones libres para unas fechas 154

168 Si las hay, elegirá la habitación que le interese y completará la reserva. Ilustración 83: Resumen de reserva de habitación Respecto a las reservas de comedor, el usuario deberá elegir un horario, con su fecha y número de personas que van a acudir. Ilustración 84: Elección de datos para reserva de comedor. Y confirmará la reserva si hay sitio suficiente. 155

169 Ilustración 85: Confirmación de reserva de comedor. Finalmente un usuario podrá ver listados de sus pedidos y reservas abiertas o ya cerradas. Ilustración 86: Pantalla de listados de pedidos 156

170 Ilustración 87: Pantalla de listados de reservas ADMINGENERAL Un admingeneral se encargará de la gestión de usuarios, de las habitaciones del hostal, del tamaño del comedor y de la visualización de estadísticas. El administrador podrá ver, modificar o crear usuarios desde el enlace de Gestión Usuarios: Ilustración 88: Pantalla de administración de usuarios 157

171 Ilustración 89: Pantalla de listado de usuarios En el apartado de Gestión Hostal podrá crear y modificar habitaciones y sus tipos y ajustar el tamaño del comedor. 158

172 Ilustración 90: Pantalla de administración del hostal Y en el enlace de estadísticas el administrador podrá crear unas gráficas con información del estado del hostal restaurante. Podrá consultar datos de pedidos, registros o reservas según elija crear una gráfica u otra. 159

173 Ilustración 91: Página de generación de gráficas 160

174 ADMINCOCINA El administrador de cocina se encarga de todo lo relacionado con el sistema de pedidos. Creará los productos puestos a la venta online, finalizará los pedidos y podrá configurar el sistema con un horario de atención o actividad. Ilustración 92: Menú administración cocina En el menú de pedidos se podrá diferenciar entre los pedidos ya cerrados y los abiertos que quedan por atender. Si se hace click en esos enlaces aparecerá un listado de pedidos donde se podrá finalizarlos en el caso de que estén aún abiertos o simplemente consultarlos. 161

175 Ilustración 93: Pantalla administración de pedidos Ilustración 94: Pantalla de finalización de pedido 162

176 En sistema de pedidos estará toda la configuración: Ilustración 95: Configuración de sistema de pedidos El apartado de reservas de comedor será bastante similar, se podrán ver listados de reservas, abiertas o cerradas, que se podrán consultar o finalizar. Ilustración 96: Pantalla de administración de comedor 163

177 Ilustración 97: Listado de reservas de comedor Ilustración 98: Finalización de reserva de comedor. 164

178 ADMINRECEPCIÓN Los administradores de recepción serán los encargados en gestionar las reservas online, atendiendo a las entradas de clientes en el hostal con su reserva anteriormente hecha. Tendrán listados de reservas que deberán finalizar cuando el cliente deje el hostal o cuando cancele esa reserva. Ilustración 99: Menú administración de la recepción Ilustración 100: Listado de reservas de habitación abiertas 165

179 Elegirán la reserva abierta que deseen y la finalizarán. Ilustración 101: Resumen de reserva de habitación a finalizar 166