Aplicación web para la gestión de rutas turísticas

(1)

Escuela T ´ecnica Superior de Ingenier´ıa Inform ´atica

Grado en ingenier´ıa del software

Aplicaci ´on web para la gesti ´on de rutas tur´ısticas

Web application for tourist routes management

Realizado por

ROC´IO ARREBOLA PASCUAL

Dirigido por

JOS ´

E MAR´IA ´

ALVAREZ PALOMO

Departamento

LENGUAJES Y CIENCIAS DE LA COMPUTACI ´

ON

UNIVERSIDAD DE M ´ALAGA M ´alaga, junio de 2017.

(2)

(3)

Resumen:

En este proyecto se aborda la creaci ón de una aplicaci ón web utilizando Django y los servicios web de Amazon (Amazon Web Services). En esta aplicaci ón se pretende re-unir a los viajeros de todo el mundo para que compartan sus experiencias con el resto de usuarios.

La aplicaci ón se alojar á en instancias de Amazon EC2, el servidor ofertado por Ama-zon. Estas instancias se administrar án en AWS Elastic Beanstalk por medio de AWS Auto Scaling, que aumentar á o reducir á la capacidad de Amazon EC2 en funci ón al tr áfico de carga. Para la base de datos se utilizar á una instancia de Amazon RDS, el servidor de bases de datos relacionales de Amazon, con una base de datos MySQL. Tambi én se har á un estudio del gasto que supone tener una aplicaci ón alojada en AWS mediante el tablero de facturaci ón que proporciona Amazon.

Para comprobar que AWS Auto Scaling hace un balanceo de carga correcto, se utili-zar án herramientas para simular un gran n úmero de peticiones al servidor de la apli-caci ón, de modo que haya que aumentar la capacidad de Amazon EC2.

Palabras clave: Amazon Web Services, Django, aplicaci ´on web, Amazon EC2, AWS Elastic Beanstalk, AWS Auto Scaling, Amazon RDS.

Abstract:

This project deals with the creation of a web application using Django and Amazon Web Services. The primary goal of this application is gathering travellers around the world so that they can share their experiences with the rest of users.

This application will be hosted in Amazon EC2 instances, AWS’s server. Instances will be managed in AWS Elastic Beanstalk by AWS Auto Scaling, that will increase or re-duce server’s capacity according to application’s traffic. For the database, an Amazon RDS instance will be used, which is the Amazon’s relational database server, into this instance a MySQL database will be used. Furthermore, in order to study the costs of hosting a web application in AWS, Amazon’s billing dashboard will be used.

For the shake of checking that AWS Auto Scaling is scaling in a proper way, tools to simulate a big number of requests to the application’s server will be used, so that it will be necessary to increase Amazon EC2’s capacity.

(4)

(5)

´Indice general

1. Introducci ´on 1

1.1. Motivaci ´on . . . 1

1.2. Objetivos . . . 1

1.3. Django . . . 2

1.3.1. ¿Qu ´e es Django? . . . 2

1.3.2. Modelos . . . 4

1.4. Amazon Web Services (AWS). . . 5

1.5. Bootstrap . . . 6

2. Requisitos 7 2.1. Descripci ´on de participantes y usuarios . . . 7

2.1.1. Perfiles de usuario . . . 7

2.2. Requisitos funcionales . . . 8

2.3. Requisitos no funcionales . . . 10

2.4. Requisitos de documentaci ´on . . . 11

3. Dise ˜no 13 3.1. Diagrama de clases . . . 13

4. Visi ´on de conjunto 17 5. Primera iteraci ´on 19 5.1. Requisitos implementados . . . 19

5.2. Desarrollo . . . 20

5.2.1. Modelos . . . 20

5.2.2. Vistas . . . 21

5.2.3. Formularios . . . 24

5.2.4. Templates . . . 24

(6)

6.1. Requisitos implementados . . . 27

6.2.1. Vistas . . . 28

6.2.2. Templates . . . 29

6.3. Pruebas . . . 30

7. Tercera iteraci ´on 31 7.1. Requisitos implementados . . . 31

7.2.2. Vistas . . . 33

7.2.3. Templates . . . 35

8. Cuarta iteraci ´on 37 8.1. Requisitos implementados . . . 37

8.2.1. Modelos . . . 38

8.2.2. Vistas . . . 38

8.2.4. Templates . . . 40

9. Quinta iteraci ´on 41 9.1. Requisitos implementados . . . 41

9.2.1. Vistas . . . 41

9.2.2. Templates . . . 43

10. Sexta iteraci ´on 49 10.1.Modificaciones . . . 49

10.2.Desarrollo . . . 49

10.2.1. Modelos . . . 49

10.2.2. Vistas . . . 50

10.2.3.Templates . . . 50

11. Conclusiones 53 11.1.Opini ´on sobre la uni ´on deDjango yAmazon Web Services . . . 53

11.2.An ´alisis de resultados . . . 54

12. Bibliograf´ıa 57 Bibliograf´ıa . . . 57

(7)

B. Casos de prueba 83

C. Manual de usuario 135

C.1. Introducci ´on . . . 135

C.2. Instalaci ´on . . . 135

C.2.1. Requisitos del sistema . . . 135

C.2.2. Instalaci ´on . . . 136

C.3. Funcionalidades . . . 136

C.3.1. Crear cuenta . . . 136

C.3.2. Recuperar la contrase ˜na . . . 137

C.3.3. Iniciar sesi ´on . . . 138

C.3.4. Cerrar sesi ´on . . . 139

C.3.5. Crear una ruta . . . 139

C.3.6. Editar una ruta . . . 139

C.3.7. Borrar una ruta . . . 140

C.3.8. Crear un d´ıa . . . 141

C.3.9. Editar un d´ıa . . . 143

C.3.10.A ˜nadir un lugar de inter ´es a un d´ıa . . . 144

C.3.11.Quitar un lugar de inter ´es de un d´ıa . . . 146

C.3.12.Borrar un d´ıa . . . 146

C.3.13.Crear un lugar de inter ´es . . . 147

C.3.14.Editar un lugar de inter ´es . . . 148

C.3.15.B ´usqueda . . . 149

C.3.16.Seguir una ruta . . . 149

C.3.17.Dejar de seguir una ruta . . . 150

C.3.18.Seguir a un usuario . . . 150

C.3.19.Dejar de seguir un usuario . . . 151

C.3.20.Valorar una ruta . . . 151

C.3.21.Borrar la valoraci ´on de una ruta . . . 152

C.3.22.Valorar un lugar de inter ´es . . . 152

C.3.23.Borrar la valoraci ´on de un lugar de inter ´es . . . 153

C.3.24.Editar perfil de usuario . . . 154

(8)

(9)

´Indice de figuras

1.1. Mapa de las regiones geogr ´aficas usadas por AWS . . . 5

3.1. Diagrama de clases inicial . . . 14

3.2. Diagrama de clases final . . . 15

C.1. Registro de usuario. Paso 1. P ´agina de inicio. . . 136

C.2. Registro de usuario. Paso 2. P ´agina de registro. . . 137

C.3. Recuperar la contrase ˜na. Paso 1. P ´agina de inicio. . . 137

C.4. Recuperar la contrase ña. Paso 2. P ágina de recuperaci ón de la contra-se ña. . . 138

C.5. Iniciar sesi ´on. Paso 1. P ´agina principal. . . 138

C.6. Cerrar sesi ´on. . . 139

C.7. Crear ruta. Paso 1.a. Pantalla principal . . . 140

C.8. Crear ruta. Paso 1.b. Pantalla principal . . . 140

C.9. Crear ruta. Paso 2. Formulario de creaci ´on de la ruta. . . 141

C.10.Editar ruta. Paso 1. P ´agina de ruta . . . 141

C.11.Editar ruta. Paso 2. P ´agina de edici ´on de ruta . . . 142

C.12.Borrar ruta. Paso 1. P ´agina de ruta . . . 142

C.13.Borrar ruta. Paso 2. Confirmaci ´on de la acci ´on . . . 142

C.14.Crear d´ıa. Paso 1. P ´agina de ruta . . . 143

C.15.Crear d´ıa. Paso 2. P ´agina de creaci ´on del d´ıa . . . 143

C.16.Editar d´ıa. Paso 1. P ´agina de d´ıa . . . 144

C.17.Editar d´ıa. Paso 2. P ´agina de edici ´on del d´ıa . . . 144

C.18.A ñadir lugar de inter és a d´ıa. Paso 1. P ágina de d´ıa . . . 145

C.21.Quitar lugar de inter ´es de d´ıa. Paso 1. P ´agina de d´ıa . . . 146

