Plataforma web para el uso colaborativo de transporte · Plataforma web para el uso colaborativo de...

Miguel Bastida Rodríguez

Francisco José García Izquierdo

Facultad de Ciencia y Tecnología

Grado en Ingeniería Informática

2015-2016

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Plataforma web para el uso colaborativo de transporte

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2016

publicaciones.unirioja.esE-mail: [email protected]

Plataforma web para el uso colaborativo de transporte, trabajo fin de gradode Miguel Bastida Rodríguez, dirigido por Francisco José García Izquierdo (publicado por

la Universidad de La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.

Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a lostitulares del copyright.

Facultad de Ciencia y Tecnología

TRABAJO FIN DE GRADO

Grado en Ingeniería informática

Plataforma web para el uso

colaborativo de transporte

Alumno:

Miguel Bastida Rodríguez

Tutores:

Francisco José García Izquierdo

Departamento de Matemáticas y Computación

Logroño, junio, 2016

Plataforma web para el uso colaborativo de transporte - Miguel Bastida Rodríguez - i

Agradecimientos En primer lugar, me gustaría agradecer tanto a mi tutor del trabajo fin de grado, Francisco José García Izquierdo, quien me ha guiado durante todo el trabajo y me ha ofrecido ayuda ante cualquier duda que pudiera tener, como a mi tutor de la empresa, Hernán González Buteler, por proponerme la realización de este trabajo y confiar en mí para llevarla a cabo.

También quiero agradecer a todos mis compañeros de la universidad durante todos estos años, ya que han hecho que este periodo sea una experiencia inolvidable.

Igualmente, agradecer a los compañeros que han estado conmigo o trabajan en la empresa Netbrain Media Solutions S.L., ya que sé que podré contar con ellos siempre que los necesite.

Por último, agradecer a quienes siempre han estado animándome cada día pase lo que pase, como son mi familia y amigos, cuyo apoyo ha sido esencial durante este proyecto y estos años.

Plataforma web para el uso colaborativo de transporte - Miguel Bastida Rodríguez - ii

Resumen La realización de este proyecto ha sido propuesta por la empresa NetBrain Media Solutions S.L. con el objetivo de conseguir que todos los trabajadores de un mismo centro puedan organizarse para no tener que llevar cada uno su propio coche todos los días.

Por lo tanto, en este proyecto se llevará a cabo una aplicación web capaz de crear una cartelera con varios días donde se indiquen los distintos conductores y sus acompañantes para cada jornada. La idea es que el número de conducciones de todos los participantes sea equitativo.

Para realizar este trabajo se usarán tanto varios conocimientos adquiridos durante la realización del Grado en Ingeniería Informática como algunas de las técnicas aprendidas durante la estancia en las prácticas de empresa. El trabajo se ha realizado utilizando PHP como lenguaje principal.

Abstract The realization of this project was proposed by NetBrain Media Solutions Ltd. with one goal in mind: to make possible for all the workers from the same centre to organize themselves in order not to take one’s car every day.

Therefore, in this project we will create a web application that is able to create a listing with several days where it is indicated for each day the different drivers and their companion. The idea is to have an equitable driving number for all the participants. In order to do this task, we will make use of the knowledge that has been acquired in the Degree in Computer Engineering as well as some of the learned techniques during the internship in the com-pany. This work has been carried out by using PHP as its main language.

Plataforma web para el uso colaborativo de transporte - Miguel Bastida Rodríguez - iii

Índice de contenido Agradecimientos ............................................................................................................................. i Resumen ........................................................................................................................................ ii Abstract .......................................................................................................................................... ii

1 Introducción ...............................................................................................................................1 1.1 Contexto .............................................................................................................................1 1.2 Tecnologías y herramientas a utilizar .................................................................................1 1.3 Planificación .......................................................................................................................2

1.3.1 Alcance .......................................................................................................................2 1.3.2 Exclusiones .................................................................................................................3 1.3.3 Metodología de trabajo ..............................................................................................3 1.3.4 Entregables .................................................................................................................3 1.3.5 Tareas .........................................................................................................................4 1.3.6 Distribución temporal .................................................................................................6

2 Análisis .......................................................................................................................................8 2.1 Requisitos funcionales ........................................................................................................8 2.2 Requisitos no funcionales .................................................................................................10 2.3 Descripción de la agrupación ............................................................................................10

3 Diseño ......................................................................................................................................13 3.1 Diseño de la base de datos ...............................................................................................13

3.1.1 Descripción de la base de datos ...............................................................................13 3.1.2 Diagrama de entidad relación...................................................................................14

3.2 Diseño de la interfaz gráfica .............................................................................................16 3.2.1 Pantalla de bienvenida .............................................................................................16 3.2.2 Pantalla de registro ...................................................................................................17 3.2.3 Pantalla de coordinador ...........................................................................................17 3.2.4 Pantalla de añadir participante.................................................................................17 3.2.5 Pantalla de resultado de agrupación ........................................................................18 3.2.6 Pantalla de modificación de horario .........................................................................18 3.2.7 Pantalla de error .......................................................................................................18

3.3 Diseño del algoritmo ........................................................................................................19 4 Implementación .......................................................................................................................23

4.1 Implementación de la base de datos ................................................................................23 4.2 Implementación del algoritmo .........................................................................................24

4.2.1 Calcular todas las combinaciones de conductores en un mismo día ........................24 4.2.2 Validar una combinación para un día .......................................................................26 4.2.3 Unión de todas las combinaciones válidas ...............................................................27 4.2.4 Valoración de una combinación de conductores ......................................................28 4.2.5 Uso de métodos de terceros.....................................................................................29 4.2.6 Optimización del algoritmo ......................................................................................31

4.3 Implementación del control de acceso y seguridad .........................................................34

Plataforma web para el uso colaborativo de transporte - Miguel Bastida Rodríguez - iv

4.4 Implementación del diseño ..............................................................................................36 4.5 Implementación de otros aspectos ..................................................................................36

5 Pruebas de la aplicación ...........................................................................................................40 6 Mejoras de la aplicación ...........................................................................................................42

6.1 Mejoras realizadas............................................................................................................42 6.2 Mejoras propuestas ..........................................................................................................43

7 Seguimiento y control del proyecto .........................................................................................45 7.1 Alcance y objetivos alcanzados ........................................................................................45 7.2 Periodos de ejecución real y desviaciones........................................................................45 7.3 Comunicaciones con el cliente y el tutor ..........................................................................47 7.4 Adquisiciones ...................................................................................................................47

8 Conclusiones y lecciones aprendidas .......................................................................................49 9 Bibliografía ...............................................................................................................................51

Índice de tablas Tabla 1.1. Versiones de las herramientas utilizadas ...........................................................................2 Tabla 1.2. Descomposición en tareas del proyecto. ...........................................................................5 Tabla 1.3. Horario semanal de horas dedicadas .................................................................................6 Tabla 1.4. Diagrama de hitos ..............................................................................................................6 Tabla 1.5. Diagrama de Gantt (1/2) ....................................................................................................7 Tabla 1.6. Diagrama de Gantt (2/2) ....................................................................................................7 Tabla 2.1. Ejemplo del cálculo de horas necesarias ..........................................................................11 Tabla 2.2. Ejemplo de combinaciones válidas para un día cualquiera. .............................................12 Tabla 3.1. Ejemplo del algoritmo de los matrimonios estables ........................................................21 Tabla 4.1. Ejemplo de las opciones de conductores en cada hora ...................................................24 Tabla 4.2. Ejemplo de cómo se guardan las combinaciones finales .................................................26 Tabla 4.3. Ejemplo del sistema de rejilla de Bootstrap .....................................................................36 Tabla 5.1. Comprobación de funcionamiento de los requisitos principales .....................................40 Tabla 5.2. Comprobación de funcionamiento en distintos navegadores y sistemas operativos ......41 Tabla 6.1. Mejoras realizadas en el proyecto actual ........................................................................42 Tabla 6.2. Mejoras propuestas para el futuro del proyecto actual...................................................43 Tabla 7.1. Comparativa de horas planificadas y horas reales ...........................................................46 Tabla 7.2. Principales adquisiciones del proyecto ............................................................................47

Plataforma web para el uso colaborativo de transporte - Miguel Bastida Rodríguez - v

Índice de figuras Figura 1.1. EDT del proyecto ..............................................................................................................4 Figura 2.1. División de varios usuarios en dos grupos dependiendo de la cercanía entre ellos .......11 Figura 2.2. Ejemplo de la elección de los acompañantes una vez se conocen los conductores .......12 Figura 3.1. Diagrama de entidad relación.........................................................................................14 Figura 3.2. Pantalla de bienvenida Figura 3.3. Pantalla de registro.................................17 Figura 3.4. Pantalla de coordinador Figura 3.5. Pantalla de añadir participante ..............18 Figura 3.6. Fragmento del documento actual de agrupación (con los datos reales modificados) ....18 Figura 3.7. Pantalla de resultado de agrupación y Figura 3.8. Pantalla de modificación de hor ......19 Figura 4.1. Comparativa del diseño de la pantalla del Coordinador con el resultado final...............36 Figura 4.2. Apariencia del formulario de añadir participante ...........................................................37 Figura 5.1. Gráfica del tiempo de cálculo del algoritmo de asignación de conductores y acom ......41 Figura 7.1. Comparativa entre horas reales-planificadas y progreso en las diferentes activ ............47

Índice de bloques de código Bloque de código 3.1. Pseudocódigo del algoritmo de agrupación (1/2) .........................................21 Bloque de código 3.2. Pseudocódigo del algoritmo de agrupación (2/2) .........................................22 Bloque de código 4.1. Implementación de la creación de la tabla centro. .......................................23 Bloque de código 4.2. Ejemplo de consulta a la base de datos ........................................................24 Bloque de código 4.3. Método para calcular todas las combinaciones de conductores en un día...25 Bloque de código 4.4. Implementación de la validación de una combinación .................................27 Bloque de código 4.5. Unión de todas las opciones válidas y elección de la mejor ..........................28 Bloque de código 4.6. Cálculo de la valoración de una combinación de conductores .....................29 Bloque de código 4.7. Ejemplo de uso de la función unset ..............................................................32 Bloque de código 4.8. Introducción de variables en caché para no repetir cálculos ........................33 Bloque de código 4.9. Ahorro del número de consultas al actualizar las zonas de los particip ........34 Bloque de código 4.10. Instrucción para las rutas seguras ...............................................................34 Bloque de código 4.11. Creación de la vista SQL de login ................................................................35 Bloque de código 4.12. Implementación de la lógica del mapa del formulario de añadir particip ...38 Bloque de código 4.13. Implementación de la localización de los valores de los inputs ..................38 Bloque de código 4.14. Ejemplo de documentación del código .......................................................39

Plataforma web para el uso colaborativo de transporte - Miguel Bastida Rodríguez - 1

1 Introducción 1.1 Contexto La principal motivación del presente trabajo, es la situación actual de los profesores que residen en Logroño e imparten clase en el colegio público de Calahorra. Con el objetivo de no tener que llevar todos los profesores su coche todos los días, organizan lo que llaman una “Rueda de conductores”. Esta “Rueda” consiste en que uno de ellos recoge los datos del resto de profesores al comienzo del curso, y a partir de estos datos lleva a cabo una planificación, en la que se indica quién conduce cada día y a que otros profesores lleva. Para hacer esta tarea dedica varias horas y, además, la planifica-ción que lleva a cabo puede dejar de ser válida si surge algún cambio, como puede ser por ejemplo el cambio de horario de un profesor. Por este motivo se ve obligado a hacer varias versiones de la planificación cada curso, con su correspondiente coste de tiempo.

La idea de la “Rueda de conductores” es bastante bien acogida por el resto de profesores, llegando a estar apuntados casi todos los profesores que imparten clase en el colegio de Calahorra y viven en Logroño (actualmente participan 39 profesores).

Como hemos mencionado, no disponen de ningún sistema informatizado que calcule la solución más óptima para organizar a todos los participantes, por lo que en cuanto surge una modificación en el horario de cualquiera de los profesores, hay que realizar cada una de las modificaciones de modo manual y analizando que dicho cambio sea posible, además de tener que avisar uno a uno a todos los afectados por el cambio.

Con el objetivo de facilitar este proceso surge este proyecto, que consistirá en una aplicación web adaptable a cualquier dispositivo, que permitirá, una vez introducidos los datos de todos los parti-cipantes, calcular la planificación de conductores y acompañantes más óptima. Además, se permi-tirá la realización de determinados cambios. La aplicación no se limitará a organizar únicamente a los profesores del colegio público de Calahorra, sino que ofrecerá la posibilidad de registrar distintos centros (colegios, fábricas, talleres…) y calcular una planificación de conductores para los partici-pantes de estos centros.

Este Trabajo Fin de Grado ha sido propuesto por mi tutor de prácticas, Hernán González Buteler, quien actuará como cliente. El trabajo será dirigido por Francisco José García Izquierdo, quien ac-tuará como tutor.

1.2 Tecnologías y herramientas a utilizar Para la realización de la aplicación que vamos a realizar se ha elegido trabajar con el framework Laravel, con el cual hemos trabajado durante el periodo de prácticas. Consiste en un framework Modelo-Vista-Controlador de código abierto para desarrollar aplicaciones y servicios web con PHP.

Como sistema gestor de base de datos, trabajaremos con MySQL, y como cliente de explotación para la base de datos utilizaremos phpMyAdmin.


Para realizar el diseño gráfico de la aplicación se utilizará un framework que permite crear interfaces web tanto con CSS como con Javascript, como es Bootstrap. Permite llevar a cabo un diseño adap-tativo (Responsive Design), cuyo objetivo es adaptar la apariencia de las páginas web al dispositivo que se esté utilizando para visualizarla. Entre las características de Bootstrap destacan que ofrece un sistema de rejilla (grid), que facilita considerablemente la colocación de los elementos, y que establece Media Queries, ofreciendo la posibilidad de establecer distintos tamaños de los elemen-tos dependiendo del tamaño de la pantalla.

Se usará Composer para gestionar las dependencias entre los paquetes necesarios. Además, para realizar un control de versiones, se utilizará Git, que nos permitirá gestionar todos los cambios rea-lizados en la aplicación.

Para llevar a cabo las funciones de servidor en un entorno local, se utilizará XAMPP, que nos permite contar tanto con un servidor Apache como con un servidor MySQL de forma sencilla.

Como entorno de desarrollo para llevar a cabo la implementación del proyecto, se utilizará Net-Beans, debido a que se trata de un programa utilizado en bastantes asignaturas a lo largo del grado.

Por último, para llevar a cabo la redacción de la memoria, utilizaremos el programa Microsoft Word, y para la realización de algunos gráficos y diagramas utilizaremos la herramienta online draw.io.

En la Tabla 1.1. Versiones de las herramientas utilizadas se muestran las versiones de todas las he-rramientas que se van a utilizar. En todas ellas se ha tratado de seleccionar la última versión LTS (Long Term Support – Soporte a largo plazo) o que cuente con suficiente documentación, y que, además sea estable al comienzo del proyecto actual.

Herramienta o lenguaje Versión Herramienta o lenguaje Versión Microsoft Word 2016 CSS 3

Laravel 5.1 JavaScript 1.8 PHP 5.6 Bootstrap 3.3.6

MySQL 5.6.26 XAMPP 3.2.1 phpMyAdmin 4.4.14 Apache 2.4.16

HTML 5 NetBeans 8.1 Composer 1.1.2 Git 2.7.2

Tabla 1.1. Versiones de las herramientas utilizadas

1.3 Planificación A continuación, se llevará a cabo una planificación de las tareas y el alcance del proyecto. Con el objetivo de conseguir una planificación más precisa, se realizará una descomposición del proyecto en las principales tareas, además de indicar cada uno de los entregables que se llevará a cabo.

1.3.1 Alcance Se llevará a cabo el desarrollo de una aplicación web que permitirá realizar la planificación óptima del reparto de conductores y acompañantes para ir a un centro en distintos días. Excepto la carga de datos, todo el proceso será automático. La aplicación deberá permitir a un usuario registrar un centro determinado, especificar los participantes y sus determinados horarios, calcular la planifica-ción óptima y compartir esta planificación entre todos los participantes.


En cuanto a la base de datos de la aplicación, se almacenarán datos de carácter personal, por lo que se realizará una base de datos consistente, que permita realizar copias de seguridad.

1.3.2 Exclusiones En la aplicación, por cada centro solo se podrá registrar un usuario, que será el único usuario capaz de añadir los datos del resto de participantes y de solicitar a la aplicación que se realice la agrupación de los participantes. Esta restricción de que sólo pueda haber un usuario registrado por centro, fue una decisión que el cliente del proyecto tomó en la reunión inicial (Anexo C.1), y se debe a que hacía falta acotar el proyecto para que sea viable realizarlo en 300 horas. El impacto de esta limitación en los requisitos y roles de la aplicación serán tratados en la futura sección de análisis Sección 2.

1.3.3 Metodología de trabajo En cuanto a la metodología de trabajo, ya que se trata de un proyecto con un único desarrollador y con el alcance claramente definido desde el inicio, se llevará a cabo una metodología de trabajo en cascada, siguiendo las fases correspondientes a la ingeniería del software: análisis, diseño, imple-mentación y pruebas. Para asegurar que cada una de las fases anteriores se realiza correctamente y no tener que volver atrás, se llevará a cabo una pequeña reunión con el cliente tanto antes como después de cada fase.

1.3.4 Entregables En el momento de finalizar cada una de las tareas principales planificadas (Introducción, análisis, diseño, implementación, pruebas y manual de usuario), se realizará un entregable tanto al cliente como al tutor del presente trabajo, de modo que, si fuera necesario realizar alguna modificación, se hará antes de pasar a la siguiente tarea.

Para llevar a cabo estos entregables con éxito, durante el proceso se tendrá una comunicación con-tinua tanto con el cliente como con el tutor. La comunicación con el cliente se llevará a cabo en pequeñas reuniones presenciales en la empresa; mientras que, con el tutor, se realizarán reuniones periódicamente en su despacho, además de tener un contacto continuo vía correo electrónico.

En la Figura 1.1. EDT del proyecto, se puede ver la Estructura de Descomposición del Trabajo (EDT) del proyecto, en la que se organiza y define el alcance total del proyecto de modo visual y sencillo de entender.

En la fase de implementación, hemos considerado necesario realizar cuatro entregables distintos, con el objetivo de asegurar no dar pasos en falso. A continuación, realizamos una pequeña descrip-ción de cada uno de los entregables:

1. Introducción: Entrega de la redacción de la planificación del proyecto completo, junto con una pequeña descripción del contexto que ha motivado el presente proyecto.

2. Análisis: Entrega de la redacción del análisis del proyecto. 3. Diseño: Entrega de la redacción del diseño del proyecto, junto con prototipos de las dis-

tintas pantallas de la aplicación, un diagrama entidad-relación de la base de datos y el pseu-docódigo del algoritmo de agrupación diseñado.


Figura 1.1. EDT del proyecto

4. Implementación: o 4.1. Implementación BD: Entrega de la implementación de la base de datos junto

con la redacción de los distintos imprevistos que han surgido en este proceso. o 4.2. Implementación Lógica de negocio: Entrega de la implementación básica de

lógica de negocio, de modo que nos permita realizar las operaciones CRUD (Create-crear, Read-leer, Update-actualizar y Delete-eliminar) básicas de cada tabla de la base de datos para poder pasar a implementar el algoritmo. Además, se redactarán los distintos imprevistos que han surgido en este proceso.

o 4.3. Implementación algoritmo: Entrega de la implementación del algoritmo junto con la redacción de los distintos imprevistos que han surgido en este proceso.

o 4.4. Implementación Presentación/Lógica: Última entrega de la implementación, en la que se entregará la implementación de la presentación y de toda la lógica de la aplicación, junto con la redacción de los distintos imprevistos que han surgido en este proceso.

5. Pruebas: Realización de distintas pruebas para comprobar el correcto funcionamiento de la aplicación, además de verificar el cumplimiento de los requisitos de la aplicación.

6. Manual de usuario: Entrega de un pequeño manual de uso de la aplicación. 7. Tareas transversales:

o 7.1. Memoria: Entrega de una memoria de aproximadamente 50 hojas en la que se llevará a cabo una descripción del proyecto y de las fases seguidas.

o 7.2. Reuniones: Entrega como anexo de la memoria anterior. Realización de una pequeña acta de las reuniones más destacables que se han llevado a cabo.

o 7.3. Presentación: Realización de una presentación que se mostrará el día que se defienda el proyecto actual.

1.3.5 Tareas En la Tabla 1.2, podemos ver la descomposición de las tareas principales del proyecto en distintas subtareas, junto con la estimación en horas del tiempo previsto para cada una de ellas.

EDT

1. Introducción 2. Análisis 3. Diseño 4. Implementación

4.1. Implementación

BD


Lógica de negocio


algoritmo

4.4. Imp. Presentación/

Lógica

5. Pruebas

6. Manual de usuario

7. Tareas transversales

7.1 Memoria

7.2. Reuniones

7.3. Presentación


Cód Tarea Descripción Horas 1 Introducción Realización de las tareas previas e iniciales del proyecto. 7

1.1 Contexto Descripción de la situación actual, cuya mejora será el objetivo de este proyecto. 2

1.2 Planificación Conjunto de tareas a realizar distribuidas temporalmente, además del coste temporal previsto para cada una de ellas. 5

2 Análisis Fase dedicada a la recopilación de requisitos a partir de reuniones con el cliente 7

2.1 Requisitos funcionales Conjunto de características que definen el comportamiento del sistema. 5

2.2 Requisitos no funcio-nales

Conjunto de características del funcionamiento y de calidad. 2

3 Diseño Proceso para definir el sistema. 21

3.1 Diagrama entidad rela-ción

Realización de un diagrama que describirá la estructura del sistema en distintos entidades y relaciones. 3

3.2 Diseño de la base de datos Realización de un diseño de la base de datos que se usará. 5

3.3 Diseño de interfaces Creación de bocetos y prototipos de las distintas pantallas que tendrá la aplicación. 3

3.4 Diseño del algoritmo Realización en pseudocódigo de los principales pasos que se llevarán a cabo a la hora de realizar la asignación de conductores y acompañantes. 10

4 Implementación Implementación de cada una de las tres capas en las que estará distri-buida la aplicación 200

4.1 Imp. base de Datos Creación de la base de datos e implementación de la capa de persistencia 20

4.2 Imp. Lógica de negocio Implementación inicial de la capa de lógica de negocio, de modo que nos permita realizar todas las operaciones CRUD. 30

4.3 Imp. Algoritmo Implementación del algoritmo. 80 4.3.1 Algoritmo Implementación de una versión funcional del algoritmo 60

4.3.2

Optimización del algo-ritmo

Realización de modificaciones en el algoritmo inicial para optimizar su rendimiento. 10

4.3.3 Mejoras del algoritmo Realización de modificaciones en el algoritmo inicial con el objetivo de

poder realizar cambios de horarios sin un gran coste. 10

4.4 Imp. Presentación/Ló-gica

Implementación de la parte visual de la aplicación, además de añadir el funcionamiento necesario para unir las distintas páginas de la aplicación. 70

5 Pruebas Realización de comprobaciones del funcionamiento de la aplicación 5

6 Manual de usuario Redacción de un pequeño manual que sirva de ayuda al usuario final de la aplicación. 5

7 Tareas transversales Tareas complementarias que estarán repartidas a lo largo de todo el proyecto. 55

7.1 Memoria Redacción de un documento de unas 50 páginas, donde se mostrarán los aspectos más relevantes del ciclo de vida del proyecto. 40

7.2 Reuniones Reuniones tanto con el tutor del trabajo fin de grado como con el cliente, con el objetivo de detectar y corregir errores, además de llevar a cabo un seguimiento del proyecto.

10

7.3 Presentación Preparación del documento que se presentará el día de la exposición del proyecto. 5

TFG Total Realización del proyecto completo 300 Tabla 1.2. Descomposición en tareas del proyecto.


1.3.6 Distribución temporal Como acabamos de ver en la descomposición del proyecto en distintas tareas, el proyecto actual se estima que tendrá una duración de 300 horas, las cuales distribuiremos desde la segunda semana de febrero hasta la segunda de julio, semana en la que se realizará la defensa del mismo.

El trabajo actual se realizará en gran parte asistiendo a la empresa, acudiendo todas las mañanas de los días laborables menos las de los miércoles. En la Tabla 1.3 se puede ver un pequeño horario semanal con las horas dedicadas para llevar a cabo el proyecto, además de añadir una serie de horas complementarias por si fueran necesarias para la realización del proyecto a tiempo.

Horas en empresa Horas de clase Horas complementarias Tabla 1.3. Horario semanal de horas dedicadas

En el diagrama de hitos (Tabla 1.4) mostraremos los hitos más importantes de la vida del proyecto, entre los que están todos los entregables expuestos en la Sección 1.3.4.

Semana 0 1 3 5 6 10 18 19 20 22-23 Hito (entregable)

1-5 feb

8-12 feb

22-26 feb

7-11 feb

14-18 mar

11-15 abr

6-8 jun

13-17 jun

22-24 jun

7-13 jul

1º Reunión con el director del TFG

1º Reunión con el cliente

Entrega planificación (1)

Entrega análisis (2)

Entrega del diseño (3)

Entrega implementación base de datos (4.1)

Entrega implementación lógica de negocio (4.2)

Entrega implementación algoritmo (4.3)

Entrega implementación presentación/Lógica (4.4)

Pruebas (5)

Manual de usuario (6)

Memoria (7.1)

Reuniones (7.2)

Presentación (7.3)

Última reunión con el director antes del depó-sito

Depósito del TFG

Defensa

Tabla 1.4. Diagrama de hitos

Lunes Martes Miércoles Jueves Viernes Sábado Domingo 9-10

10-11 11-12 12-13 13-14 14-15 15-16 16-17 17-18 18-19 19-20


En las Tabla 1.5 y Tabla 1.6, mostramos un diagrama de Gantt donde se representa gráficamente el tiempo que se dedicará a cada tarea. En este diagrama se puede apreciar claramente la metodología utilizada, ya que todas las tareas van justo después de la anterior, exceptuando las tareas transver-sales del proyecto, que están presentes durante todo el periodo. Para garantizar una mejor visuali-zación del diagrama sólo se han puesto los códigos de las tareas, en vez de sus nombres completos.

Tabla 1.5. Diagrama de Gantt (1/2)

Tabla 1.6. Diagrama de Gantt (2/2)

Código Inicio Fin 8 9 11 12 15 16 18 19 22 23 25 26 29 1 3 4 7 8 10 11 14 15 17 18 21 22 29 30 31 1 4 5 7 8 11 12 14 15 18 19 21 22 25 26 28 291 08-02-16 12-02-161.1 08-02-16 09-02-161.2 11-02-16 12-02-162 09-02-16 11-02-162.1 09-02-16 11-02-162.2 11-02-16 11-02-163 15-02-16 26-02-163.1 15-02-16 16-02-163.2 16-02-16 19-02-163.3 19-02-16 23-02-163.4 22-02-16 26-02-164 29-02-16 08-06-164.1 29-02-16 07-03-164.2 04-03-16 15-03-164.3 14-03-16 19-04-164.3.1 14-03-16 12-04-164.3.2 11-04-16 15-04-164.3.3 14-04-16 19-04-164.4 18-04-16 08-06-165 12-06-16 13-06-166 13-06-16 14-06-167 08-02-16 13-07-167.1 08-02-16 17-06-167.2 08-02-16 17-06-167.3 18-06-16 13-07-16

SemanaMes

9 10 11 12Abril

321MarzoFebrero

87654

Código Inicio Fin 2 3 5 6 9 10 12 13 16 17 19 20 6 7 8 13 14 15 16 17 20 21 22 23 24 27 28 29 30 1 4 5 6 7 8 11 12 131 08-02-16 12-02-161.1 08-02-16 09-02-161.2 11-02-16 12-02-162 09-02-16 11-02-162.1 09-02-16 11-02-162.2 11-02-16 11-02-163 15-02-16 26-02-163.1 15-02-16 16-02-163.2 16-02-16 19-02-163.3 19-02-16 23-02-163.4 22-02-16 26-02-164 29-02-16 08-06-164.1 29-02-16 07-03-164.2 04-03-16 15-03-164.3 14-03-16 19-04-164.3.1 14-03-16 12-04-164.3.2 11-04-16 15-04-164.3.3 14-04-16 19-04-164.4 18-04-16 08-06-165 12-06-16 13-06-166 13-06-16 14-06-167 08-02-16 13-07-167.1 08-02-16 17-06-167.2 08-02-16 17-06-167.3 18-06-16 13-07-16

SemanaMes

15 18 1913 14JulioJunioMayo

2320 21 22


2 Análisis 2.1 Requisitos funcionales Se desarrollará una aplicación web, que permitirá organizar un grupo de personas que trabajan en un mismo centro y viven en una población apartada del mismo, de modo que no todas ellas tengan que llevar su coche cada día. Por lo tanto, el objetivo de esta aplicación, será tanto el ahorro de dinero y de peligro de los participantes inscritos en la misma, al no tener que llevar cada uno su propio coche todos los días, como el fomentar las relaciones sociales entre los usuarios.

El reparto de conductores y acompañantes en distintos coches, se llevará a cabo a partir de la des-cripción que veremos en la Sección 2.3, de modo que el reparto sea lo más óptimo posible. El obje-tivo es ofrecer a los miembros de un mismo centro una forma fácil y óptima de organizarse a la hora de ir y volver del mismo. Para llevar a cabo esta agrupación necesitaremos tanto los horarios de los participantes como las coordenadas de un punto en el mapa para recogerlos.

En la aplicación sólo se contemplará un rol funcional, que será el coordinador de un determinado centro. Para poder hacer uso de la aplicación como coordinador, será necesario registrarse, intro-duciendo tanto los datos del coordinador (nombre, apellidos, correo electrónico, teléfono y contra-seña) como del centro (nombre, descripción y clave de acceso a la agrupación). Por defecto, el coor-dinador no tiene por qué ser participante, pero puede decidir serlo en cualquier momento. Una vez se haya registrado, ya podrá acceder a la aplicación. Se le enviará un correo electrónico confirmando el registro. Un centro únicamente deberá tener un coordinador, y un coordinador sólo lo será de un centro. Además, no pueden existir dos coordinadores con el mismo correo electrónico, aunque sea en dos centros distintos, y tal como dijimos en la Sección 1.3.2, por limitaciones de tiempo, no con-sideraremos la posibilidad de que un centro tenga más de un coordinador. Si se diera el caso de que dos personas, por error, creasen por separado el mismo centro, este error no debería ser preocu-pante, ya que en el caso de que ocurriera, sólo uno de los dos debería tener los datos de todos los participantes, por lo que el otro coordinador no podría llenar los datos de los participantes. En el caso de tener ambos coordinadores todos los datos, el segundo que trate de rellenar los datos no podrá, porque el correo electrónico de los participantes no se puede repetir, aunque se trate de otro centro.

Los coordinadores serán quienes lleven a cabo toda la carga de datos, desde los datos del centro correspondiente hasta los de los participantes (nombre, apellidos, correo electrónico, teléfono, di-rección y coordenadas del punto de recogida, las plazas de su coche en caso de tenerlo y su horario). Los coordinadores también podrán editar tanto los datos de su propio centro como los datos de los participantes del mismo, pudiendo eliminarlos si fuera necesario.

El coordinador dispondrá de todos los datos de los participantes porque estos mismos se los habrán dado al coordinador personalmente antes de cargarlos en la aplicación. Además, una vez el coordi-nador haya introducido los datos de un participante, se enviará un correo electrónico al mismo con un enlace, de modo que tendrá que acceder a este enlace para confirmar que acepta que los datos


introducidos son suyos y da permiso a la aplicación para usarlos y mostrarlos en la pantalla de re-sultados. Una vez acepte se le enviará otro correo electrónico con una contraseña para acceder a la asignación final.

Por otra parte, los participantes cuyos datos ha añadido el coordinador a la aplicación, no podrán llevar a cabo ninguna operación, solo podrán ver la asignación final a partir de la URL aleatoria que reciben automáticamente al confirmar que dan permiso a la aplicación para usar sus datos. Para acceder a esta URL tendrán que introducir una contraseña que recibirán cuando el coordinador del centro decida (cuando tenga las asignaciones de conductores y acompañantes bien calculadas). Una vez se haya introducido la clave de acceso correcta, se mostrará un horario con las horas de cada día, tanto de ida como de vuelta, con todas las asignaciones, indicando en cada una el conductor y sus acompañantes. Además, en esta misma página, se mostrará un listado de los correos electróni-cos y los teléfonos de los participantes (el mostrar estos datos es el motivo por el que hay que ac-ceder con contraseña).

Esta asignación final se calculará cuando el coordinador decida solicitar el cálculo del algoritmo de agrupación. El cálculo de esta asignación no será inmediato, ya que el número de operaciones será muy elevado y dependerá del número de usuarios, de modo que cuantos más usuarios, más opera-ciones habrá que realizar y por lo tanto más tiempo costará el cálculo de la asignación óptima. En este cálculo se dividirá a los participantes en distintas zonas dependiendo de la dirección de recogida que se haya introducido. Una vez este hecho el cálculo, el coordinador deberá poder acceder a la página de resultados y enviar la clave de acceso a todos los usuarios a través de la aplicación.

Por lo tanto, resumiendo todo lo anterior, los datos con los que se trabajarán en la aplicación serán:

Centro: nombre, descripción y clave de acceso. Coordinador: nombre, apellidos, email y teléfono. Participante: nombre, apellidos, email, teléfono, plazas del coche (cero en caso de no dis-

poner de coche), descripción del coche, punto de recogida (no tiene por qué ser su domici-lio, puede ser la de un punto cercano) y coordenadas del mismo (necesarias a la hora de calcular la asignación óptima). Estas coordenadas se calcularán automáticamente gracias a un mapa que se mostrará en el formulario para crear un participante, no tendrán que ser introducidas manualmente.

Horario: Cada participante tendrá varios horarios, de modo que en cada uno de ellos guar-daremos un día de la semana, una hora, y un indicador de si es para ir o para volver. Por ejemplo, si un usuario va los lunes a las 9:00 y vuelve a las 15:00, tendrá dos horarios para el lunes.

El rol de coordinador podrá realizar las siguientes operaciones:

Modificar sus propios datos, mencionados anteriormente. Modificar los datos del centro. Añadir, modificar o eliminar participantes. Añadir o quitar horarios a cada uno de los participantes. Solicitar la división de los participantes en distintas zonas. Solicitar la agrupación de los participantes. Esta acción llevará a cabo la agrupación que de-

tallaremos en la Sección 2.3.


Generar una dirección URL aleatoria que dirija a la planificación calculada, la cual se enviará automáticamente por correo electrónico a todos los participantes.

Enviar por correo electrónico la clave de acceso a todos los participantes. Para poder llevar a cabo esta operación se tendrá que haber calculado la agrupación previamente.

Llevar a cabo modificaciones en el horario de los participantes tras calcular el algoritmo de agrupación. Es decir, podrá cambiar el horario de cualquiera de los participantes, añadir o eliminar participantes una vez están calculadas las asignaciones de conductores y acompa-ñantes. Para que estas modificaciones tengan efecto en la pantalla de resultados, el coordi-nador deberá volver a ejecutar el algoritmo de agrupación.

2.2 Requisitos no funcionales La aplicación deberá funcionar y visualizarse correctamente en las versiones más recientes de los navegadores modernos, tanto para ordenador como para teléfono móvil, independientemente del sistema operativo. Para facilitar este requisito se usará un diseño adaptativo (Responsive Design).

Para proteger la seguridad de los datos de los usuarios, se usarán los distintos métodos de seguridad que implanta Laravel, garantizando que los datos personales sólo sean visibles por los participantes del mismo centro.

Además, debido al coste computacional del algoritmo de agrupación, se llevarán a cabo acciones para optimizar este proceso y evitar denegaciones de servicio, como por ejemplo una revisión ex-haustiva de todo el código generado para el algoritmo, con el objetivo de evitar cualquier paso en falso. La aplicación en ningún momento tendrá que dejar de funcionar por sobrecarga del servidor al realizar el cálculo. En cuanto al tiempo, no se aplica ninguna restricción.

Por último, la aplicación, al tratarse de un proyecto Laravel en su versión 5.1, necesitará como mí-nimo un servidor HTTP Apache que cuente con:

Versión de PHP ≥ 5.5.9. Versión de MySQL ≥ 5 (si se hubiera usado otro sistema gestor de base de datos no sería

necesario). Composer instalado.

2.3 Descripción de la agrupación Con el objetivo de entender claramente el sentido que tienen los requisitos funcionales y no funcio-nales, es necesario describir el funcionamiento principal de la aplicación, que consistirá en el algo-ritmo de agrupación de los participantes en conductores y acompañantes.

Nuestro problema consistirá en agrupar cada día de la semana a los distintos usuarios que estén apuntados en la aplicación, tanto para el viaje de ida como para el de vuelta de cada día. Esta agru-pación deberá ser lo más óptima posible, de modo que no siempre conduzcan los mismos partici-pantes. Para ello se tendrán en cuenta factores como los horarios de los participantes, la localización de sus puntos de recogida o las conducciones ya hechas en esa misma semana.


Comenzaremos agrupando a los usuarios por zonas geográficas a partir de las coordenadas de sus puntos de recogida. En la Figura 2.1, podemos ver un ejemplo de cómo se separarían a los usuarios por la cercanía de sus puntos de recogida.

Figura 2.1. División de varios usuarios en dos grupos dependiendo de la cercanía entre ellos

Una vez tengamos a los usuarios separados por zonas, nos centraremos únicamente en los usuarios de una sola zona. Para cada día de la semana, comenzaremos por calcular todas las horas necesarias, tanto de ida como de vuelta, de los usuarios de la misma zona. En la Tabla 2.1 vemos un ejemplo de lo anterior.

Usuario Lunes Ida Lunes Vuelta Gonzalo 9 13 Lunes Eduardo 9 14

Horas ida Horas vuelta

Rosa 10 14 9 13 … … … 10 14 Miguel 10 13

Tabla 2.1. Ejemplo del cálculo de horas necesarias

Una vez sepamos las horas necesarias, tendremos que saber cuántos conductores harán falta para los usuarios de esa zona cada día, para ello usaremos el número de plazas de los coches de los usuarios. Se dejará como mínimo una plaza libre en cada coche, tanto por motivos de comodidad de los usuarios como de soporte a futuros cambios de horario. Por ejemplo, considerando que todos los coches son de cinco plazas, y que por lo tanto pueden ir cuatro personas por coche, si a las 9:00 van siete personas, harán falta dos coches a esa hora. Este cálculo habrá que hacerlo tanto para todas las horas de ida como de vuelta, de modo que nos tendremos que quedar con el número de coches máximo entre los coches necesarios entre todas las horas de ida o de todas las horas de vuelta. Por ejemplo, si hacen falta dos coches para ir a las 9:00, otros dos para ir a las 10:00, tres para volver a las 14:00 y dos para volver a las 15:00, harán falta en total cuatro coches para ir y cinco para volver. Por lo tanto, serán necesarios cinco coches, tanto para ir como para volver, ya que los coches que se usan para ir, serán los que se usen para volver.

Una vez sepamos cuántos coches van a hacer falta, se generarán todas las combinaciones posibles de conductores, que se validarán una a una para comprobar si son válidas (hay que comprobar que cubre tanto la ida como la vuelta). Este proceso viene ejemplificado en la Tabla 2.2, en la que se muestra un ejemplo con cuatro usuarios. En el ejemplo se calculan todas las combinaciones posi-bles, pero solo nos interesa quedarnos con las que sean válidas. Por ejemplo, la combinación de conductores formada por Eduardo y Rosa, no es válida porque si solo condujeran ellos, Gonzalo y Miguel no podrían volver a la una.


Cálculo de combinaciones de conductores posibles Horarios

Horario ida 09:00 – Gonzalo, Eduardo 10:00 – Rosa, Miguel Horario vuelta 13:00 – Gonzalo, Miguel

14:00 – Eduardo, Rosa Necesarios: 2 conductores

Conductores posibles: Gonzalo, Eduardo, Rosa y Miguel

Combinaciones Gonzalo + Eduardo Gonzalo + Rosa Gonzalo + Miguel Eduardo + Rosa Eduardo + Miguel Rosa + Miguel

Se validan todas las combinaciones, quedándonos en este caso solo con dos válidas

Válidas Gonzalo + Eduardo Gonzalo + Rosa Gonzalo + Miguel Eduardo + Rosa Eduardo + Miguel Rosa + Miguel

Tabla 2.2. Ejemplo de combinaciones válidas para un día cualquiera.

Repetimos todo el proceso anterior para cada día, de modo que al final tendremos una serie de combinaciones de conductores válidas para cada día. Una vez tengamos todas las combinaciones válidas, lo que haremos es juntarlas todas, de modo que nos quedaremos con la combinación más adecuada a partir de los factores comentados anteriormente (horarios, localización y número de conducciones anteriores). Por ejemplo, no será conveniente que una persona conduzca cuatro ve-ces y otra sólo una.

Una vez tenemos la combinación más adecuada de conductores, ya solo falta asignar los acompa-ñantes de cada conductor. Este proceso habrá que hacerlo para cada zona en las que hayamos divi-dido a los usuarios, intentando que cada conductor lleve a los participantes que más cerca tiene, como se puede ver en el ejemplo de la Figura 2.2, donde tenemos dos conductores y 5 acompañan-tes, y asignamos a cada conductor los acompañantes que mejor le vienen.

Figura 2.2. Ejemplo de la elección de los acompañantes una vez se conocen los conductores

Por último, cuando se calcula la combinación óptima para todas las zonas, ya tenemos la agrupación que hay que mostrar a los usuarios finales.

De modo que, como hemos visto, lo que se hará es separar el problema por zonas, de modo que así reduciremos el número de operaciones sin dejar de obtener un resultado óptimo.


3 Diseño 3.1 Diseño de la base de datos 3.1.1 Descripción de la base de datos En nuestra aplicación, existirán dos tipos de usuarios, que serán los coordinadores de los centros, y los participantes de un centro. De cada usuario nos interesará saber su identificador, nombre, ape-llidos, email (no podrá haber dos usuarios con el mismo email), teléfono y rol. Cuando un usuario se registra, únicamente podrá hacerlo como coordinador de un centro, por lo que se le pedirán los datos del centro, que serán el nombre (podrán existir dos centros con el mismo nombre, pero no con el mismo coordinador), una descripción del mismo, una clave para acceder a la agrupación de conductores y acompañantes una vez esté hecha, que será la que necesitarán los participantes para acceder a la página del resultado final, y dos indicadores, uno de ellos para saber si se está calcu-lando el algoritmo de agrupación en ese mismo momento, y el otro para indicar si se ha realizado algún cambio que pueda afectar al resultado de la agrupación después de haberlo calculado por última vez. Estos flags fueron añadidos al diseño de BD con posterioridad para poder llevar a cabo dos de las mejoras realizadas, detalladas en la Sección 6.1. Además, también tendrá que introducir una contraseña de acceso a la cuenta del coordinador. Un coordinador únicamente podrá dirigir un centro y un centro únicamente podrá tener un solo coordinador.

Además de coordinador, un usuario también puede ser participante. Por defecto un coordinador no será participante. Un usuario podrá ser únicamente coordinador, únicamente participante o ser am-bos roles simultáneamente.

De cada participante, al cual se le asignará el centro del coordinador que introduzca sus datos, ade-más de los datos de usuario, nos interesará saber los datos de localización de su punto de recogida, como son un nombre de la localización, una descripción si fuera necesaria, la latitud y la longitud. Además, en el caso de que el participante disponga de coche, se guardarán tanto las plazas máximas como una pequeña descripción del mismo, si no lo tiene se guardará que su coche tiene 0 plazas. Cada participante podrá tener como máximo un coche.

Un participante tendrá asignados varios horarios, en los que en cada uno guardaremos un día de la semana, una hora y si es de entrada o de salida. Cada participante tendrá asignados desde dos a varios horarios, y un mismo horario podrá ser de varios participantes. Además, interesará que estos horarios pertenezcan también a un centro (al del participante), de modo que un centro tendrá varios horarios.

Para los participantes del centro en el que se realiza la agrupación, se guardará para cada uno la zona que se le ha asignado, de modo que un participante podrá tener una zona y una zona podrá tener varios participantes. De cada zona nos interesará saber su número de zona, de modo que la primera zona de un centro será la zona número uno, la segunda zona la zona número 2 y así sucesi-vamente.

Asimismo, a la hora de realizar la agrupación de los participantes de un centro, se registrarán una serie de asignaciones, las cuales tendrán un identificador, un único horario y varios participantes,


de los cuales uno será el conductor. Un participante podrá pertenecer a varias asignaciones (tanto como conductor como no). Además, un mismo horario podrá tener una o más asignaciones.

3.1.2 Diagrama de entidad relación En la Figura 3.1, podemos ver un diagrama de entidad relación que representa la estructura de la base de datos que acabamos de describir en la sección anterior.

Figura 3.1. Diagrama de entidad relación

Las tablas son las siguientes:

USUARIO id nombre apellidos telefono email coordinador participante idCentro CF: Centro

Tipos: id, teléfono (inte ger); nombre, apellidos, email (varchar); coordinador, participante (boolean).

COORDINADOR id contrasenia

CF: Usuario

Tipos: id (integer); contraseña (varchar).

PARTICIPANTE id localidad direccion latitud longitud plazasCoche descripcionCoche idZona confirmacion

CF: Usuario CF: Zona

Tipos: id, idZona (integer); localidad, dirección, descripcionCoche (varchar); latitud, longitud (float); plazasCo-che (integer); confirmación(boolean).


RECUERDOCONTRASENIA idCoordinador fecha codigo

CF: Coordinador

Tipos: idCoordinador (integer); fecha (date), codigo(varchar).

CONFIRMARREGISTRO idParticipante fecha codigo

CF: Participante

Tipos: idParticipante (integer); fecha (date), codigo(varchar).

CENTRO id nombre descripcionCentro plazasCoche ocupadoBD cambiadoBD

Tipos: id, plazasCoche (integer); nombre, descripcionCentro (varchar); ocupadoBD, cambiadoBD (boolean).

HORARIO id dia hora esHoraEntrada idCentro CF: Centro

Tipos: id, idCentro (integer); dia, hora (varchar); esHoraEntrada (boolean).

HORARIOPARTICIPANTE idHorario idParticipante

CF: Horario CF: Participante

Tipos: idHorario, idParticipante (varchar).

ASIGNACIÓN id idHorario CF: Horario

Tipos: id, idHorario (varchar).

ASIGNACIONPARTICIPANTE idAsignacion idParticipante conductor

CF: Asignación CF: Participante

Tipos: idAsignacion, idParticipante (integer), conductor (boolean).

ZONA id idCentro numZona CF: Centro

Tipos: id, idCentro, numZona (integer).

La herencia de Usuario a Coordinador y Participante se planteó realizarla de dos maneras, la primera de ellas es como se ha realizado, y la segunda es creando una única tabla en vez de tres tablas, es decir, de la siguiente forma:


USUARIO id nombre apellidos teléfono email confirmacion contrasenia

idCentro localidad direccion latitud longitud plazasCoche descripcionCoche coordinador participante

Esta forma de realizar la herencia sería más eficiente en el caso de que la tabla Usuario hubiera tenido pocos atributos. Además, en nuestro caso, a la hora de realizar el algoritmo nos interesa que la tabla participante sea lo más simple y ligera posible, ya que accederemos a ella en bastantes ocasiones. Por lo tanto, se ha elegido dividir en tres tablas para llevar a cabo la herencia.

Cabe destacar los dos atributos booleanos de la tabla Centro, ocupadoBD y cambiadoBD. El primero de ellos, ocupadoBD, solamente tendrá valor verdadero mientras se esté realizando el cálculo del algoritmo de agrupación, de modo que, gracias a este atributo, si el coordinador desea realizar algún cambio que afecte a los datos que necesita el algoritmo, como puede ser el horario de un partici-pante, mientras ocupadoBD sea cierto, la aplicación no le dejará guardar estos cambios. Al terminar la ejecución del algoritmo el valor de ocupadoBD se cambiará a falso. El segundo de estos atributos booleanos, cambiadoBD, servirá para indicar que se ha realizado algún cambio en algún dato influ-yente en el resultado del cálculo de la agrupación desde la última vez que se llevó a cabo dicho algoritmo.

3.2 Diseño de la interfaz gráfica Se contemplarán las siguientes pantallas en la aplicación a desarrollar:

Pantalla de bienvenida. Pantalla de registro. Pantalla de coordinador. Pantalla de añadir participante. Pantalla de resultado de agrupación. Pantalla de modificación de horario. Pantalla de error.

Todas las pantallas de la aplicación tendrán una apariencia similar. El conjunto de colores de la apli-cación consistirá en una combinación de distintas tonalidades de gris junto con distintos colores, con el objetivo de mostrar una apariencia sencilla y amigable. El fondo de la aplicación será de color blanco. Todas las pantallas en común una barra de navegación en la parte superior, en la que se mostrarán el logo de la aplicación y enlaces a las distintas pantallas en el caso de estar con la sesión iniciada. Tras descartar algunas opciones, en los siguientes apartados se mostrará un diseño gráfico para cada una de las pantallas de la aplicación.

3.2.1 Pantalla de bienvenida Pantalla que verá cualquier visitante cuando acceda a la aplicación. Desde esta pantalla únicamente se podrá iniciar sesión o registrarse en la aplicación. Tendrá la apariencia mostrada en la Figura 3.2, en la que se ve que únicamente hay un formulario que permite iniciar sesión. En el caso de tratarse de un usuario no registrado, se mostrará también un enlace a la pantalla de registro.


3.2.2 Pantalla de registro Como se ha dicho en el análisis de requisitos, únicamente nos podremos registrar con rol de coor-dinador de un centro, por lo que sólo existirá un formulario de registro, en el que se introducirán los datos tanto del centro como del coordinador. Este formulario será accesible desde la página de bienvenida, pero solo permitirá registrarse con un correo electrónico que no se haya usado previa-mente.

Una vez haya rellenado este formulario, podrá iniciar sesión a partir del formulario de la pantalla de bienvenida del apartado anterior, consiguiendo acceder a la pantalla de coordinador que veremos en el siguiente apartado. En la Figura 3.3, podemos ver un boceto de la pantalla de bienvenida.

Figura 3.2. Pantalla de bienvenida Figura 3.3. Pantalla de registro

3.2.3 Pantalla de coordinador Como se ha dicho anteriormente, el coordinador será el único que podrá añadir participantes, aña-dir y modificar horarios además de solicitar la agrupación de los usuarios. Por lo tanto, lo que el coordinador verá en esta pantalla inicial, serán tres enlaces en la barra de navegación superior que remitirán hacia las páginas correspondientes, en las que podrá llevar a cabo estas operaciones. En el cuerpo de la página se mostrará un enlace a la agrupación calculada y una lista de los participantes apuntados, los cuales se podrán tanto editar como eliminar. En la Figura 3.4 podemos ver una idea de cómo será esta pantalla.

3.2.4 Pantalla de añadir participante Esta pantalla sólo será accesible por el coordinador, y en ella sólo tendrá la opción de añadir parti-cipantes uno a uno. En el formulario, interesa conocer la latitud y longitud del punto de recogida de los usuarios, por lo que se pedirá un nombre de la localización. A partir de este nombre, se mostrará un punto en un mapa integrado en el formulario, en el cual se podrá elegir el punto exacto si no se consigue indicarlo desde el campo de localización. Es de este punto en el mapa del cual se va a conseguir la latitud y la longitud, por lo que el coordinador no tendrá que introducir las coordenadas manualmente. El resto de campos son como los de un formulario normal. En la barra de navegación se mostrará un enlace a cada una de las pantallas a las que tiene acceso el coordinador, menciona-das todas ellas anteriormente. Esta pantalla se puede ver en la Figura 3.5.


Figura 3.4. Pantalla de coordinador Figura 3.5. Pantalla de añadir participante

3.2.5 Pantalla de resultado de agrupación Una vez se haya ejecutado la agrupación, se podrá acceder a esta página. Esta es la única página que será accesible para los participantes. Para acceder a la misma, cada participante habrá recibido por correo electrónico tanto el enlace correspondiente, como la clave de acceso que se les solicitará antes de poder acceder a esta pantalla. Lo que se podrá ver en esta página, es el resultado de llevar a cabo todo el proceso de agrupación, por lo que se mostrará la agrupación de todos los usuarios, detallando hora por hora los distintos grupos (coches) formados con sus respectivos conductores. Además, por petición del cliente, también se mostrarán tanto el teléfono como el correo electrónico de los usuarios. En la Figura 3.6, podemos ver un fragmento del documento con el que se organizan actualmente los profesores del colegio de Calahorra, motivantes del proyecto actual. En la Figura 3.7 vemos un boceto de la página de resultado.

Figura 3.6. Fragmento del documento actual de agrupación (con los datos reales modificados)

3.2.6 Pantalla de modificación de horario Esta pantalla sólo será accesible por el coordinador, y en ella podrá llevar a cabo modificaciones del horario de un participante, de modo que para que estos cambios sean notables en caso de haber una agrupación ya calculada, el coordinador debe volver a solicitar el cálculo del algoritmo de asig-nación de conductores y acompañantes. En la Figura 3.8 podemos ver un diseño previo de esta pan-talla.

3.2.7 Pantalla de error Por último, esta última pantalla seguirá la misma temática que las páginas anteriores y mostrará el error HTTP correspondiente, sin datos de depuración.


Figura 3.7. Pantalla de resultado de agrupación Figura 3.8. Pantalla de modificación de horario

3.3 Diseño del algoritmo Para comprender mejor y facilitar la implementación del algoritmo de agrupación, se describirán en este apartado cada uno de los pasos que se tendrán que llevar a cabo.

Tanto en el diseñó como en la implementación se intentará optimizar el proceso de todo el algo-ritmo, ya que tiene que realizar una gran cantidad de operaciones. Por lo tanto, se intentará llevar a cabo un diseño con el mínimo número de operaciones.

Una vez tengamos seleccionados a los conductores, habrá que decidir los acompañantes de cada uno, que se elegirán mediante requisitos como la cercanía de los mismos.

A continuación, enumeraremos cada uno de los pasos que se llevarán a cabo en el algoritmo, junto con una breve explicación de cada uno:

1. Calcular el número de zonas en las que dividir a los usuarios. Este número dependerá del número de los participantes que tenga el centro, de modo que el número de zonas respon-derá a la siguiente expresión:

redondeoHaciaArriba(númeroUsuarios/20)

El objetivo es que cada zona tenga unos 16 usuarios. 2. Distribuiremos en zonas a los usuarios. Es decir, si el número de zonas anterior es cuatro,

tendremos que distribuir a los usuarios para cuatro zonas. Para ello utilizaremos el algo-ritmo de K-means, el cual agrupa distintos puntos por su cercanía en función de sus coor-denadas, en la Figura 2.1 hemos visto un ejemplo sencillo de cómo actuaría este algoritmo.

3. Para cada zona y día de la semana: a. Calcular todas las horas de ida y de vuelta. Recorreremos todos los participantes de

la zona correspondiente, de modo que obtendremos todas las horas tanto de ida como de vuelta, además de que participantes van en cada hora.

b. Calcular el número de coches. Para ello será necesario establecer el número de per-sonas que van en cada coche. Será importante calcular este número contemplando tanto el número de participantes en las horas de ida como en las horas de vuelta. El número de coches que obtendremos será el máximo entre el número de coches ne-cesarios a la ida y a la vuelta. Es decir, si necesitamos cuatro coches entre todas las horas de ida, y cinco coches entre todas las horas de vuelta, el número de coches será cinco.


c. Calcular todas las combinaciones de conductores. En el paso anterior hemos calcu-lado el número de coches, quedándonos con el máximo entre la ida y la vuelta. De-pendiendo de si este máximo ha sido en la ida o en la vuelta, distinguiremos tres formas de distinguir el cálculo de todas las combinaciones de conductores:

i. Si el máximo se ha obtenido con el número de coches necesarios para la ida, obtendremos todas las combinaciones posibles de conductores para cada hora de ida.

ii. Si el máximo número de coches se ha obtenido con los necesarios para la vuelta, se haría el proceso anterior, pero con las horas de vuelta.

iii. Por último, existe la opción de que el número de coches necesarios para la ida sean los mismos que para la vuelta. En este caso se llevará a cabo el proceso anterior tanto para las horas de ida como de vuelta, obteniendo todas las combinaciones de conductores.

d. Validar las combinaciones. Este paso se realizará simultáneamente con el paso 3.c. A la vez que calculamos todas las combinaciones de un día, hay que comprobar si con cada una de ellas, todos los participantes pueden tanto ir como volver. Estas combinaciones serán las que se guarden para pasar al siguiente paso. En la Tabla 2.2 podemos ver un pequeño ejemplo de cómo sería este paso de validación.

e. Una vez se hayan comprobado todos los días para una zona, comparar las combina-ciones de cada día y seleccionar la mejor. Para decidir cómo de buena es una com-binación, tendremos en cuenta que el número de conducciones de un mismo con-ductor, cuanto menor sea mejor. Por lo tanto, usaremos valores como el número medio de conducciones, de modo que buscaremos que el reparto de conducciones esté lo más repartido posible.

4. Añadir a los acompañantes de cada conductor. Por último, una vez ya conocemos la com-binación óptima con los conductores que tendremos, para cada hora de cada día, seleccio-naremos los acompañantes de cada conductor. Esta selección se realizará utilizando la va-riante del algoritmo del problema de los matrimonios estables llamada problema de los hospitales y los residentes. El problema original (el de los matrimonios estables) consiste en realizar el emparejamiento de hombres y mujeres a partir de las preferencias tanto de cada uno de ellos como de cada una de ellas. La variante que nosotros usaremos se basará a la explicada por Marina Blanco Peña en el apartado 1.3 de su Trabajo fin de Grado en Mate-máticas (Sección 9.IV), en la que se trata el mismo problema, pero con datos incompletos. Para asignar las preferencias de cada conductor y cada acompañante se tendrá en cuenta la distancia entre la localización del punto de recogida de los conductores y los acompañan-tes. Tras decidir los acompañantes, se guardarán todas las asignaciones de conductor-acom-pañantes y se mostrarán a los usuarios finales. En la Tabla 3.1, podemos ver un ejemplo de cómo sería este proceso.

En los Bloques de Código 3.1 y 3.2 podemos ver el pseudocódigo del algoritmo que acabamos de describir.


Cálculo de los acompañantes de cada conductor Cada conductor establece que participantes tiene más cerca de los que coinciden en su hora

(en el ejemplo estaríamos en una hora con dos conductores, Eduardo y Miguel) Eduardo 1-Gonzalo 2-Alan 3-Rosa 4-Laura Miguel 1-Laura 2-Rosa 3-Alan 4-Gonzalo

Cada participante establece que conductores tiene más cerca Gonzalo 1-Eduardo 2-Miguel Alan 1-Miguel 2-Eduardo

Rosa 1-Miguel 2-Eduardo Laura 1-Miguel 2-Eduardo Tras aplicar el algoritmo de los matrimonios estables obtendríamos lo siguiente (cada conduc-

tor tendrá asignados unos participantes determinados): Eduardo Gonzalo Miguel Laura + Rosa + Alan

Tabla 3.1. Ejemplo del algoritmo de los matrimonios estables

participantes <- obtenerParticipantes() numParticipantes <- participantes.tamano() //PASO 1 numZonas <- redondeoSuperior(numParticipantes/16); //PASO 2 participantesEnZonas <- kMeans(participantes, numZonas) //PASO 3 zonaActual <- 1 combinacionesValidas <- [] zonaActual <- 0 mientras que (zonaActual < numZonas)

para cada dia de la semana //PASO 3.a horasIda, horasVuelta <- [] participantesZona <- obtenerParticipantes(participantesEnZonas, zonaActual) para cada participante en participantesZona si (participante.horaIda no pertenece a horasIda) añadir(participante.horaIda, horasIda) fsi si (participante.horaVuelta no pertenece a horasVuelta) añadir(participante.horaVuelta, horasVuelta) fsi fpara //PASO 3.b numeroCochesIda, numeroCochesVuelta <- 0 para cada hora en horasIda numeroCochesIda <- numeroCochesIda + numeroParticipantesEn(hora, zonaActual, diaSemana) fpara para cada hora en horasVuelta numeroCochesVuelta <- numeroCochesVuelta + numeroParticipantesEn(hora, zonaActual, diaSemana) fpara numeroCoches <- maximo(numeroCochesIda, numeroCochesVuelta) //PASO 3.c combinaciones <- [] si(numeroCoches = numeroCochesIda) combinaciones <- unir(combinaciones, obtenerCombinaciones(numeroCoches, horasIda)) fsi

CONTINÚA EN EL BLOQUE DE CÓDIGO 3.2 Bloque de código 3.1. Pseudocódigo del algoritmo de agrupación (1/2)


CONTINUACIÓN DEL BLOQUE DE CÓDIGO 3.1 si(numeroCoches = numeroCochesVuelta) combinaciones <- unir(combinaciones, obtenerCombinaciones(numeroCoches, horasVuelta)) fsi //PASO 3.d añadir([dia, zona, validar(combinaciones)]) a combinacionesValidas

//al validar combinaciones eliminaremos las que no son posibles //PASO 3.e si (es el ultimo dia) combinacionOptimaZona<-recorrerArbolValorando(combinacionesValidas); //combinacionOptimaZona contendrá la zona, una opción y su valor, //se quedará con la mejor opción al final fsi

diaSemana <- siguiente(diaSemana) fpara zonaActual <- zonaActual+1 fmq opcionOptima <- juntar(combinacionOptimaZona) //PASO 4 asignaciones <- [] para cada opcion de opcionOptima para cada conductor de opcion.conductores añadir([dia, hora, conductor, [matrimoniosEstables(participanes)]) fpara fpara

Bloque de código 3.2. Pseudocódigo del algoritmo de agrupación (2/2)

Las llamadas a las funciones de kMeans y de matrimoniosEstables representan el funcionamiento propio de ambos algoritmos.


4 Implementación 4.1 Implementación de la base de datos En cuanto a la implementación de la base de datos, tanto la creación como la utilización posterior, se ha realizado utilizando el ORM (Object Relational Mapping) integrado en Laravel, Eloquent ORM, de modo que se podría cambiar el tipo de base de datos de MySQL a cualquier otro tipo sin que la aplicación deje de funcionar. A continuación, tenemos dos fragmentos en los que se ve cómo se ha realizado el acceso a base de datos.

El primer ejemplo (Bloque de código 4.1) es una instrucción para crear la tabla “centro”.

class CreateCentroTable extends Migration { public function up(){//si se ejecuta entera -> commit Schema::create('centro', function(Blueprint $table) { $table->increments('id'); $table->timestamps(); $table->string('nombreCentro', 20); $table->string('centroDescripcion', 100); $table->smallInteger('nZonasElegida')->unsigned()->nullable(); }); } public function down(){//rollback Schema::drop('centro'); } }

Bloque de código 4.1. Implementación de la creación de la tabla centro.

Todas las tablas se han creado como en el Bloque de código 4.1, utilizando el sistema de migraciones de Laravel, de modo que mediante el comando

php artisan migrate

se construye la base de datos a partir de los archivos de migraciones. Si se quiere realizar algún cambio en la base de datos, se realiza en un nuevo fichero de migraciones, habrá que volver a eje-cutar el mismo comando, de modo que se realizarán los cambios pendientes en la base de datos y, si todo va bien (método up) se hace commit, si no rollback (método down).

De este modo, utilizando el sistema de migraciones, aunque al principio es bastante más costoso, se puede realizar en cualquier momento un cambio en la base de datos sin peligro. Además, facilita la instalación de la aplicación en más de un ordenador o servidor, ya que se puede crear la estructura de la base de datos a partir de estos ficheros en cualquier momento.

En cuanto a las consultas a la base de datos, se han llevado a cabo en los modelos correspondientes, utilizando también el ORM integrado en Laravel para no depender de una base de datos determi-nada.


DB::table('usuario') ->join('participante', 'usuario.id', '=', 'participante.idUsuario') ->where('usuario.idCentro', '=', $idCentro) ->select('usuario.*', 'participante.*') ->get(); //equivalente a: select usuario.*, participante.* from usuario join participante on usuario.id=participante.id where usuario.idCentro = ? //en este caso ? sería $idCentro

Bloque de código 4.2. Ejemplo de consulta a la base de datos

4.2 Implementación del algoritmo A la hora de implementar el algoritmo, nos hemos encontrado con varios problemas. A continua-ción, mostramos cuales han sido estos problemas. En alguno de los siguientes apartados, por cues-tión de espacio no se ha podido ser suficientemente detallista, por lo que tienen una explicación más amplia o ejemplos completos en el Anexo B.

4.2.1 Calcular todas las combinaciones de conductores en un mismo día Este cálculo se corresponde al paso 3.c del algoritmo, explicado en la Sección 3.3. En este paso se calculan todas las combinaciones posibles de conductores en un mismo día.

Comenzaremos guardando cada una de las opciones de quien conduce en cada hora en un único vector, como se puede ver en la Tabla 4.1, en la que se muestra un ejemplo con dos horas. El valor de las componentes de los vectores son los identificadores de los participantes, de modo que en la primera hora las opciones serían que condujeran los participantes con identificadores 6 y 10, o los participantes 6 y 12, 6 y 14…

Primera componente del vector de opciones, co-rrespondiente a las opciones de conductores para la primera hora (necesarios dos conductores).

Segunda componente del vector de opciones, co-rrespondiente a las opciones de conductores para la segunda hora (necesarios dos conductores).

array (size=15) 0 => array (size=2) 0 => int 6 1 => int 10 1 => array (size=2) 0 => int 6 1 => int 12 2 => array (size=2) 0 => int 6 1 => int 14 . . .

array (size=10) 0 => array (size=2) 0 => int 7 1 => int 11 1 => array (size=2) 0 => int 7 1 => int 15 2 => array (size=2) 0 => int 7 1 => int 16 . . .

Tabla 4.1. Ejemplo de las opciones de conductores en cada hora

Lo que necesitamos es calcular todas las combinaciones posibles escogiendo una opción de cada hora, es decir, en el ejemplo de la Tabla 4.1, nos interesaría combinar cada una de las componentes del primer vector con cada una de las del segundo vector, obteniendo combinaciones como [0][0]


(significan que conducen los participantes con identificador 6, 10, 7 y 11), [0][1] (participantes con identificador 6, 10, 7, 15) …

Para calcular estas combinaciones, se ha llevado a cabo un método recursivo, ya que hasta el mo-mento de ejecutar el algoritmo no se sabe cuántas horas distintas va a haber en cada día. La imple-mentación de este método la podemos ver en el Bloque de código 4.3.

public function unir($fila, $matriz, $resultado, $paso) { $tamanoPaso = sizeof($paso) + 1; for ($i = 0; $i < sizeof($matriz[$fila]); $i++) { array_push($paso, $matriz[$fila][$i]); if ($fila + 1 < sizeof($matriz)) { $resultado = $this->unir($fila + 1, $matriz, $resultado, $paso); } else { if ($this->validar($paso)) { array_push($resultado, $paso); } } array_pop($paso); } return $resultado; }

Bloque de código 4.3. Método para calcular todas las combinaciones de conductores en un día

El significado de cada uno de los parámetros de entrada del método es:

Fila: número de la fila en la que nos encontramos en la matriz. Matriz: Vector de vectores, donde cada uno de los vectores que compone la matriz, tiene

como componentes todas las opciones de conductores de una hora, es decir, la matriz es-tará formada por vectores como los dos mostrados en la Tabla 4.1.

Resultado: Será donde se guarden cada una de las combinaciones que vamos calculando, por ello es la salida del método.

Paso: En paso, lo que iremos guardando es un elemento de cada una de las filas de la matriz, es decir, un elemento de cada uno de los vectores que componen la matriz. Cuando la va-riable paso tenga tantos elementos como filas tenga la matriz, quiere decir que en paso tenemos una opción completa, y por lo tanto la guardamos en la variable resultado en el caso de que la opción sea válida.

El proceso que se ha seguido en este método consiste en recorrer todas las filas de esta matriz y quedarnos con una componente de cada fila. Es en este momento donde utilizamos la recursividad, ya que en la variable paso vamos guardando un elemento de cada fila, y hasta que no tengamos uno de cada fila no podremos comprobar si la combinación que tenemos es válida.

Finalmente, como solución de este método, obtenemos un vector donde sus componentes son cada una de las combinaciones válidas para un día correspondiente. Este vector viene representado en la Tabla 4.2.


Vector con las combinaciones válidas array (size=68) 0 => array (size=2) 0 => array (size=2) 0 => int 6 1 => int 10 1 => array (size=2) 0 => int 7 1 => int 11 1 => array (size=2) 0 => array (size=2) 0 => int 6 1 => int 10 1 => array (size=2) 0 => int 7 1 => int 15 . . .

Tabla 4.2. Ejemplo de cómo se guardan las combinaciones finales

4.2.2 Validar una combinación para un día A la hora de calcular todas las combinaciones de cada día, hemos visto que antes de guardar cada combinación, comprobamos si ésta es válida.

Diremos que una combinación es válida siempre que, con los conductores de esa opción, se pueda tanto ir como volver, es decir, que no haya horas en las que van participantes y que a ninguno de ellos le toque conducir. Por lo tanto, en esta función comprobamos si con una combinación de conductores (que por el modo en el que la hemos calculado ya sabemos que es válida para la ida o la vuelta), tendremos que calcular si es válida para el viaje contrario, es decir, si es válida para la vuelta comprobar si lo es para la vuelta o viceversa.

Necesitaremos tener todos los participantes y todas las horas del periodo contrario. Tanto los par-ticipantes y las horas necesarias, las hemos calculado y guardado en la memoria caché previamente a calcular todas las combinaciones y validarlas, evitándonos de este modo tener que llevar a cabo las mismas consultas constantemente.

En el Bloque de código 4.4, se muestra la implementación del método validar, en el que comproba-mos si el número de conductores de cada hora es suficiente para el número de participantes que van a esa hora. Para realizar esta comprobación, comparamos el número de conductores multipli-cado por las plazas por coche por defecto con el número de participantes total que van en esa hora, de modo que, si la primera cantidad es mayor o igual que la segunda, la combinación será válida para esa hora. Hay que repetir este proceso para cada hora, de manera que, si en una hora obtene-mos que la combinación no es válida, devolvemos false y acabamos la validación. Si tras comprobar todas las horas no hemos devuelto false, significa que la combinación es válida y devolvemos true.

Primera combinación final, el primer día conducen los partici-pantes con id 6, 10, 11 y 7.

Segunda combinación final, el segundo día conducen los partici-pantes con id 6, 10, 7 y 15.


public function validar($paso) { $plazasCocheDefecto = (int) Centro::obtenerPlazasPorDefecto( Session::get('idCentro'))[0]->plazasCoche; $conductores = []; foreach ($paso as $p) { $conductores = array_merge($conductores, $p); } $horas = Cache::get(Session::get('idCentro') . 'horasContrarias'); $participantes = Cache::get(Session::get('idCentro') . 'participantesContrarios'); foreach ($horas as $h) { $nc = count($conductores) - ( count(array_count_values( array_merge($participantes[$h], $conductores)) ) - count($participantes[$h])); if (sizeof($participantes[$h]) > $plazasCocheDefecto * ($nc)) { return false; } } return true; }

Bloque de código 4.4. Implementación de la validación de una combinación

4.2.3 Unión de todas las combinaciones válidas Una vez ya tenemos todas las combinaciones válidas para cada día calculadas, es el momento de juntar todas, y de este modo, combinando una opción de cada día, poder elegir cuál es la mejor elección de conductores.

Para decidir cuál es la mejor opción, haremos uso del método valorar, al que le meteremos una combinación con una opción de cada día, a la que se le pondrá “nota”, de modo que la valoración con menos “nota” será la mejor opción. Teniendo en cuenta que la valoración mínima es uno (en el siguiente apartado se indicará porqué), si una combinación obtiene un uno de valoración, dejare-mos de valorar todas las demás, ya que ya tenemos una combinación totalmente óptima. Este mé-todo de valoración y el significado de esta “nota” se explica en el siguiente apartado (4.2.4).

En el Bloque de código 4.5 se muestra el método utilizado para juntar estas combinaciones, que tiene la misma estructura que el método utilizado para calcular todas las posibilidades de conduc-tores válidos en un día (Bloque de código 4.3).

El significado de las variables de entrada será similar a las vistas en el Bloque de código 4.3, en el método recorremos todas las filas de matriz y nos quedamos con una componente de cada fila. Es en este momento donde utilizamos la recursividad, ya que en la variable paso vamos guardando un elemento de cada fila, y hasta que no tengamos uno de cada fila no podremos valorar esa combina-ción.

Una vez podamos valorar una combinación, se comparará su valoración con la de resultado, guar-dando en resultado la que sea menor. En el caso de que la valoración sea uno, devolveremos direc-tamente esta opción cortando lo antes posible la ejecución de esta función.


public function unir2($fila, $matriz, $resultado, $paso) { if ($this->valorar($resultado) > 1) { $tamanoPaso = sizeof($paso) + 1; //sumamos uno porque en este paso el tamaño será //uno más que en anterior for ($i = 0; $i < sizeof($matriz[$fila]); $i++) { array_push($paso, $matriz[$fila][$i]); if ($fila + 1 < sizeof($matriz)) { $resultado = $this->unir2($fila + 1, $matriz, $resultado, $paso); } else { if ($this->valorar($paso) < $this->valorar($resultado)) { $resultado = $paso; if ($this->valorar($resultado) == 1) { return $resultado; } } } array_pop($paso); } } return $resultado; }

Bloque de código 4.5. Unión de todas las opciones válidas y elección de la mejor

Destaca que en esta función se invoca tres veces a la función valorar con la variable resultado, en vez de invocarla una sola vez y guardarla en una variable. Esto se debe a que, al ser un método recursivo, si creamos una variable cada vez que entramos, acabaríamos guardando en memoria mu-chas copias de esa variable, y tras realizar bastantes pruebas, invocando la función valorar tres veces el tiempo de ejecución y el uso de memoria es menor que si lo invocamos una vez y lo asignamos a una variable.

4.2.4 Valoración de una combinación de conductores El último paso para obtener la mejor combinación de conductores, es quedarnos con la que obtenga una mejor valoración (cuanto menor sea una valoración mejor será). En este apartado veremos cómo valorar cada opción.

Para valorar una opción, se tendrá en cuenta que todas las opciones tienen el mismo número de conducciones (esto es así porque el número de plazas por coche se considera igual para todos los conductores, por lo tanto, siempre serán necesarios el mismo número de coches). El valor de cada valoración seguirá la siguiente fórmula:

El motivo de que para calcular la valoración se sumen tanto la media como la desviación típica, fue a partir de la reunión realizada el 4 de abril con el cliente (se puede consultar en el anexo de reunio-nes - C.1). Antes de esta reunión, se había considerado valorar las combinaciones utilizando única-mente la media de conducciones, pero tras la reunión mencionada se decidió tener en cuenta tam-bién la desviación típica. Vamos a ver un ejemplo de porque hay que tener en cuenta la desviación típica. Supongamos que tenemos dos combinaciones distintas, en una Eduardo conduce tres veces


y Rosa una vez, en la otra ambos conducen dos veces. Si solo tenemos en cuenta la media, el valor de ambas combinaciones es de dos, aunque en la segunda combinación el número de conducciones está mejor repartido.

Si nos fijamos en el Bloque de código 4.6, podemos ver que calculamos la media y la desviación típica de la opción que estamos analizando, de modo que devolvemos la suma de ambos valores. Se puede ver que en el caso de que la opción que queramos analizar está vacía se devolverá una valo-ración bastante alta (esto pasará cuando analicemos las primeras opciones únicamente, hasta que tengamos una primera combinación guardada como resultado provisional).

public function valorar($opcion) { $opciones = []; if (count($opcion) == 0) { //esta valoración inicial es muy mala de forma intencionada, solo //entrará cuando introduzcamos una opción vacía return 100; } else { foreach ($opcion as $opc) { foreach ($opc as $op) { $opciones = array_merge($opciones, $op); } } $opcionJunta = array_count_values($opciones); $media = array_sum($opcionJunta) / count($opcionJunta); $desviacionTipica = 0; foreach ($opcionJunta as $op) { $desviacionTipica = ($op - $media) * ($op - $media); } $desviacionTipica = sqrt($desviacionTipica / count($opcionJunta)); return $media + $desviacionTipica; } }

Bloque de código 4.6. Cálculo de la valoración de una combinación de conductores

En el Anexo B, se ha realizado un ejemplo completo sobre el cálculo de la valoración de distintas opciones.

4.2.5 Uso de métodos de terceros Cabe destacar que tanto el método usado para la separación de los usuarios en distintas zonas según la ubicación de su punto de recogida, como el método para asignar los acompañantes de cada con-ductor, se han utilizado librerías externas con el objetivo de acortar el tiempo de implementación.

4.2.5.1 Algoritmo de K-Means Para llevar a cabo la implementación de este algoritmo, se ha utilizado código de terceros, disponi-ble en la bibliografía (9.VI.0). La función de este algoritmo es dividir una serie de coordenadas en distintos grupos, de modo que las coordenadas cercanas entre si estén en el mismo grupo. En la Figura 2.1 se ha visto un pequeño ejemplo del objetivo de este algoritmo.

Por defecto, la librería seleccionada para la implementación sólo permitía la entrada de vectores de dos componentes, la latitud y la longitud, de modo que como resultado devolvía estos vectores separados en los grupos correspondientes. En nuestro caso no nos vale con introducir sólo dos coor-denadas, ya que, al obtener el resultado del algoritmo, queremos saber a qué participante corres-ponde cada coordenada. Por ello, se ha realizado una pequeña modificación en el código original,


de modo que admita introducir vectores de tres componentes, siendo la tercera componente me-ramente informativa, es decir, que no afecta al resultado. En esta tercera componente hemos intro-ducido el identificador de cada participante.

Además, también ha sido necesario realizar otra modificación a la hora de introducir las coordena-das, ya que el algoritmo está preparado por defecto para trabajar con cifras sin decimales, y las coordenadas que nosotros le introducimos tienen hasta cinco decimales. Para solucionar este con-tratiempo, hemos multiplicado todas las coordenadas que introducimos al algoritmo por 100 000, de modo que los cinco decimales desaparecen, y las distancias entre las coordenadas son propor-cionalmente iguales que antes de haber realizado esta multiplicación, como podemos ver en el si-guiente ejemplo, donde calculamos la distancia entre dos coordenadas distintas:

Distancia entre ellas: unidades

Distancia entre ellos: unidades

4.2.5.2 Problema de los matrimonios estables La implementación de este algoritmo ha sido realizada utilizando código de terceros, disponible en la bibliografía (9.VI.0). La función de este algoritmo es emparejar dos tipos de elementos, por ejem-plo, hombres y mujeres (este es el ejemplo más conocido de este algoritmo). Cada hombre ordena las mujeres según sus preferencias. Lo mismo ocurre con las mujeres, que cada una de ellas ordena a los hombres según sus preferencias. Lo que hace el algoritmo, es que a través de estas preferencias empareja a los hombres y mujeres de modo que todos estén lo más satisfechos posible. El caso ideal es encontrarse con el mismo número de hombres y de mujeres, ya que en caso contrario alguien se quedará sin emparejar.

Si enfocamos este problema a nuestro caso, nos encontramos con que tenemos que emparejar en cada hora una serie de conductores con una serie de acompañantes. Si suponemos que todos los conductores admiten hasta tres acompañantes, entonces cada conductor debería poder estar em-parejado con tres acompañantes, y no sólo con uno.

Para conseguir que cada conductor esté emparejado hasta con tres acompañantes, a la hora de meter a los conductores en el algoritmo, introducimos cada conductor tres veces en vez de una (recordar que hemos supuesto que cada conductor puede llevar hasta tres acompañantes). De este modo tendremos 3n conductores en el algoritmo (siendo n el número de conductores distintos). Una vez hemos metido a los conductores en el algoritmo, tenemos que meter a los acompañantes, los cuales queremos emparejar con los conductores. Para que el algoritmo funcione correctamente, tendremos que meter 3n participantes, y puede que no tengamos tantos participantes (en ningún caso va a haber más de 3n participantes ya que nos hemos asegurado de que el número de conduc-tores es siempre el suficiente). Para solucionar esta falta de participantes, añadimos participantes nulos, los cuales no representarán a ningún participante.

Por último, tenemos que insertar las preferencias de cada conductor y de cada participante, de modo que, si hay participantes nulos, estos siempre irán en último lugar en las preferencias de los conductores. En cuanto a las preferencias de los participantes nulos, se introducen de modo alea-torio para no alterar la solución final (si pusiéramos las preferencias de todos los participantes nulos


iguales, podríamos alterar la respuesta, ya que sería bastante posible que se emparejarían todos los participantes nulos con su conductor preferente).

Como solución obtenemos los emparejamientos entre los conductores y los participantes (tanto reales como nulos), de modo que sólo tenemos que quedarnos con los emparejamientos cuyo par-ticipante sea real y guardar estos datos en la base de datos.

4.2.6 Optimización del algoritmo En este apartado veremos algunas modificaciones realizadas al algoritmo que nos ha permitido me-jorar la eficiencia de nuestro algoritmo.

4.2.6.1 Modificación de la comprobación de todos los días En el diseño del algoritmo, se dijo que se calcularían todas las combinaciones de conductores válidas para todos los días y después se combinarían todas quedándonos con la mejor. Durante el periodo de desarrollo se han realizado pruebas con una base de datos pequeña, de 20 usuarios que van sólo durante dos días. Con esta pequeña base de datos todo el proceso del cálculo de la agrupación era bastante rápido, la sorpresa fue al realizar una prueba con una base de datos tan grande como la real (se decidió hacer esta prueba cuanto antes tras la reunión con el tutor del día 19 de abril – Anexo C.2).

Una vez estaba desarrollado todo el algoritmo completo, se probó con una base de datos de tamaño similar a la real. Para ello creamos una base de datos con 40 usuarios (real: 39 usuarios) y 7 días (real: 5 días). Al realizar la primera prueba con esta base de datos el funcionamiento fue totalmente correcto, ya que se realizó la agrupación sin sobrecargar el funcionamiento del servidor en ningún momento, pero el rendimiento fue muy malo, ya que le costó más de una hora calcular dicha agru-pación. Este tiempo se consideró inaceptable, aunque no hubiera restricciones de tiempo. Por lo tanto, se realizó un análisis completo de todo el proceso del algoritmo, incluyendo el cálculo del número de operaciones necesario. En este cálculo, se pudo comprobar que la razón de este au-mento de coste era causado por el aumento de días en la base de datos. Al aumentar el número de días, las combinaciones posibles crecían de manera exponencial, de modo que con una base de datos pequeña de 12 usuarios y 5 días, se calculó que existían más de combinaciones posibles (en el Anexo B.5 se pueden ver estos cálculos). Por lo tanto, era necesario realizar una acotación en el número de días, ya que sino la utilización de nuestro algoritmo en bases de datos con varios participantes y varios días, sería totalmente inviable.

La medida tomada para evitar este crecimiento exponencial del número de opciones, es separar los días en grupos de tres, es decir, si tenemos 5 días, primero calcular la combinación óptima para los tres primeros días y después calcular la combinación óptima para los dos últimos. De este modo, la combinación obtenida finalmente no es la mejor, ya que se tratará de una unión de combinaciones óptimas, aunque tras realizar varias pruebas, el reparto de conducciones tras tomar esta medida sigue siendo totalmente justo.

Tras aplicar esta medida, el coste de realizar el algoritmo con una base de datos de 40 usuarios y 7 días, supera levemente el minuto, ya que con la medida tomada nos evitamos comprobar miles de combinaciones poco valiosas (por ejemplo, las que conduce la misma persona durante cuatro, cinco o más días), y que, por lo tanto, nunca hubieran sido elegidas. En el Anexo mencionado anterior-mente (B.5) se han realizado todos los cálculos para ambas opciones.


4.2.6.2 Paso por referencia de la variable principal en los métodos recursivos Como se ha visto en las secciones 4.2.1 y 4.2.3, la implementación de ambos pasos se realiza con dos algoritmos recursivos similares. En ambos casos tenemos una cabecera con la siguiente forma:

unir($fila, $matriz, $resultado, $paso);

En ambos métodos recursivos, se modifican en su interior las variables fila, paso y resultado, mien-tras que la variable matriz no se modifica en ningún caso. Es por esto que tras pensar varias opciones sobre cómo ahorrarnos tener que reservar memoria para la variable matriz, la cual contiene todas las opciones que tenemos que recorrer. La principal alternativa que se contempló para no tener que reservar memoria constantemente para la misma variable, es meter los datos de matriz en una va-riable estática, a la cual podríamos acceder sin ningún problema desde dentro del método, pero esta idea fue descartada ya que la idea es que el algoritmo soporte un comportamiento concurrente, es decir, que desde dos centros distintos puedan solicitar la agrupación a la vez, y si usamos variables estáticas los datos de distintos centros se sobrescribirían entre ellos.

Otras alternativas para mejorar el rendimiento, fue el obtener los datos de la variable matriz direc-tamente desde base de datos o utilizando la memoria caché, pero tras probar estos métodos, la eficiencia del algoritmo se vio considerablemente perjudicada.

Finalmente, tras consultar la documentación de PHP y algún ejemplo, se decidió pasar la variable matriz por referencia (poniendo un ‘&’ antes de su declaración), en vez de por valor. De este modo, todas las llamadas a esta variable se referirán en todo momento al mismo espacio de memoria, al contrario que si la pasamos por valor, donde cada vez que hagamos una llamada al método se utiliza un nuevo espacio de memoria para la variable matriz. Eso sí, si realizáramos un cambio sobre esta variable, este cambio se guardaría en el mismo espacio de memoria al que accederán las siguientes iteraciones del método recursivo. Además, si dentro de estos métodos asignáramos la variable ma-triz a una nueva variable, se crearía una copia de la variable matriz en memoria, por lo que esta opción dejaría de ser ventajosa. Por lo tanto, la cabecera final de estos métodos es la siguiente

unir($fila, &$matriz, $resultado, $paso);

4.2.6.3 Liberar recursos innecesarios una vez han sido utilizados Durante la implementación del algoritmo, ha sido necesario crear una gran cantidad de variables, que después de la realización completa del algoritmo, el propio recolector de basura (garbage co-llector) de PHP liberará automáticamente la memoria inutilizada para evitar hacer un gasto innece-sario de la misma. Pero en nuestro algoritmo, al trabajar con combinaciones, el tamaño de algunas variables de tipo array en ocasiones crece considerablemente, ocupando gran parte de la memoria y ralentizando la ejecución del cálculo, llegando a sobrecargar la ejecución de la aplicación dando el correspondiente error. Es por ello, que se ha realizado un seguimiento de cada una de las variables de mayor tamaño que se han creado durante el algoritmo, eliminándolas de memoria una vez ya no son necesarias utilizando la función unset, predefinida en PHP. En el Bloque de código 4.7, vemos dos ejemplos de uso de esta función, que admite cualquier número de parámetros.

unset($participantes); ... unset($resultadoProvisional, $valoracionFinal, $valoracionProvisional);

Bloque de código 4.7. Ejemplo de uso de la función unset


4.2.6.4 Utilización de la memoria caché Para ahorrar el uso excesivo de memoria mientras se usa el algoritmo de agrupación, además de liberar la memoria de algunas variables, también se ha hecho uso del sistema de memoria caché implantado en Laravel.

En el Bloque de código 4.8 podemos ver cuáles son las instrucciones para introducir objetos en me-moria caché. Para introducir un elemento en caché, se utiliza el método put, al que primero tenemos que indicarle el nombre con el que lo queremos guardar, que en nuestro caso será de la forma “ID del centro + nombre de la variable”, de modo que al añadir el ID del centro en el nombre, se podrá ejecutar el algoritmo de asignación desde más de un centro a la vez. Como segundo parámetro introducimos el objeto que queremos guardar. El entero que se introduce como tercer parámetro indica el tiempo en minutos que queremos guardar este objeto en memoria caché. Tras introducir en caché estas variables las eliminamos de memoria mediante el método de PHP que hemos expli-cado en el apartado anterior, unset. Para obtener los datos almacenados en caché sólo tenemos que llamar al método get, cuyo funcionamiento es idéntico al del método put.

Cache::put(Session::get('idCentro') . 'nombre', $nombre, 15); unset($nombre); $nombre = Cache::get(Session::get('idCentro') . 'nombre');

Bloque de código 4.8. Introducción de variables en caché para no repetir cálculos

Por defecto, Laravel utiliza un sistema de memoria caché basado en ficheros, de modo que guarda las variables en un fichero y las lee cuando es necesario de manera eficiente. La razón por la que se ha decidido utilizar la memoria caché durante varios pasos del cálculo de las asignaciones, es que, al estar trabajando con combinaciones, podemos llegar a construir varios vectores de un tamaño considerable (20 personas divididas en 5 coches dan lugar a 15504 combinaciones posibles) que en caso de guardarse en memoria ralentizarían considerablemente la aplicación.

4.2.6.5 Realización de consultas completas a la base de datos Durante la realización del algoritmo, se han intentado realizar las mínimas consultas a la base de datos, ya que abusar de la comunicación con la base de datos ralentizaba bastante el algoritmo. Por ello se ha revisado todo el código del algoritmo, intentado reducir al mínimo el uso de estas consul-tas y que cuando sea necesario hacer uso de ellas, que sean lo más completas posibles, de modo que no tengamos que hacer dos consultas y luego combinar los datos de ambas cuando podemos hacerlo todo en la misma consulta. Además, en todos los selects, se ha intentado ser lo más especí-fico posible, con el objetivo de no traer de la base de datos cosas innecesarias.

Otra mejora que se ha realizado para reducir el número de usos de la base de datos, ha sido a la hora de insertar/actualizar más de un elemento a la vez en ella, evitando hacerlo dentro de un bucle o ejecutando secuencialmente varias instrucciones de inserción/actualización similares. Por ejem-plo, en el Bloque de código 4.9, podemos ver cómo un fragmento de como se llevaba a cabo antes la actualización de las zonas de los participantes tras aplicar el algoritmo de K-Means y cómo se realiza ahora. Cada fragmento actualiza los datos de los participantes de una única zona, por lo tanto, estos bloques de código se repiten una vez para cada zona.


Antes de realizar la mejora, se realizaba una consulta para cada participante foreach ($agrupacion->toArray()['points'] as $participante) { $participanteCoordenadas = $participante['coordinates']; DB::table('participante') ->where('id', $participanteCoordenadas[2]) ->update(['idZona' => $zona->id]); } //consulta equivalente: update participante set idZona = ?1 where id = ?2 Los ? indicarán: ?1 = $zona->id y ?2 = $participanteCoordenadas[2]

Después de realizar la mejora, el bucle se sigue haciendo pero solo se realiza una consulta $participantes = []; foreach ($agrupacion->toArray()['points'] as $participante) { array_push($participantes, $participante['coordinates'][2]); } DB::table('participante') ->whereIn('id', $participantes) ->update(['idZona' => $zona->id]); //consulta equivalente: update participante set idZona = ?1 where id in ?2 Los ? indicarán: ?1 = $zona->id y ?2 = $participantes

Bloque de código 4.9. Ahorro del número de consultas al actualizar las zonas de los participantes

4.3 Implementación del control de acceso y seguridad Para acceder a la aplicación como coordinador, es necesario acceder mediante el sistema de login. Además, una vez está dentro de la aplicación, es posible que el administrador envíe datos persona-les por la aplicación, por ello se ha decidido que desde la propia página de login se utilice una cone-xión segura mediante HTTPS, de modo que evitaremos que cualquiera con un sniffer HTTP pueda apoderarse de los datos que enviamos por la aplicación. Para implementar el uso de HTTPS, sola-mente ha sido necesario indicárselo en el archivo de rutas, de modo que englobaremos todas las rutas que queremos que sólo admitan una ruta segura. En nuestro caso, al tener pocas páginas e introducir datos en la gran mayoría, hemos utilizado una conexión segura en todas ellas. Para ello, solamente hemos necesitado llevar a cabo dos modificaciones:

1. Englobar en el archivo de rutas de la aplicación todas las rutas con una instrucción en la cual se indica que sólo se accederá a esas rutas si se realizan mediante una conexión segura. Esta instrucción se puede ver en el Bloque de código 4.10.

Route::group(['https'], function () { // Authentication routes... Route::get('login', ['https', 'as' => 'login', 'uses' => 'Auth\AuthController@getLogin']); ...

Bloque de código 4.10. Instrucción para las rutas seguras

2. Modificar las rutas de la aplicación, de modo que en vez de utilizar la instrucción URL::to(di-rección relativa) utilizaremos URL::secure(dirección relativa), que automáticamente usa HTTPS.

En cuanto al formulario de login, para utilizar el sistema de autenticación con el que cuenta Laravel, hemos tenido que realizar las siguientes configuraciones previas:


Necesitamos una tabla en la base de datos en la que se encuentren tanto el correo electró-nico como la contraseña (los datos de acceso). Pero en nuestro caso, estos dos campos es-tán guardados en tablas distintas (el correo electrónico está en la tabla usuario y la contra-seña en la tabla coordinador). Para solucionar este problema, nos hemos visto obligados a crear una vista SQL de las dos tablas anteriores. En este caso no se ha usado el ORM implan-tado en Laravel, ya que no permite crear vistas SQL, por lo que se ha usado SQL directa-mente, que hemos introducido dentro de una migración, como podemos ver en el Bloque de código 4.11.

class CreateVistaLoginTable extends Migration { public function up() { DB::statement("CREATE VIEW tablalogin AS SELECT usuario.id, usuario.email, coordinador.password FROM `usuario` JOIN coordinador ON coordinador.id = usuario.id"); } public function down() { DB::statement("DROP VIEW tablalogin"); } }

Bloque de código 4.11. Creación de la vista SQL de login

Una vez tenemos una tabla con el email y la contraseña, sólo hay que introducir en el archivo de configuración auth.php todos los datos de esta tabla.

Una vez tenemos esta configuración, sólo es necesario llamar al método integrado en Laravel Auth::attempt(email, contraseña) en la petición POST a la que llama el formulario de login. Este método busca el email en la tabla correspondiente de la base de datos, y, en caso de encontrarlo, se compara el hash de la contraseña introducida con el valor del hash almacenado en base de datos.

Acabamos de afirmar que en la base de datos, lo que hemos guardado a la hora de registrar un coordinador, es el hash de la contraseña que introduce, y no su valor original. El motivo por lo que se ha realizado esto es para proteger la contraseña de los usuarios, de modo que aunque alguien ajeno acceda a la base de datos, nunca podrá saber el valor original de las contraseñas. Para calcular el valor hash de una cadena de texto cualquiera, utilizamos el método Hash::make(texto), que de-volverá el hash del texto introducido.

El último detalle por mencionar en este apartado, es cómo se ha llevado a cabo el sistema de recor-dar contraseña. Para ello, se han realizado dos vistas, en la primera de ellas se pide al usuario que introduzca el correo electrónico correspondiente al coordinador, y en la siguiente vista, a la cual sólo se puede acceder mediante una URL aleatoria que se le habrá enviado por correo electrónico al coordinador, se le pedirá al usuario que introduzca la nueva contraseña, de modo que una vez la haya introducido, no podrá volver a acceder a la URL aleatoria. Este sistema de recordar contraseña lo hacemos utilizando la tabla de la base de datos RecuerdoContrasenia. Cada vez que un coordina-dor nos solicita recordar su contraseña, tras enviarle el correo electrónico ya mencionado, añadimos una fila en esta tabla, guardando el identificador del coordinador al que corresponda el correo elec-trónico y un código aleatorio. La URL que enviamos por correo, será de la forma /recordar/código, de modo que al acceder a esta URL podrá introducir su nueva contraseña. Una vez haya introducido


su nueva contraseña, guardaremos en la base de datos el hash de la nueva contraseña (sobreescri-biendo la anterior) y eliminaremos la fila correspondiente de la tabla RecuerdoContrasenia, de modo que si el usuario vuelve a acceder a la URL del correo electrónico, ya no le dejará cambiar sus con-traseñas.

4.4 Implementación del diseño En cuanto a la parte gráfica, como se dijo en los requisitos de la aplicación se intentará llevar a cabo un diseño responsivo (Responsive Design) que se adapte a cualquier dispositivo. Para ello hemos utilizado el Framework CSS y Javascript llamado Bootstrap, que nos ha permitido conseguir nuestro objetivo en cuanto a la parte gráfica de manera sencilla y rápida.

La principal característica de Bootstrap que hemos utilizado, es su sistema de rejilla basado en doce columnas, de modo que podemos decirle cuanto espacio queremos que ocupe cada elemento de-pendiendo del tamaño de la pantalla.

A continuación, en la Tabla 4.3, vamos a ver un pequeño ejemplo, en el que mostramos los dos botones de la página de login dependiendo del tamaño de la pantalla (medio = md, pequeño o extra pequeño = xs).

<button class="col-md-2 col-xs-12 ... Iniciar Sesión <a class="col-md-2 col-xs-12 ... Contraseña olvidada

Tamaño medio (col-md-2): 2 columnas Tamaño medio (col-xs-12): 12 columnas

Tabla 4.3. Ejemplo del sistema de rejilla de Bootstrap

El diseño de todas las pantallas creadas ha seguido el patrón de las pantallas que diseñamos en la Sección 3.2, consiguiendo un resultado bastante similar, como podemos ver en la Figura 4.1, en la que se compara el diseño de la pantalla del Coordinador con el resultado final.

Figura 4.1. Comparativa del diseño de la pantalla del Coordinador con el resultado final

4.5 Implementación de otros aspectos Uno de los detalles a destacar en la aplicación, es el método para obtener las coordenadas sin que el usuario de la aplicación tenga que saberse las coordenadas de los puntos de recogida de cada uno


de los participantes. Para facilitar este proceso, se ha integrado un mapa en el formulario de añadir participante, de modo que a partir de este mapa y de los campos de localidad y de dirección, se podrán obtener las coordenadas de cualquier localización sin esfuerzo. Este sistema de obtención de las coordenadas tiene la apariencia final mostrada en la Figura 4.2.

Figura 4.2. Apariencia del formulario de añadir participante

Para integrar este mapa al formulario, se ha utilizado la API (Application Programming Interface) de Google Maps basada en Javascript.

Para integrar el mapa en el formulario, se han utilizado distintas instrucciones tanto de JavaScript como de JQuery, de modo que en el código HTML solo hemos creado un div vacío cuyo id es map. En el Bloque de código 4.12 podemos ver cómo se ha implementado la lógica del mapa. Lo primero es recoger los datos de latitud y longitud de los respectivos campos del formulario, cuyo valor sólo podrá ser numérico. Comprobamos si estos valores no son nulos, y en caso de serlo los colocamos en un punto (en este caso en el centro de Logroño). Construimos el mapa el cual centramos en las coordenadas anteriores, y al cual le colocamos un marcador en la posición central. Este marcador se podrá arrastrar por el mapa (draggable: true;) de modo que asignamos una tarea para el evento dragend de este marcador (cuando se suelta tras arrastrarlo). En este evento lo que haremos es recoger la latitud y la longitud del marcador (con una precisión de 5 decimales: evt.latLng.lat().toFixed(5);) y asignárselas a los inputs de latitud y longitud. Por lo tanto, sólo con esto ya tenemos un mapa en el cual podremos desplazar un marcador hasta colocarlo sobre la posición que queramos, obteniendo las coordenadas de esta posición.

Pero al diseñar la aplicación, se dijo que las coordenadas se podrían sacar también directamente del texto de la localización. Por este motivo, se ha declarado la última función del Bloque de código 4.12, en la cual asignamos al evento click del botón con id buscarenMapa (es el botón azúl que se puede ver en la Figura 4.2). Cuando se haga click en este botón, se realizará una petición a Google Maps obteniendo las coordenadas correspondientes a la localización indicada en los inputs de loca-lidad y dirección. En caso de no obtener las coordenadas se mostrará un aviso emergente al usuario. En el Bloque de código 4.13, podemos ver como se ha realizado la función a la que se llama en el evento click del botón. Además, al final de este Bloque de código, se ha incluido la eliminación del funcionamiento por defecto de la tecla “Enter” (código de tecla nº 13), ya que cuando se están rellenando estos campos, el comportamiento normal es pulsar esta tecla para buscar en el mapa,


pero como estamos dentro de un formulario, el comportamiento por defecto de esta tecla es enviar el formulario, no buscar en el mapa.

var lat = document.getElementById('latitud').value; if (lat == "") { lat = 42.462719; }else{ lat = lat *1 ; } var long = document.getElementById('longitud').value; ... var marker = new google.maps.Marker({ position: {lat: lat, lng: long}, draggable: true, map: map }); var geocoder = new google.maps.Geocoder(); google.maps.event.trigger(map, 'resize'); google.maps.event.addListener(marker, 'dragend', function (evt) { document.getElementById('latitud').value = evt.latLng.lat().toFixed(5); document.getElementById('longitud').value = evt.latLng.lng().toFixed(5); }); document.getElementById('buscarEnMapa').addEventListener('click', function () { geocodeAddress(geocoder, map, marker); });

Bloque de código 4.12. Implementación de la lógica del mapa del formulario de añadir participante

function geocodeAddress(geocoder, resultsMap, marcador) { var address2 = document.getElementById('direccion').value; var address1 = document.getElementById('localidad').value; geocoder.geocode( {'address': address1 + " " + address2}, function (results, status) { if (status === google.maps.GeocoderStatus.OK) { resultsMap.setCenter(results[0].geometry.location); marcador.setPosition(results[0].geometry.location); google.maps.event.addListener(marcador, 'dragend', function (evt) { document.getElementById('latitud').value=evt.latLng.lat().toFixed(5); document.getElementById('longitud').value=evt.latLng.lng().toFixed(5); }); resultsMap.setZoom(16); document.getElementById('latitud').value = results[0].geometry.location.lat().toFixed(5); document.getElementById('longitud').value = results[0].geometry.location.lng().toFixed(5); } else { alert("Introduzca valores válidos en localidad y dirección"); } }); } $('#localidad').keypress(function (event) { if (event.keyCode == 13) { event.preventDefault(); } }); $('#direccion').keypress(function (event) { if (event.keyCode == 13) { event.preventDefault(); } });

Bloque de código 4.13. Implementación de la localización de los valores de los inputs


Además de la implementación del sistema de obtención de coordenadas a partir de la dirección, también cabe destacar que todos los métodos creados han sido documentados siguiendo el estilo de documentación por defecto. En el Bloque de código 4.14 podemos ver un ejemplo de cómo se ha realizado esta documentación.

/** * @brief Calcula todas las combinaciones de conductores guardando sólo las válidas * @param int $fila número de la fila en la que nos encontramos en la matriz * @param array $matriz Vector de vectores, donde cada uno de los vectores que compone la matriz, tiene como componentes todas las opciones de conductores de una hora * @param array $resultado Será donde se guarden cada una de las combinaciones que vamos calculando, por ello es la salida final * @param array $paso iremos guardando es un elemento de cada una de las filas de la matriz * @return array devuelve la variable resultado con todas las combinaciones válidas */ public function unir($fila, $matriz, $resultado, $paso) { . . .

Bloque de código 4.14. Ejemplo de documentación del código


5 Pruebas de la aplicación Tanto durante la fase de implementación como después de terminarla, hemos realizado distintas pruebas funcionales con el objetivo de conseguir el visto bueno por parte del cliente. En todas estas pruebas han intervenido distintos usuarios con distintos niveles de conocimientos, desde el propio cliente, que además de tener conocimientos avanzados sobre informática, es el que mejor sabe lo que quiere que haga la aplicación, hasta compañeros de la empresa sin conocimientos sobre pro-gramación.

Como se puede ver en la Tabla 5.1, la versión final del producto se adecúa bastante bien a lo que buscábamos, ya que cumple todos los requisitos principales (menos uno debido a que se decidió cambiar el requisito indicado).

Requisito a probar Cumplido Registrarse como coordinador de un nuevo centro El coordinador, una vez estén distribuidos los participantes, puede solicitar el cálculo de las agru-paciones en distintos coches de los mismos

El coordinador puede modificar sus propios datos, mencionados anteriormente.

El coordinador puede modificar los datos del centro.

El coordinador puede añadir, modificar o eliminar participantes.

El coordinador puede añadir o quitar horarios a cada uno de los participantes.

El coordinador puede solicitar la división de los participantes en distintas zonas.

El coordinador puede solicitar la agrupación de los participantes. Esta acción llevará a cabo la agrupación detallada en la Sección 2.3. El coordinador puede generar una dirección URL aleatoria que dirija a la planificación calculada, la cual se enviará automáticamente por correo electrónico a todos los participantes.

Motivo: Al tener que acceder con clave a la pantalla de resultados, se decidió que no hacía falta generar una URL aleatoria (esta decisión fue tomada junto con el cliente).

El coordinador puede enviar por correo electrónico la clave de acceso a todos los participantes. Para poder llevar a cabo esta operación se tendrá que haber calculado la agrupación previamente. El coordinador puede llevar a cabo modificaciones en el horario de los participantes tras calcular el algoritmo de agrupación. Es decir, podrá cambiar el horario de cualquiera de los participantes, añadir o eliminar participantes una vez están calculadas las asignaciones de conductores y acom-pañantes. Para que estas modificaciones tengan efecto en la pantalla de resultados, el coordina-dor deberá recalcular el algoritmo de agrupación. El coordinador puede solicitar el cálculo de las agrupaciones tantas veces como quiera Al calcular las agrupaciones, la aplicación en ningún caso deja de funcionar la aplicación por so-brecarga

Tabla 5.1. Comprobación de funcionamiento de los requisitos principales

Además de comprobar la consecución de los requisitos funcionales del proyecto, también se han tenido en cuenta los requisitos no funcionales. En la Tabla 5.2, vemos los navegadores más usados en distintos sistemas operativos, en los cuales se ha comprobado si la aplicación funciona correcta-mente o no. Además, en todos los dispositivos en los que funciona correctamente, su visualización se adecúa correctamente al tamaño de la pantalla, ya que gracias a las facilidades que proporciona


Bootstrap (4.4) hemos llevado a cabo un diseño responsivo (Responsive Design) en nuestra aplica-ción.

↓ SO \ Navegador → Chrome Firefox I. Explorer Opera Safari M. Edge Windows - Mac OS X - - Linux (Ubuntu) - - - Android - - - iOs - -

Tabla 5.2. Comprobación de funcionamiento en distintos navegadores y sistemas operativos

En cuanto al tiempo que le cuesta calcular el algoritmo de agrupación de conductores y acompa-ñantes, el caso ideal sería que en una situación como la que ha inspirado este proyecto (39 partici-pantes que van 5 días a la semana), no superara los 5 minutos. Para comprobar lo anterior, se han realizado comprobaciones del tiempo que le cuesta a la aplicación llevar a cabo el cálculo de la agrupación, es decir, realizar el algoritmo que hemos creado. En los requisitos establecidos con el cliente no se especificó un tiempo máximo, sólo se dijo que debería poder calcularse en un tiempo razonable (unos 5 minutos máximo en casos como el real, que son 39 usuarios). El requisito que si se impuso es que en ningún caso la aplicación se sobrecargará y dejará de funcionar al calcular las agrupaciones de conductores y acompañantes. Para comprobar el tiempo que le cuesta realizar el algoritmo, hemos hecho distintas pruebas modificando tanto el número de usuarios como el nú-mero de días, obteniendo los resultados mostrados en la Figura 5.1. Para calcular los datos de esta gráfica se han realizado tres intentos para cada caso con distintas bases de datos generadas aleato-riamente, quedándonos finalmente con la media de los tres tiempos calculados.

Figura 5.1. Gráfica del tiempo de cálculo del algoritmo de asignación de conductores y acompañantes

En la Figura 5.1, se puede ver que mediante aumentamos el número de días con el mismo número de participantes, como es de esperar el tiempo de cálculo aumenta. Lo mismo ocurre si dejamos fijo el número de participantes y aumentamos el número de días. Vemos que en el caso más grande que se ha probado, el cual consiste en 40 participantes que van los 7 días de la semana, el tiempo medio ha sido de 62.5 segundos, por lo que se trata de una situación aceptable.


6 Mejoras de la aplicación Por último, en esta sección vamos a ver las mejoras de la aplicación que se han ido proponiendo durante el desarrollo del proyecto. Todas las mejoras que vamos a mencionar no están indicadas en el apartado de requisitos, ya que algunas de ellas son ideas que se descartaron en la reunión inicial con el cliente (Anexo C.1) y otras han ido surgiendo durante la realización del proyecto.

6.1 Mejoras realizadas Además, en las Tablas 6.1 y 6.2 podemos ver algunas mejoras que se han ido proponiendo y se han llevado a cabo durante el desarrollo del proyecto.

Mejoras realizadas en la aplicación (1/2) Sistema de modificación de zonas de los participantes sin necesidad de recalcular las zonas

En la pantalla de inicio una vez has accedido como coordinador, se ve la lista de participantes del centro. Gracias a esta mejora se puede editar la zona de los participantes directamente desde esta pantalla, como se puede ver en la siguiente imagen.

Mostrar un mapa para indicar el reparto de las zonas

En la misma pantalla de inicio que en la mejora anterior, mostrar un mapa en el que se muestren puntos de distinto color, donde cada punto representará un participante y cada color representará una zona. Este mapa solo se mostrará una vez hayan sido calculadas las zonas. En la siguiente imagen podemos ver un ejemplo del mapa con tres zonas claramente visibles.

Modificaciones en la pantalla de resultados

Desde la pantalla de resultados, habiendo accedido con la sesión del coordinador iniciada, se podrá modificar los acompañantes de cada asignación, dando la opción tanto de añadir (si la capacidad del coche del conduc-tor lo permite) como de eliminar acompañantes. Con esto conseguimos también satisfacer otra petición del cliente, ya que en el caso real (profesores del colegio público de Calahorra), hay gente que algún día va, pero después no vuelve a Logroño directamente, por lo que, con esta mejora, podríamos hacer que un acompa-ñante nunca vuelva, o dejar que un conductor vuelva sólo, de modo que si no vuelve no afectará a ningún acompañante.

Tabla 6.1. Mejoras realizadas en el proyecto actual (1/2)


Mejoras realizadas en la aplicación (2/2) Control de cambios mientras se calcula el algoritmo

Cuando el coordinador solicite calcular la agrupación de conductores y acompañantes, tendrá que esperar un tiempo hasta obtener los resultados. Si mientras tanto decide desde otra pestaña u otro navegador rea-lizar algún cambio que influya en algún dato necesario para el cálculo de la agrupación, como por ejemplo la modificación del horario de un usuario, la aplicación no le permitirá realizar esta modificación y le mostrará una alerta como la de la siguiente imagen.

Aviso de cambios tras calcular el algoritmo Si el coordinador realiza algún cambio que afecte a algún dato que influya en el cálculo de la agrupación, si ya existe una agrupación calculada, se le permitirá realizar el cambio, pero aparecerá un mensaje de aviso permanente en la parte superior, como se puede ver en la siguiente imagen.

Tabla 6.2. Mejoras realizadas en el proyecto actual (2/2)

6.2 Mejoras propuestas En las Tablas 6.3 y 6.4 se muestran varias mejoras que se proponen para llevarlas a cabo en un futuro y mejorar la presente aplicación.

Mejoras propuestas para la aplicación (1/2) Recalcular las asignaciones con los mínimos cambios posibles

Integración de la lógica necesaria para que cuando se cambie el horario o la zona de un participante cualquiera, una vez ya están calculadas las asignaciones de conductores y participantes, se recalcule todo el algoritmo con los menores cambios posibles respecto a la asignación ya calculada anterior-mente.

Dar la opción de cambiar los conductores Implementación de un sistema de validación ante la opción de cambiar el conductor de una asig-nación cualquiera, de modo que te diga si el cambio es válido para que todos los participantes puedan tanto ir como volver ese mismo día.

Cambios en los participantes asignados de modo gráfico Habiendo iniciado sesión como coordinador, hacer en la página de resultados de su centro se pue-dan llevar a cabo modificaciones en las asignaciones simplemente arrastrando los participantes de una asignación a otra.

Acceso a la aplicación a todos los usuarios Permitir el registro a los usuarios que no sean coordinadores de un centro, de modo que sean los propios usuarios quienes puedan introducir sus propios datos personales como participantes de un centro.

Tabla 6.3. Mejoras propuestas para el futuro del proyecto actual (1/2)


Mejoras propuestas para la aplicación (2/2) Número de plazas de coche individual al calcular las agrupaciones

Cambiar el método de validación del algoritmo, de modo que en vez de comprobar que los partici-pantes caben en los coches con un número de plazas por coche fijo (actualmente se comprueba con el número de plazas que el coordinador haya metido al inicio), esta validación se haga a partir del número de plazas por coche de cada conductor. Este cambio supondría aumentar el número de operaciones a llevar a cabo considerablemente, por lo que la mejora sería realizar esta modificación sin afectar al coste de cálculo del algoritmo.

Datos estadísticos del número de conducciones Mostrar datos estadísticos en la página de resultados, en los que se muestre el número de conduc-ciones de cada usuario, qué usuarios conducen un mayor número de veces o cuáles no conducen ninguna vez, junto con otros datos que pueden ser de interés.

Tabla 6.4. Mejoras propuestas para el futuro del proyecto actual (2/2)


7 Seguimiento y control del proyecto Durante la presente memoria, se han ido explicando las distintas fases que hemos ido realizando y los problemas con los que nos hemos ido encontrando. Por lo tanto, en este apartado haremos referencia a las secciones donde se detallen distintos aspectos del seguimiento.

7.1 Alcance y objetivos alcanzados En la realización del proyecto se han alcanzado los objetivos propuestos en el análisis de requisitos de forma satisfactoria. Tras la realización del proyecto se ha obtenido un sitio web orientado a cual-quier tipo de organización o empresa, de modo que se puede obtener una organización de conduc-tores y participantes para distintos días de una forma cómoda y rápida.

Como se puede ver en el apartado de pruebas (Sección 5), hemos conseguido cumplir con todos los requisitos propuestos en los requisitos iniciales (Secciones 2.1 y 2.2). Además, se han llevado a cabo algunas pequeñas mejoras indicadas en la Sección 6.1.

Tras la realización del proyecto actual, hemos llevado a cabo los siguientes entregables finales:

Aplicación web realizada en Laravel que calcula agrupaciones de conductores con acompa-ñantes.

Memoria en la que se describen los principales detalles de la realización del proyecto. Den-tro de este entregable se pueden diferenciar los siguientes entregables:

o Memoria del proyecto, la cual tiene una longitud de 50 páginas (7.1 en la EDT). o Anexo en el que se incluye un manual de usuario de la aplicación web (6 en la EDT). o Anexo en el que se detallan algunos detalles específicos de la implementación del

algoritmo. o Anexo en el que se incluyen las actas de las principales reuniones llevadas a cabo

durante el periodo del proyecto (7.2 en la EDT).

Durante la realización del proyecto, se ha seguido la EDT planificada sin ninguna modificación.

7.2 Periodos de ejecución real y desviaciones En la Tabla 7.1, podemos ver las desviaciones en el coste de ejecución de las tareas junto con la explicación del motivo de las desviaciones más destacables.

En cuanto al avance del proyecto respecto a las fechas, la mayor desviación en el calendario ha sido la finalización de la fase de implementación el día 13 de mayo (en el diagrama de Gantt de las Tablas Tabla 1.5 y Tabla 1.6 se indicó que esta fase finalizaría el día 8 de junio). Este adelanto de la fecha de finalización se debe a que en la reunión realizada con el tutor el día 19 de abril (Anexo C.2), al ver lo avanzada que se llevaba la fase de implementación, se decidió dedicar más tiempo a esta parte, de modo que se pudiera dejar terminada antes del realizar un parón para preparar los exámenes del segundo cuatrimestre. Finalmente conseguimos tener la implementación terminada completa-mente para el día 13 de mayo, así que se decidió realizar una pausa en el trabajo para poder preparar los exámenes con tiempo suficiente, ya que el avance del proyecto era bastante favorable.


Cód. Tarea H.P H.R Desv. Motivo de la desviación

1 Introducción 7 10 43% La actividad de planificación fue más costosa de lo espe-rado.

1.1 Contexto 2 2 0% Desviación mínima o nula.

1.2 Planificación 5 8 60% Necesidad de ponerse de acuerdo con el cliente tanto en las herramientas a usar como en las fechas de los entregables.

2 Análisis 7 7 0% Desviación mínima o nula. 2.1 Requisitos funcionales 5 5 0% Desviación mínima o nula. 2.2 Requisitos no funcionales 2 2 0% Desviación mínima o nula. 3 Diseño 21 20 -5% Desviación mínima o nula.

3.1 Diagrama entidad relación 3 5 66% El coste de traducir los requisitos a un diagrama entidad re-lación que sea claro para poder diseñar la base de datos co-rrectamente, ha sido más costos de lo esperado.

3.2 Diseño de la base de datos 5 5 0% Desviación mínima o nula.

3.3 Diseño de interfaces 3 2 -33% Gracias al uso de una herramienta ya conocida como es draw.io, pudimos ahorrarnos tiempo en esta tarea.

3.4 Diseño del algoritmo 10 8 -20% En esta actividad, el poder discutir con el cliente los aspec-tos más importantes ha disminuido el tiempo necesario.

4 Implementación 200 207 3.5% Desviación mínima o nula.

4.1 Imp. base de Datos 20 22 10%

La decisión de crear la base de datos a través del sistema de migraciones de Laravel tuvo un coste de tiempo extra, aun-que este tiempo extra ha sido totalmente rentabilizado du-rante las siguientes fases de implementación y pruebas.

4.2 Imp. Lógica de negocio 30 40 33% Al tener que crear toda la aplicación desde cero por primera vez, fue necesario configurar más cosas de las esperadas para poder pasar a la implementación del algoritmo.

4.3 Imp. Algoritmo 80 85 6% Desviación mínima o nula.

4.3.1 Algoritmo 60 75 25% La parte de generar la mejor combinación de conductores, ha sido bastante más complicada de lo esperado.

4.3.2 Optimización del algoritmo 10 5 -50% Al dedicar más tiempo del esperado para el algoritmo, hubo que recortar horas en esta fase.

4.3.3 Mejoras del algoritmo 10 5 -50% Al dedicar más tiempo del esperado para el algoritmo, hubo que recortar horas en esta fase.

4.4 Imp. Presentación/Lógica 70 60 -14% La facilidad de uso de Bootstrap (4.4) nos ha permitido aho-rrar bastante tiempo en esta fase.

5 Pruebas 5 5 0% Desviación mínima o nula. 6 Manual de usuario 5 5 0% Desviación mínima o nula.

7 Tareas transversales 55 65 18% El tiempo planificado para la memoria no ha sido sufi-ciente.

7.1 Memoria 40 55 37.5% El tiempo planificado para la memoria no ha sido suficiente. 7.2 Reuniones 10 10 0% Desviación mínima o nula. 7.3 Presentación 5 5 0% Desviación mínima o nula.

TFG Total 300 315 5% Podemos concluir que una desviación de 15 horas en todo un proyecto de 300 horas es una desviación aceptable.

H.P = Horas Planificadas H.R = Horas Reales Desv = Desviación del tiempo real respecto al planificado Tabla 7.1. Comparativa de horas planificadas y horas reales


A continuación, vamos a ver dos gráficas obtenidas de la aplicación web de la universidad para ges-tionar trabajos fin de grado, disponible en https://yaiza.unirioja.es:1443/tfg/. En la Figura 7.1 se muestran las dos gráficas, en la primera de ellas se muestra la evolución del progreso teniendo en cuenta las horas reales y las horas planificadas, y en la segunda gráfica se representa la evolución del progreso en las diferentes actividades del trabajo fin de grado (la fase de producto no se ha puesto como completa hasta no tener todos los entregables completos, incluida la memoria actual). En ambas gráficas se puede ver que durante la segunda quincena de mayo y la primera semana de junio se realizó una pausa en el trabajo.

Figura 7.1. Comparativa entre horas reales-planificadas y progreso en las diferentes actividades

7.3 Comunicaciones con el cliente y el tutor Todas las comunicaciones con el cliente han sido en persona, de modo que las principales reuniones están incluidas en el Anexo C.1.

De la misma forma, con el tutor la mayoría de las comunicaciones han sido en persona, ya sea en reuniones o en pequeñas conversaciones. Además, también nos hemos comunicado en ocasiones vía correo electrónico. Las principales reuniones están incluidas en el Anexo C.2.

7.4 Adquisiciones Durante el proyecto se han realizado distintas adquisiciones, como por ejemplo distintas librerías que nos han permitido conseguir nuestro objetivo de una forma más eficiente y correcta. En las Tablas 7.2 y 7.3 podemos ver las principales adquisiciones.

Adquisición Autor Origen Licencia

Algoritmo de KMeans

Benjamin Delespierre Packagist Copyright, dando permiso para usar, copiar, modi-

ficar, publicar, distribuir o vender copias. Descripción: Librería con la implementación del algoritmo de KMeans (Sección 4.2.5)

Problema de los matri-monios estables

Thomas McGregor GitHub

Copyright. El permiso para usar, copiar, modificar, publicar, distribuir o vender copias, ha sido obte-nido contactando con el autor.

Descripción: Librería con la implementación del problema de los matrimonios es-tables (Sección 4.2.5) Tabla 7.2. Principales adquisiciones del proyecto (1/2)


Adquisición Autor Origen Licencia

Notificaciones en Lara-vel

Laracasts GitHub Licencia MIT. Permite usar, copiar, modificar, pu-blicar, distribuir o vender copias, pero siempre in-cluyendo una referencia al autor.

Descripción: Librería que nos permite poner fácilmente mensajes de notificación visuales en nuestra aplicación, mejorando la usabilidad de la aplicación.

Barra de depuración de Laravel

Barry Heuvel GitHub Copyright, dando permiso de usar, copiar, modifi-car, publicar, distribuir o vender copias.

Descripción: Librería que proporciona la posibilidad de añadir una barra de depu-ración a nuestra aplicación, mostrándonos aspectos como el tiempo que cuesta realizar una petición o todas las consultas a base de datos hechas en cada ocasión. Tabla 7.3. Principales adquisiciones del proyecto (2/2)


8 Conclusiones y lecciones aprendidas En este último apartado, se realizará una reflexión sobre todos los aspectos que ha englobado el presente Trabajo Fin de Grado.

En lo que se refiere al ámbito personal, puedo decir que estoy muy satisfecho con el resultado ob-tenido, ya que se han conseguido cumplir todos los requisitos que se planificaron en un inicio, cum-pliendo con los plazos establecidos en la planificación.

Realizar este Trabajo Fin de Grado ha sido todo un reto personal, ya que se trata de una aplicación web, y mientras lo realizaba estaba asistiendo por primera vez a la asignatura de Programación de aplicaciones web, por lo que, al comienzo del proyecto, la única base sobre esta programación con la que contaba eran los conocimientos adquiridos el cuatrimestre anterior durante la realización de prácticas en la empresa, misma empresa en la que se ha realizado posteriormente el presente tra-bajo. Cuando se me propuso este trabajo, me planteé si debía aceptarlo o no por el desconocimiento de este tipo de programación en ese momento, pero decidí aceptarlo ya que es un tipo de progra-mación que en las prácticas en empresa me estaba gustando bastante y me parecía una muy buena oportunidad para aprender más sobre ella.

Pero éste no ha sido el único reto, ya que para realizar este proyecto he tenido que usar como lenguaje principal PHP, con el cuál sólo se había tenido un breve contacto durante el periodo de prácticas. Además, al estar viendo la asignatura de Programación de aplicaciones web simultánea-mente a la realización del Trabajo Fin de Grado, otras tecnologías que se han usado como JavaScript, apenas se conocían. Usar estos lenguajes, además de un reto, también supuso una motivación, ya que actualmente son de los más demandados en el mercado laboral informático.

El mayor problema durante la realización de este proyecto, ha sido la falta de tiempo para impre-vistos. Esto se debe a que la planificación de la doble titulación obliga a combinar el estudiar cuatro asignaturas en el segundo cuatrimestre y realizar el Trabajo Fin de Grado, el cual se ha realizado asistiendo diariamente a la empresa. Aun así, el poder asistir a la empresa presencialmente ha per-mitido no sufrir ninguna desviación de tiempo negativa, además de poder estar en contacto con el cliente en todo momento.

En cuanto a los aspectos técnicos, he aprendido lenguajes de programación que desconocía por completo, nuevos entornos de desarrollo y librerías útiles para la programación web. También cabe destacar el uso de multitud de conocimientos adquiridos durante el estudio del Grado en Ingeniería informática, como las capacidades en programación, bases de datos, tareas transversales, seguri-dad, métodos algorítmicos…

Cabe destacar la dificultad e importancia que tiene en este trabajo la parte algorítmica, ya que se trata de la principal funcionalidad de la aplicación creada. En ella se han utilizado distintos métodos aprendidos durante la realización del Grado en Ingeniería Informática y el Grado en Matemáticas, además de otras técnicas que no se conocían previamente a este trabajo. Ha sido fundamental el haber pensado el algoritmo previamente a su implementación, ya que nos permitió usar dos algo-ritmos ya existentes (kMeans y el problema de los matrimonios estables) y por lo tanto nos pudimos ahorrar su implementación mediante el uso de librerías. Si no se hubiera hecho un análisis y un


diseño completo del algoritmo previamente a su implementación, posiblemente no se hubiera po-dido terminar este proyecto en el tiempo estimado.

Por último, en este trabajo se han aprendido varios conocimientos técnicos nuevos, de los cuales enumeraremos los más importantes a continuación.

1. Utilización de Git permitiendo realizar un control de versiones completo. Utilización de ca-racterísticas de las cuales se desconocía su uso, como es la utilización de ramas.

2. La gran ventaja que proporciona utilizar un buen entorno de desarrollo. Al principio, debido al desconocimiento de cuál era el mejor entorno para trabajar en PHP, se comenzó utili-zando Sublime Text, pero una vez se decidió abrir el proyecto con NetBeans, no se volvió a usar Sublime Text. Esto se debe a la multitud de opciones que te ofrece NetBeans, como la posibilidad de consultar la documentación directamente o la posibilidad de refactorizar mé-todos y variables de una manera bastante sencilla.

3. Utilización de Composer. Esta herramienta se trata de un manejador de dependiencias, ca-paz de instalar las librerías que necesita nuestro proyecto con las versiones que necesitemos a partir de un simple comando y un archivo de propiedades. Por lo tanto, el uso de esta herramienta incrementa la usabilidad y portabilidad de la aplicación.


9 Bibliografía I. Laravel – Documentación oficial

Disponible en https://laravel.com/docs/5.1

II. Comunidad Hispanoamericana de Laravel

Diponible en http://laraveles.com/

III. Página oficial de Bootstrap

Disponible en http://getbootstrap.com/

IV. El problema de los matrimonios estables y otros problemas de emparejamiento – Trabajo fin de Grado en Matemáticas en la Universidad de La Rioja de Marina Blanco Peña (Tutor: Jesús María Aransay Azofra)

Disponible en http://biblioteca.unirioja.es/tfe_e/TFE001024.pdf

V. Sitio de preguntas y respuestas para programadores

Disponible en http://stackoverflow.com/

VI. Librerías utilizadas

a. kMeans

Disponible en https://packagist.org/packages/bdelespierre/php-kmeans

b. Problema de los matrimonios estables

Disponible en https://github.com/tommc1985/stable-marriage-problem

c. Notificaciones en Laravel

Disponible en https://github.com/laracasts/flash

d. Barra de depuración de Laravel

e. Disponible en https://github.com/barryvdh/laravel-debugbar

VII. Documentación oficial de PHP

Disponible en https://secure.php.net/manual/es/index.php

Plataforma web para el uso colaborativo de transporte · Plataforma web para el uso colaborativo de...

Documents

Transcript of Plataforma web para el uso colaborativo de transporte · Plataforma web para el uso colaborativo de...