instituto politécnico nacionaltesis.ipn.mx/jspui/bitstream/123456789/15889/1/plataforma... ·...

!!!

Instituto Politécnico Nacional !UNIDAD PROFESIONAL INTERDISCIPLINARIA

EN INGENIERÍA Y TECNOLOGÍAS AVANZADAS !

UPIITA!

Trabajo Terminal:

“Plataforma de Menú en la Nube”

Que para obtener el título de: “Ingeniero en Telemática”

!Presentan:

Abel Escalante Mendoza Sandra Patiño Fuentes

!!Asesores:Ing. Carlos Hernández Mejía

Ing. Fernando Cisneros Escalante

Instituto Politécnico Nacional

UNIDAD PROFESIONAL INTERDISCIPLINARIA

EN INGENIERÍA Y TECNOLOGÍA AVANZADA

UPIITA

Trabajo Terminal:

“MiTV VOD Gateway”

Que para obtener el título de:

“Ingeniero en Telemática”

Presenta:

Juan Carlos Castañeda Martínez

Asesores:

M. en C. Raúl Fernández Zavala

M. en C. Noé Sierra Romero

M. en C. Blanca Alicia Rico Jiménez

!

!




UPIITA

Trabajo Terminal:




Presenta:


Asesores:




!

!




UPIITA

Trabajo Terminal:




Presenta:


Asesores:




!

!

!!!!Instituto Politécnico Nacional

!UNIDAD PROFESIONAL INTERDISCIPLINARIA EN

INGENIERÍA Y TECNOLOGÍAS AVANZADAS !

UPIITA!

Trabajo Terminal:

“Plataforma de Menú en la Nube”

Que para obtener el título de: “Ingeniero en Telemática”

!Presentan:Abel Escalante Mendoza Sandra Patiño Fuentes




UPIITA

Trabajo Terminal:




Presenta:


Asesores:




!

!




UPIITA

Trabajo Terminal:




Presenta:


Asesores:




!

!

Presidente !

Secretario

_______________________ _______________________M. en C. Paola Nayeli Cortez Herrera M. en C. Iclia Villordo Jiménez!

Vocales

!_______________________

!_______________________

Ing. Carlos Hernández Mejía Ing. Fernando Cisneros Escalante

!

Agradecimientos

Abel Escalante Mendoza !A mis padres: Abel Escalante y Cecilia Mendoza por su comprensión, amor y apoyo incondicional; no solo durante toda mi formación académica, si no durante toda mi vida y sobre todo por enseñarme lo que hoy resumo en una frase: “Nada es imposible, lo que te propongas lo puedes hacer, solo sé perseverante y constante”. Éste nuevo logro no solo es mío; si no también de ustedes, porque sin ustedes esto no hubiera sido posible, y les puedo asegurar que sus sacrificios no fueron en en vano, y que aquello que sembraron ayer, hoy por fin está rindiendo frutos. No me queda mas que agradecerles infinitamente todo lo que han hecho por mi y permitirme aprender tanto de ustedes … Gracias, los amo “papis”, espero que lo disfruten. !A mi asesor, primo y mejor amigo: Fernando Cisneros por su gran apoyo, amor y ganas de querer transmitirme todo su gran conocimiento y sobre todo porque sin él, esto definitivamente no hubiera sido posible. Mi primo, mejor amigo y hermano, te estoy eternamente agradecido por todo lo que has hecho por mi, has estado presente durante todas las etapas de mi vida; desde nuestras locuras de niños, como en este nuevo logro. Hoy puedo decirte con dicha y orgullo que eres mi ejemplo a seguir y aunque aun me falta mucho por hacer, “Quiero ser como tú”. Gracias !!! !A mi hoy esposa: Sandra Patiño Fuentes por querer compartir conmigo este largo viaje y sobre todo por ser parte de este nuevo logro para ambos, porque hoy por fin podemos decir que “Somos Ingenieros”. Esto solo es el comienzo de muchos logros y éxitos que seguiremos cosechando, siempre juntos, simplemente …… TE AMO !!!. !A mi pequeño: “Santy” que hoy no sabe lo que significa esto, pero espero en unos años pueda entender el significado de este gran logro, y por supuesto, que el día de mañana yo pueda llegar a ser un ejemplo a seguir para él.

!!!!!!A mi hermana: Ceci Escalante por se pilar de mi desarrollo, por todo lo que me permitiste compartir contigo; desde nuestras “tonterías” como de esos momentos que nos embargaron de felicidad, como el nacimiento de “Danita”. Hoy quiero darte las gracias, porque de verdad sin ti mi infancia no hubiera sido igual y por supuesto que debes considerarte parte de este nuevo logro para mi …… Hermanita, te quiero mucho!!!. !A mis tíos, primos y sobrinos: David, Liz, Ale, Gaby Flores, Ángel, Fabi, Itzel, Jairo, Brando, Higinio Agatón, Licha, Iraís, Marco, Julio, Gumaro, Arnurlfo, Vitelia, Higinio Mendoza por estar siempre en todo momento y hacer este camino mas llevadero y ameno. !A mis amigos: Pepe, Tabla, Juan, Ray, Carmen, Suniel, Gabriel, Adrian, Victor, Israel por siempre estar en la mejor disposición y hacer ameno este largo camino para convertimos en profesionistas. !A mi asesor: Carlos Hernández por siempre estar en la mejor disposición para ayudarme a realizar este trabajo. !A mi profesor: Noe Sierra, porque gracias a todas sus enseñanzas y entusiasmo, hoy reafirme mi vocación.

!!!!!!!Sandra Patiño Fuentes !La presente Tesis es un esfuerzo en el cual, directa o indirectamente, participaron varias personas leyendo, opinando, corrigiendo, teniéndonos paciencia, dando ánimo, acompañando en los momentos de crisis y en los momentos de felicidad. !Agradezco con todo mi cariño y mi amor de una manera muy especial a Dios y a mis padres, la señora Ma. Inés Fuentes Gracia y el Sr. Alberto Patiño Paz, que hicieron todo en la vida para que yo pudiera lograr mis sueños personales y profesionales, por motivarme y darme la mano cuando sentía que el camino se terminaba, por haberme acompañado a lo largo de mi vida y carrera, y por brindarme una vida llena de aprendizajes, valores, experiencias y sobre todo felicidad. !A mi hermana Griselda Patiño Fuentes y mi hermano José Alberto Patiño gracias por apoyarme en los momentos difíciles y por los momentos de felicidad. Gracias a mi cuñada Elvia Edith Mar por su apoyo y por dejarme estar cerca de ese angelito hermoso Héctor que fue mi motivación y me dio fortaleza y una gran alegría con su llegada. !Agradezco también de una manera muy especial con mucho amor a mi compañero de tesis, amigo y amado esposo Abel Escalante Mendoza que ha sido un impulso en mi vida y una parte importante para la culminación de mi carrera, gracias amor por tu apoyo constante y amor incondicional hoy hemos alcanzado un triunfo más por que los dos somos uno mismo y mis logros son tuyos, te amo. !A mi querido hijo Abel Santiago con el cual hoy estamos compartiendo un logro importante, pero anhelo el día en el que él comparta sus logros con nosotros, te amo hijo. !También me gustaría agradecer de todo corazón a Fernando Cisneros Trejo uno de nuestros asesores por compartir este proyecto con nosotros apoyarnos incondicionalmente y guiarnos durante el desarrollo del mismo y claro también agradezco a su linda esposa Gabriela Flores que es una persona increíble, los queremos y apreciamos demasiado. Al profesor Carlos Hernandez que fue nuestro asesor gracias profesor por sus consejos, por su disposición para ayudarnos cuando lo necesitamos, su apoyo incondicional y su amistad.

!!!!!!Doy las gracias a mis profesores durante toda mi carrera profesional porque todos han aportado con un granito de arena a mi formación, gracias por sus consejos, sus enseñanza y más que todo por su amistad. y por supuesto a esta mi querida institución IPN y sobre todo a la UPIITA que me ha dejado muchas enseñanzas y lecciones de vida. !Son muchas las personas que han formado parte de mi vida profesional a las que me encantaría agradecerles su amistad, consejos, apoyo, ánimo y compañía en los momentos más difíciles de mi vida. Algunas están aquí conmigo y otras en mis recuerdos y en mi corazón, sin importar en donde estén quiero darles las gracias por formar parte de mí, por todo lo que me han brindado y por todas sus bendiciones !Ricardo García, Christopher Virgen Vazquez, Ivan Raul Flores Morales, Suniel Ottolenghi Katter, Enrico Morales, Jose Antonio Rodriguez, Claudia Cristina Barron, Omar Calzada, Alvaro Fernando Becerril, Israel Rivera, Elizabeth Martinez, Andrés Mateo, Alejandro Velazquez, Cesar Hernandez,Guillermo Chaparro, Jose Juan Torres, etc. !

Gracias. !

Cuando hay amor, pasión y determinación no hay nada que te detenga.. Vive para lo que hagas y no vivas de lo que haces.

!

Índice

Resumen 1 Abstract 3 Objetivos 5

Objetivo General 5 Objetivos Específicos 5

Capítulo 1: Antecedentes y Planteamiento del Problema 6 1.1 Introducción 6 1.2 Justificación 7 1.3 Antecedentes 9

eMenu 9

CENTRAL ® para iMenu v100 9

1.4 Planteamiento del Problema 10 1.5 Solución Propuesta 11

Módulo Perfil 12

Módulo Navegación 13

Módulo Comanda 13

Módulo Receptor de Órdenes 15

Funcionamiento 15

Capítulo 2: Marco Teórico 18 2.1 Ruby on Rails 18 2.2 iOS SDK 19 2.3 Heruku 19 2.4 AFNetworking 20

2.5 ZBar 21 2.6 Devise 22 2.7 Fórmula Haversine 23 2.8 Google Maps SDK 24 2.9 PostgreSQL 25 2.10 Faye 26

Capítulo 3: Arquitectura y Diseño del Sistema 27 3.1 Arquitectura del Sistema 27 3.2 Diseño del Sistema 30

Diagrama de Casos de Uso 30 Módulo Perfil 31


Módulo Comanda 36


Diagrama de Actividades 42 Módulo Perfil 42


Módulo Comanda 47


Diagrama de Despliegue 49

Diagrama de Paquetes y Clases 50

Diagrama de Secuencia 54

Diagrama Entidad – Relación 59

Capítulo 4: Necesidades del Sistema y Selección de Herramientas 65

4.1 Necesidades del Sistema 65 4.2 Selección de Herramientas 65

Módulo Perfil 65


Módulo Comanda 66


Plataforma de Menú en la Nube (General) 66

Capítulo 5: Desarrollo del Sistema 67

!

!

5.1 Aplicación Web 67 Vista general de la Aplicación Web 67

Base de Datos de la Plataforma 68

Consultas (Modelos) 70

Interfaz Web (vistas) 72 Módulo Perfil 73


Funcionalidad de la Aplicación (controlador) 78 Módulo Perfil 78


5.2 Aplicación Nativa para Dispositivos Móviles iOS 82 Vista general de la Aplicación para Dispositivos Móviles 82

“Check In” en Sucursal 83

Asignación de Mesa 86

Selección de Items 88

Visualización y envío de Orden 89

“Check Out” de Órdenes 90

Capítulo 6: Pruebas del Sistema 92 6.1 Módulo Perfil 92 6.2 Módulo Navegación 98 6.3 Módulo Comanda 100 6.4 Módulo Receptor de Órdenes 102

Conclusiones 103 Acrónimos 105 Bibliografía 107

!

Índice de Figuras y Tablas

Figura 1-1. Diagrama de Bloques General de la Plataforma de Menú en la Nube. 11

Figura 1-2. Diagrama de Bloques Detallado de la Plataforma de Menú en la Nube. 17

Figura 2-1. Logotipo de Ruby on Rails. 18

Figura 2-2. Logotipo de iOS SDK. 19

Figura 2-3. Logotipo de Heroku. 19

Figura 2-4. Logotipo de AFNetworking. 20

Figura 2-5. Logotipo de ZBar. 21

Figura 2-6. Logotipo de Devise. 22

Figura 2-7. Triángulo esférico solucionado por la ley de haversine. 23

Figura 2-8. Logotipo de Google Maps. 24

Figura 2-9. Logotipo de PostgreSQL. 25

Figura 2-10. Logotipo de Faye. 26

Figura 3-1. Diagrama de Bloques de la Arquitectura de la Plataforma de Menú en la Nube. 27

Figura 3-2. Diagrama de Casos de Uso General. 30

Figura 3-3. Diagrama de Casos de Uso del Módulo Perfil. 31

Tabla 3-1. Descripción de Caso de Uso Crear Perfil. 32

Tabla 3-2. Descripción de Caso de Uso Registrar Restaurante. 32

Tabla 3-3. Descripción de Caso de Uso Autenticarse. 33

Figura 3-4. Diagrama de Casos de Uso del Módulo Navegación. 34

Tabla 3-4. Descripción de Caso de Uso Navegar Perfil. 35

Tabla 3-5. Descripción de Caso de Uso Navegar Restaurante. 35

Figura 3-5. Diagrama de Casos de Uso del Módulo Navegación. 36

Tabla 3-6. Descripción de Caso de Uso Hacer “Check In”. 37

Tabla 3-7. Descripción de Caso de Uso Leer Código QR de Mesa. 37

Tabla 3-8. Descripción de Caso de Uso Ordenar Ítems. 38

Tabla 3-9. Descripción de Caso de Uso Pagar Comanda. 38

Figura 3-6. Diagrama de Casos de Uso del Módulo Receptor de Órdenes. 39

Tabla 3-10. Descripción de Caso de Uso Ver Orden. 40

Tabla 3-11. Descripción de Caso de Uso Atender Orden. 40

Tabla 3-12. Descripción de Caso de Uso Cerrar Orden. 41

Figura 3-7. Diagrama de Actividades de Crear Perfil. 42

Figura 3-8. Diagrama de Actividades de Crear Restaurante. 43

Figura 3-9. Diagrama de Actividades de Crear Sucursal. 44

Figura 3-10. Diagrama de Actividades de Ver Restaurante. 45

Figura 3-11. Diagrama de Actividades de Ver Sucursal. 46

Figura 3-12. Diagrama de Actividades del Módulo Comanda. 47

Figura 3-13. Diagrama de Actividades del Módulo Receptor de Órdenes. 48

Figura 3-14. Diagrama de Despliegue de la Plataforma de Menú en la Nube. 49

Figura 3-15. Diagrama de Paquetes. 50

Figura 3-16. Diagrama de Clases del Módulo Perfil. 51

Figura 3-17. Diagrama de Clases del Módulo Navegación. 52

Figura 3-18. Diagrama de Clases del Módulo Comanda. 53

Figura 3-19. Diagrama de Clases del Módulo Recepto de Órdenes. 53

Figura 3-20. Diagrama de Secuencia de Perfiles del Módulo Perfil. 54

Figura 3-21. Diagrama de Secuencia de Restaurantes del Módulo Perfil. 55

Figura 3-22. Diagrama de Secuencia del Módulo Navegación. 56

Figura 3-23. Diagrama de Secuencia del Módulo Comanda. 57