C.22.Quitar lugar de inter ´es de d´ıa. Paso 2. P ´agina de d´ıa . . . 146

C.23.Borrar d´ıa. Paso 1. P ´agina de d´ıa . . . 147

(10)

C.25.Crear lugar de inter ´es. Paso 1. P ´agina principal . . . 148

C.26.Crear lugar de inter és. Paso 2. P ágina de creaci ón del lugar de inter és . 148 C.27.Editar lugar de inter és. Paso 1. P ágina de lugar de inter és . . . 149

C.28.Editar lugar de inter és. Paso 2. P ágina de edici ón del lugar de inter és . 149 C.29.B úsqueda. P ágina principal . . . 150

C.30.Seguir una ruta. P ´agina de ruta . . . 150

C.31.Dejar de seguir una ruta. P ´agina de ruta . . . 151

C.32.Seguir a un usuario. P ´agina de usuario . . . 151

C.33.Dejar de seguir a un usuario. P ´agina de usuario . . . 152

C.34.Valorar una ruta. P ´agina de ruta . . . 152

C.35.Borrar la valoraci ´on de una ruta. Paso 1. P ´agina de ruta . . . 153

C.36.Borrar la valoraci ´on de una ruta. Paso 2. P ´agina de ruta . . . 153

C.37.Valorar una ruta. P ´agina de lugar de inter ´es . . . 154

C.38.Borrar la valoraci ón de un lugar de inter és. Paso 1. P ágina de lugar de inter és . . . 154

C.39.Borrar la valoraci ón de un lugar de inter és. Paso 2. P ágina de lugar de inter és . . . 155

C.40.Editar perfil de usuario. Paso 1.a. P ´agina del perfil de usuario . . . 155

C.41.Editar perfil de usuario. Paso 1.b. P ´agina principal . . . 156

C.42.Editar perfil de usuario. Paso 2. P ágina de edici ón del perfil de usuario . 156 C.43.Eliminar perfil de usuario. Paso 1. P ágina de perfil de usuario . . . 156

(11)

´Indice de cuadros

(12)

(13)

´Indice de C ´odigos

5.1. Relaci ´onsigueentre distintos usuarios . . . 20

5.2. Relaci ´onsigueentre usuarios y rutas . . . 20

5.3. Relaci ´on de composici ´on entre las clasesDiayLugarInteres . . . 20

5.4. Control de sesiones de la aplicaci ´on . . . 23

5.5. Implementaci ´on del m ´etodoclean()en la claseUsuarioForm . . . 24

7.1. Clase para el formulario de creaci ´on/edici ´on de eventos . . . 32

9.1. Configuraci ´on delemail en el ficherosettings.py . . . 42

9.2. Borrado de d´ıas as´ıncrono . . . 44

9.3. A ˜nadido de valoraciones as´ıncrono . . . 44

(14)

(15)

CAP´ITULO

1

Introducci ´

on

1.1. Motivaci ´

on

A d´ıa de hoy nos encontramos con m ´ultiples aplicaciones muy populares que re ´unen a personas con intereses comunes. En estos grupos o foros, los usuarios participan de manera activa aportando su experiencia y su conocimiento e interaccionan entre ellos enriqueciendo la experiencia.

En este proyecto se propone el desarrollo de una aplicaci ón web basada en viajes, pues, aunque existen muchas aplicaciones y foros sobre viajes, no existe un reposi-torio com ún para todos los aficionados a viajar, haciendo que la b úsqueda de rutas y lugares de inter és cuando se pretende ver mundo sea tediosa y el usuario pierda tiem-po de manera innecesaria. Aunque esto no solucione el problema de la infoxicaci ón, ya que supone a ñadir una aplicaci ón m ás, se considera que supone una ayuda para que los usuarios puedan planificar sus viajes de manera m ás concreta.

1.2. Objetivos

(16)

1.3. Django

usuarios, lugares de inter ´es, etc ´etera).

Las principales funciones que se implementar ´an ser ´an las siguientes:

◦ Posibilidad de que el usuario a ˜nada rutas hechas por ´el.

◦ Posiblidad de que el usuario a ˜nada d´ıas a las rutas creadas.

◦ Posibilidad de que el usuario a ˜nada lugares de inter ´es.

◦ Interacci ón entre usuarios (suscripci ón a otros usuarios, valoraci ón y comenta-rios sobre las rutas de otros usuacomenta-rios).

◦ Gesti ´on de rutas.

Para pr óximas versiones de la aplicaci ón se propone la creaci ón de un usuario que tenga el papel de moderador y controle que la informaci ón dada es ver´ıdica y no es ofensiva. En este proyecto, esto se administrar á desde la p ágina deladmin generada conDjango.

Respecto a la parte tecnol ´ogica, la idea principal consist´ıa en usar los servicios de

Amazon Web Services para la base de datos, el servidor, la distribuci ón de carga, la monitorizaci ón de rendimiento y el uso. Debido a ciertas complicaciones a la hora de subir la aplicaci ón a Amazon Web Services finalmente se ha utilizado el servidor interno deDjangoy una base de datos local con el servidor de MySQL.

1.3. Django

(Documentaci ´on de django, s.f.)

1.3.1. ¿Qu ´e es Django?

Djangoes unframework para el desarrollo de aplicaciones Web escrito enPython.

Antes de hablar sobre la arquitectura deDjangoes importante hacer la distinci ´on entre proyecto y aplicaci ´on enDjango.

◦ Una aplicaci ´on deDjango es un conjunto de funcionalidades.

(17)

Cap´ıtulo 1. Introducci ´on

Dentro del proyecto, se encontrar á un paquete con el mismo nombre que el proyec-to que incluir á diversos ficheros que se auproyec-togeneran al crear el proyecproyec-to. Los m ás interesantes son:

◦ settings.py: contiene informaci ´on sobre la configuraci ´on del proyecto.

◦ urls.py: en ´el se indican todas las urls que usar ´a el proyecto Django.

◦ wsgi.py: es el fichero en el que ”se encarga”de realizar la conexi ´on con el servi-dor.

En este proyecto se desarrollar á una única aplicaci ón deDjango, pues no se considera que sea necesario el desarrollo de ninguna otra m ás.

El desarrollo de aplicaciones con Django sigue el patr ´on MTV, que viene de models,

templates,views y es como se recomienda estructurar las mismas.

Las aplicaciones enDjango deben tener la siguiente estructura:

◦ El fichero en el que se implementan los modelos de la aplicaci ón, por conven-ci ón, es el ficheromodels.py, en él se crear án las clases, que se corresponder án con las tablas de la base de datos. Las clases de dicho fichero heredan de mo-dels.Model y tienen acceso a la base de datos.

◦ El fichero en el que se implementan las vistas de la aplicaci ón, por convenci ón, es el fichero views.py. Es importante tener en cuenta que cuando se habla de vistas en Django no se habla de interfaz gr áfica, sino de controladores, de este modo, el ficheroviews.py ser á el intermediario entre los modelos y las plantillas. En el caso de esta aplicaci ón, se ha decidido separar las vistas de cada modelo en ficheros diferentes para evitar que el ficheroviews.py sea demasiado extenso, de modo que el c ódigo sea m ás modular. Una vista se define como una funci ón que toma una petici ón (request) y devuelve una respuesta, esta respuesta puede ser de diferentes tipos.

◦ La interfaz gr áfica de la aplicaci ón se crear á en los templates (plantillas). No hay un fichero espec´ıfico para declarar estas plantillas, pues habr á una por cada p ágina que tenga la aplicaci ón. Las plantillas se crear án dentro de una carpeta

templatesy tendr ´an extensi ´on.html.

(18)

1.3. Django

◦ forms.py: en él se crean clases que heredan defoms.Form. Dichas clases pue-den utilizarse directamente en las plantillas para generar formularios de manera autom ática, sin tener que escribir c ódigo enhtml. De este fichero se hablar á con m ás profundidad en el apartadoDesarrollodel cap´ıtuloPrimera iteraci ón.

◦ Ficheros para las pruebas: estos ficheros empiezan por la palabratests. En ellos se crean clases que heredar ´an de LiveServerTestCase. Esta clase inicia el ser-vidor al iniciar un test y lo apaga al finalizar el test, permitiendo el uso de herra-mientas de automatizaci ´on de pruebas.

◦ Un paquetestatic que contendr á diferentes paquetes hijo dentro. Cada paquete hijo contendr á diferentes ficheros. En este proyecto habr á un paquete css que contendr á ficheros con extensi ón.css que se usar án para embellecer las planti-llas.

1.3.2. Modelos

