u c -l m e s i

UNIVERSIDAD DE CASTILLA-LA MANCHAESCUELA SUPERIOR DE INFORMÁTICA

GRADO EN INGENIERÍA EN INFORMÁTICA

TECNOLOGÍA ESPECÍFICA DE

INGENIERÍA DEL SOFTWARE

TRABAJO FIN DE GRADO

SUEGRA: Sistema Único de Emparejamiento paraGarantizar la Reorganización de los Asistentes

Carlos del Olmo Lorenzo

Febrero, 2015

UNIVERSIDAD DE CASTILLA-LA MANCHAESCUELA SUPERIOR DE INFORMÁTICA

DPTO. DE TECNOLOGÍAS

Y SISTEMAS DE INFORMACIÓN

TECNOLOGÍA ESPECÍFICA DE

INGENIERÍA DEL SOFTWARE

TRABAJO FIN DE GRADO

SUEGRA: Sistema Único de Emparejamiento paraGarantizar la Reorganización de los Asistentes

Autor: Carlos del Olmo Lorenzo

Director: José Antonio Cruz Lemus

Febrero, 2015

TRIBUNAL:

Presidente:

Vocal :

Secretario:

FECHA DE DEFENSA:

CALIFICACIÓN:

PRESIDENTE VOCAL SECRETARIO

Fdo.: Fdo.: Fdo.:

Resumen

Aún en los tiempos de crisis que corren, las personas siguen tomando la decisión dedar un paso muy importante y contraer matrimonio para afianzar la relación con su pareja.Es por esto por lo que uno de los días más importante en la vida de una persona es el díade su boda. Los novios implicados quieren que todo salga perfecto y con esta herramientase facilita la gestión de algunas de esas tareas que los novios deben tratar para celebrar su boda.

En el actual Trabajo Fin de Grado se va a desarrollar una herramienta capaz de gestionartodos los aspectos relacionados con la celebración de una boda, la principal novedad queincluirá este trabajo, será la incorporación de una funcionalidad que permita a los novios dela boda la organización automática de los invitados según la afinidad que exista entre ellos.

Debido al tipo de trabajo se ha decidido desarrollar una aplicación web para gestionartodos estos aspectos. En cuanto al método de desarrollo he decidido utilizar Proceso Unifica-do Ágil (AUP), ya que se trata de una versión simplificada del Proceso Unificado Rational(RUP) para proyectos menos pesados. También se hablará de las tecnologías utilizadas, eneste caso se ha decidido utilizar como lenguaje de programación Ruby y el framework Rails,trabajando con el patrón Modelo-Vista-Controlador.

La aportación más importante de este TFG consiste en en la organización automática delos invitados según el nivel de afinidad existente entre ellos, es decir, la aplicación sentaráen una misma mesa a aquellos invitados que tengan un nivel de afinidad alto. Haciendo unapequeña búsqueda por Internet se ha llegado a la conclusión de que ningún portal web ofreceesta funcionalidad por lo que es interesante resolver este problema que tienen las personasque han decidido casarse.

La realización de este Trabajo Fin de Grado ha supuesto para mi la puesta en práctica delos conocimientos aprendidos a lo largo de la carrera, desde la captura de requisitos aplicandolas técnicas vistas en la carrera sobre cómo elicitar los requisitos, hasta el diseño y desarrollode una aplicación web, pasando por la realización del plan de proyecto y un estudio deviabilidad.

vii

Abstract

Despite of the crisis time, people are making the decision to take a step very importantin their lifes and get married to secure the relationship with their partner. Therefore one ofthe most important day in the life of a person is the day of their wedding. The groom wanteverything to be perfect, and this web tool help the groom to manage all of those tasks whichshould be proccessed to celebrate the wedding.

In the current final project I am going to develop a tool which is able to manage allaspects about a wedding celebration, the main newness, which this project include, will be afunctionallity which allows to the groom automatically guest organization according to theaffinity level between them.

Due to the type of project, I have decided develop a web application to manage all ofthese aspects. I have decided to use Agile Unified Process (AUP) as software developmentprocess, which is a simplified version of Rational Unified Process (RUP) for lighter projects.I will also discuss about the technologies wich are used, in this case I have decided to use asprogramming language Ruby with the framework Rails, this programming language workswith the pattern Model-View-Controller.

The main contribution of this TFG is the automatic organization of the guests in a weddingby the level of affinity between them, ie, the application sit at a table those guests who have ahigh level of affinity. I have done a little research on the Internet and I hve concluded that noweb provides this functionality so I consider this interesting to solve this problem which havethe people who have decide to marry.

The realization of this TFG has meant to me the knowdeledge learned during the de-gree,the requirements capture by applying the techniques learned in the degree about howto elicit requirements, the design and develop a web application and the realization a planproject and the feasibility study.

ix

A mis padres y a mi hermano.Por haber creído siempre en mí.

A todos mis amigos, tanto de Ciudad Real como de Torrijos.Por su apoyo y amistad.

A José Antonio.Por sus ánimos y su apoyo incondicional

a lo largo de estos años de carrera.

xi

Índice general

Índice de figuras xvi

Índice de tablas xx

1 Introducción 11.1 Introducción al tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Objetivos del TFG 52.1 Objetivo principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Objetivos parciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Medios utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 Medios Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.2 Medios Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Estado del Arte 93.1 Evolución del desarrollo web . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.2 ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.3 Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Portales web similares . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1 iNovios.es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.2 WedTool.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.3 bodas.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Método de Trabajo 234.1 AUP. Proceso Unificado Ágil . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Características de AUP . . . . . . . . . . . . . . . . . . . . . . . . 244.1.2 Disciplinas de trabajo de AUP . . . . . . . . . . . . . . . . . . . . 25

4.2 Evolución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.1 Fase I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.2 Fase II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.3 Fase III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2.4 Fase IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.5 Fase V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.6 Fase VI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Marco Tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

xiii

xiv ÍNDICE GENERAL

4.3.1 Visual Paradigm for UML . . . . . . . . . . . . . . . . . . . . . . 304.3.2 LATEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.3 Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.4 Microsoft Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Resultados 335.1 Iteración I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.1 Primeras entrevistas con el cliente . . . . . . . . . . . . . . . . . . 335.1.2 Estudio de viabilidad . . . . . . . . . . . . . . . . . . . . . . . . . 395.1.3 Plan de proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2 Iteración II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2.1 Crear Boda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2.2 Alta de Novios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2.3 Administración de Salones . . . . . . . . . . . . . . . . . . . . . . 525.2.4 Administración de Mesas . . . . . . . . . . . . . . . . . . . . . . . 56

5.3 Iteración III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.3.1 Elegir Mesas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.3.2 Alta de Invitados . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3.3 Definir Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 685.3.4 Organizar Invitados . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.4 Iteración IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.4.1 Confirmar asistencia . . . . . . . . . . . . . . . . . . . . . . . . . . 875.4.2 Invitados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.4.3 Posición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.5 Iteración V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.5.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.5.2 Perfil de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.5.3 Generador de invitados . . . . . . . . . . . . . . . . . . . . . . . . 945.5.4 Nombres, apellidos y passwords aleatorias . . . . . . . . . . . . . 95

6 Conclusiones y Propuestas 976.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 976.2 Propuestas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Bibliografía 100

A Acrónimos 105

B Manual de Usuario 107B.1 Gerente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

B.1.1 Crear Salón . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107B.1.2 Generar y eliminar Mesas . . . . . . . . . . . . . . . . . . . . . . 108B.1.3 Crear Boda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109B.1.4 Alta de Novios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

B.2 Novio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110B.2.1 Alta de Invitados . . . . . . . . . . . . . . . . . . . . . . . . . . . 110B.2.2 Elegir Mesas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111B.2.3 Definir Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 112B.2.4 Organizar Invitados . . . . . . . . . . . . . . . . . . . . . . . . . . 112

ÍNDICE GENERAL xv

C Codigo fuente 115C.1 Organización de invitados . . . . . . . . . . . . . . . . . . . . . . . . . . . 115C.2 Asignar salones libres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135C.3 Generador de invitados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136C.4 Algoritmo para elegir mesas . . . . . . . . . . . . . . . . . . . . . . . . . 142C.5 Clase para iniciar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Índice de figuras

3.1 Niveles en una aplicación web. . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Lenguajes desarrollo web en 2006. [21] . . . . . . . . . . . . . . . . . . . 153.3 Lenguajes desarrollo web en 2010. [22] . . . . . . . . . . . . . . . . . . . 153.4 Lenguajes desarrollo web en 2013. [23] . . . . . . . . . . . . . . . . . . . 163.5 Diagrama de ejecución MVC . . . . . . . . . . . . . . . . . . . . . . . . . . 173.6 Captura de iNovios.es [28] . . . . . . . . . . . . . . . . . . . . . . . . . . 193.7 Captura de WedTool.com [29] . . . . . . . . . . . . . . . . . . . . . . . . 203.8 Captura de bodas.net [30] . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Trazabilidad a partir de los Casos de Uso. . . . . . . . . . . . . . . . . . . 254.2 Herramientas utilizadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Casos de Uso para Gerente. . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2 Casos de Uso para Novios. . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3 Casos de Uso para Invitados. . . . . . . . . . . . . . . . . . . . . . . . . . 355.4 Diagrama ER de la apliación. . . . . . . . . . . . . . . . . . . . . . . . . . 365.5 Planificación inicial. Diagrama de Gantt. . . . . . . . . . . . . . . . . . . . 445.6 Acciones del gerente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.7 Casos de Uso para Gerente. . . . . . . . . . . . . . . . . . . . . . . . . . . 465.8 Boda ejemplo1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.9 Boda ejemplo2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.10 Error salones no disponibles. . . . . . . . . . . . . . . . . . . . . . . . . . . 475.11 Error numero invitados grande. . . . . . . . . . . . . . . . . . . . . . . . . . 475.12 Crear Boda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.13 Alta Novio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.14 Datos de enlace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.15 Enlace con Novios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.16 Enlace sin Novios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.17 Diagrama de secuencia Creación de boda. . . . . . . . . . . . . . . . . . . 495.18 Diagrama de clases Creación de boda. . . . . . . . . . . . . . . . . . . . . 505.19 Alta Novio 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.20 Alta Novio 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.21 Error 1 en Alta de novios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.22 Error 2 en Alta de novios. . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.23 Diagrama de secuencia Alta de novios. . . . . . . . . . . . . . . . . . . . . 525.24 Diagrama de clases Alta Novios. . . . . . . . . . . . . . . . . . . . . . . . 535.25 Lista de salones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.26 Crear salón. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

xvii

xviii ÍNDICE DE FIGURAS

5.27 Consultar salón. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.28 Editar salón. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.29 Eliminar salón. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.30 Diagrama de secuencia Crear Salón. . . . . . . . . . . . . . . . . . . . . . 555.31 Diagrama clases Administración Salones. . . . . . . . . . . . . . . . . . . 565.32 Listado de mesas antiguo. . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.33 Mostrar según el salón elegido. . . . . . . . . . . . . . . . . . . . . . . . . . 575.34 Listado de mesas agrupadas. . . . . . . . . . . . . . . . . . . . . . . . . . . 575.35 Generador de mesas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.36 Eliminar mesas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.37 Error mesas no encontradas. . . . . . . . . . . . . . . . . . . . . . . . . . 595.38 Diagrama de secuencia Generar Mesas. . . . . . . . . . . . . . . . . . . . 595.39 Diagrama clases Administración Mesas. . . . . . . . . . . . . . . . . . . . 605.40 Primera pantalla inicio Novios. . . . . . . . . . . . . . . . . . . . . . . . . . 615.41 Primera pantalla inicio Novios. . . . . . . . . . . . . . . . . . . . . . . . . . 615.42 Primera pantalla inicio Novios. . . . . . . . . . . . . . . . . . . . . . . . . 625.43 Casos de uso para el rol Novio. . . . . . . . . . . . . . . . . . . . . . . . . 625.44 Mesas disponibles en un salón. . . . . . . . . . . . . . . . . . . . . . . . . 635.45 Formulario elegir Mesas Novio. . . . . . . . . . . . . . . . . . . . . . . . 645.46 Diagrama de secuencia Elegir Mesas. . . . . . . . . . . . . . . . . . . . . 645.47 Diagrama clases Administración Salones. . . . . . . . . . . . . . . . . . . 655.48 Relaciones entre invitados. . . . . . . . . . . . . . . . . . . . . . . . . . . 665.49 Formulario Nuevo Invitado. . . . . . . . . . . . . . . . . . . . . . . . . . . 665.50 Diagrama de secuencia Alta de invitados. . . . . . . . . . . . . . . . . . . . 675.51 Diagrama clases Alta Invitados. . . . . . . . . . . . . . . . . . . . . . . . 685.52 Tipos de relaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.53 Afinidad Familiares del Novio con el resto. . . . . . . . . . . . . . . . . . 695.54 Diagrama de secuencia Definir Relaciones. . . . . . . . . . . . . . . . . . 705.55 Diagrama clases Definir Relaciones. . . . . . . . . . . . . . . . . . . . . . 705.56 Elegir grupo de invitados para empezar a organizar. . . . . . . . . . . . . . . 715.57 Elegir afinidad mínima entre invitados de una misma mesa. . . . . . . . . . . 715.58 Afinidad alta entre todos los invitados. . . . . . . . . . . . . . . . . . . . . 725.59 Datos de entrada, ejemplo 1. . . . . . . . . . . . . . . . . . . . . . . . . . 735.60 Resultado obtenido, ejemplo 1. . . . . . . . . . . . . . . . . . . . . . . . . 735.61 Resultado obtenido, ejemplo 1. . . . . . . . . . . . . . . . . . . . . . . . . 745.62 Datos de entrada, ejemplo 2. . . . . . . . . . . . . . . . . . . . . . . . . . 755.63 Datos de entrada, ejemplo 2. . . . . . . . . . . . . . . . . . . . . . . . . . 755.64 Resultado obtenido, ejemplo 2. . . . . . . . . . . . . . . . . . . . . . . . . 765.65 Datos de entrada, ejemplo 3. . . . . . . . . . . . . . . . . . . . . . . . . . . 775.66 Datos de entrada, ejemplo 3. . . . . . . . . . . . . . . . . . . . . . . . . . . 775.67 Resultado obtenido, ejemplo 3. . . . . . . . . . . . . . . . . . . . . . . . . 785.68 Resultado obtenido, ejemplo 3. . . . . . . . . . . . . . . . . . . . . . . . . 795.69 Datos de entrada, ejemplo 3. . . . . . . . . . . . . . . . . . . . . . . . . . 795.70 Resultado obtenido, ejemplo 3. . . . . . . . . . . . . . . . . . . . . . . . . 795.71 Resultado obtenido, ejemplo 3. . . . . . . . . . . . . . . . . . . . . . . . . 805.72 Datos de entrada, ejemplo 4. . . . . . . . . . . . . . . . . . . . . . . . . . . 815.73 Datos de entrada, ejemplo 4. . . . . . . . . . . . . . . . . . . . . . . . . . 825.74 Datos de entrada, ejemplo 4. . . . . . . . . . . . . . . . . . . . . . . . . . 82

ÍNDICE DE FIGURAS xix

5.75 Resultado obtenido, ejemplo 4. . . . . . . . . . . . . . . . . . . . . . . . . 825.76 Resultado obtenido, ejemplo 4. . . . . . . . . . . . . . . . . . . . . . . . . 835.77 Datos de entrada, ejemplo 4. . . . . . . . . . . . . . . . . . . . . . . . . . 835.78 Resultado obtenido, ejemplo 4. . . . . . . . . . . . . . . . . . . . . . . . . 835.79 Resultado obtenido, ejemplo 4. . . . . . . . . . . . . . . . . . . . . . . . . 845.80 Diagrama de secuencia Organizar Invitados. . . . . . . . . . . . . . . . . . 855.81 Diagrama clases Organizar Invitados. . . . . . . . . . . . . . . . . . . . . 855.82 Pantalla inicio rol Invitado. . . . . . . . . . . . . . . . . . . . . . . . . . . 865.83 Diagrama de Casos de Uso para el rol Invitado. . . . . . . . . . . . . . . . 865.84 Confirmar asistencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.85 Diagrama de secuencia Confirmar Asistencia. . . . . . . . . . . . . . . . . 885.86 Diagrama clases Confirmar Asitencia. . . . . . . . . . . . . . . . . . . . . 885.87 Lista completa de invitados. . . . . . . . . . . . . . . . . . . . . . . . . . 895.88 Diagrama de secuencia Lista Invitados. . . . . . . . . . . . . . . . . . . . 895.89 Diagrama clases Lista Invitados. . . . . . . . . . . . . . . . . . . . . . . . 905.90 Posición del invitado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.91 Diagrama de secuencia Posición Invitado. . . . . . . . . . . . . . . . . . . . 915.92 Diagrama clases Posicion Invitados. . . . . . . . . . . . . . . . . . . . . . . 915.93 Acceso al sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.94 Error al acceder al sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . 935.95 Enlace al perfil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.96 Enlace al perfil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.97 Enlace al perfil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.98 Vector de nombres y apellidos. . . . . . . . . . . . . . . . . . . . . . . . . 955.99 Función Random en Ruby. . . . . . . . . . . . . . . . . . . . . . . . . . . 955.100Función SecureRandom en Ruby. . . . . . . . . . . . . . . . . . . . . . . . 955.101Ejemplo de contraseñas generadas. . . . . . . . . . . . . . . . . . . . . . . 96

B.1 Login del Gerente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107B.2 Crear Salon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107B.3 Crear Salon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108B.4 Crear Salon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108B.5 Generar Mesas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108B.6 Generar Mesas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109B.7 Generar Mesas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109B.8 Generar Mesas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109B.9 Crear Boda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110B.10 Crear Boda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110B.11 Alta de Novios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110B.12 Alta de Novios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111B.13 Alta de Invitados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111B.14 Alta de Invitados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112B.15 Elegir Mesas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112B.16 Elegir Mesas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113B.17 Definir Relaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113B.18 Definir Relaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114B.19 Organizar Invitados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114B.20 Organizar Invitados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

xx ÍNDICE DE FIGURAS

B.21 Organizar Invitados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Índice de tablas

2.1 Tabla de objetivos parciales. . . . . . . . . . . . . . . . . . . . . . . . . . 6

4.1 Fase I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 Fase II. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 Fase III. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Fase IV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5 Fase VI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Costes directos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2 Costes indirectos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1 Tabla resumen de los objetivos. . . . . . . . . . . . . . . . . . . . . . . . . 98

xxi

Capítulo 1

Introducción

1.1 Introducción al tema

El día de la boda es uno de los días más importantes de la vida de muchas personas, ya que es

un día muy especial donde se jura amor eterno a la pareja. Aún en los tiempos de crisis que

corren, los enlaces matrimoniales son una de las pocas cosas que no han reducido su número

de celebraciones, es por ello que surge la necesidad de crear una aplicación que facilite el

trabajo a los novios reduciendo así notablemente el esfuerzo y dedicación que tienen que

hacer para la celebración de su boda y reduciendo su nivel estrés y nerviosismo antes de la

boda, debido a que esta aplicación evitará que la pareja tenga que dedicar tiempo a organi-

zar a los invitados, una de las tareas más laboriosas, ya que el sistema lo hará automáticamente.

Sin duda, lo más importante de esta aplicación será la organización automática de los

invitados, funcionalidad que ningún otro portal web gestiona y uno de los quebraderos de

cabeza más grandes para los novios. Esta funcionalidad sentará a los invitados de una misma

mesa en función del nivel de afinidad que tengan entre ellos. Como resultado el sistema dará

una lista provisional de invitados ordenados cada uno en su mesa, la cual podrán utilizar para

configurar la lista definitiva de invitados

En el presente documento se va a abordar la solución al Trabajo Fin de Grado, el cual

trata de dar solución a la gente que tiene problemas a la hora de organizar la celebración de su

enlace matrimonial. El sistema será capaz de gestionar algunos aspectos relacionados con la

celebración de una boda, ésos que tanto cuesta organizar y que siempre se dejan algunos sin

contratar.

2 1.1. INTRODUCCIÓN AL TEMA

Sise introduce en cualquier buscador de Internet gestión de bodas al instante nos aparecen

decenas de portales web, éste es un ejemplo [1], y aplicaciones de escritorio ofreciendo

tareas de gestión de bodas igual que ofrecerá este TFG, pero ninguno de estos portales y

aplicaciones ofrece la funcionalidad que incluirá este TFG para sentar a los invitados de

manera automática, una de las cosas que más quebraderos de cabeza lleva a los novios, ya

que siempre intentan hacerlo lo mejor posible, pero en rara ocasión aciertan y siempre queda

algún invitado descontento con la mesa en la que le sientan.

Con estas ideas claras y con intención de realizar un Trabajo Fin de Grado (TFG) que

permita al alumno ampliar los conocimientos y competencias adquiridas durante los años de

carrera, se toma la decisión de realizar este proyecto.

Una vez decidido el tema del proyecto se evalúan diferentes alternativas para su realiza-

ción. Puesto que se trata de un sistema web, se valoraron diferentes posibilidades a la hora

de elegir el lenguaje de programación, una de ellas fue PHP, sin duda uno de los lenguajes

más utilizados en el desarrollo web, pero finalmente se decidió desarrollarlo con Ruby on

Rails debido a la importancia que está tomando este lenguaje en los últimos años, aunque

