Embed Size (px)
Citation preview
Javier Muro Robles
Red social deportiva
César Domínguez Pérez
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Grado en Ingeniería Informática
2012-2013
Título
Autor/es
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.esE-mail: [email protected]
Red social deportiva, trabajo fin de gradode Javier Muro Robles, dirigido por César Domínguez Pérez (publicado por la Universidad
de La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a lostitulares del copyright.
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
2.2 Errores de planificación
3. ANALISIS. 14
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 <Nombre del modelo> <nombre_columna>:<tipo_dato>, …
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 <%= yield %> que renderizará
la vista que muestre el controlador.
5.4.1 Vista de deportes
/app/views/sport/show.html.erb
<div class="main"> <div class="main-inner"> <div class="container"> <div class="row"> <div class="span6"> <div class="widget widget-table action-table"> <div class="widget-header"> <i class="icon-dribbble"></i> <h3>Deportes</h3> </div> <div class="widget-content"> <table class="table table-striped table-bordered"> <tbody> <% @sports.each do |s| %> <tr> <td width="20%"><%= s.name %></td> <td width="70%"><%= s.description %></td> <td width="10%" class="td-actions">
40
<% practice = false #current_user.user_sports.each do |us| UserSport.find_all_by_user_id(current_user.id).each do |us| if s == us.sport practice = true end end if practice == false %> <a href="/user_sport/add?sport=<%= s.name %>&page=<%= params[:page] %>" class="btn btn-small btn-warning"> <i class="btn-icon-only icon-plus"></i> </a> <% else %> <a href="/user_sport/remove?sport=<%= s.name %>&page=<%= params[:page] %>" class="btn btn-small btn-success"> <i class="btn-icon-only icon-ok"></i> </a> <% end %> </td> </tr> <% end %> </tbody> </table> </div> <div class="digg_pagination"> <%= will_paginate @sports, :container => false %> </div> </div> </div> <div class="span6"> <div class="widget "> <div class="widget-header"> <i class="icon-dribbble"></i> <h3>Añadir Deporte</h3> </div> <div class="widget-content"> <form id="add-sport" class="form-horizontal" action="./add" method="POST"> <fieldset> <div class="control-group"> <label class="control-label">Nombre</label> <div class="controls"> <input type="text" class="input-medium" name="name"> </div> </div> <div class="control-group"> <label class="control-label">Descripcion</label> <div class="controls"> <textarea cols="35" rows="5" name="description"></textarea> </div> </div> <div class="form-actions"> <button type="submit" class="btn btn-primary">Añadir</button> </div> </fieldset> </form> </div> </div> </div> </div> </div> </div> </div> <% if @mens != nil %> <SCRIPT Language=Javascript> alert('<%= @mens %>'); </SCRIPT> <% end %>
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