Como se ha comentado en la secci ´on anterior, los modelos se corresponden con las tablas de la base de datos, los atributos de un modelo son los campos de la tabla, y son los encargados de realizar la conexi ´on con la misma.

Djangodetermina el tipo de columna de la tabla de la base de datos dependiendo del tipo de datos que tenga su correspondiente atributo en el modelo. A diferencia de otros lenguajes, estos tipos de datos no son tipos simples, sino que son clases. Adem ´as, de-pendiendo del tipo de datos,Django validar ´a los datos que se intentan insertar en las columnas de la base de datos.

Adem ás, los campos tendr án una serie de opciones dependiendo de si son claves pri-marias, únicos, si pueden ser vac´ıos, etc étera. Estas opciones se pasan como par áme-tros a la hora de definir el tipo de datos del atributo. En caso de que se cree un modelo sin clave primaria, Django autogenerar á un atributo autoincremental que asumir á el papel de la misma.

(19)

Cap´ıtulo 1. Introducci ´on

1.4. Amazon Web Services (AWS)

“Amazon Web Services (AWS abreviado) es una colecci ón de servicios de compu-taci ón en la nube (tambi én llamados servicios web) que en conjunto forman una plata-forma de computaci ón en la nube, ofrecidas a trav és de Internet por Amazon.com.”(Amazon Web Services, s.f.).

Para reducir la latencia y aumentar la robustez de los servicios, AWS se divide en 11 regiones geogr ´aficas, que son los centros de datos donde se alojan los servicios. En

Figura 1.1: Mapa de las regiones geogr ´aficas usadas por AWS

nuestro caso, debido a la cercan´ıa geogr áfica, la aplicaci ón se hospedar á en la regi ón de Frankfurt.

Aunque AWS dispone de m ás de media centena de servicios, en este trabajo de fin de grado se explicar án aquellos que se ten´ıa intenci ón de utilizar a la hora de crear y lanzar el proyecto desarrollado. Los servicios investigados han sido:

◦ Elastic Beanstalk (EB): para administrar las aplicaciones. Es un PaaS que per-mite implementar y administrar aplicaciones web en la nube de AWS. Adem ´as, proporciona una serie de servicios para facilitar la labor de los desarrolladores.

(20)

1.5. Bootstrap

de cada cliente.

◦ Identity and Access Management (IAM): para el control de acceso a los servicios. “Con IAM es posible dar permiso a otros usuarios para que administren otros recursos propios de tu cuenta de AWS sin necesidad de compartir contrase ˜nas”. (What Is IAM?, s.f.)

◦ Relational Database Service (RDS): para la base de datos de la aplicaci ´on.

◦ Auto Scaling: para el autoescalado de EC2. Auto Scaling permite incrementar o reducir el n ´umero de instancias activas de EC2 dependiendo del n ´umero de peticiones que reciba el servidor.

◦ Elastic Load Balancing: para el balanceado de carga.

◦ Virtual Private Cloud (VPC): que permite el acceso al servidor a trav ´es de una red privada.

1.5. Bootstrap

(21)

CAP´ITULO

2

Requisitos

2.1. Descripci ´

on de participantes y usuarios

2.1.1. Perfiles de usuario

Usuario

Representante Usuario

Descripci ón Podr á llevar a cabo operaciones de gesti ón de rutas tales como la creaci ón, modificaci ón, borrado, visua-lizaci ón o valoraci ón de las mismas. Tambi én podr á crear, editar, visualizar y eliminar d´ıas dentro de las rutas previamente creadas, adem ás de crear, visuali-zar, editar y valorar lugares de inter és.

Tipo No hay un tipo de usuario definido.

Responsabilidades La responsabilidad del usuario con el producto es, meramente, realizar un uso correcto del mismo. Criterio de ´exito Permite que el resto de usuarios tengan informaci ´on

(22)

2.2. Requisitos funcionales

1. Gesti ón del perfil de usuario: el usuario podr á gestionar su perfil de usuario, pu-diendo registrarse, acceder al sistema, recuperar su contrase ña, salir del siste-ma, modificar el perfil y borrarlo.

a) Registro: el usuario podr ´a registrarse en el sistema introduciendo los datos necesarios.

b) Acceso: el usuario podr ´a acceder al sistema mediante un nombre de usuario y una contrase ˜na.

c) Recuperaci ón de la contrase ña: el usuario podr á recuperar su contrase ña en caso de haberla olvidado.

d) Salida del sistema: el usuario podr ´a salir del sistema cerrando la sesi ´on.

e) Modificaci ´on del perfil: el usuario podr ´a modificar su perfil.

f) Borrado del perfil: el usuario podr ´a eliminar su perfil.

2. Gesti ón de d´ıas: el usuario podr á crear nuevos d´ıas, visualizarlos, editarlos, bo-rrarlos, a ñadir y quitar lugares de inter és a d´ıas.

a) Creaci ón de d´ıas: el usuario podr á crear un nuevo d´ıa dentro de una ruta espec´ıfica creada previamente por él.

b) Visualizaci ón de d´ıas: el usuario podr á visualizar los d´ıas que est én creados en el sistema.

c) Modificaci ón de d´ıas: el usuario podr á modificar los datos relativos a un d´ıa creado previamente por él.

d) Borrado de d´ıas: el usuario podr ´a borrar un d´ıa creado previamente por ´el.

e) A ñadido de lugares de inter és a d´ıas: el usuario podr á a ñadir lugares de in-ter és previamente creados a los d´ıas de sus rutas.

f) Borrado de lugares de inter és en d´ıas: el usuario podr á quitar lugares de in-ter és que han sido previamente a ñadidos a un d´ıa creado por él.

3. Gesti ´on de rutas: el usuario podr ´a crear nuevas rutas, visualizarlas, editarlas, borrarlas, seguir rutas, dejar de seguir rutas, valorarlas, eliminar valoraciones hechas en rutas y buscar rutas en el sistema.

(23)

Cap´ıtulo 2. Requisitos

b) Visualizaci ón de rutas: el usuario podr á visualizar las rutas que est én crea-das en el sistema.

c) Modificaci ón de rutas: el usuario podr á modificar informaci ón relativa a una ruta creada previamente por él.

d) Borrado de rutas: el usuario podr ´a borrar una ruta creada previamente por ´el.

e) Seguimiento de rutas: el usuario podr ´a seguir rutas creadas por otros usua-rios.

f) Cancelaci ´on del seguimiento de rutas: el usuario podr ´a dejar de seguir ru-tas que previamente segu´ıa.

g) Valoraci ón de rutas: el usuario podr á valorar las rutas creadas en el sistema indicando una puntuaci ón y haciendo un comentario.

h) Borrado de valoraciones de rutas: el usuario podr ´a eliminar valoraciones de rutas previamente hechas por ´el.

i) B úsqueda de rutas: el usuario podr á realizar b úsquedas sobre rutas.

4. Gesti ´on de usuarios: el usuario podr ´a seguir a otros usuarios, dejar de seguir usuarios, buscar usuarios y visualizar perfiles de usuario.

a) Seguimiento de usuarios: el usuario podr ´a seguir a otros usuarios que se encuentren registrados en el sistema.

b) Cancelaci ´on del seguimiento de usuarios: el usuario podr ´a dejar de seguir usuarios que previamente segu´ıa.

c) B úsqueda de usuarios: el usuario podr á realizar b úsquedas sobre usuarios.

d) Visualizaci ´on del perfil: el usuario podr ´a ver perfiles de usuarios existentes en el sistema.

5. Gesti ón de lugares de inter és: el usuario podr á crear, editar y visualizar lugares de inter és, adem ás de valorarlos, eliminar valoraciones previamente hechas en lugares de inter és y buscar lugares de inter és.

a) Creaci ón de lugares de inter és: el usuario podr á crear nuevos lugares de inter és.

b) Visualizaci ón de lugares de inter és: el usuario podr á visualizar lugares de inter és previamente creados en el sistema.

(24)

in-2.3. Requisitos no funcionales

ter ´es sin necesidad de ser el creador de los mismos.

d) Valoraci ón de lugares de inter és: el usuario podr á valorar los lugares de in-ter és creados en el sistema indicando una puntuaci ón y haciendo un co-mentario.

e) Borrado de valoraciones de lugares de inter és: el usuario podr á eliminar va-loraciones de lugares de inter és previamente hechas por él.

f) B úsqueda de lugares de inter és: el usuario podr á realizar b úsquedas sobre lugares de inter és.