el principal motivo fue la motivación personal de aprender un nuevo lenguaje y un nuevo

patrón de diseño. En cuanto a la metodología de desarrollo se sopesó la idea de realizarlo

bajo un modelo pesado, pero rápidamente se desestimó esta idea por la necesidad de ir modi-

ficando requisitos a lo largo del desarrollo del sistema. Por esta razón se decidió utilizar una

metodología ágil, en este caso fue Proceso Unificado Ágil (AUP), una versión simplificada de

Proceso Unificado Rational (RUP). Todos estos aspectos se abordarán con más detalles en los

capítulos 3 y 4.

Este trabajo forma parte del desarrollo del proyecto IMPACTUM: Aplicación del ISBV

en el estudio del impacto de UML en el desarrollo de software en un contexto DSDM-

LPS (Consejería de Educación, Ciencia y Cultura de la Junta de Comunidades de Castilla La

Mancha, y Fondo Europeo de Desarrollo Regional FEDER, PEII-2014-017-A).

CAPÍTULO 1. INTRODUCCIÓN 3

1.2 Estructura del documento

En este apartado se describe resumidamente la estructura de loa apartados de este TFG.

• Capítulo 1. Introducción: En este primer capítulo se realizar una breve introducción

al tema, se menciona el entorno y justificación de la importancia del trabajo abordado.

• Capítulo 2. Objetivos: En este apartado se detallan los objetivos que se pretenden

alcanzar en este Trabajo Fin de Grado.

• Capitulo 3. Estado del arte: En esta sección se detallan los resultados de la búsqueda

bibliográfica realizada para establecer el marco teórico sobre el cual desarrollar el

presente Trabajo Fin de Grado.

• Capítulo 4. Método de trabajo: En este capítulo se explica tanto la metodología de

desarrollo seleccionada (AUP), como las fases de trabajo realizadas para la consecución

de los objetivos del TFG.

• Capitulo 5. Resultados: En esta sección se muestran los resultados obtenidos después

de haber desarrollado la aplicación aplicando al metodología seleccionada.

• Capítulo 6. Conclusiones y propuestas: En este apartado se detallan las conclusiones

obtenidas revisando la consecución de objetivos y se presentan líneas de trabajo y

mejoras que quedan pendientes para el futuro.

• Capítulo 7. Bibliografía: Referencias bibliográfica consultadas.

• Anexos: Lista de Acrónimos utilizados, Manual de Usuario y Código fuente relevante.

Capítulo 2

Objetivos del TFG

En este capítulo se describe el objetivo principal de este Trabajo Fin de Grado, y los objetivos

parciales derivados del objetivo principal.

2.1 Objetivo principal

El objetivo principal de este Trabajo Fin de Grado es el desarrollo de una herramienta que

ayude a los novios a gestionar algunos aspectos de la celebración de su boda. Tanto el Ge-

rente de los salones como los Novios podrán apoyarse en esta aplicación para organizar la

celebración de un enlace.

De este objetivo se derivan otros objetivos parciales que se detallan a continuación.

2.2 Objetivos parciales

Para cumplir con el objetivo principal, es necesario haber satisfecho los siguientes objetivos

parciales.

• Op1. Realización de un plan de proyecto con el que se estimarán costes y tiempo de

realización.

• Op2. Elicitación de requisitos de la aplicación. Dará como resultado el documento

IEEE 830, este documento fue aprobado por el cliente y a partir de estos requisitos se

pudo empezar a realizar el análisis y el diseño de la aplicación.

• Op3. Realización de un diseño consistente de la aplicación como base para empezar a

desarrollar el sistema.

6 2.3. MEDIOS UTILIZADOS

• Op4. Diseño de la Base de Datos para almacenar todos los datos pertenecientes a la

aplicación.

• Op5. Aprendizaje del lenguaje de programación Ruby y el framework Rails, así como

HTML5 y CSS3.

• Op6. Desarrollo de la aplicación en diferentes iteraciones, utilizando las tecnologías

previamente comentadas.

Objetivo Descripción de objetivos

Op1 Plan de proyecto

Op2 Elicitación de requisitos

Op3 Diseño de la aplicación

Op4 Diseño de la Base de Datos

Op5 Aprendizaje de Ruby on Rails, HTML5 y CSS3

Op6 Desarrollo de la aplicación

Tabla 2.1: Tabla de objetivos parciales.

2.3 Medios utilizados

A continuación se detallarán todos los medios que se han tenido al alcance para poder realizar

este Trabajo Fin de Grado.

2.3.1 Medios Hardware

• Ordenador portátil Toshiba SATELLITE L850-138. 4 GB de memoria RAM, 620 GB

de Disco duro y procesador Intel Core i5.

• Monitor Samsung LS22B1150NS de 22 pulgadas para facilitar el trabajo.

2.3.2 Medios Software

• Visual Paradigm for UML 11.0 con licencia de la Escuela Superior de Informática de

Ciudad Real, como herramienta CASE para el diseño de la aplicación, tanto diseño

CAPÍTULO 2. OBJETIVOS DEL TFG 7

funcional como diseño de la Base de Datos.

• Ruby 1.9.3 como lenguaje de programación para la implementación de la aplicación.

• Rails 4.1 como framework de Ruby.

• Bootstrap 3.2, framwork para crear interfaces y diseños web responsive, es decir, que

se adaptan a diferentes tamaños de pantalla, basados en HTML5 y CSS3.

• Sublime Text 2 como editor de texto para desarrollar los diferentes archivos compilables.

• Microsoft Project 2013 para elaborar el plan de proyecto.

• LATEX como procesador de textos junto con el framwork Texmaker para la realización

de la documentación del TFG.

• Dropbox como medio de almacenamiento en la nube y para realizar backups a diario.

Capítulo 3

Estado del Arte

En este apartado se detalla el estado actual de las tecnologías que han servido como base

teórica para la realización de este TFG. Primero se abordará la evolución en el desarrollo web

y las distintas posibilidades para la realización de este proyecto. A continuación se va ver

el patrón Modelo-Vista-Controlador utilizado para el desarrollo del sistema. Por último se

comparan diferentes portales web existentes para gestionar celebraciones de boda.

3.1 Evolución del desarrollo web

El desarrollo web en la última década ha experimentado un gran desarrollo [2]. En la década

de los noventa la web era una sencilla colección de páginas estáticas, documentos et... donde

los usuarios únicamente podían consultarlas. Sin embargo esta evolución ha dado lugar a

páginas complejas con contenidos dinámicos que provienen de bases de datos, lo que permite

la creación de aplicaciones web. Estos sistemas web permiten realizar acciones sencillas

como redactar un email, publicar un catálogo de productos, manejar inventarios, publicar

información restringiendo el acceso a ciertos usuarios, etc.

Una aplicación web típica está organizada en tres capas o niveles (lo cual se adapta

perfectamente al patrón de diseño Modelo-Vista-Controlador), donde el sistema recogerá

datos del usuario, primer nivel (Vista), los enviará al servidor, que ejecutará la lógica del

programa donde se cargarán los datos de la base de datos, segundo y tercer nivel (Controlador

y Modelo respectivamente). El resultado será mostrado al usuario en el navegador de nuevo,

primer nivel.

Desarrollar aplicaciones web tiene grandes ventajas frente a desarrollar aplicaciones de

escritorio. A continuación se enumeran algunas de las más importantes [4]

10 3.1. EVOLUCIÓN DEL DESARROLLO WEB

Figura 3.1: Niveles en una aplicación web.

• Compatibilidad multiplataforma. Una misma versión de la aplicación puede correr sin

problemas en múltiples plataformas como Windows, Linux, Mac, Android etc.

• Actualización. Las aplicaciones web siempre se mantienen actualizadas y no requieren

que el usuario deba descargar actualizaciones y realizar tareas de instalación.

• Inmediatez de acceso. Las aplicaciones web no necesitan ser descargadas, instaladas y

configuradas. Además se puede acceder a estas aplicaciones desde cualquier ordenador

que esté conectado a la red.

• Menos Bugs. Con este tipo de aplicaciones todos los usuarios utilizan la misma versión,

por lo que todos los errores pueden ser corregidos tan pronto como son descubier-

tos. También serán menos propensas a errores ya que no se producen conflictos con

aplicaciones internas del ordenador o con software personal instalado por el usuario.

• Múltiples usuarios concurrentes. Las aplicaciones web pueden realmente ser utilizada

por múltiples usuarios al mismo tiempo.

• Seguridad de los datos. Los datos se alojan en servidores que aseguran la protección de

datos y el funcionamiento constante de las aplicaciones.

Una vez que se ha visto la evolución del desarrollo web y las principales ventajas que

tiene frente a las aplicaciones de escritorio, a continuación se va a presentar los principales

frameworks para desarrollar aplicaciones web, en los que destacan PHP, ASP.Net y Ruby on

Rails.

CAPÍTULO 3. ESTADO DEL ARTE 11

3.1.1 PHP

PHP [7] es un lenguaje de script interpretado en el lado del servidor utilizado para la genera-

ción de páginas Web dinámicas. Fue uno de los primeros lenguajes del lado del servidor que

se podían incorporar directamente en el documento HTML en lugar de llamar a un archivo

externos que procese los datos. Es considerado como uno de los lenguajes más flexibles,

potentes y de alto rendimiento, por lo que gran número de páginas y portales web están

creadas con PHP, uno de los más importantes y conocidos es Facebook.

Como ya se ha dicho PHP es un lenguaje flexible permitiendo la conexión a diferentes

tipos de servidores de bases de datos tanto SQL como NoSQL. MySQL constituye el mejor

sistema para la administración de bases de datos relacionales de modo rápido y sólido, pero

también puede conectarse con PostgreSQL, Oracle, ODBC, DB2, Microsoft SQL Server,

Firebird, SQLite, MongoDB.9, etc.

A continuación se detallan algunas características importantes de PHP, lo que le hacen

que sea tan popular:

• Es un lenguaje multiplataforma.

• Es el servidor el encargado de ejecutar el código y enviar el resultado HTML al

navegador.

• Sintaxis similar a C, fácil de entender y rápido de aprender.

• Rápido. PHP es utilizado como modulo de Apache lo que lo hace extremadamente

veloz.

• Open Source, es decir, código abierto, software distribuido y desarrollado libremente.

• Posee una amplia documentación en su página oficial, entre la cual se destaca que todas

las funciones del sistema están explicadas.

• Permite aplicar técnicas de programación orientada a objetos. Además desde la versión

5 de PHP (PHP5) se permite el manejo de excepciones.


3.1.2 ASP.NET

ASP.NET [9] es un framework creado por Microsoft para desarrollar páginas web dinámicas,

aplicaciones web y sitios web XML. Forma parte del framework .NET por lo que tiene acceso

a las clases del entorno de trabajo .NET. Por ello es compatible con múltiples lenguajes como

Visual Basic, JScript.NET o C#.

En la actualidad ASP.NET soporta tres modelos de programación [13] que son: ASP.NET

Web Pages, ASP.NET Web Forms y ASP.NET MVC. Cada uno de ellos promueve diferentes

metodologías de desarrollo, se adaptan a perfiles de desarrolladores distintos y organizan la

aplicación de forma totalmente diferente. Aunque existan estos tres modelos, no necesaria-

mente son excluyentes entre ellos, sino que se podrá desarrollar aplicaciones combinando

estos modelos, unas partes de la aplicación se desarrollarán con un modelo porque se adapte

mejor a sus características, y otra parte de la aplicación podrá ser desarrollada con otro modelo

de programación.

ASP.NET ofrece varias ventajas [12] importantes referentes a los modelos de programa-

ción web:

• Gran rendimiento gracias a su compilación just-in-time, es una técnica para mejorar

el rendimiento de la compilación de código binario de los sistemas de programación

por medio de la traducción del código binario en código máquina nativo en tiempo de

ejecución.

• Ofrece flexibilidad, es independiente del lenguaje, se puede elegir el lenguaje que mejor

se adapte a la aplicación o implementar varios lenguajes.

• Simplicidad para el programador, permite generar interfaces de usuario, que separan la

lógica de la aplicación del código de presentación.

• Otra característica importante es su escalabilidad. Diseñado para tener en cuenta ca-

racterísticas a medida con el fin de mejorar el rendimiento de entornos agrupados y de

múltiples procesadores.

• Controla y administra los procesos de tal manera que si uno falla, se puede crear uno

nuevo para ayudar a mantener la aplicación disponible.


• Es posible obtener una seguridad completa de las aplicaciones gracias a la autentifica-

ción de Windows.

• Encargado de detectar el tipo de navegador que utiliza el cliente a la hora de realizar

una petición, lo que determina que versión HTML soporta.

Gracias a estas ventajas tuvo una gran aceptación entre los programadores. Sin embargo a

continuación se verán algunas de sus desventajas:

• Se requiere el envío de la página web al completo siempre que se produzca comunica-

ción de un evento con el servidor.

• Siempre que el usuario haga un envío de datos al servidor, debe esperar a que le proceso

se haya completado y el servidor devuelva la respuesta, por lo que se realiza un envío

de información síncrona.

• Transferencia de datos en la red relativamente grande debido a la existencia de un

elemento en los formularios llamado VIEWSTATE.

3.1.3 Ruby on Rails

Ruby on Rails [14] fue creado en 2003 por David Heinemeier Hansson, pese a su juventud se

ha convertido en uno de los framworks más potentes en la actualidad dentro del desarrollo de

aplicaciones web. Esto se refleja en la cantidad de grandes compañías que lo utiliza, las más

importantes: GitHub o Twitter.

Este framework hace uso de Ruby, un lenguaje de programación interpretado y orientado

a objetos. Fue creado en 1993 por Yukihiro Matsumoto y presentado públicamente en 1995.

Tiene características de lenguajes como Perl, Smalltalk, Eiffiel, Ada y Lisp. Su sintaxis está

inspirada en Python y Perl.

Una de las características más importantes de Ruby on Rails es la utilización del patrón

Modelo-Vista-Controlador [15], este patrón de diseño permite separar el código en tres partes:

• Modelo. Son las clases que representan las tablas de la base de datos.

• Vista. Es la lógica de la visualización, o cómo se muestran los datos de las clases del

Controlador


• Controlador. Las clases responden a la interacción del usuario e invocan a la lógica de

la aplicación.

A continuación se muestran características [16] que hacen que Ruby on Rails haya crecido

tanto en tan poco tiempo.

• Don´t repeat yourself filosofía DRY, es un principio de desarrollo software. Su objetivo

es la reducción de fragmentos de código duplicados.

• Siguiendo las convenciones de Rails sobre la configuración se puede escribir una

aplicación con menos código que el necesario para la misma aplicación desarrollada

con cualquier otro lenguaje.

• Clase Active Record para la administración y funcionamiento de los modelos proporcio-

nando una capa objeto-relacional que sigue el estándar ORM. Permite guardar objetos

en la base de datos, además facilita el entendimiento del código asociado a base de

datos.

• Añade la característica Scaffolding, que permite generar la estructura básica necesaria de

manera automática, apoyándose en los componentes del modelo MVC para desarrollar

la aplicación.

• Utilización de Gemas, son plugins y/o código añadido a nuestro proyecto de Ruby on

Rails, que permiten nuevas funcionalidades, nuevas funciones predefinidas o nuevas

herramientas para el desarrollo.

• Permite la integración con otros servicios web como el envío y recepción de emails.

También tiene la posibilidad de incorporar AJAX on Rails.

3.1.3.1 Evolución a lo largo de los años

A continuación se verá la evolución que ha tenido Ruby on Rails frente a los demás lenguajes

presentados.

En esta figura se ve que cuando fue creado en 2003 aún no tiene gran repercusión en el mundo

del desarrollo web, pero a medida que se va avanzando en el tiempo, finales de 2005, el

framework va cogiendo importancia en la comunidad de desarrolladores web.


Figura 3.2: Lenguajes desarrollo web en 2006. [21]


En 2010 ya es un lenguaje consolidado y se ve como sus números se van acercando a los

de PHP en muy poco tiempo.

En el año 2013, Ruby on Rails ya es más popular que PHP, lo que supone un gran avance

para este framework en tan solo diez años. Por su sencillez y rápido aprendizaje parece que

cada vez más programadores web confían en este framework dejando atrás PHP que ha

sufrido una bajada grandísima en sus números en los últimos años.

16 3.2. MODELO-VISTA-CONTROLADOR


3.2 Modelo-Vista-Controlador

El patrón Modelo-Vista-Controlador [24] fue de los primeros en separar funciones a la hora

de desarrollar software, fue descrito para el lenguaje Smalltalk por primera vez en 1979. En

la actualidad es utilizado por multitud de frameworks como ASP.NET, Apache Struts, o Ruby

on Rails entre otros. Gracias a estos numerosos frameworks de desarrollo web que utilizan

este patrón, ha ganado muchos seguidores en los últimos años. Surge de la necesidad de crear

software más robusto y con un ciclo de vida más adecuado. Gracias a este patrón se facilitan

las tareas de mantenimiento y reutilización de código.

El patrón Modelo-Vista-COntrolador trata de separar los datos y la lógica de negocio de

una aplicación de la interfaz de usuario, con esto se consigue crear aplicaciones con bajo

acoplamiento y alta cohesión. A continuación se explica lo que hace cada una de las partes

del patrón:

• Modelo: Es la capa que trabaja con el acceso a la base de datos. Aquí se mantendrá

encapsulada la complejidad de la base de datos, por lo que se tendrá sólo las funciones

que accederán a las tablas y harán los correspondientes select, insert, update, etc.

Gracias a esto se podrán invocar a estas funciones desde otras partes del programa y el

modelo sólo se encargará de procesarlas.


• Vista: Es la capa que contiene el código que va a codificar la visualización de las

interfaces de usuario. Esta capa contendrá todo el código HTML, CSS etc. que nos

permite mostrar la salida. En la vista se trabaja con los datos pero no se acceden a ellos,

si no que los requerirán a los modelos para generar la salida requerida.

• Controlador: Es la capa que contiene el código para responder a las acciones que se

solicitan en la aplicación. Hace de enlace entre el modelo y la vista. Es aquí donde se

codifica toda la lógica de nuestra aplicación.

Flujo de ejecución en MVC

A continuación se procede a explicar el orden de ejecución [27] que tendría una petición con

el patrón Modelo-Vista-Controlador.

Figura 3.5: Diagrama de ejecución MVC

Según se puede ver en el diagrama, éste sería el resultado de la ejecución del patrón MVC:

• El usuario realiza alguna acción en la aplicación que provoca que se envíe una petición.

• El controlador recibe el aviso de la acción solicitada por el usuario. El controlador es

el encargado de gestionar el evento que llega. El controlador accede al modelo para

realizar la acción solicitada por el usuario (por ejemplo, el usuario quiere dar de alta un

nuevo producto en una tienda online, esto provoca que se produzca un insert dentro de

la base de datos).

• Gracias a los datos que devuelve el modelo, es el controlador el encargado de elegir

que vista mostrar al usuario.

18 3.3. PORTALES WEB SIMILARES

• El controlador deja a a los objetos de la vista la tarea de desplegar la interfaz de usuario,

es decir, es la vista quien obtiene los datos del modelo para generar la interfaz donde se

reflejan los cambios en el modelo para resolver la petición del usuario.

• Se actualiza la interfaz de usuario esperando nuevas interacciones con el usuario, dando

lugar a un nuevo ciclo.

3.3 Portales web similares

A continuación se realiza una comparación con varios portales de Internet, todos ellos realizan

funciones para gestionar y planificar los preparativos de una boda. Como en este TFG se

puesto especial hincapié en la organización de los invitados, a continuación se hará una crítica

de estos portales web y en especial de la parte de organización de invitados.

3.3.1 iNovios.es

iNovios [28] es una página web para resolver los problemas que surgen con los preparativos

de una boda. En el inicio de la página esta es la descripción que dan sobre ellos mismos:

contratación del salón de bodas, adornos y decoración floral, fotografía de boda, elección

de las tarjetas de invitación, envío de las tarjetas a los invitados, llamadas de teléfono para

las confirmaciones de asistencia, regalos o listas de bodas, etc. Con iNovios podéis ahorraros

algunas de esas tareas.

Al entrar en la web a modo Demo se puede ver como esta web deja añadir invitados, o

como dejaría elegir invitaciones de boda para posteriormente enviarlas a los invitados, además

de otras funcionalidades. Pero la parte que interesa es la sección de Mesas de invitados. En

esta sección, esta aplicación deja añadir mesas, y en cada mesa que se añade, se pueden sentar

a los invitados que aún no están sentados. El problema está en que los novios deben saber

dónde quieren sentar a cada invitado, en ningún caso se hará de forma automática como lo

hace la aplicación desarrollada en este Trabajo Fin de Grado, por lo que los novios seguirán

teniendo los mismos problemas a la hora de sentar a los invitados.


Figura 3.6: Captura de iNovios.es [28]

3.3.2 WedTool.com

WedTool [29] es otra aplicación online que ofrece una guía completa para organizar una boda.

Destaca por su organizador de mesas, su función para elaborar el presupuesto o por gestionar

la lista de invitados desde la aplicación, además de otras funciones típicas de este tipo de

aplicaciones web. A continuación se verá la captura del organizador de mesas.

Como se puede apreciar en la imagen, se trata de crear una salón añadiendo las mesas que

se quiera, a diferencia de iNovios, éste portal lo hace de forma gráfica. Aquí también se tienen

