TRABAJO FIN DE GRADO

Título

Red social deportiva Autor/es

Javier Muro Robles Director/es

César Domínguez Pérez Facultad

Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación

Grado en Ingeniería Informática Departamento

Curso Académico

2012-2013

Red social deportiva, trabajo fin de grado de Javier Muro Robles, dirigido por César Domínguez Pérez (publicado por la Universidad de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright.

© ©

El autor Universidad de La Rioja, Servicio de Publicaciones, 2013 publicaciones.unirioja.es E-mail: [email protected]

UNIVERSIDAD DE LA RIOJA

Facultad de Ciencias, Estudios Agroalimentarios e Informática

TRABAJO FIN DE GRADO Grado en Ingeniería Informática

Red Social Deportiva

Alumno: Javier Muro Robles Director: César Domínguez Pérez Logroño, 03‐07‐2013.  

ÍNDICE  RESUMEN.                                                                                                                             3  1. DOCUMENTO DE OBJETIVOS DEL PROYECTO.                                                          4  1.1 Objetivo   

 

 

 

 

 

 

1.2 Alcance del proyecto                                                                   

 

 

  

   

 

 

 

2. GESTIÓN DEL PROYECTO.                                                                                             12  2.1 Diagrama de Gantt final   

 

 

 

 

 

 

 

 

14 

2.2 Errores de planificación     3. ANALISIS.                                                                                                      

3.1 Definición del sistema                                                                                    

 

3.2 Casos de uso                                                                             

 

 

 

3.3 Análisis de clases                                                                                  

 

 

4. DISEÑO.                                                                                                                            25  4.1 Estructura de la aplicación                                                                                                   4.2 Diseño de la base de datos                                                                                                           4.3 Diseño de interfaces                                                                                                      5. CONSRTUCCIÓN.                                                                                                            34  5.1 Preparación del entorno de construcción                                                          

 

5.2 Implantación de la base de datos                                              

 

 

 

 

5.3 Controladores                                5.4 Vistas 

 

 

 

 

 

 

 

 

 

 

5.5 Librerías externas utilizadas  5.6 Seguridad   

 

5.7 Problemas  

 

5.8 Posibles mejoras   

 

 

6. CONCLUSIÓN                                                                                                                   45 

 

8. BLIBIOGRAFÍA                                                                                                                  46  ANEXO I. MANUAL DE USUARIO                                                                                      48     

2   

RESUMEN  Español   El proyecto realizado es una aplicación web llamada “sports joinder”, en ella se podrán  realizar quedadas deportivas con gente que realice el mismo deporte.  La  aplicación  tiene  características  de  redes  sociales,  como  hacer  amigos  y  enviar  mensajes. También se podrá configurar para que el sistema envíe notificaciones a los  usuarios en los horarios que tenga libres, sobre eventos deportivos que otros usuarios  creen.  Para  que  los  enfrentamientos  sean  divertidos,  la  aplicación  cuenta  con  un  sistema de emparejamiento por nivel.  Los usuarios pueden introducir zonas deportivas para poder realizar el deporte donde  quieran.  Lo que se pretende con esta aplicación es que nadie se quede sin realizar su deporte  favorito.  Inglés   The  created  project  is  a  web  application  called  "sports  joinder".  In  this  web,  sport  meetups can be done with people who do the same sport.  The  application  has  social  networking  features,  such  as  making  friends  and  sending  messages. Sports joinder can also be configured to send notifications to system users  in her free times on sport events that other users create. Besides, the application has a  matching system per level.  Users can also enter sports areas to perform the sport where they want.  The purpose of this application is that nobody stays in home without doing her favorite  sport.          3   

1 DOCUMENTO DE OBJETIVOS DEL PROYECTO  1.1 Objetivo.  El  proyecto  consistirá  en  la  creación  de  una  aplicación  web  pública,  de  la  cual,  su  función  principal  será  gestionar  y  organizar  eventos  deportivos  entre  los  diferentes  usuarios del sistema, todo esto envuelto en un entorno de red social.   1.2 Alcance del proyecto.  La  carencia  de  un  cliente  que  solicite  esta  aplicación  conlleva  que  el  alcance  del  proyecto sea confeccionado entre el alumno y el profesor, con la intención de que el  producto  final  tenga  todas  las  funcionalidades  apropiadas  de  una  aplicación  de  este  tipo.  1.2.1 Requisitos mínimos alcanzables.   A continuación se enumeran con mayor nivel de concreción las funcionalidades que se  pretenden para la aplicación web.  Con la palabra gestión me refiero a la creación, consulta, actualización.  Aplicación web.   Gestión  de  Usuarios:  Los  usuarios  podrán  darse  de  alta  por  sí  mismos  en  la  aplicación  y  podrán  gestionar  sus  datos  personales  e  introducir  los  deportes  que  practica,  además  de  poder  acceder  a  la  misma  mediante  cuenta  de  Facebook o Twitter.    Gestión de Deportes: Tanto el administrador de la aplicación como los usuarios  (previa  validación  del  administrador)  podrán  introducir  nuevos  deportes  al  sistema.   Gestión  de  nivel  de  usuarios:  El  nivel  de  los  usuarios  en  cada  deporte  se  determinara mediante autoevaluación y evaluación de los contrincantes de los  eventos organizados por el sistema. 

4   

 Gestión de Zonas deportivas: Tanto el administrador de la aplicación como los  usuarios  (previa  validación  del  administrador)  podrán  introducir  zonas  deportivas facilitándose un mapa interactivo para su creación.   Gestión  de  Grupos:  Los  usuarios  podrán  crear  grupos  por  cada  deporte  para  poder facilitar la organización de partidos.   Organización de eventos deportivos: El sistema organizará eventos deportivos  en función de los datos introducidos por los usuarios en el sistema (Localidad,  Deporte, Nivel del deporte, Horarios disponibles, Zona deportiva). Los eventos  organizados se enviarán a los usuarios, dejando a uno de ellos encargado para  la  reserva  de  la  zona  deportiva.  Se  necesitará  una  confirmación  por  parte  de  cada usuario para que se considere válido.   Búsqueda  manual  de  usuarios:  Los  usuarios  tendrán  la  opción  de  buscar  usuarios  mediante  diferentes  criterios  para  poder  organizar  entre  ellos  los  eventos deportivos.   Comunicación  de  usuarios:  Habilitar  sistemas  de  comunicación  entre  los  usuarios del sistema como envío de correo y chat.  1.2.2 Posibles ampliaciones de la aplicación.  ‐Integración con Facebook.  ‐Envío de SMS a los usuarios.  ‐Posibilidad de integración del sistema con una zona deportiva para que puedan llevar  la organización de sus eventos P.E: Club de pádel.  ‐Aplicación Android para el sistema.  1.2.3 Especificación de las tecnologías  En  este  apartado  se  exponen  las  diferentes  tecnologías  usadas  en  el  proyecto,  tratando de justificar el uso de cada una de ellas.  Ruby con el framework ruby on rails: En principio, parto de un conocimiento bastante  limitado  con  relación  a  los  lenguajes  que  permiten  programación  Web.  Después  de  investigar un tiempo, opto por Ruby on rails por el crecimiento y la extensa aceptación  que está obteniendo por parte de la comunidad de desarrolladores, aunque se podría  5   

haber optado por otros lenguajes de similar funcionalidad como pueden ser PHP, JSP,   o ASP.NET.  El entorno de programación que usaré para este lenguaje será Rubymine.  MySql: En un principio había contemplado usar SQL Server u Oracle, pero la gratuidad  de  MySql  (para  uso  privado,  no  comercial)  y  la  gran  aceptación  que  tiene  ha  hecho  decantarme por él.    También he de decir que existen entornos de creación de redes sociales, como Spree,  Isocial o Mahara, he decidido desecharlos puesto que ni en mi vida como estudiante ni  mi vida laboral he podido realizar una aplicación web de esta entidad, y entiendo que  este trabajo es necesario y muy aprovechable para mi formación profesional.    1.2.4 Antecedentes.  Existen gran cantidad de redes sociales de diversa índole, pero ninguna de ellas explota  el tema de la organización de eventos deportivos. La única que he podido observar que  realiza  gestiones  parecidas  es  una  aplicación  web  que  se  dedica  a  la  organización  de  partidos de futbol.    1.2.5 Riesgos Posibles  No se encuentran riesgos específicos a la hora de realizar esta aplicación, por lo tanto  contamos con los riesgos habituales del desarrollo de proyectos.    1.2.6 Seguimiento y Entregables.  Las  comunicaciones  y  revisiones  con  el  profesor  serán  semanales  vía  E‐Mail,  y  quincenales mediante reuniones.    Durante la realización del proyecto se realizarán los siguientes entregables.  ‐Memoria del proyecto.   Documento de Objetivos del proyecto.   Fase de análisis.   Fase de diseño.  ‐CD con todo el código del proyecto junto con su documentación, manuales etc.  6   

1.2.7 Planificación del proyecto  1.2.7.1 Estructura de descomposición de trabajo (EDT) 

  1.2.9.2 Descomposición de Tareas  T01 ‐ Gestión  Temporalmente,  esta  tarea  comprende  toda  la  vida  del  proyecto,  puesto  que  este  bloque contiene las tareas necesarias para la correcta gestión y dirección del mismo.  Abarca todos los procesos que implican un gasto temporal considerable y que sirven  tanto para la planificación del proyecto como para el seguimiento del mismo.    T011 ‐ Planificación de Tareas  Este  paquete  consta  de  la  localización  de  las  diferentes  tareas    del  proyecto  y  para  estimar su duración.  ‐> 3 horas.  T012 ‐ Reuniones  Puesto  que  no  hay  un  cliente  real  las  reuniones  se  realizarán  con  el  director  del  proyecto.  ‐> 10 horas.  T013‐ Seguimiento  El  seguimiento del avance del proyecto se sucederá durante toda la vida del proyecto  para comprobar el estado del mismo.  ‐> 6 horas.  T02‐ Inicio del proyecto  Este paquete agrupa todas las tareas necesarias para la puesta en marcha del proyecto  T021‐ Confección del DOP  Constará de las características más importantes del proyecto.  7   

‐>Estimación‐ 8 horas.  T022‐ Requisitos  El alumno recogerá en un documento de requisitos las necesidades del cliente (en este  caso ficticio).  ‐>Estimación‐ 3 horas.    T03‐ Formación  Tecnologías usadas en la aplicación.   T031‐ ROR (Ruby on Rails)  Poseo escasos conocimientos sobre este lenguaje de programación por lo tanto tendré  que dedicar bastante tiempo de estudio a esta tecnología y el paradigma modelo vista  controlador.  ‐>Estimación‐ 15 horas.  T032‐ SQL  Prácticamente  no  será  necesaria  formación  en  SQL,  ya  que  durante  la  carrera  y  mi  formación  profesional  he  obtenido  los  conocimientos  necesarios  para  poder  realizar  este proyecto.  ‐>Estimación‐ 1 horas.  T033‐ RubyMine  Puesta en marcha y pruebas con el IDE de rails.  ‐>Estimación‐ 1:30 horas.  T04‐ Análisis  Los  paquetes  de  trabajo  de  este  bloque  pretenden  analizar  las  capacidades  y  limitaciones de cada una de las tecnologías para evitar problemas futuros.  T041‐ Casos de Uso  En  este  paquete  de  trabajo  se  identificarán  actores,  se  crearán  los  casos  de  uso,  se  crearán  los  diagramas  de  actividad,  de  flujo  y  se  realizara  una  revisión  de  los  documentos generados del mismo.  ‐>Estimación‐ 8 horas.  T042‐ Análisis de clases  Se  Identificarán  las  clases  más  importantes  y  se  realizarán  diagramas  de  clases  para  cada una de las capas que se diseñen.  8   

‐>Estimación‐ 8 horas.  T05‐ Diseño  En las tareas que se exponen a continuación se realizará el diseño de la aplicación de  acuerdo con los conocimientos obtenidos en la fase de análisis.  T051‐ Prototipo de aplicación  El  diseño  de  los  prototipos  servirá  para  indicar  a  grandes  rasgos  cuál  es  el  aspecto  y  funcionalidad que se desea obtener de la aplicación.  ‐> Estimación‐ 10 horas.   T052‐ Diseño de la base de datos.  Crear  la  base  de  datos  a  partir  del  análisis  realizado  anteriormente  y  crear  diagrama  entidad relación.  ‐>Estimación‐ 8 horas.  T053‐ Diseño interfaz gráfico.  ‐>Estimación‐ 2 horas.  T054‐ Diseño página web.  El diseño de páginas web es un tema que no termino de dominar, por lo tanto estimo  que tardaré bastante tiempo en realizarlo.  ‐>Estimación‐ 10 hora.  T06‐ Construcción  En la fase de construcción se realizan las tareas de implementación y codificación de  todas  las  herramientas  necesarias,  así  como  labores  complementarias  de  la  misma  como la documentación.  T061‐ Desarrollo de la aplicación  Este es el producto final del proyecto. Esta es la aplicación de la página web final que  se  debe  desarrollar,  por  lo  tanto,  el  tiempo  que  se  dedicara  a  esta  tarea  será  considerablemente largo.  Todas o casi todas las tareas de este proyecto guardan relación directa con esta fase.  ‐Estimación‐ 160 horas.  T062‐ Documentación del código  Para una mejor comprensión se comentarán los puntos más críticos del código.  ‐Estimación‐4 horas.  • T07‐ Pruebas  9   

Este  paquete  de  trabajo  agrupa  las  tareas  realizadas  para  comprobar  el  correcto  funcionamiento de la aplicación final.  T071‐ Pruebas durante la implementación  Durante la implementación del código se irán realizando pruebas en la aplicación  ‐>Estimación‐ 4 horas.  T072‐ Pruebas Finales  Última  fase  de  pruebas  en  la  cual  se  realizarán  pruebas  exhaustivas  una  vez  esté  finalizado el programa.  ‐>Estimación‐ 2 horas.  T08‐ Memoria  T081‐ Elaboración de la Memoria  Se  trata  de  la  creación  de  la  memoria  del  proyecto,  el  Documento  de  Objetivos  del  Proyecto no se recoge en este paquete debido a que se determina en PT02.  ‐>Estimación‐ 30 horas.  T09‐ Manuales  T091‐ Manual de usuario  En esta tarea se creará un manual de uso de la aplicación para usuarios potenciales del  sistema.  Mostrará  la  información  necesaria  para  facilitar  al  usuario  la  información  necesaria para una correcta interacción con el programa de gestión.  ‐>Estimación‐ 3 horas.  T10‐ Defensa  T101‐ Defensa del Proyecto  Esta tarea comprende el tiempo dedicado a la preparación de la defensa del proyecto  fin de carrera.   ‐>Estimación‐ 3 horas.  2.9.3 Diagrama de Gantt  El siguiente apartado trata de especificar gráficamente las previsiones realizadas en la  anterior sección.  El total de horas planificado para este proyecto es de 300 horas.  El  gráfico  llega  a  su  final  en  Junio,  fecha  límite  para  la  entrega  del  proyecto,  se  ha  elegido debido a que las nuevas normas de proyectos planifican la presentación en esa  fecha.  10   

 

                                 

11   

2  GESTIÓN DEL PROYECTO  En esta sección se analiza cómo ha ido el transcurso del proyecto realizando un estudio  comparativo entre el tiempo estimado para cada una de las tareas que lo componen y  el tiempo real que se ha dedicado a ellas.  Se realizará un estudio de comparativas de las previsiones totales, y posteriormente se  profundizará la comparación en cada una de las partes.  Normalmente, el trabajo de un día varía entre una hora y media a 3 horas.  Con esta tarea se podrán identificar los desajustes de estimación en el documento de  objetivos del proyecto. Además en cada caso, se analizará si ha existido alguna causa  que justifique el desajuste.  2.1 Diagrama de Gantt Final. 

   

2.2 Errores de planificación.  Por lo general, la planificación del trabajo ha sido correcta, quizás por la experiencia  previa del anterior proyecto realizado.  El problema principal ha sido un parón de un mes y diez días desde el 10 de abril hasta  el 23 de mayo, por lo tanto todas las estimaciones se aplazaron un mes.  El parón de trabajo fue debido a la falta de tiempo, el tener varias asignaturas del  tercer curso, y también un proyecto profesional, no pude dedicarle el tiempo que tenía  previsto al proyecto, y en ese punto preferí aplazar la entrega a la convocatoria de  12   

Julio, y a partir del 23 de mayo, fecha del último examen que tenía, poder dedicarle  jornada completa a la realización del proyecto.  Por supuesto, ha habido algunos desajustes del tiempo estimado al tiempo final, que  se especificarán en la siguiente tabla  Tabla de error de estimación de horas:  Tarea 

Tiempo Estimado 

Tiempo Real 

Error Estimación 

T01‐Dirección y gestión  

19 Horas 

18 Horas 

‐1 Horas 

T02‐Inicio 

11 Horas 

12 Horas 

1 Horas 

T03‐Formación 

18 Horas 

25 Horas 

7 Horas 

T04‐Analisis 

16 Horas 

15 Horas 

‐1 Horas 

T05‐Diseño 

30 Horas 

30 Horas 

0  Horas 

T06‐Construcción 

164 Horas 

158 Horas 

‐6 Horas 

T07‐Pruebas 

6 Horas 

7 Horas 

1 Hora 

T08‐Memoria 

30 Horas 

28 Horas 

‐2 Horas 

T09‐Manuales 

3 Horas 

3 Horas 

0 Horas 

T10‐Presentación 

3 Horas 

3 Horas 

0 Horas 

 

 

ERROR ESTIMACION 

‐2 Horas 

  El error de estimación es tan pequeño puesto que la necesidad de acabar el proyecto  en la fecha indicada hizo que las partes restantes se ajustaran al plazo y por una buena  previsión.               

13   

3.  ANÁLISIS DEL SISTEMA  El objetivo de esta tarea es obtener las especificaciones del sistema necesarias  para  servir de apoyo y satisfacer las necesidades de información de la parte del diseño.  Para  realizar  el  análisis  del  sistema  nos  vamos  a  inspirar  en  las  tareas  referidas  por  métrica 3, profundizando solo en los puntos más importantes.  3.1  Definición del sistema  En esta parte se realizará el análisis del alcance, los usuarios del sistema, los requisitos  del mismo y el entorno tecnológico.  3.1.1  Determinación de los requisitos  Los requisitos son los que ya hemos mencionado en el DOP del proyecto, teniendo una  prioridad  alta  los  requisitos  mínimos  alcanzables  y  una  prioridad  baja  las  posibles  ampliaciones del sistema.  3.1.2 Determinación del entorno tecnológico  En  esta  parte  de  la  memoria  se  van  a  comentar  las  necesidades  tecnológicas  del  sistema de información y los posibles problemas que se supone que pueden conllevar.  Para un correcto funcionamiento de este sistema de información se necesitará el uso  de un servidor, el cual va a tener instalada la base de datos y la aplicación web. Puesto  que el servicio tiene que permanecer activo las 24 horas al día, se optará por el alquiler  de un servidor virtual con las siguientes características:   Sistema operativo Linux.   Framework  de  Ruby  on  Rails  instalado  con  el  correspondiente  intérprete  de  Ruby.   Servidor apache de enlace.    Servidor MySql para la base de datos.  Para  el  desarrollo  de  algunos  puntos  del  proyecto,  como  es  el  acceso  mediante  Facebook  o  Twitter,  añadiremos  determinados  Plugins  llamados  “Gemas”  al  Framework Ruby on Rails, que especificaremos en la parte de desarrollo.  14   

3.1.3 Identificación de los usuarios participantes y finales.  Los roles que van a considerarse en la aplicación Web son:  Usuario: Persona que usa los servicios de la aplicación.  Administrador: Persona encargada del correcto funcionamiento de la aplicación y de la  gestión de la misma.  3.2 CASOS DE USO  En esta sección se establecerán los casos de uso previstos. Para ello se realizarán los  correspondientes  diagramas  y  posteriormente  se  elaborará  la  especificación  de  cada  caso de uso.   Para no caer en la reiteración, solo mostraremos los casos de uso más significativos de  la aplicación, puesto que los casos de uso referidos a la gestión son los habituales en  esta clase de proyectos.   Los  casos  de  uso  que  mostraremos  se  dividirán  en  dos  partes,  la  primera  será  el  diagrama  general  de  casos  de  uso  y  la  segunda  la  explicación  del  mismo  mediante  explicación convencional o de otros diagramas más específicos.  3.2.1 Diagramas de Casos de Uso  ‐Aclaraciones de los diagramas de casos de uso.  Los  diagramas  presentan  alguna  variación  gráfica  con  respecto  a  los  diagramas  de  casos de uso UML, las flechas "extend" e "include" no serán discontinuas, y en vez de  tener  “extend”  se  usará  la  nomenclatura  “extends”,  estas  variaciones  son  debidas  a  que  la  herramienta  con  la  que  se  está  trabajando  (Visio)  para  los  casos  de  uso  UML  tiene definidos los tipos de flecha que voy a usar y no los correctos de UML.   3.2.2 Actores  La aplicación contiene dos tipos de roles Usuario y administrador, especificados en los  Usuarios participantes y finales.          15   

D1.‐APLICACIÓN WEB  Caso de uso de todo el sistema.   

  16   

A  continuación,  detallaremos  el  caso  de  uso  de  la  gestión  de  zonas  deportivas  para  ejemplificar los casos de uso de gestión.  D2‐GESTIÓN DE ZONAS DEPORTIVAS   

                       

17   

Como  caso  de  uso  significativo  del  sistema,  también  detallaremos  la  gestión  de  eventos.  D3‐GESTIÓN DE EVENTOS 

                      18   

3.2.3  Especificación de Casos de Uso  En este punto explicaremos los casos de uso más significativos.  3.2.3 .1 Registro  El  registro  será  accesible  a  todos  los  usuarios  de  la  aplicación  web  para  que  puedan  acceder al sistema. Solo se dará la capacidad de registrarse como usuario. Se creará un  sistema de verificación con el envío de E‐Mail a las cuentas registradas.  Actores:  ‐Usuario.  Propósito  Registrar usuarios en el sistema.    3.2.3 .2 Login  El caso de uso Login se trata de la acción para poder identificar el papel del usuario a la  hora de interactuar con el sistema.  En este caso de uso se introducirán tanto el E‐Mail de usuario como la contraseña, que  previamente  han  sido  introducidas  en  el  registro  del  sistema.  También  se  podrá  acceder al sistema mediante cuentas de Twitter o Facebook. (Mediante sus respectivas  APIs, podemos obtener todos los datos necesarios para realizar un registro correcto.)  Actores:  ‐Usuario, Administrador.  Propósito  Prohibir el acceso a la aplicación a personal no autorizado y distinguir entre usuarios y  administradores del sistema.    3.2.3.3 Gestión de Zonas deportivas  Agrupación lógica de casos de uso que representa todas las acciones necesarias para  gestionar las zonas deportivas en las que se podrán realizar eventos deportivos, tanto  administradores como usuarios podrán insertar, eliminar o modificar zonas deportivas  y el administrador será el encargado de validar las mismas.        19   

Casos de Uso:  3.2.3.3.1 Insertar Zona deportiva  Este caso de uso representa la capacidad, por parte del usuario y del administrador, de  insertar una nueva zona deportiva en la aplicación web introduciendo todos los datos  necesarios. A través de este caso de uso podremos añadir los posibles deportes de la  zona  deportiva,  y  también  gestionar  los  mismos.  (En  la  modificación  también  se  podrán realizar estas últimas acciones.)  Actores:  ‐Usuario, Administrador.  Propósito  Insertar una nueva zona deportiva en el sistema.  3.2.3.3.2 Modificar zona deportiva  Representa  la  acción  de  modificar  una  zona  deportiva  ya  existente  en  la  aplicación,  para  poder  realizar  esta  acción,    se  tendrá  la  capacidad  de realizar  una  búsqueda  de  zonas deportivas, para poder seleccionar la deseada.   Actores:  ‐Usuario, Administrador.  Propósito  Modificar una zona deportiva existente del sistema.                            20   

Diagrama de actividad 

  3.2.3.3.3 Eliminar Zona Deportiva  El caso de uso Eliminar Zona Deportiva otorga la capacidad de eliminar la seleccionada  de la base de datos. Para poder realizar esta acción se tendrá la capacidad de realizar  una búsqueda de zona deportiva, para eliminar la que se desee.   Actores:  ‐Usuario, Administrador.  Propósito  Eliminar una instalación existente del polideportivo.  3.2.3.3.4 Buscar zona deportiva  Representa  la  capacidad  de  buscar  una  zona  deportiva  deseada  entre  todas  las  que  existen en la base de datos, para ello se dispondrá de filtros para poder seleccionar la   que se desee. 

21   

Este  caso  de  uso,  aparte  de  ser  usado  por  el  usuario  del  sistema  puede  ser  una  extensión de otros casos de uso, como por ejemplo el caso de uso modificar o eliminar  zona deportiva.   Además, este caso de uso permitirá acceder a la gestión de eventos.  Actores:  ‐Usuario, Administrador.  Propósito  Búsqueda de zonas deportivas mediante filtros.    3.2.3.4 Gestión de Eventos deportivos  Esta agrupación de casos de uso estará dedicada a gestionar los eventos del sistema.  3.2.3.4.1 Mostrar eventos  Representa la capacidad de buscar los eventos relativos a determinada zona deportiva  (Gestión  de  zonas  deportivas),  deporte  (Gestión  de  deportes)  o  usuario  (Gestión  social).  Actores:  ‐Usuario, Administrador.  Propósito  Búsqueda de eventos mediante filtros de los propios eventos o de otros casos de uso.  3.2.3.4.2 Notificación de eventos  Es un caso de uso que se efectúa cuando se inserta o se anula un evento por parte de  un  usuario  del  sistema,  si  un  usuario  se  apunta  a  determinado  evento  (insertar  evento), se enviarán tres tipos de notificaciones vía correo electrónico:   A los usuarios ya apuntados al evento, se les avisará de que otro usuario más ha  sido apuntado.   A los usuarios que coincidan en los horarios con el evento (Gestión de horarios)  se les enviará una notificación de que se pueden apuntar al evento.   Si se ha completado, se notificará a los participantes del evento y se asignará  aleatoriamente un encargado de reservar la zona deportiva.    Una  vez  el  encargado  confirme  la  reserva,  se  enviará  una  última  notificación  de  confirmación del evento.  22   

Actores:  ‐Ninguno.  Propósito  Notificación por parte del servidor a los usuarios del estado de los eventos.  3.2.3.4.3 Confirmar evento  Una  vez  que  se  ha  recibido  la  notificación  de  que  el  evento  se  ha  completado,  si  el  sistema te ha asignado como encargado de la reserva de la zona deportiva, se podrá  confirmar el evento una vez el usuario haya reservado la zona deportiva.  Actores:  ‐Usuario, Administrador.  Propósito  Confirmación completa del evento.                              23   

3.3  

Análisis de clases. 

Mediante  las  partes  realizadas  anteriormente  en  el  análisis  se  puede  realizar  un  diagrama de clases, identificando las relaciones entre ellas y sus atributos con un nivel  de abstracción elevado. 

            24   

4.  DISEÑO DEL SISTEMA  Una  vez  finalizado  el  análisis  del  sistema  pasaremos  al  diseño  del  mismo.  En  este  apartado realizaremos tareas para definir más detalladamente el modelo de datos, la  estructura de la aplicación y el diseño de la interfaz.  4.1 ‐  Estructura de la aplicación.  4.1.1 –Patrón MVC  El  patrón  o  modelo  de  abstracción  que  se  va  a  utilizar  se  basa  en  Modelo  Vista  Controlador, este tipo de patrón es de los más usados en aplicaciones Web.  1. La  vista  es  la  página HTML y  el  código  que  provee  de  datos  dinámicos  a  la  página.  2. Es la representación de la información con la cual el sistema opera.  3. El  controlador  es  el  responsable  de  recibir  los  eventos  de  entrada  desde  la  vista.  Desarrollar la aplicación web de esta manera otorga varias ventajas:  Dividiendo la lógica del diseño, obtenemos mayor escalabilidad, Facilita el uso de urls  amigables para un mejor posicionamiento SEO, Abstracción de datos.  Por último un ejemplo visual del MVC. 

  25   

4.1.2 –Diseño de MVC  4.1.2.1 Diseño de vista.  Debido a la gran cantidad de vistas solo mostraré las vistas de deportes, amigos, y de  zonas deportivas.  Deportes.   Show: mostrar los deportes.  Amigos.   Show: mostrar los amigos.  Zonas deportivas.   Show: mostrar todas las zonas deportivas.   New: Añadir zona deportiva.   Search: Buscar zona deportiva.   Select: Seleccionar una zona deportiva para la creación.  4.1.2.1 Diseño de controlador.  Deportes.   Show: mostrar los deportes.   Add: añadir deporte.  Amigos.   Show: mostrar los amigos.   Add: Añadir Amigo a la base de datos.   Validate: Validar un usuario que ha realizado una petición de amistad.   Denegate: Denegar petición de amistad.  26   

 Delete: Borrar a un amigo ya aceptado.  Zonas deportivas.   Show: mostrar todas las zonas deportivas.   New: crear zona deportiva.   Search: Buscar zona deportiva.   Select: Seleccionar una zona deportiva para la creación.   Add: Añadir la zona creada a la base de datos.  Cada  uno  de  los  métodos  serán  definidos  en  el  controlador,  y  tendrán  una  vista  asociada en lo que se mostrará la página html, en algunos casos como en amigos new,  no  tendrá  vista  asociada,  puesto  que  add  redirigirá  a  show,  por  lo  que  no  hará  falta  vista.    4.1.2.2 Diseño de modelo.  Una vez obtenido el diseño de las vistas y los controladores, con esta tarea trataremos  de obtener una colección de conceptos que sirven para realizar el diseño de la base de  datos.  4.2 Diseño de la base de datos  Realizaremos  un  diagrama  de  las  tablas  de  la  base  de  datos,  en  este  diagrama   podemos ver la misma al completo, desde todos los atributos con su tipo, a las claves  foráneas,  que  se  delimitan  por  el  campo  que  es  clave  foránea  con  un  triángulo  y  la  tabla a la que apunta esa clave con dos rayas paralelas.   

27   

  4.2.2 Nivel de aislamiento la base de datos.  Debido  a  que  la  base  de  datos  se  hallará  en  el  servidor  de  la  página  Web,  varios  usuarios serían capaces de atacar la base de datos a la vez, si a esto le unimos que la  propia  página  web  va  a  realizar  actualizaciones  a  la  misma  base  de  datos  cabe  la  posibilidad de que varias personas en el mismo momento ataquen a el mismo campo  de  una  tabla  de  la  base  de  datos,  esto  puede  acarrear  serios  problemas  para  la  consistencia de la misma.  Con lo comentado anteriormente se ha decidido que se usará el nivel de aislamiento  “serializable”:  Sentencia SQL: “set transaction isolation level serializable” 

28   

Analizando  el  entorno  de  las  aplicaciones  podemos  deducir  que  la  probabilidad  de  colisión es bastante baja, esto se sabe por los siguientes motivos:   ‐las transacciones en esta aplicación son cortas.  ‐las  actualizaciones  son  bastante  atómicas  (los  usuarios  que  son  el  principal  caso  de  conflicto solo modifican para ellos mismos).   Dicho esto, este nivel de aislamiento es el apropiado, puesto que aunque sea el nivel  de  aislamiento  más  restrictivo  no  se  perderá  demasiada  eficiencia  (bajo  número  de  colisiones), y nos aseguramos de que se mantenga la consistencia en la base de datos.  4.2.3 Usuarios de la base de datos.  Otro de los  puntos a tener en cuenta a la hora de utilizar una la base de datos es el  usuario con el que accedemos a ella en la aplicación.  Es posible que la introducción de código malicioso en la aplicación en la Web por parte  de los usuarios da la base de datos alojada en el servidor, por lo tanto, en la aplicación  web  se  creará  un  usuario  llamado  WebUser  con  los  privilegios  de  SELECT,  INSERT  y  DELETE.  4.3 Diseño de Interfaces  Basándonos en las especificaciones señaladas en el análisis de las interfaces pasamos a  realizar  los  prototipos  de  las  mismas,    se  realizarán  prototipos  generales  para  cada  apartado de la gestión: Inserción, Eliminación, modificación y búsqueda. Y prototipos  específicos para las partes más importantes de la interfaz Web.  Para diseñar las interfaces se ha comprado un template bastante completo realizado  con  HTML  y  Bootstrap,  que  tiene  todas  las  herramientas  necesarias  para  esta  aplicación. https://wrapbootstrap.com/theme/base‐admin‐WB00U99JJ  Las interfaces variarán con logo de la página pero seguirán esta estética      29   

4.3.1 Login y Registro 

   

        30   

4.3.2 Pantalla principal y menús. 

  4.3.3 Área de usuario. 

        31   

4.3.4.1 Eventos. 

  4.3.4.2 Creación de eventos. 

        32   

4.3.5 Pantalla de Errores. 

  4.3.6 Pie 

          33   

5  CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN  En esta tarea se genera tanto la preparación del entorno de programación como todo  el  código  del  sistema  de  información,  y  también  se  especificarán  las  pruebas  que  se  realizarán durante la construcción.  5.1 Preparación del entorno de construcción  Aunque  el  despliegue  final  de  la  aplicación  se  realizará  en  Linux,  en  base  de  datos  MySql, el entorno de construcción se ha realizado en Windows, con una base de datos  Sqlite,  esto  se  ha  decidido  así  por  comodidad,  puesto  que  Windows  es  el  sistema  operativo  que  uso  habitualmente.  La  base  de  datos  Sqlite  se  usó  porque  se  encontraron  problemas  a  la  hora  de  desplegarlo  en  MySql  en  Windows,  y  también  porque  a  la  hora  de  hacer  pruebas  Sqlite  es  bastante  más  liviana  que  MySql,  lo  que  hace que nos ahorremos recursos del sistema.  Para  instalarlo,  he  usado  ‘RailsInstaller’  que  es  un  paquete  de  instalación  para  Windows que contiene, entre otros, los siguientes elementos:  ‐

Ruby 1.9.3‐p392 

‐

Rails 3.2 

‐

Sqlite 

Una  vez  instalado,  y  para  facilitar  la  programación  en  la  plataforma,  he  usado  el  entorno de desarrollo RubyMine, que es el definido por la comunidad como uno de los  mejores IDE para ruby.  http://stackoverflow.com/questions/5724637/pros‐and‐cons‐to‐rubymine‐and‐textmate. 

Después  de  esto,  generamos  una  nueva  aplicación  rails,  y  ya  podemos  empezar  a  desarrollar.  Lo primero que hay que tener en cuenta al ponerse a desarrollar es la complejidad de  utilizar  cualquier  framework,  puesto  que  prácticamente  todo  lo  que  conozco  como  programador está ‘redefinido’, con lo cual hay que aprender todos los métodos y todo  el funcionamiento del framework ‘ruby on rails’ prácticamente desde cero. 

34   

También comentar, que, una vez controlado, ayuda muchísimo el desarrollo y se gana  mucho tiempo a la hora de programar.   Ahora mostraré un ejemplo de la complejidad del framework Rails, nada más crear un  proyecto ‘Hello World’, nos encontramos con la siguiente distribución de ficheros.  Distribución de los directorios en rails 

  Esto nos da una idea de la dificultad de empezar con este tipo de frameworks.            35   

5.2  Implantación de la base de datos  En esta tarea se crean todas las tablas diseñadas en los puntos anteriores. Puesto que  la aplicación se va a desarrollar en el framework ruby on rails,  la base de datos no se  creará mediante el sistema de consultas sql.  En  ruby  on  rails  la  base  de  datos  es  representada  por  Modelos,  los  cuales  hay  que  generarlos mediante el comando   ‘rails generate new model  :, …  Este  comando  generará  varios  elementos,  entre  ellos  un  fichero  de  migración  y  un  fichero de modelos.  Debido a la importancia de estos ficheros, pasaremos a detallarlos a continuación.  5.2.1 Migraciones  Los  ficheros  de  migración  se  crean  en  el  directorio  /db/migrations/  En  la  figura  siguiente se mostrará el ejemplo de ‘deportes’ 

  En este fichero de migración, vemos que crea la tabla ‘sports’, con las columnas name  de  tipo  string,  ‘desctription’  de  tipo  text  y  ‘validated’  de  tipo  boolean.  Los  t.timestamps  son  columnas  en  las  que  se  almacena  el  momento  de  creación  y  de  actualización de la tabla.  Una  vez  creados  todos  los  modelos  con  todas  las  migraciones,  el  comando  ‘rake  db:migrate’,  creará  todas  las  tablas  en  el  sistema  gestor  de  base  de  datos  que  tengamos  configurada  en  el  fichero  ‘/app/config/database.yml’.  Esto  permite  una  36   

abstracción absoluta de la base de datos en la que vayas a trabajar. Solo cambiando el  fichero de configuración podríamos cambiar por ejemplo de mysql a mariadb.  El  fichero  de  migraciones  es  una  pre‐configuración  para  que  la  base  de  datos  sea  posteriormente creada. Puesto que algunas de las tablas tienen que ser rellenadas en  la creación como por ejemplo la tabla ‘city’ o la tabla ‘sport’, para poder poblar la base  de datos en el momento de la creación contamos del fichero /db/db.seed , mediante  métodos Active Record que posteriormente comentaremos.  5.2.2 Modelos  Otro  fichero  que  se  generará  con  el  comando  ‘generate  model’  son  los  modelos,  afincados en /app/models/  La estructura de los mismos es la siguiente: 

  La generación anterior de migraciones crea tablas en la base de datos no relacionadas,  toda  la  consistencia  y  las  relaciones  de  la  base  de  datos  se  realizará  en  los  modelos,  siendo  el  propio  sistema  rails  el  encargado  de  la  consistencia  de  los  datos,  y  no  la  propia base de datos.  En  este  modelo  podemos  ver  ‘attr_accesible’  que  serían  los  atributos  de  la  tabla  anteriormente  generada  a  los  que  podemos  acceder  y  modificar  en  la  aplicación,  los  ‘has_many’  significa  que  hay  una  relación  1‐N  desde  esta  tabla  hacia  por  ejemplo  ‘user_sports’, que tendrá el siguiente modelo. 

  37   

Con este modelo podemos apreciar la definición 1 a N por las dos partes.  5.3 Controladores  Los  controladores  son  los  encargados  de  recibir  las  peticiones  de  los  usuarios  y  disparar las acciones para poder devolver la respuesta a los usuarios y en gran medida  de la lógica de la aplicación. Estos controladores se implementan mediante clases en la  carpeta ‘/app/controllers’.  Se generan mediante el comando ‘rail generate controller mycontroller new create …’ ,   Ejemplo de controlador: 

  Podemos  observar  varias  cosas  en  este  controlador,  primero  vemos  la  clase  ‘SportsController’ que define el controlador del modelo ‘sports’. 

38   

El método before_filter nos permite filtrar las llamadas a esta clase, por lo tanto, en  este caso, si un usuario no tiene una sesión en el sistema, se le redigirá a la pantalla de  login.  El  método  show  define  la  variable  @sports,  que  será  usada  por  la  vista  para  poder  mostrar todos los deportes.  Puesto que rails está basado en COC (Convention over configuration), el método show  hace  una  renderización  por  defecto  de  la  vista  /sport/show.html.erb,  si  quisiéramos  renderizar otra vista podríamos hacerlo con el método ‘render’.  El método add, después de realizar los chequeos oportunos, almacena un deporte en la  base de datos.  Podemos  observar  diversos  métodos  Active  Record.  Esta  es  una  de  las  principales  características  de  rails.  Permite  realizar  consultas,  modificaciones  y  creaciones  a  la  base de datos como si de clases de ruby se trataran.  Por ejemplo, antes veíamos que la tabla ‘user_sports’ tenía una referencia a la tabla  ‘sports’ . Cada una de las referencias de la fila se transforman en clases accesibles a los  elementos que contienen, por ejemplo:    Tabla sports  ID 

nombre 

3 

fútbol 

  Tabla user_sports  ID 

User_id 

Sport_id 

1 

2 

3 

    39   

siendo ‘Us’ una variable de tipo UserSport con ID 1.  Us.sport.name ‐> accederíamos al nombre del deporte asociado a la tabla (fútbol).  También en el ejemplo de arriba podemos ver la creación de un nuevo deporte y su  introducción  en  la  base  de  datos  de  una  forma  muy  amigable  y  abstraída  completamente del Gestor de base de datos que estemos usando.  Una  vez  realizada  la  creación  en  la  base  de  datos  vemos  que  hace  una  redirección  hacia la acción/método, show, de este mismo controlador.  5.4 Vistas  Última  capa  del  modelo  vista  controlador,  que  se  asemeja a  la  capa  de  presentación  del modelo de tres capas.  En  el  anterior  punto  hemos  visto  que  el  controlador  es  el  encargado  de  hacer  renderización de las vistas, seguimos con el ejemplo y ponemos la vista de deporte que  mostraremos en el gráfico 6.4.1.  También  comentar,  que  por  defecto,  a  la  hora  de  hacer  una  renderización,  se  llama  también  a  ‘/app/views/layout/application.html.erb’  esto  sirve  para  introducir  la  cabecera y el pie de la aplicación web, con el parámetro  que renderizará  la vista que muestre el controlador.  5.4.1 Vista de deportes   /app/views/sport/show.html.erb  Deportes

40

false %> Añadir Deporte Nombre Descripcion Añadir alert('');

 

41   

Como  hemos  comentado  antes,  la  cabecera  y  el  pie  estarían  en  el  fichero  /app/views/layout/application.html.erb, además se pueden observar la variable que se  han declarado en el controlador, @sports para mostrarlos, y una llamada a /sport/add,  para la creación del deporte mediante el formulario.  Los tres puntos anteriores forman el paradigma MVC, modelo, vista, controlador.  5.5 Librerías externas utilizadas  Las  librerías  externas  que  se  han  utilizado  para  el  desarrollo  de  la  aplicación  son  las  siguientes:  ‐Gemas de rails: Librerías de funciones o plugins para rails que permiten realizar todo  tipo de funciones para las aplicaciones web.   Paginate:  Sirve  para  mostrar  la  paginación  de  los  elementos  rails  con  una  simple declaración.    Devise: Conjunto de herramientas para la gestión de usuarios de una aplicación  web.   Omniauth: librería para el acceso a twitter y facebook.  ‐Jquery: librerías de funciones que facilitan el desarrollo en javascript.  ‐Google  Maps  Api:  Api  de  desarrollo  de  google  maps,  se  ha  utilizado  para  señalar  y  crear la disposición geográfica de las zonas deportivas en la aplicación.  ‐Jquery  WeekCalendar:  Para  mostrar  y  crear  horarios  de  una  forma  intuitiva,  se  ha  usado  esta  librería,  que  crea  un  horario  semanal  en  javascript  con  el  que  el  usuario  puede interactuar.  ‐Jquery  Multiselect:  Elemento  javascript  que  mezcla  el  combo  y  con  las  checks,  para  realizar selecciones múltiples fácilmente.    5.6 Seguridad de la aplicación. 

42   

Otra de las ventajas de utilizar un framework como ruby on rails, es la seguridad por  defecto que otorga, todo lo que se desarrolla está delimitado por la estructura de la  propia plataforma, lo que te obliga a utilizar buenas prácticas de seguridad, a parte de  las propias características de seguridad del sistema como por ejemplo.   Sistema de sesiones.   Manejo de bases de datos mediante Active Record (Evita SQL Injection).   Filtros  de  acceso  en  los  controladores,  se  tienen  que  implementar,  pero  facilitan mucho el trabajo para la seguridad.  Por  supuesto,  el  framework  no  evita  todos  los  posibles  ataques,  por  lo  que  se  ha  procurado  realizar  controles  en  todas  las  peticiones  post  y  get  de  los  parámetros  enviados para evitar problemas.   5.7 Problemas encontrados durante el desarrollo de la aplicación.  Uso del entorno ruby on rails.  El principal problema a la hora de desarrollar la aplicación ha sido el uso del framework  Ruby on Rails.   Sus  principales  puntos  más  complicados  son  la  distribución  de  los  directorios  en  el  entorno, son muchísimos elementos, a primera vista desperdigados, conectados entre  sí  por  convenciones  de  nombres,  esto  hace  que  entres  en  el  desarrollo  un  poco  perdido.  Otro  de  los  elementos  que  me  han  dado  problemas  ha  sido  la  utilización  de  active  record,  es  una  herramienta  potentísima  pero  que  implica  el  estudio  de  todos  sus  métodos para un correcto uso.  Los  demás  elementos  son  los  típicos  de  aplicaciones  web,  y  no  he  tenido  prácticamente problemas.  Despliegue de la aplicación en bluehost 

43   

En  el  despliegue  de  la  aplicación  en  internet  se  han  encontrado  varios  problemas,  sobre  todo  a  la  hora  de  configurar  el  servidor  apache  con  ruby  on  rails,  para  el  desarrollo, Rails usa el servidor Webrick, que es bastante rápido y liviano, pero que no  da los mismos resultados que apache a la hora de utilizarse en un entorno real. Para  poder usarlo se ha usado Passenger, es un tema que se desconocía y que ha ocupado  bastante tiempo solucionarlo.  Tiempo   Uno de los principales problemas y el cual ha hecho que retrase la presentación a Julio  es la falta de tiempo, el tener asignaturas de 3º y el desarrollo de un proyecto personal  me  ha  quitado  gran  parte  del  tiempo  que  en  un  principio  tenía  previsto  para  la  realización del PFG.  5.8 Posibles Mejoras  Aplicación para Móvil.‐ Creo que una aplicación móvil vendría muy bien a esta página  web, puesto que el poder acceder directamente a los eventos sería muy interesante.   Mejora de sistema social.‐  Al final la aplicación ha quedado algo coja con el sistema  social,  quizás  la  creación  de  un  chat  o  de  algún  sistema  de  amistades  mejoraría  bastante la aplicación.                 

44   

    6   CONCLUSIONES  Uno de los motivos de la realización de una aplicación web de esta envergadura es que  laboralmente no he desarrollado prácticamente nada del paradigma web, y veía el PFG  como una gran oportunidad de aprendizaje y crecimiento personal.  También opté por desarrollarla en un framework porque en la asignatura de desarrollo  de aplicaciones web conocimos el método tradicional de desarrollo.  Al  final  creo  que  el  resultado  ha  sido  bastante  bueno,  ha  quedado  una  página  Web  muy  vistosa  y  sencilla  de  utilizar,  con  una  integración  con  las  Apis  de  google  y  elementos javascript muy interesante.  También quería destacar que veo como buena medida el nuevo sistema de desarrollo  de PFG, puesto que con el límite de 50 páginas hace que nos centremos en los puntos  más importantes del desarrollo y que no se haga demasiado pesada la elaboración del  mismo.                   

45   

    8  BIBLIOGRAFÍA  ‐Métodos, documentación y ejemplos del framework ruby on rails  http://rubyonrails.org/documentation  ‐Bases de ruby on rails con ejemplos prácticos.   http://railsforzombies.org/  ‐Explicación del modelo vista controlador detallada  http://es.wikipedia.org/wiki/Modelo_Vista_Controlador  ‐Api de google maps para integración con la aplicación.   

https://developers.google.com/maps/ 

‐Apuntes de la asignatura Programación de aplicaciones web de la Universidad de La  Rioja. Impartida por Francisco José García Izquierdo.                   

46   

    ANEXO I. MANUAL DE USUARIO  Registro  Para registrarse en la aplicación hay que acceder a http://127.0.0.1:3000/users/sign_up o  hacer click en “registrarse” en la parte superior derecha de la página de inicio. 

  Introducimos nuestros datos y creamos la cuenta.  Configurar cuenta de usuario  Una vez hemos accedido a la aplicación, hay que introducir los datos de usuario, así  como una foto de avatar. Para hacerlo clikamos en: 

    47   

    Una vez accedemos a la cuenta introducimos nuestros datos y una foto de avatar 

  Configurar deportes  Para configurar los deportes que vamos a practicar accedemos a 

48   

  Ahí nos aparecerá la siguiente página 

  En la parte izquierda haciendo click en el botón + podremos añadir deportes y a la  derecha podremos introducir nuevos deportes que no estén en el sistema.  Configurar calendario de horas libres  Accedemos al calendario en la siguiente opción de menú 

 

49   

En la siguiente pantalla, podremos seleccionar las horas libres haciendo click en las  horas que queramos y arrastrando, también podemos copiar el horario semanal a las  semanas posteriores con la opción del panel derecho.  Para que el sistema nos notifique de eventos en nuestra localidad en las horas libres  tendremos que marcar la opción, recibir notificaciones de eventos. 

  Eventos  Una vez realizada la configuración ya podremos usar plenamente la aplicación, como  por ejemplo ver eventos disponibles en el menú Eventos 

  Podremos ver los eventos a los que estamos apuntados en la parte superior, con los  usuarios  apuntados  al  evento,  ver  los  eventos  a  los  que  podemos  apuntarnos  con  el  buscador de la tabla inferior, y crear nuevos eventos en el botón “crear evento” de la  tabla derecha. 

50   

  Crear Evento 

  Zonas deportivas  Si  quieres  practicar  deportes  en  zonas  deportivas  particulares  o  no  registradas  en  el  programa, podemos ver e introducir nuevas zonas en  Menú configuración ‐> Zonas Deportivas 

51   

  Pichando en los marcadores del mapa podremos ver las zonas deportivas, y en crear  zona deportiva accederemos a la siguiente pantalla.  Crear zona deportiva 

  Amigos  Accedemos en menú ‐> Social ‐> Amigos 

52   

  Podremos añadir amigos en la parte superior derecha, en la parte superior izquierda  veremos  a  los  amigos  ya  agregados,  con  la  posibilidad  de  enviar  mensajes,  y  en  la  inferior derecha veremos las solicitudes de amistad, con la posibilidad de descartar o  aceptar.     

53