6. Monitorizaci ón de acciones: el sistema monitorizar á las acciones que los usua-rios realicen sobre las rutas, incluyendo la creaci ón y modificaci ón de las mis-mas, a ñadido de d´ıas, modificado de d´ıas, a ñadido de lugares de inter és a d´ıas y borrado de lugares de inter és de d´ıas.

2.3. Requisitos no funcionales

REQUISITOS DE ASPECTO

RNF 1. El dise ño de la aplicaci ón debe serresponsive: para mejorar la experiencia del usuario, la aplicaci ón debe poder adaptar su dise ño a cualquier tipo de pantalla.

REQUISITOS DE FACILIDAD DE USO Y APRENDIZAJE

RNF 2. La aplicaci ´on debe ser f ´acil de usar: para mayor comodidad del usuario, el pro-grama debe ser sencillo e intuitivo.

RNF 3. La aplicaci ´on debe ser adaptable: debe permitir a ˜nadir funcionalidades.

RNF 4. La aplicaci ón debe poder internacionalizarse: la aplicaci ón podr á traducirse a varios idiomas.

REQUISITOS OPERACIONALES

(25)

Cap´ıtulo 2. Requisitos

RNF 6. La aplicaci ´on debe estar desarrollada en Django.

2.4. Requisitos de documentaci ´

on

MANUAL DE USUARIO

La aplicaci ón deber á incluir un manual de usuario que indique, en un lenguaje no t écnico, c ómo utilizar la misma.

GUÍAS DE INSTALACI ÓN Y CONFIGURACI ÓN

(26)

(27)

CAP´ITULO

3

Dise ˜

no

3.1. Diagrama de clases

Inicialmente, la implementaci ´on del proyecto se hab´ıa pensado con dos tipos de usua-rios: el usuario y el administrador. El diagrama de clases inicial era el diagrama de clases de la figura 3.1.

En vista de que no era posible verificar la identidad del usuario cuyo tipo de perfil esAdministradorLugarInteres, se decidi ´o hacer diversas modificaciones, quedando el siguiente diagrama de clases (figura 3.2):

Como se puede observar, se han eliminado las clases AdministradorLugarInteres y

Evento, y la relaci ón entre Usuario y LugarDeInteres pasa de llamarsesigue a crea. El porqu é de estos cambios se explicar á m ás detalladamente en el cap´ıtulo 9,4a ite-raci ón.

(28)

3.1. Diagrama de clases

(29)

Cap´ıtulo 3. Dise ˜no

(30)

(31)

CAP´ITULO

4

Visi ´

on de conjunto

Para facilitar la comprensi ón de este documento, se hace necesario explicar la visi ón de conjunto de la aplicaci ón.

En este desarrollo de la aplicaci ón se implementa un único tipo de usuario, que podr á crear rutas tur´ısticas, d´ıas dentro de las mismas y a ñadir lugares de inter és a estos.

Las rutas estar án compuestas por d´ıas, cada d´ıa incluir á una serie de lugares de in-ter és localizados en un mapa y listados por orden en la p ágina de informaci ón de cada d´ıa.

En la p ágina principal de la aplicaci ón se mostrar án las rutas a las que est á suscrito un usuario y las rutas creadas por él, adem ás de untimelineque mostrar á los cambios m ás recientes que han realizado los usuarios seguidos por el usuario.

El usuario de la aplicaci ón, despu és de haber accedido al sistema, podr á realizar las siguientes acciones:

◦ Crear, editar, visualizar y eliminar rutas.

◦ A ˜nadir d´ıas a rutas.

(32)

◦ A ñadir y quitar lugares de inter és a d´ıas. Ya que, como se ha comentado ante-riormente, un d´ıa incluye una serie de lugares de inter és.

◦ Crear, visualizar y editar lugares de inter ´es.

◦ Seguir o dejar de seguir rutas.

◦ Seguir o dejar de seguir a usuarios.

◦ Visualizar perfiles de usuarios.

◦ Valorar rutas y lugares de inter ´es.

◦ Buscar rutas, usuarios y lugares de inter ´es.

◦ Editar o eliminar su perfil de usuario.

(33)

CAP´ITULO

5

Primera iteraci ´

on

5.1. Requisitos implementados

En la primera iteraci ´on del desarrollo del proyecto se han decidido implementar los siguientes requisitos funcionales:

◦ Registro.

◦ Acceso.

◦ Creaci ´on de rutas.

◦ Visualizaci ´on de rutas.

◦ Modificaci ´on de rutas.

◦ Borrado de rutas.

◦ Creaci ´on de d´ıas.

◦ Visualizaci ´on de d´ıas.

◦ Modificaci ´on de d´ıas.

◦ Borrado de d´ıas.

(34)

5.2. Desarrollo

5.2.1. Modelos

Al ser el primer desarrollo que se hace del proyecto, ha sido necesaria la implementa-ci ón de los modelos de Django. La implementaimplementa-ci ón de modelos de la primera iteraimplementa-ci ón se hizo acorde al primer diagrama de clases que se dise ñ ó (Figura 4.1), habiendo su-frido modificaciones en iteraciones posteriores.

Aparte de las clases que se ven en dicho diagrama, se implementaron las clases

RelacionSeguidos, RelacionRutasSeguidas y RelacionDiaLugarInteres; estas clases se utilizan para implementar las relaciones M:M que hay entre algunas tablas. De este modo, la clase RelacionSeguidos se corresponde con la relaci ´on reflexivasigue

entre distintos usuarios; la claseRelacionRutasSeguidasimplementa la relaci ´onsigue

entre usuarios y rutas; y la clase RelacionDiaLugarInteres representa la relaci ón de composici ón entre la clase Dia y la clase LugarInteres. La implementaci ón qued ó de la siguiente manera:

C ´odigo 5.1: Relaci ´onsigueentre distintos usuarios

class RelacionSeguidos(models.Model):

seguidor = models.ForeignKey(Usuario, related_name=’seguidor’)

seguido = models.ForeignKey(Usuario, related_name=’seguido’)

class Meta:

unique_together = (’seguidor’, ’seguido’)

C ´odigo 5.2: Relaci ´on sigueentre usuarios y rutas

class RelacionRutasSeguidas(models.Model):

seguidorRuta = models.ForeignKey(Usuario, related_name=’seguidorRuta’)

ruta = models.ForeignKey(Ruta, related_name=’ruta’)

class Meta:

unique_together = (’seguidorRuta’, ’ruta’)

C ódigo 5.3: Relaci ón de composici ón entre las clasesDiayLugarInteres

class RelacionDiaLugarInteres(models.Model):