que organizar a los invitados de forma manual, por lo que no disminuyen los problemas. Este

portal da la opción de mover las mesas a nuestro gusto y añadir y quitar tanto invitados como

mesas tosas las veces que se quiera.

3.3.3 bodas.net

bodas.net [30] es otro ejemplo de aplicaciones web para gestionar web. Muy parecida a

las anteriores, con las mismas funcionalidades, como buscar proveedores para el catering,

20 3.3. PORTALES WEB SIMILARES

Figura 3.7: Captura de WedTool.com [29]

buscar fotógrafos para la realización del vídeo y de las fotografías de la bodas, a parte de las

mencionadas en las anteriores webs como la gestión de invitados, el organizador de mesas, o

la sección para elaborar el presupuesto entre otras. Como se ha hecho en las anteriores se va a

presentar el organizador de mesas.

Figura 3.8: Captura de bodas.net [30]

Este organizador de bodas es muy parecido al organizador de WedTool, como se puede

observar también es gráfico, y la única forma de sentar a los invitados es de forma manual, es


decir, hay que tener antes claro donde se quiere sentar a cada invitado, ésto lleva al mismo

problema que si no se tuviera esta página web, los novios van a seguir sin saber donde colocar

a los invitados.

Capítulo 4

Método de Trabajo

A lo largo de este capítulo se va a detallar el método de trabajo que se ha aplicado para llevar

a cabo el desarrollo de este Trabajo Fin de Grado.

4.1 AUP. Proceso Unificado Ágil

Como metodología de desarrollo se utiliza Proceso Unificado Ágil (AUP). Esta metodología

se trata de una versión simplificada del Proceso Unificado Rational (RUP). AUP Describe de

una manera simple y fácil de entender la forma de desarrollar aplicaciones de software de

negocio usando técnicas ágiles y conceptos que aún se mantienen válidos en RUP.

Se propone esta metodología debido al carácter de este Trabajo Fin de Grado, ya que

es necesario poder modificar los requisitos según se va evaluando y probando las distintas

posibilidades con las que se cuenta para desarrollarlo. Debido a esto, un modelo pesado no se

ajustaría como solución a la metodología de desarrollo.

Sin embargo, si se habla de un modelo ágil se necesitará un equipo de desarrollo con

experiencia para ser llevado a cabo de manera satisfactoria, por lo que una metodología ágil

completa tampoco sirve como solución. Debido a esto, es por lo que se decide elegir una

simplificación de una metodología ágil que se adapte al desarrollo de este TFG.

24 4.1. AUP. PROCESO UNIFICADO ÁGIL

4.1.1 Características de AUP

Iterativo e Incremental

AUP [31] trata de descomponer un proyecto grande en mini-proyectos, cada uno de estos

mini-proyectos es una iteración que ofrece un incremento en el desarrollo del producto inclu-

yendo mejoras o nuevas funcionalidades. AUP se divide en cuatro fases:

• Inicio: Se define el alcance del proyecto, se desarrolla una descripción del producto y

las principales funciones del sistema. Además se estiman costes y plazos y se determina

la factibilidad del proyecto.

• Elaboración: Se identifica y se tratan los riesgos del sistema. También se define y valida

la arquitectura del sistema en profundidad.

• Construcción: Construcción del software de forma incremental. Se implementa el

sistema tomando como base la arquitectura obtenida en la fase de Elaboración. Se

incluirán las distintas funcionalidades del producto en diferentes iteraciones, al final de

cada iteración se obtiene una nueva versión ejecutable del TFG.

• Transición: Implantación del producto en el entorno de los usuarios. En esta fase se

producen las pruebas con el usuario para comprobar que todo está implementado como

lo descrito en la fase de Inicio.

Cada una de estas fases son divididas en iteraciones, las cuales son las que producen los

incrementos en el desarrollo del sistema.

Dirigido por Casos de Uso.

Se centra en las funcionalidades que debe tener el sistema para satisfacer las necesidades del

usuario que interactúa con él. Estas funcionalidades son conocidas como requisitos funciona-

les y gracias a estos requisitos se pueden extraer los casos de uso.

El modelo de casos de uso se utilizan para capturar los requisitos funcionales y para definir

los contenidos de las iteraciones. Cada iteración tomará un conjunto de casos de uso y guiará

CAPÍTULO 4. MÉTODO DE TRABAJO 25

el proceso de desarrollo desde etapas tempranas como el análisis de requisitos hasta las etapas

finales de prueba.

Figura 4.1: Trazabilidad a partir de los Casos de Uso.

Como se ve en la anterior imagen, para llevar a cabo los modelos de análisis y diseño se

puede basar en los casos de uso, para posteriormente realizar la implementación, verificando

que el producto implemente adecuadamente cada Caso de Uso.

4.1.2 Disciplinas de trabajo de AUP

Las disciplinas de trabajo en AUP son ejecutadas en una forma iterativa, definiendo las

actividades que el equipo de desarrollo ejecuta para que el sistema cumpla con las necesidades

del usuario. A continuación se introducen estas siete disciplinas:

• Modelado: Tiene como objetivo entender el negocio, entender cuál es el problema que

se va a abordar e identificar las posibles soluciones viables para dicho problema.

• Implementación: El objetivo es transformar los modelos en código ejecutable y realizar

pruebas básicas (unitarias).

• Pruebas: Su objetivo es realizar una evaluación de los objetivos para asegurar la calidad.

Esto incluye encontrar defectos, validar que el sistema funciona como fue diseñado y

verificar que los requisitos se cumplen.

• Despliegue: La meta de esta disciplina es ejecutar un plan para que el sistema esté a

disposición de los usuarios.

• Gestión de la configuración: Administra el acceso a los artefactos del proyecto. Lleva

un control de versiones y un control de cambios y la gestión de ambos.

26 4.2. EVOLUCIÓN

• Gestión del proyecto: Dirige las actividades que tienen lugar dentro del proyecto. Éstas

incluyen gestión de riesgos, dirección del personal y coordinación.

• Entorno: Apoya los esfuerzos para garantizar la disponibilidad de los procesos, normas

y herramientas cuando sea necesario.

4.2 Evolución

En esta sección se va a tratar de detallar las fases que se ha seguido para la realización de

este Trabajo Fin de Grado. Se va a tratar de explicar las distintas fases que se ha seguido para

llevar a cabo el desarrollo de la aplicación propuesta, se tratará de detallar la finalidad de cada

fase y el resultado obtenido al final de la misma.

4.2.1 Fase I

En esta primera fase se tienen las primeras entrevistas con el cliente con el fin de obtener una

primera lista de requisitos funcionales para empezar a tener conocimiento acerca del dominio

del problema. De estas primeras entrevistas se podrán extraer una lista lo suficientemente

grande como para poder realizar un documento donde establecer estos requisitos y obtener la

aprobación del cliente.

Finalidad Resultado

Primeras entrevistas con el clienteLista previa de requisitos funciona-

les

Realización de documento de requi-

sitos

Realización y aprobación del docu-

mento IEEE 830-1998 para la reco-

pilación de requisitos

Tabla 4.1: Fase I.

4.2.2 Fase II

En esta fase se ha tratado la elaboración de los distintos diagramas UML para modelar el

sistema y así poder ver y explicar los procesos que contendrá la aplicación al cliente y, que

éste de su aprobación. También se realiza el diagrama E/R para modelar la base de datos


viendo así fácilmente las tablas y sus campos además de la relación que existente entre estas

tablas dentro de la base de datos.

Finalidad Resultado

Elaboración del diagrama de Casos

de Uso

Diagramas de Casos de Uso que des-

criben las relaciones y las dependen-

cias entre un grupo de casos de uso

y los actores participantes en el pro-

ceso

Realización del diagrama de ClasesDiagrama de Clases para describir

la estructura de nuestra aplicación

Realización del diagrama de Secuen-

cia

Diagramas de Secuencia que descri-

ben la interacción entre los objetos

de nuestro sistema

Elaboración del diagrama E/RDiagrama E/R para definir las enti-

dades del sistema y sus relaciones

Tabla 4.2: Fase II.

4.2.3 Fase III

Una vez modelado el sistema es hora de empezar a desarrollarlo. Como Ruby on Rails es un

lenguaje nuevo para el alumno, se decido hacer algunos cursillos por Internet que no llevarán

más de dos semanas realizarlos y que suponen un gran beneficio en cuanto ahorro de tiempo

a la hora de desarrollar el sistema. El haber cursado la asignatura de desarrollo web por parte

del alumno, ha resultado más sencillo es aprendizaje de este lenguaje por la similitud con

otros lenguajes y por no partir de cero en cuanto al aprendizaje del desarrollo web.

Finalidad Resultado

Aprendizaje y primeros pasos con

Ruby on Rails

Realización de primeras aplicacio-

nes web que me permiten adqui-

rir conocimientos necesarios para la

realización de este Trabajo Fin de

Grado

Tabla 4.3: Fase III.

28 4.2. EVOLUCIÓN

4.2.4 Fase IV

Una vez realizado el análisis y diseño de la aplicación, se decide dividir todo el trabajo en

varias iteraciones. A continuación se enumeran las distintas iteraciones que se han planificado

para el desarrollo y realización de este Trabajo Fin de Grado. Estas iteraciones se explicarán

con más detalles en el siguiente capítulo.

Finalidad Resultado

Iteración 0Realización del anteproyecto y el

plan de proyecto

Iteración 1 Desarrollo del módulo del Gerente

Iteración 2 Desarrollo del módulo de los Novios

Iteración 3Desarrollo del módulo de los invita-

dos

Iteración 4Mejora de la interfaz de la aplica-

ción e inclusión de otros requisitos

Tabla 4.4: Fase IV.

4.2.5 Fase V

En esta fase del trabajo se realiza el desarrollo de cada iteración donde se llevan a cabo una

serie de actividades para cumplir los objetivos de cada iteración:

• Modelado: El objetivo es entender el problema de dominio que se aborda en el proyecto

e identificar las soluciones para la satisfacción del problema.

• Implementación: El objetivo de esta disciplina es transformar su modelo (s) en código

ejecutable y llevar a cabo un nivel básico de las pruebas.

• Pruebas: El objetivo de esta disciplina es ejecutar una evaluación objetiva para asegurar

la calidad.

• Despliegue: Se planifica la entrega del proyecto.

• Administración de la configuración: Control y administración de los cambios del

proyecto.


• Administración del proyecto: El objetivos es la dirección de las actividades a lo largo

del proyecto.

• Entorno: Asegurar que el proceso es apropiado, y que las guías y herramientas estén

disponibles cuando se necesiten.

4.2.6 Fase VI

En esta última fase se tienen las últimas reuniones con el cliente para enseñar el producto

final y poner en común los últimos detalles de la aplicación. De estas últimas reuniones se

debe sacar el visto bueno del cliente acerca de la aplicación desarrollada.

Finalidad Resultado

Tener las últimas reuniones con el

cliente

producto final con el aprobado del

cliente

Tabla 4.5: Fase VI.

4.3 Marco Tecnológico

A continuación se explican las herramientas utilizadas para desarrollar este Trabajo Fin de

Grado

Figura 4.2: Herramientas utilizadas.

30 4.3. MARCO TECNOLÓGICO

4.3.1 Visual Paradigm for UML

Visual Paradigm [36] es una herramienta CASE utilizada para el desarrollo de aplicaciones

software utilizando el modelado UML. Herramienta para apoyarse en ella durante todo el

ciclo de vida del software, desde la elicitación de requisitos con su modelado de requisitos

hasta la generación de código y documentación pasando por el modelado de la base de datos

y por las etapas de diseño gracias a sus diagramas de Casos de Uso, diagramas de clase

etc. Todos los diagramas UML de este Trabajo Fin de Grado han sido generados con Visual

Paradigm fot UML 11.0.

4.3.2 LATEX

LATEX [37] es un sistema de composición de documentos de texto orientados la creación

de documentos técnicos y científicos que presenten una alta calidad tipográfica. Latex Está

formado por órdenes construidas a partir de comandos de TeX, esto nos permite escribir texto

sin fijarnos en el formato, ya que el formato se obtiene gracias a las instrucciones que obtiene.

La elaboración de un documento con LATEX se realiza en dos etapas. La primera elaborar

el fichero fuente mediante un editor, en este caso se ha utilizado Texmaker, en este fichero

fuente es donde tendrá que contener el texto que imprimirá y las ordenes para dar formato al

texto. Y la segunda etapa que se trata de procesar el archivo fuente donde un compilador, en

este caso MikTex, compila el fichero dejándolo listo para mostrar por pantalla.

4.3.3 Ruby on Rails

Para el desarrollo de este Trabajo Fin de Grado se decidió utilizar Ruby on Rails, ya explicado

en la sección 3.1.3.

4.3.3.1 Bootstrap

Bootstrap [38] es un framework que combina HTML5 con CSS3 y JavaScript para diseño de

aplicaciones web. Permite la adaptación de la interfaz dependiendo del tamaño del dispositivo

en el que se visualice, esto es lo conocido como diseño adaptativo.


Gracias a Bootstrap se pueden crear diseños simples e intuitivos lo que da agilidad a la

hora de cargar y adaptar la aplicación a los dispositivos.

4.3.3.2 MySQL

MySQL [39] es uun sistema gestor de bases de datos para bases de datos relacionales. Destaca

por su gran adaptación a diferentes entornos de desarrollo y por su integración en distintos

sistemas operativos. Para realizar este Trabajo Fin de Grado se decidió MySQL debido a

que es una de las mejores bases de datos para el desarrollo de aplicaciones web gracias a su

rapidez en la lectura de datos.

4.3.3.3 Sublime Text 2

Sublime Text 2 [40] es un editor de texto y editor de código fuente. Se eligió este editor de

texto para la elaboración de código fuente de este trabajo por su características, desde el

soporte nativo de Ruby como el autocompletado, marcado de llaves, coloreado de sintaxis o

el minimapa que posee para la previsualización del archivo en desarrollo.

4.3.4 Microsoft Project

Microsoft Project [41] es una herramienta para la administración de proyectos desarrollado

por Microsoft. Entre sus características están el desarrollo de planes, asignación de recursos a

tareas, dar seguimiento al progreso, administrar presupuesto o analizar cargas de trabajo. Se

ha utilizado esta herramienta para realizar el seguimiento y gestión de este Trabajo Fin de

Grado.

Capítulo 5

Resultados

A continuación se detallan las distintas iteraciones que se presentaron en el capítulo anterior

y que se han realizado para el desarrollo de la aplicación que tendrá como resultado este

Trabajo Fin de Grado.

5.1 Iteración I

En esta iteración se lleva a cabo la búsqueda de información acerca de las tecnologías a utilizar

para la elaboración del anteproyecto. También se llevan a cabo las primeras entrevistas con el

cliente para conocer el dominio del problema y poder llevar a cabo la primera captación de

requisitos.

Una vez realizado estas primeras tareas, se procede a realizar un estudio de viabilidad del

proyecto para saber si el trabajo a realizar resultará exitoso o se tienen que plantear soluciones

alternativas. Además se realizará la primera planificación del proyecto donde se estimarán

costes en cuanto a tiempo y presupuesto.

5.1.1 Primeras entrevistas con el cliente

En febrero de 2014 se tiene una primera toma de contacto con la idea de la aplicación. Se

ponen en común las ideas acerca del alcance que se debe tener la aplicación. De esta primera

entrevista el alumno saca sus primeras conclusiones sobre lo que debe contener la aplicación

por lo que se realiza la primera versión del documento IEEE 830.

34 5.1. ITERACIÓN I

En marzo de 2014 en la segunda entrevista que se realiza por ambas partes se discute

acerca del contenido del Estándar anteriormente citado. Tras algunas modificaciones menores,

el cliente da el visto bueno a la primera captación de requisitos por lo que se procede a

elaborar el documento del Anteproyecto.

En mayo de 2014 tras la presentación del Anteproyecto se produce la aceptación del

mismo y por tanto luz verde para empezar a desarrollar la aplicación.

Tras la aprobación del Anteproyecto y para comenzar a desarrollar el Trabajo Fin de

Grado se realiza un primera versión de un Diagrama de Casos de Uso y un Diagrama Entida-

d/Relación que fue aceptado por el cliente.

A continuación se adjuntan dichos diagramas presentados:

Figura 5.1: Casos de Uso para Gerente.

CAPÍTULO 5. RESULTADOS 35

Figura 5.2: Casos de Uso para Novios.

Figura 5.3: Casos de Uso para Invitados.

Según se iba avanzando en el desarrollo del sistema se han ido modificando requisitos por

lo que se han producido modificaciones en los diagramas que se mostrarán cuando se detalle

la iteración correspondiente.


Figura 5.4: Diagrama ER de la apliación.

5.1.1.1 IEEE 830

A continuación se expone el documento IEEE 830 que se elaboró para la elicitación de

requisitos.

Introducción

En este documento se trata de estandarizar la captación de requisitos del sistema a desarrollar.


Propósito

Para la captación de requisitos he decidido utilizar el estándar IEEE 830, de esta forma todos

los requisitos se especifican de forma clara y concisa.

Ámbito del Sistema

El sistema a desarrollar ser llama XXX y realizará las siguientes tareas:

• La principal tarea será la organización automática de los invitados en las distintas mesas

del salón según la afinidad que tenga un invitado con el resto de la mesa. Para ello

los invitados primero tendrán que confirmar su asistencia, y una vez que los Novios

soliciten la organización automática, el sistema debe ser capaz de organizar a todos los

invitados en las mesas del salón según la afinidad que tengan entre ellos.

• El sistema debe permitir al Gerente la gestión de salones y las mesas que contendrán

esos salones. Una vez dentro del sistema, el Gerente podrá añadir, modificar o eliminar

salones del sistema. También podrá generar o eliminar mesas dentro de un salón

seleccionado.

• Una vez que se dé de alta un nuevo enlace, donde se indicará el número de invitados que

tendrá, la aplicación debe asignar el salón más pequeño posible que esté disponible y

que tenga un aforo lo suficientemente grande como para que quepan todos los invitados.

• El sistema debe guardar en la base de datos la confirmación de los invitados a la

boda. Una vez que cada invitado guarde su confirmación de asistencia, el sistema debe

almacenarlo para después poder realizar la organización automática sin problemas.

• La aplicación dará la posibilidad de elegir las mesas que los Novios quieran, siempre y

cuando existan en el salón adjudicado para la celebración del enlace.

El sistema tiene los siguientes objetivos:

• Ayudar a los novios a la organización de los Invitados, ya que el sistema los organizará

de forma automática según la afinidad que tengan entre ellos.

• Gestionar algunos aspectos relacionados con la celebración de una boda, desde la

distribución de las mesas o la creación de salones hasta dar de alta nuevos invitados, los


cuales podrán confirmar su asistencia o consultar su posición, es decir, la mesa que se

le ha asignado.

• Mantener informado al gerente de las bodas que se van a celebrar en sus salones, además

de informar las bodas que se celebrarán dentro de un salón.

Visión general del documento

Este sistema aporta una nueva idea respecto a otros sistemas ya desarrollados, es la posibilidad

de organizar a los invitados de forma automática de forma que en una misma mesa estén

sentados invitados con una afinidad alta. Además de gestionar todos los elementos típicos de

una boda. Este documento especifica un conjunto de normas, actividades y requisitos que debe

cumplir el sistema para adaptarse a las necesidades del cliente, ayudando a la elaboración del

sistema.

Descripción general

Perspectiva del producto

El sistema que se va a diseñar no necesitará de otros sistemas para su funcionamiento,

simplemente la interacción entre la persona que lo utilice y el sistema. Para realizar la

interacción entre la persona y el sistema se va a diferenciar distintas interfaces según el rol

que tenga el usuario en el sistema.

• Interface de los Novios.

• Interface del Gerente.

• Interface de los Invitados.

Todas estas interfaces deben ser claras e intuitivas de forma que todos los usuarios puedan

utilizarlas sin una formación previa.

Características de los usuarios

• Novios: Tienen la función de añadir a todos los Invitados en el sistema. Además, como

se mencionó anteriormente, son los encargados de elegir las mesas del salón, además

son los únicos que podrán definir las relaciones existentes entre los grupos de invitados.


• Gerente: Encargados de dar de alta nuevos enlaces y a los novios que se casarán en

esos enlaces, además tiene la función de añadir, modificar o borrar salones y generar o

eliminar las mesas de esos salones.

• Invitados: Encargados de confirmar su asistencia a la boda. Podrán consultar su locali-

zación dentro del salón o la lista de invitados completa.

Restricciones

El sistema debe cumplir con la ley de protección de datos. Nunca podrán ser revelados los

datos proporcionado de los Novios y de los Invitados.

Para desarrollar el sistema se va utilizar Ruby como lenguaje de programación bajo el

framework Rails. Para la base de datos se utilizará MySQL y para realizar las vistas se utilizará

HTML5 y CSS3.

Para lograr un sistema seguro se debe proporcionar datos de acceso, tanto usuario como

contraseña, a Invitados, Novios y Gerente. Además las distintas interfaces con las que contará

el sistema deberán ser intuitivas para una mayor comodidad del usuario.

5.1.2 Estudio de viabilidad

Con el presente análisis se pretende determinar el éxito o fracaso del proyecto presentado, con

el fin de decidir la viabilidad de la idea presentada y con la pretensión de ponerlo en marcha.