Figura 3-24. Diagrama de Secuencia del Módulo Receptor de Órdenes. 58

Figura 3-25. Diagrama Entidad Relación de la Base de Datos. 59

Figura 3-26. Diagrama Relacional de la Base de Datos. 60

Tabla 3-13. Campos de la tabla PROFILES de la Base de Datos. 61

Tabla 3-14. Campos de la tabla RESTAURANTS de la Base de Datos. 61

Tabla 3-15. Campos de la tabla MENUS de la Base de Datos. 61

Tabla 3-16. Campos de la tabla ITEMS de la Base de Datos. 62

Tabla 3-17. Campos de la tabla ITEMS_MENUS de la Base de Datos. 62

Tabla 3-18. Campos de la tabla BRANCHES de la Base de Datos. 62

Tabla 3-19. Campos de la tabla TABLES de la Base de Datos. 63

Tabla 3-20. Campos de la tabla TABLES_SESSIONS de la Base de Datos. 63

Tabla 3-21. Campos de la tabla ORDERS de la Base de Datos. 63

Tabla 3-22. Campos de la tabla ITEMS_ORDERS de la Base de Datos. 64

Tabla 3-23. Campos de la tabla PICTURES de la Base de Datos. 64

Figura 5-1. Diagrama de Bloques de la Aplicación Web. 67

Figura 5-2. Extracto del archivo de configuración database.yml. 68

Figura 5-3. Archivo de migración devise_create_profiles.rb para la creación de la tabla Perfiles. 69

Figura 5-4. Extracto del archivo profile.rb. 70

Figura 5-5. Extracto del archivo restaurant.rb. 71

Figura 5-6. Extracto del archivo new.html.erb de las vistas de profiles. 72

Figura 5-7. Pantalla de Creación de Perfil. 73

Figura 5-8. Pantalla de Creación de Restaurante. 73

Figura 5-9. Pantalla de Creación de Menús. 74

Figura 5-10. Pantalla de Creación de Ítems. 74

Figura 5-11. Pantalla de Creación de Sucursales. 75

Figura 5-12. Pantalla de Creación de Mesas. 75

Figura 5-13. Pantalla Ver Restaurante. 76

Figura 5-14. Pantalla Ver Menú. 76

Figura 5-15. Pantalla Ver Ítem. 77

Figura 5-16. Pantalla Ver Sucursal. 77

Figura 5-17. Extracto del archivo branches_controller.rb. 78

Figura 5-18. Extracto del archivo tables_controller.rb. 79

Figura 5-19. Extracto del archivo restaurants_controller.rb. 80

Figura 5-20. Extracto del archivo menus_controller.rb. 81

Figura 5-21. Diagrama de Bloques de la Aplicación Nativa para Dispositivos Móviles iOS. 82

Figura 5-22. Fragmento de código de petición HTTP a través de AFNetworking. 83

Figura 5-23. Fragmento de código del controlador GetCheckInViewController. 83

Figura 5-24. Fragmento de código del método didUpdateToLocation. 84

Figura 5-25. Fragmento de código del método reverseGeocodeLocation. 85

Figura 5-26. Pantalla de “check in” del dispositivo móvil. 86

Figura 5-27. Fragmento de código del controlador ReadQRCodeViewController. 86

Figura 5-28. Pantalla de leer código QR del dispositivo móvil. 87

Figura 5-29. Fragmento de código del controlador AddItemsToOrderViewController. 88

Figura 5-30. Pantallas para agregar items a la orden. 89

Figura 5-31. Fragmento de código del controlador ShowOrdersViewController. 89

Figura 5-32. Pantallas para ver la orden actual. 90

Figura 5-33. Fragmento de código del controlador SessionOrdersCheckOutViewController. 91

Figura 5-34. Pantalla para ver la orden actual. 91

!!!!!!!!!

Figura 6-1. Pantalla en la cual se creó un nuevo perfil. 92

Figura 6-2. Pantalla en la cual se creó un nuevo restaurante. 93

Figura 6-3. Pantalla en la cual se visualizó el restaurante creado. 93

Figura 6-4. Pantalla en la cual se creó un nuevo menú. 94

Figura 6-5. Pantalla en la cual se visualizó el menú creado. 94

Figura 6-6. Pantalla en la cual se creó un nuevo item. 95

Figura 6-7. Pantalla en la cual se visualizó el item creado. 95

Figura 6-8. Pantalla en la cual se creó una nueva sucursal. 96

Figura 6-9. Pantalla en la cual se creó una mesa. 96

Figura 6-10. Pantalla en la cual se visualizó la mesa creada. 97

Figura 6-11. Pantalla en la cual se seleccionó un restaurante. 98

Figura 6-12. Pantalla en la cual se seleccionó un menú. 98

Figura 6-13. Pantalla en la cual se seleccionó un item. 99

Figura 6-14. Pantalla en la cual se seleccionó una sucursal. 99

Figura 6-15. Pantalla en la cual se realizó el “check in”. 100

Figura 6-16. Pantalla en la cual se realizó la lectura del código QR. 100

Figura 6-17. Pantallas en la cuales se seleccionó y agrego un item a la orden. 101

Figura 6-18. Pantalla en la cual se visualizó la orden. 101

Figura 6-19. Pantalla en la cual se visualizó el “check out” de la orden. 102

Figura 6-20. Pantalla en la cual se visualizaron las órdenes que fueron atendidas. 102

!

Resumen

Hoy en día muchos restaurantes han incursionado en la adquisición de una infraestructura especializada para brindar un servicio más rápido, eficiente y de mejor calidad al cliente y solucionar muchos problemas que se encuentran presentes con respecto a la atención que los restaurantes brindan hacia los clientes. !Debido a lo anterior, el propósito de ésta plataforma es mejorar la interacción que tienen actualmente los restaurantes con sus clientes, logrando que dicha interacción sea más rápida y eficiente; haciendo uso de la tecnología que ofrecen los dispositivos móviles de última generación y tomando como base la estructura y funcionamiento de algunas redes sociales usadas hoy en día. !Los restaurantes que se suscriban a la plataforma, podrán crear un nuevo perfil que les permitirá administrar toda la información referente a dicho restaurante (menús, ítems, sucursales, etc.) y permitirá que dicha información pueda se consultada por los visitantes (posibles clientes). El uso de perfiles para la administración de los restaurantes suscritos a la plataforma tiene como objetivo que los restaurantes puedan mostrar los servicios que ofrecen a los clientes; de forma similar a como algunas redes sociales (como Facebook™, Twitter™, Instagram™, etc.) realizan la administración de perfiles de sus miembros; logrando con esto, que dicha administración sea más limpia y eficiente. !Una vez creados los perfiles de los restaurantes suscritos a la plataforma, los visitantes podrán navegar a través de cada uno de éstos perfiles y conocer lo que ofrece cada uno de los restaurantes (menús, ítems, sucursales, etc.). La navegación a través de los perfiles de los restaurantes se llevará a cabo accediendo a la plataforma desde cualquier dispositivo móvil o equipo de cómputo que cuente con algún navegador Web y una conexión a una red de datos (WiFi, Ethernet, 3G, etc.) con acceso a Internet. Gracias al diseño considerado para esta sección de la plataforma (diseñada y estructurada como aplicación Web); los visitantes podrán visualizar los perfiles desde cualquier lugar a cualquier hora, tan solo accediendo a dicha plataforma desde sus dispositivos móviles o equipos de cómputo. !!!

!1Tesis: Plataforma de Menú en la Nube

Plataforma Menú en la Nube

Los clientes que acudan a cualquiera de los restaurantes (suscritos a la plataforma) podrán disfrutar del gran beneficio que ofrece la plataforma: ahorrar tiempo. La forma en la cual los clientes podrán obtener éste beneficio, será usando sus propios dispositivos móviles (específicamente dispositivos móviles que cuenten con el sistema operativo iOS de Apple™) para poder realizar las siguientes actividades: !

๏ “Check In” al momento de llegar al restaurante; como lo hace actualmente la red social Foursquare™ (geolocalización).

๏ Asignación de mesa (lectura de códigos QR). ๏ Ordenar los productos que ofrece el restaurante directamente al personal de cocina y/o bar. ๏ “Check Out” al momento de solicitar la cuenta. !

Debido a que los clientes serán los que lleven a cabo las actividades anteriores, esto permitirá que el proceso de atención que los restaurantes tienen con sus clientes sea mucho más sencillo, eficiente y mucho mas rápido (con respecto al tiempo que actualmente tardan realizar dichas actividades), ademas del hecho de requerir menos personal (comparado con el personal requerido de forma tradicional). !Finalmente, el personal de la cocina y/o bar, podrán recibir las órdenes en tiempo record (tiempo real); es decir, en cuanto los clientes ordenen algún producto, el personal de cocina y/o bar podrán visualizarlo de forma inmediata para poder atenderlo, logrando con esto, una reducción de tiempo considerable. Además, el personal de la cocina y/o bar, podrá distinguir entre los productos que ya han atendido de todos aquellos que aun les hace falta por atender.

!

!



!

Abstract

Today, many restaurants have entered the acquisition of specialized infrastructure to provide faster, more efficient and better customer service and solve many problems that are present with respect to the care provided to the client. !Due to the above, the purpose of this platform is to improve the interaction that currently have restaurants with their customers, making this interaction more quickly and efficiently, using technology that offer the latest generation of mobile devices and based on the structure and functionality of some social networks used today. !The restaurants that subscribe to the platform, can create a new profile that will allow them to manage all the information related to that restaurant (menus, items, locations, etc.) and allow this information to be accessed by visitors (potential customers). The use of profiles for managing restaurants subscribed to the platform aims to show their services to customers, in asimilar way to they do some social networks (such as Facebook ™, Twitter ™, Instagram ™, etc.) perform profile management of its members; thus achieving a more clean and efficient administration. !Once created profiles restaurants subscribed to the platform, visitors can browse through each of these sections and know what each restaurant offers (menus, items, locations, etc.). Navigation through the profiles of the restaurants will be conducted by accessing the platform from any mobile device or computer equipment that has a Web browser and a connection to a data network (WiFi, Ethernet, 3G, etc.) with Internet access. The design considered for this section of the platform (designed and structured as a Web application), allows visitors can visualize profiles from anywhere at any time, just by accessing the platform from their mobile device or computer equipment. !!!!



Customers come to any of the restaurants (subscribed to the platform) can enjoy one of the great benefits offered by platform: time saving. The way in which customers can save time, be using their own mobile devices (specifically Apple™ mobile devices with iOS operating system) to perform the following activities: !

๏ "Check In" upon arrival at the restaurant, as it currently does social network Foursquare ™ (geolocation).

๏ Allocation table (QR codes reader). ๏ Sort products offered directly to the restaurant kitchen staff and/or bar staff. ๏ "Check Out" when you apply for the account. !

Because customers will be carrying out the above activities, allow the attention process that restaurants have with their customers much easier, efficient and much faster (relative to the time it currently takes to perform these activities), Besides the fact of requiring less staff (compared with staff required in a traditional way). !Finally, the kitchen staff and/or bar staff, can receive orders in record time (real time), ie, when customers ordered a product, staff can visualize the product immediately for release of the product, achieving this reduction time. Also, the staff in the kitchen and/or bar, can distinguish between products that have already taken care of all those still they need to dispatch.

!

!

!



!

Objetivos

Objetivo General Desarrollar una plataforma capaz de hacer más eficiente la interacción de los restaurantes con sus clientes a través del uso de la tecnología disponible para los dispositivos móviles de última generación, tomando como base las características fundamentales de las redes sociales (centrado en los usuarios, sus interacciones y contenidos, acceso global, etc.) de gran popularidad hoy en día. !!!Objetivos Específicos

๏ Diseñar y desarrollar una aplicación Web en la nube que permita: !• Administrar la información de los restaurantes con deseo de montarse a dicha

plataforma utilizando el concepto de perfiles (Módulo Perfil).

• Consultar la información de todos los restaurantes suscritos a la plataforma desde cualquier lugar y cualquier dispositivo con capacidades de navegación web (Módulo Navegación). !

๏ Diseñar y desarrollar una aplicación nativa para dispositivos móviles iOS (iPhone, iPad, iPod), que sea capaz de identificar el restaurante en el que se encuentra físicamente el cliente, mostrar el menú correspondiente a dicho restaurante y permitir la creación de una orden desde su mesa, sin la necesidad de esperar y/o recurrir a un mesero que lo haga (Módulo Comanda). !

๏ Recibir y atender las órdenes generadas por los clientes en tiempo real (Módulo Receptor de órdenes).

!



!

Capítulo 1: Antecedentes y Planteamiento del Problema

1.1 Introducción Hoy en día, existe una gran diversidad de soluciones que ofrecen mejorar los procesos que se llevan a cabo en todas las áreas de un restaurante; sin embargo solo se enfocan específicamente al restaurante, dejando de lado que el cliente puede jugar un papel de suma importancia en la mejora de dichos procesos. !Aunado a lo anterior, algunas de las soluciones existentes en el mercado requieren de la adquisición equipo de computo adicional (PDA, servidores de almacenamiento, etc.) lo que conduce a un gasto fuerte en infraestructura, capacitación al personal y mantenimiento, pudiendo resultar; para el caso de restaurantes pequeños o medianos; más un costo innecesario que un beneficio. !La plataforma propuesta en este documento, no solo pretende mejorar los procesos que se llevan a cabo en los restaurantes, sino también pretende cambiar uno de los puntos mas importantes en la relación restaurante-cliente: la interacción constante existente entre ellos. Debido a lo anterior, dicha plataforma propuesta está enfocada en cambiar el proceso dicha interacción entre los clientes con el personal de los restaurantes haciendo uso de tecnologías de última generación; como las ofrecidas por los dispositivos móviles, así como algunas de las características que ofrecen las redes sociales en la actualidad (como Facebook™, Twitter™, Instagram™, etc.). !Otro de los beneficios que ofrece la plataforma descrita es precisamente el hecho que no se requiere de equipo de cómputo adicional para montar dicha plataforma, ya que como se detallará en las secciones posteriores, se montará en la nube; es decir, no se encontrará en un equipo o servidor físico que necesite alojarse en el restaurante. !!