lugaresInteres = models.ForeignKey(LugarInteres,

(35)

Cap´ıtulo 5. Primera iteraci ´on

dia = models.ForeignKey(Dia, related_name=’dia’)

class Meta:

unique_together = (’lugaresInteres’,’dia’)

Cabe destacar el uso de la clase internaMetadentro de cada una de las clases de la relaci ´on con el objetivo de definir los metadatos del modelo, en este caso, el objetivo principal de los metadatos es evitar que haya objetos duplicados, esto se indica en el atributounique together de dicha clase.

En la claseRutase ha implementado una funci ón llamadarutasSeguidasUsuarioa la que se le pasa un par ámetro usuario y que devolver á todas las rutas que sigue ese usuario.

Finalmente, en la clase Dia se ha implementado una funci ón dias ruta a la que se le pasa como par ámetro ruta, esta funci ón devolver á una lista con los d´ıas que tiene asociada una ruta.

Tras desarrollar los modelos, es muy importante realizar las migraciones de modo que los modelos pasen a ser entidades en la base de datos. Desde la consola de coman-dos (y estando en el directorio ra´ız del proyecto), es necesario ejecutar los siguientes comandos:

python manage.py makemigrations

Lo que hace este comando es comparar las entidades que hay actualmente en la base de datos con los nuevos modelos y crea un archivo con las migraciones pertinentes. Despu ´es de obtener dicho archivo, para realizar los cambios en la base de datos, habr ´a que ejecutar el comando:

python manage.py migrate

5.2.2. Vistas

(36)

modifica-5.2. Desarrollo

ciones y hacer m ´as sencilla la lectura del c ´odigo.

views usuario.py

En este fichero se implementan las vistas necesarias para desarrollar los casos de uso relacionados con el perfil del usuario. Se ha estimado necesario desarrollar los siguientes m ´etodos:

◦ init(request): carga la p ágina inicial de la aplicaci ón (login.html) con su respectivo formulario, tambi én valida que los datos introducidos en el formulario pertenecen a un usuario registrado en el sistema, y que son correctos. La URL asociada a esta vista es una URL vac´ıa, de modo que sea la primera p ágina que se cargue a la hora de acceder a la aplicaci ón en caso de no tener una sesi ón iniciada en el sistema.

◦ registro(request): carga una p ´agina con un formulario para el registro de un nuevo usuario en el sistema. Tambi ´en se encarga de validar que los campos obligato-rios han sido rellenados y que no existan usuaobligato-rios con el mismo alias o email que se introduce para crear una nueva cuenta y una vez validados los datos (siendo estos correctos), crea un nuevo perfil de usuario.

Se puede observar que una vez creado el usuario, el alias del mismo se almace-na en ualmace-na variable de sesi ón. Se ha decidido usar variables de sesi ón en lugar de cookies porque estas últimas no se consideran seguras si no se env´ıan por HTTPS, siendo susceptibles a diversos ataques, como pueden ser ataques de tiposnooping1yMan-in-the-middle. Estos problemas se solucionan (en gran par-te) con el uso de sesiones, pues al almacenar toda la informaci ón relevante en el servidor, evitan el env´ıo constante de informaci ón como ocurre con lascookies.

◦ inicio(request): esta vista carga la p ágina de principal de la aplicaci ón con los datos de las rutas pertenecientes al usuario que est á almacenado en la variable de sesi ón. En caso de no haber ning ún usuario almacenado en la variable de sesi ón, se cargar á la p ágina dellogin.

views ruta.py

En este fichero se han implementado las vistas necesarias para hacer el CRUD de la clase Ruta. A grandes rasgos, se puede comprobar que todas las vistas contienen un fragmento de c ódigo com ún, este c ódigo controla que el usuario haya accedido

(37)

al sistema; en caso de que no haya accedido, la aplicaci ón redirigir á al usuario a la p ágina delogin. El c ódigo es el siguiente:

C ´odigo 5.4: Control de sesiones de la aplicaci ´on

if "usuario" in request.session:

usuario = models.Usuario.objects.filter(alias = request.session["usuario"])[0]

if usuario == None:

form = forms.RegistroForm()

return render(request, ’login.html’, {’form’: form})

else:

# Implementacion de la vista

else:

Este c ódigo de control de sesiones va a estar presente pr ácticamente en todas las vis-tas de la aplicaci ón, a excepci ón de aquellas relativas a la creaci ón de nuevos usuarios o al registro de los mismos.

Tambi én se puede observar que en las vistas editarRuta(request, id ruta)y borrarRu-ta(request, id ruta) se comprueba que el usuario que intenta realizar la acci ón sea el creador de dicha ruta; en caso contrario, se le redirigir á a la p ágina principal de la aplicaci ón.

views dia.py

(38)

5.2. Desarrollo

5.2.3. Formularios

Debido a las facilidades que ofrece Django para la creaci ón de formularios, se ha decidido desarrollar los mismos utilizando el fichero forms.py, en este fichero se han implementado clases que heredan de forms.Form cuyos atributos se corresponder án con los campos de los formularios que se mostrar án al ejecutar los ficheros.html.

En este fichero destaca la definici ón de un m étodoclean()dentro de la clase Usuario-Form. Este m étodo viene heredado de forms.Form y se utiliza para validar los datos recibidos desde el formulario; en este caso, valida que los campos que hacen referen-cia a la contrase ña y alemail coincidan.

C ódigo 5.5: Implementaci ón del m étodoclean()en la claseUsuarioForm

def clean(self):

if (self.cleaned_data.get(’password’) !=

self.cleaned_data.get(’confirmacionPassword’)):

msg = ’Las contrasenas no coinciden’

self.add_error(’confirmacionPassword’, msg)

if (self.cleaned_data.get(’email’) !=

self.cleaned_data.get(’confirmacionEmail’)):

msg = ’Los emails no coinciden’

self.add_error(’confirmacionEmail’, msg)

5.2.4. Templates

Dentro del paquete templates se encuentran los ficheros de la interfaz gr áfica de la aplicaci ón, es decir, los ficheros con extensi ón .html. En esta iteraci ón se han imple-mentado los siguientes:

◦ login.html: en él se ha implementado la p ágina para el login. Como se puede comprobar, se muestra un formulario. El formulario usado no se especifica en este fichero sino que se enviar á desde la vista. En este caso, el formulario mos-trado esRegistroForm. Es interesante destacar el uso de la etiquetacsrf token

justo despu ´es de la apertura del formulario. Esta etiqueta se usa para evitar

Cross Site Request Forgeries. Esta etiqueta se usa en formularios POST que apuntan a URLs internas.

(39)

a la delogin.html.

◦ En el ficheroinicio.html viene implementada la p ágina principal de la aplicaci ón. En ella se muestra un listado con enlaces a las rutas creadas por el usuario de la sesi ón.

◦ Los ficherosruta.html ydia.html muestran la informaci ´on correspondiente a una ruta y a un d´ıa, respectivamente.

Para el dise ño gr áfico de la interfaz gr áfica (archivos.css), es necesario crear un nue-vo paquete llamadostatic en el que se guardar án todos los archivos est áticos (CSS,

JavaScript, im ágenes, etc); dentro de este paquete es necesario crear un nuevo pa-quete llamadocsspara guardar los archivos de este tipo. Para relacionar los .csscon los.html, habr á que escribir la siguiente l´ınea de c ódigo dentro de la etiqueta<head> del archivo.html:

Adicionalmente, se han usado los siguientes componentes deBootstrap:

◦ Navbar para la barra que se encuentra en la parte superior de todas las p áginas de la aplicaci ón una vez se ha iniciado sesi ón.

◦ Para hacer m ´as visuales algunas opciones, se han utilizado algunosGlyphicons, como pueden ser el l ´apiz que se encuentra al lado del textoEditar o la papelera que se encuentra al lado del textoBorrar.

(40)

(41)

CAP´ITULO

6

Segunda iteraci ´

on

6.1. Requisitos implementados

En esta iteraci ´on se han decidido implementar los siguientes requisitos funcionales:

◦ Salida del sistema.

◦ Seguimiento de rutas.

◦ Cancelaci ´on del seguimiento de rutas.

◦ B ´usqueda de rutas.

◦ Seguimiento de usuarios.

◦ Cancelaci ´on del seguimiento de usuarios.

◦ B ´usqueda de usuarios.

◦ Visualizaci ´on del perfil.

◦ Modificaci ´on del perfil.

◦ Borrado del perfil.

(42)

6.2. Desarrollo

6.2.1. Vistas

En esta iteraci ´on los cambios m ´as notables se han producido en las vistas, por lo que nos centratemos en las mismas.

Se han a ˜nadido los siguientes m ´etodos al fichero:

◦ logout(request): este m étodo se encarga de limpiar la variable de sesi ón que almacena el nombre de usuario, terminando as´ı con la sesi ón del mismo e impi-diendo que pueda acceder a la aplicaci ón.

◦ miPerfil(request): este m étodo se encarga de cargar la informaci ón del usuario que tiene una sesi ón iniciada en el sistema en una p ágina. Adem ás de la infor-maci ón b ásica del perfil, tambi én muestra inforinfor-maci ón sobre las rutas creadas, las rutas seguidas y los usuarios seguidos. Adem ás, en ella se da la opci ón al usuario de editar o eliminar el perfil.

◦ editarPerfil(request): carga un formulario con la informaci ón b ásica del usuario que tiene iniciada sesi ón en el sistema para que este la modifique seg ún estime conveniente.

◦ borrarPerfil(request): elimina el perfil del usuario que tiene iniciada sesi ón en el sistema, limpiando tambi én la variable de sesi ón que almacena el nombre del usuario.

◦ perfil(request, id usuario): carga el perfil de un usuario registrado en el sistema. La ´unica diferencia con la vista miPerfil(request) es que a esta no se le pasa como par ´ametro elid usuario, ya que no es necesario.

◦ seguirUsuario(request, id usuario): esta vista a ˜nade un usuario seleccionado a la lista de seguidos del usuario que tiene iniciada sesi ´on en el sistema.

(43)

Cap´ıtulo 6. Segunda iteraci ´on

views ruta.py

La vista m ´as destacable del fichero views ruta.py es busqueda(request). En ella, se toma el valor de un formulario de tipo GET y se buscan rutas y usuarios atendiendo a los siguientes criterios:

◦ El t´ıtulo de la ruta contiene la consulta.

◦ La descripci ´on del a ruta contiene la consulta.

◦ El t´ıtulo o la descripci ´on del d´ıa contienen la consulta.

◦ El creador de la ruta contiene la consulta.

◦ El alias del usuario contiene la consulta.

Esta vista redirigir á a una nueva p ágina que mostrar á dos pesta ñas: una pesta ña mos-trar á las rutas coincidentes encontradas y la otra, los usuarios.

Tambi ´en se han implementado las vistasseguirRuta(request, id ruta)y dejarDeSegui-rRuta(request, id ruta), las cuales no ser ´an comentadas pues son muy similares a las vistasseguirUsuario(request, id usuario)ydejarDeSeguirUsuario(request, id usuario).

Finalmente, se han modificado las vistas anteriormente implementadas, en ellas ahora se comprueba si el usuario sigue la ruta que cargan.

6.2.2. Templates

En esta iteraci ón se ha a ñadido eltemplate busqueda.html, en el que se muestran los datos relativos a la b úsqueda realizada.

Tambi ´en se han implementadotemplates relativos al perfil de usuario, como son per-fil.html, en el que se muestran los datos de un usuario, y editarPerfil.html, para la modificaci ´on de los datos de un usuario.

(44)

6.3. Pruebas

Una modificaci ´on bastante simple pero a la vez bastante significativa es el despliegue de unalert usandoJavaScript para confirmar el borrado de d´ıas y rutas.

6.3. Pruebas

(45)

CAP´ITULO

7

Tercera iteraci ´

on

7.1. Requisitos implementados

En esta iteraci ´on del desarrollo del proyecto se han implementado una serie de requi-sitos funcionales que no se encuentran en el cap´ıtulo 3. Esto se debe a que la lista de requisitos del cap´ıtulo 2 no es la lista inicial y ha sufrido modificaciones a lo largo del desarrollo.

En este caso, exist´ıa otro rol de usuario llamadoAdministrador, que se encargaba de crear, editar, modificar y borrar lugares de inter és creados por él. Adem ás, pod´ıa crear, modificar y borrar eventos asociados a los lugares de inter és creados por él.

A continuaci ´on se enumeran y explican los requisitos que se implementaron en esta iteraci ´on:

◦ Registro de administrador: el administrador podr ´a registrarse en el sistema intro-duciendo los datos necesarios.

◦ Acceso de administrador: el administrador podr ´a acceder al sistema indicando que es un administrador e introduciendo un nombre de usuario y una contrase ˜na.

◦ Salida del sistema del administrador: el administrador podr ´a salir del sistema ce-rrando sesi ´on.

(46)

7.2. Desarrollo

inter ´es.

◦ Visualizaci ón de lugares de inter és: el usuario y el administrador podr án visuali-zar los lugares de inter és que est én creados en el sistema.

◦ Modificaci ón de lugares de inter és: el administrador podr á modificar la informa-ci ón relativa a un lugar de inter és creado previamente por él.

◦ Borrado de lugares de inter és: el administrador podr á borrar un lugar de inter és previamente creado por él.

◦ Creaci ón de eventos: el administrador podr á crear un nuevo evento dentro de un lugar de inter és espec´ıfico creado por él.

◦ Visualizaci ón de eventos: el usuario y el administrador podr án visualizar los even-tos que est én creados en el sistema.

◦ Modificaci ón de eventos: el administrador podr á modificar informaci ón relativa a un evento creado previamente por él.

◦ Borrado de eventos: el administrador podr ´a borrar un evento creado previamente por ´el.

La especificaci ´on de los casos de uso, al igual que en los cap´ıtulos anteriores, vendr ´a hecha en elAnexo A.

7.2. Desarrollo

7.2.1. Formularios

Se hace necesario mencionar las modificaciones en el fichero forms.py antes de ex-plicar las modificaciones en las vistas.

En primer lugar, se crearon dos nuevas clases, una para el formulario de creaci ón y edici ón del lugar de inter és, y otra para el formulario de creaci ón y edici ón del evento. Se hace interesante mostrar el c ódigo del formulario implementado para la creaci ón y edici ón de eventos, pues ha sido eliminado en posteriores iteraciones (el porqu é de estos cambios viene explicado en el siguiente cap´ıtulo), por lo que no es posible encontrarla en el c ódigo de la aplicaci ón:

(47)

Cap´ıtulo 7. Tercera iteraci ´on

class EventoForm(forms.Form):

nombre = forms.CharField(max_length=100, label="Nombre")

descripcion = forms.CharField(max_length=1000, widget=forms.Textarea)

inicio = forms.DateField(initial=datetime.date.today())

fin = forms.DateField(initial=datetime.date.today())

precio = forms.DecimalField(max_digits=8, decimal_places=2)

Tambi én se hace necesario comentar que el campo horario de la clase LugarInteres-Form sea de tipo CharField, en lugar de ser de tipoTimeField, se ha decidido imple-mentar de esta manera para dar m ás libertad al administrador del lugar de inter és, pues los horarios pueden variar dependiendo de si es fin de semana, festivo o laboral.

Se a ñadi ó tambi én un campo adminde tipoBooleanField a la claseUsuarioForm, de manera que se puedan crear usuarios con el rol de administrador de lugares de inter és. Asimismo, tambi én se a ñadi ó un campo administrador, tambi én de tipo BooleanField

a la claseRegistroFormpara que el administrador de lugares de inter ´es pudiera iniciar sesi ´on.

7.2.2. Vistas

Las vistas implementadas en iteraciones anteriores fueron modificadas para evitar que el administrador de lugares de inter és accediera a p áginas que no le estaban permiti-das, como eran la p ágina de inicio de usuario, las p áginas de creaci ón, visualizaci ón, modificaci ón y borrado de la ruta, la p áginas de creaci ón, visualizaci ón, modificaci ón y borrado del d´ıa y la p ágina de b úsqueda. De este modo, el administrador de lugares de inter és solo pod´ıa acceder a las p áginas de creaci ón, visualizaci ón, modificaci ón y borrado de lugares de inter és y eventos, adem ás de la p ágina de inicio del adminis-trador de lugares de inter és, que mostraba únicamente los lugares de inter és creados por el mismo.

(48)

7.2. Desarrollo

views admin.py

En este fichero solo se ha implementado una única vista: inicioAdmin(request) esta vista cargar´ıa todos los lugares de inter és (ordenados por nombre) creados por el administrador que tiene iniciada sesi ón en el sistema y los mostrar´ıa en su p ágina principal de la aplicaci ón.

views lugar interes.py

Se puede comprobar que en todas las vistas de este fichero se repite el mismo frag-mento de c ´odigo:

if "admin" in request.session:

admin = models.Administrador.objects.filter(alias = request.session["admin"])[0]

if admin == None:

else:

Este c ódigo impide que los usuarios que no hayan iniciado sesi ón en el sistema pue-dan ver las p áginas del mismo. Y, aunque hayan iniciado sesi ón, si no son de tipo

Administrador, tampoco podr án acceder a ciertas p áginas de la aplicaci ón.

(49)

Cap´ıtulo 7. Tercera iteraci ´on

views evento.py

La implementaci ´on de las vistas de este fichero es similar a la del ficheroviews lugar interes.py. En ´el se desarrollan las vistas necesarias para hacer un CRUD de un evento dentro de

un lugar de inter és. Al igual que en las vistas desarrolladas en el fichero explicado en el apartado anterior, se comprueba que el administrador tiene una sesi ón iniciada en el sistema. Tambi én se comprueba que el administrador que intenta crear un evento en un lugar de inter és sea el mismo que cre ó el lugar de inter és.

7.2.3. Templates

En esta iteraci ´on se han implementado los siguientestemplates:

◦ En el fichero inicioAdmin.html se implementa la p ágina principal de la aplica-ci ón de cara al administrador. En ella únicamente se muestra un listado con los lugares de inter és creados por él.

◦ En los ficheros crearEvento.html y crearLugarInteres.html se implementan las p ´aginas que muestran los formulariosEventoForm yLugarInteresForm respecti-vamente.

(50)

(51)

CAP´ITULO

8

Cuarta iteraci ´

on

8.1. Requisitos implementados

Debido a que no es posible verificar que el usuario registrado como administrador de lugares de inter és sea realmente alguien que tenga relaci ón con dichos lugares de in-ter és, se ha decidido eliminar el rol de administrador. De este modo, todos los usuarios podr án crear y editar cualquier lugar de inter és. La idea es que haya la mayor infor-maci ón posible sobre los lugares de inter és, y se puedan corregir los errores. Para futuras versiones se propone la creaci ón de un usuario con rol moderador que ser á el encargado de confirmar que la informaci ón de los lugares de inter és es correcta.

Teniendo esto en cuenta, los requisitos funcionales desarrollados en esta iteraci ´on han sido los siguientes:

◦ Creaci ´on de lugares de inter ´es.

◦ Visualizaci ´on de lugares de inter ´es.

◦ Modificaci ´on de lugares de inter ´es.

◦ B ´usqueda de lugares de inter ´es.

◦ Valoraci ´on de rutas.

◦ Borrado de valoraciones de rutas.

(52)

8.2. Desarrollo

◦ Borrado de valoraciones de lugares de inter ´es.

◦ A ˜nadido de lugares de inter ´es a d´ıas.

8.2. Desarrollo

8.2.1. Modelos

Como se ha comentado en el apartado anterior, no es posible verificar que el admi-nistrador de lugares de inter és sea una persona que realmente tiene una relaci ón con dichos lugares de inter és, por lo que se ha decidido eliminar este tipo de usuario, eli-minando as´ı este modelo.

Eliminado el administrador, no tiene sentido que los lugares de inter és contengan eventos, pues los usuarios no tienen por qu é saber si en un lugar se va a celebrar algo, por lo que tambi én se ha decidido eliminar este modelo.

8.2.2. Vistas

En esta iteraci ón se han modificado las vistas relativas a los lugares de inter és y se han a ñadido vistas para las valoraciones.

Con respecto a las modificaciones en las vistas relativas a los lugares de inter és se puede comprobar que el c ódigo que antes era com ún en las mismas ha sido reempla-zado por el siguiente:

if "usuario" in request.session:

usuario = models.Usuario.objects.filter(alias = request.session["usuario"])[0]

if usuario == None:

else:

(53)

Cap´ıtulo 8. Cuarta iteraci ´on

Como se puede observar, en estas vistas no se comprueba que el usuario sea el creador del lugar de inter ´es, sino que ´unicamente se comprueba que haya un usuario registrado en el sistema.

En el ficheroviews ruta.py se han producido varias modificaciones:

◦ Se ha modificado la vista busqueda(request) para que se busquen lugares de inter ´es cuyo t´ıtulo o localidad contengan la consulta.

◦ Se han a ñadido las vistas addValoracion(request) y borrarValoracion(request, id valoracion) para a ñadir una valoraci ón a una ruta, o borrar una valoraci ón he-cha en una ruta, respectivamente.

◦ Adem ás, cuando se carga la p ágina de una ruta, se carga tambi én una lista con las valoraciones asociadas a la ruta.

◦ Se ha implementado una funci ´on para calcular la valoraci ´on media de una ruta.

En el ficheroviews lugar interes.py adem ás de implementar las vistas para el a ñadido y borrado de valoraciones de los mismos (similares a las vistas de a ñadido y borrado de valoraciones de las rutas), cabe destacar la vista buscar lugares interes(request). Contra todo pron óstico, esta vista se llama desde la p ágina de informaci ón de un d´ıa, y se utiliza para buscar lugares de inter és dada una localidad, y recargar á la p ágina del d´ıa mostrando un listado con los lugares de inter és encontrados. La vista que a ñade dichos lugares de inter és al d´ıa esadd lugar interes(request).

8.2.3. Formularios

En los formularios relativos al acceso y al registro se puede observar que se ha elimi-nado el campo que hac´ıa referencia al administrador.

Se ha a ñadido una nueva clase al fichero, EditarLugarInteresForm. El prop ósito de esta clase de formulario es que el usuario no pueda modificar el nombre, la direcci ón ni la localidad del lugar de inter és cuando entra en la p ágina que muestra el formulario de edici ón del mismo.

(54)

8.2. Desarrollo

valoraciones tanto en la p ágina de informaci ón de la ruta como en la del lugar de inter és.

8.2.4. Templates

En esta iteraci ´on se han producido los siguientes cambios en lostemplates:

◦ Enruta.html ylugarInteres.html se han implementado los formularios de las va-loraciones y debajo se muestran las vava-loraciones relativas a la ruta o al lugar de inter és de los cuales se est á consultando la informaci ón.

(55)

CAP´ITULO

9

Quinta iteraci ´

on

9.1. Requisitos implementados

En esta iteraci ón se han implementado únicamente dos requisitos funcionales. El peso de la misma ha reca´ıdo en el desarrollo de tareas as´ıncronas, validaciones de datos en los formularios e internacionalizaci ón. Los requisitos implementados han sido los siguientes:

◦ Borrado de lugares de inter ´es en d´ıas.

◦ Recuperaci ´on de la contrase ˜na.

Tambi én se ha modificado la creaci ón de lugares de inter és, ahora se comprueba que no existe un lugar de inter és con el mismo nombre en la misma ciudad.

9.2. Desarrollo

9.2.1. Vistas

(56)

9.2. Desarrollo

comprueba que exista un usuario con el email introducido en el formulario de recupe-raci ´on de la contrase ˜na.

En caso de que exista un usuario con el email introducido, se generar á una contra-se ña con caracteres alfanum éricos de longitud 10 y contra-se asignar á al usuario. Luego contra-se procede al env´ıo de la contrase ña alemail vinculado al usuario.

Para el env´ıo del email se ha utilizado la clase de Django EmailMultiAlternatives. Que se importar á dedjango.core.mail. Adem ás, es necesario modificar el fichero set-tings.py y a ñadir la siguiente configuraci ón:

C ´odigo 9.1: Configuraci ´on delemail en el ficherosettings.py

EMAIL_HOST = ’smtp.gmail.com’ # Servidor del e-mail, en este caso es Gmail

EMAIL_HOST_PASSWORD = ’password’

EMAIL_HOST_USER = ’[email protected]’

EMAIL_PORT = 587

EMAIL_USE_TLS = True

DEFAULT_FROM_EMAIL = EMAIL_HOST_USER

views lugar interes.html

Se ha implementado la vista removeLugarInteresEnDia(request, id lugarInteres) que permitir á al creador de un d´ıa quitar lugares de inter és previamente a ñadidos.

Tambi én se ha modificado la vistacrearLugarInteres(request) de modo que se valide que no haya ya un lugar de inter és con el mismo nombre y la misma localizaci ón crea-do en el sistema.

Adem ás, se ha a ñadido un m étodo que calcular á la valoraci ón media de un lugar de inter és.

views ruta.py yviews dia.py

(57)

Cap´ıtulo 9. Quinta iteraci ´on

El precio del d´ıa ser á la suma de los precios de todos los lugares de inter és del mismo y el precio de la ruta ser á la suma del precio de sus d´ıas.

9.2.2. Templates

Como se ha comentado anteriormente, el peso de esta iteraci ón ha reca´ıdo en el desarrollo de operaciones as´ıncronas y el uso de la API de Google Maps, por lo que se har á hincapi é en los mismos. Al implementarse en diferentes archivos .html, se comentar á lo desarrollado, sin dar importancia al archivo en el que se desarrolla.

Tareas as´ıncronas

Antes de comentar el desarrollo, se hace necesario explicar qu é es una tarea as´ıncro-na. A grandes rasgos, en el ámbito de la ingenier´ıa web las tareas as´ıncronas son aquellas que se ejecutan en segundo plano y evitan que la p ágina tenga que estar refresc ándose.

Para implementar estas tareas se ha utilizado AJAX y JQuery, aunque existen otras tecnolog´ıas como pueden ser Celery o Parsley. ¿Por qu ´e no se ha utilizadoCelery o

Parsley? Pues bien,Celery est á pensado para la ejecuci ón de tareas intensivas que bloquear´ıan la aplicaci ón en caso de no ejecutarse en segundo plano.Parsley, por otro lado, se utiliza para las validaciones de campos en formularios en tiempo real, pero se ha quedado obsoleto.

Teniendo esto en cuenta, se procede a explicar las tareas as´ıncronas desarrolladas en esta iteraci ´on:

◦ Borrado de d´ıas directamente desde la tabla que se muestra en la p ´agina de la ruta. Esta tarea se invoca en el atributoonclick dentro de la etiqueta <a> del borrado del d´ıa. Como se puede comprobar se ha eliminado el atributohref

de la misma, esto es debido a que la llamada a la vista que se hace dentro de este atributo tiene m ás prioridad que la llamada a la tarea en JQuery, adem ás de que no hay ning ún inter és en acceder a una nueva p ágina.

(58)

cons-9.2. Desarrollo

truida anteriormente y, en caso de éxito en la operaci ón, modificar á la p ágina actual, en caso de fallo, lanzar á un mensaje de error.

C ´odigo 9.2: Borrado de d´ıas as´ıncrono

<td><a onclick="borrarDia({{dia.id}})"><span class="glyphicon

glyphicon-trash" aria-hidden="true"></span>{ % trans "Borrar" %}</a> <script type="text/javascript">

function borrarDia(id_dia){

var confirmacion = confirm(’Borrar el dia?’);

if (confirmacion == true){

var $url = "/"+id_dia+"/borrarDia/";

$.ajax({ url: $url, success: function(data){ $(’body’).html(data); }, error: function(){

alert("Error");

}

});

}

</script>

\label{borrado_dias_asincrono}

◦ A ñadido de valoraciones a rutas.(listado ??) Para realizar esta operaci ón es necesario que la etiqueta <form>tenga un único atributo, este ser á el atributo

id. La tarea se realizar á creando un objeto con el formulario en JQuery y lla-mando desde el objeto al m étodo submit. Dentro del m étodosubmit se llama al m étodoajax(), en el que se serializan los datos para su tratamiento, se indica si el formulario es de tipoGET oPOST y la URL de la vista en la que se tratar á el formulario, en este caso,/addValoracion/.

C ´odigo 9.3: A ˜nadido de valoraciones as´ıncrono

<form id="form-valoracion-ruta">{ % csrf_token %}

(59)

Cap´ıtulo 9. Quinta iteraci ´on

$(’#form-valoracion-ruta’).submit(function(event){ event.preventDefault(); $.ajax({ data: $(this).serialize(), type: ’POST’, url: ’/addValoracion/’, success: function(data){ $(’body’).html(data); }, error: function(){

alert("Error");

}

})

});

