EasyOrder. Parte II

0 EasyOrder: Desarrollo de una aplicación para dispositivos móviles orientada a la gestión y administración de los servicios de una empresa de restauración. Parte II Aythami Jesús Mendoza García Proyecto de Fin de Carrera Diciembre 2013 Escuela de Ingeniería Informática Universidad de Las Palmas de Gran Canaria 2 Proyecto de fin de carrera de la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria presentado por: Aythami Jesús Mendoza García Título del proyecto: EasyOrder: Desarrollo de una aplicación para dispositivos móviles orientada a la gestión y administración de los servicios de una empresa de restauración. Parte II Tutores: Alexis Quesada Arencibia Agustín Sánchez Medina 4 Dedicatoria A todas las personas que han hecho posible que mis sueños se hagan realidad. 6 Agradecimientos A mis padres María Josefa y José Luis, por ser mi guía y referencia en la vida, sin ellos nada podría haber sido posible. A mis hermanos Miriam y Kiko, que han sido un ejemplo en constancia y superación, y un espejo en el que reflejarme. A mis tutores Alexis Quesada y Agustín Sánchez, por depositar toda su confianza y ayudarme en todo momento. A mi compañero de proyecto y amigo Eugenio Mendoza, que siempre ha estado ayudándome durante toda mi carrera desde los inicios hasta la realización de este proyecto. Sin él, todo hubiera sido más difícil. A mis amigos y mi pareja, en los que destaco a Alejando, a mi prima Mary Paz y a Magdalena, que sin duda han sido una pieza fundamental en mi crecimiento como persona, y un apoyo en los momentos de debilidad. A José Manuel Izquierdo, del que he aprendido muchas cosas de la vida, y del que espero seguir aprendiendo. A todas las personas que integran el IUCTC por acogerme con cariño y darme todas las herramientas necesarias para poder llevar a cabo este proyecto. Por último me gustaría agradecer a todas las personas que algún momento han pasado por mi vida, por muy pequeña que fuera nuestra relación, ha servido para ser como soy. Mi más sentido agradecimiento, Aythami Mendoza 8 Índice 1!Introducción .............................................................................................................. 1! 2!Estructura de la memoria ......................................................................................... 2! 3!Estado del arte ......................................................................................................... 4! 3.1!Plataformas web ................................................................................................ 4! 3.1.1!Just Eat ........................................................................................................ 4! 3.1.2!PizzaPortal.pl ............................................................................................... 5! 3.1.3!La Nevera Roja ............................................................................................ 5! 3.1.4!HungryHouse.co.uk ..................................................................................... 6! 3.2!Aplicaciones para dispositivos móviles ............................................................. 7! 3.2.1!Tocarta ........................................................................................................ 8! 3.2.2!Tabsquare ................................................................................................... 8! 3.2.3!MenuPad ..................................................................................................... 9! 4!Objetivos ................................................................................................................. 12! 5!Planificación temporal ............................................................................................ 14! 5.1!Fase 1: Análisis ................................................................................................ 14! 5.1.1!Actividad 1.1 Documentación y herramientas .......................................... 14! 5.1.2!Actividad 1.2 Estudio de las herramientas para poder abordar el proyecto. 14! 5.1.3!Actividad 1.3 Análisis UML ....................................................................... 14! 5.2!Fase 2: Diseño ................................................................................................. 14! 5.2.1!Actividad 2.1 : Diseño de Estructura web. ................................................ 14! 5.2.2!Actividad 2.2 : Diseño de módulo de bases de datos .............................. 14! 5.2.3!Actividad 2.3 : Diseño de módulos de aplicación .................................... 15! 5.3!Fase 3: Implementación ................................................................................... 15! 5.3.1!Actividad 3.1 : Implementación de módulos de bases de datos ............. 15! 5.3.2!Actividad 3.2 : Implementación de módulos de aplicación ...................... 15! 5.4!Fase 4 : Validación y Publicidad del PFC ........................................................ 15! 5.4.1!Actividad 4.1 : Tests de validación ........................................................... 15! 5.4.2!Actividad 4.2 : Publicidad ......................................................................... 15! 6!Metodología ............................................................................................................ 17! 6.1!Fase de inicio ................................................................................................... 17! 6.2!Fase de elaboración ........................................................................................ 17! 6.3!Fase de construcción ...................................................................................... 17! 6.4!Fase de transición ............................................................................................ 17! 7!Recursos utilizados ................................................................................................ 19! 7.1!Recursos hardware .......................................................................................... 19! 7.1.1!Equipos informáticos ................................................................................. 19! 7.1.2!Dispositivos móviles .................................................................................. 19! 16 Índice de diagramas Diagrama 1 - Estructura del CD ..................................................................................... 3! Diagrama 1Temporización del proyecto .................................................................... 16! Diagrama 2 - Actores del sistema ................................................................................ 26! Diagrama 3 - Casos de uso de un usuario no registrado ............................................ 32! Diagrama 4 - Casos de uso de un cliente I .................................................................. 32! Diagrama 5 - Casos de uso de un cliente II ................................................................. 33! Diagrama 6 - Casos de uso de un cliente III ................................................................ 33! Diagrama 7 - Casos de uso de un administrador de restaurante I .............................. 34! Diagrama 8 - Casos de uso de un administrador de restaurante II ............................. 34! Diagrama 9 - Casos de uso de un administrador de restaurante III ............................ 35! Diagrama 10 - Casos de uso del administrador o trabajador del restaurante I .......... 41! Diagrama 11 - Casos de uso del administrador o trabajador del restaurante II ......... 41! Diagrama 12 - Modelo Vista Controlador ..................................................................... 45! Diagrama 13 - Diseño arquitectónico .......................................................................... 46! Diagrama 14 - Ejemplo de funcionamiento para el registro ........................................ 47! Diagrama 15 - Flujo de una aplicación en CodeIgniter ............................................... 49! Diagrama 16 - Estructura de CodeIgniter .................................................................... 50! Diagrama 17 - Estructura de la carpeta application .................................................... 50! Diagrama 18 - Estructura de la carpeta system .......................................................... 51! Diagrama 19 - Estructura de la aplicación web ........................................................... 52! Diagrama 20 - Estructura de la carpeta media ............................................................ 54! Diagrama 21 - Estructura de la aplicación de camarero ............................................. 55! Diagrama 22Funcionamiento de un pedido .............................................................. 71! 18 Índice de esquemas Esquema 1 - Relaciones entre los actores con registro en la base de datos ............. 56! Esquema 2 – Relación entre los elementos del bloque de contenido en la base de datos ............................................................................................................................. 58! Esquema 3 - Relación entre los elementos del bloque social en la base de datos .... 59! Esquema 4 - Tablas de log .......................................................................................... 60! Esquema 5 – Tablas con los datos sobre un restaurante ............................................ 60! Esquema 6 – Tablas con la información de los pedidos ............................................. 61! Esquema 7 - Tabla de descuentos .............................................................................. 62! Esquema 8 - Enfoque funcional o de caja negra. ........................................................ 84! 0 1 1 Introducción En este proyecto se ha pretendido desarrollar un completo sistema de gestión de restaurantes y fidelización de clientes. Dada la complejidad del sistema y las numerosas funcionalidades que se pretenden abarcar, este proyecto se ha dividido de manera equitativa en dos PFC desarrollados por alumnos de la Escuela de Ingeniería Informática, siendo el autor de esta memoria uno de ellos. Para ello se ha investigado cómo los restaurantes realizan su gestión interna e interactúan con sus clientes para mostrar su oferta gastronómica. Como resultado de esa investigación se propone un sistema de gestión automatizado de las cartas, así como de los pedidos que se realizan tanto en el restaurante cómo fuera de él. Este sistema facilita al gestor del restaurante la posibilidad de tener de forma organizada sus cartas y menús, así como de conocer de forma directa la opinión de sus clientes. La aplicación ha sido diseñada de forma que se facilite el acceso a todos los trabajadores de los restaurantes y se pueda restringir su acceso mediante asignación de roles. Además, se facilita a los restaurantes un sistema completo de estadísticas para ver, de forma gráfica, la evolución tanto en ventas como en opiniones y valoraciones de sus clientes. Los clientes tienen la posibilidad de realizar pedidos desde la plataforma y desde el propio restaurante en una carta digitalizada, así como de conocer y descubrir todos los restaurantes registrados con las valoraciones y comentarios de otros usuarios. Todas estas funcionalidades son posibles gracias a la integración de un portal web y de dos aplicaciones diseñadas para dispositivos móviles (adaptadas a los tamaños de pantalla y resolución más usados actualmente) que se comunican e interactúan de forma directa. 2 2 Estructura de la memoria EasyOrder se desarrolló en dos fases diferentes. En primer lugar, se inició una etapa de desarrollo del portal web, que sería la herramienta fundamental donde están todas las funcionalidades del proyecto. Debido a su extensión y sus múltiples funciones, se dividió en varios módulos y se distribuyó de forma equitativa para realizar el proyecto en forma conjunta, minimizando las dificultades de organización en un desarrollo conjunto. En el documento que leerán a continuación, se reflejan datos e información necesaria para entender el porqué y el cómo de este proyecto. La documentación comienza con una breve descripción del estado del arte tanto de portales web, como de aplicaciones utilizadas en restauración. Con ello se pretende dar a conocer al lector la situación actual. A continuación, se han especificado los objetivos que nos marcamos al inicio del proyecto y una planificación temporal para que, una vez finalizada la lectura, se puedan evaluar mejor los resultados obtenidos. La memoria continúa detallando la metodología de desarrollo utilizada en el transcurso del proyecto así como todas las herramientas hardware y software necesarias para desarrollarlo. Tras esto, se procede a analizar tanto la plataforma web como la aplicación de camarero haciendo especial hincapié sobre los actores y los casos de uso. Para poder llevar a cabo este proyecto, en el apartado de diseño se especifica el diseño arquitectónico de la solución así como el diseño definitivo de las interfaces de usuario. En la parte de desarrollo se específica la parte más reseñable del código implementado y las librerías de terceros utilizadas para la implementación. Por último, y tras una breve reseña sobre la difusión en medios de comunicación, se relatan los resultados y conclusiones que se obtuvieron tras el desarrollo de este proyecto de fin de carrera, así como nuevas líneas de trabajo futuro que ampliarían las capacidades y funcionalidades de este proyecto. Como complemento, se han añadido diferentes Anexos al final de este documento que completan la información de las secciones anteriores y que facilitarán al lector la comprensión y lectura de esta memoria. Junto al documento se adjunta un CD con el código fuente desarrollado, la base de datos, videos sobre el uso del portal web y la aplicación de comanda y una copia de esta memoria en PDF. El CD está organizado de la siguiente manera: 3 Diagrama 1 - Estructura del CD 4 3 Estado del arte En este apartado se presenta un estudio de las diferentes plataformas y aplicaciones que dispone un restaurante para ofrecer su carta digitalizada y online a los clientes. 3.1 Plataformas web A continuación veremos diferentes plataformas web que existen en la actualidad. 3.1.1 Just Eat Es la plataforma líder mundial de pedidos de comida a domicilio a través de internet. Actualmente tiene presencia en 13 países y cuenta con una cartera de más de 28.000 restaurantes. El portal ofrece a los restaurantes registrarse para tener presencia online. Así mismo el restaurante puede rellenar una breve ficha de información general para los clientes (horarios, dirección, nombre, logo…) y también toda la información sobre su carta. La información de cada plato es básica: nombre, descripción y precio. Es bastante simple y funcional, permite crear descuentos pero no da la oportunidad de ver fotos de los platos, opiniones y valoraciones de otros clientes de los platos, pero sí del restaurante en general. Por otra parte una característica buena que tiene, es que se puede seleccionar el día y la hora de entrega del pedido. Obliga a los futuros clientes a registrarse en la plataforma para poder hacer un pedido y solo permite el pago electrónico. Por último destacar que dispone de una aplicación móvil igual de sencilla que la web para poder pedir en cualquier instante desde cualquier sitio. Ilustración 1 - Plataforma web y app móvil de Just Eat 11 12 4 Objetivos El software que se utiliza hoy en día en el mundo de la hostelería, generalmente es software POS (Point of Sale), es decir, es el software del punto de venta, que utilizan los empleados de un restaurante para tomar pedidos, hacer reservas, imprimir facturas, etc. Por otra parte, algunos restaurantes suelen combinar este tipo de software con una PDA, para facilitar el trabajo a sus empleados cuando se disponen a solicitar pedidos de los clientes. Sin embargo, son pocos los restaurantes que utilizan un software específico para que sus clientes lo utilicen, como por ejemplo, digitalizar y hacer interactiva su carta, para que puedan ver fotos de los platos, su receta, videos para saber cómo se ha elaborado, dar su opinión, valorar los platos, comentar como ha sido su visita, compartir su experiencia a través de las redes sociales, etc. La aplicación completa que se pretende desarrollar se ha dividido en dos proyectos: la plataforma web y las aplicaciones para dispositivos móviles. Seguidamente se describirá la totalidad de la aplicación y la parte que pretende desarrollar este proyecto. La plataforma web está orientada tanto a los restaurantes como a sus clientes, por lo tanto tiene dos interfaces con sus respectivos módulos. La interfaz para los restaurantes está compuesta de los siguientes módulos: 1. Módulo de administración a. Inicio – pantalla inicial que verá el administrador al iniciar sesión con una vista rápida de los pedidos del restaurante. b. Pedidos – gestor de pedidos, en el cual podrá crear, modificar y eliminar cualquier pedido, así como emitir facturas. c. Clientes – gestor de clientes, en el cual podrá ver toda la información de un cliente, como por ejemplo cosas que le gustan o los últimos pedidos en el restaurante. d. Descuentos – gestor de descuentos, en el cual se podrá crear, modificar y eliminar cualquier descuento. 2. Módulo de informes a. Estadísticas – se podrá visualizar estadísticas sociales y de los pedidos mediante gráficas, comprendido en un rango de tiempo. b. Social – gestor de comentarios, valoraciones, likes y valoraciones generales. c. Log – visor del historial sobre cualquier acción/cambio que se realice. 3. Módulo de contenido a. Ítems – gestor de ítems, en el cual se podrá crear, modificar y eliminar cualquier ítem. b. Categorías – gestor de categorías, en el cual se podrá crear, modificar y eliminar cualquier categoría. c. Cartas – gestor de cartas, en el cual se podrá crear, modificar y eliminar cualquier carta. d. Menús – gestor de menús, en el cual se podrá crear, modificar y eliminar cualquier menú. 13 4. Módulo de configuración a. Perfil – configuración del perfil del restaurante: cover, widgets, redes sociales… b. Información – configuración de los datos del restaurante: nombre, dirección, horarios, logo… c. Usuarios – gestor de usuarios y roles, en el cual se podrá crear, modificar y eliminar cualquier usuario y/o rol. d. Pagos – configuración de los datos del pago electrónico mediante Paypal. e. Acceso – permite cambiar la contraseña de acceso del restaurante. La interfaz para los clientes está compuesta por el siguiente módulo: 1. Módulo de perfil a. Inicio – pantalla inicial que verá el cliente al iniciar sesión con una vista rápida sobre sus últimos pedidos y nuevos restaurantes disponibles. b. Pedidos – podrá visualizar los pedidos que ha realizado así como pagar en el caso que esté disponible o incluso imprimir una factura. c. Restaurantes – podrá ver todos los restaurantes en los cuales sea cliente. d. Social – gestor de comentarios, valoraciones, likes y valoraciones generales. e. Mis datos – configuración de los datos del cliente: nombre, dirección, foto… Por último las aplicaciones para dispositivos móviles serán dos, la primera para agilizar la gestión de comandas al camarero, y la segunda, destinada a los clientes del restaurante, dónde se mostrará la carta de una forma más atractiva y visual. En este proyecto se propone el desarrollo de los siguientes módulos: • En la interfaz para el restaurante el módulo de administración al completo, en el módulo de informes, el apartado de log y en el módulo de configuración los apartados de usuarios, pagos y acceso. • En la interfaz de los clientes, los apartados de pedidos, restaurantes y mis datos. • La aplicación para dispositivos móviles destinada a la gestión de comandas de camareros. 14 5 Planificación temporal 5.1 Fase 1: Análisis 5.1.1 Actividad 1.1 Documentación y herramientas • Realización encuestas y entrevistas • Estudio herramientas necesarias para el PFC • Búsqueda en internet de información herramientas • Generación de documentación sobre herramientas 5.1.2 Actividad 1.2 Estudio de las herramientas para poder abordar el proyecto. • Lectura y documentación. • Pruebas y ejemplos. • Generación documentación. 5.1.3 Actividad 1.3 Análisis UML • Lectura y documentación. • Análisis de funciones, métodos, actores, etc. • Generación documentación análisis UML. 5.2 Fase 2: Diseño 5.2.1 Actividad 2.1 : Diseño de Estructura web. • Lectura y documentación. • Diseño de interfaz. • Diseño de la funciones y métodos UML. • Generación de documentación. 5.2.2 Actividad 2.2 : Diseño de módulo de bases de datos • Lectura y documentación. • Diseño de módulo de interconexión con base de datos. • Pruebas de las bases de datos. • Generación documentación de módulo de base de datos. 15 5.2.3 Actividad 2.3 : Diseño de módulos de aplicación • Lectura y documentación. • Diseño del módulo de administración. • Diseño del sub-módulo log. • Diseño de los sub-módulos usuarios, pagos y acceso. • Diseño de los sub-módulos pedidos, restaurantes y mis datos de los clientes. • Diseño la aplicación para el camarero. • Diseño de las interfaces de los diferentes módulos y sub-módulos. • Generación documentación de los módulos y sub-módulos. 5.3 Fase 3: Implementación 5.3.1 Actividad 3.1 : Implementación de módulos de bases de datos • Implementación de base de datos. • Implementación del módulo de interconexión con base de datos. • Generación documentación de Implementación de base de datos. 5.3.2 Actividad 3.2 : Implementación de módulos de aplicación • Implementación del módulo de administración. • Implementación del sub-módulo log. • Implementación de los sub-módulos usuarios, pagos y acceso. • Implementación de los sub-módulos pedidos, restaurantes y mis datos de los clientes. • Implementación la aplicación para el camarero. • Implementación de las interfaces de los diferentes módulos y submódulos. 5.4 Fase 4 : Validación y Publicidad del PFC 5.4.1 Actividad 4.1 : Tests de validación • Definición de los test de validación • Aplicación de los test de validación • Análisis de resultados de los test de validación • Generación documentación test de validación 5.4.2 Actividad 4.2 : Publicidad • Confección de manuales de usuario 16 • Realización página web publicidad PFC TEMPORIZACION Fases/Actividades Meses Horas 1 2 3 4 5 6 Fase 1: Análisis Actividad 1.1 Documentación y herramientas 55 Actividad 1.2 Estudio herramientas necesarias 76 Actividad 1.3 Análisis de requisitos de soft. 101 Fase 2: Diseño Actividad 2.1: Diseño estructura Web. 125 Actividad 2.2 : Módulos de bases de datos 76 Actividad 2.3 : Módulos de aplicación 97 Fase 3: Implementación Actividad 3.1 : Módulos de bases de datos 52 Actividad 3.2 : Módulos de aplicación 340 Fase 4 : Validación y Publicidad del PFC Actividad 4.1 : Tests de validación 43 Actividad 4.2 : Publicidad 30 TOTAL HORAS 995 Diagrama 2Temporización del proyecto 17 6 Metodología La metodología utilizada en el desarrollo del software de este proyecto es el proceso unificado de desarrollo de software. En primer lugar, el proceso unificado es un proceso de desarrollo software, es decir, es un conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. Sin embargo, es más que un simple proceso; es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto. Este marco de trabajo es iterativo e incremental, y está compuesto de cuatro fases generales denominadas: inicio, elaboración, construcción y transición. 6.1 Fase de inicio Suele ser la fase más corta del desarrollo, y no debería alargarse demasiado en el tiempo. En ella se realizarán las siguientes tareas: • Desarrollar una descripción del producto final y presentar el análisis de negocio. • Realizar una identificación inicial de riesgos. • Establecer las principales funciones del sistema para los usuarios más importantes, la arquitectura a grandes rasgos y un plan de proyecto. • Establecer los hitos de la iteración actual que se pretende abordar. La fase de inicio termina con el hito de los objetivos del desarrollo. 6.2 Fase de elaboración Se capturan la mayoría de los requisitos del sistema, aunque los objetivos principales son tratar los riesgos ya identificados y, establecer y validar la base de la arquitectura del sistema. La fase de elaboración finaliza al alcanzar el hito de la arquitectura del sistema. 6.3 Fase de construcción Completa la implementación del sistema tomando como base la arquitectura obtenida durante la fase anterior. A partir de esta, las distintas funcionalidades son incluidas en distintas iteraciones, las cuales al finalizarlas, se obtendrán nuevas versiones ejecutables del producto. La fase de construcción finaliza con el hito de obtención de una funcionalidad completa que capacite al producto para funcionar en un entorno de producción. 6.4 Fase de transición Se lleva a cabo el despliegue del producto en el entorno de los usuarios, lo que incluye la formación de estos. En lo relativo a la evolución del propio producto: 18 El producto evoluciona en cada iteración gracias a lo aprendido en versiones anteriores del producto en iteraciones anteriores. Se resuelven incidencias en la implantación e integración, y si existen, se clasifican aquellas que podrían justificar una nueva versión del producto. La fase de transición concluye con el hito de la publicación del producto. El proceso unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software interconectados a través de interfaces bien definidas. El proceso unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) para preparar todos los esquemas de un sistema software. De hecho, UML es una parte esencial del Proceso Unificado – sus desarrollos fueron paralelos. No obstante, los aspectos clave que definen al proceso unificado son los siguientes: • Dirigido por casos de uso, es importante la comunicación con el cliente y los métodos directos para describir su punto de vista respecto de un sistema. • Centrado en la arquitectura, ayuda a que el arquitecto se centre en las metas correctas, como que permita cambios futuros y la reutilización. • Iterativo e incremental, lo que da la sensación evolutiva que resulta esencial en el desarrollo moderno del software. Esto es lo que hace único al proceso unificado. 19 7 Recursos utilizados En este apartado se ven los recursos hardware y software, así cómo, las tecnologías que se han utilizado para realizar el proyecto. 7.1 Recursos hardware Para un buen desarrollo del proyecto, la elección de los recursos hardware es una parte fundamental, tanto para la implementación como para probarlo, aquí veremos nuestra elección. 7.1.1 Equipos informáticos Ha sido necesario utilizar diferentes equipos informáticos que dispongan de las últimas tecnologías que hayan salido al mercado: Procesador: Intel Core i7 a 2,80 Ghz. Memoria RAM: 4 Gb de memoria RAM DDR3. Disco duro: 1 Tb. Conexión a internet: Realtek PCI E Gigabit Ethernet. Tarjeta gráfica: NVIDIA GeForce GT 210. Dos pantallas panorámicas LG de 22’’. Sistema operativo: Windows 7 Professional 64 bits. 7.1.2 Dispositivos móviles Para poder probar y ajustar las interfaces a los distintos dispositivos se ha optado por los dispositivos móviles más usados en la actualidad: Iphone 5 Sistema Operativo: iOS 7. Alimentación: Batería Li-Polymer 1440 mAh. CPU: Apple A6 – doble núcleo a 1.3 GHz. Memoria: 1 GB (LP DDR2 SDRAM). Capacidad de Almacenamiento: Memoria Flash 16 Gigas. Pantalla: LCD IPS con retroiluminación LED, resolución 1136×640 px, de 4 pulgadas. Cámaras: Delantera 1.2 Mpx – Trasera 8 Mpx. Conectividad: Wi-Fi 802.11 a/b/g/n (802.11n), Bluetooth 4.0 A2DP. Dimensiones y peso: 12,38 x 58,6 x 0,76 cm, 112 g. Samsung Galaxy S III Sistema Operativo: Android 4.1.2. Alimentación: Batería Li-Polymer 2100 mAh. CPU: Exynos – cuatro núcleos a 1.4 GHz. Memoria: 1 GB. Capacidad de Almacenamiento: Memoria Flash 16 Gigas. Pantalla: HD SUPER AMOLED con 1280×720 pixels (306 ppi) y RGBG-Matrix (PenTile), de 4,8 pulgadas. Cámaras: Delantera 1.9 Mpx Trasera 8 Mpx. Conectividad: Bluetooth 4.0, Wi-Fi 802.11 a/b/g/n, NFC, micro-USB OTG Dimensiones y peso: 13,66 x 7,06 x 0,86 cm, 133g. Ilustración 9 - iPhone 5 Ilustración 10 - Samsung Galaxy S III 20 Ipad 2 Sistema Operativo: iOS 7 Alimentación: Batería de ion de litio 25 Wh CPU: Apple A5 de 1 GHz dual core Memoria: 512 MB DDR2 (1066 Mbit/s) RAM Capacidad de almacenamiento: Memoria flash16GB Pantalla: LCD IPS con retroiluminación LED, resolución 1024×768 px (XGA), de 9,7 plg. Cámaras: Delantera 0,3 Mpx. Trasera 0,7 Mpx. Conectividad: Wi-Fi (802.11 a/b/g/n), Bluetooth 2.1+EDR, USB 2.0 (requiere accesorio para conector dock) Dimensiones y peso: 24,13 x 18,57 x 0,88 cm, 700 g Eee Pad Slider SL 101 Sistema Operativo: Android 4.0.3 Alimentación: Batería 25Wh Li-Polymer de 8 horas CPU: NVIDIA® Tegra™ 2 Memoria: 1024 MB DDR2 RAM Capacidad de almacenamiento: Memoria flash32GB Pantalla: 10.1" LED retroiluminado WXGA (1280x800), multitáctil y resistente. Cámara: Delantera 1,2 Mpx. Trasera 5 Mpx. Conectividad: Wi-Fi (802.11 a/b/g/n), Bluetooth 2.1+EDR, 1xUSB 2.0, 1xMini HDMI Dimensiones y peso: 273 x 180.3 x 17.3 mm, 960 g Teclado incorporado. 7.2 Recursos software Otra parte importante del proyecto es la elección de los recursos software, influirá bastante sobre el diseño e implementación del mismo. Estos han sido lo que hemos utilizado. 7.2.1 SISTEMA OPERATIVO WINDOWS 7 Windows 7 es una versión de Microsoft Windows, la línea de sistemas operativos producida por Microsoft Corporation. Esta versión está diseñada para uso en PC, incluyendo equipos de escritorio en hogares y oficinas, equipos portátiles, tablet PC, netbooks y equipos media center. Fue concebido como una actualización incremental y focalizada de Vista y su núcleo NT 6.0, lo que permitió mantener cierto grado de compatibilidad con aplicaciones y hardware en los que éste ya era compatible. Incluye varias características nuevas, como mejoras en el reconocimiento de escritura a mano, soporte para discos duros virtuales, rendimiento mejorado en procesadores multinúcleo, mejor rendimiento de arranque, DirectAccess y mejoras en el núcleo. El desarrollo de las aplicaciones del sistema se ha llevado a cabo mayoritariamente en este sistema operativo. 7.2.2 MICROSOFT WORD 2010 Para la realización de la documentación del proyecto se ha optado por el procesador de textos Microsoft Word 2010 en detrimento del procesador de textos Ilustración 11 - Ipad 2 Ilustración 12 - Eee Pad Slider 27 • Ítem: El elemento básico que puede crearse en la aplicación. Puede ser un plato o una bebida. • Menú: Un conjunto de ítems, organizados por secciones, en el que todo el conjunto tiene un precio concreto. • Carta: Un conjunto de ítems, organizados por secciones, en el que cada ítem tiene un precio concreto. • Descuento: Un porcentaje que se le resta al precio de un ítem, menú o pedido. • Pedido: Un conjunto de ítems incluidos en una carta y/o menús, en el que su precio es la suma total de cada uno de sus elementos, al que se le puede aplicar un único descuento. • Rol: Un conjunto privilegios que un usuario puede tener. • Usuario: Definido en los actores como trabajador de restaurante. 8.2.4 Actores/Objetivos La siguiente tabla especifica los objetivos de cada uno de los actores. Es una manera rápida de ver globalmente las funciones de actor en las aplicaciones, y no representan los casos de uso. Como queda reflejado en la tabla, las funciones que desempeña el trabajador de restaurante son las mismas que puede desempeñar el administrador de restaurante dependiendo del tipo de rol que se le asigne. Actor (Rol) Objetivos Breve resumen Usuario no registrado Registrarse Realiza el registro como cliente o administrador de restaurante para posteriormente poder acceder al Sistema Ver perfil público del restaurante Puede ver las diferentes opciones del perfil público de los restaurantes, si éste ha sido activado. Cliente Iniciar sesión Realiza el proceso de login incluyendo sus datos de acceso Ver/editar su perfil Ver y editar su información datos personales, información básica y gustos o preferencias Ver historial de pedidos Ver los detalles de todos pedidos realizados en el sistema Ver sus restaurantes Ver todos los restaurantes de los que es cliente en el sistema Buscar Restaurantes Buscar todos los restaurantes existentes en el sistema Ver/Eliminar historial de valoraciones Ver y eliminar todos los comentarios, likes, valoraciones de ítems y valoraciones generales que haya echo Cerrar sesión Cierra la sesión actual en la aplicación Hacerse cliente del restaurante Hacerse cliente de un restaurante del que en ese momento no es 28 Eliminar su condición de cliente Quitar su condición de cliente de un restaurante del que en ese momento es Hacer Valoraciones Realizar comentarios, likes, valoraciones sobre ítems y/o valorar de forma general los restaurantes de los que sea cliente Hacer Pedidos Podrá realizar un pedido. Pagar Podrá realizar el pago de un pedido. Generar factura Podrá general la factura de un pedido realizado y pagado. Administrador de restaurante Ver/editar/eliminar pedidos Ver, editar y eliminar pedidos realizados por los clientes. Ver clientes Ver lista de clientes del restaurante con una pequeña información básica de los mismos. Añadir información privada de un cliente Añadir información confidencial del restaurante sobre un cliente en particular. Crear/ver/editar/eliminar descuentos Crear, ver, editar y eliminar descuentos Ver estadísticas Ver estadísticas sobre los pedidos y valoraciones de los clientes. Ver/moderar valoraciones Ver y moderar las valoraciones generadas por los clientes. Ver registro de uso Ver un amplio registro de uso del restaurante. Crear/ver/editar/eliminar ítems Crear, ver, editar y eliminar toda la información referente a un ítem Crear/ver/editar/eliminar categorías Crear, ver, editar y eliminar toda la información referente a una categoría Crear/ver/editar/eliminar cartas Crear, ver, editar y eliminar toda la información referente a una carta Crear/ver/editar/eliminar menús Crear, ver, editar y eliminar toda la información referente a un menú Configurar perfil de restaurante Configurar todas las opciones del perfil del restaurante (Visibilidad, cover, slider, redes sociales, etc.) Configurar información del restaurante Configurar toda la información del restaurante (Nombre, descripción, localización, horarios, etc.) Crear/ver/editar/eliminar roles Crear, ver, editar y eliminar un rol Crear/ver/editar/eliminar usuarios Crear, ver, editar y eliminar un usuario y su rol Configurar información de pago Configurar todas las opciones de pago Cambiar contraseña Cambiar contraseña de acceso 29 generar factura Generar en formato pdf una factura de un pedido Iniciar sesión Realiza el proceso de login incluyendo sus datos de acceso Cerrar sesión Cierra la sesión actual en la aplicación Trabajador de restaurante Ver/editar su perfil Ver y editar la información de su perfil Subconjunto de objetivos del administrador de restaurante Dependiendo del rol que tenga este actor, podrá realizar un subconjunto de todos los objetivos de un Administrador de restaurante Tabla 4 - Actores y objetivos 8.2.5 Listado resumen de los casos de uso Actor Caso de uso NCU Usuario no registrado Registro 1 Ver perfil del restaurante 2 Ver pestaña de inicio 3 Ver pestaña de información 4 Ver pestaña de cartas 5 Ver pestaña de menús 6 Ver pestaña de descuentos 7 Ver vista detallada de un ítem 8 Ver vista detallada de un descuento 9 Cliente Iniciar sesión 10 Cerrar sesión 11 Recordar contraseña 12 Ver inicio 13 Ver pedidos 14 Ver vista detallada de un pedido 15 Generar factura de un pedido 16 Ver restaurantes que es cliente 17 Buscar restaurantes 18 Ver valoraciones 19 Ver comentarios 20 Eliminar comentarios 21 Ver Likes 22 30 Eliminar Likes 23 Ver valoraciones de ítems 24 Eliminar valoraciones de ítems 25 Ver valoraciones generales 26 Eliminar valoraciones generales 27 Actualizar datos personales 28 Hacerse cliente de un restaurante 29 Eliminar condición de cliente del restaurante 30 Hacer una valoración general 31 Añadir ítem a un pedido 32 Añadir menú a un pedido 33 Ver pedido 34 Borrar pedido 35 Añadir descuento 36 Confirmar pedido 37 Pagar 38 Seleccionar método de pago 39 Comentar ítem 40 Valorar ítem 41 Hacer like en ítem 42 Administrador de restaurante Cambiar estado del pedido 43 Poner como pagado 44 Eliminar pedido 45 Reembolsar pedido 46 Editar un pedido 47 Añadir notas privadas a un pedido 48 Ver clientes 49 Añadir información privada a un cliente 50 Ver vista detallada de un cliente 51 Ver descuentos 52 Eliminar un descuento 53 Crear descuento 54 Actualizar descuento 55 31 Ver estadísticas de pedidos 56 Ver estadísticas de social 57 Seleccionar rango de fechas para las estadísticas 58 Ocultar comentario 59 Aprobar comentario 60 Ver log 61 Crear ítem 62 Ver ítem 63 Eliminar ítem 64 Actualizar ítem 65 Crear categoría 66 Ver categoría 67 Eliminar categoría 68 Actualizar categoría 69 Crear carta 70 Ver carta 71 Eliminar carta 72 Actualizar carta 73 Crear menú 74 Ver menú 75 Eliminar menú 76 Actualizar menú 77 Actualizar perfil 78 Actualizar información 79 Ver usuarios 80 Crear rol 81 Actualizar rol 82 Eliminar rol 83 Ver roles 84 Crear usuario 85 Eliminar usuario 86 Modificar rol de usuario 87 Eliminar usuario temporal 88 32 Actualizar información de pagos 89 Actualizar acceso 90 Tabla 5 - Listado de los casos de uso 8.2.6 Diagramas de casos de usos Diagrama 4 - Casos de uso de un usuario no registrado Diagrama 5 - Casos de uso de un cliente I 33 Diagrama 6 - Casos de uso de un cliente II Diagrama 7 - Casos de uso de un cliente III 34 Diagrama 8 - Casos de uso de un administrador de restaurante I Diagrama 9 - Casos de uso de un administrador de restaurante II 35 Diagrama 10 - Casos de uso de un administrador de restaurante III 8.2.7 Casos de uso completos Ya se han identificado los actores y definido mediante diagramas los casos de uso. Los diagramas dan una representación rápida del sistema, pero no aportan toda la información sobre el caso de uso. Jacobson [JAC92] sugiere varias preguntas que se deberían contestar mediante un caso de uso. Estas preguntas se han extendido para proporcionar una visión más completa del contenido del caso de uso: • ¿Quién(es) es(son) el(los) actor(es) primario(s)? • ¿Cuáles son las metas del actor? • ¿Cuáles son las condiciones previas que deben existir antes de comenzar la historia? • ¿Cuáles son las tareas o funciones principales que realiza el actor? • ¿Qué excepciones podrían considerarse mientras se describe la historia? • ¿Cuáles son las variaciones posibles en la interacción del actor? • ¿Cuál es la información del sistema que el actor adquirirá, producirá o cambiará? • ¿Cuál es la información que el actor desea del sistema? Para dar respuesta a todas estas cuestiones relativas a los casos de uso, se utilizará una plantilla que se explica en el Anexo 1. Todos los casos de uso están detallados en el Anexo 2. 8.2.8 Prototipos de validación para el portal web La realización de prototipos ayuda a identificar los requisitos y objetivos globales del software. Además, es la primera representación de la interfaz, lo que facilita la tarea de diseño. Por otra parte, ayuda al desarrollador a entender la interacción hombre-máquina, obteniendo así un mejor enfoque. El prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer. Con el fin de validar los actores y casos de uso, se han realizado una serie de prototipos de la aplicación antes de continuar con la siguiente fase del proyecto. El proyecto ha pasado por una evolución y se ha ido ajustando a las necesidades reales, diferenciando las siguientes fases de prototipos para el panel de administración: 36 • Fase inicial • Adaptación de la fase inicial • Reestructuración • Fase final del diseño (explicada de manera detallada en el apartado de diseño). En este primer ejemplo vemos la evolución del prototipo para los detalles de un ítem. En la primera fase, la interfaz era muy primitiva, organizada por bloques. Ilustración 13 - Prototipo inicial de detalles de un ítem En la segunda fase, se hizo una adaptación funcional a un entorno web. Se suprimió la colocación por bloques, adaptando la interfaz a una visión más moderna. Ilustración 14 - Adaptación de la fase inicial Tras realizar pruebas de funcionalidad a esta adaptación, se decidió hacer un cambio radical en la estructura, debido a la complejidad de uso de esta interfaz. En este caso existía una pantalla de ver ítem de forma individual, y una editar, paso que se consideró innecesario puesto que se necesitaba demasiado tiempo para poder utilizar la plataforma. Uno de los factores esenciales para este tipo de proyectos es la facilidad de uso, por tanto, se rediseñó toda la interfaz utilizando software específico para ello. En la siguiente imagen podemos ver el cambio en la interfaz. 43 Ilustración 18 – Prototipo de vista principal de la aplicación La estructura de la información y el diseño se ha centrado en cómo un camarero toma las comandas en la actualidad, para ayudarle a agilizar el proceso y que la curva de aprendizaje no sea excesiva. 44 10 Diseño 10.1 Introducción El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño del software que se utilice. Una vez que se analizan y especifican los requisitos del software, el diseño es la primera de las tres actividades técnicas – diseño, generación de código y pruebas – que se requieren para construir y verificar el software. Cada actividad transforma la información de manera que dé lugar, por último, a un software validado. En general, la actividad del diseño se refiere al establecimiento de las estructuras de datos, la arquitectura general del software, representaciones de la interfaz y algoritmos. Por tanto, el diseño debe contemplar todos los requisitos explícitos obtenidos en la fase de análisis, debe ser una guía que puedan leer y entender los que construyen el código y los que prueban y mantienen el software, debe proporcionar una idea completa de lo que es el software. Al tratarse de una aplicación y varios clientes web, la arquitectura será clienteservidor. Además, para diseñar dicha arquitectura se ha seleccionado el patrón MVC (Modelo Vista Controlador). 10.2 Arquitectura Cliente-Servidor La arquitectura cliente-servidor es un modelo para el desarrollo de sistemas de información en el que las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos. Se denomina cliente al proceso que inicia el diálogo o solicita los recursos y servidor al proceso que responde a las solicitudes. En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios y en el cliente permanece sólo lo particular de cada usuario. En esta aplicación los clientes realizan funciones como: • Manejar la interfaz de usuario. • Capturar y validar datos de entrada. • Generar consultas e informes sobre la base de datos. El servidor realiza, entre otras, las siguientes funciones: • Controlar accesos concurrentes a bases de datos compartidas. • Enlaces de comunicaciones con otras redes de área local o extensa. Entre las principales características de esta arquitectura se pueden destacar las siguientes: • El servidor presenta a todos sus clientes una interfaz única. • El cliente no necesita reconocer la lógica del servidor, sólo su interfaz externa. 45 • El cliente no depende de la ubicación física del servidor, ni del tipo de equipo físico en el que se encuentra, ni de su sistema operativo. • Los cambios en el servidor implican pocos o ningún cambio en el cliente. 10.3 Patrón MVC (Modelo Vista Controlador) Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario y la lógica de control en tres componentes distintos: • Modelo: datos. • Vista: muestra la información del modelo al usuario. • Controlador: gestiona las entradas del usuario e implementa la lógica de la aplicación. En el siguiente diagrama se puede observar este patrón y qué elementos se asocian con cada componente en la aplicación: Diagrama 13 - Modelo Vista Controlador En el diagrama anterior puede observarse que la Vista se presentará en un formato adecuado para que el usuario pueda interactuar con la misma. La interfaz de usuario, principalmente desarrollada en HTML, se encargará de presentar los contenidos de manera clara y accesible, obtenidos del Modelo. Cuando el usuario interactúa con la Vista haciendo clic en algún botón o realizando alguna acción, el Controlador recibirá la petición solicitada. Tras procesar la acción requerida, éste será el encargado de invocar peticiones al Modelo e incluso a la Vista. El Controlador está desarrollado en PHP, con lo que le permite comunicarse con la Vista y el Modelo, para modificarlos o actualizarlos. El Modelo es la representación específica de la información con la que opera el sistema. Consiste, principalmente, en las bases de datos en MySQL que almacenan toda la información de la aplicación. A ellas accede el Controlador para realizar modificaciones y actualizaciones y la Vista para obtener la información a presentar. 10.4 Diseño arquitectónico El diseño arquitectónico consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construcción del software para un sistema de información. Para la realización del diseño arquitectónico se ha seguido el patrón ModeloVista-Controlador, junto con la arquitectura Cliente-Servidor que nos proporciona 46 PHP, ambas explicadas anteriormente. El siguiente diagrama se muestra el diseño arquitectónico general del proyecto. Diagrama 14 - Diseño arquitectónico La capa de presentación representa la interfaz de usuario, a través de la cual se interactúa con la aplicación. Contiene el código HTML de la página y se encuentra enlazado a las librerías JavaScript y a las hojas de estilo (CSS). Esta capa presenta el sistema al usuario, le comunica información y también la captura para poder transmitirla a la capa de negocio. La capa de negocio es donde residen los programas que se ejecutan. Se reciben peticiones del usuario y se envían respuestas tras el proceso. Se denomina capa de 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 ejecutar programas y solicitar al gestor de la base de datos almacenar o recuperar información. La capa de datos es donde residen los datos. Está formada por el módulo Modelo que contiene las clases, métodos y funciones externas al sistema, las cuales son llamadas en la capa de negocio. Además, consta de un gestor de base de datos en MySQL que realiza gestiones como almacenar o recuperar información. 47 El siguiente diagrama ilustra un ejemplo de funcionamiento de todo lo explicado en las secciones anteriores para el caso de registro de un usuario. Diagrama 15 - Ejemplo de funcionamiento para el registro 10.5 Arquitectura de la solución La arquitectura en su capa más superior es tipo cliente-servidor, concretamente siguiendo el patrón MVC (Modelo-Vista-Controlador), ya explicado anteriormente. Este tipo de arquitecturas están basadas en que en uno de los lados se encuentra un servidor, el cual es único, y uno o varios clientes. Los clientes envían solicitudes de algún tipo de recursos al servidor, este procesa las solicitudes y responde a los clientes. A continuación se muestra una figura dónde se puede observar la arquitectura: 48 Ilustración 19 - Arquitectura de la solución Como se puede ver en el dibujo para seguir este patrón, hemos decidido utilizar el framework CodeIgniter. 10.5.1 CodeIgniter y su arquitectura CodeIgniter es un framework de código libre desarrollado en PHP para la creación de aplicaciones web en PHP. Contiene una serie de librerías y utilidades para hacer más fácil el uso de funciones de PHP avanzadas, que agilizan a su vez el proceso de desarrollo de una aplicación. Los puntos más interesantes del framework que ha hecho que nos decidamos por él, y no por otros, son: • Versatilidad: es capaz de trabajar con la mayoría de los entornos, servidores e incluso sistemas de alojamiento compartido. • Compatibilidad: es compatible con PHP 4, lo que hace que se pueda utilizar con servidores antiguos, y también con PHP 5. • Facilidad de instalación: con solo descomprimir el archivo de descarga en el servidor, y ajustar unos pocos parámetros en un archivo de configuración, tendremos CodeIgniter funcionando correctamente. No hay que estar con una consola escribiendo comandos, es bastante sencillo. • Flexibilidad: aunque tenga una manera definida para trabajar con él, muchas veces podremos seguir o no las reglas, lo que hace que la curva de 49 aprendizaje del mismo sea leve, y podemos aprender a utilizarlo en poco tiempo. • Ligereza: tiene un núcleo muy ligero, lo que permite que el servidor no se sobrecargue interpretando o ejecutando nuestro código. También ofrece la posibilidad de cargar los módulos según se necesite. • Documentación: tiene una documentación muy fácil de seguir ya que está explicada en modo tutorial. • Comunidad de usuarios: día a día los desarrolladores que trabajan con CodeIgniter aumenta y tiene una comunidad extensa con diferentes foros de ayuda que siempre viene bien. 10.5.2 Flujo de una aplicación con CodeIgniter En CodeIgniter existe un procedimiento para atender una solicitud de página del cliente. Este proceso se realiza internamente por el propio framework y de manera transparente para el desarrollador. Durante el proceso participan varios módulos como el enrutamiento de la solicitud, la caché interna, etc. Ahora veremos de manera gráfica como es el flujo que sigue la aplicación. Diagrama 16 - Flujo de una aplicación en CodeIgniter En resumen se puede seguir los siguientes pasos: 1. Toda solicitud de una página comienza en un index.php que hay en la raíz del framework. 2. Se realiza un filtrado de la URL para saber cuál es elemento que tiene que procesar esta página. 3. Si la página se había generado antes y está en la caché, se devuelve el archivo de la caché ya generado, con lo que se ahorra procesamientos repetidos. La caché se puede configurar y si lo deseamos, incluso deshabilitar. 4. Antes de continuar con el proceso se realiza un tratamiento de seguridad sobre la entrada que tengamos, tanto de la información que haya en la URL como de la información que haya en un posible POST, si lo hemos configurado así. 5. El controlador adecuado realiza el procesamiento de la solicitud. CodeIgniter decide el controlador que debe procesar la solicitud en función de la URL solicitada. 6. El controlador comunica con una serie de módulos, los que necesite, para producir la página. 7. A través de las vistas adecuadas, el controlador genera la página, tal cual se tiene que enviar al navegador. 8. Si la página no estaba en la caché, se introduce, para que las futuras solicitudes de esta página sean más rápidas. 50 Algunos de estos módulos, como la caché o el enrutamiento, funcionan de manera transparente para nosotros (es decir, no nos vamos a enterar). Otros, como los controladores, modelos y vistas, los tenemos que programar por nuestra cuenta y forman cada una de las partes de nuestra aplicación que, al estar separadas nos ayudan a organizar nuestro código. También tenemos a nuestra disposición diversas librerías, helpers y plugins con numerosas clases y funciones muy útiles para el desarrollo de aplicaciones web. 10.5.3 Estructura de una aplicación en CodeIgniter Una vez descargado y descomprimido el archivo de CodeIgniter, podemos observar que presenta la siguiente estructura: Diagrama 17 - Estructura de CodeIgniter Ahora veremos en detalle que hay en cada carpeta y cuál es su funcionalidad. Principalmente la estructura se divide en tres grandes módulos: application, system y user_guide. 10.5.3.1 Application Es la carpeta dónde se encontrará todo el código que vayamos a desarrollar. Básicamente contiene: los controladores, vistas, modelos, librerías y demás código para que nuestra aplicación funcione correctamente. Diagrama 18 - Estructura de la carpeta application A su vez contiene las siguientes carpetas: 51 • Cache: se guardarán las páginas que tengamos en caché si activamos la caché de páginas. • Config: contiene los ficheros de configuración del propio framework o de nuestras clases. • Controllers: es dónde estarán los controladores que hayamos creado. • Core: si creamos aplicaciones modulares con una estructura jerárquica, aquí guardaremos los ficheros que formen el núcleo de nuestra aplicación escalable que heredaran las otras aplicaciones. • Errors: contiene las clases que gestionan los errores de la aplicación. • Helpers: son clases con funciones que nos ayudan a mostrar o generar contenido de una forma rápida y sencilla. • Hooks: son funciones que le podemos dar la orden que se carguen, por ejemplo, antes de cargar los controladores, o después. • Language: es dónde guardaremos las clases para hacer que nuestra aplicación sea multilenguaje. • Libraries: dónde podemos guardar nuestras propias librerías para utilizarlas en los controladores. • Logs: cuando se produce algún error en el framework, aquí se guardan ficheros de logs de los mismos, que podemos consultar para depurar el código y corregirlo. • Models: guardaremos todos los modelos de datos que creemos. Directamente cada modelo trabajará con la base de datos. • Third_party: aquí se guardará código generado por un tercero, es decir, los plugins. • Views: todos los ficheros de las vistas irán en esta carpeta. 10.5.3.2 System Es la carpeta que contiene todo el núcleo del framework de CodeIgniter. A no ser que sea un caso excepcional, esta carpeta se mantendrá tal cual viene y no se modificará ningún archivo del mismo, porque podríamos hacer que dejase de funcionar correctamente el framework. Diagrama 19 - Estructura de la carpeta system Dentro de System podemos encontrar: • Core: es dónde están las clases del núcleo de CodeIgniter. • Database: se encuentran las clases, drivers y utilidades del framework para utilizar las bases de datos. • Fonts: contiene las familias de fuentes con las que trabaja CodeIgniter por defecto. 52 • Helpers: clases que dan forma a las funciones que nos ayudan en CodeIgniter para facilitarnos el uso de funciones más avanzadas. • Language: se utiliza para el multilenguaje. • Libraries: contienen todas las librerías que trae por defecto CodeIgniter. 10.5.3.3 User_guide Está toda la documentación del framework. También se puede encontrar en la web, así que si lo deseamos podemos suprimirla para evitar que ocupe espacio en el servidor. 10.5.4 Estructura de la aplicación web La estructura de la aplicación web se basa principalmente en la estructura del framework pero nos centraremos en el siguiente árbol de carpetas: Diagrama 20 - Estructura de la aplicación web 10.5.4.1 Controllers En ella están todos los controladores que hemos creado para la aplicación. • Acceso: se utiliza para actualizar la contraseña de al administrador. • Accounts: se utiliza para el iniciar sesión, registro de cualquier usuario, cliente y administrador, recordar contraseña. • Carrito: se utiliza para todo lo que tenga que ver con la gestión de un pedido, como por ejemplo añadir un ítem, descuento, menú, o también validarlo y pagar. • Cartas: se encarga de toda la gestión de la carta. • Categorías: se encarga de toda la gestión de las categorías. • Cliente: es un controlador que da acceso al perfil de un cliente. • Clientes: se encarga de toda la gestión de los clientes. • Descuentos: se utiliza para la gestión de los descuentos. • Estadísticas: un controlador bastante elaborado en el cual se tratan los datos para mostrar estadísticas útiles para el administrador. • iCliente: este controlador se encarga de gestionar toda la información necesaria que tiene un cliente en el restaurante. • Información: se utiliza para gestionar información básica de un restaurante como por ejemplo, horarios, descripción, logo, etc… • Ítems: se encarga de la gestión de los ítems. • Log: se encarga de todas las funciones necesarias para llevar un log del uso de la aplicación por parte de los usuarios. 59 (dependiendo del tamaño) de cada uno de los ítems para esa carta en concreto1. El tercer esquema representa las opciones relacionas con los comentarios y valoraciones de un restaurante. Las tablas comentarios, likes y valoraciones, están relacionadas, mediante el identificador, a las tablas de item, administrador y cliente, para poder determinar que comentarios y/o like y/o valoración se hizo sobre qué ítem y quién lo hizo. La tabla valoraciones_generales tiene asociada la tabla de administradores y clientes puesto que son valoraciones de un restaurante de forma genérica, siguiendo los parámetros escalables señalados en el esquema. Esquema 3 - Relación entre los elementos del bloque social en la base de datos • comentarios: contiene cada uno de los comentarios sobre un ítem, con su fecha y si es público o no. • comentarios_histórico: es una copia exacta de cada uno de los comentarios usado para generar las estadísticas. • likes: contiene cada uno de los likes realizados sobre un ítem con su fecha. • likes_histórico: copia de likes para generación de estadísticas. • valoraciones: contiene cada una de las valoraciones numéricas sobre un ítem, con su fecha y su visibilidad (si es público o no). • valoraciones_histórico: copia de valoraciones para generación de estadísticas. • valoraciones_generales: contiene la valoración numérica del restaurante atendiendo a los parámetros establecidos. Además incluye la fecha. • valoraciones_generales_historico: copia de valoraciones_generales para generación de estadísticas. Las siguientes dos tablas representadas en el cuarto de los esquemas, se utilizan para guardar la información de uso dentro del sistema. 1 El precio de un ítem puede ser distinto en diferentes cartas, como por ejemplo por cuestiones de temporada, algunos productos tienen precios distintos dependiendo de la época del año. 60 Esquema 4 - Tablas de log • log: Guarda información cuando un administrador o trabajador de restaurante realiza un cambio. Esto es útil para llevar un seguimiento sobre los cambios que se producen en el sistema. • logcliente: Guarda información cuando un cliente realiza un cambio. En el siguiente esquema se detallan todas las tablas que hacen referencia a la información que se muestra en el perfil público del restaurante. Todas las tablas de este esquema dependen de la tabla administradores para saber a qué restaurante se hace referencia. La inclusión de estas tablas es una decisión de diseño para facilitar la detección de errores en la información y no tener una única tabla con demasiada información. Esquema 5 – Tablas con los datos sobre un restaurante 61 • perfiles: Contiene la información sobre redes sociales, y las cosas que son visibles dentro del perfil público. • slider: Contiene las imágenes y los enlaces de las imágenes en el carrusel de imágenes del perfil. • widgets: determina si los elementos dinámicos del perfil son visibles y su orden. • establecimientos: incluye toda la información relativa al restaurante y la forma de pago. • horarios: contiene los horarios de apertura y cierre del restaurante. El sexto esquema contiene las tablas relacionas con los pedidos realizados. Nótese que la tabla pedido_cliente depende de las tablas administradores y clientes para determinar quién ha hecho el pedido y en qué restaurante. Esquema 6 – Tablas con la información de los pedidos • Pedido_cliente: contiene toda la información relativa a un pedido. • Detalles_pedido: contiene todos los ítems y/o menús y/o descuento que tiene un pedido. • Pedido_cliente_historico: copia de la tabla pedido_cliente (sin el campo que determina una llama del cliente dentro del restaurante) para utilizar en el apartado de estadísticas y en el de generación de facturas en formato pdf. 62 La última de las tablas hace referencia al apartado de los descuentos. Esta tabla depende de administradores y determina a qué restaurante corresponde el descuento. Esquema 7 - Tabla de descuentos El resultado de este diseño se encuentra en el CD adjunto en el archivo easyorder.sql. El manual de instalación de esta base de datos y del proyecto en general se encuentra en el Anexo 6. 63 10.7 Diseño de la interfaz web Para conseguir uniformidad visual y siguiendo el prototipo definitivo señalado en el apartado de análisis, se realiza el diseño de la interfaz siguiendo una serie de patrones visuales: • Combinación de colores: Se ha optado por destacar las partes fundamentales de las interfaces con rojo en combinación con blanco. Según estudios psicológicos realizados sobre los colores, el color rojo2 puede atraer dependiendo del estado emocional. Es el color del fuego y se asocia con impulsos como comer, por tanto puede crear apetito. Además tiende a estimular y aumenta el ritmo cardiaco. A nivel corporativo, el azul y el rojo son los colores más usados en publicidad. El blanco suele ser usado para sugerir limpieza y eficiencia. Es muy usado por compañías involucradas en prestar servicios. La combinación rojo/blanco para las interfaces y el logotipo se considera, teniendo en cuenta las características del proyecto, como la más acertada. Se ha utilizado la siguiente tonalidad de rojo por compatibilidad con los navegadores web actuales. Ilustración 20 - Colores corporativos • Tipografía: Se ha utilizado, debido a su limpieza, claridad y compatibilidad con caracteres internacionales, para todo el contenido la tipografía Lato. Ilustración 21 - Tipografía utilizada El nombre de la aplicación debe englobar los valores corporativos que se pretenden destacar, así como una identificación rápida de la marca. Para la decisión se hizo la siguiente lluvia de ideas, donde podemos destacar, Facilidad de uso (simple/easy), rapidez (fast/instant) y pedidos (order) : 2 El rojo también ha sido utilizado por grandes empresas como coca cola, que le ha dado valor de felicidad y tranquilidad con sus campañas publicitarias. 64 Ilustración 22 - Lluvia de ideas de posibles nombres para el proyecto Por tanto, se ha optado finalmente por el nombre easyorder. Para el logotipo del proyecto, usando la combinación de colores seleccionada y la tipografía Lobster 1.4, éste es el resultado final: Ilustración 23 - Logotipo definitivo Para la identificación de las opciones disponibles, se ha utilizado una representación iconográfica uniforme en tonalidades de grises y azules claros que combinan con el fondo blanco del resto de la interfaz, que le da un aspecto limpio, plano y claro al portal. Ilustración 24 - Diseño de las opciones Para la representación y fácil identificación de los estados de un pedido, se ha utilizado un código de colores específico dependiendo de dicho estado. 65 Ilustración 25 - Identificación por colores del estado de un pedido Por tanto, podemos ver en la siguiente imagen cómo es una de las vistas del panel de administración: Ilustración 26 - Vista de los ítems creados en el restaurante En cuanto al perfil público de la interfaz, para continuar con la homogeneidad de estilos, y siguiendo las características definidas en el prototipo de validación tenemos la siguiente interfaz: 66 Ilustración 27 - Vista principal del perfil público Como se puede ver en la imagen, el rojo está presente en la cabecera principal del perfil, y los bloques con información están destacados en gris, en combinación con el fondo blanco general. Tanto en el panel de administración, como en el perfil, la simplicidad y la limpieza (sin sombras ni efectos de profundidad) son la base del estilo utilizado, siguiendo los estilos de las aplicaciones y sistemas operativos de la actualidad. Para ver más detalles sobre el diseño de la interfaz, vaya al ANEXO 3 apartado b. 67 10.8 Diseño de la interfaz móvil La aplicación móvil de comanda necesita de una interfaz funcional y clara, sin necesidad de entrar en detalles de aspecto visual. Por tanto, en este caso se ha optado por una interfaz con tonos azules y grises, con letras en negro o blanco (dependiendo del fondo donde se utilicen) que facilitan la lectura de los datos para pantallas pequeñas. Siguiendo las tendencias actuales en aplicaciones para pantallas de 4 o 5 pulgadas, se ha incluido un menú lateral despegable con las funciones principales, que está disponible únicamente cuando el usuario de la aplicación lo seleccione. En la siguiente imagen podemos ver este menú lateral, así como las vistas de pedidos en proceso y pedidos servidos. Nótese que el pedido señalado en amarillo significa que se ha producido un aviso por parte de un cliente en el restaurante. Ilustración 28 - Menú lateral, y vista de los pedidos Con respecto a la toma del pedido, en la siguiente imagen se puede ver cómo se ha adaptado ese procedimiento siguiendo el procedimiento habitual en un restaurante. 68 Ilustración 29 - Pasos para la toma de un pedido Además se incluye la posibilidad de ver detalles de los clientes del restaurante, como se puede ver en la siguiente imagen: Ilustración 30 - Buscar información de un cliente En la vista general de un pedido se puede cambiar el estado, editar las notas, activas/desactivar aviso del cliente y marcar un pedido como pagado. En la siguiente imagen podemos ver los pasos para marcar un pedido como pagado. 75 tecnología AJAX o indicadores de carga de página. Para su instalación se debe descargar, incluir los ficheros en el proyecto y cargarlos mediante el siguiente código: Se ha usado para mostrar ventanas emergentes como la carga de imágenes, o la vista detallada de los ítems en el perfil público. Ilustración 34 - Ventana emergente que utiliza dialog2 • formhelper: Librería que proporciona muchas funciones estéticas interesantes como la selección de países o husos horarios por banderas, con filtrado de datos. En la página oficial7 se puede obtener información sobre su uso e instalación. Siguiendo los ejemplos anteriores, una vez descargado, para poder instalarla simplemente debemos invocar de la misma forma, tanto sus archivos CSS como sus JS. En el proyecto se ha utilizado para seleccionar el país en los datos de un restaurante, y mostrar las banderas. También se utilizó para mostrar los horarios de apertura y cierre del restaurante. 7 Página web oficial: http://bootstrapformhelpers.com/ <link href="<?php echo base_url();?>media/css/dialog2/jquery.dialog2.css" rel="stylesheet"> <script type="text/javascript" src="<?php echo base_url();?>media/js/dialog2/jquery.dialog2.js"></script> <script type="text/javascript" src="<?php echo base_url();?>media/js/dialog2/jquery.dialog2.helpers.js"></sc ript> 76 Ilustración 35 - Selección del país utilizando la estética de FormHelper • holder: Librería usada para mostrar una imagen en blanco. En la página web oficial8 vemos muchos de los ejemplos según los tamaños que queramos definir. Para su instalación simplemente debemos incluir el fichero holder.js a nuestro proyecto, e invocarlo desde el código fuente. Para su uso hay que añadir la siguiente línea de código, que especifica el tamaño en pixeles. Crea una imagen con fondo gris especificando el tamaño en pixeles. Ilustración 36 - Vista de una imagen creada con holder • highcharts: Librería que utiliza tecnología JavaScript para la representación gráfica de datos. En su página web oficial9 podemos descargar los ficheros y añadirlos a nuestro proyecto. Es la única librería de pago de las utilizadas, aunque sólo para fines comerciales. Incluye diferentes formas de representación entre las que destacamos: • Representación lineal • Representación por áreas coloreadas • Representación por columnas • Representación en burbujas Entre sus funciones más destacadas podemos destacar la posibilidad de ocultar/mostrar información en los gráficos de forma inmediata y hacer zoom en cualquier zona del gráfico. En el proyecto se utiliza para el apartado de estadísticas. En el siguiente código vemos la configuración para el apartado de tipo de pago. 8 Página web oficial: http://imsky.github.io/holder/ 9 Página web oficial: http://www.highcharts.com/ <img src="holder.js/100x100"> 77 • raty: Librería para la representación de las valoraciones numéricas, permite asignar rangos de valores, e incluye diferentes iconos de representación. En chart9 = new Highcharts.Chart({ chart: { plotBackgroundColor: null, plotBorderWidth: null, plotShadow: false, renderTo: 'multi_forma_pagos' }, title: { text: "Efectivo vs. Tarjeta vs. Paypal" }, tooltip: { formatter: function(){ return this.point.name + ': <b>'+ this.point.y +' veces</b> - <b>'+Highcharts.numberFormat(this.percentage,1)+'%</b> '; } }, plotOptions: { pie: { allowPointSelect: true, cursor: 'pointer', dataLabels: { enabled: false }, showInLegend: true } }, series: [{ type: 'pie', name: 'Veces', data: par_9 }] }); 78 la página web10 se puede descargar el fichero para incluirlo en el proyecto. Se utiliza para hacer valoraciones sobre los ítems y el restaurante en el perfil público. Ilustración 37 - Valoración general de un restaurante. • jQuery Mobile: framework basado en jQuery que adapta las interfaces de una aplicación web a los dispositivos móviles. Se utiliza para el desarrollo de las aplicaciones móviles facilitando la adaptación de la interfaz. Además, gracias al uso de este framework, las aplicaciones móviles no dependen del sistema operativo del dispositivo, por tanto pueden ser ejecutadas en cualquier dispositivo con conexión a internet. Para poder utilizarlo debemos descargarlo de la página web oficial11 e integrarlo en nuestro código. Una posible estructura puede ser la representada en el siguiente código, donde tenemos una cabecera, una lista de elementos, un botón y un pie de vista. 10 Página web oficial: http://wbotelhos.com/raty 11 Página web oficial: http://jquerymobile.com/ 79 En este proyecto se ha utilizado para la creación de la aplicación móvil. 11.2.2 Funcionales • paypal: Librería de paypal integrada en codeigniter para realizar los pagos a través de su plataforma. En el proyecto se utiliza para configurar una pasarela de pago de los pedidos, siempre que el administrador del restaurante especifique su identificador de usuario de paypal. Se han hecho pruebas con el entorno sandbox que paypal proporciona para los desarrolladores de <div data-role="page" id="page1"> <div data-theme="a" data-role="header"> <h3> Header </h3> <ul data-role="listview" data-divider-theme="b" datainset="true"> <li data-role="list-divider" role="heading"> Divider </li> <li data-theme="c"> <a href="#" data-transition="slide"> Button </a> </li> </ul> </div> <div data-role="content"> <a data-role="button" href="#page1"> Button </a> </div> <div data-theme="a" data-role="footer" data-position="fixed"> <h3> Footer </h3> </div> </div> 80 aplicaciones. Al estar incluida en el CodeIgniter no tenemos que hacer nada para poder utilizarla. • twitteroauth: Librería de autentificado en twitter, en el caso de que el restaurante tenga perfil en esta red social, para obtener el número de seguidores y poder actualizarlo en el perfil público del restaurante. Para su uso, nos la descargamos de su página oficial12 y la integramos en nuestro código. Ilustración 38 - Actualizar contadores sociales • jQuery.video: Librería utilizada para cargar videos subidos de los ítems. En la página oficial13 podemos descargarnos el fichero para la inclusión en el proyecto. Se puede configurar el reproductor con diferentes opciones. La reproducción de video sigue los estándares de HTML5 y puede ser integrado en la gran mayoría de los navegadores web actuales. Permite la inclusión de videos en mp4 y ogv. Ilustración 39 - Vista de un video con el reproductor. • WYSIhtml: Librería de formateado de texto basada en HTML5. Incluye la mayoría de las opciones principales para editar el texto, entre las que destacan negrita, cursiva, subrayado y subida de imágenes entre otras. Se puede configurar para activar y desactivar todas las opciones que queramos, personalizando los bloques de texto. En la página web14 tenemos los ficheros que debemos descargar y su forma de uso. 12 Página web oficial: https://github.com/abraham/twitteroauth 13 Página web oficial: http://html5-ninja.com/preview/5 14 Página web oficial: http://jhollingworth.github.io/bootstrap-wysihtml5/ 81 Ilustración 40 - Vista de las opciones incluidas en el proyecto de edición de texto. En este proyecto se utiliza para poder personalizar el texto (cambiar colores al texto, propiedades de negrita, cursiva, etc.) de la descripción de los ítems, cartas, información del restaurante, etc. • gomap: Librería para la inclusión de mapas utilizando Google Maps. En su página web15 encontramos la información necesaria para su instalación y uso. Incluye múltiples opciones de como centrar el mapa y añadir marcadores. Para su uso, añadimos la configuración de la siguiente forma: #direccioncompleta contiene la información del restaurante En el proyecto se utiliza en el mapa de la información de un restaurante en su perfil público. • TCPDF: Librería de creación de documentos pdf. Incluye numerosas configuraciones para la creación y maquetado de los documentos. Es una de las librerías más usadas y utiliza tecnología PHP para el paso de las variables, por tanto, se integra de forma directa con nuestro proyecto. En la página web16 se encuentra un manual extenso con todas las configuraciones y método de instalación. Para este proyecto se ha hecho una adaptación para generar las facturas de los pedidos en el siguiente formato: 15 Página web oficial: http://www.pittss.lv/jquery/gomap/ 16 Página web oficial: http://www.tcpdf.org/ $("#map").goMap({ address: $("td#direccioncompleta").text(), scaleControl: true, maptype: 'ROADMAP', zoom: 17 }); $.goMap.createMarker({ address: $("td#direccioncompleta").text() }); 82 Ilustración 41 - Diseño de una factura generada en formato PDF • dataTables: Librería que permite la creación y edición de tablas creadas en HTML para la representación de datos. Entre sus características principales podemos destacar: • Paginación de longitud variable. • Ordenación de columnas por tipo de datos. • Manejo automático del acho de las columnas. • Amplia variedad de plugins. • Búsqueda de elementos. En la página web17 disponemos del manual de instalación y uso, así como de mucha información para la configuración personalizada. Un pequeño ejemplo de uso es el siguiente, donde vemos la configuración para la tabla de usuarios de un administrador de restaurante: 17 Página web oficial: http://datatables.net/ 83 En este proyecto se utiliza para todas las tablas que muestran la información en las diferentes opciones. • slidemenu: Librería usada para la aplicación móvil de comanda, que permite la inclusión de un menú lateral. En la página web18 tenemos información detallada de su uso e instalación. Esta perfectamente integrada en jQuery Mobile, lo cual hace sencillo su uso en el proyecto. 18 Página web oficial: http://www.tegdesign.com/tegansnyder-JQuery-Mobile-Slide-Menu/ $('#usuarios_tabla').dataTable( { "sDom":"<'row-fluid'<'span12 input-block-level'f>r>t<'rowfluid'<'span12'p>>", "sPaginationType": "bootstrap", "oLanguage": { "sLengthMenu": "Mostrar _MENU_ por página", "sZeroRecords": "No existe nada relacionado, lo sentimos :(", "sInfo": "Hay _TOTAL_ usuarios.", "sInfoEmpty": "", "sInfoFiltered": "", "sSearch": "" }, "aoColumns": [ null, null, null, null, {"bSortable": false} ], "iDisplayLength": 7 } ); 84 12 Validación y Testeo Las pruebas presentan una interesante anomalía para el ingeniero del software. Durante las fases anteriores de definición y de desarrollo, el ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible. A continuación, llegan las pruebas. El ingeniero crea una serie de casos de pruebas que intentan "demoler" el software construido. De hecho, las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo. [PRE03] Para la realización de pruebas del software existen tres enfoques principales. Ya que la prueba exhaustiva del software es impracticable (no se pueden probar todas las posibilidades de su funcionamiento), en este proyecto se ha llevado a cabo el enfoque funcional o de caja negra, donde las pruebas se centran en las funciones, entradas y salidas. El enfoque funcional o de caja negra sigue el siguiente esquema: Esquema 8 - Enfoque funcional o de caja negra. En un sistema formado por módulos como nuestro proyecto, se ha considerado a cada módulo como una caja negra dentro del sistema global. De esta manera se consigue una independencia entre los módulos que facilita sus pruebas, para una detección centralizada de errores. Las pruebas se han realizado sobre la propia interfaz del proyecto durante su fase de desarrollo, validando los módulos por separado, proporcionando unas entradas y estudiando las salidas para ver si concuerdan con las esperadas. Para la elección de los casos de prueba se ha tenido en cuenta uno de los fundamentos del enfoque de caja negra: Reducir el número de casos necesarios para que la prueba sea razonable. Esto implica que el caso ejecute el máximo número de posibilidades de entrada diferentes para así reducir el total de casos. Gracias a este método se ha conseguido una detección temprana de errores funcionales y se ha agilizado el proceso de desarrollo de forma notable. Una vez que todos los módulos se implementaron y se probaron usando este enfoque, se hicieron pruebas globales de rendimiento y usabilidad con distintas personas ajenas al desarrollo de este proyecto (algunas de ellas profesionales de la hostelería y restauración), tratando de darle un enfoque aplicado a la realidad en los restaurantes. Estas últimas pruebas tuvieron como objetivo fundamental conocer las carencias y virtudes de la aplicación de cara a una posible integración en algún restaurante y definieron algunos de los puntos explicados en el apartado de trabajo futuro. 91 JavaScript, PHP, HTML5 y CSS3, así como en frameworks de desarrollo actuales como CodeIgniter, JqueryMobile y Bootstrap. Para el desarrollo del proyecto se han tenido que combinar conocimientos obtenidos durante la carrera con el aprendizaje de aplicaciones y herramientas desconocidas, lo cual ha proporcionado unas nuevas aptitudes que pueden ser muy útiles en el futuro. Además, uno de los puntos importantes de este proyecto, es la reutilización y personificación de librerías de terceros que en la carrera no se tiene en cuenta. La realidad de los proyectos actuales es que existen muchas librerías y algoritmos con licencia de uso gratuita que son utilizadas para agilizar el desarrollo. Gracias a este proyecto he adquirido experiencia en la integración y adaptación de esas librerías de terceros. 13.6.2 Conclusiones personales A nivel personal, este es el proyecto más ambicioso y con posibilidades de ampliación, como se muestra en el apartado de trabajo futuro, en el que he trabajado. He quedado satisfecho tanto con el trabajo realizado, como con los resultados obtenidos. Además, al tener una parte de trabajo en equipo, he experimentado las dificultades y bondades de este tipo de proyectos, donde la organización y la coordinación son fundamentales. 92 14 Trabajo futuro EasyOrder nació bajo unas necesidades y objetivos mínimos que debían cumplirse, pero un producto software nunca es perfecto en su primera versión y es por eso que se proponen unas líneas de trabajo futuro que pueden mejorar sensiblemente las características actuales e incluir nuevas funcionalidades: • Estado por comanda: En la actualidad el sistema contempla la posibilidad de añadir un estado a un pedido global. La realidad en un restaurante es distinta, cada elemento o grupos de elementos dentro de un pedido pueden estar en diferentes estados, por tanto, incluir esta modificación ayudaría a conseguir un sistema más cercano a la realidad. • Notificaciones más rápidas: En la actualidad el sistema de notificaciones de nuevos pedidos se actualiza cada 30 segundos, si bien no es un tiempo muy amplio, lo ideal sería que las notificaciones se hicieran en tiempo real, sin incluir retardo. • Hacer las cartas más personalizadas: El sistema contempla la posibilidad de añadir gustos de los clientes, pero éstos no quedan reflejados en la carta que un cliente en concreto ve. Se podría destacar esos ítems que están relacionados con los gustos del cliente. • Pedidos desde más dispositivos: En la actualidad, existe una versión para dispositivos móviles que usa el trabajador de restaurante, pero no el cliente. Cada vez más, las personas disponen de teléfonos inteligentes, por tanto, sería interesante desarrollar una aplicación de forma que el cliente pueda realizar pedidos desde su propio dispositivo móvil. • Sistema de reserva de mesa: El sistema permite realizar pedidos, pero no contempla un sistema de reserva. En la realidad, muchas personas reservan mesa, por tanto, una función interesante podría ser un sistema que permita al cliente solicitar una reserva en el restaurante. • Sistema de validación de restaurante: Para evitar el registro de restaurantes que en realidad no lo sean, se podría implementar un sistema automático de validación, donde el administrador de un restaurante debería de suministrar unos datos para comprobar que realmente es el propietario del mismo. • Software multilenguaje: Se ha desarrollado todo en español, una gran mejora seria disponer de la posibilidad de cambiar el idioma para internacionalizar la aplicación, y ofrecer a los restaurantes una traducción directa de sus cartas en diferentes idiomas. 93 15 Bibliografía básica [1] [PRE03] Pressman, Roger S. Ingeniería del Software, un enfoque práctico Editorial McGraw-Hill España, 2003, pp. 21. [2] [MAT03] Celma Giménez, Matilde. Bases de datos relacionales. Pearson Educación, Madrid, 2003. [3] [PSRE09] Hermosillo Aguirre, Jesús Darío Psicología en los restaurantes Universidad de las Américas, Puebla, 2009 [4] [DUAPP10] Clark, Josh Diseño y usabilidad de aplicaciones iPhone Anaya, Madrid, 2010 94 16 Webgrafía básica [w1] http://ellislab.com/codeigniter [w2] http://getbootstrap.com/2.3.2/ [w3] http://www.w3schools.com/ [w4] https://github.com/ [w5] http://www.maestrosdelweb.com/ [w6] http://jquerymobile.com/ [w7] http://uno-de-piera.com/ [w8] http://stackoverflow.com/ [w9] http://fontawesome.io/ 95 17 Anexos 17.1 Anexo 1 – Plantilla de casos de uso A continuación se explica la estructura de la plantilla utilizada para representar los casos de uso. Nombre Identificador Actor Principal Personal involucrado o intereses Descripción Trigger Precondición Postcondición Flujo Normal Flujo Alternativo Excepción Includes Requisitos Especiales Notas Identificador Dar a cada caso de uso un entero secuencial único identificativo. Alternativamente, se puede usar la forma jerárquica X.Y. Casos relacionados pueden agruparse jerárquicamente. Nombre Selecciona un nombre que sea lo más explicativo posible. Este ha de reflejar por sí mismo la tarea que el usuario necesita realizar. Actor Especifica el actor principal que recurre a los servicios del sistema para cumplir un objetivo. También hay que indicar cualquier otro actor que participe en la consecución. Personal involucrado o intereses Esta lista es más importante y práctica de lo que podría parecer a primera vista. Sugiere y delimita qué es lo que debe hacer el sistema. Citando a Cockburn: “El sistema funciona siguiendo un contrato entre el personal involucrado, donde los casos de usos detallan parte de comportamiento del contrato… El caso de 96 uso, como contrato de comportamiento, captura todo y sólo el comportamiento relacionado con la satisfacción de los intereses del personal involucrado” [COC01]. Descripción Especifica una descripción resumida de las razones y el resultado del caso de uso. Trigger Identifica al evento que inicializo el caso de uso. Esto puede ser un evento externo o un evento del generado por el propio sistema, también puede ser el primer paso del flujo normal. Precondiciones Las precondiciones establecen lo que siempre debe cumplirse antes de comenzar un escenario de caso de uso. Las precondiciones no se prueban en el caso de uso, sino que son condiciones que se asumen que son verdad. Normalmente, una precondición implica un escenario de otro caso de uso que se ha completado con éxito. Por lo tanto, hay que listar cualquier actividad que debe tener lugar, o cualquier condición que debe ser cierta, antes de que el caso de uso pueda comenzar. Postcondiciones Las postcondiciones o garantías de éxito establecen qué debe cumplirse cuando el caso de uso se completa con éxito. La garantía debería satisfacer a todo el personal involucrado. Por lo tanto, las postcondiciones describen el estado del sistema tras la conclusión del caso de uso. Las postcondiciones se deben numerar. Flujo normal Describe el camino de éxito típico que satisface los intereses del personal involucrado. Provee una descripción detallada de las acciones de usuario y las respuestas del sistema que tendrán lugar durante la ejecución normal del caso de uso. Esta secuencia llevará a la consecución del caso de uso, alcanzando el objetivo deseado. La descripción se puede escribir como una respuesta a la hipotética pregunta, “¿Cómo hago para conseguir la tarea especificada en el caso de uso en cuestión?” Esto se consigue mejor mediante una lista de acciones realizadas por el actor, alternativamente con las respuestas ofrecidas por el sistema. Un estilo habitual es poner en mayúsculas los nombres de los actores para facilitar la identificación. Flujo alternativo o extensiones Las extensiones son muy importantes. Indican todos los otros escenarios o bifurcaciones, tanto de éxito como de fracaso. Por lo tanto, la combinación del flujo normal y del flujo alternativo deberían satisfacer “casi” todos los intereses del personal involucrado (de los usuarios). Excepciones Describe cualquier condición de error que pueda ocurrir durante la ejecución del caso de uso, y define cómo el sistema responde en estas situaciones. También describe cómo el sistema responde si la ejecución del caso de uso falla por alguna situación no controlada. Se ha de especificar si tras un error de este tipo se ha de realizar una vuelta atrás de las modificaciones que se estaban realizando, si 97 finaliza parcialmente con un estado conocido, o si se deja en un estado indeterminado como resultado de la excepción. Includes Lista cualquier otro caso de uso que este incluido por este caso de uso. Si aparece una funcionalidad común en múltiples casos de uso, esta puede convertirse en un caso de uso el cual pueda ser incluido por aquellos casos de uso que necesiten esa funcionalidad. Requisitos especiales Si un requisito no funcional, atributo de calidad o restricción se relaciona de manera específica con un caso de uso, se recoge en el caso de uso. Esto incluye cualidades tales como rendimiento, fiabilidad y facilidad de uso, y restricciones de diseño (a menudo, en dispositivos de entrada/salida) que son obligados o se consideran probables. Notas Lista cualquier comentario adicional sobre el caso de uso. 98 99 17.2 Anexo 2 – Casos de uso de la web Nombre Registro Identificador 1 Actor Principal Usuario no registrado. Personal involucrado o intereses El usuario desea registrarse en la plataforma. Descripción Un usuario que accede a la plataforma sin registrarse y desea formar parte de la plataforma. Trigger Acceder a la pantalla de registro de la plataforma. Precondición No exista ese usuario ya en el sistema. Postcondición El usuario recibe un email para validar su registro. Flujo Normal 1. Accede a la pantalla de registro. 2. Rellena sus datos de acceso. 3. Selecciona el tipo de usuario (cliente o restaurante). 4. Envía la solicitud de acceso. Flujo Alternativo Excepción El nombre de usuario ya está registrado en la plataforma. Includes Requisitos Especiales Notas 100 Nombre Ver perfil del restaurante Identificador 2 Actores Principales 1. Usuario no registrado. 2. Administrador de restaurante. 3. Trabajador de restaurante. 4. Cliente. Personal involucrado o intereses Cualquier actor que realice esto quiere ver el perfil público de un restaurante. Descripción Se desea ver la información sobre un restaurante en concreto. Trigger Seleccionar el perfil del restaurante. Precondición El restaurante debe tener activado el perfil público. Postcondición Accede a la información pública del restaurante. Flujo Normal 1. Busca la dirección pública del restaurante. 2. Accede a ella. Flujo Alternativo En el caso de un cliente, puede acceder a ella desde el apartado de restaurantes 1. Accede al apartado de búsqueda de restaurantes. 2. Selecciona el restaurante que desea. Excepción Si el perfil no está público el sistema no permite el acceso y muestra un mensaje de error. Includes Requisitos Especiales Notas 107 Nombre Ver vista detallada de un descuento Identificador 9 Actores Principales 1. Usuario no registrado. 2. Administrador de restaurante. 3. Trabajador de restaurante. 4. Cliente. Personal involucrado o intereses Cualquier actor que realice esto quiere ver la información detallada de un descuento en concreto. Descripción Se desea ver la información de un descuento, donde aparece información como su descripción, el código para utilizarlo, el periodo de validez, etc. Trigger En el apartado de descuentos del perfil del restaurante seleccionar un descuento. Precondición El restaurante debe tener activado el perfil público y el actor debe estar en la sección descuentos del perfil. Postcondición Accede a la información detallada de un descuento. Flujo Normal 1. Estando en el perfil público, selecciona el apartado de descuento 2. Selecciona el descuento del que desea ver la información detallada. Flujo Alternativo Excepción Si el perfil no está público el sistema no permite el acceso. Includes Requisitos Especiales Notas 108 Nombre Iniciar sesión Identificador 10 Actor Principal 1. Cliente. 2. Administrador de restaurante. 3. Trabajador de restaurante. Personal involucrado o intereses Cualquier actor registrado en la plataforma que quiera acceder. Descripción La persona que quiere acceder a la plataforma para utilizarla. Trigger En la página principal de la plataforma en el apartado de iniciar sesión Precondición 1. Estar registrado en la plataforma. 2. No haber iniciado sesión. Postcondición Acceso a la plataforma. Flujo Normal 1. Accede a la página principal de la plataforma. 2. Introduce sus datos de acceso. 3. Envía la información para poder acceder. Flujo Alternativo Excepción Los datos de acceso no son válidos. En tal caso el sistema alertará que no se han introducido correctamente. Includes Requisitos Especiales Notas 109 Nombre Cerrar sesión Identificador 11 Actor Principal 1. Cliente. 2. Administrador de restaurante. 3. Trabajador de restaurante. Personal involucrado o intereses Cualquier actor registrado en la plataforma que quiera salir y cerrar su sesión. Descripción La persona que teniendo su sesión iniciada quiere salir de ella. Trigger En la cabecera principal de la aplicación, seleccionar cerrar sesión. Precondición 1. Estar registrado en la plataforma. 2. Haber iniciado sesión. Postcondición Cierre de la sesión. Flujo Normal 1. En la cabecera de la aplicación, abrir el menú de opciones. 2. Seleccionar la opción cerrar sesión. Flujo Alternativo Excepción Includes Requisitos Especiales Notas 110 Nombre Recordar contraseña Identificador 12 Actor Principal 1. Cliente. 2. Administrador de restaurante. 3. Trabajador de restaurante. Personal involucrado o intereses Cualquier actor registrado en la plataforma que quiera recordar la contraseña. Descripción La persona con registro en la plataforma que no recuerda su contraseña para acceder. Trigger En el apartado de ¿Olvidastes tu contraseña? Introducir tu correo electrónico Precondición 1. Estar registrado en la plataforma. 2. No haber iniciado sesión. Postcondición Recibe la nueva contraseña en su correo electrónico Flujo Normal 1. En la cabecera de la aplicación seleccionar ¿Olvidastes tu contraseña? . 2. Escribir el correo electrónico y enviar la información al sistema. Flujo Alternativo Excepción En el caso de que el correo electrónico no exista en la aplicación, el sistema mostrará un mensaje de error. Includes Requisitos Especiales Notas 111 Nombre Ver inicio Identificador 13 Actor Principal 1. Cliente. 2. Administrador de restaurante. 3. Trabajador de restaurante. Personal involucrado o intereses Cualquier actor registrado en la plataforma que quiera ver la página de inicio. Descripción Los clientes que quieran ver información de sus datos personales y sus últimos pedidos. En el caso de administrador de restaurante puede la información de últimos pedidos y recibir alertas de nuevos pedidos y trabajador del restaurante podrá ver su rol. Trigger Acceder a la pantalla de inicio del panel de configuración. Precondición 1. Estar registrado en la plataforma. Postcondición Accede a la pantalla de inicio. Flujo Normal 1. Teniendo la sesión abierta, entrar en el panel de configuración. 2. Acceder al apartado de inicio. Flujo Alternativo 1. Entrar en la página web de la aplicación. 2. Introducir sus datos de registro. 3. Acceder al sistema. Excepción Includes Requisitos Especiales Notas 112 Nombre Ver pedidos Identificador 14 Actor Principal 1. Cliente. 2. Administrador de restaurante. 3. Trabajador de restaurante (si tiene permiso de acceso). Personal involucrado o intereses Cualquier actor registrado en la plataforma que quiera ver los pedidos. Descripción Los clientes que quieran ver información de sus pedidos realizados, donde se muestran detalles como el restaurante donde se hizo, el estado, etc. En el caso de administrador de restaurante y trabajador (si tiene permisos de acceso) podrá ver información sobre los pedidos como estado, cliente, si ha sido pagado o no, etc. Trigger Acceder a la pantalla de pedidos del panel de configuración. Precondición 1. Estar registrado en la plataforma. 2. En el caso de trabajador del restaurante debe tener permisos de acceso al apartado de pedidos. Postcondición Accede a la pantalla de pedidos. Flujo Normal 1. Teniendo la sesión abierta, entrar en el panel de configuración. 2. Acceder al apartado de pedidos. Flujo Alternativo Excepción En el caso de que no tenga pedidos, el sistema alertará esta situación. Includes Requisitos Especiales Notas 113 Nombre Vista detallada de un pedido Identificador 15 Actor Principal 1. Cliente. 2. Administrador de restaurante. 3. Trabajador de restaurante (si tiene permiso de acceso). Personal involucrado o intereses Cualquier actor registrado en la plataforma que quiera ver detalles de un pedido. Descripción Los clientes que quieran ver información detallada de un pedido concreto, donde se muestran detalles como los ítems/menus/descuentos, el estado, generar factura (caso de uso 16), etc. En el caso de administrador de restaurante y trabajador (si tiene permisos de acceso) podrá ver información detallada de un pedido como los ítems/menus/descuentos, el estado, las notas privadas, generar factura (caso de uso 16), etc. Trigger Acceder a la pantalla detalles de un pedido. Precondición 1. Estar registrado en la plataforma. 2. Estar en el apartado de pedidos. Postcondición Accede a los detalles del pedido señalado. Flujo Normal 1. Teniendo la sesión abierta, entrar en el panel de configuración. 2. Acceder al apartado de pedidos. 3. Seleccionar el pedido que se quiere ver. Flujo Alternativo Excepción Includes Requisitos Especiales Notas 114 Nombre Generar factura de un pedido Identificador 16 Actor Principal 1. Cliente. 2. Administrador de restaurante. 3. Trabajador de restaurante (si tiene permiso de acceso). Personal involucrado o intereses Cualquier actor registrado en la plataforma que quiera generar una factura. Descripción Cualquiera de los actores que quiera generar la factura de un pedido. Trigger Generar la factura de un pedido en formato PDF. Precondición 1. Estar registrado en la plataforma. 2. Estar en la vista detallada de un pedido. Postcondición Obtener la factura en formato PDF. Flujo Normal 1. Teniendo la sesión abierta, entrar en el panel de configuración. 2. Acceder al apartado de pedidos. 3. Seleccionar el pedido que se quiere ver. 4. Seleccionar Factura. Flujo Alternativo Excepción En el caso de un pedido reembolsado, se genera un documento PDF con dos folios, especificando el reembolso. Includes Requisitos Especiales Notas 115 Nombre Ver restaurantes que es cliente Identificador 17 Actor Principal 1. Cliente. Personal involucrado o intereses El cliente que quiera ver sus restaurantes. Descripción Un cliente que quiera ver todos los restaurantes de los que es cliente de forma rápida. Trigger Ver restaurantes de los que es cliente. Precondición 1. Estar registrado en la plataforma. Postcondición Ver todos los restaurantes de los que es cliente. Flujo Normal 1. Teniendo la sesión abierta, entrar en el panel de configuración. 2. Acceder al apartado de Restaurantes. Flujo Alternativo Excepción En el caso de que no tenga restaurantes, el sistema alertará esta situación. Includes Requisitos Especiales Notas 116 Nombre Buscar restaurantes Identificador 18 Actor Principal 1. Cliente. Personal involucrado o intereses El cliente que quiera buscar los restaurantes que están en el sistema Descripción Un cliente que quiera ver todos los restaurantes adheridos a la plataforma. Trigger Ver información de todos los restaurantes como nombre, dirección, e información de contacto. Precondición 1. Estar registrado en la plataforma como cliente. Postcondición Ver todos los restaurantes con la información básica. Flujo Normal 1. Teniendo la sesión abierta, entrar en el panel de configuración. 2. Acceder al apartado de Restaurantes. 3. Acceder a la opción de buscar restaurantes. Flujo Alternativo Excepción En el caso de que no existan restaurantes en la aplicación, el sistema alertará esta situación. Includes Requisitos Especiales Notas 123 Nombre Eliminar valoraciones de ítems Identificador 25 Actor Principal 1. Cliente. Personal involucrado o intereses Cliente que quiera eliminar una valoración realizada sobre un ítem. Descripción En el caso de un cliente podrá eliminar cualquier valoración sobre un ítem que haya hecho. Trigger Eliminar una valoración sobe un ítem concreto. Precondición 1. Estar registrado en la plataforma. 2. Haber realizado una valoración sobre el ítem. Postcondición Valoración eliminada. Flujo Normal 1. Teniendo la sesión abierta, entrar en el panel de configuración. 2. Acceder al apartado de valoraciones. 3. Acceder a ver todas las valoraciones. 4. Hacer clic en eliminar la valoración que se quiera. Flujo Alternativo Excepción En el caso de que no existan valoraciones, la opción de eliminar no aparecerá. Includes Requisitos Especiales Notas 124 Nombre Ver valoraciones generales Identificador 26 Actor Principal 1. Cliente. 2. Administrador de restaurante. 3. Trabajador de restaurante (si tiene permiso de acceso). Personal involucrado o intereses Cualquier actor registrado en la plataforma que quiera las valoraciones sobre el restaurante. Descripción En el caso de un cliente podrá ver sus valoraciones globales de los restaurantes, en base a los parámetros globales, pudiendo ordenar por restaurante, fecha y valores. En el caso de un administrador o trabajador de restaurante, podrá ver las valoraciones que han hecho los clientes sobre su restaurante, en base a los parámetros globales, pudiendo ordenar por cliente, fecha y valores. Trigger Ver todas las valoraciones globales del restaurante. Precondición 1. Estar registrado en la plataforma. Postcondición Ver todas las valoraciones globales. Flujo Normal 1. Teniendo la sesión abierta, entrar en el panel de configuración. 2. Acceder al apartado de valoraciones. 3. Acceder a ver a las valoraciones generales. Flujo Alternativo Excepción En el caso de que no haya valoraciones, el sistema alertará esta situación. Includes Requisitos Especiales Notas 125 Nombre Eliminar valoraciones generales Identificador 27 Actor Principal 1. Cliente. Personal involucrado o intereses Cliente que quiera eliminar una valoración realizada sobre un restaurante. Descripción En el caso de un cliente podrá eliminar cualquier valoración sobre un restaurante que haya hecho. Trigger Eliminar una valoración sobe un restaurante concreto. Precondición 1. Estar registrado en la plataforma. 2. Haber realizado una valoración sobre el restaurante. Postcondición Valoración eliminada. Flujo Normal 1. Teniendo la sesión abierta, entrar en el panel de configuración. 2. Acceder al apartado de valoraciones. 3. Acceder a ver todas las valoraciones generales. 4. Hacer clic en eliminar la valoración que se quiera. Flujo Alternativo Excepción En el caso de que no existan valoraciones, la opción de eliminar no aparecerá. Includes Requisitos Especiales Notas 126 Nombre Actualizar datos personales Identificador 28 Actor Principal 1. Cliente. 2. Trabajador del Restaurante. Personal involucrado o intereses Actores que quieran cambiar sus datos personales. Descripción Cuando cualquiera de los actores especificados quiera realizar cambios en sus datos personales. En el caso de los clientes podrán actualizar datos como gustos, una foto, email, teléfono de contacto, etc. En el caso de un trabajador de restaurante podrá cambiar nombre y apellidos. Trigger Cambiar o actualizar los datos personales. Precondición 1. Estar registrado en el sistema. Postcondición Los datos modificados serán actualizados en el sistema. Flujo Normal 1. Teniendo la sesión abierta, entrar en el panel de configuración. 2. Acceder al apartado de mis datos. 3. Actualizar los datos que se deseen cambiar. Flujo Alternativo Excepción Includes Requisitos Especiales Notas 127 Nombre Hacerse cliente de un restaurante Identificador 29 Actor Principal 1. Cliente. Personal involucrado o intereses Un cliente que quiera ser cliente de un restaurante. Descripción Un cliente, que desea poder realizar valoraciones, comentarios y poder pedir, en un restaurante concreto. Trigger Hacerse cliente de un restaurante. Precondición 1. Estar registrado en el sistema como cliente. 2. No ser cliente de ese restaurante en concreto. Postcondición Es cliente del restaurante seleccionado. Flujo Normal 1. Teniendo la sesión abierta, acceder al perfil público del restaurante. 2. Hacer clic en hacerse cliente del restaurante. Flujo Alternativo Excepción Si el restaurante no tiene visible el perfil público, no se podrá hacer cliente. Includes Requisitos Especiales Notas 128 Nombre Eliminar condición de cliente del restaurante Identificador 30 Actor Principal 1. Cliente. 2. Administrador de restaurante 3. Trabajador de restaurante (si tiene permiso de acceso). Personal involucrado o intereses Un cliente que ya no quiera ser cliente de un restaurante. Un Administrador o trabajador de restaurante, que ya no quiera a una persona como cliente. Descripción Una persona que siendo cliente del restaurante, ya no lo quiere ser más. En el caso del restaurante también podrá quitar a una persona de su clientela, negándole por tanto, los privilegios de comentarios, valoraciones y pedidos. Trigger Eliminar la condición de cliente de un restaurante en concreto. Precondición 1. Estar registrado en el sistema. 2. La persona a eliminar debe ser cliente de ese restaurante en concreto. Postcondición Elimina la condición de cliente del restaurante seleccionado. Flujo Normal (como cliente) 1. Teniendo la sesión abierta como cliente. 2. a) Acceder al perfil público del restaurante. 3. a) Hacer clic en eliminar cliente del restaurante. 2. b) Acceder al panel de configuración. 3. b) Acceder al apartado de restaurantes. 4. b) Hacer clic en el botón de eliminar del restaurante. Flujo Alternativo (como administrador o trabajador de restaurante) 1 Teniendo la sesión abierta como administrador o trabajador, acceder a panel de administración. 2 Acceder al apartado de clientes. 3 Eliminar el cliente. Excepción Si el restaurante no tiene visible el perfil público, no se podrá eliminar la condición de cliente, desde el flujo normal apartado a Includes 129 Nombre Hacer una valoración general Identificador 31 Actor Principal 1 Cliente. Personal involucrado o intereses Cliente que quiera realizar una valoración sobre un restaurante. Descripción En el caso de un cliente podrá valorar un restaurante en base a unos parámetros predefinidos. Trigger Hacer una valoración general sobe un restaurante concreto. Precondición 1 Estar registrado en la plataforma como cliente. 2 Ser cliente del restaurante 3 No haber realizado una valoración general sobre ese restaurante, al menos 24 horas antes. Postcondición Valoración del restaurante. Flujo Normal 1 Teniendo la sesión abierta, acceder al perfil del restaurante a valorar. 2 Acceder a “danos tu valoración”. 3 Marcar los valores de cada parámetro y enviar las valoraciones. Flujo Alternativo Excepción En el caso de que no sea cliente del restaurante, no verá está opción. Siendo cliente del restaurante, intenta valorar dos veces en menos de 24 horas el sistema alertará que no es posible realizar la valoración. Includes Requisitos Especiales Notas 130 Nombre Añadir ítem a un pedido Identificador 32 Actor Principal 1 Cliente. Personal involucrado o intereses Cliente que quiera añadir ítem a un pedido. Descripción En el momento de realizar un pedido, un cliente quiere añadir un ítem a su pedido. Trigger Añadir ítem a un pedido. Precondición 1 Estar registrado en la plataforma como cliente. 2 Ser cliente del restaurante. 3 El restaurante debe tener activado el perfil público, y la posibilidad de realizar pedidos. Postcondición Se añade el ítem seleccionado al pedido. Flujo Normal 1 Teniendo la sesión abierta, acceder al perfil del restaurante. 2 Acceder al apartado de cartas. 3 Seleccionar el ítem, con su tamaño. 4 Añadir al pedido. Flujo Alternativo Excepción En el caso de que no sea cliente del restaurante, no verá está opción. Siendo cliente del restaurante, si el restaurante no tiene activado los pedidos, sólo podrá ver el ítem pero no pedirlo. Includes Requisitos Especiales Notas 131 Nombre Añadir menú a un pedido Identificador 33 Actor Principal 1 Cliente. Personal involucrado o intereses Cliente que quiera añadir un menú a un pedido. Descripción En el momento de realizar un pedido, un cliente quiere añadir un menú a su pedido. Trigger Añadir menú a un pedido. Precondición 1 Estar registrado en la plataforma como cliente. 2 Ser cliente del restaurante. 3 El restaurante debe tener activado el perfil público, y la posibilidad de realizar pedidos. Postcondición Se añade el menú seleccionado al pedido. Flujo Normal 1 Teniendo la sesión abierta, acceder al perfil del restaurante. 2 Acceder al apartado de cartas. 3 Seleccionar el menú. 4 Seleccionar los ítems del menú (uno por sección). 5 Añadir al pedido. Flujo Alternativo Excepción En el caso de que no sea cliente del restaurante, no verá está opción. Siendo cliente del restaurante, si el restaurante no tiene activado los pedidos, sólo podrá ver los menús, sin poder añadirlo al pedido. Includes Requisitos Especiales Notas 132 Nombre Ver pedido Identificador 34 Actor Principal 1 Cliente. Personal involucrado o intereses Cliente que quiera ver su pedido actual. Descripción En cualquier momento, un cliente quiere poder ver su pedido actual, es decir el pedido que está realizando pero que no ha confirmado. Trigger Ver detalles de un pedido actual. Precondición 1 Estar registrado en la plataforma como cliente. 2 Ser cliente del restaurante. 3 El restaurante debe tener activado el perfil público, y la posibilidad de realizar pedidos. Postcondición Aparecen todos los detalles del pedido actual. Flujo Normal 1 Teniendo la sesión abierta, acceder al perfil del restaurante. 2 Hacer clic en el apartado de pedido. Flujo Alternativo Excepción En el caso de que no sea cliente del restaurante, no verá está opción. Siendo cliente del restaurante, si el restaurante no tiene activado los pedidos no podrá ver está opción. Si el pedido está vacío el sistema alertará de este evento. Includes Requisitos Especiales Notas