Para desarrollar este estudio de viabilidad se tendrán en cuenta las siguientes áreas:

• Viabilidad económica: Evaluación de los costos del desarrollo.

• Viabilidad técnica: Estudio de los conocimientos y aptitudes adquiridas en los años

de carrera.

• Viabilidad legal: Determinar cualquier posibilidad de infracción o responsabilidad

legal.


5.1.2.1 Viabilidad económica

El análisis económico es una de las tares más complejas a la hora de realizar el estudio de

viabilidad debido a que los costos a la hora de desarrollar software muchas veces resultan

intangibles, pero a la vez resulta una tarea muy importante debido a que gracias a ésta depende

la posibilidad de éxito del proyecto.

Para realizar el estudio económico se decide separar los gastos en diretos e indirectos

para evaluar la posibilidad de realización de este Trabajo Fin de Grado.

Costes directos

Son aquellos gastos fijos que habrá que desembolsar como inversión inicial o los costes fijos

que se tendrán todos los meses. En este caso el único desembolso inicial fue la compra de

Monitor Samsung LS22B1150NS de 22 pulgadas y el coste fijo mes tras mes será el sueldo

de los trabajadores que realizarán este Trabajo Fin de Grado. A continuación se especifican

todos los gastos en la tabla:

Gasto Coste

Sueldo Desarrollador Software 500 ¤

Monitor Samsung 120 ¤

Tabla 5.1: Costes directos.

Como únicamente hay un desarrollador, no habrá que multiplicar ese sueldo, por lo que

cada mes se estima el gasto de un único desarrollador 500 ¤.

Costes indirectos

Son los gastos que no están relacionados directamente con las actividades o resultados, sino

con el conjunto de ellos. En la siguiente tabla se especifican todos los gastos de este tipo:


Gasto Coste

Luz 45 ¤

Calefacción 40 ¤

Alquiler piso 180 ¤

Internet 40 ¤

Diferente material de oficina 10 ¤

Tabla 5.2: Costes indirectos.

Coste total

A continuación se detalla el coste total sumando ambos costes durante la duración del proyecto.

El proyecto tiene una duración de 8 meses por lo que el coste por sueldo del desarrollador

será: 500 ¤* 8 meses = 4.000 ¤totales. A esto habría que sumar los 120 ¤de la inversión

inicial para la compra del Monitor. En total se tienen 4.120 ¤de gastos directos.

El total de gastos indirectos será aproximadamente de 315 ¤al mes, si la duración del

proyecto es de 8 meses se tiene: 315 ¤* 8 meses = 2520 ¤.

Asumir estos gastos no sería viable, pero se tiene en cuenta que el desarrollador no perci-

birá ningún sueldo ya que se hace por cuenta propia, y los gastos indirectos se asumen por

cuenta propia gracias a la beca MEC. Por lo que el proyecto solo tendrá gasto de la compra

del monitor, responsabilidad por parte del alumno por lo que no afectará al coste del proyecto.

Concluión, el proyecto se hará a coste cero.

5.1.2.2 Viabilidad técnica

El análisis técnico consiste en realizar una evaluación del software y personas disponibles y si

tienen las capacidades técnicas requeridas.

Para la realización de este Trabajo Fin de Grado se cuentan con las siguientes herramientas

de trabajo:


• Ordenador portátil Toshiba Satellite L850-138.

• Monitor Samsung LS22B1150NS de 22 pulgadas.

• Microsoft Windows 8.1.

• Micorsoft Office 2010.

• Visual Paradigm 11.0.

• Texmaker

• Editor Sublime text 2.

• Editor Notepad ++.

• WAMPServer

• Framework Ruby on Rails.

• Framework Bootstrap.

• Navegador Google Chrome.

Como se puede observar la mayoría del software es Opensource, aunque el software pri-

vativo cuenta con la licencia en su mayoría de la Universidad de Castilla-la Mancha. Gracias

a que se cuenta con todo este software se puede decir que no hay problema para desarrollar

este trabajo.

En cuanto a las capacidades técnicas de la persona encargada de realizar este proyecto, el

alumno ha adquirido el conocimiento necesario a lo largo de sus años de estudios universita-

rios y con las diferentes asignaturas cursadas, para desarrollar el Trabajo Fin de Grado.

Viendo que ambos análisis son favorables y se tiene, tanto los conocimientos, como el

software necesarios, se puede decir que el estudio de la viabilidad técnica es favorable para

emprender este proyecto.


5.1.2.3 Viabilidad legal

En este estudio se asegura que el proyecto no infringe ninguna norma o ley establecida.

Además se debe garantizar el respeto a los acuerdos relacionados con el ámbito del proyec-

to. También se deben tener en cuenta que las licencias para el software empleado debe ser

auténticas para evitar inconvenientes legales futuros. Y es por estas razones por las que se

ha decidido poner atención en la Ley Orgánica 15/1999 de Protección de Datos de Carácter

Personal.

Puesto que se almacenarán datos personales tanto del gerente como del novio y de

los invitados, se aplica un nivel de seguridad básico de la LOPD, ya que la aplicación de

la LOPD con carácter general es de aplicación a todo tratamiento de datos de carácter personal.

A la hora de dar de alta un nuevo usuario, ya sea novio o invitado, se recogen los datos a

un mayor de edad por lo que cumple todos los requisitos del artículo 5 de la LOPD. En todo

momento se respetará el derecho de acceso, rectificación, cancelación u oposición (ARCO)

garantizado que el usuario dado de alta es exclusivamente el interesado.

Existe la posibilidad también de dar de alta a menores de catorce año en este caso, y según

el artículo 13 del RDLOPD, sólo se podrán dar de alta previo consentimiento de los padres o

tutores.

5.1.3 Plan de proyecto

Una vez realizado el Estudio de viabilidad y ver que es factible realizar el proyecto, se debe

realizar una planificación del proyecto inicial.

A continuación se muestra el diagrama de Gantt elaborado para la planificación inicial del

proyecto. teniendo en cuneta que el desarrollo del proyecto se ha divido en cuatro iteraciones,

que se empieza a desarrollar el día 1 de septiembre de 2014, y teniendo en cuenta la dificultad

de cada iteración, quedaría así la planificación inicial:

a


Figura 5.5: Planificación inicial. Diagrama de Gantt.

a

a

a

a

a

a


5.2 Iteración II

En esta iteración se desarrolla el módulo del rol que se ha llamado Gerente. Este usuario será

el dueño de los salones donde se celebrarán los enlaces. En esta iteración se han desarrollado

todas las funcionalidades que desempeña este usuario.

A continuación se adjunta imagen con todas las acciones que podrá realizar el Gerente:

Figura 5.6: Acciones del gerente.

Todas estas acciones se definieron anteriormente en la captura de requisitos y fueron

validadas por el cliente mediante el diagrama de casos de uso del actor Gerente:

5.2.1 Crear Boda

Uno de los primeros pasos que debe realizar el gerente del salón para utilizar la aplicación

será la creación de enlaces matrimoniales. En este módulo se dará de alta una nueva boda

indicando la fecha de la misma y el número máximo de invitados que asistirán para que

se le asignen una salón que esté disponible automáticamente. Se pide que se introduzca el

número de invitados para la asignación automática del salón donde se celebrará la boda, dicha

asignación automática se explica a continuación.

Uno de los requisitos del cliente era la asignación del salón más pequeño posible cuyo

aforo sea lo suficientemente grande para que entren todos los invitados. Se tiene en cuenta

que un mismo salón no puede acoger dos bodas un mismo día. Considerando estos aspectos

se llega a la conclusión que para la asignación automática del salón se tienen en cuenta dos

aspectos, la fecha del enlace y el número de invitados. Si se crean dos bodas para un mismo

día y con un número similar de invitados, en principio a las dos se les podría asignar un

46 5.2. ITERACIÓN II

Figura 5.7: Casos de Uso para Gerente.

mismo salón, esto no sería posible ya que a la primera boda de darse de alta se le asignaría el

salón más pequeño posible cuyo aforo sea lo suficientemente grande para que entren todos

los invitados y la siguiente boda se le asignaría el siguiente salón más pequeño donde entren

todos los invitados.

A continuación se pone un ejemplo y se ve como con el mismo número de invitados y la

misma fecha, a cada boda se le asigna un salón diferente:

Figura 5.8: Boda ejemplo1.

Sin embargo surgen varios problemas a la hora de dar de alta los enlaces y asignar


Figura 5.9: Boda ejemplo2.

automáticamente los salones:

• El primer problema surge cuando todos los salones están cogidos para una misma fecha.

En este caso nos aparece un mensaje de alerta avisando que en esa fecha no hay salones

disponibles. Si aparece este error no dejará dar de alta ese enlace en esa fecha, por lo

que se debe modificar la fecha hasta encontrar una donde esté algún salón libre.

Figura 5.10: Error salones no disponibles.

• El segundo problema surge a la hora de dar de alta una boda con un número de invitados

superior al aforo de todos nuestros salones. En este caso se muestra un mensaje avisando

de que no se dispone de un salón tan grande por lo que no nos dejará dar de alta a este

enlace con este número de invitados.

Figura 5.11: Error numero invitados grande.

Otro de los requisitos a la hora de crear un nuevo enlace era la posibilidad de dar de alta a

los novios desde la misma página de alta del enlace. Para ello se da la posibilidad de crearlos

en el mismo momento de dar de alta el enlace o de darles de alta en otro momento.

Si se decide dar de alta a los novios cuando se crea el enlace, aparecerá una ventana modal

para cada novio. En la ventana aparecerá un formulario sencillo que se rellena con los datos

del novio y se presiona el botón Guardar cambios para dar de alta a los novios y guardar los

datos en la base de datos.


Figura 5.12: Crear Boda.

Figura 5.13: Alta Novio.

Si no se quiere dar de alta a ninguno de los dos novios en el instante de dar de alta el

enlace, se puede hacer sin problemas, simplemente tendrá que dar de alta a los novios en otro

momento para el enlace que desee. Para esta opción simplemente se introduce la fecha y el

número de invitados para ese enlace.

Figura 5.14: Datos de enlace.

A la hora de meter la fecha del enlace, no se puede introducir cualquier fecha, si no que la


fecha mínima para introducir será la fecha actual ya que se considera innecesario poder dar

de alta bodas con fechas pasadas.

Hasta que no se dan de alta a los Novios, los enlaces aparecen con el nombre de los novios

vacíos hasta que éstos no sean dados de alta. A continuación se muestra como aparecen en el

listado de enlaces que posee el administrador los enlaces con novios dados de alta y enlaces

sin novios dados de alta.

Figura 5.15: Enlace con Novios.

Figura 5.16: Enlace sin Novios.

5.2.1.1 Diagrama de secuencia

A continuación se muestra el diagrama de secuencia que muestra la interacción de los objetos

que influyen en la creación de una boda.

Figura 5.17: Diagrama de secuencia Creación de boda.


5.2.1.2 Diagrama de clases

A continuación se muestra el diagrama de las clases que intervienen en la creación de un boda

nueva.

Figura 5.18: Diagrama de clases Creación de boda.

5.2.2 Alta de Novios

Como se ha explicado en n la sección de Crear boda, hay dos opciones, o dos momentos, en

los que se pueden crear a los novios:

• La primera opción es dar de alta a los novios al mismo tiempo que se crea el enlace, en

este caso aparece una ventana modal para crear a cada uno de los novios.

• La segunda opción es crear primero el enlace y después dar de alta a los novios eligiendo

el enlace que se le asignará al novio dado de alta:

Como se puede observar ambos formularios son iguales, con la única diferencia que en la

segunda opción se tendrá que elegir el enlace asociado debido a que no se da de alta a los

novios desde la página de alta de enlaces.

Esta vez como requisito impuesto por el cliente y algo totalmente lógico, una boda sólo

podrá tener dos novios, es decir, si se da de alta un novio eligiendo una boda la cual ya tiene


Figura 5.19: Alta Novio 1.

Figura 5.20: Alta Novio 2.

sus dos novios, el sistema nos lanzará un mensaje de error impidiendo que se inserte en base

de datos al novio.

Figura 5.21: Error 1 en Alta de novios.

Otro de los requisitos era la unicidad del email de los novios, ya que se pensó como caso

muy excepcional la posibilidad de que una misma persona se case dos veces en un mismo

restaurante. De ser así se hablaría con el gerente del restaurante para solucionar el problema.

Debido a la unicidad se hacen las comprobaciones correspondientes para comprobar este


requisito en base de datos y si existe el email se lanza un mensaje de error impidiendo la

inserción en base de datos.

Figura 5.22: Error 2 en Alta de novios.


Diagrama de secuencia que muestra la interacción de los objetos que intervienen en el Alta

satisfactoria de un nuevo novio.

Figura 5.23: Diagrama de secuencia Alta de novios.


Diagrama de las clases utilizadas para el Alta de Novios.

5.2.3 Administración de Salones

En esta sección se explica como el gerente podrá dar de alta todos los salones de los que

disponga su establecimiento. También tiene la posibilidad de modificar sus características, es

decir, si por algún casual la empresa decide hacer obras en los salones y aumenta o disminuye

la capacidad para albergar personas, el aforo, desde aquí se podrá modificar. Si se decide


Figura 5.24: Diagrama de clases Alta Novios.

también dejar de ofertar ese salón el gerente podrá eliminar el salón de la lista de salones.

Para administrar los salones simplemente se tendrá que pinchar sobre la opción Salones

del menú disponible para el administrador. Una vez dentro, aparecerá la lista completa de

salones que se están ofertando, es decir, que están dados de alta en la base de datos.

Figura 5.25: Lista de salones.

Se ve como el administrador podrá realizar las siguientes acciones:

• Crear salón: Para crear un salón lo único que debe hacer el administrador del salón es

introducir el nombre y el aforo del salón a crear.


Figura 5.26: Crear salón.

• Consultar salón: Se pueden consultar las características de un salón existente donde

se especifican el nombre, y el aforo del salón seleccionado. Además se pueden ver las

bodas que se celebrarán en ese salón, a continuación se muestra un salón como ejemplo

en el que se celebran varios enlaces.

Figura 5.27: Consultar salón.

• Editar salón: Si el gerente de los salones decide modificar los salones por cualquier

razón lo podrá hacer desde aquí, ya sea modificar los nombre por marketing o modificar

el aforo por obras.

Figura 5.28: Editar salón.

• Eliminar salón: Si el gerente decide dejar de ofertar cualquier salón y desea eliminarlo

de la lista de salones tendrá que pinchar en Eliminar en el salón a eliminar. Nos


aparecerá una ventana de aviso para asegurar que es ese el salón que se quiere eliminar

y no ha sido un error.

Figura 5.29: Eliminar salón.

En esta sección no hay mucho más que comentar, a continuación se muestran los diagramas

realizador para el diseño de este apartado.


Diagrama de secuencia que muestra la interacción de los objetos que intervienen a la hora de

crear satisfactoriamente de un nuevo Salón.

Figura 5.30: Diagrama de secuencia Crear Salón.


Diagrama de las clases utilizadas para la administración de salones


Figura 5.31: Diagrama clases Administración Salones.

5.2.4 Administración de Mesas

En este apartado del módulo del Gerente del salón se muestra la generación y eliminación de

mesas en cada uno de los salones. En un principio se pensó en un diseño para este apartado

donde se mostraban mesa por mesa todas las mesas de todos los salones.

Figura 5.32: Listado de mesas antiguo.

Como se puede observar no es agradable para el usuario ver todas y cada una de las mesas

dadas de alta, por lo que se acordó con el cliente estudiar una forma diferente de mostrar las

mesas y a continuación se muestra la mejor solución encontrada.

Lo primero se tendrá que hacer es escoger un salón. Esto se hace para mostrar solamente


las mesas de ese salón y si se quiere añadir o eliminar las mesas de ese salón. Esto es debido

a que el Gerente de los salones querrá eliminar o generar mesas de un salón nuevo o que se

haya modificado recientemente. Así que esta será la primera pantalla a la hora de ver las mesas:

Figura 5.33: Mostrar según el salón elegido.

Una vez que se elige el salón nos redirecciona a una página nueva donde muestra las

mesas que contiene ese salón. En vez de mostrar todas las mesas sueltas, lo que se decidió

realizar fue la agrupación de las mesas por número de comensales quedando una interfaz

mucho más amigable para el usuario, en este caso el Gerente del salón.

Figura 5.34: Listado de mesas agrupadas.

En este apartado el dar de alta a las mesas se hace de forma diferente. Se pensó que dar de

alta una por una a las mesas iba a ser una tarea demasiado engorrosa por lo que se ha realizado

un generador de mesas, es decir, el Gerente del salón tendrá que introducir el número de

mesas que desea dar de alta y el número de comensales que tendrá cada una de esas mesas.

Todo esto aparecerá en una ventana modal para agilizar el proceso.

Como se puede observar el introducir así las mesas agiliza mucho el alta de las mesas.

Se decidió realizar el mismo proceso para eliminar las mesas, cuando se quiere eliminar un

número de mesas, aparecerá una ventana modal pidiendo el número de mesas a eliminar y el

numero de comensales de esas mesas.


Figura 5.35: Generador de mesas.

Figura 5.36: Eliminar mesas.

Al igual que el generador de mesas, el eliminar de esta forma las mesas ahorra tiempo al

Gerente a la hora de eliminar mesas, sin tener que eliminar mesa a mesa.

Con esta última funcionalidad surge el problema de introducir mesas que no estén dadas

de alta, es decir, el gerente puede introducir mesas con un número de comensales que no estén

en la base de datos, en este caso aparecerá un mensaje de alerta diciendo que no existen este

tipo de mesas, y por lo tanto al no estar dadas de alta en la base de datos, no se eliminarán.


Figura 5.37: Error mesas no encontradas.



generar satisfactoriamente nuevo Mesas.

Figura 5.38: Diagrama de secuencia Generar Mesas.


Diagrama de las clases utilizadas para la administración de mesas

a

a

a


Figura 5.39: Diagrama clases Administración Mesas.

a

a

a

a


5.3 Iteración III

Una vez que se ha dado de alta a los novio para un enlace, estos ya podrán entrar en el sistema.

Los novios deben entrar al sistema mediante su email y su contraseña. La primera pantalla

que verán será la pantalla de inicio de la interfaz que se ha llamado BienvenidaNovios. En

esta primera pantalla aparecerán todas las funcionalidades que podrá realizar un Novio que

contrate el servicio de esta aplicación.

En esta parte del desarrollo se ha dividido en tres fases:

• La primera fase es cuando el novio entra las primeras veces al sistema. Aquí el novio

debe dar de alta a los invitados a la boda y elegir las mesas que quiere que estén

presentes en el salón. Hasta que alguno de los dos novios no elija las suficientes mesas

como para sentar a todos los invitados, el sistema no le dejará realizar ninguna de las

otras acciones.

Figura 5.40: Primera pantalla inicio Novios.

• La segunda fase empieza cuando los novios han elegido todas las mesas para que

puedan sentarse todos los invitados. En este momento el sistema habilita la opción

para definir las relaciones que existen entre los invitados. Hasta que no se definan estas

relaciones el sistema no dejará avanzar hasta la tercera fase.


• La tercera fase para los novios empieza cuando han elegido las suficientes mesas como

para que quepan todos los invitados a la boda y han definido las relaciones existentes

entre ellos. En este momento el sistema dejará a los novios realizar los siguientes pasos

para organizar a los invitados. Para que puedan

62 5.3. ITERACIÓN III


En la imagen se puede ver como han aparecido los dos nuevas funcionalidades para los

novios una vez que se hayan elegido las mesas.

A continuación se puede ver el diagrama de casos de uso que se definió en la captura de

requisitos

Figura 5.43: Casos de uso para el rol Novio.

Ahora se va a desglosar una por una las funcionalidades que podrá realizar el rol de Novio

5.3.1 Elegir Mesas

Esta funcionalidad es una de las primeras cosas que puede y debe realizar un usuario con

el rol de Novio. En esta parte del sistema se trata de que el novio elija las mesas que cree


oportuno para sentar a sus invitados. Está claro que cada salón dispondrá de sus propias mesas

y son los novios quienes eligen cuantas mesas habrá de cada tipo. Se diferencian las mesas

según el número de comensales, hay que recordar que quien da de alta las mesas y define su

número de comensales es el Gerente del salón desde su interfaz, como ya se explicó en la

5.2.4. Los novios solo podrán disponer de las mesas que haya dado de alta el Gerente para ese

salón.

A continuación se muestra un ejemplo con las mesas almacenadas en la Base de Datos

para el salón asignado a esta boda.

Figura 5.44: Mesas disponibles en un salón.

Como se ve en la imagen, se anuncia a los Novios las mesas que están disponibles. Como

ya se ha dicho esto es simplemente mera información que se le aporta al usuario. Debajo de

esta información se encuentra el formulario que deben rellenar con el numero de mesas de

cada tipo que desean que posea su enlace.

Además se da la opción de incluir una única mesa para los invitados que sean niños. Es

decir en esta mesa solo se sentarán los niños, dando igual la relación que guarden con los

novios. En esta mesa no hace falta indicar el numero de comensales ya que se creará una

mesa con el número de invitados que sean niños. Esto se ha conseguido almacenando en la

tabla de base de datos de invitados un campo que indique si el invitado en cuestión es niño

o no, y a la hora de crear la mesa se dimensiona con el número total de invitados donde el

campo niño sea true. A continuación se muestra una imagen de ese formulario:

Hay una puntualización que se debe hacer a la hora de elegir las mesas. Si los novios

escogen menos mesas de las que deben y todos sus invitados no pueden sentarse, el sistema

seguirá pidiendo que introduzca mesas hasta que todos los invitados puedan sentarse. De esta

forma nos se asegura que todos los invitados estén sentados y a la hora de organizar a los

invitados no haya problemas.


Figura 5.45: Formulario elegir Mesas Novio.



elegir de forma satisfactoria las mesas para un enlace por parte de los Novios.

Figura 5.46: Diagrama de secuencia Elegir Mesas.



Diagrama de las clases utilizadas para la elección de mesas por parte de los Novios

Figura 5.47: Diagrama clases Administración Salones.

5.3.2 Alta de Invitados

Es la hora de crear Invitados, y en esta sección se explicará cómo. Hasta ahora el Gerente de

los salones se ha encargado de dar de alta los enlaces y los novios asociados a esos enlaces,

también se encarga de dar de alta nuevos salones y las que contendrán estos salones. Los

Novios se han encargado de elegir las mesas del salón donde celebrarán su boda, y ahora les

toca dar de alta a los invitados.

Para crear un invitado nuevo, los novios deben irse al enlace Alta de invitados, una vez

dentro deben rellenar el formulario con los datos del invitado que vayan a dar de alta. En este

formulario los Novios deben rellenar nombre, apellidos y email del invitado, además debe

elegir una de las posibles relaciones que tiene el invitado con respecto a los novios. Estas

posibles relaciones son:

• Familiares del Novios

• Familiares del Novios

• Amigos del Novio

• Amigos de la Novia

• Amigos en Común del Novio y de la Novia


• Compañeros de Trabajo del Novio

• Compañeros de Trabajo de la Novia

Figura 5.48: Relaciones entre invitados.

Esto se ha definido así para que a la hora de realizar la organización de los invitados

resulte más sencillo para los novios definir la relación existente entre estos siete grupos de

invitados. A continuación se muestra el formulario que deben rellenar los Novios para crear

un nuevo invitado.

Figura 5.49: Formulario Nuevo Invitado.

En esta funcionalidad de dar de alta nuevos invitados, se tiene que destacar que se ha

añadido el campo Asistencia para aquellos invitados que se sepa que van a ir y no puedan

confirmar la asistencia, como por ejemplo personas mayares o personas que no dispongan de

ordenador. Para ello los novios son los Novios los encargados de fijar la asistencia a true en


lugar de los invitados.

También se ha incluido el campo Niño donde indica si el nuevo invitado es un niño para

luego incluirlo en la mesa exclusiva para niños.

Para la realización de pruebas de este Trabajo Fin de Grado sería una perdida enorme

de tiempo tener que ir dando de alta invitado a invitado cada vez que se creará una nueva

boda para ver los resultados de nuestro trabajo por lo que se decidió crear un generador de

invitados que se explicará más adelante.



dar de alta satisfactoriamente nuevo Invitados.

Figura 5.50: Diagrama de secuencia Alta de invitados.


Diagrama de las clases utilizadas para dar de alta nuevos invitados


Figura 5.51: Diagrama clases Alta Invitados.

5.3.3 Definir Relaciones

En este apartado se va a explicar como y para que sirve definir la relación existente entre

los diferentes grupos de invitados. Este paso es fundamental para organizar a los invitados,

siempre y cuando se quiera sentar a los invitados de una forma correcta y con una relación

optima entre los invitados sentados en una misma mesa.

se han definido tres tipos de relaciones: Buena, Normal y Mala. Así los novios lo único

que tienen que hacer es rellenar el formulario indicando el tipo de relación. Para que sea

una interfaz más amigable para el usuario se ha decidido expresar estos tipos de relaciones

mediante emoticonos que definen a la perfección el tipo del que se trata.

Figura 5.52: Tipos de relaciones.

Como se puede intuir en la imagen, la cara verde será para indicar que la afinidad entre

grupos es Alta, la cara amarilla será para indicar que la afinidad es Normal y la cara roja será

para indicar que la afinidad es Baja.

Los Novios serán los encargados de indicar la afinidad existente entre los 7 grupo: Fami-


liares del Novio, Familiares de la Novia, Amigos del Novio, Amigos de la Novia, Amigos

en Común, Compañeros de Trabajo del Novio y Compañeros de Trabajo de la Novia. Si

se parte de que los invitados de un mismo grupo siempre se van a tener una afinidad alta,

solo se tendrían que definir las afinidades que existen entre el grupo con el resto de grupos,

por ejemplo, en el grupo de invitados Amigos de la novia no hay que definir la relación

con el grupo de invitados Familiares del Novio, ya que esta relación ya está definida en el

grupo Familiares del Novios como se puede observar. Ahora se mostrará una parte de esta

funcionalidad para ver como se tendría que rellenar este formulario.

Figura 5.53: Afinidad Familiares del Novio con el resto.


Diagrama de secuencia que muestra la interacción de los objetos que intervienen cuando se

define satisfactoriamente el nivel de afinidad existente entre los grupos de invitados.


Diagrama de las clases utilizadas para definir la relación existente entre los grupos de invitados.

5.3.4 Organizar Invitados

Una vez que se guarda la afinidad existente entre todos los grupos de invitados, ha llegado la

hora de organizar a los invitados dados de alta en el sistema en las mesas elegido. Sin duda


Figura 5.54: Diagrama de secuencia Definir Relaciones.

Figura 5.55: Diagrama clases Definir Relaciones.

esta es la funcionalidad más importante y el principal motivo de realización de este Trabajo

Fin de Grado. Es por esto por lo que se detallará más en profundidad esta sección evaluando

todos lo casos posibles para organizar a los invitados.

Para empezar hay que decir que esta aplicación ofrece la posibilidad de empezar a sentar

a los invitados a partir de cualquiera de los siete grupos de invitados, es decir, que en las

primeras mesas se sienten invitados del grupo de la familia del novio, o empezar sentando

invitados del grupo de la familia de la novio, o sentar primero los amigos del novio etc. Para

ello primero se debe elegir en el formulario previo a la lista de invitados organizados.


Figura 5.56: Elegir grupo de invitados para empezar a organizar.

También hay que especificar en este formulario la afinidad existente entre los miembros

de una misma mesa, es decir, si se quedan invitados sin sentar de varios grupos, habrá que

mirar la afinidad existente entre ellos y sentar solo a los invitados cuya afinidad sea igual o

mayor a la indicada en este formulario. Un ejemplo sería el siguiente:

Si en este formulario se indica la afinidad entre invitados en las mesas debe ser buena y si

se quedan sin sentar invitados que sean familiares del novio e invitados que sean familiares de

la novia, sólo se sentarían en la misma mesa si entre ambos grupos existe una afinidad alta

(emoticono de cara verde).

Figura 5.57: Elegir afinidad mínima entre invitados de una misma mesa.

Una vez que se ha seleccionado el grupo de invitados por el que los novios quieren

empezar a sentar a los invitados y la afinidad que quieren que hayan entre los invitados de

una misma mesa, el siguiente paso es que la aplicación nos muestre la lista de invitados

completa organizados por mesas y un porcentaje. Este porcentaje será el número de invitados

sentados en mesas gracias a esta aplicación. Hay que decir que este porcentaje varía según los

datos introducidos en la anterior pantalla (grupo por el que empezar a sentar y afinidad entre

invitados de una misma mesa). A continuación se pondrán ejemplos de los posibles casos que

se pueden dar a la hora de organizar a los invitados.


Ejemplo 1

Si existe una buena relación entre todos los grupos de invitados, significa que en todas las

mesas habrá una afinidad alta entre cualquier invitado, es por ello por lo que dará igual porque

grupo de invitados se empiece a organizar o el nivel de afinidad mínimo que debe existir entre

los grupos, que siempre sentará al 100 % de los invitados puesto que entre ellos se llevan

todos bien.

Datos de prueba

En la pantalla de Definir relaciones se seleccionará Afinidad Alta (emoticono cara verde)

entre todos los grupo. En este caso habría que definir las 21 afinidades con esta afinidad.

Figura 5.58: Afinidad alta entre todos los invitados.

De esta forma se irán seleccionando todos los campos existentes en este formulario.

En el formulario previo a la lista de invitados organizados, es indiferente los datos a

introducir ya que como se ha dicho antes al tener una alta afinidad entre todos los invitados,

dará igual si se introduce que la afinidad mínima sea una afinidad media, porque el algoritmo

evaluará las afinidades Media y Alta. También da igual por que grupo se empiece a sentar

porque sea cual sea el grupo por el que se empiece a sentar, el porcentaje de invitados sentados

será de un 100 %. Como ejemplo se pondrá el siguiente:


Figura 5.59: Datos de entrada, ejemplo 1.

Resultado obtenido

Figura 5.60: Resultado obtenido, ejemplo 1.

Como se ve se obtiene un 100 % de invitados sentados, además se puede ver como la

primera mesa será la mesa exclusiva para los niños y en las siguientes mesas ya se sentarán

los demás invitados, empezando por los familiares de la novia como se indicó anteriormente

en los Datos de prueba.

A continuación se muestra un ejemplo de mesas donde se tienen que juntar invitados de

distintos grupos de invitados debido a que no cabían con los invitados de su propio grupo


como se ve en el primer ejemplo. Al tener una buena relación entre todos no hay problemas al

sentar unos grupos con otros.



Ejemplo 2

Siguiendo el ejemplo anterior se ve como los grupos amigos del novio, amigos de la novia y

compañero de trabajo de la novio se pueden sentar juntos en una misma mesa porque entre

los 3 grupos existe una Alta afinidad. Sin embargo, si se cambia la afinidad de cualquiera de

estos grupos con otro, ya no se podrán sentar en una misma mesa siempre que la afinidad sea

menor a la indicada. A continuación se ilustra con el ejemplo.

Datos de prueba

Para rellenar los campos previos a la lista de organizados puede valer con la mostrada

anteriormente:


Sin embargo ahora se va a cambiar la relación entre los amigos del novio y los amigos de

la novia con respecto a compañeros de trabajo de la novia.



Con estos datos de entrada se puede prever que en la última mesa no se podrán juntos los

grupos especificados anteriormente ya que la afinidad mínima entre grupos se ha marcado

como buena y la relación entre estos grupo es normal. Ahora se muestra en los resultados

obtenidos.

Resultado obtenido


En los resultados obtenidos se ve como al no mantener una buena relación entre los

grupos de amigos del novio y de la novia con los compañeros de trabajo de la novia, estos se

intercambian posiciones con otro grupo de invitados que tengan buena relación para seguir

manteniendo el porcentaje del 100 % de invitados sentados.


Ejemplo 3

Este ejemplo va a ser totalmente diferente, se va a definir una Baja afinidad para todos los

grupos, es decir todos los grupos se llevarán mal entre ellos.

Datos de prueba

Primero se define la mala relación entre los grupos de invitados. A continuación se muestra el

ejemplo de la relación de los familiares del novio con los demás grupos de invitados.


Ahora se va a introducir los siguiente datos para empezar a organizar a los invitados y

para seleccionar la afinidad mínima entre mesas:


El resultado que se espera obtener será invitados sentados únicamente con invitados de

sus mismo grupo ya que al tener una relación mala entre todos los grupo e indicarle que

la afinidad mínima entre mesas sea Alta, los invitados que se queden sin sentar no podrán

sentarse con el resto de invitados por tener una mala relación.


Resultado obtenido

Este es el resultado que se obtiene:


Se ve como la aplicación ha sido capaz de sentar al 88 % de los invitados, por las razones

antes comentadas, una mala afinidad entre grupos y una Alta afinidad mínima en las mesas.

A continuación se muestra como los invitados sin sentar no se les asigna ninguna mesa:

Bien, ahora se hará una modificación en los datos de entrada, se verá como introduciendo

una baja afinidad mínima entre los invitados de una misma mesa si que sentará a todos

los invitados. La explicación es muy simple, introducir baja afinidad mínima entre mesas

significa que en una misma mesa pueden sentarse invitados que se lleven mal, bien o regular,



entonces en una mesa podrán sentarse grupos de invitados que se lleven mal como es nuestro

caso, ya que no se han modificado las relaciones entre grupos de invitados.


Gracias a esta modificación se espera obtener un 100 % de invitados sentados, pero claro

habrá mesas en los que los invitados tengan una baja afinidad.


Se observa como se obtiene el 100 % de los invitados sentado por lo que no hay invitados

sin sentar, pero hay mesas con grupos de invitado que se tienen una afinidad baja



Ejemplo 4

En este ejemplo se ha querido poner un ejemplo más o menos real, donde se definen las

afinidades que probablemente pueden tener entre sí los grupos de invitados en un entorno

real. En los anteriores ejemplos se han explicado los casos más extremos para explicar de una

manera clara el funcionamiento de la aplicación, ahora se va a explicar un más realista.

Datos de prueba

Lo primero que se va a realizar va a ser la definición de afinidades entre los grupos de

invitados tal y como se haría en una boda real. A continuación se detallan todas las afinidades

introducidas para realizar este ejemplo.

Para este ejemplo se ha decidido empezar a sentar a los invitados por los Familiares del

Novio y la relación mínima entre los invitados de una misma mesa sea Buena

Resultado obtenido

A continuación se muestra el resultado, donde se ha obtenido un 93 % de los invitados sentados

en mesas.

Esto es debido a que hay grupos de invitados que no tienen una relación Buena entre ellos,

por lo que les queda la tarea a los Novios de organizarlos automáticamente.

Se puede ver como con los compañeros de trabajo no se puede sentar a ningún invitado

porque no existe una afinidad alta entre cualquier grupo de invitados y los compañeros de



trabajo.

Los invitados que quedan sin sentar es debido a que no guardan una Buena relación con

los Familiares del Novio y los Amigos del Novio que son los que están sentados en la última

mesa. Entre ellos si que guardan una Alta afinidad como puede comprobarse en los Datos de

entrada.

Visto que se han sentado a un 93 % de los invitados, los Novios pueden decidir que quieren

aumentar ese porcentaje, entonces lo único que tendrán que hacer sería bajar la relación

mínima que puede haber entre los invitados de una misma mesa. A continuación se muestra

el ejemplo.

Con las mismas afinidades que se definieron anteriormente, lo único que se cambia es lo





siguiente:

Una vez que termina de organizar a los invitados, se ve como aumente hasta un 97 % el

porcentaje de los invitados sentados en mesas. Esto se debe que ahora la relación mínima que

deben guardar entre los invitados de una misma mesa es Normal.

Como se observa en una misma mesa se sentarán invitados de los grupos: Familiares del

Novio, Familiares de la Novia, Amigos del Novio y Amigos de la Novia ya que entre ellos

existe una relación Buena o Normal. También se ve como con los Compañeros de Trabajo

no se puede sentar, esto sigue debiéndose a la Mala relación existente entre estos grupos y el

resto de grupos.





Se podría hacer una nueva prueba introduciendo que la relación mínima entre invitados de

una misma mesa sea Mala, así se vería como la aplicación sienta al 100 % de los invitados,



pero esta prueba ya se realizó en ejemplos anteriores



organizar de forma satisfactoria a todos los invitados.


Figura 5.80: Diagrama de secuencia Organizar Invitados.


Diagrama de las clases utilizadas para organizar a los invitados

Figura 5.81: Diagrama clases Organizar Invitados.

86 5.4. ITERACIÓN IV

5.4 Iteración IV

En esta iteración se va a tratar el módulo de Invitados. Para que un invitado pueda entrar en el

sistema, primero tiene que estar dado de alta en el mismo por los Novios. Este grupo es el

que menos acciones podrá realizar. Lo más importante que deben hacer las primeras veces

que ingresen en el sistema será la confirmación de la asistencia al enlace. Por defecto todos

los invitados que se den de alta en el sistema tendrán la asistencia a True por lo que se les

incluirán a la hora de organizar a los invitados, es por este motivo por lo que si no pueden

asistir a la boda deben indicarlo a través de este sistema. Con este simple gesto de marcar una

casilla hacen un favor enorme a los Novios a la hora de que quieran organizar a los invitados a

través de esta aplicación.

En la siguiente imagen se ve todas las acciones que podrán realizar los usuarios con el rol

de Invitados a través de su interfaz.

Figura 5.82: Pantalla inicio rol Invitado.

Con el diagrama de casos de uso se definen estas acciones aceptadas por el cliente por

medio de la captura de requisitos.

Figura 5.83: Diagrama de Casos de Uso para el rol Invitado.

Ahora se detallarán estos tres casos de uso con mas detalle.


5.4.1 Confirmar asistencia

Como ya se ha comentado anteriormente esta es la acción más importante para los Invitados.

Que realicen esta acción no afecta al funcionamiento del sistema pero sí que ayudan a los

Novios a la hora de organizar a todos los invitados en las mesas, ya que todos los invitados

dados de alta se crearan con el campo asistencia a true por lo que en un primer momento

todos asistirán al enlace.

Son los propios invitados, cada uno ingresando al sistema con su usuario y contraseña,

los que deben modificar ese campo desde esta pantalla indicando si no asisten o si sí asisten.

Así a la hora de organizar a los invitado, el sistema sólo seleccionará los invitados con el

campo asistencia a true ignorando todos lo invitados que hayan marcado el campo como

false. El campo asistencia de la tabla de base de datos Invitados se marca como false cuando

se ingresa un No en el siguiente formulario.

Figura 5.84: Confirmar asistencia.

Con este simple formulario los invitados pueden confirmar o declinar la invitación al

enlace.

Como ya se ha comentado este gesto de lo Invitados ayuda a seleccionar solamente a los

invitados que si que asistan ignorando a los que hayan declinado la invitación a la boda. Se

sigue diciendo que esto no influye en el funcionamiento del sistema, sino que únicamente no

incluirá en la organización de los invitados en las mesas a aquellos que no vayan a asistir a la

boda.




confirmar la asistencia del invitado.

Figura 5.85: Diagrama de secuencia Confirmar Asistencia.


Diagrama de las clases utilizadas para confirmar asistencia por parte de los Invitado

Figura 5.86: Diagrama clases Confirmar Asitencia.


5.4.2 Invitados

En este apartado los Invitados que entren en el sistema podrán ver el listado completo de las

personas que asistirán a la boda.

Se trata de un apartado meramente informativo donde se podrá visualizar el listado

completo de los invitados que asistirán al enlace, aquí el usuario con el rol de Invitado no

podrá realizar ninguna acción, solamente ver el listado.

Figura 5.87: Lista completa de invitados.



mostrar la lista de invitados asistentes al enlace.

Figura 5.88: Diagrama de secuencia Lista Invitados.



Diagrama de las clases utilizadas para mostrar la lista de invitados completa.

Figura 5.89: Diagrama clases Lista Invitados.

5.4.3 Posición

En esta sección los Invitados podrán ver la mesa en la cual están sentados según la organi-

zación realizada por la aplicación. También podrán visualizar el resto de invitados que les

acompañaran en la mesa.

Al igual que en el anterior apartado, se trata de una sección informativa para el usuario

donde no podrá realizar ninguna acción, solamente visualizar la mesa donde se sentará.



mostrar la mesa del invitado y los invitados que le acompañarán.


Diagrama de las clases utilizadas para mostrar la lista de invitados completa.


Figura 5.90: Posición del invitado.

Figura 5.91: Diagrama de secuencia Posición Invitado.

Figura 5.92: Diagrama clases Posicion Invitados.

92 5.5. ITERACIÓN V

5.5 Iteración V

En esta interación se van a tratar otros requisitos funcionales que no influyen en el resultado

final del problema pero que se han considerado lo suficientemente importantes como para

incluirlos en esta memoria. Entre ellos está el acceso al sistema (login), gestión del perfil de

usuario, desarrollo de un generador de invitados para generar casos de prueba y la gestión de

contraseñas y nombres aleatorios en el alta de invitados.

5.5.1 Login

Esta funcionalidad se ha creado para que los usuarios puedan acceder al sistema, y que éste

redireccione al usuario, según el rol con el que entre (Gerente, Novio o Invitado), a la interfaz

correspondiente.

Figura 5.93: Acceso al sistema.

Como se puede ver se trata de un formulario muy simple donde el usuario que quiera

acceder al sistema deberá rellenar los campos con su email y su password. Es aquí donde

el sistema comprueba en la base de datos si el usuario que quiere entrar está dado de alta,

primero se comprueba si el email existe en la base de datos y si existe se comprueba que

las contraseñas, la introducida en el formulario y la existente en base de datos, coinciden.

Es posible que un usuario dado de alta se equivoque a la hora de introducir el email o la

password, es por esto por lo que saltará un mensaje de error avisando del problema:

Esta funcionalidad se ha conseguido gracias a la gema sorcery, algo modificada en la

vista y en el controlador, pero la base de la autenticación y gestion de sessions y cookies está

proporcionada por esta gema.


Figura 5.94: Error al acceder al sistema.

5.5.2 Perfil de usuario

Esta funcionalidad fue creada para satisfacer el artículo 5 de la LOPD, respetando en todo

momento el derecho de acceso, rectificación cnacelación u oposición (ARCO). Es por ello

que se ha creado este apartado donde el usuario podrá consultar o modificar sus datos en todo

momento y darse de baja cuando el decida.

Figura 5.95: Enlace al perfil.

Para acceder al perfil hay que irse al enlace info que se encuentra justo a la derecha de la