</script>

\label{add_valoraciones}

◦ Del resto de tareas as´ıncronas implementadas no se va a comentar el c ´odigo, pues esto supondr´ıa repetir los dos puntos anteriores. S´ı que se procede a enu-merarlas:

• Seguimiento de rutas.

• Cancelaci ´on del seguimiento de rutas.

• Borrado de valoraciones de rutas.

• B úsqueda de lugares de inter és en la p ágina de d´ıas.

• A ˜nadido de lugares de inter ´es a d´ıas.

• Borrado de lugares de inter ´es en d´ıas.

• Seguimiento de usuarios.

• Cancelaci ´on del seguimiento de usuarios.

• A ˜nadido de valoraciones a lugares de inter ´es.

(60)

9.2. Desarrollo

API deGoogle Maps

Para mejorar la experiencia del usuario, se muestran mapas indicando d ´onde se en-cuentran los lugares de inter ´es de las rutas. Para ello se ha hecho uso de la API de

Google Maps, que ofrece diferentes funcionalidades. En este caso se utilizar á la geo-localizaci ón dada una direcci ón.

Dependiendo de si se desea mostrar un único marcador (como es el caso de la p ági-na de informaci ón de los lugares de inter és) o m últiples marcadores (como es el caso de la p ágina de informaci ón de d´ıa o ruta), la implementaci ón de la funci ón initMap()