1.2 Justificación Actualmente en la mayoría de los restaurantes se cuenta con personal capacitado para atender y servir a los clientes; mejor conocidos como meseros. Los meseros son los encargados de asignar mesas, levantar órdenes de cada una de las mesas, llevar a las mesas los alimentos y/o bebidas que les fueron solicitados, así como elaborar y cobrar la cuenta final como parte de los servicios que se ofrecen al cliente. !Uno de los servicios con mayor peso; tanto para los meseros como para los restaurantes, es precisamente la forma de levantar las órdenes de los clientes. La forma tradicional para levantar las órdenes; aplicada en la mayoría de los restaurantes, es utilizar una especie de libreta en donde se anotan cada uno de los alimentos y/o bebidas previamente seleccionados por los clientes; en base a un menú predefinido y establecido por el restaurante; que posteriormente son turnadas a la cocina ó bar (según sea el caso) para su elaboración y finalmente, despachadas a los clientes. Existen algunos restaurantes; en especial aquellos que pertenecen a un cadena ó grupo de restaurantes con gran presencia, en donde las órdenes se levantan sustituyendo la libreta por un dispositivo portátil (en su gran mayoría utilizando un PDA) que son transmitidas y visualizadas en la cocina en tiempo real; lo anterior gracias a una infraestructura especializada previamente diseñada, construida y montada (a la medida) en los restaurantes, reduciendo considerablemente el tiempo para atender, elaborar y despechar dichas órdenes. !A pesar de que hoy en día muchos restaurantes han incursionado en la adquisición de una infraestructura especializada para brindar un servicio más rápido, eficiente y de mejor calidad al cliente, aún se presentan problemas en común con aquellos restaurantes que no cuentan con ésta tecnología, aunado a nuevos problemas e inconvenientes generados a raíz de la implementación de dicha infraestructura. !Los problemas de mayor relevancia que afectan de manera considerable la atención hacia el cliente por parte de los restaurantes y el personal que laboran en él son: !

๏ La falta de personal aumenta de manera significativa los tiempos de respuesta de tres actividades: comenzar a atender a los clientes (asignar las mesas, colocar los utensilios necesarios para los comensales, mostrar los menús, etc.), levantar la órdenes y despachar los alimentos y/o bebidas levantadas en las órdenes. !!



๏ La poca eficiencia y atención de los meseros al momento de tomar de las órdenes hacia los clientes lo cual repercute en despachar alimentos y/o bebidas equivocadas trayendo como consecuencia pérdidas económicas, de tiempo y afluencia de clientes potenciales. !

๏ Los restaurantes que desean incursionar en la mejora en la atención hacia los clientes implementando tecnologías presentes en otros restaurantes, necesitan adquirir todo el equipo, dispositivos y servicios necesarios (PDA, servidores de almacenamiento, etc.) lo que conduce a un gasto fuerte en infraestructura, capacitación al personal y mantenimiento, pudiendo resultar; para el caso de restaurantes pequeños o medianos; más un costo que un beneficio. !

๏ Si una cadena o grupo de restaurantes desea hacer uso de las tecnologías existentes, cada sucursal debe contar con su propia infraestructura debido a que el costo para poder enlazar todas las sucursales requiere equipo adicional y servicios brindados por una compañía de comunicaciones, lo que repercute en un gasto mucho mayor. !

Muchos de los problemas anteriores se solucionan de una manera radical utilizando la tecnología de última generación, incluso brinda muchas ventajas en comparación al sistema tradicional. A continuación se muestran las ventajas de contar con alguna plataforma como la descrita en es este documento: !

๏ Menos tiempo de espera para poder ser atendido por un mesero. !๏ No se requiere de tanto personal para atender a los clientes. !๏ No es necesario presentarles menús impresos de los platillos y/o bebidas que se ofrecen. !๏ No es necesario realizar una inversión en hardware y software para implementar dicha

plataforma, ya que gracias a la tecnología se puede hacer uso de la solución sin tener un equipo físico (en la nube). !!!!!



1.3 Antecedentes A continuación se muestran algunas de las soluciones existentes en el mercado, y como se explicó al inicio de esta sección, están enfocadas en mejorar los procesos en todas las áreas de un restaurante: !!eMenu La empresa “Conceptic: Interactive Menus” (establecida en Estados Unidos) ofrece una solución llamada “eMenu” en donde se muestra un menú interactivo utilizando imágenes de los platillos que se ofrecen en los restaurantes suscritos a dicha solución. La visualización de los diferentes menús se hace a través de un dispositivo móvil integrante de la familia Apple (iPad).

!!CENTRAL ® para iMenu v100 SoftLanding Systems es una empresa (establecida en Estados Unidos) que ofrece una solución de un menú interactivo que permite:

๏ Dedicar menos tiempo a la gestión de los usuarios opciones de menú y de las autoridades. ๏ Transferir tareas del menú para personal no técnico con confianza. ๏ Controlar el acceso a las opciones sensibles. ๏ Trabajar activamente con los usuarios conectados desde la pantalla de administrador. ๏ Estandarizar la gestión de todos los menús, incluyendo aplicaciones empaquetadas. ๏ Administre fácilmente complejos montajes que involucran múltiples sistemas, divisiones o

ubicaciones. ๏ Centralizar o descentralizar la administración menú, según sea necesario. ๏ Crear menús personalizados por el usuario. ๏ Definir "Grupo de Trabajo" opciones. ๏ Defina sus propias teclas de comando. ๏ Hacer que los cambios estén disponibles para los usuarios inmediatamente.

!!!!!!!



1.4 Planteamiento del Problema !Debido a los problemas existentes en la atención que reciben los clientes por parte de los restaurantes (descritos al inicio de ésta sección), se requiere de una plataforma capaz de mejorar; de manera significativa, la atención que los restaurantes brindan hacia los clientes y cambiar de forma radical la interacción entre los clientes y los restaurantes. Dicha plataforma debe presentar las siguientes características: !

๏ Los restaurantes que deseen suscribirse a la plataforma, puedan subir toda la información relacionada al tipo de comida y/o bebidas que ofrecen, como lo son: menús, imágenes de los platillos, precios, descripción, ubicación de mesas, horario de servicio, etc. y puedan agregar nueva información y consultar, modificar o eliminar información existente. !

๏ Los clientes podrán visualizar toda la información de los restaurantes (nombre, tipo de comida que ofrece, menú, ubicación, etc.) desde un dispositivo móvil en cualquier lugar y a cualquier hora utilizando la red la datos del dispositivo (red 2G, 3G, Wi-Fi, etc.). !

๏ Los clientes puedan visualizar la información del restaurante (menú, platillos, precios, etc.) al momento de ingresar al mismo utilizando su propio dispositivo móvil. !

๏ La información requerida en la plataforma debe ser de fácil acceso desde cualquier parte. !!!!!!!!!!!!!



1.5 Solución Propuesta La plataforma que se propone pretende ser una herramienta interactiva que cambie de manera radical la interacción entre un restaurante y sus clientes, y convierta la experiencia de acudir a consumir alimentos y/o bebidas a un restaurante, en un hecho único y placentero y logre que los clientes regresen a vivir de nuevo con mayor frecuencia y recomienden dicha experiencia. !Para entender el funcionamiento de la plataforma que se propone, en primera instancia de describirá cada una de las partes que lo integran (Módulo Perfil, Módulo Navegación, Módulo Comanda, Módulo Receptor de Órdenes) y finalmente se explicará de forma clara y concisa la interacción de cada una de ellas con el resto, detallando el funcionamiento de la plataforma como un todo.

Figura 1-1. Diagrama de Bloques General de la Plataforma de Menú en la Nube. !!!!!!


Plataforma de Menú en la Nube

Módulo Comanda

Módulo Perfil

Módulo ComandaMódulo Perfil

Módulo Navegación

Googlehttp://domain.com

Web Page Title

Módulo Navegación


Módulo Navegación


Web Page Title

Módulo Receptor de Órdenes


Módulo Navegación


Web Page Title


Módulo Perfil El Módulo Perfil tendrá como objetivo administrar la información descriptiva de cada uno de los restaurantes suscritos a la plataforma (detallada en este documento) a través del concepto de perfiles (utilizado por la mayoría de las redes sociales; por ejemplo: Facebook™, Twitter™ e Instagram™), es decir, cada restaurante tendrá un espacio dedicado a él (concepto de perfil) en donde; a través de la inclusión de descripciones escritas y/o imágenes a dicho espacio, podrá detallar toda la información que desee que los clientes conozcan de él. !En base a la clasificación de la información que cada restaurante pude incluir, el perfil estará dividido en las siguientes secciones: !

1. Información descriptiva: En esta sección, se podrá incluir la información de cada restaurante, como el horario de servicio, descripción, historia, etc. También se podrán agregar imágenes del restaurante que permitirá ampliar la descripción de manera visual.

2. Sucursales: Para que los clientes de cualquier sucursal puedan acudir a dicha sucursal es importante conocer la ubicación geográfica de la sucursal lo mas exacta y detalladamente posible; esto ya que le permitirá al cliente llegar al establecimiento sin ningún problema y de una manera fácil y rápida. Debido a lo anterior, en esta sección se podrá incluir la dirección de las sucursales del restaurante de manera textual y utilizando mapas geográficos de ubicación (como Google Maps™, Guia Roji™, etc.).

3. Menús: Esta sección es la columna vertebral de cada perfil debido a que entre mas detallado, descriptivo y atractivo sean los menús es como se podrán adquirir mas clientes. Para cada uno de los productos que se plasmen en el menú, se podrá incluir el nombre del producto (para el caso de la plataforma en estudio, serán platillos y/o bebidas), una descripción, fotografías, disponibilidad (debido a que no todos los platillos están disponibles a cualquier hora del día) y su precio.

4. Mesas: En esta sección se podrán incluir la información de las mesas pertenecientes a una sucursal como el nombre de la mesa, capacidad (no. de personas que pueden sentarse en dicha mesa) y un código QR el cual será utilizado por los clientes. !

Las operaciones que cada restaurante podrá realizar como parte de la administración de su perfil son las operaciones básicas: consultar, agregar, modificar y eliminar información y/o imágenes (en las secciones donde se cuente con imágenes) en cada una de las secciones que integran al perfil. !!



Módulo Navegación En el módulo “Navegación” los clientes podrán consultar cada uno de los perfiles de los restaurantes suscritos a la plataforma propuesta para conocer a detalle la los productos que cada uno de ellos ofrece. La información que podrá consultarse será la que el restaurante incluya al momento de crear su perfil. !La forma en como cada cliente podrá visualizar la información incluida en cada perfil, se llevará a cabo de manera similar a como se realiza una consulta de un perfil en Facebook™; es decir, se podrá navegar a través de las diferentes secciones para conocer los menús, la ubicación geográfica, la distribución de las mesas, etc. !Es de vital importancia mencionar que los módulos descritos hasta el momento (Módulo Perfil y Módulo Navegación) y serán parte de una aplicación Web a través de la cual se podrá consultar cada uno de los perfiles desde cualquier sitio utilizando un equipo de cómputo o dispositivo móvil que cuente con acceso a internet y/o acceso a una red Wi-Fi y no se necesite de hardware o software específico para poder alojar dicha aplicación Web.

!!Módulo Comanda El Módulo Comanda será un conjunto de tecnologías (web, geolocalización, cámara fotográfica); plasmadas en una aplicación nativa para dispositivos móviles, que optimizará los procesos tradicionales involucrados al momento de acudir a un restaurante para consumir algún platillo y/o bebida: recepción en Lobby, asignación de mesa, presentación de menú(s), levantar la orden, despachar la orden, otorgar cuenta (procesos atendidos en la mayoría de los restaurantes por los meseros). !Para entender de manera clara y concisa el funcionamiento de la aplicación (aplicación propuesta en esta sección), es necesario dividir dicha funcionalidad en base a cada uno de los procesos involucrados mencionados en párrafo anterior y la interacción que el cliente tendrá con dichos procesos. A continuación se describen los procesos y la funcionalidad de la aplicación en cada uno de ellos: !Recepción en el Lobby

La recepción por parte del personal del restaurante en el área del Lobby es el primer proceso, en donde el cliente tendrá una interacción con la aplicación (aplicación propuesta en esta sección). !



En este proceso, la aplicación tendrá la capacidad de identificar en que restaurante (de todos los suscritos a la plataforma aquí propuesta) se encuentra el cliente y poder mostrarle la información (distribución de mesas, número de mesas, menús, etc.) de dicho restaurante. La forma en como la aplicación realizará lo anterior, es haciendo uso del concepto “check in” (de forma similar a como se realiza en la red social Foursquare™); es decir, la aplicación obtendrá; en primera instancia, la ubicación geográfica del cliente a través del GPS integrado en el dispositivo móvil de última generación (utilizado por el cliente) en conjunto con la ejecución de algún algoritmo de geolocalización, y posteriormente comparará la ubicación geográfica obtenida con las ubicaciones geográficas de cada uno de los restaurantes (previamente registrados en la plataforma) hasta encontrar al restaurante que coincida con la ubicación geográfica del cliente y es en ese momento será cuando la aplicación muestre toda la información del restaurante. !Asignación de Mesa

Cada mesa contará con un código de identificación, por ejemplo un código QR (código de respuesta rápida), que permitirá identificar cada una de las mesas y podrá ser asignada a los clientes de una manera ágil y sencilla. !El restaurante podrá asignar la mesa a los clientes de dos formas distintas:

1. El restaurante (personal encargado de la asignación de mesas) le proporcionará al cliente el código QR de la mesa que se le asignará en base a la disponibilidad.

2. El personal encargado de la asignación de mesas, acompañará al cliente a la mesa que se le asignará en base a la disponibilidad y en donde estará el código QR de dicha mesa. !

Sin importar cual de las dos opciones decida utilizar el restaurante, la aplicación será capaz de leer el código QR de la mesa; haciendo uso la cámara del dispositivo móvil (operado por el cliente), y avisarle a la cocina y/o bar, la mesa en la que el cliente se encuentra, con la finalidad de tener presente la ubicación del cliente (mesa asignada) para poder despacharle los platillos y/o bebidas que ordene posteriormente. Y es en este momento será cuando la aplicación genere la orden (comanda). !Presentación de Menús, levantar y despachar la orden

La aplicación mostrará el o los menús disponibles para el restaurante; donde se encuentre el cliente; para que éste último (cliente) pueda observarlos y elija cual de ellos desea ordenar. !El cliente seleccionará los platillos y/o bebidas de su elección y elegirá si desea eliminar o agregar algún ingrediente al platillo y/o bebida. Una vez terminada su selección, la aplicación enviará la orden a la cocina y/o bar; según sea el caso, para que sea despachada lo mas rápido posible.



La aplicación le permitirá al cliente seleccionar si desea algo extra para su orden, como algún aderezo, algún platillo extra o algún objeto (plato, vaso, cubierto, etc.) y enviarla al personal para que pueda despacharlo. !Otorgar cuenta

La aplicación será capaz de proporcionarle la cuenta al cliente en el momento en el que él así lo decida. Una vez que el cliente así lo solicite, la aplicación enviará la señal al personal encargado, que la orden de la mesa en donde se encuentra el cliente llegó a su fin. !Finalmente, el encargado acudirá a la mesa del cliente y procederá a cobrarle la cantidad establecida en la orden. !Cabe mencionar que la aplicación descrita en esta sección, será una aplicación nativa; es decir; será una aplicación desarrollada exclusivamente para dispositivos IOS (iPhone, iPad, iPhone) y requerirá ser instalada en cada uno de los dispositivos que serán utilizados por los clientes al momento de acudir a una de las sucursales de los restaurantes suscritos a la plataforma. !!Módulo Receptor de Órdenes El Módulo Receptor de Órdenes será el encargado de recibir todas las órdenes que se generen en el restaurante y mostrará; al personal encargado de la cocina y/o bar, los alimentos y/o bebidas que tendrán que elaborar y preparar, especificadas en las nuevas órdenes. !!!Funcionamiento Todo el flujo comenzará en el momento en que los restaurantes se suscriban la plataforma; a través de la aplicación Web en la nube, en donde podrán ingresar toda la información e imágenes que crea conveniente para crear y configurar su perfil. !!!!