pantalla principal al lado del nombre del usuario que haya entrado en el sistema, como se ve

en la anterior imagen.


Dentro del perfil del usuario las acciones que podrá realizar serán las de editar perfil

o darse de baja, si el usuario decide cambiar de contraseña o considera que algún dato es

erróneo podrá modificarlo desde el enlace editar. Si por el contrario decide que no quiere

seguir dado de alta en el sistema podrá darse de baja mediante el enlace darse de baja, antes


de ser eliminado aparecerá un mensaje de confirmación, una vez aceptado el mensaje de

confirmación, este usuario será borrado de la base de datos.

5.5.3 Generador de invitados

Esta es una funcionalidad externa al sistema, el cliente en ningún momento pidió este requi-

sito, simplemente se hizo para generar datos de de prueba y poder comprobar el correcto

funcionamiento de la aplicación. Para generar invitados solo se pide que se introduzca el

tanto por ciento de Invitados de cada grupo que se quiere generar tal y como se muestra en la

siguiente imagen:


Rellenando los campos de este formulario se crearan los invitados en función del tanto

por ciento introducido y del número de invitados que tenga el enlace.

Gracias a este generador se ha ahorrado mucho tiempo a la hora de generar datos de

prueba, ya que si se hubiese hecho de forma manual, uno por uno, como en la seccón 5.3.2, se

hubiese tardado una eternidad en generar los casi 5.000 invitados de prueba creados gracias a

este generador, es por ello que ha resultado vital para probar la aplicación y poder realizar la

mayor cantidad de pruebas posibles.


5.5.4 Nombres, apellidos y passwords aleatorias

Este apartado está relacionado con el apartado anterior, cuando se utiliza el generador de

invitados, los invitados creados deben contener un nombre y un apellido ya que no pueden ser

NULL en base de datos, es por ello que para crear más realismo se decidió crear un vector

con nombre y otro con apellidos para que los invitados creados de este modo tuviesen un

nombre y un apellido real. Luego simplemente utilizado la función Random de Ruby, se van

asignando unos nombre u otros a los invitados, lo mismo ocurrirá con los apellidos.

Figura 5.98: Vector de nombres y apellidos.

Estos son los nombres y apellidos elegidos aleatoriamente y ahora se muestra como se

llama a la función Random en Ruby para asignar un nombre y apellido al azar a los invitados

creados por el generador:

Figura 5.99: Función Random en Ruby.

Tanto los nombres como los apellidos aleatorios se han utilizado para el generador de

invitados, sin embargo las claves aleatorias se ha decidido realizar para los Invitados que se

den de alta de forma manual además de los creados por el generador. En este caso se decide

utilizar otra función de Ruby que genera Strings aleatorios de forma segura, de esta forma se

evita suplantación de identidad proporcionando un grado mayor de seguridad al sistema.

Figura 5.100: Función SecureRandom en Ruby.

Esta función de Ruby crea Strings combinando letras, mayúsculas y minúsculas, números

y simbolos. De esta forma la contraseña que se le envíe al Invitado por correo será segura.


Este es un ejemplo de contraseñas generadas por esta función:

Figura 5.101: Ejemplo de contraseñas generadas.

Capítulo 6

Conclusiones y Propuestas

En este capítulo se exponen las conclusiones del desarrollo de este Proyecto Final de Carrera

y se proponen propuestas de trabajo futuros. Además se realiza una comprobación del grado

de satisfacción de los objetivos propuestos en el Capítulo 2.

6.1 Conclusiones

En este apartado se discutirán los objetivos logrados y dando una justificación de porqué

motivo se han conseguido superar.

Cumpliendo con los objetivos parciales, se ha logrado desarrollar una aplicación web que

servirá de ayuda a personas que decidan casarse, gracias a esta herramienta los Novios se

ahorrarán la tarea de tener que organizar a los invitados en las mesas ya que esta aplicación lo

realza automáticamente, también servirá de ayuda a Gerentes de salones de boda para llevar

un control acerca de las bodas que se celebrarán en sus salones. A continuación se definen los

objetivos parciales y se comprueba su consecución.

98 6.1. CONCLUSIONES

Objetivo Justificación Éxito?

Op1 Plan de pro-

yecto

Se ha desarrollado un plan de proyecto y un estudio de viabilidad

(sección 5.1.2 y 5.1.3) del proyecto donde se estiman costes y

tiempo de realización

SI

Op2 Documento

IEEE 830

Se elaboró el documento IEEE 830 sección 5.1.1 con los requisitos

de la aplicación tras las primeras entrevistas con el cliente

SI

Op3 Diseño de la

aplicación

Se han elaborado diferentes diagramas de Casos de Uso, de Clases

y de Secuencia presentes a lo largo de la seccion 5

SI

Op4 Diseño de la

base de datos

Se elaboró el diagrama Entidad/Relación de la aplicación, sección

5.1.1

SI

Op5 Aprendizaje

de Ruby, HTML y

CSS

Se realizaron cursos durante dos semanas y como puesta en prácti-

ca de esos conocimientos es este Trabajo Fin de Grado

SI

Op6 Desarrollo

de la aplicación

Se desarrolló esta aplicación cumpliendo con los objetivos como

puede observarse en la sección 5

SI

Tabla 6.1: Tabla resumen de los objetivos.

Como se ven cumplidos todos lo objetivos parciales, el objetivo principal de este Trabajo

Fin de Grado, que no es otro que es el desarrollo de una herramienta que ayude a las personas

que deciden casarse a gestionar algunos aspectos de la celebración del enlace, se ve cumplido.

Además será una aplicación que podrá ser utilizada por el Gerente del lugar de celebración

del enlace para controlar todas las bodas que se celebrarán en su establecimiento o controlar

temas como los salones disponibles o mesas disponibles en cada salón.

CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS 99

6.2 Propuestas futuras

En esta sección se van a proponer algunas mejoras para una posible comercialización de la

aplicación. Ya que en este Trabajo, el desarrollo se ha centrado en la organización de los

invitados, se han dejado algunos temas de la gestión de bodas sin tocar por no tener relación

con la gestión y organización de los invitados.

A continuación se citan algunas de las posibles mejoras para la aplicación.

• Gestión integral de Menús: Una mejora podría ser la incorporación al sistema de la

gestión de menús por parte de los novios. En este apartado los novios podría escoger de

cuántos platos dispondría el menú a servir en su enlace, de esos platos cuantos serían

entrantes, cuantos serían primeros platos etc. Por supuesto ellos serían quienes elegirían

cada plato. También tendrían la posibilidad de elegir la bebida durante el banquete, o

podrían decidir si quieren barra libre para después de la cena o animación para los niños

etc.

• Elaborar presupuesto: Esta sería una funcionalidad a añadir en la parte del Gerente,

donde el podría ir llevando una hoja de gastos según todo lo que vayan configurando

los novios en cuanto a número de invitados, mesas y salón elegido, menú escogido, etc.

Para realizar este módulo económico sería necesario definir algunos aspectos legales,

que en este Trabajo Fin de Grado no se han abarcado.

• Disposición física de las mesas: Una opción para el futuro sería la posibilidad de

incorporar la elección de distribución de las mesas en el salón por parte de los Novios,

pudiendo así colocar las mesas que como ellos quieran, a su gusto, pudiendo colocar,

por ejemplo, las mesas de los familiares más cerca de la mesa presidencial, o cerca de

los otros grupos de invitados que tengan una afinidad alta.

Bibliografía

[1] bodas.net. www.bodas.net.

[2] Evolucion desarrollo web. https://docs.google.com/presentation/d/

1chk81rXDo8ZXwVB_aymOAieJBDYd9u0al2IItwg-TnU/edit#slide=

id.i21.

[3] Evolucion web. http://www.evolutionoftheweb.com/?hl=es.

[4] Ventajas desarrollo Web. http://www.pixima.net/aplicaciones-web/

ventajas-de-las-aplicaciones-web/.

[5] Ventajas desarrollo Web. http://www.internetya.co/

ventajas-y-beneficios-de-las-aplicaciones-web/.

[6] Caracterisiticas desarrollo Web. http://www.logindesarrollos.com/es/

Servicios-aplicaciones-web-21.

[7] PHP. http://es.wikipedia.org/wiki/PHP.

[8] PHP. http://www.ecured.cu/index.php/PHP.

[9] ASP. http://msdn.microsoft.com/es-es/library/4w3ex9c2(v=vs.

100).aspx.

[10] ASP. http://es.wikipedia.org/wiki/ASP.NET.

[11] ASP. http://www.ecured.cu/index.php/ASP.NET.

[12] Libro ASP. http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/

bitstream/231104/349/1/ASP%20.NET%20orientado%20web.pdf.

www.bodas.net

https://docs.google.com/presentation/d/1chk81rXDo8ZXwVB_aymOAieJBDYd9u0al2IItwg-TnU/edit#slide=id.i21



http://www.evolutionoftheweb.com/?hl=es

http://www.pixima.net/aplicaciones-web/ventajas-de-las-aplicaciones-web/

http://www.pixima.net/aplicaciones-web/ventajas-de-las-aplicaciones-web/

http://www.internetya.co/ventajas-y-beneficios-de-las-aplicaciones-web/

http://www.internetya.co/ventajas-y-beneficios-de-las-aplicaciones-web/

http://www.logindesarrollos.com/es/Servicios-aplicaciones-web-21

http://www.logindesarrollos.com/es/Servicios-aplicaciones-web-21

http://es.wikipedia.org/wiki/PHP

http://www.ecured.cu/index.php/PHP

http://msdn.microsoft.com/es-es/library/4w3ex9c2(v=vs.100).aspx

http://msdn.microsoft.com/es-es/library/4w3ex9c2(v=vs.100).aspx

http://es.wikipedia.org/wiki/ASP.NET

http://www.ecured.cu/index.php/ASP.NET

http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/231104/349/1/ASP%20.NET%20orientado%20web.pdf

http://dgsa.uaeh.edu.mx:8080/bibliotecadigital/bitstream/231104/349/1/ASP%20.NET%20orientado%20web.pdf

102 BIBLIOGRAFÍA

[13] Modelos programaciÃ³n ASP. http://blogs.msdn.com/b/daniem/

archive/2012/05/10/modelos-de-programacion-en-aspnet.

aspx.

[14] Ruby on Rails. http://www.rubyonrails.org.es/.

[15] Libro Modelo-Vista-Controlador. http://book.cakephp.org/2.0/

es/cakephp-overview/understanding-model-view-controller.

html.

[16] Porque Ruby. http://www.cristalab.com/blog/

por-que-aprender-ruby-on-rails-c109181l/.

[17] 10 razones para aprender Ruby. http://blog.xenodesystems.com/2012/

06/10-razones-para-aprender-ruby-on-rails.html.

[18] 10 razones para aprender Ruby. http://blog.xenodesystems.com/2012/

06/10-razones-para-aprender-ruby-on-rails.html.

[19] Primeros pasos con ruby. http://html5facil.com/tutoriales/

ruby-on-rails-desde-cero-primeros-pasos/.

[20] Utilizar Ruby. http://www.innovaxp.com/es/blog/

por-que-utilizar-ruby-on-rails/.

[21] Lenguajes de programacion en 2006. http://www.tufuncion.com/

diferentes-lenguajes-programacion.

[22] Lenguajes de programacion en 2010. http://www.innovaxp.com/.

[23] Lenguajes de programacion en 2013. http://programacion.net/noticia/

los_lenguajes_de_programacion_mas_populares_en_2013_2114/.

[24] Introduccion a MVC. http://www.desarrolloweb.com/articulos/

que-es-mvc.html.

[25] CaracterÃsticas MVC. http://www.desarrolloweb.com/articulos/

modelo-vista-controlador-codeigniter.html.

http://blogs.msdn.com/b/daniem/archive/2012/05/10/modelos-de-programacion-en-aspnet.aspx



http://www.rubyonrails.org.es/

http://book.cakephp.org/2.0/es/cakephp-overview/understanding-model-view-controller.html



http://www.cristalab.com/blog/por-que-aprender-ruby-on-rails-c109181l/

http://www.cristalab.com/blog/por-que-aprender-ruby-on-rails-c109181l/

http://blog.xenodesystems.com/2012/06/10-razones-para-aprender-ruby-on-rails.html




http://html5facil.com/tutoriales/ruby-on-rails-desde-cero-primeros-pasos/

http://html5facil.com/tutoriales/ruby-on-rails-desde-cero-primeros-pasos/

http://www.innovaxp.com/es/blog/por-que-utilizar-ruby-on-rails/

http://www.innovaxp.com/es/blog/por-que-utilizar-ruby-on-rails/

http://www.tufuncion.com/diferentes-lenguajes-programacion

http://www.tufuncion.com/diferentes-lenguajes-programacion

http://www.innovaxp.com/

http://programacion.net/noticia/los_lenguajes_de_programacion_mas_populares_en_2013_2114/

http://programacion.net/noticia/los_lenguajes_de_programacion_mas_populares_en_2013_2114/

http://www.desarrolloweb.com/articulos/que-es-mvc.html

http://www.desarrolloweb.com/articulos/que-es-mvc.html

http://www.desarrolloweb.com/articulos/modelo-vista-controlador-codeigniter.html

http://www.desarrolloweb.com/articulos/modelo-vista-controlador-codeigniter.html

BIBLIOGRAFÍA 103

[26] Introduccion a MVC. http://es.wikipedia.org/wiki/Modelo%E2%80%

93vista%E2%80%93controlador.

[27] Flujo de ejecucion MVC. http://si.ua.es/es/documentacion/

asp-net-mvc-3/1-dia/modelo-vista-controlador-mvc.html.

[28] Web inovios. http://www.inovios.es/.

[29] Web Wedtool. es.wedtool.com/.

[30] Web bodas.net. http://www.bodas.net/.

[31] AUP. http://www.ambysoft.com/unifiedprocess/agileUP.html.

[32] AUP. http://es.slideshare.net/joseluisdifu/

proceso-unificado-gil-aup-17171038.

[33] Metodologia AUP. http://ubuntu-adempiere.blogspot.com.es/2011/

09/metodologia-aup-agile-unified-process.html.

[34] AUP. http://nosolopau.com/2012/06/07/

mas-sobre-el-proceso-unificado-agil-fases-y-disciplinas/.

[35] AUP. http://nosolopau.com/2012/06/07/

mas-sobre-el-proceso-unificado-agil-fases-y-disciplinas/.

[36] Visual Paradigm. http://www.visual-paradigm.com/.

[37] Latex. http://www.latex-project.org/.

[38] Bootstrap. http://getbootstrap.com/.

[39] MySQL. http://www.mysql.com/.

[40] SublimeText2. http://www.sublimetext.com/2.

[41] Microsoft Project 2013. http://es.wikipedia.org/wiki/Microsoft_

Project.

http://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93controlador

http://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93controlador

http://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-controlador-mvc.html

http://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-controlador-mvc.html

http://www.inovios.es/

es.wedtool.com/

http://www.bodas.net/

http://www.ambysoft.com/unifiedprocess/agileUP.html

http://es.slideshare.net/joseluisdifu/proceso-unificado-gil-aup-17171038

http://es.slideshare.net/joseluisdifu/proceso-unificado-gil-aup-17171038

http://ubuntu-adempiere.blogspot.com.es/2011/09/metodologia-aup-agile-unified-process.html

http://ubuntu-adempiere.blogspot.com.es/2011/09/metodologia-aup-agile-unified-process.html

http://nosolopau.com/2012/06/07/mas-sobre-el-proceso-unificado-agil-fases-y-disciplinas/




http://www.visual-paradigm.com/

http://www.latex-project.org/

http://getbootstrap.com/

http://www.mysql.com/

http://www.sublimetext.com/2

http://es.wikipedia.org/wiki/Microsoft_Project

http://es.wikipedia.org/wiki/Microsoft_Project

Anexo A

Acrónimos

A continuación se muestra el listado de acrónimos encontrados en la memoria de este Trabajo

Fin de Grado.

AJAX. Asynchronous JavaScript and XML.

ASP. Active Server Pages.

AUP. Proceso Unificado Ágil.

CASE. Computer Aided Software Engineering.

CSS. Cascading Style Sheets.

DRY. Don´t Repeat Yourself.

E/R. Entidad Relacion.

HTML. HyperText Markup Language.

IEEE. Institute of Electrical and Electronics Engineers.

LOPD. Ley Organica de Protección de Datos.

MVC. Modelo-Vista-Controlador.

ODBC. Open DataBase Connectivity.

Op. Objetivo parcial.

ORM. Object-Relational mapping.

PHP. Hypertext Preprocessor.

RDLOPD. Real Decreto de la Ley Organica de Protección de Datos.

RoR. Ruby on Rails.

RUP. Proceso Unificado Rational.

SQL. Structured Query Language.

TFG. Trabajo Fin de Grado.

UML. Unified Modeling Language.

XML. eXtensible Markup Language

Anexo B

Manual de Usuario

A continuación se explica cómo podrá utilizar la aplicación cada uno de los usuarios depen-

diendo del rol que tengan dentro del sistema.

B.1 Gerente

El Gerente de los salones de boda debe entrar en la aplicación con el email [email protected]

y con el password admin.

Figura B.1: Login del Gerente.

Una vez dentro del sistema, siguiendo estos pasos no se tendrá ningún problema

B.1.1 Crear Salón

En la pantalla inicial pinchar en el enlace Salones

Figura B.2: Crear Salon.

108 B.1. GERENTE

Aquí aparece un listado de salones, para crear uno nuevo hay que acceder a través del

enlace Crear Salón


En el formulario que aparece en esta pantalla, rellenarlo con los datos que quiera el

Gerente


B.1.2 Generar y eliminar Mesas

En la pantalla inicial de la interface del Gerente, pinchar en el enlace Mesas

Figura B.5: Generar Mesas.

Una vez dentro, se elegirá el salón donde se quieran generar o eliminar mesas.

ANEXO B. MANUAL DE USUARIO 109


Aquí se muestran las mesas que tiene este salón, para generar mesas hay que pulsar sobre

el enlace Generar Mesas


Entonces aparece una ventana modal donde hay que introducir el número de mesas que se

quieren generar y el número de invitados por mesa.


El mismo procedimiento habría que hacer para eliminar mesas, solo que habrá que pinchar

en el enlace Eliminar Mesas, y habrá que introducir correctamente el número de mesas y el

número de invitados por mesa.

B.1.3 Crear Boda

Crear una boda es muy sencillo, simplemente se pincha en el enlace Crear Boda

Y una vez dentro, rellenar el formulario indicando la fecha del enlace y el número de

invitados.

110 B.2. NOVIO

Figura B.9: Crear Boda.

Figura B.10: Crear Boda.

B.1.4 Alta de Novios

Para dar de alta a un novio dentro del sistema, se pulsa en el enlace Alta de Novios

Figura B.11: Alta de Novios.

Una vez dentro se rellena el formulario y se elige la fecha de la boda cuando se casará ese

novio.

B.2 Novio

Si el usuario entra con el rol de Novio, a continuación se explica cómo podrá realizar las

acciones de este tipo de usuarios.

B.2.1 Alta de Invitados

Lo primer que debe hacer el Novio cuando entra en el sistema es dar de alta a los invitados.

Para ello se pulsa sobre el enlace Alta de Invitados


Figura B.12: Alta de Novios.

Figura B.13: Alta de Invitados.

Aqui se rellenan los campos del invitado eligiendo bien al grupo al que pertenece el

invitado, ya que luego influirá a la hora de la organización automática

Otro campo a tener en cuenta es el campo Nino, ya que indica si el invitado que se da de

alta es un niños o no para posteriormente sentarlo en la mesa exclusiva de niños.

B.2.2 Elegir Mesas

Este es el siguiente paso que debe realizar el novio. Una vez que se den de alta todos los

invitados, se debe elegir las mesas. Se accede mediante el enlace Elegir Mesas

Una vez dentro, Los novios son los encargados de decidir cuantas mesas quieren de cada

tipo. Aquí solo están las mesas disponibles para el salón que se ha adjudicado al enlace.

Aquí el campo a destacar, es el campos Mesa exclusiva para niños, en caso de querer una

mesa exclusiva para los niños, este campo debe ser Si.

112 B.2. NOVIO

Figura B.14: Alta de Invitados.

Figura B.15: Elegir Mesas.

B.2.3 Definir Relaciones

El tercer paso que deben realizar los novios es la definición de las afinidades entre los grupos

de invitados. Solo los novios saben como se llevan entre los grupos de invitados, por esta

razón son ellos quienes tienen que definir las relaciones entre los invitados.

Para acceder simplemente pulsamos sobre el enlace Definir Relaciones.

AquÃ simplemente ir marcando como se llevan entre los invitados: Si tienen una afinidad

alta marcar emoticono de carita verde, si tienen una afinidad media marcar emoticono de

carita amarilla y si tienen una afinidad baja marcar emoticono de carita roja.

B.2.4 Organizar Invitados

Esta es la última acción que se puede hacer si se entra con el rol de Novios. Para acceder a

ella hay que dirigirse al enlace Organizar invitados.

En esta pantalla hay que elegir el grupo de invitados por el que la aplicación empezará


Figura B.16: Elegir Mesas.

Figura B.17: Definir Relaciones.

a sentar a los invitados, y la afinidad mÃnima que quieren los novios que haya entre los

invitados de una misma mesa.

Cuando se hayan decidido los datos a introducir en el anterior paso, se pulsa en el botón