(funci ´on encargada de mostrar el mapa con los marcadores) ser ´a diferente.

En el caso de querer mostrar un único marcador, la funci óninitMap()crear á un nuevo objeto de tipo Map en el que se indicar á el estilo del mapa y otro de tipo Geocoder, al que se le indicar á la direcci ón en la que se desea poner el marcador. Tambi én se llamar á a una funci ón que ser á la encargada de localizar el marcador en la direcci ón indicada y centrar á el mapa en funci ón del marcador.

En el caso de querer mostrar m ´as marcadores, el desarrollo se complica. En la funci ´on

initMap() únicamente se inicializan las variables globales. Tambi én se implementa una funci óngeocodeAddress(address, next) que geolocaliza la direcci ón y llama a la fun-ci óncreateMarker(add, lat, lng), que ser á la encargada de a ñadir el marcador al mapa.

Internacionalizaci ´on

La internacionalizaci ´on se ha llevado a cabo tanto en lostemplatescomo en el fichero

forms.py, aunque de maneras diferentes.

Enforms.py se utiliza la funci ´on ()para indicar las cadenas que son traducibles, mien-tras que en los templates es necesario incluir {% load i18n %} antes de la etiqueta <html>. En los templates las cadenas que son traducibles se indican de la siguiente manera:

{% trans “Cadena” %}

(61)

do-Cap´ıtulo 9. Quinta iteraci ´on

(62)

(63)

CAP´ITULO

10

Sexta iteraci ´

on

10.1. Modificaciones

Este iteraci ón iteraci ón ha consistido en arreglar fallos menores, hacer la interfaz m ás intuitiva y a ñadir untimelinea la p ágina principal de la aplicaci ón.

La implementaci ón deltimelinecorresponde a la implementaci ón del requisito Monito-rizaci ón de acciones.

10.2. Desarrollo

10.2.1. Modelos

Para esta iteraci ón se ha modificado el archivomodels.py. En él se ha implementado una caseLog que almacenar á los cambios que hace un usuario en una ruta.

(64)

10.2. Desarrollo

10.2.2. Vistas

En la vistainicio(request) en el archivo views usuario.py se cargan todos los objetos de la claseLog cuyo usuario est é en la lista de seguidos del usuario que tiene iniciada la sesi ón, o cuya ruta est é en la lista de rutas seguidas del usuario que tiene iniciada la sesi ón.

En las vistascrearRuta(request)yeditarRuta(request, id ruta)en el ficheroviews ruta.py

y en las vistasanadirDia(request, id ruta),borrarDia(request, id dia)yeditarDia(request, id dia)en el ficheroviews dia.py se observa un fragmento de c ´odigo com ´un:

C ´odigo 10.1:Log de operaciones

log = models.Log(usuario=usuario,

ruta=ruta,

fecha=timezone.now(),

log=’accion realizada por el usuario’)

log.save()

En ´el se guardan los cambios que ha realizado el usuario para posteriormente mos-trarlos en elTimeline.

En el campologse almacena la acci ón que realizada, ya sea creaci ón o modificaci ón.

10.2.3. Templates

En esta iteraci ´on los cambios realizados en los ficheros .html son principalmente est ´eticos:

◦ Los enlaces que antes hab´ıa en elNavbar ahora est ´an contenidos dentro de un

Dropdown que se encuentra en elNavbar.

◦ En el Dropdown se han a ñadido enlaces a la p ágina de creaci ón de ruta, lugar de inter és, perfil de usuario, edici ón del perfil ylog out.

◦ El Navbar pasa a estar fijo en la parte superior de la p ´agina, de manera que el usuario siempre lo tiene a la vista.

(65)

Cap´ıtulo 10. Sexta iteraci ´on

◦ La p ´agina principal ahora muestra un panel con las rutas creadas por el usuario y las rutas que sigue y tambi ´en elTimelinecomentado anteriormente.

(66)

(67)

CAP´ITULO

11

Conclusiones

11.1. Opini ´

on sobre la uni ´

on de

Django

y

Amazon Web

Services

Para poner en contexto a futuros lectores de este proyecto, mi intenci ón a la hora de desarrollar esta aplicaci ón era utilizarJava Server Faces, pero debido a la poca infor-maci ón que encontr é en Internet de aplicaciones Web desarrolladas en Java Server Faces y desplegadas enAmazon Web Services, decid´ı aventurarme a utilizar Django

(a pesar de que no ten´ıa conocimientos de Python) para el mismo pues, tras varios d´ıas investigando, me dio la sensaci ón de que hab´ıa una gran cantidad de informaci ón respecto al tema y no perder´ıa mucho tiempo investigando sobre c ómo desplegar la aplicaci ón.

(68)

11.2. An ´alisis de resultados

A pesar de esto, Django presenta tambi én inconvenientes, sobre todo a la hora de desplegar una aplicaci ón en un servidor. Como se ha comentado en el p árrafo an-terior, Django facilita al programador las conexiones con las bases de datos locales, pero, por el contrario, conectarDjangoa una base de datos remota requiere de mucho tiempo y paciencia.

11.2. An ´alisis de resultados

En el anteproyecto se propuso el desarrollo de una aplicaci ´onWeb utilizando elcloud

de Amazon. Si bien se ha desarrollado la aplicaci ´on web al completo, no me ha sido posible desplegarla en Amazon Web Services, pues la documentaci ´on disponible en

Internet era escasa o estaba desfasada.

Tambi ´en se propuso la entrega de un manual de usuario, este se puede encontrar en elAnexo C.

Ser´ıa interesante hablar tambi ´en de las estimaciones que se hicieron en el antepro-yecto. Si bien se hizo la estimaci ´on del cuadro 11.1, la realidad se aleja bastante de la misma, quedando el tiempo empleado como se refleja en el cuadro 11.2.

Fase Horas

An ´alisis de requisitos 10 An ´alisis de requisitos 51

Dise ˜no 51

Implementaci ´on 52

Pruebas 51

Integraci ´on 51

Memoria 30

Cuadro 11.1: Estimaciones hechas en el anteproyecto