Cuando la plataforma cuente con algunos restaurantes suscritos, los clientes podrán acceder a la aplicación Web en la nube (Módulo Navegación) y navegar en los perfiles de los restaurantes suscritos para observar la tanto la información general del restaurante (horario, ubicación, tipo de comida, etc.) como las imágenes y descripciones de los mismos (menús, mapa de ubicación, instalaciones, etc.) para finalmente, los clientes tomen una decisión sobre el restaurante que visitarán. !Al momento de la llegada del cliente al restaurante, el restaurante deberá verificará que el cliente cuente con un dispositivo móvil IOS (iPhone, iPad o iPod) y cuente con la aplicación móvil (Módulo Comanda) previamente instalado en su dispositivo móvil. En caso que el cliente no cuente con la aplicación previamente instalada, el restaurante le proporcionará la información necesaria y detallada para que puede instalar dicha aplicación en su dispositivo, y en dado caso que el cliente no cuente con un dispositivo móvil IOS, el restaurante le proporcionará uno; con la aplicación previamente instalada (esto es opcional y depende de cada uno de los restaurantes), durante el tiempo que dure su estancia en el restaurante. !Después de cerciorarse que el cliente ya pueda hacer uso de la aplicación (dependiendo los casos descritos en el párrafo anterior), el cliente realizará un “check in” dentro del restaurante; es decir, le indicará aplicación móvil; que ya se encuentra dentro de las instalaciones del restaurante. Posteriormente, aplicación móvil obtendrá la ubicación geográfica del cliente; utilizando el GPS del dispositivo móvil en donde se encuentra alojada dicha aplicación, en conjunto con la ejecución de algún algoritmo de geolocalización, y la comparará con la ubicación geográfica de cada uno de los restaurantes que se encuentren suscritos a la plataforma hasta obtener el restaurante en donde se encuentra el cliente y finalmente, se le mostrará al cliente toda la información necesaria del restaurante. Una vez mostrada la información del restaurante, el cliente llegará a la mesa de su elección (dependiendo la disponibilidad de las mesas), leerá el código QR de la mesa que eligió y seleccionará los alimentos o bebidas que desea ordenar y la cantidad de cada uno de ellos. !Finalmente, la aplicación móvil recopilará toda la información proporcionada por el cliente (código de la mesa, alimentos y o bebidas, cantidad, etc.) y la enviará al Módulo Receptor de Órdenes (localizado por lo general, en la cocina del restaurante) con la finalidad de indicarle al restaurante la mesa en donde se encuentra el cliente y poder procesar, atender y despachar su orden a la brevedad. !!!!



Es importante mencionar que los restaurantes si contarán con meseros; sin embargo, dichos meseros solo realizarán las siguientes actividades:

๏ Verificar si el cliente cuenta con un dispositivo móvil IOS y la aplicación móvil instalada. ๏ Llevar los alimentos y/o bebidas a los clientes. ๏ Cobrar el total de la orden a los clientes. !

También es de vital importancia mencionar que la plataforma no incluirá un sistema de pago electrónico, por lo que el pago de la orden se llevará a cabo de la forma tradicional como se llevaba en el restaurante antes de la implementación de dicha plataforma.

Figura 1-2. Diagrama de Bloques Detallado de la Plataforma de Menú en la Nube.

!




Módulo Comanda

Leer Código QR

"Check In"

Asignación de Mesa

Ordenar Items

"Check Out"


Recibir Órdenes

Despachar Órdenes

Cerrar Órdenes


Módulo Navegación


Web Page Title

Módulo Perfil

Administrar Perfil

Administrar Restaurante


Módulo Navegación


Web Page Title

Módulo Navegación

Administrar Perfil

Administrar Restaurante


Módulo Navegación


Web Page Title

La Nube

!

Capítulo 2: Marco Teórico

2.1 Ruby on Rails Ruby on Rails (ó RoR) es un framework para el desarrollo de aplicaciones Web de código abierto escrito en el lenguaje de programación Ruby. Está basado en el patrón de diseño Modelo-Vista-Controlador (MVC – Model View Controller). !RoR está basado en estos principios de desarrollo:

๏ DRY - Don’t Repeat Yourself. ๏ Convention Over Configuration. !

El primer principio, DRY, significa “No te repitas”: Esto viene del hecho de que RoR es un framework de pila completa; los componentes están integrados de manera que no hace falta establecer puentes entre ellos. RoR puede averiguarlos a partir de la propia base de datos (de forma que definirlos tanto en el código como en el programa sería redundante) y manipular los registros de una tabla como un objeto y a sus campos como un atributo, sin necesidad de declarar nada. !El segundo principio “Convención sobre Configuración”: significa que el programador sólo necesita definir aquella configuración que no es convencional.

Figura 2-1. Logotipo de Ruby on Rails. !!!!



2.2 iOS SDK iOS es el sistema operativo móvil más avanzado del mundo, continuamente redefiniendo lo que la gente puede hacer con un dispositivo móvil. Juntos, el SDK de iOS y Xcode IDE que sea fácil para los desarrolladores crear aplicaciones móviles revolucionarias. !Derivado de tecnologías básicas en OS X, la increíble experiencia de usuario de iOS se ha simplificado para aprovechar al máximo el iPhone, iPad, y el hardware del iPod touch.Tecnologías compartidas entre iOS y OS X incluyen el kernel de OS X, sockets BSD para la creación de redes, y Objective-C y compiladores de C de C + para obtener un rendimiento nativo.

Figura 2-2. Logotipo de iOS SDK. !!!2.3 Heruku Heroku es un servicio en la nube del tipo PaaS (Platform as a Service) multi lenguaje (Ruby, Java, PHP, Scala, Clojure, JavaScript (node.js) y Phyton) montado sobre la infraestructura de Amazon Web Services en donde los clientes no tienen que contar con infraestructura, el tiempo de procesamiento y almacenamiento se le rentan a un tercero.

Figura 2-3. Logotipo de Heroku.

!!!!!



2.4 AFNetworking AFNetworking es una librería para la gestión de tareas de neworking para iOS y OS X que funciona a modo de envoltorio de las librerías del Foundation URL Loading System. Cuando hablamos de Foundation URL Loading System estamos hablando de NSURLConnection y de NSURLSession.

!NSURLConnection y NSURLSession se utilizan en realidad para englobar a un conjunto mayor de clases relacionadas con el networking. Así, por ejemplo, la antigua NSURLConnection en realidad hace referencia al siguiente conjunto de clases: NSURLRequest, NSURLResponse, NSURLCache, NSURLProtocol, NSHTTPCookieStorage, NSURLCredentialStorage y a la propia NSURLConnection. Y además, habría que tener en cuenta protocolos aledaños como NSURLConnectionDelegate o NSURLConnectionDataDelegate.

!Por su parte NSURLSession hace referencia al mismo conjunto de clases sustituyendo NSURLConnection por NSURLSession y añade NSURLSessionConfiguration y las tres subclases de N S U R L S e s s i o n T a s k : N S U R L S e s s i o n D a t a T a s k , N S U R L S e s s i o n U p l o a d T a s k y NSURLSessionDownloadTask.

!AFNetworking funciona haciendo uso de todas estas clases y su objetivo es hacernos la vida más sencilla. A veces se limita a ofrecernos una sintaxis más clara y fácil de leer y en otras ocasiones se encarga por su cuenta de tareas muchos más tediosas como la conversión de datos JSON, XML, PLIST, la gestión del estado de las solicitudes y respuestas haciendo uso de bloques, monitorización de reachability para controlar la capacidad del sistema para resolver direcciones remotas tanto en redes WAN como WiFi, etc.

Figura 2-4. Logotipo de AFNetworking.

!!!!



2.5 ZBar Se trata de una utilidad multiplataforma que nos permite escanear códigos QR y de barras desde cualquier imagen o sitio web en el que estemos navegando, o también utilizando la webcam para visualizarlos. Aunque hay que decir que su funcionamiento difiere bastante de acuerdo a la plataforma en la que vayamos a utilizarlo.

!En Linux funciona desde la consola, a través de dos comandos: zbarimg y zbarcam, para utilizar una imagen o cámara respectivamente como origen de los códigos. En el caso de Windows funciona como una utilidad de interfaz bastante espartana pero que nos permite abrir un archivo de imagen o bien seleccionar la webcam. Y en iOS, la tercera plataforma soportada, es donde tal vez más cómodo lo sentiremos puesto que funciona de manera similar a como estamos acostumbrados: leyendo el código desde la cámara del iPhone. !En todo caso es una utilidad interesante que es compatible con varias plataformas y ofrece su código

fuente para poder ser incorporada en otras soluciones.

Figura 2-5. Logotipo de ZBar.

!!!!!!!!!!!!



2.6 Devise Divise es una solución de autenticación flexible para Rails basadas en Warden : 1

๏ Es una solución completa MVC basado en motores de Rails. ๏ Le permite tener múltiples modelos firmados en al mismo tiempo. ๏ Se basa en un concepto de modularidad: utilizar sólo lo que realmente necesita. !

Se compone de 10 módulos: ๏ Database Authenticatable: encripta y almacena una contraseña en la base de datos para

validar la autenticidad de un usuario al firmar pulg La autenticación se puede realizar tanto a través de las peticiones POST o HTTP de autenticación básica.

๏ Omniauthable:OmniAuth es una biblioteca que estandariza la autenticación multi-proveedor para las aplicaciones web; Cualquier desarrollador puede crear estrategias para OmniAuth que pueden autenticar usuarios a través de sistemas dispares. Estrategias OmniAuth se han creado para todo, desde Facebook a LDAP.

๏ Confirmable: envía mensajes de correo electrónico con instrucciones para confirmar y verificar si una cuenta está ya confirmado durante signo pulg.

๏ Recoverable: restablece la contraseña del usuario y envía las instrucciones de restablecimiento.

๏ Registerable: maneja la firma usuarios a través de un proceso de registro, que también les permite editar y destruyen su cuenta.

๏ Rememberable: gestiona la generación y la limpieza de un token para recordar al usuario de una cookie guardada.

๏ Trackable: pistas firman en el recuento, marcas de tiempo y la dirección IP. ๏ Timeoutable: expira sesiones que no tienen actividad en un período determinado de tiempo. ๏ Validatable: ofrece validaciones de correo electrónico y contraseña. Es opcional y puede ser

personalizado, por lo que estamos en condiciones de definir sus propias validaciones. ๏ Lockable: bloquea una cuenta después de un número determinado de intentos de inicio de

sesión fallidos. Puede desbloquear a través de correo electrónico o después de un período de tiempo especificado.

Figura 2-6. Logotipo de Devise.



! Administra entornos aislados, efímeros, y de recursos controlados.1

2.7 Fórmula Haversine La fórmula Haversine es una importante ecuación para la navegación astronómica, en cuanto al cálculo distancia de círculo máximo entre dos puntos de un globo sabiendo sus longitud y latitud. Es un caso especial de una fórmula más general de trigonometría esférica, la ley de los semiversenos , que relaciona los lados y los ángulos de "triángulos esféricos”. !Estos nombres se derivan del hecho de que suele expresarse en términos de la función haversine, dada por haversin (θ) = sen 2 (θ/2). Las fórmulas también podrían estar escritas en términos de cualquier múltiple del haversine, como la antigua función verseno (el doble del haversine).

Para cualquier par de puntos sobre una esfera:

donde:

haversin es la función haversine, haversin ( θ ) = sen 2 ( θ /2) = (1-cos ( θ ))/2

d es la distancia entre los dos puntos (a lo largo de un círculo máximo de la esfera, véase distancia esférica),

R es el radio de la esfera,

φ 1 es la latitud del punto 1,

φ 2 es la latitud del punto 2, y

Δ λ es la diferencia de longitud

Figura 2-7. Triángulo esférico solucionado por la ley de haversine. !Tenga en cuenta que el argumento a la función haversine Aquí se supone que debe darse en radián s. !!



2.8 Google Maps SDK Google Maps es un servicio de Google que ofrece imágenes vía satélite de todo el planeta, combinadas, en el caso de algunos países, con mapas de sus ciudades, lo que unido a sus posibilidades de programación abierta ha dado lugar a diversas utilidades ofrecidas desde numerosas páginas web. !Varios aspectos de Google Maps son los responsables de su facilidad de uso por cualquier usuario: el sistema de deslizamiento de imagen, acoplado a la carga dinámica de nuevas imágenes; la adaptación del mapa al tamaño de ventana del navegador; la interfaz minimalista; la posibilidad de cambiar de tipo de mapa en un clic. Como todas las demás aplicaciones Google, Maps descansa poderosamente sobre la utilización de JavaScript. La carga y el deslizamiento de imagen no podrían efectuarse sin este código. !Según el nivel de zoom, un mapa podría descomponerse en varias decenas de miles de cuadrados. Esta descomposición se realiza automáticamente por un script del lado servidor. Cuando el utilizador hace deslizar la imagen en un sentido, JavaScript calcula cuales son los cuadrados involucrados, envía al servidor una pregunta sobre las imágenes en cuestión, y las coloca alineadas junto a las otras. !Cada cuadrado es almacenado en un fichero cuyo nombre indica su longitud, su latitud, y el valor del zoom. Recuperar estas informaciones para todos los cuadrados a colocar,no es sino una cuestión de derivación de los datos conocidos para un solo cuadrado. !Todo ello necesita, por tanto, una sincronización perfecta entre lo que puede preguntar el código JavaScript, y lo que está efectivamente disponible en el servidor. El programa de recorte inicial de la imagen completa es por tanto extremadamente importante, porque es el responsable, para la precisión del corte y el rigor de su etiquetamiento, del buen desenvolvimiento de los acontecimientos desencadenados por las acciones del usuario. !Google Maps provee a los desarrolladores un API capaz de aprovechar los datos disponibles a través del servicio, en el seno de las propias aplicaciones. Y más interesante para el funcionamiento mismo del servicio, Google da acceso a AjaXSLT, un proyecto Open Source que propone una biblioteca JavaScript.

Figura 2-8. Logotipo de Google Maps.



