eRestaurante : prototipo de un restaurante digital

1 PROYECTO FINAL DE CARRERA: eRestaurante: Prototipo de un Restaurante Digital ALUMNA: Silvia Puchol Herrero DIRECTOR: Joan Fons i Cors CURSO: 2009/2010 2 3 ÍNDICE 1. INTRODUCCIÓN ......................................................................................................................................................................... 5 1.1 OBJETIVOS Y RESUMEN DEL PROYECTO ....................................................................................................................................... 5 1.2 PROBLEMA PLANTEADO ............................................................................................................................................................... 5 1.3 ESTRUCTURA DEL PROYECTO ....................................................................................................................................................... 6 2. ESPECIFICACIÓN DE REQUISITOS .............................................................................................................................................. 7 2.1 INTRODUCCIÓN ............................................................................................................................................................................ 7 2.1.1 Propósito........................................................................................................................................................................... 7 2.1.2 Ámbito .............................................................................................................................................................................. 7 2.1.3 Definiciones, acrónimos y abreviaturas ........................................................................................................................... 7 2.1.4 Referencias ....................................................................................................................................................................... 8 2.1.5 Visión global ..................................................................................................................................................................... 8 2.2 DESCRIPCIÓN GENERAL ................................................................................................................................................................ 9 2.2.1 Perspectiva del producto .................................................................................................................................................. 9 2.2.2 Funciones del producto..................................................................................................................................................... 9 2.2.3 Características del usuario ............................................................................................................................................. 10 2.2.4 Restricciones generales .................................................................................................................................................. 11 2.3 REQUISITOS ESPECÍFICOS ........................................................................................................................................................... 11 2.3.1 Requisitos de interfaces externas ................................................................................................................................... 11 2.3.2 Requisitos específicos ..................................................................................................................................................... 12 2.3.3 Restricciones de diseño ................................................................................................................................................... 16 3. ANÁLISIS ............................................................................................................................................................................... 19 3.1 DIAGRAMA DE CLASES ................................................................................................................................................................ 19 3.2 DIAGRAMA DE USUARIOS ........................................................................................................................................................... 21 3.3 MODELO NAVEGACIONAL .......................................................................................................................................................... 22 3.3.1 Modelo navegacional anónimo ...................................................................................................................................... 23 3.3.2 Modelo navegacional gerente ........................................................................................................................................ 23 3.3.3 Modelo navegacional camarero..................................................................................................................................... 27 3.3.4 Modelo navegacional cliente.......................................................................................................................................... 32 3.3.5 Modelo navegacional cliente normal ............................................................................................................................. 34 3.3.6 Modelo navegacional cliente web .................................................................................................................................. 36 4. DISEÑO ................................................................................................................................................................................. 39 4.1 NIVEL DE PRESENTACIÓN ........................................................................................................................................................... 39 4.1.1 Interfaz del usuario anónimo ......................................................................................................................................... 40 4.1.2 Interfaz del usuario gerente ........................................................................................................................................... 45 4.1.3 Interfaz del usuario camarero ........................................................................................................................................ 47 4.1.4 Interfaz del usuario cliente ............................................................................................................................................. 51 4.1.5 Interfaz del usuario cliente estándar .............................................................................................................................. 52 4.1.6 Interfaz del usuario cliente web ..................................................................................................................................... 53 4.2 NIVEL DE APLICACIÓN ................................................................................................................................................................. 54 4.3 NIVEL DE PERSISTENCIA .............................................................................................................................................................. 56 5. IMPLEMENTACIÓN E INTEGRACIÓN ....................................................................................................................................... 59 5.1 TECNOLOGÍAS ............................................................................................................................................................................. 59 5.2 HERRAMIENTAS .......................................................................................................................................................................... 64 5.3 DETALLES DE LA IMPLEMENTACIÓN ........................................................................................................................................... 65 6. CONCLUSIONES ..................................................................................................................................................................... 83 7. BIBLIOGRAFÍA ....................................................................................................................................................................... 85 8. ANEXOS ................................................................................................................................................................................ 87 8.1 ANEXO A: TABLAS DE LA BASE DE DATOS ................................................................................................................................... 87 8.2 ANEXO B: CONFIGURACIÓN SERVIDOR WEB APACHE ................................................................................................................ 91 8.3 ANEXO C: CONFIGURACIÓN CERTIFICADOS SEGURIDAD ........................................................................................................... 95 8.4 ANEXO D: MANUAL DEL USUARIO GERENTE ............................................................................................................................ 105 8.5 ANEXO E: MANUAL DEL USUARIO CAMARERO......................................................................................................................... 111 8.6 ANEXO F: MANUAL DEL USUARIO CLIENTE............................................................................................................................... 119 8.7 ANEXO G: MANUAL DEL USUARIO CLIENTE WEB ..................................................................................................................... 123 4 5 1. INTRODUCCIÓN Para empezar se explicará la finalidad, en qué consiste y la estructura de elaboración de este proyecto. 1.1 OBJETIVOS Y RESUMEN DEL PROYECTO El objetivo del proyecto, a grandes rasgos, es la implementación de una aplicación web, que gestione un restaurante desde el punto de vista de los usuarios gerente, camarero y cliente. No obstante, el objetivo más concreto es llevar a cabo la implementación utilizando un concepto innovador. Este concepto consiste en que el cliente tenga acceso a dicha aplicación desde su propia mesa y pueda seleccionar los productos que desee directamente desde ésta, sin tener que necesitar al camarero para realizar su pedido. A todo esto debemos añadir que la aplicación debe permitir interactuar con ella a los usuarios de una manera ágil y sencilla, dentro de las posibilidades de su funcionalidad. A su vez, otro de los objetivos, éste desde el punto de vista del desarrollador, es adquirir experiencia en la implementación de este tipo de sitios web, que cada vez están más extendidos en la sociedad. 1.2 PROBLEMA PLANTEADO Desarrollar un sitio web para un restaurante que permita:  A los gerentes gestionar el catálogo de productos y los empleados del restaurante.  A los camareros gestionar y atender los pedidos, obteniendo en tiempo real los pedidos de los clientes en sus terminales.  A los clientes realizar pedidos desde su mesa desde el primer momento en que llegan al restaurante, visualizar en qué estado se encuentran en tiempo real y realizar reservas cuando se conecten a la aplicación desde fuera del restaurante.  A cualquier usuario que se conecte a la aplicación conocer el restaurante consultando información diversa acerca del mismo y registrarse en el sistema. 6 1.3 ESTRUCTURA DEL PROYECTO En este apartado describiremos el proceso de elaboración completa de un proyecto de una aplicación web. En él se tratarán distintos puntos, como la especificación de requisitos; aquí trataremos de describir cómo será la aplicación final que obtendremos, las funciones que realizará, los tipos de usuarios que la utilizarán, etc. Para ello hemos seguido una guía, recomendada por la mayor parte de expertos en este campo, la especificación IEEE Standard 830 1998. La siguiente parte será la de análisis, en la cual se creará el diagrama de clases que ayudará a comprender la estructura de la aplicación. La sección de diseño vendrá a continuación, donde se estudiará el diseño por capas que vamos a utilizar (tres capas: de presentación, de lógica de la aplicación y de persistencia), y describiremos la interfaz gráfica de la aplicación, la base de datos, etc. En el siguiente capítulo, implementación e integración, explicaremos las tecnologías utilizadas para el desarrollo, así como las herramientas usadas. Además se explicará todo el desarrollo realizado hasta obtener el producto final. Para finalizar, se presentan una serie de conclusiones que se han obtenido durante la creación del sitio web y se hace referencia a la bibliografía utilizada. 7 2. ESPECIFICACIÓN DE REQUISITOS 2.1 INTRODUCCIÓN 2.1.1 Propósito Este sistema permitirá a los clientes realizar reservas y pedidos sobre la carta, y a los camareros conocer el estado de cada mesa y saber los platos a servir en cada momento. El principal objetivo de este software es permitir a los clientes de un restaurante obtener una mejor atención y a los camareros facilitarles y organizarles el trabajo. 2.1.2 Ámbito El producto software a desarrollar se denominará “eRestaurante”. 2.1.3 Definiciones, acrónimos y abreviaturas  ERS. Documento de Especificación de Requisitos Software.  Internet. Red de redes a escala mundial con millones de computadores interconectados entre ellos mediante el conjunto de protocolos TCP/IP. También se utiliza este nombre para designar cualquier red de redes que utilice las mismas tecnologías que Internet.  Web. El web o WWW (acrónimo en inglés de World Wide Web, gran telaraña mundial) es una red de páginas escritas en hipertexto, con el lenguaje de marcado HTML, y conectadas entre sí. Para acceder la única herramienta indispensable es un navegador web.  Software. Programas, aplicaciones.  Aplicación Web. Aplicación que los usuarios utilizan desde un servidor web a través de Internet o una intranet. La facilidad para actualizar y mantener aplicaciones sin la necesidad de instalar programas en los millones de clientes potenciales es una de las principales causas de su popularidad.  Usuario. Persona que después de haberse identificado hace uso de las funciones de la aplicación. 8  Sistema. Conjunto de partes interrelacionadas, hardware, software y de recurso humano.  Apache. Es un software libre, servidor HTTP de código abierto que implementa el protocolo HTTP/1.1.  Código abierto. Término usado para referirse a programas que se ofrecen con total libertad de modificación, uso y distribución bajo la regla implícita de no modificar dichas libertades hacia el futuro.  Protocolo. Conjunto de reglas que especifican el intercambio de datos u órdenes durante la comunicación entre sistemas.  Servidor web. Es un programa que se ejecuta continuamente en un ordenador manteniéndose a la espera de peticiones por parte de un cliente (un navegador web) y que responde a estas peticiones adecuadamente, mediante una página web que se exhibirá en el navegador o mostrando el respectivo mensaje si se detectó algún error.  MySQL. Sistema de gestión de base de datos. 2.1.4 Referencias Guía del IEEE std. 830 1998 para la especificación de requisitos del Software. 2.1.5 Visión global El producto a desarrollar es un sitio web, llamado “eRestaurante”, orientado a la realización de pedidos en un restaurante mediante un terminal, de forma que los camareros tengan un control individualizado, a través de la aplicación, de lo que se ha pedido y servido en cada mesa. El objetivo es facilitar a los clientes la realización de sus pedidos y a los camareros la atención de los mismos. Entre las ventajas de la implantación de este sistema destacan entre otras que los clientes no deberán sufrir esperas para realizar su pedido (en cuanto lleguen podrán comenzar a pedir y cuando confirmen el pedido podrán pagar con la tarjeta si lo desean), lo que agilizará el servicio y permitirá conseguir una mayor satisfacción del cliente. 9 2.2 DESCRIPCIÓN GENERAL 2.2.1 Perspectiva del producto El producto software no depende de ningún sistema mayor, es independiente. 2.2.2 Funciones del producto Podemos clasificarlas en dos partes diferenciadas: Funciones de visualización: Nuestra aplicación visualizará información relacionada con el restaurante, los clientes y los pedidos. a) Función de gestión de la información  Consulta de los productos existentes y sus precios.  Consulta de los menús de oferta.  Envío de comentarios y sugerencias.  Recordatorio de pedidos anteriores realizados por el cliente  Visualizar los pedidos (camareros). Los camareros podrán ver en todo momento la descripción de los pedidos realizados de sus mesas, así como el estado en el que se encuentran: servido o sin servir.  Visualización de pedidos (clientes). El cliente podrá acceder a un listado con los pedidos realizados, los productos que componen cada pedido y el estado (servido o sin servir) de cada producto del mismo. Funciones de mantenimiento/actualización de la base de datos a) Función de control de usuarios  Registro e identificación de usuarios  Asignar clientes a una mesa. Los camareros serán los encargados de comprobar qué mesas hay libres en el restaurante y asignar a los clientes a una mesa libre. b) Función de gestión de los productos  Añadir productos. Se podrán añadir productos al restaurante.  Gestionar productos. Se podrán modificar y eliminar productos existentes. 16 Requisito funcional 28: Eliminar producto Podrá eliminar un producto existente en el catálogo de productos del restaurante. Requisito funcional 29: Registrar camarero Podrá dar de alta en el sistema a un nuevo camarero introduciendo como dato el nombre y la foto solamente, ya que sólo interesa tener a los camareros registrados para controlar su asignación a las mesas. Requisito funcional 30: Dar de baja camarero Se podrán borrar los datos de cualquier camarero que haya en el sistema. Requisito funcional 31: Crear tipo de producto El gerente podrá añadir un tipo de producto al restaurante especificando el nombre de la categoría de producto. Requisito funcional 32: Modificar tipo de producto Se podrá modificar el nombre de la categoría y los productos que la componen. Requisito funcional 33: Eliminar tipo de producto Se podrá eliminar la categoría del producto. 2.3.3 Restricciones de diseño 2.3.3.1 Estándares cumplidos En el desarrollo de la aplicación se hará uso de XHTML para tener la certeza de una mayor compatibilidad con los navegadores. Se implementará siguiendo la versión XHTML 1.0 transicional junto con hojas de estilo CSS 2.1 para optimizar posibles cambios futuros en la estética de la aplicación. 2.3.3.2 Limitaciones hardware Para que la aplicación funcione correctamente y que los tiempos de espera sean aceptables, es recomendable una buena conexión a Internet. En cuanto a la instalación del servidor web con soporte de ASP.NET y el de la base de datos, se podrá realizar en un computador de prestaciones medias, 17 pero para soportar una mayor carga de usuarios es recomendable un ordenador de mayores prestaciones. 18 19 3. ANÁLISIS El propósito principal del análisis es obtener una descripción lógica del sistema a desarrollar, es decir, describir formalmente mediante modelos las características de la aplicación. Estos modelos servirán posteriormente de guía para obtener el producto deseado. Para ello utilizaremos el lenguaje de modelado UML (Lenguaje Unificado de Modelado). Se trata de un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. Éste tiene varios diagramas aunque únicamente desarrollaremos el diagrama de clases. 3.1 DIAGRAMA DE CLASES El diagrama de clases en UML es el diagrama principal para el modelado y el diseño en la programación orientada a objetos y sirve para representar las clases del sistema, que corresponden a tipos de usuarios, opciones, las relaciones que se establecen entre ellas, ya sean de herencia o de tipo estructural. A continuación se muestra el diagrama de clases para el erestaurante. 20 Figura 3.1.1. Diagrama de clases 21 Utilizamos la entidad <Usuario> para representar los usuarios que pueden autenticarse en el sistema: gerente, camarero y cliente, es por este motivo que <Cliente> hereda de <Usuario>, porque los clientes tienen las propiedades del <Usuario> más otras extra, pero el usuario gerente no necesita almacenar la información del los clientes tales como: nombre, teléfono, apellido1, etc. Algo similar sucede con los camareros, se ha decidido diferenciar entre el usuario camarero (puede autenticarse) y el empleado camarero. Esto se ha realizado en base a que cada camarero no necesita un usuario, esta aplicación está pensada para que varios camareros entren con el mismo usuario para así tener una vista general del restaurante. Cada cliente puede tener asignados pedidos, aunque por la aplicación se controla que cada cliente solamente tenga un pedido activo, el resto de pedidos pasarán a formar parte del histórico. Cada pedido está, a su vez relacionado con un camarero que lo atenderá, una mesa y las consumiciones seleccionadas por el cliente. Una consumición no es más que un ítem de consumición que almacena las siguientes propiedades: cantidad (del ítem de consumición), precio, servida y confirmada. Asimismo, un ítem de consumición puede ser un producto (de un tipo de producto) o un menú. Observamos también en el diagrama la entidad <Reserva>, de manera que un cliente podrá realizar una reserva para una fecha y una mesa, cuando llegue al restaurante se le creará un pedido para la mesa reservada en esa fecha o posterior. Por último, nuestra aplicación está preparada para almacenar comentarios procedentes de clientes o usuarios anónimos. 3.2 DIAGRAMA DE USUARIOS En nuestra aplicación web tenemos 5 tipos de usuarios y cada tipo de usuario representa un conjunto de usuarios con objetivos y responsabilidades comunes en el sistema. Estos usuarios son: anónimo, cliente, cliente web, camarero y gerente, y sus inter-relaciones así como su modo de acceso al sistema se muestran en el diagrama siguiente: 22 Figura 3.2.1. Diagrama de usuarios Como se ve en la figura, a nuestra aplicación podemos acceder como usuario anónimo o como autenticado, esto es, como: gerente, camarero o cliente. El usuario cliente se especializa en dos: Cliente normal y Cliente web. El cliente normal se asocia a un cliente que accede a la aplicación físicamente desde el restaurante, mientras el cliente web a uno que accede desde fuera del restaurante y que tiene acceso a funcionalidad diferente. Resulta importante destacar que el cliente como tal no existe en la aplicación, se utiliza en el diagrama para indicar que el cliente normal (estándar) y el web comparten funcionalidad. 3.3 MODELO NAVEGACIONAL Para representar las interfaces de usuario nos hemos basado en OOWS, un método de producción de aplicaciones web que introduce nuevos conceptos orientados a objetos para dar una noción de semántica navegacional y de presentación. Así que 23 para cada usuario vamos a comentar su interfaz y su navegabilidad en el sistema mediante mapas navegacionales. 3.3.1 Modelo navegacional anónimo 3.3.1.1 Mapa navegacional Figura 3.3.1.1.1 Mapa navegacional usuario anónimo Todos los contextos a los que pueden acceder los usuarios anónimos son de exploración, como se puede ver su mapa navegacional es muy sencillo, con sólo un nivel. Ninguno de los contextos tiene acceso a la base de datos así que omitimos el apartado de “Contextos navegacionales”. 3.3.2 Modelo navegacional gerente 3.3.2.1 Mapa navegacional 24 Figura 3.3.2.1.1 Mapa navegacional usuario gerente Se trata de un mapa navegacional sencillo, ya que el usuario de tipo gerente es el encargado de realizar tareas de administración: creación y modificación de productos, empleados, etc., acciones relativamente sencillas, es por esto que la longitud máxima de los caminos de navegación es uno. Se ha decidido que desde cada contexto de secuencia se pueda volver directamente al contexto de exploración desde el que llegó, sin necesidad de utilizar los enlaces de exploración para proporcionar una mayor agilidad, imprescindible en tareas de administración. 3.3.2.2 Contextos navegacionales 25 32 3.3.4 Modelo navegacional cliente 3.3.4.1 Mapa navegacional Figura 3.3.4.1.1 Mapa navegacional usuario cliente El mapa navegacional del usuario cliente, con tal sólo dos contextos de exploración y uno de secuencia, se caracteriza por su sencillez, ya que el usuario cliente está relacionado con los usuarios cliente normal y cliente web, que son especializados de el primero, y que tienen funcionalidad extra. Precisamente esta sencillez de la que hablamos es uno de los objetivos de tener en nuestro diagrama de usuarios un usuario virtual (“sin permiso”). 33 3.3.4.2 Contextos navegacionales Descripción de los contextos:  Historial de pedidos. Este contexto muestra los información de los pedidos que ya no están activos (han sido pagados ya), para el cliente conectado. Define dos relaciones de dependencia contextual con Mesa y Camarero para recuperar información extra, y una relación de contexto, recíproca, en Pedido, que define navegabilidad a Detalles de Pedido a través del enlace “Detalles pedido”. 34  Detalles de pedido. Visualiza datos extra del pedido seleccionado, mediante relaciones de dependencia contextual con Mesa, Camarero, Consumicion e ItemConsumicion.  Mis datos personales. Muestra información personal del cliente autenticado en la aplicación y permite realizar las operaciones: modificar_datos() y cambiar_contraseña(). 3.3.5 Modelo navegacional cliente normal 3.3.5.1 Mapa navegacional Figura 3.3.5.1.1 Mapa navegacional cliente estándar De este mapa navegacional podemos destacar lo mismo que del mapa navegacional anterior, el del usuario virtual Cliente. Se trata de un mapa navegacional de un usuario especializado, por lo tanto, aunque el resultado es un mapa sencillo, no implica que la funcionalidad del usuario sea reducida, ya que, hereda la del usuario padre. 3.3.5.2 Contextos navegacionales A continuación se adjuntan los contextos navegacionales del usuario “Cliente estándar”, mostramos solamente los contextos que añaden nuevas propiedades navegacionales. 35 Descripción de los contextos:  Mi Pedido. Muestra información sobre el pedido activo para el usuario conectado. Establece dos relaciones de dependencia contextual con Consumicion e ItemConsumicion para recuperar información extra del pedido, y dos relaciones recíprocas que definen navegabilidad: en Pedido con destino Detalles Pedido y en ItemConsumicion con destino Detalles ItemConsumicion. Además, permite realizar operaciones de pago y confirmación del pedido, y de adición y eliminación de consumiciones a/del mismo. 36  Detalles ItemConsumicion. Visualizar los datos del ítem de consumición seleccionado de una manera detallada. Para ello, utiliza relaciones sin navegabilidad con Menu, Producto, ProductosMenu y TipoProducto. También tenemos una relación de contexto entre ItemConsumicion y Pedido con destino Mi Pedido. Destaca en el contexto que la vista Producto aparece duplicada y es que el contexto Detalles ItemConsumicion intenta mostrar información diferente según el ítem seleccionado sea un producto o un menú. De manera que sí seleccionamos un menú seguiremos la primera rama y se mostraran los productos del mismo (cantidad + nombre), mientras que si se selecciona un producto se seguirá la segunda rama y se visualizará el nombre del producto más el tipo de producto al que pertenece. 3.3.6 Modelo navegacional cliente web 3.3.6.1 Mapa navegacional Figura 3.3.6.1.1 Mapa navegacional usuario Cliente web La explicación es la misma que para el cliente estándar (ver 3.3.5.1), si bien este mapa todavía es más sencillo, ya que la funcionalidad del cliente web prácticamente se reduce a realizar reservas. 37 3.3.6.2 Contextos navegacionales Descripción del contexto:  Reservas. Este contexto muestra un listado de las reservas del cliente autenticado en el sistema, tan sólo tiene una relación de dependencia contextual con Mesa, para recuperar el número de la misma, y permite realizar las operaciones creación y cancelación de una reserva. 38 39 4. DISEÑO El diseño de la aplicación se basa en una de las arquitecturas multicapa que se está utilizando actualmente de forma más extendida es la arquitectura de tres capas (threetier) lógicas. En ella tenemos las siguientes capas:  Nivel de Presentación.  Nivel de Dominio o de Aplicación.  Nivel de Persistencia. Figura 4.1. Arquitectura genérica de tres capas 4.1 NIVEL DE PRESENTACIÓN Son los componentes software que implementan la interacción con los usuarios, a través de una representación visual de la aplicación, proporcionando a estos una forma de acceder y controlar los datos y los servicios de los objetos. En nuestro caso serán las páginas web, formularios, enlaces, tablas, etc., y darán acceso a usuarios invitados, camareros, clientes y administrador. Cada contexto del modelo navegacional tiene como resultado una interfaz en nuestra aplicación: cada atributo representa la información que se mostrará en 40 cada página, y cada operación las acciones que podremos realizar desde cada una de ellas. A continuación, mostramos las interfaces de cada uno de los usuarios. 4.1.1 Interfaz del usuario anónimo Al acceder a la página web principal el navegador nos mostrará la página de bienvenida a eRestaurante. Figura 4.1.1.1 Página principal Podemos diferenciar varias zonas:  Zona institucional (1). La compone el logo de la empresa.  Zona de enlaces de aplicación (2). Aparecen enlaces a funcionalidades/enlaces comunes a todas las aplicaciones para la web: login, home, a la carta, menús, etc.  Zona de información (3). Zona encargada de mostrar información de interés. Cuando naveguemos por la aplicación, la información irá cambiando solamente en esta zona, las demás mantendrán sus contenidos, adecuándose al contexto navegacional.  Zona de entrada de datos (4). Zona encargada de proporcionar un formulario de entrada de datos al usuario para su autenticación en la aplicación. Esta zona cambiará en función de desde dónde acceda el usuario a la aplicación, mostramos a continuación un árbol informativo de qué se muestra dependiendo de la ubicación mencionada: o Restaurante: 41  PC correspondiente a empleados  Zona empleados  PC correspondiente a cliente  Zona clientes o Fuera del restaurante  Zona clientes (Web) Seguidamente, mostramos las capturas que lo confirman. Figura 4.1.1.2 Zona empleados Figura 4.1.1.3 Zona clientes web Si navegamos por los distintos enlaces de aplicación podremos acceder a información sobre la carta, el menú y fotografías del restaurante, así como enviar 48 Figura 4.1.3.1 Página principal camarero: Estado de las mesas Seguidamente se muestran las zonas en las que se divide la página, las que ya han sido explicadas en el usuario anónimo o gerente solamente las citamos.  Zona institucional (1).  Zona de enlaces de aplicación (2).  Zona de ubicación (3).  Zona de información (4).  Zona de logout (5).  Zona de navegación (6).  Zona de estructuras de acceso (7). Zona que contiene los mecanismos avanzados de exploración, en este caso los filtros de día y hora, en función de los cuales se muestra el estado de las mesas. Si navegamos por los distintos enlaces de aplicación, podremos consultar información sobre el estado de las mesas, pedidos, clientes, comentarios e histórico de pedidos. A continuación, mostramos las páginas que se corresponden con dicha información. De nuevo, podemos ver cómo van cambiando las zonas de información y ubicación, y, también la de estructuras de acceso, ya que no es común a todas las páginas del usuario de tipo camarero. 49 Figura 4.1.3.2 Pedidos Figura 4.1.3.3 Clientes 50 Figura 4.1.3.4 Comentarios Figura 4.1.3.5 Historial de pedidos En la página de Historial de pedidos también tenemos zona de estructuras de acceso, tenemos un filtro de fechas para los pedidos, ya que el volumen de pedidos inactivos en un restaurante al cabo de un mes puede ser superior a cien, y sin filtro la página sería muy poco legible. 51 4.1.4 Interfaz del usuario cliente Como se comenta en la sección 3.2, el usuario cliente como tal no existe en la aplicación, se trata de un usuario abstracto. Como se ve en el diagrama de usuarios de la aplicación (Figura 4.1.1), de él extienden los clientes normal (estándar) y web. Así pues, ambos tipos de cliente tienen en común los enlaces de exploración: Historial de pedidos y Mis datos personales. Figura 4.1.4.1 Historial de pedidos (Cliente estándar) 52 Figura 4.1.4.2 Mis datos personales (Cliente web) 4.1.5 Interfaz del usuario cliente estándar Al entrar a la aplicación como cliente estándar accederemos a la página de Mi Pedido. Figura 4.1.5.1 Página principal usuario cliente: Mi pedido 53 Las zonas en las que se divide la página son las siguientes (las ya explicadas sólo las citamos:  Zona institucional (1).  Zona de enlaces de aplicación (2).  Zona de ubicación (3).  Zona de logout (4). Permite al usuario autentificado cerrar la sesión existente.  Zona de información (5).  Zona de navegación (6). Las pantallas Historial de pedidos y Mis datos personales ya han sido mostradas para el usuario virtual Cliente y pueden ser consultadas en las figuras 4.1.4.1 y 4.1.4.2, respectivamente. 4.1.6 Interfaz del usuario cliente web Al entrar a la aplicación como cliente web accederemos a la página de Reservas. Figura 4.1.6.1 Página principal usuario Cliente web: Reservas Las zonas en las que se divide la página son las siguientes (las ya explicadas sólo las citamos:  Zona institucional (1).  Zona de enlaces de aplicación (2).  Zona de ubicación (3). 54  Zona de logout (4). Permite al usuario autentificado cerrar la sesión existente.  Zona de información (5).  Zona de navegación (6). Las pantallas Historial de pedidos y Mis datos personales ya han sido mostradas para el usuario virtual Cliente y pueden ser consultadas en las figuras 4.1.4.1 y 4.1.4.2, respectivamente. 4.2 NIVEL DE APLICACIÓN Es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. En esta capa se implementa el comportamiento del sistema, las operaciones descritas en el diagrama de clases, siguiendo una metodología OO (Orientada a Objetos) y son todas las clases, atributos, funciones, etc. Además, al tratarse de una aplicación web, también abarca nuevos servicios, como la gestión de usuarios (log in, altas) o la monitorización de la navegación (sesiones, caminos navegacionales). En cuanto al acceso a la base de datos, en nuestro sistema, cada tabla de la misma se corresponde con una clase, la cual implementa los métodos de acceso. Sintaxis: “<nombretabla>_bd“ (ver más en sección 5). A continuación, mostramos el diagrama de clases de diseño, donde se representa lo comentado en los párrafos anteriores. Podemos observar como cada clase depende de una superior identificada por el nombre “MasterPage<TipoUsuario>”. De esta manera conseguimos simplificar el diagrama y a posteriori el código de la aplicación (ver más en sección 5). 55 4.2.1 Diagrama de clases de diseño 56 4.3 NIVEL DE PERSISTENCIA Es donde residen los datos y es el nivel encargado de acceder a los mismos. En nuestro caso está formado por un gestor de base de datos que realiza todo el almacenamiento de datos y recibe solicitudes de almacenamiento o recuperación de información desde la capa de negocio. Seguidamente mostramos el diagrama de base de datos del eRestaurante. Para consultar la información detallada de las tablas y columnas véase el Anexo A: Tablas de la base de datos. 57 Figura 4.3.1 Diagrama de base de datos 64 remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. Cabe mencionar que el uso del protocolo HTTPS no impide que se pueda utilizar HTTP. Es aquí, cuando nuestro navegador nos advertirá sobre la carga de elementos no seguros (HTTP), estando conectados a un entorno seguro (HTTPS). Los protocolos https son utilizados por navegadores como: Safari (navegador), Internet Explorer, Mozilla Firefox, Opera,... entre otros. Es utilizado principalmente por entidades bancarias, tiendas en línea, y cualquier tipo de servicio que requiera el envío de datos personales o contraseñas. El puerto estándar para este protocolo es el 443. Para conocer si una página web que estamos visitando, utiliza el protocolo https y es, por tanto, segura en cuanto a la transmisión de los datos que estamos transcribiendo, debemos observar si en la barra de direcciones de nuestro navegador, aparece https al comienzo, en lugar de http. Algunos navegadores utilizan un icono (generalmente un candado) en la parte derecha de la barra de direcciones para indicar la existencia de un protocolo de comunicaciones seguro e incluso cambian el color del fondo de la barra de direcciones por amarillo (Firefox) o verde (Internet Explorer) para identificar páginas web seguras. 5.2 HERRAMIENTAS Se ha utilizado como herramienta base de este proyecto, por su sencillez y facilidad de instalación y de gestión, el paquete XAMPP 1.7.1, que contiene:  Servidor web Apache 5.0.51a.  SGBD MySQL 5.1.33.  MyPhpAdmin 3.1.3.1.  Servidor de correo Mercury/32 v4.6. Para la creación del certificado de seguridad que nos permite usar el protocolo https en nuestro servidor web , por lo tanto, que la información comprometida se envíe de forma segura entre páginas, hemos utilizado OpenSSL, de código abierto y libre descarga. Para el análisis y el diseño de nuestra aplicación hemos empleado:  MOSkitt 0.9.0. Herramienta Case libre basada en Eclipse. La hemos utilizado para la creación de los diagramas de clases y base de datos, ya 65 que permite realizar una transformación bastante acertada desde el primero al segundo.  StarUML. Herramienta de modelado UML de código abierto, gratuita, destacada por su rapidez y sencillez. Con ella se ha realizado el resto de diagramas de la etapa de diseño:  Diagrama de usuarios  Mapas navegacionales  Contextos navegacionales Para la implementación del código hemos utilizado Microsoft Visual Web Developer 2008 Express, ya que, es el entorno de desarrollo con ASP.NET más completo del mercado. Llegado a este punto resulta necesario explicar el porqué de la utilización de un servidor Apache con sistema de gestión de base de datos MySQL en combinación con el lenguaje ASP.NET, que, obviamente, no es lo más habitual ni lo más eficiente. El porqué es muy sencillo, simplemente es una cuestión de investigación y, de alguna manera, un reto: conseguir hacerlas funcionar y, comprobar de primera mano cómo se comporta una aplicación mezclando dos tecnologías que, a priori, no están preparadas o pensadas para trabajar juntas. En el apartado correspondiente se expondrán las conclusiones. 5.3 DETALLES DE LA IMPLEMENTACIÓN PÁGINAS PRINCIPALES Para que el desarrollo del sitio web resultara más sencillo, rápido y organizado a medida que avanzáramos en él, hemos utilizado páginas principales (master pages), concretamente, una página principal por cada tipo de usuario (anónimo, empleado, gerente y cliente), ya que, cada uno de estos usuarios precisan de una zona de navegación distinta (un menú distinto). De esta forma, una vez tenemos las cuatro páginas principales creadas ya sólo tenemos que preocuparnos del contenido de las mismas, y es lo único que tendremos que implementar en el resto de páginas, que se basaran en éstas. Las páginas principales permiten definir el aspecto, el diseño y el comportamiento estándar que se desea que tengan todas las páginas (o un grupo de páginas) de la aplicación en una sola página principal. A partir de ella se pueden crear páginas de contenido individuales que incluyan lo que se desea mostrar. Cuando los usuarios solicitan las páginas de contenido, éstas se combinan con la página principal para dar como resultado una página con el diseño de la página principal y el contenido de la página de contenido. 66 En definitiva, su utilización nos da muchas ventajas, ya que proporcionan una funcionalidad que tradicionalmente los programadores creaban copiando el código, el texto y los elementos de control existentes repetidamente, mediante conjuntos de marcos, archivos de inclusión de elementos comunes, controles de usuario de ASP.NET, etc. Entre las ventajas de las páginas principales se incluyen las siguientes:  Permiten centralizar las funciones comunes de las páginas para que las actualizaciones puedan llevarse a cabo en un solo lugar.  Facilitan la creación de un conjunto de controles y código, y aplican los resultados en un conjunto de páginas. Por ejemplo, se pueden utilizar los controles en la página principal para crear un menú que se aplique a todas las páginas.  Proporcionan un modelo de objetos que permite personalizar la página principal a partir de páginas de contenido individuales. A continuación, le voy a dar un enfoque más práctico a este apartado para tratar de demostrar lo comentado. Para que una página sea página principal debe tener un encabezado similar al que ponemos de ejemplo al comienzo de la página de diseño (la que tendrá el código HTML): En la propiedad “CodeFile” deberemos poner la página que almacena el código de nuestra página principal. Deberemos especificar en ella la zona o zonas de contenido (pueden haber varias), es decir, donde se situará la información de las páginas que hereden de la página principal. Esto se consigue mediante uno o varios controles ASP.NET llamados “ContentPlaceHolder”. Además, como la aplicación la hemos desarrollado con AJAX debemos añadir también un ScriptManager en la sección en la que queramos utilizar estos controles: A excepción de estos dos detalles el código HTML será como el de cualquier página (teniendo en cuenta que cualquier control asp.net debe ir dentro de una etiqueta <form> que se ejecute en el servidor <form runat=”Server”>) y para que se vea claro ponemos un ejemplo: <%@ Master Language="VB" CodeFile="MasterPageAnonimo.master.vb" Inherits="MasterPageAnonimo" %> <asp:ScriptManager ID="ScriptManager1" runat="server" EnablePartialRendering="true" /> <asp:ContentPlaceHolder id="ContentPlaceHolder2" runat="server"> </asp:ContentPlaceHolder> 67 <%@ Master Language="VB" CodeFile="MasterPageAnonimo.master.vb" Inherits="MasterPageAnonimo" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title>eRestaurante</title> <link rel="Stylesheet" type="text/css" href="css/style.css"/> <asp:ContentPlaceHolder id="head" runat="server"> </asp:ContentPlaceHolder> </head> <body> <div id="container"> <div id="page"> <div id="header"></div> <div id="menu"> <div class="menu_top"></div> <div> <div class="menu_middle"><a id="quienes_somos" href="/eRestaurante/index.aspx">Quiénes somos</a></div> <div class="menu_middle"><a id="a_la_carta" href="/eRestaurante/secciones/Carta.aspx">A la carta</a></div> <div class="menu_middle"><a id="menus" href="/eRestaurante/secciones/Menus.aspx">Menús</a ></div> <div class="menu_middle"><a id="fotos" href="/eRestaurante/secciones/Fotos.aspx">Fotos</a></div> <div class="menu_middle"><a id="contacto" href="/eRestaurante/secciones/Contacto.aspx">Contacto</a> </div> </div> <div class="menu_bottom"></div> <div id="zona_cliente"> <a href="/eRestaurante/anonimo/auth.aspx"> <asp:HyperLink ID="ZonaHyperLink" NavigateUrl="/eRestaurante/anonimo/auth.aspx" runat="server" Text=""></asp:HyperLink> </a> </div> </div> 68 En cuanto a las páginas que hereden de una página principal deben comenzar con esta cabecera: MaterPageFile: ruta de la página principal de la que hereda. CodeFile: página que tiene el código fuente de esta página. Y donde queramos que vaya el contenido utilizar un control ASP.NET llamado “Content”: Seguidamente mostramos al igual que hemos hecho con la página principal un código completo de página. <div id="content_ext"> <div id="navigational_way"> </div> <div id="content_int"> <form id="form1" runat="server"> <div> <asp:ScriptManager ID="ScriptManager1" runat="server" /> <asp:ContentPlaceHolder id="ContentPlaceHolder1" runat="server"> </asp:ContentPlaceHolder> </div> </form> </div> </div> <div id="footer"> </div> </div> </div> </body> </html> <%@ Page Title="" Language="VB" MasterPageFile="~/MasterPageAnonimo.master" AutoEventWireup="false" CodeFile="index.aspx.vb" Inherits="img_Default" %> <asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server"> AQUI VA EL CONTENIDO </asp:Content> <%@ Page Title="" Language="VB" MasterPageFile="~/MasterPageAnonimo.master" AutoEventWireup="false" CodeFile="index.aspx.vb" Inherits="img_Default" %> <asp:Content ID="Content1" ContentPlaceHolderID="head" Runat="Server"> </asp:Content> <asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server"> <div class="texto"> 69 HOJAS DE ESTILO (CSS) Otro detalle que puede resultar interesante comentar es en relación a la implementación de las CSS. Tenemos una sola hoja de estilo para toda nuestra aplicación, no obstante, esto no es trivial en cualquier aplicación, ya que, Internet Explorer 8 cumple los estándares establecidos por el W3C en mucha menor medida que Mozilla, lo que ocasiona que lo que con una hoja de estilos se ve perfectamente en Mozilla, se vea distinto en IE8 y al revés. Para solucionar este problema utilizamos un hack, los caracteres “\9” detrás de la propiedad css que nos convenga, lo que hace que Visual Studio nos avise de que tenemos fallos pero no evitan de ninguna manera que la aplicación web funcione correctamente. Este hack lo que hace es que el navegador IE entienda el estilo pero Mozilla no, de manera que podemos definir estilos diferentes para la misma propiedad. A continuación se muestra un ejemplo para terminar de comprenderlo. <div><span class="destacado">eRestaurante</span> le da la bienvenida y espera que quede satisfecho con nuestros servicios.</div> <br /> <div>Nuestro objetivo es que disfrute con nuestra comida, elaborada con la máxima calidad y el mayor de los cuidados, así como ofrecerle una <span class="negrita">metodología innovadora</span> en la atención al cliente, que pretende darle acceso a un servicio en el que las esperas se minimizan.</div> <img id="eRestauranteTenedores" src="img/tenedores.jpg" alt="eRestaurante" title="Carlos Porto / FreeDigitalPhotos.net" class="imagen-tenedores" /> <br /> <div>Usted podrá realizar su pedido desde el primer instante en el que tome asiento, seleccionando los productos que desee en nuestra <span class="negrita">carta online</span>. Nuestros camareros quedarán informados al minuto automáticamente y estarán, por supuesto, en todo momento a su disposición.</div> <br /> <div>Le ofrecemos además un ambiente agradable, moderno y acogedor, acorde a nuestro <span class="negrita">estilo innovador</span>.</div> </div> </asp:Content> 70 El navegador Mozilla cogerá el ancho 70% y el Internet Explorer 100%. AJAX La incorporación de la tecnología AJAX al proyecto ha sido fundamental para dotarla de rapidez y mayor dinamismo. Para el funcionamiento de esta tecnología en nuestra aplicación sobre Apache hemos tenido que añadir los ficheros ScriptResource.axd y WebResource.axd a la raíz del proyecto web, si no los ponemos, el servidor los busca, no los encuentra y no funciona correctamente. UpdatePanel y Triggers Para el desarrollo con esta tecnología se ha necesitado tener la utilización de los siguientes controles.  UpdatePanel La utilización del control UpdatePanel es la base del desarrollo web con AJAX. Definimos dentro de un UpdatePanel los controles que queremos que se actualicen sin necesidad de refrescar toda la página, de forma que solamente se actualizarán las zonas que recojan el evento lanzado por un control determinado. Seguidamente, mostramos un ejemplo gráfico de la distribución de UpdatePanel sobre nuestra aplicación. .mini-boton { background-color: #666666; color: White; border: solid 1px #333333; width: 70%; width: 100%\9; } 71 Figura 5.3.1 Dos UpdatePanel Como se ve en la figura anterior, en la página MisDatosPersonales.aspx tenemos dos UpdatePanel: o UpdatePanel 1. Contiene los datos personales del cliente. o UpdatePanel2. Contiene los botones de acción. Al pulsar sobre alguno de los botones del UpdatePanel2 se actualizarán los datos personales (UpdatePanel1) sin necesidad de hacer postback. Además, en este caso, también cambiarán los botones. Resultado: 72 Figura 5.3.2 Botón modificar pulsado Como se ve en la figura los campos de datos han cambiado y también los botones, sin embargo, la página no ha sufrido una actualización completa.  Triggers Se utiliza el control AsyncPostBackTrigger para que los controles puedan ser los desencadenadores de un control UpdatePanel. Los controles que son los desencadenadores de un panel de actualización provocan una actualización del contenido del panel después de una devolución de datos asincrónica. Utilizamos un Trigger de tipo AsyncPostBackTrigger por cada evento de un control que queramos que actualice nuestro panel al desencadenarse. Siguiendo con nuestro ejemplo, los triggers para el UpdatePanel 1 son el evento click de los botones: o Modificar. o Cambiar contraseña. o Cancelar cambiar contraseña. o Cancelar. Resulta necesario destacar que estos dos controles explicados son la base, pero ni mucho menos los únicos, AJAX es mucho más rico y extenso, pero son los que más predominan en nuestra aplicación. A continuación mostramos un ejemplo de nuestro código con estos controles. 73 <asp:Content ID="Content3" ContentPlaceHolderID="ContentPlaceHolder2" Runat="Server"> <div class="centrar"> <div class="marron"><span class="negrita">Mis Datos Personales</span></div><br /> </div> <div class="contenedor"> <div class="caja-centrada-3"> <asp:UpdatePanel ID="DatosUpdatePanel" runat="server" UpdateMode="Conditional"> <ContentTemplate> <!— AQUI VAN LOS TEXTBOX PARA LOS DATOS --> </ContentTemplate> <Triggers> <asp:AsyncPostBackTrigger ControlID="ModificarButton" EventName="Click" /> <asp:AsyncPostBackTrigger ControlID="CancelarButton" EventName="Click" /> <asp:AsyncPostBackTrigger ControlID="CambiarPasswdButton" EventName="Click" /> <asp:AsyncPostBackTrigger ControlID="CancelarCambiarPasswdButton" EventName="Click" /> </Triggers> </asp:UpdatePanel> </div> </div> <asp:UpdatePanel ID="BotonesPassUpdatePanel" runat="server" UpdateMode="Conditional"> <ContentTemplate> <div class="centrar"> <asp:Button ID="ConfirmarNuevoPasswdButton" runat="server" CssClass="boton2-autoancho" Text="Confirmar contraseña"/> <asp:Button ID="CancelarCambiarPasswdButton" runat="server" CssClass="boton2-autoancho" Text="Cancelar"/> </div> </ContentTemplate> <Triggers> <asp:AsyncPostBackTrigger ControlID="CambiarPasswdButton" EventName="Click" /> <asp:AsyncPostBackTrigger ControlID="CancelarCambiarPasswdButton" EventName="Click" /> </Triggers> </asp:UpdatePanel> <div class="centrar"> <asp:UpdatePanel ID="BotonesUpdatePanel" runat="server" UpdateMode="Conditional" RenderMode="Inline"> <ContentTemplate> <asp:Button ID="ModificarButton" runat="server" CssClass="boton2autoancho" Text="Modificar"/> <asp:Button ID="CambiarPasswdButton" runat="server" CssClass="boton2-autoancho" Text="Cambiar contraseña"/> <asp:Button ID="GuardarButton" runat="server" CssClass="boton2autoancho" Text="Guardar" /> <asp:Button ID="CancelarButton" runat="server" CssClass="boton2autoancho" Text="Cancelar" /> </ContentTemplate> <Triggers> <asp:AsyncPostBackTrigger ControlID="CambiarPasswdButton" EventName="Click" /> <asp:AsyncPostBackTrigger ControlID="CancelarCambiarPasswdButton" EventName="Click" /> </Triggers> </asp:UpdatePanel> </div> </asp:Content> 80 Public Shared Function get_camarero(ByVal tmp_camarero_clave As camarero_clave, ByVal cadena_conexion As String) As camarero_reg Dim conexion As New MySqlClient.MySqlConnection(cadena_conexion) Dim comando As MySqlClient.MySqlCommand Dim lector As MySqlClient.MySqlDataReader = Nothing Dim strSQL As String Dim tmp_camarero_reg As New camarero_reg Try strSQL = " SELECT * FROM camarero WHERE id = " & tmp_camarero_clave.id & " " 'Abro la conexion conexion.Open() comando = New MySqlClient.MySqlCommand(strSQL, conexion) 'Ejecuto la consulta y la guardo lector = comando.ExecuteReader() 'Leo el registro Try With lector If .Read() Then If Not (lector Is Nothing) Then tmp_camarero_reg.id = lector("id") tmp_camarero_reg.nombre = lector("nombre") tmp_camarero_reg.apellido1 = lector("apellido1") tmp_camarero_reg.apellido2 = lector("apellido2") tmp_camarero_reg.foto = lector("foto") Else tmp_camarero_reg = error_camarero() End If Else tmp_camarero_reg = error_camarero() End If End With Catch ex As Exception tmp_camarero_reg = error_camarero() End Try 'Cierro la conexion conexion.Close() Catch e As Exception tmp_camarero_reg = error_camarero() End Try Return tmp_camarero_reg End Function 81 Ahora si por ejemplo queremos acceder a la tabla camarero en el código de la página de la aplicación web importaremos el archivo correspondiente a esa tabla, en este caso camarero_bd, de la siguiente manera: Y llamaremos al método que nos convenga, por ejemplo, si queremos recuperar un camarero escribiremos: El nombre de la DLL es “accesoBDeRestaurante.dll” y se encuentra en la carpeta “bin” del proyecto Web. Imports accesoBDeRestaurante.camarero_bd ' Declaramos el registro de tipo clave y tipo registro Dim tmp_camarero_clave As camarero_clave Dim tmp_camarero_reg As camarero_reg ' Asignamos el identificador de camarero al registro de 'clave tmp_camarero_clave.id = tmp_pedido_reg.FK_camarero ' Obtenemos el camarero tmp_camarero_reg = get_camarero(tmp_camarero_clave, cadena_conexion) 82 83 6. CONCLUSIONES La principal conclusión que obtengo de la realización de este Proyecto Final de Carrera es la importancia de seguir una metodología de desarrollo correcta, siguiendo fases bien definidas (especificación de requisitos, análisis, diseño, implementación y pruebas), las aprendidas a lo largo de la carrera y en las que se ha incidido tanto en respetar, ya no sólo en el orden, sino en la dedicación a cada una de ellas. A lo largo de mi corta experiencia laboral ya he aprendido que la existencia de diagramas es vital para un correcto desarrollo, sobre todo para el mantenimiento de una aplicación de gran envergadura y, su utilización, en general, en el mundo del software, evitaría muchos contratiempos. Por otro lado, analizando el proceso de desarrollo y centrándome en la configuración del servidor web, he de decir que he llegado a la conclusión de que combinar ASP.NET con el servidor web Apache no me parece una buena idea. Decidí llevarlo a cabo como un experimento, ya que, ya había desarrollado varias veces con ASP.NET contra el servidor de Microsoft IIS, y consideré que no estaría de más probar sobre Apache, para saber de primera mano cómo funciona. No obstante, la configuración fue complicada y, a medida que fui avanzando en la implementación me encontré con que algunos controles no funcionaban correctamente debido a este hecho y había que de alguna manera “arreglarlos”. Conclusión: bajo mi experiencia de este proyecto no es nada recomendable. Siguiendo con las tecnologías utilizadas, he de decir que nunca había utilizado AJAX, no tenía ningún conocimiento, y, para realizar este PFC he tenido que aprenderlo. La verdad es que la diferencia entre el sitio web sin y con AJAX es muy grande, los tiempos de respuesta son mucho mejores con AJAX y la aplicación se vuelve mucho más ágil y usable. En cuanto a posibles ampliaciones destacaría ampliar la funcionalidad del cliente web, permitiendo que pueda realizar pedidos con servicio a domicilio. Para finalizar, he de decir que estoy satisfecha con la realización de un sitio web de estas características, ya que este tipo de sitios están cada vez más extendidos, así que tener experiencia en este campo creo que es altamente positivo. 84 85 7. BIBLIOGRAFÍA  Web oficial de Microsoft: MSDN para ASP.NET. http://msdn.microsoft.com/es-es/asp.net/default.aspx  Blog de ASP.NET, VB.NET y desarrollo web en general http://www.blog-de.net/  Guías sobre CSS de la web del consorcio W3C. http://www.w3c.es/Divulgacion/GuiasReferencia/CSS21/  Web oficial Mercury Mail. http://www.pmail.com/  Artículo sobre instalación de ssl en Apache. http://www.symantec.com/connect/es/articles/apache-2-ssltls-step-step-part-2  Artículo sobre la seguridad en Apache. http://www.tufuncion.com/configuracion_apache  Wikipedia. http://www.wikipedia.org/  Apuntes de asignaturas de las carreras Ingeniería Técnica en Informática e Ingeniería Informática.  Creación de Documentos en Hipertexto.  Ingeniería del Software de Sistemas.  Bases de Datos Relacionales.  Diseño de Bases de Datos.  Desarrollo de Aplicaciones para Entornos Web.  Ingeniería de Requerimientos.  Ingeniería de la Programación.  Servidores Web.  Otros proyectos finales de carrera.  Sistema para la gestión web del catálogo de productos de una empresa  Aplicación de comercio electrónico - Desoras  Desarrollo de un sitio web para un camping  Gestor de referencias bibliográficas 86 87 8. ANEXOS 8.1 ANEXO A: TABLAS DE LA BASE DE DATOS Importante: las claves principales aparecen en negrita. Tabla usuario Nombre Tipo Descripción id int (11) Identificador de la tabla. clave char(9) Clave de acceso a la aplicación. passwd char(20) Password de acceso asociado a la clave. Tipo char(1) Tipo de usuario:  “G”. Gerente  “C”. Cliente  “E”. Camarero Tabla cliente Nombre Tipo Descripción id int (11) Identificador de la tabla. nombre char(50) Nombre del cliente. telefono char(9) Teléfono de contacto del cliente. apellido1 char(50) Primer apellido del cliente. apellido2 char(50) Segundo apellido del cliente. email char(30) Dirección de correo del cliente. FK_usuario int(11) Clave ajena al atributo id de la tabla usuario. Tabla pedido Nombre Tipo Descripción id int (11) Identificador de la tabla. fecha datetime Fecha de realización del pedido. precio decimal(10,2) Precio total del pedido. pagado tinyint(4) Indica si el pedido ha sido pagado por el cliente.  0: Pedido sin pagar.  1: Pedido pagado. confirmado tinyint(4) Indica si el pedido ha sido confirmado por el cliente y ya pueden comenzar a servirle:  0: Pedido sin confirmar.  1: Pedido confirmado. 88 servido tinyint(4) Indica si todos las consumiciones del pedido han sido ya servidas:  0: Quedan consumiciones por servir.  1: Todo el pedido está servido. activo tinyint(4) Indica si el pedido está todavía abierto, aún no ha pasado al histórico:  0: Pedido inactivo.  1: Pedido activo. FK_Cliente int(11) Clave ajena a la tabla cliente. FK_Mesa int(11) Clave ajena a la tabla mesa. FK_Camarero int(11) Clave ajena a la tabla camarero. Tabla mesa Nombre Tipo Descripción id int (11) Identificador de la tabla. numero int (11) Número de la mesa. libre tinyint(4) Indica si la mesa está libre en el momento actual:  0: Mesa libre.  1: Mesa ocupada. max_personas int(11) Máximo número de personas recomendado para la mesa. comensales int(11) Número de comensales que hay en el momento actual en la mesa. num_mesas int(11) Número de mesas que componen la mesa, identificadas por el mismo número. Tabla camarero Nombre Tipo Descripción id int (11) Identificador de la tabla. nombre char(50) Nombre del camarero. apellido1 char(50) Primer apellido del camarero. apellido2 char(50) Segundo apellido del camarero. foto char(100) Fotografía en la que aparece el camarero. Tabla reserva Nombre Tipo Descripción id int (11) Identificador de la tabla. fecha datetime Fecha de realización de la reserva. finalizada tinyint(4) Indica si la reserva ya ha sido efectuada y finalizada: 89  0: Reserva por finalizar.  1: Reserva finalizada. FK_Cliente int(11) Clave ajena a la tabla cliente. FK_Mesa int(11) Clave ajena a la tabla mesa. Tabla comentario Nombre Tipo Descripción id int (11) Identificador de la tabla. desde char(50) Dirección de correo desde la cual se recibe el comentario. asunto char(80) Explicación breve del comentario. comentario char(255) Comentario del usuario. fecha datetime Fecha de envío del comentario. Tabla consumicion Nombre Tipo Descripción id int (11) Identificador de la tabla. cantidad int(11) Cantidad de ítems de consumición que forman la consumición. precio decimal(10,2) Precio total de la consumición (cantidad * precio del itemconsumicion). servida int(11) Indica la cantidad de consumiciones servidas. FK_Pedido int(11) Clave ajena a la tabla pedido. FK_Itemconsumicion int(11) Clave ajena a la tabla itemconsumicion. Tabla itemconsumicion Nombre Tipo Descripción id int (11) Identificador de la tabla. tipo char(1) Tipo del ítem de consumición:  P: Producto  M: Menú nombre char(50) Nombre del ítem de consumición. descripcion char(255) Descripción del ítem de consumición. precio decimal(10,2) Precio del ítem de consumición. Tabla menu Nombre Tipo Descripción id int (11) Identificador de la tabla. FK_ItemConsumicion int (11) Clave ajena a la tabla itemconsumicion. 96 Los ficheros generados los situamos en las carpetas del servidor apache conf/ssl.key y conf/ssl.crt. Instalación del certificado El siguiente paso es instalar el certificado en cada navegador donde vayamos a utilizarlo. En nuestro caso: Mozilla e Internet Explorer.  Instalación en Mozilla 1. Abrimos el navegador Mozilla, vamos a Opciones y seleccionamos Ver certificados. Figura 8.3.1 Certificado Mozilla paso 1 97 2. Vamos a la pestaña Autoridades y seleccionamos Importar. Figura 8.3.2 Certificado Mozilla paso 2 3. Seleccionamos en el sistema de ficheros el certificado creado anteriormente. Figura 8.3.3 Certificado Mozilla paso 3 98 4. Seleccionamos confiar en la Autoridad Certificadora (CA) para identificar sitios web. Figura 8.3.4 Certificado Mozilla paso 4 5. Ya tenemos instalado el certificado en el navegador Mozilla Firefox. Figura 8.3.5 Certificado Mozilla paso 5  Instalación en Internet Explorer 1. Vamos al certificado, hacemos doble clic sobre él y seleccionamos Instalar certificado. 99 Figura 8.3.6 Certificado IE paso 1 2. Se abre el asistente para importación de certificados. Siguiente. Figura 8.3.7 Certificado IE paso 2 100 3. Elegimos colocar el certificado en el almacén de certificados Entidades de certificación raíz de confianza. Figura 8.3.8 Certificado IE paso 3 4. Pulsamos en finalizar para instalar el certificado y aceptamos el aviso. 101 Figura 8.3.9 Certificado IE paso 4 5. El certificado ya está importado e instalado. Figura 8.3.10 Importación correcta Si ahora accedemos a cualquiera de las páginas de la aplicación web que utilizan HTTPS accederemos de manera segura. Por ejemplo, la página de autenticación de usuario: 102 Figura 8.3.11 Página autenticación con HTTPS. Si hacemos doble clic en el candado accederemos a la información de seguridad y podemos ver que el certificado creado está instalado, y se nos permite verlo. 103 Figura 8.3.12 Certificado en nuestra aplicación 104 105 8.4 ANEXO D: MANUAL DEL USUARIO GERENTE Una vez autenticado en la aplicación, tiene acceso desde el menú situado a la izquierda, en la parte inferior, a la gestión de: tipos de producto, productos, menús y empleados.  TIPOS DE PRODUCTO Muestra un listado con todos los tipos de producto disponibles. Figura 8.4.1 Tipos de producto Acciones posibles: o Nuevo. Creación de un nuevo tipo de producto. Se debe proporcionar el nombre. Figura 8.4.2 Nuevo tipo de producto 112 Si no seleccionamos ninguna mesa solamente veremos el botón Nueva. Por el contrario, si seleccionamos cualquier mesa se mostrarán todos los botones que aparecen en la Figura 8.5.1 y que se describen a continuación. o Nueva mesa. Creación de una nueva mesa en el restaurante. Se debe introducir: número de mesa, número de mesas que forman la mesa y máximo número de comensales. Figura 8.5.2 Nueva mesa o Modificar. Se abre una ventana con los datos de la mesa y se pueden modificar. Figura 8.5.3 Modificar mesa o Eliminar. Se elimina una mesa seleccionada siempre que no tenga pedidos asignados. o Detalles. Se muestran los datos de la mesa seleccionada y del pedido si tuviera uno asignado y activo, y permite gestionarlo. 113 Figura 8.5.4 Detalles mesa/pedido Desde esta pantalla podemos:  Liberar mesa. Marcamos la mesa como libre.  Marcar pagado. El pedido se da por pagado.  Consumiciones. Accedemos a la pantalla de consumiciones del pedido. Figura 8.5.5 Gestión de consumiciones Añadir un ítem de consumición más al pedido Eliminar un ítem de consumición menos del pedido Marca como servido un ítem de consumición. Resta un ítem de consumición a los ítems servidos. Elimina una consumición. Añadir productos. Se abre una ventana para añadir más productos a la lista.  Cancelar pedido. El pedido pasa a estado inactivo. o Asignar a cliente. Se asigna una mesa a un cliente y a un camarero. Esta acción hay que realizarla a la llegada del cliente al restaurante. Al realizar la 114 asignación se le creará un pedido activo y vacío al cliente, de manera que cuando llegue a su mesa ya podrá empezar a pedir. Figura 8.5.6 Asignar mesa a cliente Al escribir el nombre del cliente se desplegará un listado para seleccionar uno de ellos. Lo mismo sucede con el camarero.  Registro rápido. Si el cliente no está registrado en el sistema, porque es la primera vez que visita el restaurante haremos un registro rápido haciendo clic en este enlace.  PEDIDOS Muestra un listado con los pedidos activos del restaurante. Figura 8.5.7 Pedidos 115 Acciones posibles: o Detalles de pedido. Muestra información del pedido seleccionado y de su mesa asignada (Figura 8.5.4). Ver las acciones posibles en Estado Mesas).  CLIENTES Muestra un listado con los clientes registrados en el restaurante. Figura 8.5.8 Clientes Acciones posibles: o Detalles de cliente. Muestra información del cliente seleccionado y permite modificar sus datos y su contraseña. Figura 8.5.9 Detalles de cliente 116 Desde esta pantalla podemos:  Modificar. Aparece el mismo formulario de la figura pero con los campos habilitados y la opción de guardarlos.  Cambiar contraseña. Aparece un formulario para realizar el cambio de contraseña. Se solicita introducir la antigua y la nueva.  COMENTARIOS Muestra un listado con todos los comentarios recibidos en el restaurante. Figura 8.5.10 Comentarios Acciones posibles: o Ver comentario. Accedemos al comentario. Hay que pulsar en el asunto del comentario que se quiera consultar. 117 Figura 8.5.11 Detalles de comentario Desde esta pantalla podemos:  Responder. Se carga la pantalla para introducir la respuesta que queremos dar al cliente y poder enviarla. Figura 8.5.12 Responder comentario o Eliminar. Este botón está pensado para eliminar varios comentarios seleccionándolos previamente en el listado. o Elimina un comentario. 118  HISTORIAL PEDIDOS Se visualizan los pedidos que ya no están activos (ya han sido pagados) filtrados por fecha, y se permite consultar sus detalles. Figura 8.5.13 Historial de pedidos Acciones posibles: o Buscar pedidos. Seleccionamos fecha de inicio y de fin haciendo clic en los campos de texto Fecha Inicio y Fecha Fin, y pulsamos el botón Buscar. o Detalles de pedido. Seleccionamos un pedido de la tabla de pedidos y pulsamos en el botón Detalles de Pedido para acceder a los datos del mismo. Figura 8.5.14 Detalles de pedido 119 8.6 ANEXO F: MANUAL DEL USUARIO CLIENTE Una vez autenticado en la aplicación, tiene acceso desde el menú situado a la izquierda, en la parte inferior, a: su pedido actual, su historial de pedidos y sus datos personales.  MI PEDIDO Es la pantalla principal del cliente. Le permite ver su pedido en todo momento y, por supuesto, modificarlo, añadiendo o quitando productos, confirmándolo, etc. Figura 8.6.1 Mi Pedido Acciones posibles: o Añadir productos. Se abre una ventana para añadir más productos a la lista. Figura 8.6.2 Añadir productos En esta pantalla podemos filtrar por tipo de producto, utilizando los botones superiores. Se añaden productos al pedido marcándolos en la tabla y pulsando el botón Añadir al pedido. o Detalles de pedido. Se accede a información detallada del pedido actual, en modo lectura: fecha, mesa, camarero, consumiciones y precio. 120 Figura 8.6.3 Detalles de pedido o Confirmar pedido. Confirma el pedido, ya no se podrá modificar. Se le notificará automáticamente a los camareros, apareciendo como confirmado, para que pongan en marcha el pedido. o Pagar. Se podrá pagar una vez el pedido se confirme. Si se pulsa en pagar se solicita si se desea realizar el pago en efectivo o con tarjeta. En caso de seleccionar en efectivo se informará al camarero automáticamente de que lleve la cuenta a esa mesa. Si se selecciona con tarjeta se solicitarán los siguientes datos: nombre del titular, número de tarjeta y fecha de caducidad. o Eliminar todos. Se eliminan todas las consumiciones. Se añade un ítem de consumición más del producto o menú. Se resta un ítem de consumición del producto o menú. Se eliminan todos los ítems de consumición del producto o menú.  HISTORIAL DE PEDIDOS Muestra un listado con los pedidos anteriores del cliente. Figura 8.6.4 Historial de pedidos 121 Acciones posibles: o Detalles de pedido. Se accede a información detallada del pedido seleccionado, en modo lectura: fecha, mesa, camarero, consumiciones y precio (Figura 8.6.3).  MIS DATOS PERSONALES. Muestra los datos personales del cliente: nombre, apellidos, DNI, teléfono y dirección de correo, y permite modificarlos. Permite cambiar la contraseña. Figura 8.6.5 Mis datos personales Acciones posibles: o Modificar. Modificación de los datos mostrados en la figura 8.6.5. o Cambiar contraseña. Se accede a una pantalla de cambio de contraseña. Hay que introducir la contraseña antigua y la nueva. Figura 8.6.6 Cambiar contraseña