Organizar invitados y esto llevará a la lista de invitados organizados en las mesas.

114 B.2. NOVIO

Figura B.18: Definir Relaciones.

Figura B.19: Organizar Invitados.



Anexo C

Codigo fuente

En este anexo se muestra parte del código generado para proporcionar la solución a este

Trabajo Fin de Grado. Se han incluido solamente los algoritmos o partes de clases que se han

considerado más importantes para dar solución al problema inicial.

C.1 Organización de invitados

El algoritmo más importante de este Trabajo Fin de Grado. Aquí su solución:

1 d e f o r g a n i z a d o r

2 @mesas = MesaEnlace . s e l e c t ("id, mesa_id, numero_comensales" )

. where ( : e n l a c e _ i d => s e s s i o n [ : e n l a c e _ i d ] ) ;

3 i f ( params [ : o rden ] )

4 o r g a n i z a r ( params [ : o rden ] , params [ : r e l a c i o n _ m e s a s ] )

5 end

6 end

7

8 d e f o r g a n i z a r ( orden , r e l a c i o n M e s a s )

9 @ i n v i t a d o s = I n v i t a d o . s e l e c t ("id, nombre, apellidos, relacion

, mesa_id" ) . where ("enlace_id=? AND asistencia =? AND

nino=?" , s e s s i o n [ : e n l a c e _ i d ] , t r u e , f a l s e )

10

11 @ i n v i t a d o n i n o = I n v i t a d o . where ("enlace_id=? AND asistencia =?

AND nino=?" , s e s s i o n [ : e n l a c e _ i d ] , t r u e , t r u e ) . f i r s t

12 i f @ i n v i t a d o n i n o

13 @mesanino=MesaEnlace . where ("enlace_id = ? AND mesa_id = ?" ,

s e s s i o n [ : e n l a c e _ i d ] , @ i n v i t a d o n i n o . mesa_id )

14 end

15 @ i n v i t a d o s . each do | i n v i t a d o |

116 C.1. ORGANIZACIÓN DE INVITADOS

16 i n v i t a d o . u p d a t e _ a t t r i b u t e s ( { : mesa_id => n i l } )

17 end

18

19 #raise @mesanino.cogida.inspect

20 @ a c t u a l i z a r m e s a s = MesaEnlace . s e l e c t ("id, mesa_id,

numero_comensales" ) . where ("enlace_id = ?" , s e s s i o n [ :

e n l a c e _ i d ] ) ;

21

22 @ a c t u a l i z a r m e s a s . each do | mesa |

23 mesa . u p d a t e _ a t t r i b u t e s ( {

24 : c o g i d a => f a l s e

25 } )

26 end

27 i f @mesanino

28 @mesanino . each do | mesanino |

29 mesanino . u p d a t e _ a t t r i b u t e s ( {

30 : c o g i d a => t r u e

31 } )

32 end

33 end


. where ("enlace_id = ? AND cogida =?" , s e s s i o n [ : e n l a c e _ i d

] , f a l s e ) ;

35

36 c a s e o rden . t o _ i

37 when 1

38 @i=1

39 @mesas . each do | mesa |

40

41 @num_comensales = 0

42 #@invitadosmesa = Invitado.order("relacion ASC").where("

enlace_id = ? AND asistencia =? AND nino=?", session

[:enlace_id], true, false)

43

44 @inv i t adosmesa = I n v i t a d o . where ("enlace_id = ? AND

asistencia =? AND nino=? AND relacion = ? AND

mesa_id IS NULL" , s e s s i o n [ : e n l a c e _ i d ] , t r u e , f a l s e ,

@i )

45

ANEXO C. CODIGO FUENTE 117

46

47 @ i n v i t a d o c o n t = I n v i t a d o . where ("enlace_id = ? AND


mesa_id IS NULL " , s e s s i o n [ : e n l a c e _ i d ] , t r u e , f a l s e ,

@i ) . c o u n t

48 #raise @invitadocont.inspect

49

50 i f @ i n v i t a d o c o n t >= mesa . numero_comensa les . t o _ i

51 @inv i t adosmesa . each do | i n v i t a d o |

52 i f @num_comensales . t o _ i < mesa . numero_comensa les .

t o _ i

53

54 i f i n v i t a d o . mesa_id == n i l

55 i n v i t a d o . u p d a t e _ a t t r i b u t e s ( {

56 : mesa_id =>mesa . mesa_id ,

57 } )

58 @num_comensales = @num_comensales + 1

59 end

60 e l s e


62 : c o g i d a => t r u e

63 } )

64 end

65

66 end

67 e l s e

68 @i = @i + 1

69

70 s e n t a r i n v i t a d o s ( @i , mesa )

71

72 end

73 end

74 s e n t a r I n v i t a d o s S i n M e s a ( r e l a c i o n M e s a s )

75 when 2

76 @i=2

77 s e n t a r ( @i , @mesas , r e l a c i o n M e s a s )

78

79 when 3

80 @i=3



82

83 when 4

84 @i=4


86

87

88 when 5

89 @i=5


91

92

93 when 6

94 @i=6


96

97 when 7

98 @i=7


100

101 #fin de recorrer todas las mesas

102 end

103

104 r e s p o n d _ t o do | f o r m a t |

105 f o r m a t . h tml { r e d i r e c t _ t o n o v i o s _ l i s t a i n v i t a d o s _ u r l ,

n o t i c e : ’Mesa was successfully created.’ }

106 f o r m a t . j s o n { r e n d e r j s o n : @invi tado , s t a t u s : : c r e a t e d ,

l o c a t i o n : @inv i t ado }

107 end

108

109 end

110

111 d e f s e n t a r ( i , mesas , r e l a c i o n M e s a s )

112

113 @i= i . t o _ i

114 mesas . each do | mesa |

115

116 @num_comensales = 0

117 #@invitadosmesa = Invitado.order("relacion ASC").where("


enlace_id = ? AND asistencia =? AND nino=?", session

[:enlace_id], true, false)

118



mesa_id IS NULL" , s e s s i o n [ : e n l a c e _ i d ] , t r u e , f a l s e ,

@i )

120

121



mesa_id IS NULL " , s e s s i o n [ : e n l a c e _ i d ] , t r u e , f a l s e ,

@i ) . c o u n t

123 #raise @invitadocont.inspect

124

125 i f @ i n v i t a d o c o n t >= mesa . numero_comensa les . t o _ i

126 @inv i t adosmesa . each do | i n v i t a d o |

127 i f @num_comensales . t o _ i < mesa . numero_comensa les .

t o _ i

128




132 } )


134 end

135 e l s e


137 : c o g i d a => t r u e

138 } )

139 end

140

141 end

142 e l s e

143 @i = @i + 1

144 i f @i== i . t o _ i

145 @i=8

146 b r e a k

147


148 end

149

150 i f @i<=7


152 e l s e

153 @i = 1


155 end

156 end

157 end

158 @inv i t adosS inMesa = I n v i t a d o . where ("enlace_id = ? and

mesa_id IS NULL" , s e s s i o n [ : e n l a c e _ i d ] )

159

160 i f @inv i t adosS inMesa . c o u n t != 0

161 s e n t a r I n v i t a d o s S i n M e s a ( r e l a c i o n M e s a s )

162 end

163 end

164

165 d e f s e n t a r i n v i t a d o s ( r e l a c i o n , mesa )

166

167 @invi t adosmesa1 = I n v i t a d o . where ("enlace_id = ? AND

asistencia =? AND nino=? AND relacion = ? AND mesa_id IS

NULL" , s e s s i o n [ : e n l a c e _ i d ] , t r u e , f a l s e , r e l a c i o n . t o _ i )

168


asistencia =? AND nino=? AND relacion = ? AND mesa_id IS

NULL" , s e s s i o n [ : e n l a c e _ i d ] , t r u e , f a l s e , r e l a c i o n . t o _ i )

. c o u n t

170 @invi t adosmesa1 . each do | i n v i t a d o |

171 i f @num_comensales . t o _ i < mesa . numero_comensa les . t o _ i

172




176 } )


178 end

179 e l s e



181 : c o g i d a => t r u e

182 } )

183 end

184

185 end

186

187 end

188

189 d e f l i s t a i n v i t a d o s

190 @mesas=MesaEnlace . s e l e c t ("id, mesa_id, numero_comensales" ) .

where ( : e n l a c e _ i d => s e s s i o n [ : e n l a c e _ i d ] ) ;

191 @ i n v i t a d o s = I n v i t a d o . s e l e c t ("id, nombre, apellidos, mesa_id,

relacion" ) . where ( : e n l a c e _ i d => s e s s i o n [ : e n l a c e _ i d ] )

192 @ i n v i t a d o s c o n = I n v i t a d o . where ("enlace_id =? AND mesa_id IS

NOT NULL" , s e s s i o n [ : e n l a c e _ i d ] ) . c o u n t

193 @ i n v i t a d o s s i n m e s a = I n v i t a d o . where ("enlace_id =? AND mesa_id

IS NULL" , s e s s i o n [ : e n l a c e _ i d ] )

194 ( ( @ i n v i t a d o s c o n . t o _ f ) / ( @ i n v i t a d o s . c o u n t . t o _ f ) ) . i n s p e c t

195 @ p o r c e n t a j e = ( ( @ i n v i t a d o s c o n . t o _ f / @ i n v i t a d o s . c o u n t . t o _ f ) *

100) . t o _ i

196 #raise @porcentaje.inspect

197 end

198

199 d e f s e n t a r I n v i t a d o s S i n M e s a ( r e l a c i o n M e s a s )

200

201 @inv i t adosS inMesa = I n v i t a d o . where ("enlace_id = ? and

mesa_id IS NULL" , s e s s i o n [ : e n l a c e _ i d ] )

202

203 i f @inv i t adosS inMesa . c o u n t != 0

204

205 @mesas l i b r e s = MesaEnlace . where ("enlace_id = ? AND cogida

= ?" , s e s s i o n [ : e n l a c e _ i d ] , f a l s e )

206

207 #INICIO CONDICION RELACION BUENA

208 #if relacionMesas.to_i == relacionMesas.to_i

209 @ r e l a c i o n e s = R e l a c i o n . where ( : e n l a c e _ i d => s e s s i o n [ :

e n l a c e _ i d ] ) . f i r s t

210 @mesas l i b r e s . each do | r e l a c i o n |

211 #Relacion buena entre familiares del novio y los


demas grupos

212 i f @ r e l a c i o n e s . fNov io fNov ia >= r e l a c i o n M e s a s . t o _ i

213 s e n t a r I n v i t a d o s S i n M e s a H e l p e r ( 1 , 2 )

214 end

215 i f @ r e l a c i o n e s . fNovioaNovio >= r e l a c i o n M e s a s . t o _ i


217 end

218 i f @ r e l a c i o n e s . fNovioaNovia >= r e l a c i o n M e s a s . t o _ i


220 end

221 i f @ r e l a c i o n e s . fNovioaComun >= r e l a c i o n M e s a s . t o _ i


223 end

224 i f @ r e l a c i o n e s . fNov io tNov io >= r e l a c i o n M e s a s . t o _ i


226 end

227 i f @ r e l a c i o n e s . f N o v i o t N o v i a >= r e l a c i o n M e s a s . t o _ i


229 end

230

231 #relacion buena entre familiares de la novia y los

demas grupos

232 i f @ r e l a c i o n e s . fNoviaaNovio >= r e l a c i o n M e s a s . t o _ i


234 end

235 i f @ r e l a c i o n e s . fNov iaaNovia >= r e l a c i o n M e s a s . t o _ i


237 end

238 i f @ r e l a c i o n e s . fNoviaaComun >= r e l a c i o n M e s a s . t o _ i


240 end

241 i f @ r e l a c i o n e s . f N o v i a t N o v i o >= r e l a c i o n M e s a s . t o _ i


243 end

244 i f @ r e l a c i o n e s . f N o v i a t N o v i a >= r e l a c i o n M e s a s . t o _ i


246 end

247

248 #relacion buena entre amigos del novio y los demas


grupos

249 i f @ r e l a c i o n e s . aNovioaNovia >= r e l a c i o n M e s a s . t o _ i


251 end

252 i f @ r e l a c i o n e s . aNovioaComun >= r e l a c i o n M e s a s . t o _ i


254 end

255 i f @ r e l a c i o n e s . aNovio tNovio >= r e l a c i o n M e s a s . t o _ i


257 end

258 i f @ r e l a c i o n e s . aNovio tNovia >= r e l a c i o n M e s a s . t o _ i


260

261 end

262

263 #relacion buena entre amigos de la novia y los demas

grupos

264 i f @ r e l a c i o n e s . aNoviaaComun >= r e l a c i o n M e s a s . t o _ i


266 end

267 i f @ r e l a c i o n e s . aNovia tNovio >= r e l a c i o n M e s a s . t o _ i


269 end

270 i f @ r e l a c i o n e s . aNov ia tNov ia >= r e l a c i o n M e s a s . t o _ i


272

273 end

274

275 #relacion buena entre amigos Comun y los demas

grupos

276 i f @ r e l a c i o n e s . aComuntNovio >= r e l a c i o n M e s a s . t o _ i


278 end

279 i f @ r e l a c i o n e s . aComuntNovia >= r e l a c i o n M e s a s . t o _ i


281

282 end

283

284 #relacion buena entre trabajo del Novio y los demas


grupos



287

288 end

289

290 end

291

292 #FIN CONDICION RELACION BUENA

293 #end

294

295 #FIN del if que comprueba si hay invitados sin sentar

296 end

297 #if relacionMesas.to_i == 1

298 c o m p l e t a r ( r e l a c i o n M e s a s . t o _ i )

299 #end

300 end

301

302 d e f s e n t a r I n v i t a d o s S i n M e s a H e l p e r ( i n v i t a d o s N 1 , i n v i t a d o s N 2 )

303 @mesas l i b r e s . each do | m e s a l i b r e |

304


mesa_id = ?" , s e s s i o n [ : e n l a c e _ i d ] , m e s a l i b r e .

mesa_id ) . c o u n t

306

307 i f @inv i t adosmesa ==0

308 @ i n v i t a d o s 1 = I n v i t a d o . where ("enlace_id = ? AND

relacion =? AND mesa_id IS NULL" , s e s s i o n [ :

e n l a c e _ i d ] , i n v i t a d o s N 1 . t o _ i )

309 @ i n v i t a d o s 1 c o n t = I n v i t a d o . where ("enlace_id = ? AND


e n l a c e _ i d ] , i n v i t a d o s N 1 . t o _ i ) . c o u n t

310

311 @ i n v i t a d o s 2 = I n v i t a d o . where ("enlace_id = ? AND


e n l a c e _ i d ] , i n v i t a d o s N 2 . t o _ i )

312 @ i n v i t a d o s 2 c o n t = I n v i t a d o . where ("enlace_id = ? AND


e n l a c e _ i d ] , i n v i t a d o s N 2 . t o _ i ) . c o u n t


313

314

315 i f @ i n v i t a d o s 1 c o n t >0 && @ i n v i t a d o s 2 c o n t >0

316 @ i n v i t a d o s 1 . each do | i n v i t a d o 1 |

317 i n v i t a d o 1 . u p d a t e _ a t t r i b u t e s ( { : mesa_id =>

m e s a l i b r e . mesa_id , } )

318 #fin de sentar a los invitados familiares del

novio

319 end

320 @num_comensales = @ i n v i t a d o s 1 c o n t

321

322 @ i n v i t a d o s 2 . each do | i n v i t a d o 2 |

323 i f @num_comensales < m e s a l i b r e .

numero_comensa les . t o _ i

324 i n v i t a d o 2 . u p d a t e _ a t t r i b u t e s ( { : mesa_id =>

m e s a l i b r e . mesa_id , } )

325 @num_comensales=@num_comensales+1

326 i f @num_comensales== m e s a l i b r e .

numero_comensa les

327 m e s a l i b r e . u p d a t e _ a t t r i b u t e s ( {

328 : c o g i d a => t r u e

329 } )

330

331 end

332

333 end

334 #fin de sentar a los invitados familiares de

la novia

335 end

336

337 #fin del if que compruba que hay familiares de

ambos novios

338 end

339

340 #fin del if que comprubea que la mesa esté vacía

341 end

342 #fin del recorrido de todas las mesas

343 end

344 end


345

346 d e f c o m p l e t a r ( r e l a c i o n M e s a s )

347 @mesasSinCoger = MesaEnlace . where ("enlace_id = ? AND cogida

= ?" , s e s s i o n [ : e n l a c e _ i d ] , f a l s e )

348 @mesasSinCogercount = MesaEnlace . where ("enlace_id = ? AND

cogida = ?" , s e s s i o n [ : e n l a c e _ i d ] , f a l s e ) . c o u n t

349

350 @mesasSinCoger . each do | mesaSinCoger |

351 @sentar = f a l s e

352 @ i n v i t a d o s = I n v i t a d o . where ("enlace_id = ? AND mesa_id IS

NULL" , s e s s i o n [ : e n l a c e _ i d ] )

353 @ i n v i t a d o s c o n t = I n v i t a d o . where ("enlace_id = ? AND mesa_id

=? " , s e s s i o n [ : e n l a c e _ i d ] , mesaSinCoger . mesa_id ) .

c o u n t

354 @invi tadosMesa = I n v i t a d o . where ("enlace_id = ? AND mesa_id

=? " , s e s s i o n [ : e n l a c e _ i d ] , mesaSinCoger . mesa_id )

355

356 @num_comensales = @ i n v i t a d o s c o n t

357

358 @ i n v i t a d o s . each do | i n v i t a d o |

359 @invi tadosMesa . each do | i n v i t a d o M e s a |

360 #raise invitadoMesa.relacion.inspect

361 i f i n v i t a d o . r e l a c i o n == 1 && i n v i t a d o M e s a == 2


363 @sentar = t r u e

364 end

365 end

366

367 i f i n v i t a d o . r e l a c i o n == 1 && i n v i t a d o M e s a . r e l a c i o n

== 3



370 end

371 end

372


== 4




376 end

377 end

378


== 5



382 end

383 end

384


== 6



388 end

389 end

390


== 7



394 end

395 end

396


== 1



400 end

401 end

402


== 3



406 end

407 end

408

409 i f i n v i t a d o . r e l a c i o n == 2 && i n v i t a d o M e s a . r e l a c i o n ==


4



412 end

413 end

414


== 5

416 i f @ r e l a c i o n e s . fNoviaaComun >= r e l a c i o n M e s a s . t o _ i


418 end

419 end

420


== 6

422 i f @ r e l a c i o n e s . f N o v i a t N o v i o >= r e l a c i o n M e s a s . t o _ i


424 end

425 end

426


== 7

428 i f @ r e l a c i o n e s . f N o v i a t N o v i a >= r e l a c i o n M e s a s . t o _ i


430 end

431 end

432


== 2



436 end

437 end

438


== 1



442 end


443 end

444


== 4



448 end

449 end

450


== 5



454 end

455 end

456


== 6



460 end

461 end

462


== 7



466 end

467 end

468


== 2



472 end

473 end

474


== 1




478 end

479 end

480


== 3



484 end

485 end

486


== 5



490 end

491 end

492


== 6



496 end

497 end

498


== 7



502 end

503 end

504


== 2



508 end

509 end


510


== 1



514 end

515 end

516


== 3



520 end

521 end

522


== 4



526 end

527 end

528


== 6



532 end

533 end

534


== 7



538 end

539 end

540


== 2




544 end

545 end

546


== 1



550 end

551 end

552


== 3



556 end

557 end

558


== 4



562 end

563 end

564


== 5



568 end

569 end

570


== 7

572 i f @ r e l a c i o n e s . t N o v i o t N o v i a >= r e l a c i o n M e s a s . t o _ i


574 end

575 end

576



== 2



580 end

581 end

582


== 1



586 end

587 end

588


== 3



592 end

593 end

594


== 4



598 end

599 end

600


== 5



604 end

605 end

606


== 6

608 i f @ r e l a c i o n e s . t N o v i o t N o v i a >= r e l a c i o n M e s a s . t o _ i



610 end

611 end

612

613 end

614

615 i f @sentar == t r u e

616 i f @num_comensales < mesaSinCoger . numero_comensa les

617 i n v i t a d o . u p d a t e _ a t t r i b u t e s ( { : mesa_id =>mesaSinCoger .

mesa_id , } )

618 @num_comensales=@num_comensales . t o _ i +1

619

620 i f @num_comensales . t o _ i == mesaSinCoger .

numero_comensa les

621 mesaSinCoger . u p d a t e _ a t t r i b u t e s ( {

622 : c o g i d a => t r u e

623 } )

624 end

625 end

626 end

627

628 end

629 end

630

631 end


C.2 Asignar salones libres

1 @salones = Sa lon . f i n d ( : a l l , : o r d e r => "aforo desc" )

2 @salones . each do | s a l o n |

3 @ s a l o n e l e g i d o = s a l o n . i d

4 i f s a l o n . a f o r o >= params [ : n u m e r o _ i n v i t a d o s ] . t o _ i

5 @enlaces = En l ac e . s e l e c t ("id" ) . where ("salon_id = ?

AND fecha = ?" , s a l o n . id , @enlace . f e c h a ) . c o u n t

6 i f @enlaces == 0

7 @enlace . s a l o n _ i d = s a l o n . i d

8 end

9

10 end

11 end

136 C.3. GENERADOR DE INVITADOS

C.3 Generador de invitados

1 d e f g e n e r a r I n v i t a d o s ( p o r c e n t a j e F a m i l i a N o v i o ,

p o r c e n t a j e F a m i l i a N o v i a , po rcen ta j eAmigosNov io ,

po rcen t a j eAmigosNov ia , porcentajeAmigosComun ,

p o r c e n t a j e T r a b a j o N o v i o , p o r c e n t a j e T r a b a j o N o v i a ,

p o r c e n t a j e N i n o s )

2 @enlace= En la c e . f i n d ( s e s s i o n [ : e n l a c e _ i d ] ) ;


. where ( : e n l a c e _ i d => s e s s i o n [ : e n l a c e _ i d ] ) ;

4 @mesai=@mesas . f i r s t

5 @mesaf=@mesas . l a s t

6 l i m i t e =@enlace . n u m e r o _ i n v i t a d o s ;

7 c o n t a d o r = 0 ;

8

9 nombres = ["CARLOS" , "ALEJANDRO" ,"DANIEL" , "PABLO" , "HUGO" ,

"ALVARO" , "ADRIAN" , "DAVID" ,

10 "DIEGO" , "JAVIER" , "MARIO" , "SERGIO" , "MANUEL" , "NICOLAS" ,

"JORGE" , "VICTOR" , "LUCIA" ,

11 "PAULA" , "CARLA" , "MARIA" , "ALBA" , "CLAUDIA" , "MARTINA" , "

JULIA" , "MARTA" , "LAURA" ,

12 "VALERIA" , "CARMEN" , "ADRIANA" , "ANA" , "ISABEL" ] ;

13

14 a p e l l i d o s = ["GARCIA" , "FERNANDEZ" , "MARTINEZ" , "GONZALEZ" ,

"MARTIN" , "DIAZ" , "GIL" , "RUIZ" ,

15 "ALONSO" ,"SERRANO" , "TORRES" , "RAMOS" , "RUBIO" , "GALLEGO" ,

"AGUADO" , "NIETO" , "CRUZ" , "CARRASCO" ] ;

16

17 i f p o r c e n t a j e F a m i l i a N o v i o

18 l im = ( ( l i m i t e . t o _ i * p o r c e n t a j e F a m i l i a N o v i o . t o _ i ) / 1 0 0 ) .

t o _ i

19 w h i l e c o n t a d o r < l im

20

21 @inv i t ado = I n v i t a d o . new ( {

22 : nombre => nombres [ Random . r and ( nombres . s i z e ) ] ,

23 : a p e l l i d o s => a p e l l i d o s [ Random . r and ( a p e l l i d o s . s i z e ) ] ,

24 : e m a i l => "FamiliaNovio" + c o n t a d o r . t o _ s + "@gmail.com

" ,


25 : p a s s => SecureRandom . base64 ( 1 2 ) ,

26 : a s i s t e n c i a => t r u e ,

27 : r e l a c i o n => 1 ,

28 : e n l a c e _ i d => s e s s i o n [ : e n l a c e _ i d ] ,

29 : n ino => f a l s e ,

30 #:mesa_id => Random.rand(@mesai.mesa_id...(@mesaf.

mesa_id+1)),

31 : mesa_id => n i l ,

32 } )

33 @inv i t ado . s ave

34 c o n t a d o r +=1;

35 end

36 end

37

38 c o n t a d o r = 0 ;

39 i f p o r c e n t a j e F a m i l i a N o v i a

40 l im = ( ( l i m i t e . t o _ i * p o r c e n t a j e F a m i l i a N o v i a . t o _ i ) / 1 0 0 ) .

t o _ i


42




46 : e m a i l => "FamiliaNovia" + c o n t a d o r . t o _ s + "@gmail.com

" ,


48 : a s i s t e n c i a => t r u e ,

49 : r e l a c i o n => 2 ,


51 : n ino => f a l s e ,


mesa_id+1)),

53 : mesa_id => n i l ,

54 } )