2.9 PostgreSQL PostgreSQL es un potente sistema de base de datos, de código abierto objeto-relacional. Cuenta con más de 15 años de desarrollo activo y una arquitectura probada que se ha ganado una sólida reputación de fiabilidad, integridad de datos y la corrección. Funciona en todos los principales sistemas operativos, incluyendo Linux, UNIX (AIX, BSD, HP- UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows. Es totalmente compatible con ACID, tiene soporte completo para claves foráneas, uniones, vistas, disparadores y procedimientos almacenados (en varios idiomas). Incluye más de SQL : 2008 tipos de datos, incluyendo INTEGER, numéricos, booleanos, CHAR, VARCHAR, DATE, INTERVAL , y TIMESTAMP. También es compatible con el almacenamiento de grandes objetos binarios, como imágenes, sonidos o vídeo. Cuenta con interfaces de programación nativas para C / C + +, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, entre otros, y la documentación excepcional. !Una base de datos de clase empresarial, PostgreSQL cuenta con características avanzadas tales como multi Version y Control de concurrencia (MVCC), punto en el tiempo de recuperación, tablespaces, replicación asincrónica, transacciones anidadas (puntos de retorno), en línea de copias de seguridad/calor, un sofisticado planificador/optimizador de consulta. Es compatible con los juegos de caracteres internacionales, codificaciones de caracteres multibyte, Unicode , y es consciente de la configuración regional de la clasificación, mayúsculas y minúsculas, y el formato. Es altamente escalable tanto en la enorme cantidad de datos que puede manejar y en el número de usuarios concurrentes que puede acomodar. Hay sistemas de PostgreSQL activos en entornos de producción que manejan más de 4 terabytes de datos. !PostgreSQL ha ganado los elogios de sus usuarios y el reconocimiento del sector, entre ellos el Premio de Nuevos Medios de Linux para mejor sistema de base de datos y cinco veces ganador del Premio de los Editores de Linux Journal al mejor DBMS.

Figura 2-9. Logotipo de PostgreSQL. !!!!



2.10 Faye Faye es un sistema de publicación-suscripción de mensajería basado en el protocolo Bayeux. Proporciona los servidores de mensajes para Node.js y Ruby, y clientes para su uso en el servidor y en los principales navegadores web. !Todos los clientes Faye necesitan un servidor de mensajería para comunicarse con, los registros de servidor que los clientes están suscritos a qué canales y maneja el enrutamiento de mensajes entre los clientes. Faye es igual que cualquier otra aplicación en rack.

Figura 2-10. Logotipo de Faye.

!

!!

!

!



!

Capítulo 3: Arquitectura y Diseño del Sistema

3.1 Arquitectura del Sistema Debido a la problemática expuesta en secciones anteriores de este documento, se propone el desarrollo de una plataforma que mejore; en gran manera, el proceso en el cual un restaurante brinda sus servicios de atención a sus clientes potenciales a través del uso de las características que ofrecen los dispositivos móviles de última generación; como los dispositivos móviles de Apple™ (iPhone, iPad, iPod), para lograr una interacción única y placentera entre ambas partes (restaurante y clientes).

Figura 3-1. Diagrama de Bloques de la Arquitectura de la Plataforma de Menú en la Nube.




La Nube

Módulo Comanda

Módulo Perfil


Módulo Navegación


Web Page Title

Módulo Navegación


Módulo Navegación


Web Page Title



Módulo Navegación


Web Page Title

Google Maps

ZBar

AFNetworking

Base de Datos

Faye

Para entender el funcionamiento de la plataforma, es necesario describir cada uno de los componentes que lo integran y la forma de interacción que existe entre cada una de ellos, así como la interacción que tienen con algunos componentes externos utilizados para el buen funcionamiento de la plataforma. !En la Figura 3-1, se muestra la interacción entre los componentes de la plataforma, la arquitectura en la cual se basa cada uno de los componentes y la interacción que existe con componentes externos (como Google Maps™, AFNetworking™, Devise™, ZBar™ y Faye™). Desde ésta perspectiva se puede describir de manera más específica el funcionamiento de la plataforma a desarrollada. !La Plataforma de Menú en la Nube está conformada por cuatro componentes que se describen a continuación: !

๏ Módulo Perfil: Es el encargado de la administración de perfiles, restaurantes y sus elementos (menús, ítems, sucursales, mesas). !

๏ Módulo Navegación: Este componente es el encargado de mostrar a los visitantes la información de cada uno de los perfiles creados por los restaurantes; es decir, se encarga de mostrar la información del restaurante, menús que ofrecen, ítems de cada menú, sucursales, etc. !

๏ Módulo Comanda: Este componente es el encargado de realizar el “check in” del cliente, leer el código QR de la mesa que le será asignada y levantar las órdenes que dicho cliente genere. !

๏ Módulo Receptor de Órdenes: Es el módulo encargado de recibir las órdenes que los clientes han levantado. De igual manera, éste módulo se encarga de despachar dichas órdenes. !

El flujo de la plataforma comienza cuando el Administrador de Perfil; a través del Módulo Perfil, crea su perfil realizando un proceso de registro (como cualquier creación de perfil en una red social) en la plataforma, proporcionando un usuario y contraseña (los cuales ocupará en futuras ocasiones para administrar dicho perfil). Una vez creado el perfil, el Administrador de Perfiles puede agregar los menús e ítems que el restaurante ofrece, agrega la información de cada una de las sucursales con las que cuenta el restaurante (mesas, dirección, horarios, etc.) y algunas imágenes para que la información de dicho perfil sea mas atractiva y vistosa. !!



En cualquier momento, los Visitantes pueden entrar a la plataforma; a través del Módulo Navegación, y navegar a través de los diferentes perfiles (restaurantes), menús e ítems que ofrecen y sucursales con las que cuentan y conocer más respecto de cada uno de los restaurantes que; hasta ese momento; se encuentran suscritos a la plataforma. !Al momento en que un Cliente asista a cualquiera de las sucursales de los restaurantes suscritos a la plataforma, debe contar con un dispositivo móvil de Apple™ (iPhone, iPad, iPod) para poder acceder al Módulo Comanda (aplicación móvil). !En primera instancia, el Cliente debe realizar un “check in” en la sucursal donde se encuentre. Una vez realizado el “check in”, el Cliente puede realizar la lectura del código QR de la mesa que le fue asignada e ingresar el número de personas que lo acompañan. Finalmente, con la mesa asignada, el Cliente puede ordenar los ítems pertenecientes a los diferentes menús que el restaurante ofrece, generando así, una orden que posteriormente será atendida por el Personal de Cocina del restaurante. !El Personal de Cocina; a través del Módulo Receptor de Órdenes, puede visualizar todas las órdenes que; hasta ese momento, se encuentren activas, para poder despacharlas y finalmente colocarlas como órdenes atendidas. !Se pretende que la Plataforma de Menú en la Nube; como su nombre lo indica, se aloje en la Nube (Cloud) y no requiera de infraestructura física; es decir, no se requiere de un equipo de cómputo localizado en la sucursal el cual aloje a los Módulos de Perfil, Navegación y Receptor de Órdenes y la Base de Datos. Para lograr lo anterior, es necesario que cada una de las sucursales de los restaurantes cuente con una computadora personal con acceso a Internet para poder acceder a los Módulos Perfil, Navegación y Receptor de Órdenes que se encontrarán en la Nube. De igual manera, es necesario que cada uno de los Clientes que hagan uso de la plataforma; en específico del Módulo Comanda (aplicación móvil), cuenten con un dispositivo móvil de Apple™ (iPhone, iPad, iPod) y tenga una conexión de datos; ya sea a través de WiFi o a través de la red de datos móvil (3G, 4G) de cada compañía, para poder interactuar con la información almacenada en la Nube.

!!!!!!



3.2 Diseño del Sistema Ahora que se ha descrito la función e interacción de cada uno de los componentes que integran la Plataforma de Menú en la Nube, es necesario detallar el diseño de dicha plataforma. Para estandarizar el diseño de la plataforma, se ha decidido utilizar UML; en su versión 2.0, para crear diagramas que nos permitirán ver al sistema; tanto en sus aspectos estáticos o arquitectónicos como la dinámica entre sus componentes. !!!Diagrama de Casos de Uso Como se mencionó en la sección anterior, la Plataforma de Menú en la Nube está formado por cuatro módulos, los siguientes diagramas muestran las funciones principales de los mismos, así como los sistemas con los que interactúan.

Figura 3-2. Diagrama de Casos de Uso General. !En la Figura 3-2 se muestra el diagrama general de la Plataforma de Menú en la Nube, los módulos que integran a dicha plataforma y los actores que interactúan con dichos módulos.



Módulo Perfil

Figura 3-3. Diagrama de Casos de Uso del Módulo Perfil. !!El diagrama del Módulo Perfil; mostrado en la Figura 3-3, contiene los CU que se encargan de administrar la información referente a cada perfil, así como de administrar la información de cada restaurante (menús, ítems, sucursales, mesas). Es importante mencionar que cada restaurante tendrá un solo perfil, por lo que la relación entre estos será: ‘por un perfil, un restaurante’. !!!!!!!



A continuación se muestra la descripción de los CU del diagrama del Módulo Perfil: !

!Tabla 3-1. Descripción de Caso de Uso Crear Perfil. !!

!Tabla 3-2. Descripción de Caso de Uso Registrar Restaurante. !

Caso de Uso Crear Perfil.

Actores Administrador de Perfil y PaaS.

Tipo Básico.

Propósito Crear un nuevo perfil dentro de la plataforma.

Resumen El Administrador de Perfil solicita crear un nuevo perfil, ingresa su usuario y contraseña y la PaaS registra el nuevo perfil.

Precondiciones Ninguna.

Flujo1. El Administrador de Perfil solicita crear nuevo perfil. 2. El Administrador de Perfil introduce su usuario y contraseña. 3. La Paas valida la información. 4. La PaaS crea el nuevo perfil.

Postcondiciones Agregar el nuevo perfil a la Base de Datos de la plataforma.

Excepciones La red no esté disponible.

Caso de Uso Registrar Restaurante.


Tipo Inclusión.

Propósito Agregar al perfil un restaurante.

Resumen El Administrador de Perfil solicita registrar un restaurante, ingresa la información del restaurante y la PaaS agrega el nuevo restaurante al perfil.

Precondiciones Que ya exista un perfil creado.

Flujo1. El Administrador de Perfil solicita registrar un restaurante. 2. El Administrador de Perfil introduce la información del restaurante. 3. La Paas valida la información. 4. La PaaS agrega el nuevo restaurante al perfil.

Postcondiciones Agregar el nuevo restaurante al perfil.




!Tabla 3-3. Descripción de Caso de Uso Autenticarse. !

!!!!!!!!!!!!!!!!

Caso de Uso Autenticarse.


Tipo Inclusión.

Propósito Autenticarse a la plataforma para ver un perfil.

Resumen El Administrador de Perfil solicita autenticarse, ingresa usuario y contraseña, la PaaS verifica el usuario y contraseña y otorga acceso.

Precondiciones Que ya exista un perfil creado.

Flujo1. El Administrador de Perfil solicita autenticarse. 2. El Administrador de Perfil introduce usuario y contraseña. 3. La Paas valida el usuario y contraseña. 4. El PaaS permite acceso.

Postcondiciones Ninguna.




Módulo Navegación

Figura 3-4. Diagrama de Casos de Uso del Módulo Navegación. !!La Figura 3-4, muestra los CU del diagrama del Módulo Navegación que se encargan de mostrar toda la información de los restaurantes, los menús e ítems que ofrece el restaurante, así como la información de las sucursales con las que cuenta dicho restaurante (mapa de ubicación, horarios de atención, etc.). La información será consultada por los Visitantes desde un dispositivo móvil en cualquier lugar y a cualquier hora utilizando la red la datos del dispositivo (red 2G, 3G, Wi-Fi, etc.) o cualquier equipo de cómputo que cuente con acceso a internet. !!!!



!A continuación se muestra la descripción de los CU del diagrama del Módulo Navegación: !

!Tabla 3-4. Descripción de Caso de Uso Navegar Perfil. !!

!Tabla 3-5. Descripción de Caso de Uso Navegar Restaurante.

!

Caso de Uso Navegar Perfil.

Actores Visitante y PaaS.

Tipo Básico.

Propósito Navegar a través de un perfil determinado.

Resumen El Visitante selecciona el perfil que desea ver y la PaaS le muestra la información de dicho perfil.


Flujo 1. El Visitante selecciona un perfil. 2. La PaaS muestra la información del perfil seleccionado.



Caso de Uso Navegar Restaurante.

Actores Visitante y PaaS.

Tipo Inclusión.

Propósito Navegar a través de un restaurante determinado.

Resumen El Visitante selecciona el restaurante que desea ver y la PaaS le muestra la información de dicho restaurante.

Precondiciones Que exista un perfil creado.

Flujo 1. El Visitante selecciona un restaurante. 2. La PaaS muestra la información del restaurante seleccionado.





Módulo Comanda

Figura 3-5. Diagrama de Casos de Uso del Módulo Navegación. !!El diagrama de la Figura 3-5, muestra los CU del Módulo Comanda que se encargan de realizar el “check in” de un cliente en la sucursal del restaurante mas cercano a su ubicación, asignar una mesa a través de la lectura del código QR, levantar las ordenes de los ítems seleccionados y finalmente, el “check out” de dichas órdenes. Los Clientes serán los encargados de disparar cada una de las actividades descritas en los CU de éste diagrama. !!



A continuación se muestra la descripción de los CU del diagrama del Módulo Comanda: !

!Tabla 3-6. Descripción de Caso de Uso Hacer “Check In”. !!

!!Tabla 3-7. Descripción de Caso de Uso Leer Código QR de Mesa. !

Caso de Uso Hacer “Check In”

Actores Cliente y PaaS.

Tipo Básico.

Propósito Hacer “check in” en la sucursal mas cercana a la ubicación del cliente.

Resumen El Cliente selecciona “check in”, se envía su ubicación actual a la PaaS, éste responde con la sucursal mas cercana a dicha ubicación.


Flujo1. El Cliente seleciona “check in”. 2. Se envía la ubicación actual del Cliente a la PaaS. 3. La PaaS busca la sucursal mas cercana a la ubicación recibida. 4. La PaaS responde con la sucursal encontrada.





Caso de Uso Leer Código QR de Mesa.


Tipo Inclusión.

Propósito Leer el código QR de la mesa para poder asignarla.

Resumen El Cliente lee el código QR de la mesa que le será asignada y es enviado a la PaaS.

Precondiciones Que se haya realizado un “check in” previo.

Flujo1. El Cliente lee el código QR de la mesa. 2. Se procesa el código QR leido. 3. Se envía el identificador de la mesa a la PaaS.



!

!Tabla 3-8. Descripción de Caso de Uso Ordenar Ítems. !!

!Tabla 3-9. Descripción de Caso de Uso Pagar Comanda. !

!

Caso de Uso Ordenar Ítems.


Tipo Inclusión.

Propósito Agregar los Ítems que el Cliente desee a la órden.

Resumen El Cliente selecciona los ítems que desea agregar a la orden y se envía la orden; con los ítems agregados por el Cliente, a la PaaS.

Precondiciones Que se cuente con una mesa asignada.

Flujo1. El Cliente selecciona los ítems a agregar. 2. Se agregan los ítems seleccionados a la orden. 3. Se envía la orden a la PaaS.



Caso de Uso Pagar Comanda


Tipo Inclusión.

Propósito Pagar las órdenes que el Cliente ha generado.

Resumen El Cliente selecciona Pagar Comanda y se envía la petición a la PaaS.

Precondiciones Que se cuente con órdenes creadas.

Flujo1. El Cliente selecciona Pagar Comanda. 2. Se envía la petición a la PaaS. 3. La PaaS cierra las órdenes a pagar.






!Figura 3-6. Diagrama de Casos de Uso del Módulo Receptor de Órdenes. !

El diagrama de la Figura 3-6, muestra los CU del Módulo Receptor de Órdenes que se encargan de mostrar todas las órdenes que se encuentran activas y actualiza aquellas que ya fueron atendidas. !!!!!!!!!!



A continuación se muestra la descripción de los CU del diagrama del Módulo Receptor de Órdenes: !

!Tabla 3-10. Descripción de Caso de Uso Ver Orden. ! !

!Tabla 3-11. Descripción de Caso de Uso Atender Orden. ! !!

Caso de Uso Ver Orden.

Actores Personal de Cocina y PaaS.

Tipo Básico.

Propósito Ver las órdenes que se encuentren activas.

Resumen El Personal de Cocina selecciona Ver Órdenes y la PaaS muestra las órdenes.

Precondiciones Que existan órdenes creadas.

Flujo1. El Personal de Cocina selecciona Ver Órdenes. 2. Se envía la petición a la PaaS. 3. La PaaS busca las órdenes activas. 4. La PaaS responde con las órdenes encontradas.



Caso de Uso Atender Orden.


Tipo Inclusión.

Propósito Atender las órdenes que se encuentran activas

Resumen El Personal de Cocina selecciona la orden que desea atender.

Precondiciones Que se hayan buscado órdenes activas.

Flujo1. El Personal de Cocina selecciona la orden a atender. 2. Se envía la órden atender a la PaaS. 3. La PaaS actualiza el estado de la órden recibida.





!Tabla 3-12. Descripción de Caso de Uso Cerrar Orden.

!!!!!!!!!!!!!!!!!!

Caso de Uso Cerrar Orden.


Tipo Inclusión.

Propósito Cerrar las órdenes que ya se encuentren atendidas.

Resumen El Personal de Cocina selecciona la orden atendida.

Precondiciones Que se haya atendido la orden a cerrar.

Flujo1. El Personal de Cocina selecciona la orden atendida. 2. Se envía la orden atendida a la PaaS. 3. La PaaS actualiza el estado de la orden atendida.





Diagrama de Actividades Los diagramas de actividades muestran; de manera ordenada, la interacción que tiene un sistema en particular con sus subsistemas que lo conforman y/o la interacción con sistemas externos.

Módulo Perfil

!Figura 3-7. Diagrama de Actividades de Crear Perfil. !

El diagrama de la Figura 3-7 muestra las actividades que se llevan a cabo al momento de crear un perfil por el Administrador de Perfil.


Administradorde Perfil

MóduloPerfil PaaS

SeleccionarCrear Perfil

EnviarDatos

RecibirDatos

IntroducirDatos de Perfil

Preparar Perfil

EnviarPetición

RecibirPetición

CrearPerfil

EnviarRespuesta

RecibirRespuesta

ProcesarRespuesta

Mostrar mensaje de Creación de

Perfil

Notificación


Figura 3-8. Diagrama de Actividades de Crear Restaurante. !

En la Figura 3-8 se observa el diagrama de actividades para crear un restaurante, posteriormente crear un menú y finalmente crear un ítem.



MóduloPerfil PaaS

SeleccionarCrear

Restaurante

EnviarDatos

RecibirDatos

IntroducirDatos de

Restaurante

Preparar Restaurante

EnviarPetición

RecibirPetición

CrearRestaurante

EnviarRespuesta

RecibirRespuesta

ProcesarRespuesta


Perfil

Notificación

SeleccionarCrear Menú

EnviarDatos

IntroducirDatos de Menú

RecibirDatos

Preparar Menú

EnviarPetición

RecibirPetición

CrearMenú

EnviarRespuesta

RecibirRespuesta

ProcesarRespuesta


Menú

Notificación

SeleccionarCrear Item

EnviarDatos

IntroducirDatos de Item

RecibirDatos

Preparar Item

EnviarPetición

RecibirPetición

CrearItem

EnviarRespuesta

RecibirRespuesta

ProcesarRespuesta


Item

Notificación


Figura 3-9. Diagrama de Actividades de Crear Sucursal. !

En el diagrama de la Figura 3-9 se muestran las actividades que se llevan a cabo para agregar una nueva sucursal al restaurante ya creado.



MóduloPerfil PaaS Google Maps QRCode

SeleccionarCrear Sucursal

EnviarDatos

RecibirDatos

IntroducirDatos de Sucursal

Obtener Dirección

EnviarDirección

RecibirPetición

CrearRestaurante

EnviarRespuesta

RecibirRespuesta

ProcesarRespuesta


Sucursal

Notificación

SeleccionarCrear Mesa

EnviarDatos

IntroducirDatos de Mesa

RecibirDatos

Generar Id Mesa

EnviarId Mesa

RecibirPetición

CrearMesa

EnviarRespuesta

RecibirRespuesta

ProcesarRespuesta


Mesa

Notificación

RecibirUbicación

Preparar Sucursal

EnviarPetición

RecibirDirección

Obtener Ubicación

(latitud,longuitud)

EnviarUbicación

RecibirId Mesa

GenerarCódigo QR

EnviarCódigo QR

RecibirCódigo QR

Preparar Mesa

EnviarPetición


Módulo Navegación

!Figura 3-10. Diagrama de Actividades de Ver Restaurante. !

El diagrama de la Figura 3-10 muestra las actividades que se llevan a cabo al momento de navegar a través de un restaurante dentro del Módulo Navegación.


Visitante MóduloNavegación PaaS

SeleccionarVer

Restaurante

EnviarPetición

RecibirPetición

Preparar Búsqueda

EnviarBúsqueda

RecibirBúsqueda

Buscar Restaurante

EnviarRespuesta

RecibirRespuesta

ProcesarRespuesta

Mostrar Restaurante

Notificación

SeleccionarVer Menus

EnviarPetición

RecibirPetición

Preparar Búsqueda

EnviarBúsqueda

RecibirBúsqueda

Buscar Menus

EnviarRespuesta

RecibirRespuesta

ProcesarRespuesta

Mostrar MenusNotificación

SeleccionarVer Items

EnviarPetición

RecibirPetición

Preparar Búsqueda

EnviarBúsqueda

RecibirBúsqueda

Buscar Items

EnviarRespuesta

RecibirRespuesta

ProcesarRespuesta

Mostrar ItemsNotificación


Figura 3-11. Diagrama de Actividades de Ver Sucursal. !

En la Figura 3-11 se observa el diagrama de actividades para navegar a través de las sucursales con las que cuenta un restaurante. !!!


Visitante MóduloNavegación PaaS Google Maps

SeleccionarVer Sucursal

EnviarPetición

RecibirMapa

RecibirBúsqueda

Buscar Restaurante

EnviarBúsqueda

ProcesarRespuesta

Mostrar Sucursal

Notificación

RecibirPetición

Preparar Búsqueda

EnviarBúsqueda

RecibirBúsqueda

ObtenerUbicación

EnviarUbicación

Recibir Ubicación

Generar Mapa

EnviarMapa


Módulo Comanda

Figura 3-12. Diagrama de Actividades del Módulo Comanda. !El diagrama de la Figura 3-12 muestra las actividades que se llevan acabo cuando un cliente desea asistir a un restaurante para hacer un “check in”, le sea asignada una mesa y pueda ordenar los ítems que el desee a través del Módulo Comanda.


Cliente MóduloComanda AFNetworking Google Maps ZBar PaaS

Seleccionar"Check In"

EnviarPetición

RecibirPetición

Preparar Petición: Obtener

Ubicación

EnviarPetición

RecibirPetición

Generar Petición

EnviarPetición

RecibirRespuesta

ProcesarRespuesta

MostarRestaurantes

Notificación

SeleccionarRestaurante

EnviarPetición

SeleccionarLeer

Código QR

RecibirPetición

Preparar Petición: Leer

Código QR

EnviarPetición

RecibirUbicación

Preparar Petición: Obtener

Restaurantes

EnviarPetición

RecibirPetición

Obtener Ubicación

(latitud,longuitud)

EnviarUbicación

RecibirPetición

LeerCódigo QR

EnviarMensaje

RecibirPetición

Buscar Restaurantes

EnviarRespuesta

RecibirMensaje

Obtener Id Mesa del Mensaje

MostarMesa

Notificación

SeleccionarAsignar Mesa

EnviarPetición

RecibirPetición

Preparar Petición:

Asignar Mesa

EnviarPetición

RecibirPetición

Generar Petición

EnviarPetición

RecibirPetición

Asignar Mesa

EnviarRespuesta

RecibirRespuesta

ProcesarRespuesta

MostarMenus

Notificación



Figura 3-13. Diagrama de Actividades del Módulo Receptor de Órdenes. !En la Figura se observa el diagrama de actividades que el Personal de Cocina debe realizar para poder ver las órdenes activas, atenderlas y cerrar aquellas que hayan sido atendidas; dentro del Módulo Receptor de Órdenes.


Personal de Cocina

MóduloReceptor de Órdenes PaaS

SeleccionarVer Órdenes

Activas

EnviarPetición

RecibirPetición

Preparar Búsqueda

EnviarBúsqueda

RecibirBúsqueda

Buscar Órdenes

EnviarBúsqueda

RecibirBúsqueda

ProcesarRespuesta

Mostrar Órdenes Activas

Notificación

SeleccionarAtender Órden

EnviarPetición

RecibirPetición

Preparar Cerrar Órden

EnviarEjecución

RecibirEjecución

Cerrar Órden

EnviarRespuesta

RecibirRespuesta

ProcesarRespuesta

Mostrar Mensaje de

Órden Atendida

Notificación


Diagrama de Despliegue

Figura 3-14. Diagrama de Despliegue de la Plataforma de Menú en la Nube. !!A través del diagrama de la Figura 3-14 se observan los protocolos e interfaces de comunicación de los módulos que conforman la Plataforma de Menú en la Nube, así como de los sistemas externos que interactúan con dicha plataforma. !!!!!!!



Plataforma de Menú en la NubeAFNetworking

API Class

Google Maps

API Class

ZBar

API Class

<<Component>>

Módulo Navegación

<<Component>>


<<Component>>

Módulo Comanda

Request

Request

HTTP HTTPHTTP

Faye

API Class

<<Component>>

Módulo Pefil

WEB SOCKET

WEB SOCKET

Diagrama de Paquetes y Clases Los diagramas de paquetes y clases permiten tener una estática del sistema, de los componentes que lo integran y de los sistemas con los cuales tienen interacción.

Figura 3-15. Diagrama de Paquetes. !!El diagrama de paquetes de la Figura 3-15 muestra que la Plataforma de Menú en la Nube está conformado por cuatro módulos: Módulo Perfil, Módulo Navegación, Módulo Comanda y Módulo Receptor de Órdenes. !!!!!!!!!!



Las siguientes figuras, muestran los diagramas de clases de cada uno de los módulos que integran la Plataforma de Menú en la Nube:

!Figura 3-16. Diagrama de Clases del Módulo Perfil. ! !



!Figura 3-17. Diagrama de Clases del Módulo Navegación. !! !!!!!!!!!!!!



Figura 3-18. Diagrama de Clases del Módulo Comanda.

!

Figura 3-19. Diagrama de Clases del Módulo Recepto de Órdenes. !!



Diagrama de Secuencia Una vez mostradas las clases principales que conformarán a la Plataforma de Menú en la Nube, a continuación se describe la interacción entre los objetos de las clases a través de los siguientes diagramas de secuencia:

Figura 3-20. Diagrama de Secuencia de Perfiles del Módulo Perfil.


<<actor>>Administrador de Perfil

mainView:MainView

restaurantController:RestaurantController

menuController:MenuController

itemController:ItemController

introducir datos

enviar petición

validar información

guardar información

de restauranteregresar mensaje

de operación

enviar respuestamostrar mensaje

de operación

introducir datos

enviar peticiónvalidar información

guardarinformación

de menúregresar mensaje

de operación

enviar respuesta

mostrar mensaje de operación

branchController:BranchController

tableController:TableController

googleMapsAPI:GoogleMapsAPI

introducir datos

enviar petición


guardarinformación

de itemregresar mensaje de operación

qrCodeGeneratorAPI:QRCodeGeneratorAPI

<<actor>>PaaS

enviar respuesta


introducir datos

enviar petición

enviar dirección

regresar ubicación(latitud, longuitud)

buscarubicación

(latitud, longuitud)


regresar mensaje de operación

guardarinformación de sucursal

enviar respuesta


introducir datos

enviar peticiónenviar identificador

de mesa

regresar código QR

generar códigoQR



guardarinformación

de mesa

enviar respuesta


ALTCrear Restaurante

ALTCrear Menú

ALTCrear Item

ALTCrear Sucursal

ALTCrear Mesa


Figura 3-21. Diagrama de Secuencia de Restaurantes del Módulo Perfil.


<<actor>>Administrador de Perfil

mainView:MainView

registrationsController:RegistrationsController

passwordsController:PasswordsController

<<actor>>PaaS

introducir datos

enviar petición


guardar información

de perfilregresar mensaje

de operación


de operación

introducir datos


buscar perfil

regresar respuesta de búsqueda

enviar respuesta

mostrar respuesta de búsqueda

introducir nuevacontraseña


guardarcontraseña


enviar respuesta


ALTCrear Perfil

ALTCambiar Contraseña


Figura 3-22. Diagrama de Secuencia del Módulo Navegación.


<<actor>>Visitante

mainView:MainView

restaurantController:RestaurantController

menuController:MenuController

itemController:ItemController

seleccionar restuarante

enviar petición


buscar restaurante

regresar informaciónde restaurante

enviar respuestamostrar información

de restaurante

seleccionar menú


buscarmenú

regresar informaciónde menú

enviar respuesta

mostrar información de menú

branchController:BranchController

googleMapsAPI:GoogleMapsAPI

seleccionar item

enviar petición


buscaritem

regresar informaciónde item

<<actor>>PaaS

enviar respuesta

mostrar informaciónde item

seleccionar sucursal

enviar petición

enviar dirección

regresar ubicación(latitud, longuitud)

en mapa

buscarubicación

(latitud, longuitud)


regresar informaciónde sucursal

buscarsucursal

enviar respuesta

mostrar informaciónde sucursal

ALTVerRestaurante

ALTVer Menú

ALTVer Item

ALTVerSucursal


Figura 3-23. Diagrama de Secuencia del Módulo Comanda.


<<actor>>Cliente

uiView:UIView

checkIn:GetCheckInViewController

branch:ReadQRCodeViewController

menus:SelectMenusViewController

realizar "check in"

enviar petición

implementarobtención de ubicación

buscarubicación

(latitud, longuitud)regresar mapade ubicación

enviar respuestamostrar

restaurante

items:SelectItemsViewController

item:AddItemsViewController

allItems:ShowComandaViewController

comanda:PayComandaViewController

request:AFNetworking

location:GoogleMapsAPI

qrReader:ZBarAPI

generar petición de restaurantes(en base a ubicación)

buscar restaurante

regresar restaurante

leer códigoQR de mesa

enviar petición

<<actor>>PaaS

enviar petición

enviar respuesta

leer código QR(a través dela cámara)

implementarlector de código QR

regresar mensaje

del código QR

generar peticiónde asignación de mesa

regresarmenus

asignar mesa

enviar petición

enviar respuesta

buscarmenus

enviar respuestamostrarmenus

seleccionarmenú

enviar petición

generar peticiónobtener items

buscaritems

enviar petición

enviar respuestaregresar

items

enviar respuestamostraritems

seleccionaritem

enviar petición

generar peticiónordenar item

buscardetalle

item

enviar petición


detalle item


detalle item

ordenaritem

enviar petición

generar peticiónagregar item

agregaritem a

comanda

enviar petición


mensaje de operación



vercomanda

enviar petición

generar peticiónobtener comanda

buscarcomanda

enviar petición

enviar respuestaregresarcomanda


comanda

pagarcomanda

enviar petición

generar peticiónpagar comanda

cerrarcomanda

enviar petición





ALTPagarComanda


Figura 3-24. Diagrama de Secuencia del Módulo Receptor de Órdenes. !

!!!!


<<actor>>Personal de Cocina

mainView:MainView

orderController:OrderController

ver órdenesactivas

enviar petición

buscarórdenesactivas

enviar respuestamostrar órdenes

activas

cerrar órdenesatendida

enviar petición

cerrarórden


de operación

<<actor>>PaaS

generar peticiónobtener órdenes

activas

regresar órdenesactivas

generar peticióncerrar órden

regresar mensajede operación

ALTVerÓrdenesActivas

ALTCerrarÓrdenAtendida


Diagrama Entidad – Relación La Plataforma de Menú en la Nube contará con una base de datos relacional que permitirá almacenar la información de cada uno de los módulos que integran a dicha plataforma. A continuación se muestra el diagrama de la base de datos:

!Figura 3-25. Diagrama Entidad Relación de la Base de Datos. !!!



Del diagrama anterior, se generan las siguientes tablas; mostradas en la Figura 3-35, con sus respectivos campos y la relación que existe entre ellas:

Figura 3-26. Diagrama Relacional de la Base de Datos.



Del diagrama anterior, se obtienen las siguientes tablas con sus correspondientes campos:

!Tabla 3-13. Campos de la tabla PROFILES de la Base de Datos. ! !

!Tabla 3-14. Campos de la tabla RESTAURANTS de la Base de Datos. !!

!Tabla 3-15. Campos de la tabla MENUS de la Base de Datos.

Nombre del Campo Tipo de Dato Descripción

id serial Identificador único del perfil.

description string Descripción del perfil.

email string Correo electrónico para iniciar sesión de un perfil.

password string Contraseña para poder iniciar sesión de un perfil.


id serial Identificador único del restaurante.

name string Nombre del restaurante.

tin string RFC del restaurante.

description text Descripción del restaurante.

history text Historia del restaurante.

profile_id serial Identificador único del perfil asociado.


id serial Identificador único del menú.

name string Nombre del menú.

description string Descripción del menú.

type_menu string Tipo de menú.

availability string Disponibilidad del menú.

restaurant_id serial Identificador único del restaurante asociado.



!Tabla 3-16. Campos de la tabla ITEMS de la Base de Datos. ! !

!Tabla 3-17. Campos de la tabla ITEMS_MENUS de la Base de Datos. !!

!Tabla 3-18. Campos de la tabla BRANCHES de la Base de Datos.


id serial Identificador único del ítem.

name string Nombre del ítem.

description string Descripción del ítem.

type_item string Tipo de ítem.

price decimal Precio unitario del ítem.

rations integer Raciones del ítem.


menu_id serial Identificador único de menú asociado.

item_id serial Identificador único de item asociado.


id serial Identificador único de la sucursal.

name string Nombre del la sucursal.

phone_main string Teléfono principal de la sucursal.

phone_secundary string Teléfono secundario de la sucursal.

service_hours string Horario de servicio de la sucursal.

address string Dirección física de la sucursal.

latitude decimal Latitud de la ubicación geográfica de la sucursal.

longitude decimal Longitud de la ubicación geográfica de la sucursal.

restaurant_id serial Identificador único del restaurante asociado.



!Tabla 3-19. Campos de la tabla TABLES de la Base de Datos. !!!

!Tabla 3-20. Campos de la tabla TABLES_SESSIONS de la Base de Datos. !!!

!Tabla 3-21. Campos de la tabla ORDERS de la Base de Datos. !!!! !


id serial Identificador único de mesa.

name string Nombre de la mesa.

people string Cantidad de personas que pueden ocupar la mesa.

branch_id string Identificador único de la sucursal asociada.


id serial Identificador único de la orden.

session_id string Identificador único de la sesión asosicada.

status string Estatus de la orden.


order_id serial Identificador único de la orden asociada.

item_id serial Identificador único de la sesión asociada.

quantity integer Estatus de la orden.

price decimal Precio total de los items de la orden.



!Tabla 3-22. Campos de la tabla ITEMS_ORDERS de la Base de Datos. !!

!Tabla 3-23. Campos de la tabla PICTURES de la Base de Datos.

!

!

!


uuid string Identificador único de la sesión.

table_id id Identificador único de la mesa.

status string Estatus de la sesión.


id serial Identificador único de la imagen.

description text Descripción de la imagen.

photo_file_name string Nombre del archivo de la imagen.

photo_content_type string Tipo de archivo de la imagen.

photo_file_size decimal Tamaño del archivo de la imagen.



!

Capítulo 4: Necesidades del Sistema y Selección de Herramientas

4.1 Necesidades del Sistema Es importante mencionar que para el buen funcionamiento de la Plataforma de Menú en la Nube y debido a la arquitectura de dicha plataforma, es de vital importancia considerar los siguientes puntos: !

๏ Los dispositivos móviles de los clientes deben tener acceso a internet, ya sea a través de una red WiFi o de la red de datos de su compañía telefónica.

๏ Los dispositivos móviles de los clientes pueden ser los pertenecientes a la empresa Apple™; ya sea un iPhone, una iPad o un iPod.

๏ El personal de cocina, debe contar con un equipo de cómputo con acceso a internet para poder visualizar las órdenes que generan los clientes desde sus dispositivos móviles. !!

4.2 Selección de Herramientas Módulo Perfil Como se mención anteriormente, el Módulo Perfil será una aplicación Web, por lo que se ha elegido desarrollar dicha aplicación utilizando el framework RoR (Ruby on Rails) debido a dos razones principales: la primera de ellas es la existencia de una gran cantidad de libros, tutoriales y documentación disponibles, y la segunda razón es por la gran facilidad e implementación de características dependiendo lo que se necesite realizar. !Módulo Navegación Al igual que el Módulo Perfil, el Módulo Navegación formará parte de una aplicación Web, por lo que la la herramienta elegida para su desarrollo es el framework RoR (Ruby on Rails) por las mismas razones ya expuestas.



Módulo Comanda El Módulo Comanda; como ya se mencionó en las secciones anteriores, será una aplicación móvil para dispositivos con SO iOS (solo dispositivos móviles de Apple™: iPhone. iPad, iPod). En base a lo anterior, la aplicación móvil se desarrollará utilizando el SDK del iOS en su versión 7. !Para la localización de la ubicación de los clientes, se ha decido ocupar el SDK de Google Maps para iOS en su versión 1.6. La razón por la cual se decidió ocupar dicha herramienta es por la gran popularidad, exactitud y gran cantidad de documentación y tutoriales con los que cuenta. !Finalmente, para realizar la lectura de códigos QR de las mesas, se ha elegido utilizar el SDK de ZBar para iOS en su versión 0.10. La razón por la cual se eligió dicha herramienta es la simplicidad para implementar el uso de la cámara del dispositivo móvil y la interpretación de los códigos QR. !Módulo Receptor de Órdenes El Módulo Receptor de Órdenes; al igual que los Módulos Perfil y Navegación, formará parte de la misma aplicación Web, por lo que la herramienta elegida es la misma (framework RoR) al igual que las razones por las cuales se eligió dicha herramienta. Para éste módulo, se utilizará Faye para enviar las órdenes creadas por los clientes a dicho receptor de órdenes (por medio de un broadcast). !Plataforma de Menú en la Nube (General) Para la base de datos que se utilizará en todos los módulos que integran la Plataforma de Menú en la Nube, se ha decidido utilizar PostgreSQL; en su versión 9.2.1, ya que es un DBMS con características avanzadas; como la gran velocidad en consultas, y actualmente se encuentra disponible en la plataforma (PaaS) que se utilizará para montar la aplicación en la Nube. !Debido a que los Módulos Perfil, Navegación y Receptor de Órdenes se desarrollarán a través de una aplicación Web, es necesario que dicha aplicación Web se encuentre alojada en un servidor el cual permita el acceso desde cualquier punto, lo anterior aunado a la necesidad de accesibilidad que deben tener la base de datos de la plataforma y la aplicación Web, serán alojadas en servidor en la nube. Debido a lo anterior, se ha elegido utilizar la PaaS (Platform as a Service; por sus siglas en inglés) Heroku™, por su gran versatilidad de lenguajes de programación y base de datos soportados y la escalabilidad que ofrece sin necesidad de afectar el desarrollo de la plataforma; es decir, no hay necesidad de modificar el código de la plataforma para poder escalarlo (aumentar el tamaño de almacenamiento, concurrencias, etc.).



!

Capítulo 5: Desarrollo del Sistema

5.1 Aplicación Web Vista general de la Aplicación Web

Figura 5-1. Diagrama de Bloques de la Aplicación Web. !



Aplicación RoRMVC

Base de Datos

ModeloRoR

ActiveRecord

VistasRoR

PC - Móvil

ControladorRoR

Application Controller

Google Maps

DeviseFaye

La Figura 5-1 muestra el diagrama de bloques de los componentes de que forman la Aplicación Web alojada en la PaaS (Heroku™). Dicha aplicación se ha programado utilizando el framework Ruby on Rails, el cual se basa en el patrón de arquitectura de software MVC. !Base de Datos de la Plataforma Todas las tareas concernientes a la Base de Datos (conexión, consultas, inserciones, modificaciones, etc.) son realizadas por el Modelo de RoR (clases extendidas de la clase ActiveRecord). !Para conectarse a la Base de Datos, se necesita tener instalado el conector correspondiente al manejador (PostgreSQL en el caso de la Plataforma de Menú en la Nube) y configurar el archivo

database.yml. A continuación se muestra un extracto del archivo de configuración:

!Figura 5-2. Extracto del archivo de configuración database.yml. !!



En éste archivo se configura el nombre del conector, la codificación, el nombre de la BD, usuario,

contraseña, etc. Para cada una de los ambientes del proyecto . 2

!RoR permite una abstracción del SQL mediante migraciones (migrations). Esto es, que escribiendo

código en Ruby se puede realizar desde la creación de la estructura de la BD hasta las consultas.

!Las ventajas de ésta característica son que sólo se tiene que lidiar con las peculiaridades de Ruby, en vez de tener que consultar las referencias de la sintaxis SQL del manejador de base de datos (haciendo

a nuestra aplicación independiente del DBMS). La segunda es que, además de modificar el esquema

de la base de datos añadiendo tablas, columnas, etc. con las migraciones podemos modificar los datos ya existentes en las tablas.

El siguiente código muestra la migración correspondiente a la creación de la tabla Profiles:

Figura 5-3. Archivo de migración devise_create_profiles.rb para la creación de la tabla Perfiles.



! Los ambientes son desarrollo (development), pruebas (test) y producción (production).2

Para aplicar las migraciones se ejecuta el comando ‘rake db:migrate’, y RoR se encarga de ejecutar las instrucciones, aplicando los cambios en la BD. !Pero además de poder aplicar cambios a la BD, también se pueden deshacer, indicando en la

instrucción ‘rake db:migrate’ la versión de migración que se desea. Esto es, por ejemplo, si han

ejecutado 4 migraciones (versión 4) en la que se agregaron 4 tablas, y queremos eliminar las últimas

dos, se ejecuta ‘rake db:migarte VERSION=2’. Con ésta instrucción, RoR deshace los cambios

realizados por las últimas dos migraciones, dejando la estructura (y los datos) de la BD como estaba en

la versión 2.

!!Consultas (Modelos) Al crear una clase extendida de ActiveRecord, se crean automáticamente métodos para el acceso a la BD de acuerdo a las relaciones de las tablas. Una tabla es mapeada a un objeto, y sus columnas son

los atributos. A continuación se explica como se accede a los datos de las tablas ‘Profiles’ y ‘Restaurants’ y sus relaciones mediante objetos: !Las tablas ‘Profiles’ y ‘Restaurants’ tienen una relación uno a uno (un perfil tiene un restaurante, y un

restaurante pertenece a un perfil). Para indicarle a RoR ésta relación, se pone lo siguiente en los modelos: !

Figura 5-4. Extracto del archivo profile.rb. !!!!!!!



!Figura 5-5. Extracto del archivo restaurant.rb. !!

Con éstas aparentemente simples declaraciones, ActiveRecord inspecciona la BD obteniendo las

columnas , que serán mapeadas a los atributos de los objetos, así como los métodos de acceso.3

!De esta forma, si creamos una instancia de la clase Profile, podemos acceder a su restaurante con el método restaurant: !

perfil = Profile.new(params)

restaurante = perfil.restaurant !El método restaurant nos regresa un solo objetos de la clase Restaurant, relacionados con ‘perfil’. De la misma forma se hizo para las relaciones de todas las tablas de la BD (como branches – tables, menús – items, etc.), de modo que no fue necesaria la escritura de ningún tipo de SQL. !!!!!!!!!



! Los nombres de las clases (por ejemplo Profile o Restaurant) son los mismos que los nombres de las tablas en la BD. Esto 3

por el principio convention over configuration de RoR.

Interfaz Web (vistas) Para las vistas se utilizan archivos con extensión .erb, que no son más que html con código

Ruby embebido . Pero a partir de Rails 2.0, se pueden crear más tipos (además del html) para la 4

misma vista. A continuación se muestra un extracto de la vista del registro de perfiles (new.html.rb de la vista Profiles): !

Figura 5-6. Extracto del archivo new.html.erb de las vistas de profiles. !!El sitio Web que se implementó en RoR para PC y móviles cuenta con las funciones básicas de Administración de usuarios, computadoras y perfiles, además del control remoto establecido en el diseño a través del programa cliente. !La navegación básica que se planteó en el diseño no fue alterada. A continuación se muestra ésta navegación y algunas pantallas del sistema implementado: !!!!!!!!



! El código Ruby embebido se encierra entre las etiquietas <% ruby code %>4

Módulo Perfil

!Figura 5-7. Pantalla de Creación de Perfil.

!Figura 5-8. Pantalla de Creación de Restaurante.



Figura 5-9. Pantalla de Creación de Menús.

Figura 5-10. Pantalla de Creación de Ítems. !!



Figura 5-11. Pantalla de Creación de Sucursales.

Figura 5-12. Pantalla de Creación de Mesas. !!



Módulo Navegación

Figura 5-13. Pantalla Ver Restaurante. ! !

Figura 5-14. Pantalla Ver Menú. !!!!



Figura 5-15. Pantalla Ver Ítem.

!Figura 5-16. Pantalla Ver Sucursal.

!



Funcionalidad de la Aplicación (controlador) Una petición primero es direccionada a un Controlador, éste interactúa con el Modelo y posteriormente invoca una Vista que finalmente genera la respuesta al navegador.

!En nuestro sistema, la lógica está dividida en atender las peticiones de los navegadores e intercambiar (envío, recepción y procesamiento) de la información proveniente de los programas cliente. !Módulo Perfil Sucursal

Para poder crear una sucursal (es necesario que previamente se haya creado un restaurante) se implementó en la PaaS el controlador llamado branches_controller, cuya tarea es la de administrar todo lo referente a las sucursales (crear, eliminar, modificar ó consultar). A continuación se muestra un fragmento del código de dicho controlador:

!Figura 5-17. Extracto del archivo branches_controller.rb.



Mesa

Para poder crear una mesa (es necesario que previamente se haya creado una sucursal) se implementó en la PaaS el controlador llamado tables_controller, cuya tarea es la de administrar todo lo referente a las mesas de una sucursal (crear, eliminar, modificar ó consultar).

Figura 5-18. Extracto del archivo tables_controller.rb. !!La Figura 5-18 muestra un fragmento del controlador tables_controller, en el cual se puede observar método llamado qrcode, que es el encargado de la generación de los códigos QR de cada una de las mesas que pertenecen a una sucursal determinada. La generación de códigos QR se realizó a través de la implementación de un paquete de librerías (llamdas gemas en RoR) llamado ‘rqrcode’. !!!



Módulo Navegación Restaurante

Para poder visualizar la información de un restaurante se implementó en la PaaS el controlador llamado restaurants_controller, cuya tarea es obtener la información del restaurante y mostrarse en la vista. A continuación se muestra un fragmento del código de dicho controlador:

!Figura 5-19. Extracto del archivo restaurants_controller.rb. !!!

Menús

Para poder visualizar la información de un restaurante se implementó en la PaaS el controlador llamado menus_controller, cuya tarea es obtener la información de los diferentes menús que el restaurante ofrece. A continuación se muestra un fragmento del código de dicho controlador:

!!!!!!



Figura 5-20. Extracto del archivo menus_controller.rb. !!

!!!!!!!!!!!



5.2 Aplicación Nativa para Dispositivos Móviles iOS Vista general de la Aplicación para Dispositivos Móviles

!Figura 5-21. Diagrama de Bloques de la Aplicación Nativa para Dispositivos Móviles iOS. !!

La Figura 5-21 muestra el diagrama de bloques de los componentes de que forman la Aplicación Nativa para Dispositivos Móviles con SO iOS. Esta aplicación se ha programado utilizando el iOS SDK de Apple™. !El flujo comienza cuando una petición es enviada al controlador (implementación de la clase UIViewController) desde la vista asociada (implementación de la clase IUView) a dicho controlador. !La comunicación que existe entre el Módulo Comanda y el Módulo Perfil, es a través del uso del componente AFNetworking.


Aplicación RoRMVC

ZBar

AFNetworking

VistasiOS SDKUIView

ControladoriOS SDK

UIViewController

Google Maps


Figura 5-22. Fragmento de código de petición HTTP a través de AFNetworking. !

En la Figura 5-22 se muestra un fragmento de código en donde se realiza una petición HTTP a la PaaS utilizando la clase AFJSONRequestOperation, el cual recibe como parámetros una URL del servidor, y regresa un objeto de tipo JSON. !!“Check In” en Sucursal El proceso de “check in” comienza en el momento en que se ubica geográficamente al cliente; es decir, se obtiene la ubicación geográfica (latitud y longitud) del cliente a través del dispositivo móvil que esté utilizando. La ubicación del cliente se obtiene haciendo uso de las características que ofrece el SDK de Google Maps.

!Figura 5-23. Fragmento de código del controlador GetCheckInViewController. !



En la Figura 5-23 se muestra un fragmento del código del controlador l lamado GetCheckInViewController, que es el encargado de obtener la ubicación del cliente utilizando la implementación de la clase de Google Maps CLLocationManager. !Una vez invocada la clase CLLocationManager, se dispara un evento; en el momento en que la ubicación del cliente cambia, el cual se cacha a través de la implementación del método didUpdateToLocation. Cuando el evento dispara la implementación del método, este último regresa un objeto de tipo CLLocation, el cual contiene la nueva ubicación del cliente. A continuación se muestra el fragmento de código que contiene la implementación del método didUpdateToLocation:

Figura 5-24. Fragmento de código del método didUpdateToLocation. !Después de conocer la ubicación del cliente (su latitud y longitud), se muestra en la vista a través de la implementación de un mapa; generado por el SDK de Google Maps. !



El mapa generado, tiene la dirección generada a partir de la ubicación del cliente. La dirección se obtiene utilizando el método reverseGeocodeLocation perteneciente a la clase del SDK de Google Maps llamada CLGeocoder:

!!Figura 5-25. Fragmento de código del método reverseGeocodeLocation. !

Finalmente, el controlador envía a la PaaS la ubicación del cliente a través del componente AFNetworking. !A continuación de muestran las vistas (pantallas) del “check in” en una sucursal. !! !!!!!!!!!!



Figura 5-26. Pantalla de “check in” del dispositivo móvil.

!!Asignación de Mesa Para poder asignar una mesa, es necesario conocer cual es la mesa que se va a asignar. Lo anterior se logra utilizando las características que ofrece el SDK de ZBar.

!Figura 5-27. Fragmento de código del controlador ReadQRCodeViewController.



!En la Figura 5-27 se observa un fragmento de código del controlador l lamado ReadQRCodeViewController, que se encarga de leer el código QR de la mesa, procesar dicho código y regresar el significado del código. La lectura del código QR se realiza utilizando la cámara del dispositivo móvil que es controlada por la clase ZBarImageScanner, y el mensaje es descodificado utilizando la clase ZBarSymbol. !Una vez que se tenga el identificador de mesa, el controlador envía al PaaS la ubicación del cliente a través del componente AFNetworking. !A continuación de muestran las vistas (pantallas) de la asignación de una mesa en una sucursal.

!Figura 5-28. Pantalla de leer código QR del dispositivo móvil. !

!!!!!!!



Selección de Items Una vez realizada la asignación de mesa, se navega a través de los diferentes menús e items que el restaurante ofrece, se selecciona el item a ordenar.

!Figura 5-29. Fragmento de código del controlador AddItemsToOrderViewController. !!

En la Figura 5-29 se observa un fragmento de código del controlador l lamado AddItemsToOrderViewController, que se encarga añadir a la orden actual, los items que el cliente va seleccionando. ! !!!!!



Figura 5-30. Pantallas para agregar items a la orden. !!

Visualización y envío de Orden Finalmente, una vez se encuentre la orden lista, dicha orden es enviada al Personal de Cocina, a través de la implementación de petición correspondiente, implementada en el siguiente fragmento de código.

Figura 5-31. Fragmento de código del controlador ShowOrdersViewController.



En la Figura 5-31 se observa un fragmento de código del controlador llamado ShowOrderViewController, que se encarga de enviar al PaaS, la orden generada por el cliente a través del componente AFNetworking.

Figura 5-32. Pantallas para ver la orden actual. !!!“Check Out” de Órdenes En el momento en que el cliente desea pedir la cuenta, es necesario hacer un “check out” para poder cerrar las ordenes que el cliente haya realizado. !!!!!!!!!!



Figura 5-33. Fragmento de código del controlador SessionOrdersCheckOutViewController. !

Figura 5-34. Pantalla para ver la orden actual.



!

Capítulo 6: Pruebas del Sistema

Las pruebas de la plataforma de realizaron de manera genera; es decir, se probó la plataforma completa; incluyendo la interacción con cada uno de sus módulos. !!6.1 Módulo Perfil

!Figura 6-1. Pantalla en la cual se creó un nuevo perfil. !!!!!!



!Figura 6-2. Pantalla en la cual se creó un nuevo restaurante.

Figura 6-3. Pantalla en la cual se visualizó el restaurante creado.

!



Figura 6-4. Pantalla en la cual se creó un nuevo menú.

!

Figura 6-5. Pantalla en la cual se visualizó el menú creado.

!!!



Figura 6-6. Pantalla en la cual se creó un nuevo item.

Figura 6-7. Pantalla en la cual se visualizó el item creado.

!!



Figura 6-8. Pantalla en la cual se creó una nueva sucursal. !

Figura 6-9. Pantalla en la cual se creó una mesa. !



Figura 6-10. Pantalla en la cual se visualizó la mesa creada.

!!!!!!!!!!!



6.2 Módulo Navegación

Figura 6-11. Pantalla en la cual se seleccionó un restaurante.

!

Figura 6-12. Pantalla en la cual se seleccionó un menú.

!!!!



Figura 6-13. Pantalla en la cual se seleccionó un item.

Figura 6-14. Pantalla en la cual se seleccionó una sucursal.

!!



6.3 Módulo Comanda

Figura 6-15. Pantalla en la cual se realizó el “check in”. !

!Figura 6-16. Pantalla en la cual se realizó la lectura del código QR. !



Figura 6-17. Pantallas en la cuales se seleccionó y agrego un item a la orden.

!Figura 6-18. Pantalla en la cual se visualizó la orden. !



Figura 6-19. Pantalla en la cual se visualizó el “check out” de la orden. !!

6.4 Módulo Receptor de Órdenes

Figura 6-20. Pantalla en la cual se visualizaron las órdenes que fueron atendidas. !



!

Conclusiones

La Plataforma de Menú en la Nube ha sido el proyecto mas ambicioso y complejos el cual hemos emprendido debido a que la mayoría de las tecnologías que utilizamos para el desarrollo no habíamos tenido contacto con ellas en proyectos anteriores. Aunado a lo anterior, la plataforma desarrollada en este documento, tuvo que ser dividida en varias etapas debido a la complejidad de la misma y los diferentes escenarios que abarca como parte de una solución integral y completa. !Sin embargo, a pesar de no haber tenido contacto no las tecnologías utilizadas en esta plataforma; como el uso del framework Ruby on Rails y el uso del SDK de iOS, nos llevamos una grata sorpresa al darnos cuenta que gracias a las bondades que ofrecen éstas tecnologías, se redujeron los tiempos de desarrollo de manera considerable y se evitó la regeneración de código. !Aunado al reto de aprender las nuevas tecnologías con las cuales se desarrollo la Plataforma de Menú en la Nube; como experiencia personal, tuvimos que ampliar nuestro horario activo de trabajo debido a las actividades alternas que ambos realizamos en paralelo con el desarrollo de dicha plataforma. Alguna se las actividades alternas que ambos llevamos a cabo no nos permitían trabajar durante el día, por lo que tuvimos que reducir nuestro horario de sueño y ampliar nuestro horario de trabajo. !También es importante mencionar, que debido al tiempo con el que contamos para el desarrollo de éste proyecto, no se diseño un plan de trabajo adecuado en base a nuestras necesidades, por lo que la complejidad en la realización de éste proyecto aumento de manera considerable. !A pesar de todo lo que implicó el diseño y desarrollo de la Plataforma de Menú en la Nube, nos llevamos una de las mejores experiencias de aprendizaje de nuestra vida; y gracias a este gran aprendizaje y el buen sabor de boca que nos dejó la plataforma ya finalizada, continuaremos con el desarrollo de la plataforma para terminar el proyecto tal cual lo planeamos. !!!



Trabajo a futuro !Como se mencionó al inicio de ésta sección, la Plataforma de Menú en la Nube tuvo que ser dividida debido a la complejidad del proyecto en general. Debido a lo anterior, algunas de las etapas; por cuestiones de tiempo, no fueron agregadas ni consideradas para ésta etapa inicial. !Uno de módulos a agregar es el proceso de pago a través de algún servicio como lo es PayPal™ o algún otro servicio. Con lo anterior, la plataforma podría ofrecer que los clientes pague desde sus dispositivos móviles, y con ello asegurar que sus datos estarán seguros. !Otro de los módulos que aun faltan de incluir es el desarrollo del Módulo Comanda para otros dispositivos móviles diferentes a los que cuentan con SO iOS; como lo son aquellos dispositivos móviles que cuenten con el SO Android.

!

!

!

!!!



!!!

Acrónimos

๏

PaaS Platform as a Service

๏

QR Quick Responde Code

๏

SO Sistema Operativo

๏

SDK Software Development Kit

๏

RoR Ruby on Rails

๏

MVC Model, View, Controller

๏

DRY Don´t Repeat Yourself

๏

MVCC Multi Versión de Control de Concurrencias

๏

API Application Programming Inteface



!

!

!

!

๏

ACID Atomicity, Consistency, Isolation, Durability

๏

UML Unified Modeling Language

๏

CU Caso de Uso

๏

BD Base de Datos

๏

DBMS Data Base Management System

๏

SQL Structured Query Language

๏

PC Personal Computer



!

Bibliografía

๏ IBMSmartCloud, noviembre 2013, Plataforma as a Service (Pass), http://www-05.ibm.com/es/cloud-computing/paas.html

๏ GitHub, Plataformatec/divise, Noviembre 2013,Soluciones de autenticasión flexibles para Rails con Warden, Divise. https://github.com/plataformatec/devise

๏ GitHub, AFNetworking /AFNetworking, Noviembre 2013, Un encantador iOS y OS X marco de red https://github.com/AFNetworking/AFNetworking

๏

Migueldiasrubio.com, , Noviembre 2013, DesarrolloiOS7: Introducción a AFNetworking2, publicado por sendaportuondo el 21/10/2013, http://www.migueldiazrubio.com/2013/10/21/desarrollo-ios-7-introduccion-afnetworking-2/

๏

Books google, novienbre 2013, Math Formulas and tables for Smartphones and mobile divices, Haversine Formula. http://books.google.com.mx/books?id=Fte4xjoUiu8C&pg=PT188&dq=formula+de+haversine&hl=es419&sa=X&ei=upauUrX2DoWMyQHh1ICoBQ&ved=0CDAQ6AEwAA#v=onepage&q=formula%20de%20haversine&f=falseonepage&q=formula%20de%20haversine&f=false

๏ http://www.visualbeta.es/22529/software-libre/zbar-una-utilidad-multiplataforma-para-escanear-codigos-qr-y-de-barras/

๏ ZBar bar code reader, Copyright 2007-2010 (c) Jeff Brown, novienbre 2013, http://zbar.sourceforge.net/about.html



๏ Noticias de Google Maps, Noviembre 2013, ¿Qué es Google Maps?http://www.googlemaps.es/?page_id=3

๏

Recorriendo otros rumbos , Escribiendo sobre los que aprendo del mundo Ruby on Rails, Noviembre 2013, Rails en la nuebe se llama Heroku, http://recorriendootrosrumbos.blogspot.mx/2011/10/rails-en-la-nube-se-llama-heroku.html

๏ GitHub, cloudfoundry/warden Noviembre 3013, Cloudfoundry – the open platform as a service project https://github.com/cloudfoundry/warden

๏ GitHub, intridea/omniauth, noviembre 2013, OmniAuth is a flexible authentication system utilizing Rack middleware, https://github.com/intridea/omniauth

๏ PostgreSQL-es. Portal en español sobre PostgreSQL , noviembre 2013, Sobre PostgreSQL http://www.postgresql.org.es/sobre_postgresql



instituto politécnico nacionaltesis.ipn.mx/jspui/bitstream/123456789/15889/1/plataforma... ·...

Documents