56 c o n t a d o r +=1;

57 end

58 end

59 c o n t a d o r = 0 ;


60 i f p o rc e n t a j e A m i go s N o v io

61 l im = ( ( l i m i t e . t o _ i * p o rc e n t a j e A m i g os N o v i o . t o _ i ) / 1 0 0 ) .

t o _ i


63




67 : e m a i l => "AmigosNovio" + c o n t a d o r . t o _ s + "@gmail.com"

,


69 : a s i s t e n c i a => t r u e ,

70 : r e l a c i o n => 3 ,


72 : n ino => f a l s e ,


mesa_id+1)),

74 : mesa_id => n i l ,

75 } )


77 c o n t a d o r +=1;

78 end

79 end

80 c o n t a d o r = 0 ;

81 i f p o r c e n t a j e A m i g o s N o v i a

82 l im = ( ( l i m i t e . t o _ i * p o r c e n t a j e A m i g o s N o v i a . t o _ i ) / 1 0 0 ) .

t o _ i


84




88 : e m a i l => "AmigosNovia" + c o n t a d o r . t o _ s + "@gmail.com"

,


90 : a s i s t e n c i a => t r u e ,

91 : r e l a c i o n => 4 ,


93 : n ino => f a l s e ,



mesa_id+1)),

95 : mesa_id => n i l ,

96 } )


98 c o n t a d o r +=1;

99 end

100 end

101 c o n t a d o r = 0 ;

102 i f porcenta jeAmigosComun

103 l im = ( ( l i m i t e . t o _ i * porcenta jeAmigosComun . t o _ i ) / 1 0 0 ) .

t o _ i


105


107 : nombre => nombres [ Random . rand ( nombres . s i z e ) ] ,


109 : e m a i l => "AmigosComun" + c o n t a d o r . t o _ s + "@gmail.com"

,


111 : a s i s t e n c i a => t r u e ,

112 : r e l a c i o n => 5 ,


114 : n ino => f a l s e ,


mesa_id+1)),

116 : mesa_id => n i l ,

117 } )


119 c o n t a d o r +=1;

120 end

121 end

122 c o n t a d o r = 0 ;

123 i f p o r c e n t a j e T r a b a j o N o v i o

124 l im = ( ( l i m i t e . t o _ i * p o r c e n t a j e T r a b a j o N o v i o . t o _ i ) / 1 0 0 ) .

t o _ i


126





130 : e m a i l => "TrabajoNovio" + c o n t a d o r . t o _ s + "@gmail.com

" ,


132 : a s i s t e n c i a => t r u e ,

133 : r e l a c i o n => 6 ,


135 : n ino => f a l s e ,


mesa_id+1)),

137 : mesa_id => n i l ,

138 } )


140 c o n t a d o r +=1;

141 end

142 end

143

144 c o n t a d o r = 0 ;

145 i f p o r c e n t a j e T r a b a j o N o v i a

146 l im = ( ( l i m i t e . t o _ i * p o r c e n t a j e T r a b a j o N o v i a . t o _ i ) / 1 0 0 ) .

t o _ i


148




152 : e m a i l => "TrabajoNovia" + c o n t a d o r . t o _ s + "@gmail.com

" ,


154 : a s i s t e n c i a => t r u e ,

155 : r e l a c i o n => 7 ,


157 : n ino => f a l s e ,


mesa_id+1)),

159 : mesa_id => n i l ,

160 } )



162 c o n t a d o r +=1;

163 end

164 end

165

166 c o n t a d o r = 0 ;

167 i f p o r c e n t a j e N i n o s

168 l im = ( ( l i m i t e . t o _ i * p o r c e n t a j e N i n o s . t o _ i ) / 1 0 0 ) . t o _ i


170


172 : nombre => nombres [ Random . rand ( nombres . s i z e ) ] ,


174 : e m a i l => "Nino" + c o n t a d o r . t o _ s + "@gmail.com" ,


176 : a s i s t e n c i a => t r u e ,

177 : r e l a c i o n => 1 + Random . rand ( 6 ) ,


179 : n ino => t r u e ,


mesa_id+1)),

181 : mesa_id => n i l ,

182 } )


184 c o n t a d o r +=1;

185 end

186 end

187


189 f o r m a t . h tml { r e d i r e c t _ t o i n v i t a d o s _ u r l , n o t i c e : ’Invitado

was successfully created.’ }

190 f o r m a t . j s o n { r e n d e r j s o n : @invi tado , s t a t u s : : c r e a t e d ,

l o c a t i o n : @inv i t ado }

191 end

192 end

142 C.4. ALGORITMO PARA ELEGIR MESAS

C.4 Algoritmo para elegir mesas

Este es el algoritmo para dar solución a la sección 5.3.1.

1 d e f e l e g i r m e s a s

2 @enlace= En la c e . f i n d ( s e s s i o n [ : e n l a c e _ i d ] )

3 @salon= Sa lon . s e l e c t ("id" ) . where ( : i d => @enlace . s a l o n _ i d ) .

f i r s t ;

4 @mesas=Mesa . group ("numero_comensales" ) . where ( : s a l o n _ i d =>

@salon . i d ) . c o u n t

5 @mesasenlaces = MesaEnlace . group ("numero_comensales" ) . where

( : e n l a c e _ i d => s e s s i o n [ : e n l a c e _ i d ] ) . c o u n t

6 @ i n v i t a d o s n i n o = I n v i t a d o . s e l e c t ("id, mesa_id" ) . where ("nino

=? AND enlace_id =?" , t r u e , s e s s i o n [ : e n l a c e _ i d ] ) . f i r s t

7 @ i n v i t a d o s n i n o c o u n t = I n v i t a d o . where ("nino =? AND enlace_id

=?" , t r u e , s e s s i o n [ : e n l a c e _ i d ] ) . c o u n t

8 i f ( @ i n v i t a d o s n i n o )

9 @mesanino=MesaEnlace . s e l e c t ("id" ) . where ( : mesa_id =>

@ i n v i t a d o s n i n o . mesa_id ) . c o u n t

10 end

11

12 @z=1

13 @error = f a l s e

14

15 i f ( params [ : mesa_n inos ]=="true" )

16 c r e a r m e s a n i n o ( @salon . i d )

17 end

18

19 i f ( params [ : numero_mesas1 ] )

20

21 @mesas . each do | mesa |

22

23 @i=1;

24 numero_comensa les =mesa [ 0 ]

25 mesas_con t =mesa [ 1 ] . t o _ i

26 @mesa = Mesa . s e l e c t ("id, numero_comensales,

enlace_id" ) . where ("numero_comensales =? AND

salon_id = ?" , numero_comensales , @enlace .

s a l o n _ i d )


27 @mesaenlacecont = MesaEnlace . s e l e c t ("id,

numero_comensales, enlace_id" ) . where ("

numero_comensales =? AND enlace_id = ?" ,

numero_comensales , @enlace . i d ) . c o u n t

28 p a r a m e t r o s =( params ["numero_mesas"+(@z) . t o _ s ] . t o _ i )

29 t o t a l = @mesaenlacecont . t o _ i + p a r a m e t r o s

30 @comparacion =( t o t a l <= mesas_con t )

31 i f ( t o t a l <= mesas_con t )

32 @mesa . each do | mesa1 |

33 i f ( e s t a l i b r e ( mesa1 . id , mesa1 .

numero_comensa les ) == t r u e and ( p a r a m e t r o s

) >=@i )

34 @mesaenlace = MesaEnlace . new ( {


36 : mesa_id => mesa1 . id ,

37 : numero_comensa les => mesa1 .

numero_comensales ,

38 : c o g i d a => f a l s e ,

39 } )

40 @mesaenlace . s ave

41 end

42 @i = @i + 1

43 end

44 e l s e

45 @error= t r u e

46 end

47

48 @z=@z+1

49

50 end

51 end

52

53 i f ( params [ : numero_mesas1 ] )


55 i f @error == t r u e

56

57 f o r m a t . h tml { r e n d e r a c t i o n : "elegirmesas" }

58 f o r m a t . j s o n { r e n d e r j s o n : @mesa . e r r o r s , s t a t u s : :

u n p r o c e s s a b l e _ e n t i t y }

144 C.4. ALGORITMO PARA ELEGIR MESAS

59 e l s e

60 f o r m a t . h tml { r e d i r e c t _ t o m e s a _ e n l a c e s _ u r l , n o t i c e : ’

Mesa was successfully created.’ }

61 f o r m a t . j s o n { r e n d e r j s o n : @mesa , s t a t u s : : c r e a t e d ,

l o c a t i o n : @mesa }

62 end

63 end

64 end

65 end

66

67 d e f e s t a l i b r e ( id_m , numero_comensa les )

68 l i b r e = t r u e

69 @mesaenlace = MesaEnlace . s e l e c t ("id, enlace_id, mesa_id" ) .

where ("enlace_id =? AND numero_comensales =? " , s e s s i o n

[ : e n l a c e _ i d ] , numero_comensa les )

70

71 @mesaenlace . each do | m e s a e n l a c e |

72 i f ( m e s a e n l a c e . mesa_id == id_m . t o _ i )

73 l i b r e = f a l s e

74 e l s e

75 l i b r e = t r u e

76 end

77 end

78 r e t u r n l i b r e

79 end


C.5 Clase para iniciar sesión

En esta clase se controlan las sesiones que se guardan en el navegador.

1 c l a s s T e s t S e s i o n e s C o n t r o l l e r < A p p l i c a t i o n C o n t r o l l e r

2 d e f i n i c i a r _ s e s i o n

3 @ e r r o r _ l o g i n = f a l s e ;

4 #Verifica si se ha enviado el formulario.

5 i f r e q u e s t . p o s t ?

6 #Verifica si el nombre de usuario y la contraseña son

correctos.

7 i f l o g i n ( params [ : n o m b r e _ u s u a r i o ] , params [ : c o n t r a s e n a ] ) &&

@user

8 #Los datos son correctos así que redirecciona a la

página de bienvenida.

9 r e d i r e c t _ t o : c o n t r o l l e r => "test_sesiones" , : a c t i o n =>

"bienvenida" ;

10 e l s i f l o g i n ( params [ : n o m b r e _ u s u a r i o ] , params [ : c o n t r a s e n a ] )

&& @novio

11 r e d i r e c t _ t o : c o n t r o l l e r => "test_sesiones" , : a c t i o n

=> "bienvenidaNovio" ;

12 e l s i f l o g i n ( params [ : n o m b r e _ u s u a r i o ] , params [ : c o n t r a s e n a

] ) && @inv i t ado

13 r e d i r e c t _ t o : c o n t r o l l e r => "test_sesiones" , : a c t i o n

=> "bienvenidaInvitado" ;

14 e l s e

15 #Los datos son incorrectos así que setea la variable

@error_login a true para mostrar el error por

pantalla.

16 @ e r r o r _ l o g i n = t r u e ;

17 end

18 end

19 end

20

21 d e f c e r r a r _ s e s i o n

22 @sesion = g e t _ l o g i n ( ) ;

23 i f @sesion

24 l o g o u t ( ) ;

25 e l s e

146 C.5. CLASE PARA INICIAR SESIÓN

26 r e d i r e c t _ t o : c o n t r o l l e r => "test_sesiones" , : a c t i o n => "

iniciar_sesion" ;

27 end

28 end

29 d e f b i e n v e n i d a

30 #@enlaces = Enlace.all

31 @enlaces= En la c e . o r d e r ( : f e c h a )

32 @novios = Novio . a l l

33 #@salon = Salon.select("metros_ancho, metros_largo, nombre").

where(:id => @enlace.salon_id).first

34 @sesion = g e t _ l o g i n ( ) ;

35 i f @sesion

36 @nombre = @sesion [ : nombre ] ;

37 @ ap e l l i do = @sesion [ : a p e l l i d o ] ;

38 e l s e


iniciar_sesion" ;

40 end

41 end

42 d e f b i e n v e n i d a N o v i o

43 @enlace = En la c e . s e l e c t ("fecha, numero_invitados" ) . where ( : i d

=> s e s s i o n [ : e n l a c e _ i d ] ) . f i r s t

44 @mesaEnlace= MesaEnlace . s e l e c t ("id, mesa_id, enlace_id,

numero_comensales" ) . where ( : e n l a c e _ i d => s e s s i o n [ : e n l a c e _ i d

] )

45 @numero_to ta l = 0 ;

46

47 @ i n v i t a d o s = I n v i t a d o . where ("enlace_id = ? AND asistencia = ?"

, s e s s i o n [ : e n l a c e _ i d ] , t r u e ) . c o u n t

48 @mesaEnlace . each do | m e s a e n l a c e |

49

50 @numero_to ta l = @numero_to ta l + m e s a e n l a c e .

numero_comensa les

51 end

52 @ r e l a c i o n e s = R e l a c i o n . where ("enlace_id = ? " , s e s s i o n [ :

e n l a c e _ i d ] ) . f i r s t

53

54 @sesion = g e t _ l o g i n ( ) ;

55 i f @sesion



57 @a p e l l i do = @sesion [ : a p e l l i d o ] ;

58 @email = @sesion [ : e m a i l ]

59 @novio = Novio . s e l e c t ("id, nombre, apellidos" ) . where ( : i d

=> s e s s i o n [ : i d _ n o v i o ] ) . f i r s t

60

61 e l s e


iniciar_sesion" ;

63 end

64 end

65 d e f b i e n v e n i d a I n v i t a d o

66 @enlace = En la c e . s e l e c t ("fecha" ) . where ( : i d => s e s s i o n [ :

e n l a c e _ i d ] ) . f i r s t

67

68 @sesion = g e t _ l o g i n ( ) ;

69

70 i f @sesion


72 @a p e l l i do = @sesion [ : a p e l l i d o ] ;

73 @inv i t ado = I n v i t a d o . s e l e c t ("id, nombre, apellidos" ) . where

( : i d => s e s s i o n [ : i d _ i n v i t a d o ] ) . f i r s t

74 e l s e


iniciar_sesion" ;

76 end

77 end

78 p r i v a t e

79 d e f l o g i n ( u s u a r i o , c o n t r a s e n a )

80 @user = U s u a r i o . s e l e c t ("nombre, apellidos, pass" ) . where ( :

e m a i l => u s u a r i o ) . f i r s t

81 @novio = Novio . s e l e c t ("id, nombre, pass, apellidos, email,

telefono, enlace_id" ) . where ( : e m a i l => u s u a r i o ) . f i r s t

82 @inv i t ado = I n v i t a d o . s e l e c t ("id,nombre, apellidos, pass,

enlace_id" ) . where ( : e m a i l => u s u a r i o ) . f i r s t

83 i f ( @novio ) && ( @novio . p a s s == c o n t r a s e n a )

84 s e s s i o n [ : l o g u e a d o ] = t r u e ;

85 s e s s i o n [ : nombre ] = @novio [ : nombre ] ;

86 s e s s i o n [ : a p e l l i d o ] = @novio [ : a p e l l i d o s ] ;

148 C.5. CLASE PARA INICIAR SESIÓN

87 s e s s i o n [ : e m a i l ] = @novio [ : e m a i l ] ;

88 s e s s i o n [ : t e l e f o n o ] = @novio [ : t e l e f o n o ] ;

89 s e s s i o n [ : i d _ n o v i o ]= @novio [ : i d ]

90 s e s s i o n [ : e n l a c e _ i d ] = @novio [ : e n l a c e _ i d ] ;

91 s e s s i o n [ : i d ] = 1 ;

92

93 r e t u r n t r u e ;

94 r e d i r e c t _ t o "/novios" , : n o t i c e => "Logged in!"

95

96 e l s i f ( @user ) && @user . p a s s == c o n t r a s e n a


98 s e s s i o n [ : nombre ] = @user [ : nombre ] ;

99 s e s s i o n [ : a p e l l i d o ] = @user [ : a p e l l i d o s ] ;

100 s e s s i o n [ : e m a i l ] = @user [ : e m a i l ] ;

101 s e s s i o n [ : i d ] = 2 ;


103

104 r e d i r e c t _ b a c k _ o r _ t o "/usuarios" , : n o t i c e => "Logged in!"

105

106 e l s i f ( @inv i t ado ) && @inv i t ado . p a s s == c o n t r a s e n a


108 s e s s i o n [ : nombre ] = @inv i t ado [ : nombre ] ; ;

109 s e s s i o n [ : a p e l l i d o ] = @inv i t ado [ : a p e l l i d o s ] ;

110 s e s s i o n [ : i d _ i n v i t a d o ]= @inv i t ado [ : i d ]

111 s e s s i o n [ : i d ]= 3 ;

112 s e s s i o n [ : e n l a c e _ i d ]= @inv i t ado [ : e n l a c e _ i d ] ;


114

115 r e d i r e c t _ b a c k _ o r _ t o "/invitados" , : n o t i c e => "Logged

in!"

116

117 e l s e

118 r e t u r n f a l s e ;

119 end

120

121 end

122 d e f l o g o u t

123 #Desloguea al usuario.

124 r e s e t _ s e s s i o n ;


125 end

126 d e f g e t _ l o g i n

127 #Verifica si el usuario está logueado. Primero pregunta si

existe la session[:logueado] y además que este sea

true, si existe devuelve la sesión sino existe

devuelve false.

128 i f d e f i n e d ? ( s e s s i o n [ : l o g u e a d o ] ) and s e s s i o n [ : l o g u e a d o ]

129 #Está logueado.

130 r e t u r n s e s s i o n ;

131 e l s e

132 #No está logueado.

133 r e t u r n f a l s e ;

134 end

135 end

136

137 end

u c -l m e s i

Documents